Aplicando Gerenciamento de Requisitos com Casos de Uso

Roger Oberg, Leslee Probasco e Maria Ericsson

Rational Software White Paper
TP 505 (Verso 1.4)

ndice Analtico

Software and System Development in the Age of Process ..................................................................................................... 1 Why Manage Requirements? ................................................................................................................................................... 1 What is a Requirement? ........................................................................................................................................................... 2 What is Requirements Management?...................................................................................................................................... 2 The Problems of Requirements Management......................................................................................................................... 2 Requirements Management Skills ........................................................................................................................................... 3 Key Skill 1: Analyze the Problem ........................................................................................................................................... 4 Key Skill 2: Understand Stakeholder Needs ........................................................................................................................... 4 Key Skill 3: Define the System ............................................................................................................................................... 4 Key Skill 4: Manage the Scope of the System......................................................................................................................... 5 Key Skill 5: Refine the System Definition............................................................................................................................... 5 Key Skill 6: Manage Changing Requirements......................................................................................................................... 6 Important Requirements Concepts.......................................................................................................................................... 6 Requirement Types.................................................................................................................................................................. 7 Cross-Functional Teams.......................................................................................................................................................... 7 Traceability ............................................................................................................................................................................. 8 Multi-Dimensional Attributes.................................................................................................................................................. 8 Change History...................................................................................................................................................................... 10 Putting Requirements Management to Work....................................................................................................................... 10 Requirements Management: Activities ................................................................................................................................. 11 Activity: Analyze the Problem .............................................................................................................................................. 12 Activity: Understand Stakeholder Needs............................................................................................................................... 14 Activity: Define the System................................................................................................................................................... 16 Activity: Manage the Scope of the System............................................................................................................................ 17 Activity: Refine the System Definition.................................................................................................................................. 18 Activity: Manage Changing Requirements............................................................................................................................ 19 Summary .................................................................................................................................................................................. 21 References ................................................................................................................................................................................ 22

Aplicando Gerenciamento de Requisitos com Casos de Uso

Se voc for iniciante ou de alguma forma estiver familiarizado com o gerenciamento de requisitos e estiver interessado no aprimoramento do processo de requisitos, este documento oferece uma estrutura com a qual ir desenvolver a sua prpria abordagem.
Casos de Uso e SRS (Especificaes de Requisitos de Software)

Para tornar as atividades de gerenciamento de requisitos mais significativas aos leitores, os autores escolheram tipos de documentos especficos e outros artefatos de gerenciamento de requisitos do Unified Process da Rational Software e do Idioma Unificado de Modelagem padro de mercado, que recomendam um processo de engenharia de software conduzido por caso de uso. Portanto, uma abordagem conduzida por caso de uso para especificar requisitos de software est descrita aqui. Essas atividades tambm podem ser utilizadas com as Especificaes de Requisitos de Software mais tradicionais (por exemplo, padres IEEE) no lugar dos modelos de caso de uso e de casos de uso ou em adio a eles.

Software e Desenvolvimento de Software no Perodo do Processo

Para a maioria das equipes de desenvolvimento de software e de sistema, a dcada de 90 foi intensa em processos quando comparada aos dias em que as coisas eram mais livres e improvisadas. Os padres para medir e certificar o processo efetivo de desenvolvimento de software foram introduzidos e popularizados. Foram publicados muitos livros e artigos sobre o processo de desenvolvimento de software e material relacionado sobre modelagem e reengenharia de processos de negcios. O nmero crescente de ferramentas de software ajudou a definir e a aplicar o processo efetivo de desenvolvimento de software. A dependncia de software da economia global foi acelerada durante a dcada, permitindo processos de desenvolvimento e aprimorando a qualidade dos sistemas. Ento, como explicamos a alta incidncia de falhas em projetos de software nos dias de hoje? Por que h vrios projetos de software, se no a maioria, que ainda sofrem com atrasos, oramentos excessivos e problemas de qualidade? Como podemos aprimorar a qualidade dos sistemas que construmos conforme nossas empresas, economias nacionais e atividades dirias tornam-se cada vez mais dependentes deles? As respostas, como sempre, esto nas pessoas, nas ferramentas e nos processos aplicados a nossa profisso. O gerenciamento de requisitos freqentemente proposto como uma soluo para os problemas contnuos de desenvolvimento de software, no entanto, relativamente pouca ateno tem sido focada no aprimoramento da prtica dessa disciplina. Este documento apresenta os elementos de um processo efetivo de gerenciamento de requisitos e destaca alguns dos obstculos para sua implementao bem-sucedida. O gerenciamento de requisitos aplica-se igualmente aos projetos de software e aos projetos nos quais o software apenas uma parte do resultado final ou no est de modo algum includo. Por questo de convenincia, este documento daqui em diante utilizar o termo "sistema" para referir-se a todas as essas coisas. No entanto, a natureza abstrata do desenvolvimento de software, sozinha ou em conjunto com o hardware, que complica o gerenciamento de requisitos e este o foco principal do documento.

Por Que Gerenciar Requisitos?

Em poucas palavras, equipes de desenvolvimento de software que gerenciam requisitos o fazem porque desejam que seus projetos tenham xito. Atender aos seus requisitos de projeto define o sucesso. A falha no gerenciamento de requisitos reduz a probabilidade de atender a esses objetivos. Evidncia recente sustentada: Os Relatrios CHAOS da Standish Group, de 1994 e 1997, estabeleceram que os contribuidores mais significativos para a falha de um projeto esto relacionados aos requisitos. [1]
Field Code Changed

Aplicando Gerenciamento de Requisitos com Casos de Uso

Em dezembro de 1997, a Computer Industry Daily relatou um estudo da Sequent Computer Systems, Inc. com 500 gerentes de TI nos Estados Unidos e no Reino Unido que apontou que 76 por cento dos entrevistados j tinham tido falhas em projetos inteiros durante suas carreiras. A causa mais freqentemente apontada como falha nos projetos foi "alterao de requisitos do usurio". [2]

Field Code Changed

Evitar falhas deve ser uma motivao suficiente para gerenciar requisitos. Aumentar a probabilidade de um projeto bemsucedido e de outros benefcios provenientes do gerenciamento de requisitos pode ser igualmente uma motivao. O relatrio CHAOS do Standish Group estabeleceu ainda que o bom gerenciamento de requisitos era o fator mais relacionado aos projetos bem-sucedidos.

O Que um Requisito?
A primeira etapa para entender o gerenciamento de requisitos concordar com um vocabulrio comum. A Rational define um requisito como "uma condio ou capacidade com a qual o sistema [sendo construdo] deve estar em conformidade". O IEEE (Institute of Electronics and Electrical Engineers) utiliza uma definio similar. Os j conhecidos autores de engenharia de requisitos, Merlin Dorfman e Richard H. Thayer, oferecem uma definio compatvel e mais refinada que especficamas no est necessariamente limitadaao software. "Um requisito de software pode ser definido como: Uma capacidade de software necessria pelo usurio para resolver um problema atingir um objetivo. Uma capacidade de software que deve ser atendida ou que deve ser de posse de um sistema ou componente de sistema para satisfazer um contrato, padro, especificao ou outra documentao formalmente imposta". [3]
Field Code Changed

O Que Gerenciamento de Requisitos?

Como requisitos so coisas com as quais o sistema que est sendo construdo deve estar em conformidade e a conformidade com alguns conjuntos de requisitos define o sucesso ou a falha de projetos, faz sentido descobrir quais so os requisitos, anot-los, organiz-los e rastre-los, caso sejam alterados. Em outras palavras, o gerenciamento de requisitos : uma abordagem sistemtica de fazer levantamento, organizar e documentar os requisitos do sistema e um processo que estabelece e mantm concordncia entre o cliente e a equipe do projeto na alterao de requisitos do sistema.

Essa definio similar a de Dorfman e Thayer e definio do IEEE de "engenharia de requisitos de software". A engenharia de requisitos inclui levantamento, anlise, especificao, verificao e gerenciamento dos requisitos de software, em que o "gerenciamento de requisitos de software" o planejamento e o controle de todas essas atividades relacionadas[4]. Todas essas atividades so incorporadas na definio de gerenciamento de requisitos apresentada aqui e ensinada pela Rational Software. A diferena est principalmente na escolha da palavra "gerenciamento" em vez de "engenharia". O gerenciamento uma descrio mais apropriada de todas as atividades envolvidas e enfatiza precisamente a importncia de se rastrear alteraes para manter a concordncia entre os envolvidos e a equipe do projeto. Para aqueles que no esto familiarizados com o termo "levantamento", ele definido como o conjunto de atividades que as equipes empregam para fazer o levantamento ou descobrir pedidos dos envolvidos, determinar as necessidades reais por trs dos pedidos e chegar a um conjunto adequado de requisitos que poder ser colocado no sistema para atender a essas necessidades.

Field Code Changed

Os Problemas do Gerenciamento de Requisitos

Portanto, o que poder ser difcil sobre um processo que pretende assegurar que um sistema esteja em conformidade com as expectativas depositadas nele? Quando colocado na prtica em projetos reais, as dificuldades vm tona. A Figura 1 exibe os resultados de uma pesquisa de opinio de 1996 realizada com desenvolvedores, gerentes e pessoal de garantia de qualidade.

Aplicando Gerenciamento de Requisitos com Casos de Uso

Ela mostra a porcentagem de entrevistados que tiveram os problemas relacionados a requisitos mais freqentemente mencionados.

Figura 1Problemas Comuns de Requisitos

Uma lista mais abrangente de problemas inclui: Os requisitos nem sempre so bvios e tm muitas fontes. Nem sempre fcil expressar os requisitos claramente em palavras. Existem diversos tipos de requisitos em diferentes nveis de detalhe. O nmero de requisitos poder impossibilitar a gerncia se no for controlado. Os requisitos esto relacionados uns com os outros e com outros distribuveis do processo de vrias maneiras. Os requisitos tm propriedades exclusivas ou valores de propriedade. Por exemplo, eles no so igualmente importantes nem igualmente fceis de atender. H vrios envolvidos e responsveis, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de diferentes funes. Os requisitos so alterados. Os requisitos podem ser sensveis hora.

Quando esses problemas so combinados com o gerenciamento de requisitos e habilidades do processo inadequados e a falta de ferramentas fceis de utilizar, muitas equipes perdem a esperana de que podero gerenciar bem requisitos. A Rational Software desenvolveu a habilidade para instruir equipes nas tcnicas e processos de gerenciamento de requisitos. Alm disso, o Rational RequisitePro uma ferramenta acessvel para automatizar o gerenciamento efetivo de requisitos.

Habilidades de Gerenciamento de Requisitos

Para resolver os problemas mencionados acima, a Rational incentiva o desenvolvimento de habilidades-chave. Estas habilidades so apresentadas a seguir e parecem estar em ordem seqencial, no entanto, em um processo efetivo de gerenciamento de requisitos, elas so aplicadas continuamente em uma ordem variada. Elas so apresentadas aqui na seqncia em que provavelmente voc aplicaria primeira iterao de um projeto novo.

Aplicando Gerenciamento de Requisitos com Casos de Uso

Figura 2Etapas na Anlise de Problemas

Habilidade-chave 1: Analisar o Problema A anlise do problema feita para compreender os problemas de negcios, as necessidades-alvo iniciais dos envolvidos e propor solues de nvel alto. Essas linhas de raciocnio e anlise localizam "o problema por trs do problema". Durante a anlise do problema, chega-se a um acordo em relatrio dos problemas reais e os envolvidos so identificados. Os limites e restries iniciais da soluo so definidos a partir das perspectivas tcnicas e comerciais. Se apropriado, o caso de negcios para o projeto analisa o retorno do investimento esperado do sistema. Habilidade-chave 2: Entender as Necessidades dos Envolvidos Os requisitos tm muitas fontes. Eles podem vir de qualquer um que tenha interesse no resultado do projeto. Os clientes, parceiros, usurios finais e especialistas em domnios so algumas fontes de requisitos. Gerenciamento, membros da equipe do projeto, polticas de negcios e agncias reguladoras podem ser outras. importante saber como determinar quais devem ser as fontes, como obter acesso a essas fontes e qual a melhor forma de fazer o levantamento de informaes delas. Os indivduos que constituem as fontes primrias para essas informaes so conhecidos como os "envolvidos" no projeto. Se voc estiver desenvolvendo um sistema de informaes para ser utilizado internamente na sua empresa, poder incluir na sua equipe de desenvolvimento pessoas com experincia de usurio final e com conhecimento do domnio de negcios. Com bastante freqncia, voc comear os debates no nvel de um modelo de negcio em vez de no nvel de um sistema. Se voc estiver desenvolvendo um produto para ser vendido para um estabelecimento comercial, poder fazer uso extensivo do pessoal de marketing para entender melhor as necessidades dos clientes desse mercado. As tcnicas para o levantamento de requisitos incluem entrevistas, discusso de idias, prottipos conceituais, questionrios e anlise competitiva. O resultado do levantamento de requisitos uma lista dos pedidos ou das necessidades que foram descritos textual e graficamente e que receberam prioridade em relao ao outro. Habilidade-chave 3: Definir o Sistema Definir o sistema significa traduzir e organizar as necessidades dos investidores em descries significativas do sistema a ser construdo. No incio da definio do sistema, as decises so tomadas sobre o que constitui um requisito, o formato de

Aplicando Gerenciamento de Requisitos com Casos de Uso

documentao, a formalidade da linguagem, o grau dos requisitos, a prioridade dos pedidos e o esforo estimado, os riscos tcnicos e de gerenciamento e o escopo. Parte dessa atividade pode incluir modelos de design e prottipos iniciais diretamente relacionados aos pedidos mais importantes dos investidores. Utilizamos a palavra "descrio" em vez de "documento" para evitar a limitao percebida inerente no uso comum da ltima. Uma descrio pode ser um documento escrito, um arquivo eletrnico, uma imagem ou qualquer outra representao utilizada para comunicar requisitos do sistema, com exceo do prprio sistema. O resultado da definio do sistema uma descrio do sistema que esteja em idioma natural e tambm seja grfica. Alguns formatos sugeridos para a descrio so fornecidos em sees posteriores.

Princpio 55: Escrever em uma Linguagem Natural Antes de um Modelo Mais Formal

Se voc escrever o modelo formal primeiro, a tendncia ser escrever em uma linguagem natural que descreve o modelo em vez do sistema de soluo. Considere os seguintes exemplos: Para fazer uma chamada de longa distncia, o usurio deve levantar o gancho. O sistema deve responder com um tom de discagem. O usurio deve discar "9". O sistema deve responder com um tom de discagem distintivo O sistema consiste em quatro estados: Inativo, Tom de Discagem, Tom Discagem Distintivo e Conectado. Para ir do estado inativo para o estado de tom de discagem, levante o gancho. Para ir do estado de tom de discagem para o estado de tom de discagem distintivo, disque "9". Observe que no ltimo exemplo, o texto no ajuda o leitor. Alan M. Davis, 201 Principles of Software Development, 1995

Habilidade-chave 4: Gerenciar o Escopo do Sistema O escopo de um projeto definido pelo conjunto de requisitos alocados para ele. O gerenciamento do escopo do projeto para se adequar aos recursos disponveis (tempo, pessoas e dinheiro) primordial para o gerenciamento de projetos com xito. Gerenciar o escopo uma atividade contnua que requer desenvolvimento iterativo ou incremental, que quebra o escopo do projeto em partes menores mais simples de gerenciar. O uso de atributos de requisitos, como prioridade, esforo e risco como a base para a negociao da incluso de um requisito uma tcnica particularmente til para gerenciar o escopo. Focar os atributos em vez de os requisitos propriamente ditos ajuda a desestimular negociaes que so normalmente controversas. proveitoso que os lderes de equipe sejam treinados para negociaes, e que o projeto tenha um defensor na organizao, assim como no lado do cliente. Os defensores do produto ou do projeto devem ter o poder organizacional para recusar alteraes de escopo alm dos recursos disponveis ou para expandir recursos a fim de acomodar escopo adicional. Habilidade-chave 5: Refinar a Definio do Sistema Com uma definio do sistema de nvel alto aceita e um escopo inicial completamente entendido, possvel e econmico investir recursos em definies do sistema mais refinadas. Refinar a definio do sistema inclui duas consideraes fundamentais: desenvolver descries mais detalhadas da definio do sistema de nvel alto e verificar se o sistema atender as necessidades dos envolvidos e se comportar conforme o descrito. As descries so freqentemente os materiais de referncia crtica para as equipes do projeto. As descries so melhores feitas com o pblico em mente. Um engano comum representar o que complexo para construir com uma definio complexa, particularmente quando o pblico no pode ou no deseja investir a opinio crtica necessria para obter concordncia. Isso leva a dificuldades para explicar a finalidade do sistema para pessoas que esto dentro e fora da equipe do projeto. Em vez disso, voc poder descobrir a necessidade de produzir diferentes tipos de descries para pblicos

Aplicando Gerenciamento de Requisitos com Casos de Uso

diferentes. Este documento inclui formatos sugeridos para linguagem natural detalhada, texto formal e descries grficas. Depois de estabelecer o formato da descrio, o refinamento continua em todo o ciclo de vida do projeto. Habilidade-chave 6: Gerenciar a Alterao de Requisitos No importa o cuidado com que voc define seus requisitos, eles sero alterados. De fato, alguma alterao de requisitos desejvel! Significa que sua equipe est atraindo os envolvidos. Acomodar a alterao de requisitos uma medida de sensibilidade e de flexibilidade operacional dos envolvidos da equipeatributos de equipe que contribuem para projetos bem-sucedidos. A alterao no o inimigo; mas sim a alterao no gerenciada.

Figura 3Um Processo para Gerenciar Alteraes

Um requisito alterado significa que mais ou menos tempo precisa ser gasto na implementao de um determinado recurso e que uma alterao em um requisito poder ter impacto em outros requisitos. O gerenciamento de alteraes em requisitos inclui atividades como estabelecer uma linha de base, acompanhar o histrico de cada requisito, determinar quais dependncias so importantes para o rastreio, estabelecer relacionamentos rastreveis entre itens relacionados e manter o controle de verso. Conforme a Figura 3 ilustra, tambm importante estabelecer um controle de alteraes ou processo de aprovao, o que requer que todas as alteraes propostas sejam revisadas pelos membros da equipe designada. s vezes, esse nico canal de controle de alteraes chamado de CCB (Conselho de Controle de Alteraes).

Conceitos de Requisitos Importantes

Para aplicar habilidades de gerenciamento de requisitos a um projeto, determinados conceitos de gerenciamento de requisitos so teis para que cada um no projeto entenda. Eles incluem: Tipos de requisitos Equipes com diferentes funes Rastreabilidade Atributos multidimensionais Histrico de alteraes

Aplicando Gerenciamento de Requisitos com Casos de Uso

Tipos de Requisitos Quanto maior e mais complexo o sistema, mais tipos de requisitos aparecero. Um tipo de requisito simplesmente uma classe de requisitos. Ao identificar os tipos de requisitos, as equipes podem organizar nmeros grandes de requisitos em grupos significativos e mais gerenciveis. O estabelecimento de tipos diferentes de requisitos em um projeto ajuda os membros da equipe a classificarem pedidos de alteraes e a se comunicarem mais claramente. Normalmente, um tipo de requisito pode ser dividido ou decomposto em outros tipos. As regras de negcios e as declaraes de viso podem ser tipos de requisitos de nvel alto dos quais as equipes derivam as necessidades dos usurios, os recursos e os tipos de requisitos do produto. Os casos de uso e outras formas de modelagem conduzem os requisitos de design que podem ser decompostos para requisitos de software e representados em modelos de anlise e design. Os requisitos de teste so derivados dos requisitos de software e decompostos em procedimentos de teste especficos. Quando h centenas, milhares ou mesmo dezenas de milhares de instncias de requisitos em um determinado projeto, a classificao de requisitos em tipos torna o projeto mais gerencivel. Equipes de Diferentes Funes Ao contrrio de outros processos, como teste ou modelagem de aplicativo, que podem ser gerenciados dentro de um nico grupo de negcios, o gerenciamento de requisitos deve envolver qualquer um que possa contribuir com seu conhecimento no processo de desenvolvimento. Ele deve incluir as pessoas que representam as expectativas do cliente e da empresa. Gerentes de desenvolvimento, gerentes de produtos, analistas, engenheiros de sistema e at mesmo clientes devem participar. As equipes de requisitos devem incluir tambm aqueles que criam a soluo do sistemaengenheiros, arquitetos, designers, programadores, escritores tcnicos e outros contribuidores tcnicos. Testadores e outro pessoal de QA (Garantia de Qualidade) devem ser contados como membros importantes da equipe.

Figura 4Equipe de Requisitos de Diferentes Funes

Freqentemente, a responsabilidade por autorizar e manter um tipo de requisito pode ser alocada pela rea funcional, contribuindo adicionalmente para um melhor gerenciamento de projetos grandes. A natureza do gerenciamento de requisitos em diferentes funes uma dos aspectos mais desafiadores da disciplina.

Aplicando Gerenciamento de Requisitos com Casos de Uso

Rastreabilidade Conforme implicado na descrio de tipos de requisito, nenhuma expresso individual de um requisito fica sozinha. Os pedidos dos envolvidos esto relacionados aos recursos do produto propostos para atend-los. Os recursos dos produtos esto relacionados a requisitos individuais que especificam os recursos em termos de comportamento funcional e no funcional. Os casos de teste esto relacionados aos requisitos que eles verificam e validam. Os requisitos podem ser dependentes de outros requisitos ou podem ser mutuamente exclusivos. Para que as equipes determinem o impacto das alteraes e sintam-se seguras que o sistema est em conformidade com as expectativas, esses relacionamentos de rastreabilidade devem ser entendidos, documentados e mantidos. Enquanto a rastreabilidade um dos conceitos mais difceis de implementar no gerenciamento de requisitos, ela essencial para acomodar alteraes. O estabelecimento de tipos de requisitos claros e a incorporao da participao de diferentes funes podem tornar a implementao e a manuteno da rastreabilidade mais fceis. Para obter informaes adicionais sobre estratgias diferentes para rastreabilidade de requisitos, consulte o white paper, "Estratgias de Rastreabilidade para Gerenciar Requisitos com Casos de Uso" [5].

Field Code Changed

Figura 5Rastreabilidade de Requisitos

Atributos Multidimensionais Cada tipo de requisito tem atributos e cada requisito individual tem valores de atributo diferentes. Por exemplo, os requisitos podem receber prioridades, ser identificados por origem e base racional, delegados a subequipes especficas dentro de uma rea funcional, receber uma designao de grau de dificuldade ou associados a uma iterao particular do sistema. Para ilustrar, a Figura 6 exibe atributos para um Tipo de Requisito de Recurso de um Projeto de Aprendizado na ferramenta de gerenciamento de requisitos Rational RequisitePro. Conforme implicado pelo ttulo da tela, o tipo de requisito e os atributos para cada tipo so definidos para o projeto inteiro, assegurando consistncia de uso entre a equipe.

Aplicando Gerenciamento de Requisitos com Casos de Uso

Figura 6Definindo Atributos de Requisito para Recursos

Na Figura 7, as instncias dos requisitos de recurso so exibidas para um projeto especfico no RequisitePro. Observe que mesmo sem exibir o texto inteiro para cada requisito, podemos aprender muito sobre cada requisito a partir de seus valores de atributo. Nesse caso, sua prioridade e dificuldadesem dvida designadas por membros da equipe diferentesajudaro a equipe a comear o escopo do projeto para recursos e horas disponveis, levando em conta as prioridades dos envolvidos e uma estimativa aproximada do esforo refletido no valor do atributo de dificuldade. Em tipos de requisitos mais detalhados, os atributos de prioridade e esforo podem ter valores mais especficos, por exemplo, tempo estimado, linhas de cdigo e assim por diante) com os quais ir refinar mais o escopo. Esse aspecto multidimensional de um requisito, composto por tipos diferentes de requisitoscada um com seus prprios atributos essencial para organizar grandes nmeros de requisitos e para gerenciar o escopo global do projeto.

Figura 7Definindo Valores de Atributo para Cada Requisito

Aplicando Gerenciamento de Requisitos com Casos de Uso

Histrico de Alteraes Requisitos individuais e uma coleta de requisitos tm histrias que se tornam significativas com o tempo. A alterao inevitvel e desejvel para acompanhar uma ambiente de alteraes e a evoluo da tecnologia. O registro das verses de requisitos do projeto permitem que os lderes de equipe capturem as razes para alterar o projeto, como um novo release do sistema. A compreenso de que uma coleta de requisitos pode estar associada a uma verso especfica de software permite gerenciar alteraes incrementalmente, reduzindo o risco e aprimorando a probabilidade de atender marcos. Como os requisitos individuais evoluem, importante entender seu histrico: o que mudou, por que, quando e quem autorizou.

Colocando o Gerenciamento de Requisitos para Trabalhar

O gerenciamento de requisitos emprega habilidades-chave e conceitos apresentados acima para identificar e resolver os problemas com xito. Para construir um sistema que realmente atenda s necessidades dos clientes, a equipe do projeto deve primeiro definir o problema a ser resolvido pelo sistema. Em seguida, a equipe deve identificar os envolvidos a partir dos quais so feitos o levantamento, a descrio e a priorizao das necessidades da empresa e do usurio. A partir desse conjunto de expectativas ou necessidades de nvel alto, um conjunto de recursos do produto ou do sistema deve ser aceito. Os requisitos de software detalhados precisam ser escritos de uma forma que sejam entendido pelos clientes e pela equipe de desenvolvimento. Achamos que utilizar a linguagem do cliente para descrever esses requisitos de software mais efetivo na obteno de entendimento e aceitao. Esses requisitos de software detalhados so ento utilizados como entrada para as especificaes de design do sistema, bem como para planos e procedimentos de teste necessrios para implementao e validao. Os requisitos de software devem tambm conduzir o planejamento e o design iniciais da documentao do usurio.

Figura 8Viso Geral da Estrutura de Gerenciamento de Requisitos

Para facilitar isso, a equipe do projeto deve: Concordar com um vocabulrio comum para o projeto. Desenvolver uma viso do sistema que descreve o problema a ser resolvido pelo sistema, bem como de seus recursos principais.

10

Aplicando Gerenciamento de Requisitos com Casos de Uso

Fazer o levantamento das necessidades dos envolvidos em pelo menos cinco reas importantes: funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade. Determinar quais tipos de requisitos utilizar. Selecionar atributos e valores para cada tipo de requisito. Escolher os formatos nos quais os requisitos so descritos. Identificar membros da equipe que sero autores, contribuiro ou simplesmente visualizaro um ou mais tipos de requisitos. Decidir qual rastreabilidade necessria. Estabelecer um procedimento para propor, revisar e resolver alteraes em requisitos. Desenvolver um mecanismo para rastrear o histrico de requisitos. Criar relatrios de progresso e status para membros da equipe e gerenciamento.

Essas atividades essenciais de gerenciamento de requisitos so independentes de indstria, metodologia de desenvolvimento ou ferramentas de requisitos. Elas tambm so flexveis, o que permite o gerenciamento efetivo de requisitos em ambientes de desenvolvimento de aplicativos mais rigorosos e mais rpidos.

Algumas Informaes sobre Documentos

A deciso de descrever requisitos em documentos merece alguma ateno. Por um lado, a escrita uma forma amplamente aceita de comunicao e, para a maioria das pessoas, uma coisa natural de se fazer. Por outro lado, o objetivo do projeto produzir um sistema e no documentos. O senso comum e a experincia ensinam que a deciso no se ir documentar requisitos, mas como ir document-los. Gabaritos de documentos fornecem um formato consistente para gerenciamento de requisitos. O Rational RequisitePro oferece esses gabaritos e o recurso adicional de vincular requisitos dentro de um documento a um banco de dados que contm todos os requisitos do projeto. Esse recurso exclusivo permite que os requisitos sejam documentados naturalmente enquanto se tornam mais acessveis e gerenciveis em um banco de dados relacional.

Gerenciamento de Requisitos: Atividades

O gerenciamento de requisitos pode seguir um nmero infinito de caminhos especficos do domnio. A seguinte abordagem prescreve seis atividades detalhadas que se aplicam a cada uma das habilidades-chave de gerenciamento de requisitos, mas podem ser aplicadas a qualquer domnio. Os seguintes diagramas de atividades so do Rational Unified Process [6] Disciplina de Requisitos. Essas atividades so expressas em termos de funes, tarefas e artefatos (entrada ou sada) conforme resumido na Figura 9. O texto associado neste documento descreve cada atividade brevemente, na esperana de estimular suas idias e interesses no aprimoramento do processo de gerenciamento de requisitos. Informaes adicionais sobre o Rational Unified Process podem ser localizadas em www.ibm.com/software/rational.
Field Code Changed

Field Code Changed

11

Aplicando Gerenciamento de Requisitos com Casos de Uso

Figura 9Fluxo de Trabalho de Requisitos no Rational Unified Process

Atividade: Analisar o Problema Na Anlise de Problema, a atividade principal desenvolver a viso para o projeto. A sada dessa atividade um documento de viso que identifica a viso de nvel alto do usurio ou cliente do sistema a ser construdo. A viso expressa os requisitos iniciais como recursos-chave que o sistema deve possuir para resolver os problemas mais crticos e atender s necessidades fundamentais dos envolvidos. O analista de sistemas tem a funo principal nessa atividade. O analista de sistemas deve ter conhecimento no domnio do problema e um entendimento do problema e deve poder descrever um processo que acredita que resolver o problema. O envolvimento ativo de vrios envolvidos no projeto requerido e todos os pedidos relevantes dos envolvidos devem ser considerados. Para iniciar a tarefa Gerenciar Dependncias, os recursos devem receber atributos como base racional, valor relativo ou prioridade e fonte de pedidos. Conforme a viso se desenvolve, o analista identifica usurios e sistemas (os agentes) de possveis casos de uso. Os agentes so os primeiros elementos do modelo de caso de uso, que definiro os requisitos tcnicos funcionais e no funcionais do sistema.

12

Aplicando Gerenciamento de Requisitos com Casos de Uso

Figura 10Analisando o Problema

Atividade: Analisar o Problema Iniciao: Um ou mais envolvidos que percebem um problema iniciaro a atividade. Um analista de sistemas em uma equipe de desenvolvimento poder facilitar uma sesso para ajudar os envolvidos iniciais a descreverem o problema que desejam solucionar. importante haver concordncia sobre uma declarao concisa do problema percebido. Elementos-chave de uma declarao do problema so mostrados na seguinte tabela: O Problema de Afeta os Envolvidos O Impacto do Problema Uma Soluo Bem-sucedida incluir definir o problema listar os envolvidos afetados pelo problema descrever o impacto do problema listar alguns benefcios fundamentais de uma soluo bem-sucedida

A declarao do problema explica concisamente o objetivo do projeto. A anlise do problema estimula investigao adicional em todos os pedidos dos envolvidos e no caso de negcios inicial, incluindo benefcios convincentes e custos aproximadamente estimados. Em paralelo com a definio das declaraes do problema, a equipe tambm deve compilar um glossrio acompanhando os termos utilizados comumente e concordando com suas definies.

Introduo do Modelo de Caso de Uso

Um modelo de caso de uso consiste em agentes, casos de uso e relacionamentos entre eles. Os agentes representam tudo que deve trocar informaes com o sistema, incluindo os que normalmente so chamados de usurios. Quando um agente utiliza o sistema, o sistema executa um caso de uso. Um bom caso de uso uma seqncia de transaes que produz um resultado mensurvel do valor para um agente. A coleta de casos de uso a funcionalidade completa do sistema. Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented Software Engineering A Use Case Driven Approach, Addison Wesley ACM Press, 1992

13

Aplicando Gerenciamento de Requisitos com Casos de Uso

A anlise do problema tambm identifica os agentes principais do sistema. Os agentes so usurios do sistema ou de qualquer outro sistema que trocar informaes com ele. Nesse estgio, a anlise do problema deve identificar rapidamente algumas formas bvias que os agentes iro interagir com o sistema. As descries devem ser orientadas em direo ao processo de negcios em vez de ao comportamento do sistema. Por exemplo, um programa de oramento pode permitir um tipo de agente para "Criar o oramento departamental", enquanto outro agente pode "Consolidar os oramentos departamentais". O analista de sistemas pode posteriormente dividi-los em casos de uso adicionais que se alinham mais significativamente com o comportamento especfico do sistema. Por exemplo, "Criar o oramento departamental" pode resultar em casos de uso do sistema como "Importar informaes de planilha" e "Criar visualizaes de oramentos". A sesso de anlise de problemas descrita acima freqentemente executada mais de uma vez, talvez com diferentes envolvidos, e entremisturada com sesses da equipe de desenvolvimento interna. O analista de sistemas que conduziu a reunio com os envolvidos liderar uma sesso com membros da equipe de desenvolvimento para visionar uma soluo tcnica para os problemas, derivar recursos das entradas iniciais dos envolvidos e esboar a descrio da viso, que a primeira definio do sistema a ser construdo. Para facilitar o entendimento da soluo proposta entre os envolvidos iniciais, o analista de sistemas poder utilizar ferramentas de modelagem ou tcnicas de desenho manuais para complementar a descrio da viso. Os envolvidos iniciais so consultados em vrios pontos para ajudar a refinar a descrio do problema e restringir o nmero e o escopo de possveis solues. Os envolvidos e os analistas de sistemas gerenciam dependncias nessa atividade negociando a prioridade de recursos-chave e ganhando um entendimento geral dos recursos e esforos necessrios para desenvolv-los. Embora a alterao inevitvel das estimativas de prioridade e esforos ou recursos, o gerenciamento de dependncias estabelece antecipadamente um padro importante que continua em todo o ciclo de vida de desenvolvimento. Essa a essncia do gerenciamento de escopo e um preditor antecipado do sucesso de um projeto. Depois de vrios esboos, a viso atinge um ponto no qual a equipe deve decidir se ir investir em levantamento adicional de requisitos. Ao mesmo tempo, o processo de aprovao do caso de negcios foi iniciado separadamente. Embora no discutido adicionalmente neste documento, o caso de negcios descreve o seguinte: contexto (domnio, mercado e escopo do produto); abordagem tcnica; abordagem de gerenciamento (planejamento, risco medida objetiva do sucesso); previso financeira.

Atividade: Entender as Necessidades dos Envolvidos Se a anlise do problema inicial justificar gasto adicional, a atividade Entendendo as Necessidades dos Envolvidos iniciada srio. A tarefa-chave fazer o levantamento dos pedidos dos envolvidos. As sadas principais so coletas de necessidades e recursos priorizados dos envolvidos, que permitem o refinamento do documento de viso e fornecem um melhor entendimento dos atributos de requisito. Alm disso, durante essa atividade voc pode comear discutindo o sistema em termos de casos de uso e agentes. Outra sada importante um glossrio atualizado de termos para facilitar o vocabulrio comum entre os membros da equipe.

14

Aplicando Gerenciamento de Requisitos com Casos de Uso

Figura 11Entendendo as Necessidades dos Envolvidos

Atividade: Entender as Necessidades dos Envolvidos O analista de sistemas e os envolvidos-chave identificam envolvidos adicionais, fazem o levantamento de seus pedidos e determinam as necessidades e recursos fundamentais atravs de entrevistas, workshops, storyboards, casos de uso de processos de negcios e outras tcnicas. Um ou mais analistas de sistemas auxiliam essas sesses. Esses workshops de requisitos esto entre as tcnicas de levantamento mais teis. O processo inclui usurios, pessoal de helpdesk, proprietrios de empresas, testadores e outros que tm um interesse no resultado do projeto proposto. Os pedidos dos envolvidos so freqentemente ambguos, sobrepostos e at estranhos. Alm dos resultados do levantamento formal, os pedidos dos envolvidos podem ser expressos em documentos bem formatados, em defeitos e pedidos de aprimoramento de bancos de dados ou em encadeamentos de e-mail e groupware. Os analistas de sistemas registram, categorizam e priorizam as necessidades identificadas dos envolvidos-chave.

Entender as Necessidades dos Envolvidos: Onde Comea o "Deleite dos Clientes"

Os pedidos dos envolvidos so capturados ao mximo na linguagem e no formato do envolvido que est fazendo o pedido. Ao contrrio dos tipos de requisitos subseqentes, que normalmente tm autoria dos membros da equipe do projeto treinados para o processo e proficientes tecnicamente, os pedidos dos envolvidos so freqentemente expressos de forma ruim. Eles so duplicados ou sobrepostos. Eles podem ser expressos sobre qualquer coisa, desde tiras de papel a bancos de dados de pedidos de aprimoramento. O analista (ou equipe que representa a funo de analista) deve revisar todos os pedidos, interpret-los, agrup-los, talvez digit-los novamente (sem reescrev-los) e traduzi-los para as necessidades e recursos do sistema fundamentais dos envolvidos no documento de viso. Dependendo do rigor aplicado em seu desenvolvimento e na disponibilidade de ferramentas, a rastreabilidade entre alguns pedidos (ou todos) dos envolvidos, as necessidades e os recursos podem ser aplicados para ajudar os envolvidos a entender como seus pedidos e necessidades so considerados na determinao dos requisitos do sistema. Demonstrar srio interesse para fazer o levantamento de pedidos e satisfazer as necessidades dos envolvidos, aplicando a Atividade Entendendo as Necessidades dos Envolvidos, pode ser crtico para estabelecer a confiana do envolvido nas habilidades da equipe de desenvolvimento.

15

Aplicando Gerenciamento de Requisitos com Casos de Uso

Baseado em um melhor entendimento das necessidades dos envolvidos, os analistas de sistemas na equipe de desenvolvimento refinam o documento de viso, prestando ateno especial ao desenvolvimento de uma "declarao de posio de produto". Em duas ou trs sentenas, essa declarao estabelece o valor convincente do projeto. A declarao deve incluir os usurios planejados, os problemas que ela soluciona, os benefcios que ela fornece e os concorrentes que ela substitui. Todos os membros da equipe devem entender esse tema do projeto. Os analistas de sistemas tambm atualizam o glossrio para facilitar o entendimento comum dos termos. Os envolvidos-chave so consultados em vrios pontos para negociar prioridades de novos recursos derivados do entendimento das necessidades dos envolvidos e ganham um entendimento atual dos recursos e esforos necessrios para desenvolv-los. Como ocorre na anlise de problemas, o gerenciamento de dependncias nessa atividade ajuda a gerenciar o escopo. Ele tambm estabelece a rastreabilidade entre os pedidos dos envolvidos, necessidades e recursos do sistema, portanto, os envolvidos podem assegurar-se de que suas entradas foram consideradas. Atividade: Definir o Sistema As duas primeiras atividades de Requisitos, Analisar o Problema e Entender as Necessidades dos Envolvidos, criam iteraes antecipadas das definies do sistema-chave, incluindo recursos especificados no documento de viso, um primeiro esboo para o modelo de caso de uso e atributos de requisitos iniciais. A prxima atividade, Definir o Sistema, completa a descrio dos requisitos do sistema de nvel alto com refinamento das definies de recurso, a adio de novos agentes, casos de uso e especificaes suplementares.

Figura 12Definindo o Sistema

Atividade: Definir o Sistema O glossrio atualizado para refletir o entendimento atual sobre os termos utilizados para descrever recursos e os requisitos capturados no modelo de caso de uso e nas Especificaes Suplementares. O analista de sistemas utiliza o conjunto de recursos definido na viso refinada para derivar e descrever os casos de uso que elaboram a viso dos usurios do comportamento esperado do sistema. O modelo de caso de uso serve como um contrato entre o cliente, os usurios e os desenvolvedores do sistema sobre como os recursos selecionados funcionaro no sistema. Ele ajuda a definir expectativas e objetivos realsticos para desenvolvedores do sistema e ajuda os clientes e usurios a confirmarem que o sistema atender a essas expectativas. Alguns requisitos do sistema no se ajustam bem em casos de uso. O analista de sistemas os descreve em uma especificao suplementar. Muitos requisitos no funcionais, como usabilidade, confiabilidade, desempenho e suportabilidade freqentemente so finalizados aqui. Deve ser observado que muitos requisitos no funcionais desses tipos so especficos a um nico caso de uso. melhor para os especificadores de casos de uso colocar esses requisitos na prpria especificao de caso de uso (consulte a atividade Refinando o Sistema), deixando a especificao suplementar para requisitos no funcionais em todo o sistema.

16

Aplicando Gerenciamento de Requisitos com Casos de Uso

Nessa atividade, o analista de sistemas cria e define atributos para requisitos suplementares (como prioridade e casos de uso relacionados). Alm disso, o analista de sistemas inclui e atualiza valores de atributos para os casos de uso iniciais e novos. Finalmente, o analista de sistemas gerencia dependncias rastreando necessidades importantes do usurio e recursos crticos para casos de uso relacionados e requisitos descritos em especificaes suplementares. Atividade: Gerenciar o Escopo do Sistema Depois de identificar os requisitos no nvel do recurso, descrever a maioria dos agentes, casos de uso e outros requisitos especificados nas especificaes suplementares, o analista de sistemas deve reunir e designar valores o mais precisamente possvel aos atributos de requisito, como prioridade, esforo, custo e risco. Isso permite um melhor entendimento sobre como determinar o escopo inicial do release do sistema e tambm pode permitir que o arquiteto identifique casos de uso arquiteturalmente significativos. O plano de iterao, desenvolvido em paralelo pelo gerenciamento de projeto e de desenvolvimento, aparece primeiro nessa atividade: Gerenciar o Escopo do Sistema. Tambm conhecido como um plano de desenvolvimento, o plano de iterao define o nmero e a freqncia de iteraes planejadas para o release. Os elementos de maior risco dentro do escopo devem ser planejados para iteraes antecipadas. Outras sadas importantes da atividade Gerenciando o Escopo incluem a iterao inicial do documento da arquitetura de software e uma viso revisada que reflete o entendimento crescente dos analistas e envolvidos-chave sobre a funcionalidade do sistema e os recursos do projeto. Como ocorre no caso de negcios, mencionado anteriormente, e no primeiro problema do plano de iterao, o documento da arquitetura de software no um artefato do gerenciamento de requisitos, embora esteja relacionado e faa parte do Rational Unified Process. Ele no assunto desse documento.

A experincia ensina que as chaves para gerenciar o escopo com xito so valores de atributo bem considerados designados s necessidades dos envolvidos, recursos, casos de uso e outros requisitos especificados em especificaes suplementares; juntamente com iterao regular, aberta e honesta com os envolvidos representativos.

Figura 13Gerenciando o Escopo do Sistema

17

Aplicando Gerenciamento de Requisitos com Casos de Uso

Atividade: Gerenciar o Escopo do Sistema Os arquitetos priorizam casos de uso para sua cobertura de risco, significncia arquitetural e cobertura arquitetural. Enquanto o sistema pode ser definido com vrios requisitos de casos de uso e especificaes suplementares, apenas um subconjunto de casos de uso normalmente crtico para uma boa arquitetura de sistema. Com casos de uso priorizados, os arquitetos refinam a iterao ou o plano de desenvolvimento e modelam uma visualizao de caso de uso da arquitetura do sistema em ferramentas, como o Rational Rose. Os analistas de sistemas gerenciam dependncias refinando atributos de requisitos para recursos na viso. Eles tambm refinam requisitos em casos de uso e em especificaes suplementares. Os analistas de sistemas asseguram que existe rastreabilidade* adequada para os requisitos de necessidades, recursos e casos de uso dos envolvidos e requisitos de especificaes suplementares. O termo "rastreabilidade adequada" deliberado. Consulte o texto em Rastreabilidade posteriormente neste documento. Esta etapa est entre a mais importante no projeto inteiro. Pela primeira vez, a amplitude de conhecimento sobre o sistema proposto est disponvel para tornar srios os compromissos de requisitos, recursos do projeto e datas de entrega. Ao mesmo tempo, deve-se entender que esses requisitos sero alterados conforme aumenta a profundidade de conhecimento. Se as dependncias tiverem sido gerenciadas nas trs atividades anteriores, esta etapa ser bem mais fcil e as alteraes futuras sero mais fceis. Durante todo o projeto, conforme so alteradas as situaes e ambientes, essa atividade revisitada vrias vezes porque o analista de sistemas deve negociar o escopo e a viso do projeto revisado com os envolvidos-chave. O gerenciamento do escopo do projeto para que corresponda aos recursos disponveis ser bem-sucedido apenas se os envolvidos e os membros da equipe de desenvolvimento visualizem essa etapa como uma progresso natural no como uma cilada para as expectativas dos usurios ou uma tentativa de extorquir da organizao mais tempo e dinheiro. Essa atividade precisar ser repetida em marcos principais no projeto para avaliar se a nova percepo do sistema e de seus problemas requer alterao no escopo. Como requisitos, oramentos e prazos finais confirmados so difceis de serem alterados, um entendimento profundo de casos de uso priorizados, de especificaes suplementares e de iteraes antecipadas do sistema inevitavelmente leva reconsiderao do escopo. Novamente, importante que a equipe do projeto se comprometa com o gerenciamento habitual do escopo antes de chegar ao estgio de refinamento, bem como com todo o ciclo de vida do projeto conforme ocorrem as alteraes. Os envolvidos representativos devem entender e confiar que suas prioridades e interesses so considerados seriamente durante as negociaes de escopo cada vez mais difceis. Enquanto os requisitos do sistema so refinados, apenas requisitos importantes permanecem para serem negociados ou modificados. A menos que hbitos efetivos de gerenciamento de escopo tenham sido estabelecidos, seu projeto poder estar destinado a uma "marcha da morte" um projeto irremediavelmente com excesso de escopos movendo-se inexoravelmente em direo a atrasos e excessos de custo. Atividade: Refinar a Definio do Sistema Seguindo em direo a Refinar a Definio do Sistema, os detalhes dessa atividade assumem que os casos de uso no nvel do sistema foram esboados e os agentes foram descritos, ao menos brevemente. Atravs do gerenciamento do escopo do projeto, os recursos na viso foram novamente priorizados e agora acredita-se que sejam realizveis com oramentos e datas completamente seguros. A sada dessa atividade um entendimento mais profundo da funcionalidade do sistema expressa em casos de uso detalhados, especificaes suplementares revisadas e iteraes antecipadas do prprio sistema. Obviamente, nem todos os sistemas tero interfaces com o usurio e nem todas as iteraes antecipadas incluiro elementos da GUI. Ns os utilizamos aqui apenas como um exemplo de uma iterao antecipada. Outros exemplos incluem prottipos, modelos e storyboards.

18

Aplicando Gerenciamento de Requisitos com Casos de Uso

Figura 14Refinando a Definio do Sistema

Atividade: Refinar a Definio do Sistema O especificador de caso de uso detalha a definio do fluxo de eventos, pr e ps-condies e outras propriedades textuais de cada caso de uso. Para minimizar o esforo e aprimorar a capacidade de leitura, aconselhvel utilizar um formato de documento padro ou um gabarito de especificao de caso de uso para capturar informaes textuais sobre cada caso de uso. A criao de especificaes de caso de uso bem consideradas crtica para a qualidade do sistema. Esse desenvolvimento de especificao requer um entendimento completo das necessidades e dos recursos dos envolvidos relacionados ao caso de uso. desejvel que vrios membros da equipe do projeto (como engenheiros de software) participem na criao de casos de uso. Em paralelo, o especificador de caso de uso revisa a especificao suplementar com requisitos adicionais que no so especficos para o caso de uso. O designer da interface com o usurio modela e utiliza um prottipo da interface com o usurio do sistema. Esse trabalho est altamente correlacionado com a evoluo dos casos de uso. O especificador de caso de uso e o analista de sistemas revisam o esforo, o custo, o risco e outros valores de atributo para cada requisito que entendido melhor. Os resultados desse refinamento da definio do sistema so enviados para outra rodada da atividade Gerenciando o Escopo. Depois de saber mais sobre o sistema, voc poder desejar alterar as prioridades. Mais definitivamente, o escopo do release do sistema precisar ser revisado e refinado, se necessrio. Atividade: Gerenciar a Alterao de Requisitos Conforme ocorrem as alteraese elas ocorrero inevitavelmentea atividade Gerenciar a Alterao de Requisitos precisa ser aplicada continuamente durante toda a vida do projeto, conforme discutido em Gerenciar o Escopo do Sistema. A sada dessa atividade pode causar modificaes em cada artefato, que, por sua vez, requer comunicao efetiva entre todos os membros da equipe do projeto e envolvidos. Nessa atividade, introduzimos artefatos adicionais que so afetados pelas atividades de requisitos. As alteraes em requisitos afetam naturalmente os modelos de sistema que so representados nas atividades de anlise & design. As alteraes de

19

Aplicando Gerenciamento de Requisitos com Casos de Uso

requisito tambm afetam os testes criados para validar a implementao adequada dos requisitos. Como nos exemplos anteriores, esses artefatos so parte do Rational Unified Process, mas no so os assuntos deste documento. Os relacionamentos de rastreabilidade identificados no processo de gerenciamento de dependncias so as chaves para entender esses impactos.

Rastreabilidade

Muito feito da rastreabilidade no campo de requisitos. Muitos promovem a eficcia do rastreamento de requisitos individuais do cliente para cada especificao, teste, elemento de modelo e, essencialmente, arquivos de cdigo fonte relacionados. Certamente, alguma rastreabilidade a chave para o gerenciamento bem-sucedido de alteraes de requisitos. Saiba, no entanto, que todas as formas de rastreabilidade requerem um gasto com configurao e manuteno durante a vida do projeto. Como em todos os gastos, a rastreabilidade diminui pontos de retorno dependendo de sua situao especfica. Este documento enfatiza o valor do rastreamento entre tipos diferentes de requisitos. Esse um bom local para comear e pode ser automatizado por ferramentas, como o Rational RequisitePro, o Rational Rose, o Rational SoDA e o Rational TeamTest. Acreditamos que voc achar que algum nvel de rastreabilidade de requisitos um bom gasto. Para obter informaes adicionais sobre estratgias diferentes para rastreabilidade de requisitos, consulte o white paper, "Estratgias de Rastreabilidade para Gerenciar Requisitos com Casos de Uso" [6].
Field Code Changed

Outro conceito importante para Gerenciar a Alterao de Requisitos o rastreamento do histrico de requisitos. Pela assimilao da natureza e base racional das alteraes de requisitos, os revisores (algum da equipe de projeto de software cujo trabalho seja afetado pela alterao) recebem as informaes necessrias para responder alterao corretamente.

Figura 15Gerenciando Alterao de Requisitos

20

Aplicando Gerenciamento de Requisitos com Casos de Uso

Atividade: Gerenciar a Alterao de Requisitos Os pedidos de alteraes em requisitos podem ser iniciados por qualquer envolvido ou membro da equipe do projeto por diversas razes. Todos os CRs (Controle de Alteraes), incluindo alteraes em requisitos ou em pedidos de aprimoramento, bem como defeitos, devem passar pelo mesmo processo CRM (Gerenciamento de Controle de Alteraes). No mnimo, ele deve incluir o registro e o rastreio do pedido em um sistema de banco de dados centralizado e deve forar a reviso por uma autoridade de reviso central. Consulte outras sees do Rational Unified Process para obter detalhes adicionais de tal processo CRM. O analista de sistemas deve coordenar a atividade de reviso, preferivelmente por um CCB (Conselho de Controle de Alteraes), coletando e revisando todos os controles de alteraes, e classific-los como: defeitos na implementao que no afetam os requisitos modificaes de algum tipo em requisitos existentes solicitaes de melhoria

Depois de classificadas, as alteraes de requisitos propostas recebem atributos e valores, conforme descrito em outras atividades de requisitos. Na reviso dos controles de alteraes, o analista de sistemas apresenta as alteraes de requisitos priorizadas propostas a um CCB composto de envolvidos representativos e membros da equipe do projeto. As modificaes de escopo que excedem os recursos devem ser rejeitadas ou levantadas para os representantes dos envolvidos que podem aprovar as alteraes requeridas para compromissos de datas e oramentos. O CCB aprova ou rejeita as alteraes de requisitos. O analista de sistemas comunica as alteraes de requisitos ao especificadores de requisitos ou faz as alteraes diretamente nos requisitos na viso, nos casos de uso, nos documentos de especificao suplementar ou em outros artefatos de requisitos. Os revisores de requisitos (desenvolvedores, testadores, gerentes e outros membros da equipe do projeto) avaliam o impacto das alteraes dos requisitos em seu trabalho, revisando o histrico de requisitos. implementarFinally, eles implementam a alterao e fazem as alteraes necessrias aos requisitos relativos para os quais tem autoridade.

Sumrio
A necessidade de gerenciar requisitos no nova. Portanto, o que faz com que as informaes precedentes sejam consideradas agora? Primeiro, se seus projetos no estiverem satisfazendo os clientes regularmente, atendendo aos prazos finais e ficando dentro do oramento, voc tem razes para reconsiderar a sua abordagem de desenvolvimento. Se ao fazer isso, voc determinar que os problemas relacionados aos requisitos esto minando os seus esforos de desenvolvimento, voc tem razes para considerar boas prticas de gerenciamento de requisitos. Segundo, as prticas de gerenciamento de requisitos resumidas neste documento englobam a experincia coletiva de milhares e so as opinies bem consideradas de uma srie de indivduos que passaram anos trabalhando com clientes no campo de gerenciamento de requisitos. Sugerimos que essa viso geral de suas contribuiese a mais direta apresentao delas feita no Rational Unified Processrepresentem uma "boa prtica" no gerenciamento de requisitos. Voc no encontrar mais pareceres comprovados sobre requisitos em nenhum lugar. Os autores gostariam de agradecer as contribuies diretas e indiretas do Dr. Ivar Jacobson e de Dean Leffingwell, Dr. Alan Davis, Ed Yourdon e Elemer Magaziner. O mais importante que apreciamos os clientes da Rational Software que aplicaram e aprimoraram essas prticas em centenas de projetos de desenvolvimento. Finalmente, nos dois ltimos anos, a Rational Software, uma lder na produo de solues efetivas de desenvolvimento de software, assumiu o desafio de gerenciamento de requisitos e surgiu com as ferramentas para automatizar essa tarefa difcil. Os problemas crnicos e difusos do gerenciamento de requisitos so solucionveis. E, essencialmente, pode ser a melhor razo para iniciar a prtica de excelncia em gerenciamento de requisitos nos dias de hoje. Para obter uma discusso completa dos conceitos acima, consulte o excelente livro de Dean Leffingwell sobre Managing Software Requirements [7].
Field Code Changed

21

Aplicando Gerenciamento de Requisitos com Casos de Uso

Referncias
[1] CHAOS, The Standish Group International, Inc., Dennis, MA, 1994, 1997. [2] Computer Industry Daily, 12 de dezembro de 1997. [3] Dorfman, M. e R. Thayer, Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1997 pp. 79. [4] Dorfman, M. e R. Thayer, Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1997 pp. 80. [5] Spence, Ian e Leslee Probasco, Estratgias de Rastreabilidade para Gerenciar Requisitos com Casos de Uso, White Paper, Rational Software Corporation, 1998. [6] Rational Unified Process, Rational Software Corporation, Cupertino, CA, 1999. [7] Leffingwell, Dean e Don Widrig, Managing Software Requirements A Unified Approach, AddisonWesley, 2000.

22

Duas Sedes: Rational Software 18880 Homestead Road Cupertino, CA 95014 Tel: (408) 863-9900 Rational Software 20 Maguire Road Lexington, MA 02421 Tel: (781) 676-2400 Sem custo: (800) 728-1212 E-mail: info@rational.com Web: www.rational.com Localizao Internacional:www.rational.com/worldwide Rational, o logotipo Rational e Rational Unified Process so marcas registradas da Rational Software Corporation nos Estados Unidos e/ou outros pases. Microsoft, Microsoft Windows, Microsoft Visual Studio, Microsoft Word, Microsoft Project, Visual C++ e Visual Basic so marcas ou marcas registradas da Microsoft Corporation. Todos os outros nomes so usados apenas para fins de identificao e so marcas ou marcas registradas de suas respectivas empresas. TODOS OS DIREITOS RESERVADOS. Feito nos EUA. Copyright 2002 Rational Software Corporation. Sujeito mudanas sem aviso prvio.

Field Code Changed Field Code Changed Field Code Changed