Análise e especificação de requisitos

Prévia do material em texto

ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Definição de universo de informações 
 
A especificação de requisitos deve incluir não somente as 
especificações do domínio do problema, mas também qualquer 
tipo de informação que descreva o contexto do sistema. 
 
Esse contexto é conhecido como universo de informações, que é 
a realidade circunstanciada pelo conjunto de objetivos definidos 
pelos que demandam o software, e inclui todas as fontes de 
informação e todos os stakeholders. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Definição de domínio do problema 
 
•  O domínio do problema é o domínio de atuação do software e 
inclui todos os elementos que interagem com ele. 
•  O domínio do problema é, portanto, o ambiente de atuação do 
software. Neste ambiente principiam as atividades da engenharia 
de software, a definição das necessidades do software. 
•  É tarefa dos engenheiros de requisitos entender o problema, na 
cultura e linguagem dos usuários, e definir um sistema que 
atenda às suas necessidades. Para tal, o engenheiro de requisitos 
deve descobrir e estabelecer o universo de informações, de onde 
obtém os recursos na tarefa de elucidação do problema. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Definição do domínio da solução 
•  No domínio da solução é enfocada a definição da solução aos 
problemas dos usuários. 
•  Os desenvolvedores do software aplicam seus conhecimentos em busca 
da especificação do sistema a ser desenvolvido. 
•  Envolve as características da solução e os requisitos do sistema. 
•  Uma característica é definida como um serviço que o sistema provê 
para cumprir uma ou mais necessidades dos stakeholders. 
•  Uma vez estabelecido o conjunto de características com a concordância 
dos stakeholders, deve-se definir os requisitos mais específicos que serão 
necessários impor a solução. 
•  Requisitos são propriedades que um sistema de software deve ter. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Requisitos 
 
•  Funcionais – representam os comportamentos que um programa ou sistema 
deve apresentar diante de certas ações de seus usuários. 
•  Não-funcionais – quantificam determinados aspectos do comportamento. 
(Ex: tempo de resposta, tempo médio entre falhas, etc.). 
 
Especificações dos requisitos: 
 
•  Explícitos – são aqueles descritos em um documento que arrola os requisitos 
de um produto, ou seja, a especificação de requisitos. 
•  Normativos – são aqueles que decorrem de lei, regulamentos e outros tipos 
de normas a que o produto deve obedecer. 
•  Implícitos – são expectativas dos clientes e usuários, que são cobradas por 
esses, embora não documentadas. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Processo de Aquisição e Especificação de Requisitos 
Elicitação (Levantamento) de Requisitos – Fontes 
–  Stakeholders 
•  Clientes 
•  Usuários 
•  Desenvolvedores 
–  Documentos 
–  Livros 
–  Sistemas de software (específico da organização ou software 
comercial) 
Levantamento de requisitos – Técnicas 
–  Levantamento orientado a pontos de vista 
–  Cenários 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Levantamento orientado a pontos de vista 
•  Normalmente, há diferentes tipos de usuário final e, em função disso, 
diferentes pontos de vista. 
•  Os pontos de vista podem ser organizados de forma hierárquica, como por 
exemplo: 
Todos os pontos de vista 
Cliente Pessoal 
do banco 
Caixa Gerente Engenheiro 
Não-titular 
da conta 
Titular 
da conta 
Serviços 
 
Consultar saldo 
Retirar dinheiro 
Serviços 
 
Pedir cheques 
Enviar mensagem 
Executar transação 
da lista 
Pedir extrato 
Transferir fundos 
Referência: 
 
Atributos: 
 
 
Eventos: 
 
 
 
Serviços: 
 
 
Subpontos de vista: 
Cliente 
 
Número da conta PIN 
Início da transação 
 
Selecionar serviço 
Cancelar transação 
Encerrar transação 
 
Retirada de dinheiro 
Consulta de saldo 
 
Titular da conta 
Não-titular da conta 
Referência: 
 
Razão: 
 
 
 
Especificações: 
 
 
 
 
 
 
 
Pontos de vista: 
 
Requisitos não 
funcionais: 
 
 
Provedor: 
Retirada de dinheiro 
 
Melhorar serviço do cliente e 
reduzir trabalho com papel 
 
 
Usuários escolhem o serviço 
pressionando o botão de retirada 
de dinheiro. Em seguida, 
informam a quantia solicitada. A 
operação é confirmada e, se o 
saldo permitir, o dinheiro é 
entregue. 
 
Cliente 
 
Entregar o dinheiro um minuto 
após ser confirmada e quantia. 
 
Preenchido posteriormente 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Levantamento orientado a pontos de vista (continuação) 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Cenários 
 
•  Cada cenário aborda um ou um pequeno número de possíveis interações. 
•  O cenário geralmente começa com um esboço da interação e, durante o 
levantamento de requisitos, são acrescentados detalhes para criar uma 
distribuição completa dessa interação. 
•  O cenário pode incluir: 
•  uma descrição de estado do sistema no início do cenário; 
•  uma descrição do fluxo normal de eventos no cenário; 
•  uma distribuição do que pode sair errado e de como lidar com isso; 
•  informações sobre outras atividades que possam estar em andamento ao 
mesmo tempo; 
•  uma descrição do estado do sistema no final do cenário. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Métodos de Coleta de Requisitos 
 
Algumas técnicas das ciências sociais, como psicologia e sociologia, têm 
sido estudadas e utilizadas nesta atividade, que envolve fatores 
comportamentais e de relacionamento humano. 
 
Entre os métodos mais comuns estão: 
 
•  análise de documentos; 
•  entrevistas (tutoriais, estruturadas, não-estruturadas, semi-estruturadas); 
•  reuniões (Participatory Design, Joint Application Design e 
Brainstorming); 
•  observações; 
•  etnografia. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
 
Análise de documentos 
 
•  A análise de documentos é uma técnica usualmente aplicada na 
qual explora-se o conhecimento escrito encontrado no universo de 
informações. 
•  A análise dos documentos permite um contato com o vocabulário 
utilizado no domínio do problema e auxilia na construção do 
glossário de termos especializados, que tem por objetivo definir os 
objetos e equalizar o conhecimento dos stakeholders. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Técnicas de entrevistas 
 
•  Entrevista é uma técnica de interação entre entrevistado (especialista do conhecimento) e 
entrevistador (engenheiro de requisitos) buscando revelar conceitos, objetos e a organização do 
domínio do problema, além de buscar soluções ou projeções de soluções que comporão o 
domínio da solução. 
•  Entrevistas tutoriais - o entrevistado fica no comando, praticamente lecionando sobre um 
determinado assunto. 
•  Entrevistas informais (não estruturadas) - o entrevistador age espontaneamente, perguntando 
ao entrevistado sem obedecer a nenhuma organização. Esse tipo de entrevista oferece 
flexibilidade ao entrevistador e, normalmente, é utilizado no início do processo de elicitação. 
•  Entrevistas estruturadas - são preparadas pelo entrevistador, que define previamente o 
andamento do procedimento de aquisição de conhecimento. 
•  Entrevistas semi-estruturadas – são entrevistas que misturam as características das entrevistas 
estruturadas e das entrevistas não estruturadas. 
•  Um fator importante a ser considerado nas entrevistas é o registro das informações coletadas, 
que pode ser realizado através de anotações ou gravações de áudio ou vídeo. O material 
produzido deve ser organizado e serve como base para a preparação da próxima entrevista. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOSTécnicas de reuniões 
Reunião - Permite uma interação mais natural entre os participantes e que 
podem oferecer múltiplas visões sobre a questão abordada. 
• Joint Application Design, Participatory Design e Brainstorming são 
metodologias de reuniões que enfatizam a participação coletiva na elicitação 
de requisitos. 
•  Joint Application Design (JAD) - Baseia-se em sessões estruturadas e 
disciplinadas, onde os envolvidos reúnem-se para desenvolver juntos o 
sistema de software. Em linhas gerais, essas sessões possuem uma agenda 
detalhada, recursos visuais para auxiliar a exposição de idéias, um 
moderador e um relator que registra as especificações de acordo comum 
entre os membros do grupo. O produto final é um documento que contém 
definições do software. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Técnicas de reuniões (continuação) 
• Participatory Design (PD) é uma abordagem que concentra-se mais fortemente 
no envolvimento dos usuários, em relação ao Joint Application Design, por 
facilitar o processo de aprendizado entre desenvolvedores e usuários através de 
experiências conjuntas em situações de trabalho simuladas. Em linhas gerais, 
os usuários são introduzidos no ambiente dos desenvolvedores, conhecendo 
possibilidades técnicas e, da mesma maneira, os desenvolvedores colaboram com 
os usuários em suas tarefas. Ocorre um aprendizado mútuo que vem a contribuir 
no processo de definição dos requisitos. 
• Braistorming - A filosofia básica do brainstorming é procurar deixar que venham 
a tona todas as idéias possíveis, sem que estas sofram quaisquer críticas durante o 
processo de criação. Isto diminui os bloqueios, e permite que as idéias fluam 
melhor. Isto faz com que o inconsciente comece a desbloquear parte do raciocínio 
não-lógico que estava bloqueado e, quando bem aplicado, seja um poderoso 
instrumento de trabalho. Nesta reunião, a característica principal é a total ausência 
de crítica e o julgamento adiado. As idéias que surgirem serão anotadas, por mais 
loucas que possam parecer, e nunca sofrerão críticas na hora em que forem 
formuladas. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Técnica de observação 
 
•  Observação é uma técnica na qual o engenheiro de requisitos 
procura ter uma posição sobre o domínio do problema, observando 
seus elementos e comportamentos. 
•  Visa obter um entendimento inicial sobre o contexto em estudo. 
•  As observações consistem em observar alguém no momento da 
realização de suas tarefas rotineiras no ambiente real. 
•  O observador procura familiarizar-se com o domínio do problema 
e elicitar as informações necessárias para o seu entendimento. 
•  A aquisição desse conhecimento pode ocorrer com interrupção ou 
não das atividades do observador. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Etnografia 
•  Outra técnica que pode ser aplicada de forma complementar com o intento 
de permitir uma visão mais completa e ajustada do domínio do problema é a 
etnografia. 
•  Etnografia é a coleta direta, e o mais minuciosa possível, dos fenômenos 
observados, por uma impregnação duradoura e contínua e um processo que 
se realiza por aproximações sucessivas. 
•  É originária da antropologia, em observações de práticas das sociedades. 
•  No contexto da engenharia de requisitos, é uma técnica que busca revelar 
informações sobre a estrutura, organização e práticas do domínio do 
problema. 
•  A etnografia, segundo conclusão do projeto realizado, pode levar a 
obtenção de requisitos fechados à prática corrente, o conhecimento tácito. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Validação de Requisitos 
 
A validação de requisitos se ocupa em mostrar que os requisitos realmente definem o 
sistema que o cliente deseja. 
 
Principais verificações de requisitos: 
 
•  Verificações de validade – O sistema deve conciliar as necessidades de todos os 
seus usuários. 
•  Verificações de consistência – Os requisitos em um documento não devem ser 
conflitantes, ou seja, não devem existir restrições contraditórias. 
•  Verificações de completeza – O documento de requisitos deve incluir requisitos que 
definam todas as funções e restrições exigidas pelo usuário do sistema. 
•  Verificações de realismo – Um conjunto de verificações deve ser projetado para 
mostrar que o sistema entregue cumpre com seus requisitos. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Validação de Requisitos (continuação) 
 
Técnicas de validação de requisitos: 
 
•  Revisões de requisitos – É um processo manual, que envolve muitos 
leitores, tanto do pessoal do cliente como do fornecedor, que verifica o 
documento de requisitos a fim de detectar anomalias ou omissões. 
•  Prototipação – É fornecido um modelo do sistema para que o usuário 
possa verificar se o sistema atenderá às suas necessidades. 
•  Análise automatizada da consistência - Utilização de ferramenta CASE 
para fazer a de consistência dos requisitos. 
Registro dos requisitos 
 
1.  Missão do Produto 
2.  Limites do Produto 
3.  Lista de requisitos funcionais 
•  Nome e descrição do requisito 
•  Identificação do ator 
•  Necessidades e Benefícios 
•  Estabilidade 
•  Prioridade 
4.  Descrição dos atores 
5.  Regras de Negócio 
6.  Lista de requisitos não funcionais 
7.  Lista dos requisitos de persistência 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
1. Missão do Produto 
 
Descrever os objetivos do produto que deverá ser desenvolvido no projeto. De 
preferência, usar um único parágrafo que sintetize a missão a ser desempenhada 
pelo produto, ou seja, que valor o produto acrescenta para o cliente e os usuários. 
 
A declaração de missão deve cumprir os seguintes objetivos: 
 
•  delimitar as responsabilidades do produto; 
•  delimitar o escopo do produto; 
•  sintetizar o comprometimento entre cliente e fornecedor. 
 
Exemplo: 
 
O produto Merci 1.0 visa a oferecer apoio informatizado ao controle de vendas, 
de estoque, de compra e de fornecedores da mercearia Pereira & Pereira. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
2. Limites do Produto 
 
Deve-se determinar o que o produto não fará. Isso evita falsas expectativas 
por parte dos clientes e usuários e podem ressaltar funções e atributos que 
serão implementados por outros componentes de um sistema maior, ou em 
versões futuras desse produto. 
 
Exemplo: 
 
1.  O sistema não fará vendas parceladas e só receberá pagamentos em 
dinheiro ou cheque. 
2.  O backup e a recuperação das bases de dados do sistema ficam a cargo da 
administração, não sendo providos pelo sistema. 
3.  O sistema não terá ajuda on-line. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
3. Lista de requisitos funcionais – Nome e descrição do requisito 
 
Os requisitos funcionais definem as ações fundamentais através das quais o 
produto aceita e processa as entradas especificadas, gerando as respectivas 
saídas. 
 
Exemplo: 
Número Requisito Descrição 
1 Manter mercadoria Realizar o cadastro (inclusão, alteração, exclusão e consulta dos 
dados de uma mercadoria. 
2 Manter pedido de compra Realizar o cadastro (inclusão, alteração, exclusão e consulta dos 
dados de umpedido de compra. 
3 Abrir caixa Dar início às operações do caixa. 
4 Fechar caixa Encerrar as operações do caixa. 
3. Lista de requisitos funcionais – Identificação dos atores 
 
Na terminologia da UML, qualquer elemento externo que interage com o sistema é 
denominado ator. Note que um ator corresponde a um papel representado em relação ao 
sistema. 
 
Critérios para identificação dos atores: 
 
•  quem está interessado em certo requisito; 
•  quem se beneficiará diretamente do produto; 
•  quem usará informação do produto; 
•  quem fornecerá informação ao produto; 
•  quem dará suporte e manutençãoao produto; 
•  quais os recursos externos usados pelo produto; 
•  quais os papéis desempenhados por cada usuário; 
•  quais os grupos de usuários que desempenham o mesmo papel; 
•  quais os sistemas legados com os quais o produto deve interagir; 
•  o tempo, quando os casos de uso são disparados periodicamente, de forma automática. 
 
Exemplo: Caixa, Atendente, Sistema Financeiro, Setor de Cadastro, etc. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
3. Lista de requisitos funcionais – Identificação dos atores (continuação) 
Os atores podem ser classificados em: 
Ator Primário 
•  É aquele que inicia uma seqüência de interações de um caso de uso; 
•  É um agente externo para o qual o caso de uso traz benefício direto; 
•  As funcionalidades principais do sistema são definidas tendo em mente os 
objetivos dos atores primários. 
 
Ator Secundário 
•  É aquele que supervisiona, opera, mantém ou auxilia na utilização do sistema; 
•  Existem apenas para que os atores primários possam utilizar o sistema. 
 
Exemplo-1: Considere um programa para navegar na Internet (browser). Para que o 
usuário (ator primário) requisite uma página ao programa, um outro ator 
(secundário) está envolvido: o Servidor Web. 
 
Exemplo-2: Quando um cliente precisa da ajuda do vendedor para registrar suas 
compras no sistema, o cliente é o ator primário e o vendedor o ator secundário. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
3. Lista de requisitos funcionais – Nome e descrição do requisito 
 
Os requisitos funcionais definem as ações fundamentais através das quais o 
produto aceita e processa as entradas especificadas, gerando as respectivas 
saídas. 
 
Exemplo: 
Número Requisito Descrição Ator 
1 Manter mercadoria Realizar o cadastro (inclusão, alteração, exclusão 
e consulta dos dados de mercadorias. 
Gerente de Compras 
2 Manter fornecedor Realizar o cadastro (inclusão, alteração, exclusão 
e consulta dos dados de fornecedores. 
Gerente de Compras 
3 Manter pedido de compra Controlar os pedidos de compra feitos aos 
fornecedores. 
Gerente de Compras 
4 Abrir caixa Dar início às operações do caixa. Caixa 
5 Fechar caixa Encerrar as operações do caixa. Caixa 
3. Lista de requisitos funcionais – Necessidades e Benefícios 
 
Deve-se identificar as necessidades que os requisitos atenderão e os benefícios que eles 
podem proporcionar. O levantamento dos benefícios é necessário para determinar se o 
valor dele compensará o investimento no projeto. 
 
Exemplo: 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Núm. Requisito Ator Necessidades Benefícios 
1 Manter 
mercadoria 
Gerente de 
Compras 
Identificação das mercadorias. 
Fornecer dados para outras funções 
Agilidade na compra e venda de mercadorias. 
Melhoria do conhecimento dos produtos 
comercializados. 
2 Manter 
fornecedor 
Gerente de 
Compras 
Atualizar os dados dos fornecedores. 
Atualizr a lista de produtos comercializados 
por cada fornecedor. 
Fornecer dados para outras funções 
Controle dos dados de fornecedores. 
Conhecimento do mercado de fornecedores. 
Avaliação da qualidade de fornecimento. 
3 Manter 
pedido de 
compra 
Gerente de 
Compras 
Registro dos pedidos de compra. 
Controle de cancelamento de pedidos. 
Acompanhamento do prazo de entrega. 
Registro da recepção das mercadorias. 
Fornecer dados para outras funções 
Apoio na avaliação das melhores condições de preço e 
menores prazos de entrega. 
Eliminação da duplicidade de pedidos. 
Identificação de mercadorias não entregues. 
4 Abrir caixa Caixa Colocar o caixa no modo de venda, 
informando o seu valor de abertura. 
Ter controle dos valores de cada abertura do caixa. 
Diminuição de erros na prestação de contas. 
5 Fechar caixa Caixa Encerrar as operações do caixa, apurando o 
total das transações realizadas. 
Ter controle da movimentação do período. 
Diminuição de erros na prestação de contas. 
3. Lista de requisitos funcionais – Prioridade 
 
Representa o valor atribuído ao requisito, pelo cliente, em função do(s) 
benefício(s) que ele lhe proporcionará. 
 
A prioridade é classificada em: 
 
•  Essencial – O requisito é fundamental. Sua falta acarretará o não 
atendimento das necessidades do cliente. 
•  Desejável – A existência do requisito contribuirá para o atendimento das 
necessidades do cliente, mas a sua falta é aceitável. 
•  Opcional – A existência do requisito está condicionada a sobra de 
recursos, prazo, etc. Sua falta não prejudica o atendimento das 
necessidades do cliente. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
3. Lista de requisitos funcionais – Estabilidade 
 
Representa a probabilidade do requisito ser alterado no decorrer do 
projeto, com base na experiência de projetos correlatos. 
 
A estabilidade é classificada em: 
 
•  Alta – O requisito tem pouca chance de mudar no decorrer do 
projeto. 
•  Média – A probabilidade do requisito mudar no decorrer do projeto 
estaria em torno de 50% de chance. 
•  Baixa – O requisito tem grande chance de mudar no decorrer do 
projeto. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Exemplo: Lista de requisitos funcionais – Prioridade e Estabilidade 
 
Número Requisito Funcional Ator Prioridade Estabilidade 
1 
Manter mercadoria 
 
Gerente de Compras Essencial Média 
2 
Manter fornecedor 
 
Gerente de Compras 
Essencial 
 
Baixa 
3 Manter pedido de compra Gerente de Compras Opcional Baixa 
4 Abrir caixa Caixa Essencial Média 
5 Fechar caixa Caixa Essencial Média 
4. Descrição dos Atores 
 
Para cada ator deve-se incluir uma descrição sucinta das responsabilidades do 
respectivo papel. 
 
Deve-se também identificar as características mais importantes do respectivo 
grupo de usuários. 
 
Exemplo de descrição dos atores: 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Ator Descrição 
Caixa Funcionário operador comercial do caixa. 
Gerente de Compras Funcionário responsável pela gestão dos cadastros de 
mercadorias e fornecedores, e pela emissão e acompanhamento 
de pedidos de compra. 
Sistema Financeiro Sistema de gestão financeira que recebe os detalhes financeiros 
das transações diárias, para utilização posterior pela 
administração financeira da mercearia. 
5. Regras de Negócio 
 
Segundo o Business Rules Group (BRG) pode-se definir regra de negócio segundo 
dois aspectos: 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Sistemas de informação Negócio 
Regra de negócio é “uma sentença 
que define ou restringe algum aspecto 
do negócio (...) sua intenção é manter 
a estrutura do negócio, ou controlar ou 
influenciar algum aspecto do 
negócio”. Nesse contexto, as regras de 
negócio dizem respeito aos “dados 
que podem ser cadastrados em um 
sistema de informação”. 
Regras de negócio são “diretivas que 
visam influenciar ou guiar o 
comportamento do negócio. Tais 
diretivas existem como suporte a 
políticas de negócio, formuladas em 
resposta a riscos, ameaças ou 
oportunidades”. 
 
 
5. Regras de Negócio (continuação) 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
5. Regras de Negócio (continuação) 
 
Classificação das Regras de Negócio: 
 Regras de Rejeição (Rejector): são regras que rejeitam um evento porque ele conduz o 
sistema a um estado que não é permitido. As restrições de integridade em bancos de 
dados são exemplos desse tipo de regra. 
 Ex1: “Uma conta não pode ter saldo negativo”. 
 Ex2: “Um time não pode ter mais que 11 jogadores em campo”. 
 Regras de Projeção (Projector): são regras que projetam o evento em outros eventos 
alterando os fluxos de execução. 
 Ex1: “Ao criar um cliente, deve ser criada uma nova conta para ele”. 
 Ex2: “Seuma conta tiver saldo maior que 5.000, enviar folheto sobre investimentos”. 
 Regras de Produção (Productor): são regras que não respondem a eventos, elas apenas 
definem informações do negócio. 
 Ex1: “Saldo é igual a crédito menos débito” 
 Ex2: “Uma conta é “Ouro Especial” se seu saldo atual é superior a 30.000 e seu 
 médio saldo médio é superior a 20.000.” 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
5. Regras de Negócio (continuação) 
 
Exemplo: 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Nome Condição para realização do pedido de compra 
(RN01) 
Descrição Somente serão aceitos pedidos de compra para 
fornecedores que tenham menos do que 3 
ocorrências de entrega fora do prazo. 
Obs: Esta regra de negócio deverá ser aplicada no requisito Incluir 
pedido de compra. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Requisitos 
Não 
Funcionais 
Requisitos 
do produto 
Requisitos 
organizacionais 
Requisitos 
externos 
Requisitos 
éticos 
Requisitos de 
interoperabilidade 
Requisitos 
legais 
Requisitos 
de segurança 
Requisitos 
de 
privacidade 
Requisitos 
de 
implementação 
Requisitos 
de espaço 
Requisitos 
de 
desempenho 
Requisitos 
de eficiência 
Requisitos 
de facilidade 
de uso 
Requisitos 
de 
confiabilidade 
Requisitos 
de 
portabilidade 
Requisitos 
de entrega 
Requisitos 
de padrões 
6. Lista de requisitos não funcionais 
 
Os requisitos não funcionais 
podem ser classificados segundo 
a seguinte estrutura hierárquica 
 
6. Lista de requisitos não funcionais (continuação) 
 
Exemplos: 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
RNF01 O tempo de totalização da Operação de Venda (isto é, o 
intervalo de tempo entre qualquer alteração nos itens de venda 
e a exibição do total a pagar) não pode ser maior do que 2 
segundos. 
RNF02 O tempo para realização de qualquer operação de pesquisa de 
usuários, mercadorias, fornecedores ou pedidos de compra não 
pode ser maior do que 10 segundos. 
RNF03 O leiaute do relatório Nota Fiscal deve ser previamente 
aprovado pela Secretaria de Receita. 
RNF04 O Merci deverá ser desenhado de forma que possa ser 
expandido para mais de um terminal. 
7. Lista dos Requisitos de Persistência 
Requisitos de persistência são representados através das classes de entidade, 
com seus atributos e operações. 
Possíveis Notações para uma Classe na UML 
Nome da Classe Nome da classe Nome da classe Nome da classe 
Lista de atributos Lista de operações Lista de atributos 
Lista de operações 
Atributos – descrição dos dados armazenados pelos objetos de uma classe. 
Cada atributo de uma classe está associado a um conjunto de valores que esse 
atributo pode assumir. 
 
Operações – correspondem à descrição das ações que os objetos de uma classe 
sabem realizar. O nome de uma operação, normalmente, contém um verbo e 
um complemento e termina com um par de parênteses. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
7. Lista dos Requisitos de Persistência (continuação) 
Técnica para identificação das classes - procurar substantivos 
existentes nos fluxos dos casos de uso. 
•  eliminar aspectos de implementação e conceitos irrelevantes quanto à 
missão do produto; 
•  resolver ambigüidades da linguagem; 
•  considerar também locuções verbais, desde que equivalentes a 
substantivos; 
•  considerar que substantivos podem não resultar em classes, mas em 
objetos, relacionamentos ou atributos de classes; 
•  permanecer no nível lógico, não incluindo detalhes da implementação; 
•  permanecer dentro do escopo do produto, evitando classes não conexas 
com a missão. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
7. Lista dos Requisitos de Persistência (continuação) 
Especificação das classes 
•  Deve-se escolher nomes significativos, isto é, substantivo no singular; 
•  Deve-se evitar nomes vagos, assim como nomes reservados da própria 
metodologia (classe, tipo, etc.); 
•  Deve-se utilizar nomes que façam parte do domínio do negócio. 
Ao longo da análise, a especificação das classes será completada com 
outros aspectos relevantes, como: 
•  Operações necessárias para cumprir as responsabilidades; 
•  Atributos necessários para cumprir as responsabilidades. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
7. Lista dos Requisitos de Persistência (continuação) 
 
Nomenclatura para o diagrama de classes na UML 
 
•  Para identificadores – quaisquer espaços em branco e preposições do 
nome são removidos. 
•  Para nomes de classes e nomes de relacionamentos – começar 
com letra maiúscula. Exemplo: Cliente, ItemPedido, Pedido, etc. 
•  Para nomes de atributos e nomes de operações – escrever a 
primeira palavra do nome em minúsculas e as palavras 
subseqüentes, sem espaço em entre elas, começando com a letra 
em maiúsculo. No entanto, siglas são mantidas inalteradas. 
Exemplo: quantidade, precoUnitario, CPF, dataNascimento, etc. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
7. Lista dos Requisitos de Persistência (continuação) 
Exemplos de classes 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Nome da classe Descrição da classe Atributos da classe 
Fornecedor representa os fornecedores da 
empresa 
nome 
CNPJ 
contato 
telefone 
PedidoCompra representa os pedidos feitos pelos 
aos fornecedores da empresa 
dataPedido 
status 
Obs: A associação existente entre Fornecedor e PedidoCompra (um fornecedor 
fornece muitos pedidos e um pedido é fornecido por somente um fornecedor) 
só ficará evidente após a construção do diagrama de classes. Não pode existir 
nenhum atributo na classe PedidoCompra, nem na classe Fornecedor, que 
tente representar essa associação. 
7. Lista dos Requisitos de Persistência (continuação) 
Diagrama de Objetos (ou Diagrama de Instâncias) 
 
•  Podem ser vistos como instâncias de diagramas de classes, da mesma 
forma que objetos são instâncias de classes; 
•  Assim como diagramas de classes, diagramas de objetos são estruturas 
estáticas. Um diagrama de objetos exibe uma “fotografia” do sistema em 
um certo momento; 
•  Cada objeto é representado por um retângulo com dois compartimentos. 
•  No compartimento superior, a identificação do objeto é exibida 
•  No compartimento inferior, quando utilizado, exibe uma lista de 
pares da forma nome do atributo: valor do atributo; 
•  A identificação do onjeto deve ser sempre sublinhada. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
7. Lista dos Requisitos de Persistência (continuação) 
Exemplo de Diagrama de Objetos: 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 
Pedido1:Pedido 
 
data = 13/09/2002 
status = “A” 
Item1:ItemPedido 
 
quantidade = 6 
Item2:ItemPedido 
 
quantidade = 20 
Item3:ItemPedido 
 
quantidade = 1 
Mercadoria20:Mercadoria 
 
nome = “caderno M” 
descrição = “caderno em espiral tamanho médio” 
Mercadoria12:Mercadoria 
 
nome = “caneta esf” 
descrição = “caneta esferográfica 5 mm” 
Mercadoria07:Mercadoria 
 
nome = “esquadro” 
descrição = “esquadro de acrílico 20 cm 
Fornecedor10:Fornecedor 
 
nome = “Distribuidora XYZ” 
CNPJ = 30502231000129 
contato = “Maria” 
telefone = 2126657588 
Referências Bibliográficas 
 
Rocco, Giovanni Ely. Engenharia de Requisitos. Universidade de Caxias do Sul - Centro de 
Ciências Exatas e Tecnologia - Departamento de Informática. 
 
Alenquer , Pablo Lopes . Regras de Negócio para Análise em Ambientes OLAP. Disponível 
em http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Pablo/TesePablo.pdf 
Acesso em 02/11/2005. 
 
Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro: 
Elsevier, 2002. 
Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões.Rio de Janeiro: LTC, 2003. 
 
Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte III. 
Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003. 
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS