Engenharia De Requisitos 5

Os Processos Típicos da Engenharia de Requisitos – Parte 5 Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and Techniques ISBN 0-471-97208-8 Tradução de Eduardo Marquioni Finalizando a série de artigos da apresentação dos processos típicos da Engenharia de Requisitos, a parte 5 trata conceitos de Gerenciamento dos Requisitos/Gerenciamento de Alterações (Rastreabilidade de Requisitos). 1. Rastreabilidade Uma parte crítica do gerenciamento de alterações é a avaliação do impacto da mudança no resto do sistema. Se a mudança é proposta enquanto os requisitos estão sendo desenvolvidos, deve ser identificado como a alteração afeta outros requisitos. Se a alteração é proposta enquanto o sistema está em implementação, o impacto de alteração envolve verificar como a alteração afeta os requisitos, o design do sistema e sua implementação. Se a alteração é proposta depois que o sistema foi colocado em operação, deve haver também uma verificação adicional a fim de identificar como todos os stakeholders do sistema podem ser afetados pela alteração. Para conduzir este tipo de avaliação de impacto, informações sobre dependências de requisitos, razão do requisito e sua implementação devem ser mantidas para complementar as informações do documento de requisitos. Estas informações são chamadas usualmente de informações de rastreabilidade. Avaliações de impacto de alteração dependem destas informações de rastreabilidade para encontrar os requisitos afetados por uma proposta de alteração. Estas informações são classificadas em 4 tipos: · Rastreabilidade “de – para trás”: links dos requisitos a suas fontes (outros documentos ou pessoas); · Rastreabilidade “de – para frente”: links dos requisitos a seus componentes de design e implementação; · Rastreabilidade “volta – para trás”: links dos componentes de design e implementação de volta para os requisitos; · Rastreabilidade “volta – para frente”: links de documentos (que precederam o documento de requisitos) aos requisitos relevantes. Potencialmente, isto cobre um volume muito grande de informação. Na prática, é impossível e caro coletar e gerenciar todos os tipos de informação de rastreabilidade. Os gerentes do projeto devem definir políticas de rastreabilidade identificando quais informações de rastreabilidade essenciais devem ser mantidas. Na prática, as informações de rastreabilidade que são mais comumente mantidas são as rastreabilidades “requisitos para requisitos” e “requisitos para design”. A seguir, alguns dos diferentes tipos de rastreabilidade que podem ser instanciados: Tipo de rastreabilidade Descrição Requisitos – Fontes Link do requisito às pessoas ou documentos que especificaram o requisito. Requisitos – Razão Link do requisito com uma descrição de “porque” foi especificado. Pode ser uma destilação de informações de várias fontes. Requisitos – Requisitos Link do requisito com outros requisitos que sejam, de alguma maneira, dependentes dele. Deve ser um link de “mão dupla” (“depende” e “é dependente de”). Requisitos – Arquitetura Link do requisito com os subsistemas onde estes requisitos estão implementados. Particularmente importante se os subsistemas estiverem sendo desenvolvidos por subcontratados diferentes. Requisitos – Design Link do requisito com hardware ou componentes de software específicos no sistema que são usados para implementar o requisito. Requisitos – Interface Link do requisito com as interfaces de sistemas externos que serão usados na provisão dos requisitos. 2. Tabelas de rastreabilidade As tabelas de rastreabilidade mostram os relacionamentos entre requisitos ou entre requisitos e componentes de design. As tabelas de requisitos devem ser definidas com o número dos requisitos destacados nas linhas e colunas da tabela. Um exemplo simples para um sistema com 6 requisitos seria: Depende de

R1 R1 R2 R3 R4 R5 T6

R2

R3 X

R4 X X

R5

R6

X X

X

X X

Onde: Linha: dependente de Coluna: depende de No exemplo, R1 é dependente de R3 e R4; R2 é dependente de R5 e R6, etc. Se for proposta uma alteração no requisito R4, a leitura da coluna R4 aponta que R1 e R3 dependem de R4. Deve ser avaliado com isso o impacto em R1 e R3 com relação à alteração proposta a R4. A tabela de requisitos é gerenciável para um número pequeno de requisitos (P.EX. até 250). Quando a quantidade de requisitos aumenta e a tabela fica com gerenciamento impossível podem ser usadas listas de rastreabilidade. Estas listas são mais compactas que as tabelas, mas sua desvantagem é que não uma maneira fácil de avaliar a inversa de uma relação (é necessária uma lista para “dependente de” e outra para “depende de”): Requisito Depende de R1 R3, R4 R2 R5, R6 R3 R4, R5 R4 R2 R5 R6 Embora não haja necessidade de um banco de dados de requisitos, é evidente que a navegação entre as informações de rastreabilidade em um banco de dados de requisitos que mantenha informações de relacionamentos de dependência N:N entre os requisitos é muito mais fácil. 3. Políticas de rastreabilidade O problema fundamental em manter informações de rastreabilidade é o alto custo de coletar, analisar e manter a informação. Normalmente as informações de rastreabilidade não são atualizadas, e se torna progressivamente menos útil, o que gera pouco incentivo em atualizá-la: em pouco tempo é descartada e a análise de mudança é realizada informalmente. É útil para as Organizações a definição de um conjunto de políticas de rastreabilidade sobre a informação que deve ser mantida. Normalmente estas políticas incluem: · A informação de rastreabilidade que será mantida (ver tabela abaixo); · As técnicas, como as matrizes de rastreabilidade, que serão utilizadas para manter a rastreabilidade; · Uma descrição dos pontos em que a informação de rastreabilidade deverá ser coletada durante a execução dos processos de engenharia de requisitos e desenvolvimento de sistemas. Os papéis das pessoas responsáveis pela manutenção da informação de rastreabilidade também devem ser definidos; · Uma descrição de como manipular e documentar políticas de exceções, para quando as restrições de tempo tornarem impossível implementar a política de rastreabilidade normal. Haverá sempre ocasiões em que as alterações nos requisitos deverão ser realizadas sem uma primeira avaliação de todos os impactos de alteração e sem manter a informação de rastreabilidade. A política de exceções deve definir como essas alterações serão sancionadas; · O processo usado para garantir que a informação de rastreabilidade seja atualizada depois que a alteração for realizada. Este processo deve cobrir tanto o caso normal quando o processo de exceção. As políticas de rastreabilidade normalmente são definidas para cada projeto, pois envolvem identificar a informação que será rastreada, como representar a informação de rastreabilidade, identificação do responsável pela coleta de informações de rastreabilidade, etc. Some-se a isto o fato de projetos terem requisitos diferentes, ciclos de vida diferentes: a política definida para um projeto pode não ser aplicável a outro. Alguns fatores que influenciam na especificação de políticas de rastreabilidade:

Fator Número de requisitos

Descrição Quanto maior o número de requisitos, maior a necessidade de políticas de rastreabilidade formais. Contudo, uma rastreabilidade completa requisitos – design é impraticável sem apoio de ferramenta para sistemas grandes, pois há muita informação para manter. Ciclo de vida estimado para o Políticas de rastreabilidade mais compreensíveis devem ser definidas para sistemas que tenham um sistema ciclo de vida longo. Nível de maturidade da Políticas de rastreabilidade detalhadas são mais efetivas em termos de custos em Organizações que Organização tenham um nível de maturidade alto. Organizações no nível de maturidade básico devem focar na rastreabilidade mais simples (requisitos – requisitos). Tamanho e composição do Com um time de projeto pequeno, pode ser possível avaliar impacto de alterações propostas sem time de projeto informações de rastreabilidade estruturadas. Em times grandes são necessárias políticas formais. Especialmente se os membros do time trabalham em sites diferentes. Tipo de sistema Sistemas críticos como sistemas de controle tempo-real ou sistemas de segurança críticos necessitam de políticas de rastreabilidade mais compreensíveis que sistemas não críticos. Requisitos específicos do Alguns clientes podem especificar que informações de rastreabilidade especificas, que devem ser cliente entregues como parte da documentação do sistema. Embora as políticas de rastreabilidade estejam especificadas, é muito importante que elas sejam realistas: é tedioso e consome tempo manter informações de rastreabilidade; se as políticas não podem ser implementadas, elas não são úteis. Toda a informação relativa a rastreabilidade que seja relevante para um projeto deve ser disponibilizada de maneira (relativamente) simples aos membros do projeto. Esta informação deve ser atualizada regularmente para se manter útil. Pode ser criado um manual de rastreabilidade, que seria o registro formal utilizado para mostrar os componentes independentes, ou não afetados por uma proposta de alteração em particular. O gerente do projeto (ou o gerente de requisitos) deve trabalhar com os desenvolvedores para garantir que as mudanças nos requisitos, design, etc. foram incorporadas no manual de rastreabilidade; deve revisar as políticas de rastreabilidade; deve avaliar os desvios da política de rastreabilidade e garantir que toda informação será mantida no manual. Esperamos que esta série sobre a Engenharia de Requisitos auxilie os profissionais interessados e/ou envolvidos no assunto. A Choose Technologies coloca-se à disposição para esclarecimentos adicionais através de seu corpo de consultores.