Engenharia De Requisitos 2

Os Processos Típicos da Engenharia de Requisitos – Parte 2 Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and Techniques ISBN 0-471-97208-8 Traduzido por Eduardo Marquioni Na última edição do InfoChoose teve início uma série de artigos para apresentar em linhas gerais os 5 processos típicos da Engenharia de Requisitos. A parte 2 desta série trata os processos de Especificação de Requisitos, Validação dos Requisitos e o Gerenciamento dos Requisitos.

1. Especificação de Requisitos No contexto de software, o termo especificação tem significado diferente para diversas pessoas. Uma especificação pode ser um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de cenários de uso, um protótipo, ou qualquer combinação dos itens citados. Embora seja sugerido às vezes o desenvolvimento e uso de templates padrão para especificação de requisitos, com o argumento que isto conduz a uma representação de maneira mais consistente e compreensível, há momentos em que existe a necessidade da criação de uma especificação mais “flexível”. Para grandes sistemas, um documento escrito contendo linguagem natural combinada a modelos gráficos pode ser a melhor abordagem. Para sistemas pequenos desenvolvidos em ambiente técnico conhecido pode ser suficiente a utilização de cenários de uso. A especificação do sistema é o produto final produzido pelos engenheiros de requisitos. Ela é usada como a base para as engenharias de hardware, software e banco de dados, pois descreve funções e performance requeridas de um sistema baseado em computação e as regras que irão guiar seu desenvolvimento. A especificação limita cada elemento alocado ao sistema. A especificação do sistema também descreve a informação (dados e controle) que é entrada e saída do sistema.

1.1. Modelagem do Sistema Imagine que se deseja especificar todos os requisitos para a construção de uma cozinha. Deve-se saber as dimensões da obra, localização das portas e janelas e todo o espaço disponível. Com isso é possível especificar os gabinetes e demais utilitários, além de indicar onde eles estarão localizados. Contudo, para uma especificação completa, seria necessária a criação de uma planta ou uma representação tridimensional que exibisse a posição dos gabinetes e demais utilitários, a relação entre eles a fim de avaliar, por exemplo, a eficiência do fluxo durante o trabalho (que é um requisito básico de toda cozinha). São construídos modelos de sistema pela mesma razão da planta da cozinha. É importante avaliar a relação entre os componentes de um sistema, para avaliar a “estética” do sistema. O engenheiro de sistemas pode criar um template para modelo do sistema (que funcionará como a fundação para as etapas seguintes do desenvolvimento) contendo: a interface com o usuário, entradas, funções e controles do sistema, saídas, manutenção e teste. Pode ser definida também uma estrutura hierárquica montada a partir de um diagrama de contexto, para identificar os produtores externos de informação, consumidores externos da informação produzida pelo sistema e todas as entidades que se comunicam através da interface ou executam manutenção e testes.

2. Validação de Requisitos Os produtos de trabalho criados como conseqüência da engenharia de requisitos (uma especificação do sistema e informações relacionadas) devem ser validados quanto à qualidade durante o passo de validação de requisitos. Esta validação examina a especificação para garantir que todos os requisitos do sistema foram estruturados de maneira não ambígua, que as inconsistências, omissões e erros foram apagados e corrigidos, e que os produtos de trabalho estão em conformidade com os padrões estabelecidos para o processo, para o projeto e para o produto. O mecanismo primário de validação de requisitos é a revisão técnica formal. O time de revisão inclui os engenheiros de sistema, clientes, usuários e outros stakeholders que examinam a especificação1 do sistema à procura de erros de conteúdo ou interpretação, pontos onde pode ser necessário esclarecimento, perda de informações, inconsistências (um dos maiores problemas da engenharia de grandes produtos), requisitos conflitantes, ou requisitos irreais (de desenvolvimento impossível).

Embora a revisão para validação dos requisitos possa ser conduzida de qualquer maneira desde que possibilite a descoberta de erros nos requisitos, é útil examinar cada requisito contra um check list. A seguir um pequeno subconjunto do que pode ser questionado: • Os requisitos estão estruturados claramente? Não há problemas de interpretação incorreta? •

A fonte (pessoa, regimento, documento, etc.) foi identificada? A estrutura final do requisito foi examinada pela/contra a fonte original?

•

O requisito está definido em termos quantitativos?

•

Quais são os requisitos relacionados a cada um? Eles estão claramente identificados através de uma matriz de referência cruzada ou outro mecanismo?

•

O requisito viola alguma regra de domínio?

•

O requisito é passível de teste? Se sim, podem ser especificados os testes para exercitar os requisitos 2 ?

•

O requisito é rastreável para qualquer modelo de sistema que seja criado?

•

O requisito é rastreável para os objetivos gerais do produto/sistema?

•

Os requisitos associados à performance, comportamento e características operacionais foram estruturados claramente? Que requisitos parecem implícitos?

3. Gerenciamento de Requisitos É necessário persistir as alterações de requisitos através de toda a vida do software; neste sentido, o gerenciamento de requisitos corresponde ao conjunto de atividades que auxilia o time do projeto a identificar, controlar e rastrear os requisitos, bem como as alterações nos requisitos em muitos momentos do projeto3. Gerenciamento de Requisitos é o processo que gerencia mudanças nos requisitos de um sistema. Os requisitos evoluem devido às mudanças no ambiente do sistema e conforme os clientes desenvolvem um melhor entendimento de suas reais necessidades4. Novos requisitos surgem e há alterações nos requisitos em todos os estágios do processo de desenvolvimento do sistema. São comuns os casos em que mais de 50% dos requisitos são alterados antes que o sistema seja posto em operação, o que causa sérios problemas para os desenvolvedores; para minimizar dificuldades, os requisitos devem ser documentados e controlados. Quando não há controle de alterações, mudanças de baixa prioridade podem ser implementadas antes que aquelas de alta prioridade, além de mudanças com alto custo não serem necessariamente aprovadas. Um levantamento em mais de 4.000 empresas européias identificou que uma das principais áreas problemáticas do desenvolvimento e produção de software era o gerenciamento de requisitos dos clientes (internos e externos). As principais preocupações de gerenciamento de requisitos são: • Gerenciar mudanças nos requisitos acordados; • •

Gerenciar os relacionamentos entre os requisitos;

Gerenciar as dependências entre o documento de requisitos e outros documentos produzidos ao longo do sistema e do processo de engenharia de software. As mudanças nos requisitos podem ser devidas a erros e confusão no processo de engenharia de requisitos, design ou problemas de implementação. Novos requisitos podem surgir conforme os stakeholders desenvolvem uma melhor compreensão do sistema. Normalmente, as alterações em requisitos são resultados de alterações em circunstâncias externas (P.EX. novas leis ou regulamentações introduzidas no ambiente de negócio). Os requisitos não podem ser gerenciados de forma efetiva sem rastreabilidade. Um requisito é rastreável se for possível identificar quem solicitou o requisito, porque o requisito existe, quais os requisitos relacionados e

como os requisitos se relacionam a outras informações como design de sistemas, implementações e documentos do usuário. Estas informações são utilizadas para identificar todos os requisitos afetados por mudanças propostas. Boas práticas de gerenciamento de requisitos, como uma manutenção de dependências entre requisitos têm benefícios em longo prazo, como maior satisfação do cliente e custos de desenvolvimento mais baixos. Uma vez que os retornos não são imediatos, o gerenciamento de requisitos pode parecer uma despesa desnecessária; contudo, sem a gerencia, a economia de curto prazo será devastada pelos custos em longo prazo. Os problemas com gerenciamento de requisitos geralmente significam que os clientes não ficarão satisfeitos quando da entrega do produto. Gerenciamento de requisitos é essencialmente um processo de gerenciar grandes quantidades de informação e garantir que elas serão entregues à pessoa certa no tempo certo. Ferramentas de gerenciamento de requisitos podem prover facilidades como: • Um sistema de banco de dados para armazenamento de requisitos; •

Análise de documento e facilidades de geração para ajudar a construir um banco de dados de requisitos e auxiliar na criação dos documentos de requisitos;

•

Facilidades de gerenciamento de mudanças que ajudam a garantir que as mudanças foram avaliadas e cotadas corretamente;

•

Facilidades de rastreabilidade que auxiliam os engenheiros de requisitos a encontrar dependências entre requisitos. Nas próximas edições do InfoChoose, serão melhor discutidos aspectos relativos ao Gerenciamento de Requisitos: estabilidade e volatilidade, armazenamento, gerenciamento de alterações e rastreabilidade. 1

É muito recomendável que haja várias revisões de requisitos durante a especificação dos requisitos, para que sejam validadas pequenas porções de especificação, garantindo que a atenção seja focada em aspectos específicos dos requisitos. 2 Estes testes são chamados de critérios de validação. 3 Segundo Pressman 4 Segundo Kotonya e Sommerville