Gerncia de Requisitos

Miriam Sayo1 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 definio da arquitetura do sistema, para a implementao propriamente dita, para gerao dos casos de testes e para validao do sistema junto ao usurio. Gerenciamento de requisitos est relacionado ao processo de controlar todo o processo de desenvolvimento tendo como referncia 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 mudanas em requisitos, ao gerenciamento da configurao, rastreabilidade e qualidade em requisitos.

1 Faculdade de Informtica da PUC-RS e DI/PUC-Rio; miriam@inf.puc-rio.br 2 Departamento de Informtica da/PUC-Rio; karin@inf.puc-rio.br

1.1. Conceitos Bsicos Nesta seo apresentamos os conceitos bsicos relativos disciplina de Engenharia de Requisitos e aos processos de Produo e Gerncia de Requisitos. Iniciamos nossa discusso com a definio do termo Requisito. Segundo Dorfman e Thayer um requisito definido como [Dorfman90]:

Uma capacidade de software que o usurio necessita de modo a resolver um problema ou alcanar um objetivo

Uma capacidade de software que deve ser disponibilizada por um sistema ou componente de sistema de modo a satisfazer um contrato, padro, especificao ou outra formalidade imposta.

Segundo Ian Sommerville requisitos so definidos nas fases inciais de um projeto e servem como especificao do que deve ser implementado. So descries de como o sistema deve se comportar, de uma propriedade ou atributo do sistema. Um requisito pode descrever:

Uma facilidade encontrada no nvel do usurio Uma propriedade geral do sistema Uma restrio do sistema Uma restrio ao desenvolvimento do sistema

Uma discusso freqente na literatura de Engenharia de requisitos a distino entre o QUE e COMO. Alguns autores pregam que os requisitos devem descrever apenas o que sistema deve fazer (QUE) no se atendo aos detalhes de implementao (COMO). Alan Davis aponta que em muitos casos esta distino quase impossvel de ser feita, pois dependendo do nvel de detalhe da anlise, 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 so classificados em trs categorias: Requisitos funcionais So requisitos diretamente ligados funcionalidade do software, o que o sistema deve prover. Suzanne e James Robertson definem requisitos funcionais como "uma ao que o produto deve ser capaz de realizar" [Robertson05] Exemplo: O sistema deve emitir um recibo aps cada transao de compra. Requisitos no funcionais So requisitos que expressam restries que o software deve atender ou qualidades especficas que o software deve ter. Suzanne e James Robertson definem requisitos no funcionais como "uma qualidade que o produto deve possuir." [Robertson05] Exemplo: O tempo de impresso de qualquer documento no deve exceder 1 minuto.

Requisitos inversos So requisitos que definem estados e situaes que nunca devem ocorrer. Exemplo: O sistema no 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, esto bem escritos, livres de ambiguidade e completos? Na seo 1.5 discutiremos estes tpicos ao abordar qualidade dos requisitos e da especificao.

1.1.2 Engenharia de Requisitos A Engenharia de Requisitos (ER) uma sub-rea da Engenharia de Software que estuda o processo de produo e gerncia dos requisitos que o software dever atender. Este processo tem incio junto aos clientes durante a fase de elicitao ou levantamento dos requisitos e perpassa todas as fases do processo de desenvolvimento do software. O objetivo da ER fornecer mtodos, tcnicas e ferramentas que forneam suporte adequado s tarefas de produo (elicitao, modelagem e anlise) e gerncia dos requisitos do sistema. A Engenharia de Requisitos foi estabelecida como disciplina independente em 1993, quando da criao do IEEE International Symposyum on Requirements Engineering (RE93). A rea tem crescido desde ento. Atualmente temos a conferncia internacional de requisitos RE (IEEE International Requirements Conference), que alm 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 pblico ibero-americano, j que aceita trabalhos em portugus e espanhol. Os artigos do WER esto disponibilizados na rede, atravs do site http://wer.inf.puc-rio.br/WERpapers/. O Requirements Engineering Journal, publicado pela Springer Verlag London, o peridico 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 sistemtico de desenvolvimento de requisitos atravs de um processo cooperativo de anlise onde os resultados das observaes so codificados em uma variedade de formatos e a acurcia das observaes constantemente verificada.

Linda Macaulay discute a definio proposta por Pohl, que enfatiza as questes centrais da Engenharia de requisitos. Entre outras esto:

Como este processo pode ser sistemtico se tantos fatores so desconhecidos no incio do processo de desenvolvimento de software?

Quantas interaes sero necessrias para realmente verificar a acurcia das observaes (esta questo est diretamente ligada ao processo de validao e verificao dos requisitos, ver seo 1.5 qualidade)

Como sabemos que ja foram levantados requisitos suficientes? Os usurios devem ser includos no processo ou so meramente fontes de

informao? Quantas e quais representaes devem ser utilizadas na codificao dos

requisitos? Quais padres devem ser adotados e quais notaes existentes podem ser

adaptadatas para atender o processo de captura e codificao de requisitos? Qual o nvel de preciso dos requisitos ? Como sabemos que chegamos ao final do processo?

Muitas destas perguntas ainda esto em aberto e esto sendo abordadas por pesquisadores de requisitos no mundo inteiro, o que contribui para um crescente interesse por parte de profissionais e pesquisadores em relao ao papel da Engenharia de Requisitos no processo de produo de software. Levantamentos recentes da comunidade europia 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 gerncia de requisitos vista como um dos principais problemas a serem superados para que as organizaes cheguem ao nvel 2 de maturidade segundo o modelo CMM (Capability Maturity Model) do SEI, sendo que o prprio SEI disponibilizou recentemente um pacote que ajuda a transferncia de tecnologia em Engenharia de Requisitos para facilitar a certificao das empresas. No entanto ainda existe confuso entre os termos Engenharia e Gerncia de Requisitos. A Engenharia de Requisitos, como mencionado acima, engloba os processos de produo e gerncia de requisitos, como ilustrado na figura 1.1.

Figura 1.1 - Engenharia de requisitos

1.1.3 Produo de Requisitos

Segundo Ian Sommerville, um bom processo de produo de requisitos tem de levar em conta as seguintes etapas: elicitao, anlise e negociao e validao [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 produo de requisitos so: elicitao, modelagem e anlise (validao e verificao). Karl Wiegers inclui um quarto processo, especificao, que foca na documentao de informao relativa a rastreabilidade dos requisitos. Independente da organizao dos processos, o fato todos os enfoques levam em conta a captura (elicitao dos requisitos), registro (codificao, modelagem, utilizando-se algum tipo de representao persistente que garanta o acesso posterior aos requisitos e suas origens) e qualidade (validao e verificao de modo a garantir a acurcia das observaes e informaes levantadas durante o processo). Neste artigo vamos nos concentrar nos processo de gerncia de requisitos.

1.1.4 Gerncia de requisitos Durante o processo de desenvolvimento e operao de um sistema de software natural o surgimento de novos requisitos e a necessidade de mudanas nos requisitos existentes. Este processo, tambm conhecido como evoluo de sistemas, acontece como resultado de mudanas no meio ambiente onde o prprio sistema de software est inserido. Se o macrosistema muda os sistemas de software devem acompanhar esta mudana ou ficaro cada vez menos teis [Lehman96]. O processo de mudana dos requisitos precisa ser controlado de modo a garantir a qualidade do sistema. O impacto destas mudanas precisa ser avaliado e compreendido de modo que sua implementao seja feita de maneira eficiente e a baixo custo. Este processo conhecido como a gerncia de requisitos, que pode ser definido da seguinte forma:

Enfoque sistemtico para a elicitao, organizao e documentao dos requisitos do sistema e um processo que estabelece e mantm o acordo entre usurios e a equipe de projeto medida que os requisitos se modificam [Leffingwell00].

Segundo Ian Sommerville, os principais aspectos ligados gerncia de requisitos so relacionados a:

1. Gerenciar as mudanas em requisitos existentes (pertencentes a especificao), 2. Gerenciar o relacionamento entre os requisitos, 3. Gerenciar as dependncias entre o documento de requisitos e outros documentos produzidos durante o desenvolvimento de software.

Para implementar uma gerncia de requisitos eficaz necessrio, de antemo, definir um conjunto de polticas. necessrio definir um conjunto de objetivos para o processo de gerncia. 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 gerncia dos requisitos visvel e transparente. Estes documentos devem ser gerados levando-se em contas padres externos e corporativos, de modo a assegurar consistncia e uniformidade das informaes. Polticas bem definidas para a gerncia de configurao, controle de mudanas e rastreabilidade e garantia da qualidade precisam colocadas em prtica de modo a viabilizar um processo dinmico e eficaz de gerncia de requisitos. Nas prximas sees vamos discutir os aspectos fundamentais de gerencia de requisitos. So eles: controle de mudanas, gerncia da configurao, rastreabilidade e garantia da qualidade.

1.2. Controle de Mudanas Em um ambiente real de desenvolvimento de software mudanas so inevitveis. Em muitos dos casos os requisitos do sistema mudam enquanto o sistema aida est sendo desenvolvido. As razes para mudanas so de vrios tipos, entre outras:

A complexidade dos sistemas impe mudanas medida que se adquire maior conhecimento sobre os mesmos,

Requisitos errados ou mal definidos precisam ser corrigidos/ajustados ao longo do processo de desenvolvimento,

Mudanas no ambiente: regras de negcios, leis, polticas internas, Desenvolvedores querem adicionar funcionalidades mais avanadas de modo a

oferecer vantangem Tecnologia muda, Clientes mudam de idia.

A grande verdade que no ambiente corporativo atual, sistemas de informao devem estar em constante evoluo de modo a servir as necessidades de seus usurios. Este fenmeno particular a sistemas de inforamao e foi observado inicialmente por Manny Lehman [Lehman96]. Este tipo de sistema, tambm conhecido como sistema do tipo E (evolutionary) se caracteriza por, uma vez instalado, tornar-se parte do meio ambiente e acabar alterando seus prprios requisitos. Sistemas do tipo E esto inseridos no mundo real, infinito e contnuo, o que determina a impossibilidade de se obter para os mesmos especificaes exatas e completas. Os modelos de especificao de software que somos capazes de desenvolver so finitos (tempo finito para o desenvolvimento, memria finita para guardar, recursos limitados). Para agravar a situao, estes sistemas tambm devem levar em conta que o mundo real est em constante mudana de modo que algumas das hipteses iniciais podem se tornar incorretas (sem que nos demos conta disto). Desta forma a atitude correta perante a gerncia de requisitos "preparar para mudar". Segundo Caper Jones os requistos de sofware se modificam, em mdia, na taxa de 2% ao ms durante as fases de projeto e codificao. Durante a fase de manuteno esta taxa pode aumentar. A mudana nos requisitos comumente chamada de

volatilidade; parte das atividades da gerncia de requisitos controlar mudanas. O CMM define mudanas como:

As alteraes que precisam ser feitas nos requisitos e artefatos de software. fudamental que as alteraes dos requisitos sejam:

Identificadas e avaliadas Avaliadas sob o ponto de vista de risco Documentadas Planejadas Comunicadas aos grupos e indivduos envolvidos Acompanhadas at a finalizao

O ponto de vista do CMM compartilhado por vrios autores. Fundamental para garantir que o escopo do sistema a manutenao de um processo de mudanas controlado. Um processo bem definido fornece aos interessados (clientes e desenvolvedores) um mecanismo formal de solicitao de mudanas nos requisitos de software. Este processo vai facilitar processos de tomada de deciso, gerncia e controle de custos. O processo de controle de mudanas permite com que todas as mudanas sejam rastreadas e garante que nenhuma solicitao seja perdida ou deixada de lado. Este processo no deve ser encarado como obstculo mas sim como um filtro que vai permitir uma gerncia mais eficaz e transparente. fundamental que este processo seja bem documentado e que faa uso de templates para solicitao de mudanas. Os templates garantem consistncia e uniformidade nas solicitaes, facilitam a manipulao e o armazenamento das informaes em um formato nico e compartilhado. A figura 1.2 ilustra um exemplo de template de solicitao de mudana. Templates para o registro de mudanas em requisitos devem conter, minimamente, informaes relativas ao tipo de mudanas, pessoa responsvel pela solicitao, data e rgo de origem, e uma boa descrio da mudana em si. Idealmente tambm pode conter informaes relativas prioridade da mudana, em relao s diretivas do projeto e um cronograma que estabelea a data desejada em que a mudana deveria ser implementada.

Figura 1.2 - Exemplo de Registro de Solicitao de Mudana Para o gerente de requisitos o mais importante estabelecer uma prtica consistente para a mudana dos requisitos. Para tal necessrio estabelecer um processo de tratamento de mudanas. Este processo, que deve ser acordado com os membros da equipe de desenvolvimento e usurios, deve ser descrito de modo a deixar claro:

Entradas - quais condies devem ser satisfeitas antes de se dar partida ao processo

Tarefas - detalhar quais so as tarefas envolvidas neste processo, deixando claro quem ser responsvel pela sua execuo e o formato em que os resultados devem ser comunicados

Verificao - definir etapas onde os resultados obtidos so verificados de modo a garantir consistncia e qualidade

Sadas - definir um critrio claro que indique que o processo chegou ao fim. Na figura 1.3 apresentamos um exemplo de processo de mudana de requisitos, proposto por Karl Wiegers.

No-Funcional

Figura 1.3 - Processo de requisio de mudana em requisito, proposto por

Wiegers.

1.3. Gerncia da Configurao A Gerncia de Configurao est comumente associada a dois tipos de tarefas: controle de verses e controle de configurao.

1.3.1 Controle de verses Por controle de verses entende-se as atividades associadas a manter, sob estrito acompanhamento, as diferentes verses de um artefato. Nas metodologias tradicionais de desenvolvimento, aps clientes, usurios e equipe de desenvolvimento terem identificado e validado o conjunto de requisitos que ser atendido pelo software, tem incio as etapas que envolvem design, codificao, testes, etc. Mudanas em requisitos j registrados no documento de requisitos podem impactar na arquitetura proposta para o sistema, na organizao de componentes, em casos de testes, em prazos e custos. Mudanas, portanto, devem ser rigorosamente controladas; o controle de verses possibilita manter a histria de todas as diferentes verses dos artefatos, ao longo do ciclo de vida do sistema; isto inclui desde o levantamento inicial de informaes, passa pelas atividades do processo de requisitos, e indo ainda alm, durante as atividades de evoluo. O controle de verses fundamental para garantir que toda a equipe compartilha a mesma verso dos artefatos sendo trabalhados. Se isto no acontecesse, poderamos ter a situao onde o conjunto de casos de teste sendo trabalhados pela equipe responsvel pelos procedimentos de qualidade considera requisitos diferentes daqueles que esto em processo de implementao, ou mesmo j implementados. Se essa divergncia entre o que foi implementado e o que vai ser testado no for identificada a tempo, os testes apontariam defeitos inexistentes, ou, no pior caso, deixariam de apontar defeitos presentes na implementao. Com o controle de verses, torna-se mais fcil garantir que todos os envolvidos no sistema em desenvolvimento compartilhem a mesma verso do documento de requisitos e dos demais artefatos utilizados durante as vrias atividades associadas criao do sistema. Quando o desenvolvimento do software distribudo, ou terceirizado, o controle de verses torna-se mais crtico, sendo fundamental a utilizao de uma ferramenta que auxilie esse trabalho. Muitas vezes a empresa contratante sofre presses para a rpida liberao do software no mercado, para fazer frente concorrncia. A tendncia dividir o trabalho entre vrias equipes, e no incomum a situao onde uma equipe executa o processo de requisitos, passa os artefatos para uma segunda equipe efetuar projeto e implementao, enquanto uma terceira fica encarregada dos testes. Se mudanas nos artefatos de requisitos no forem comunicadas a todos os envolvidos, ento a situao descrita acima tem probabilidade bastante alta de acontecer.

1.3.2 Controle da configurao do software Por controle de configurao entende-se as atividades associadas a manter, sob estrito acompanhamento, o conjunto de artefatos relacionadas a uma determinada configurao

do sistema. Um exemplo bastante comum encontrado nas verses demo de muitos softwares comercializados: em relao verso full, a verso demo possui restries de funcionalidades, de perodo de utilizao ou de quantidade de informaes manipulada e/ou armazenada. Nestes casos, os requisitos da verso demo certamente possuem diferenas em relao aos requisitos da verso full - essas diferenas correspondem justamente s restries colocadas pelo fabricante na verso para demonstrao. Isto vale tambm para outros artefatos, pois essas restries no se limitam ao conjunto de requisitos: elas podem implicar na arquitetura, nos componentes, nos casos de teste, etc. Gerencia de configurao, portanto, envolve manter controle sobre os diferentes artefatos e componentes que fazem parte de cada uma das diferentes configuraes para o software em pauta. A figura 1.4 a seguir ilustra a situao onde, ao longo do tempo, foram sendo geradas diferentes revises de uma mesma verso do software (a reviso 1.0 aps a primeira alterao 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 tambm podem ser visualizadas as revises de outra configurao ou variante do mesmo software; revises estas geradas a partir da reviso 1.1 da configurao principal. Todos os artefatos que correspondem a uma verso (ou reviso) devem ser consistentes uns com os outros, ou seja, todos devem refletir o mesmo conjunto de requisitos.

Figura 1.4 - diferentes revises e configuraes de um software

1.3.3 Ferramentas para controle de verses e gerncia de configurao O mercado disponibiliza diversas ferramentas que podem ser utilizadas tanto para controle de verses como para gerncia de configurao. Visual SourceSafe, CVS e ClearQuest so algumas das ferramentas disponveis com estas finalidades. Uma das mais utilizadas o CVS - Concurrent Version System, licenciado na forma de software livre. Iremos relacionar algumas das caractersticas deste software, que so tambm encontradas em outras ferramentas que possuem o mesmo propsito. O CVS utiliza o conceito de repositrios para armazenamento e controle de verses de arquivos. Os diretrios que compem a estrutura dos arquivos depositados no repositrio so chamados de mdulos; muitos comandos de CVS referem-se a mdulos ao invs de arquivos. O administrador (gerente do projeto, por exemplo), cria o repositrio e define os usurios que podero ter acesso aos arquivos nele armazenados. possvel restringir os direitos de acesso dos usurios aos arquivos controlados. As operaes de check in e check out possibilitam ao desenvolvedor executar a "retirada"

1.0 1.1 1.2

1.1.1 1.1.2 ...... variante

configurao principal

...... 1.3

de um arquivo (ou de um conjunto de arquivos) para o seu prprio diretrio de trabalho, fazer as modificaes necessrias e recolocar os componentes modificados sob o gerenciamento do controlador de verses. O controlador, por sua vez, mantm controle sobre estas operaes, verificando e informando ao usurio se alguma outra operao de modificao foi executada sobre o mesmo componente. Ferramentas deste tipo costumam trabalhar com estruturas de diretrios para o armazenamento das diferentes configuraes do software sendo gerenciado; isto facilita a co-existncia de diferentes configuraes para um mesmo software. O espao para armazenamento otimizado, pois a cada nova verso, apenas as diferenas em relao anterior so armazenadas - o CVS se encarrega de fazer a identificao das diferenas entre uma verso ou reviso 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 viso mais simples, rastreabilidade pode ser encarada como o conjunto de ligaes 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 usurio que trouxe uma necessidade, como documentos da organizao, padres a serem seguidos e tambm legislao pertinente. As ligaes existem nos dois sentidos, como podemos visualizar na figura 1.5 a seguir.

As ligaes denominadas de pr-rastreabilidade so aquelas relacionadas ao contexto do qual emergem os requisitos; as ligaes denominadas de ps-rastreabilidade so relacionadas diretamente ao contexto tcnico do processo de desenvolvimento. As ligaes associadas pr-rastreabilidade permitem identificar a origem de cada requisito e tambm quais os requisitos originados de uma determinada fonte (por exemplo, os requisitos originados de padres organizacionais). As ligaes associadas ps-rastreabilidade permitem identificar quais componentes (e casos de teste, por exemplo) implementam um determinado requisito, e tambm possibilitam saber claramente, dado um componente (ou outro artefato), quais os requisitos que ele deve atender.

Outra forma de rastreabilidade associa requisitos de alto nvel aos requisitos dele derivados. Requisitos de alto nvel geralmente correspondem ao que Sommerville denomina de requisitos do usurio: declaraes em linguagem natural ou diagramas, sobre as funes que o sistema deve fornecer e as restries sobre as quais deve operar.

3 parte do texto sobre rastreabilidade foi originalmente publicada em [Sayo05]

necessidades dos clientes e

documentos

requisitos artefatos de design e

implementao

pr-rastreabilidade ps-rastreabilidade

Fig. 1.5 Rastreabilidade de Requisitos

Estes requisitos, escritos para os clientes e usurios, remetem a funcionalidades de alto nvel. J os requisitos de sistema, que so a base para o contrato entre cliente e equipe de desenvolvimento, estabelecem detalhadamente as restries que o sistema dever atender; so descries mais detalhadas dos requisitos do usurio 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 ligao; os requisitos nela relacionados foram apresentados num exemplo de [Sommerville04].

Figura 1.6 - Ligaes de rastreabilidade entre requisitos

1.4.1 Impactos da rastreabilidade num projeto de desenvolvimento de software A rastreabilidade pode auxiliar gerentes e desenvolvedores em vrias situaes comuns ao desenvolvimento de software; a seguir apresentamos algumas destas situaes visando mostrar o papel desempenhado pela rastreabilidade:

verificao da alocao de requisitos a componentes do software: a avaliao dos elos de rastreabilidade de requisitos a artefatos de desenho e implementao identifica requisitos ainda no alocados ou implementados;

verificao e validao: no processo de verificao, a avaliao das ligaes entre requisitos e casos de teste possibilita localizar requisitos para os quais no foram criados procedimentos de teste. No processo de validao do software junto ao cliente, as ligaes entre requisitos e componentes auxiliam a mostrar ao cliente que todos os requisitos foram atendidos pelo software desenvolvido;

anlise de impacto: quando uma solicitao de mudana aceita pelo gerente do projeto, as ligaes entre requisitos e componentes permitem a rpida identificao daqueles que devero ser modificados. Isto auxilia o gerente no processo de reviso do cronograma de desenvolvimento e dos custos previstos para o software;

1.1. o usurio 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

especfico na tela do usurio 1.4. quando um usurio 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

Requisitos de sistema

Requisito do usurio

gerenciamento de riscos: a anlise de riscos de um projeto inclui a identificao de riscos associados a custos e cronograma e de fatores contextuais que possam impactar em requisitos (restries legais, por exemplo). A rastreabilidade apia a identificao de artefatos atingidos por cada fator de risco, possibilitando a elaborao de estratgias para tratamento ou mitigao dos riscos.

1.4.2 Tipos de elos de rastreabilidade Em seu artigo sobre rastreabilidade [Ramesh01], Ramesh&Jarke propem um meta-modelo para a rastreabilidade que possibilita a captura de informaes relacionadas a agentes, fontes e objetos - as trs dimenses dos modelos de rastreabilidade. Nesse meta-modelo os stakeholders so ligados atravs de estruturas de contribuio [Gotel94] aos objetos conceituais que eles influenciam e a documentos onde tais objetos so registrados [Jarke98]. A Figura 1.7, adaptada de [Jarke98], apresenta a viso geral desse meta-modelo; note que so apresentados objetos (relacionados ao produto sendo elaborado) e artefatos que so gerados pelo prprio processo de desenvolvimento. As trs dimenses consideradas correspondem a:

a) Fontes: documentos que remetem origem dos requisitos (normas, padres, legislao pertinente, atas de reunies, ....);

b) Stakeholders: so as pessoas envolvidas no Processo de Requisitos e que tambm 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 bsicas:

a) relacionados ao produto: elos que descrevem propriedades e relacionamentos dos objetos; so subdivididos em elos de satisfao e elos de dependncia;

Fig. 1.7 Meta-modelo para a rastreabilidade de

requisitos [Jarke98]

b) relacionados ao processo: elos relacionados ao histrico de aes executadas no prprio processo; so subdivididos em elos de evoluo e elos de rationale.

O propsito dos elos de satisfao 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 so alocados, para assegurar que todo componente satisfaz a requisitos, registrar fatores crticos de sucesso associados a requisitos e assegurar consistncia entre sadas das diferentes fases do ciclo de vida.

O propsito dos elos de evoluo 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 compreenso dos requisitos e outros objetos (atravs de sua histria) e para registrar as modificaes e histrico de refinamentos dos vrios objetos.

O propsito dos elos de rationale representar as motivaes subjacentes aos objetos existentes ou documentar as razes para evoluo. Estes elos so utilizados para encontrar as justificativas para criao ou modificao de objetos, registrar suposies utilizadas no processo de deciso e identificar o contexto de criao de objetos. Estes elos possibilitam registrar aspectos do processo decisrio, incluindo alternativas descartadas, de forma a providenciar clara compreenso da soluo escolhida, facilitando a manuteno 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 atuao dos interessados, registrando as origens e o contexto no qual os objetos so desenvolvidos.

E finalmente, os elos de dependncia tm por propsito apoiar o gerenciamento de dependncias entre requisitos ou objetos, sendo teis para registrar a composio e hierarquia dos requisitos e apoiar o gerenciamento do impacto das alteraes num requisito sobre os objetos que dele dependem.

1.4.3 Rastreabilidade de requisitos: prtica Problemas relacionados ao registro e uso da rastreabilidade no so recentes: a literatura aponta para dificuldades ou problemas na prtica 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 nvel 2 do CMM onde fossem trabalhadas matrizes de rastreabilidade completas, indicando que cada requisito foi atendido por artefatos de design, implementao e testes. Acreditamos que estes problemas acontecem, em parte, pela inadequao das ferramentas disponveis, e em parte devido s presses relacionadas a prazos para liberao do software no mercado. Alm, claro, da j conhecida falta de cuidado dos desenvolvedores com a documentao do processo de desenvolvimento.

1.4.4 Registro da rastreabilidade Ferramentas disponveis 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 eletrnica (muitas das ferramentas comercialmente disponveis 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 - 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 seqencialmente. As demais colunas devem representar artefatos gerados durante o processo de desenvolvimento; a correspondncia 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 dependncias entre requisitos funcionais e no funcionais; um exemplo bastante comum para sistemas de comrcio eletrnico associa requisitos no-funcionais como segurana a requisitos funcionais relacionados s transaes disponveis ao usurio do sistema.

Tabela 1.2 - Rastreabilidade entre requisitos funcionais e no funcionais

Projeto - Rastreabilidade RF versus RNF

Requisito No-Funcional Requisito Funcional NFR01 NFR02 NFR03 NFR04 NFR05 NFR06

RF01

RF02

RF03

RF04

Entre as ferramentas comerciais disponveis, 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) apia tarefas relacionadas ao gerenciamento de requisitos. Registramos que RequisitePro propicia tambm o registro do rationale subjacente aos requisitos e sua evoluo e a hierarquia entre requisitos de alto nvel aos seus derivados, e que DOORS associado ao toolkit ScenarioPlus possibilita elos entre requisitos e casos de uso, em mltiplas verses, para diferentes configuraes 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 no-

funcionais, no RequisitePro

O INCOSE, International Council on Systems Engineering, mantm uma pgina, periodicamente atualizada, com informaes sobre as ferramentas para apoio ao registro da rastreabilidade (veja em http://www.incose.org/ProductsPubs /products/SEtools/tooltax/reqtrace_tools.html). Outra pgina, mantida pela mesma organizao, apresenta um resumo sobre essas ferramentas, com informaes 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 especficas de cada projeto, possibilitando uma relao custo-benefcio positiva e evitando uma massa excessiva de informaes relacionadas rastreabilidade [Dmges98][Ramesh01]. A definio dos elos a serem capturados deve considerar prazos e custos do projeto em pauta, alm de processos e padres em uso na organizao. Propomos a seguir, apoiados pela nossa experincia, algumas heursticas que podem auxiliar gerente de projeto e equipe na tarefa de definir um modelo de rastreabilidade para o processo de desenvolvimento de um software especfico:

a) definir no incio do projeto, considerando a aplicao a ser desenvolvida, os tipos de elo a serem utilizados e explicitamente registrados;

b) identificar as ferramentas que apoiaro o processo de rastreabilidade; c) conscientizar a equipe da importncia do processo de rastreabilidade

(considere que desenvolvedores no so exatamente conhecidos por seu amor documentao [Jarke98] e que a falta de comprometimento da organizao com a atividade de rastreabilidade responsvel 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 esto sendo registrados pela equipe;

f) utilizar e avaliar o mecanismo de extrao de elos, em relao s expectativas realizadas;

g) aps a liberao do software, analisar criticamente com a equipe a efetividade do modelo de rastreabilidade adotado, corrigindo possveis distores e melhorando-o para os prximos projetos.

1.5. Gerncia da Qualidade de Requisitos O objetivo da gerncia 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 atravs dos seguintes critrios [Young01, Wiegers99]: Necessidade

O sistema capaz de atingir seus objetivos sem este requisito? Caso afirmativo este um requisito desnecessrio

Verificvel possvel verificar que este requisito est sendo atendido pelo sistema? Atingvel O requisito pode ser atendido pelo sistema que est sendo desenvolvido? Livre de Ambiguidades O requisito possui mais de uma interpretao possvel?

Completo O documento de especificao do sistema contm todos os requisitos?

Consistente Todos os requisitos podem ser atendedidos sem que se entre em conflito uns com os outros?

Rastrevel A origem dos requisitos conhecida? O requisito pode ser referenciado e localizado no sistema?

Alocao O requisito pode ser alocado a um elemento ou componente do sistema? Conciso O requisito est descrito de forma simples e concisa? Livre de Implementao

O requisito descreve o QUE deve ser feito sem influncias de possveis implementaes?

Identificador nico

Cada requisito possui um identificador nico que permita com que possamos referenci-lo de forma nica e precisa?

Correo

O requisito contm toda a informao necessria que permita sua implementao?

Priorizvel O requisito passvel de ser priorizado frente aos outros requisitos?

Tabela 1.3 - Critrios de avaliao da qualidade de requisitos

Segundo o CMM, uma das atividades da rea de processo chave, gerncia de requisitos a reviso dos requisitos antes antes de incorpor-los ao projeto. necessrio:

Identificar requisitos incompletos ou ausentes Determinar se os requisitos esto claros, possveis de serem implementados,

consistentes e verificveis Revisar requisitos com problemas potenciais Negociar compromissos com os grupos envolvidos

A maior parte dos requisitos de software para sistemas de informao so escritos utilizando-se linguagem natural. Esta falta de formalidade na captura dos requisitos implica em uma srie de potenciais problemas. Os problemas mais comuns so:

Ambiguidade Falta de clareza ou duplo sentido de frases ou expresses. Este tipo de requisito leva a interpretaes erradas ou inconsistentes das necessidades reais dos usurios.

Exemplo: O sistema deve enviar relatrios de produtividade dos programadores, analistas ou desenvolvedores do projeto mensalmente ou quando requisitado.

Neste caso fica difcil dizer se o usurio quer que seja enviado um ou trs relatrios. A frequncia de envio tambm no est clara. Se um relatrio for enviado em resposta a uma solicitao, a necessidade de envio do relatrio mensal permanece?

Requisitos Incompletos Requisitos que deixam de fora parte da informao necessria sua compreenso.

Exemplos: Curva S (Planejado X Realizado) de um projeto Cadastro de iniciativas estratgicas

Neste caso difcil dizer se o sistema deve plotar a curva S, importar ou s exibir a figura. O mesmo pode ser dito do cadastro. O sistema responsvel por realizar o cadastro (adio, remoo e atualizao), import-lo de outro banco de dados ou apenas exibir?

Requisitos Mltiplos Estes so requisitos que concatenam vrios requisitos em um s. Estes requisitos devem ser separados para facilitar a tarefa de priorizao e gerncia de mudanas.

Exemplo:

No evento de falha da rede eltrica, o sistema deve enviar mensagem de erro ao usurio, salvar a configurao atual do sistema e os dados entrados, at ento.

Neste caso podemos dividir este requisito em dois: envio de mensagem de erro e salvar a configurao do sistema. Perceba que os requisitos tm prioridades diferentes. Claro que salvar a configurao do sistema muito mais importante em caso de falha do que avisar o usurio, que caso a rede eltrica esteja em pane j deve ter percebido o fato sozinho. Requisitos com alternativas So aqueles requisitos que no estabelecem claramente qual deve ser a ao do sistema frente a uma dada situao. De modo geral contm frases do tipo mas, com exceo, apesar, e quando.

Exemplo: O sistema deve mostrar o total do pedido medida que os cdigos dos produtos vo sendo entrados no pedido, a no ser que se trate de um produto promocional.

Neste caso o requisito apresenta o procedimento para duas situaes diferentes e no claro qual seria o procedimento para produtos promocionais. A soluo seria quebrar este requisito em dois, cada um tratando de uma situao distinta.

Requisitos mal escritos So requisitos mal redigidos que podem causar confuso e mal entendidos. Um erro muito comum o excesso de informao

Exemplos: Na improvvel eventualidade de falha no sistema de refrigerao, o sistema deve mandar mensagem para a chave admin. Identificar e associar as intervenes que so complementares s outras

Neste caso fica difcil at entender o requisito. A primeira sentena oferece informao relativa ao ambiente que completamente desnecessria para o sistema. No segundo caso fica difcil entender o que o sistema deve fazer.

Requisitos Inverificveis de conhecimento comum a gerentes de projeto a mxima "voc no pode gerenciar o que no pode medir". Um requisito inverificvel escrito de modo que fica impossvel de assegurar que o sistema capaz de atnde-lo.

Exemplos: O sistema X deve ser seguro O sistema C deve processar depsitos rapidamente

No caso da primeira sentena fica impossvel determinar se o grau de segurana oferecido pelo sistema atende s necessidades dos usurios. Para o requisito de segurana, bem como para todos os requisitos no funcionais devemos NEGOCIAR as estratgias que atendem aquele requisito. Uma possvel soluo para estes requisitos poderia ser: O sistema X deve ser seguro

O sistema X deve parar sua operao se uma pessoa se aproximar a menos de 2 metros de uma de suas partes mveis O sistema X deve desligar os aquecedores se a temperatura da gua exceder 37C MNOP deve estar dentro dos padres estabelecidos pela norma N567 seo 3.6 para temperaturas de superfcies externas.

O sistema C deve processar depsitos rapidamente

O sistema C deve escanear os dados do usurio e conta de cada folheto de depsito em 2 segundos ou menos

Repare que as estratgias de segurana que atendem ao requisito do sistema X no seriam as mesmas para um sistema de compra de livros na Internet por exemplo. Neste tipo de sistema estratgias de segurana poderiam ser implementadas via utilizao de login e senha e criptografia de dados bancrios.

1.5.1 Processos de verificao da qualidade de requisitos Como dito anteriormente, parte do processo de garantia da qualidade de software consiste na realizao peridica dos os requisitos do projeto. Este processo, segundo o CMM, deve ser realizado tanto pela gerncia snior quanto que pelos gerentes de projeto e de qualidade, da seguinte maneira:

A gerncia snior deve revisar, periodicamente, todas as atividades de gerncia dos requisitos de software O gerente do projeto deve revisar, periodicamente e quando da ocorrncia de eventos, todas as atividades de gerncia 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 mnimo, as seguintes verificaes:

Reviso dos requisitos de software Planos de software Artefatos e produtos de trabalho Atividades da gerncia de requisitos

Na literatura da rea encontramos vrias tcnicas, formais e informais, para a realizao de verificao de requisitos de software. Uma das mais utilizadas a tcnica de inspees, criada por Fagan em 1972, visando aumentar a qualidade de software e a produtividade dos programadores. Inicialmente pensada para a identificao de defeitos na estrutura e no cdigo de programas, ela foi posteriormente ampliada para aplicao em outros artefatos de software [Fagan86] (como requisitos, especificaes, arquitetura, planos de teste), sendo atualmente bastante utilizada por desenvolvedores de software. A literatura aponta que o processo de inspeo pode detectar de 30% a 90% dos erros existentes nos artefatos gerados num processo de desenvolvimento de software [Laitenberger01], [Blackburn01].

1.5.2 Inspees4 O processo de inspeo caracteriza-se pela leitura cuidadosa de um artefato com utilizao de uma tcnica de leitura, buscando a localizao de erros ou defeitos no mesmo, segundo um critrio pr-estabelecido. A inspeo aplicvel a praticamente todos os tipos de artefatos, sendo possvel utilizar diferentes tcnicas de leitura. A tcnica escolhida deve identificar as informaes a serem verificadas e apoiar a localizao de defeitos nestas informaes. Apresentaremos brevemente as tcnicas de leitura baseadas na experincia do inspetor (ad-hoc) e as baseadas em checklists e em perspectivas. Inspees envolvem anlises criteriosas do artefato, considerando aspectos de qualidade que devem ter sido atendidos na sua elaborao. O processo de inspeo compreende vrias etapas, iniciando pela coleta dos artefatos a serem utilizados e/ou analisados, passando pela inspeo propriamente dita e chegando ao acompanhamento da correo dos defeitos encontrados. Diversas tcnicas de leitura foram propostas e esto em uso corrente; geralmente algum treinamento necessrio para sua efetiva aplicao. Os participantes desempenham diferentes papis, dependendo da etapa em desenvolvimento, e tambm do grau de conhecimento e envolvimento no projeto.

1.5.3 Etapas do processo de inspeo As etapas do processo de inspeo so esquematizadas na figura 1.9 e esto descritas a seguir:

4 parte do texto sobre inspees foi originalmente publicada em [Sayo03]

Figura 1.9 Etapas do processo de inspeo

Planejamento: nesta etapa inicial do processo, uma pessoa da organizao, envolvida diretamente ou no no projeto, responsabilizada pela organizao e conduo geral da inspeo. Os participantes so selecionados e recebem atribuies correspondentes aos papis que iro desempenhar, e definida uma data para a realizao da reunio de inspeo. O material a ser utilizado (artefatos a serem inspecionados e check lists especficas para cada tipo de artefato) reproduzido e distribudo aos participantes; Viso geral: no incio da reunio de inspeo, cuja durao deve ser definida previamente, o autor apresenta o artefato a ser inspecionado aos participantes; tambm pode ser passada a viso geral do projeto. Esta fase considerada particularmente interessante nas fases iniciais do projeto, que o caso da inspeo em artefatos de requisitos; Inspeo: durante a reunio, inspetores avaliam o artefato e registram os defeitos encontrados. A inspeo pode ser realizada de forma individual pelos inspetores, com maior ou menor grau de interao entre eles; Coleo: defeitos so reunidos e registrados num documento nico. Pode haver uma reviso nos defeitos relatados, verificando-se tambm se eles realmente correspondem a defeitos que necessitam de correo. A comunicao dos defeitos encontrados pode ser feita durante uma reunio com a presena dos inspetores e os autores do artefato, e neste caso interessante a presena do moderador; ou ento o autor do artefato sendo avaliado recebe o documento com os defeitos consolidados; Correo: o artefato retorna para que os defeitos detectados sejam corrigidos pelos desenvolvedores; Acompanhamento: so efetuados o acompanhamento e verificao da correo dos defeitos apontados no processo de inspeo. Se o nmero de defeitos for significativo, o coordenador pode determinar nova inspeo sobre o artefato revisado. No processo de inspeo existem diferentes papis a serem desempenhados pelos participantes. O organizador aquele que se responsabiliza pela organizao e conduo do processo como um todo, coletando documentos e informaes necessrias, selecionando os participantes de acordo com seu perfil, distribuindo os papis, agendando encontros e acompanhando a correo dos defeitos. O autor do artefato apresenta uma viso global do mesmo, antes da inspeo ser efetuada. O inspetor analisa os artefatos, seguindo uma tcnica de leitura pr-definida, anotando os defeitos encontrados e repassando-os ao secretrio; este ltimo rene os defeitos encontrados pelos vrios inspetores, consolida-os num documento e os repassa ao moderador. O moderador tambm conduz a reunio de inspeo, e deve ter experincia na conduo de trabalhos em equipe. O relator apresenta os defeitos coletados aos autores do artefato; esta reunio tem ainda a presena do moderador, para mediar e resolver eventuais conflitos, e do secretrio, que registra o encontro.

Das tcnicas 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 tcnicas j foram validadas em processos experimentais e esto em uso na indstria de desenvolvimento de software [Laitenberger01].

1.5.4 Ad-hoc A tcnica de leitura ad-hoc fortemente baseada no conhecimento e na experincia do inspetor; no h suporte tcnico para indicar quais informaes checar e como identificar defeitos nessas informaes. Isto no significa que as inspees com esta abordagem no sigam critrios adequados, mas apenas indica que os critrios e mtodos adotados na anlise/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 tcnica de leitura so: clareza (os requisitos esto bem determinados?), completude (esto presentes todos os requisitos necessrios especificao do sistema?), consistncia (os requisitos so consistentes com a viso geral do sistema?), corretude (os requisitos descrevem as funcionalidades de maneira correta?), funcionalidade (as funcionalidades descritas so necessrias e suficientes para atingir os objetivos do sistema?), testabilidade (as funcionalidades permitem a verificao ou teste de forma a mostrar que os requisitos so satisfeitos?) e detalhamento (o nvel de detalhe nos requisitos suficiente para fornecer uma base adequada ao design do sistema?).

1.5.5 Baseada em checklists Na tcnica de leitura baseada em checklists, j consolidada na indstria, o conjunto de inspetores utiliza uma mesma lista para a leitura e anlise 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 especfica (Documento de Requisitos, Casos de Uso, Cenrios, Lxico Ampliado da Linguagem, Diagramas de Classes, Plano de Testes, Casos de Teste, Cdigo, ...). Essas listas so adaptveis, e podem levar em considerao os defeitos de maior ocorrncia nos sistemas desenvolvidos naquele ambiente. Um dos efeitos colaterais desta abordagem que, com o uso freqente de inspees, os desenvolvedores tendero a colocar maior ateno nos pontos que originam esses defeitos, e conseqentemente dever diminuir o nmero desses defeitos nos artefatos de software. Por outro lado, defeitos de tipos no caracterizados na checklist no sero detectados; para diminuir esses problemas, deve-se procurar seguir algumas regras bsicas na construo da lista: a) uma pgina deve ser suficiente para relacionar as questes a serem respondidas; b) as questes devem ser objetivas e precisas e c) os atributos de qualidade que devem estar presentes no artefato devem ser claros, e as respostas s questes devem assegurar que tal atributo se encontra ou no presente.

Esta tcnica de inspeo, quando aplicada a artefatos de requisitos (casos de uso, cenrios, documento de requisitos, glossrios, lxico ampliado da linguagem), pode detectar os seguintes tipos de defeitos:

sintaxe incorreta nos artefatos (as sentenas/termos no seguem a sintaxe estabelecida)

informao inconsistente entre artefatos (smbolos definidos num artefato e no referido em outros; smbolos utilizados mas no definidos; descrio no condizente com o smbolo; sinnimos incorretos)

requisitos no funcionais no explicitados informao ambgua (smbolos, termos ou sentenas que possam

provocar diferentes interpretaes) informao desnecessria (por exemplo, atores em excesso) ausncia de informao (por exemplo, atores, pr ou ps-condies em

casos de uso) excees no previstas

1.5.6 Baseada em perspectivas O processo de inspeo baseado em perspectivas, ou PBR (Perspective Based Reading), caracteriza-se por considerar as diferentes perspectivas (vises) dos atores do processo [Shull00] [Porter95] e aplicvel a artefatos de requisitos, design e cdigo. Enquanto na leitura baseada em checklists todos os inspetores utilizam uma mesma lista de questes, nesta abordagem existem listas e procedimentos diferentes para cada perspectiva ou viso. Esta tcnica considera que os diferentes agentes envolvidos no processo de desenvolvimento vem os artefatos sob diferentes pontos de vista e portanto os revisores para o processo so selecionados de acordo com a utilizao que faro do artefato, por exemplo: usurio final, projetista, programador, representante da equipe de manuteno, executor de testes e outros. Um documento de requisitos pode ser visto atravs de diferentes vises: o usurio final deseja ver ali refletido o conjunto de funcionalidades a ser atendido pelo software; o projetista ir utiliz-lo como base para a criao da estrutura do software, considerando as funcionalidades e restries descritas, e o testador ver o documento de requisitos como fonte primeira para a gerao dos testes, que devero assegurar que o mesmo atende s necessidades (funcionais e no funcionais) registradas. As listas utilizadas pelos diferentes inspetores no so genricas, sendo adaptadas a cada organizao; para sua gerao so considerados as metodologias adotadas no ciclo de desenvolvimento, o ambiente operacional em uso, o grau de experincia e conhecimento dos desenvolvedores e os problemas de maior ocorrncia nos produtos j desenvolvidos pela equipe de desenvolvimento em questo. Outra importante diferena desta tcnica de leitura em relao s tcnicas de leitura ad-hoc ou baseada em checklists est relacionada atuao dos inspetores: enquanto que nas duas primeiras os inspetores limitam-se a avaliar e registrar os

defeitos encontrados, na PBR os inspetores possuem a atribuio adicional de criar um modelo voltado sua viso, e avaliar criticamente os requisitos e o modelo seguindo uma lista de questes. 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 anlise e, ao mesmo tempo, verificar se as informaes presentes nos requisitos so adequadas para a gerao desses testes. Aps isto, analisa criticamente o caso de testes gerado e avalia se ele atende aos requisitos de qualidade estabelecidos por um conjunto de questes 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 tcnica de inspeo, quando aplicada a artefatos de requisitos (cenrios, documento de requisitos, lxico ampliado da linguagem), pode detectar os seguintes tipos de defeitos:

ausncia de informao (definio de termos, unidades de medida,...) informao ambgua (vrios significados possveis para um nico termo) informao inconsistente (quando existem requisitos em conflito) fatos incorretos (fato que no pode ser verdadeiro nas condies

especificadas para o sistema) informao desnecessria (excesso de informao pode confundir os

usurios) outros tipos de defeitos (defeitos no classificados em nenhum dos tipos

anteriores, como por exemplo requisito em seo incorreta)

1.5.7 Automao, custos e benefcios da inspeo A utilizao das inspees tem sido bem aceita pelos desenvolvedores, e o treinamento, quando necessrio, exige apenas de um a dois dias de trabalho. A realizao de uma inspeo envolve um total de 10 a 20 horas de trabalho: cada participante necessita de uma a duas horas para as atividades de preparao e mais uma ou duas horas para a inspeo propriamente dita. Nesta geralmente participam de 4 a 5 pessoas, incluindo o organizador, que necessita de um pouco mais de tempo para a preparao do processo e posterior acompanhamento da correo dos defeitos. No h consenso sobre o modo da execuo da inspeo: ela tanto pode ser efetuada individualmente pelos inspetores, ou ocorrer numa reunio com presena adicional de um moderador. Alm da melhoria de qualidade resultante nos artefatos inspecionados (de 30% a 90% de defeitos so localizados em inspees) a prtica tem registrado que, a partir do envolvimento das equipes no processo de inspeo, um dos resultados a diminuio de erros nos projetos posteriores e conseqentemente diminuio do tempo do ciclo de desenvolvimento e aumento da produtividade. Os resultados obtidos com utilizao das tcnicas de leitura ad hoc e checklists, largamente aplicadas nas empresas, so equivalentes [Porter95]. A especificao de requisitos pode utilizar tanto uma linguagem formal quanto a linguagem natural. A utilizao da linguagem natural mais freqente, pois favorece o

entendimento por parte de todos os envolvidos no processo de desenvolvimento, o que no acontece quando se utiliza uma linguagem formal. Artefatos de requisitos escritos em linguagem natural costumam seguir um conjunto bsico de regras de sintaxe, visando a diminuio da ambigidade e aumento da clareza e conciso do documento. possvel automatizar a verificao da sintaxe com um analisador lxico, e tambm a verificao cruzada de artefatos (por exemplo glossrios, casos de uso e documentos de requisitos). Independente do processo de inspeo ser manual ou automatizado, a relao custo/benefcio bastante positiva: dados coletados em inspees efetuadas em diferentes empresas mostram que o retorno do investimento (economia estimada/custo da inspeo) da ordem de quatro a oito, independente do contexto de aplicao (requisitos, desenho, cdigo ...) [ONeill99].

Bibliografia Nesta seo inclumos algumas das publicaes 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 Bsicos [Breitman99] - Breitman, K.K., Leite, J.C.S.P., Finkelstein, A. - The Worlds 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.

Produo de Requisitos [Batista03] Batista, Edinelson; Carvalho, Ariadne - Uma taxonomia facetada para

tcnicas de elicitao 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 (ICRE00) 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 Simpsio 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. Dpartement dIngnierie 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.

Pgina de Early Aspects: Aspect Oriented Requirements Engineering. http://www.early-aspects.net/

Gerncia 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. Disponvel em . 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. Disponvel em . Acesso em 13 set 2002.

[ONeill99] O'Neill, Don. National Software Quality Experiment: Results 1992-1999. In: SOFTWARE TECHNOLOGY CONFERENCE, 12th, 2000, Salt Lake City. Proceedings. STC Disponvel em . Acesso em 18 set 2002.

[Sayo03] Sayo, M.; von Staa, A. & Leite, J. C. S. P. Qualidade em Requisitos relatrio tcnico 47/03, srie Monografias em Cincia da Computao, DI/PUC-Rio, 2003.

[Sayo05] Sayo, M. & Leite, J. C. S. P. Rastreabilidade de Requisitos relatrio tcnico 20/05, srie Monografias em Cincia da Computao, 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. Disponvel em . Acesso em 13 set 2002.

Gerncia [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 Ingeniera 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 Prtica, 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.