Engenharia de software i 3 - processos de engenharia de requisitos

PROCESSOS DE
ENGENHARIA DE REQUISITOS
Engenharia de Software 1
Prof. Me. Marcelo dos Santos Moreira
1. INTRODUÇÃO
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 nível
de engenharia de requisitos. Eles estão relacionados à:
 estudo de viabilidade: avaliação se o sistema é útil para a empresa
 elicitação e análise: obtenção de requisitos
 especificação: conversão desses requisitos em alguma forma padrão
 validação: verificação se os requisitos realmente definem o sistema
que o cliente deseja
A Figura 1.1 ilustra o relacionamento entre essas atividades. Ela mostra
também os documentos produzidos em cada estágio do processo de engenharia de requisitos.
A especificação e a documentação 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 estão relacionadas à obtenção,
documentação e verificação de requisitos. Na prática, no entanto, todos os requisitos de
sistema mudam. As pessoas envolvidas desenvolvem uma compreensão maior do que
desejam que o software faça, a organização que está comprando o sistema muda, são feitas
modificações no hardware, no software e no ambiente organizacional do sistema. O processo
de gerenciamento dessas mudanças de requisitos é denominado gerenciamento de requisitos
e é abordado na seção final desta apostila.
Figura 1.1 – Processo de engenharia de requisitos
Estudo de
viabilidade
Elicitação e
análise de
requisitos
Especificação
de requisitos
Validação de
requisitos
Documento
de requisitos
Requisitos de
usuário e de
sistema
Modelos de
sistemas
Relatório de
viabilidade

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 três estágios,
no qual as atividades estão organizadas como um processo iterativo em espiral. A quantidade
de tempo e esforço dispensado para cada atividade na iteração depende do estágio do
processo geral e do tipo de sistema que está sendo desenvolvido. No início do processo, a
maior parte do esforço será empregada na compreensão dos requisitos de alto nível de
negócios, requisitos não funcionais e requisitos de usuário. Próximo ao fim do processo, nas
partes mais externas da espiral, um esforço maior será dedicado à engenharia de requisitos e à
modelagem de sistema.
O modelo em espiral acomoda abordagens de desenvolvimento em que os
requisitos são desenvolvidos para diferentes níveis de detalhes. O número de iterações na
espiral pode variar, de modo que se pode sair da espiral depois que alguns ou todos os
requisitos de usuário tiverem sido elicitados. Se a atividade de prototipação apresentada sob a
validação de requisitos for ampliada para incluir o desenvolvimento iterativo, este modelo
permitirá que os requisitos e a implementação de sistema sejam desenvolvidos em conjunto.
Algumas pessoas consideram a engenharia de requisitos como se fosse o
processo de aplicação de um método estruturado de análise como, por exemplo, a análise
orientada a objetos. Isso consiste na análise do sistema e no desenvolvimento de um conjunto
de modelos gráficos de sistemas, como modelos de casos de uso, que servem como uma
especificação de sistema. O conjunto de modelos descreve o comportamento do sistema e
Figura 1.2 – Modelo em espiral dos processos de engenharia de requisitos
Elicitação de
requisitos
Validação de
requisitos
Especificação
de requisitos
Especificação de
requisitos de sistema
e modelagem
Especificação de
requisitos de usuário
Especificação de
requisitos de negócios
Estudo de
viabilidade
Prototipação
Revisões
Elicitação de
requisitos
de usuário
Elicitação de
requisitos
de sistema
Documento de requisitos
de sistema

PROCESSOS DE
inclui anotações com descrições adicionais de informações como, por exemplo, o desempenho
ou a confiabilidade necessária.
Embora os métodos estruturados possuam um papel a desempenhar no
processo de engenharia de requisitos, existe muito mais sobre engenharia de requisitos do que
é abordado nesses métodos. A elicitação de requisitos, em particular, é uma atividade centrada
em pessoas, e as pessoas não gostam das restrições impostas pelos modelos rígidos de
sistema.
2. ESTUDO DE VIABILIDADE
Em todos os sistemas novos, o processo de engenharia de requisitos deve
começar com um estudo de viabilidade. A entrada para o estudo de viabilidade consiste de um
conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como o
sistema pretende apoiar os processos de negócios. Os resultados do estudo de viabilidade
devem estar em um relatório que recomenda se vale a pena ou não 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 série de questões:
1. O sistema contribui para os objetivos gerais da organização?
2. O sistema pode ser implementado com tecnologia atual e dentro das
restrições definidas de custo e prazo?
3. O sistema pode ser integrado a outros sistemas já implantados?
A questão de se o sistema contribui ou não para os objetivos da empresa é
crítica. Se um sistema não apoia esses objetivos, ele não tem valor real para a empresa.
Apesar de esse fato parecer óbvio, muitas organizações desenvolvem sistemas que não
contribuem para seus objetivos, porque elas não têm um perfil claro desses objetivos, pois
falham em definir os requisitos de negócios para o sistema, ou porque outros fatores políticos
ou organizacionais influenciam na aquisição do sistema.
A realização de um estudo de viabilidade envolve a avaliação de informações,
sua coleta e a elaboração de um relatório.
A avaliação de informações identifica as informações necessárias para
responder às três questões apresentadas anteriormente. Após a identificação das informações,
é necessário falar com as fontes de informações para descobrir as respostas a essas
perguntas. Alguns exemplos de possíveis questões que podem ser levantadas são:

PROCESSOS DE
1. Como a organização se comportaria se esse sistema não fosse
implementado?
2. Quais são os problemas com os processos atuais e como o novo
sistema ajudaria a reduzir esses problemas?
3. Qual será a contribuição direta do sistema para os objetivos e requisitos
da empresa?
4. As informações podem ser transferidas e recebidas de outros sistemas
da organização?
5. O sistema requer tecnologia que ainda não foi usada na organização?
6. O que deve ser apoiado pelo sistema e o que não precisa ser apoiado?
Em um estudo de viabilidade, pode-se consultar fontes de informações 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 usuários finais do
sistema. Normalmente, deve-se tentar concluir um estudo de viabilidade em duas ou três
semanas. Após obter as informações, é elaborado o relatório de estudo de viabilidade. Deve-se
fazer uma recomendação de se o desenvolvimento do sistema deve ou não prosseguir. No
relatório podem ser propostas mudanças de escopo, orçamento e prazo e sugerir requisitos de
alto nível adicionais para o sistema.
3. ELICITAÇÃO E ANÁLISE DE REQUISITOS
O próximo estágio do processo de engenharia de requisitos é a elicitação e
análise de requisitos. Nessa atividade, os engenheiros de software trabalham com os clientes e
os usuários finais do sistema para aprender sobre o domínio da aplicação, quais serviços o
sistema deve fornecer, o desempenho esperado do sistema, restrições de hardware etc.
A elicitação e a análise de requisitos podem envolver várias pessoas de uma
organização. O termo stakeholder é usado para se referir a qualquer pessoa ou grupo afetado
pelo sistema, direta ou indiretamente. Os stakeholders incluem os usuários finais que
interagem com o sistema e todo pessoal na organização que possa ser afetado por sua
instalação. Outros stakeholders no sistema podem ser os engenheiros que estão
desenvolvendo ou mantendo sistemas relacionados, gerentes de negócios, especialistas do
domínio e representantes do sindicato.
A elicitação e a compreensão dos requisitos dos stakeholders são difíceis
devido a várias razões:

PROCESSOS DE
1. Os stakeholders, frequentemente, não sabem o que querem do sistema
de computador a não ser em termos gerais. Eles podem achar difícil
articular o que desejam que o sistema faça ou fazem pedidos não
realistas, pois ignoram o custo de seus requisitos.
2. Os stakeholders expressam os requisitos naturalmente em seus
próprios termos e com o conhecimento implícito de se trabalho. Os
engenheiros de requisitos, sem experiência no domínio 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 políticos podem influenciar os requisitos do sistema. Por
exemplo, os gerentes podem solicitar requisitos específicos do sistema
que aumentarão a sua influência na organização.
5. O ambiente econômico e de negócios sobre o qual a análise é
realizada é dinâmico. Ele muda inevitavelmente durante o processo de
análise. Portanto, a importância de determinado requisito pode mudar.
Novos requisitos podem surgir de novos stakeholders que não haviam
sido consultados anteriormente.
Um modelo de processo bastante genérico de elicitação e análise de requisitos
é apresentado na figura 3.1. Cada organização terá a sua própria versão ou modelo desse
modelo geral, dependendo de fatores locais, como o nível de conhecimento da equipe, o tipo
do sistema que está sendo desenvolvido e os padrões 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 são:
1. Obtenção de requisitos: é o processo de interação com os
stakeholders no sistema para coletar os seus requisitos. Os requisitos
de domínio são também descobertos durante essa atividade,
provenientes dos stakeholders e da documentação.
2. Classificação e organização de requisitos: esta atividade envolve a
coleção de requisitos não estruturados, agrupa os requisitos
relacionados e os organiza em conjuntos coerentes.

PROCESSOS DE
3. Priorização e negociação de requisitos: inevitavelmente, quando
vários stakeholders participam do processo, os requisitos serão
conflitantes. Esta atividade está relacionada à priorização de requisitos,
à procura e à resolução de conflitos de requisitos por meio da
negociação.
4. Documentação de requisitos: os requisitos são documentados e
colocados na próxima volta da espiral. Podem ser produzidos
documentos de requisitos formais ou informais.
A figura 3.1 mostra que a elicitação e a análise de requisitos é um processo
iterativo com realimentação contínua de cada atividade para outras atividades. O ciclo do
processo começa com a obtenção de requisitos e termina com a documentação de requisitos.
O entendimento dos requisitos pelo analista aumenta a cada volta do ciclo.
Aqui é enfocado principalmente a descoberta de requisitos e as diversas
técnicas desenvolvidas para dar apoio a essas atividades. A classificação e a organização de
requisitos estão relacionadas principalmente com a identificação da sobreposição 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 visões diferentes sobre a
importância e a prioridade dos requisitos e, algumas vezes, essas visões entram em conflito.
Durante o processo, deve-se organizar negociações frequentes com os stakeholders, de modo
que os compromissos possam ser atingidos. É impossível satisfazer completamente a todos os
stakeholders, mas, se alguns deles perceberem que suas visões não foram consideradas de
maneira apropriada, eles podem tentar boicotar intencionalmente o processo de engenharia de
requisitos.
No estágio de documentação, os requisitos elicitados são documentados de
modo que possam ser usados para auxiliar as próximas obtenções de requisitos. Nesse
estágio, uma versão inicial dos requisitos do sistema pode ser produzida, mas terá seções
faltantes e requisitos incompletos. Como alternativa, os requisitos podem ser documentados
como tabelas em um documento ou em cartões. Escrever os requisitos em cartões (abordagem
usada na extreme programming) pode ser muito eficiente, pois os stakeholders podem
manusear, alterar e organizar os cartões com facilidade.

PROCESSOS DE
3.1.Obtenção de requisitos
A obtenção de requisitos é o processo que reúne informações sobre o sistema
proposto e os existentes para obter os requisitos de usuário e de sistema com base nessas
informações. As fontes de informações, durante a fase de obtenção de requisitos, incluem
documentação, stakeholders de sistema e especificações de sistemas similares. A interação
com os stakeholders ocorre por meio de entrevistas e observações, podendo ser usados
cenários e protótipos para auxiliar na obtenção dos requisitos. Aqui é apresentada uma
abordagem que ajuda a assegurar uma cobertura ampla de stakeholders durante a obtenção
de requisitos e descritas técnicas que incluem entrevistas, cenários e etnografia. Outras
técnicas de obtenção de requisitos que podem ser usadas incluem métodos estruturados de
análise e prototipação de sistema.
Os stakeholders variam de usuários finais do sistema a gerentes e envolvidos
externos, como regulamentadores que certificam a aceitação do sistema. Por exemplo, os
stakeholders em um sistema de caixa eletrônico bancário incluem:
1. Clientes atuais do banco que recebem serviços do sistema.
2. Representantes de outros bancos que têm acordos recíprocos que
permitem usar os caixas eletrônicos uns dos outros.
Figura 3.1 – Processo de elicitação e análise de requisitos
Classificação e
organização de
requisitos
Priorização e
negociação de
requisitos
Documentação
de requisitos
Obtenção de
requisitos

PROCESSOS DE
3. Gerentes de agências bancárias que obtêm informações de
gerenciamento do sistema.
4. Pessoal de atendimento nas agências bancárias envolvidos na
operação diária do sistema.
5. Administradores de banco de dados responsáveis pela integração do
sistema com o banco de dados dos clientes do banco.
6. Gerentes de proteção bancária que devem assegurar que o sistema
não seja exposto a riscos de proteção.
7. Departamento de marketing do banco provavelmente interessado em
usar o sistema como meio de marketing do banco.
8. Engenheiros de manutenção de hardware e software que são
responsáveis pela manutenção e atualização de hardware e software.
9. Reguladores nacionais de bancos responsáveis por assegurar que o
sistema esteja em conformidade com os regulamentos bancários.
Além dos stakeholders no sistema, vimos anteriormente que os requisitos
podem ser provenientes do domínio de aplicação e de outros sistemas que interagem com o
sistema que está sendo especificado. Tudo isso deve ser considerado durante o processo de
elicitação de requisitos.
Essas fontes de requisitos (stakeholders, domínio, 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 não são completamente independentes – elas geralmente se
sobrepõem de modo que haja requisitos comuns.
Pontos de vista
As abordagens orientadas a pontos de vista para engenharia de requisitos
organizam o processo de elicitação e os próprios requisitos usando pontos de vista. Um ponto
forte da análise orientada a pontos de vista é que ela reconhece várias 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 classificação de
stakeholders e de outras fontes de requisitos. Existem três tipos genéricos de pontos de vista:

PROCESSOS DE
1. Pontos de vista de interação: representam pessoas ou outros
sistemas que interagem diretamente com o sistema. No sistema de
caixa eletrônico bancário, exemplos de pontos de vista de interação
são os clientes do banco e o banco de dados de contas bancárias.
2. Pontos de vista indiretos: representam os stakeholders que não
usam o sistema diretamente, mas que influenciam requisitos de alguma
forma. No sistema de caixa eletrônico bancário, exemplos de pontos de
vista indiretos são a gerência do banco e o pessoal de proteção do
banco.
3. Pontos de vista de domínio: representam características e restrições
de domínio que influenciam os requisitos de sistema. No sistema de
caixa eletrônico bancário, um exemplo de um ponto de vista de domínio
são os padrões desenvolvidos para comunicações entre os bancos.
Tipicamente, esses pontos de vista fornecem diferentes tipos de requisitos:
 os pontos de vista de interação fornecem requisitos de sistema
detalhados que abrangem as características e as interfaces do sistema.
 os pontos de vista indiretos são os que mais provavelmente
fornecem requisitos e restrições organizacionais de alto nível.
 os pontos de vista de domínio fornecem normalmente as restrições
de domínio que se aplicam ao sistema.
A identificação inicial dos pontos de vista relevantes ao sistema pode ser difícil
algumas vezes. Para ajudar nesse processo, deve-se tentar identificar tipos mais específicos
de pontos de vista:
1. Fornecedores e receptores de serviços do sistema.
2. Sistemas que devem interfacear diretamente com o sistema que está
sendo especificado.
3. Regulamentos e padrões que se aplicam ao sistema.
4. Fontes de requisitos de negócios e não 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 características do produto esperadas pelos clientes e
como o sistema deve refletir a imagem externa da organização.
Quase todos os sistemas organizacionais devem interoperar com outros
sistemas na organização. Quando um novo sistema é planejado, as interações com outros
sistemas devem ser planejadas. As interfaces oferecidas por esses outros sistemas já foram
projetadas. Elas podem incluir requisitos e restrições sobre o novo sistema. Além disso, novos
sistemas podem precisar estar em conformidade com regulamentos e padrões preexistentes
que restringem os requisitos do sistema.
Conforme explicado anteriormente, deve-se identificar os requisitos de negócio
e não funcionais de alto nível no início 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 nível gerando requisitos de
sistema mais específicos.
Os pontos de vista de engenharia podem ser importantes por duas razões.
Primeiro, os engenheiros que desenvolvem o sistema podem ter experiência com sistemas
similares e ser capazes de sugerir requisitos levando em conta essa experiência. Segundo, o
pessoal técnico que deve gerenciar e manter o sistema pode ter requisitos que irão ajudar a
simplificar o apoio ao sistema. Os requisitos de gerenciamento de sistema são cada vez mais
importantes, pois os custos de gerenciamento constituem uma porção 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 negócios externos em uma organização.
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 favorável da organização, assim como oferecer funcionalidade ao
usuário. No tocante a produtos de software, o departamento de marketing deve conhecer quais
características tornarão o sistema mais atraente aos potenciais compradores.
Para qualquer sistema não trivial, existe um grande número de possíveis
pontos de vista, e é praticamente impossível 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 compartilharão requisitos comuns.
Como ilustração, 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

PROCESSOS DE
classificação dos pontos de vista de interação, indiretos e de domínio ajuda a identificar fontes
de requisitos independente dos usuários 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 obtenção de
requisitos do sistema.
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 questões para os stakeholders sobre o sistema que eles
usam e o sistema a ser desenvolvido. Os requisitos são derivados das respostas a essas
questões. 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 não existe um roteiro predefinido. A
equipe de engenharia de requisitos explora vários assuntos com os
stakeholders do sistema e, assim, desenvolve uma compreensão maior
de suas necessidades.
Figura 3.2 – Pontos de vista no LIBSYS
Todos os pontos de vista
Indiretos
Gerente da
biblioteca
Finanças
Fornecedores
de artigos
Interação
Usuários
Pessoal da
biblioteca
Domínio
Padrões
de IU
Sistema de
classificação
Estudantes
Externos
Pessoal
Gerente do
sistema
Responsável
pela catalogação

PROCESSOS DE
Na prática, as entrevistas com os stakeholders são, geralmente, uma
combinação desses tipos. As respostas a algumas perguntas podem levar a outros assuntos
discutidos de maneira menos estruturada. As discussões 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 são ú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 não são tão úteis para
compreender os requisitos do domínio da aplicação.
É difícil elicitar o conhecimento de domínio durante as entrevistas por dois
motivos:
1. Todos os especialistas de domínio usam terminologia e jargões
específicos. É impossível para eles explicar os requisitos de domínio
sem usar essa terminologia. Eles em geral usam a terminologia de
maneira precisa e específica, o que facilmente provoca mal-entendidos
por parte dos engenheiros de requisitos.
2. Alguns conhecimentos de domínio são tão familiares aos stakeholders
que são considerados difíceis de explicar ou considerados tão
fundamentais que não vale a pena mencioná-los. Por exemplo, para
uma bibliotecária, não há necessidade de dizer que todas as
aquisições são catalogadas antes de serem colocadas na biblioteca.
Contudo, isso pode não ser óbvio para o entrevistador e, portanto, não
é levado em consideração nos requisitos.
A entrevista não é uma técnica eficiente para elicitação de conhecimentos
sobre os requisitos e as restrições organizacionais, pois existem relacionamentos sutis de
poder e influência entre os stakeholders na organização. As estruturas organizacionais públicas
raramente coincidem com a realidade da tomada de decisões na organização, mas os
entrevistados podem não querer revelar a estrutura real, em lugar da teórica, a um estranho.
Em geral, a maioria das pessoas é relutante em discutir questões políticas e organizacionais
que podem afetar os requisitos.
Os entrevistadores eficientes possuem duas características:
1. Possuem mente aberta, evitam ideias preconcebidas sobre os
requisitos e querem ouvir os stakeholders. Se o stakeholder propuser

PROCESSOS DE
requisitos surpreendentes, os entrevistadores estão dispostos a mudar
de ideia sobre o sistema.
2. Induzem os entrevistados a iniciar as discussões com uma questão,
uma proposta de requisitos ou sugerindo um trabalho conjunto em um
protótipo do sistema. Dizer para as pessoas 'conte-me o que você
necessita/deseja' provavelmente trará informações úteis como
resultado. A maioria das pessoas considera mais fácil falar em um
contexto definido do que em termos gerais.
As informações obtidas das entrevistas complementam outras informações
sobre o sistema obtidas de documentos, observações de usuários etc. Às vezes,
independentemente das informações de documentos, as entrevistas podem ser as únicas
fontes de informações sobre os requisitos do sistema. No entanto, apenas com as entrevistas
pode haver a perda de informações essenciais; assim, essa técnica deve ser usada junto com
outras para a elicitação de requisitos.
Cenários
As pessoas geralmente consideram mais fácil relatar exemplos da vida real do
que abstrair descrições. Elas podem compreender e criticar um cenário de como interagiriam
com um sistema de software. Os engenheiros de requisitos podem usar as informações obtidas
nessa discussão para elaborar os requisitos reais do sistema.
Os cenários podem ser particularmente úteis para adicionar detalhes a um
esboço da descrição de requisitos. Eles são descrições de exemplos das sessões de interação.
Cada cenário abrange uma ou mais interações possíveis. Diversos tipos de cenários foram
desenvolvidos, cada um dos quais fornecendo diferentes tipos de informações sobre o sistema
em diferentes níveis de detalhamento. O uso de cenários para descrever requisitos é parte
integrante dos métodos ágeis, como a extreme programming.
O cenário começa com um esboço da interação e, durante a elicitação, os
detalhes são adicionados para criar uma descrição completa dessa interação. De maneira geral,
um cenário deve incluir:
1. Uma descrição do que os usuários esperam do sistema no início do
cenário
2. Uma descrição do fluxo normal de eventos no cenário
3. Uma descrição do que pode dar errado e como isso é tratado
4. Informações sobre outras atividades que podem ocorrer
simultaneamente

PROCESSOS DE
5. Uma descrição do estado de sistema no fim do cenário
A elicitação baseada em cenários pode ser realizada informalmente – os
engenheiros de requisitos trabalham com os stakeholders para identificar cenários e captar os
detalhes desses cenários. Os cenários podem ser escritos na forma de textos,
complementados por diagramas, imagens de computador etc. Como alternativa, pode ser
adotada uma abordagem mais estruturada, como cenários de eventos ou casos de uso.
Como exemplo de um cenário simples em texto, considere como um usuário
do sistema LIBSYS de biblioteca pode usar o sistema. O cenário é mostrado no Quadro 3.1. O
usuário deseja imprimir uma cópia para uso pessoal de um artigo de uma revista médica. Essa
revista permite cópias gratuitas de artigos disponíveis para assinantes, mas os não-assinantes
devem pagar uma taxa por artigo. O usuário conhece o artigo, seu título e a data da publicação.
Quadro 3.1 – Cenário para download de artigo no LIBSYS
Hipótese inicial: O usuário se conectou ao sistema LlBSYS e localizou a revista que contém a cópia do
artigo.
Normal: O usuário seleciona o artigo a ser copiado. O sistema solicita que o usuário forneça as
informações de assinante da revista ou indique uma forma de pagamento pelo artigo. O pagamento pode
ser feito por meio de cartão de crédito ou com a informação de um número de conta da organização.
É solicitado, depois, que o usuário preencha um formulário de direitos autorais com os detalhes da
transação e o envie ao sistema LlBSYS.
O formulário de direitos autorais é verificado e, caso aprovado, a versão do artigo em PDF é baixada na
área de trabalho do LlBSYS no computador do usuário e este é avisado de que o artigo está disponível.
É solicitado que o usuário selecione uma impressora e uma cópia do artigo é impressa. Se o artigo
estiver marcado como 'apenas para impressão', este será apagado automaticamente do sistema do
usuário após o término da impressão.
O que pode dar errado: O usuário pode não preencher o formulário de direitos autorais corretamente.
Nesse caso, o formulário deverá ser reapresentado ao usuário para correção.
Se o formulário reapresentado ainda estiver incorreto, a solicitação do usuário para o artigo será
rejeitada.
O pagamento pode ser rejeitado pelo sistema; nesse caso, a solicitação do usuário para o artigo será
rejeitada.
O download do artigo pode falhar, o que faz com que o sistema tente novamente até que a operação
seja bem-sucedida ou que o usuário termine a sessão.
Pode não ser possível imprimir o artigo. Se o artigo não estiver marcado como 'apenas para impressão',
ele será mantido na área de trabalho do LlBSYS. Caso contrário, o artigo será apagado automaticamente
e o custo do artigo será debitado na conta do usuário.
Outras atividades: Downloads simultâneos de outros artigos.
Estado de sistema após o término: O usuário estará conectado. O artigo baixado teria sido apagado
da área de trabalho do LlBSYS caso estivesse marcado como 'apenas para impressão' .

PROCESSOS DE
Casos de uso
Os casos de uso constituem uma técnica baseada em cenários para elicitação
de requisitos e se tornaram uma característica fundamental da notação UML para descrição de
modelos de sistema orientado a objetos. Em sua forma mais simples, um caso de uso identifica
o tipo da interação e os agentes envolvidos. Por exemplo, a figura 3.3 mostra o caso de uso de
alto nível do recurso de impressão de artigos no LIBSYS, descrito no Quadro 3.1.
A figura 3.3 mostra os elementos essenciais da notação de caso de uso. Os
agentes no processo são representados como bonecos e cada classe de interação é
representada como uma elipse identificada. O conjunto de casos de uso representa todas as
possíveis interações a serem representadas nos requisitos de sistema. A figura 3.4 desenvolve
o exemplo do LIBSYS e mostra outros casos de uso nesse ambiente.
Usuário da
biblioteca
Figura 3.4 – Casos de uso para o sistema de biblioteca
Busca de
artigos
Impressão
de artigos
Administração
de usuários
Serviços de
catálogo
Fornecedor
Pessoal da
biblioteca
Impressão
de artigos
Usuário da
biblioteca
Figura 3.3 – Caso de uso simples para impressão de artigos

PROCESSOS DE
Algumas vezes, existe confusão sobre se um caso de uso é um cenário em si
ou se um caso de uso engloba um conjunto de cenários, sendo cada cenário um
encadeamento isolado ao longo do caso de uso. Se um cenário incluir vários encadeamentos,
existirá um cenário para interação normal e mais cenários para cada possível exceção.
Os casos de uso identificam as interações individuais com o sistema. Eles
podem ser documentados por meio de texto ou de links com os modelos UML que
desenvolvem o cenário mais detalhadamente. Os diagramas de sequência são frequentemente
usados para adicionar informações ao caso de uso. Os diagramas de sequência mostram os
agentes envolvidos na interação, os objetos com os quais interagem e as operações
associadas a esses objetos.
Como ilustração disto, a figura 3.5 mostra as interações envolvidas no uso do
LIBSYS para baixar e imprimir um artigo na forma de diagrama de sequência. Na figura 3.5,
existem quatro objetos de classes – Artigo, Formulário, Área de Trabalho e Impressora –
envolvidos na interação. A sequência de ações ocorre de cima para baixo e os rótulos sobre as
setas entre os agentes e os objetos indicam os nomes das operações. Essencialmente, a
solicitação de um artigo pelo usuário dispara uma requisição para um formulário de direitos
autorais. Quando o usuário concluir o preenchimento do formulário, o artigo será baixado e
enviado para a impressora. Quando a impressão terminar, o artigo será apagado da área de
trabalho do LIBSYS.
Figura 3.5 – Diagrama de sequência das interações do sistema para impressão de artigos
apagar
informar
confirmar
enviar
imprimir
artigo ok
liberar
direitos autorais ok
retornar
completar
solicitar
solicitar
Item: Artigo copyrightForm:
Formulário
myWorkspace:
Área de trabalho
myPrinter:
ImpressoraUsuário da
biblioteca

PROCESSOS DE
A UML é um padrão real para a modelagem orientada a objetos e, portanto, os
casos de uso e a elicitação baseada em casos de uso têm sido cada vez mais usados para
elicitação de requisitos.
Cenários e casos de uso são técnicas eficazes para elicitação de requisitos
segundo pontos de vista de interação, em que cada tipo de interação pode ser representado
como um caso de uso. Eles também podem ser usados em conjunto com alguns pontos de
vista indiretos, sendo que esses pontos de vista recebem alguns resultados (como um relatório
gerencial) do sistema. Contudo, como eles enfocam as interações, não são eficazes para
elicitar restrições ou requisitos de negócios e não funcionais de alto nível com base nos pontos
de vista indiretos ou para obter requisitos de domínio.
Etnografia
Os sistemas de software não existem isoladamente – eles são 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 e
organizacionais é importante para o sucesso do sistema. Uma razão pela qual vários sistemas
de software são entregues, mas nunca usados, é que eles não dão a importância devida a
esses requisitos.
Etnografia é uma técnica de observação 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 estão envolvidos. O valor da etnografia está na ajuda que
presta aos analistas para descobrir os requisitos implícitos de sistema que refletem os
processos reais, e não os formais, com os quais as pessoas estão envolvidas.
As pessoas frequentemente consideram muito difícil articular detalhes de seu
trabalho, pois isso é secundário para elas. Elas compreendem seu próprio trabalho, mas
podem não compreender seu relacionamento com o trabalho de outros na organização. Os
fatores sociais e organizacionais, que afetam o trabalho, mas que não são óbvios para as
pessoas, podem somente se tornar claros quando examinados por um observador imparcial.
Pesquisadores usaram a etnografia para estudar o trabalho em escritório e
concluíram que as práticas reais de trabalho eram mais ricas, mais complexas e mais
dinâmicas do que os simples modelos considerados pelos sistemas e automação de escritório.
A diferença entre o trabalho suposto e o real é a razão mais importante pela qual os sistemas
de escritório não tiveram efeito significativo na produtividade. Outros estudos de etnografia
para a compreensão dos requisitos de sistema incluíram estudos sobre controle de tráfego
aéreo, salas de controle do metrô, sistemas financeiros e várias atividades de projeto.

PROCESSOS DE
Outras pesquisas investigaram métodos de integração de etnografia no
processo de engenharia de software, ligando-o aos métodos de engenharia de requisitos e pela
documentação de padrões de interação 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 definições de processo
dizem que elas deveriam trabalhar. Por exemplo, os controladores de
tráfego aéreo podem desligar um sistema de alerta de colisão de
aeronaves que detecta rotas de voo em colisão, embora os
procedimentos normais de controle especifiquem que ele deve ser
usado. Sua estratégia 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 cooperação e do conhecimento das
atividades de outras pessoas. Por exemplo, os controladores de
tráfego aéreo podem usar o conhecimento que têm do trabalho de
outros controladores para prever o número de aeronaves que entrarão
em seu setor de controle. Depois eles modificam suas estratégias de
controle, dependendo da sobrecarga prevista. Portanto, um sistema
automatizado de controle de tráfego aéreo deve permitir que os
controladores em um setor tenham alguma visibilidade do trabalho em
setores adjacentes.
A etnografia pode ser combinada com a prototipação (figura 3.6). A etnografia
informa o desenvolvimento do protótipo de tal modo que poucos ciclos de refinamento de
protótipo sejam necessários. Além disso, a prototipação enfoca a etnografia, identificando os
problemas e as questões que podem, assim, ser discutidos com o etnógrafo. O etnógrafo deve,
então, procurar as respostas a estas questões durante a próxima fase do estudo de sistema.
Os estudos de etnografia podem revelar detalhes importantes do processo
frequentemente ignorados por outras técnicas de elicitação de requisitos. No entanto, devido a
seu foco no usuário final, essa abordagem não é apropriada para obter os requisitos
organizacionais ou de domínio. Os estudos etnográficos nem sempre podem identificar novas
características a serem acrescentadas a um sistema. A etnografia não é, portanto, uma
abordagem completa para elicitação e deve ser usada para complementar outras abordagens,
como a análise de casos de uso.

PROCESSOS DE
4. VALIDAÇÃO DE REQUISITOS
A validação de requisitos dedica-se a mostrar que os requisitos realmente
definem o sistema que o usuário deseja/necessita. A validação de requisitos se sobrepõe à
análise; está relacionada à descoberta de problemas com os requisitos. A validação de
requisitos é importante porque os erros em um documento de requisitos podem levar a custos
excessivos de retrabalho quando são descobertos durante o desenvolvimento ou depois que o
sistema está em operação. O custo de correção de um problema de requisitos, fazendo uma
mudança de sistema, é muito maior do que a correção de erros de projeto e de codificação. A
razão disso é que uma mudança de requisitos significa geralmente que o projeto e a
implementação do sistema devem também ser mudados e o sistema deve ser novamente
testado.
Durante o processo de validação de requisitos, devem ser realizadas
verificações nos requisitos do documento de requisitos. Essas verificações incluem:
1. Verificações de validade: um usuário pode pensar que um sistema é
necessário para desempenhar determinadas funções. Contudo, mais
estudos e análises podem identificar que funções adicionais e
diferentes são necessárias. Os sistemas têm diversos stakeholders
com necessidades diferentes e qualquer conjunto de requisitos é,
inevitavelmente, um compromisso da comunidade de stakeholders.
2. Verificações de consistência: os requisitos em um documento não
devem ser conflitantes. Isso significa que não devem existir restrições
ou descrições contraditórias para a mesma função do sistema.
Figura 3.6 – Etnografia e prototipação para análise de requisitos
Análise
etnográfica
Reuniões
de prestação
de contas
Etnografia
focalizada
Desenvolvimento
de sistema
genérico
Prototipação
de sistema
Avaliação de
protótipo

PROCESSOS DE
3. Verificações de completeza: o documento de requisitos deve incluir
requisitos que definam todas as funções e as restrições desejadas
pelo usuário do sistema.
4. Verificações de realismo: usando o conhecimento da tecnologia
existente, os requisitos devem ser verificados quanto a se realmente
podem ser implementados. Essas verificações também devem levar
em consideração o orçamento e o prazo para o desenvolvimento do
sistema.
5. Facilidade de verificação: para reduzir o potencial de divergências
entre cliente e fornecedor, os requisitos do sistema devem sempre
ser escritos de modo que sejam verificáveis. Isso significa que deve-
se ser capaz de escrever um conjunto de testes que possa
demonstrar que o sistema entregue atende a cada requisito
especificado.
Uma série de técnicas de validação de requisitos pode ser usada em conjunto
ou individualmente:
1. Revisões de requisitos: os requisitos são analisados
sistematicamente por uma equipe de revisores.
2. Prototipação: nesta abordagem de validação, um modelo executável
do sistema é apresentado para usuários finais e clientes. Eles podem
experimentar o modelo para verificar se atende às suas necessidades
reais.
3. Geração de casos de teste: os requisitos devem ser testáveis. Se os
testes dos requisitos forem criados como parte do processo de
validação, eles frequentemente revelarão problemas de requisitos. Se
um teste for difícil ou impossível de ser projetado, isso significa
geralmente que os requisitos serão difíceis de ser implementados e
devem ser reconsiderados. O desenvolvimento de testes a partir de
requisitos de usuário, antes de o código estar escrito, é uma parte
integrante da extreme programming.
Não se deve subestimar os problemas de validação de requisitos. É difícil
demonstrar que um conjunto de requisitos atende às necessidades do usuário. Os usuários
devem imaginar o sistema em operação e avaliar sua adequação ao trabalho. É difícil para
profissionais de informática habilidosos realizar esse tipo de análise abstrata e é ainda mais
difícil para os usuários do sistema. Como resultado, raramente se encontra todos os problemas

PROCESSOS DE
de requisitos durante o processo de validação. É inevitável que haja mudanças de requisitos
posteriores para corrigir omissões e mal-entendidos depois da aprovação do documento de
requisitos.
4.1. Revisões de requisitos
A revisão de requisitos é um processo manual que envolve pessoas de ambas
as organizações, do cliente e do fornecedor. Eles verificam o documento de requisitos em
busca de anomalias e omissões. O processo de revisão pode ser gerenciado da mesma
maneira que as inspeções 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 revisões de requisitos podem ser informais ou formais. As revisões
informais envolvem simplesmente os fornecedores que discutem os requisitos com o maior
número possível de stakeholders. É surpreendente a frequência com que a comunicação entre
os projetistas e os stakeholders termina após a elicitação e não existe confirmação de se os
requisitos documentados são os que os stakeholders realmente solicitaram. Muitos problemas
podem ser detectados simplesmente conversando sobre o sistema com os stakeholders antes
do comprometimento de uma revisão formal.
Em uma revisão formal de requisitos, a equipe de desenvolvimento deve
'conduzir' o cliente pelos requisitos de sistema, explicando as implicações de cada requisito. A
equipe de revisão deve verificar cada requisito em termos de consistência bem como verificar
os requisitos como um todo em termos de completeza. Os revisores podem também verificar:
1. Facilidade de verificação: o requisito, conforme estabelecido, é
testável de forma realística?
2. Facilidade de compreensão: os adquirentes e os usuários finais do
sistema compreendem o requisito de forma apropriada?
3. Rastreabilidade: a origem do requisito está estabelecida claramente?
Talvez seja necessário retornar à fonte do requisito para avaliar o
impacto de uma mudança. A rastreabilidade é importante, pois
permite que o impacto de uma mudança seja avaliado em relação ao
restante do sistema. A rastreabilidade é explicada mais
detalhadamente na próxima seção.
4. Adaptabilidade: o requisito é adaptável? Isto é, o requisito pode ser
mudado sem efeitos em grande escala sobre os outros requisitos de
sistema?

PROCESSOS DE
Conflitos, contradições, erros e omissões nos requisitos devem ser apontados
pelos revisores e registrados formalmente no relatório de revisão. É, portanto, de
responsabilidade dos usuários, do adquirente de sistema e do desenvolvedor de sistema
negociar uma solução para esses problemas identificados.
5. GERENCIAMENTO DE REQUISITOS
Os requisitos de sistemas de software de grande porte estão sempre mudando.
Um motivo para isso é que esses sistemas são geralmente desenvolvidos para lidar com
problemas 'perversos'. Como o problema não 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 então evoluir
para refletir essas novas visões do problema.
Além disso, depois que o sistema estiver instalado, inevitavelmente surgirão
novos requisitos. É difícil para os usuários e os clientes do sistema anteciparem quais efeitos o
novo sistema causará na organização. Quando os usuários adquirirem experiência com o
sistema, eles descobrirão novas necessidades e prioridades:
1. Sistemas de grande porte geralmente têm uma comunidade
diversificada de usuários, sendo que esses usuários têm diferentes
requisitos e prioridades, os quais podem ser conflitantes ou
contraditórios. Os requisitos finais do sistema constituem
inevitavelmente um compromisso entre eles e, com a experiência,
descobre-se frequentemente que o equilíbrio de apoio dado aos
diferentes usuários tem de ser mudado.
2. As pessoas que pagam por um sistema e os usuários de um sistema
raramente são as mesmas pessoas. Os clientes do sistema impõem
requisitos devido a restrições organizacionais e de orçamento. Essas
restrições podem ser conflitantes com os requisitos dos usuários finais
e, após a entrega, novas características podem ser incluídas para
apoio do usuário, fazendo com que o sistema alcance as suas metas.
3. Os ambientes de negócios e técnico do sistema mudam após a
instalação e essas mudanças devem se refletir no sistema.
4. Um novo hardware pode ser introduzido, pode ser necessária uma
interface com outros sistemas, as prioridades de negócios podem
mudar trazendo consequentes mudanças no apoio ao sistema e uma

PROCESSOS DE
nova legislação e regulamentos em ser introduzidos devendo ser
implementados no sistema.
O gerenciamento de requisitos é um processo para compreender e controlar as
mudanças dos requisitos de sistema. É necessário manter o acompanhamento dos requisitos
individuais e manter as ligações entre os requisitos dependentes, de modo que seja possível
avaliar o impacto das mudanças de requisitos. É necessário estabelecer um processo formal
para fazer propostas de mudança e ligá-las aos requisitos de sistema. O processo de
gerenciamento de requisitos deve se iniciar assim que uma versão inicial do documento de
requisitos esteja disponível, mas deve-se iniciar o planejamento das mudanças de requisitos
durante o processo de elicitação de requisitos.
5.1. Requisitos permanentes e voláteis
A evolução de requisitos, durante o processo de engenharia de requisitos e
após a entrada de um sistema em operação, é inevitável. O desenvolvimento de requisitos de
software enfoca as capacidades de software, objetivos da empresa e outros sistemas da
empresa. À medida que a definição dos requisitos se desenvolve, uma compreensão maior das
necessidades dos usuários é obtida. Isso realimenta as informações do usuário que pode,
então, propor uma mudança nos requisitos (figura 5.1). Além 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 mudanças.
Do ponto de vista da evolução, os requisitos dividem-se em duas classes:
1. Requisitos permanentes: são requisitos relativamente estáveis
derivados da atividade central da organização e que se relacionam
diretamente ao domínio do sistema. Por exemplo, em um hospital,
sempre existirão requisitos relacionados a pacientes, médicos,
Compreensão
inicial
do problema
Requisitos
iniciais
Compreensão
modificada
do problema
Requisitos
modificados
tempo
Figura 5.1 – Evolução de requisitos

PROCESSOS DE
enfermeiros e tratamentos. Esses requisitos podem ser derivados
de modelos de domínio que mostram as entidades e as relações
que caracterizam um domínio de aplicação.
2. Requisitos voláteis: são requisitos que provavelmente irão mudar
durante o processo de desenvolvimento do sistema ou depois que o
sistema estiver em operação. Um exemplo seria os requisitos que
resultam de políticas de saúde do governo.
Sugere-se que os requisitos voláteis sejam divididos em cinco classes,
conforme demonstrado na tabela 5.1.
Tabela 5.1 – Classificação de requisitos voláteis
Tipo de requisito Descrição
Requisitos
mutáveis
Requisitos que mudam devido a mudanças no ambiente no qual a
organização está operando. Por exemplo, em sistemas hospitalares, o
financiamento do tratamento de pacientes pode mudar e, assim, exigir
que informações de diferentes tratamentos sejam coletadas.
Requisitos
emergentes
Requisitos que surgem à medida que a compreensão 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 introdução do sistema de computador. A
introdução do sistema de computador pode mudar os processos da
organização e criar novas formas de trabalho que geram novos
requisitos de sistema.
Requisitos de
compatibilidade
Requisitos que dependem de sistemas ou processos de negócios
específicos dentro de uma organização. À medida que eles mudam, os
requisitos de compatibilidade do sistema encomendado ou entregue
podem também evoluir.
5.2. Planejamento de gerenciamento de requisitos
O planejamento é o primeiro estágio essencial no processo de gerenciamento
de requisitos. O gerenciamento de requisitos é muito dispendioso. Para cada projeto, o estágio
de planejamento estabelece o nível de detalhamento necessário para o gerenciamento de
requisitos. Durante o estágio de gerenciamento de requisitos, deve-se decidir sobre:
1. Identificação de requisitos: cada requisito deve ser identificado
unicamente de modo que possa ser feita a referência cruzada entre
este e outros requisitos para que ele possa ser usado nas
avaliações de rastreabilidade.

PROCESSOS DE
2. Processo de gerenciamento de mudanças: é o conjunto de
atividades que avaliam o impacto e custo das mudanças.
3. Políticas de rastreabilidade: essas políticas 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 informações
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 vários relacionamentos entre os requisitos e entre os requisitos e o
projeto do sistema. Existem também ligações entre requisitos e os motivos básicos de por que
esses requisitos foram propostos. Quando as mudanças são propostas, deve-se rastrear o seu
impacto em outros requisitos e no projeto do sistema. A rastreabilidade é a propriedade de uma
especificação de requisitos que reflete a facilidade de encontrar os requisitos relacionados.
Existem três tipos de informações de rastreabilidade que podem ser mantidos:
1. Informações de rastreabilidade da origem ligam os requisitos aos
stakeholders que propuseram os requisitos e aos motivos desses
requisitos. Quando uma mudança é proposta, essas informações são
usadas para encontrar e consultar os stakeholders sobre a mudança.
2. Informações de rastreabilidade de requisitos ligam os requisitos
dependentes dentro do documento de requisitos. Essas informações
são usadas para avaliar quantos requisitos provavelmente serão
afetados pela mudança proposta e a extensão das mudanças de
requisitos consequentes que podem ser necessários.
3. Informações de rastreabilidade de projeto ligam os requisitos aos
módulos de projeto, nos quais esses requisitos são implementados.
Essas informações são usadas para avaliar o impacto das mudanças
de requisitos propostas no projeto e na implementação do sistema.
As informações de rastreabilidade são frequentemente representadas por meio
de matrizes de rastreabilidade que relacionam os requisitos aos stakeholders, aos outros
requisitos ou aos módulos de projeto. Em uma matriz de rastreabilidade de requisitos, cada

PROCESSOS DE
requisito é introduzido em uma linha e uma coluna da matriz. As dependências entre diferentes
requisitos são registradas na célula correspondente à intersecção de linha/coluna.
A tabela 5.2 mostra uma matriz simples de rastreabilidade que registra as
dependências entre requisitos. A letra 'D' na intersecção 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.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 D R
1.2 D R D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R
As matrizes de rastreabilidade podem ser usadas quando um pequeno número
de requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos requisitos,
tornam-se muito difíceis de serem gerenciadas e sua manutenção é dispendiosa, Para esses
sistemas, deve-se captar as informações de rastreabilidade em um banco de dados de
requisitos, no qual cada requisito é explicitamente ligado a requisitos relacionados. Pode-se,
então, avaliar o impacto das mudanças 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 é necessário para:
1. Armazenamento de requisitos: os requisitos devem ser mantidos em
um repositório de dados seguro e gerenciado, acessível a todos os
envolvidos no processo de engenharia de requisitos.

PROCESSOS DE
2. Gerenciamento de mudanças: o processo de gerenciamento de
mudanças (figura 5.2) é simplificado se um apoio ativo de ferramentas
estiver disponível.
3. Gerenciamento de rastreabilidade: conforme explicado anteriormente,
o apoio de ferramentas para rastreabilidade permite que requisitos
relacionados sejam obtidos. Algumas ferramentas usam técnicas de
processamento de linguagem natural para auxiliar na descoberta de
possíveis relacionamentos entre os requisitos.
Para sistemas de pequeno porte, o uso de ferramentas especializadas de
gerenciamento de requisitos pode não ser necessário. O processo de gerenciamento de
requisitos pode ter o apoio de recursos disponíveis em processadores de texto, planilhas e
bancos de dados. Contudo, para sistemas de grande porte, é necessária uma ferramenta de
apoio mais especializada.
5.3. Gerenciamento de mudanças de requisitos
O gerenciamento de mudanças de requisitos (figura 5.2) deve ser aplicado a
todas as mudanças propostas aos requisitos. A vantagem de usar um processo formal para
gerenciamento de mudanças é que todas as propostas de mudança são tratadas
consistentemente e as mudanças no documento de requisitos são feitas de maneira controlada.
Existem três principais estágios para um processo de gerenciamento de mudanças:
1. Análise do problema e especificação da mudança: o processo se
inicia com um problema de requisitos identificado ou, às vezes, com
uma proposta de mudança específica. Durante esse estágio, o
problema ou a proposta de mudança é analisada para verificar se é
válida. Os resultados da análise são realimentados para o solicitante
da mudança e, algumas vezes, é feita uma proposta de mudança de
requisitos mais específica.
2. Análise da mudança e estimativa de custo: o efeito da mudança
proposta é avaliado usando as informações de rastreabilidade e o
conhecimento geral sobre os requisitos do sistema. O custo de
realizar a mudança é estimado em termos de modificações no
documento de requisitos e, se adequado, do projeto e da
implementação do sistema. Uma vez completada esta análise, é
tomada uma decisão sobre prosseguir ou não com a mudança de
requisitos.

PROCESSOS DE
3. Implementação da mudança: o documento de requisitos e, quando
necessário, o projeto e a implementação de sistema são modificados.
Deve-se organizar o documento de requisitos de modo que possa
realizar as mudanças sem reescrita ou reorganização extensivas. Da
mesma maneira que na programação, a facilidade de mudanças no
documento é obtida por meio da minimização das referências
externas e tornando as seções do documento o mais modulares
possível. Assim, as seções individuais podem ser mudadas e
substituídas sem afetar outras partes do documento.
Se uma mudança de requisitos do sistema é solicitada com urgência, existe
sempre uma propensão a realizar a mudança no sistema e, depois, retrospectivamente,
modificar o documento de requisitos. Isso leva quase inevitavelmente à defasagem entre o
documento de requisitos e a implementação do sistema. Uma vez feitas as mudanças no
sistema, as mudanças no documento de requisitos podem ser esquecidas ou realizadas de
maneira não consistente com as mudanças 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 usuário propõe mudança de requisito, essa mudança não é
realizada por meio de um processo de gerenciamento de mudanças formal. Em vez disso, o
usuário precisa priorizar essa mudança e, se a prioridade for alta, decidir quais características
do sistema planejadas para a próxima iteração devem ser abandonadas.
Análise do
problema e
especificação
de mudanças
Figura 5.2 – Gerenciamento de mudanças de requisitos
Problema
identificado
Análise de
mudanças e
estimativa
de custo
Implementação
das mudanças
Requisitos
revisados

PROCESSOS DE
 Empresário
 Consultor de Empresas
 Professor Universitário
 Mestre em Informática
 Gestão de Sistemas de Informação
 Especialista em Sistemas de Informatização
Empresarial
 Bacharel em Administração
 Tecnólogo em Processamento de Dados
marcelo.moreira2@fatec.sp.gov.br

Engenharia de software i 3 - processos de engenharia de requisitos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Engenharia de software i 3 - processos de engenharia de requisitos

Semelhante a Engenharia de software i 3 - processos de engenharia de requisitos (20)

Último

Último (20)

Engenharia de software i 3 - processos de engenharia de requisitos