COMPILADO Requisitos de Sistemas COMPLETO AULAS RESUMOS REVISAO PROVAS AV1 AV2 AV3 SaibaMais EXTRAS Graduacao Programacao Sistemas Dados Software Gestao Tecnologia da Informacao

Prévia do material em texto

REQUISITOS DE SISTEMAS
PROF. Horacio Ribeiro
Aula 1- requisitos de sistemas
REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Conteúdo Programático desta aula
▪ Fracasso de projetos por falta de 
especificações
▪ Objetivos e requisitos
▪ Tipos de requisitos
▪ Requisitos funcionais e não funcionais
NOME DA AULA – AULA1
NOME DA DISCIPLINA
FRACASSOS DE PROJETOS 
E OS MOTIVOS ???
Situação Desenvolvimento de Software
Managing Software Requirements: 
A Use Case Approach, Second Edition, 2003
31% dos projetos são cancelados antes de serem 
completados
52,7% dos projetos custam 189% de sua estimativa 
inicial
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Causas mais importantes
O PRINCIPAL PROBLEMA É A COMUNICAÇÃO ENTRE OS 
ENVOLVIDOS NO PROJETO
Falta de comunicação do usuário - 13%
Requisitos /Especificações incompletas - 12%
Requisitos /Especificações que mudam - 12%
NOME DA AULA – AULA1
NOME DA DISCIPLINA
CUSTOS DE MODIFICAÇÕES
DEVE-SE EVITAR ERROS E FALTA DE DEFINIÇÕES
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Uma condição ou capacidade necessitada por um usuário para 
resolver um problema ou alcançar um objetivo; 
Requisitos do Sistema:
NOME DA AULA – AULA1
NOME DA DISCIPLINA
a comunicação ocorre ao longo de todo o projeto; 
O PROBLEMA É DE COMUNICAÇÃO
influenciado pelo 
conhecimento dos 
envolvidos
DEFINIÇÃO 
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Mudança nos Requisitos
Mas eu não quero 
me molhar! Como 
vou carregar minha 
pasta ?
Re-projeto
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Entrega do Sistema
NOME DA AULA – AULA1
NOME DA DISCIPLINA
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Explorando o tema
VIDEO DE ANIMAÇÃO
REQ1.AVI
DETERMINAÇÃO DE OBJETIVOS
REQUISITOS
NOME DA AULA – AULA1
NOME DA DISCIPLINA
CARACTERISTICAS DE UM OBJETIVO
-CLARO
-PRECISO
-COMPLETO
-DUAS DIMENSÕES 
NOME DA AULA – AULA1
NOME DA DISCIPLINA
OBJETIVOS GRANDES
-DECOMPOSTOS EM SUB OBJETIVOS
- METAS REALIZAVEIS
-COMPLETUDE DA TAREFA
-DEVE-SE COMEMORAR CADA 
OBJETIVO ATINGIDO
NOME DA AULA – AULA1
NOME DA DISCIPLINA
CADA OBJETIVO OU SUBOBJETIVO
TEM UM CONJUNTO DE REQUISITOS
NOME DA AULA – AULA1
NOME DA DISCIPLINA
OS REQUISITOS SÃO ORGANIZADOS EM GRUPOS.
CADA GRUPO DE REQUISITOS É ATENDIDO POR UMA 
FUNCIONALIDADE NO SISTEMA.
PARA CADA FUNCIONALIDADE DEVE-SE FAZER UMA ESPECIFICAÇÃO
OBJETIVO
REQUISITOS
FUNCIONALI
DADES
ESPECIFICA
ÇÃO
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Aplicando o conhecimento
OBJETIVO:
UM SISTEMA PARA APOIAR O DEPARTAMENTO DE VENDAS NAS 
SEGUINTES FUNÇÕES:
-ATENDER O CLIENTE
- EMITIR O TOTAL DE COMISSOES DE VENDAS.
-NECESSIDADES DO USUARIO:
- TER ACESSO AOS PEDIDOS DE UM CLIENTE.
- TER ACESSO AOS DADOS DO CLIENTE
--TER ACESSO AS INFORMAÇÕES DE PAGAMENTO
-FUNCIONALIDADES:
- -UM CADASTRO DE CLIENTES COM AS FUNÇOES.....
--UM CADASTRO DE VENDAS COM AS FUNÇOES....
-- UM CADASTRO DE PAGAMENTOS REALIZADOS....
-.......
NOME DA AULA – AULA1
NOME DA DISCIPLINA
ESPECIFICAÇÃO DE OBJETIVOS
TEXTO BREVE ATÉ CINCO LINHAS APROXIMADAMENTE
-NÃO DESCREVE COMO É O SISTEMA e sim o que ele faz.
-DEVE-SE DEFINIR FUNÇOES QUE COMPOEM O OBJETIVO
EXEMPLO:
O SISTEMA DEVERÁ APOIAR O DEPARTAMENTO DE VENDAS 
CARACTERIZADO PELAS FUNÇOES DE:
-CALCULAR COMISSOES DE VENDEDORES
-DISPONIBILIZAR OS DADOS CADASTRAIS DE UM CLIENTE
-DISPONIBLIZAR A CARTEIRA DE VENDAS DE UM VENDEDOR
-GERAR OS RELATÓRIOS DE PEDIDOS ENTREGUES.
atenção 
Não pode ter termos técnicos
Tipos de requisitos
Analise de requisitos
A análise de requisitos envolve os processos de descobrir, 
analisar, documentar e verificar as necessidades de clientes e 
sistemas no desenvolvimento de software garantindo que o 
sistema desenvolvido atenda de forma correta as necessidades 
especificadas.
Requisitos de Sistemas: 
Definem, detalhadamente, as funções, os serviços e as 
restrições operacionais do sistema. O documento de 
requisitos do sistema deve ser preciso. Ele deve definir 
exatamente o que será implementado.
Requisitos de Usuários:
São declarações, em linguagem natural, com diagramas, de 
quais serviços são esperados do sistema e as restrições sobre 
as quais ele deve operar
Um conjunto de requisitos pode ser definido como uma condição 
ou capacidade necessárias que o software deve possuir 
(1) para que o usuário possa resolver um problema ou atingir um 
objetivo ou
(2) para atender as necessidades ou restrições da organização ou 
dos outros componentes do sistema.
(def. Wikipédia)
Requisitos funcionais
Requisitos funcionais
Os requisitos funcionais são descrições das diversas necessidades de
clientes e usuários. Eles definem a funcionalidade desejada do
software.
São exemplos de requisitos funcionais:
•"o software deve possibilitar o cálculo dos gastos diários, semanais,
mensais e anuais com pessoal".
•"o software deve emitir relatórios de compras a cada quinze dias“
•"os usuários devem poder obter o número de aprovações,
reprovações e trancamentos em todas as disciplinas por um
determinado período de tempo.
A especificação de um requisito funcional deve determinar o
que se espera que o software faça, sem a preocupação
de como ele faz.
Requisitos não funcionais
são as características técnicas de um sistema como
manutenibilidade, usabilidade, desempenho, custos e várias
outras.
São requisitos de caráter técnico e não são pedidos pelo usuário
ou cliente.
Exemplos de requisitos não-funcionais:
•"a base de dados deve ser protegida para acesso apenas de
usuários autorizados".
•"o tempo de resposta do sistema não deve ultrapassar 30
segundo".
•"o software deve ser operacionalizado no sistema Linux“
•"o tempo de desenvolvimento não deve ultrapassar seis meses".
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Requisitos funcionais e não funcionais
Necessidades dos usuários
E clientes
Necessidades técnicas
Requisitos
Do
sistema
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Existe um conjunto de métricas definidas pelo IFPUG 
para para especificar as medidas e avaliações dos 
requisitos não funcionais (14 características do 
software)
O produto RUP para desenvolvimento de software 
tem um módulo para levantamento, gestão e 
acompanhamento da implantação de um requisito
NOME DA AULA – AULA1
NOME DA DISCIPLINA
NA PROXIMA AULA
VAMOS APRENDER SOBRE REQUISITOS DE DOMINIOS
E REQUISITOS DE SISTEMA
VAMOS APRENDER OS DIVERSOS TIPOS DE 
REQUISITOS NÃO FUNCIONAIS
VAMOS APRENDER COMO DOCUMENTAR UM 
REQUISITO
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Contactos e material complementar e exercícios
www.espacodoprofessor.com
Professor: Horacio ribeiro
Modulo Estácio 2012.1
Senha 222222
http://www.espacodoprofessor.com/
REQUISITOS DE SISTEMAS
PROF. Horacio Ribeiro
Aula 2- Requisitos de Dominio e de usuário 
REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Conteúdo Programático desta aula
•Tipos de requisitos não funcionais
•Propriedades dos requisitos
• Características de requisitos de domínio
•O que são requisitos de usuários
• técnicas de especificação e documentação de 
requisitos de sistemas
NOME DA AULA – AULA1
NOME DA DISCIPLINA
•Objetivos (processos de negócio) 
•Provem a base para os sub-objetivos
•Mostram :
•O ciclo de vida da seqüência de objetivos relacionados
•O contexto no qual os objetivos do usuário operam
•Abrangem vários sub-objetivos de usuário
•Tem a ver com a organização ( as intenções, o problema ) 
do usuário
•Pode ser um sub-objetivo de outro objetivo estratégico
NOME DA AULA – AULA1
NOME DA DISCIPLINA
O sistema também tem Objetivos correspondentes
O uso do sistema faz com que os Objetivos possam ser 
alcançados ou falhem
Objetivos podem ser divididos em sub-objetivos
Normalmente existem hierarquias de objetivos, onde se vê 
Níveis dos Objetivos
Hierarquias e Navies de 
Objetivos
NOME DA AULA – AULA1
NOME DA DISCIPLINATipos de Requisitos
Funcionais
o que o sistema faz para satisfazer as necessidades de seu 
usuário
Não Funcionais
Atributos técnicos que um sistema deve possuir para atender 
os requisitos funcionais
Restrições
Restrições que o sistema deve satisfazer, e que afetam 
igualmente os dois primeiros tipos.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Requisitos não Funcionais (alguns)
•Usabilidade (facilidade de uso pelos usuários)
•Confiança ( freqüência e resistência a falhas, capacidade de 
recuperação, predibilidade, precisão )
•Desempenho (capacidade, taxas em relação ao tempo, de 
precisão: velocidade, disponibilidade, tempo de resposta, uso de 
memória )
•Suporte ( capacidade manter o sistema atualizado, em termos 
de testes, manutenção, versões )
•Aparência ( estética, visual, design gráfico )
•Operacional ( o ambiente no qual será usado; ambiente 
operacional, condições do usuário, sistemas relacionados)
•Segurança ( confidencialidade, integridade, disponibilidade )
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Propriedades dos requisitos (1)
•Validade: 
requisitos identificados individualmente (isto é, junto a especificação resulta 
da análise dos requisitos identificados junto das diversas partes interessadas 
envolvidas. 
•Completude(atender todo tipo de usuário):
todas as funcionalidades pretendidas devem fazer parte da especificação do 
sistema
-Verificar em três dimensões:
- por tipo de ator
- por tipo de serviço
- por tipo de ambiente
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Propriedades dos requisitos (1)
•Consistência: 
não devem existir conflitos entre os requisitos identificados.
Deve-se também validar os requisitos em duas dimensões:
- atender aos aspectos legais
- atender aos aspectos culturais
•Compreensibilidade / Ambiguidade: 
os requisitos devem poder ser compreendidos de forma inequívoca pelas 
partes interessadas.
•.Realismo: 
dadas as restrições do projeto (tecnológicas, financeiras e temporais) o 
sistema especificado tem de ser implementável.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Propriedades dos requisitos (2)
•Verificabilidade: 
de forma a evitar futuras discordâncias quanto à concretização dos 
requisitos especificados, estes devem ser descritos de modo a 
que seja possível verificar se foram ou não concretizados, isto é, 
se o sistema final corresponde à especificação inicial.
Definir condições de testabilidade e verificação do requisito.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Propriedades dos requisitos (3)
•Rastreabilidade: (é fundamental: saber quem pediu o que)
a origem dos requisitos, em relação ao cliente, deve estar 
claramente identificada. Entre outros motivos, isto é importante 
para facilitar a gestão futura dos requisitos.
Requisito 
1usuário
usuário
usuário
Funcionalid
ade 1.1
Modulo 
1.1.1 Programa 
1.1.1.1
Requisitos de dominio e de usuário
Requisítos de Usuários:
São declarações, em linguagem formal ( evitar linguagem 
natural) com diagramas, de quais serviços são esperados do 
sistema e as restrições sobre as quais ele deve operar
Define O QUE O SISTEMA FAZ.
Pode-se definir uma sintaxe da forma:
<temporaL> o sistema <ação do sistema>
Temporal: uma expressão que denota um instante no tempo.
exemplo: sempre que solicitado o sistema.....
as 14 horas do dia 30 o sistema....
ao identificar a chamada telefônica o sistema
Exemplo:
Sempre que solicitado(temporal) o sistema apresenta uma 
tela com o produto e a quantidade em estoque
Para cada requisito de usuário encontrado, deve-se 
estabelecer o conjunto de exceções.
Sintaxe:
O sistema não <ação> <condição>
O sistema não apresentará o produto e a quantidade se o 
produto for importado.
Para o sistema fazer o seu objetivo: O QUE
Precisa que algumas premissas sejam atendidas.
Para identificar estas premissas temos a sintaxe:
<temporal><ator><ação no sistema>
<temporal>: uma expressão que denote um instante de tempo.
<ator> um agente externo que atua sobre o sistema
<ação no sistema> : normalmente cadastrar, deletar,...
Exemplo:
Sempre que um novo produto é comprado(temporal)
o gerente de compras
atualiza a tabela de produtos 
informando o nome, características,
quantidade.
exercício
Ache os requisitos necessários para implementar a necessidade 
abaixo, use a sintaxe apresentada. 
Regra de negócio:
RN1: “não se empresta livros quando existir apenas um volume”
“emprestar um livro para um estudante previamente cadastrado”
Requisitos de usuário
Devem descrever requisitos funcionais e não-funcionais de tal 
forma que sejam entendíveis pelos usuários do sistema que 
não têm conhecimento técnico detalhado
Requisitos do usuário são definidos usando linguagem 
natural (evitar), tabelas e diagramas
Problemas
- Interpretações da linguagem natural
-- completude e entendimento da tarefa
--participação do usuário
linguagem natural
(problemas relacionados a falta de clareza, confusão de 
requisitos, fusão de requisitos,erros de interpretação por usuários e 
desenvolvedores, etc.). 
Os requisitos do usuário devem ser classificados em:
requisitos obrigatórios: fundamentais para a aceitação do 
sistema
requisitos desejáveis: que devem ser implementados mas não 
comprometem a utilização do sistema
Os requisitos podem ser ainda:
Implantados: que serão ou estão implantados
Adiados: que serão implementados em outras versões
Os requisitos de sistemas precisam ser documentados de forma mais 
especifica e detalhada 
-Diagramas a análise estruturada, essencial, orientada a objetos 
-Usa-se notações para levantamento de requisitos (Notações Gráficas, 
Especificações Matemáticas, Linguagem Natural, etc.) 
-Vamos trabalhar mais estes conceitos e produtos ao longo do curso
formalizar a documentação de requisitos
Nome do Caso de Uso
Descrição
Atores
Objetivo
Fluxo de Eventos
Fluxo Básico
Sub-objetivo 1
Sub-objetivo 2 
.............
Fluxo Alternativo
Pré-condições
Pós-condições
Outras técnicas de levantamento 
-Mapas mentais.
--entrevistas
--documentos
-Encontros estruturados
--linguagens e especificação
--softwares de gerencia de requisitos
--templates (RUP) (praxis)...
Estrutura de documentos do RUP - templates
Mais detalhes: www.espacodoprofessor.com---horacioribeiro--curso de requisitos
http://www.espacodoprofessor.com---horacioribeiro--curso/
Derivados do domínio da aplicação e descrevem características do 
sistema e qualidades que refletem o domínio
Podem ser requisitos funcionais novos, restrições sobre requisitos 
existentes ou computações específicas
Se requisitos de domínio não forem satisfeitos, o sistema pode 
tornar-se não prático
Requisitos de dominio
Problemas com dominio
Entendimento
Requisitos são descritos na linguagem do domínio da 
aplicação
Não é entendido pelos engenheiros de software que vão 
desenvolver a aplicação
Implicitude
Especialistas no domínio entendem a área tão bem que 
não tornam todos os requisitos de domínio explícitos
Propriedade Medida
Velocidade Transações processadas/seg
Tempo de resposta do usuário/evento
Tamanho K bytes
No de chips de RAM
Facilidade de uso Tempo de treinamento
No de quadros de ajuda
Confiabilidade Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Robustez Tempo de reinício após falha
Percentual de eventos causando falhas
Probabilidade de corrupção de dados após 
falha
Portabilidade Percentual de declarações dependentes do 
destino
No de sistemas destino
Métricas de requisitos
Próxima aula
-engenharia de requisitos
-Processo de gestão de requisitos
-Estudo de viabilidade
- Documentação de requisitos
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Contactos e material complementar e exercícios
www.espacodoprofessor.com
Professor: Horacio ribeiro
Modulo Estácio 2012.1
Senha 222222
http://www.espacodoprofessor.com/
REQUISITOS DE SISTEMAS
PROF. Horacio Ribeiro
Aula 3 requisitos – qualidade – engenhariade 
requisitos
REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Conteúdo Programático desta aula
• Influencia dos requisitos na qualidade do sistema
• requisitos de usuário e de sistema
•requisitos funcionais e não funcionais
•Engenharia de requisitos
• Processo de requisitos
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Qualidade de sistemas e os requisitos
conceito da palavra “sistema”,
seqüência de atividades, e conjunto de “coisas” para
atingir um objetivo
soma:
software + hardware + procedimentos
antes de se pensar em questões tecnológicas (ambiente de 
desenvolvimento, linguagens de programação, banco de 
dados a ser utilizado, etc.), é preciso ter a concepção 
correta do que se está sendo solicitado. 
Determinação de objetivos;
determinar necessidades para atingir objetivos.
Sem um levantamento de requisitos adequado, certamente 
o desafio será muito maior!
É preciso conscientizar o profissional de desenvolvimento de 
sistemas sobre as necessidades da especificação e 
documentação correta
NOME DA AULA – AULA1
NOME DA DISCIPLINA
O processo de levantamento de requisito está vinculado 
para garantir qualidade no produto que vamos entregar. 
Para qualquer empresa, ter 
qualidade nos seus processos 
para seu é ter uma estratégia 
competitiva, principalmente 
para aquela que desenvolve 
software.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Adventos de várias transformações no mundo, as
organizações precisam produzir produtos e serviços de
qualidade, não mais como uma estratégia de diferenciação
de mercado, mas como uma condição de subsistência.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
qualidade, Pressman (2006) atribuiu o alcance da qualidade de software 
como uma conseqüência de:
.
•Criar um conjunto de atividades que irão ajudar a garantir que cada 
produto de trabalho da engenharia de software exiba alta qualidade.
•Realizar atividades de segurança da qualidade em cada projeto de 
software.
•Usar métricas para desenvolver estratégias para a melhoria de processo 
de software e, como conseqüência, a qualidade no produto final.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
“Qualidade de software deve ser compreendido e empreendido como um 
processo sistêmico que precisa está presente todas as etapas e artefatos 
produzidos, visando a garantia da conformidade de processos e produtos 
mediante aos requisitos definidos.”
NOME DA AULA – AULA1
NOME DA DISCIPLINA
• não confundir os conceitos e a aplicação dos termos Controle da 
Qualidade e Garantia da Qualidade. 
Garantia da Qualidade Controle da Qualidade
a) Garantia da qualidade garante que o processo é
definido e apropriado.
b) Metodologia e padrões de desenvolvimento são
exemplos de garantia da qualidade.
c) Garantia da qualidade é orientada a processo.
d) Garantia da qualidade é orientada a prevenção.
e) Foco em monitoração e melhoria de processo.
f) As atividades são focadas no inicio das fases no ciclo
de vida de desenvolvimento de software.
g) Garantia da qualidade garante que você está fazendo
as coisas certas e da maneira correta.
a) As atividades de controle da qualidade focam na
descoberta de defeitos em i específicos.
b) Um exemplo de controle da qualidade poderia ser:
"Os requisitos definidos são os requisitos certos?".
c) Controle da qualidade é orientado a produto.
d) Controle da qualidade é orientado a detecção.
e) Inspeções e garantia de que o produto de trabalho
atenda aos requisitos especificados.
f) As atividades são focadas no final das fases no ciclo
de vida de desenvolvimento de software.
g) Controle da qualidade garante que os resultados do
seu trabalho são os esperados conforme requisitos.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
De acordo com o PMBOK (Project Management Body Of Knowledge)
do PMI (Project Management Institute), na versão 2004, os processos
de gerenciamento da qualidade do projeto detêm: :
Os principais processos são:
•Planejamento da Qualidade:
Identificação dos padrões de qualidade relevantes para o projeto e
determinação de como satisfazê-los.
•Garantia da Qualidade:
Aplicação das atividades de qualidade planejadas e sistemáticas para
garantir que o projeto emprega todos os processos necessários para
atender aos requisitos.
•.Controle da Qualidade:
Monitoramento de resultados específicos do projeto a fim de
determinar se eles estão de acordo com os padrões relevantes de
qualidade e identificação de maneiras de eliminar as causas de um
desempenho insatisfatório.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
• alcançar um produto de software de maneira mais assertiva, de 
maneira correta , entrega dentro de um tempo e lugar que 
satisfazem ao cliente, inicia com a identificação dos requisitos. 
•Então devemos primeiramente levantamos as pessoas, os 
processos e recursos que estão envolvidos, e buscar então 
evidenciar suas ações e documentá-las, da maneira mais 
detalhadamente necessária para que não haja dúvidas do(s) 
respectivo(s) comportamento(s).
requisitos.
Requisitos de sistemas e de usuário
Requisítos de Usuários:
Segundo Summerville (2011, pág. 58), precisam ser escritos 
em diferentes níveis de detalhamento para que os diferentes 
leitores possam usá-los de diversas maneiras. (Todo tipo de ator)
Os requisitos classificados por níveis estão vinculado na 
linguagem ou ambiente do teor da especificação para 
determinada finalidade, com o intuito de consegui ser 
entendível, evitando que qualquer anomalia na qualidade da 
informação disposta imponha obstáculos para se alcançar 
plenamente o resultado esperado
Os requisitos de usuário
definem em uma linguagem qualquer o que o sistema deve 
atender, sem se preocupar como vai atender. 
O foco é apontar características que agregam o valor do 
software, sem apontar como isso foi feito. 
É uma espécie de manual do sistema, que aponta suas 
funcionalidades para todos que o venham a ler. 
Exemplos: clientes (contratantes) e usuários finais do sistema.
o usuário define então a rotina de determinada atividade, 
expressando claramente qual a necessidade, de forma que seja 
então criado todo o processo necessário para atender os 
anseios, e conseqüentemente possa atingir plenamente os 
objetivos. 
Notadamente não está se considerando quaisquer tecnologias a 
ser empregada; pelo contrário, deve ser permissiva e sentida a 
flexibilidade, de modo que o usuário possa ter total liberdade 
para sua explanação. 
requisitos de sistema, estes já são especificados para um 
grupo de usuários que detém de uma experiência, seja no 
negócio como na área de tecnologia da informação, nas 
especificidades da empresa.
exemplo: Um jogo com características mínimas
exigidas para que o jogo possa funcionar em um
determinado computador.
As informações ali dispostas são consideradas,
obrigatórias, pois define os componentes e
configurações para que seja possível usufruir das
emoções dos jogos. Portanto, são requisitos do
sistema (Fonte das imagens:
http://froog.com.br/requisitos-de-sistema-need-for-
speed-shift/).
Sommerville (2011, pág. 60), destaca que os requisitos devem 
especificar todos os intentos do cliente, e que sejam de forma 
clara – os quais denominam pelo conceito de completude e 
consistência. 
De maneira geral, os requisitos são classificados em três tipos. 
São eles:
Funcionais;
Não funcionais; e
Interface. (vamos definir)
processo de engenharia de requisitos 
• estudos de viabilidade, 
•Levantamento e documentação
•Elicitação e análise de requisitos,
• validação e 
•gerenciamento de requisitos).
estudo de viabilidade -> documento de analise do 
projeto
elicitação e análise de requisitos -> documento que 
mostra cada forma de registrar ações, telas,...
especificação de requisitos -> especificação 
padronizada de cada requisito
validação de requisitos) - > validação nos aspectos de 
completude e consistência.
Processo de desenvolvimentol dos processos de 
engenharia de requisitos (Especificação de requisitos –
Elicitação de Requisitos e Validação de Requisitos) 
Processo de engenharia(todo processo de engenharia é assim):
Cascata espiral reuso prototipação desenvolvimentos ágeis
Estudo de viabilidade
Todo projeto de software, em sua fase inicial, deve ser submetido 
a uma rápida análise nos seus diversos aspectos
.
O estudo de viabilidade(fundamental) determinará pontos críticos 
do projeto, apresentando diferentes alternativas de soluções
para o problema e, até mesmo, se o projeto será levado adiante 
ou não.
Deve tratar aspectos técnicos\ financeiros
Estudo de viabilidade
Á análise de viabilidade é um documento que serve para 
decisões no projeto
A estrutura básica do documento é composto por uma breve 
descrição sobre a organização, o problema em questão, fontes e 
referências que lhe proporcionaram conhecimento do problema 
(questionários, bibliografia, etc)
E é apresentada mais de uma solução para o problema.
Cada uma, acompanhada de uma breve análise com prós e 
contras.
Ao final do documento, o desenvolvedor, a partir da análise de 
cada uma das soluções por ele propostas, indica qual a mais 
adequada, levando em consideração fatores como custo, tempo 
de desenvolvimento, satisfação dos anseios do cliente, etc.
.
Estudo de viabilidade
O estudo de viabilidade já é um procedimento padrão no 
processo de design, do qual depende todo o restante do projeto.
um estudo de viabilidade ele leva um certo tempo para ser feito e 
consome algumas horas de trabalho. 
Com uma análise prévia, o desenvolvedor terá uma visão mais 
abrangente sobre o problema e poderá cogitar diversas soluções
. Imagine chegar no meio de um projeto, e descobrir que havia 
uma maneira mais fácil e mais eficiente para chegar ao mesmo 
resultado? 
Tendo determinações prévias da solução poderá determinar 
cronograma de entregas e desembolsos.
.
Próxima aula
-Ciclo do processo de engenharia de requisistos e 
suas atividades
-- modelo dos entregáveis
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Contactos e material complementar e exercícios
www.espacodoprofessor.com
Professor: Horacio ribeiro
Modulo Estácio 2012.1
Senha 222222
http://www.espacodoprofessor.com/
REQUISITOS DE SISTEMAS
PROF. Horacio Ribeiro
Aula 4 IDENTIFICAÇÃO DOS STAKEHOLDERS. 
TÉCNICAS DE LEVANTAMENTO DE REQUISITOS
REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Conteúdo Programático desta aula
•Conhecer o conceito de stakeholders.
•Identificar características dos stakeholders.
•Conhecer técnicas de levantamento de requisitos
•Relacionar cenários distintos e as melhores técnicas
de levantamento de requisitos a serem aplicadas
Aula passada: ciclo de vida do processo
estudo de viabilidade -> documento de analise do 
projeto
elicitação e análise de requisitos -> documento que 
mostra cada forma de registrar ações, telas,...
especificação de requisitos -> especificação 
padronizada de cada requisito
validação de requisitos) - > validação nos aspectos de 
completude e consistência.
Estudo de viabilidade
Todo projeto de software, em sua fase inicial, deve ser submetido 
a uma rápida análise nos seus diversos aspectos.
.
É o estudo de viabilidade
estudar pontos críticos do projeto
apresentar diferentes alternativas de soluções para o problema
Verificar opçoes de custo e prazo
.... E decide-se se o projeto será levado adiante ou não.
Deve tratar aspectos técnicos\ financeiros
Estudo de viabilidade
Documento:
- Breve descrição sobre a organização,
- Descrição do problema em questão, fontes e referências que 
proporcionam conhecimento do problema (questionários, 
bibliografia, etc)
- Apresentação de mais de uma solução para o problema.
Cada uma, acompanhada de uma breve análise com prós e 
contras.
- conclusao
a partir da análise de cada uma das soluções propostas, indica 
qual a mais adequada, levando em consideração fatores como 
custo, tempo de desenvolvimento, satisfação dos anseios do 
cliente.
.
conceito de stakeholders. e suas características
Existem indivíduos que estão relacionados direta ou
indiretamente com um software.
Eles nem precisam fazer uso do sistema, mas mesmo assim,
ele é afetado em algum aspecto.
São denominamos stakeholders.
Um requisitos funcional está sempre associado 
a um ou vários stakeholders. 
Nem sempre é uma atividade fácil conseguir 
identificar o que realmente deve ser um requisito 
funcional ou não funcional.
Após identificar os objetivos desejados vamos identificar e
detalhar as pessoas que usam e/ou são afetados pelo sistema
Independente de tecnologia um projeto que atua na área da
engenharia de software contempla a participação direta ou
indireta, ativa ou passiva, de pessoas.
Um tipo de ator (indivíduo) que em algum momento tem algum tipo
de interesse, participação, etc., sobre um determinado software ´é
é chamado de stakeholder.
um entendimento mais amplo do que é um stakeholder,
Em todo em qualquer sistema (computacional ou não), sempre
teremos agentes diretos ou indiretos, que irão compor ou
sofrer com as suas características.
A palavra vem de da seguinte composição:
•Stake: interesse, participação, risco.
•Holder: aquele que possui.
Portanto, todos aqueles que de alguma maneira é afetado pelo 
software, é um stakeholder . 
É correto afirmar que toda a preocupação para o correto 
desenvolvimento de um sistema e demais recursos de infra-estrutura 
tem como objetivo de facilitar o atendimento das responsabilidades 
dos stakeholders.
Ao usarmos a sintaxe de premissa (visto na segunda aula)
<temporal> <agente><ação no sistema>
os agentes são pessoas que irão usar o software
Segundo Summerville (2009), podemos definir da 
seguinte forma:
“Um stakeholder em uma arquitetura de software é 
uma pessoa, grupo ou entidade com um interesse ou 
preocupações sobre a realização da arquitetura.”
Podemos então relacionar os seguintes exemplos e atribuições de 
stakeholders no desenvolvimento de um projeto de sofware::
Gerente de Projeto – Responsável em organizar e conduzir as 
equipes em suas responsabilidades. 
Como gestor, precisa manter harmonia no desenvolvimento do projeto, 
supervisionando a execução das tarefas, observar os processos, 
sustentar e fomentar o equilíbrio entre os stakeholders, etc.
Analista de Sistema – Responsável em analisar quais as 
características o que deverá ter o produto a ser desenvolvido para 
atingir o objetivo final, ou seja, o que o cliente espera. 
Para isso, busca analisar as especificidades inerentes ao determinado 
software.
Programador – São os responsável por escrever as linhas de códigos 
que construirão a identidade lógica do software.
Podemos então relacionar os seguintes exemplos e atribuições de 
stakeholders no desenvolvimento de um projeto de sofware::
(continuação)
Patrocinador – Popularmente é quem “paga a conta”. É aquele que 
libera os recursos, custeia a produção do projeto. Ele será o 
responsável por prover financeiramente a arquitetura necessária para 
o desenvolvimento de software. 
Cliente (usuário) – É aquele que, a partir de uma necessidade, faz a 
encomenda de um software. Portanto, é quem vai usufruir do produto 
a ser entregue; seja ele apenas um ou um grupo de usuários.
Além dos citados tem se muitos outros stakeholders – que
não são tão elementares, mas possuem algum tipo de
interesse.
Por exemplo:
•Poder público
•A comunidade
•Concorrentes
•Fornecedores
•Investidores e acionistas
•As famílias da equipe de projeto
São outras características dos stakeholders:
•São específicos para cada projeto;
•Possuem anseios e objetivos distintos em um projeto;
•São atores fundamentais para detalhamento do que deve ser
desenvolvido.
O envolvimento é fundamental para o êxito de um projeto de
software.
um dos riscos projeto é a ocorrência de uma falha nolevantamento dos stakeholders.
O gerente de projeto deve avaliar as necessidades de todos
os envolvidos;
A conseqüência pode ser:
- um software que não atende aquilo que o cliente esperava, e
de que deverá ser revisto e ajustado posteriormente.
-desgastes de recursos, além da insatisfação daquele que
encomendou o sistema.
Primeiros cuidados:
- o gerente de projeto deve observar bem seus objetivos
-e não procurar stakeholders por todos lados, o que culminará em
um cenário difícil de gerenciar.
-Deve haver limitação no escopo daqueles que afetam e/ou serão
afetados pelo projeto.
-influência dos stakeholders em um projeto de software, suas
relações e inter-dependência na concepção e uso de um
determinado sistema.
Açoes com stakeholders
Com influencia
politica
Sem influencia
politica
Com interesse 
No sistema
Sem interesse 
No sistema
Técnicas para levantamento de 
Requisitos
escrever linhas de códigos não deve ser o foco de
atenção para o projeto de software, o inicio do
projeto de desenvolvimento de software deve ser o
levantamento de requisitos.
E tratar esta atividade como engenharia
Para um navio que não tem rumo qualquer porto serve’
levantamento inicial:
A fonte das informações inerentes as atividades
está com que pratica as atividades atualmente de
forma manual ou automática.
Problema:
-o cliente não estabelece claramente todas as
regras relativas ao negócio;
- quem está sendo contratado desconhece as
especificidades referente ao processo que
atualmente está em execução.
Sommerville (2009) propõe um processo genérico de levantamento e
análise que contém as seguintes atividades:
•Compreensão do domínio: Os analistas devem desenvolver sua
compreensão do domínio da aplicação;
•Coleta de requisitos: É o processo de interagir com os stakeholders
do sistema para descobrir seus requisitos. A compreensão do domínio
se desenvolve mais durante essa atividade;
•Classificação: Essa atividade considera o conjunto não estruturado
dos requisitos e os organiza em grupos coerentes;
Sommerville (2009) propõe um processo genérico de levantamento e
análise que contém as seguintes atividades:
•Resolução de conflitos: Quando múltiplos stakeholders estão
envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por
objetivo solucionar esses conflitos;
•Definição das prioridades: Em qualquer conjunto de requisitos,
alguns serão mais importantes do que outros. Esse estágio envolve
interação com os stakeholders para a definição dos requisitos mais
importantes;
•Verificação de requisitos: Os requisitos são verificados para
descobrir se estão completos e consistentes e se estão em
concordância com o que os stakeholders desejam do sistema.
o problema de não saber especificar corretamente o que o
sistema deverá fazer é muito rotineiro:
(a) de um usuário principal do sistema não saber o que quer que
o sistema faça ou sabe e não consegue/quer transmitir para o
analista;
(b) requisitos identificados, mas que não exprimem a realidade;
(c) não estão em concordância com os requisitos informados por
pessoas diferentes, são constantes na elaboração dos requisitos.
Um stakeholder ou informação errada afetará em perda de tempo
e dinheiro
É preciso aferir e revisar os requisitos.
No levantamento dos requisitos, dois fatores contribuem para o 
baixo grau de satisfação dos usuários:
•Não utilizar uma técnica adequada para extrair os 
requisitos do sistema; 
•Descrever os requisitos do sistema de modo pouco claro, 
com ambigüidades, sem consistência com todos os aspectos 
significativos do sistema proposto.
Algumas técnicas de levantamento de requisitos, detalhando
seu conceito e suas respectivas vantagens e desvantagens:
Etnografia
A etnografia é uma técnica de observação, aonde o analista buscar
uma familiarização do cliente, seus valores, sua história. Ela pode ser
utilizada para compreender os requisitos sociais e organizacionais, que
facilitem compreensão da política organizacional e da sua cultura.
O observador é inserido no ambiente de trabalho. Diariamente são
realizadas anotações das tarefas observadas.
Esta técnica tem por principal objetivo em auxiliar na descoberta de
requisitos de sistema implícitos, que refletem os processos reais, em
vez de os processos formais.
Tem eficácia em atuar na descoberta da maneira como as pessoas
realmente trabalham, além do contexto de integração e colaboração
entre o stakeholder .
Etnografia
ações consideradas importantes que devem ser executados antes,
durante e depois do estudo de observação:
•Antes, é necessário identificar as áreas de usuário a serem
observadas; obter a aprovação das gerências apropriadas para
executar as observações; obter os nomes e funções das pessoas
chave que estão envolvidas no estudo de observação; e explicar a
finalidade do estudo;
•Durante, é necessário familiarizar-se com o local de trabalho que está
sendo observado. é preciso observar os agrupamentos organizacionais;
facilidades manuais e automatizadas; coletar amostras de documentos
e procedimentos usados em cada processo que está sendo observado;
e acumular informações estatísticas a respeito das tarefas, como:
frequência que ocorrem, estimativas de volumes, tempo de duração
para cada pessoa. Observar as exceções;
Etnografia
ações consideradas importantes que devem ser executados antes,
durante e depois do estudo de observação:
•Depois, é necessário documentar as descobertas resultantes das
observações feitas. Consolidar o resultado e rever os resultados com
as pessoas observadas e/ou com seus superiores(CONVERSANDO).
desvantagens
. Consumir bastante tempo, além da possibilidade do analista ser
induzido a erros em suas observações, mediante anomalia no
comportamento dos stakeholders.
. Perda de foco na observação(Não se envolver).
. Perpetuar erros no processo (atividades)
Workshops
Trata-se de uma técnica de elicitação desenvolvida em grupo,
usada em uma reunião estruturada.
São integrantes do grupo que participaram do workshop:
•Equipe de analistas.
•Seleção dos stakeholders mais envolvidos no contexto em que o
sistema atuará.
principal estratégia
acionar o trabalho em equipe. Há um facilitador neutro cujo papel é
conduzir a workshop e promover a discussão entre os vários
mediadores.
As tomadas de decisão são baseadas em processos bem definidos
e com o objetivo de obter um processo de negociação, mediado
pelo facilitador.
Workshops
É dos e com o objetivo de obter um processo de negociação
promovido mediado pelo facilitador.
Uma vez encerrado é gerada uma documentação que reflete os
requisitos e decisões tomadas sobre o sistema.
Fatores de sucesso são:
•A postura do condutor do seminário - mediador e observador;
•Deve possuir dia, hora, local, horário de início e de término;
destacando o assunto a ser debatido e sua documentação.
Entrevistas
A entrevista é tradicionalmente mais simples de utilizar,
produz bons resultados na fase inicial de obtenção de dados.
Organizar a entrevista:
- Os membros da equipe devem ter funçoes : redator,
condutor, revisor....
•O entrevistador dê margem ao entrevistado para expor as
suas idéias.
•Ter um plano de entrevista para que seja mantido o foco no
cerne do assunto principal.
•Evita que a entrevista fique longa, deixando o entrevistado
cansado e não produzindo bons resultados.
Entrevistas
boas práticas de entrevistas:
•Desenvolver um plano geral de entrevistas;
•Certificar-se da autorização para falar com os usuários;
•Planejar a entrevista para fazer uso eficiente do tempo.
Previamente o analista que fará a entrevista deve procurar
está bem contextualizado, sendo mais assertivo e produtivo
O entrevistador deve coletar e estudar todos os dados
pertinentes, como formulários, relatórios, documentos e
outros.
. No término, é necessário validar se o que foi documentado
está de acordo com a necessidade do usuário, que o usuário
não mudou de opinião e que o usuário entendea notação ou
representação gráfica de suas informações.
Entrevistas -termino
exemplos de como aferir a veracidade das informações
levantadas na entrevista:
1 -Faça uma explanação sobre o relacionamento entre o que
está em discussão e as demais partes do sistema;
•Informe do ponto de vista de outros usuários em relação ao
item que foi discutido;
•Descreva informalmente a narrativa do item em que o
analista deseja obter informações;
•O analista deve dizer ao usuário o que acha que ouviu ele
dizer. e solicitar ao entrevistado confirmação do que foi dito.
Questionários
Existem vários tipos de questionários :
• múltipla escolha, 
•lista de verificação 
•questões com espaços em branco. 
quando há diversos grupos de usuários que podem 
estar em diversos locais diferentes do país elaboram-
se pesquisas específicas de acompanhamento com 
usuários selecionados, que a contribuição em potencial 
pareça mais importante, pois não seria prático 
entrevistar todas as pessoas em todos os locais.
Questionários
Etapas
.preparo (fazer um protótipo)
•Identifique todos os destinatários que o receberão.
•Realize a distribuição junto com instruções detalhadas sobre 
seu preenchimento.
•Defina e informe o prazo para devolução do questionário.
•Documente o resultado da análise e consolidação das 
respostas dos participantes. 
•Envie uma cópia com as informações levantadas para o 
participante, como sendo uma forma de agradecimento e 
consideração pelo tempo dedicado a pesquisa.
Brainstorming
Brainstorming é uma técnica para geração de idéias.
Uma idéia preliminar gerada serve como incentivo para que
outras apareçam, sejam concordantes ou não.
Pode ser estabelecida uma ou várias reuniões.
Os participantes devem ser encorajados a dar, e combinar ou
enriquecer as idéias de outros e, para isso, é necessário que
todas as idéias permaneçam visíveis a todos os participantes.
Brainstorming
AS etapas necessárias para conduzir uma sessão de brainstorming
são:
•Seleção dos participantes ou grupo de trabalho:
É aconselhável sempre a presença de pessoas que estejam sempre
bem informadas, sejam de diferentes grupos;
•Prepara a sessão:
Duração e local do encontro, bem como o que será tratado.
•Explicar a técnica e as regras a serem seguidas:
Definir as regras a serem seguidas durante a sessão;
•Gerar ou produzir uma boa quantidade de idéias:
Os participantes são convidados, um por vez, a dar uma única idéia.
Se alguém tiver problema, passa a vez e espera a próxima rodada.
•Analisar as idéias: Revisar a produção de idéias, destacando as mais
valiosas definidas pelo grupo e classificando-as com prioridades.
Prototipagem
Fazer um protótipo para explorar requisitos vinculados a um 
produto que possua aspectos críticos. 
Implementando de maneira mais rápida um pequeno subconjunto 
de funcionalidades deste produto. 
requisitos desenvolver validar
acertar
fim
protótipo é aconselhado para:
1.Estudar as alternativas de interface do usuário;
2.Problemas de comunicação com outros produtos; 
3.A viabilidade de atendimento dos requisitos de desempenho. 
principais benefícios :
reduções dos riscos na construção do sistema, 
Validaçoes de especificaçoes
. 
elementos para o sucesso na elaboração dos protótipos:
1.Seleção do ambiente de prototipagem;
2.Compreender os objetivos do protótipo por parte de todos os 
interessados no projeto;
3.Focar em áreas que estejam com maior dificuldade na 
compreensão; 
4.Rapidez na construção.
JAD (Joint Application Design).
É uma técnica destinada a promover cooperação, entendimento 
e trabalho em grupo entre os usuários desenvolvedores. 
A idéia é criar uma visão compartilhada do produto de software .
Ela ajuda os usuários e desenvolvedores a formular problemas e 
explorar soluções, no escopo do projeto a ser desenvolvido. 
JAD (Joint Application Design).
Possui quatro princípios básicos:
•Dinâmica de grupo: são realizadas reuniões com um líder 
experiente, analista, usuários e gerentes, para despertar a força e 
criatividade dos participantes. O resultado final será a 
determinação dos objetivos e requisitos do sistema;
•Uso de técnicas visuais: para aumentar a comunicação e o 
entendimento;
•Manutenção do processo organizado e racional: o JAD 
emprega a análise top down e atividades bem definidas. 
•Utilização de documentação padrão: preenchida e assinada 
por todos os participantes. Este documento garante a qualidade 
esperada do projeto e promove a confiança dos participantes.
JAD -participantes –
•Líder da sessão: É um facilitador dos encontros. Deve ser competente, 
com bom relacionamento pessoal e qualidades gerenciais de liderança.
•Engenheiro de requisitos: É um participante experiente nas questões 
técnicas, diretamente responsável pela produção dos documentos de 
saída das sessões JAD.
•Executor: É o responsável pelo produto sendo construído. 
•Representantes dos usuários: São pessoas na empresa que terão 
incumbência de utilizar o produto de software.
•Representantes de produtos de software: São pessoas que estão 
familiarizadas com as capacidades dos produtos de software, capazes 
de mediar os usuários na compreensão entre o que é possível e 
razoável no sistema.
•Especialista: é a pessoa que pode fornecer informações detalhadas 
sobre um tópico específico.
Outras técnicas:
-simuladores
-mapas mentais
- Determinação de cenários
-oficinas de requisitos
- Casos de uso
Na próxima aula:
você estudará sobre os assuntos seguintes:
- Documento de Requisitos de Software.
- Composição do Documento de Requisitos de Software.
- Utilidade e validade do Documento de Requisitos de Software.
NOME DA AULA – AULA1
NOME DA DISCIPLINA
Contactos e material complementar e exercícios
www.espacodoprofessor.com
Professor: Horacio ribeiro
Modulo Estácio 2012.1
Senha 222222
http://www.espacodoprofessor.com/
REQUISITOS DE SISTEMAS
PROF. Horacio Ribeiro
Aula 05: DOCUMENTAÇÃO DE REQUISITOS DE 
SOFTWARE
Entrevistas
A entrevista é tradicionalmente mais simples de utilizar,
produz bons resultados na fase inicial de obtenção de dados.
Organizar a entrevista:
- Os membros da equipe devem ter funçoes : redator,
condutor, revisor....
•O entrevistador dê margem ao entrevistado para expor as
suas idéias.
•Ter um plano de entrevista para que seja mantido o foco no
cerne do assunto principal.
•Evita que a entrevista fique longa, deixando o entrevistado
cansado e não produzindo bons resultados.
Entrevistas
boas práticas de entrevistas:
•Desenvolver um plano geral de entrevistas;
•Certificar-se da autorização para falar com os usuários;
•Planejar a entrevista para fazer uso eficiente do tempo.
Previamente o analista que fará a entrevista deve procurar
está bem contextualizado, sendo mais assertivo e produtivo
O entrevistador deve coletar e estudar todos os dados
pertinentes, como formulários, relatórios, documentos e
outros.
. No término, é necessário validar se o que foi documentado
está de acordo com a necessidade do usuário, que o usuário
não mudou de opinião e que o usuário entende a notação ou
representação gráfica de suas informações.
Entrevistas -termino
exemplos de como aferir a veracidade das informações
levantadas na entrevista:
1 -Faça uma explanação sobre o relacionamento entre o que
está em discussão e as demais partes do sistema;
•Informe do ponto de vista de outros usuários em relação ao
item que foi discutido;
•Descreva informalmente a narrativa do item em que o
analista deseja obter informações;
•O analista deve dizer ao usuário o que acha que ouviu ele
dizer. e solicitar ao entrevistado confirmação do que foi dito.
Questionários
Existem vários tipos de questionários :
• múltipla escolha, 
•lista de verificação 
•questões com espaços em branco. 
quando há diversos grupos de usuários que podem 
estar em diversos locais diferentes do país elaboram-
se pesquisas específicas de acompanhamento com 
usuáriosselecionados, que a contribuição em potencial 
pareça mais importante, pois não seria prático 
entrevistar todas as pessoas em todos os locais.
Questionários
Etapas
.preparo (fazer um protótipo)
•Identifique todos os destinatários que o receberão.
•Realize a distribuição junto com instruções detalhadas 
sobre seu preenchimento.
•Defina e informe o prazo para devolução do questionário.
•Documente o resultado da análise e consolidação das 
respostas dos participantes. 
•Envie uma cópia com as informações levantadas para o 
participante, como sendo uma forma de agradecimento e 
consideração pelo tempo dedicado a pesquisa.
Brainstorming
Brainstorming é uma técnica para geração de idéias.
Uma idéia preliminar gerada serve como incentivo para
que outras apareçam, sejam concordantes ou não.
Pode ser estabelecida uma ou várias reuniões.
Os participantes devem ser encorajados a dar, e combinar ou
enriquecer as idéias de outros e, para isso, é necessário que
todas as idéias permaneçam visíveis a todos os participantes.
Brainstorming
AS etapas necessárias para conduzir uma sessão de brainstorming
são:
•Seleção dos participantes ou grupo de trabalho:
É aconselhável sempre a presença de pessoas que estejam sempre
bem informadas, sejam de diferentes grupos;
•Prepara a sessão:
Duração e local do encontro, bem como o que será tratado.
•Explicar a técnica e as regras a serem seguidas:
Definir as regras a serem seguidas durante a sessão;
•Gerar ou produzir uma boa quantidade de idéias:
Os participantes são convidados, um por vez, a dar uma única idéia.
Se alguém tiver problema, passa a vez e espera a próxima rodada.
•Analisar as idéias: Revisar a produção de idéias, destacando as mais
valiosas definidas pelo grupo e classificando-as com prioridades.
Prototipagem
Fazer um protótipo para explorar requisitos vinculados a um 
produto que possua aspectos críticos. 
Implementando de maneira mais rápida um pequeno subconjunto 
de funcionalidades deste produto. 
requisitos desenvolver validar
acertar
fim
protótipo é aconselhado para:
1.Estudar as alternativas de interface do usuário;
2.Problemas de comunicação com outros produtos; 
3.A viabilidade de atendimento dos requisitos de desempenho. 
principais benefícios :
reduções dos riscos na construção do sistema, 
Validaçoes de especificaçoes
. 
elementos para o sucesso na elaboração dos protótipos:
1.Seleção do ambiente de prototipagem;
2.Compreender os objetivos do protótipo por parte de todos os 
interessados no projeto;
3.Focar em áreas que estejam com maior dificuldade na 
compreensão; 
4.Rapidez na construção.
JAD (Joint Application Design).
É uma técnica destinada a promover cooperação, entendimento 
e trabalho em grupo entre os usuários e desenvolvedores. 
A idéia é criar uma visão compartilhada do produto de software .
Ela ajuda os usuários e desenvolvedores a formular problemas e 
explorar soluções, no escopo do projeto a ser desenvolvido. 
JAD (Joint Application Design).
Possui quatro princípios básicos:
•Dinâmica de grupo: são realizadas reuniões com um líder 
experiente, analista, usuários e gerentes, para despertar a força e 
criatividade dos participantes. O resultado final será a 
determinação dos objetivos e requisitos do sistema;
•Uso de técnicas visuais: para aumentar a comunicação e o 
entendimento; datashow, gráficos.
•Manutenção do processo organizado e racional: o JAD 
emprega a análise top down e atividades bem definidas. 
•Utilização de documentação padrão: preenchida e assinada 
por todos os participantes. Este documento garante a qualidade 
esperada do projeto e promove a confiança dos participantes.
JAD -participantes –
•Líder da sessão: É um facilitador dos encontros. Deve ser competente, 
com bom relacionamento pessoal e qualidades gerenciais de liderança.
•Engenheiro de requisitos: É um participante experiente nas questões 
técnicas, diretamente responsável pela produção dos documentos de 
saída das sessões JAD.
•Executor: É o responsável pelo produto sendo construído. 
•Representantes dos usuários: São pessoas na empresa que terão 
incumbência de utilizar o produto de software.
•Representantes de produtos de software: São pessoas que estão 
familiarizadas com as capacidades dos produtos de software, capazes 
de mediar os usuários na compreensão entre o que é possível e 
razoável no sistema.
•Especialista: é a pessoa que pode fornecer informações detalhadas 
sobre um tópico específico.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Conteúdo Programático desta aula
•Aprender sobre o documento de requisitos. 
•Reconhecer a importância da elaboração do documento de 
requisitos.
•Verificar os pontos prioritários e a atenção na redação de um 
documento. 
•Compreender quem são os envolvidos no processo de criação de 
um documento de requisitos.
•Verificar a composição de um documento de requisitos.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
O requisito precisa ser documentado de uma forma
organizada.
O documento de requisitos é um documento formal utilizado
para comunicar os requisitos aos clientes, engenheiros e
gestores, além de outros envolvidos que necessitem acessar
este documento.
É importante conhecer o que deve conter e a quem e como
será utilizado, que permita uma visão geral do sistema,
necessidades de negócio suportadas pelo sistema
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Utilização:
A documentação de requisitos:
-É importante para o desenvolvimento de software,
-é muito útil na análise e seleção de fornecedores de
aplicações comerciais já desenvolvidas.
-- é fundamental para a manutenção do sistema
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
A documentação registra todo o conteúdo extraído no levantamento de
requisitos.
Retrata as especificações a serem seguidas no desenvolvimento de
software.
Este é o que denominamos que documento de requisitos de software.
Existem “templates “ para desenvolver estes documentos.
Modelos de PRAXIS _RUP _ PROPRIETÁRIOS
Documentação de requisitos
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
De acordo com Sommerville (2009),
“o documento de requisitos de software, às vezes chamado de
Especificação de Requisitos de Software (SRS – do inglês Software
Requerimento Specification), é uma declaração oficial do que os
desenvolvedores do sistema devem implementar”.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
requisitos de sistemas tem total ligação com o fator qualidade
para o desenvolvimento de software.
o documento de requisitos trata então de indicar e detalhar sobre os
componentes a serem inseridos no sistema que está sendo
construído.
E se comportar como uma bússola que NORTEIA TODO O
PROJETO e quais as ferramentas a serem estabelecidas ao término
do projeto.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
criar um documento no editor de texto e digitar os itens e seus 
respectivos conceitos. Não é o ideal
É preciso ter disciplina e orientação para alcançar um documento 
que seja acessível e entendido pelos diversos participantes do 
projeto, evitando que ele seja o primeiro recurso de desentendimento 
e dificuldade para a compreensão .
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Uma especificação de requisitos não é apenas um documento 
técnico, que será lido apenas pelos analistas de sistemas e os 
programadores. Tem que ser lido por todos.
Sommerville (2009) esclarece sobre tal realidade, tratando 
claramente sobre a diversidade do perfil de usuários, que vão 
desde a cúpula organizacional até aqueles vinculados à 
tecnologia da informação e comunicação.
(todos os tipos e stakeholders)
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Sommerville (2009)
“a diversidade de possíveisusuários é um indicativo de que o 
documento de requisitos precisa ser um compromisso com a 
comunicação dos requisitos para o cliente, a definição dos requisitos 
em detalhes precisos para os desenvolvedores e testadores e a 
inclusão de informações sobre a possível evolução do sistema”.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Premissa:
“compreensível” deve ser uma tônica para o grupo que está
responsável por gerar o documento de requisitos.
o documento é referência:
-presente (quanto se está em pleno desenvolvimento),
-Futuro quando na fase de manutenção.
No tocante a compreensão o texto utilizado precisa ser organizado
com nível adequado aos respectivos leitores.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
exemplo abaixo, retirado do livro do PFLEEGER (Engenharia de
Software – Teoria e Prática – 2ª Edição, pág. 140):
Em 1995, a Organização Australiana de Defesa e Tecnologia
relatou os resultados de uma pesquisa sobre problemas com
especificação de requisitos na Marinha.
Um dos problemas destacados foi a disparidade no nível das
especificações.
-alguns requisitos foram especificados em um nível alto
- outros em um nível muito baixo.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Analistas:
•Algumas vezes, os analistas de requisitos utilizaram diferentes
estilos de escrita, especialmente em área diferentes do sistema.
•A diferença de experiência entre os analistas levou a diferentes
níveis de detalhes nos requisitos.
•Na tentativa de reutilizar os requisitos a partir de sistemas
anteriores, os analistas empregaram diferentes formatos e estilos
de escrita.
•Os analistas, algumas vezes, mesclaram requisitos com soluções
parciais, levando a sérios problemas para o projeto de uma solução
com boa relação custo-benefício.
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Analistas:
•Freqüentemente os requisitos foram excessivamente
especificados, quando os analistas identificaram tipos específicos
de computadores e linguagens de programação assumiram uma
solução específica ou impuseram processos e protocolos não
apropriados.
•Algumas vezes, os requisitos foram pouco especificados,
especialmente ao descreverem o ambiente de operação,
manutenção, simulação para treinamento, computação
administrativa e tolerância a falhas.
Sommerville (2009) na Figura 1, são estes exemplos de usuários de um
documento de requisitos de software:
perfil de um documento de requisitos,
Vamos analisar sobre:
-a sua estrutura,
- o que pode ser considerado para a sua criação.
-- modelos
Segundo estrutura Sommerville (2009) –
Capítulo Descrição
Prefácio Deve definir os possíveis leitores do documento e
descrever seu histórico de versões, incluindo uma
justificativa para a criação de uma nova versão e um
resumo das mudanças feitas em cada versão.
Introdução Deve descrever a necessidade para o sistema. Deve
descrever brevemente as funções do sistema e
explicar como ele vai funciona com outros sistemas.
Também deve descrever como o sistema atende aos
objetivos globais do negócio ou estratégicos da
organização que encomendou o software.
Segundo estrutura Sommerville (2009) –
Capítulo Descrição
Glossário Deve definir os termos técnicos usados no
documento. Não deve conter suposições sobre o
conhecimento ou experiência do leitor.
Definição de 
requisitos de 
usuário
Deve descrever os serviços oferecidos ao usuário.
Os requisitos não funcionais do sistema também
devem ser descritos nessa seção. Essa descrição
pode usar linguagem natural, diagramas ou outras
notações compreensíveis para os clientes. Normas
produtos que devem ser seguidos devem sem
especificados.
Modelos do
sistema
Pode incluir modelos gráficos do sistema que
mostram relacionamentos entre os componentes do
sistema, o sistema e seu ambiente.
Segundo estrutura Sommerville (2009) –
Capítulo Descrição
Evolução do
sistema
Deve descrever os pressupostos fundamentais em
que o sistema se baseia, bem como quaisquer
mudanças previstas, em decorrência da evolução do
hardware, de mudanças nas necessidades do
usuário, etc. Essa seção é útil para projetistas de
sistemas, pois pode ajudá-los a evitar decisões
capazes de restringir possíveis mudanças futuras no
sistema.
Segundo estrutura Sommerville (2009) –
Capítulo Descrição
Apêndices Deve fornecer informações detalhadas e especificas
em relação à aplicação em desenvolvimento, além
das descrições de hardware e banco de dados, por
exemplo. Os requisitos de hardware definem as
configurações mínimas do sistema. Requisitos de
banco de dados, definem a organização lógica dos
dados usados pelo sistema e os relacionamentos
entre esses dados.
Índice Vários índices podem ser incluídos no documento.
Pode haver, além de um índice alfabético normal, um
índice de diagramas, de funções, dentre outros que
sejam pertinentes.
essa proposta não é única e definitiva, podendo sofrer 
adaptações, inclusões e exclusões, a depender da 
necessidade do cliente dos responsáveis pela sua 
criação e de padrões de documentação das empresas
Ficha Técnica
Equipe Responsável pela Elaboração
<nome> <identificação: carga, setor, divisão, região>
<nome> <identificação: carga, setor, divisão, região>
<nome> <identificação: carga, setor, divisão, região>
<nome> <identificação: carga, setor, divisão, região>
Público Alvo
Este manual destina-se a <especifique o público alvo deste documento>
Versão <x.y> - <local>, <mês> de <ano>
Dúvidas, críticas e sugestões devem ser encaminhadas por escrito para o
seguinte endereço postal:
<especifique o endereço para correspondência>
Ou para o seguinte endereço eletrônico:
<especifique o e-mail para contato>
Recomendamos que o assunto seja identificado com o título desta obra.
Alertamos ainda para a importância de se identificar o endereço e o nome
completos do remetente para que seja possível o envio de respostas.
Sumário
INTRODUÇÃO P2
Visão geral deste documento P2
Convenções, termos e abreviações P2
CAPÍTULO 1 - DESCRIÇÃO GERAL DO SISTEMA C1 . P2
Abrangência e sistemas relacionadosC1 . P2
Descrição dos usuários C1 . P2
1.<Opcional> <Nome de um tipo específico de usuário> C1 . P2
2.<Opcional> <Nome de outro tipo específico de usuário > C1 . P2
3.… C1 . P2
CAPÍTULO 2 - REQUISITOS FUNCIONAIS (CASOS DE USO) C2 . P2
<Nome de subseção para agrupar casos de uso correlacionados> C2 . P2
[RF001] <Nome do caso de uso> C2 . P2
Fluxo de eventos principal C2 . P2
<Opcional> Fluxos secundários (alternativos e de exceção) C2 . P2
[RF…] <Nome de outro caso de uso> C2 . P2
<Nome de outra subseção para agrupar outros casos de uso 
correlacionados> C2 . P2
… C2 . P2
CAPÍTULO 3 - REQUISITOS NÃO FUNCIONAIS C3 . P2
Usabilidade C3 . P2
[NF001] <Nome do requisito> C3 . P2
[NF…] <Nome do requisito> C3 . P2
Confiabilidade C3 . P2
[NF…] <Nome do requisito> C3 . P2
Desempenho C3 . P2
[NF…] <Nome do requisito> C3 . P2
Segurança C3 . P2
[NF…] <Nome do requisito> C3 . P2
Distribuição C3 . P2
[NF…] <Nome do requisito> C3 . P2
Padrões C3 . P2
[NF…] <Nome do requisito> C3 . P2
Hardware e software C3 . P2
[NF…] <Nome do requisito> C3 . P2
CAPÍTULO 4 - <OPCIONAL> DESCRIÇÃO DA INTERFACE COM O USUÁRIO
C4 . P2
<Identificador de uma interface> C4 . P2
1.<Opcional> Críticas da interface C4 . P2
<Identificador de outra interface> C4 . P2
… C4 . P2
Introdução
<Este espaço deve ser usado para descrever os objetivos deste
documento e o público ao qual ele se destina. Complete e/ou
adapte o texto abaixo para fornecer essas informações.>
Este documento especifica o sistema <Nome do sistema>,
fornecendo aos desenvolvedores as informações necessárias para
o projeto e implementação, assim como para a realização dos
testes e homologação do sistema.
Visão geral deste documento
<Esta seção fornece uma breve descrição de como o resto deste 
documento está organizado.Complete e/ou adapte o texto abaixo para 
fornecer essa informação.>
Contemple com as informações necessárias para fazer um bom uso deste 
documento, abrangendo a maioria dos objetivos e das convenções a serem 
adotadas no texto, bem como uma lista de referências para outros 
documentos relacionados. 
Para as demais seções, siga orientação como descrito abaixo.
•Seção 2 – Descrição geral do sistema: apresenta uma visão geral do 
sistema, caracterizando qual é o seu escopo e descrevendo seus usuários.
•Seção 3 – Requisitos funcionais (casos de uso): especifica todos os 
requisitos funcionais do sistema, descrevendo os fluxos de eventos, 
prioridades, atores, entradas e saídas de cada caso de uso a ser 
implementado.
•Seção 4 – Requisitos não funcionais: especifica todos os requisitos não 
funcionais do sistema, divididos em requisitos de usabilidade, 
confiabilidade, desempenho, segurança, distribuição, adequação a padrões 
e requisitos de hardware e software.
Seção 5 – Descrição da interface com o usuário: apresenta desenhos, 
figuras ou rascunhos de telas do sistema.
Convenções, termos e abreviações
<Esta subseção deve descrever as convenções, termos e abreviações
necessários para interpretar apropriadamente este documento. As
explicações necessárias podem ser fornecidas diretamente nesta
seção ou através de referências para outros documentos ou para
apêndices deste documento. Complete e/ou adapte o texto abaixo
para fornecer essas informações.>
A correta interpretação deste documento exige o conhecimento de
algumas convenções e termos específicos, que são descritos a seguir.
Identificação dos Requisitos
Por convenção, a referência a requisitos é feita através do nome da
subseção onde eles estão descritos, seguido do identificador do requisito,
de acordo com o esquema abaixo:
[nome da subseção.identificador do requisito]
Por exemplo, o requisito [Recuperação de dados.RF016] está descrito em
uma subseção chamada “Recuperação de dados”, em um bloco
identificado pelo número [RF016].
Já o requisito não funcional [Confiabilidade.NF008] está descrito na
seção de requisitos não funcionais de Confiabilidade, em um bloco
identificado por [NF008].
Prioridades dos Requisitos
Para estabelecer a prioridade dos requisitos foram adotadas as 
denominações “essencial”, “importante” e “desejável”. 
•Essencial é o requisito sem o qual o sistema não entra em 
funcionamento. Requisitos essenciais são requisitos 
imprescindíveis, que têm que ser implementados impreterivelmente.
•Importante é o requisito sem o qual o sistema entra em 
funcionamento, mas de forma não satisfatória. Requisitos 
importantes devem ser implementados, mas, se não forem, o 
sistema poderá ser implantado e usado mesmo assim.
Desejável é o requisito que não compromete as funcionalidades 
básicas do sistema, isto é, o sistema pode funcionar de forma 
satisfatória sem ele. Requisitos desejáveis são requisitos que 
podem ser deixados para versões posteriores do sistema, caso 
não haja tempo hábil para implementá-los na versão que está 
sendo especificada
Descrição geral do sistema
<Descreva aqui, em linhas gerais, os objetivos do sistema,
comunicando o propósito da aplicação e a importância do projeto para
todas as pessoas envolvidas.
Se for necessário apresentar detalhes mais técnicos sobre o sistema,
você também pode usar esta seção para descrever em linhas gerais a
arquitetura do sistema, indicando seus módulos principais, o uso (se
existir) da Internet ou outra rede de comunicação, componentes on-line
e off-line, e a interação (se existir) com outros sistemas. Use um
diagrama se achar conveniente.>
Abrangência e sistemas relacionados
<Nesta seção, descreva em linhas gerais o que o sistema irá fazer (suas
principais funcionalidades) e o que ele não irá fazer (escopo negativo),
deixando claro se o sistema irá interagir com outros sistemas
relacionados ou se ele é independente e totalmente auto-contido.
As funcionalidades principais do sistema devem ser apenas citadas,
para dar uma idéia geral ao leitor dos serviços que serão fornecidos pelo
sistema. Os detalhes serão fornecidos posteriormente, na seção 3 deste
documento. Funcionalidades que a princípio seriam da alçada do
sistema e que não serão implementadas também devem ser listadas,
registrando-se o motivo pela qual elas não serão contempladas (porque
serão fornecidas por outros sistemas relacionados, por exemplo, ou
porque serão implementadas apenas em projetos futuros).
Se o sistema for independente e totalmente auto-contido diga isso
explicitamente, caso contrário, liste e descreva brevemente os outros
sistemas com os quais este sistema deve interagir, explicando, de
maneira geral, quais os papéis de cada um e o meio de comunicação
entre eles.>
Descrição dos usuários
<Para efetivamente prover produtos e serviços que atendam às
necessidades dos usuários, é necessário entender os desafios que eles
enfrentam para executar suas funções. Esta seção deve descrever os
futuros usuários do sistema e os principais problemas que limitam sua
produtividade.
Descreva os aspectos gerais, relacionados a todos os usuários, aqui.
Depois, se for necessário, descreva nas subseções abaixo as
características específicas de cada usuário.>
<Opcional> <Nome de um tipo específico de usuário>
<Se for conveniente fornecer mais detalhes sobre um tipo específico de
usuário, use esta subseção para descrevê-lo.>
<Opcional> <Nome de outro tipo específico de usuário >
<Prossiga no detalhamento das características dos usuários,
descrevendo todos os tipos de usuário que for necessário, cada um em
uma subseção.>
Requisitos funcionais
<Nesta seção, apresente todos os requisitos funcionais, ou casos de uso,
do sistema. Em sistemas grandes é comum haver muitos casos de uso e,
para facilitar a visualização deste documento, você pode agrupá-los em
subseções de casos de uso correlacionados. Os nomes das subseções
devem ser únicos e pequenos (3 palavras no máximo) e podem ser
formados por palavras, números e/ou abreviações.
Cada um dos casos de uso deve ser descrito em um bloco específico,
seguindo o modelo descrito abaixo. O identificador do bloco deve conter o
número do caso de uso (por exemplo, [RF001]) e o seu nome. Se os
casos de uso forem agrupados em subseções específicas, a numeração
deles deve ser reiniciada a cada subseção (dentro de uma mesma
subseção, todo caso de uso deve ter um número de identificação único).
Quando a primeira versão deste documento for disponibilizada para a
equipe de desenvolvimento, os nomes das subseções e os números dos
casos de uso não devem ser modificados ou reaproveitados, para não
invalidar referências externas feitas a eles.>
Prioridade: 
Essenci
al
 Importante 
Dese
jável
Nome de subseção para agrupar casos de uso correlacionados>
<Utilize este espaço para descrever características comuns dos casos de
uso desta seção, explicitando o motivo do seu agrupamento em uma
seção única.
Se todos os casos de uso desta seção estiverem relacionados com o
mesmo ator você pode informar isso aqui, especificando qual é o ator em
questão, e eliminar o campo “Ator:” das descrições dos casos de uso
feitas nos blocos a seguir.>
[RF001] <Nome do caso de uso>
<Opcional – forneça uma pequena explicação do propósito do caso de
uso (útil quando o nome do caso de uso não deixa suficientemente claro
qual é o seu objetivo) e o(s) seu(s) respectivo(s) ator(es). Em seguida,
substitua um dos símbolos abaixo por , para indicar a prioridade do
caso de uso.>
Ator: <informe o(s) ator(es) do caso de uso >
<Opcional> Interface(s) associada(s): <inclua aqui o(s)
identificador(es) da(s) respectiva(s) interface(s) do caso de uso
(descrita(s) na Seção 5).>
Prioridade: 
Essenci
al
 Importante 
Dese
jável
Entradas e pré condições: <Liste aqui todas as entradas e/ou pré
condições do caso de uso. Pré condição de um caso de uso é o estado
em que o sistema deve estar pararealizar o caso de uso.>
Saídas e pós condições: <Liste aqui todas as saídas e/ou pós
condições do caso de uso. Pós condição de um caso de uso é a lista de
possíveis estados em que o sistema pode estar imediatamente após o
término da realização do caso de uso.>
Fluxo de eventos principal
<Descreva aqui o fluxo de eventos principal que ocorre durante a
execução do caso de uso.>
<Opcional> Fluxos secundários (alternativos e de exceção)
<Fluxo secundário XXX>
<Use este espaço para descrever o fluxo secundário XXX do
caso de uso.>
<Fluxo secundário YYY>
<Prossiga na descrição dos fluxos secundários do caso de uso,
descrevendo cada um deles separadamente.>
[RF…] <Nome de outro caso de uso>
<Utilize os mesmos campos mostrados no bloco anterior para
descrever este e os demais requisitos funcionais (casos de
uso) desta subseção.>
<Nome de outra subseção para agrupar outros casos de uso
correlacionados>
<Prossiga de maneira similar à subseção anterior para
descrever quaisquer outras subseções que forem usadas para
agrupar requisitos funcionais.>
Requisitos não funcionais
<Esta seção deve conter os requisitos não funcionais do sistema.
Para uma melhor organização deste documento, utilize as subseções
abaixo para agrupar os requisitos não funcionais relacionados.
Naturalmente, o número e tipo de subseções utilizadas depende do
sistema que está sendo especificado e não é preciso utilizar todas
elas. Simplesmente elimine as subseções para as quais não for
encontrado nenhum requisito.
Os requisitos não funcionais devem ser identificados com um
identificador único, da mesma maneira que os requisitos funcionais
(casos de uso). Inicie a numeração com o identificador NF001 e
prossiga incrementando os números a medida que forem surgindo
novos requisitos não funcionais. Reinicie a numeração em cada
subseção. Forneça também um nome para o requisito, como foi feito
para os requisitos funcionais.
Descreva o requisito, assinale a sua prioridade e, em seguida, caso o
requisito esteja relacionado a um caso de uso ou a um grupo de
casos de uso específicos, utilize o campo “Caso(s) de uso
associado(s):” para identificar o(s) caso(s) de uso correspondente(s).
Se for um requisito não funcional do sistema como um todo, esse
campo não precisa ser utilizado.>
Prioridade: 
Essenci
al
 Importante 
Dese
jável
Usabilidade
Esta seção descreve os requisitos não funcionais associados à facilidade
de uso da interface com o usuário, material de treinamento e documentação
do sistema.
[NF001] <Nome do requisito>
<Descreva o requisito não funcional e substitua um dos símbolos abaixo por
, para indicar a sua prioridade.>
<Opcional> Caso(s) de uso associado(s): <use este campo para
identificar a que caso(s) de uso o requisito de usabilidade está
relacionado.>
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados no bloco anterior para descrever
este e os demais requisitos não funcionais de usabilidade.>
Confiabilidade
Esta seção descreve os requisitos não funcionais associados à freqüência,
severidade de falhas do sistema e habilidade de recuperação das mesmas,
bem como à corretude do sistema.
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados na seção 4.1 para descrever este e
os demais requisitos não funcionais de confiabilidade.>
Desempenho
Esta seção descreve os requisitos não funcionais associados à eficiência,
uso de recursos e tempo de resposta do sistema.
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados na seção 4.1 para descrever este
e os demais requisitos não funcionais de desempenho.>
Segurança
Esta seção descreve os requisitos não funcionais associados à
integridade, privacidade e autenticidade dos dados do sistema.
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados na seção 4.1 para descrever este
e os demais requisitos não funcionais de segurança.>
Distribuição
Esta seção descreve os requisitos não funcionais associados à
distribuição da versão executável do sistema.
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados na seção 4.1 para descrever este
e os demais requisitos não funcionais de distribuição.>
Padrões
Esta seção descreve os requisitos não funcionais associados a padrões 
ou normas que devem ser seguidos pelo sistema ou pelo seu processo de 
desenvolvimento. 
<Se você mencionar documentos relacionados, não esqueça de listá-los 
na seção 1.3.> 
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados na seção 4.1 para descrever este 
e os demais requisitos não funcionais de adequação a padrões.>
Hardware e software
Esta seção descreve os requisitos não funcionais associados ao hardware 
e software usados para desenvolver ou para executar o sistema. 
[NF…] <Nome do requisito>
<Utilize os mesmos campos mostrados na seção 4.1 para descrever este 
e os demais requisitos não funcionais de hardware e software.>
<Opcional> Descrição da interface com o usuário
<Esta seção deve conter desenhos ou rascunhos das telas do sistema 
que forem necessários ou convenientes para esclarecer algum dos 
requisitos do sistema. Para sistemas que possuem protótipos ou 
versões já desenvolvidas é possível capturar as telas e apresentar 
figuras das mesmas.
Use nomes e/ou números para identificar cada interface e descreva-as 
em seções independentes.>
<Identificador de uma interface>
<Descreva a interface em questão, através de figuras, diagramas e/ou 
texto. 
<Opcional> Críticas da interface
<Você pode fazer aqui a descrição de críticas simples de interface, 
como o tamanho e máscara de campos, simplificando assim a 
descrição dos fluxos de exceção.>
<Identificador de outra interface>
<Prossiga no detalhamento das interfaces do sistema, descrevendo 
todas que for necessário, cada uma em uma subseção.>
Existem outros modelos:
Recomendamos que você pesquise na internet:
Modelo do práxis: 
especificação do produto de software
especificação dos requisitos de software
Pode-se fazer uma página WEB para documentar requisitos para 
um projeto
DESAFIO
EXERCITE:
PEGUE UM SISTEMA QUE VOCE CONHECE OU 
ESTÁ ESPECIFICANDO E COLQUE NO 
MODELO APRESENTADO
Na próxima aula:
faremos uma revisão da cinco primeiras aulas preparando-o para a AV1
DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE – AULA5
REQUISITOS DE SISTEMAS
Contactos e material complementar e exercícios
www.espacodoprofessor.com
Professor: Horacio ribeiro
Modulo Estácio 2012.1
Senha 222222
http://www.espacodoprofessor.com/
REQUISITOS DE SISTEMAS
PROF. Horacio Ribeiro
Aula 6: ENGENHARIA DE REQUISITOS E 
ESTUDOS DE VIABILIDADE
REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS
ENGENHARIA DE REQUISITOS E ESTUDOS DE VIABILIDADE - AULA 7
REQUISITOS DE SISTEMAS
Conteúdo Programático desta aula
•Identificar o conceito e os processos de engenharia de 
requisitos.
•Identificar o conceito sobre viabilidade de requisitos.
•Reconhecer a importância da atividade de análise de 
viabilidade.
•Realizar a análise de viabilidade de um projeto de 
software. 
ENGENHARIA DE REQUISITOS E ESTUDOS DE VIABILIDADE - AULA 7
REQUISITOS DE SISTEMAS
Introdução da aula
O estudo de viabilidade, estamos concentrados, no 
contexto da fase inicial a qualquer projeto de software, 
na realização de um “checklist” sobre os problemas 
identificados e que deverão ser solucionados.
No estudo de viabilidade, é possível determinar pontos 
críticos do projeto, o que se tem de diferentes 
alternativas de soluções para o problema 
Até mesmo, a conclusão de que o projeto tem realmente 
condições de ser finalizado, ou seja, será levado 
adiante ou não.
ENGENHARIA DE REQUISITOS E ESTUDOS DE VIABILIDADE - AULA 7
REQUISITOS DE SISTEMAS
Introdução da aula
De maneira pragmática, na atividade vinculada ao 
estudo de viabilidade incide de um documento com 
formato previamente definido e que tem a importante 
missão de descrever, de maneira geral: 
•o problema a ser tratado; a
• proposta e o plano do