Esta lição pretende ensinar a importância do requisito (em inglês, requirement) para o processo de desenvolvimento de software. Além disso, você vai compreender que existem muitos tipos de requisitos, cada qual com as suas particularidades. Vamos, então, aprimorar mais um pouco o seu conhecimento? 

Nessa trajetória, em que a cada lição você conhece um pouco mais sobre o processo de criação de um software, você já se perguntou como ocorre a descrição do que deve conter em um software? Será que uma lista de itens é suficiente? Ou é necessário algo mais elaborado de forma que todos os envolvidos, clientes ou desenvolvedores, compreendam?

Nesse processo, ocorre a compreensão da "dor do cliente" e de suas necessidades, que são traduzidas para requisitos funcionais e não funcionais. Se o processo não for feito de forma adequada, haverá problemas no projeto e, por consequência, na implementação do sistema. 

O processo de Engenharia de Requisitos tem o objetivo de produzir um documento de requisitos que são combinados entre o cliente e a equipe de desenvolvimento. Este documento deve especificar um sistema que satisfaça os requisitos dos stakeholders (interessados no projeto).

 Além disso, a especificação desses requisitos tem dois níveis: uma declaração de requisitos em alto nível para usuários finais, atendendo às necessidades dos clientes; e uma especificação mais detalhada do sistema para desenvolvedores do sistema.

Vamos compreender melhor o "coração" deste documento, ou seja, os requisitos?

Já pensou existir um sistema de informação que dê suporte aos pacientes, em seus cuidados com a saúde? Seria muito interessante um sistema médico de informação que mantenha os dados sobre os seus pacientes como também os tratamentos que eles recebem para os seus problemas de saúde. 

A maioria dos pacientes com problemas não requer tratamento hospitalar dedicado, isso quer dizer que, em geral, eles precisam visitar regularmente algumas clínicas especializadas, onde podem encontrar médicos que possuam conhecimento detalhado de seus problemas. 

Para ficar mais fácil atender os pacientes, essas clínicas não existem apenas dentro dos hospitais, podem ser encontradas em centros comunitários de saúde. Você já deve ter visitado um médico especialista, que não fica, necessariamente, em hospital e, sim, em uma clínica, não é mesmo? (SOMMERVILLE, 2011).

Esse sistema poderia utilizar um banco de dados centralizado com as informações dos pacientes. Além disso, teria que ser projetado para funcionar em um PC, de forma que possa ser usado em ambientes que não possuem uma conexão de rede segura. 

Quando o sistema local possui um acesso de rede seguro, a informação sobre os pacientes é usada, a partir do banco de dados, mas essa informação pode ser baixada, e uma cópia local de registros de pacientes pode ser usada, quando não há conexão disponível. O sistema não é um sistema completo de registros médicos e, por isso, não contém informações sobre outras condições médicas. Este sistema deve:

O que você achou dessa ideia? Esta case pretende que você procure conhecer a "dor do cliente"; nesse caso, os pacientes e médicos, bem como as necessidades deste sistema. Mais, ainda, pretendemos que você consiga perceber o que são requisitos funcionais e não funcionais, dentro dessas necessidades.

Requisitos são descrições do que o sistema deve fazer, os serviços que oferecem e as restrições para seu correto funcionamento. Estes requisitos refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar informações. 

Em alguns casos, o requisito é uma declaração abstrata em alto nível de um serviço que o sistema deve oferecer ou uma restrição a um sistema. Em outros casos, requisito é uma definição detalhada e formal de uma função do sistema. Vamos entender melhor essas diferenças?

Se uma empresa pretende fechar um contrato para um projeto de desenvolvimento de software de grande porte, os profissionais devem definir as necessidades de forma abstrata, ou seja, de forma que a solução para estas necessidades não seja predefinida. Lembre-se da arte abstrata, ao observar uma arte abstrata, você consegue definir formas claras? Consegue descrevê-la com precisão? Você observa um todo, mas não sabe ao certo o que é cada elemento, correto?

Dessa mesma forma, pode-se ter uma descrição abstrata para descrever as necessidades do cliente. Por que isto deve acontecer? Porque os requisitos precisam ser escritos de modo que várias empresas de informática possam concorrer pelo contrato e oferecer diferentes maneiras de atender às necessidades do cliente. Ou seja, as empresas conseguem observar o todo, o propósito geral, mas as especificidades, ainda, não estão escritas com clareza. 

Uma vez que o contrato entre cliente e uma empresa de informática tenha sido fechado, esta empresa apresentará uma definição mais detalhada do sistema para o cliente, para que este entenda e possa validar o que o software fará. 

Será criado um documento de requisitos do sistema que deve apresentar, exatamente, o que deverá ser implementado. A versão inicial é mais abstrata e, depois que o contrato é fechado entre cliente e empresa de informática, o documento deverá ser mais detalhado. 

Acredito que você possa estar pensando como os requisitos devem ser escritos, estou certa? Primeiro devemos saber que existem diferentes tipos de requisitos. Sommerville (2012) indica que devemos ter:

Perceba que os requisitos funcionais de usuário são descritos de forma abstrata para serem compreendidos pelos usuários do sistema. Os requisitos funcionais de sistema, porém, são mais específicos, pois devem descrever as funções do sistema, suas entradas e saídas, exceções etc. 

O Quadro 1 apresenta um exemplo de requisitos que segue a narrativa do sistema apresentado na seção “Case”. Observe que o requisito de usuário pode ser expandido em diversos requisitos de sistemas. Além disso, o requisito de usuário é mais geral e os requisitos de sistema fornecem informações mais específicas sobre os serviços e funções do sistema.

Penso que você percebeu que a especificação dos requisitos funcionais de um sistema deve ter cuidado para:

Podemos, então, deduzir que é, praticamente, impossível alcançar a completude e consistência para requisitos de sistemas grandes e complexos, pois é fácil cometer erros, omissões e elaborar especificações para este tipo de sistema. 

Uma outra dificuldade para definir os requisitos em sistemas de grande porte é porque existem muitos stakeholders. Um stakeholder é uma pessoa específica (por exemplo, um especialista que domina as regras e restrições que devem ser respeitadas, entre outros conhecimentos) ou um "papel" que representa um perfil profissional ou cliente que, de alguma maneira, será afetado pelo sistema. Os stakeholders têm necessidades diferentes e, muitas vezes, inconsistentes. Essas inconsistências podem não ser evidentes no primeiro momento e, assim, são incluídas na especificação. Os problemas acabam por surgir após uma análise mais profunda ou, pior, depois do sistema ter sido entregue ao cliente.

Na realidade, a distinção entre diferentes tipos de requisitos não é tão clara como sugerem as definições que apresentamos para você. Isto se adquire com prática, experiência e muita troca de conhecimento com profissionais mais experientes! Para você ter uma ideia, veja as possibilidades para requisitos não funcionais na Figura 1.

São muitos tipos de requisitos, não é verdade? Eles estão organizados em uma árvore hierárquica. Relembrando, uma árvore hierárquica é parecida com um organograma de uma empresa ou uma árvore genealógica de uma família. As linhas da árvore unem dois nodos e indicam o relacionamento lógico entre eles: na vertical, representam nó pai (nível de cima) e nó filho (nível de baixo); na horizontal, estão os nós com o mesmo nível hierárquico. Tradicionalmente, desenha-se a raiz na parte superior e os nodos subordinados na parte inferior; o nível mais inferior é denominado de "folhas".

Vamos conceituar os que estão no topo dessa árvore, pois todos os "requisitos filhos" herdam o que já foi especificado no "requisito pai", isto é, algumas especificidades que cabe a cada requisito.

É possível perceber que os requisitos do sistema devem ser construídos e escritos com diferentes níveis de detalhamento. Isso acontece, pois devem ser usados e/ou avaliados de diversas maneiras e por diferentes leitores. Além do stakeholder, temos ainda: 

Reforço que esta lição é muito importante para qualquer processo de desenvolvimento de software, pois a "dor do cliente" e suas necessidades devem ser traduzidas para requisitos. Se isso for bem-feito, você vai evitar retrabalho durante o restante do processo, ou seja, ter que compreender novamente o que o cliente precisa, entre outras atividades necessárias para desfazer e, depois, refazer o que for necessário.

Vamos, então, aplicar o que você aprendeu nesta lição? Conto que você já esteja mais atento a reconhecer a "dor do cliente" e as necessidades que são apresentadas. Por exemplo, cada vez mais, eu costumo pensar em soluções de como posso automatizar situações do meu dia a dia. 

Lembra que eu falei sobre não ter muita paciência para ir ao supermercado, mais ainda quando eu não faço uma lista com os produtos que preciso comprar para reposição.  Pois, então, estive pensando um pouco mais sobre os requisitos que este sistema deveria ter, veja se você concorda comigo. 

No requisito funcional de usuário, o sistema permite gerenciar lista de compras de produtos. Portanto, o sistema deve permitir gerir mais de uma lista de produtos e criar uma lista permanente de produtos. Os requisitos funcionais de sistema que pensei até, agora, são: