engenharia de software i 3 - processos de engenharia de requisitos

.

Engenharia de Software I

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



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



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:



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:



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.



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.



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



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:



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.



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



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



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



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



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' .



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



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: Impressora Usuário da

biblioteca



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.



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.



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



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



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?



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



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



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.



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



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.



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.



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



Prof. Me. Marcelo dos Santos Moreira 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

[email protected]

engenharia de software i 3 - processos de engenharia de requisitos

Education