Gerência de Requisitos
Miriam Sayão1 e Karin Koogan Breitman2
Abstract
Requirements management is a fundamental activity to software development and evolution. Requirements constitute the basis for system design, implementation, test and validation. The requirements management discipline focuses on methods, tools and techniques that can be used to help control software development, deployment and evolution using a requirements baseline as reference. Its goal is to maintain plans, artifacts and development activities consistent with the software requirements. This course discusses several aspects related to requirement management, in particular change control, requirement versioning, traceability and requirement quality assurance.
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
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].
1.1 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.
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 100oC.
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.
1.2 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 http://wer.inf.puc- rio.br/WERpapers/. 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 coperativo 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?
• 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 1.1 - Engenharia de requisitos
1.3 Produção de Requisitos
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 que 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.
1.4 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 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.
2. 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 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 requisistos 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.
( ) Referente a Infra-estrutura ( ) Referente ao Apoio ( ) Outros. Especifique _________________________
( ) Novo Requisito ( ) Exclusão de Requisito ( ) Alteração de Requisito [Permitir mais de uma seleção.]
Não Funcional Funcional
Alteração Cancelamento
Tipo de Mudança
Contato:
Fone/Correio
Unidade: Sigla da unidade organizacional.
Solicitante: Nome do usuário que solicitou a mudança.
Registro de Solicitação de Mudança
( ) Referente a Infra-estrutura ( ) Referente ao Apoio ( ) Outros. Especifique _________________________
( ) Novo Requisito ( ) Exclusão de Requisito ( ) Alteração de Requisito [Permitir mais de uma seleção.]
Não Funcional Funcional
Alteração Cancelamento
Tipo de Mudança
Contato:
Fone/Correio
Unidade: Sigla da unidade organizacional.
Solicitante: Nome do usuário que solicitou a mudança.
Registro de Solicitação de Mudança
Não-Funcional
Figura 1.2 - 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 involvidas neste processo, deixando claro quem será responsável pela sua execução e qual 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.
Figura 1.3 - Processo de requisição de mudança em requisito, proposto por Wiegers.
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 gerenciamento de configuração.
3.1 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 a 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 a 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.
3.2 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
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.
1.0 1.1 1.2
1.1.1 1.1.2 ...
variante
configuração
principal 1.3 ...
Figura 1.4 - diferentes revisões e configurações de um software
3.3 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"
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.
4. Rastreabilidade3
A rastreabilidade de requisitos é uma das atividades preconizadas pelos modelos de qualidade como CMM, CMMI, MPS-BR ou ISO 9001. 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.
pré-rastreabilidade pós-rastreabilidade
requisitos artefatos de design e implementação necessidades dos
clientes e documentos
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ós- rastreabilidade 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]
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].
Figura 1.6 - Ligações de rastreabilidade entre requisitos
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) 1. O software deve oferecer um meio de representar e acessar
arquivos externos criados por outras ferramentas Requisito do usuário
Requisitos de sistema
4.1 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;
• 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.
4.2 Tipos de elos de rastreabilidade
Em seu artigo sobre rastreabilidade [Ramesh01], Ramesh&Jarke propõem um meta- modelo 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.
Ramesh&Jarke ponderam que mesmo existindo uma grande variedade de elos de rastreabilidade, eles podem ser agrupados em duas categorias básicas:
FONTE STAKEHOLDER
objetos ou entidades
artefatos gerados no processo
satisfação
evolução rationale dependência
estruturas de contribuição
FONTE STAKEHOLDER
objetos ou entidades
artefatos gerados no processo
satisfação
evolução rationale dependência
estruturas de contribuição
Fig. 1.7 – Meta-modelo para a rastreabilidade de requisitos [Jarke98]
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;
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.
4.3 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.
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 1.1 - Rastreabilidade entre requisitos e entidades geradas no processo de desenvolvimento
Projeto <nome_projeto> - Matriz de Rastreabilidade Requisito 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 1.2 - Rastreabilidade entre requisitos funcionais e não funcionais
Projeto <nome_projeto> - Rastreabilidade RF versus RNF Requisito Não-Funcional Requisito
Funcional NFR01 NFR02 NFR03 NFR04 NFR05 NFR06
RF01
RF02
RF03
RF04
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
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ão-funcionais, 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 http://www.incose.org/ProductsPubs /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 (http://www.paper-review.com/tools/rms/read.php).
4.5 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:
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.
5. 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 O sistema é capaz de atingir seus objetivos sem este requisito? Caso afirmativo este é um requisito desnecessário
Verificável É possível verificar que este requisito está sendo atendido pelo sistema?
Atingível O requisito pode ser atendido pelo sistema que está sendo desenvolvido?
Livre de
Ambiguidades O requisito possui mais de uma interpretação possível?
Completo O documento de especificação do sistema contém todos os requisitos?
Consistente Todos os requisitos podem ser atendedidos sem que se entre em conflito uns com os outros?
Rastreável A origem dos requisitos é conhecida? O requisito pode ser referenciado e localizado no sistema?
Alocação O requisito pode ser alocado a um elemento ou componente do sistema?
Concisão O requisito está descrito de forma simples e concisa?
Livre de Implementação
O requisito descreve o QUE deve ser feito sem influências de possíveis implementações?
Identificador único
Cada requisito possui um identificador único que permita com que possamos referenciá-lo de forma única e precisa?
Correção O requisito contém toda a informação necessária que permita sua implementação?
Priorizável O requisito é passível de ser priorizado frente aos outros requisitos?
Tabela 1.3 - Critérios de avaliação da qualidade de requisitos
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:
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
No caso da primeira sentença fica impossível determinar se o grau de segurança oferecido pelo sistema atende às necessidades dos usuários. Para o requisito de segurança, bem como para todos os requisitos não funcionais devemos NEGOCIAR as estratégias que atendem aquele requisito. Uma possível solução para estes requisitos poderia ser:
O sistema X deve ser seguro O sistema X deve parar sua operação se uma pessoa se aproximar a menos de 2 metros de uma de suas partes móveis O sistema X deve desligar os aquecedores se a temperatura da água exceder 37°C MNOP deve estar dentro dos padrões estabelecidos pela norma N567 seção 3.6 para temperaturas de superfícies externas.
O sistema C deve processar depósitos rapidamente
O sistema C deve escanear os dados do usuário e conta de cada folheto de depósito em 2 segundos ou menos
Repare que as estratégias de segurança que atendem ao requisito do sistema X não seriam as mesmas para um sistema de compra de livros na Internet por exemplo.
Neste tipo de sistema estratégias de segurança poderiam ser implementadas via utilização de login e senha e criptografia de dados bancários.
5.1 Processos de verificação da qualidade de requisitos
Como dito anteriormente, parte do processo de garantia da qualidade de software consiste na realização periódica dos os requisitos do projeto. Este processo, segundo o CMM, deve ser realizado tanto pela gerência sênior quanto que pelos gerentes de projeto e de qualidade, da seguinte maneira:
–A gerência sênior deve revisar, periodicamente, todas as atividades de gerência dos requisitos de software
–O gerente do projeto deve revisar, periodicamente e quando da ocorrência de eventos, todas as atividades de gerência dos requisitos do software.
–O grupo de GQS deve revisar e/ou auditar as atividades e artefatos utilizados para gerenciar os requisitos alocados, reportando seus resultados. Devem ser realizadas, no mínimo, as seguintes verificações:
• Revisão dos requisitos de software
• Planos de software
• Artefatos e produtos de trabalho
• Atividades da gerência de requisitos
Na literatura da área encontramos várias técnicas, formais e informais, para a realização de verificação de requisitos de software. Uma das mais utilizadas é a técnica de inspeções, criada por Fagan em 1972, visando aumentar a qualidade de software e a produtividade dos programadores. Inicialmente pensada para a identificação de defeitos na estrutura e no código de programas, ela foi posteriormente ampliada para aplicação em outros artefatos de software [Fagan86] (como requisitos, especificações, arquitetura, planos de teste), sendo atualmente bastante utilizada por desenvolvedores de software.
A literatura aponta que o processo de inspeção pode detectar de 30% a 90% dos erros existentes nos artefatos gerados num processo de desenvolvimento de software [Laitenberger01], [Blackburn01].
5.2 Inspeções4
O processo de inspeção caracteriza-se pela leitura cuidadosa de um artefato com utilização de uma técnica de leitura, buscando a localização de erros ou defeitos no mesmo, segundo um critério pré-estabelecido. A inspeção é aplicável a praticamente todos os tipos de artefatos, sendo possível utilizar diferentes técnicas de leitura. A técnica escolhida deve identificar as informações a serem verificadas e apoiar a localização de defeitos nestas informações. Apresentaremos brevemente as técnicas de leitura baseadas na experiência do inspetor (ad-hoc) e as baseadas em checklists e em perspectivas.
Inspeções envolvem análises criteriosas do artefato, considerando aspectos de qualidade que devem ter sido atendidos na sua elaboração. O processo de inspeção compreende várias etapas, iniciando pela coleta dos artefatos a serem utilizados e/ou analisados, passando pela inspeção propriamente dita e chegando ao acompanhamento da correção dos defeitos encontrados. Diversas técnicas de leitura foram propostas e estão em uso corrente; geralmente algum treinamento é necessário para sua efetiva aplicação. Os participantes desempenham diferentes papéis, dependendo da etapa em desenvolvimento, e também do grau de conhecimento e envolvimento no projeto.
5.3 Etapas do processo de inspeção
As etapas do processo de inspeção são esquematizadas na figura 1.9 e estão descritas a seguir:
Planeja - mento
Inspeção Coleção Correção
Visão geral
Acompa - nhamento Planeja -
mento Visão Coleção Correção
geral
Acompa - nhamento Figura 1.9 – Etapas do processo de inspeção
4 parte do texto sobre inspeções foi originalmente publicada em [Sayão03]
Planejamento: nesta etapa inicial do processo, uma pessoa da organização, envolvida diretamente ou não no projeto, é responsabilizada pela organização e condução geral da inspeção. Os participantes são selecionados e recebem atribuições correspondentes aos papéis que irão desempenhar, e é definida uma data para a realização da reunião de inspeção. O material a ser utilizado (artefatos a serem inspecionados e check lists específicas para cada tipo de artefato) é reproduzido e distribuído aos participantes;
Visão geral: no início da reunião de inspeção, cuja duração deve ser definida previamente, o autor apresenta o artefato a ser inspecionado aos participantes; também pode ser passada a visão geral do projeto. Esta fase é considerada particularmente interessante nas fases iniciais do projeto, que é o caso da inspeção em artefatos de requisitos;
Inspeção: durante a reunião, inspetores avaliam o artefato e registram os defeitos encontrados. A inspeção pode ser realizada de forma individual pelos inspetores, com maior ou menor grau de interação entre eles;
Coleção: defeitos são reunidos e registrados num documento único. Pode haver uma revisão nos defeitos relatados, verificando-se também se eles realmente correspondem a defeitos que necessitam de correção. A comunicação dos defeitos encontrados pode ser feita durante uma reunião com a presença dos inspetores e os autores do artefato, e neste caso é interessante a presença do moderador; ou então o autor do artefato sendo avaliado recebe o documento com os defeitos consolidados;
Correção: o artefato retorna para que os defeitos detectados sejam corrigidos pelos desenvolvedores;
Acompanhamento: são efetuados o acompanhamento e verificação da correção dos defeitos apontados no processo de inspeção. Se o número de defeitos for significativo, o coordenador pode determinar nova inspeção sobre o artefato revisado.
No processo de inspeção existem diferentes papéis a serem desempenhados pelos participantes. O organizador é aquele que se responsabiliza pela organização e condução do processo como um todo, coletando documentos e informações necessárias, selecionando os participantes de acordo com seu perfil, distribuindo os papéis, agendando encontros e acompanhando a correção dos defeitos. O autor do artefato apresenta uma visão global do mesmo, antes da inspeção ser efetuada. O inspetor analisa os artefatos, seguindo uma técnica de leitura pré-definida, anotando os defeitos encontrados e repassando-os ao secretário; este último reúne os defeitos encontrados pelos vários inspetores, consolida-os num documento e os repassa ao moderador. O moderador também conduz a reunião de inspeção, e deve ter experiência na condução de trabalhos em equipe. O relator apresenta os defeitos coletados aos autores do artefato; esta reunião tem ainda a presença do moderador, para mediar e resolver eventuais conflitos, e do secretário, que registra o encontro.
Das técnicas de leitura indicadas para artefatos produzidos na fase de requisitos ressaltamos: Ad-hoc, Baseada em Checklists (ou ckecklists) e Baseadas em Perspectivas (ou PBR). Estas técnicas já foram validadas em processos experimentais e estão em uso na indústria de desenvolvimento de software [Laitenberger01].
5.4 Ad-hoc
A técnica de leitura ad-hoc é fortemente baseada no conhecimento e na experiência do inspetor; não há suporte técnico para indicar quais informações checar e como identificar defeitos nessas informações. Isto não significa que as inspeções com esta abordagem não sigam critérios adequados, mas apenas indica que os critérios e métodos adotados na análise/leitura dos artefatos dependem do inspetor que as efetua.
As qualidades a serem satisfeitas num documento de requisitos e que podem ser verificadas por esta técnica de leitura são: clareza (os requisitos estão bem determinados?), completude (estão presentes todos os requisitos necessários à especificação do sistema?), consistência (os requisitos são consistentes com a visão geral do sistema?), corretude (os requisitos descrevem as funcionalidades de maneira correta?), funcionalidade (as funcionalidades descritas são necessárias e suficientes para atingir os objetivos do sistema?), testabilidade (as funcionalidades permitem a verificação ou teste de forma a mostrar que os requisitos são satisfeitos?) e detalhamento (o nível de detalhe nos requisitos é suficiente para fornecer uma base adequada ao design do sistema?).
5.5 Baseada em checklists
Na técnica de leitura baseada em checklists, já consolidada na indústria, o conjunto de inspetores utiliza uma mesma lista para a leitura e análise do artefato. Esta lista relaciona os itens a serem verificados e o que deve ser entendido como defeito. Para cada tipo de artefato há uma lista específica (Documento de Requisitos, Casos de Uso, Cenários, Léxico Ampliado da Linguagem, Diagramas de Classes, Plano de Testes, Casos de Teste, Código, ...).
Essas listas são adaptáveis, e podem levar em consideração os defeitos de maior ocorrência nos sistemas desenvolvidos naquele ambiente. Um dos efeitos colaterais desta abordagem é que, com o uso freqüente de inspeções, os desenvolvedores tenderão a colocar maior atenção nos pontos que originam esses defeitos, e conseqüentemente deverá diminuir o número desses defeitos nos artefatos de software. Por outro lado, defeitos de tipos não caracterizados na checklist não serão detectados; para diminuir esses problemas, deve-se procurar seguir algumas regras básicas na construção da lista:
a) uma página deve ser suficiente para relacionar as questões a serem respondidas; b) as questões devem ser objetivas e precisas e c) os atributos de qualidade que devem estar presentes no artefato devem ser claros, e as respostas às questões devem assegurar que tal atributo se encontra ou não presente.
Esta técnica de inspeção, quando aplicada a artefatos de requisitos (casos de uso, cenários, documento de requisitos, glossários, léxico ampliado da linguagem), pode detectar os seguintes tipos de defeitos:
• sintaxe incorreta nos artefatos (as sentenças/termos não seguem a sintaxe estabelecida)
• informação inconsistente entre artefatos (símbolos definidos num artefato e não referido em outros; símbolos utilizados mas não definidos;
descrição não condizente com o símbolo; sinônimos incorretos)
• requisitos não funcionais não explicitados
• informação ambígua (símbolos, termos ou sentenças que possam provocar diferentes interpretações)
• informação desnecessária (por exemplo, atores em excesso)
• ausência de informação (por exemplo, atores, pré ou pós-condições em casos de uso)
• exceções não previstas 5.6 Baseada em perspectivas
O processo de inspeção baseado em perspectivas, ou PBR (Perspective Based Reading), caracteriza-se por considerar as diferentes perspectivas (visões) dos atores do processo [Shull00] [Porter95] e é aplicável a artefatos de requisitos, design e código. Enquanto na leitura baseada em checklists todos os inspetores utilizam uma mesma lista de questões, nesta abordagem existem listas e procedimentos diferentes para cada perspectiva ou visão. Esta técnica considera que os diferentes agentes envolvidos no processo de desenvolvimento vêem os artefatos sob diferentes pontos de vista e portanto os revisores para o processo são selecionados de acordo com a utilização que farão do artefato, por exemplo: usuário final, projetista, programador, representante da equipe de manutenção, executor de testes e outros.
Um documento de requisitos pode ser visto através de diferentes visões: o usuário final deseja ver ali refletido o conjunto de funcionalidades a ser atendido pelo software; o projetista irá utilizá-lo como base para a criação da estrutura do software, considerando as funcionalidades e restrições descritas, e o testador verá o documento de requisitos como fonte primeira para a geração dos testes, que deverão assegurar que o mesmo atende às necessidades (funcionais e não funcionais) registradas.
As listas utilizadas pelos diferentes inspetores não são genéricas, sendo adaptadas a cada organização; para sua geração são considerados as metodologias adotadas no ciclo de desenvolvimento, o ambiente operacional em uso, o grau de experiência e conhecimento dos desenvolvedores e os problemas de maior ocorrência nos produtos já desenvolvidos pela equipe de desenvolvimento em questão.
Outra importante diferença desta técnica de leitura em relação às técnicas de leitura ad-hoc ou baseada em checklists está relacionada à atuação dos inspetores:
enquanto que nas duas primeiras os inspetores limitam-se a avaliar e registrar os
defeitos encontrados, na PBR os inspetores possuem a atribuição adicional de criar um modelo voltado à sua visão, e avaliar criticamente os requisitos e o modelo seguindo uma lista de questões. Exemplificando: um inspetor que assume o papel de testador (preparador dos testes) deve gerar casos de teste para cada entrada do artefato de requisitos em análise e, ao mesmo tempo, verificar se as informações presentes nos requisitos são adequadas para a geração desses testes. Após isto, analisa criticamente o caso de testes gerado e avalia se ele atende aos requisitos de qualidade estabelecidos por um conjunto de questões associadas a casos de teste. O modelo de testes assim obtido será a base para o conjunto de casos de testes a ser gerado posteriormente.
Esta técnica de inspeção, quando aplicada a artefatos de requisitos (cenários, documento de requisitos, léxico ampliado da linguagem), pode detectar os seguintes tipos de defeitos:
• ausência de informação (definição de termos, unidades de medida,...)
• informação ambígua (vários significados possíveis para um único termo)
• informação inconsistente (quando existem requisitos em conflito)
• fatos incorretos (fato que não pode ser verdadeiro nas condições especificadas para o sistema)
• informação desnecessária (excesso de informação pode confundir os usuários)
• outros tipos de defeitos (defeitos não classificados em nenhum dos tipos anteriores, como por exemplo requisito em seção incorreta)
5.7 Automação, custos e benefícios da inspeção
A utilização das inspeções tem sido bem aceita pelos desenvolvedores, e o treinamento, quando necessário, exige apenas de um a dois dias de trabalho. A realização de uma inspeção envolve um total de 10 a 20 horas de trabalho: cada participante necessita de uma a duas horas para as atividades de preparação e mais uma ou duas horas para a inspeção propriamente dita. Nesta geralmente participam de 4 a 5 pessoas, incluindo o organizador, que necessita de um pouco mais de tempo para a preparação do processo e posterior acompanhamento da correção dos defeitos. Não há consenso sobre o modo da execução da inspeção: ela tanto pode ser efetuada individualmente pelos inspetores, ou ocorrer numa reunião com presença adicional de um moderador.
Além da melhoria de qualidade resultante nos artefatos inspecionados (de 30% a 90% de defeitos são localizados em inspeções) a prática tem registrado que, a partir do envolvimento das equipes no processo de inspeção, um dos resultados é a diminuição de erros nos projetos posteriores e conseqüentemente diminuição do tempo do ciclo de desenvolvimento e aumento da produtividade. Os resultados obtidos com utilização das técnicas de leitura ad hoc e checklists, largamente aplicadas nas empresas, são equivalentes [Porter95].
A especificação de requisitos pode utilizar tanto uma linguagem formal quanto a linguagem natural. A utilização da linguagem natural é mais freqüente, pois favorece o
entendimento por parte de todos os envolvidos no processo de desenvolvimento, o que não acontece quando se utiliza uma linguagem formal. Artefatos de requisitos escritos em linguagem natural costumam seguir um conjunto básico de regras de sintaxe, visando a diminuição da ambigüidade e aumento da clareza e concisão do documento. É possível automatizar a verificação da sintaxe com um analisador léxico, e também a verificação cruzada de artefatos (por exemplo glossários, casos de uso e documentos de requisitos).
Independente do processo de inspeção ser manual ou automatizado, a relação custo/benefício é bastante positiva: dados coletados em inspeções efetuadas em diferentes empresas mostram que o retorno do investimento (economia estimada/custo da inspeção) é da ordem de quatro a oito, independente do contexto de aplicação (requisitos, desenho, código ...) [O´Neill99].
Bibliografia
Nesta seção incluímos algumas das publicações mais significativas da área de Engenharia de Requisitos separadas por tipo.
Livros
Managing Software Requirements: A Unified Approach - Dean Leffingwell, Don Widrig - Addison Wesley- 2000
Requirements Led Project Management: Discovering David's Slingshot - by Suzanne Robertson, James Robertson (May 4, 2000) Addison-Wesley Pub Co -2005 Requirements Engineering: a good practice guide - Ian Sommerville, Peter Sawyer -
Wiley - 1997
Effective Requirements Practices - Ralph Young - Addison Wesley - 2001 Requirements Engineering - Linda Macaulay - Sringer - 1996
Software Requirements - Karl E. Wiegers - Microsoft Press 1999
Mastering the Requirements Process by Suzanne Robertson, James Robertson Addison-Wesley Pub Co - 2000
Requirements Engineering: Processes and Techniques by Kotonya, Gerald;
Sommerville, Ian. Wiley & Sons, c1998;
Software Requirements & Specifications : A Lexicon of Practice, Principles and Prejudices by Michael Jackson - 1995 Addison-Wesley Pub Co;
Exploring Requirements : Quality Before Design. by Donald C. Gause and Gerald M. Weinberg (September 1989) Dorset House
Standards, Guidelines and Examples of System and Software Requirements Engineering - Dorfman, M. and Thayer, R. eds., Institute of Electrical and Electronics Engineers, Inc., 1990.
Software Engineering - Ian Somerville - Pearson - 2004
Conceitos Básicos
[Breitman99] - Breitman, K.K., Leite, J.C.S.P., Finkelstein, A. - The World´s a Stage: A Survey on Requirements Engineering using a Real-Life Case Study Journal of the Brazilian Computer Society, Vol.6, N.1, pp. 13-37, (1999), SBC.
[Goguen94] - Goguen, J.A. and Linde, C. - Techiques for Requirements Elicitation, In Proceedings of the First IEEE International Symposium on Requirements Engineering, San Diego, Ca, IEEE Computer Society Press - 1994, pp. 152-164.
[Leite94] Leite, J. C. S. P. Engenharia de Requisitos. PUC-Rio, Rio de Janeiro, 1994.
Notas de aula.
[Nuseibeh00] Nuseibeh, B. and Easterbrook, S. Requirements engineering: a roadmap.
In: A. Finkelstein, editor, "The Future of Software Engineering", Special Volume published in conjunction with ICSE 2000, 2000.
[Pohl93] Pohl, K. The Three dimensions of Requirements Engineering - Fifth International Conference on Information Systems Engineering - CAiSE'93 - Paris.
[Zave97] - Zave, P., Jackson, M. - Four Dark Corners of Requirements Engineering - ACM Transactions on Software Engineering and Methodology, January 1997, Vol.6 No.1, pp. 1-30.
Produção de Requisitos
[Batista03] Batista, Edinelson; Carvalho, Ariadne - Uma taxonomia facetada para técnicas de elicitação de requisitos - Workshop de Engenharia de Requisitos (WER 2003) - Piracicaba, SP - 27 e 28 de Novembro de 2003.
[Breitman00] Breitman, K.K.; Leite, J.C.S.P. – Scenario Evolution: A Closer View on Relationships – in Proceedings of the Fourth International Conference on Requirements Engineering (ICRE’00) – 2000.
[Breitman04] Breitman, K.K., Leite, J.C.S.P., Berry, D., M., - Scenario Evolution - accepted to the Requirements Engineering Journal - Springer Verlag - London.
[Breitman04] Breitman, K.K.; Leite, J.C.S.P - Lexicon Based Ontology Construction - Lecture Notes in Computer Science 2940- Editors: Carlos Lucena, Alessandro Garcia, Alexander Romanovsky, et al. - ISBN: 3-540-21182-9 - Springer-Verlag Heidelberg, February 2004, pp.19-34.
[Breitman05] Breitman, K.K.; Haendchen, A.; von Staa, A.; Haeusler, H. - Ontologies to Formalize Services Specifications in Multi-Agent Systems. In: Lecture Notes in Artificial Intelligence. . Formal Approaches to Agent-Based Systems: International Workshop, FAABS 2004. Heidelberg, 2005, LNAI 3228, 2005. pp.92-110.
[Brooks87] Brooks Jr., F.- No silver bullet: Essence and Accidents of Software Engineering - Computer, April 1987.
[Chavez03] Chavez, C. v. F.; Lucena, C.J.P. - A theory of aspects for aspect oriented software development - 17º Simpósio Brasileiro de Engenharia de Software (SBES'03) - Manaus, Outubro 2003 - pp. 130-145.
