Alcançar a competitividade pela qualidade implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Em vista disto, a qualidade se torna fator crítico de sucesso para as empresas de software que visam à oferta de produtos de software e serviços conforme padrões internacionais de qualidade (SOFTEX, 2012).
Desta forma, foi criado em dezembro de 2003 o programa MPS.BR (Melhoria de Processo de Software Brasileiro) que tem como meta definir e aprimorar um modelo de melhoria e avaliação
de processo de software e serviços, visando preferencialmente às micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e ser reconhecido como um modelo aplicável à indústria de software e serviços (SOFTEX, 2012).
O programa MPS.BR está dividido em quatro componentes: o Modelo de Referência MPS para Software (MR-MPS-SW), o Modelo de Referência MPS para Serviços (MR-MPS-SV), o Método de Avaliação (MA-MPS) e o Modelo de Negócio (MN-MPS) (SOFTEX, 2012). O MR- MPS-SW contém as definições dos níveis de maturidade, processos e atributos do processo para desenvolvimento de software e está em conformidade com os requisitos de modelos de referência de processo da Norma Internacional ISO/IEC 15504-2 (SOFTEX, 2012).
O MR-MPS-SW define sete níveis de maturidade: G (Parcialmente Gerenciado), F (Gerenciado), E (Parcialmente Definido), D (Largamente Definido), C (Definido), B (Gerenciado Quantitativamente) e A (Em Otimização). Para cada um destes níveis, é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria (SOFTEX, 2012).
O nível G de maturidade é o primeiro nível descrito pelo modelo de referência de software (MR-MPS-SW) e é composto pelos processos Gerência de Projetos (GPR) e Gerência de Requisitos (GRE). Sua implementação deve ser executada com cautela por estabelecer o início dos trabalhos em uma implementação de melhoria dos processos na organização. Esta cautela se deve pelo fato de envolver uma mudança cultural na organização e a definição do conceito acerca do que é projeto para a organização (SOFTEX, 2011).
É no nível G que a gerência de requisitos (GRE) começa a ser definida e tem como propósito gerenciar os requisitos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Tem como principal objetivo controlar a evolução dos requisitos (SOFTEX, 2011). Outras atribuições desse processo são documentar as mudanças nos requisitos e suas justificativas, manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho em geral e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2011).
Para aumentar as chances de sucesso e assegurar um bom entendimento das necessidades do cliente e dos requisitos do projeto é fundamental uma boa comunicação com os fornecedores de requisitos, que podem ser os responsáveis pelo produto ou até mesmo o próprio cliente. Essa
comunicação deve tratar de assuntos como: definição e aprovação de requisitos e solicitação de mudanças nos requisitos, dentre outros (SOFTEX, 2011). A gerência de requisitos envolve então identificar os requisitos do produto e dos componentes do produto do projeto estabelecendo e mantendo um acordo entre o cliente e a equipe de projeto sobre esses requisitos. Tem também por objetivo controlar e tratar as mudanças nos requisitos ao longo do desenvolvimento (SOFTEX, 2011).
Para apoiar o processo de mudança de requisito, é fundamental definir e manter a rastreabilidade dos requisitos. Quando os requisitos são bem gerenciados, a rastreabilidade pode ser estabelecida, desde um requisito fonte até seus requisitos de mais baixo nível e destes até o seu requisito fonte. Esta rastreabilidade bidirecional ajuda a determinar se todos os requisitos fonte foram completamente tratados e se todos os requisitos de mais baixo nível podem ser rastreados para uma fonte válida (SEI, 2010).
Com isso, o responsável pela gerência de requisitos é capaz de negociar com o cliente e fornecedores de requisitos, alterações nos planos do projeto para atender às solicitações de mudanças de requisitos e, ao mesmo tempo, minimizar os riscos do projeto, como por exemplo, desvios de cronograma e de custos (SILVEIRA, 2012).
Diferentemente do processo de Gerência do Projeto (GPR), que possui uma característica evolutiva, todos os resultados esperados são requisitos obrigatórios para o alcance do nível de maturidade G. Esse processo é requisito obrigatório para a progressão aos demais níveis de maturidade (SOFTEX, 2011).
As atividades relacionadas à gerência de requisitos no MPS.BR são descritas no processo GRE do nível G através de cinco resultados esperados (GRE1 à GRE5), conforme será visto a seguir.
2.2.1 GRE1
A fim de serem evitados problemas futuros, critérios são estabelecidos para designar canais apropriados ou fontes oficiais que serão responsáveis pelos requisitos (SEI, 2010). Este resultado tem como objetivo garantir que os requisitos obtidos junto aos fornecedores de requisitos estejam bem entendidos e definidos (SOFTEX, 2011). A comunicação com os fornecedores de requisitos
deve ser registrada formalmente através de atas, e-mails, ferramentas de comunicação ou outros meios (SOFTEX, 2011).
A documentação dos requisitos pode assumir diferentes formas de acordo com a necessidade da organização como, por exemplo, uma lista de requisitos, especificações de casos de uso, especificações de estórias, ou ainda detalhados conforme uma metodologia própria da empresa. Esta documentação é feita como comprovação do entendimento dos requisitos (SOFTEX, 2011).
Para garantir que os requisitos propostos atendam às necessidades e expectativas do cliente e dos usuários, é feita uma avaliação dos requisitos e um registro de aceite dos mesmos deve ser obtido pelos fornecedores de requisitos, como sendo um marco do projeto, onde mudanças nos requisitos devem ser tratadas formalmente minimizando assim o impacto dessas alterações no escopo, estimativas, cronograma e compromissos já estabelecidos no projeto (SOFTEX, 2011).
2.2.2 GRE2
Visto que o resultado anterior tratou de alcançar uma compreensão com os fornecedores de requisitos, este resultado trata dos acordos e dos compromissos entre aqueles que têm que realizar as atividades necessárias para implementar os requisitos (SEI, 2010). Este resultado tem como objetivo avaliar os requisitos com base em critérios objetivos e obter um comprometimento de todos os envolvidos diretamente no desenvolvimento do produto. A avaliação e aprovação dos requisitos não deve ser somente por parte do cliente, mas deve envolver também a equipe técnica, por exemplo, analistas de sistemas, desenvolvedores e projetistas que estão envolvidos diretamente no desenvolvimento do produto. Além disso, um comprometimento formal da equipe com os requisitos deve ser obtido e registrado na forma de ata de reunião, e-mail ou algum outro mecanismo (SOFTEX, 2011).
Quando os requisitos mudam, este resultado assegura que os participantes do projeto estejam comprometidos com os atuais requisitos aprovados e com as mudanças necessárias nos planos de projeto, atividades e produtos de trabalho (SEI, 2010).
A avaliação dos requisitos identificados pode ser feita com base em um conjunto de critérios objetivos previamente estabelecidos como por exemplo: possuir identificação única; estar claro e apropriadamente declarado; não ser ambíguo; ser relevante; ser completo; estar consistente com os
demais requisitos; ser implementável, testável e rastreável (IEEE, 1998 apud SOFTEX, 2011). Para favorecer a identificação dos problemas mais frequentes em relação à especificação de requisitos, o uso de um checklist para apoiar esta atividade pode ser útil. Nem todos os envolvidos com o desenvolvimento do produto precisam participar efetivamente na avaliação dos requisitos com base em critérios estabelecidos mas é importante que haja comprometimento de todos para que diminua o risco de os requisitos não terem sido perfeitamente entendidos por todos (SOFTEX, 2011).
Uma prática muito comum que algumas empresas tem realizado para satisfazerem este resultado é a realização de reuniões de kick off na qual se apresenta o projeto como um todo, incluindo os requisitos, permitindo que as diversas partes envolvidas possam opinar, aprovar e se comprometer com os requisitos. Caso haja alguma mudança de requisitos aprovada pelos fornecedores de requisitos e para não afetar compromissos já estabelecidos, é necessário obter um novo comprometimento da equipe técnica com os requisitos modificados (SOFTEX, 2011).
2.2.3 GRE3
Este resultado indica a necessidade de se estabelecer um mecanismo para rastrear a dependência entre os requisitos e os produtos de trabalho. A definição da rastreabilidade visa facilitar a avaliação do impacto das mudanças de requisitos que venham a ocorrer no decorrer do desenvolvimento do produto. Essas mudanças podem ocorrer nas estimativas do escopo, nos produtos de trabalho ou nas tarefas do projeto descritas no cronograma (SOFTEX, 2011).
Com o desenvolvimento do projeto, os requisitos assumem diferentes abstrações e denominações. Por exemplo, podem estar descritos como necessidades e restrições do cliente, requisitos do cliente, casos de uso, requisitos funcionais e não-funcionais, estórias, entre outros. Em geral, o detalhamento dos requisitos, a transformação em modelos, a codificação e o planejamento e a execução de testes são planejados para garantir a correta execução do projeto, tendo tarefas documentadas em um plano do processo para o projeto ou em um cronograma, conforme previsto pelo processo Gerência de Projeto (GPR) (SOFTEX, 2011).
Assim, a existência de rastreabilidade bidirecional, pressupõe que diferentes abstrações dos requisitos (requisitos de cliente ou casos de uso), documentos relacionados (cronogramas e casos de testes) e código fonte sejam rastreáveis entre si (SOFTEX, 2011). A rastreabilidade bidirecional
ajuda a determinar se todos os requisitos de origem foram tratados e se todos os níveis dos requisitos podem ser rastreados até um requisito de origem válido (SEI, 2010).Para as empresas de desenvolvimento de software, essa rastreabilidade envolve o rastreio das especificações recebidas em relação aos produtos produzidos pela própria empresa (SOFTEX, 2011). A rastreabilidade é particularmente necessária na condução da avaliação de impacto das mudanças de requisitos nas atividades do projeto, e nos produtos de trabalho (SEI, 2010).
Este resultado, apesar de estabelecer a criação de um sistema de rastreamento, não envolve necessariamente a criação de uma matriz de rastreabilidade específica para o atendimento do resultado esperado. Contudo, deve existir um mecanismo que possibilite o rastreamento bidirecional entre os requisitos e os demais produtos de trabalho (SOFTEX, 2011).
2.2.4 GRE4
O objetivo deste resultado sugere revisar planos e produtos de trabalho do projeto para identificar e corrigir inconsistências em relação aos requisitos (SOFTEX, 2011). Esta prática específica encontra inconsistências entre requisitos, planos de projeto e produtos de trabalho e inicia uma ação corretiva para corrigi-las (SEI, 2010). A realização de revisões ou de algum mecanismo para identificar inconsistências entre os requisitos e os demais elementos do projeto devem ser atendidas neste processo (SOFTEX, 2011).
Ao longo do projeto é responsabilidade da empresa e do cliente realizarem revisões visando garantir a consistência entre os requisitos e os produtos de trabalho do projeto. Alguns exemplos de revisões com esse objetivo são revisões de monitoração e controle do projeto e inspeções baseadas em critérios para identificar inconsistências entre os planos, atividades e produtos de trabalho com os requisitos e com mudanças nesses requisitos (SOFTEX, 2011).
Quando ocorrem mudanças nos requisitos, é importante revisar se os demais elementos estão consistentes com as alterações realizadas. Pode-se verificar, por exemplo, se a planilha de estimativas contempla todos os requisitos e mudanças, verificar se essas mudanças foram incorporadas ao escopo ou cronograma do projeto, entre outras coisas. É importante que as ações para correções das inconsistências sejam acompanhadas até serem resolvidas (SOFTEX, 2011).
2.2.5 GRE5
Este resultado define que, ao longo do projeto, as mudanças nos requisitos devem ser gerenciadas (SOFTEX, 2011). À medida que as necessidades mudam e que o trabalho prossegue, requisitos adicionais ou imprevistos podem ser incorporados ao projeto e/ou mudanças podem ser feitas nos requisitos já existentes (SEI, 2010).
Ao se iniciar um conjunto de pedidos de mudança por parte dos usuários, gerentes ou clientes, o custo e o impacto devem ser analisados para se verificar quanto do sistema será afetado pela alteração e quanto poderá custar para desenvolver esta mudança (SOMMERVILLE, 2007).
As mudanças nos requisitos devem ser registradas e um histórico das decisões tomadas sobre os requisitos devem estar disponível. Estas decisões são tomadas através da realização de análises de impacto da mudança no projeto com a ajuda de mecanismos de rastreio e podem incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo (SOFTEX, 2011). Para analisar o impacto das mudanças, é necessário que a fonte de cada requisito seja conhecida e que o fundamento lógico de qualquer mudança seja documentado (SEI, 2010).
Muitas vezes é necessário que a organização determine a aplicabilidade da gerência de mudança, visto que as mudanças nos projetos acontecem em diferentes níveis de abstração dos requisitos e não apenas nos requisitos do cliente (SOFTEX, 2011).