Olá, estudante, que bom te ver aqui novamente! Na lição anterior, abordamos o conceito de Requisitos funcionais e não funcionais, e agora, vamos retomar e aprofundar a compreensão sobre as duas primeiras atividades clássicas de um processo de desenvolvimento de software, que são: "Elicitação e Análise de Requisitos" e "Projeto". A primeira atividade permite compreender a "dor do cliente" (dificuldade do cliente) e, por consequência, os requisitos necessários para resolvê-la. A segunda atividade, por sua vez, permite que seja definida uma solução técnica para os requisitos detectados.

Nas lições anteriores, nós aprendemos que todo processo da Engenharia de Software é constituído por uma série de ações. Estas permitem que o desenvolvimento de software possa ser realizado por uma equipe de desenvolvimento, garantindo a qualidade do produto entregue. Se as primeiras ações não forem bem realizadas, as ações seguintes podem ficar comprometidas; consecutivamente, todo o processo de desenvolvimento de software, também, ficará comprometido. Você consegue perceber porque isso acontece?

Imagine que uma equipe de desenvolvimento não consegue compreender direito a "dor do cliente", porque, por exemplo, há pouco tempo para se reunir com o cliente ou, mais especificamente, com as pessoas que representam o cliente e têm conhecimento sobre o que é necessário para resolver o problema. Outra situação que pode ocorrer é o cliente não ter certeza do que precisa e passar informações incompletas ou, até mesmo, erradas. Estas são duas situações, mas muitas outras podem ocorrer. 

Independentemente da razão, a equipe acaba por ficar com uma ideia vaga ou, até mesmo, errada sobre o problema e, por consequência, ficará em dúvida sobre a solução que deve ser construída. Portanto, é muito importante saber realizar a "Elicitação e Análise de Requisitos" e, depois, o "Projeto"; por isso, vamos aprender sobre esses temas, nesta lição! 

Frequentemente, envolvo-me em projetos de software para dar apoio à etapa de Elicitação e Análise de Requisitos. Em um desses projetos, eu havia acabado de entrar no departamento e, por isto, ainda, não compreendia a dinâmica entre os meus colegas. 

Foi-me solicitado apoio para desenvolver uma ferramenta que ajudasse na coleta de dados, para posterior diagnóstico sobre os dados analisados. Iniciei o projeto com seis membros, sendo que três eram professores (especialistas no assunto) e três profissionais na área de informática. 

As duas reuniões iniciais foram para compreender a "dor do cliente", eu e meus dois colegas conseguimos perceber que os professores precisavam de uma ferramenta similar ao Google Forms (isto é, um questionário online), mas que tinha algumas particularidades que o Google Forms não possuía, como: o questionário deveria ser enviado para o gestor, que deveria reencaminhar automaticamente para ser respondido por colaboradores do seu setor; as respostas deveriam ter pontuações diferentes, entre outros detalhes. 

Portanto, precisávamos de mais algumas reuniões para perceber melhor como essas particularidades deveriam ocorrer. Passamos, no entanto, a ter dificuldade com a frequência dos professores nas reuniões e, por isso, a compreensão dessas particularidades ficou comprometida. 

A compreensão total das particularidades do projeto ficou comprometida, pois os professores tinham visões diferenciadas sobre as necessidades que a ferramenta deveria ter, por exemplo: um dos professores tinha pouco conhecimento de tecnologia e não conseguia compreender algumas restrições apresentadas; por isso, nem tudo poderia ser executado em smartphone. 

Outra situação foi que alguns professores não conseguiam participar de todas as reuniões e, por isso, não compreendiam a solução apresentada e, algumas vezes, apresentavam situações que contradiziam o que tinha sido definido até aquela data. Situação complicada, mas conseguimos resolver, envolvendo apenas um dos professores, o que compreendia melhor a tecnologia e tinha pleno domínio sobre o problema e suas restrições. Esse professor se comprometeu a comparecer em todas as reuniões e, com base nas contribuições apresentadas por ele, conseguimos extrair os dados necessários para a construção dos documentos de requisitos.

O case te deixou curioso(a)? Assista ao vídeo a seguir para conhecer um pouco mais sobre essa história.

A "Elicitação e Análise de Requisitos" e "Projeto" são as duas primeiras etapas no ciclo clássico do Software, conforme apresentado na Figura 1.

Você notou na Figura 1 que as etapas "Elicitação e Análise de Requisitos" e "Projeto" são realizadas no ambiente de desenvolvimento? Você já se perguntou por que isso ocorre? Porque essas duas atividades devem ser realizadas na empresa que irá desenvolver o produto de software. 

Não podemos usar o ambiente do cliente, enquanto estamos desenvolvendo o produto de software. Você deve estar a pensar "Por que não?". Porque não devemos usar os dados e os recursos tecnológicos do cliente enquanto não tivermos certeza que o software está finalizado e, principalmente, executando corretamente e de acordo com as necessidades do cliente. 

Além disso, você notou que a primeira etapa tem duas atividades? A primeira é "Elicitação (de requisitos)", e a segunda é "Análise de requisitos".

Elicitação de requisitos: a atividade é realizada pela equipe de desenvolvimento junto com stakeholders.

Nesta atividade, a equipe deve compreender a "dor do cliente" (ou seja, o problema). O grande objetivo desta atividade é garantir que os stakeholders e a equipe de desenvolvimento tenham a mesma visão do problema que deve ser resolvido. 

A equipe de desenvolvimento (mais especificamente, os profissionais com perfil de analista) deve entender o domínio do negócio que deve ser automatizado pelo sistema de software. Após, deve fazer um estudo exploratório das necessidades dos usuários e, se existir, analisar também a situação do sistema atual.

Análise de requisitos: na sequência, a atividade de análise de requisitos é realizada pela equipe de desenvolvimento (mais especificamente, pelos profissionais com perfil de analista). Esta equipe deve traduzir as necessidades dos stakeholders para um conjunto de requisitos funcionais e não funcionais e, assim, propor uma solução tecnológica para resolver a "dor do cliente" (SOMMERVILLE, 2011).

Nesta atividade de análise, é importante definir a melhor solução para o problema, sem se preocupar com detalhes tecnológicos, pois isso será feito na etapa a seguir, que falaremos adiante. 

A seguir, um exemplo para você compreender melhor a relação entre essas duas atividades:

Durante a elicitação de requisitos, um cliente diz que existem diferentes perfis de profissionais — diretor, gestor, secretária e atendente —, cada um destes perfis pode realizar um conjunto específico de funcionalidades. Na etapa de análise de requisitos, a equipe de desenvolvimento deve decidir que todo usuário deverá "fazer login" e que cada usuário será associado a um perfil profissional que tem autorização para executar um conjunto de funcionalidades.

Uma outra tarefa realizada, durante a análise, é particionar (dividir) o problema para simplificar a construção da solução. O problema deve ser dividido em pequenos problemas, pois, assim, a equipe pode construir uma pequena solução para cada um destes pequenos problemas. A solução final será, então, a junção dessas pequenas soluções.

Por exemplo, durante a elicitação de requisitos, um cliente indica a importância de fazer a gestão automatizada das informações dos alunos e dos profissionais de um colégio. Este é o "grande problema" que deverá ser dividido em dois problemas menores, que são: (1) gestão das informações dos profissionais e (2) gestão das informações dos alunos. 

Além disso, fazer a gestão de informações significa:

Por exemplo, durante a elicitação de requisitos, um cliente indica a importância de fazer a gestão automatizada das informações dos alunos e dos profissionais de um colégio. Este é o "grande problema" que deverá ser dividido em dois problemas menores, que são: (1) gestão das informações dos profissionais e (2) gestão das informações dos alunos. 

Além disso, fazer a gestão de informações significa:

Mais uma vez, esse problema pode ser dividido em quatro problemas menores. Portanto, esta separação vai permitir que a equipe foque, então, nas seguintes "pequenas soluções" ou, usando um termo mais técnico, nos seguintes requisitos funcionais: 

Outra tarefa importante que a equipe de desenvolvimento deve definir é o modelo para os dados, o qual permitirá posterior definição do banco de dados. Além disso, os requisitos a serem implementados, também, devem ser determinados, isto é, cada um desses requisitos deve satisfazer, pelo menos, uma necessidade explicitada pelo cliente ou detectada pela equipe de desenvolvimento.

Seguindo o exemplo anterior, para realizar a gestão das informações, a equipe deverá especificar quais são os dados que devem ser armazenados para todo profissional e todo aluno do Colégio. Tanto em um caso quanto no outro tem: nome, CPF e endereço completo. O profissional, contudo, tem categoria e carga horária de trabalho; já o aluno tem série e turma. Mais detalhes serão definidos na etapa de projeto. Além disso, a equipe percebe que serão necessários outros requisitos funcionais, que são: (3) cadastrar usuário; (3) fazer login e (4) recuperar senha.

Esta primeira etapa deve entregar um documento, preferencialmente textual, que será refinado pela equipe de desenvolvimento, na próxima etapa.

Projeto: esta etapa vai exigir decisões mais técnicas para a construção do projeto de software. Vamos compreender, primeiramente, o que significa um projeto de software

Muitos são os elementos que compõem um projeto de software, tais como: modelos, estrutura de dados, interface, componentes, entre outros. Estes elementos dependem do tipo de produto de software que está sendo construído, da expertise da equipe de desenvolvimento e, muitas vezes, das necessidades apresentadas pelo cliente.

Nesta lição, não vamos nos aprofundar nesses elementos. Neste momento, você deve compreender que o projeto de software é um documento técnico que será utilizado pela equipe de desenvolvimento (mais especificamente, os profissionais com perfil de programador) para codificar o software. Futuramente, esse documento será utilizado sempre que for necessário alterar o software: é preciso saber o que existe para decidir o que pode/deve ser modificado para satisfazer as novas necessidades.

Você percebeu que a equipe de desenvolvimento (mais especificamente, os profissionais com perfil de projetista) não consegue construir um projeto final de imediato? Este projeto deve ser desenvolvido de forma iterativa e incremental, isto é, aberto a melhorias. Os projetistas adicionam informações técnicas e detalhes ao documento, à medida que realizam revisões frequentes para corrigir e/ou refinar a solução que está sendo construída.

Os projetistas devem ficar atentos ao fato de que a maioria dos softwares interagem com outros sistemas de software, incluindo o sistema operacional, o banco de dados, o middleware e outros aplicativos. Estes softwares formam o que chamamos de "plataforma de software", ou seja, o ambiente no qual o produto de software será executado. Informações sobre esta plataforma são entradas essenciais para a construção do projeto, pois os projetistas devem decidir a melhor forma de integrar essa plataforma ao ambiente do software.

Mais um exemplo: a especificação de requisitos funcionais de um sistema deve conter a descrição da funcionalidade que o sistema deve oferecer; alguns dos requisitos não funcionais importantes para esse sistema são: desempenho e confiança. Se esse sistema for para processamento de dados existentes, a descrição desses dados poderia ser incluída na especificação da plataforma; caso contrário, a descrição dos dados deve ser uma entrada para o processo de projeto para que a organização dos dados do sistema seja definida. 

Finalmente, as atividades no processo de projeto podem variar, dependendo do tipo de sistema a ser desenvolvido. A seguir, as quatro atividades que podem ser parte do processo de projeto de sistemas de informação: 

Agora, para concluir esta lição, vamos imaginar um cenário de exemplo em que um time de desenvolvimento de sistema recebe os seguinte requisitos funcionais:

1. A solução deve ser um aplicativo móvel.

2. Deve ter uma lista denominada "semanal" e outra "mensal".

3. O sistema deve permitir criar, consultar, alterar e remover informações sobre produtos comprados.

4. O sistema deve permitir gerir os produtos da lista.

Essa lista de requisitos é resultado de uma elicitação de requisitos, ou seja, representa as necessidades identificadas e que podem ser formalmente descritas como requisitos funcionais.

Para esse desafio, vamos colocar em prática o que aprendemos nesta lição! Relembre que, no case dessa lição, tratamos da gestão automatizada das informações dos alunos e dos profissionais de um colégio. Agora, vamos identificar os requisitos para um aplicativo de gestão de informações, classificando-os como foi mostrado no exemplo do início dessa sessão.

Além disso, aprofunde sua análise pesquisando sobre os requisitos não funcionais relacionados aos seguintes temas: usabilidade, acessibilidade, segurança da informação e proteção de dados. Esses elementos são importantes e devem ser considerados no desenvolvimento de qualquer sistema atual. 

Bom trabalho!