Gerência de Requisitos

Transcrição

1 Gerência de Requisitos Miriam Sayão 1 e Karin Koogan Breitman 2 Abstract Requirements management is a fundamental activity to software development process. Requirements constitute the basis for system design, for implementation, for tests cases and for software validation. Requirements management process is related to control the whole development process using the requirements baseline as main reference. This process aims to maintain plans, artifacts and development activities in consistency with requirements defined for the software. This course discusses several aspects related to requirements changes control, to requirements version control, to traceability and to quality in requirements. Resumo Gerenciamento de Requisitos é uma das atividades fundamentais ao processo de desenvolvimento de software. Requisitos constituem a base para a definição da arquitetura do sistema, para a implementação propriamente dita, para geração dos casos de testes e para validação do sistema junto ao usuário. Gerenciamento de requisitos está relacionado ao processo de controlar todo o processo de desenvolvimento tendo como referência a baseline de requisitos. Este processo visa manter planos, artefatos e atividades de desenvolvimento consistentes com o conjunto de requisitos definidos para o software. Neste curso abordaremos aspectos relacionados ao controle de mudanças em requisitos, ao gerenciamento da configuração, à rastreabilidade e à qualidade em requisitos. 1 Faculdade de Informática da PUC-RS e DI/PUC-Rio; miriam@inf.puc-rio.br 2 Departamento de Informática da/puc-rio; karin@inf.puc-rio.br

2 1.1. Conceitos Básicos Nesta seção apresentamos os conceitos básicos relativos à disciplina de Engenharia de Requisitos e aos processos de Produção e Gerência de Requisitos. Iniciamos nossa discussão com a definição do termo Requisito. Segundo Dorfman e Thayer um requisito é definido como [Dorfman90]: Uma capacidade de software que o usuário necessita de modo a resolver um problema ou alcançar um objetivo Uma capacidade de software que deve ser disponibilizada por um sistema ou componente de sistema de modo a satisfazer um contrato, padrão, especificação ou outra formalidade imposta. Segundo Ian Sommerville requisitos são definidos nas fases inciais de um projeto e servem como especificação do que deve ser implementado. São descrições de como o sistema deve se comportar, de uma propriedade ou atributo do sistema. Um requisito pode descrever: Uma facilidade encontrada no nível do usuário Uma propriedade geral do sistema Uma restrição do sistema Uma restrição ao desenvolvimento do sistema Uma discussão freqüente na literatura de Engenharia de requisitos é a distinção entre o QUE e COMO. Alguns autores pregam que os requisitos devem descrever apenas o que sistema deve fazer (QUE) não se atendo aos detalhes de implementação (COMO). Alan Davis aponta que em muitos casos esta distinção é quase impossível de ser feita, pois dependendo do nível de detalhe da análise, o QUE de um processo pode servir de COMO para o refinamento do mesmo [Davis93] Tipos de Requisitos De modo geral os requisitos de software são classificados em três categorias: Requisitos funcionais São requisitos diretamente ligados à funcionalidade do software, o que o sistema deve prover. Suzanne e James Robertson definem requisitos funcionais como "uma ação que o produto deve ser capaz de realizar" [Robertson05] Exemplo: O sistema deve emitir um recibo após cada transação de compra. Requisitos não funcionais São requisitos que expressam restrições que o software deve atender ou qualidades específicas que o software deve ter. Suzanne e James Robertson definem requisitos não funcionais como "uma qualidade que o produto deve possuir." [Robertson05] Exemplo: O tempo de impressão de qualquer documento não deve exceder 1 minuto.

3 Requisitos inversos São requisitos que definem estados e situações que nunca devem ocorrer. Exemplo: O sistema não pode deixar que a temperatura da caldeira ultrapasse 100 o C. Independente do tipo do requisito, um aspecto fundamental é distinguir bons requisitos daqueles que apresentam riscos potenciais. Como sabemos se os requisitos do sistema foram capturados corretamente, estão bem escritos, livres de ambiguidade e completos? Na seção 1.5 discutiremos estes tópicos ao abordar qualidade dos requisitos e da especificação Engenharia de Requisitos A Engenharia de Requisitos (ER) é uma sub-área da Engenharia de Software que estuda o processo de produção e gerência dos requisitos que o software deverá atender. Este processo tem início junto aos clientes durante a fase de elicitação ou levantamento dos requisitos e perpassa todas as fases do processo de desenvolvimento do software. O objetivo da ER é fornecer métodos, técnicas e ferramentas que forneçam suporte adequado às tarefas de produção (elicitação, modelagem e análise) e gerência dos requisitos do sistema. A Engenharia de Requisitos foi estabelecida como disciplina independente em 1993, quando da criação do IEEE International Symposyum on Requirements Engineering (RE 93). A área tem crescido desde então. Atualmente temos a conferência internacional de requisitos RE (IEEE International Requirements Conference), que além dos artigos apresentados engloba uma serie de workshops com temas relacionados a requisitos e o WER, Workshop Engenharia de Requisitos (WER), criado em 1998 para atender ao público ibero-americano, já que aceita trabalhos em português e espanhol. Os artigos do WER estão disponibilizados na rede, através do site O Requirements Engineering Journal, publicado pela Springer Verlag London, é o periódico internacional dedicado à área de Engenharia de Requisitos. Klaus Pohl define a Engenharia de Requisitos da seguinte forma [Pohl93]: Engenharia de Requisitos pode ser definida como o processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constantemente verificada. Linda Macaulay discute a definição proposta por Pohl, que enfatiza as questões centrais da Engenharia de requisitos. Entre outras estão: Como este processo pode ser sistemático se tantos fatores são desconhecidos no início do processo de desenvolvimento de software?

4 Quantas interações serão necessárias para realmente verificar a acurácia das observações (esta questão está diretamente ligada ao processo de validação e verificação dos requisitos, ver seção 1.5 qualidade) Como sabemos que ja foram levantados requisitos suficientes? Os usuários devem ser incluídos no processo ou são meramente fontes de informação? Quantas e quais representações devem ser utilizadas na codificação dos requisitos? Quais padrões devem ser adotados e quais notações existentes podem ser adaptadatas para atender o processo de captura e codificação de requisitos? Qual o nível de precisão dos requisitos? Como sabemos que chegamos ao final do processo? Muitas destas perguntas ainda estão em aberto e estão sendo abordadas por pesquisadores de requisitos no mundo inteiro, o que contribui para um crescente interesse por parte de profissionais e pesquisadores em relação ao papel da Engenharia de Requisitos no processo de produção de software. Levantamentos recentes da comunidade européia bem como do Software Engineering Institute (SEI) nos Estados Unidos apontam para problemas relacionados à Engenharia de Requisitos como os mais importantes. Nos Estados Unidos a gerência de requisitos é vista como um dos principais problemas a serem superados para que as organizações cheguem ao nível 2 de maturidade segundo o modelo CMM (Capability Maturity Model) do SEI, sendo que o próprio SEI disponibilizou recentemente um pacote que ajuda a transferência de tecnologia em Engenharia de Requisitos para facilitar a certificação das empresas. No entanto ainda existe confusão entre os termos Engenharia e Gerência de Requisitos. A Engenharia de Requisitos, como mencionado acima, engloba os processos de produção e gerência de requisitos, como ilustrado na figura 1.1. Figura Engenharia de requisitos Produção de Requisitos

5 Segundo Ian Sommerville, um bom processo de produção de requisitos tem de levar em conta as seguintes etapas: elicitação, análise e negociação e validação [Sommerville97]. Este ponto de vista é compartilhado por Julio Cesar Sampaio do Prado Leite, pesquisador chefe da linha de Engenharia de Requisitos da PUC-Rio [Leite01a]. Para este pesquisador os processos essenciais à produção de requisitos são: elicitação, modelagem e análise (validação e verificação). Karl Wiegers inclui um quarto processo, especificação, que foca na documentação de informação relativa a rastreabilidade dos requisitos. Independente da organização dos processos, o fato é todos os enfoques levam em conta a captura (elicitação dos requisitos), registro (codificação, modelagem, utilizando-se algum tipo de representação persistente que garanta o acesso posterior aos requisitos e suas origens) e qualidade (validação e verificação de modo a garantir a acurácia das observações e informações levantadas durante o processo). Neste artigo vamos nos concentrar nos processo de gerência de requisitos Gerência de requisitos Durante o processo de desenvolvimento e operação de um sistema de software é natural o surgimento de novos requisitos e a necessidade de mudanças nos requisitos existentes. Este processo, também conhecido como evolução de sistemas, acontece como resultado de mudanças no meio ambiente onde o próprio sistema de software está inserido. Se o macrosistema muda os sistemas de software devem acompanhar esta mudança ou ficarão cada vez menos úteis [Lehman96]. O processo de mudança dos requisitos precisa ser controlado de modo a garantir a qualidade do sistema. O impacto destas mudanças precisa ser avaliado e compreendido de modo que sua implementação seja feita de maneira eficiente e a baixo custo. Este processo é conhecido como a gerência de requisitos, que pode ser definido da seguinte forma: Enfoque sistemático para a elicitação, organização e documentação dos requisitos do sistema e um processo que estabelece e mantém o acordo entre usuários e a equipe de projeto à medida que os requisitos se modificam [Leffingwell00]. Segundo Ian Sommerville, os principais aspectos ligados à gerência de requisitos são relacionados a: 1. Gerenciar as mudanças em requisitos existentes (pertencentes a especificação), 2. Gerenciar o relacionamento entre os requisitos, 3. Gerenciar as dependências entre o documento de requisitos e outros documentos produzidos durante o desenvolvimento de software. Para implementar uma gerência de requisitos eficaz é necessário, de antemão, definir um conjunto de políticas. É necessário definir um conjunto de objetivos para o processo de gerência. Estes objetivos devem ser claros e transmitidos para todos os integrantes da equipe. Todos os artefatos (documentos) produzidos durante o

6 desenvolvimento do software devem tornar a gerência dos requisitos visível e transparente. Estes documentos devem ser gerados levando-se em contas padrões externos e corporativos, de modo a assegurar consistência e uniformidade das informações. Políticas bem definidas para a gerência de configuração, controle de mudanças e rastreabilidade e garantia da qualidade precisam colocadas em prática de modo a viabilizar um processo dinâmico e eficaz de gerência de requisitos. Nas próximas seções vamos discutir os aspectos fundamentais de gerencia de requisitos. São eles: controle de mudanças, gerência da configuração, rastreabilidade e garantia da qualidade Controle de Mudanças Em um ambiente real de desenvolvimento de software mudanças são inevitáveis. Em muitos dos casos os requisitos do sistema mudam enquanto o sistema aida está sendo desenvolvido. As razões para mudanças são de vários tipos, entre outras: A complexidade dos sistemas impõe mudanças à medida que se adquire maior conhecimento sobre os mesmos, Requisitos errados ou mal definidos precisam ser corrigidos/ajustados ao longo do processo de desenvolvimento, Mudanças no ambiente: regras de negócios, leis, políticas internas, Desenvolvedores querem adicionar funcionalidades mais avançadas de modo a oferecer vantangem Tecnologia muda, Clientes mudam de idéia. A grande verdade é que no ambiente corporativo atual, sistemas de informação devem estar em constante evolução de modo a servir as necessidades de seus usuários. Este fenômeno é particular a sistemas de inforamação e foi observado inicialmente por Manny Lehman [Lehman96]. Este tipo de sistema, também conhecido como sistema do tipo E (evolutionary) se caracteriza por, uma vez instalado, tornar-se parte do meio ambiente e acabar alterando seus próprios requisitos. Sistemas do tipo E estão inseridos no mundo real, infinito e contínuo, o que determina a impossibilidade de se obter para os mesmos especificações exatas e completas. Os modelos de especificação de software que somos capazes de desenvolver são finitos (tempo finito para o desenvolvimento, memória finita para guardar, recursos limitados). Para agravar a situação, estes sistemas também devem levar em conta que o mundo real está em constante mudança de modo que algumas das hipóteses iniciais podem se tornar incorretas (sem que nos demos conta disto). Desta forma a atitude correta perante a gerência de requisitos é "preparar para mudar". Segundo Caper Jones os requistos de sofware se modificam, em média, na taxa de 2% ao mês durante as fases de projeto e codificação. Durante a fase de manutenção esta taxa pode aumentar. A mudança nos requisitos é comumente chamada de

7 volatilidade; parte das atividades da gerência de requisitos é controlar mudanças. O CMM define mudanças como: As alterações que precisam ser feitas nos requisitos e artefatos de software. É fudamental que as alterações dos requisitos sejam: Identificadas e avaliadas Avaliadas sob o ponto de vista de risco Documentadas Planejadas Comunicadas aos grupos e indivíduos envolvidos Acompanhadas até a finalização O ponto de vista do CMM é compartilhado por vários autores. Fundamental para garantir que o escopo do sistema é a manutençao de um processo de mudanças controlado. Um processo bem definido fornece aos interessados (clientes e desenvolvedores) um mecanismo formal de solicitação de mudanças nos requisitos de software. Este processo vai facilitar processos de tomada de decisão, gerência e controle de custos. O processo de controle de mudanças permite com que todas as mudanças sejam rastreadas e garante que nenhuma solicitação seja perdida ou deixada de lado. Este processo não deve ser encarado como obstáculo mas sim como um filtro que vai permitir uma gerência mais eficaz e transparente. É fundamental que este processo seja bem documentado e que faça uso de templates para solicitação de mudanças. Os templates garantem consistência e uniformidade nas solicitações, facilitam a manipulação e o armazenamento das informações em um formato único e compartilhado. A figura 1.2 ilustra um exemplo de template de solicitação de mudança. Templates para o registro de mudanças em requisitos devem conter, minimamente, informações relativas ao tipo de mudanças, à pessoa responsável pela solicitação, data e órgão de origem, e uma boa descrição da mudança em si. Idealmente também pode conter informações relativas à prioridade da mudança, em relação às diretivas do projeto e um cronograma que estabeleça a data desejada em que a mudança deveria ser implementada.

8 Não-Funcional Figura Exemplo de Registro de Solicitação de Mudança Para o gerente de requisitos o mais importante é estabelecer uma prática consistente para a mudança dos requisitos. Para tal é necessário estabelecer um processo de tratamento de mudanças. Este processo, que deve ser acordado com os membros da equipe de desenvolvimento e usuários, deve ser descrito de modo a deixar claro: Entradas - quais condições devem ser satisfeitas antes de se dar partida ao processo Tarefas - detalhar quais são as tarefas envolvidas neste processo, deixando claro quem será responsável pela sua execução e o formato em que os resultados devem ser comunicados Verificação - definir etapas onde os resultados obtidos são verificados de modo a garantir consistência e qualidade Saídas - definir um critério claro que indique que o processo chegou ao fim. Na figura 1.3 apresentamos um exemplo de processo de mudança de requisitos, proposto por Karl Wiegers.

9 Figura Processo de requisição de mudança em requisito, proposto por Wiegers.

10 1.3. Gerência da Configuração A Gerência de Configuração está comumente associada a dois tipos de tarefas: controle de versões e controle de configuração Controle de versões Por controle de versões entende-se as atividades associadas a manter, sob estrito acompanhamento, as diferentes versões de um artefato. Nas metodologias tradicionais de desenvolvimento, após clientes, usuários e equipe de desenvolvimento terem identificado e validado o conjunto de requisitos que será atendido pelo software, tem início as etapas que envolvem design, codificação, testes, etc. Mudanças em requisitos já registrados no documento de requisitos podem impactar na arquitetura proposta para o sistema, na organização de componentes, em casos de testes, em prazos e custos. Mudanças, portanto, devem ser rigorosamente controladas; o controle de versões possibilita manter a história de todas as diferentes versões dos artefatos, ao longo do ciclo de vida do sistema; isto inclui desde o levantamento inicial de informações, passa pelas atividades do processo de requisitos, e indo ainda além, durante as atividades de evolução. O controle de versões é fundamental para garantir que toda a equipe compartilha a mesma versão dos artefatos sendo trabalhados. Se isto não acontecesse, poderíamos ter a situação onde o conjunto de casos de teste sendo trabalhados pela equipe responsável pelos procedimentos de qualidade considera requisitos diferentes daqueles que estão em processo de implementação, ou mesmo já implementados. Se essa divergência entre o que foi implementado e o que vai ser testado não for identificada a tempo, os testes apontariam defeitos inexistentes, ou, no pior caso, deixariam de apontar defeitos presentes na implementação. Com o controle de versões, torna-se mais fácil garantir que todos os envolvidos no sistema em desenvolvimento compartilhem a mesma versão do documento de requisitos e dos demais artefatos utilizados durante as várias atividades associadas à criação do sistema. Quando o desenvolvimento do software é distribuído, ou terceirizado, o controle de versões torna-se mais crítico, sendo fundamental a utilização de uma ferramenta que auxilie esse trabalho. Muitas vezes a empresa contratante sofre pressões para a rápida liberação do software no mercado, para fazer frente à concorrência. A tendência é dividir o trabalho entre várias equipes, e não é incomum a situação onde uma equipe executa o processo de requisitos, passa os artefatos para uma segunda equipe efetuar projeto e implementação, enquanto uma terceira fica encarregada dos testes. Se mudanças nos artefatos de requisitos não forem comunicadas a todos os envolvidos, então a situação descrita acima tem probabilidade bastante alta de acontecer Controle da configuração do software Por controle de configuração entende-se as atividades associadas a manter, sob estrito acompanhamento, o conjunto de artefatos relacionadas a uma determinada configuração

11 do sistema. Um exemplo bastante comum é encontrado nas versões demo de muitos softwares comercializados: em relação à versão full, a versão demo possui restrições de funcionalidades, de período de utilização ou de quantidade de informações manipulada e/ou armazenada. Nestes casos, os requisitos da versão demo certamente possuem diferenças em relação aos requisitos da versão full - essas diferenças correspondem justamente às restrições colocadas pelo fabricante na versão para demonstração. Isto vale também para outros artefatos, pois essas restrições não se limitam ao conjunto de requisitos: elas podem implicar na arquitetura, nos componentes, nos casos de teste, etc. Gerencia de configuração, portanto, envolve manter controle sobre os diferentes artefatos e componentes que fazem parte de cada uma das diferentes configurações para o software em pauta. A figura 1.4 a seguir ilustra a situação onde, ao longo do tempo, foram sendo geradas diferentes revisões de uma mesma versão do software (a revisão 1.0 após a primeira alteração passou a ser denominada de 1.1, que por sua vez depois de alterada passou a ser denominada de 1.2 e assim por diante). Na mesma figura também podem ser visualizadas as revisões de outra configuração ou variante do mesmo software; revisões estas geradas a partir da revisão 1.1 da configuração principal. Todos os artefatos que correspondem a uma versão (ou revisão) devem ser consistentes uns com os outros, ou seja, todos devem refletir o mesmo conjunto de requisitos. variante configuração principal Figura diferentes revisões e configurações de um software Ferramentas para controle de versões e gerência de configuração O mercado disponibiliza diversas ferramentas que podem ser utilizadas tanto para controle de versões como para gerência de configuração. Visual SourceSafe, CVS e ClearQuest são algumas das ferramentas disponíveis com estas finalidades. Uma das mais utilizadas é o CVS - Concurrent Version System, licenciado na forma de software livre. Iremos relacionar algumas das características deste software, que são também encontradas em outras ferramentas que possuem o mesmo propósito. O CVS utiliza o conceito de repositórios para armazenamento e controle de versões de arquivos. Os diretórios que compõem a estrutura dos arquivos depositados no repositório são chamados de módulos; muitos comandos de CVS referem-se a módulos ao invés de arquivos. O administrador (gerente do projeto, por exemplo), cria o repositório e define os usuários que poderão ter acesso aos arquivos nele armazenados. É possível restringir os direitos de acesso dos usuários aos arquivos controlados. As operações de check in e check out possibilitam ao desenvolvedor executar a "retirada"

12 de um arquivo (ou de um conjunto de arquivos) para o seu próprio diretório de trabalho, fazer as modificações necessárias e recolocar os componentes modificados sob o gerenciamento do controlador de versões. O controlador, por sua vez, mantém controle sobre estas operações, verificando e informando ao usuário se alguma outra operação de modificação foi executada sobre o mesmo componente. Ferramentas deste tipo costumam trabalhar com estruturas de diretórios para o armazenamento das diferentes configurações do software sendo gerenciado; isto facilita a co-existência de diferentes configurações para um mesmo software. O espaço para armazenamento é otimizado, pois a cada nova versão, apenas as diferenças em relação à anterior são armazenadas - o CVS se encarrega de fazer a identificação das diferenças entre uma versão ou revisão e a sua anterior Rastreabilidade 3 A rastreabilidade de requisitos é uma das atividades preconizadas pelos modelos de qualidade como CMM, CMMI, MPS-BR ou ISO Na visão mais simples, rastreabilidade pode ser encarada como o conjunto de ligações entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefatos como componentes e casos de teste. Por fontes dos requisitos consideramos tanto o cliente ou usuário que trouxe uma necessidade, como documentos da organização, padrões a serem seguidos e também legislação pertinente. As ligações existem nos dois sentidos, como podemos visualizar na figura 1.5 a seguir. necessidades dos clientes e documentos pré-rastreabilidade requisitos pós-rastreabilidade artefatos de design e implementação Fig. 1.5 Rastreabilidade de Requisitos As ligações denominadas de pré-rastreabilidade são aquelas relacionadas ao contexto do qual emergem os requisitos; as ligações denominadas de pós-rastreabilidade são relacionadas diretamente ao contexto técnico do processo de desenvolvimento. As ligações associadas à pré-rastreabilidade permitem identificar a origem de cada requisito e também quais os requisitos originados de uma determinada fonte (por exemplo, os requisitos originados de padrões organizacionais). As ligações associadas à pósrastreabilidade permitem identificar quais componentes (e casos de teste, por exemplo) implementam um determinado requisito, e também possibilitam saber claramente, dado um componente (ou outro artefato), quais os requisitos que ele deve atender. Outra forma de rastreabilidade associa requisitos de alto nível aos requisitos dele derivados. Requisitos de alto nível geralmente correspondem ao que Sommerville denomina de requisitos do usuário: declarações em linguagem natural ou diagramas, sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar. 3 parte do texto sobre rastreabilidade foi originalmente publicada em [Sayão05]

13 Estes requisitos, escritos para os clientes e usuários, remetem a funcionalidades de alto nível. Já os requisitos de sistema, que são a base para o contrato entre cliente e equipe de desenvolvimento, estabelecem detalhadamente as restrições que o sistema deverá atender; são descrições mais detalhadas dos requisitos do usuário e servem de ponto de partida para o projeto do sistema. A figura 1.6 a seguir ilustra os conceitos associados a este tipo de ligação; os requisitos nela relacionados foram apresentados num exemplo de [Sommerville04]. Requisito do usuário 1. O software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas Requisitos de sistema 1.1. o usuário deve dispor de recursos para definir o tipo dos arquivos externos 1.2. cada tipo de arquivo externo pode ter uma ferramenta associada 1.3. cada tipo de arquivo externo pode ser representado por um ícone específico na tela do usuário 1.4. quando um usuário seleciona um arquivo externo, a ferramenta associada é ativada (para manipular adequadamente esse arquivo) Figura Ligações de rastreabilidade entre requisitos Impactos da rastreabilidade num projeto de desenvolvimento de software A rastreabilidade pode auxiliar gerentes e desenvolvedores em várias situações comuns ao desenvolvimento de software; a seguir apresentamos algumas destas situações visando mostrar o papel desempenhado pela rastreabilidade: verificação da alocação de requisitos a componentes do software: a avaliação dos elos de rastreabilidade de requisitos a artefatos de desenho e implementação identifica requisitos ainda não alocados ou implementados; verificação e validação: no processo de verificação, a avaliação das ligações entre requisitos e casos de teste possibilita localizar requisitos para os quais não foram criados procedimentos de teste. No processo de validação do software junto ao cliente, as ligações entre requisitos e componentes auxiliam a mostrar ao cliente que todos os requisitos foram atendidos pelo software desenvolvido; análise de impacto: quando uma solicitação de mudança é aceita pelo gerente do projeto, as ligações entre requisitos e componentes permitem a rápida identificação daqueles que deverão ser modificados. Isto auxilia o gerente no processo de revisão do cronograma de desenvolvimento e dos custos previstos para o software;

14 gerenciamento de riscos: a análise de riscos de um projeto inclui a identificação de riscos associados a custos e cronograma e de fatores contextuais que possam impactar em requisitos (restrições legais, por exemplo). A rastreabilidade apóia a identificação de artefatos atingidos por cada fator de risco, possibilitando a elaboração de estratégias para tratamento ou mitigação dos riscos Tipos de elos de rastreabilidade Em seu artigo sobre rastreabilidade [Ramesh01], Ramesh&Jarke propõem um metamodelo para a rastreabilidade que possibilita a captura de informações relacionadas a agentes, fontes e objetos - as três dimensões dos modelos de rastreabilidade. Nesse meta-modelo os stakeholders são ligados através de estruturas de contribuição [Gotel94] aos objetos conceituais que eles influenciam e a documentos onde tais objetos são registrados [Jarke98]. A Figura 1.7, adaptada de [Jarke98], apresenta a visão geral desse meta-modelo; note que são apresentados objetos (relacionados ao produto sendo elaborado) e artefatos que são gerados pelo próprio processo de desenvolvimento. As três dimensões consideradas correspondem a: a) Fontes: documentos que remetem à origem dos requisitos (normas, padrões, legislação pertinente, atas de reuniões,...); b) Stakeholders: são as pessoas envolvidas no Processo de Requisitos e que também possuem algum grau de interesse na rastreabilidade; c) Objetos ou artefatos: correspondem a objetos conceituais relacionados ao produto ou a artefatos gerados pelo processo de desenvolvimento. Fig. 1.7 Meta-modelo para a rastreabilidade de requisitos [Jarke98] Ramesh&Jarke ponderam que mesmo existindo uma grande variedade de elos de rastreabilidade, eles podem ser agrupados em duas categorias básicas: a) relacionados ao produto: elos que descrevem propriedades e relacionamentos dos objetos; são subdivididos em elos de satisfação e elos de dependência;

15 b) relacionados ao processo: elos relacionados ao histórico de ações executadas no próprio processo; são subdivididos em elos de evolução e elos de rationale. O propósito dos elos de satisfação é assegurar que os requisitos sejam atendidos pelo sistema, ou seja, a cada requisito foi associado um componente que deverá atendêlo. Este tipo de link é utilizado para registrar os desenhos criados para satisfazer requisitos e os componentes para os quais requisitos são alocados, para assegurar que todo componente satisfaz a requisitos, registrar fatores críticos de sucesso associados a requisitos e assegurar consistência entre saídas das diferentes fases do ciclo de vida. O propósito dos elos de evolução é registrar relacionamentos que levam de objetos existentes para objetos novos ou modificados. Este tipo de elo é útil para identificar as origens dos objetos, para melhor compreensão dos requisitos e outros objetos (através de sua história) e para registrar as modificações e histórico de refinamentos dos vários objetos. O propósito dos elos de rationale é representar as motivações subjacentes aos objetos existentes ou documentar as razões para evolução. Estes elos são utilizados para encontrar as justificativas para criação ou modificação de objetos, registrar suposições utilizadas no processo de decisão e identificar o contexto de criação de objetos. Estes elos possibilitam registrar aspectos do processo decisório, incluindo alternativas descartadas, de forma a providenciar clara compreensão da solução escolhida, facilitando a manutenção e o reuso. Em outras palavras, os elos de rationale auxiliam a gerenciar o desenvolvimento do sistema de acordo com as necessidades e objetivos organizacionais. Estes elos representam a área de atuação dos interessados, registrando as origens e o contexto no qual os objetos são desenvolvidos. E finalmente, os elos de dependência têm por propósito apoiar o gerenciamento de dependências entre requisitos ou objetos, sendo úteis para registrar a composição e hierarquia dos requisitos e apoiar o gerenciamento do impacto das alterações num requisito sobre os objetos que dele dependem Rastreabilidade de requisitos: prática Problemas relacionados ao registro e uso da rastreabilidade não são recentes: a literatura aponta para dificuldades ou problemas na prática da rastreabilidade [Gotel94a] [Ramesh01] [Zowghi01] [Damian03]. Mesmo em empresas certificadas por modelos de qualidade esta dificuldade é encontrada: Linscomb [Linscomb03] registra que nunca encontrou empresas certificadas ao nível 2 do CMM onde fossem trabalhadas matrizes de rastreabilidade completas, indicando que cada requisito foi atendido por artefatos de design, implementação e testes. Acreditamos que estes problemas acontecem, em parte, pela inadequação das ferramentas disponíveis, e em parte devido às pressões relacionadas a prazos para liberação do software no mercado. Além, é claro, da já conhecida falta de cuidado dos desenvolvedores com a documentação do processo de desenvolvimento.

16 1.4.4 Registro da rastreabilidade Ferramentas disponíveis comercialmente para o gerenciamento de requisitos utilizam matrizes de rastreabilidade como as visualizadas nas tabelas 1.1 e 1.2. A matriz de rastreabilidade pode ser implementada com uso de uma ferramenta de uso geral, como um editor de textos ou uma planilha eletrônica (muitas das ferramentas comercialmente disponíveis para a fase de requisitos utilizam alguma forma de matriz de rastreabilidade). A Tabela 1.1 apresenta um modelo simplificado de matriz de rastreabilidade. Tabela Rastreabilidade entre requisitos e entidades geradas no processo de desenvolvimento Requisito Projeto <nome_projeto> - Matriz de Rastreabilidade Documento fonte Arquitetura Componente Caso de teste No exemplo da Tabela 1.1, a primeira coluna da matriz deverá ser preenchida com os requisitos, normalmente expressos em linguagem natural e numerados seqüencialmente. As demais colunas devem representar artefatos gerados durante o processo de desenvolvimento; a correspondência nem sempre é da ordem de um para um (por exemplo, um requisito pode estar sendo verificado em diversos casos de teste, e vice-versa). Já a tabela 1.2 mostra dependências entre requisitos funcionais e não funcionais; um exemplo bastante comum para sistemas de comércio eletrônico associa requisitos não-funcionais como segurança a requisitos funcionais relacionados às transações disponíveis ao usuário do sistema. Tabela Rastreabilidade entre requisitos funcionais e não funcionais RF01 RF02 RF03 RF04 Projeto <nome_projeto> - Rastreabilidade RF versus RNF Requisito Funcional Requisito Não-Funcional NFR01 NFR02 NFR03 NFR04 NFR05 NFR06 Entre as ferramentas comerciais disponíveis, citamos a suite da IBM/Rational, que inclui o RequisitePro (centrado em documentos e utilizando matriz de rastreabilidade) para o Processo de Requisitos e outras ferramentas como o

17 AnalystStudio para o gerenciamento de requisitos. Da mesma forma, DOORS (centrado em documentos e utilizando hiperlinks para rastreabilidade) apóia tarefas relacionadas ao gerenciamento de requisitos. Registramos que RequisitePro propicia também o registro do rationale subjacente aos requisitos e sua evolução e a hierarquia entre requisitos de alto nível aos seus derivados, e que DOORS associado ao toolkit ScenarioPlus possibilita elos entre requisitos e casos de uso, em múltiplas versões, para diferentes configurações de um mesmo sistema. A figura 1.8 apresenta um exemplo de matriz de rastreabilidade, conforme registrada no RequisitePro. Fig. 1.8 Matriz de rastreabilidade entre requisitos funcionais e nãofuncionais, no RequisitePro O INCOSE, International Council on Systems Engineering, mantém uma página, periodicamente atualizada, com informações sobre as ferramentas para apoio ao registro da rastreabilidade (veja em /products/setools/tooltax/reqtrace_tools.html). Outra página, mantida pela mesma organização, apresenta um resumo sobre essas ferramentas, com informações fornecidas pelos fabricantes ( Definindo um modelo de rastreabilidade para um projeto A captura e uso dos elos de rastreabilidade devem ser adaptados às necessidades específicas de cada projeto, possibilitando uma relação custo-benefício positiva e evitando uma massa excessiva de informações relacionadas à rastreabilidade [Dömges98][Ramesh01]. A definição dos elos a serem capturados deve considerar prazos e custos do projeto em pauta, além de processos e padrões em uso na organização. Propomos a seguir, apoiados pela nossa experiência, algumas heurísticas que podem auxiliar gerente de projeto e equipe na tarefa de definir um modelo de rastreabilidade para o processo de desenvolvimento de um software específico:

18 a) definir no início do projeto, considerando a aplicação a ser desenvolvida, os tipos de elo a serem utilizados e explicitamente registrados; b) identificar as ferramentas que apoiarão o processo de rastreabilidade; c) conscientizar a equipe da importância do processo de rastreabilidade (considere que desenvolvedores não são exatamente conhecidos por seu amor à documentação [Jarke98] e que a falta de comprometimento da organização com a atividade de rastreabilidade é responsável pela falta de interesse de seus desenvolvedores nessa tarefa [Ramesh98]); d) estabelecer as entidades (artefatos, componentes, objetos, requisitos) a serem rastreadas e os pontos onde o registro deverá ser realizado; e) durante o processo de desenvolvimento, verificar se os elos de rastreabilidade estão sendo registrados pela equipe; f) utilizar e avaliar o mecanismo de extração de elos, em relação às expectativas realizadas; g) após a liberação do software, analisar criticamente com a equipe a efetividade do modelo de rastreabilidade adotado, corrigindo possíveis distorções e melhorando-o para os próximos projetos Gerência da Qualidade de Requisitos O objetivo da gerência de qualidade de requisitos é garantir que uma base de requsitos composta essencialmente de bons requisitos. Existe uma vasta literatura sobre o que torna um requisito bom, que pode ser resumida através dos seguintes critérios [Young01, Wiegers99]: Necessidade Verificável Atingível Livre de Ambiguidades Completo Consistente Rastreável Alocação Concisão Livre de Implementação Identificador único Correção Priorizável O sistema é capaz de atingir seus objetivos sem este requisito? Caso afirmativo este é um requisito desnecessário É possível verificar que este requisito está sendo atendido pelo sistema? O requisito pode ser atendido pelo sistema que está sendo desenvolvido? O requisito possui mais de uma interpretação possível? O documento de especificação do sistema contém todos os requisitos? Todos os requisitos podem ser atendedidos sem que se entre em conflito uns com os outros? A origem dos requisitos é conhecida? O requisito pode ser referenciado e localizado no sistema? O requisito pode ser alocado a um elemento ou componente do sistema? O requisito está descrito de forma simples e concisa? O requisito descreve o QUE deve ser feito sem influências de possíveis implementações? Cada requisito possui um identificador único que permita com que possamos referenciá-lo de forma única e precisa? O requisito contém toda a informação necessária que permita sua implementação? O requisito é passível de ser priorizado frente aos outros requisitos? Tabela Critérios de avaliação da qualidade de requisitos

19 Segundo o CMM, uma das atividades da área de processo chave, gerência de requisitos é a revisão dos requisitos antes antes de incorporá-los ao projeto. É necessário: Identificar requisitos incompletos ou ausentes Determinar se os requisitos estão claros, possíveis de serem implementados, consistentes e verificáveis Revisar requisitos com problemas potenciais Negociar compromissos com os grupos envolvidos A maior parte dos requisitos de software para sistemas de informação são escritos utilizando-se linguagem natural. Esta falta de formalidade na captura dos requisitos implica em uma série de potenciais problemas. Os problemas mais comuns são: Ambiguidade Falta de clareza ou duplo sentido de frases ou expressões. Este tipo de requisito leva a interpretações erradas ou inconsistentes das necessidades reais dos usuários. Exemplo: O sistema deve enviar relatórios de produtividade dos programadores, analistas ou desenvolvedores do projeto mensalmente ou quando requisitado. Neste caso fica difícil dizer se o usuário quer que seja enviado um ou três relatórios. A frequência de envio também não está clara. Se um relatório for enviado em resposta a uma solicitação, a necessidade de envio do relatório mensal permanece? Requisitos Incompletos Requisitos que deixam de fora parte da informação necessária à sua compreensão. Exemplos: Curva S (Planejado X Realizado) de um projeto Cadastro de iniciativas estratégicas Neste caso é difícil dizer se o sistema deve plotar a curva S, importar ou só exibir a figura. O mesmo pode ser dito do cadastro. O sistema é responsável por realizar o cadastro (adição, remoção e atualização), importá-lo de outro banco de dados ou apenas exibir? Requisitos Múltiplos Estes são requisitos que concatenam vários requisitos em um só. Estes requisitos devem ser separados para facilitar a tarefa de priorização e gerência de mudanças. Exemplo:

20 No evento de falha da rede elétrica, o sistema deve enviar mensagem de erro ao usuário, salvar a configuração atual do sistema e os dados entrados, até então. Neste caso podemos dividir este requisito em dois: envio de mensagem de erro e salvar a configuração do sistema. Perceba que os requisitos têm prioridades diferentes. Claro que salvar a configuração do sistema é muito mais importante em caso de falha do que avisar o usuário, que caso a rede elétrica esteja em pane já deve ter percebido o fato sozinho. Requisitos com alternativas São aqueles requisitos que não estabelecem claramente qual deve ser a ação do sistema frente a uma dada situação. De modo geral contém frases do tipo mas, com exceção, apesar, e quando. Exemplo: O sistema deve mostrar o total do pedido à medida que os códigos dos produtos vão sendo entrados no pedido, a não ser que se trate de um produto promocional. Neste caso o requisito apresenta o procedimento para duas situações diferentes e não é claro qual seria o procedimento para produtos promocionais. A solução seria quebrar este requisito em dois, cada um tratando de uma situação distinta. Requisitos mal escritos São requisitos mal redigidos que podem causar confusão e mal entendidos. Um erro muito comum é o excesso de informação Exemplos: Na improvável eventualidade de falha no sistema de refrigeração, o sistema deve mandar mensagem para a chave admin. Identificar e associar as intervenções que são complementares às outras Neste caso fica difícil até entender o requisito. A primeira sentença oferece informação relativa ao ambiente que é completamente desnecessária para o sistema. No segundo caso fica difícil entender o que o sistema deve fazer. Requisitos Inverificáveis É de conhecimento comum a gerentes de projeto a máxima "você não pode gerenciar o que não pode medir". Um requisito inverificável é escrito de modo que fica impossível de assegurar que o sistema é capaz de atênde-lo. Exemplos: O sistema X deve ser seguro O sistema C deve processar depósitos rapidamente