Esta lição pretende que você compreenda as principais atividades de elicitação e análise de requisitos, a validação dos requisitos e as relações entre essas atividades. Compreenderá, também, por que o gerenciamento de requisitos é necessário e como essa atividade dá suporte às outras atividades da engenharia de requisitos.

Você percebeu tudo o que aprendeu até agora? Em linhas gerais, você compreendeu o que é software, o que são requisitos e quais são as suas categorias, quais são as atividades clássicas de desenvolvimento de software e a importância da construção do projeto de arquitetura. 

Você deve estar se perguntando, por que devo estudar Engenharia de Requisitos? E eu lhe digo que você irá visualizar a complexidade desse processo, pois ele abrange não só as atividades de elicitação e análise de requisitos, como também outras atividades que são importantes para garantir que os requisitos tenham sido bem interpretados pela equipe de desenvolvimento, a partir da narrativa e documentação fornecida pelos stakeholders. 

Você deve estar se perguntando: que atividades são essas?  

Pense comigo, antes de iniciar a elicitação e análise de requisitos, é importante verificar se é viável construir o sistema solicitado. Muitas variáveis devem ser consideradas, tais como: data de entrega solicitada pelo cliente e disponibilidade de tempo da equipe; recursos de hardware e software necessários para a construção do sistema; habilidades e competências da equipe de desenvolvimento, entre muitos outros fatores.

Depois da elicitação e análise de requisitos ser realizada, devemos validar esses requisitos junto ao cliente para ver se a equipe de desenvolvimento compreendeu corretamente o que foi apresentado pelos stakeholders. 

Finalmente, um ponto muito importante é fazer a gestão adequada das alterações que possam vir a surgir sobre os requisitos funcionais e não funcionais e, para isso, existe uma atividade denominada gerenciamento de requisitos.

Curioso? Espero que sim! Vamos, então, compreender essa área de engenharia de requisitos e suas atividades.

Renata conseguiu um estágio em uma empresa de informática para apoiar uma das equipes de desenvolvimento. Nos primeiros dias, ela já conseguiu acompanhar o início do processo de desenvolvimento de software com um cliente novo.  Preocupada em aprender com esta experiência, ela começou a observar com muita atenção as atividades realizadas pelos membros mais sêniores da equipe. Ela combinou de apresentar para eles o que tinha aprendido, por isso foi anotando o que compreendia.

Ela começou a sua apresentação falando que os requisitos de software representam as necessidades que devem ser satisfeitas pelo sistema, não esquecendo que indicam, também, as restrições de funcionamento e procedimentos desse sistema. Ela percebeu que os requisitos funcionais descrevem o comportamento do sistema, e que os requisitos não funcionais podem restringir tanto o sistema quanto o processo de desenvolvimento. 

Além disso, como ela colaborou na construção do documento de requisitos, ela detectou que esse deve ser organizado de forma que os desenvolvedores de software e os clientes do sistema possam utilizá-lo; por isso, o cuidado de definir os requisitos funcionais de usuário com uma escrita textual informal; e os requisitos funcionais de sistema e os requisitos não funcionais, ambos com escrita mais técnica com apoio de modelos e diagramas.

Ela disse para os seus colegas que: o processo de engenharia de requisitos deve iniciar com um estudo da viabilidade para verificar se é possível construir o sistema solicitado. Após, deve ser feita a elicitação e a análise de requisitos para, na sequência, poder especificar os requisitos desse sistema, sem esquecer as atividades de validação e o gerenciamento de requisitos.

Muito orgulhosa, a Renata indicou que a atividade de elicitação e análise de requisitos pode ser vista como uma espiral de atividades que envolve descobrir os requisitos, classificá-los, organizá-los e negociá-los, sem esquecer da importância de documentá-los. Ela salientou que a validação dos requisitos permite verificar se os requisitos são validados, consistentes, completos, realistas e verificáveis. 

Para finalizar, ela disse que compreendeu que podem ocorrer mudanças organizacionais, nos negócios ou técnicas que vão provocar mudanças nos requisitos do sistema de software. Assim, ela reconhece que o gerenciamento de requisitos é importante para controlar essas mudanças.

Conforme Sommerville (2011), a Engenharia de Requisitos (em inglês, Requirements Engineering) é também conhecida por especificação de Software e abrange as atividades clássicas denominadas por elicitação e análise de requisitos. 

A Engenharia de Requisitos engloba a compreensão, a definição dos serviços requisitados para o sistema e a identificação das restrições à operação e o desenvolvimento do produto de software. Além disso, todas essas atividades são particularmente críticas no processo de desenvolvimento do software, pois se houverem erros nessas atividades, inevitavelmente, vão ocorrer problemas no projeto e, por consequência, na implementação do software.

Você percebe que o principal objetivo da Engenharia de Requisitos é produzir um documento de requisitos? Esse documento deve especificar o produto de software, satisfazer os requisitos do cliente e obter a aceitação do(s) stakeholder(s).  

Além disso, os requisitos são, geralmente, apresentados em dois níveis de detalhe, pois (1) os usuários finais e os clientes precisam de uma declaração de requisitos em alto nível, e (2) os desenvolvedores de sistemas precisam de uma especificação mais detalhada do sistema.

Finalmente, os processos que compõem a atividade de Engenharia de Requisitos são o "Estudo de viabilidade", "Elicitação e análise de requisitos", "Especificação de requisitos", "Validação de requisitos" e "Gerenciamento de requisitos". Vamos conhecê-los melhor?

Estudo de viabilidade realiza uma estimativa acerca da possibilidade de se satisfazerem as necessidades do usuário identificado, procurando usar as tecnologias atuais de software e hardware. Este estudo considera se o sistema proposto será rentável, a partir de um ponto de vista de negócio, e se ele pode ser desenvolvido no âmbito das atuais restrições orçamentais. Todo estudo de viabilidade deve ser relativamente barato e rápido e o resultado deve informar a decisão de avançar ou não, com uma análise mais detalhada.

Elicitação e análise de requisitos é o processo que permite a definição dos requisitos do sistema, utilizando técnicas de coleta de dados que permitem, por exemplo, observar os sistemas existentes, discutir com os potenciais usuários e compradores, realizar análise das tarefas executadas pelos usuários finais, entre outras técnicas. Essa parte do processo pode envolver o desenvolvimento de um ou mais modelos de sistemas e protótipos, os quais nos ajudam a entender o sistema a ser especificado.

Especificação de requisitos pretende traduzir as informações, obtidas pelo processo de elicitação e análise de requisitos, para um conjunto de requisitos apresentados em um documento técnico. Saliento que existem dois tipos de requisitos que podem ser incluídos nesse documento: de usuário ou de sistema. Os requisitos de usuário são declarações abstratas dos requisitos do sistema para o cliente e usuário final do sistema; já os requisitos de sistema são uma descrição mais detalhada da funcionalidade a ser provida.

Validação de requisitos verifica os requisitos quanto ao realismo, consistência e completude. Durante esta atividade, os erros no documento de requisitos são descobertos e, portanto, o documento deve ser modificado para correção desses erros.

Para que você possa reconhecer melhor quando a Engenharia de requisitos é realizada, eu sugiro que você revise a Lição 8 para relembrar os modelos de processo de desenvolvimento de software.

A sequência das atividades "Estudo de viabilidade", "Elicitação e análise de requisitos", "Especificação de requisitos", "Validação de requisitos" e "Gerenciamento de requisitos" é organizada em uma Espiral, conforme apresentado na Figura 1, e o documento de requisitos de sistema é o resultado desse processo.

Você notou que, no início do processo, o tempo gasto é maior? Isso acontece porque é preciso compreender os requisitos de negócio, os requisitos não funcionais (uma visão em alto nível) e os requisitos de usuário. Além disso, mais ao final do processo (ou seja, os anéis externos desta espiral) o esforço gasto será para elicitar e compreender os requisitos de sistema de forma detalhada.

Sommerville (2011) salienta que, embora os métodos estruturados tenham um papel a desempenhar no processo de engenharia de requisitos, muito mais é necessário para que a Engenharia de Requisitos ocorra. A elicitação de requisitos, em particular, é uma atividade centrada nas pessoas, e deve-se ter cuidado, pois as pessoas não gostam das restrições impostas por modelos rígidos de sistema. 

Além disso, você já percebeu que, em praticamente todos os sistemas, os requisitos podem mudar? Uma razão é que os sistemas normalmente são construídos para enfrentar "dores dos clientes" que refletem em necessidades que não são completamente definidas e, portanto, os requisitos de software acabam por ser incompletos. 

Contudo, durante o processo de desenvolvimento do software, os stakeholders acabam por amadurecer, regras de negócio e/ou restrições orçamentárias e organizacionais da organização podem ser atualizadas, entre outros motivos. Portanto, é preciso fazer um bom gerenciamento dos requisitos, pois novos requisitos podem surgir, e requisitos existentes devem ser alterados ou, até mesmo, desconsiderados. 

O gerenciamento de requisitos pretende a compreensão e o controle das mudanças nos requisitos do sistema. A equipe de desenvolvimento precisa estar consciente das necessidades individuais dos requisitos como também saber quais são as necessidades que dependem de outras, para que possa avaliar o impacto das mudanças nos requisitos. Portanto, é preciso estabelecer um processo formal para que possa propor mudanças e a ligação dessas às exigências gerais do sistema. Esse processo formal de gerenciamento de requisitos deve ser iniciado tão logo haja uma versão preliminar do documento de requisitos. Você percebeu que deve começar a planejar como gerenciar as mudanças dos requisitos já no processo de elicitação de requisitos?

Além disso, perceba que o gerenciamento de requisitos deve ter o apoio automatizado, e as ferramentas de software devem ser escolhidas já na fase de planejamento. Essas ferramentas de apoio devem permitir:

1. O armazenamento de requisitos em um repositório de dados deve ser gerenciado, seguro e acessível para todos os envolvidos na engenharia de requisitos;

2. O gerenciamento de mudanças de forma simplificada, quando se usa ferramenta de apoio; e

3. O gerenciamento de rastreabilidade necessita de ferramentas de apoio para rastreabilidade para que se possa descobrir os requisitos relacionados.

Mas não pense que é tudo igual! Se for para construir produtos de software de pequeno porte, você pode utilizar recursos disponíveis nos processadores de texto, planilhas e bancos de dados do PC; para produtos de software de grande porte, serão necessárias ferramentas de apoio mais especializadas.

Você percebeu que o gerenciamento de mudanças é essencial? Essa atividade permite decidir se os benefícios da criação de novos requisitos justificam os custos de implementação deste. Portanto, a vantagem de se usar um processo formal de gerenciamento de mudanças é que todas as propostas de mudanças são tratadas de forma consistente, e as alterações nos documentos dos requisitos são feitas de forma controlada.

Esta lição procurou que você compreendesse a importância da Engenharia de Requisitos, salientando as atividades que devem ser realizadas. O último desafio que lhe propomos é fazer a elicitação de requisitos relacionados com automatização de agronegócios familiares, uma realidade bastante forte no Brasil. 

Como você não tem um "cliente pagante", você vai trabalhar como se fosse uma startup, ou seja, vai pensar na construção de um produto de software para só depois vendê-lo. Para tal, procure ler ou assistir notícias sobre tecnologia da informação que tem sido aplicada em pequenos negócios na área da agricultura, pecuária e piscicultura. 

Depois disso, procure detectar um problema que você pode resolver com a construção de um produto de software para, por exemplo, fazer o controle de estoque em uma fazenda, controlar a irrigação de uma plantação ou controlar a temperatura em um aviário. 

Não se esqueça de verificar se sua ideia é viável para um pequeno negócio, ou seja, sua solução não pode ser complexa, pois vai demorar muito tempo, e nem necessitar de muitos recursos tecnológicos, pois isso vai encarecer o seu projeto. Lembre-se que uma startup não tem muitos recursos financeiros no início, só depois que começar a vender o seu produto.

Após, procure ajuda para contatar conhecidos de agricultores ou de uma cooperativa para você poder compreender melhor o que é preciso para resolver o problema que você pensou. Assim, você pode refinar a sua ideia, pois essas pessoas irão lhe ajudar a construir o documento de requisitos. Procure passar pelas etapas propostas na Figura 1, sempre procurando apoio na literatura para realizar as atividades como deve ser. Conto que você goste deste último desafio!