Engenharia de Requisitos

.
Engenharia de Software I
PROCESSOS DE
ENGENHARIA DE REQUISITOS
1. INTRODUO
O objetivo do processo de engenharia de requisitos criar e manter um
documento de requisitos de sistema. O processo geral inclui quatro subprocessos de alto nvel
de engenharia de requisitos. Eles esto relacionados :
estudo de viabilidade: avaliao se o sistema til para a empresa
elicitao e anlise: obteno de requisitos
especificao: converso desses requisitos em alguma forma padro
validao: verificao se os requisitos realmente definem o sistema
que o cliente deseja
A Figura 1.1 ilustra o relacionamento entre essas atividades. Ela mostra
tambm os documentos produzidos em cada estgio do processo de engenharia de requisitos.
A especificao e a documentao foram abordadas na apostila 2 Requisitos de Software e
esta apostila se concentra nas outras atividades da engenharia de requisitos.
As atividades mostradas na Figura 1.1 esto relacionadas obteno,
documentao e verificao de requisitos. Na prtica, no entanto, todos os requisitos de
sistema mudam. As pessoas envolvidas desenvolvem uma compreenso maior do que
desejam que o software faa, a organizao que est comprando o sistema muda, so feitas
modificaes no hardware, no software e no ambiente organizacional do sistema. O processo
de gerenciamento dessas mudanas de requisitos denominado gerenciamento de requisitos
e abordado na seo final desta apostila.
Estudo de
viabilidade
Elicitao e
anlise de
requisitos
Especificao
de requisitos
Relatrio de
viabilidade
Validao de
requisitos
Modelos de
sistemas
Requisitos de
usurio e de
sistema
Documento
de requisitos
Figura 1.1 Processo de engenharia de requisitos
Engenharia de Software
Prof. Me. Marcelo dos Santos Moreira
PROCESSOS DE
A figura 1.2 apresenta uma perspectiva alternativa do processo de engenharia
de requisitos modelo espiral. Ela mostra o processo como uma atividade de trs estgios,
no qual as atividades esto organizadas como um processo iterativo em espiral. A quantidade
de tempo e esforo dispensado para cada atividade na iterao depende do estgio do
processo geral e do tipo de sistema que est sendo desenvolvido. No incio do processo, a
maior parte do esforo ser empregada na compreenso dos requisitos de alto nvel de
negcios, requisitos no funcionais e requisitos de usurio. Prximo ao fim do processo, nas
partes mais externas da espiral, um esforo maior ser dedicado engenharia de requisitos e
modelagem de sistema.
O modelo em espiral acomoda abordagens de desenvolvimento em que os
requisitos so desenvolvidos para diferentes nveis de detalhes. O nmero de iteraes na
espiral pode variar, de modo que se pode sair da espiral depois que alguns ou todos os
requisitos de usurio tiverem sido elicitados. Se a atividade de prototipao apresentada sob a
validao de requisitos for ampliada para incluir o desenvolvimento iterativo, este modelo
permitir que os requisitos e a implementao de sistema sejam desenvolvidos em conjunto.
Especificao
de requisitos
Especificao de
requisitos de sistema
e modelagem
Especificao de
requisitos de usurio
Especificao de
requisitos de negcios
Elicitao de
requisitos
de sistema
Elicitao de
requisitos
de usurio
Elicitao de
requisitos
Estudo de
viabilidade
Prototipao
Validao de
requisitos
Revises
Documento de requisitos
de sistema
Figura 1.2 Modelo em espiral dos processos de engenharia de requisitos
Algumas pessoas consideram a engenharia de requisitos como se fosse o

processo de aplicao de um mtodo estruturado de anlise como, por exemplo, a anlise
orientada a objetos. Isso consiste na anlise do sistema e no desenvolvimento de um conjunto
de modelos grficos de sistemas, como modelos de casos de uso, que servem como uma
especificao de sistema. O conjunto de modelos descreve o comportamento do sistema e
PROCESSOS DE
inclui anotaes com descries adicionais de informaes como, por exemplo, o desempenho
ou a confiabilidade necessria.
Embora os mtodos estruturados possuam um papel a desempenhar no
processo de engenharia de requisitos, existe muito mais sobre engenharia de requisitos do que
abordado nesses mtodos. A elicitao de requisitos, em particular, uma atividade centrada
em pessoas, e as pessoas no gostam das restries impostas pelos modelos rgidos de
sistema.
2. ESTUDO DE VIABILIDADE
Em todos os sistemas novos, o processo de engenharia de requisitos deve
comear com um estudo de viabilidade. A entrada para o estudo de viabilidade consiste de um
conjunto preliminar de requisitos de negcios, um esboo da descrio do sistema e como o
sistema pretende apoiar os processos de negcios. Os resultados do estudo de viabilidade
devem estar em um relatrio que recomenda se vale a pena ou no prosseguir com os
processos de engenharia de requisitos e de desenvolvimento do sistema.
Um estudo de viabilidade um estudo breve e focalizado que procura
responder a uma srie de questes:
1. O sistema contribui para os objetivos gerais da organizao?
2. O sistema pode ser implementado com tecnologia atual e dentro das
restries definidas de custo e prazo?
3. O sistema pode ser integrado a outros sistemas j implantados?
A questo de se o sistema contribui ou no para os objetivos da empresa
crtica. Se um sistema no apoia esses objetivos, ele no tem valor real para a empresa.
Apesar de esse fato parecer bvio, muitas organizaes desenvolvem sistemas que no
contribuem para seus objetivos, porque elas no tm um perfil claro desses objetivos, pois
falham em definir os requisitos de negcios para o sistema, ou porque outros fatores polticos
ou organizacionais influenciam na aquisio do sistema.
A realizao de um estudo de viabilidade envolve a avaliao de informaes,
sua coleta e a elaborao de um relatrio.
A avaliao de informaes identifica as informaes necessrias para
responder s trs questes apresentadas anteriormente. Aps a identificao das informaes,
necessrio falar com as fontes de informaes para descobrir as respostas a essas
perguntas. Alguns exemplos de possveis questes que podem ser levantadas so:
PROCESSOS DE
1. Como a organizao se comportaria se esse sistema no fosse
implementado?
2. Quais so os problemas com os processos atuais e como o novo
sistema ajudaria a reduzir esses problemas?
3. Qual ser a contribuio direta do sistema para os objetivos e requisitos
da empresa?
4. As informaes podem ser transferidas e recebidas de outros sistemas
da organizao?
5. O sistema requer tecnologia que ainda no foi usada na organizao?
6. O que deve ser apoiado pelo sistema e o que no precisa ser apoiado?
Em um estudo de viabilidade, pode-se consultar fontes de informaes como
os gerentes de departamentos em que o sistema ser usado, engenheiros de software
familiarizados com o tipo de sistema proposto, especialistas em tecnologia e usurios finais do
sistema. Normalmente, deve-se tentar concluir um estudo de viabilidade em duas ou trs
semanas. Aps obter as informaes, elaborado o relatrio de estudo de viabilidade. Deve-se
fazer uma recomendao de se o desenvolvimento do sistema deve ou no prosseguir. No
relatrio podem ser propostas mudanas de escopo, oramento e prazo e sugerir requisitos de
alto nvel adicionais para o sistema.
3. ELICITAO E ANLISE DE REQUISITOS

O prximo estgio do processo de engenharia de requisitos a elicitao e
anlise de requisitos. Nessa atividade, os engenheiros de software trabalham com os clientes e
os usurios finais do sistema para aprender sobre o domnio da aplicao, quais servios o
sistema deve fornecer, o desempenho esperado do sistema, restries de hardware etc.
A elicitao e a anlise de requisitos podem envolver vrias pessoas de uma
organizao. O termo stakeholder usado para se referir a qualquer pessoa ou grupo afetado
pelo sistema, direta ou indiretamente. Os stakeholders incluem os usurios finais que
interagem com o sistema e todo pessoal na organizao que possa ser afetado por sua
instalao. Outros stakeholders no sistema podem ser os engenheiros que esto
desenvolvendo ou mantendo sistemas relacionados, gerentes de negcios, especialistas do
domnio e representantes do sindicato.
A elicitao e a compreenso dos requisitos dos stakeholders so difceis
devido a vrias razes:
PROCESSOS DE
1. Os stakeholders, frequentemente, no sabem o que querem do sistema
de computador a no ser em termos gerais. Eles podem achar difcil
articular o que desejam que o sistema faa ou fazem pedidos no
realistas, pois ignoram o custo de seus requisitos.
2. Os stakeholders expressam os requisitos naturalmente em seus
prprios termos e com o conhecimento implcito de se trabalho. Os
engenheiros de requisitos, sem experincia no domnio do cliente,
devem entender esses requisitos.
3. Diferentes stakeholders possuem diferentes requisitos, expressos de
diferentes formas. Os engenheiros de requisitos precisam considerar
todas as fontes potenciais de requisitos e descobrir pontos em comum
e conflitos.
4. Fatores polticos podem influenciar os requisitos do sistema. Por
exemplo, os gerentes podem solicitar requisitos especficos do sistema
que aumentaro a sua influncia na organizao.
5. O ambiente econmico e de negcios sobre o qual a anlise
realizada dinmico. Ele muda inevitavelmente durante o processo de
anlise. Portanto, a importncia de determinado requisito pode mudar.
Novos requisitos podem surgir de novos stakeholders que no haviam
sido consultados anteriormente.
Um modelo de processo bastante genrico de elicitao e anlise de requisitos
apresentado na figura 3.1. Cada organizao ter a sua prpria verso ou modelo desse
modelo geral, dependendo de fatores locais, como o nvel de conhecimento da equipe, o tipo
do sistema que est sendo desenvolvido e os padres usados. Novamente, pode-se pensar
nessas atividades como uma espiral, de modo que as atividades se intercalem medida que o
processo progrida da parte interna da espiral para a externa.
As atividades de processo so:
1. Obteno de requisitos: o processo de interao com os
stakeholders no sistema para coletar os seus requisitos. Os requisitos
de domnio so tambm descobertos durante essa atividade,
provenientes dos stakeholders e da documentao.
2. Classificao e organizao de requisitos: esta atividade envolve a
coleo
de requisitos no
estruturados,
agrupa
os requisitos
relacionados e os organiza em conjuntos coerentes.

PROCESSOS DE
3. Priorizao e negociao de requisitos: inevitavelmente, quando

vrios stakeholders participam do processo, os requisitos sero
conflitantes. Esta atividade est relacionada priorizao de requisitos,
procura e resoluo de conflitos de requisitos por meio da
negociao.
4. Documentao de requisitos: os requisitos so documentados e
colocados na prxima volta da espiral. Podem ser produzidos
documentos de requisitos formais ou informais.
A figura 3.1 mostra que a elicitao e a anlise de requisitos um processo
iterativo com realimentao contnua de cada atividade para outras atividades. O ciclo do
processo comea com a obteno de requisitos e termina com a documentao de requisitos.
O entendimento dos requisitos pelo analista aumenta a cada volta do ciclo.
Aqui enfocado principalmente a descoberta de requisitos e as diversas
tcnicas desenvolvidas para dar apoio a essas atividades. A classificao e a organizao de
requisitos esto relacionadas principalmente com a identificao da sobreposio de requisitos
dos diferentes stakeholders e o agrupamento de requisitos relacionados. O modo mais comum
de agrupamento de requisitos usar um modelo de arquitetura de sistema para identificar os
subsistemas e associar os requisitos a cada subsistema. Isso enfatiza que a engenharia de
requisitos e o projeto de arquitetura nem sempre podem estar separados.
Inevitavelmente,
os stakeholders possuem
vises diferentes sobre a
importncia e a prioridade dos requisitos e, algumas vezes, essas vises entram em conflito.
Durante o processo, deve-se organizar negociaes frequentes com os stakeholders, de modo
que os compromissos possam ser atingidos. impossvel satisfazer completamente a todos os
stakeholders, mas, se alguns deles perceberem que suas vises no foram consideradas de
maneira apropriada, eles podem tentar boicotar intencionalmente o processo de engenharia de
requisitos.
No estgio de documentao, os requisitos elicitados so documentados de
modo que possam ser usados para auxiliar as prximas obtenes de requisitos. Nesse
estgio, uma verso inicial dos requisitos do sistema pode ser produzida, mas ter sees
faltantes e requisitos incompletos. Como alternativa, os requisitos podem ser documentados
como tabelas em um documento ou em cartes. Escrever os requisitos em cartes (abordagem
usada na extreme programming) pode ser muito eficiente, pois os stakeholders podem
manusear, alterar e organizar os cartes com facilidade.
PROCESSOS DE
Obteno de
requisitos
Classificao e
organizao de
requisitos
Documentao
de requisitos
Priorizao e
negociao de
requisitos
Figura 3.1 Processo de elicitao e anlise de requisitos
3.1. Obteno de requisitos

A obteno de requisitos o processo que rene informaes sobre o sistema
proposto e os existentes para obter os requisitos de usurio e de sistema com base nessas
informaes. As fontes de informaes, durante a fase de obteno de requisitos, incluem
documentao, stakeholders de sistema e especificaes de sistemas similares. A interao
com os stakeholders ocorre por meio de entrevistas e observaes, podendo ser usados
cenrios e prottipos para auxiliar na obteno dos requisitos. Aqui apresentada uma
abordagem que ajuda a assegurar uma cobertura ampla de stakeholders durante a obteno
de requisitos e descritas tcnicas que incluem entrevistas, cenrios e etnografia. Outras
tcnicas de obteno de requisitos que podem ser usadas incluem mtodos estruturados de
anlise e prototipao de sistema.
Os stakeholders variam de usurios finais do sistema a gerentes e envolvidos
externos, como regulamentadores que certificam a aceitao do sistema. Por exemplo, os
stakeholders em um sistema de caixa eletrnico bancrio incluem:
1. Clientes atuais do banco que recebem servios do sistema.
2. Representantes de outros bancos que tm acordos recprocos que
permitem usar os caixas eletrnicos uns dos outros.
PROCESSOS DE
3. Gerentes de
agncias bancrias
que
obtm
informaes de
gerenciamento do sistema.
4. Pessoal de atendimento nas agncias bancrias envolvidos na
operao diria do sistema.
5. Administradores de banco de dados responsveis pela integrao do
sistema com o banco de dados dos clientes do banco.
6. Gerentes de proteo bancria que devem assegurar que o sistema
no seja exposto a riscos de proteo.
7. Departamento de marketing do banco provavelmente interessado em
usar o sistema como meio de marketing do banco.
8. Engenheiros de manuteno de hardware e software que so
responsveis pela manuteno e atualizao de hardware e software.
9. Reguladores nacionais de bancos responsveis por assegurar que o
sistema esteja em conformidade com os regulamentos bancrios.
Alm dos stakeholders no sistema, vimos anteriormente que os requisitos
podem ser provenientes do domnio de aplicao e de outros sistemas que interagem com o
sistema que est sendo especificado. Tudo isso deve ser considerado durante o processo de
elicitao de requisitos.
Essas fontes de requisitos (stakeholders, domnio, sistemas) podem ser
representadas como pontos de vista do sistema, em que cada ponto de vista apresenta um
subconjunto de requisitos do sistema. Cada ponto de vista fornece uma perspectiva nova do
sistema, mas essas perspectivas no so completamente independentes elas geralmente se
sobrepem de modo que haja requisitos comuns.
Pontos de vista
As abordagens orientadas a pontos de vista para engenharia de requisitos
organizam o processo de elicitao e os prprios requisitos usando pontos de vista. Um ponto
forte da anlise orientada a pontos de vista que ela reconhece vrias perspectivas e fornece
um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders.
Os pontos de vista podem ser usados como um meio de classificao de
stakeholders e de outras fontes de requisitos. Existem trs tipos genricos de pontos de vista:
PROCESSOS DE
1. Pontos de vista de interao: representam pessoas ou outros
sistemas que interagem diretamente com o sistema. No sistema de
caixa eletrnico bancrio, exemplos de pontos de vista de interao
so os clientes do banco e o banco de dados de contas bancrias.
2. Pontos de vista indiretos: representam os stakeholders que no
usam o sistema diretamente, mas que influenciam requisitos de alguma
forma. No sistema de caixa eletrnico bancrio, exemplos de pontos de
vista indiretos so a gerncia do banco e o pessoal de proteo do
banco.
3. Pontos de vista de domnio: representam caractersticas e restries
de domnio que influenciam os requisitos de sistema. No sistema de
caixa eletrnico bancrio, um exemplo de um ponto de vista de domnio
so os padres desenvolvidos para comunicaes entre os bancos.
Tipicamente, esses pontos de vista fornecem diferentes tipos de requisitos:
os pontos de vista de interao fornecem requisitos de sistema

detalhados que abrangem as caractersticas e as interfaces do sistema.
os pontos de vista indiretos so os que mais provavelmente

fornecem requisitos e restries organizacionais de alto nvel.
os pontos de vista de domnio fornecem normalmente as restries

de domnio que se aplicam ao sistema.
A identificao inicial dos pontos de vista relevantes ao sistema pode ser difcil
algumas vezes. Para ajudar nesse processo, deve-se tentar identificar tipos mais especficos
de pontos de vista:
1. Fornecedores e receptores de servios do sistema.
2. Sistemas que devem interfacear diretamente com o sistema que est
sendo especificado.
3. Regulamentos e padres que se aplicam ao sistema.
4. Fontes de requisitos de negcios e no funcionais do sistema.
5. Pontos de vista de engenharia que refletem os requisitos de pessoas
que devem desenvolver, gerenciar e manter o sistema.
PROCESSOS DE
6. Pontos de vista de marketing e outros pontos de vista que geram
requisitos de caractersticas do produto esperadas pelos clientes e
como o sistema deve refletir a imagem externa da organizao.
Quase todos os sistemas organizacionais devem interoperar com outros
sistemas na organizao. Quando um novo sistema planejado, as interaes com outros
sistemas devem ser planejadas. As interfaces oferecidas por esses outros sistemas j foram
projetadas. Elas podem incluir requisitos e restries sobre o novo sistema. Alm disso, novos
sistemas podem precisar estar em conformidade com regulamentos e padres preexistentes
que restringem os requisitos do sistema.
Conforme explicado anteriormente, deve-se identificar os requisitos de negcio
e no funcionais de alto nvel no incio do processo de engenharia de requisitos. As fontes
desses requisitos podem ser pontos de vista teis em um processo mais detalhado. Elas
devem ser capazes de expandir e desenvolver os requisitos de alto nvel gerando requisitos de
sistema mais especficos.
Os pontos de vista de engenharia podem ser importantes por duas razes.
Primeiro, os engenheiros que desenvolvem o sistema podem ter experincia com sistemas
similares e ser capazes de sugerir requisitos levando em conta essa experincia. Segundo, o
pessoal tcnico que deve gerenciar e manter o sistema pode ter requisitos que iro ajudar a
simplificar o apoio ao sistema. Os requisitos de gerenciamento de sistema so cada vez mais
importantes, pois os custos de gerenciamento constituem uma poro cada vez maior dos
custos totais no tempo de vida do sistema.
Finalmente, os pontos de vista que fornecem requisitos podem ser
provenientes dos departamentos de marketing ou de negcios externos em uma organizao.
Isso especialmente verdadeiro em sistemas baseados na Web, mais especificamente
sistemas de e-commerce e softwares comerciais. Os sistemas baseados na Web devem
apresentar uma imagem favorvel da organizao, assim como oferecer funcionalidade ao
usurio. No tocante a produtos de software, o departamento de marketing deve conhecer quais
caractersticas tornaro o sistema mais atraente aos potenciais compradores.
Para qualquer sistema no trivial, existe um grande nmero de possveis
pontos de vista, e praticamente impossvel elicitar os requisitos baseado em todos eles.
Portanto, importante que se organize e se estruture os pontos de vista em uma hierarquia. Os
pontos de vista do mesmo ramo provavelmente compartilharo requisitos comuns.
Como ilustrao, considere a hierarquia de pontos de vista apresentada na
Figura 3.2. um diagrama relativamente simples de pontos de vista que podem ser
consultados para derivar requisitos para o sistema LIBSYS. Pode-se observar que a
10
PROCESSOS DE
classificao dos pontos de vista de interao, indiretos e de domnio ajuda a identificar fontes
de requisitos independente dos usurios imediatos do sistema.
Depois que os pontos de vista forem identificados e estruturados, pode-se
tentar identificar os pontos de vista mais importantes e iniciar com eles a obteno de
requisitos do sistema.
Todos os pontos de vista
Indiretos
Gerente da
biblioteca
Interao
Fornecedores
de artigos
Usurios
Domnio
Pessoal da
biblioteca
Padres
de IU
Sistema de
classificao
Finanas
Estudantes
Pessoal
Gerente do
sistema
Responsvel
pela catalogao
Externos
Figura 3.2 Pontos de vista no LIBSYS
Entrevistas
Entrevistas formais ou informais com os stakeholders no sistema fazem parte
da maioria dos processos de engenharia de requisitos. Nessas entrevistas, a equipe de
engenharia de requisitos formula questes para os stakeholders sobre o sistema que eles
usam e o sistema a ser desenvolvido. Os requisitos so derivados das respostas a essas
questes. As entrevistas podem ser de dois tipos:
1. Entrevistas fechadas: nas quais o stakeholder responde a um
conjunto de perguntas predefinidas.
2. Entrevistas abertas: nas quais no existe um roteiro predefinido. A
equipe de engenharia de requisitos explora vrios assuntos com os
stakeholders do sistema e, assim, desenvolve uma compreenso maior
de suas necessidades.
11
PROCESSOS DE
Na prtica, as entrevistas com os stakeholders so, geralmente, uma
combinao desses tipos. As respostas a algumas perguntas podem levar a outros assuntos
discutidos de maneira menos estruturada. As discusses completamente abertas raramente
funcionam bem; a maioria das entrevistas requer algumas perguntas como ponto de partida e
para manter o foco no sistema a ser desenvolvido.
As entrevistas so teis para obter um entendimento geral sobre o que os
stakeholders fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam
com os sistemas atuais. As pessoas gostam de falar sobre o seu trabalho e, normalmente,
ficam felizes em participar de entrevistas. No entanto, as entrevistas no so to teis para
compreender os requisitos do domnio da aplicao.
difcil elicitar o conhecimento de domnio durante as entrevistas por dois
motivos:
1. Todos os especialistas de domnio usam terminologia e jarges
especficos. impossvel para eles explicar os requisitos de domnio
sem usar essa terminologia. Eles em geral usam a terminologia de
maneira precisa e especfica, o que facilmente provoca mal-entendidos
por parte dos engenheiros de requisitos.
2. Alguns conhecimentos de domnio so to familiares aos stakeholders
que so considerados difceis de explicar ou considerados to
fundamentais que no vale a pena mencion-los. Por exemplo, para
uma bibliotecria, no h necessidade de dizer que todas as
aquisies so catalogadas antes de serem colocadas na biblioteca.
Contudo, isso pode no ser bvio para o entrevistador e, portanto, no
levado em considerao nos requisitos.
A entrevista no uma tcnica eficiente para elicitao de conhecimentos
sobre os requisitos e as restries organizacionais, pois existem relacionamentos sutis de
poder e influncia entre os stakeholders na organizao. As estruturas organizacionais pblicas
raramente coincidem com a realidade da tomada de decises na organizao, mas os
entrevistados podem no querer revelar a estrutura real, em lugar da terica, a um estranho.
Em geral, a maioria das pessoas relutante em discutir questes polticas e organizacionais
que podem afetar os requisitos.
Os entrevistadores eficientes possuem duas caractersticas:
1. Possuem mente aberta, evitam ideias preconcebidas sobre os
requisitos e querem ouvir os stakeholders. Se o stakeholder propuser
12
PROCESSOS DE
requisitos surpreendentes, os entrevistadores esto dispostos a mudar
de ideia sobre o sistema.
2. Induzem os entrevistados a iniciar as discusses com uma questo,
uma proposta de requisitos ou sugerindo um trabalho conjunto em um
prottipo do sistema. Dizer para as pessoas 'conte-me o que voc
necessita/deseja'
provavelmente
trar
informaes
teis
como
resultado. A maioria das pessoas considera mais fcil falar em um

contexto definido do que em termos gerais.
As informaes obtidas das entrevistas complementam outras informaes
sobre o sistema obtidas de documentos, observaes de usurios etc. s vezes,
independentemente das informaes de documentos, as entrevistas podem ser as nicas
fontes de informaes sobre os requisitos do sistema. No entanto, apenas com as entrevistas
pode haver a perda de informaes essenciais; assim, essa tcnica deve ser usada junto com
outras para a elicitao de requisitos.
Cenrios
As pessoas geralmente consideram mais fcil relatar exemplos da vida real do
que abstrair descries. Elas podem compreender e criticar um cenrio de como interagiriam
com um sistema de software. Os engenheiros de requisitos podem usar as informaes obtidas
nessa discusso para elaborar os requisitos reais do sistema.
Os cenrios podem ser particularmente teis para adicionar detalhes a um
esboo da descrio de requisitos. Eles so descries de exemplos das sesses de interao.
Cada cenrio abrange uma ou mais interaes possveis. Diversos tipos de cenrios foram
desenvolvidos, cada um dos quais fornecendo diferentes tipos de informaes sobre o sistema
em diferentes nveis de detalhamento. O uso de cenrios para descrever requisitos parte
integrante dos mtodos geis, como a extreme programming.
O cenrio comea com um esboo da interao e, durante a elicitao, os
detalhes so adicionados para criar uma descrio completa dessa interao. De maneira geral,
um cenrio deve incluir:
1. Uma descrio do que os usurios esperam do sistema no incio do
cenrio
2. Uma descrio do fluxo normal de eventos no cenrio
3. Uma descrio do que pode dar errado e como isso tratado
4. Informaes sobre
simultaneamente
outras
atividades
que
podem
ocorrer
13
PROCESSOS DE
5. Uma descrio do estado de sistema no fim do cenrio
A elicitao baseada em cenrios pode ser realizada informalmente os
engenheiros de requisitos trabalham com os stakeholders para identificar cenrios e captar os
detalhes desses cenrios. Os cenrios podem ser escritos na forma de textos,
complementados por diagramas, imagens de computador etc. Como alternativa, pode ser
adotada uma abordagem mais estruturada, como cenrios de eventos ou casos de uso.
Como exemplo de um cenrio simples em texto, considere como um usurio
do sistema LIBSYS de biblioteca pode usar o sistema. O cenrio mostrado no Quadro 3.1. O
usurio deseja imprimir uma cpia para uso pessoal de um artigo de uma revista mdica. Essa
revista permite cpias gratuitas de artigos disponveis para assinantes, mas os no-assinantes
devem pagar uma taxa por artigo. O usurio conhece o artigo, seu ttulo e a data da publicao.
Quadro 3.1 Cenrio para download de artigo no LIBSYS
Hiptese inicial: O usurio se conectou ao sistema LlBSYS e localizou a revista que contm a cpia do
artigo.
Normal: O usurio seleciona o artigo a ser copiado. O sistema solicita que o usurio fornea as
informaes de assinante da revista ou indique uma forma de pagamento pelo artigo. O pagamento pode
ser feito por meio de carto de crdito ou com a informao de um nmero de conta da organizao.
solicitado, depois, que o usurio preencha um formulrio de direitos autorais com os detalhes da
transao e o envie ao sistema LlBSYS.
O formulrio de direitos autorais verificado e, caso aprovado, a verso do artigo em PDF baixada na
rea de trabalho do LlBSYS no computador do usurio e este avisado de que o artigo est disponvel.
solicitado que o usurio selecione uma impressora e uma cpia do artigo impressa. Se o artigo
estiver marcado como 'apenas para impresso', este ser apagado automaticamente do sistema do
usurio aps o trmino da impresso.
O que pode dar errado: O usurio pode no preencher o formulrio de direitos autorais corretamente.
Nesse caso, o formulrio dever ser reapresentado ao usurio para correo.
Se o formulrio reapresentado ainda estiver incorreto, a solicitao do usurio para o artigo ser
rejeitada.
O pagamento pode ser rejeitado pelo sistema; nesse caso, a solicitao do usurio para o artigo ser
rejeitada.
O download do artigo pode falhar, o que faz com que o sistema tente novamente at que a operao
seja bem-sucedida ou que o usurio termine a sesso.
Pode no ser possvel imprimir o artigo. Se o artigo no estiver marcado como 'apenas para impresso',
ele ser mantido na rea de trabalho do LlBSYS. Caso contrrio, o artigo ser apagado automaticamente
e o custo do artigo ser debitado na conta do usurio.
Outras atividades: Downloads simultneos de outros artigos.
Estado de sistema aps o trmino: O usurio estar conectado. O artigo baixado teria sido apagado
da rea de trabalho do LlBSYS caso estivesse marcado como 'apenas para impresso' .
14
PROCESSOS DE
Casos de uso
Os casos de uso constituem uma tcnica baseada em cenrios para elicitao
de requisitos e se tornaram uma caracterstica fundamental da notao UML para descrio de
modelos de sistema orientado a objetos. Em sua forma mais simples, um caso de uso identifica
o tipo da interao e os agentes envolvidos. Por exemplo, a figura 3.3 mostra o caso de uso de
alto nvel do recurso de impresso de artigos no LIBSYS, descrito no Quadro 3.1.
Impresso
de artigos
Usurio da
biblioteca
Figura 3.3 Caso de uso simples para impresso de artigos
A figura 3.3 mostra os elementos essenciais da notao de caso de uso. Os

agentes no processo so representados como bonecos e cada classe de interao
representada como uma elipse identificada. O conjunto de casos de uso representa todas as
possveis interaes a serem representadas nos requisitos de sistema. A figura 3.4 desenvolve
o exemplo do LIBSYS e mostra outros casos de uso nesse ambiente.
Busca de
artigos
Impresso
de artigos
Usurio da
biblioteca
Administrao
de usurios
Servios de
catlogo
Pessoal da
biblioteca
Fornecedor
Figura 3.4 Casos de uso para o sistema de biblioteca
15
PROCESSOS DE
Algumas vezes, existe confuso sobre se um caso de uso um cenrio em si
ou se um caso de uso engloba um conjunto de cenrios, sendo cada cenrio um
encadeamento isolado ao longo do caso de uso. Se um cenrio incluir vrios encadeamentos,
existir um cenrio para interao normal e mais cenrios para cada possvel exceo.
Os casos de uso identificam as interaes individuais com o sistema. Eles
podem ser documentados por meio de texto ou de links com os modelos UML que
desenvolvem o cenrio mais detalhadamente. Os diagramas de sequncia so frequentemente
usados para adicionar informaes ao caso de uso. Os diagramas de sequncia mostram os
agentes envolvidos na interao, os objetos com os quais interagem e as operaes
associadas a esses objetos.
Como ilustrao disto, a figura 3.5 mostra as interaes envolvidas no uso do
LIBSYS para baixar e imprimir um artigo na forma de diagrama de sequncia. Na figura 3.5,
existem quatro objetos de classes Artigo, Formulrio, rea de Trabalho e Impressora
envolvidos na interao. A sequncia de aes ocorre de cima para baixo e os rtulos sobre as
setas entre os agentes e os objetos indicam os nomes das operaes. Essencialmente, a
solicitao de um artigo pelo usurio dispara uma requisio para um formulrio de direitos
autorais. Quando o usurio concluir o preenchimento do formulrio, o artigo ser baixado e
enviado para a impressora. Quando a impresso terminar, o artigo ser apagado da rea de
trabalho do LIBSYS.
Item: Artigo
Usurio da
biblioteca
solicitar
copyrightForm:
Formulrio
myWorkspace:
rea de trabalho
myPrinter:
Impressora
solicitar
completar
retornar
direitos autorais ok
liberar
artigo ok
imprimir
enviar
confirmar
informar
apagar
Figura 3.5 Diagrama de sequncia das interaes do sistema para impresso de artigos
16
PROCESSOS DE
A UML um padro real para a modelagem orientada a objetos e, portanto, os
casos de uso e a elicitao baseada em casos de uso tm sido cada vez mais usados para
elicitao de requisitos.
Cenrios e casos de uso so tcnicas eficazes para elicitao de requisitos
segundo pontos de vista de interao, em que cada tipo de interao pode ser representado
como um caso de uso. Eles tambm podem ser usados em conjunto com alguns pontos de
vista indiretos, sendo que esses pontos de vista recebem alguns resultados (como um relatrio
gerencial) do sistema. Contudo, como eles enfocam as interaes, no so eficazes para
elicitar restries ou requisitos de negcios e no funcionais de alto nvel com base nos pontos
de vista indiretos ou para obter requisitos de domnio.
Etnografia
Os sistemas de software no existem isoladamente eles so usados em um
contexto social e organizacional e os requisitos do sistema de software podem ser derivados ou
restringidos
por
esse
contexto.
Geralmente,
satisfazer
esses
requisitos
sociais
organizacionais importante para o sucesso do sistema. Uma razo pela qual vrios sistemas
de software so entregues, mas nunca usados, que eles no do a importncia devida a
esses requisitos.
Etnografia uma tcnica de observao que pode ser usada para
compreender os requisitos sociais e organizacionais. Um analista se insere no ambiente de
trabalho onde o sistema ser usado. Ele observa o trabalho do dia a dia e anota as tarefas
reais nas quais os participantes esto envolvidos. O valor da etnografia est na ajuda que
presta aos analistas para descobrir os requisitos implcitos de sistema que refletem os
processos reais, e no os formais, com os quais as pessoas esto envolvidas.
As pessoas frequentemente consideram muito difcil articular detalhes de seu
trabalho, pois isso secundrio para elas. Elas compreendem seu prprio trabalho, mas
podem no compreender seu relacionamento com o trabalho de outros na organizao. Os
fatores sociais e organizacionais, que afetam o trabalho, mas que no so bvios para as
pessoas, podem somente se tornar claros quando examinados por um observador imparcial.
Pesquisadores usaram a etnografia para estudar o trabalho em escritrio e
concluram que as prticas reais de trabalho eram mais ricas, mais complexas e mais
dinmicas do que os simples modelos considerados pelos sistemas e automao de escritrio.
A diferena entre o trabalho suposto e o real a razo mais importante pela qual os sistemas
de escritrio no tiveram efeito significativo na produtividade. Outros estudos de etnografia
para a compreenso dos requisitos de sistema incluram estudos sobre controle de trfego
areo, salas de controle do metr, sistemas financeiros e vrias atividades de projeto.
17
PROCESSOS DE
Outras pesquisas investigaram mtodos de integrao de etnografia no
processo de engenharia de software, ligando-o aos mtodos de engenharia de requisitos e pela
documentao de padres de interao em sistemas cooperativos.
A etnografia particularmente eficaz para descobrir dois tipos de requisitos:
1. Requisitos derivados da maneira como as pessoas realmente
trabalham em vez da maneira pela qual as definies de processo
dizem que elas deveriam trabalhar. Por exemplo, os controladores de
trfego areo podem desligar um sistema de alerta de coliso de
aeronaves que detecta rotas de voo em coliso, embora os
procedimentos normais de controle especifiquem que ele deve ser
usado. Sua estratgia de controle projetada para assegurar que
essas aeronaves sejam afastadas antes que ocorram problemas e os
controladores consideram que o alarme de alerta os distrai de seu
trabalho.
2. Requisitos derivados da cooperao e do conhecimento das
atividades de outras pessoas. Por exemplo, os controladores de
trfego areo podem usar o conhecimento que tm do trabalho de
outros controladores para prever o nmero de aeronaves que entraro
em seu setor de controle. Depois eles modificam suas estratgias de
controle, dependendo da sobrecarga prevista. Portanto, um sistema
automatizado de controle de trfego areo deve permitir que os
controladores em um setor tenham alguma visibilidade do trabalho em
setores adjacentes.
A etnografia pode ser combinada com a prototipao (figura 3.6). A etnografia
informa o desenvolvimento do prottipo de tal modo que poucos ciclos de refinamento de
prottipo sejam necessrios. Alm disso, a prototipao enfoca a etnografia, identificando os
problemas e as questes que podem, assim, ser discutidos com o etngrafo. O etngrafo deve,
ento, procurar as respostas a estas questes durante a prxima fase do estudo de sistema.
Os estudos de etnografia podem revelar detalhes importantes do processo
frequentemente ignorados por outras tcnicas de elicitao de requisitos. No entanto, devido a
seu foco no usurio final, essa abordagem no apropriada para obter os requisitos
organizacionais ou de domnio. Os estudos etnogrficos nem sempre podem identificar novas
caractersticas a serem acrescentadas a um sistema. A etnografia no , portanto, uma
abordagem completa para elicitao e deve ser usada para complementar outras abordagens,
como a anlise de casos de uso.
18
PROCESSOS DE
Reunies
de prestao
de contas
Anlise
etnogrfica
Etnografia
focalizada
Avaliao de
prottipo
Desenvolvimento
de sistema
genrico
Prototipao
de sistema
Figura 3.6 Etnografia e prototipao para anlise de requisitos
4. VALIDAO DE REQUISITOS
A validao de requisitos dedica-se a mostrar que os requisitos realmente
definem o sistema que o usurio deseja/necessita. A validao de requisitos se sobrepe
anlise; est relacionada descoberta de problemas com os requisitos. A validao de
requisitos importante porque os erros em um documento de requisitos podem levar a custos
excessivos de retrabalho quando so descobertos durante o desenvolvimento ou depois que o
sistema est em operao. O custo de correo de um problema de requisitos, fazendo uma
mudana de sistema, muito maior do que a correo de erros de projeto e de codificao. A
razo disso que uma mudana de requisitos significa geralmente que o projeto e a
implementao do sistema devem tambm ser mudados e o sistema deve ser novamente
testado.
Durante o processo de validao de requisitos, devem ser realizadas
verificaes nos requisitos do documento de requisitos. Essas verificaes incluem:
1. Verificaes de validade: um usurio pode pensar que um sistema
necessrio para desempenhar determinadas funes. Contudo, mais
estudos e anlises podem identificar que funes adicionais e
diferentes so necessrias. Os sistemas tm diversos stakeholders
com necessidades diferentes e qualquer conjunto de requisitos ,
inevitavelmente, um compromisso da comunidade de stakeholders.
2. Verificaes de consistncia: os requisitos em um documento no
devem ser conflitantes. Isso significa que no devem existir restries
ou descries contraditrias para a mesma funo do sistema.
19
PROCESSOS DE
3. Verificaes de completeza: o documento de requisitos deve incluir
requisitos que definam todas as funes e as restries desejadas
pelo usurio do sistema.
4. Verificaes de realismo: usando o conhecimento da tecnologia
existente, os requisitos devem ser verificados quanto a se realmente
podem ser implementados. Essas verificaes tambm devem levar
em considerao o oramento e o prazo para o desenvolvimento do
sistema.
5. Facilidade de verificao: para reduzir o potencial de divergncias
entre cliente e fornecedor, os requisitos do sistema devem sempre
ser escritos de modo que sejam verificveis. Isso significa que devese ser capaz de escrever um conjunto de testes que possa
demonstrar que o sistema entregue atende a cada requisito
especificado.
Uma srie de tcnicas de validao de requisitos pode ser usada em conjunto
ou individualmente:
1. Revises
de
requisitos:
os
requisitos
so
analisados
sistematicamente por uma equipe de revisores.

2. Prototipao: nesta abordagem de validao, um modelo executvel
do sistema apresentado para usurios finais e clientes. Eles podem
experimentar o modelo para verificar se atende s suas necessidades
reais.
3. Gerao de casos de teste: os requisitos devem ser testveis. Se os
testes dos requisitos forem criados como parte do processo de
validao, eles frequentemente revelaro problemas de requisitos. Se
um teste for difcil ou impossvel de ser projetado, isso significa
geralmente que os requisitos sero difceis de ser implementados e
devem ser reconsiderados. O desenvolvimento de testes a partir de
requisitos de usurio, antes de o cdigo estar escrito, uma parte
integrante da extreme programming.
No se deve subestimar os problemas de validao de requisitos. difcil
demonstrar que um conjunto de requisitos atende s necessidades do usurio. Os usurios
devem imaginar o sistema em operao e avaliar sua adequao ao trabalho. difcil para
profissionais de informtica habilidosos realizar esse tipo de anlise abstrata e ainda mais
difcil para os usurios do sistema. Como resultado, raramente se encontra todos os problemas
20
PROCESSOS DE
de requisitos durante o processo de validao. inevitvel que haja mudanas de requisitos
posteriores para corrigir omisses e mal-entendidos depois da aprovao do documento de
requisitos.
4.1. Revises de requisitos

A reviso de requisitos um processo manual que envolve pessoas de ambas
as organizaes, do cliente e do fornecedor. Eles verificam o documento de requisitos em
busca de anomalias e omisses. O processo de reviso pode ser gerenciado da mesma
maneira que as inspees de programa auditoria de sistemas. Como alternativa, ele pode ser
organizado como uma atividade mais ampla, sendo que diferentes pessoas verificam diferentes
partes do documento.
As revises de requisitos podem ser informais ou formais. As revises
informais envolvem simplesmente os fornecedores que discutem os requisitos com o maior
nmero possvel de stakeholders. surpreendente a frequncia com que a comunicao entre
os projetistas e os stakeholders termina aps a elicitao e no existe confirmao de se os
requisitos documentados so os que os stakeholders realmente solicitaram. Muitos problemas
podem ser detectados simplesmente conversando sobre o sistema com os stakeholders antes
do comprometimento de uma reviso formal.
Em uma reviso formal de requisitos, a equipe de desenvolvimento deve
'conduzir' o cliente pelos requisitos de sistema, explicando as implicaes de cada requisito. A
equipe de reviso deve verificar cada requisito em termos de consistncia bem como verificar
os requisitos como um todo em termos de completeza. Os revisores podem tambm verificar:
1. Facilidade de verificao: o requisito, conforme estabelecido,
testvel de forma realstica?
2. Facilidade de compreenso: os adquirentes e os usurios finais do
sistema compreendem o requisito de forma apropriada?
3. Rastreabilidade: a origem do requisito est estabelecida claramente?
Talvez seja necessrio retornar fonte do requisito para avaliar o
impacto de uma mudana. A rastreabilidade importante, pois
permite que o impacto de uma mudana seja avaliado em relao ao
restante
do
sistema.
rastreabilidade
explicada
mais
detalhadamente na prxima seo.

4. Adaptabilidade: o requisito adaptvel? Isto , o requisito pode ser
mudado sem efeitos em grande escala sobre os outros requisitos de
sistema?
21
PROCESSOS DE
Conflitos, contradies, erros e omisses nos requisitos devem ser apontados
pelos revisores e registrados formalmente no relatrio de reviso. , portanto, de
responsabilidade dos usurios, do adquirente de sistema e do desenvolvedor de sistema
negociar uma soluo para esses problemas identificados.
5. GERENCIAMENTO DE REQUISITOS
Os requisitos de sistemas de software de grande porte esto sempre mudando.
Um motivo para isso que esses sistemas so geralmente desenvolvidos para lidar com
problemas 'perversos'. Como o problema no pode ser totalmente definido, os requisitos de
software tendem a ser incompletos. Durante o processo de software, o entendimento dos
stakeholders sobre o problema muda constantemente. Esses requisitos devem ento evoluir
para refletir essas novas vises do problema.
Alm disso, depois que o sistema estiver instalado, inevitavelmente surgiro
novos requisitos. difcil para os usurios e os clientes do sistema anteciparem quais efeitos o
novo sistema causar na organizao. Quando os usurios adquirirem experincia com o
sistema, eles descobriro novas necessidades e prioridades:
1. Sistemas de
grande
porte
geralmente
tm
uma
comunidade
diversificada de usurios, sendo que esses usurios tm diferentes

requisitos e prioridades, os quais podem ser conflitantes ou
contraditrios.
Os
requisitos
finais
do
sistema
constituem
inevitavelmente um compromisso entre eles e, com a experincia,

descobre-se frequentemente que o equilbrio de apoio dado aos
diferentes usurios tem de ser mudado.
2. As pessoas que pagam por um sistema e os usurios de um sistema
raramente so as mesmas pessoas. Os clientes do sistema impem
requisitos devido a restries organizacionais e de oramento. Essas
restries podem ser conflitantes com os requisitos dos usurios finais
e, aps a entrega, novas caractersticas podem ser includas para
apoio do usurio, fazendo com que o sistema alcance as suas metas.
3. Os ambientes de negcios e tcnico do sistema mudam aps a
instalao e essas mudanas devem se refletir no sistema.
4. Um novo hardware pode ser introduzido, pode ser necessria uma
interface com outros sistemas, as prioridades de negcios podem
mudar trazendo consequentes mudanas no apoio ao sistema e uma
22
PROCESSOS DE
nova legislao e regulamentos em ser introduzidos devendo ser
implementados no sistema.
O gerenciamento de requisitos um processo para compreender e controlar as
mudanas dos requisitos de sistema. necessrio manter o acompanhamento dos requisitos
individuais e manter as ligaes entre os requisitos dependentes, de modo que seja possvel
avaliar o impacto das mudanas de requisitos. necessrio estabelecer um processo formal
para fazer propostas de mudana e lig-las aos requisitos de sistema. O processo de
gerenciamento de requisitos deve se iniciar assim que uma verso inicial do documento de
requisitos esteja disponvel, mas deve-se iniciar o planejamento das mudanas de requisitos
durante o processo de elicitao de requisitos.
5.1. Requisitos permanentes e volteis
A evoluo de requisitos, durante o processo de engenharia de requisitos e
aps a entrada de um sistema em operao, inevitvel. O desenvolvimento de requisitos de
software enfoca as capacidades de software, objetivos da empresa e outros sistemas da
empresa. medida que a definio dos requisitos se desenvolve, uma compreenso maior das
necessidades dos usurios obtida. Isso realimenta as informaes do usurio que pode,
ento, propor uma mudana nos requisitos (figura 5.1). Alm disso, pode levar muitos anos
para especificar um sistema de grande porte. Ao longo desse tempo, o ambiente do sistema e
os objetivos da empresa mudam e os requisitos evoluem para refletir essas mudanas.
Compreenso
inicial
do problema
Compreenso
modificada
do problema
Requisitos
iniciais
Requisitos
modificados
tempo
Figura 5.1 Evoluo de requisitos
Do ponto de vista da evoluo, os requisitos dividem-se em duas classes:

1.
Requisitos permanentes: so requisitos relativamente estveis

derivados da atividade central da organizao e que se relacionam
diretamente ao domnio do sistema. Por exemplo, em um hospital,
sempre existiro requisitos relacionados a pacientes, mdicos,
23
PROCESSOS DE
enfermeiros e tratamentos. Esses requisitos podem ser derivados
de modelos de domnio que mostram as entidades e as relaes
que caracterizam um domnio de aplicao.
2.
Requisitos volteis: so requisitos que provavelmente iro mudar

durante o processo de desenvolvimento do sistema ou depois que o
sistema estiver em operao. Um exemplo seria os requisitos que
resultam de polticas de sade do governo.
Sugere-se que os requisitos volteis sejam divididos em cinco classes,

conforme demonstrado na tabela 5.1.
Tabela 5.1 Classificao de requisitos volteis
Tipo de requisito
Descrio
Requisitos
mutveis
Requisitos que mudam devido a mudanas no ambiente no qual a

organizao est operando. Por exemplo, em sistemas hospitalares, o
financiamento do tratamento de pacientes pode mudar e, assim, exigir
que informaes de diferentes tratamentos sejam coletadas.
Requisitos
emergentes
Requisitos que surgem medida que a compreenso do sistema pelo

cliente progride durante o desenvolvimento do sistema. O processo de
projeto pode revelar novos requisitos emergentes.
Requisitos
consequentes
Requisitos que resultam da introduo do sistema de computador. A

introduo do sistema de computador pode mudar os processos da
organizao e criar novas formas de trabalho que geram novos
requisitos de sistema.
Requisitos de
compatibilidade
Requisitos que dependem de sistemas ou processos de negcios

especficos dentro de uma organizao. medida que eles mudam, os
requisitos de compatibilidade do sistema encomendado ou entregue
podem tambm evoluir.
5.2. Planejamento de gerenciamento de requisitos

O planejamento o primeiro estgio essencial no processo de gerenciamento
de requisitos. O gerenciamento de requisitos muito dispendioso. Para cada projeto, o estgio
de planejamento estabelece o nvel de detalhamento necessrio para o gerenciamento de
requisitos. Durante o estgio de gerenciamento de requisitos, deve-se decidir sobre:
1. Identificao de requisitos: cada requisito deve ser identificado
unicamente de modo que possa ser feita a referncia cruzada entre
este e outros requisitos para que ele possa ser usado nas
avaliaes de rastreabilidade.
24
PROCESSOS DE
2. Processo de gerenciamento de mudanas: o conjunto de
atividades que avaliam o impacto e custo das mudanas.
3. Polticas
de
rastreabilidade:
essas
polticas
definem
os
relacionamentos entre os requisitos e entre os requisitos e o projeto

do sistema, que devem ser registrados e como esses registros
devem ser mantidos.
4. Apoio de ferramentas CASE: o gerenciamento de requisitos
envolve o processamento de grandes quantidades de informaes
sobre os requisitos. As ferramentas que podem ser usadas variam
desde sistemas especializados de gerenciamento de requisitos a
planilhas e sistemas simples de banco de dados.
Existem vrios relacionamentos entre os requisitos e entre os requisitos e o
projeto do sistema. Existem tambm ligaes entre requisitos e os motivos bsicos de por que
esses requisitos foram propostos. Quando as mudanas so propostas, deve-se rastrear o seu
impacto em outros requisitos e no projeto do sistema. A rastreabilidade a propriedade de uma
especificao de requisitos que reflete a facilidade de encontrar os requisitos relacionados.
Existem trs tipos de informaes de rastreabilidade que podem ser mantidos:
1. Informaes de rastreabilidade da origem ligam os requisitos aos
stakeholders que propuseram os requisitos e aos motivos desses
requisitos. Quando uma mudana proposta, essas informaes so
usadas para encontrar e consultar os stakeholders sobre a mudana.
2. Informaes de rastreabilidade de requisitos ligam os requisitos
dependentes dentro do documento de requisitos. Essas informaes
so usadas para avaliar quantos requisitos provavelmente sero
afetados pela mudana proposta e a extenso das mudanas de
requisitos consequentes que podem ser necessrios.
3. Informaes de rastreabilidade de projeto ligam os requisitos aos
mdulos de projeto, nos quais esses requisitos so implementados.
Essas informaes so usadas para avaliar o impacto das mudanas
de requisitos propostas no projeto e na implementao do sistema.
As informaes de rastreabilidade so frequentemente representadas por meio
de matrizes de rastreabilidade que relacionam os requisitos aos stakeholders, aos outros
requisitos ou aos mdulos de projeto. Em uma matriz de rastreabilidade de requisitos, cada
25
PROCESSOS DE
requisito introduzido em uma linha e uma coluna da matriz. As dependncias entre diferentes
requisitos so registradas na clula correspondente interseco de linha/coluna.
A tabela 5.2 mostra uma matriz simples de rastreabilidade que registra as
dependncias entre requisitos. A letra 'D' na interseco linha/coluna ilustra que o requisito da
linha depende do requisito identificado na coluna; a letra 'R' significa que existe algum outro
relacionamento mais fraco entre os requisitos. Por exemplo, ambos podem definir os requisitos
para partes do mesmo subsistema.
Tabela 5.2 Matriz de rastreabilidade
ID de
requisito
1.1
1.1
1.2
1.3
1.2
1.3
2.1
2.2
D
R
2.3
3.1
2.1
2.2
2.3
3.2
D
R
3.1
3.2
As matrizes de rastreabilidade podem ser usadas quando um pequeno nmero

de requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos requisitos,
tornam-se muito difceis de serem gerenciadas e sua manuteno dispendiosa, Para esses
sistemas, deve-se captar as informaes de rastreabilidade em um banco de dados de
requisitos, no qual cada requisito explicitamente ligado a requisitos relacionados. Pode-se,
ento, avaliar o impacto das mudanas usando os recursos de acesso ao banco de dados. As
matrizes de rastreabilidade podem ser geradas automaticamente baseadas no banco de dados.
O gerenciamento de requisitos precisa de apoio automatizado; as ferramentas
CASE para essa finalidade devem ser selecionadas durante a fase de planejamento. O apoio
de ferramentas necessrio para:
1. Armazenamento de requisitos: os requisitos devem ser mantidos em
um repositrio de dados seguro e gerenciado, acessvel a todos os
envolvidos no processo de engenharia de requisitos.
26
PROCESSOS DE
2. Gerenciamento de mudanas: o processo de gerenciamento de
mudanas (figura 5.2) simplificado se um apoio ativo de ferramentas
estiver disponvel.
3. Gerenciamento de rastreabilidade: conforme explicado anteriormente,
o apoio de ferramentas para rastreabilidade permite que requisitos
relacionados sejam obtidos. Algumas ferramentas usam tcnicas de
processamento de linguagem natural para auxiliar na descoberta de
possveis relacionamentos entre os requisitos.
Para sistemas de pequeno porte, o uso de ferramentas especializadas de
gerenciamento de requisitos pode no ser necessrio. O processo de gerenciamento de
requisitos pode ter o apoio de recursos disponveis em processadores de texto, planilhas e
bancos de dados. Contudo, para sistemas de grande porte, necessria uma ferramenta de
apoio mais especializada.
5.3. Gerenciamento de mudanas de requisitos
O gerenciamento de mudanas de requisitos (figura 5.2) deve ser aplicado a
todas as mudanas propostas aos requisitos. A vantagem de usar um processo formal para
gerenciamento de mudanas que todas as propostas de mudana so tratadas
consistentemente e as mudanas no documento de requisitos so feitas de maneira controlada.
Existem trs principais estgios para um processo de gerenciamento de mudanas:
1. Anlise do problema e especificao da mudana: o processo se
inicia com um problema de requisitos identificado ou, s vezes, com
uma proposta de mudana especfica. Durante esse estgio, o
problema ou a proposta de mudana analisada para verificar se
vlida. Os resultados da anlise so realimentados para o solicitante
da mudana e, algumas vezes, feita uma proposta de mudana de
requisitos mais especfica.
2. Anlise da mudana e estimativa de custo: o efeito da mudana
proposta avaliado usando as informaes de rastreabilidade e o
conhecimento geral sobre os requisitos do sistema. O custo de
realizar a mudana estimado em termos de modificaes no
documento de requisitos e, se adequado, do projeto e da
implementao do sistema. Uma vez completada esta anlise,
tomada uma deciso sobre prosseguir ou no com a mudana de
requisitos.
27
PROCESSOS DE
3. Implementao da mudana: o documento de requisitos e, quando
necessrio, o projeto e a implementao de sistema so modificados.
Deve-se organizar o documento de requisitos de modo que possa
realizar as mudanas sem reescrita ou reorganizao extensivas. Da
mesma maneira que na programao, a facilidade de mudanas no
documento obtida por meio da minimizao das referncias
externas e tornando as sees do documento o mais modulares
possvel. Assim, as sees individuais podem ser mudadas e
substitudas sem afetar outras partes do documento.
Problem a
identificado
Anlise do
problema e
especificao
de mudanas
Anlise de
mudanas e
estimativa
de custo
Implementao
das mudanas
Requisitos
revisados
Figura 5.2 Gerenciamento de mudanas de requisitos
Se uma mudana de requisitos do sistema solicitada com urgncia, existe

sempre uma propenso a realizar a mudana no sistema e, depois, retrospectivamente,
modificar o documento de requisitos. Isso leva quase inevitavelmente defasagem entre o
documento de requisitos e a implementao do sistema. Uma vez feitas as mudanas no
sistema, as mudanas no documento de requisitos podem ser esquecidas ou realizadas de
maneira no consistente com as mudanas no sistema.
Os processos iterativos de desenvolvimento, como extreme programming,
foram definidos para lidar com requisitos que mudam durante o processo de desenvolvimento.
Nesses processos, quando um usurio prope mudana de requisito, essa mudana no
realizada por meio de um processo de gerenciamento de mudanas formal. Em vez disso, o
usurio precisa priorizar essa mudana e, se a prioridade for alta, decidir quais caractersticas
do sistema planejadas para a prxima iterao devem ser abandonadas.
28
PROCESSOS DE
Empresrio
Consultor de Empresas
Professor Universitrio
Mestre em Informtica
Gesto de Sistemas de Informao
Especialista em Sistemas de Informatizao

Empresarial
Bacharel em Administrao
Tecnlogo em Processamento de Dados
marcelo.moreira2@fatec.sp.gov.br
29

Engenharia de Requisitos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

.

Figura 1.1 Processo de engenharia de requisitos

Figura 1.2 Modelo em espiral dos processos de engenharia de requisitos

Algumas pessoas consideram a engenharia de requisitos como se fosse o

3. ELICITAO E ANLISE DE REQUISITOS

relacionados e os organiza em conjuntos coerentes.

3. Priorizao e negociao de requisitos: inevitavelmente, quando

vises diferentes sobre a

Figura 3.1 Processo de elicitao e anlise de requisitos

3.1. Obteno de requisitos

os pontos de vista de interao fornecem requisitos de sistema

os pontos de vista indiretos so os que mais provavelmente

os pontos de vista de domnio fornecem normalmente as restries

Todos os pontos de vista

Figura 3.2 Pontos de vista no LIBSYS

resultado. A maioria das pessoas considera mais fcil falar em um

Figura 3.3 Caso de uso simples para impresso de artigos

A figura 3.3 mostra os elementos essenciais da notao de caso de uso. Os

Figura 3.4 Casos de uso para o sistema de biblioteca

Figura 3.6 Etnografia e prototipao para anlise de requisitos

sistematicamente por uma equipe de revisores.

4.1. Revises de requisitos

detalhadamente na prxima seo.

diversificada de usurios, sendo que esses usurios tm diferentes

inevitavelmente um compromisso entre eles e, com a experincia,

Figura 5.1 Evoluo de requisitos

Do ponto de vista da evoluo, os requisitos dividem-se em duas classes:

Requisitos permanentes: so requisitos relativamente estveis

Requisitos volteis: so requisitos que provavelmente iro mudar

Sugere-se que os requisitos volteis sejam divididos em cinco classes,

Requisitos que mudam devido a mudanas no ambiente no qual a

Requisitos que surgem medida que a compreenso do sistema pelo

Requisitos que resultam da introduo do sistema de computador. A

Requisitos que dependem de sistemas ou processos de negcios

5.2. Planejamento de gerenciamento de requisitos

relacionamentos entre os requisitos e entre os requisitos e o projeto

As matrizes de rastreabilidade podem ser usadas quando um pequeno nmero

Figura 5.2 Gerenciamento de mudanas de requisitos

Se uma mudana de requisitos do sistema solicitada com urgncia, existe

Prof. Me. Marcelo dos Santos Moreira

Gesto de Sistemas de Informao

Especialista em Sistemas de Informatizao

Tecnlogo em Processamento de Dados

Você também pode gostar