A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Requisitos Eveline Alonso Veloso PUC-Minas. Bibliografia PAULA-FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed.,

Apresentações semelhantes


Apresentação em tema: "Requisitos Eveline Alonso Veloso PUC-Minas. Bibliografia PAULA-FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed.,"— Transcrição da apresentação:

1 Requisitos Eveline Alonso Veloso PUC-Minas

2 Bibliografia PAULA-FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed., Rio de Janeiro: LTC - Livros Técnicos e Científicos, c2003, capítulos 1 e 5. SOMMERVILLE, Ian. Engenharia de Software. 6ª ed., São Paulo: Pearson, 2003, capítulo 6. BROOKS, Fred. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 20(4):10-19, April JACKSON, Michael. Software Requirements and Specifications: A Lexicon of Practice, Principles, and Prejudices. ACM Press, Transparências da professora Maria Augusta Vieira Nelson da PUC-Minas.

3 O que é um Requisito? Uma condição ou capacidade necessitada por um usuário; para resolver um problema ou atingir um objetivo. Uma condição ou capacidade que deve ser cumprida ou possuída por um sistema ou componente do sistema; para satisfazer um contrato, padrão, especificação ou outro documento formal imposto. IEEE Standard Glossary of Software Engineering Terminology

4 O que é um Requisito? Característica que define um dos critérios de aceitação de um produto. Qualquer característica externa do sistema; observada por um usuário, comprador ou cliente que participe do desenvolvimento desse sistema. Descrição de uma das funções ou restrições do sistema; gerada durante o processo de engenharia de requisitos.

5 Requisitos Não falam sobre o sistema; mas sobre os efeitos do sistema. O requisito se refere a um problema que existe no mundo real; não na máquina. O software é uma solução para algum problema: se você não sabe o quê fazer; não adianta definir como fazer; ainda será muito prematuro para tomar decisões. Envolvem aspectos do domínio; na fronteira do software.

6 Por quê Requisitos são Importantes? A parte individual mais difícil de se fazer no desenvolvimento de um sistema de software; é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil; quanto estabelecer detalhadamente os requisitos técnicos. Nenhuma outra parte do trabalho prejudica tanto o sistema final; se feita incorretamente. Nenhuma outra parte do trabalho é mais difícil de se reparar; a posteriori. Fred Brooks

7 Por quê Requisitos são Importantes? Fator de Insucesso de Projetos de Desenvolvimento de Software % dos Projetos Requisitos incompletos13,1 Falta de envolvimento dos usuários12,4 Falta de recursos10,6 Expectativas não-realistas9,9 Falta de suporte executivo9,3 Alterações nos requisitos e especificações8,7 Falta de planejamento8,1 O software não é mais necessário7,5 Falta de gerenciamento de TI6,2 Outros14,2

8 Por quê Requisitos são Importantes? Custo associado à reparação de defeitos Barry Boehm e Victor Basili Software Defect Reduction Top 10 List

9 Por quê Requisitos são Importantes? Erros introduzidos durante a etapa de requisitos podem causar: perda de vidas; prejuízos financeiros; atrasos nas entregas; aumento de riscos; baixa qualidade.

10 Perdas de Vidas Atribuídas a Softwares Therac-25: (1985 a 1987) acidentes envolvendo doses altíssimas de radiação; pelo menos 3 mortes e 8 pessoas gravemente contaminadas; diversos problemas; inclusive especificação incompleta. Sistema de Ambulâncias de Londres: (1992) 11 mortes; inúmeros problemas; inclusive na especificação de requisitos.

11 Prejuízos Financeiros Atribuídos a Softwares Ariane 5: (1996) $500 milhões de dólares; overflow durante conversão de ponto flutuante para inteiro. Sonda Orbital de Marte: (1999) $125 milhões de dólares; um componente usou escala métrica; e o outro escala imperial. Erro do software ocorreu; em decorrência de sua especificação incorreta.

12 Para que Servem os Requisitos? Podem ser utilizados como base: para que potenciais fornecedores apresentem suas propostas; descrição em alto nível. de um contrato; descrição em maior nível de detalhamento.

13 De onde Surgem os Requisitos? Os requisitos surgem dos usuários; e do domínio da aplicação. Dificuldades: clientes e usuários nem sempre compreendem os processos de desenvolvimento de software em grau suficiente; para produzir uma especificação de requisitos de implementação viável. especialistas no domínio podem entender tão bem a área; que não tornam todos os requisitos explícitos.

14 De onde Surgem os Requisitos? Dificuldades: analistas de requisitos nem sempre entendem o domínio da aplicação de forma suficiente; para produzir uma especificação de requisitos satisfatória. por não ser a especialidade dos engenheiros de software; as características do domínio da aplicação podem não ser entendidas pelos profissionais que irão desenvolver a aplicação.

15 Regras de Negócio Regras de negócio ou propriedades do domínio: não são requisitos; são fatos sobre o meio em que o sistema será inserido; são verdadeiras; mesmo se não houver um sistema; são relevantes para o desenvolvimento do sistema correto: se regras de negócio não forem satisfeitas; o sistema pode tornar-se inútil.

16 Regras de Negócio Exemplos: um aluno não pode se matricular em mais de 28 créditos por semestre; cheques vencem 30 dias após sua emissão; a temperatura do paciente tem de ser medida a cada 2 horas.

17 Tipos de Regras de Negócio Fatos: afirmativas que são sempre verdadeiras no contexto do negócio. Exemplo: notas fiscais são emitidas em quatro vias. Restrições: reduzem as alternativas disponíveis para o sistema; devido a motivos reais. Exemplo: o correio não aceita pacotes de mais de 50 quilos.

18 Tipos de Regras de Negócio Gatilhos: uma regra que causa uma atividade; em dadas condições. Exemplo: se a data de validade do produto expirar; deve-se removê-lo do estoque.

19 Tipos de Regras de Negócio Inferências: uma regra que estabelece um novo fato; quando alguma condição é verdadeira. Exemplo: produtos devolvidos pelo cliente; são sempre considerados usados. Cálculos: especificam fórmulas ou algoritmos. Exemplo: toda compra acima de mil reais recebe um desconto de 10%.

20 Tipos de Requisitos Funcionais; Restrições de projeto; Restrições de processo; Não-funcionais.

21 Requisitos Funcionais São os mais comuns. Definem detalhadamente: as funcionalidades ou os serviços esperados do sistema; como o sistema deve reagir a entradas específicas; como o sistema deve se comportar em determinadas situações.

22 Requisitos Funcionais O que o sistema deve fazer? Quando ele deve atuar? Quais cálculos devem ser realizados? Como o sistema deve reagir a eventos externos? Também definem informações sobre os dados: Qual deve ser o formato dos dados de entrada e saída? Quais dados devem ser armazenados?

23 Exemplos de Requisitos Funcionais O professor deve cadastrar as avaliações da disciplina. O usuário deve ser capaz de pesquisar todo o acervo da biblioteca. Cada pedido de compra deverá ser analisado pelo gestor de compras, que poderá decidir por aprová-lo ou retorná- lo ao solicitante.

24 Restrições de Projeto São restrições relativas a fatores externos ao sistema, como: ambiente de desenvolvimento ou de operação: onde ficará o equipamento? há restrições de temperatura, umidade ou outras? há restrições no tamanho do sistema? há restrições na linguagem de programação usada, devido a outros sistemas já existentes?

25 Restrições de Projeto interfaces com outros sistemas: o sistema receberá dados de outros sistemas? o sistema enviará dados para algum outro sistema? usuários do sistema: quem usará o sistema? haverá diversos tipos de usuário? qual é o nível esperado de habilidade dos usuários?

26 Restrições de Processo São restrições relativas à forma como o desenvolvimento do sistema será conduzido, como: recursos disponíveis: há restrições de materiais ou pessoas disponíveis para o projeto? qual é o nível esperado de capacidade dos desenvolvedores?

27 Restrições de Processo documentação exigida: quanta documentação é necessária? em que formato (on-line, impresso)? normas a serem seguidas: existem normas (IEEE, etc.) que devem ser seguidas? processo de desenvolvimento de software a ser seguido: o sistema precisa ser desenvolvido seguindo algum processo (RUP, etc.)?

28 Requisitos Não-Funcionais Quantificam determinados aspectos do comportamento do sistema. Exemplos: toda consulta ao acervo da biblioteca deve ser respondida em até 30 segundos. o sistema deve ser dimensionado para suportar até 100 usuários simultâneos.

29 Requisitos Não-Funcionais Podem ser mais críticos do que requisitos funcionais. Se eles não forem atendidos; o sistema pode se tornar inútil. Podem influenciar um ou mais requisitos funcionais; ou mesmo todos. Devido à sua própria definição, requisitos não-funcionais devem ser mensuráveis; deve-se associar uma métrica a cada requisito não-funcional elicitado.

30 Metas e Requisitos Pode ser muito difícil especificar e verificar precisamente requisitos não-funcionais. Meta: uma intenção geral do usuário; tal como a facilidade de uso. Requisito não-funcional verificável: uma especificação utilizando alguma métrica; que pode ser objetivamente medida. Métricas são úteis para os desenvolvedores testarem; se o sistema cumpre as metas dos usuários.

31 Atributos de Qualidade ISO-9126 Eficiência: há restrições no tempo de execução ou de resposta do sistema? qual é o volume de dados que o sistema deve ser capaz de processar? qual é a quantidade de acessos que o sistema deverá ser capaz de atender simultaneamente? qual é a taxa de processamento esperada para este sistema?

32 Atributos de Qualidade ISO-9126 Usabilidade: quão fácil deve ser para um usuário compreender e usar o sistema? quão difícil deve ser para um usuário usar incorretamente o sistema? Confiabilidade: o sistema deve detectar e/ou recuperar-se de falhas? qual é a tolerância para o tempo médio entre falhas? existe um nível de tolerância a falhas e interrupções?

33 Atributos de Qualidade ISO-9126 Segurança: o acesso ao sistema ou à informação deve ser controlado? que precauções devem ser tomadas contra o uso indevido do sistema? devem existir restrições de acesso para determinados grupos de usuários?

34 Atributos de Qualidade ISO-9126 Manutenibilidade: quão simples deve ser a adição de novas funcionalidades ao sistema? qual é o tempo aceitável para diagnóstico de problemas? qual é o tempo aceitável para resolução de problemas? Portabilidade: o sistema deve ser portável a outras plataformas?

35 Outra Classificação para os Requisitos Tipos de requisitos: implícitos: expectativas dos clientes e usuários; normativos: leis, padrões, etc.; explícitos: descritos em um documento que apresenta os requisitos de um produto.

36 Mais Outra Classificação para os Requisitos IEEE Classificação dos requisitos quanto à importância: essencial: sem seu atendimento; o produto torna-se inaceitável. condicional: seu atendimento aumenta o valor do produto; mas sua ausência pode ser considerada em caso de necessidade. opcional: pode ou não ser implementado; dependendo dos prazos e recursos disponíveis.


Carregar ppt "Requisitos Eveline Alonso Veloso PUC-Minas. Bibliografia PAULA-FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed.,"

Apresentações semelhantes


Anúncios Google