Eveline Alonso Veloso PUC-Minas Requisitos Eveline Alonso Veloso PUC-Minas

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 1987. JACKSON, Michael. Software Requirements and Specifications: A Lexicon of Practice, Principles, and Prejudices. ACM Press, 1995. Transparências da professora Maria Augusta Vieira Nelson da PUC-Minas.

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

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.

Requisitos Não falam sobre o sistema; Envolvem aspectos do domínio; 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.

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

Por quê Requisitos são Importantes? Fator de Insucesso de Projetos de Desenvolvimento de Software % dos Projetos Requisitos incompletos 13,1 Falta de envolvimento dos usuários 12,4 Falta de recursos 10,6 Expectativas não-realistas 9,9 Falta de suporte executivo 9,3 Alterações nos requisitos e especificações 8,7 Falta de planejamento 8,1 O software não é mais necessário 7,5 Falta de gerenciamento de TI 6,2 Outros 14,2

Por quê Requisitos são Importantes? Custo associado à reparação de defeitos Existem vários dados que mostram a importância de requisitos bem definidos. Em 1981 Barry Boehm fez experimentos para medir os custos associados à reparação de defeitos. O custo de se descobrir e reparar um erro, depois da entrega do sistema, é frequentemente 100 vezes maior do que o custo de encontrá-lo e consertá-lo na fase de definição dos requisitos. Em 2001 novas medições foram repetidas por Boehm e Basili e a afirmação continua válida. Se os requisitos tiverem maior qualidade, menos defeitos serão encontrados posteriormente à entrega do software e portanto o custo de reparo de defeitos será reduzido. Barry Boehm e Victor Basili “Software Defect Reduction Top 10 List”

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.

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. A qualidade dos requisitos é especialmente importante quando se trata de sistemas que lidam com vidas humanas. Therac-25: uma máquina controlada por um computador que emitia radiações para tratamento de câncer. Reutilização de código utilizado para controlar máquinas de modelos anteriores. Não havia na especificação do Therac-25 a indicação de que sua máquina possuía características diferentes dos modelos anteriores, como por exemplo, não apresentava controles de segurança. London ambulance system: sistema para enviar ambulâncias para os locais das chamadas de emergência. No dia em que ele entrou em operação estima-se que 11 pessoas morreram, pois as ambulâncias levaram horas para chegar aos locais das chamadas. Análises posteriores revelaram inúmeros problemas, inclusive na especificação dos requisitos: “inappropriate and unjustified assumptions were made during the specification process; there was a lack of consultation with users and clients in the development process with knock-on consequences for their “ownership” of the resulting system; the poor fit of the system with the organisational structure of the ambulance service.”

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. Mesmo quando não há vidas em jogo, os prejuízos financeiros associados a requisitos de baixa qualidade podem ser grandes. On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off from Kourou, French Guiana. The destroyed rocket and its cargo were valued at $500 million. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32.767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed. O componente onde o erro se manisfestou foi reusado da Ariane 4. Na Ariane 4 a velocidade horizontal do foguete não passaria de 32.767. Porém a especificação do componente não deixava claro esta premissa. September 23, 1999 the orbiter fired its main engine to go into orbit around the planet. "We had planned to approach the planet at an altitude of about 150 kilometers (93 miles). We thought we were doing that, but upon review of the last six to eight hours of data leading up to arrival, we saw indications that the actual approach altitude had been much lower. It appears that the actual altitude was about 60 kilometers (37 miles). We believe that the minimum survivable altitude for the spacecraft would have been 85 kilometers (53 miles)." The peer review preliminary findings indicate that one team used English units (e.g., inches, feet and pounds) while the other used metric units for a key spacecraft operation. This information was critical to the maneuvers required to place the spacecraft in the proper Mars orbit.

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.

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.

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.

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.

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.

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.

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.

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%.

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

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.

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?

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.

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?

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?

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?

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.)?

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.

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.

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.

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?

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?

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?

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?

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.

Mais Outra Classificação para os Requisitos IEEE 1998. 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.