REQUISITOS
Analise de Sistema
• Requisitos
• Modelo lógico do sistema
• Diagrama de fluxo de dados,
• Dicionário de dados,
Processo de Analise
•
ENGENHARIA DE SOFTWARE
• ENGENHARIA DE REQUISITOS
• FUNDAMENTOS DE REQUISITOS DE SOFTWARE
• PROCESSO DE REQUISITOS
• ELICITAÇÃO DE REQUISITOS
• ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• DOCUMENTAÇÃO DE REQUISITOS
• VALIDAÇÃO DE REQUISITOS
• PROBLEMAS NA ENGENHARIA DE REQUISITOS
• BOAS PRÁTICAS
• MODELO DE CASO DE USO – ATORES E CASOS DE USO
• MODELO DE CASO DE USO – ESTRUTURAÇÃO
•
“A engenharia refere-se à prática das atividades organizadas de projeto, construção e operação de qualquer artefato que transforme os mundos físico e social ao nosso redor para atender a alguma necessidade reconhecida...”
•
“Desenvolvimento e aplicação sistemática de modelos de comprovada eficácia gerando soluções tecnológicas para problemas da humanidade (prof. Jose Fernandes UFRN)
ENGENHARIA DE SOFTWARE
•
A IEEE define a Engenharia de Software como:
• A aplicação de uma abordagem sistemática, disciplinada e quantificável para desenvolvimento, operação e manutenção de software; isto é, a aplicação da engenharia para o software.
• IEEE - Acrônimo para Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Eletricistas e Eletrônicos), uma organização composta por engenheiros, cientistas e estudantes, que desenvolvem padrões para a indústria de computadores e eletro-eletrônicos.
•
“Engenharia de Software é a uma área de interesse (disciplina) preocupada com a criação e manutenção de aplicações de software pela aplicação de tecnologias e práticas da ciência da computação, gerência de projetos, engenharia, domínios de aplicação e outros campos”.
ENGENHARIA DE SOFTWARE
SWEBOK – (Software Engineering Body of Knowledge)
• É uma iniciativa da IEEE Computer Society em criar um consenso sobre as áreas de conhecimento da engenharia de software e seu escopo.
• O SWEBOK (Organização do Conhecimento de Engenharia de Software) é um guia de uso e aplicação das melhores práticas de Engenharia de Software, informado, sensato e razoável. Ele foi desenvolvido com conhecimentos recolhidos no período de 4 décadas e revisado por inúmeros profissionais de diversos países envolvidos com a Engenharia de Software.
• Seu principal objetivo foi estabelecer um conjunto apropriado de critérios e normas para a prática profissional da Engenharia de Software. Neste guia, a
SWEBOK – (Software Engineering Body of Knowledge)
Áreas de
Conhecimento (Disciplinas)
Requisitos de Software Manutenção de Software Qualidade de Software
Gerenciamento de Configuração Software
Ferramentas e Métodos de Engenharia de Software Construção de Software
Teste de Software Desenho de Software
Gerenciamento de Engenharia Software Processo de Engenharia de Software Requisitos de Software
REQUISITOS DE SOFTWARE
Requisitos
O que é requisitos ?
•
que foi requisitado, requerido, solicitado (...)
•
condição para se alcançar determinado fim.
•
exigência de ordem legal necessária para a validade de
um ato jurídico; condição; formalidade (...)
Requisitos de Software
• uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo;
• é o que o sistema deve fazer para implementar uma necessidade de automação requerida pela solução. Desde as necessidades básicas do cliente, premissas e restrições obtidas na fase de levantamento do projeto até as condições de negócio explicitadas no contrato com o fornecedor da solução.
• conjunto de definições que descreve como o sistema deve ser construído e testado
• Propriedade que o sistema deve apresentar para resolver um problema real (SWEBOK, 2004)
REQUISITOS DE SOFTWARE
Características dos Requisitos
São os grandes
“vilões” da engenharia de software
Grande impacto sobre o desenvolvimento
e manutenção
Sub-áreas de conhecimento de Requisitos de Software
Fundamentos de Requisitos de
Software
Processo de requisitos
Elicitação de Requisitos
Considerações Práticas
Análise de Requisitos
Especificação de Requisitos Requisitos de Software
(Área de Conhecimento)
Validação de Requisitos
ENGENHARIA DE REQUISITOS
Porque Engenharia de Requisitos?
Os números da área de Engenharia de Software não são animadores…
• O CHAOS Report de 2003 (Standish Group) apresentou as seguintes estatísticas:
– 34% dos projetos são bem sucedidos;
–15% dos projetos foram cancelados;
–43% é o erro médio em relação ao orçamento do projeto daqueles que foram completados;
–52% das características (requisitos não funcionais) e funcionalidades são entregues no produto.
Algo relacionado com a Engenharia de Requisitos?
•
O que disse o SEI - Software Engineering Institute:
• Dois principais fatores de falhas de orçamentos e cronograma são problemas de requisitos:
•Especificação de requisitos inadequada
•Mudanças em requisitos
•
70 a 85% dos erros encontrados em software podem ser rastreados para problemas de requisitos
(Barry Boehm, 1981)•
Os erros mais caros de se corrigir em um projeto de software são os originados nesta etapa.
• Se partimos de algo com problemas, que não atende ao usuário...
certamente não chegaremos ao sucesso.
ENGENHARIA DE REQUISITOS
Custo de Requisitos
•
O custo relativo para correção de um problema de requisitos em cada fase do sistema é
(Boehm and Papaccio 19882):• $1 na fase de análise de requisitos
• $5 na fase de projeto do sistema
• $10 na fase de codificação
• $20 na fase de testes unitários
• $200 após a entrega do produto
Fatores de Falhas nos Projetos
•
Objetivos não estavam claros
•
Ignorar um grupo de clientes
•
Requisitos e Especificações incompletas
•
Requisitos e Especificações instáveis (mudanças)
•
Omitir um grupo de requisitos
•
Permitir inconsistências entre grupos de requisitos
•
Aceitar requisitos inadequados, incorretos, indefinidos e impreciso
•
Aceitar um requisito ambíguo e inconsistente
ENGENHARIA DE REQUISITOS
•
Não importa quão bem projetado ou codificado está um
programa, se ele for mal analisado e especificado
desapontará o usuário e trará aborrecimentos ao
desenvolvedor
•
Importância da Engenharia de Software
•
Mps.Br – Melhoria do processo de software brasileiro
• O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS). Voltado para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil, ele é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e compatível com o CMMI.
(Wikipedia.org)
ENGENHARIA DE REQUISITOS
•
Importância da Engenharia de Software
•
Mps.Br – Melhoria do processo de software brasileiro
•
Importância da Engenharia de Software
•
CMMI - Capability Maturity Model Integration
• O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.
• O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção.
ENGENHARIA DE REQUISITOS
•
Importância da Engenharia de Software
•
CMMI - Capability Maturity Model Integration
•
Importância da Engenharia de Software
•
CMMI - Capability Maturity Model Integration
• NÍVEL 2 – Gerenciado
• Gerência de requisitos,
• Planejamento do Projeto,
• Monitoração e Controle do Projeto,
• Garantia da Qualidade do Processo e do
• Produto,
• Gerência de Configuração,…
•Entendimento comum entre o cliente e o fornecedor quanto aos requisitos que serão atendidos no projeto de software
•Acordo entre os envolvidos com o projeto sobre os requisitos e suas mudanças ao longo do mesmo.
ENGENHARIA DE REQUISITOS
•
Resumindo...
•
Resumindo...
•
Necessidade
• A origem de tudo!
• Se não há qualquer necessidade, é porque não existe problema
• Necessidade é igual a problema operacional ou de negócio que precisa ser resolvido
•
O que é um requisito de software?
• Propriedade que deve ser atendida com o objetivo de resolver algum problema no mundo real
• Descrevem comportamento, propriedade e atributo dos softwares
• As vezes permite múltiplas interpretações
• Dever ser testáveis
• Devem ser unicamente identificados
• É o processo de estabelecer os serviços que o cliente necessita do sistema e as restrições sob as quais ele opera e é desenvolvido.
• Os próprios requisitos são as descrições dos serviços do sistema e restrições geradas durante o processo de engenharia de requisitos.
ENGENHARIA DE REQUISITOS
O que é um requisito?
• Um requisito consiste de atributos, propriedade ou comportamento que um produto ou serviço particular deve atender.
• Requisitos são tipicamente utilizados como informações fundamentais para a fase de projeto de um produto ou serviço, especificando as propriedades e funções necessárias (ou desejáveis) a serem consideradas no desenvolvimento do projeto em questão.
Tipos de requisitos
• Requisitos de usuário
Declarações em linguagem natural com diagramas dos serviços que o sistema deverá fornecer e suas restrições operacionais. Escrito para os clientes.
• Requisitos de sistema
Um documento estruturado estabelecendo descrições detalhadas das funções do sistema, serviços e restrições operacionais. Define o que
ENGENHARIA DE REQUISITOS
• Um sistema de informação em que pacientes necessitam de cuidados com saúde mentais
• Um sistema de informações do paciente para dar suporte aos serviços de saúde mental é um sistema de informações médicas que mantém informações sobre pacientes que sofrem de problemas de saúde mental e os tratamentos que receberam.
• A maioria dos pacientes de saúde mental não necessitam de tratamento hospitalar dedicado, mas precisam comparecer regularmente a clínicas especializadas onde possam encontrar um médico que tenha conhecimento detalhado dos seus problemas.
• Para facilitar o comparecimento dos pacientes, essas consultas não precisam acontecer apenas em hospitais. Elas também podem ser realizadas em locais de práticas médicas ou centros comunitários.
Exemplo - MHC-PMS
• O MHC-PMS (Sistema de Gerenciamento de Pacientes com Problemas de Saúde Mental) é um sistema de informações destinado para uso em clínicas.
• Ele faz uso de um banco de dados centralizado de informações sobre os pacientes, mas também foi projetado para rodar em um PC, de modo que possa ser acessado e usado a partir de sites que não tenha conectividade de rede.
• Quando os sistemas locais têm acesso à rede, eles usam as informações do paciente que constam no banco de dados, mas, quando desconectados, podem baixar e usar cópias locais de registros de pacientes.
•
Gerar informações gerenciais que permitam aos gerentes de serviços de saúde avaliar o desempenho contra alvos locais e de governo.
•
Fornecer informações atualizadas para a equipe médica para apoiar o tratamento dos pacientes.
Exemplo - A organização do MHC-PMS
• Gerenciamento do cuidado individual
O pessoal clínico pode criar registros de pacientes, editar as informações no sistema, ver o histórico dos pacientes, etc. O sistema suporta resumos de dados para que os médicos possam aprender rapidamente sobre os principais problemas e tratamentos que foram prescritos.
• Monitoramento de pacientes
O sistema monitora os registros dos pacientes envolvidos no tratamento e emitem alertas, no caso de possíveis problemas serem detectados.
• Relatórios administrativos
O sistema gera relatórios gerenciais mensais mostrando o número de pacientes tratados em cada clínica, o número de pacientes que têm entrado e saído do sistema de assistência, o número de pacientes internados, os remédios prescritos e seus custos, etc.
Exemplo - Preocupações do MHC-PMS
•
Privacidade
É essencial que as informações do paciente sejam confidenciais e nunca sejam reveladas para ninguém além do pessoal médico autorizado e que o próprio paciente.
•
Segurança
Algumas doenças mentais levar o paciente a tornar-se suicida
ou um perigo para outras pessoas. Sempre que possível, o
sistema deve alertar profissionais de saúde sobre os pacientes
potencialmente suicidas ou perigosos. O sistema deve estar
disponível quando necessário, de outra forma, a segurança
pode ser comprometida e pode ser impossível prescrever a
medicação correta para os pacientes.
Leitores de diferentes tipos de especificação de requisitos
ENGENHARIA DE REQUISITOS
Requisitos Funcionais, Não-funcionais e de Domínio
• Requisitos funcionais
O sistema deve fornecer declarações de serviços, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
Pode explicitar o que o sistema não deve fazer.
• Requisitos não-funcionais
Restrições aos serviços ou funções oferecidas pelo sistema, tais como restrições de tempo, restrições no processo de desenvolvimento, padrões.
Muitas vezes se aplica ao sistema como um todo ao invés de características individuais ou serviços.
• Requisitos de domínio
• Restrições no sistema a partir do domínio de operação
Requisitos Funcionais
•
Descrever a funcionalidade ou os serviços do sistema.
•
Requisitos funcionais dos usuários podem ser declarações de alto nível a respeito do que o sistema deve fazer.
•
Requisitos funcionais do sistema devem descrever detalhadamente os serviços do sistema.
ENGENHARIA DE REQUISITOS
Requisitos Funcionais
•
Definem funcionalidades do software
• Operações que clientes e usuários querem, ou precisam, que sejam realizadas pelo sistema
•
Exemplo:
• – Possibilitar consulta de Saldo e Extrato em Caixas Eletrônicos e pela Internet
• – Permitir impressão de cheques em Caixas Eletrônicos
• – Permitir solicitação de entrega de talão cheques pela Internet;
Exemplo - Requisitos funcionais para o MHC-PMS
• Um usuário deve ser capaz de pesquisar as listas de agendamentos para todas as clínicas.
• O sistema deve gerar, a cada dia, para cada clínica, uma lista de pacientes esperados para as consultas daquele dia.
• Cada membro da equipe que usa o sistema deve ser exclusivamente identificado pelo seu número de funcionário de 8 dígitos.
ENGENHARIA DE REQUISITOS
Imprecisão de requisitos
• Problemas surgem quando os requisitos não são precisamente definidos.
• Requisitos ambíguos podem ser interpretados de maneiras diferentes por desenvolvedores e usuários.
• Exemplo:
• Requisito 1 - Um usuário deve ser capaz de pesquisar as listas de agendamentos para todas as clínicas.
•
Considere o termo 'pesquisa' no requisito 1
• A intenção do usuário – busca pelo nome de um paciente em todos as consultas em todas as clínicas;
• Interpretação do desenvolvedor – busca pelo nome de um paciente em uma clínica. O usuário escolhe a clínica e em seguida pesquisa.
Integridade e consistência dos requisitos
• Em princípio, os requisitos devem ser completos e consistentes.
• Completos
Eles devem incluir descrições de todos os serviços necessários.
• Consistentes
Não devem haver conflitos ou contradições nas descrições dos recursos do sistema.
• Na prática, é impossível produzir documentos de requisitos completos e consistentes .
Trabalho Maçante e Cansativo
ENGENHARIA DE REQUISITOS
Requisitos Não-funcionais
• Esses requisitos definem as propriedades e as restrições do sistema por exemplo, confiabilidade, tempo de resposta e ocupação de área.
• As restrições são capacidades de dispositivos de E/S.
• Os requisitos não-funcionais também podem ser especificados impondo um IDE particular, linguagem de programação ou método de desenvolvimento.
• Os requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais. Se esses não forem atendidos, o sistema pode ser inútil.
Requisitos Não-funcionais
• Atuam na limitação da solução
• Conhecidos como limitações (no sistema e/ou processo de desenvolvimento) ou requisitos de qualidade
• Dizem respeito a:
aspectos de desempenho,
interfaces com o usuário,
confiabilidade,
segurança,
manutenibilidade,
ENGENHARIA DE REQUISITOS
Requisitos Não-funcionais
• Tipo de interface desejada
• Facilidade de uso necessária
• Volume de utilização (número de usuários, número de transações,...)
• Hardware e software alvo para o produto
• Desempenho
• Segurança
• Compatibilidade com outros produtos/versões e necessidades de migração
• Necessidades de customização do produto pelo cliente
• Suporte
• Preço da solução
• Documentação necessária
• Uso de padrões
• Aspectos legais
• Integração com outros produtos
• Requisitos de instalação
• Tolerância a falha
Requisitos Não-funcionais
•
São críticos para o sucesso de sistemas de software
•
Os defeitos provenientes da não elicitação ou elicitação incorreta de Requisitos Não Funcionais (RNFs) estão entre os requisitos mais caros e difíceis de se corrigir.
Softwares de baixa qualidade
Tempo e custo maiores que os planejados
Insatisfação dos clientes e da equipe de desenvolvimento
•
As consequências da desconsideração de um RNF são frequentemente mais severas do que as decorrentes de um
ENGENHARIA DE REQUISITOS
Exemplos de Requisitos Não-funcionais
Tipos de requisitos não funcionais
ENGENHARIA DE REQUISITOS
Classificações de requisitos não funcionais
• Requisitos de produto
Requisitos que especificam que o produto entregue deve se comportar de uma maneira particular, por exemplo velocidade de execução, confiabilidade, etc.
• Requisitos organizacionais
Requisitos que são consequência de políticas e procedimentos organizacionais, por exemplo padrões de processo usados, requisitos de implementação, etc.
• Requisitos externos
Requisitos que surgem de fatores externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de reguladores, requisitos legais, etc.
Exemplos de requisitos não funcionais no MHC-PMS
ENGENHARIA DE REQUISITOS
Implementação de requisitos não funcionais
•
Requisitos não-funcionais podem afetar a arquitetura geral de um sistema, em vez de componentes individuais.
Exemplo
Para assegurar que os requisitos de desempenho sejam cumpridos, você pode ter que organizar o sistema para minimizar a comunicação entre os componentes.
•
Um único requisito não-funcional, como um requisito de proteção, pode gerar uma série de requisitos funcionais relacionados que definem os serviços do sistema que são necessários.
•
Ele também pode gerar requisitos que restringem os requisitos existentes. (conflitos entre requisitos)
Metas e requisitos
•
Requisitos não-funcionais podem ser muito difíceis de se definir precisamente e requisitos imprecisos podem ser difíceis de se verificar.
•
Metas Produzir Requisito não-funcional mensurável.
Uma declaração usando alguma métrica que pode ser objetivamente testada.
•
Metas são úteis para desenvolvedores quando exprimem as intenções dos usuários do sistema.
ENGENHARIA DE REQUISITOS
se tornem verificáveis
Requisito Inverificável Requisito Verificável
“ O banco de dados ZZ deve ser flexível”
• O banco de dados ZZ deve possuir oito campos por registro.
“MNOP deve ser seguro” • MNOP deve parar sua operação se uma pessoa se aproximar a mais de 2 metros de uma de suas partes móveis
• MNOP deve desligar os aquecedores se a temperatura da água exceder 37°C
• MNOP deve estar dentro dos padrões estabelecidos pela norma N567 seção 3.6 para temperaturas de superfícies externas.
“O sistema CE deve processar depósitos rapidamente”
• O sistema CE deve escanear os dados do usuário e conta de cada folheto de depósito em 2 segundos ou menos”
•
Algumas palavras levam a requisitos impossíveis de serem verificados
ENGENHARIA DE REQUISITOS
Palavras não Verificáveis Possíveis substitutos
Amigável • Número máximo de passos
• Lista de funcionalidades presentes
• Menus ou acesso via teclado para auxiliar usuários
Portável • Dimensões
• Requisitos mínimos de hardware
• Sistemas operacionais em que deve funcionar Pequeno • Dimensões aceitáveis (em número de Bytes) Flexível • Variáveis que podem acomodar uma gama de
mudanças de valores
• Funções que implementam uma de várias possibilidades
difícil de usar e demora muito para executar operações simples!” Discussão:
O que pode estar faltando?
2. Em qual nível do CMMI encontra- se a Gerência de Requisitos?
a. Gerenciado b. Inicial c. Definido
d. Em otimização e. Gerenciado Quantitativamente 3. Indique o tipo do requisito:
a) O sistema deve manter registros de todos os materiais da biblioteca, incluindo livros, jornais, revistas, vídeo, áudio, relatórios, CDs e DVDs b) O sistema deve permitir os usuários pesquisarem qualquer item por título, autor ou ISBN.
c) O sistema deve se desenvolvido em plataforma Dot Net.
d) O sistema deve suportar pelo menos 20 transações por segundo.
e) As principais funcionalidades do sistema, disponíveis para o público, devem poder ser apresentadas em menos de 15 minutos.
Classifique os requisitos em Funcionais e Não Funcionais
• O sistema deve autenticar o usuário no sistema mediante a informação de login e senha.
• O usuário autorizado deverá efetuar logon no sistema para poder realizar as operações de manutenção de cadastros de usuários autorizados e documentos.
• Permite ao usuário se cadastrar ou alterar seu cadastro no sistema para criar leilões, dar lances em leilões abertos ou abrir seu próprio leilão.
• O sistema deve ser desenvolvido em C#.
Discussão
• O sistema deve ter uma interface de fácil utilização.
• Permite ao usuário efetuar um lance em leilões em aberto.
• Permite ao usuário pesquisar leilões abertos, podendo este utilizar filtros para pesquisa.
• O sistema deve estar disponível 24 horas por dia durante os 7 dias da semana. Por não se tratar de um sistema crítico, o sistema poderá ficar fora do ar até que seja corrigida alguma falha que possa ocorrer.
• Permite ao sistema do cliente obter a lista dos meios de pagamentos disponíveis.
•
