Análise e Gerência de Requisitos

Fabiano Oss, 2014
fabiano.oss@gmail.com

1

Objetivos
• Compreender os principais conceitos sobre
Requisitos de Software;
• Selecionar a melhor técnica para
levantamento de requisitos;
• Especificar requisitos usando Casos de Uso;
• Conhecer a Gerência de Requisitos;
• Compreender como os processos de software
tratam a Gerência de Requisitos.
2

Referências

MACHADO, Felipe Nery. Análise e Gestão de
Requisitos de Software: onde nascem os
sistemas. São Paulo: Editora Érica, 2011.

3

Porto Alegre: Bookman.Referências LARMAN. 3a. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 4 . 2007. ed. Graig.

São Paulo: Addison Wesley. 8a. ed.Referências SOMMERVILLE. Ian. 2007. Engenharia de Software. 5 .

Raul Sidnei. 6 . 2011. Rio de Janeiro. 2a. Análise e Projeto de Sistemas de Informação Orientados a Objetos. ed.Referências WAZLAWICK.

Site: http://alistair. Escrevendo Casos de Uso Eficazes.cockburn. Alistair. São Paulo: Addison Wesley. 2005.us/Use+cases 7 .Referências COCKBURN.

Klaus.Referências POHL. Requirements Engineering Fundamentals. RUPP Chis. CA. Sebastopol. 8 . O’ Reilly. 2011.

Avaliação • Exercícios. • Trabalho Final 9 .

Roteiro • • • • • • • • • Introdução Requisitos de Software Visão Geral do Sistema Técnicas de Analise e Levantamento de Requisitos Especificaçao de Requisitos com Casos de Uso Engenharia de Requisitos Gerência de Requisitos CMMI e Requisitos RUP e Requisitos 10 .

Projeto de Sucesso 11 .

dentro das restrições de tempo e custo. • [Gasnier. produzindo produtos de qualidade. mantendo e promovendo relações harmoniosas entre os envolvidos.Projetos de Sucesso • Um projeto de sucesso satisfaz seus clientes e patrocinadores com resultados que atendem aos seus objetivos. incluindo os executores. e contribuindo para o aprendizado da organização. 2000] 12 .

Cenário dos Projetos 60.00% 0.00% 1994 1996 1998 2000 2002 2004 Fonte: Chaos Report 2006 2009 13 .00% 10.00% 40.00% 50.00% Sucesso Fracassou Modificado 30.00% 20.

Cenário dos Projetos 14 .

Motivos de Sucesso Envolvimento do usuário: 15.6% Expectativas realistas 8.7% Equipe competente 7.9% Trabalho duro e equipe focada 2.9% Apoio executivo: 13.3% Visão e objetivos claros 2.2% Propriedade 5.2% Milestones pequenos 7.9% Declaração de requisitos clara e limpa: 13% Planejamento apropriado 9.4% 15 .

6% Expectativas realistas 8.7% Equipe competente 7.9% Apoio executivo: 13.9% Declaração de requisitos clara e limpa: 13% Planejamento apropriado 9.9% Trabalho duro e equipe focada 2.2% Propriedade 5.4% 16 .Motivos de Sucesso Envolvimento do usuário: 15.2% Milestones pequenos 7.3% Visão e objetivos claros 2.

Origens dos problemas

17

Conclusão
Um trabalho consistente de análise de requisitos,
ou seja, identificar, quantificar, definir,
priorizar e classificar os principais problemas
que o futuro software deve resolver é a base de
um projeto de software com sucesso

18

Terminologia
• Stakeholder: qualquer pessoa envolvida no projeto;
• Cliente: tipo especial de stakeholder é o responsável
pelo orçamento do projeto;
• Elicitar: significa extrair, obter, produzir os requisitos;
• Cenário: sequência de eventos que podem ocorrer
durante a utilização de um sistema;
• Disciplina: é o conhecimento disponível, relacionado a
um modelo de processo;
• Artefato: é toda informação produzida
19

Requisitos de Software 20 .

• SOMMERVILLE. Também podemos dizer que requisitos expressam as características de um software do ponto de vista da satisfação das necessidades dos usuários. 2005 21 .Conceito • Requisito é a descrição dos serviços e das restrições do sistema.

Conceito • Conjunto de condições ou capacidades necessárias que um software deve possuir para que o usuário possa resolver um problema ou atingir um objetivo ou para atender as necessidades ou restrições da organização ou dos outros componentes do sistema. • Machado (2011) 22 .

Uma condição ou capacidade exigida por um usuário para resolver um problema atingir um objetivo 2. Uma representação documentada dos itens [1] e [2] IEEE Std. especificação ou outro documento oficial 3. Uma condição ou capacidade que precisa ser possuida ou processada por um sistema ou componentes do sistema para satisfazer um contrato.12.Conceito 1. 610.1990 23 . padrão.

Atividades • • • • Elicitação Documentação Validação Gerenciamento 24 .

Nível de Detalhamentos de Requisitos • Requisitos do Usuário (Necessidades) • Requisitos do Sistema (Características) • Especificação do projeto de software (Requisitos de Software) 25 .

Nível de Detalhamentos de Requisito Espaço do problema Necessidade Característica Solução Requisitos de Software 26 .

Requisitos do Usuário (Necessidades) • São descritos em linguagem natural ou através de diagramas e refletem o que o sistema deve fornecer e as restrições sob as quais deve operar • Reflexões de problemas de negócio. Este é considerado o espaço do problema. 27 . pessoais ou operacionais para justificar o desenvolvimento do sistema.

Requisitos do Usuário (Necessidades) Exemplos Id Necessidade Stakeholder N1 Necessita associar uma solicitação de mudança ao engenheiro responsável. Gerente de suporte N2 O cliente necessita manter-se informado sobre o progresso da requisição. Usuário N3 Necessita ser notificado quando uma requisição de suporte for iniciada Gerente de suporte 28 .

Requisitos do Sistema (Característica) • Um serviço que o sistema provê para atender uma ou mais necessidades dos stakeholders. É considerado o espaço da solução 29 .

Característica ID Característica Descrição Necessidade F1 O Sistema deve ser orientado a workflow A requisiçao de suporte irá passar por uma série de estágios e poderá ser executado por um conjunto de profissional N1. N3 mail será utilizado pelo workflow 30 . N3 F2 Notificação via e-mail Um sistema central de notificações de e. N2.N1. N2.

Possui mais especialização e maior volume.Especificação do Projeto (Requisitos de Software) • Detalhamento das características. • Destinado ao projeto de software 31 .

Diferentes níveis de descrição 32 .

33 .Exemplo Necessidade Característica Requisito N001 – Gerenciar cadastro de professores C001-Manter professores RF001-O sistema deve permitir o cadastro de novos professores RF002-Ao finalizar o cadastro do professor o sistema deverá enviar um e-mail para o mesmo informando a senha de acesso temporária RF003-O sistema deverá permitir a pesquisa dos professores pelo nome ….

• Uma propriedade bem genérica do sistema: – Exemplo: O sistema deve garantir que as informações pessoais nunca sejam disponibilizadas sem autorização. • Uma restrição ao desenvolvimento do sistema: – Exemplo: O sistema deve ser desenvolvido em Java. 34 .O que um requisito pode descrever? • Uma facilidade em nível de usuário final: – Exemplo: O processador de texto deve incluir um corretor ortográfico. • Uma regra de negócio: – Exemplo: A nota final do aluno será a média aritmética simples entre as notas parciais. • Uma restrição específica: – Exemplo: O sensor deve fazer 10 varreduras a cada segundo.

Classificação dos requisistos de sistema • Requisitos Funcionais. • Requisitos Não Funcionais ou Requisitos de Qualidade ou Restrições. • Requisitos de Domínio ou Regra de Negócio 35 .

como o sistema deve reagir às entradas específicas e como deve se comportar em determinadas situações. neste caso esse tipo de requisito também pode ser chamado de requisito inverso 36 .Requisitos Funcionais • Descrevem as funções que o sistema deve fornecer. Também pode declarar o que o sistema não deve fazer.

Requisitos Funcionais • Os requisitos funcionais devem determinar o que se espera que o software faça. sem a preocupação de como ele faz 37 .

38 .Como descrever requisitos {[sujeito + ação + objeto] + qualificação} Exemplo: • O sistema deve usar protocolo TCP-IP • O sistema deve registrar as vendas de livros • O sistema deve emitir relatório de livros mais vendidos.

Construção de sentenças 39 .

• A descrição de uma função a ser executada pelo sistema (usualmente entrada.Elementos do Requisitos Funcional • Um identificador. • Quais restrições lógicas (regras de negócio) ou tecnológicas se aplicam na função. • A origem do requisito (quem solicitou) e/ou quem vai executar a função em questão. 40 . saída ou transformação da informação). • Quais informações que são passadas do sistema para o usuário e vice-versa.

41 . Informações de saída: A lista de editoras (nome) O relatório de atualizações efetuadas (lista contendo: nome da editora. o sistema atualiza a base com as novas informações. Fontes: Maria Oliveira (gerente) e manual técnico da interface de catálogo das editoras Usuário: Gerente Informações de entrada: O gerente informa quais são as editoras para as quais pretende fazer a atualização a partir de uma lista fornecida pelo sistema. A seleção feita pelo gerente deve ser através de uma lista de seleção múltipla. titulo e preço de compra) Restrições lógicas: Não se aplica.Exemplo RF001: O sistema deve registrar novos títulos a partir do catálogo das editoras. ISBN. O sistema consulta os ISBN disponibilizados e os compara com os existentes na base. A tecnologia usada pode ser REST ou WebServices. Restrições tecnológicas: A interface de comunicação com as editoras deve seguir o manual de cada uma. Descrição: O gerente seleciona as editoras para as quais pretende fazer a atualização. Havendo novos ISBN. que deve ser ordenada de forma alfabética.

42 .

Requisitos Não Funcionais • Os requisitos não funcionais. de qualidade do produto. não estão ligados diretamente a funções específicas fornecidas pelo sistema. Esse tipo de requisito refere-se às especificações técnicas e de padrões e métodos do processo produtivo. de políticas aplicáveis ao processo e ao produto gerado 43 .

• RN003: O software deve ser operacionalizado no sistema operacional Linux. • RN002: O tempo de desenvolvimento não deve ultrapassar 3 meses. 44 .Exemplos • RN001: O tempo de resposta do sistema não deve ultrapassar 30 segundos.

Tipos de Requisitos Não Funcionais 45 .

• Confiabilidade: • Maturidade. Interoperabilidade. • Recuperabilidade. Apreensibilidade. Operacionalidade.Tipos de Requisitos (ISO/IEC 9126 NBR 13596) • Funcionalidade: • • • • Adequação. Atratividade. • Usabilidade • • • • Inteligibilidade. Segurança de acesso. 46 . Acurácia. • Tolerância a falhas.

Testabilidade.Tipos de Requisitos (ISO/IEC 9126 NBR 13596) • Eficiência • Comportamento em relação ao tempo. Capacidade para ser instalado. Modificabilidade. Estabilidade. • Manutenibilidade • • • • Analisabilidade. 47 . • Portabilidade • • • • Adaptabilidade. Coexistência Capacidade de ser substituído. • Comportamento em relação aos recursos.

Exemplo de definição de RNF 48 .

Requisitos de Domínio (Regras de Negócio) • Os requisitos de domínio. que também são conhecidos como “regras de negócio” por alguns autores. 49 . derivam do conhecimento relacionado ao negócio da aplicação. • Alguns autores classificam esse tipo de requisitos como requisito não funcional.

• Um pedido deve possuir no mínimo um produto • Um cliente é bom se e somente se as faturas não pagas têm menos de 30 dias • O preço líquido de um Produto é calculado utilizando a seguinte formula: – preço do produto * (1+porcentagem de imposto/100). 50 .Exemplo • A nota final do aluno será a média aritmética simples entre as notas parciais.

Exemplo: tabela de decisão 51 .

O que é um bom requisitos? • • • • • Não ambíguo. Determinístico. 52 . Correto. Verificável. Rastreável.

– Assumir conhecimento prévio. – Indeterminação: O sistema deverá fazer as correções no registro quando possível.Não ambíguo • A ambigüidade refere-se a uma incerteza por causa da obscuridade ou indistinção • São fontes principais de ambigüidades: – Uso de pronomes: Exemplo: O sistema deverá permitir somente cinco registros de dependentes válidos e tipos de plano de saúde. – Acrônimos: Exemplo: O sistema deverá montar e transmitir novos registros de mensagens para o STM. 53 . Ele deve incluir o mais velho.

de modo razoável. 54 . • Exemplo de requisito não verificável: “O sistema deverá ser amigável”.Verificável • Um requisito é verificável se ele pode ser testado completamente.

Portável.Lista de palavras para evitar • • • • • Amigável. Rápido. Pequeno. 55 . Flexível.

• Exemplo de requisito não determinístico: “O sistema deve enviar novos registros ao sistema X a cada cinco minutos”.Determinístico • Um requisito é determinístico se especifica todos os possíveis resultados e caminhos do seu fluxo. 56 .

57 .Rastreável • Indica que o requisito é possível identificar desde seu requisitante até sua implementação. Isso é importante quando o requisito é alterado identificar as possíveis modificações.

58 .Correto • Assegurar que o requisito descrito está correto.

São Paulo: Editora Érica.Referências • COCKBURN. Felipe Nery. Requirements Engineering Fundamentals. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro. • MACHADO. O’ Reilly. São Paulo: Addison Wesley. Ian. ed. RUPP Chis. 2a. Engenharia de Software. ed. • SOMMERVILLE. 2007. São Paulo: Addison Wesley. • POHL. Raul Sidnei. 2011. 2011. 2007. Análise e Gestão de Requisitos de Software: onde nascem os sistemas. Sebastopol. Alistair. 2005. Escrevendo Casos de Uso Eficazes. 59 . • LARMAN. • WAZLAWICK. 3a. CA. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. Klaus. Graig. Porto Alegre: Bookman. ed. 8a. 2011.

com 60 .Análise e Gerência de Requisitos Fabiano Oss. 2013 fabiano.oss@gmail.