Uma Estratgia para Implantao de uma Gerencia de Requisitos Visando a Melhoria Dos Processos de Software

Ana Elizabete Souza de Carvalho, Helena Cristina Tavares, Jaelson Brelaz Castro
Centro de Informtica, Univesidade Federal de Pernanbuco {ana-elizabete.carvalho, helena-cristina.tavares}@serpro.gov.ar, jbc@cin.ufpe.br Resumo. A indstria de software vem demonstrando crescente interesse em engenharia de requisitos, isto , entender o que se deseja construir antes de comear a faz-lo. Esto percebendo que o tempo utilizado no entendimento do problema um excelente investimento. Os requisitos de software so a base a partir da qual a qualidade medida. Desta forma, a falta de conformidade aos requisitos significa falta de qualidade. O modelo de avaliao de maturidade do processo de desenvolvimento CMM (Capability Maturity Model) considera o gerenciamento de requisitos como sendo uma das primeiras etapas para alcanar a maturidade organizacional, e para haver o gerenciamento preciso que o processo de desenvolvimento de requisitos esteja implantado na empresa. Desta forma, para se alcanar a gerncia de requisitos necessrio que os requisitos tenham sido definidos, e importante que a empresa tambm possua seus processos de desenvolvimento de requisitos definidos. Este artigo tem por objetivo definir uma estratgia para a implantao dos processos de desenvolvimento e gerenciamento de requisitos para os projetos de desenvolvimento e manuteno de software sob responsabilidade do SERPRO, estabelecendo um entendimento comum entre o cliente e a equipe de projeto quanto aos requisitos que sero atendidos no projeto de software. Palavras chaves: requisitos, processos, gerenciamento.

1. Introduo
Ultimamente tem havido um grande interesse na comunidade de engenharia de software na melhoria do processo. As empresas precisam medir a sua capacidade de desenvolver software com qualidade. Para isto, esto utilizando o modelo CMM (Capability Maturity Model), que um modelo gerencial que organiza as melhores prticas existentes, embora os padres e as prticas que so aplicveis no sejam completamente definidos. Em geral, o desenvolvimento de software comercial responde rapidamente s mudanas tecnolgicas [1]. Por isso, importante investir no processo de melhoria contnua para o aumento da qualidade focalizando a engenharia de requisitos. Encontram-se algumas tentativas de uso de requisitos nas organizaes mas, infelizmente, as tentativas comeam pela fase do gerenciamento do ciclo de vida e rastreabilidade dos requisitos, iniciada por um processo de avaliao de maturidade do nvel organizacional SEI-CMM [2], sem antes ter o domnio da importante fase de descobrimento de requisitos, a partir do descobrimento dos fatos e fenmenos do 32

ambiente ou domnio da aplicao [3]. Por isso, importante que a empresa tambm possua seus processos para o desenvolvimento de requisitos definidos. Na prxima Seo, descrita a importncia da Qualidade de Software e o contexto do SERPRO. Na Seo 3, os processos a serem executados para a implantao da Gerncia de Requisitos que foram definidos pelo SERPRO so descritos. Na Seo 4, as fases utilizadas para a implantao dos processos para a gerncia de requisitos definidos so descritas. Na seo 5 feito um mapeamento entre a proposta apresentada e as prticas do CMM para a Gerncia de Requisitos. Uma descrio breve do estudo de caso apresentada na Seo 6 e, a Seo 7 composta das concluses e trabalhos futuros.

2. Importncia da Qualidade de Software

A cada dia, as empresas tornam-se mais dependentes dos seus sistemas de informaes. Construir esses sistemas, em tempo hbil para serem teis aos negcios, com a qualidade e custos adequados sua importncia para a organizao, o desafio que todos os desenvolvedores esto enfrentando. Pressman define qualidade de software como conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padres de desenvolvimento claramente documentados e a caractersticas implcitas que so esperadas de todo software profissionalmente desenvolvido [4]. Diversos modelos, ferramentas e propostas tem sido projetadas, desenvolvidas e sugeridas nos ltimos anos, visando permitir as empresas a se capacitarem evolutivamente para o projeto de software, agregando cultura empresarial mecanismos de medies e controle, bem como de evoluir toda a tcnica utilizada sempre que necessrio. Entre as abordagens para a melhoria da qualidade, destaca-se aquela que atua nos processos utilizados por uma organizao de software. O modelo CMM (Capability Maturity Model) foi desenvolvido para guiar a melhoria da qualidade, por meio da maturidade da capacidade dos processos de software. A capacitao do processo permite uma maior previsibilidade de desempenho. A maturidade de um processo de software de uma organizao ajuda a prever a habilidade em atingir suas metas. Quanto maior for a capacidade do processo, mais benefcios podem ser alcanados, tanto para o cliente (interno ou externo) quanto para os desenvolvedores [5]. O CMM um modelo utilizado para medir a maturidade de uma organizao nos seus processos de desenvolvimento de software. um modelo gerencial que organiza as melhores prticas existentes. Segundo o modelo CMM, quanto maior o controle sobre o processo de desenvolvimento, mais madura a organizao. organizado em cinco nveis de maturidade, considerados como a principal caracterstica do modelo. Nvel de maturidade um estgio evolutivo bem definido para alcanar um processo de software maduro. Cada nvel de maturidade indica um nvel de capacidade do processo, visando a melhoria contnua do processo de desenvolvimento de software [6]. Com exceo do nvel 1, cada nvel composto por vrias reas-chave de Processo (ACPs). Estas reas conduzem ao alcance das metas de melhoria de um determinado nvel [7]. 33

A primeira ACP do CMM para atingir o Nvel 2 (figura 3) a Gerncia de Requisitos, a qual estabelece as diretrizes para um comum entendimento entre o cliente e os requisitos de seu projeto de software, que sero conduzidos pela equipe do desenvolvimento. Este acordo com o cliente a base para planejar e administrar o projeto de software. O controle das relaes com o cliente depende de um efetivo controle do processo da mudana. Mas, para que a Gerncia de Requisitos seja implantada na organizao necessrio que um processo de Engenharia de Requisitos esteja implantado. Como Empresa de Tecnologia da Informao, o SERPRO atua num mercado em permanente ebulio, por isso iniciou um processo para identificao e implantao das melhores prticas para elevar o estgio de maturidade do processo de desenvolvimento de software. Impulsionando este processo est a meta de atingir o nvel 2 de maturidade segundo o modelo CMM (Capability Maturity Model) do SEI at o final de 2002. E, os trabalhos iniciais verificaram que a falta de uma efetiva gerncia de requisitos um dos principais problemas a serem superados. Dando incio estruturao interna de uma gerncia de requisitos, o SERPRO participou do projeto Plataforma Tecnolgica em Engenharia de Requisitos Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas [8], o qual teve como objetivo estabelecer bases para o aumento da qualidade dos processos de produo de software, por meio da cooperao entre universidades e empresas, com nfase na utilizao da Engenharia de Requisitos. A plataforma foi extremamente importante para um melhor conhecimento dos problemas enfrentados pelas organizaes que participaram do projeto e da possibilidade da cooperao com as instituies de pesquisa para minorar esses problemas. Identificados os problemas, os processos a serem executados para a implantao da Gerncia de Requisitos foram definidos pelo SERPRO e so descritos na prxima Seo.

3. O Processo para Implantao da Engenharia de Requisitos visando a melhoria da Qualidade de Software

A definio dos processos para a gerncia de requisitos implantados no SERPRO foram baseadas nas boas prticas existentes na empresa, na cultura da organizao e nas caractersticas de seus clientes. Pesquisas em bibliografia existente, o apoio de instituies de pesquisa e a utilizao de benchmarking foram importantes para o desenvolvimento do projeto. A figura 1 resume a estrutura adotada. Para alcanar as metas, algumas atividades precisam ser executadas por pessoas com papis bem definidos. O responsvel por analisar e selecionar os requisitos coleta os requisitos de software, os quais so revistos pelo Grupo de Engenharia de Software antes de sua incorporao no projeto. Uma vez incorporados, os requisitos formam uma baseline, que ser a base para o Contrato Tcnico entre o cliente e o desenvolvedor. Depois de validados, os requisitos so utilizados pelo Grupo de Engenharia de Software para planejar os artefatos e as atividades do desenvolvimento que iro compor o Plano de Desenvolvimento de 34

Software. Os desvios e as solicitaes de alterao de requisitos so revistos antes de serem incorporados, seus impactos so avaliados, e os compromissos assumidos so renegociados com as partes interessadas (stakeholders).

Meta 1- Requisitos so controlados e a baseline estabelecida para a Gesto da Engenharia S f Requisitos de Sistemas (alocar Hb2) responsvel por analisar e alocar os requisitos (Hb1)

Grupo de Eng. de Software

Rever os Requisitos antes de serem incorporados ao projeto (At1)

Requisito de Software Requisitos Validados Baselinede Requisitos: Contrato Tcnico (Hb2)

Usar os Requisitos para planejar os Artefatos e Atvidades(At2)

PDS - Plano de Desenvolvimento de Software

Grupo de Eng. de Software

Novas Baselines

Desvios e SAR'sSolictaes ( de Alterao de Requisitos)

Rever as Mudanas e incorporar as alteraes apropriadas (At3)

Meta 2- Planos, produtos, atividades so mantidas consistentes com os Requisitos SAR - Solicitao de Alterao de Requisitos Avaliar impactos e renegociar compromissos Notificar / Renegociar Partes Interessadas

Habilidade Hb) ( Atividade (At) Subatividade Plano

Responsvel por analisar e alocar os requisitos (Hb1)

Figura 1. rea-Chave de Processo Gerncia de Requisitos Os processos devem definir as atividades que devero ser executadas para que as metas sejam atingidas. Nesta proposta, os processos da Gerncia de Requisitos foram divididos em: Definio, Gerenciamento & Mtricas, Validao e Verificao (figura 2) e definem as atividades a serem executadas por uma empresa que desenvolve sistemas a partir das solicitaes de um cliente. Ao receber uma Solicitao de Servio, o processo de Definio elabora o documento de Viso, o Glossrio, o Documento de Requisitos de Software (DRS) e as Matrizes de Rastreabilidade. Caso uma Solicitao de Alterao de Requisitos (SAR) seja recebida, o processo para Gerenciamento & Mtricas de requisitos, juntamente com as Matrizes de Rastreabilidade e o Documento de Requisitos de Software (DRS), analisa os requisitos impactados, gera uma nova verso atualizada dos requisitos (baseline), atualiza o Documento de Requisitos de Software (DRS) e comunica as alteraes s reas envolvidas. Neste processo tambm so coletadas as mtricas para controle. Durante o processo de Validao, o Documento de Requisitos de Software (DRS) e demais artefatos so avaliados para a elaborao dos Casos de Testes, alm das comunicao das reas envolvidas. O processo de Verificao recebe os artefatos dos modelos do processo de desenvolvimento e avalia se esto de acordo com os requisitos definidos. 35

As figuras 2 e 3 so apresentadas apenas com as entradas e sadas da tcnica IDEF0. A Tabela 1 descreve as principais entradas e sadas dos processos descritos anteriormente.
Solicitaa de SAR' 1 A DR Gerenciament e 2 A Valida 4 SAR' Verifica Artefato 3 A Atas de Notificao para reas SAR' Casos de Notificao para reas Vis Defini

Plano de Glossri Matrize Requisito Impactado Nova DRS Mtrica Notificao para reas

Figura 2. Grupos de Processos para a obteno da Gerncia de Requisitos A figura 4 apresenta o detalhamento do processo para a definio de requisitos que foi exibido no macroprocesso da figura 2. composto de Elicitao, Anlise &Documentao e Negociao & Priorizao (figura 4). O processo de Elicitao dos Requisitos de Software recebe novos requisitos por meio de uma Solicitao de Servio ou Solicitao de Alterao de Requisitos entre outras fontes, e uma vez documentados e analisados, so elaboradas as Matrizes de Rastreabilidade e o Documento de Requisitos de Software (DRS) entram num processo para negociao de prioridades, conforme detalhado a seguir. A Elicitao pode ser subdividida nas seguintes atividades, e seguem a ordem seqencial e o paralelismo explicitado na figura 6 a qual utiliza o diagrama de atividades da UML [9]: Efetuar a reunio inicial com o cliente: Devem participar da reunio inicial com o cliente todos as partes interessadas (stakeholders) candidatos. Nesta reunio devem ser obtidos os principais assuntos que devero estar presentes no Documento de Viso.

36

ENTRADA TIPO OU SADA Solicitao entrada de Servio SAR (Solici- entrada tao de Alterao de Requisitos)

DESCRIO

Refere-se ao documento formal por meio do qual o sistema solicitado pelo cliente. Documento que deve ser preenchido quando h necessidade de alterao ou incluso de requisitos. Especifica e documenta a alterao de requisitos solicitada pelo stakeholder, estabelecendo as bases para sua execuo, e condies de execuo (prioridades, recursos envolvidos, recursos afetados, etc). Viso sada Referem-se a informaes gerais sobre o sistema. Documento onde fornecido o objetivo do sistema a ser desenvolvido; suas principais caractersticas, funcionalidades e no-funcionalidades; os stakeholders. Seu objetivo apresentar o sistema em linhas gerais, fornecendo uma viso inicial. Documenta o ambiente geral de processos a ser desen-volvido, fornecendo a todos os envolvidos uma descrio compreensvel do sistema e suas macro-funcionalidades. O objetivo do documento Viso definir as necessidades de alto-nvel e caractersticas do sistema, focando nas potencialidades requeridas pelos stakeholders e como estes requisitos sero abordados no sistema. Glossrio entrada O objetivo do glossrio fornecer uma terminologia comum sobre o e sada projeto a todos os envolvidos. Este conjunto de termos e conceitos originais usado para definir um mapeamento especfico sobre o domnio do problema, explicando os itens mais relevantes e as descries de outros componentes do projeto. Alm de facilitar o entendimento da aplicao, o Glossrio evita ambigidades no entendimento das informaes, ao longo do processo. Rastreabilida entrada Neste contexto, as Matrizes de Rastreabilidade mostram os de e sada relacionamentos entre os requisitos elicitados. DRS (Docu- entrada composto pelo detalhamento dos requisitos. A DRS guarda a mento de e sada especificao dos requisitos de software, descritos num nvel de Requisitos detalhe que possibilite o entendimento de todos os envolvidos. A DRS de serve como base de comunicao entre os stakeholders, e ajuda a Software) manter um foco integrado no desenvolvimento. Requisitos sada Referem-se aos requisitos que sero alterados em decorrncia da Impactados incluso ou alterao de requisitos. Nova sada Baseline ou configurao base um conjunto de requisitos aprovados Baseline e revisados que representa o embasamento de um acordo de evoluo e desenvolvimento; atualizada por meio da incluso ou alterao de requisitos. DRS sada Corresponde ao Documento de Requisitos de Software alterado em atualizado funo da incluso ou alterao de requisitos. Notificao sada Refere-se comunicao a todos os que sero impactados pela as reas incluso ou alterao de requisitos. envolvidas Mtricas sada Informaes coletadas ao longo do gerenciamento de requisitos. Casos de sada Devem estar includos no DRS (Documento de Requisitos de Testes Software). Atas de sada Ser utilizada a Ata de Reunio para registrar as no-conformidades. Verificao Plano de sada Ser utilizado a Ata de Reunio para registrar os compromissos de Reviso reviso.

Tabela 1. Entradas e Sadas dos processos descritos 37

Entender o domnio da aplicao: A reunio inicial com o cliente fornecer a base para determinar quais os principais domnios sero necessrios estudar mais profundamente para o desenvolvimento do sistema. Uma das principais dificuldades enfrentadas pelo desenvolvedor de software a complexidade do domnio do problema [10]. Alm disso, os usurios e desenvolvedores possuem perspectivas diferentes e fazem suposies diferentes sobre a natureza da soluo [11]. Quando o desenvolvedor e o usurio compartilham a mesma linguagem, melhora a comunicao entre ambos. Em particular, se esta linguagem prpria do usurio esta comunicao melhora consideravelmente [12]. Identificar as partes interessadas (stakeholders): Identifique as pessoas interessadas pelo produto, ou participaro do seu desenvolvimento. Para cada stakeholder importante identificar alm da funo, o nome do stakeholder.
Glossrio

Solicitao de Sistemas

Requisitos de Software

Elicitao dos

Documentao

& Anlise
SAR's

DRS

Negociao &
Priorizao

DRS

1 A11
Viso

2 A12 Matrize s (Acompanhamento

e rastreabilidade)

3
A1

Plano de Reviso

Figura 3. Processos para a Definio de Requisitos Escolher a tcnica de elicitao: Ao escolher a tcnica de elicitao deve-se considerar quais as fontes dos requisitos, a disponibilidade das pessoas e os tipos de requisitos a serem elicitados. A escolha da tcnica apropriada para elicitar requisitos depende do tempo e recursos disponveis, assim como do tipo de informao necessria. Algumas das classes de tcnicas de elicitao so [13]: o Tcnicas tradicionais inclui o uso de questionrios, entrevistas, anlise de documentao existente [14]; Questionrios: questes predefinidas so distribudas para uma amostragem significante e representativa de stakeholders e os resultados so avaliados. So teis quando a quantidade de stakeholders extremamente grande. Uma vez que todas as questes podem ser predeterminadas, mais eficiente na avaliao de tendncias de opinies a respeito de requisitos especficos e bem definidos. Entrevistas: Perguntar questes relacionadas aos stakeholders e/ou suas necessidades a respeito do problema a ser resolvido e 38

escutar suas respostas [15]. So teis quando stakeholders possuem muitos conhecimentos subjetivos e esto dispostos a serem entrevistados. Para ser mais eficiente, o entrevistador deve ser experiente. Tcnicas de elicitao de grupo so tcnicas de dinmica de grupo com o objetivo de entender de forma mais detalhada as necessidades dos usurios, esto includas: brainstorming, sesses JAD e RAD [16]; Brainstorming: stakeholders so reunidos em um local, num ambiente que encoraje a participao, permitindo que todas as idias sejam declaradas em voz alta (para que os demais sejam influenciados) e escritas (para que no sejam perdidas) [17]. mais eficaz quando cada stakeholder possui uma parte do conhecimento de algum aspecto do problema. Prototipao implementao parcial de um sistema de forma rpida para obter feedback para o processo de requisitos. O prottipo descartado. utilizada para elicitar requisitos quando h um alto grau de incerteza ou quando necessrio um rpido feedback dos usurios; Tcnicas de modelagem fornece um modelo especfico das informaes que sero adquiridas, e usa esse modelo para orientar o processo de elicitao. Uma tcnica bastante utilizada o uso de cenrios para representar as tarefas que os usurios executam normalmente e aquelas que eles desejam executar [18]. Inclui mtodos baseados em metas, tais como: KAOS [19] e I* [20] e mtodos baseados em cenrios como CREWS [21]. Tcnicas cognitivas inclui uma srie de tcnicas originalmente desenvolvidas para aquisio de conhecimento para sistemas baseados em conhecimento, alguns exemplos so: Anlise de protocolo, laddering, card sorting, repertory grids [22]; Tcnicas contextuais surgiu como uma alternativa para as tcnicas tradicionais e cognitivas, inclui tcnicas de etnografia e anlise social [23]; Etnografia: observar potenciais usurios em seu ambiente natural. Resulta em uma percepo mais precisa do problema do que perguntar aos usurios o que eles fazem [24]. So teis para suporte automao de uma funo pouco ou no automatizada, particularmente quando so disponveis a observadores treinados sem noes preconcebidas do problema e de sua soluo.

Condies especficas do projeto devem definir a tcnica mais eficaz a ser utilizada [25], ou a combinao delas. No SERPRO, as tcnicas mais utilizadas so a entrevista, o uso de cenrios com Use Cases e a prototipao, com o acompanhamento do cliente no s na fase de requisitos, mas durante todo o processo de desenvolvimento do software. Um benefcio o comprometimento do cliente e a participao direta na definio dos 39

documentos. Um cuidado, porm, deve ser tomado para a tendncia da no utilizao dos processos para alterao de requisitos.
Incio Efetuar a reunio inicial com o Cliente
C1 . .

Escolher e executar Tcnicas de Elicitao

C2 .

Identificar os stakeholders .

Entender o domnio da aplicao

Elaborar a lista de Requisitos Candidatos Estudar: os Requisitos candidatos sistemas similares e os documentos do cliente
C3

Elaborar o Glossrio
C4

Elaborar o documento de Viso

Fim

Figura 4. Processos para a Elicitao de Requisitos Elaborar a lista de Requisitos Candidatos: o objetivo desta atividade descrever os principais requisitos do sistema, de forma a obter a essncia do sistema, de forma que representar as principais necessidades e funcionalidades do sistema e dever ser includa no documento de Viso. Estudar os Requisitos Candidatos, os sistemas similares e os documentos coletados com o cliente: documentos devem ser inspecionados, arquivos e sistemas similares, para melhor compreender o contexto do sistema, e avaliar a possibilidade de reusabilidade de requisitos e de solues. Elaborar o Glossrio: para evitar ambigidades e facilitar a leitura de documentos do sistema, importante a definio de um glossrio, onde os principais termos utilizados pelo domnio da aplicao e pelos desenvolvedores e usurios devem ser definidos. Elaborar o documento de Viso: o objetivo desta atividade descobrir os principais requisitos do sistema, de forma a obter a essncia do sistema. Deve-se avaliar o conjunto de requisitos essenciais para a definio do Documento de Viso do software e este deve incluir o escopo do projeto e suas limitaes, bem como as principais caractersticas do software a ser desenvolvido.

A Documentao & Anlise (figura 7) deve possuir as seguintes atividades: 40

Descrever os requisitos e os seus atributos: depois que os requisitos do sistema so elicitados, eles devem ser documentados com um nvel apropriado de detalhes. Na maior parte das organizaes os requisitos so escritos em linguagem natural, pois uma notao que de fcil entendimento para uma grande variedade de stakeholders. Entretanto, o nvel de abstrao dos requisitos varia de acordo com a organizao e deve ser definido de acordo com o projeto ou at mesmo com o tipo de requisito. O principal foco da pesquisa em documentao de requisitos prover notaes e linguagens de especificao. Desde linguagem natural [26] lgica [27], diferentes linguagens tm sido propostas para expressar e descrever requisitos. Pesquisas atuais tm reconhecido que o gerenciamento de requisitos uma atividade crucial no processo de engenharia de requisitos, ou seja, necessrio no somente escrever os requisitos de forma entendvel mas tambm permitir que eles possam ser rastreados e gerenciados ao longo da evoluo do sistema [28].
Incio

Descrever os Requisitos e seus atributos C1 Analisar os Riscos dos requisitos

Definir a Fronteirado Software C2

Utilizar Check List para analisar Requisitos

Classificar os Requisitos C3 Elaborar o Documento de Requisito de Software (DRS) C4 Definir as Matrizes de Iterao e Rastreabilidade

FIm

Figura 5. Processo Documentao & Anlise Definir a Fronteira do Software: freqentemente os stakeholders no tm certeza do que deve ou no estar no software a ser desenvolvido, o que faz com que requisitos desnecessrios sejam includos durante a fase de Elicitao de requisitos. Por isso, deve-se avaliar o conjunto de requisitos essenciais para a definio do Documento de Viso do software. O Documento de Viso deve incluir o escopo do projeto e suas limitaes, bem como as principais caractersticas do software a ser desenvolvido [29]. importante que seja documentado os argumentos tcnicos e/ou econmicos que justificam a excluso dos requisitos do escopo do software. 41

Utilizar um Checklist para analisar os requisitos: para facilitar, otimizar e tornar mais completa a anlise de requisitos, deve-se definir um checklist, por meio do qual cada requisito deve ser analisado. Alm de reduzir a probabilidade de erros, a utilizao de um checklist uma forma de reutilizar o conhecimento em anlise de requisitos entre diferentes projetos. Caso fique muito grande deve-se particion-lo, de forma a criar vrios checklists que possam ser distribudos para diferentes analistas. O checklist deve ser periodicamente revisado e validado por analistas experientes para verificar a necessidade de alteraes. importante conscientizar os analistas de que o checklist deve ser apenas um guia e que podem existir outros problemas no cobertos pelo checklist. Analisar os Riscos dos requisitos: uma forma de identificar os requisitos que podero causar mais problemas aos desenvolvedores. Deve-se identificar os problemas que podero surgir, a probabilidade destes problemas e os efeitos decorrentes desses problemas para cada requisito ou para grupos de requisitos. Explicitar os riscos associados aos requisitos nesta fase uma forma de avaliar se os requisitos esto incompletos, se precisam ser modificados ou se necessria a definio de procedimentos para reduo da probabilidade do problema ocorrer e do impacto, caso ocorra. Classificar os requisitos: o objetivo da classificao dos requisitos agruplos de forma a identificar requisitos semelhantes. importante que o nmero de classes definido no seja muito grande, pois ficam muito poucos requisitos por classe. Geralmente, fica em cinco ou seis tipos de requisitos. Uma vez classificados, os requisitos de uma mesma classe devem ser comparados e analisados, pois conflitos e sobreposies so mais freqentes em requisitos de um mesmo tipo. Requisitos similares tambm podem ser comparados e pode-se visualizar melhor a falta de algum requisito. A classificao dos requisitos deve ser definida no Guia de Classificao de Requisitos. Definir as Matrizes de Iterao e Rastreabilidade: numa matriz de interao, cada requisito deve ser comparado com os demais de forma a identificar se so conflitantes, sobrepostos ou independentes. Se a quantidade de requisitos for muito grande, deve-se definir a matriz para uma classe especfica de requisito ou para os requisitos de um subsistema. Elaborar o Documento de Requisito de Software (DRS): o documento de requisitos o meio atravs do qual possvel descrever as restries quanto s caractersticas do produto e quanto ao processo de desenvolvimento, a interface com outras aplicaes, a descrio sobre o domnio e as informaes de suporte ao conhecimento do problema [30]. Em geral, necessrio que o documento de requisitos seja entendvel por todos os envolvidos no processo de engenharia de requisitos pois ele servir como um contrato entre usurios e desenvolvedores.

Durante a Negociao & Priorizao (figura 8) as seguintes atividades so feitas: Escolher a tcnica de negociao: o processo de negociao de requisitos tenta resolver conflitos entre usurios sem necessariamente comprometer a 42

satisfao dos objetivos de cada usurio. Em geral, os modelos de negociao identificam as principais necessidades de cada usurio, ou seja, atribuem prioridades aos requisitos, em seguida analisam esses resultados para tentar garantir que os requisitos mais crticos sejam atendidos. Em [31], Karlsson descreve um estudo de caso realizado num projeto Ericsson em que duas importantes tcnicas para priorizao e negociao de requisitos foram comparadas. As tcnicas avaliadas foram AHP [32] e QFD [33], os resultados obtidos indicaram que a tcnica AHP apesar de ter sido considerada complexa, apresentou melhores resultados.
In c io

E s co lh e r a T c n ic a d e N e g o c ia o

P rio riz a r o s R e q u is ito s D e fin ir o s m ile s to n e s e o s p o n to s d e re v is o

A tu a liz a r o D R S

F im

Figura 6. Processo Negociao & Priorizao Priorizar os Requisitos: uma vez escolhida a tcnica de negociao, ela deve ser usada para no apenas para resolver conflitos, mas tambm para priorizar os requisitos. Ao priorizar os requisitos, importante que os riscos e a complexidade dos requisitos sejam observados de forma mitigar possveis atrasos nos milestones a serem definidos. Definir os milestones e os pontos de reviso: de acordo com a priorizao, os requisitos so agrupados para estabelecer baselines de implementao, facilitando a definio dos milestones e pontos de reviso. Atualizar o Documento de Requisitos de Software: o resultado obtido a partir da tcnica de priorizao deve ser incorporado ao Documento de Requisitos de Software, enriquecendo a documentao sobre os atributos dos requisitos.

Durante processo de Gerenciamento & Mtricas (figura 9) as seguintes atividades so executadas: Receber as Solicitaes de Alterao de Requisitos (SAR): O grupo de engenharia de requisitos recebe as solicitaes de alterao de requisitos ou 43

por formulrio padronizado ou por meio de sistema de solicitao de demandas. Registrar novos requisitos: Os novos requisitos tambm devem ser recebidos formalmente ou por formulrio padronizado ou por meio de sistema de solicitao de demandas. Verificar requisitos relacionados: uma vez preenchidas as matrizes de rastreabilidade, de forma que tenham sido estabelecidos relacionamentos de rastreamento entre os requisitos, necessrio verificar os requisitos relacionados para que seja avaliado o impacto desta incluso ou alterao posteriormente.
C1 Receber as SAR's C2 Verificar Requisitos Relacionados Avaliar Impacto C3 Incio

Registrar novos Requisitos

Elaborar Relatrio de Impacto nos Requisitos C4

Notificar os envolvidos

Coletar Mtricas

Fim

Figura 7. Processo de Gerenciamento & Mtricas Elaborar relatrios de Impacto nos Requisitos: uma vez decidida a alterao, mantido um histrico de alteraes para cada requisito, permitindo uma viso cronolgica das principais mudanas nos requisitos, inclusive em seus atributos. O autor, a data-hora, a descrio e a justificativa da alterao tambm so documentados. Notificar os envolvidos: todos os envolvidos devido alterao dos requisitos devem ser notificados. Coletar Mtricas: as mtricas desempenham um papel essencial na deteco dos desvios, fornecendo meios para a visualizao de discrepncias e identificao de pontos fora de uma situao projetada. As mtricas devem ser utilizadas e coletadas periodicamente para o devido acompanhamento das atividades da Gerncia de Requisitos, fornecendo tambm uma indicao da 44

volatilidade dos requisitos. A equipe de gerncia de requisitos deve definir quais mtricas sero utilizadas no projeto, de acordo com suas caractersticas peculiares. Durante processo de Validao (figura 10) as seguintes atividades so executadas: Usar Checklist de Validao: checklists estruturam o processo de validao de forma que aspectos importantes no sejam esquecidos. Embora sejam semelhantes aos checklists de anlise, os checklists de validao devem focalizar aspectos de qualidade do documento de requisito como um todo, bem como os relacionamentos entre os requisitos. Algumas questes podem ser relacionadas para checar se algum requisito est ausente; se os requisitos esto consistentes e no contraditrios; se o documento est estruturado de forma a facilitar o entendimento; se foi feito o rastreamento dos requisitos; ou se o documento est de acordo com os padres. Definir os casos de teste dos requisitos: definir um ou mais casos de testes que posteriormente permitam verificar se o sistema satisfaz o requisito, alm de uma forma de validar os requisitos, pode servir como base para os testes finais do sistema. Ao escrever o caso de teste, o requisito estar sendo escrito de um ngulo diferente. Cada caso de teste deve possuir, no mnimo, um identificador, os requisitos a ele relacionados e a descrio do teste. Se utilizados em uma ferramenta, os casos de testes podem estar diretamente associados aos requisitos, alm de permitir que os testes possam ser feitos automaticamente.
Incio C1

Usar os checklist de validao C2

Definir os casos de teste dos requisitos

Executar a Inspeo Formal para Validao Desvios resolvveis internamente Notificar Gerente de Projeto e envolvidos Final Desvios no resolvveis internamente Notificar Gerncia Snior

D1

Figura 8. Processo de Validao Executar as Inspees Formais: nas inspees formais um grupo deve validar os requisitos de forma sistemtica, descobrir os problemas relacionados a eles e entrar em um acordo a respeito de como solucion-los. 45

Durante o encontro, que deve ser coordenado por algum que no esteja envolvido na definio dos requisitos a serem validados, o engenheiro de requisitos deve apresentar os requisitos e os problemas encontrados devem ser anotados para posterior discusso. Diferentemente de inspees de programas [34], onde os erros so simplesmente informados ao autor do programa, as inspees de requisitos devem definir as aes a serem tomadas para a devida correo. Durante processo de Verificao (figura 12) as seguintes atividades so executadas:
Incio

Verificar os Requisitos

Avaliar os Desvios

Desvios resolvveis internamente Notificar Gerente Projeto e envolvidos

D1

Desvios no resolvveis internamente

Notificar Gerncia Snior Final

Figura 9. Processo para Verificao Verificar os Requisitos: importante verificar se os requisitos encontram-se implementados corretamente nos modelos do processo de desenvolvimento de software. interessante que esta verificao seja feita por pessoas que conheam os modelos e a padronizao adotada pela empresa, mas no tenham se envolvido na especificao dos requisitos. Uma vez sendo encontradas inconsistncias, estas devem ser avaliadas. Neste processo, podem ser utilizadas matrizes de rastreabilidade com os modelos do processo de desenvolvimento de software definidos. Avaliar os Desvios: o objetivo avaliar junto aos grupos envolvidos o impacto das inconsistncias ou desvios encontrados. importante que seja avaliado, pois muitas vezes os desvios podem originar alteraes nos requisitos. Notificar os Gerentes e as Partes Interessadas: caso os desvios possam ser resolvidos internamente, a gerncia de projeto e os envolvidos so notificados. Caso contrrio, a gerncia snior comunicada para tomada de aes corretivas e acompanhamento. 46

4. As Fases para Implantao

Inicialmente, foram definidos os processos (vide Seo 3) e os padres documentados que devero ser utilizados, conforme a poltica de Gerncia de Requisitos aprovada para o SERPRO. Tambm foi definido um plano de treinamento para ser utilizado pelas equipes. Em cada regional foi escolhido um projeto para ser desenvolvido utilizando os procedimentos para a Gerncia de Requisitos definidos. A equipe deste projeto deve estar preparada para disseminar o conhecimento para as demais equipes do Plo, aproveitando os conhecimentos adquiridos. Primeiramente algumas atividades foram executadas para a avaliao da situao da Gerncia de Requisitos e definio da poltica, dos procedimentos, dos padres documentados e do plano de treinamento que devero ser utilizados pelas equipes na implantao da Gerncia de Requisitos. Para a implantao do processo de melhoria, nove fases (figura 14) devem ser seguidas at que se consiga o resultado esperado. Ao longo de toda a implantao os processos devem ser avaliados e continuamente ajustados de acordo com o feedback obtido. O processos podem selecionados para serem implantados ou omitidos de acordo com as caractersticas e necessidades da organizao. Por exemplo, uma organizao que j possui profundo conhecimento do negcio do cliente pode omitir a atividade entender o domnio da aplicao. A seguir, so descritas as nove fases que foram seguidas para implantao dos processos: Fase 1 - Conscientizao: nesta fase, deve-se identificar a situao atual, definir o status desejado (estabelecendo metas), e tomar aes para reduzir a distncia entre o status atual e o almejado. O status atual pode ser obtido por meio de observaes e de questionrios e entrevistas aos desenvolvedores em relao ao conhecimento e utilizao dos Processos de Engenharia de Requisitos. Uma vez obtidas as informaes, estas devem ser consolidadas e apresentadas aos gerentes e desenvolvedores, o que pode ser feito por meio de uma workshop, de forma a conscientizar e mobilizar os gerentes e desenvolvedores para a promoo das prticas e mudanas requeridas pelo programa. Neste evento podem ser organizadas palestras sobre o tema. fundamental o apoio gerencial para as aes e iniciativas de aprimoramento de processos de Engenharia de Requisitos. Manter esse comprometimento e repass-lo para os analistas parte fundamental do processo de melhoria. Fase 2 - Preparao: durante a preparao devem ser escolhidos os grupos de trabalho. Estes grupos devem estar profundamente familiarizados com a filosofia e os termos utilizados nos processos de Engenharia de Requisitos. O grupo de trabalho GT-Requisitos definido para planejar e acompanhar todas as tarefas do projeto de melhoria da capacidade. Este grupo visa garantir que o processo de implantao do modelo como um todo flua de maneira adequada. Este grupo deve aprovar, com a participao da alta gerncia, um cronograma com as macro-atividades e deve modific-lo sempre que se fizer necessrio. da responsabilidade do GT-Requisitos acompanhar e atualizar este cronograma. Dependendo do tamanho da 47

organizao podem ser definidos subgrupos de trabalho, onde o coordenador deve ser um membro do GT-Requisitos. O grupo de trabalho GT-Pessoaschave deve ser composto por pessoas que detm o conhecimento de como o processo de desenvolvimento e manuteno de software na empresa. Devem ser entrevistadas e treinadas primeiro de acordo com a necessidade e a disponibilidade. Este grupo pode mudar medida que aumenta a compreenso dos processos de software. importante que nesta fase esteja circulando na empresa informaes a respeito do trabalho sendo desenvolvido, o que pode ser feito por meio de jornais internos, circulares, email ou circulao de revistas e livros que tratem sobre o tema. Pode-se tambm disponibilizar informaes na Intranet da empresa.

Fase 8 - Implantao Fase 1 - Conscientizao Fase 7 - Definio de Papis e Responsabilidades Fase 2 - Preparao

Fase 9 Acompanhamento e Ajustes

Fase 6 - Definio dos Processos Fase 5 - Elaborao do Plano de Melhoria

Fase 3 - Treinamento

Fase 4 - Levantamento de

Figura 10. Fases para a Implantao Fase 3 - Treinamento: o GT-Requisitos tambm deve definir um Plano de Treinamento, priorizando a participao das pessoas que compe os grupos de trabalho. O treinamento deve preferencialmente ser preparado e aplicado por integrantes do GT-Requisitos, pois deve ser dada uma ateno especial para a adaptao dos termos do modelo de melhoria para a cultura da empresa. Todos os termos devem ser definidos e explicados fazendo, quando possvel, um mapeamento para os termos equivalentes utilizados na empresa. A importncia do treinamento deve-se tambm oportunidade de trocar experincia entre diferentes equipes de desenvolvimento, especialmente em empresas com diferentes plos de desenvolvimento, cada qual trabalhando com um ambiente e caractersticas de projeto prprias. Durante o treinamento, importante que um componente do GT-Requisitos anote as sugestes e consideraes que porventura apaream, pois podem ser de grande utilidade tanto para os prximos treinamentos como para utilizao ao longo do processo de melhoria. 48

Fase 4 - Levantamento de Processos Engenharia de Requisitos existentes: o primeiro passo para a melhoria o conhecimento de como est o seu processo de desenvolvimento. Uma empresa pode ter vrias maneiras de executar uma mesma tarefa como desenvolver e manter software. importante que o GT-Requisitos tome conhecimento de todos os processos de Engenharia de Requisitos existentes na empresa. Este conhecimento dever ser provido por reunies, entrevistas e coletas de documentos com o GT-Pessoas-chave. Deve-se avaliar as polticas, padres e processos atuais de Engenharia de Requisitos existentes na organizao, identificando os pontos fortes e fracos. Fase 5 - Elaborao do Plano de Melhoria: o Plano de Melhoria do Processo de Engenharia de Requisitos a base para o futuro esforo de melhoria e deve estar de acordo com o cronograma definido anteriormente. O GT-Requisitos deve preparar o Plano de Melhoria contendo os processos e documentos existentes de modo que fique claro os pontos em que h necessidade de melhoria e o impacto benfico que pode causar ao processo. Pode recomendar aes para solucionar as carncias identificadas e at estimar o tempo e recursos necessrios para cada atividade de melhoria. Fase 6 - Definio dos Processos: a definio dos Processos a serem implantados deve ser elaborada tendo como base com as boas prticas existentes na empresa, o Plano de Melhoria definido, o tipo, as restries e a cultura da organizao. So importantes pesquisas em bibliografia existente, instituies de pesquisa e, se possvel, a utilizao de benchmarking. Fase 7 - Definio de Papis e Responsabilidades: nesta fase devem ser especificados os papis e as responsabilidades das pessoas que executaro as atividades de desenvolvimento e gerenciamento de requisitos. Deve-se definir um mapeamento para as funes existentes na Empresa. Fase 8 - Implantao: a fase de Implantao deve possuir o planejamento e a execuo, inicialmente para o projeto-piloto e posteriormente, para os demais projetos. Para iniciar a implantao importante que o GTRequisitos defina um Plano para Projeto-piloto, onde seja especificado o projeto escolhido, as pessoas envolvidas, os treinamentos necessrios, alm os prazos esperados. A implantao do projeto-piloto deve ser acompanhada pelo GT-Requisitos e as dificuldades encontradas devem ser documentadas para posterior anlise e avaliao dos Processos definidos. Fase 9 Acompanhamento e Ajustes: esta fase deve acompanhar a aplicao das prticas de Gerncia de Requisitos implantadas, avaliando-as e promovendo os refinamentos necessrios. Nesta fase, devero ser executadas aes para atender a prtica de Verificao definida pelo CMM para a Gerncia de Requisitos.

5. Estratgia x CMM
A tabela 2 descreve as prticas-chave para Gerncia de Requisitos do CMM relacionando em que parte desta proposta as principais aes a serem executadas so definidas. 49

Co

Hb

Prticas do CMM O projeto segue uma poltica organizacional 1 para gerenciar os requisitos de software. Para cada projeto, est estabelecida a responsabilidade para analisar os requisitos 1 de sistema e aloc-los ao hardware, software ou outros componentes do sistema. Os requisitos de software esto 2 documentados Esto disponveis os recursos e fundos 3 necessrios para gerenciar os requisitos de software. Os membros do grupo de engenharia de software e de outros grupos relacionados a 4 software esto treinados para realizar suas atividades de gerncia de requisitos.

Estratgia Fase 6 - Definio dos Processos

Fase 7 - Definio de Papis e Responsabilidades

Processo de Definio Fase 1 - Conscientizao Fase 2 - Preparao Processo de Definio Processo de Elicitao de Requisitos Fase 3 - Treinamento Processo de Gerenciamento & Mtricas Processo de Documentao & Anlise Processo de Negociao & Priorizao Processo de Validao Processo de Verificao

At

O grupo de engenharia de software revisa 1 os requisitos de software, antes de serem incorporados ao projeto. O grupo de engenharia de software utiliza os requisitos de software como base para confeccionar os planos de desenvolvimento do software, desenvolver produtos de trabalho e realizar atividades. Revisar as alteraes nos requisitos de software e incorpor-las ao projeto de software. A gerncia snior revisa, periodicamente, todas as atividades de gerncia dos requisitos de software. O gerente de projeto revisa periodicamente ou por evento, todas as atividades de gerncia dos requisitos de software. O grupo de garantia de qualidade de software revisa e/ou audita as atividades e produtos de trabalho utilizados para gerenciar os requisitos de software, reportando seus resultados.

Processo de Verificao

3 Ve 1 2

Processo de Gerenciamento & Mtricas

Fase 9 - Acompanhamento e Ajustes

Fase 9 - Acompanhamento e Ajustes

Processo de Validao

Tabela 2. Prticas-chave e estratgia

6. Estudo de Caso
Tendo definido as diretrizes para a implantao da gerncia de requisitos, um projeto-piloto foi conduzido para validar a estratgia estabelecida. A deciso sobre qual sistema adotar foi tomada com base num perfil especfico. O sistema deveria atender s seguintes caractersticas: a. possuir um cliente disposto a ser o pioneiro no processo de implantao da gerncia e requisitos; 50

b.

possuir uma tcnica devidamente treinada ou disponvel para treinamento nos conceitos de engenharia de requisitos, em especial sobre processos para a melhoria da qualidade; possuir um escopo mnimo definido e controlvel; ser de importncia para o contexto das organizaes participantes (SERPRO e Cliente); ser de fcil insero no contexto da gerncia de requisitos do SERPRO.

c. d. e.

O sistema escolhido foi o SAD (Sistema de Apoio Deciso), um sistema de apoio deciso, possibilitando aos usurios de alto escalo do Cliente realizar consultas analticas sobre uma base de dados que agrega, para vrias reas de atuao do usurio, inmeras informaes sobre as suas atividades fins. Dando suporte ao projeto, um data warehouse congrega dados provenientes dos principais sistemas do cliente, obtidas por meio de um complexo processo de extrao, agregao e carga. Uma interface Web prov a acessibilidade s consultas para usurios habilitados em todo pas. Isto possvel por meio das funcionalidades OLAP (On-line Analytical Process) [35]. Dentre estas funcionalidades, o SAD possibilita ao usurio trabalhar a informao, manipulando a sua apresentao para permitir anlises de diversas maneiras, segunda diferentes critrios. um projeto de grande porte, envolvendo o processamento de 21 bases de dados de assuntos e extrao distintas, o que implica na especificao de requisitos para 21 equipes de desenvolvimento. Vale ressaltar que as equipes esto localizadas nas diversas regies do pas. Tendo escolhido o projeto piloto, foi inicializado o processo para a implantao da gerncia de requisitos. Foram utilizadas ferramentas automatizadas para gerenciamento de mudanas, gerenciamento de requisitos, gerenciamento de configurao e testes. Em processos de desenvolvimentos iterativos como os aplicados no SERPRO, uma das chaves para a qualidade do produto final o acompanhamento eficiente dos requisitos, como forma de garantir que todos os requisitos fluam corretamente entre todos os envolvidos, sem que requisito algum seja perdido, mal interpretado ou simplesmente adicionado sem a anuncia do cliente. Durante o processo de Definio, foram utilizadas como tcnicas de elicitao prototipao e entrevistas ao usurio. A prototipao auxiliou o usurio na descoberta de requisitos no imaginados previamente. Durante as entrevistas, foram elaborados os documentos Glossrio e Viso, cuja importncia foi bastante evidenciada tanto pelos desenvolvedores como pelo cliente No passo seguinte de Anlise & Documentao, os requisitos foram documentados utilizando os documentos Guia de Classificao de Requisitos, Especificao de Casos de Uso e Especificao Suplementar. Estes dois ltimos juntos compe o DRS (Documento de Requisitos de Software do sistema). A escrita dos requisitos utilizou Use Cases para requisitos funcionais e descries textuais para os requisitos no-funcionais e restries. Uma vez definidos e instanciados os documentos, os processos de Negociao & Priorizao se seguiram, onde o Analista de Requisitos apresentou os documentos de requisitos por meio de um Workshop envolvendo o cliente com o intuito de validar o 51

seu contedo, identificando possveis erros e priorizando os requisitos os requisitos dentro da seqncia de iteraes, alm da definio dos milestones e pontos de revises. Durante todo o processo de desenvolvimento, o processo de Gerenciamento & Mtricas, por meio das Solicitaes de Alteraes de Requisitos (SARs) , o usurio pde formalizar as alteraes necessrias nos requisitos equipe de projeto, as quais eram recebidas por meio da ferramenta de correio eletrnico da Empresa para que o Analista de Requisitos, utilizando a Matriz de Rastreamento, pudesse gerar o Relatrio de Impacto de Requisitos e negociar ento as alteraes. Aps a aprovao das alteraes, todos os envolvidos eram notificados formalmente (por meio de mensagem de correio eletrnico), os documentos, alterados e uma nova baseline gerada. Por fim, durante a execuo dos processos de Validao e Verificao, coube ao grupo de garantia de qualidade de software verificar a conformidade dos documentos com os padres definidos. Checklists de validao fornecem a base para esta atividade. O estudo de caso completo encontra-se disponvel em [36].

7. Concluso e Trabalhos Futuros

Este trabalho apresentou uma estratgia para a implantao de uma gerncia de requisitos baseada em trs pilares bsicos: qualidade, requisitos e processos. Para que a qualidade seja alcanada primordial que os requisitos tenham sido bem definidos e controlados e, para isto, devem haver processos estabelecidos e implantados. Gerenciamento de requisitos reconhecido como um importante pr-requisito para desenvolver software de alta qualidade e definidos como a habilidade de descrever e seguir a vida de um requisito, em ambas as direes. As dificuldades mencionadas pela equipe de engenharia de requisitos foram a mudana da cultura para desenvolvimento de software, a definio de requisitos utilizando um paradigma novo para a equipe, as caractersticas peculiares dos requisitos para um sistema de data warehouse e a grande quantidade de documentos gerados. Entretanto, foi ressaltada a importncia da utilizao dos processos definidos, que direcionaram as atividades e utilizao dos padres e da integrao com outros grupos, como o de garantia de qualidade de software e o de gerncia de configurao, que responsabilizou-se pelo versionamento e pelo relacionamento entre os documentos. Como trabalhos futuros, deve-se ter o acompanhamento da execuo dos processos em toda a empresa com a extrao de mtricas para que o processo evolua de acordo com as mudanas organizacionais, visando a melhoria contnua.

Bibliografia
[1] Sommerville, I., "Software Engineering", 6th Edition, Addison-Wesley, 2001.

52

[2] [3] [4] [5] [6]

SEI-Software Engineering Institute, "Capability Model for Software", 1a ed. USA: Carnegie Mellon University, Pittsburgh, Pennsylvania, 1997. Zanlorenci, E. P., "Descrio e Qualificao de Requisitos: Um Modelo Aplicvel Anlise e Validao da Informao", Tese de Mestrado, PUC-PR, 1999. Pressman, R., "Software Engineering: A Practioner's Approach", McGraw-Hill, 2000. Zahran, S., "Software Process Improvement", Addison Wesley, 1998. Paulk M. C. et all., "The Capability Maturity Model", version 1.1 (CMU/SEI-93-TR24), Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA(USA),1993. Fiorini, S. T., Staa A., Baptista R. M. ,"Engenharia de Software com CMM", Brasport, 1998. Leite, J., Castro, J., Pinheiro, F.,"Plataforma Tecnolgica em Engenharia de Requisitos Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas", http://www.cic.unb.br/~facp/per/perhome.html Booch, G., Rumbaugh, J E, Jacobson, I., "The Unified Modeling Language User Guide", Addison Wesley, 1999.

[7] [8]

[9]

[10] Booch, G., "Object Oriented Design with Applications", The Benjamin/Cumming Publishing Company, Inc., Redwood City, 1991. [11] Gil, G., Figueroa, D., Oliveros, A., "Produccin Del LEL em um Dominio Tcnico. Informe de um caso", III Workshop de Engenharia de Requisitos. Rio de JaneiroBrasil, 2000. [12] Leite, J. "Applications Language: A product Departamento de Informtica, PUC-RJ, 1989. of Requirements Analysis",

[13] Nuseibeh, B. E, Easterbrook, S., "Requirements Engineering: A Roadmap", Proceedings of the 22nd International Conference on Software Engineering. Limerick, Ireland. Jun. 2000. [15] Gause, D. E, Weinberg, G.M., "Exploring Requirements, Quality before Design", 1989. [16] Damian, A., Hong, D. E, Li, H., "Joint Application Development and Participatory Design", disponvel em www.cpsc.ucalgary.ca/~pan/seng/613/report.html [17] Couger, D., "Creative and innovation in information systems", Londom: International Thomson, 1995. [18] Schneider, G. E, Winters, J., "Applying Use Cases: a practical guide", AddisonWesley. 1998. [19] Lamsweerde, A., Darimont, R. E., Letier, E., "Managing Conflicts in Goal-Driven Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Managing Inconsistency in Software Development. Nov. 1998. [20] Yu, E., "Modeling Strategic Relationship for Process Reengineering", PhD thesis, Computer Science Department, University of Toronto, Toronto, Canada, 1995.

53

[21] Maiden, N., "CREWS-SAVRE: Scenarios for Acquiring Requirements", Automated Software Engineering, 1998.

and

Validating

[22] Shaw, M. E, Gaines, B., "Requirements Acquisition", Software Engineering Journal, vol 11, 1995. [23] Viller, S. E., Sommerville, I., "Social Analysis in the Requirements Engineering Process: from ethnography to method", 4th International Symposium on Requirements Engineering, Limerick, Ireland, Jun, 1999. [24] Gogen, J. E, Jirotka, M. "Requirement Engineering", Boston, Mass.: Academic Press, 1994. [25] Davis, A. M., "Achieving Quality in Software Requirements" SQP 1, NO. 3. 1999. [26] Ambriola, V. E., Gervasi, V., "Processing Natural Language Requirements", 12th International Conference on Automated Software Engineering. Lake Tahoe, EUA. Nov. 1997. [27] Antoniou, G., "The Role of Non-monotonic Representations in Requirements Engineering", International Journal of Software Engineering and Knowledge Engineering, vol 8. 1998. [28] Gotel, O. E., Finkelnstein, A., "An Analysis of the Requirements Traceability Problem", 1st International Conference on Requirements Engineering, Colorado Springs, EUA. Apr. 1994. [29] Wiegers K. E. ,"When Telepathy Won't Do: Requirements Engineering Key Practices", Cutter IT Journal, May, 2000. [31] Karlsson, K. E., Ryan, K., "Software Requirements Prioritizing", 2nd International Conference on Requirements Engineering. Apr. 1996. pp. 110 116. [32] Saaty, T., "The Analytic Hierarchy Process", New York: McGraw-Hill, 1990. [33] Hauser, J. E., Clausing, D., "The House of Quality", The Harvard Business Review, vol 3. 1988. [35] Codd, E. F., Codd, F. B., Salley, C. T., "Providing OLAP (Online Analytical Processing) to User Analyst: an IT Mandate", Arbor Software White Paper, http://www.arborsoft.com/OLAP.htm, 1993. [36] Carvalho, A. E., "Uma Estratgia para Implantao de uma Gerncia de Requisitos visando a Melhoria dos Processos de Software", Dissertao de Mestrado, UFPE, Brasil, 2001.

54