Unidade 2

Prévia do material em texto

Requisitos de Software 
 
 
Prezados (as) acadêmicos (as)! 
É com grande satisfação que iniciamos a nossa segunda unidade da 
disciplina de Requisitos, Análise e Projeto de Sistemas do curso de 
Licenciatura em Computação, que trata das características e conceitos que 
envolvem esta disciplina tão atual no cotidiano dos profissionais da 
computação. 
Nesta unidade, estudaremos tópicos que objetivam fazer com que o aluno 
construa uma base de conhecimento que o permita realizar atividades 
voltadas à disciplina de Requisitos. 
Os objetivos específicos são: 
● conceituar o que são Requisitos funcionais e não funcionais; 
● identificar pontos relevantes pertinentes às disciplinas de Requisitos; 
● compreender a importância da utilização de ferramentas e UML para 
essa atividade. 
Como leitura obrigatória desta unidade, selecionamos o texto ‘Requisitos 
de Software’ disponível na Aba “Biblioteca” e na ferramenta “Conteúdo 
Interativo”. 
Após a leitura atenta aos textos, vocês deverão realizar a atividade 
avaliativa: questionário com valor máximo: 100 pontos. 
A Leitura obrigatória é essencial para que vocês possam, de forma 
produtiva, construir o conhecimento nesta unidade, bem como participar 
das atividades avaliativas. 
Fiquem atentos ao prazo de encerramento da unidade e da atividade 
avaliativa. Se vocês tiverem alguma dúvida, não hesitem em entrar em 
contato com o seu tutor para saná-la. Além disso, procure discutir as 
temáticas apresentadas neste material com os seus colegas de curso, seja 
no ambiente de aprendizagem ou no polo de sua cidade. 
Bom trabalho! 
REQUISITOS DE SISTEMAS 
 
PARTE A - CONCEITOS FUNDAMENTAIS 
 
1. Introdução 
 
O desenvolvimento de software objetiva criar soluções 
computacionais em software que atendam às necessidades de clientes e 
usuários. Uma correta especificação dos requisitos do software é 
essencial para evitarmos o esforço dispendioso de desenvolvimento. 
Mesmo que um sistema tenha sido bem projetado e codificado, se ele 
for mal especificado provavelmente frustrará o usuário e causará 
desconforto à equipe de desenvolvimento, que terá de modificá-lo para 
se adequar às necessidades do cliente. 
Os requisitos abrangem a definição do que o sistema deve 
realizar, suas propriedades e as restrições que envolvem sua operação e 
o processo de desenvolvimento. A interação efetiva entre os clientes e 
usuários do software e os desenvolvedores geralmente resulta na 
definição eficaz de requisitos. Os requisitos do sistema não são 
influenciados somente pelas preferências dos usuários, mas também por 
questões organizacionais. 
Geralmente, inúmeras dificuldades são encontradas pela equipe 
desenvolvedora quanto ao entendimento da informação fornecida pelo 
cliente / usuário. Os requisitos são frequentemente registrados de 
maneira desorganizada e desperdiça-se tempo verificando o que de fato 
foi registrado, permitido que as modificações nos requisitos controlem a 
equipe desenvolvedora ao invés de se estabelecer um controle de 
modificações. Falha-se na fundamentação sólida para o desenvolvimento 
de software e, quando esses problemas se combinam, a perspectiva é 
danosa mesmo para os gerentes e profissionais mais experientes. Mas 
há uma boa notícia: existem soluções para esses problemas e elas 
abrangem a definição correta dos requisitos funcionais e dos requisitos 
não funcionais do sistema. 
40
2. Requisitos Funcionais
Os requisitos funcionais de um sistema descrevem o que o 
sistema deve fazer. Esses requisitos dependem do tipo de software que 
está sendo desenvolvido, dos usuários a que o software se destina e da 
abordagem geral considerada pela organização ao redigir os requisitos. 
Os requisitos funcionais descrevem detalhadamente as funcionalidades, 
entradas, saídas e exceções do sistema. O nível de detalhamento do 
requisito pode variar, conforme os exemplos abaixo: 
● Exemplo 1: O usuário deve ser capaz de fazer uma busca em todo 
o banco de dados ou selecionar uma visão nele baseado (requisito 
pouco detalhado). 
● Exemplo 2: O sistema deve fornecer telas apropriadas para o 
usuário visualizar os documentos do repositório (requisito pouco 
detalhado).
● Exemplo 3: Para cada pedido deve ser alocado um identificador 
único Order_ID (requisito bem detalhado).
Em uma especificação de requisitos funcionais, os serviços 
exigidos pelo usuário devem ser definidos (completeza) e os requisitos 
não devem ter definições contraditórias (consistência). Porém, é muito 
difícil atingir a completeza e consistência em sistemas grandes e 
complexos, pois além de ser fácil cometermos erros e omissões na 
especificação, há diferentes stakeholders[1] que possuem diferentes 
necessidades. Ainda, interpretações incorretas normalmente resultam na 
especificação de requisitos inconsistentes. Com isso, os problemas 
podem aparecer apenas depois de uma análise mais profunda ou, às 
vezes, depois que o desenvolvimento estiver concluído e o sistema tiver 
sido entregue para o cliente. 
3. Requisitos Não Funcionais
Os requisitos não funcionais definem as restrições do sistema, 
como a capacidade dos dispositivos de entrada/saída e as 
representações de dados utilizadas nas interfaces do sistema. Podem 
41
especificar desempenho, proteção, disponibilidade e outras propriedades 
emergentes do sistema. Abrangem também restrições de orçamento, 
políticas organizacionais, interoperabilidade com outros sistemas de 
software ou hardware, regulamentos de segurança ou legislação sobre 
privacidade, conforme ilustrado na Figura 2.1. Geralmente são mais 
importantes que os requisitos funcionais, pois o não atendimento a um 
requisito não funcional pode comprometer o funcionamento de todo o 
sistema. Por outro lado, os usuários costumam contornar uma situação 
em que uma determinada funcionalidade do sistema não atende à sua 
necessidade. 
 
[1] O termo stakeholder define a pessoa ou grupo afetado direta ou 
indiretamente pelo desenvolvimento do sistema. 
 
Figura 2.1 – Tipos de requisitos não funcionais (Fonte: SOMMERVILLE, 2007). 
 
Os requisitos não funcionais são classificados em três grupos 
principais: 
1) Requisitos de produto: especificam o comportamento do produto e 
estão relacionados à usabilidade, eficiência, confiabilidade e 
42
portabilidade do sistema. A Tabela 2.1 ilustra os tipos de requisitos de 
produto com o respectivo exemplo. 
 
Tipo de requisito de produto Exemplo 
Usabilidade Usuários deverão operar o sistema 
após um determinado tempo de 
treinamento 
Eficiência O sistema deverá processar n 
requisições por um determinado 
tempo (tempo de resposta é 
requerido) 
Confiabilidade O sistema deve estar disponível ao 
usuário durante 99% do tempo 
Portabilidade O sistema deve operar na plataforma 
Windows 
Tabela 2.1 – Tipos de requisitos de produto. 
 
 
 
2) Requisitos organizacionais: derivados de políticas e procedimentos de 
organização do cliente e do desenvolvedor. Incluem requisitos de 
entrega (especificam quando o produto e a documentação devem ser 
entregues), requisitos de implementação (linguagem e/ou método 
utilizados) e padrões de processos. A Tabela 2.2 ilustra os tipos de 
requisitos organizacionais com o respectivo exemplo. 
 
Tipode requisito 
organizacional 
Exemplo 
Entrega O sistema deve possibilitar a 
emissão de relatórios gerenciais 
de contas a pagar 
43
Implementação O sistema deverá ser 
desenvolvido na linguagem Java 
Padrões O uso de programação orientada 
a objetos sob a plataforma 
Windows 
Tabela 2.2 – Tipos de requisitos organizacionais. 
 
3) Requisitos externos: abrange todos os requisitos provenientes de 
fatores externos ao sistema e seu processo de desenvolvimento. 
Incluem requisitos de interoperabilidade, requisitos éticos e requisitos 
legais. A Tabela 2.3 ilustra os tipos de requisitos externos com os 
respectivos exemplos. 
 
Tipo de requisito externo Exemplo 
Interoperabilidade O sistema deverá se comunicar 
com o Sistema Gerenciador de 
Banco de Dados SQL Server 
Ético O sistema não apresentará aos 
usuários quaisquer dados 
considerados privados 
Legal O sistema deverá atender às 
normas legais, tais como 
padrões, leis, etc. 
Tabela 2.3 – Tipos de requisitos externos. 
 
 
 
4. Categorização dos Requisitos (FURPS+) 
 
Uma forma de estabelecer critérios de qualidade para avaliação de 
sistemas de software é caracterizar os atributos de um sistema de 
44
software de acordo com a Funcionalidade (Functionality), Usabilidade 
(Usability), Confiabilidade (Reliability), Desempenho (Performance) e 
Suportabilidade (Supportability), constituindo o modelo FURPS+. Este 
acrônimo descreve as principais categorias de requisitos e o sinal “+” 
refere-se à inclusão de requisitos relacionados ao design, 
implementação, interface e característica física. 
 
● Funcionalidade (Funcional): os requisitos de funcionalidade são 
usados para expressar o comportamento de um sistema 
especificando a contribuição e as condições esperadas de saída. 
● Usabilidade (Não Funcional): endereçam fatores humanos 
(estética, facilidade de aprendizado e de uso) e consistência na 
interface do usuário, documentação de usuário e materiais de 
treinamento. 
● Confiabilidade (Não Funcional): endereçam frequência e gravidade 
de falha, possibilidade de recuperação, previsibilidade e precisão. 
● Desempenho (Não Funcional): impõem condições aos requisitos 
funcionais. Por exemplo, para uma determinada ação ser 
executada, um requisito pode especificar parâmetros de 
desempenho relacionados à velocidade, disponibilidade, precisão, 
tempo de resposta, tempo de recuperação ou utilização de 
recursos (memória, processamento, etc.). 
● Suportabilidade (Não Funcional): os requisitos de suporte podem 
incluir a capacidade de testes, adaptabilidade, manutenibilidade, 
compatibilidade, possibilidade de configuração, possibilidade de 
serviço, possibilidade de instalação. 
 
Outros requisitos do modelo FURPS+ 
 
● Requisito de Design: Um requisito de design, frequentemente 
chamado de uma restrição de design, especifica ou restringe o 
45
design de um sistema. 
● Requisito de Implementação: Um requisito de implementação 
especifica ou restringe o código ou a construção de um sistema. 
Como exemplos, podemos citar: padrões obrigatórios, linguagens 
de implementação, políticas de integridade de banco de dados, 
limites de recursos e ambientes operacionais. 
● Requisito de Interface: Um requisito de interface especifica um 
item externo com o qual o sistema deve interagir e restrições de 
formatos, tempos ou outros fatores usados por tal interação. 
● Requisito Físico: um requisito físico especifica uma característica 
física que um sistema deve possuir, podendo estar relacionado ao 
material, forma, tamanho e peso. Esse tipo de requisito pode ser 
usado para representar requisitos de hardware, como as 
configurações físicas de rede obrigatórias. 
 
5. Engenharia de Requisitos 
 
A Engenharia de Requisitos auxilia os engenheiros de software na 
melhor compreensão do problema que terá de ser resolvido por eles. Ela 
inclui um conjunto de tarefas ou subprocessos que levam a um 
entendimento de qual será o impacto do software sobre o negócio, do 
que o cliente deseja e de como os usuários finais vão interagir com o 
software. 
Como todas as outras atividades de Engenharia de Software, a 
Engenharia de Requisitos precisa ser adaptada às necessidades do 
processo, projeto, do produto e do pessoal que está fazendo o trabalho. 
Ela estabelece uma base sólida para o projeto e a construção. Sem ela, 
o software resultante tem uma alta probabilidade de não satisfazer às 
necessidades dos clientes, pois ela fornece o mecanismo apropriado 
para entender o que o cliente deseja, analisando as necessidades, 
avaliando a exequibilidade, negociando uma condição razoável, 
especificando a solução de modo não ambíguo, validando a 
especificação e gerindo os requisitos à medida em que são 
46
transformados em um sistema de software operacional. 
O processo de Engenharia de Requisitos deve gerar e manter um 
documento de requisitos de sistema. O processo geral inclui 
subprocessos relacionados à: avaliação da utilidade do sistema para a 
empresa (estudo de viabilidade), obtenção de requisitos (elicitação e 
análise), conversão desses requisitos em alguma forma padrão 
(especificação), verificação dos requisitos quanto ao real atendimento às 
necessidades do cliente (validação) e gerenciamento de requisitos. A 
Figura 2.2 ilustra o relacionamento entre essas atividades e os 
documentos produzidos em cada estágio do processo de engenharia de 
requisitos. 
 
 
Figura 2.2 – Processo de engenharia de requisitos (Fonte: SOMMERVILLE, 2007). 
 
As atividades ilustradas na Figura 2.2 estão relacionadas à 
obtenção, documentação e verificação de requisitos. Na prática, no 
entanto, todos os requisitos de sistema sofrem modificações ao decorrer 
do tempo. As pessoas envolvidas desenvolvem uma compreensão maior 
do que desejam que o software realize, a organização que está 
47
adquirindo o sistema estabelece novas prioridades, ocorrem 
modificações de hardware, de software e no ambiente organizacional do 
sistema. 
 
 
5.1 Estudo de Viabilidade 
Em todos os sistemas novos, o processo de Engenharia de 
Requisitos deve começar com um estudo de viabilidade. Este estudo 
consiste do esboço de requisitos de negócios, do esboço da descrição do 
sistema e da definição de como o sistema apoiará os processos de 
negócios. No relatório devem constar os resultados, recomendações (por 
exemplo, mudanças de escopo, orçamento e prazo) e a conclusão sobre 
a viabilidade dos processos de engenharia de requisitos e de 
desenvolvimento de sistema. A Tabela 2.4 ilustra uma Matriz de Análise 
de Viabilidade. 
 
 
 
 
Viabilidade Peso Alternativa 
1 
Alternativa 
2 
Alternativa 
3 
Operacional 50% 8 7 10 
Técnica 10% 9 7 10 
Cronograma 10% 10 7,5 6 
Econômica 30% 8,5 7 7,5 
 
Final 100% 8,45 7,05 8,85 
Tabela 2.4 – Matriz de Análise de Viabilidade. 
48
 
Em um estudo de viabilidade algumas questões devem ser respondidas: 
● O sistema contribui para os objetivos gerais da organização? 
● O sistema pode ser implementado com tecnologia atual e dentro 
das restrições definidas de custo e prazo? 
● O sistema pode ser integrado a outros sistemas já implantados? 
 
A contribuição do sistema para os objetivos da empresa é uma 
questão crítica, pois se um sistemanão atende aos requisitos 
elicitados, ele não tem valor real para a empresa. Isso pode ocorrer 
devido às falhas na definição de requisitos de negócios para o sistema 
ou por influência de fatores políticos ou organizacionais na aquisição do 
sistema. 
 
Tipos de viabilidade 
● Viabilidade operacional: análise do grau de adequação da solução 
para a organização. 
● Viabilidade técnica: é a avaliação de uma solução técnica 
específica e a disponibilidade dos recursos técnicos. 
● Viabilidade de cronograma: avaliação do cronograma do projeto. 
● Viabilidade econômica: avaliação do custo-benefício de um projeto 
ou solução. 
 
 
5.2 Elicitação e análise de requisitos 
 
Neste subprocesso da Engenharia de Requisitos, os 
desenvolvedores do sistema trabalham com o cliente para definirem 
características globais como o domínio da aplicação, os serviços 
oferecidos pelo sistema, o desempenho esperado, as restrições de 
49
hardware, etc. Além do desenvolvedor e do cliente, outras pessoas 
podem estar envolvidas na elicitação e análise de requisitos: usuários 
que interagem com o sistema, pessoas da organização que podem ser 
afetadas pela instalação, os engenheiros que estão mantendo ou 
desenvolvendo sistemas relacionados, gerentes de negócios, 
especialistas do domínio e representantes de sindicato. 
Um modelo de subprocesso genérico de elicitação e análise de 
requisitos é apresentado na Figura 2.3. Cada organização tem seu 
próprio modelo, de acordo com fatores como nível de conhecimento da 
equipe, padrões utilizados e tipo do sistema que está sendo 
desenvolvido. Trata-se de um subprocesso iterativo com realimentação 
contínua de cada atividade para outras atividades. O entendimento dos 
requisitos pelo analista deve aumentar a cada volta do ciclo. 
 
 
Figura 2.3 – Processo de elicitação e análise de requisitos (Fonte: SOMMERVILLE, 2007). 
50
 
As atividades do subprocesso de elicitação e análise envolvem a 
interação entre desenvolvedor e stakeholders para a coleta de 
requisitos. A interação com os stakeholders ocorre por meio de 
entrevistas e observações, podendo ser utilizados cenários e protótipos 
para auxiliar na obtenção de requisitos. 
 
● Entrevistas: por meio de entrevistas formais ou informais a 
equipe de engenharia de requisitos formula questões para os 
stakeholders sobre o sistema que eles já utilizam e o 
sistema a ser desenvolvido. O entrevistador eficiente possui 
“mente aberta”, não tem ideias preconcebidas sobre os 
requisitos, sabe ouvir os stakeholders, induz os 
entrevistados a iniciar as discussões com uma questão ou 
proposta de requisitos e, quando necessário, sugerem um 
trabalho conjunto em um protótipo do sistema. As 
informações obtidas das entrevistas complementam outras 
informações sobre o sistema obtidas de documentos, 
observações de usuários, etc. Portanto, deve ser utilizada 
juntamente com outras técnicas de 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 
interagiram 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 ú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 e abrangem uma ou mais 
interações possíveis. A elicitação baseada em cenários pode 
51
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. 
● Caso de uso: em sua forma mais simples, cujos elementos 
essenciais de sua notação são ilustrados na Figura 2.4, 
identifica o tipo da interação e os agentes envolvidos. O 
conjunto de casos de uso representa as possíveis interações 
compostas pelos requisitos do sistema. Os casos de uso 
podem ser documentados por meio de textos ou de links com 
modelos UML que desenvolvem o cenário mais 
detalhadamente. Os diagramas de sequência (apresentados 
na próxima Unidade), por exemplo, são frequentemente 
utilizados para adicionar informações ao caso de uso. 
Ilustram os agentes envolvidos na interação, os objetos com 
os quais interagem e as operações associadas a esses 
objetos. 
 
 
Figura 2.4 – Exemplo simples de caso de uso (Fonte: SOMMERVILLE, 2007). 
 
● Protótipos: o objetivo da prototipação é permitir que os 
usuários tenham contato direto com a interface. A maioria de 
nós considera difícil pensar de maneira abstrata sobre uma 
52
interface com o usuário para explicar exatamente o que 
queremos. Entretanto, quando são apresentados exemplos, é 
fácil identificar as características de que gostamos ou não. 
 
5.3 Especificação 
 
O documento de requisitos de software (referido também como 
especificação de requisitos ou SRS – Software Requirements 
Specification) é a declaração oficial do que os desenvolvedores de 
sistema devem implementar. Deve incluir os requisitos de usuário de um 
sistema e uma especificação detalhada dos requisitos de sistema. Em 
alguns casos, os requisitos de usuário e de sistema podem estar 
integrados em uma única descrição. Em outros casos, os requisitos de 
usuário estão definidos em uma introdução à especificação dos 
requisitos de sistema. Se houver um grande número de requisitos, os 
requisitos detalhados de sistema podem ser apresentados em um 
documento separado. 
O documento de requisitos pode ser útil a um conjunto 
diversificado de usuários, abrangendo desde a gerência sênior da 
organização até os próprios engenheiros responsáveis pelo 
desenvolvimento do software: 
● Clientes do sistema: especificam e leem os requisitos para 
verificar se eles atendem às suas necessidades. Os clientes 
especificam as mudanças nos requisitos. 
● Gerentes: usam o documento de requisitos para planejar um 
pedido de proposta para o sistema e planejar o processo de 
desenvolvimento de sistema. 
● Engenheiros de sistema: usam os requisitos para compreender 
qual sistema será desenvolvido. 
● Engenheiros de teste de sistema: usam os requisitos para 
53
desenvolver testes de validação para o sistema. 
● Engenheiros de manutenção de sistema: usam os requisitos para 
compreender o sistema e os relacionamentos entre suas partes. 
A diversidade de possíveis usuários significa que o documento de 
requisitos deve conter uma linguagem acessível e expor claramente o 
compromisso entre a comunicação dos requisitos para os clientes, a 
definição dos requisitos em detalhes precisos para os desenvolvedores e 
testadores e as informações sobre uma possível evolução do sistema. 
As informações sobre mudanças previstas podem auxiliar tanto os 
projetistas, que evitariam decisões restritivas de projeto, quanto os 
engenheiros de manutenção de sistema, que adaptariamo sistema a 
novos requisitos. 
O nível de detalhamento a ser incluído em um documento de 
requisitos depende do tipo de sistema que está sendo desenvolvido e 
do processo de desenvolvimento usado. Quando o sistema for 
desenvolvido por um fornecedor externo, as especificações de sistema 
crítico devem ser precisas e muito detalhadas. Quando houver maior 
flexibilidade nos requisitos e quando um processo de desenvolvimento 
interno e iterativo for usado, o documento de requisitos pode ser muito 
menos detalhado e qualquer ambiguidade será resolvida durante o 
desenvolvimento do sistema. 
Uma série de grandes organizações, como o Departamento de 
Defesa dos EUA e o Instituto de Engenheiros Eletricistas e Eletrônicos 
(IEEE), definiram padrões para documentos de requisitos. O padrão mais 
amplamente conhecido é IEEE/ANSI 830-1998, atual ISO/IEC/IEEE 
29148:2011. O padrão IEEE contém um grande número de 
recomendações de como redigir requisitos e evitar problemas. A Figura 
2.5 ilustra um modelo de documento de requisitos no padrão 
ISO/IEC/IEEE 29148:2011. 
 
54
 
Figura 2.5 – Modelo de documento de requisitos (Fonte: ISO/IEC/IEEE 29148:2011). 
 
 
5.4 Validação de requisitos 
O processo de validação objetiva a certificação de que os 
requisitos realmente definem o sistema que o usuário deseja. A 
validação de requisitos se sobrepõe à análise, pois está relacionada à 
descoberta de problemas relacionados aos requisitos. Erros contidos em 
um documento de requisitos, quando descobertos durante o 
desenvolvimento ou depois que o sistema está em operação, podem 
resultar em custos financeiros elevados e retrabalho. O custo de 
correção de um requisito que exige modificações no sistema é muito 
maior quando comparado à correção de erros de projeto e de codificação. 
A razão é que modificação de requisitos geralmente significa 
modificação no projeto e na implementação do sistema, que neste caso 
55
deverá ser testado novamente. 
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 os 
problemas identificados. Algumas técnicas de validação de requisitos 
podem ser usadas em conjunto ou individualmente. 
● Revisões de requisitos: os requisitos são analisados 
sistematicamente por uma equipe de revisores. 
● Prototipação: um modelo executável do sistema é apresentado 
para usuários finais e clientes com o objetivo de verificar se 
atende às suas reais necessidades. 
● Geração de casos de teste: os requisitos devem ser testáveis. Se 
um teste foi 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. 
 
5.5 Gerenciamento de requisitos 
Durante o processo de desenvolvimento de software, o 
entendimento dos stakeholders sobre o sistema 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. Quando os usuários 
adquirirem experiência com o sistema, novas necessidades e prioridades 
serão descobertas. 
O gerenciamento de requisitos é um subprocesso da Engenharia de 
Requisitos que objetiva a compreensão e o controle das mudanças dos 
requisitos de sistema. É preciso manter o acompanhamento dos 
requisitos individuais e manter as conexões entre os requisitos 
dependentes, de modo que seja possível avaliar o impacto das 
56
modificações. É preciso estabelecer um processo formal para fazer 
propostas de mudança e ligá-las aos requisitos de sistema. O processo 
de gerenciamento de requisitos deve ser iniciado no momento em que a 
versão inicial do documento de requisitos estiver disponível. O plano de 
mudanças de requisitos deve ser elaborado durante o subprocesso de 
elicitação de requisitos. 
Durante o estágio de gerenciamento de requisitos, deve haver: 
● Identificação de requisitos: cada requisito deve ser identificado 
unicamente de modo que haja a referência cruzada entre um 
requisito e outros requisitos, permitindo avaliações de 
rastreabilidade. 
● Processo de gerenciamento de mudanças: é o conjunto de 
atividades que avaliam o impacto e custo das mudanças. 
● Políticas de rastreabilidade: definem os relacionamentos entre os 
requisitos em si e entre os requisitos e o projeto de sistema. 
● Apoio de ferramentas case: por envolver o processamento de 
grandes quantidades de informações sobre os requisitos, 
ferramentas como sistemas especializados de gerenciamento de 
requisitos, planilhas ou simples sistemas de banco de dados 
podem ser utilizados. 
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 e coluna. A Figura 2.6 mostra uma matriz simples 
de rastreabilidade que registra as dependências entre os requisitos. A 
letra “D” na intersecção linha / coluna ilustra que o registro da linha 
depende do requisito identificado na coluna; a letra “R” significa que 
57
existe algum outro relacionamento mais fraco entre os requisitos. 
 
 
Figura 2.6 – Matriz de rastreabilidade (Fonte: SOMMERVILLE, 2007). 
 
As matrizes de rastreabilidade podem ser usadas quando um 
pequeno número de requisitos deve ser gerenciado. Em sistemas de 
grande porte com muitos requisitos o gerenciamento é difícil e a 
manutenção é dispendiosa. Para esses sistemas, as informações de 
rastreabilidade devem ser registradas em um banco de dados de 
requisitos, no qual cada requisito é explicitamente conectado a outros 
requisitos relacionados. O uso de ferramentas CASE neste caso é 
necessário para o armazenamento de requisitos, para o gerenciamento 
de mudanças e para o gerenciamento de rastreabilidade. 
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 geralmente leva à defasagem entre o documento de requisitos e a 
implementação do sistema. Uma vez realizadas as modificações no 
sistema, os ajustes necessários do documento de requisitos podem ser 
esquecidos ou realizados de maneira não consistente com as mudanças 
do sistema. 
O gerenciamento de mudanças de requisitos deve ser aplicado a 
todas as mudanças propostas aos requisitos. Embora o processo formal 
58
de gerenciamento de mudanças seja dispendioso, ele pode ser 
vantajoso, uma vez 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. 
 
6. Captação e administração de requisitosutilizando o 
RUP 
 
Em cada projeto de software orientado ao RUP podemos visualizar 
uma estrutura comum relacionada a requisitos. Primeiramente, são 
coletadas as solicitações dos stakeholders, que abrangem todas as 
solicitações obtidas dos usuários finais, clientes e outros interessados 
do projeto. 
O conjunto de solicitações é utilizado para desenvolver um 
documento de visão que contém o conjunto fundamental de 
necessidades do stakeholder e dos usuários e as características de alto 
nível do sistema. Estas características de sistema expressam os serviços 
que devem ser entregues pelo sistema para cumprir as necessidades do 
stakeholder. As informações incluídas no documento de visão devem 
estar baseadas na análise de custo da implementação e na previsão de 
retorno do investimento. 
Antes de iniciada a codificação, é necessário traduzir as 
informações do documento de visão em requisitos detalhados de 
software de modo que permita projetar e construir um sistema atual e 
identificar casos de teste para testar o comportamento de sistema. 
Estes requisitos detalhados são captados no modelo de caso de uso. 
No detalhamento dos requisitos é necessário lembrar as 
necessidades originais do stakeholder e das características de sistema, 
para ter certeza de estar interpretando corretamente a visão. Durante o 
detalhamento dos requisitos serão encontradas falhas e inconsistências, 
59
que exigirão novas reuniões com os stakeholders para esclarecimentos, 
intercâmbios e atualização das necessidades. Assim, o fluxo de 
requisitos se repete de modo iterativo até que todos os requisitos 
estejam definidos, a avaliação finalizada e as mudanças inevitáveis, 
administradas. 
 
6.1 Atividades 
A Figura 2.7 resume as atividades do RUP que constituem o fluxo 
de requisitos: 
 
Figura 2.7 – Fluxo de requisitos (Fonte: www.funpar.ufpr.br). 
 
● Analisar o problema: deve haver um acordo entre as partes na 
definição do problema que tem de ser resolvido. Faz-se necessário 
identificar os interessados, os limites e restrições do sistema. 
● Compreender as necessidades dos envolvidos: utilizar várias 
60
técnicas de extração, reunir as Solicitações dos Principais 
Envolvidos e obter uma compreensão clara das reais necessidades 
dos usuários e interessados do sistema. 
● Definir o Sistema: deve-se estabelecer um conjunto de 
características de sistema a ser considerado para entrega baseado 
na contribuição dos interessados. Faz-se necessário determinar os 
critérios que serão utilizados e definir junto aos interessados 
expectativas realistas sobre como as funcionalidades serão 
entregues. Os atores e casos de uso necessários para cada 
característica fundamental devem ser identificados. 
● Gerenciar o escopo do sistema: coletar informações importantes 
de interessados no projeto e mantê-las como atributos de 
requisitos, para serem usadas na priorização e alcance do conjunto 
de requisitos acordados. Assim, o sistema pode ser entregue 
dentro do prazo com orçamento que satisfaça as expectativas dos 
clientes. 
● Refinar a definição do sistema: utilizar um modelo de caso de uso, 
detalhar os requisitos do sistema para fazer um acordo com o 
cliente sobre a funcionalidade do sistema e captar outros 
requisitos importantes, como requisitos não funcionais, restrições 
de projeto, etc. 
● Gerenciar requisitos mutáveis: utilizar atributos de requisito e 
rastreamento para avaliar o impacto das mudanças de requisitos; 
usar uma autoridade central de controle para controlar mudanças 
nos requisitos; manter acordo com o cliente e estabelecer as 
expectativas realistas do que será entregue. 
 
 
6.2 Papéis 
Como tudo isso é traduzido concretamente em termos de 
61
trabalhadores, artefatos e atividades? A Figura 2.8 ilustra os papéis 
principais e artefatos no fluxo de requisitos. 
 
 
Figura 2.8 – Papéis e artefatos no fluxo de requisitos (Fonte: www.funpar.ufpr.br). 
 
● Analista de Sistemas: conduz e coordena a extração de requisitos 
e a modelagem do caso de uso delineando a funcionalidade do 
sistema e delimitando o sistema. Ao trabalhar com os 
interessados do projeto, o Analista de Sistemas analisa o 
problema e busca entender junto aos interessados o que eles 
precisam, além de definir o que o sistema deve fazer e talvez o 
que não deve fazer – também identificando requisitos não 
funcionais. O Analista de Sistemas pode então desenvolver uma 
Visão para o projeto. Esta visão expressa como um conjunto de 
características descritas a partir da perspectiva do interessado, é a 
base para o desenvolvimento de um esboço do modelo de caso de 
uso. 
● Especificador de Requisitos: detalha toda ou parte da 
funcionalidade do sistema descrevendo os aspectos dos requisitos 
de um ou vários casos de uso. A ele é atribuído um conjunto de 
casos de uso e requisitos suplementares que devem ser 
62
detalhados e que consistirão em outros artefatos do fluxo de 
requisitos. O Especificador de Requisitos não trabalha isolado e 
deve comunicar-se frequentemente com outros indivíduos 
especificadores de caso de uso e com o Analista de Sistemas. 
● Projetista de Interface do Usuário: é responsável por selecionar o 
conjunto de casos de uso para demonstrar as interações 
essenciais dos usuários com o sistema. Trabalhando com os 
usuários, o Projetista de Interface do Usuário desenvolve 
Storyboards de Casos de Uso e protótipos de interface do usuário 
para ajudar a determinar os requisitos finais do sistema. O 
Projetista de Interface trabalha em paralelo com o Especificador de 
Requisitos para projetar a interface do usuário do sistema. Na 
maioria dos casos há uma interação sinérgica entre eles. 
 
6.3 Artefatos 
 
● Plano de Gerenciamento de Requisitos: descreve a documentação 
de requisitos, os tipos de requisitos e seus respectivos atributos 
de requisitos, especificando as informações e os mecanismos de 
controle que devem ser coletados e usados para avaliar, relatar e 
controlar mudanças nos requisitos do produto. 
● Solicitações dos Principais Envolvidos: este artefato contém 
qualquer tipo de solicitação dos principais envolvidos (cliente, 
usuário final, pessoal de marketing etc.) em relação ao sistema 
que será desenvolvido. Ele também pode conter referências a 
qualquer tipo de fonte externa com a qual o sistema deve estar de 
acordo. 
● Glossário: define uma terminologia comum usada constantemente 
ao longo do projeto ou da organização. 
● Documento de Visão: fornece uma visão completa para o sistema 
63
de software desenvolvido e proporciona a base contratual para 
requisitos técnicos mais detalhados. O Documento de Visão é 
escrito sob a perspectiva do cliente, focando nas características 
essenciais do sistema e em níveis aceitáveis de qualidade. A visão 
deve incluir uma descrição do que será incluído, bem como as 
características que foram consideradas mas não incluídas. Também 
devem especificar as capacidades operacionais (volumes, tempo 
de resposta, precisões), os perfis do usuário e as interfaces 
interoperacionais com as entidades fora do limite do sistema,onde aplicável. 
● Modelo de Caso de Uso: deve servir como um meio de 
comunicação e como um contrato entre o cliente, os usuários e os 
desenvolvedores do sistema, na funcionalidade do sistema que 
permite: a) aos clientes e usuários validar que o sistema se 
tornará o que eles esperaram, e b) aos desenvolvedores do 
sistema construir o que é esperado. O Modelo de Caso de Uso 
consiste em Casos de Uso e Atores. Cada Modelo de Caso de Uso 
é descrito em detalhes, mostrando passo a passo como o sistema 
interage com os atores e o que ele faz no caso de uso. O mesmo 
Modelo de Caso de Uso é usado na análise do sistema, no projeto, 
na implementação e no teste. 
● Especificação Suplementar: é um complemento importante ao 
Modelo de Caso de Uso, porque juntos eles captam todos os 
requisitos de software (funcional e não funcional) que precisam ser 
descritas para servirem como especificação completa de requisitos 
de software. 
● Atributos de Requisitos: este artefato contém um repositório de 
dependências, atributos e requisitos de projeto para controlar a 
partir de uma perspectiva de gerenciamento de requisitos. 
● Caso de Uso: define um conjunto de instâncias de casos de uso, 
64
no qual cada instância é uma sequência de ações realizada por um 
sistema que produz um resultado de valor observável para 
determinado ator. 
● Especificação de Requisitos de Software (SRS): captura todos os 
requisitos de software para o sistema ou para uma parte do 
sistema. Quando uma modelagem de casos de uso é utilizada, 
este artefato consiste em um pacote contendo casos de uso do 
modelo de casos de uso e Especificações Suplementares 
aplicáveis. 
● Pacote de casos de uso: é um conjunto de casos de uso, atores, 
relacionamentos, diagramas e outros pacotes. Ele é usado para 
estruturar o modelo de casos de uso, dividindo-o em partes 
menores. 
● Protótipo da Interface do Usuário: pode se manifestar como 
esboços em papel ou figuras, bitmaps feitos com uma ferramenta 
de desenho ou protótipo de executável interativo feito com o apoio 
de uma ferramenta de programação visual. 
● Encenação (ou Storyboard) de caso de uso: é uma descrição 
lógica e conceitual de como um caso de uso é fornecido pela 
interface do usuário, incluindo a interação necessária entre os 
atores e o sistema. 
 
 
 
 
 
 
 
7. Modelagem dos requisitos utilizando diagramas UML 
 
65
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 tem 
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. É 
essencial descrever os requisitos do usuário em uma linguagem em que 
os não-especialistas possam compreender. 
 
7.1 Diagrama de Casos de Uso 
Os diagramas de Casos de Uso são importantes para visualizar, 
especificar e documentar o comportamento de um elemento do sistema. 
Esses diagramas fazem com que sistemas, subsistemas e classes 
fiquem acessíveis e compreensíveis, por apresentarem uma visão 
externa sobre como esses elementos podem ser utilizados no contexto. 
O diagrama de caso de uso compartilha as mesmas propriedades 
comuns a todos os demais diagramas – um nome e um conteúdo gráfico 
que são uma projeção em um modelo. O que diferencia um diagrama de 
caso de uso dos outros tipos de diagramas são seus componentes e 
relacionamentos. 
 
7.1.1 Componentes 
 
● Caso de Uso: é uma descrição de um conjunto de sequências de 
ações que um sistema executa para produzir um resultado de valor 
observável por um ator. É representado graficamente por uma 
elipse, conforme ilustrado na Figura 2.9. Todo caso de uso deve 
ter um nome que o diferencie dos demais casos de uso. Pode ter 
um nome simples (nome sozinho) ou um nome de caminho (com 
nome do caso de uso e do pacote onde se encontra). Tipicamente 
um caso de uso é definido exibindo o nome simples. 
 
66
 
 
Figura 2.9 – Representação de um caso de uso com nome simples e nome de 
caminho (Fonte: BOOCH et. al.,2000). 
 
● Ator: representa um conjunto de papéis que os usuários 
desempenham quando interagem com esses casos de uso. 
Geralmente representa o papel que um ser humano, um dispositivo 
de hardware ou outro sistema desempenha com o sistema. Os 
atores são representados como figuras esquematizadas, conforme 
ilustrado na Figura 2.10. 
 
Figura 2.10 – Representação de atores (Fonte: BOOCH at. al., 2000). 
 
7.1.2 Organização (Relacionamentos) 
 
● Associação: Conecta atores aos casos de uso. A associação entre 
67
o ator e um caso de uso indica a comunicação entre eles, cada um 
com a possibilidade de enviar e receber mensagens. A Figura 2.11 
ilustra o contexto de um sistema com associações. 
 
 
Figura 2.11 – Modelagem do contexto de um sistema (Fonte: BOOCH at. al.,2000). 
 
● Generalização: é semelhante à generalização existente entre as 
classes. Significa que o caso de uso filho herda o comportamento e 
o significado do caso de uso pai; o filho deverá acrescentar ou 
sobrescrever o comportamento de seu pai e o filho poderá ser 
substituído em qualquer local no qual o pai apareça (ambos 
poderão ser instâncias concretas). A generalização é representada 
como uma linha cheia direcionada com uma seta aberta, 
exatamente como na generalização entre classes. 
● Inclusão: o caso de uso incorpora explicitamente o comportamento 
de outro caso de uso em uma localização especificada na base. O 
caso de uso incluído nunca permanece isolado, mas é apenas 
instanciado como parte de alguma base maior que o inclui. O 
68
relacionamento de inclusão evita a descrição do mesmo fluxo de 
evento várias vezes, incluindo o comportamento comum em um 
caso de uso próprio (o caso de uso incluído em um caso de uso 
básico). É um exemplo de delegação e pode ser representado 
como uma dependência, estereotipada como include. 
● Extensão: um relacionamento estendido entre casos de uso 
significa que o caso de uso incorpora implicitamente o 
comportamento de um outro caso de uso em um local especificado 
indiretamente pelo caso de uso estendido. O caso de uso base 
poderá permanecer isolado, mas, sob certas condições, seu 
comportamento poderá ser estendido pelo comportamento de um 
outro caso de uso. O relacionamento estendido é utilizado para a 
modelagem da parte de um caso de uso que o usuário poderá 
considerar como um comportamento opcional do sistema. O 
relacionamento estendido é representado como uma dependência, 
estereotipada como extend. A Figura 2.12 ilustra casos de uso com 
relacionamentos de Generalização, Inclusão e Extensão. 
 
Figura 2.12 – Exemplos de Generalização, Inclusão e Extensão (Fonte: BOOCH et. 
al., 2000). 
 
69
7.1.3 Modelagem do comportamento de um elemento 
A modelagem do comportamento de um elemento será a situação 
mais comum em que os casos serão aplicados, seja esse elemento o 
sistema como um todo, um subsistema ou uma classe. Ao fazer a 
modelagem do comportamento desses elementos, é importante que 
vocêfocalize o que o elemento faz e não como faz. 
Para fazer a modelagem do comportamento de um elemento: 
● Identifique os atores que interagem com o elemento. Candidatos a 
atores incluem grupos que exigem determinado comportamento 
para a realização de suas tarefas ou que são necessários direta ou 
indiretamente para a realização de funções do elemento. 
● Organize os atores, identificando papeis gerais e mais 
especializados. 
● Para cada ator, considere as formas primárias em que o ator 
interage com o elemento. Considere, também, as interações que 
alteram o estado do elemento ou seu ambiente ou que envolvam 
uma resposta a algum evento. 
● Considere, também, as formas excepcionais em que cada ator 
interage com o elemento. 
● Organize esses comportamentos como casos de uso, aplicando 
relacionamentos de inclusão e estendidos com a finalidade de 
fazer a fatoração do comportamento comum e diferenciar o 
comportamento excepcional. 
Por exemplo, um sistema de vendas e varejo interage com os 
clientes que incluem e acompanham os pedidos. Por sua vez, o sistema 
remeterá os pedidos e cobrará dos clientes. Conforme mostra a Figura 
2.13, é possível fazer a modelagem do comportamento de um sistema 
como esse, declarando-os esses comportamentos como casos de uso 
(Place order, Track order, Ship order e Bill customer). Tanto o 
comportamento comum (Validade customer) quanto as variantes (Ship 
70
partial order) podem ser identificados. Para cada um desses casos de 
uso podemos incluir uma especificação do comportamento, por meio de 
um texto, máquina de estados ou interações. 
 
Figura 2.13 - Modelagem do comportamento de um elemento (Fonte: BOOCH et. 
al., 2000). 
 
7.1.4 Recomendações para diagramação de Casos de Uso 
Ao fazer a modelagem de casos de uso na UML, todos os casos 
deverão representar algum comportamento distinto e identificável do 
sistema ou de parte do sistema. Um caso de uso bem estruturado: 
● Nomeia um comportamento do sistema ou de parte do sistema, 
que seja único, identificável e razoavelmente atômico. 
● Faz a identificação do comportamento comum, obtendo esse 
comportamento a partir de outros casos de uso que ele inclui. 
● Faz a identificação das variantes, aplicando esse comportamento a 
outros casos de uso que o estendem. 
● Descreve o fluxo de eventos de maneira suficientemente clara para 
que alguém de fora seja capaz de compreendê-lo com facilidade. 
71
● É descrito por um conjunto mínimo de cenários que especificam a 
semântica e variante do caso de uso. 
 
Ao definir um caso de uso na UML: 
● Mostre somente os casos de uso que são importantes para a 
compreensão do comportamento do sistema ou de parte em 
seu contexto. 
● Mostre somente os atores que estão relacionados com esses 
casos de uso. 
À medida em que os modelos crescem, perceberemos que muitos 
casos de uso tendem a se reunir em grupos relacionados conceitual e 
semanticamente. Na UML, podemos utilizar os pacotes para fazer a 
modelagem desses agrupamentos. O diagrama de pacotes será 
comentado a seguir. 
 
7.2 Diagrama de Pacotes 
Os pacotes são utilizados para organizar os elementos de 
modelagem em conjuntos maiores que possam ser manipulados como 
grupos. É possível controlar a visibilidade desses elementos, permitindo 
que alguns itens fiquem visíveis fora do pacote, enquanto outros ficarão 
ocultos. Os pacotes também podem ser empregados para apresentar 
diferentes visões da arquitetura do sistema. Eles podem agrupar 
qualquer elemento: classes, outros pacotes, casos de uso, etc. 
Os pacotes bem estruturados agrupam elementos que estão 
próximos semanticamente e que tendem a se modificar em conjunto. 
Portanto, os pacotes bem estruturados são fracamente acoplados em 
forte coesão, com acesso altamente controlado ao conteúdo do pacote. 
A UML oferece uma representação gráfica para os pacotes com 
uma notação que permite a visualização de grupos de elementos que 
podem se manipulados como um todo e de uma forma que permite 
72
controlar a respectiva visibilidade e o acesso aos elementos individuais. 
O nome do pacote pode ser colocado na “orelha” da pasta se o pacote 
mostrar membros internos ou, se não for o caso, na pasta principal, 
conforme ilustrado na Figura 2.14. 
 
 
Figura 2.14 – Visibilidade do diagrama de pacotes (Fonte: BOOCH et. al., 2000). 
 
É comum mostrar a dependência (acoplamento) entre pacotes, de 
modo que os desenvolvedores possam ver o acoplamento em larga 
escala do sistema. A linha de dependência UML é utilizada para isso, 
uma linha tracejada em que a seta aponta para o pacote dependente, 
conforme ilustrado na Figura 2.15. 
 
 
Figura 2.15 – Generalização entre Pacotes (Fonte: BOOCH et. al., 2000). 
 
73
 
7.2.1 Recomendações para diagramação de Pacotes 
Ao fazer a modelagem de pacotes na UML, lembre-se de que eles 
existem somente para ajudar a organizar os elementos de seu modelo. 
Caso haja abstrações manifestadas como objetos no sistema real, não 
utilize pacotes. Em seu lugar, use elementos de modelagem como as 
classes ou componentes. Um pacote bem estruturado: 
● É coeso, fornecendo uma clara fronteira para um conjunto de 
elementos relacionados. 
● É fracamente acoplado, exportando somente os elementos que 
outros pacotes realmente precisam enxergar e importando apenas 
os elementos necessários e suficientes para os elementos do 
pacote fazerem suas tarefas. 
● Não contém muitos aninhamentos, por haver limites para a 
compreensão humana de estruturas com muitos aninhamentos. 
● Tem um conjunto equilibrado de conteúdo; em relação uns com os 
outros em um sistema, os pacotes não deverão ser muito grandes 
(divida-os, se necessário) nem muito pequenos (combine 
elementos que sejam manipulados como um grupo). 
Ao definir um pacote na UML: 
● Use a forma simples de ícone de pacote, a menos que seja 
necessário revelar o conteúdo desse pacote explicitamente. 
● Ao revelar o conteúdo do pacote, mostre somente os elementos 
necessários para a compreensão do significado do pacote no 
contexto. 
● Principalmente se estiver usando pacotes para fazer a modelagem 
de itens sob um gerenciamento de configuração, revele os valores 
de etiquetas associados com a versão. 
 
7.3 Diagrama de atividades 
74
Os diagramas de atividades são empregados para fazer a 
modelagem de aspectos dinâmicos do sistema. Na maior parte, isso 
envolve a modelagem das etapas sequenciais (e possivelmente 
concorrentes) em um processo computacional. Com um diagrama de 
atividade, podemos também fazer a modelagem do fluxo de um objeto, 
à medida que ele passa de um estado para outro em pontos diferentes 
do fluxo de controle. Os diagramas de atividades poderão permanecer 
isolados para visualizar, especificar, construir e documentar a dinâmica 
de uma sociedade de objetos, ou poderão ser utilizados para fazer a 
modelagem do fluxo de controle de uma operação. Enquanto os 
diagramas de interação (de sequências e colaboração) dão ênfase ao 
fluxo de controle de um objeto para outro, os diagramas de atividades 
dão ênfase ao fluxo de controle de uma atividade para outra. Uma 
atividade é uma execução não atômica em andamentoem uma máquina 
de estados. As atividades acabam resultando em alguma ação, formada 
pelas computações atômicas executáveis que resultam em uma mudança 
de estado do sistema ou o retorno de um valor. 
Um diagrama de atividades é essencialmente um fluxograma que 
dá ênfase à atividade que ocorre ao longo do tempo, conforme ilustrado 
na Figura 2.16. Podemos considerar um diagrama de atividade com um 
diagrama de interação cujo interior é revelado. Um diagrama de 
interação observa os objetos que passam mensagens; um diagrama de 
atividades observa as operações passadas entre os objetos. A diferença 
semântica é sutil, mas resulta em formas distintas de se observar o 
mundo. 
 
75
 
Figura 2.16 – Diagrama de Atividades (Fonte: BOOCH et. al., 2000). 
 
Os diagramas de atividades costumam conter: 
● Estados de atividade e estados de ação 
● Transições 
● Objetos 
 
7.3.1 Recomendações para diagramação de atividades. Um 
diagrama de atividade bem estruturado: 
● Está voltado para comunicar um aspecto da dinâmica do sistema. 
● Contém somente os elementos essenciais para a compreensão 
desse aspecto. 
● Oferece detalhes consistentes com seu nível de abstração; você 
expõe somente os adornos essenciais à compreensão. 
● Não é tão minimalista que informe mal o leitor sobre a semântica 
importante. 
 
76
Ao definir um diagrama de atividade: 
● Dê-lhe um nome capaz de comunicar seu propósito. 
● Inicie com a modelagem do fluxo primário. Inclua ramificações, 
concorrências e fluxos de objetos como considerações secundárias, 
possivelmente em diagramas separados. 
● Distribua seus elementos de forma a minimizar o cruzamento de 
linhas. 
● Use notas e cores como indicações visuais com a finalidade de 
chamar a atenção para as características importantes de seu 
diagrama. 
É útil diferenciar os requisitos funcionais dos não-funcionais no 
documento de requisitos. Na prática, isso é difícil de ser feito. Se os 
requisitos não-funcionais forem definidos separadamente dos funcionais, 
às vezes será difícil identificar o relacionamento entre eles. Se eles 
forem definidos com os requisitos funcionais, pode haver dificuldade em 
separar as considerações funcionais e as não-funcionais e identificar os 
requisitos relacionados ao sistema como um todo. 
 
8. Ferramentas para modelagem de requisitos 
As ferramentas de engenharia de requisitos apoiam a obtenção, 
modelagem, gestão e validação de requisitos. Em geral, essas 
ferramentas constroem uma variedade de modelos gráficos (UML, por 
exemplo) que representam os aspectos informacional, funcional e 
comportamental de um sistema. Esses modelos formam a base para 
todas as outras atividades do processo de software. 
Uma lista abrangente de ferramentas de engenharia de requisitos 
pode ser encontrada em 
http://www.systemguid.com/guildsite/robs/retools.html. Outras 
ferramentas são: 
● EasyRM: constrói um dicionário / glossário específico para o 
77
projeto contendo descrições e atributos detalhados dos requisitos. 
● OnYourMarkPro: constrói um banco de dados de requisitos, 
estabelece relacionamentos entre os requisitos e permite aos 
usuários analisar o relacionamento entre os requisitos e permite 
aos usuários analisar o relacionamento entre requisitos e 
cronogramas / custos. 
● Rational RequisitePro: permite aos usuários construir um banco de 
dados de requisitos, representar os relacionamentos entre os 
requisitos e organizar, priorizar e rastrear requisitos. 
● RTM: é uma ferramenta de descrição e rastreamento de requisitos 
que apóia também certos aspectos do controle de modificações e 
gestão de testes. 
 
Deve-se notar que muitas tarefas de gestão de requisitos podem 
ser realizadas usando uma simples planilha ou um pequeno sistema de 
banco de dados. 
Em se tratando de Casos de Uso, as ferramentas objetivam 
auxiliar no desenvolvimento de casos de uso fornecendo gabaritos 
automáticos e mecanismos para avaliar a clareza e a consistência. 
Em geral, as ferramentas de casos de uso fornecem gabaritos de 
preenchimento de espaços para criar casos de uso efetivos. A maioria 
das funcionalidades do caso de uso está embutida em um conjunto de 
funções mais amplas de engenharia de requisitos. Algumas das 
ferramentas representativas para o desenvolvimento de casos de uso 
são: 
● Clear Requirement Workbench, que fornece suporte automatizado 
para a criação e avaliação de casos de uso bem como uma 
variedade de outras funções de engenharia de requisitos. 
● Objects by design: uma fonte de ferramentas UML 
(www.objectsbydesign.com/tools/umtools_byCompany.html) 
78
http://www.google.com/url?q=http%3A%2F%2Fwww.objectsbydesign.com%2Ftools%2Fumtools_byCompany.html&sa=D&sntz=1&usg=AFQjCNGK_mFWwa96CfZuJYZfxsAk7_sskQ
fornece links abrangentes para ferramentas desse tipo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PARTE B - CONCEITOS COMPLEMENTARES 
79
 
1. Definição de requisitos e Especificação de requisitos 
 
É importante distinguirmos de maneira clara esses dois conceitos, 
os quais muitas vezes podem nos levar a pensar se tratar da mesma 
atividade ou artefato. 
A Definição de Requisitos envolve uma listagem completa de tudo 
que o cliente ou usuário deseja que o sistema realize, com a descrição 
dos requisitos em linguagem natural, clara e compreensível, nos termos 
do cliente. 
A Especificação de Requisitos redefine cada requisito listado na 
Definição de Requisitos em termos técnicos apropriados, por meio de 
linguagem ou notação informal ou formal. Cada requisito listado na 
Definição de Requisitos deve corresponder a um ou mais requisitos da 
Especificação de Requisitos. 
 
2. Problemas comuns na definição de requisitos 
Vários problemas podem surgir quando os requisitos são redigidos 
em um documento com texto em linguagem natural: 
● Falta de clareza: a imprecisão no uso da linguagem pode tornar 
dificultosa tanto a leitura do documento quanto sua compreensão. 
● Confusão de requisitos: requisitos funcionais e não-funcionais, 
metas de sistema e informações de projeto podem não estar 
claramente diferenciados. 
● Fusão de requisitos: pode haver situações em que diferentes 
requisitos são expressos juntos como um único requisito. 
● A compreensão da linguagem natural depende do uso das mesmas 
palavras para os mesmos conceitos pelos leitores e pelos 
elaboradores da especificação. Isso pode resultar em mal 
80
entendidos devido à ambiguidade da linguagem natural. 
● A especificação em linguagem natural é muito flexível, pois é 
possível dizer a mesma coisa de maneiras diferentes. Cabe ao 
leitor descobrir quando os requisitos são os mesmos e quando são 
distintos. 
● Não existe uma maneira fácil de padronizar os requisitos em 
linguagem natural. Pode ser difícil encontrar requisitos 
relacionados e, para descobrir as consequências de uma mudança, 
pode ser necessário verificar todos os requisitos em vez de apenas 
um grupo de requisitos relacionados. 
As especificações de requisitos escritas em linguagem natural são 
propensas a mal entendidos e muitos requisitos não são descobertos 
até as fases finais do processo de software, tornando a solução 
onerosa. 
 
3. Requisitos de usuárioe Requisitos de sistema 
 
Os requisitos de usuário de um sistema devem descrever os 
requisitos funcionais e não funcionais, de modo que eles sejam 
compreensíveis pelos usuários do sistema que não possuem 
conhecimento técnico detalhado. Eles devem especificar apenas o 
comportamento externo do sistema e evitar, sempre que possível, 
características de projeto do sistema. Consequentemente, na elicitação 
de requisitos de usuário não se deve utilizar jargões de software, 
notações estruturadas ou formais ou descrever os requisitos por meio da 
implementação do sistema. Deve-se utilizar a linguagem simples, com 
tabelas e formulários simples e diagramas intuitivos. 
Os requisitos de sistema são versões expandidas dos requisitos 
de usuários usados pelos engenheiros de software como ponto de 
81
partida para o projeto do sistema. Eles adicionam detalhes e explicam 
como os requisitos de usuário devem ser fornecidos pelo sistema. 
Podem ser usados como parte do contrato para a implementação do 
sistema e devem, portanto, ser uma especificação completa e 
consistente de todo o sistema. 
De forma ideal, os requisitos de sistema devem simplesmente 
descrever o comportamento externo do sistema e suas restrições 
operacionais. Eles não devem estar relacionados a como o sistema pode 
ser projetado ou implementado. Entretanto, para especificar 
completamente um sistema de software complexo no nível de 
detalhamento necessário, é impossível, na prática, excluir todas as 
informações de projeto. 
A compreensão tanto das necessidades do cliente ou usuário 
quanto das características do sistema não é, por si só, suficiente para 
comunicar exatamente ao desenvolvedor o que o sistema deve fazer. É 
preciso um nível adicional de especificidade que traduza estas 
necessidades e características em especificações que se possa projetar, 
implementar e testar, determinando a conformidade do sistema. E para 
se alcançar este nível de especificidade é necessário haver negociação 
envolvendo os requisitos funcionais e não funcionais do sistema. 
Apesar da dissociação entre requisitos de usuários e de sistemas 
possuir alguma relevância acadêmica, em termos práticos esta divisão 
não é importante. Neste conteúdo, a abordagem única sem distinção 
envolvendo os dois tipos de requisitos é considerada a mais didática 
para o aluno. 
 
 
 
 
82
 
Referências 
 
SOMMERVILLE, I. Engenharia de software. 8.ed. São Paulo: Pearson 
Addison-Wesley, 2007. 
 
PRESSMAN, R. S. Engenharia de Software. São Paulo: McGraw-Hill, 
2006. 
 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – Guia do usuário. Rio 
de Janeiro: Editora Campus, 2000. 
 
KRUCHTEN, P. Introdução ao RUP – Rational Unified Process. Rio de 
Janeiro : Editora Ciência Moderna, 2003. 
 
Rational Unified Process: Disciplinas. Fundação da Universidade Federal 
do Paraná (FUNPAR). Setembro, 2013. Disponível em: 
http://www.funpar.ufpr.br:8080/rup/process/workflow/ovu_core.htm 
 
 
84
http://www.google.com/url?q=http%3A%2F%2Fwww.funpar.ufpr.br%3A8080%2Frup%2Fprocess%2Fworkflow%2Fovu_core.htm&sa=D&sntz=1&usg=AFQjCNGuRVp3UUOJXLAQz82q1cHh-UVsKQ