Os Processos Típicos da Engenharia de Requisitos – Parte 3

Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and TechniquesISBN 0-471-97208-8

Traduzido por Eduardo MarquioniContinuando a série de artigos da apresentação dos processos típicos da Engenharia de Requisitos, a parte 3 desta série se aprofunda um pouco em alguns conceitos do Gerenciamento dos Requisitos (estabilidade e armazenamento de requisitos).

1. Requisitos estáveis e requisitos voláteisMudanças em requisitos ocorrem enquanto os requisitos estão sendo elicitados, analisados, validados e após o sistema ter entrado em operação. Alterações em requisitos são inevitáveis e não implicam práticas pobres de engenharia de software, e resultam de uma combinação de fatores conforme tabela a seguir:Fator de mudança Descrição

Erros em requisitos, conflitos e inconsistências

Conforme os requisitos são analisados e implementados, erros e inconsistências surgem e devem ser corrigidas. Estes problemas podem ser descobertos durante a analise e validação de requisitos, ou mais tarde no processo de desenvolvimento.

Evolução conhecimento do cliente e/ou usuário final do sistema

Conforme os requisitos são desenvolvidos, clientes e usuários finais desenvolvem uma melhor compreensão do que realmente

Problemas técnicos, de custo ou cronograma

Problemas podem ser encontrados na implementação dos requisitos. Pode ser muito caro ou tomar muito tempo implementar certos requisitos.

Mudanças nas prioridades do cliente

As prioridades do cliente podem mudar durante o desenvolvimento do sistema como resultado de mudanças no ambiente de negócios, o aparecimento de novo concorrente, mudanças de staff, etc.

Mudanças de ambienteO ambiente no qual o sistema será instalado pode mudar de tal forma que os requisitos tenham que mudar para manter compatibilidade.

Mudanças organizacionaisA Organização que pretende usar o sistema pode mudar sua estrutura e processos, resultando em novos requisitos de sistema.

Embora a mudança seja inevitável, é usual o caso em que alguns requisitos são mais estáveis que outros. Requisitos estáveis são concebidos com a essência de um sistema e seu domínio da aplicação, e mudam mais lentamente que requisitos voláteis.Os requisitos voláteis são específicos para a instanciação de um sistema em um ambiente particular e para um cliente particular. Considere por exemplo um sistema para gerenciar registros de estudantes em uma universidade. O sistema terá sempre que manter informações sobre estudantes, cursos que fazem e suas avaliações de performance nestes cursos. Estes são os aspectos estáveis do sistema. O sistema pode manter também informações sobre comparecimento às aulas. Este último requisito é mais volátil, pois os cursos poderiam ser ministrados à distância pela Internet, o que significaria que comparecimento teria um significado completamente diferente.Há pelo menos 4 tipos de requisitos voláteis:

Requisitos mutáveis: são os requisitos que mudam em função de mudanças no ambiente no qual o sistema opera. Por exemplo, os requisitos para um sistema que calcula taxas de dedução que evolui conforme as leis de taxação mudam.

Requisitos emergentes: são os requisitos que não podem ser completamente definidos quando o sistema é especificado, mas que emergem quando o sistema está projetado e implementado. Por exemplo, pode não ser possível especificar de antemão os detalhes de como a informação será exibida. Conforme os stakeholders vêem exemplos de apresentações possíveis, eles podem pensar em novas maneiras de exibição da informação que seria útil para eles.

Requisitos conseqüentes: são os requisitos baseados em suposições de como o sistema será utilizado. Quando o sistema é posto em uso, algumas destas suposições podem estar erradas. Usuários irão adaptar-se ao sistema e encontrar novas maneiras de usar suas funcionalidades, o que irá resultar em demandas dos usuários para mudanças no sistema.

Requisitos de compatibilidade: são os requisitos que dependem de outro equipamento ou processo. Conforme muda esse equipamento, os requisitos também mudam.

É uma boa prática de gerenciamento de requisitos tentar antecipar mudanças de requisitos, o que envolve classificar os requisitos para identificar os mais voláteis e predizer possíveis mudanças, o que provê informação aos desenvolvedores do sistema que pode ajudá-los a projetar o sistema de tal forma que os requisitos sejam implementados com (relativa) independência de componentes, para tentar minimizar a influência destas mudanças no restante do sistema.

2. Identificação e armazenamento de requisitosUm pré-requisito essencial para gerenciamento de requisitos é que todo requisito deve possuir algum tipo de identificador único. Embora possa parecer simples e óbvio, muitos documentos de requisitos não possuem identificadores únicos de requisitos, o que torna o gerenciamento efetivo impossível.A abordagem mais comum para identificação de requisitos é baseada na numeração dos requisitos de acordo com o capítulo e seção do documento onde o requisito está incluído. Com isso, o 6 o requisito da 2a seção do capítulo 4 teria a numeração 4.2.6. Há dois problemas com este estilo de identificação:

O capítulo e a seção precisam obrigatoriamente ser estáveis: enquanto o documento de requisitos não estiver terminado, há pouca probabilidade de êxito na atribuição de uma numeração única. Quando um requisito é elicitado, pode ser obscuro o local onde ele irá aparecer no documento de requisitos, logo não pode ter um número associado e não pode ser referenciado por outros requisitos.

Atribuir um identificador baseado em capítulos e seção implicitamente classifica os requisitos, o que sugere que eles seja intimamente relacionados àqueles com identificadores similares. Os leitores do documento podem ser erroneamente conduzidos a pensar que não há outros relacionamentos importantes entre o requisito e outros em outras partes do documento.

Há abordagens alternativas para endereçar os problemas de identificação de requisitos. A seguir algumas técnicas para identificadores de requisitos:Método de identificação

Descrição

Renumeração dinâmica

Alguns processadores de texto permitem renumeração dinâmica de parágrafos e a inclusão de referência cruzada. Assim, pode ser atribuído um número ao requisito a qualquer momento. Conforme são incluídos novos requisitos, ou o documento é reorganizado, o processador de texto mantém a rastreabilidade da referência cruzada, re numerando automaticamente o requisito em função do capítulo, seção e posição na seção; todas as referências ao requisito também são re numeradas.

Identificação por registro do bando de dados

Quando um requisito é identificado, ele entra imediatamente em um banco de dados de requisitos e um identificador é atribuído ao registro do banco de dados. Este identificador é utilizado em todas as referências subseqüentes ao requisito.

Identificação simbólica

Os requisitos podem ser identificados através da atribuição de um nome simbólico associado ao assunto tratado pelo requisito. Por exemplo, EFS-1, EFS2, EFS3 podem ser utilizados aos requisitos relacionados à eficiência do sistema. O problema é que às vezes é difícil classificar requisitos dessa forma, além de atribuir um mnemônico significativo para ele.

Note que: Quando o requisito possui outro identificador (além do número do parágrafo), pode haver facilidade para re arranjar os

requisitos, mas confusão dos leitores (que eventualmente correm o risco de misturarem o identificador com o número do parágrafo);

O uso de um processador de texto implica que seja criada uma versão inicial do documento de requisitos, em um ou mais arquivos do tipo texto, onde várias pessoas estarão envolvidas em redigir o documento. Ocorre que as mudanças podem necessitar ser realizadas por várias pessoas, o que obriga a definição de um processo para realização de merges periódicos. A vantagem desta abordagem é que os requisitos são armazenados todos juntos, seu acesso é fácil e é relativamente simples produzir novas versões do documento de requisitos; a abordagem é utilizada por muitas Organizações que produzem requisitos para sistemas de tamanho pequeno ou médio, quando é possível manter os requisitos desta maneira. Sob a perspectiva do gerenciamento de requisitos, há desvantagens:

As informações de rastreabilidade de requisitos (dependências) são mantidas de forma superficial; As facilidades de procura dos requisitos são limitadas às facilidades de busca do editor. Normalmente não é

simples encontrar grupos de requisitos com características comuns; Não é possível fazer o link eletrônico entre os requisitos e suas correspondentes alterações propostas; Qualquer controle de versão dos requisitos deve ser realizada para todo o documento de requisitos, ou na melhor

das hipóteses, para capítulos individuais: não é normalmente possível manter versões diferentes do mesmo requisito;

Não é possível navegar automaticamente entre requisitos relacionados ou entre representações diferentes de requisitos (P.EX. de uma representação textual para um diagrama).

Um banco de dados (atualmente, preferencialmente relacional) provê as facilidades destacadas nos itens anteriores, pois geralmente suportam acesso simultâneo de usuários e fornecem facilidades de backup e recuperação. Observe que não há um banco de dados ideal para este gerenciamento, e o banco desenvolvido e/ou adquirido deve considerar alguns fatores:

1. Fator Descrição

Estrutura dos requisitos

Os requisitos podem ser expressos como combinação de linguagem natural, diagramas, expressões matemáticas, etc. Em alguns casos, informações adicionais como fotografias podem ser armazenadas como parte da explicação dos requisitos. Se há necessidade de armazenar mais que texto, um banco de dados que suporte multimídia pode ser necessário.

Número de requisitos

Os requisitos para sistemas de pequenos a médios (cerca de 1000 requisitos, P.EX.) podem ser gerenciados com o uso de bancos de dados comerciais para PC. Sistemas maiores usualmente necessitam de um banco de dados projetado para manipular volumes grandes de dados, executando em um servidor próprio.

Equipe de trabalho, distribuição da equipe e ambiente de hardware

Se os requisitos são desenvolvidos por uma equipe distribuída, talvez por Organizações diferentes, pode ser necessário um banco de dados que possua acesso remoto multi sites. Se forem usados tipos diferentes de computadores, pode ser apropriada uma solução baseada em Intranet para prover acesso aos requisitos através de um browser.

Uso de ferramentas CASEFerramentas CASE de vários tipos podem ser utilizadas em outros estágios do processo de desenvolvimento. Se elas usam um banco de dados, faz muito sentido usar o mesmo para o gerenciamento de requisitos.

Banco de dados já existenteSe já está em uso um banco de dados para suporte à Engenharia de Software, ele deve ser utilizado para o gerenciamento de requisitos. Se não for utilizado nenhum banco de dados, os custos de aquisição e treinamento dos profissionais do banco devem ser considerados.

Nas próximas edições do InfoChoose, serão melhor discutidos aspectos relativos ao gerenciamento de alterações e rastreabilidade dos requisitos.