Engenharia de Requisitos

Sabemos que os requisitos são descrições dos serviços fornecidos pelo sistema e suas restrições operacionais, ou seja, os requisitos refletem a necessidade dos clientes de um sistema que ajuda a resolver algum, ou alguns, problemas que o mesmo possui.

O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é denominado de Engenharia de Requisitos.

Segundo Davis (1993 apud Sommerville 2008) explica o porque que a indústria de software em alguns casos usa a definição de requisitos como uma declaração abstrata de alto nível e outros o definem como sendo uma definição detalhada de uma função do sistema. Desta forma Davis explica:

Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um grande projeto de software, ela necessita definir suas necessidades de maneira suficientemente abstrata, para que uma solução não seja pré-definida. Os requisitos devem ser redigidos de modo que os diversos fornecedores possam apresentar propostas, oferecendo diferentes maneiras de atender às necessidades organizacionais ao cliente. Assim que aprovado pelo cliente, o fornecedor deve redigir uma definição mais detalhada do sistema para o cliente, de uma forma que o cliente possa entender e validar o que o software fará. Esses documentos podem ser chamados de requisitos do sistema. "Davis (1993 apud Sommerville 2008)"

Basicamente podemos conceituar requisitos de usuário como sendo uma definição de alto nível, onde as declarações são expressas em linguagem natural com uso de diagramas, definindo os serviços e restrições sob as quais vão operar.

Já os requisitos de sistema definem as funções, os serviços e as restrições operacionais do sistema, de forma detalhada. O documento do sistema, também chamada de especificação funcional deve ser preciso, devendo definir claramente o que será implementado, visto que pode ser usado como parte do contrato entre o comprador do sistema e o desenvolvedor do software.

CLASSIFICAÇÃO DOS REQUISITOS

Os requisitos de sistema são classificados em requisitos funcionais, não funcionais e de domínio.

Requisitos Funcionais

Os requisitos funcionais de um sistema descrevem o que o mesmo deve fazer, onde os mesmos dependem do tipo de software que esta sendo desenvolvido, dos usuários a quem o software se destina, neste caso definindo as funções do sistema de forma bem detalhada, indicando suas entradas e saídas, bem como suas exceções.

Requisitos não Funcionais

Como o nome sugere, são aqueles requisitos não diretamente ligados às funções específicas do sistema. Eles podem estar relacionados a algumas propriedades do sistema como confiabilidade, tempo de resposta, espaço em disco, etc.

Os requisitos não funcionais estão associados as características individuais, onde podem especificar ou restringir propriedades emergentes no software, com isto podendo significar quer podem ser mais importantes que os requisitos funcionais, pois se não forem satisfeitos o sistema não ter sucesso.

Requisitos de Domínio

São derivados do domínio de aplicação do sistema, onde geralmente incluem uma terminologia especifica do domínio ou fazem referencia a conceitos do domínio, podendo ser novos requisitos funcionais em si mesmos ou podem restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser realizados.

PROCESSO DE ENGENHARIA DE REQUISITOS

O objetivo do processo de engenharia de requisitos é criar e manter um documento de requisitos do sistema, onde eles estão relacionados a avaliação de se o sistema é útil para a empresa, na obtenção requisitos, na conversão destes requisitos em alguma forma padrão e por fim verificar se os requisitos realmente definem o que o cliente deseja, isto é definindo os processos de estudo de viabilidade, elicitação e análise, especificação e por fim a validação dos requisitos.

Estudo de Viabilidade

Consiste em um conjunto preliminar de requisitos de negócio, um esboço da descrição do sistema e como o mesmo pretende apoiar os processos de negócios, resultando em um relatório que recomenda seguir ou não com o desenvolvimento do sistema.

A realização de um estudo de viabilidade envolve a avaliação de informações necessárias para responder os seguintes questionamentos:

1. O sistema contribui para atingir as metas organizacionais?
2. O sistema pode ser desenvolvido utilizando-se das tecnologias atuais, dentro do prazo e custos definidos?
3. O sistema pode ser integrado aos outros sistemas já implantados?

Após a identificação das informações é necessário falar com as fontes das informações e em seguida elaborar o relatório final do estudo de viabilidade. Normalmente esta tarefa leva de 02(duas) a 03(três) semanas, onde no final deve-se recomendar se o desenvolvimento deve ou não prosseguir. Caso decida-se pelo desenvolvimento o relatório pode propor mudanças de escopo, orçamento e prazo além de sugerir outros requisitos para o sistema.

Elicitação e analise de requisitos

Nesta atividade, os engenheiros de software trabalham com os clientes e usuários finais no intuito de obter informações sobre o domínio da aplicação, os serviços que o sistema deve oferecer, desempenho do sistema, restrições do sistema, etc..

As atividades do processo de elicitação e analise de requisitos são:

• Descoberta de requisitos

É a atividade de interação com os stakeholders para descobrir os requisitos do sistema

• Classificação e organização de requisitos

Essa atividade toma a coleção de requisitos não estruturados, agrupa os requisitos relacionados e os organiza em grupos coerentes.

• Priorização e negociação dos requisitos

Esta atividade esta relacionada com a priorização dos requisitos e em encontrar e resolver conflitos através da negociação de requisitos. Geralmente os stakeholders precisam se encontrar para resolver as diferenças e chegar a um acordo entre os requisitos.

• Especificação dos requisitos

Aqui os requisitos são documentados, utilizando-se de documentos formais e/o informais de requisitos que podem ser produzidos.

Técnicas para Elicitação de Requisitos

Descoberta dos requisitos

Às vezes chamada também de elicitação de requisitos é o processo de reunir informações sobre o sistema e os sistemas existentes e separar dessas informações os requisitos de usuário e de sistema. Você interage com os stakeholders através da observação e de entrevistas, e pode usar de cenários e protótipos para ajudar os stakeholders compreender o que o sistema vai ser.

Entrevistas

Entrevistas formais ou informais é parte da maioria dos processos de engenharia de requisitos. Aqui os stakeholders são questionados pelos engenheiros de software sobre que o sistema usam no momento e sobre o sistema a ser desenvolvido. Os requisitos surgem a partir das respostas destas perguntas. As entrevistas podem ser: fechadas (onde o stakeholder responde a um conjunto predefinido de perguntas) ou abertas (não exige uma agenda predefinida, onde é explorado pelos engenheiros de requisitos uma serie de questões com os stakeholders do sistema)

Cenários

A elicitação baseada em cenários envolve o trabalho com os stakeholders para identificar cenários e capturar detalhes que serão incluídos nesses cenários. Os cenários podem ser escritos como texto, enriquecido com diagramas, telas, documentos do dia a dia, etc.

Esta técnica é usara uma vez que os stakeholders acham mais fácil se relacionar com exemplos da vida real do que com descrições abstratas, pois eles podem compreender, interagir e criticar um cenário. No ambiente de cenário os stakeholders podem adicionar detalhes uteis para uma descrição geral de requisitos.

Casos de Usuários

Os casos de uso é uma técnica baseada em cenários para elicitação de requisitos. Eles se tornaram uma característica fundamental da notação UML para a descrição de modelos de sistemas orientados a objetos.

Casos de uso e cenários são técnicas eficazes para elicitar requisitos dos stakeholders que vão interagir diretamente com o sistema.

Etnografia

É uma técnica de observação que pode ser usada para compreender os processos operacionais e ajudar a extrair os requisitos de apoio para esses processos. Um analista faz uma imersão no ambiente de trabalho o qual o sistema será desenvolvido, e através da observação dos fatores sociais e organizacionais que afetam o trabalho, que muitas vezes não são óbvios para os indivíduos, podem ficar claros apenas quando analisados por um avaliador imparcial.

Geralmente a etnografia é combinada com a técnica de cenários, casos de uso e prototipação.