Etapas da Engenharia de Requisitos

Etapas da Engenharia de RequisitosA 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

Pressman, R. Engenharia de Software: Uma abordagem Profissional. 7º edição. Editora Bookman.

Anúncios