Boas prticas para gerncia de requisitos, de acordo com os modelos MPS.

BR e CMMI
ngelo Amaral Instituto Tecnolgico de Aeronutica. So Jos dos Campos, So Paulo - Brasil
angelo.amaral@gmail.com

Abstract. Both CMMI and MPS.BR propose that a procedure for managing requirements shall be established, indicating also the traceability level between the artifacts produced on this phase. However, there is no documentation about how to execute this activity or wich artifacts shall be used. This article traces a line through these questions, and presents a minimum set of artifacts that can be adopted by small or medium companies, aiming to improve their processes. Resumo. Tanto o CMMI quanto o MPS.BR prope que um procedimento para a gerncia de requisitos seja estabelecido, indicando inclusive o nvel de rastreabilidade existente entre os artefatos decorrentes desta fase. No entanto, no h documentao a respeito do modo como os profissionais devem conduzir esta tarefa ou de quais artefatos devem ser utilizados. Este artigo visa mapear tais questes bem como propor um conjunto mnimo de artefatos que possa ser adotado por empresas de pequeno ou mdio porte buscando a melhoria de seus processos.

1. Introduo
A atividade de gerncia de requisitos tem por objetivo mapear os requisitos identificados na fase inicial de um projeto e rastre-los at os artefatos finais, permitindo a validao da consistncia entre os mesmos e as requisies originalmente vindas dos solicitantes, conforme definido pelo modelo CMMI [SEI, 2006]. No entanto, [SOMMERVILLE, 2007] ressalta o fato de que os requisitos de sistema mudam constantemente, em virtude do amadurecimento na compreenso das pessoas envolvidas acerca do que desejam que o software faa ou ainda de modificaes no hardware, software ou ambiente organizacional do sistema. Deste modo, um controle efetivo dos requisitos vindos do usurio e de suas mudanas, assume papel maior que simplesmente atender a especificao de uma rea de processo e sim de garantir a adequao do produto final ao seu meio externo. A gerncia de requisitos representa assim, a figura de ligao entre as reas de planejamento de projeto, soluo tcnica e gerncia de configurao. Um reflexo disso o fato de que este um dos processos que no aceitam qualquer excluso no modelo MPS.BR [SOFTEX, 2008].

Sendo fundamental a ambos os modelos de referncia, esta rea de processo recebe enfoques semelhantes em cada um deles. Porm ambos apresentam apenas listas de necessidades que devem ser atendidas e no uma proposta de artefatos para sua realizao. Deste modo, empresas que tenham interesse em melhorar seus processos precisam buscar referncias externas a respeito de como proceder, gerando margem para implementaes custosas e pouco eficientes daquilo que deveria ser uma otimizao de processos. 1.1. Objetivo Este artigo tem por objetivo apresentar uma contextualizao entre o processo de gerncia de requisitos e as necessidades impostas pelos modelos CMMI e MPS.BR, definindo um conjunto mnimo de artefatos para cumprimento das mesmas, que possam ser utilizados por empresas de pequeno ou mdio porte. 1.2. Restrio So descartadas neste artigo as necessidades referentes rea de processo de definio de requisitos formalizada em [SEI, 2006] - uma vez que a mesma no o foco deste estudo.

2. Modelos de Referncia
Dentre os diversos modelos propostos ao redor do mundo, foram selecionados os modelos de referncia CMMI e MPS.BR, sendo o primeiro selecionado por sua aceitao mundial e representatividade de mercado, enquanto o segundo representa um movimento que prope uma aproximao ao cenrio das empresas brasileiras. O modelo de referncia para melhoria de software brasileiro (MR-MPS) indica ainda uma equivalncia [SOFTEX, 2008] entre seus processos e as reas de processo definidas no modelo CMMI, conforme ilustra a Figura 1.

Figura 1 - Equivalncia entre os modelos de referncia. Fonte: FAQ Implementao MR-MPS [SOFTEX, 2008]

2.1. CMMI e a Gerncia de Requisitos Dentro do modelo CMMI, a gerncia de requisitos uma rea de processo componente do Nvel 2 de Maturidade, conhecido como Gerenciado. Neste nvel, os processos da empresa devem ser executados dentro de um padro e por pessoas habilitadas, de acordo com controles definidos [SEI, 2006]. A gerncia de requisitos tem aqui o papel de garantir que todos os artefatos produzidos sejam coesos com a necessidade do cliente, por meio da identificao dos requisitos que originaram cada implementao. vista tambm como ponto de partida para o planejamento de atividades e entregas, uma vez que a rea de gerncia de configurao pode definir seus pacotes em virtude de agrupamentos de requisitos. Outro aspecto relevante a possibilidade de rastrear o impacto na soluo de falhas no software ou nas solicitaes de mudanas vindas dos usurios. 2.2. MPS.BR e a Gerncia de Requisitos Diferentemente do CMMI, dentro do modelo MPS.BR, o processo de gerncia de requisitos visto como parte do nvel mais baixo de maturidade possvel, o Nvel G, conhecido como Parcialmente Gerenciado [SOFTEX, 2007]. Este enfoque coloca um maior destaque nas tarefas que deste processo, colocando-o num papel de ligao entre artefatos e requisitos, objetivando que a rastreabilidade com relao s necessidades originalmente mapeadas seja mantida. Trata-se ento de uma diferena sutil, que demanda ateno extra s tarefas que o compe. Com relao avaliao de impacto em solicitaes de mudanas ou correes de falhas, a definio similar ao proposto pelo CMMI.

3. A Questo da Rastreabilidade
Uma das exigncias comuns ao nvel G do MPS.BR e ao nvel 2 do CMMI a rastreabilidade entre um requisito e todos os artefatos envolvidos na implementao decorrente dele, conforme apresentado em [SEI, 2006] e [SOFTEX, 2007]. Esta prtica permite uma maior efetividade na gerncia de configurao, que visa justamente garantir que cada verso do software permita isolar uma verso compatvel dos componentes envolvidos em sua realizao, chamada baseline. Realizar esta tarefa sem uma referncia slida a quais telas ou componentes so afetados por determinado requisito, dificultaria a tarefa de isolar a verso, inviabilizando a gerao 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 mtodo, desde que este seja suficientemente relevante, tem-se uma opo se soluo: mapear casos de uso versus requisitos funcionais.

Por meio desta prtica possvel identificar no detalhe os artefatos que sero afetados cada vez que uma mudana realizada em um caso de uso especfico, bem como prover uma anlise de impacto mais eficaz antes de planejar uma tarefa. A elaborao de uma planilha descrevendo esta relao, em conjunto existncia de um documento padronizado para a elicitao de requisitos, onde seja possvel no apenas mapear as necessidades, mas tambm a interdependncia entre requisitos (sejam eles funcionais ou no) permite atender a todas as necessidades especificadas pelos modelos CMMI e MPS.BR, conforme descrito em seus documentos de referncia.

4. Artefatos para a Gerncia de Requisitos

Levando em conta os aspectos discutidos anteriormente, prope-se que a gerncia de requisitos seja atendida por meio da adoo de artefatos que reflitam tarefas consideradas padro de mercado, no que diz s atividades realizadas pelos envolvidos em sua realizao. Os documentos propostos so: Documento de Viso, Matriz de Rastreabilidade e Documento de Especificao de Caso de Uso, compatveis com o Rational Unified Process [RATIONAL, 2009], processo de engenharia de software que se baseia na definio de disciplinas para atribuio de tarefas e responsabilidades no desenvolvimento do software. Visando atender os modelos de referncia observados, necessrio que os artefatos possuam sesses especficas para mapeamento das relaes de dependncia 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 relao entre artefatos, usos e fases do ciclo de vida. Por meio deles, as cinco prticas especficas exigidas pelo CMMI so totalmente atendidas, bem como os cinco resultados esperados propostos melo MPS.BR. 5. Documento de Viso

Um documento relacionando as necessidades do usurio, seu entendimento por parte do analista de requisitos e o conjunto de requisitos (funcionais ou no) propostos para atender cada uma das necessidades mapeadas. Este documento validado pelos usurios e pode ser utilizado para definio do escopo inicial do projeto. Fases do Ciclo de Desenvolvimento em que empregado e atividades realizadas: Pr-Venda: Anlise do Problema, Definio de Requisitos de Negcio e Requisitos de Usurio, Definio de Requisitos Funcionais e Requisitos No Funcionais; Anlise e Design: Relao entre: Requisitos de Usurio e Requisitos de Negcio, Requisitos de Negcio e Requisitos No Funcionais, Requisitos de Usurio e Requisitos Funcionais.

Prticas Especficas do CMMI atendidas [SEI, 2006]: SP 1.1. Obter um entendimento dos requisitos;

SP 1.2. Obter aprovao 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 so aprovados utilizando critrios objetivos.

O Anexo I ilustra a representao de cada tipo de requisito e sua rastreabilidade com os demais. 6. Matriz de Rastreabilidade

Documento responsvel por estabelecer uma relao bidirecional entre os requisitos originais e os componentes do produto final (software). Caso um requisito no possua nenhum caso de uso equivalente mapeado na planilha, uma inconsistncia de projeto efetivamente localizada. Fases do Ciclo de Desenvolvimento em que empregado e atividades realizadas: Anlise e Design: Relao entre Casos de Uso e Requisitos Funcionais; Validao e Homologao: Possibilita o Rastreio e comparao entre uma implementao e a necessidade que a originou.

Prticas Especficas do CMMI atendidas [SEI, 2006]: SP 1.3. Gerenciar as mudanas de requisitos; SP 1.4. Manter rastreabilidade bidirecional entre os requisitos; SP 1.5. Identificar inconsistncias 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. Revises em planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir inconsistncias em relao aos requisitos; GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto.

O Anexo II ilustra a representao destas relaes na matriz de rastreabilidade. 7. Documento de Especificao de Caso de Uso

Alm 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 especificao da implementao que ser realizada pelos desenvolvedores, j com o foco nos artefatos que sero produzidos. Embora esteja muito mais relacionado rea de processo de definio de requisitos do que gerncia propriamente dita, sua realizao essencial construo da Matriz de Rastreabilidade, que vincula os casos de uso a seus requisitos.

Fases do Ciclo de Desenvolvimento em que empregado e atividades realizadas: Anlise de Design: Detalha a soluo para uma necessidade traduzida em requisito funcional e permite a validao da soluo proposta pelo Analista de Requisitos ou de Negcio.

Prticas Especficas 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.

O Anexo III ilustra os modelos de documentos para detalhamento de Casos de Uso para Telas e Relatrios, Procedimento, ou Anlise de Alterao.

8. Concluso e Trabalhos Futuros

Por meio da utilizao de trs artefatos de confeco relativamente simples Documento de Viso, Matriz de Rastreabilidade e Documento de Especificao de Caso de Uso - possvel atender a todas as exigncias estabelecidas rea de processo de Gerncia de Requisitos, de acordo com os modelos de referncia analisados. Porm, o nvel de interdependncia entre os documentos evidencia a necessidade de um processo eficiente para a definio dos requisitos, uma vez que uma falha nesta atividade resultar em um conjunto inconsistente de requisitos no documento de viso, refletidos em casos de uso que no traduzem a real expectativa do cliente. Estes casos de uso e requisitos sero relacionados na matriz de rastreabilidade e futuramente, quando forem recebidas solicitaes de mudanas 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 questo que se torna evidente a margem de falha humana, pois ao discutir a elaborao dos referidos artefatos sem a proposta de um pacote especializado de ferramentas surge a possibilidade de que determinado campo no seja preenchido, mesmo que de forma no intencional. Deste modo, cabe a cada empresa avaliar a relao entre custo e benefcio da adoo de meios automatizados para a construo e relacionamento dos documentos. interessante ressaltar tambm que o modelo MPS.BR prega compatibilidade com o CMMI e, no que diz respeito gerncia de requisitos, seus resultados esperados correspondem diretamente s prticas especficas impostas pelo modelo norteamericano, de modo que os artefatos propostos poderiam ser elaborados considerando apenas o CMMI como critrio de satisfao. Como trabalho futuro, sugere-se a extenso deste estudo rea de processos de definio de requisitos, bem como a utilizao de ferramentas de Gerao Eletrnica de Documentos (GED) para automao da construo dos artefatos propostos e tambm a validao dos artefatos contra outros modelos de referncia.

Referncias Bibliogrficas
[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 Edio. So Paulo: Pearson Addison Wesley, 2007. [SOFTEX, 2008] FAQ Implementao MR-MPS - Dvidas sobre o Guia Geral e Guia de Implementao. http://www.softex.br/mpsBr/_faq/faqImplementacao.asp. Recuperado em 01/12/2008. [SOFTEX, 2007] Associao para Promoo da Excelncia do Software Brasileiro SOFTEX. MPS.BR Guia Geral, Verso 1.2, junho 2007. [MEDEIROS, 2006] Medeiros, Ernani Sales de. Desenvolvimento de Software com UML 2.0: definitivo. So 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.

Anexo I Rastreabilidade no Documento de Viso

Figura 2 - Definio dos Requisitos de Negcio

Figura 3 - Relao entre Requisitos de Usurio e de Negcio

Figura 4 - Relao entre Requisitos Funcionais e de Usurio

Figura 5 - Relao entre Requisitos Funcionais e de Negcio

Figura 6 - Requisitos No Atendidos, Escopo Negativo ou No Escopo

Anexo II Matriz de Rastreabilidade

Figura 7 - Rastreabilidade entre Casos de Uso e Requisitos Funcionais

Anexo III Documentos de Caso de Uso

Figura 8 - Modelo para Caso de Uso de Tela ou Relatrio

Figura 9 - Modelo para Caso de Uso de Procedimento