quinta-feira, 31 de maio de 2012

Engenharia de Requisitos para Concursos Parte 2 - Tipos de Requisitos

Tipos de Requisitos

Funcionais: Definem as funcionalidades do sistema. São as capacidades e serviços providos pelo sistema.

Não Funcionais: São as restrições aplicadas ao sistema ou qualidades específicas que o software deve ter. Exemplos: tempo de resposta máximo, quantidade de armezenamento e outras coisas.

De Domínio (coisa do Sommerville): Vêm do domínio (area de negócio) da aplicação do sistema e refletem características específicas do domínio. Algo mais relacionado ao domínio do que ao sistema. Depois são derivados em requisitos funcionais ou não funcionais.

Outros Tipos de Requisitos - Ponto de vista da evolução e manutenção. Visa saber quais requisitos são mais estáveis e quais são instáveis. Todos são modificáveis, mas alguns são mais propensos a mudanças do que outros

Requisitos Permanentes - Estáveis - (enduring): Estão diretamente ligados a atividade principal da organização. É pouco provável que sejam modificados por causa disso. São derivados do Modelo de Domínio. 

Requisitos Voláteis (volatile): São mais propensos a mudança. Se modificam quando o sistema está em desenvolvimento ou em uso. Requisitos resultantes de políticas governamentais fazem parte desse conjunto.

Os requisitos voláteis são divididos em 4 tipos:

Requisitos Mutáveis: se modificam por causa do ambiente do sistema. Ambiente onde o sistema está inserido. Sistemas que cuidam de impostos estão muito sujeitos a essas modificações.

Requisitos Emergentes: surgem à medida que a compreensão do cliente sobre o sistema se desenvolve. Só aparecerão durante o desenvolvimento.

Requisitos Consequentes: são resultado da introdução do sistema no ambiente do usuário. O usuário percebe a necessidade enquanto utiliza o sistema e esses requisitos são uma consequência do uso.

Requisitos de Compatibilidade: dependem de algum outro elemento. Equipamento, processo, componente, etc. Conforme outros elementos mudam, esses requisitos também mudam.

Requisitos Funcionais
Descrevem as funcionalidades ou serviços do sistema. Dependem da área de interesse relacionada ao software (domínio), dependem dos usuário e do tipo de software. Declaram as funções que o sistema deve fazer, seu comportamento, e ainda, o que o sistema NÃO deve fazer.

Podem ser escritos em alto nível, voltado para o cliente, ou podem ser especificados em detalhes para os desenvoldores.

Exemplos: o sistema deve permitir cadastros, gerar relatórios gerenciais, deve executar tarefas agendadas, etc. Tudo o que não é qualidade, atributo ou restrição do sistema, é considerado requisito funcional.

Requisitos Não Funcionais (RNF)
Definem propriedades, atributos, restrições e qualidades do software. E aí podemos colocar questões como usabilidade, confiabilidade, desempenho, manutenibilidade, escalabilidade, portabilidade. Exemplo: o sistema precisa ser fácil de usar, precisa se manter no ar por um tempo x, precisa ter tempo de resposta máximo e etc.

Segundo o Sommerville, os requisitos não funcionais NÃO se limitam a requisitos do produto, mas do sistema como um todo. Para este autor, o próprio processo, a linguagem de programação escolhida, ferramentas case e etc, também são considerados como RNF

Esses requisitos normalmente são mais críticos e adicionam mais complexidade do que os funcionais. Na grande maioria dos sistemas é assim, não é sempre. Acontece isso porque eles afetam diretamente a sensação de qualidade do usuário ao utilizar o sistema. O sistema é rápido? Está sempre disponível? Consegue suportar milhões de acessos ao mesmo tempo?

Tipos de Requisitos Não Funcionais

Requisitos de Produto: especificam que o software deve se comportar de determinada forma: confiável, robusto, rápido e coisas do tipo.

Requisitos organizacionais: são consequências das politicas, prodecimentos, processos, padrões adotados pela empresa que afetam o seu sistema.

Requisitos Externos: requisitos externos ao sistema, à organização e ao desenvolvimento. Leis e regulamentos do país por exemplo. A interoperabilidade, que é a capacidade de um sistema de se comunicar com outro sistema também é um exemplo.

Os requisitos não funcionais podem ser muito difíceis de especificar de forma precisa. Eles podem ser vagos, ambíguos, ou impossíveis de se verificar. Exemplo: o sistema deve ser fácil de usar.

RNF precisam ser VERIFICÁVEIS e mensuráveis. Deve existir alguma forma de medir objetivamente.

Muitas vezes os RNFs são conflitantes entre sí. Uma escolha de ter mais qualidade em uma determinada coisa pode significar menos de outra coisa. Exemplo: Sistemas em Java possuem portabilidade, por outro lado, costumam ser mais lentos. Interfaces muito elaboradas podem reduzir a manutenibilidade do sistema e por aí vai.

Formas de Medir um RNF

Propriedade Medida
Desempenho Transações por segundo; tempo de resposta para eventos, etc
Armazenamento  Megabytes armazenados.
Usabilidade Tempo de treinamento, número de cliques de mouse para executar uma função
Confiabilidade Tempo médio entre falhas, Taxa de ocorrência de falhas, Disponibilidade
Robustez Tempo para recomeçar depois de uma falha, Probabilidade de corrupção de dados em uma falha
Portabilidade Porcentagem de declarações dependentes de platarforma; Número de platarformas-alvo

Requisitos de Domínio
São derivados do domínio da aplicação. Descrevem características e funcionalidades do sistema que são reflexo do domínio envolvido. No final das contas deriavam para requisitos funcionais ou não funcionais. Na verdade, não serve para nada, mas o Sommerville classifica assim.

É algo extremamente específico daquele domínio. Detalhes técnicos da área que está sendo tratada.

Se não forem satisfeitos, podem inviabilizar o funcionamento do sistema ou sacrificar a qualidade. Bem óbvio, já que são funcionais ou não funcionais.

Eles são expressados na linguagem do domínio da aplicação, o que dificulta muito o entendimento do requisito. Imagine um sistema da bolsa de valores. Não é fácil especificar requisitos de domínios complexos. Muitas informações são táticas e não explíticas. Os especialistas da área acham aquilo tão óbvio que não comentam determinados requisitos.