Quais são as principais etapas do processo de engenharia de requisitos?

Apresentação

Na aula anterior, você ampliou seus conhecimentos sobre a Engenharia de Requisitos de Software, composta por cinco etapas, para garantir que os requisitos de um software sejam obtidos com a maior fidelidade possível em relação às necessidades do cliente. Estudou também a Elicitação de Requisitos e as técnicas disponíveis para entender corretamente os diversos tipos de requisitos existentes.

Dando continuidade às etapas da Engenharia de Requisitos, nesta aula serão apresentados os diversos aspectos que envolvem a Análise dos Requisitos de Software, a partir dos requisitos que foram levantados na etapa anterior, ou seja, na Elicitação de Requisitos.

Ao final desta aula, você será capaz de compreender quais são as etapas que compõem a análise dos requisitos de software e de identificar os artefatos gerados quando a análise dos requisitos de software estiver finalizada.

Conteúdo

Introdução

A análise de requisitos é uma atividade de extrema importância para o sucesso de um software.

Podemos construir sistemas altamente elegantes, com todas as boas práticas de implementação, todos os padrões de projeto, mas, sem a análise de requisitos, não se resolve o problema proposto. Sem ela, corre-se o risco de produzir um sistema que não faz sentido para o cliente/usuário.

A análise é uma atividade ampla, que engloba a especificação, o refinamento e a negociação dos requisitos junto com os stakeholders. Ela permite a criação de modelos de dados e de projeto, nos quais são definidas as restrições do software, como ele funcionará, como será a interface para o usuário, além de permitir também a criação dos testes capazes de avaliar a qualidade do sistema.

Colocando as atividades em um esquema temporal, podemos dizer que a análise de requisitos ocorreria em um momento posterior à fase de levantamento de requisitos. No entanto, na prática, a análise de requisitos é feita quase simultaneamente ao levantamento de requisitos. Isso ocorre porque devemos levar em consideração que o analista de requisitos nunca conseguirá extrair todas as informações na primeira reunião. Por isso, os dois processos acabam acontecendo de maneira conjunta.

Assim, enquanto os requisitos são levantados, o processo de análise aprimora o conhecimento obtido, aumenta o entendimento do negócio, oferece a organização necessária ao projeto e melhora a compreensão das ideias. Geralmente, surgem muitas dúvidas nesse processo, mas elas são úteis, pois acabam permitindo o crescimento da visão sistêmica por parte dos stakeholders. Portanto, perceba que esse é um processo contínuo, em que a clareza vai sendo construída aos poucos.

Análise de Requisitos

Segundo Pressman (2006, p.266), a análise de requisitos de software pode ser dividida em cinco áreas de esforço: Reconhecimento do problema, Avaliação e síntese, Modelagem, Especificação e Revisão. Conheça a seguir cada uma delas.

Reconhecimento do Problema

É muito importante que o analista de requisitos entenda o problema do usuário. Fica praticamente impossível construir o sistema certo sem um completo entendimento do problema. Perceba que o sistema certo não é aquele que é implementado de maneira elegante ou que segue todas as boas práticas de gerência de projetos, mas sim aquele que efetivamente resolve o problema enfrentado pelo usuário.

O analista de requisitos deve ter o cuidado de compreender bem as dificuldades do usuário. Muitas vezes, a ansiedade, a vontade de mostrar resultado, ou até mesmo certa prepotência por parte do analista, podem causar sérios problemas ao projeto. É comum o analista se dar por satisfeito e pensar que entendeu determinado assunto, muitas vezes, ignorando informações essenciais, por achar que aquilo não tem importância ou pensar que determinada situação não merece uma análise mais aprofundada.

Avaliação e Síntese

Nesta fase, o analista deve definir todos os objetos de dados observáveis externamente, avaliar o fluxo e o conteúdo de informação, definir e refinar todas as funções do software, entender o comportamento do software no contexto dos eventos que afetam o sistema, estabelecer as características das interfaces do sistema e descobrir restrições adicionais de projeto. Essas tarefas servem para sintetizar uma solução, adquirindo uma abordagem favorável à descrição do problema.

O processo de avaliação e síntese é contínuo. Deve ter refinamentos sucessivos que melhorem as definições das informações a serem recolhidas, as funções a serem executadas, o comportamento a ser seguido, até que o analista e o cliente/usuário sintam confiança suficiente, a ponto de decidirem que aquela solução é a mais adequada para o tipo de problema analisado.

Modelagem

A modelagem é feita, inicialmente, para atender ao propósito de entendimento do problema.

Inicialmente, pode ser feita uma análise de negócio, para que o problema seja retratado. Assim, com os modelos iniciais, podemos avaliar melhor a realidade do domínio do problema. Depois, novos modelos são feitos para servirem como proposta de solução, para um melhor entendimento, até que os envolvidos consigam retratar, por meio desses modelos, o funcionamento do negócio e como ele ficará após a construção do sistema.

Assim, são definidos novos procedimentos e processos de trabalho capazes de apoiar o negócio de maneira eficiente. Dessa forma, tenta-se resolver o problema inicialmente proposto com um sistema que efetivamente trará resultados concretos para o negócio, alinhando os objetivos do sistema com os objetivos de negócio.

Especificação

A especificação é a explicação do modelo, dos seus itens, dos relacionamentos e de todos os demais elementos que fazem parte daquele artefato.

As explicações – especificações – além de outras informações adicionais, podem estar localizadas em outros artefatos. Por exemplo, vamos supor que tenhamos feito um diagrama de caso de uso completo com todos os elementos – atores, casos de uso, relacionamentos –, a especificação seria uma breve explicação sobre cada um dos elementos contidos naquele diagrama. As ferramentas CASE permitem a inclusão de informações sobre os elementos; assim, você tem um artefato capaz de passar a informação em formato gráfico e, também, conteria texto para uma melhor compreensão.

Não devemos, porém, limitar nosso entendimento sobre especificações. Um caso de uso específico, contido no diagrama, pode e deve ter um documento de caso de uso. Esse documento deve ser uma especificação completa, com todos os detalhes daquele caso de uso, com os atores, cenários, pré-condições e pós-condições, fluxos básicos e alternativos, além das regras de negócio que podem estar especificadas em outro documento exclusivo para esse fim.

Portanto, especificação, em sentido amplo, é toda aquela explicação, breve ou completa, sobre um elemento, funcionalidade ou até mesmo um artefato ou, ainda, informações de qualquer tipo relacionadas ao ambiente que cerca o sistema.

Devemos ficar atentos para o fato de que, em um momento inicial, é difícil termos capacidade de especificar alguma coisa de forma completa. No momento em que estamos analisando os requisitos, o cliente/usuário pode não estar completamente certo daquele requisito, ou sobre seu funcionamento.

Muitas vezes, é complicado para o analista de requisitos ter a certeza de que aquele entendimento é o correto, ou que aquela solução pode ser aplicada a determinado problema. Em momentos iniciais de análise de requisitos, são necessárias muitas sessões de levantamento e entendimento de requisitos, para que as partes cheguem a um consenso e, com isso, possam avançar rumo a outras definições que se fazem necessárias para a continuidade do projeto.

Revisão

A última, mas não menos importante área de esforço, preconizada por Roger Pressman para a análise de requisitos, é a revisão. Essa é a área na qual devemos nos concentrar em olhar para aqueles modelos e definições feitos pela equipe de análise de requisitos em conjunto com os usuários e nos perguntar: “Será que é isso mesmo? Contemplamos tudo aquilo que era necessário para essa especificação? Será que não deixamos nada de fora? Todos esses levantamentos são importantes mesmo ou colocamos algo que só irá nos tomar tempo e dinheiro?”.

Toda essa reflexão é importante para que, no fim desta fase, tenhamos certeza de que podemos avançar sem medo. Devemos olhar com outra perspectiva, pedir para uma pessoa diferente dar a sua opinião sobre determinada solução. Assim, teremos mais segurança de se ter minimizado os erros de entendimento e evitado ambiguidades. Afinal, a detecção de um erro agora é muito mais barata, em comparação com o que seria necessário gastar se os problemas fossem identificados somente após a solução ter sido implementada.

Analise a situação ilustrada na figura 1:

Figura 1 – Requerimentos de Software.

Na figura, você pode observar que existem diferentes pontos de vista entre o Analista de Requisitos e o Cliente. Na análise, é possível você procurar entender a visão do cliente, sua capacidade tecnológica, suas limitações e necessidades.

Tipos de Requisitos

Uma vez que os requisitos estão finalizados no Levantamento dos Requisitos, é muito importante separá-los, conforme seu tipo. Na tabela 1, são apresentados os tipos de requisitos que podem existir em um sistema.

Tabela 1 – Tipos de Requisitos.

Análise de Requisitos Orientada a Objetos (OO)

A Análise de Requisitos Orientada a Objetos é uma abordagem atual e bastante presente no mercado de desenvolvimento de sistemas. Não é raro encontrarmos sistemas que não são orientados a objetos nas organizações. Mas é bem mais comum nos deparamos com sistemas OO, em que suas especificações são organizadas na base de requisitos, com casos de uso e demais modelos recomendados pela UML.

Quando utilizamos o paradigma orientado a objetos para o projeto de um sistema, podemos utilizar o Processo Unificado como metodologia e ciclo de vida de desenvolvimento. Entretanto, será necessário customizar o UP – Unified Process, retirar coisas que não são necessárias, adaptando-o à nossa realidade.

Feita a adaptação, agora sim, podemos começar!

Em um sistema mais complexo, começamos com a disciplina de Modelagem de Negócio. Por meio dessa disciplina, somos capazes de realizar um diagnóstico da organização, observar seus processos e fluxos de trabalho, investigar os problemas, os gargalos e as informações necessárias para o correto funcionamento do ambiente organizacional.

Segundo o UP, os objetivos da disciplina Modelagem de Negócios são os descritos a seguir:

• Entender os problemas atuais na organização de destino e identificar os potenciais de aprimoramento.
• Avaliar o impacto da alteração organizacional.
• Assegurar que clientes, usuários, desenvolvedores e outros parceiros tenham uma compreensão comum da organização.
• Derivar os requisitos do sistema de software necessários para suportar a organização de destino.
• Entender como um sistema de software a ser implementado se ajusta à organização.

No nosso caso, não utilizaremos a disciplina de Modelagem de Negócio, partiremos direto para a Análise de Requisitos. Nessa disciplina, a primeira coisa a fazer é criar o documento de visão, que será abordado no próximo tópico.

Documento de Visão

Documento de Visão consiste em uma especificação geral do sistema, uma definição em sentido macro para sabermos o propósito do sistema, em linhas gerais: o que ele faz, quais são os envolvidos, as condições e restrições-chave.

Segundo definição do UP (Unified Process), o documento de visão define a visualização de envolvidos do produto a ser desenvolvido, especificado em termos de suas necessidades e recursos mais importantes. Ele contém uma descrição dos requisitos centrais pretendidos e, portanto, proporciona a base contratual para requisitos técnicos mais detalhados.

Ainda de acordo com o UP, o documento de visão tem como objetivo fornecer uma base de alto nível, algumas vezes contratual, para os requisitos técnicos mais detalhados que devem ser visíveis para os envolvidos. Ele captura a essência da solução imaginada, na forma de requisitos de alto nível e de restrições de design, que fornecem ao leitor uma visão geral do sistema a ser desenvolvido a partir de uma perspectiva de requisitos comportamentais.

O documento de visão fornece entrada para o processo de aprovação do projeto e, portanto, está intrinsecamente relacionado ao Produto de Trabalho: Caso de Negócios. Ele comunica os principais questionamentos “por que” e “o que” do projeto, além de funcionar como base sobre a qual as decisões futuras deverão ser tomadas. Outro nome utilizado para esse artefato é o Documento de Requisitos do Produto.

Todo projeto precisa de uma origem para capturar as expectativas entre os envolvidos. Por isso, a descrição que o UP dá para o documento de visão é que ele deve fornecer uma visão completa do sistema de software em desenvolvimento, servindo de suporte para o contrato entre a autoridade financeira e a organização de desenvolvimento.

Assim, o ponto de partida é o documento de visão. Observe a figura 2:

Figura 2 – Documento de Visão.class="img-fluid">

Um breve resumo do documento de Visão é colocado pelo UP, de forma que ele seja construído a partir da perspectiva do cliente, focalizando os recursos essenciais do sistema e os níveis de qualidade minimamente aceitáveis. O documento de visão deve incluir uma descrição dos recursos que serão incluídos e considerados. Ele deve especificar capacidades operacionais, como: tempos de resposta, perfis de usuários, informações sobre quem utilizará o sistema, interfaces operacionais com entidades externas e limites do sistema.

Você fará agora um exercício de reflexão a respeito do conteúdo do Documento de Visão. A seguir, são listadas algumas questões sobre o conteúdo e a finalidade desse documento.

1. Por que o Processo Unificado sugere a elaboração desse documento?
2. O que está contido dentro de um Documento de Visão?
3. Qual é a sua importância no contexto do entendimento dos Requisitos e o que ele representa em termos de continuidade do processo de desenvolvimento de sistemas?

Para te ajudar na reflexão, incluímos um template do Documento de Visão, segundo a visão do Processo Unificado. Acesse o documento e analise sua estrutura e seu conteúdo.

Nesta aula, você compreendeu como analisar os requisitos coletados, classificando os diversos tipos de requisitos, priorizando-os e iniciando a definição de uma arquitetura, que pode ser utilizada para que o mesmo atenda às necessidades de negócio do cliente. Na próxima aula, será abordada a Modelagem dos Requisitos de Software, dando continuidade ao tratamento dos requisitos detalhados na Análise dos Requisitos de Software.

Bom estudo!

Na Prática

"Prezado(a) estudante,

Esta seção é composta por atividades que objetivam consolidar a sua aprendizagem quanto aos conteúdos estudados e discutidos. Caso alguma dessas atividades seja avaliativa, seu (sua) professor (a) indicará no Plano de Ensino e lhe orientará quanto aos critérios e formas de apresentação e de envio."

Bom Trabalho!

Algumas das atividades propostas nesta aula são interdependentes e complementares, com o intuito de possibilitar uma visão geral das diversas etapas que compõem a Engenharia de Requisitos, indo desde as informações iniciais coletadas junto ao cliente, até o momento em que a documentação necessária ao desenvolvimento do sistema esteja pronta para a próxima etapa do Processo de Desenvolvimento do ciclo de vida de desenvolvimento de software, a Análise e Projeto de Software.

Segue a relação das atividades que são interdependentes e complementares:

• Unidade I

• Aula 1 – Atividade 3
• Aula 3 – Atividade 2
• Aula 3 – Atividade 3
• Aula 3 – Atividade 4
• Aula 4 – Atividade 3
• Aula 4 – Atividade 4

Segundo Pressman (2006, p.266), a análise de requisitos de software pode ser dividida em cinco áreas de esforço: Reconhecimento do problema, Avaliação e síntese, Modelagem, Especificação e Revisão.

Preencha a tabela a seguir, na qual deve apresentar na primeira coluna o nome da área de esforço e na segunda coluna a descrição do que cada área de esforço representa na Análise de Requisitos de Software. Expresse suas ideias e compreensões com suas palavras, valorizando sua autoria.

A partir dos requisitos funcionais identificados na atividade 3, da aula Introdução a Requisitos de Software, monte os seguintes quadros:

Importante: Todo requisito funcional dará origem a um caso de uso. Já um caso de uso pode englobar um ou mais requisitos funcionais. Para nomear um caso de uso, inicia-se sempre com um verbo no infinitivo + um complemento.

Exemplo: Requisito funcional – Necessidade de cadastramento de cliente. O nome do caso de uso pode ser CADASTRAR (verbo no infinitivo) + CLIENTE (complemento).

Nesta aula, foram apresentados tipos de requisitos. Com base no sistema apresentado na atividade 3, da aula Introdução a Requisitos de Software, identifique, pelo menos, um requisito de cada um dos tipos existentes.

Na atividade 3, da aula Introdução a Requisitos de Software foi apresentado o SISCINEMA. Lá é possível você identificar as principais características do sistema. A partir dessa especificação, elabore o Documento de Visão.

Saiba Mais

Referências

• DAVIS, A. M. Software Requirements: objects, functions and states. Englewood Cliffs, New Jersey: Prentice Hall. 1993.
• KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering:processes and techniques (worldwide series in computer science). Wiley, 1998.
• PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo: Pearson Education do Brasil, 2007.
• PRESSMAN, Roger S. PENTEADO, Rosângela Delloso (Trad.). Engenharia de software. 6. ed. Rio de Janeiro: McGrawHill, 2006.
• PRESSMAN, Roger S. Engenharia de software: Uma abordagem Profissional. 7. ed. São Paulo: McGraw-Hill, 2011.
• SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Addison Wesley, 2011.