Gerência de Requisitos
Miriam Sayão1 e Karin Koogan Breitman2
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
2
Faculdade de Informática da PUC-RS e DI/PUC-Rio; [email protected]
Departamento de Informática da/PUC-Rio; [email protected]
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].
1.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.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.pucrio.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 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?
•
•
•
•
•
•
•
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.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 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.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.
1.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 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.
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 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.
Figura 1.3 - Processo de requisição de mudança em requisito, proposto por
Wiegers.
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.
1.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 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.
1.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.
variante
configuração
principal
1.0
1.1.1
1.1
1.2
1.1.2
1.3
......
......
Figura 1.4 - diferentes revisões e configurações de um software
1.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.
1.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
necessidades dos
clientes e
documentos
pós-rastreabilidade
requisitos
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]
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 1.6 - Ligações de rastreabilidade entre requisitos
1.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.
1.4.2 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;
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.
1.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
Funcional
Requisito Não-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ã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 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).
1.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.
1.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
Verificável
Atingível
Livre de
Ambiguidades
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?
Completo
O documento de especificação do sistema contém todos os requisitos?
Todos os requisitos podem ser atendedidos sem que se entre em conflito
Consistente
uns com os outros?
A origem dos requisitos é conhecida? O requisito pode ser referenciado
Rastreável
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?
O requisito descreve o QUE deve ser feito sem influências de possíveis
Livre de
Implementação implementações?
Identificador Cada requisito possui um identificador único que permita com que
único
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 O sistema C deve escanear os dados do
rapidamente
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.
1.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].
1.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.
1.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:
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].
1.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?).
1.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
1.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)
1.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.
[Cysneiros01] Cysneiros, L.M., Leite, J.C.S.P., Neto, J.M.S.- A Framework for
Integrating Non-Functional Requirements into Conceptual Models. - Requirements
Engineering Journal: Vol. 6, N. 2, Pags. 97 - 115, (2001), Springer-Verlag London
Limited.
[Cysneros02] Requirements Engineering in the health care domain - L. Cysneiros RE03- IEEE Joint International Requirements Engineering Conference - Essen,
Alemanha, 2003. pp.350-356.
[Goguen94] Goguen, Joseph - Requirements Engineering as the reconciliation of social
and technical issues - in Requirements Engineering: Social and Technical Issues
edited by Joseph Goguen and Marina Jirotka - Academic Press 1994.
[Grundy99] Aspect Oriented Requirements Engineering for Component Based Software
Systems - Proceedings of the Fourth International Symposium on Requirements
Engineering (RE'99): IEEE Computer Society Press, Limerick, Ireland, 1999.
[Lamsweerde01] A. van Lamsweerde - Goal-Oriented Requirements Engineering: A
Guided Tour - 5th IEEE International Symposium on Requirements Engineering
(RE'01), Toronto, August, 2001, pp. 249-263.
[Lamsweerde02] Axel van Lamsweerde - Formal Specification: a Roadmap.
Département d’Ingénierie Informatique Université Catholique de Louvain - In "The
Future of Software Engineering", A. Finkelstein (ed.), ACM Press.
[Leite89] Leite, J.C.S.P. - Viewpoint Analysis: A Case StudyACM Software
Engineering Notes: Vol. 14, N. 3, pp. 111-119, (1989), ACM Press.
[Leite93] Leite, J.C.S.P., Franco, A.P.M. A Strategy for Conceptual Model Acquisition
Proceedings of the First International Symposium on Requirements Engineering,
IEEE Computer Society Press, pp. 243-246, (1993).
[Leite97] Leite, J.C.S.P., Rossi, G., Maiorana, V., Balaguer, F., Kaplan, G., Hadad, G.,
Oliveros, A. - Enhancing a Requirements Baseline with Scenarios - Proceedings of
the Third International Symposium on Requirements Engineering: IEEE Computer
Society, pp. 44-53 (1997).
[Maiden98] Neil A. Maiden and Cornelius Ncube. Acquiring COTS Software Selection
Requirements. IEEE Software, 15(2):46-56, Mar 1998.
[Mylopoulos92] Mylopoulos, J. et al. – Representing and Using Non-Functional
Requirements: A process oriented approach – IEEE Transactions on Software
Engineering – Vol. 18 No. 6, June 1992, pp. 483-497.
[Yu01] Yu, E. - Agent-Oriented Modelling: Software versus the World. In:
Agent-Oriented Software Engineering AOSE-2001, Workshop Proceedings. LNCS
2222. Springer Verlag. pp. 206-225.
Página de Early Aspects: Aspect Oriented Requirements Engineering. http://www.earlyaspects.net/
Gerência de Qualidade
[Basili96] Basili, V.R.; Green, S.; Laitenberger, O.; Lanubile, F.; Shull, F.;
Soerumgaard, S. & Zelkowitz, M. "The Empirical Investigation of Perspective-Based
Reading". Empirical Software Eng. J., vol. 1, no. 2, 1996.
[Blackburn01] Blackburn, M. R.; Busser, R.; Nauman, A. Removing Requirement
Defects and Automating Test. Software Productivity Consortium NFP, 2001.
Disponível
em
<http://www.software.org/pub/taf/downloads/
RemovingRequirementDefects.pdf>. Acesso em 26 nov 2002.
[Davis94] Davis, A., Davis, A., "Operational Prototyping: A New Development
Approach," - IEEE Software - September, 1994. pp. 75-79.
[Fagan86] Fagan, M. E. Advances in Software Inspections. IEEE Transactions on
Software Engineering, vol. SE-12, nº 7, pp. 744-751, july 1986.
[Laitenberger01] Laitenberger, Oliver. A Survey of Software Inspection Technologies.
Handbook on Software Engineering and Knowledge Engineering, vol. II, World
Scientific Pub. Co, 2001. Disponível em <ftp://cs.pitt.edu/chang/handbook/61b.pdf>.
Acesso em 13 set 2002.
[O´Neill99] O'Neill, Don. National Software Quality Experiment: Results 1992-1999.
In: SOFTWARE TECHNOLOGY CONFERENCE, 12th, 2000, Salt Lake City.
Proceedings.
STC
Disponível
em
<http://www.stc-online.org/cdrom/cdrom2000/default.htm>. Acesso em 18 set 2002.
[Sayão03] Sayão, M.; von Staa, A. & Leite, J. C. S. P. – Qualidade em Requisitos –
relatório técnico 47/03, série Monografias em Ciência da Computação, DI/PUC-Rio,
2003.
[Sayão05] Sayão, M. & Leite, J. C. S. P. – Rastreabilidade de Requisitos – relatório
técnico 20/05, série Monografias em Ciência da Computação, DI/PUC-Rio, 2005.
[Shull00] Shull, F.; Rus, I.; Basili, V. How Perspective-Based Reading can Improve
Requirements Inspections. IEEE Computer, vol. 33, nº 7, pp. 73-79, july 2000.
[Wilson97] Wilson, W.M.; Rosenberg, L.H.; Hyatt, L. E. Automated Analysis of
Requirement Specifications. In: INTERNATIONAL CONFERENCE ON
SOFTWARE ENGINEERING (IASTED), 1997, Boston, MA. Proceedings.
Disponível
em
<http://satc.gsfc.nasa.gov/support/ICSE_MAY97/arm/ICSE97arm.htm>. Acesso em 13 set 2002.
Gerência
[Davis03] Davis, A., "The Art of Requirements Triage," IEEE Computer, 36, 3 (March
2003), pp. 42-49.
[Lehman96] Lehman, M. M. 1996. Laws of Software Evolution Revisited. In:
Proceedings of the 5th European Workshop on Software Process Technology
(October 09 - 11, 1996). C. Montangero, Ed. Lecture Notes in Computer Science,
vol. 1149. Springer-Verlag, London, 108-124.
[Leite01] Leite, J.C.S.P. - Extreme Requirements - Jornadas de Ingeniería de Requisitos
Aplicada, JIRA, Universidade de Sevilha, Junho de 2001, pp. 1-13
[Leite01a] Leite, J.C.S.P. - Gerenciando a Qualidade de Software com Base em
Requisitos - Qualidade de Software: Teoria e Prática, Rocha, A. R., Maldonado,
J.C. e Weber, K. C., pp. 238-246, 2001, Prentice Hall.
[Yeh90] Yeh, R.; Ng. P. - Software Requirements - a management perspective - System
and Software Requirements Engineering - Dorfman, M. and Thayer, R. eds. - pp.
450-461 - Institute of Electrical and Electronics Engineers, Inc., 1990.