O entendimento dos requisitos de um problema está entre as tarefas mais difíceis enfrentadas pelos profissionais de desenvolvimento de sistemas. Isso se deve principalmente pelo fato do cliente não saber quais são as suas necessidades e muitas vezes não possuírem um bom entendimento das características e funções que o sistema deveria contemplar. Além disso, mesmos se os clientes soubessem de tudo isso, provavelmente as necessidades deles mudariam ao longo do projeto.
No restante do artigo veremos melhor o que é engenharia de requisitos, como podemos resolver diversos problemas que envolvem o processo de software e quais são as etapas envolvidas no processo de engenharia de requisitos.
Entendendo a Engenharia de Requisitos
As tarefas de engenharia de requisitos ajudam a levar a um entendimento de qual será o impacto do software sobre o negócio, quais são as necessidades do cliente e como os usuários finais irão interagir com o software.
Normalmente a engenharia de requisitos é realizada por analistas de sistemas juntamente com gerentes, clientes, usuários finais e outros que possam ter interesse no software.
A engenharia de requisitos é muito importante, pois nos ajuda a projetar e construir um programa de computador que possa resolver o problema do cliente. Por isso a importância de entender primeiramente o que o cliente quer antes de começarmos a projetar e construir um sistema. De forma mais especifica a engenharia de requisitos consiste de um amplo espectro de tarefas e técnicas que levam a um entendimento dos requisitos.
Dessa forma, a engenharia de requisitos permite que examinemos o contexto do trabalho de software a ser realizado, as necessidades específicas que o projeto e a construção devem atender, as prioridades que orientam a ordem que o trabalho deve ser completado e as informações, funções e os comportamentos que terão um impacto profundo no projeto resultante.
Existem algumas etapas na engenharia de requisitos, são elas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. A concepção é a primeira etapa da engenharia de requisitos e nessa etapa procura-se definir o escopo e a natureza do problema que estamos tentando resolver para o cliente; A segunda etapa é a de levantamento em que se procura ajudar os interessados a definir o que é necessário; A terceira etapa é a de elaboração em que os requisitos básicos são refinados e modificados; A quarta etapa é a de negociação onde se definem quais são as prioridades, o que é essencial e quando é necessário; Na quinta etapa especifica-se o problema e então, na sexta etapa de Validação é realizada uma revisão e validação para garantir que o entendimento dos problemas coincidem com o que os interessados haviam explicado. Essa parte é realizada com os interessados; Por fim, ainda temos uma sétima etapa que é a Gestão dos requisitos em que se controlam os requisitos.
Etapas da Engenharia de Requisitos
A concepção é a primeira etapa da engenharia de requisitos em que se preocupa com o inicio do projeto de um software. Nesta etapa procura-se ter uma conversa informal com os interessados no software a fim de antecipar o trabalho envolvido no software a ser projetado e construído. Alguns projetos são cancelados nesta etapa. Por exemplo, numa empresa de médio porte pode-se chegar à conclusão que não será possível realizar o desenvolvimento daquele software, pois na etapa de concepção identificou-se que a equipe disponível para realizar o trabalho não atenderia as necessidades para o projeto em questão.
Portanto, nesta etapa estabelecemos um entendimento básico do problema, as pessoas que procuram pela solução deste problema, o tipo de solução desejada e a colaboração com os demais interessados e a equipe que será encarregada pelo software.
O Levantamento é uma etapa em que se pergunta ao cliente, usuários e os demais interessados quais são os objetivos de cada um para o sistema, qual será o objetivo do sistema, como o sistema atenderá às necessidades da empresa e como o sistema deverá ser utilizado no dia a dia. Apesar de parecer simples essa é uma etapa bastante complicada. Os autores Christel e Kang identificaram diversos problemas encontrados durante este etapa, entre eles temos: Problemas de escopo em que se definem os limites do sistema de forma precária ou clientes e usuários do sistema especificam detalhes técnicos desnecessários que confundem ao invés de esclarecer os objetivos do sistema; Problemas de Entendimento onde os clientes e usuários não sabem o que precisam, não tem entendimento das capacidades nem das limitações dos seus ambientes computacionais, não possuem completo entendimento do domínio, não sabem transmitir as necessidades aos analistas, omitem informações que consideram óbvias, especificam requisitos que conflitam com as necessidades de outros clientes ou usuários do sistema ou ainda especificam requisitos ambíguos ou impossíveis de serem testados; Por fim, temos os Problemas de Volatilidade em que os requisitos mudam com o tempo.
Portanto, nesta etapa de levantamento temos grande parte dos problemas que afetam o software como um todo. Esta etapa deve ser realizada com muita atenção.
Para o levantamento de requisitos podemos usar diversas técnicas como Entrevistas e Questionários, Workshops de requisitos, Cenários, Prototipagem, entre outras.
A Elaboração é a etapa em que as informações obtidas do cliente durante as etapas anteriores de concepção e levantamento são expandidas e refinadas. A elaboração é realizada através da criação e refinamento de cenários de usuários que descrevem como o usuário final irá interagir com o sistema. Esses cenários são analisados sintaticamente para extrair classes, atributos das classes e os serviços exigidos por essas classes são identificados. Também se identificam as relações e colaboração entre as classes, além de uma variedade de diagramas que são produzidos.
A negociação é responsável por conciliar conflitos que podem existir. Por exemplo, clientes e usuários podem pedir mais do que pode ser alcançado com os recursos limitados de negócio que se tem. Ou ainda, clientes ou usuários podem propor necessidades conflitantes. Todos esses conflitos devem ser conciliados por meio da negociação. Após a negociação alguns requisitos podem ser eliminados, combinados ou modificados, de forma que cada uma das partes fiquem satisfeitas.
A especificação pode ser um documento escrito, um conjunto de modelos gráficos, um modelo matemático formal, um conjunto de cenários de casos de uso, um protótipo ou qualquer combinação dos fatores anteriores. O importante é que essa especificação seja clara e demonstre a necessidade que o cliente solicitou. Dessa forma, a especificação é flexível o suficiente fazendo com que cada equipe, projeto ou empresa defina a melhor para as suas necessidades. De forma geral sistemas grandes preferem uma combinação de documentos escritos, descrições em linguagem natural e modelos gráficos. Por outro lado, sistemas menores preferem muitas vezes apenas cenários de casos de uso.
Uma especificação de requisitos de software ou também chamada (em inglês) de Software Requirements Specification (SRS) é um documento criado quando uma descrição mais detalhada de todos os aspectos do software que está para ser construído deve ser feito antes do inicio do projeto. Dessa forma, segue abaixo um pequeno modelo de como poderia ser essa especificação:
Sumário
Histórico de Revisão
1. Introdução
1.1. Propósito
1.2. Convenções do documento
1.3. Público-alvo e sugestão de leitura
1.4. Escopo do projeto
1.5. Referências
2. Descrição geral
2.1. Perspectiva do produto
2.2. Características do produto
2.3. Classes de usuários e características
2.4. Ambiente operacional
2.5. Restrições de projeto e implementação
2.6. Documentação para usu[arios
2.7. Hipóteses e dependências
3. Características do sistema
3.1. Características do sistema 1
3.2. Características do sistema 2
3.3. Características do sistema n
4. Requisitos de interfaces externas
4.1. Interfaces do usuário
4.2. Interfaces de hardware
4.3. Interfaces de software
4.4. Interfaces de comunicação
5. Outros requisitos não funcionais
5.1. Necessidades de desempenho
5.2. Necessidades de proteção
5.3. Necessidades de segurança
5.4. Atributos de qualidade de software
6. Outros requisitos
Apêndice A: Glosário
Apêndice B: Modelos de análise
Apêndice C: Lista de problemas
A validação é responsável pela avaliação dos artefatos produzidos na engenharia de requisitos. Será avaliada a qualidade dos artefatos produzidos verificando a especificação para garantir que todos os requisitos tenham sido declarados de forma não ambígua. Também se procura detectar inconsistências, omissões, erros e se os artefatos estão dentro de um padrão estabelecido para o processo e para o projeto.
A principal forma de validação é através da revisão técnica em que a equipe responsável pela revisão, normalmente desenvolvedores, clientes, usuários e outros interessados, examinam a especificação buscando erros no conteúdo ou na interpretação, nas áreas que talvez sejam necessários maiores esclarecimentos, informações faltantes, inconsistências, requisitos conflitantes ou irreais.
A Gestão de Requisitos é composta por um conjunto de atividades que ajuda a equipe a identificar, controlar e acompanhar as necessidades e as mudanças a qualquer momento no projeto. Muitas dessas atividades são idênticas às técnicas de gerenciamento de configuração.
Bibliografia
[1] Pressman, R. Engenharia de Software: Uma abordagem Profissional. 7º edição. Editora Bookman.
[2] Ken Schwaber e Jeff Sutherland. Scrum Guide. Disponível em http://www.scrum.org
[3] Mike Cohns: Succeding with Agile. Disponível em http://www.mountaingoatsoftware.com/blog/
