Juliana Jenny Kolb
Home > Engenharia de Software > Sumário > Engenharia de Requisitos
Requisitos Funcionais e Requisitos Não-funcionais
Requisitos funcionais
Os requisitos funcionais descrevem a funcionalidade ou os serviços que se espera que o sistema realize em benefício dos usuários (PAULA FILHO, 2000). Eles variam de acordo com o tipo de software em desenvolvimento, com usuários e com o tipo de sistema que está sendo desenvolvido. Requisitos funcionais podem ser expressos de diversas maneiras e, como já foi dito acima, em diferentes níveis de detalhamento. Os requisitos funcionais de usuários definem recursos específicos que devem ser fornecidos pelo sistema (SOMMERVILLE, 2008).
É natural para um desenvolvedor de sistemas interpretar um requisito ambíguo para simplificar sua implementação. Entretanto isso pode não ser necessariamente o que o cliente necessita. Surgem então novos requisitos e é necessário realizar alterações no sistema, o que afetará diretamente o tempo e o custo do projeto.
Inicialmente a especificação de requisitos funcionais deve ser completa – deve definir todos os requisitos de usuário e refletir as decisões de especificação tomadas – e consistente – os requisitos não devem ter definições contraditórias (PAULA FILHO, 2000). Entretanto, na realidade, em sistemas complexos e grandes, é quase impossível atingir a consistência e a completeza dos requisitos. Isso ocorre, principalmente, em função da complexidade inerente ao sistema e porque as pessoas possuem diferentes pontos de vistas em relação a um problema. Esses problemas somente emergem após uma análise mais aprofundada. À medida que os problemas vão sendo descobertos, deve se ir atualizando o documento de requisitos (SOMMERVILLE, 2008).
Requisitos não funcionais
Os requisitos não funcionais são aqueles que não dizem respeito diretamente às funcionalidades fornecidas pelo sistema. Podem estar relacionados a propriedades de sistemas emergentes, como confiabilidade, tempo de resposta, espaço em disco, desempenho e outros atributos de qualidade do produto (PAULA FILHO, 2000). Às vezes podem dizer respeito ao sistema como um todo. Isso significa que na maioria das vezes eles são mais importantes que os requisitos funcionais individuais. Se uma falha em cumprir um requisito funcional pode comprometer parte do sistema, uma falha em cumprir um requisito não funcional pode tornar todo o sistema inútil (SOMMERVILLE, 2008).
Nem sempre os requisitos não funcionais dizem respeito ao sistema de software a ser desenvolvido. Muitas vezes requisitos não funcionais podem restringir o processo utilizado para desenvolver o sistema. Requisitos de processo podem abranger desde uma especificação de padrões de qualidade a ser utilizada no processo até uma especificação de ferramentas as serem utilizadas.
Os requisitos não funcionais surgem de acordo com as necessidades dos usuários, em razão de restrições orçamentárias, de politicas organizacionais, pela necessidade de interoperabilidade com outros sistemas de software ou hardware e até mesmo em função de fatores externos. Esses últimos podem ser por exemplo de natureza legal ou de segurança.
Sommerville (2008) classifica os requisitos não funcionais em:
- Requisitos de produto que especificam o comportamento do produto. Podem restringir, por exemplo, a liberdade dos projetistas a utilizar uma determinada linguagem.
- Requisitos organizacionais que são procedentes de políticas e procedimentos adotados nas organizações do cliente e do desenvolvedor. Especifica que o sistema deve ser de acordo com um processo-padrão da empresa.
- Requisitos externos que abrange tópicos advindos de fatores externos ao sistema. Dentre eles destacam-se os requisitos de interoperabilidade, os requisitos éticos e os requisitos legais que devem ser observados a fim de garantir que o sistema opera de acordo com a lei.
Um problema dos requisitos não funcionais é que geralmente eles são de difícil verificação e quantificação em uma primeira versão do produto (PAULA FILHO, 2000). Podem ser escritos para refletir os objetivos gerais do cliente como usabilidade, recuperação à falhas ou rapidez de resposta ao usuário. Esses requisitos são problemáticos na medida em que abrem a possibilidade e múltiplas interpretações e claro discussões quando o sistema é entregue (SOMMERVILLE, 2008).
O ideal é que os requisitos não funcionais sejam expressos de forma quantitativa utilizando-se métricas que possam ser testadas. Algumas das principais métricas para testar os requisitos não funcionais são, a velocidade, o tamanho, a usabilidade, a confiabilidade, a robustez e a portabilidade.
Todavia a especificação quantitativa de requisitos também se mostra problemática uma vez que os clientes podem não conseguir traduzir suas metas em requisitos quantitativos. Não há, por exemplo, uma métrica capaz de mensurar a facilidade de manutenção. Por esse motivo, os documentos de requisitos podem incluir declarações de metas junto aos requisitos. Elas são úteis, pois fornecem pistas quanto as prioridades dos clientes. Entretanto essas metas podem ser mal entendidas e não serem objetivamente verificadas.
Requisitos não funcionais podem entrar em conflito e interagir com outros requisitos funcionais do sistema. Muitas vezes pode ser impossível equilibrar diferentes requisitos não funcionais sendo necessário sacrificar um em detrimento de outro de maior importância para a aplicação. É o que Sommerville (2008) chama de encontrar uma “compensação” para minimizar o impacto no sistema como um todo de uma escolha por atender um determinado requisito não funcional em detrimento de outro. De forma similar o PMBOK (2008) afirma que com frequência são necessárias compensações entre os requisitos e os objetivos do projeto. Destaca ainda que essas compensações irão variar de projeto para projeto.
É recomendável que requisitos funcionais e não funcionais sejam diferenciados em um documento de requisitos; embora isso não seja fácil. Se os requisitos não funcionais forem definidos separadamente dos requisitos funcionais será difícil relacioná-los. Por outro lado se forem definidos juntos, será difícil separar considerações funcionais de não funcionais e delinear requisitos que dizem respeito ao sistema como um todo. Sendo assim é preciso encontrar um equilíbrio adequado que irá depender do tipo de sistema. O ideal é que seja criada uma seção separada no documento de requisitos listando aqueles que claramente se relacionam (SOMMERVILLE, 2008).
Requisitos de Domínio
Os requisitos de domínio são derivados do domínio da aplicação do sistema que podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes ou estabelecer como devem ser executados cálculos específicos. Muitas vezes esses requisitos refletem fundamentos do domínio da aplicação (SOMMERVILLE, 2008). Sem uma compreensão satisfatória desses requisitos pode ser impossível fazer o sistema operar de forma satisfatória (PRESSMAN, 2006).
Esses requisitos são expressos com o uso de uma linguagem específica do domínio da aplicação e, geralmente, de difícil compreensão para os engenheiros de software. Os especialistas do domínio podem, por julgarem óbvio, deixarem de fornecer informações importantes e como resultado o requisito pode não ser implementado de forma satisfatória (SOMMERVILLE, 2008).
Requisitos de Usuário
Os requisitos de usuários descrevem os requisitos funcionais e não funcionais de forma compreensível pelos usuários do sistema que não têm conhecimentos técnicos detalhados. Devem especificar somente o comportamento externo do sistema evitando o quanto for possível das características do projeto de sistema. Podem ser escritos em linguagem natural, formulários e diagramas simples e intuitivos. Entretanto de acordo com Sommerville (2008) podem surgir alguns problemas quando os requisitos são escritos em linguagem natural:
- Falta de clareza não é fácil utilizar a linguagem natural de forma precisa e sem ambiguidades sem acarretar em um documento de difícil leitura.
- Confusão de requisitos os requisitos funcionais e não funcionais, os objetivos do sistema e informações do projeto podem estar definidos de forma obscura.
- Fusão de requisitos vários requisitos distintos podem ser unificados em um único requisito.
Uma boa pratica é isolar requisitos de usuário de requisitos de sistema caso contrário os leitores podem ser sobrecarregados por detalhes técnicos que não lhes são relevantes. A fim de minimizar divergências na elaboração requisitos de usuário Sommerville (2008) recomenda que:
- Se crie um formato-padrão e certifique que todas as definições de requisitos estejam de acordo com ele.
- Utilize a linguagem de forma consistente, distinguindo requisitos obrigatórios dos desejáveis.
- Ressalte partes importantes dos requisitos.
- Evite o uso de jargões técnicos.
Requisitos de Sistema
Requisitos de sistema são descrições mais detalhadas dos requisitos de usuário. Podem servir de base para um contrato de implementação e devem especificar completa e consistentemente todo o sistema. São utilizados como ponto de partida para o projeto do sistema. Inicialmente eles deveriam definir o que o sistema deveria fazer e não como ele teria de ser implementado. Entretanto de acordo com Sommerville (2008) isso é quase impossível por diferentes motivos:
- A definição de uma arquitetura inicial do sistema pode ser definida para auxiliar a estruturar a especificação de requisitos.
- Frequentemente os sistemas devem interagir com outros sistemas restringindo o sistema e consequentemente gerando novos requisitos.
- O uso de um projeto específico pode ser um requisito externo de sistema.
A linguagem natural é frequentemente usada para escrever especificações de requisitos de sistema. Todavia, de acordo com Sommerville (2008) quando ela é usada para especificar requisitos de forma detalhada isso pode provocar problemas:
- A linguagem natural está sujeita a ambiguidades
- Uma especificação de requisitos em linguagem natural é muito flexível permitindo dizer a mesma coisa de diferentes formas.
- Não existe nenhum meio fácil de padronizar especificações de requisitos escritos em linguagem natural.
As especificações de requisitos escritas em linguagem natural estão sujeitas a divergências. Frequentemente, elas só são descobertas em fases posteriores do processo de software. As soluções, quase sempre, levam a um aumento no custo e no tempo do projeto.
Enfim, as informações dos documentos de softwares irão variar de acordo com o tipo de software em desenvolvimento e da abordagem adotada para fazê-lo. E nada mais são que esboços (PRESSMAN, 2008) que podem ser usados para descrever as funcionalidades de um sistema. Dependendo da abordagem escolhida o documento de requisitos irá variar no enfoque e no tamanho. O documento poderá ter desde uma simples definição geral do escopo para um dado processo até um documento extremamente detalhado para outro processo. A decisão de qual adotar caberá aos engenheiros de software e sua decisão frente às características do sistema.
Ver: Modelo de Requisitos (+)
Referência Bibliográfica
PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora MCGrawHill: Porto Alegre, 2010.
Site de Referência
http://www.semeru.com.br/blog/category/requisitos-de-dominio/