Conforme visto no post anterior, requisitos de software nada mais são do que um conjunto de atividades que o software deve desempenhar, com suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (SOMMERVILLE, 2003).
Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001).
Os requisitos de sistema são normalmente categorizados como funcionais, não funcionais ou requisitos de domínio. A seguir, abordaremos cada uma destas categorias.
Requisitos Funcionais:
Os requisitos funcionais tratam de funções que o sistema deve fornecer, como o sistema deve se comportar a estradas e a determinadas situações (PRESSMAN, 2001).
Em outras palavras, descrevem a funcionalidade ou serviço que se espera que o sistema forneça. Dependendo do tipo de software do requisito a ser descrito é possíveis criar subgrupos de requisitos funcionais, normalmente subdivididos como (SOMERVILLE, 2001):
· Requisitos Funcionais de Usuário: Normalmente descritos de um modo geral;
· Requisitos Funcionais de Sistema: Descrevem a função de sistema detalhadamente, suas entradas, saídas e exceções.
A especificação de requisitos funcionais deve ser completa e consistente. Isto consiste em deixar evidentes e definidas todas as funções requeridas pelo usuário. Além disso, não devem ter definições contraditórias.
Requisitos Não Funcionais:
Os requisitos não funcionais dizem respeito às restrições sobre os serviços ou funções do sistema. Por exemplo, restrição de tempo, restrição do processo de desenvolvimento, padrões, etc. (PRESSMAN, 2001).
Isto é, são aqueles requisitos que não dizem respeito às funções específicas fornecidas pelo sistema. Logo, estão diretamente relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espaço em disco. Podem definir restrições para o sistema, como a capacidade de dispositivos de entrada e saída relacionados e as representações de dados utilizados em um padrão de interface.
Contudo, requisitos não funcionais também dizem respeito ao sistema como um todo e não a características individuais do sistema. Em razão disso, podemos considerá-los mais importantes que requisitos funcionais individuais. Além disso, se houver falhas ao cumprir um requisito não funcional poderá tornar todo o sistema inútil.
Os requisitos funcionais normalmente surgem conforme a necessidade de usuários, de restrições de orçamentos, de políticas organizacionais, pela necessidade de interoperabilidade com outros sistemas ou devido a fatores externos, como regulamentações ou legislação, por exemplo. Assim, podemos classificar os requisitos não funcionais de diversas formas para poder organizá-los (SOMMERVILLE, 2003):
· Requisitos de Produto
o Requisitos de Facilidade de Uso
o Requisitos de Eficiência
- Requisitos de Desempenho
- Requisitos de Espaço
o Requisitos de Confiabilidade
o Requisitos de Portabilidade
· Requisitos Organizacionais
o Requisitos de Entrega
o Requisitos de Implementação
o Requisitos de Padrões
· Requisitos Externos
o Requisitos de Interoperabilidade
o Requisitos Éticos
o Requisitos Legais
- Requisitos de Privacidade
- Requisitos de Segurança
Requisitos Não Funcionais:
Os Requisitos de Domínio originam-se do domínio da aplicação do sistema, refletindo as características deste domínio (SOMMERVILLE, 2003). Podem ser funcionais ou não (PRESSMAN, 2001).
Se estes requisitos não forem atendidos satisfatoriamente, poderá ser impossível fazer a aplicação operar adequadamente.
Referências Bibliográficas
PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Nenhum comentário:
Postar um comentário