No entanto, [SOMMERVILLE, 2007] ressalta o fato de que os requisitos de sistema mudam constantemente, em virtude do amadurecimento na compreensão das pessoas envolvidas acerca do que desejam que o software faça ou ainda de modificações no hardware, software ou ambiente organizacional do sistema.
Deste modo, um controle efetivo dos requisitos vindos do usuário e de suas mudanças, assume papel maior que simplesmente atender a especificação de uma área de processo e sim de garantir a adequação do produto final ao seu meio externo.
A gerência de requisitos representa assim, a figura de ligação entre as áreas de planejamento de projeto, solução técnica e gerência de configuração. Um reflexo disso é o fato de que este é um dos processos que não aceitam qualquer exclusão no modelo MPS.BR [SOFTEX, 2008].
Sendo fundamental a ambos os modelos de referência, esta área de processo recebe enfoques semelhantes em cada um deles. Porém ambos apresentam apenas listas de necessidades que devem ser atendidas e não uma proposta de artefatos para sua realização.
Deste modo, empresas que tenham interesse em melhorar seus processos precisam buscar referências externas a respeito de como proceder, gerando margem para implementações custosas e pouco eficientes daquilo que deveria ser uma otimização de processos.
Este artigo tem por objetivo apresentar uma contextualização entre o processo de gerência de requisitos e as necessidades impostas pelos modelos CMMI e MPS.BR, definindo um conjunto mínimo de artefatos para cumprimento das mesmas, que possam ser utilizados por empresas de pequeno ou médio porte.
São descartadas neste artigo as necessidades referentes à área de processo de definição de requisitos – formalizada em [SEI, 2006] - uma vez que a mesma não é o
foco deste estudo.
Modelos de Referência
Dentre os diversos modelos propostos ao redor do mundo, foram selecionados os modelos de referência CMMI e MPS.BR, sendo o primeiro selecionado por sua aceitação mundial e representatividade de mercado, enquanto o segundo representa um movimento que propõe uma aproximação ao cenário das empresas brasileiras.
O modelo de referência para melhoria de software brasileiro (MR-MPS) indica ainda uma equivalência [SOFTEX, 2008] entre seus processos e as áreas de processo definidas no modelo CMMI, conforme ilustra a abaixo.
CMMI e a Gerência de Requisitos
Dentro do modelo CMMI, a gerência de requisitos é uma área de processo componente do Nível 2 de Maturidade, conhecido como “Gerenciado”. Neste nível, os processos da empresa devem ser executados dentro de um padrão e por pessoas habilitadas, de acordo com controles definidos [SEI, 2006].
A gerência de requisitos tem aqui o papel de garantir que todos os artefatos produzidos sejam coesos com a necessidade do cliente, por meio da identificação dos requisitos que originaram cada implementação. É vista também como ponto de partida para o planejamento de atividades e entregas, uma vez que a área de gerência de configuração pode definir seus pacotes em virtude de agrupamentos de requisitos.
Outro aspecto relevante é a possibilidade de rastrear o impacto na solução de falhas no software ou nas solicitações de mudanças vindas dos usuários.
MPS.BR e a Gerência de Requisitos
Diferentemente do CMMI, dentro do modelo MPS.BR, o processo de gerência de requisitos é visto como parte do nível mais baixo de maturidade possível, o Nível G, conhecido como “Parcialmente Gerenciado” [SOFTEX, 2007].
Este enfoque coloca um maior destaque nas tarefas que deste processo, colocando-o num papel de ligação entre artefatos e requisitos, objetivando que a rastreabilidade com relação às necessidades originalmente mapeadas seja mantida. Trata-se então de uma diferença sutil, que demanda atenção extra às tarefas que o
compõe.
Com relação à avaliação de impacto em solicitações de mudanças ou correções de falhas, a definição é similar ao proposto pelo CMMI.
A Questão da Rastreabilidade
Uma das exigências comuns ao nível G do MPS.BR e ao nível 2 do CMMI é a rastreabilidade entre um requisito e todos os artefatos envolvidos na implementação
decorrente dele, conforme apresentado em [SEI, 2006] e [SOFTEX, 2007].
Esta prática permite uma maior efetividade na gerência de configuração, que visa justamente garantir que cada versão do software permita isolar uma versão compatível dos componentes envolvidos em sua realização, chamada baseline. Realizar
esta tarefa sem uma referência sólida a quais telas ou componentes são afetados por
determinado requisito, dificultaria a tarefa de isolar a versão, inviabilizando a geração de baselines.
No entanto, este rastreio se complica quando consideramos que um requisito pode ser atendido por uma tela inteira ou por uma simples caixa de texto. [MEDEIROS, 2006]
Levando em conta que um documento de caso de uso pode ser utilizado para refletir uma tela ou um único método, desde que este seja suficientemente relevante, tem-se uma opção se solução: mapear casos de uso versus requisitos funcionais.
Por meio desta prática é possível identificar no detalhe os artefatos que serão afetados cada vez que uma mudança é realizada em um caso de uso específico, bem como prover uma análise de impacto mais eficaz antes de planejar uma tarefa.
A elaboração de uma planilha descrevendo esta relação, em conjunto à existência de um documento padronizado para a elicitação de requisitos, onde seja possível não apenas mapear as necessidades, mas também a interdependência entre requisitos (sejam
eles funcionais ou não) permite atender a todas as necessidades especificadas pelos modelos CMMI e MPS.BR, conforme descrito em seus documentos de referência.
Artefatos para a Gerência de Requisitos
Levando em conta os aspectos discutidos anteriormente, propõe-se que a gerência de requisitos seja atendida por meio da adoção de artefatos que reflitam tarefas consideradas padrão de mercado, no que diz às atividades realizadas pelos envolvidos
em sua realização.
Os documentos propostos são: Documento de Visão, Matriz de Rastreabilidade e Documento de Especificação de Caso de Uso, compatíveis com o Rational Unified Process [RATIONAL, 2009], processo de engenharia de software que se baseia na definição de disciplinas para atribuição de tarefas e responsabilidades no desenvolvimento do software.
Visando atender os modelos de referência observados, é necessário que os artefatos possuam sessões específicas para mapeamento das relações de dependência com os diversos requisitos elicitados, conforme definido. Cada um destes artefatos acompanha todo o ciclo de vida do desenvolvimento do software, permeando suas diferentes fases. A seguir, cada um deles será observado em mais detalhes, bem como a relação entre artefatos, usos e fases do ciclo de vida.
Por meio deles, as cinco práticas específicas exigidas pelo CMMI são totalmente atendidas, bem como os cinco resultados esperados propostos melo MPS.BR.
Documento de Visão
Um documento relacionando as necessidades do usuário, seu entendimento por parte do analista de requisitos e o conjunto de requisitos (funcionais ou não) propostos para atender cada uma das necessidades mapeadas. Este documento é validado pelos usuários e pode ser utilizado para definição do escopo inicial do projeto.
Fases do Ciclo de Desenvolvimento em que é empregado e atividades realizadas:
- Pré-Venda: Análise do Problema, Definição de Requisitos de Negócio e Requisitos de Usuário, Definição de Requisitos Funcionais e Requisitos Não Funcionais;
- Análise e Design: Relação entre: Requisitos de Usuário e Requisitos de Negócio, Requisitos de Negócio e Requisitos Não Funcionais, Requisitos de Usuário e Requisitos Funcionais.
Práticas Específicas do CMMI atendidas [SEI, 2006]:
- SP 1.1. Obter um entendimento dos requisitos;
- SP 1.2. Obter aprovação dos requisitos.
Resultados Esperados do MPS.BR atendidos [SOFTEX, 2007]:
- GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;
- GRE 2. Os requisitos de software são aprovados utilizando critérios
objetivos.
Matriz de Rastreabilidade
Documento responsável por estabelecer uma relação bidirecional entre os requisitos originais e os componentes do produto final (software). Caso um requisito não possua nenhum caso de uso equivalente mapeado na planilha, uma inconsistência de projeto é efetivamente localizada.
Fases do Ciclo de Desenvolvimento em que é empregado e atividades realizadas:
- Análise e Design: Relação entre Casos de Uso e Requisitos Funcionais;
- Validação e Homologação: Possibilita o Rastreio e comparação entre uma implementação e a necessidade que a originou.
Práticas Específicas do CMMI atendidas [SEI, 2006]:
- SP 1.3. Gerenciar as mudanças de requisitos;
- SP 1.4. Manter rastreabilidade bidirecional entre os requisitos;
- SP 1.5. Identificar inconsistências entre projeto e requisitos.
Resultados Esperados do MPS.BR atendidos [SOFTEX, 2007]:
- GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;
- GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos;
- GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
Documento de Especificação de Caso de Uso
Além do tradicional Diagrama de Casos de Uso, cabe elaborar um documento detalhando cada caso de uso, de acordo com sua especificidade [MEDEIROS, 2006]. Neste documento é realizada a especificação da implementação que será realizada pelos desenvolvedores, já com o foco nos artefatos que serão produzidos.
Embora esteja muito mais relacionado à área de processo de definição de requisitos do que à gerência propriamente dita, sua realização é essencial à construção da Matriz de Rastreabilidade, que vincula os casos de uso a seus requisitos.
Fases do Ciclo de Desenvolvimento em que é empregado e atividades realizadas:
- Análise de Design: Detalha a solução para uma necessidade traduzida em requisito funcional e permite a validação da solução proposta pelo Analista de Requisitos ou de Negócio.
Práticas Específicas do CMMI atendidas [SEI, 2006]:
- SP 1.4. Manter rastreabilidade bidirecional entre os requisitos.
Resultados Esperados do MPS.BR atendidos [SOFTEX, 2007]:
- GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.
Conclusão
Por meio da utilização de três artefatos de confecção relativamente simples – Documento de Visão, Matriz de Rastreabilidade e Documento de Especificação de Caso de Uso - é possível atender a todas as exigências estabelecidas à área de processo de Gerência de Requisitos, de acordo com os modelos de referência analisados.
Porém, o nível de interdependência entre os documentos evidencia a necessidade de um processo eficiente para a definição dos requisitos, uma vez que uma falha nesta atividade resultará em um conjunto inconsistente de requisitos no documento de visão, refletidos em casos de uso que não traduzem a real expectativa do cliente.
Estes casos de uso e requisitos serão relacionados na matriz de rastreabilidade e futuramente, quando forem recebidas solicitações de mudanças em determinados pontos do sistema, a tarefa de localizar o ponto de origem do problema e os demais casos de uso relacionados a este mesmo requisito terá sua complexidade incrementada.
Outra questão que se torna evidente é a margem de falha humana, pois ao discutir a elaboração dos referidos artefatos sem a proposta de um pacote especializado de ferramentas surge a possibilidade de que determinado campo não seja preenchido, mesmo que de forma não intencional. Deste modo, cabe a cada empresa avaliar a relação entre custo e benefício da adoção de meios automatizados para a construção e relacionamento dos documentos.
É interessante ressaltar também que o modelo MPS.BR prega compatibilidade com o CMMI e, no que diz respeito à gerência de requisitos, seus resultados esperados correspondem diretamente às práticas específicas impostas pelo modelo norteamericano, de modo que os artefatos propostos poderiam ser elaborados considerando apenas o CMMI como critério de satisfação.
No anexo você encontra modelos de documentos ilustrando os conceitos abordados: Gerencia_Requisitos_slides.pdf
Referências Bibliográficas
[SEI, 2006] CMMI Product Team. CMMI for Developmment, Version 1.2. Pittsburg, EUA: Carnegie Mellon University – Software Egineering Institute, 2006.
[SOMMERVILLE, 2007] Sommerville, Ian. Engenharia de Software, 8ª Edição. São Paulo: Pearson Addison Wesley, 2007.
[SOFTEX, 2008] FAQ Implementação MR-MPS - Dúvidas sobre o Guia Geral e Guia de Implementação. http://www.softex.br/mpsBr/_faq/faqImplementacao.asp.
Recuperado em 01/12/2008.
[SOFTEX, 2007] Associação para Promoção da Excelência do Software Brasileiro - SOFTEX. MPS.BR – Guia Geral, Versão 1.2, junho 2007.
[MEDEIROS, 2006] Medeiros, Ernani Sales de. Desenvolvimento de Software com
UML 2.0: definitivo. São Paulo: Pearson Makron Books, 2006.
[RATIONAL, 2009] Technical resources and best practices for the Rational® software
platform. http://www.ibm.com/developerworks/rational. Recuperado em 03/02/2009.
Autor: Ângelo Amaral
Sobre: Pós-graduado em Engenharia de Software pelo ITA com especialização em modelos de construção de aplicações comerciais utilizando motores de regras de negócio, possui experiência na implantação de scrum e coordenação de projetos e sistemas de varejo.
Contato: angelo.amaral@gmail.com
Sobre: Pós-graduado em Engenharia de Software pelo ITA com especialização em modelos de construção de aplicações comerciais utilizando motores de regras de negócio, possui experiência na implantação de scrum e coordenação de projetos e sistemas de varejo.
Contato: angelo.amaral@gmail.com
