Requisitos

Eveline Alonso VelosoPUC-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;

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

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.

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.

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.