Engenharia Requisitos

Engenharia de Requisitos
Professor: Msc. Alexandre Rafael Lenz
Agenda
4. Processo de Engenharia de Requisitos
1. Apresentao do Professor
Viso Geral do Processo de Engenharia de Requisitos
2. Apresentao da Disciplina
Levantamento de Requisitos
Ementa
Tcnicas de Levantamento de Requisitos
Objetivo
Qualidade dos Requisitos
Bibliografia
Atributos dos Requisitos
3. Introduo
Organizao dos Requisitos
Anlise de Requisitos
Requisitos
UML
Tipos de Requisitos
Modelo Entidades e Relacionamentos
Nveis de Requisitos
Documentao de Requisitos
O Documento de Definio de Requisitos
O Documento de Especificao de Requisitos
Verificao e Validao de Requisitos
Gerncia de Requisitos
Mudanas de Requisitos
Matriz de Rastreabilidade
Engenharia de Requisitos e Normas e Modelos de
Qualidade de Processos de Software
CMMI
MPS.BR
1. Apresentao do Professor
Apresentao do Professor
- DOUTORANDO EM CINCIA DA COMPUTAO Universidade Federal
da Bahia, UFBA, Salvador, Brasil Ttulo: Uma Abordagem para Gerao
de Contedos Complementares num Cenrio de Convergncia Digital
Orientador: Celso Alberto Saibel Santos
- MESTRADO EM INFORMTICA. Universidade Federal do Paran, UFPR,
Brasil. Ttulo: Utilizando tcnicas de aprendizado de mquina para
apoio ao teste de regresso, Ano de Obteno: 2009. Orientadora: Slvia
Regina Vergilio.
- GRADUAO - BACHARELADO EM CINCIA DA COMPUTAO.
Universidade Luterana do Brasil, ULBRA. Ttulo: Processo de Teste de
Software Customizvel baseado em Modelos e Normas de Qualidade.
Ano de Obteno: 2007. Orientador: Luis Fernando Fortes Garcia.
4
- PROFESSOR 4 ANOS DE EXPERINCIA
- REA 1
- UNIJORGE
- UNIME
- UNEB Funcionrio Pblico, D.E., Concursado desde
2012
- Engenharia de Software
- Gerncia de Projetos
- Sistemas de Informao
- Sistemas Multimdia
- Interface Humano-Computador
- Algoritmos
5
Mais de 7 anos de experincia profissional na rea de T.I.,
Atuando em multinacionais como HP, LG, Nokia, Siemens e
Bunge.
Palestrante nos Simpsios da Sociedade Brasileira de

Engenharia de Televiso (SET) em Belo Horizonte, Braslia,
Recife e Manaus.
Gerente de Projetos no Centro Internacional de Tecnologia
de Software, gerenciando os Laboratrios de Teste de Tv
Digital da LG Electronics em Porto Alegre, Curitiba, So Paulo,
Belo Horizonte, Salvador e Fortaleza.
6
Nome em citaes bibliogrficas: LENZ, A. R.;

Lenz, A. R.
reas de atuao: Engenharia de Software, Teste
de Software, Televiso Digital e Convergncia
Digital.
2. Apresentao da Disciplina
Apresentao da Disciplina
Engenharia de Requisitos:
A engenharia de requisitos estabelece uma base

slida para o projeto e para a construo. Sem ela,
o software resultante tem grande probabilidade de
no atender s necessidades do cliente.
EMENTA
Introduo Engenharia de Requisitos

Tipos de requisitos.
O processo da Engenharia de Requisitos.
Tcnicas de Levantamento de Requisitos.
Anlise de Requisitos e Modelagem Conceitual.
Mtodos e tcnicas para a modelagem de sistemas.
Documentao de requisitos.
Verificao e validao de requisitos.
Gerncia de requisitos.
Engenharia de Requisitos e Normas e Modelos de
Qualidade
10
BIBLIOGRAFIA BSICA
Ian Sommerville. Engenharia de Software, 9 Edio. Pearson
Education, 2011.
Roger S. Pressman. Engenharia de Software - Uma

Abordagem Profissional, 7 Edio, Bookman, 2011.
BIBLIOGRAFIA COMPLEMENTAR
Falbo, R.A., Engenharia de Requisitos de Software Notas de
Aula, UFES, 2012.
11
Objetivo Geral: Estudar as caractersticas,

abordagens e mtodos aplicveis ao processo de
Engenharia de Requisitos, procurando capacitar os
alunos a levantar, analisar, modelar conceitualmente,
documentar, avaliar e gerenciar requisitos de
sistemas de software.
Objetivos Especficos:
Estudar os principais aspectos a serem considerados na
definio de requisitos de sistemas de software;
Capacitar o aluno a aplicar tcnicas de levantamento de
requisitos e modelagem conceitual
12
3. Introduo
Mapa dos requisitos
[PRESSMAN, 2011]
14
Problema Clssico
15
Soluo: Comunicao
Cliente
Engenheiro de
Requisitos
16
Processo de Software:
Classificao de Atividades
Um processo de software envolve diversas atividades
que podem ser classificadas quanto ao seu propsito
em:
Atividades de Desenvolvimento (ou Tcnicas)
so as atividades diretamente relacionadas ao processo de desenvolvimento
do software (levantamento e anlise de requisitos, projeto, implementao)
Atividades de Gerncia
envolvem atividades relacionadas ao gerenciamento do projeto de maneira
abrangente (gerncia de projetos, gerncia de configurao, reuso, etc.).
Atividades de Controle da Qualidade

so aquelas relacionadas com a avaliao da qualidade do produto ou do
processo (verificao, validao, garantia da qualidade).
17
18
Atividades de Desenvolvimento:
1 Atividade de Desenvolvimento
Levantamento de Requisitos:
quando os requisitos do sistema a ser desenvolvido
so preliminarmente capturados e organizados.
em seguida os requisitos devem ser modelados,
avaliados e documentados.
Modelagem Conceitual: elaborao de modelos
descrevendo o qu o software tem de fazer (e no como
faz-lo).
19
Note que muitas solues so possveis para o

mesmo conjunto de requisitos
So ligadas uma dada plataforma de implementao
linguagem de programao, mecanismo de persistncia a
ser adotado, etc.
Atividade de Projeto
Tem por objetivo definir e especificar uma soluo (como
faz-lo) a ser implementada.
20
Importncia dos Requisitos

Requisitos tm um papel central no desenvolvimento
de software, uma vez que uma das principais medidas
do sucesso de um software o grau no qual ele atende
aos objetivos e requisitos para os quais foi construdo.
Requisitos so a base para:
Estimativas
Modelagem
Projeto
Implementao
Testes
Manuteno
Esto presentes ao longo de todo o ciclo de vida de um software.
21
Atividades Relacionadas aos Requisitos
Nos estgios iniciais de um projeto,

requisitos tm de ser levantados,
entendidos e documentados.
Atividades de:
22

Dada a importncia dos requisitos para o sucesso de
um projeto, atividades de controle da qualidade devem
ser realizadas para verificar, validar e garantir a
qualidade dos requisitos
Atividades de:
Verificao de Requisitos
Validao de Requisitos
Garantia da Qualidade de Requisitos
Os custos sero bem maiores se defeitos em requisitos
23
forem identificados tardiamente

Mesmo quando coletados de forma sistemtica,
requisitos mudam. fundamental gerenciar a evoluo
dos requisitos, bem como manter a rastreabilidade
entre os requisitos e os demais artefatos produzidos no
projeto.
Atividade de:
24
25

Atividades de Desenvolvimento
Atividades de Gerncia
Atividades de Controle da Qualidade

Verificao de Requisitos
Validao de Requisitos
Garantia da Qualidade de Requisitos
26
Definio de Engenharia de Requisitos
A Engenharia de Requisitos o processo pelo

qual os requisitos de um produto de software
so coletados, analisados, documentados e
gerenciados ao longo de todo o ciclo de vida
do software. (AURUM; WOHLIN, 2005)
27
Definio de Engenharia de Requisitos
Engenharia de Requisitos :
O processo de (em relao aos requisitos):
Coletar
Analisar
Documentar
Verificar/
Validar
Gerenciar
A Engenharia de Requisitos de Software o ramo da

Engenharia de Software que envolve as atividades
relacionadas com a definio dos requisitos de software de
um sistema, desenvolvidas ao longo do ciclo de vida de
software
[Sommerville, 2011]
28
Definio de Requisito
Existem diversas definies para requisito de
software na literatura, dentre elas:
Requisitos de um sistema so descries dos servios que
devem ser fornecidos por esse sistema e as suas restries
operacionais (SOMMERVILLE, 2011).
Um requisito de um sistema uma caracterstica do
sistema ou a descrio de algo que o sistema capaz de
realizar para atingir seus objetivos (PFLEEGER, 2004).
Um requisito alguma coisa que o produto tem de fazer
ou uma qualidade que ele precisa apresentar
(ROBERTSON; ROBERTSON, 2006).
29
Tipos de Requisitos
As vrias definies apresentadas

apontam para a existncia de diferentes
tipos de requisitos:
Requisitos Funcionais
Requisitos No Funcionais
Requisitos de Domnio (Regras de Negcio)
30
Tipos de Requisitos
Requisitos Funcionais (RFs)

So declaraes de servios que o sistema deve prover,
descrevendo o que o sistema deve fazer (SOMMERVILLE,
2011).
Um requisito funcional descreve uma interao entre o
sistema e o seu ambiente (PFLEEGER, 2004).
Podendo descrever, ainda, como o sistema deve reagir a
entradas especficas, como o sistema deve se comportar
em situaes especficas e o que o sistema no deve fazer
(SOMMERVILLE, 2011).
31
Tipos de Requisitos
Requisitos Funcionais (RFs)

Exemplo:
RF1 (Fidelizao do Cliente)
Para que o cliente possa efetuar o pedido o mesmo deve estar
previamente cadastrado no site. Para a consulta no catlogo
no necessrio que o usurio esteja autenticado. Deve-se
permitir que o cliente seja bloqueado caso haja alguma
situao de inadimplncia no pagamento.
32
Tipos de Requisitos
Requisitos No Funcionais (RNFs)

Descrevem restries sobre os servios ou funes
oferecidos pelo sistema (SOMMERVILLE, 2011), as quais
limitam as opes para criar uma soluo para o problema
(PFLEEGER, 2004).
Neste sentido, os requisitos no funcionais so muito
importantes para a fase de projeto (design), servindo
como base para a tomada de decises nessa fase.
33
Tipos de Requisitos

Os requisitos no funcionais tm origem nas
necessidades dos usurios:
em restries de oramento
em polticas organizacionais
em necessidades de interoperabilidade com outros
sistemas de software ou hardware
em fatores externos como regulamentos e legislaes
(SOMMERVILLE, 2011)
34
Tipos de Requisitos
Classificao - RNFs (SOMMERVILLE, 2011):

Requisitos de produto: comportamento do produto.
confiabilidade, usabilidade, eficincia, portabilidade,
manutenibilidade e segurana.
Requisitos organizacionais: so derivados de metas,

polticas e procedimentos das organizaes do cliente e do
desenvolvedor.
Time-to-market, linguagem, custo, plataforma, etc.
Requisitos externos: referem-se a todos os requisitos

derivados de fatores externos ao sistema e seu processo
de desenvolvimento.
Interoperabilidade com outros sistemas, privacidade, etc.
35
Tipos de Requisitos
Classificao RNFs ISO 25000:
36
Tipos de Requisitos

Exemplo:
RNF1 (Desempenho)
O Site deve estar preparado para atender 20
requisies simultneas com respostas de no
mximo 1 segundo de atraso.
37
Tipos de Requisitos
Ainda que a classificao em requisitos

funcionais e no funcionais seja a mais
amplamente aceita, h outras classificaes
de requisitos.
Sommerville (2011) considera, alm de
requisitos funcionais e no funcionais,
requisitos de domnio.
38
Tipos de Requisitos
Requisitos de domnio na concepo de

Sommerville so o que outros autores, tal
como Wiegers (2003), chamam de Regras de
Negcio.
Exemplo: Em um sistema de matrcula de uma
universidade, uma regra de negcio diz que:
RN1 (pr-requisito)
Um aluno s pode se matricular em uma turma de
uma disciplina se ele tiver cumprido seus prrequisitos.
39
Tipos de Requisitos
Regras de Negcio
1. Fatos ou invariantes:
declaraes que so verdade sobre o negcio. Geralmente
descrevem associaes ou relacionamentos entre importantes
termos do negcio.
Ex.: Todo pedido tem uma taxa de remessa.
2. Restries:
como o prprio nome indica, restringem as aes que o sistema ou
seus usurios podem realizar.
Algumas palavras ou frases sugerem a descrio de uma restrio,
tais como deve, no deve, no pode e somente.
Ex.: Um aluno s pode tomar emprestado, concomitantemente, at
trs livros.
40
Tipos de Requisitos
Regras de Negcio
3. Ativadores de Aes:
so regras que disparam alguma ao sob condies especficas. Uma
declarao na forma Se <alguma condio verdadeira ou algum
evento ocorre>, ento <algo acontece> indicada para descrever
ativadores de aes.
Ex.: Se a data para retirada do livro ultrapassada e o livro no retirado, ento a
reserva cancelada.
4. Inferncias:
so regras que derivam novos fatos a partir de outros fatos ou
clculos. So normalmente escritas no padro se / ento, mas a
clusula ento implica um fato ou nova informao e no uma ao a
ser tomada.
Ex.: Se o usurio no devolve um livro dentro do prazo estabelecido, ento ele
torna-se um usurio inadimplente.
41
Tipos de Requisitos
Regras de Negcio
5. Computaes:
so regras de negcio que definem clculos a serem
realizados usando algoritmos ou frmulas matemticas
especficos.
Podem ser expressas como frmulas matemticas,
descrio textual, tabelas etc.
Ex.: Multa = Valor de Locao * Nmero de Dias de Atraso.
42
Nveis de Descrio de Requisitos
Os requisitos devem ser redigidos de modo a

serem passveis de entendimento pelos
diversos interessados (stakeholders).
Desenvolvedores tm interesse em detalhes
tcnicos.
Requisitos de Sistema
Clientes requerem descries mais abstratas.

Requisitos de Usurio
43

Requisitos de Usurio: so declaraes em
linguagem natural acompanhadas de diagramas
intuitivos de quais servios so esperados do sistema
e das restries sob as quais ele deve operar.
Nvel de abstrao mais alto para pessoas que no
possuem conhecimento tcnico.
[Sommerville, 2011]
44

Requisitos de Sistema: definem detalhadamente as
funes, servios e restries do sistema. So
verses expandidas dos requisitos de usurio usados
pelos desenvolvedores para projetar, implementar e
testar o sistema.
Especificaes em linguagem natural so insuficientes e
para especific-los, notaes mais especializadas devem
ser utilizadas.
[Sommerville, 2011]
45
Esses nveis de descrio de requisitos so aplicados

em momentos diferentes e com propsitos distintos.
Requisitos de usurio so elaborados nos estgios iniciais
do desenvolvimento.
Usados como base para a contratao e o planejamento do projeto
Requisitos de sistema so elaborados como parte dos

esforos diretos para o desenvolvimento do sistema
Capturam detalhes importantes para as fases tcnicas
46
Documentos de Requisitos
Pfleeger (2004) sugere que dois tipos de documentos de
requisitos sejam elaborados:
Documento de Definio de Requisitos: deve ser escrito de
maneira que o cliente possa entender. Usa uma listagem do qu
o cliente espera que o sistema proposto faa. Representa um
consenso entre o cliente e o desenvolvedor sobre o qu o cliente
quer.
Resultado do Levantamento de Requisitos
Documento de Especificao de Requisitos: redefine os

requisitos de usurio em termos mais tcnicos, apropriados para
o desenvolvimento de software, sendo produzido por analistas
de requisitos.
Resultado da Anlise de Requisitos
47
2. Processo de
Viso Geral do Processo de

A Engenharia de Requisitos pode ser descrita como
um processo:
Um conjunto organizado de atividades que deve ser seguido
para derivar, avaliar e manter os requisitos e artefatos
relacionados.
Deve incluir:
A estrutura ou sequncia dessas atividades

Quem responsvel por cada atividade
Suas entradas e sadas
As ferramentas usadas para apoiar as atividades
Os mtodos, tcnicas e diretrizes a serem seguidos na sua
realizao.
49

Processos de engenharia de requisitos podem

variar muito de uma organizao para outra.
A definio de um processo apropriado
organizao traz muitos benefcios.
Deve atender s necessidades da organizao,
ou at mesmo de um projeto especfico.
No faz sentido falar em processo ideal ou definir
algum e imp-lo a uma organizao.
50

Wiegers (2003) destaca alguns benefcios que

um processo de Engenharia de Requisitos de
alta qualidade pode trazer:
menor quantidade de defeitos nos requisitos,

reduo de retrabalho,
desenvolvimento de menos caractersticas desnecessrias,
diminuio de custos,
desenvolvimento mais rpido,
menos problemas de comunicao,
alteraes de escopo reduzidas,
estimativas mais confiveis,
maior satisfao dos clientes e membros da equipe.
51

5
(KOTONYA; SOMMERVILLE, 1998)
52

Vale destacar que no h limites bem definidos

entre as atividades do processo apresentado.
Na prtica, elas so intercaladas e existe um
alto grau de iterao e feedback entre elas.
O processo executado at que todos os
usurios estejam satisfeitos e concordem com
os requisitos.
53

Esse processo pode ser aplicado para

diferentes ciclos de vida:
Ao se adotar um modelo de ciclo de vida
iterativo, essas atividades podem ser
realizadas muitas vezes.
54

Atividades do Processo de Engenharia de

Requisitos:
1.
2.
3.
4.
5.
Verificao e Validao de Requisitos
55
1. Levantamento de Requisitos
Nessa fase, um esforo conjunto de clientes, usurios e
especialistas de domnio necessrio
Objetiva entender a organizao, seus processos,
necessidades, deficincias dos sistemas de software atuais,
possibilidades de melhorias, bem como restries
existentes.
No se resume somente a perguntar s pessoas o que elas
desejam, mas sim analisar cuidadosamente a organizao,
o domnio da aplicao e os processos de negcio no qual
o sistema ser utilizado
56
Os requisitos podem ser obtidos de diferentes
fontes:
Informaes dos interessados (stakeholders)
Usurios, clientes e especialistas de domnio.
Consultar documentos
Sistemas e processos existentes
Obter conhecimentos do domnio
Estudar o negcio da organizao
etc.
57
Dimenses do levantamento de requisitos
58

1.
Entendimento do domnio da aplicao:
2.
entendimento geral da rea na qual o sistema ser aplicado;
Entendimento do problema:
3.
entendimento dos detalhes do problema especfico a ser

resolvido com o auxlio do sistema a ser desenvolvido;
Entendimento do negcio:
entender como o sistema ir afetar a organizao e como

contribuir para que os objetivos do negcio e os objetivos
gerais da organizao sejam atingidos;
59

4.
Entendimento das necessidades e das restries dos

interessados:
Entender as demandas de apoio para a realizao do trabalho de

cada um dos interessados no sistema, entender os processos de
trabalho a serem apoiados pelo sistema e o papel de eventuais
sistemas existentes na execuo e conduo dos processos de
trabalho.
Consideram-se interessados (stakeholders), todas as pessoas
que so afetadas pelo sistema de alguma maneira, dentre elas
clientes, usurios finais e gerentes de departamentos onde o
sistema ser instalado.
60
Stakeholders
Todas as pessoas que so afetadas pelo sistema de alguma maneira

Nem sempre o cliente o usurio final
Cliente
Quem contrata e paga pelo servio (Administrador de um hospital)
Usurio final
Quem usa o software no dia a dia (Mdicos e enfermeiros)
Importante
Nunca deixe de levantar requisitos com os usurios finais pois sem a

colaborao deles, o software no ser usado
61
Alguns sistemas sero utilizados por milhares ou milhes de

usurios
Escolha usurios fonte dos requisitos que sejam
representativos
Lembre-se que a regra de Pareto (80-20) aparenta ser vlida
20% dos requisitos satisfazem a 80% dos usurios

Escolher um usurio muito especialista pode levar a implementao
de requisitos que nunca sero utilizados
Requisitos funcionais:
Descrevem as funcionalidades do sistema
Requisitos no funcionais:
Descrevem a qualidade do sistema
62

Dentre as vrias tcnicas, podem ser citadas (KENDALL;
KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998; AURUM;
WOHLIN, 2005):
Entrevistas
Questionrios
Observao
Anlise de Documentos
Anlise de Sistemas Existentes
Cenrios
Prototipao
Dinmicas de Grupo
As tcnicas so complementares:
til empregar vrias dessas
tcnicas concomitantemente, de
modo a se ter um levantamento
de requisitos mais eficaz.
63

Entrevistas:
Tcnica amplamente utilizada, que consiste em
conversas direcionadas com um propsito
especfico e com formato pergunta-resposta.
Seu objetivo descobrir problemas a serem
tratados, levantar procedimentos importantes e
saber a opinio e as expectativas do entrevistado
sobre o sistema.
64

Entrevistas:
Entrevistas fechadas: nas quais o interessado
responde a um conjunto de perguntas
predefinidas.
Entrevistas abertas: nas quais no existe um
roteiro predefinido. O analista explora vrios
assuntos com o interessado e, assim, desenvolve
uma maior compreenso de suas necessidades.
65

Entrevistas: Planejamento da entrevista [Kendall e Kendall, 2010]:
1. Estudar material existente sobre o domnio e a organizao.
linguagem usada , vocabulrio comum, otimizar o tempo despendido nas entrevistas.
2. Estabelecer objetivos.
fontes de informao, formatos da informao, frequncia na tomada de deciso, estilo
da tomada de deciso etc.
3. Decidir quem entrevistar.

pessoas chave das diversas classes de interessados
4. Preparar o entrevistado.
agendamento para que o entrevistado tenha tempo para pensar sobre a entrevista.
5. Preparar a entrevista.
tipos de questes e a estrutura da entrevista e o modo como a mesma ser registrada.
66

Entrevistas:
67

Questionrios:
O uso de questionrios possibilita ao analista
obter informaes como postura, crenas,
comportamentos e caractersticas de vrias
pessoas que sero afetas pelo sistema.
68

Observao:
Consiste em observar o comportamento e o ambiente
dos indivduos de vrios nveis organizacionais.
Utilizando-se essa tcnica, possvel capturar o que
realmente feito e qual tipo de suporte computacional
realmente necessrio.
Ajuda a confirmar ou refutar informaes obtidas com
outras tcnicas e ajuda a identificar tarefas que podem
ser automatizadas e que no foram identificadas pelos
interessados.
69

Anlise de Documentos:
Pela anlise de documentos existentes na organizao,
analistas capturam informaes e detalhes difceis de
conseguir por entrevista e observao.
Documentos revelam um histrico da organizao e sua
direo.
70

Anlise de Software Existente:
Caso j exista um sistema em uso e o projeto trata da sua
reconstruo, este pode ser utilizado como fonte para
levantamento de requisitos.
A tarefa ser executada atravs da Engenharia Reversa
no contexto de uma Reengenharia do software.
71

Cenrios:
Um cenrio de interao entre o usurio final e o sistema
montado e o usurio simula sua interao com o
sistema nesse cenrio, explicando ao analista o que ele
est fazendo e de quais informaes ele precisa para
realizar a tarefa descrita no cenrio.
O uso de cenrios ajuda a entender requisitos, a expor o
leque de possveis interaes e a revelar facilidades
requeridas.
72

Prototipao:
Um prottipo uma verso preliminar do sistema,
muitas vezes no operacional e descartvel, que
apresentada ao usurio para capturar informaes
especficas sobre seus requisitos de informao,
observar reaes iniciais e obter sugestes, inovaes e
informaes para estabelecer prioridades e redirecionar
planos.
73

Prototipao:
Prototipao evolucionria
Uma abordagem para o desenvolvimento do sistema onde um
prottipo inicial produzido e refinado atravs de vrios
estgios at atingir o sistema final.
Prototipao descartvel
Um prottipo o qual usualmente uma implementao prtica
do sistema produzida para ajudar a levantar os problemas
com os requisitos e depois descartado. O sistema ento
desenvolvido usando algum outro processo de
desenvolvimento.
74

Prototipao:
75

Prototipao:
76

Prototipao:
77

Dinmicas de Grupo:
H vrias tcnicas que procuram explorar dinmicas de
grupo para a descoberta e o desenvolvimento de requisitos:
Brainstorming: representantes de diferentes grupos de interessados
engajam-se em uma discusso informal para rapidamente gerarem
o maior nmero possvel de ideias.
JAD (Joint Application Development): interessados e analistas se
renem para discutir problemas a serem solucionados e solues
possveis. Com as diversas partes envolvidas representadas,
decises podem ser tomadas e questes podem ser resolvidas mais
rapidamente.
JAD so normalmente bem estruturadas (passos, aes e papis). 78
Contextualizao: O contexto consiste em definir
algumas caractersticas de cada Requisito Funcional,
tais como: para quem til?, quando?, por que?,
onde?, como?
Essas perguntas so
fundamentais para
entendimento dos requisitos,
auxiliando uma descrio
detalhada e consistente.
Dimenses Contextuais [KNIGHT, 2004]
79
Contextualizao: Para cada requisito identificado, as
seguintes questes devem ser feitas:
01) Por que o requisito deve ser considerado na Soluo?
A resposta deve ser analisada e verificada com o problema que est sendo resolvido pela
soluo em questo. A resposta tem que manter o escopo do Problema e da Soluo. Caso
a resposta indique que o requisito amplia a soluo do Problema, ento um estudo mais
aprofundado deve ser feito em relao ao escopo do Problema e da Soluo.
02) Como o requisito deve ser considerada Soluo?

Esta pergunta deve esclarecer, do ponto de vista do usurio, como o requisito deve ser
considerado na soluo. As respostas podem variar bastante e outros requisitos de diversos
tipos podem ser identificados.
Alm disso, esse item responde em partes os critrios de aceitao do requisito, uma vez
que aponta para a expectativa do cliente em relao funcionalidade. As outras perguntas
que completam os critrios de aceitao do requisito so as perguntas Quando? e
Onde?, pois nelas tambm so traduzidas as expectativas do cliente.
80
Contextualizao: Para cada requisito identificado, as
seguintes questes devem ser feitas:
03) Quando o requisito deve ser processado ou executado na Soluo?
A pergunta visa obter Requisitos que definam a frequncia de processamento, a
disponibilidade e alguns outros Requisitos para que a funcionalidade seja executada, depois
de implementada na Soluo.
04) Onde o requisito ser implementado?

Indica a localizao da funcionalidade (mdulos, ambientes, servidores especficos, etc.).
05) Quem utilizar o requisito?

A pergunta definir os usurios autorizados a utilizar a funcionalidade, aps a implantao.
Cada usurio identificado com a pergunta dever ser questionado tambm sobre os seus
Requisitos para a implementao da funcionalidade.
81
Aplicando as Tcnicas de Levantamento de Requisitos
Duas importantes questes que precisam ser abordadas em
relao s tcnicas de levantamento de requisitos so (AURUM;
WOHLIN, 2005):
Que tcnica(s) aplicar durante uma atividade de levantamento de
requisitos?
Quais dessas tcnicas so complementares?
Em ltima instncia, cada situao , em alguma extenso,

nica e, portanto, as respostas a essas perguntas so
dependentes do contexto do projeto (AURUM; WOHLIN, 2005).
De maneira geral, as principais tcnicas discutidas so
complementares.
82
Qualidade dos Requisitos: A especificao dos
requisitos deve satisfazer a uma srie de critrios para
ser considerada uma especificao que possui
qualidade, entre eles:
1.
Clareza
A clareza de um requisito expressa atravs de sua preciso, corretude e capacidade de ser
compreendido por todos os envolvidos no projeto. Para isso todos os conceitos presentes
na especificao devem ser representados pelo mesmo termo.
2.
Completude
Para determinado requisito, todas as necessidades a ele relacionado foram captadas do
cliente e registradas. (Aplicabilidade do roteiro de levantamento de requisitos)
3.
Origem
O requisito foi coletado de um fornecedor de requisito oficial?
83
Qualidade dos Requisitos:
4.
Consistncia
Garantir que no existam conflitos entre os requisitos e entre os artefatos gerados durante
o ciclo de vida do projeto.
5.
Implementveis
Garantir que determinado requisito no conflita com as tecnologias e arquiteturas
determinadas durante o ciclo de vida do projeto.
6.
Testveis
A verificao e validao do requisito ocorrem atravs de procedimentos de teste,
experimentos e provas ou atravs de acordos de aceitao previamente definidos.
Para garantir esse critrio, deve-se identificar as condies para a homologao do
Requisito, ou seja, todas as condies que permitam verificar que esse Requisito foi
atendido.
7.
Rastreveis
O requisito deve permitir a fcil determinao de seus antecedentes e precedentes.
84
Atributos dos Requisitos:
Identificador nico (RF-n, RNF-n, RN-n)

Descrio (Texto descritivo)
Prioridade (Baixa, Mdia, Alta)
Status (Identificado, Aprovado, Cancelado, Em Construo,
Em Homologao, Finalizado)
Origem (Nome do usurio, Documento analisado, etc.)
Dependncias
Etc.
85
Organizao dos Requisitos:
Narrativa livre
O sistema deve mostrar uma mensagem de status (finalizada, em
andamento, ...) para uma tarefa em intervalos no menores que 60
segundos (dificulta o entendimento - no a forma mais indicada)
Lista de Requisitos Funcionais (RFs)

RF-1: Uma mensagem de status deve ser mostrada na rea inferior
da janela (desenho da Fig.1)
RF-2: A mensagem deve ser atualizada a cada 60 segundos, com
tolerncia de 10 segundos para mais ou para menos
RF-3: A mensagem deve estar sempre visvel
86
Lista de Requisitos No Funcionais (RNFs)
Disponibilidade
RNF - DS-1: O sistema deve ficar disponvel por 99,5% do tempo nos dias teis,
das 6h s 22h
Eficincia
RNF - EF-1: Em condies de pico de uso, deve ter uma reserva de 25% de
capacidade de processamento e memria
RNF - EF-2: O clculo de interferncia deve ser finalizado com sucesso em
menos de 5 minutos
Flexibilidade
RNF - FL-1: Um novo tipo de sensor deve poder ser configurado no sistema em
menos de 3 horas
Integridade
RNF - IN-1: Transaes histricas dos consumidores s podero ser vistas por
usurios com privilgios de auditor
87
88
89
Exemplo de Requisito No Funcional (RNF)
90
Lista de Regras de Negcio (RNs)
RN-1: O valor total de um pedido igual soma dos totais dos itens do
pedido acrescido de 10% de taxa de entrega.
RN-2: Um cliente do banco no pode retirar mais de R$ 1.000 por dia de sua
conta.
RN-3: Os pedidos para um cliente no especial devem ser pagos
antecipadamente.
RN-4: A regra de consistncia de nmeros de CPF calculada como descrito
abaixo...
RN-5: sobre instncias (integridade referencial); ex: se X est em projeto,
ento X funcionrio;
RN-6: sobre comparaes; ex: salrio tem que ser maior que salrio mnimo;
RN-7: sobre tempo (cronolgico); ex: todo funcionrio deve ter sido
candidato antes;
91
Alguns problemas que tornam o levantamento

de requisitos uma tarefa difcil:
fronteiras so mal definidas

clientes/usurios especificam detalhes tcnicos desnecessrios.
clientes/usurios no sabem muito bem o que querem
clientes/usurios tm pouca compreenso das capacidades e limitaes
de um ambiente computacional
clientes/usurios no tm pleno entendimento do domnio do problema
clientes/usurios tm dificuldade de comunicar suas necessidades
clientes/usurios omitem informao que acreditam ser bvia
92
Alguns problemas que tornam o levantamento

de requisitos uma tarefa difcil:
clientes/usurios especificam requisitos que conflitam com as
necessidades de outros clientes/usurios
clientes/usurios especificam requisitos que so ambguos ou
impossveis de testar
Pode ser difcil compreender e coletar informaes quando existem
muitos termos desconhecidos
clientes/usurios que entendem o problema a ser resolvido podem ser
muito ocupadas
Polticas organizacionais podem influenciar nos requisitos de um
sistema.
93
Avaliao Parte 1
Descreva os requisitos (RFs, RNFs e RNs) de um

Gerenciador de Compromissos
Lista de requisitos funcionais
Devidamente contextualizados
Lista de requisitos no funcionais

Lista de regras de negcio
Entregveis
Os requisitos devem estar organizados em um
documento de definio de requisitos (a forma de
organizao faz parte da avaliao) e contendo os
atributos como prioridade, status, origem, etc.
94

5
95
2. Anlise de Requisitos
Uma vez identificados os requisitos, possvel iniciar a
atividade de anlise, quando os requisitos levantados
so usados como base para a modelagem do sistema.
Requisitos de usurio so escritos tipicamente em
linguagem natural, pois eles devem ser
compreendidos por pessoas que no sejam
especialistas tcnicos.
Contudo, til expressar requisitos mais detalhados
do sistema de maneira mais tcnica. Para tal, diversos
tipos de modelos podem ser utilizados (ex.: UML).
96
A atividade de anlise uma atividade de modelagem
conceitual, pois ela se preocupa com o domnio do problema e
no com solues tcnicas para o mesmo. Duas principais
perspectivas so consideradas nesta atividade:
Perspectiva estrutural:
Busca modelar os conceitos, propriedades e relaes do domnio
que so relevantes para o sistema em desenvolvimento.
Diagramas de Classes e Modelo de Entidades e Relacionamentos
so usados para modelar esta perspectiva.
Perspectiva comportamental:
visa modelar o comportamento geral do sistema, de uma de suas
funcionalidades ou de uma entidade especfica ao longo do tempo.
Diagramas de casos de uso, diagramas de atividades, diagramas de
estados e diagramas de interao so usados para esta perspectiva.
97
Os modelos criados durante a atividade de

anlise de requisitos cumprem os seguintes
papis (PFLEEGER, 2004):
prover uma base para o entendimento e
concordncia entre clientes e desenvolvedores
sobre o que o sistema deve fazer; e
prover uma especificao que guie os
desenvolvedores na demais etapas do
desenvolvimento, sobretudo no projeto,
implementao e testes do sistema.
98
Descries de Casos de Uso

No h um padro definido para especificar casos
de uso.
Diferentes autores propem diferentes estruturas,
formatos e contedos para descries de casos de
uso
Alguns mais indicados para casos de uso essenciais
e mais complexos, outros para casos de uso
cadastrais e mais simples.
Exemplos detalhados podem ser encontrados na Seo 5.3 [Falbo, 2012].
99
100
Linguagem de Modelagem Unificada (Unified

Modeling Language UML)
uma linguagem grfica padro para especificar,
visualizar, documentar e construir artefatos de
sistemas de software
somente uma linguagem e, portanto, apenas
parte de um mtodo de desenvolvimento de
software.
Ela independente do processo de software a ser
usado, ainda que seja mais adequada a processos
de desenvolvimento orientados a objetos.
101
UML
Diagramas de Classes: Um diagrama de classes
exibe um conjunto de classes e seus
relacionamentos. Proveem uma viso esttica da
estrutura de um sistema.
102
UML: Diagramas de Classes
103
UML
Diagramas de Casos de Uso:
Um diagrama de casos de uso mostra um conjunto de
casos de uso e atores e seus relacionamentos.
Os casos de uso descrevem a funcionalidade do sistema
percebida pelos atores externos.
Um ator interage com o sistema, podendo ser um
usurio humano, dispositivo de hardware ou outro
sistema.
Diagramas de casos de uso proveem uma viso das
funcionalidades do sistema, sendo importantes para a
organiz-las e model-las.
104
UML: Diagramas de
Casos de Uso
105
UML
Diagramas de Estados:
Mostram os estados pelos quais um objeto pode passar
ao longo de sua vida, em resposta a estmulos recebidos,
juntamente com suas aes.
Os diagramas de estados proveem uma viso dinmica
de um objeto, sendo importantes para modelar o
comportamento dos objetos de uma classe em resposta
ocorrncia de eventos.
106
UML: Diagramas de Estados
107
UML
Diagramas de Atividades:
Mostram a estrutura de um processo.
Proveem uma viso dinmica do sistema (ou de uma
poro do sistema) e podem ser usados tanto para
modelar processos de negcio quanto para modelar
funes do sistema.
Um diagrama de atividades d nfase ao fluxo de
controle entre objetos
108
UML: Diagramas de Atividades
109
UML
Diagramas de Interao: Diagramas de Sequncia:
Mostra um conjunto de objetos ou papis interagindo,
incluindo as mensagens que podem ser trocadas entre
eles.
So um tipo de diagrama de interao cuja nfase est
na ordenao temporal das mensagens.
110
UML: Diagramas de Sequncia
111
Fases de um projeto de BD
Mini-mundo
Coleta e Anlise de Requisitos

Requisitos de BD
Projeto Conceitual
Esquema conceitual
Projeto Lgico
Esquema lgico
Projeto Fsico
Esquema interno
112
Modelo de Entidades
e Relacionamentos (MER)
Representao semntica das estruturas de dados
mantidas num banco de dados
Foi proposto por Peter Chen em 1976
Possui vrias notaes:
- Relacionamentos como objetos do Modelo (Chen)
- Relacionamentos apenas como simples ligaes (Codd,

Martin)
113
Entidades
Uma entidade tudo aquilo sobre o qual se
deseja manter informaes.
Podendo representar:
objetos concretos: pessoas, livros, carros,
conceitos abstratos: empresas, eventos, embarques,
114
Entidades
Possui propriedades que a distingue de outras
entidades.
um subconjunto de objetos (instncias) que:
desempenha o mesmo papel semntico
possui os mesmos tipos de propriedades (atributos)
115
Entidades
Ex.:
Conjunto de todas as contas correntes de um banco
Conjunto de todos os empregados de uma empresa
Conjunto de todos os filmes de um produtor
Representao de entidades no diagrama E-R

(entidades e relacionamentos):
Empregado
Filme
Emprstimo
116
Entidades
Entidades devem ser descritas num Dicionrio de
Dados
Entidade: EMPREGADO
Descrio: Pessoa que mantm vnculo
empregatcio com a Empresa atravs de
um contrato de trabalho de acordo com a
legislao trabalhista
117
Entidades
Instncia: objeto de uma entidade com suas

respectivas propriedades que distinguvel
dos outros objetos.
Ex.: A entidade Empregado poderia ter a
seguinte instncia: Maria dos Anjos, 31
anos, Secretria, Solteira, R$ 800,00
118
Atributos
So as propriedades que caracterizam ou
descrevem uma entidade ou um relacionamento.
Ex.: A entidade CARRO poderia ter os seguintes
atributos:
Placa, fabricante, modelo, ano de fabricao, cor, preo
O relaciomento TRABALHA entre EMPREGADO e
PROJETO pode ter o atributo: horasTrabalhadas.
119
Atributos
Cada atributo possui um domnio que identifica o
conjunto de valores permitidos para aquele
atributo.
Ex.:
nome: domnio string(20)

salrio: domnio numrico
120
Atributos
Atributos devem tambm ser descritos no Dicionrio
de Dados:
Entidade: EMPREGADO
Atributo: Data de Admisso
Descrio: data na qual foi assinado o
contrato de trabalho entre a empresa e o
empregado
Domnio: data posterior a 03/01/78 (data de
criao da empresa) e a data de nascimento
do empregado
121
Atributos
Simples: atmico.
Ex.
Idade: numrico
Nome: cadeia de caracteres
Composto: contm sub-atributos que compem o

atributo.
Ex.: Endereo (rua, nmero, bairro, CEP, cidade, etc.)
122
Atributos
Simplesmente valorados: tm um nico valor para
uma instncia de uma entidade.
Ex.: PESSOA: Idade
Multivalorados: possuem vrios valores numa

instncia de uma entidade.
Ex.: PESSOA:TitulaoSuperior(nenhum, Bel., MSc., PhD)
Atributos derivados: podem ser determinados a

partir de outros atributos/entidades.
Ex. Idade e dataAniversrio
123
Relacionamentos
So funes que mapeiam um conjunto de instncias
de uma entidade em um outro conjunto de
instncias de outra entidade (ou da mesma entidade:
auto relacionamento).
Em outras palavras, so associaes entre diversas
entidades.
Ex.:
Um empregado trabalha num projeto
Um cliente possui conta bancria
Um filme possui vrios atores
124
Relacionamentos
1..N
Empregado
Projeto
trabalha
1..N
horas
matricula
nome
salrio
125
Relacionamentos
Empregado
0..N
supervisiona
0..1
126
Restries de Integridade
Caracterizam as restries nas quais os
relacionamentos entre entidades esto
submetidos (regras do negcio).
Ex.:
Todo empregado deve estar lotado num
departamento
Existe Cliente que no foi recomendado por Cliente
Toda Nota Fiscal deve ter pelo menos um item
discriminado
Toda multa deve estar associada a um carro
Existe carro sem multa associada
127
Podemos caracterizar um relacionamento em
termos de:
1. Cardinalidade: quantidade de instncias que
podem participar do relacionamento
2. Totalidade: obrigatoriedade da ocorrncia do
relacionamento entre as entidades envolvidas.
128
Tipos de Cardinalidade
Um_para_Um (1:1): uma instncia de uma entidade A
est associada a no mximo a uma instncia de uma
entidade B, e vice-versa.
Um_para_Muitos (1:N): uma instncia de uma entidade
A est associada a qualquer nmero de instncias da
entidade B. Porm, uma instncia da entidade B pode
estar associada, no mximo, a uma instncia da
entidade A.
129
Tipos de Cardinalidade
Muitos_para_Um (N:1): uma instncia da entidade A
est associada a uma instncia de B. Porm, uma
instncia de B pode estar associada a qualquer nmero
de instncias de A.
Muitos_para_Muitos(M:N): uma instncia da entidade
A est associada a qualquer nmero de instncias da
entidade B, e vice-versa.
OBS.: o uso de zero (0:1) ou (0:N) indica a

totalidade do relaciomento.
130
a1
a2
a3
a4
a5
A
b1
b2
b3
b4
b5
a1
a1
a2
a3
a4
a5
b1
a1
a2
a3
a4
a5
b3
N:1
b1
b2
b3
b4
b5
a2
a3
1:1
b2
1:N
B
b1
b2
b3
b4
b5
N:M
131
Representao clssica Chen
B
N
B
M
132
Chaves
Como distinguir as instncias de uma entidade?
Num Banco de Dados, isto feito atravs dos
atributos das entidades que formam as chamadas
chaves de identificao.
Toda instncia de uma entidade deve ter uma
chave de identificao, que deve ter algum valor
no nulo.
133
Chaves
Chave de identificao composta: uma chave
formada por mais de um atributo.
Ex.: Cenrio: sistema de controle de multas de
trnsito.
Premissas:
toda multa est relacionada a um carro,
carros devem ser de propriedades de pessoas que tenham
carteira de habilitao,
carteiras de habilitao so emitidas pelo DETRAN de cada
estado.
134
Chaves
Entidade Chave
Sigla do estado
Estado
Motorista Sigla do estado +
nmero
da
carteira
de
habilitao
Sigla do Estado
Carro
Nmero da carteira de motorista
Placa do Carro
Sigla do Estado
Multa
Nmero da carteira de motorista
Placa do Carro
Nmero de sequncia da multa
Obs.: Evitar usar chaves compostas sempre que possvel!
135
Chaves
Chaves de identificao definidas pelo usurio
concorrem entre si como chaves candidatas e so
sujeitas mudanas.
Ex.: Entidade : Departamento
Chaves candidatas:
1. Sigla do Departamento
2. Cdigo do Centro de Custo
3. Cdigo da Diretoria + Cdigo da Superintendncia +
Cdigo do Departamento
136
Chaves
O que fazer quando:
um departamento mudar de nome?
- for modificada a estrutura de codificao de
Centros de Custos?
- um departamento mudar de diretoria?
Soluo: chave de identificao prpria:

surrogate ou object identification (object id)
137
Chaves
Surrogates:
- criados para cada entidade (chave primria)
- identifica univocamente cada instncia da
entidade
- no precisa ser percebido pelos usurios
- no controlado pelos usurios (gerado
automaticamente pelo SGBD)
138
MER Estendido
Superclasses e Subclasses
Vimos que uma entidade usada para representar
um conjunto de instncias do mesmo tipo (Ex.
Empregado).
Porm, muitas vezes uma entidade tem
subentidades que necessitam ser representadas
explicitamente.
Ex. Empregado pode ser agrupado em: Secretria,
Engenheiro e Tcnico
139
MER Estendido
Estas subentidades so subconjuntos da entidade
Empregado, ou seja, cada instncia de uma
subentidade tambm uma instncia da entidade
Empregado. Ento dizemos que Secretria _uma
Empregada, Engenheiro _um Empregado e Tcnico
_um Empregado.
Este relacionamento _um caracteriza a herana. Ou
seja, a subentidade (subclasse) herda todos os
atributos e relacionamentos da superentidade
(superclasse).
140
MER Estendido
importante notar, que nem toda instncia
da superentidade membro de uma
subentidade.
Ex.: podemos ter empregados que no so nem
secretria, nem engenheiro, nem tcnico.
141
MER Estendido
Empregado
_um
Secretria
Engenheiro
Tcnico
142
Especializao
o processo de definir um conjunto de subclasses
de uma entidade (superentidade).
Podem-se ter vrias especializaes de uma
mesma entidade, baseado em caractersticas
distintas.
Ex.: A entidade Empregado pode tambm ser
especializada nas subentidades Assalariado e Horista.
143
Especializao
Existem pelo menos duas razes para usar
especializao num modelo de dados:
Certos atributos podem ser aplicados somente a
algumas instncias de uma entidade (subclasse), mas
no a todas.
Ex.:
Secretria: lnguas, velocidadeDigitao
Engenheiro: Especialidade, CREA
Motorista: nmero da carteira de habilitao, categoria
Alguns relacionamentos s se aplicam a algumas

instncias que pertencem a uma subclasse.
Ex.: Horistas pertencem_a Empreiteras
144
Generalizao
o processo inverso Especializao, isto , um
processo de sntese em que suprimimos as
diferenas entre vrias entidades (subclasses),
identificamos suas caractersticas comuns e as
generalizamos numa superclasse.
145
MER Estendido - Restries

Cobertura Total: cada instncia da superentidade
deve ser uma instncia de alguma subentidade.
Ex.: Todo Empregado deve ser Engenheiro, Secretria
ou Motorista
Cobertura Parcial: uma instncia de uma

superentidade pode no ser membro de nenhuma
subclasse.
Ex.: Pode existir empregado que no seja Engenheiro,
Secretria nem Motorista.
146
MER Estendido - Restries

Disjuno: uma dada instncia pode ser membro
de no mximo uma subentidade.
Ex. Empregado ou secretria, engenheiro ou tcnico.
Sobreposio: uma mesma instncia pode ser

membro de mais de uma subentidade.
Ex. Empregado pode ser engenheiro e tcnico.
147
DER - Exemplo
148
Mtodo de Anlise de Requisitos Funcionais
149
Avaliao Parte 2
Execute a anlise dos requisitos do

Gerenciador de Compromissos proposto na
Parte 1 da Avaliao
Entregveis:
Documento de Especificao de Requisitos com:
Diagrama de Entidades e Relacionamentos
Opcionais:
Diagrama de Classes
Diagrama de Casos de Uso
Outros Diagramas UML
150

5
151
3. Documentao de Requisitos
Basicamente so gerados dois documentos de

requisitos durante o processo de Engenharia de
Requisitos:
1. Documento de Definio de Requisitos
Resultado da atividade de Levantamento de Requisitos
2. Documento de Especificao de Requisitos

Resultado da atividade de Anlise de Requisitos
H muitos formatos distintos propostos na literatura.
152

Registro dos requisitos em um documento, de modo
que possam ser verificados, validados e utilizados como
base para outras atividades do processo de software.
Para que sejam teis, os requisitos tm de ser escritos
em um formato compreensvel por todos os
interessados.
Combinao de linguagem natural, modelos, tabelas e
outros elementos.
Formas de documentao de requisitos na Seo 3.4 [Falbo, 2012].
153

Uma estrutura simples contendo apenas quatro sees:
1. Introduo
Breve introduo ao documento, descrevendo seu propsito e
estrutura.
2. Descrio do Propsito do Sistema:

Descreve o propsito geral do sistema.
3. Descrio do Minimundo:
Apresenta uma viso geral do domnio, do problema a ser resolvido,
dos processos de negcio apoiados e das principais ideias do cliente
sobre o sistema a ser desenvolvido.
4. Requisitos de Usurio:
Requisitos funcionais, requisitos no funcionais e regras de negcio.
154

Tem como propsito registrar os requisitos escritos
a partir da perspectiva do desenvolvedor
Deve incluir os vrios modelos conceituais
desenvolvidos
Deve incluir a especificao dos requisitos no
funcionais detalhados.
155
1.
Introduo:
2.
breve introduo ao documento, descrevendo seu propsito e estrutura.
Modelo de Casos de Uso:
3.
diagramas de casos de uso e as descries de casos de uso associadas.
Modelo Estrutural:
4.
diagramas de entidades e relacionamento e diagrama de classes do sistema.
Modelo Dinmico:
5.
apresenta os modelos comportamentais dinmicos do sistema, incluindo os

diagramas de estados, diagramas de interao e diagramas de atividades.
Dicionrio do Projeto:
6.
apresenta as definies dos principais conceitos, servindo como um glossrio do

projeto.
Especificao dos Requisitos No Funcionais:
apresenta os requisitos no funcionais descritos no nvel de sistema, o que inclui

critrios de aceitao.
156

5
157
4. Verificao e Validao de Requisitos
As atividades de Verificao & Validao (V&V) devem ser

iniciadas o quanto antes no processo de desenvolvimento
de software, pois quanto mais tarde os defeitos so
encontrados, maiores os custos associados sua correo.
V&V de requisitos deve assegurar que:

1.
2.
3.
4.
Todos os requisitos do sistema tenham sido declarados de

modo no-ambguo
As inconsistncias, conflitos, omisses e erros tenham sido
detectados e corrigidos
Os documentos esto em conformidade com os padres
estabelecidos
Os requisitos realmente satisfazem s necessidades dos
clientes e usurios.
158
As atividades de Verificao & Validao (V&V) devem ser

iniciadas o quanto antes no processo de desenvolvimento
de software, pois quanto mais tarde os defeitos so
encontrados, maiores os custos associados sua correo.
Verificao x Validao
Verificao assegurar que o software esteja sendo
construdo de forma correta
Revises realizadas pela equipe do projeto (internamente).
Validao assegurar que o software que est sendo

desenvolvido o software correto
Revises realizadas pelos usurios ou clientes (externamente).

159
Verificao x Validao
Verificao
realizada em relao consistncia entre requisitos e

modelos e conformidade com padres
organizacionais de documentao de requisitos.
Validao
Tem de envolver a participao de usurios e clientes,

pois somente eles so capazes de dizer se os requisitos
atendem aos propsitos do sistema.
160
Tcnicas de Verificao e Validao

Revises Formais
Seguem um processo para realizao de revises (papis,

atividades, ferramentas, monitoramento de defeitos).
Revises Informais
Podem ser conduzidas pelos prprios autores dos

documentos, por clientes, usurios ou por qualquer
envolvido.
No seguem regras pr-estabelecidas.
So baseadas em checklists, guias e templates garantindo
161
padronizaes.

Revises Formais X Revises Informais
As revises formais devem ser combinadas

com revises informais para uma estratgia
de qualidade efetiva e dentro de custos
razoveis.
162

Revises Formais
Reviso em Pares (Peer Review)

Inspeo Formal
Walkthrough Estruturado
163

Revises Formais
Reviso em Pares (Peer Review)
Apenas uma pessoa, alm do autor, verifica o artefato.

Depende totalmente da experincia e conhecimento
do revisor.
considerada formal, pois existem checklists, guias,
templates, registro sistemtico de defeitos e
procedimentos especficos de anlise.
164

Revises Formais
Inspeo Formal
A inspeo de um artefato deve ser solicitada quando ele chegar a um

ponto de completude razovel.
No devem ser realizadas inspees de artefatos que ainda esto
mudando com frequncia.
Papis Participantes:
Autor
Moderador
Leitor
Escriba
Inspetor (Todos so inspetores)
Verificador
Atividades:
1. Preparao para a reunio
2. Conduo (leitura do documento)
3. Resultados da reunio
4. Anlise causal (em caso de alto grau de
defeitos)
165

Revises Formais
Walkthrough Estruturado
A diferena principal em relao s inspees que o autor descreve o

artefato para um grupo e solicita comentrios. (no tem o papel do leitor)
Em qualquer ponto do desenvolvimento de um artefato.
No deve durar mais de uma hora e mnimo de participantes trs

Papis Participantes:
Atividades:
Apresentador
1. Preparao para a reunio
Moderador
2. Conduo (rpida apresentao do artefato)
Escriba
3. Resultados da reunio
Especialista de manuteno
4. Anlise causal (em caso de alto grau de
Especialista de padres
defeitos)
Outros Revisores
166

Revises Informais
Demonstrao
Muito utilizada para demonstrao de artefatos ou prottipos para

clientes e usurios
Checklists de padres
Guias de padronizao
Comparao com Templates
167
Verificao e Validao Questes:
Os requisitos esto claros?

A fonte dos requisitos est identificada?
Os requisitos foram mostrados para essa fonte?
Os requisitos esto descritos de forma quantitativa?
Os requisitos esto relacionados via referncia cruzada?
Os requisitos violam alguma restrio do domnio?
O requisito testvel? Os testes foram especificados?
Os requisitos so rastreveis para os modelos e o cdigo
subsequente?
Existem requisitos implcitos?
168
Exemplos de Ambiguidade:
A janela deve abrir rapidamente

O sistema deve ser flexvel
O clculo deve ser eficiente
A interface com o usurio deve ser melhor que a atual
No devem ser mostradas muitas mensagens de erro
A exibio do mapa de navegao deve ser amigvel
169
Avaliao Parte 3
Execute verificao dos artefatos gerados nas

Partes 1 e 2 da Avaliao
Cada grupo ir verificar os artefatos de outro
grupo.
Tcnica: Walkthrough Estruturado
Entregveis:
Lista de Defeitos categorizados por prioridade e tipo.
Ambiguidade
Inconsistncia
Omisso
Erro
170

5
171
5. Gerncia de Requisitos
Mudana de software inevitvel
Novos requisitos surgem quando o software usado;

O ambiente de negcio muda;
Erros devem ser reparados;
Novos computadores e equipamentos so adicionados ao
sistema;
O desempenho ou a confiabilidade do sistema deve ser
melhorada.
Um problema-chave para as organizaes a

implementao e o gerenciamento de mudanas em
seus sistemas e a rastreabilidade entre os artefatos.
172
Objetivo
Controlar as mudanas nos requisitos
Permitir a anlise de impacto das
mudanas
173
Custo da evoluo
174
Distribuio de esforos de manuteno
(SOMMERVILLE, 2011)
175
Distribuio de esforos de manuteno
Percentuais de
Esforo por
Tipo de
Manuteno
(PFLEEGER,
2007)
176
O processo de evoluo de sistema
(Sommerville, 2011)
177
Implementao de mudanas
(Sommerville, 2011)
178
Solicitaes de mudana urgentes
Mudanas urgentes podem ter de ser
implementadas sem passar por todos os estgios do
processo de desenvolvimento de software
Se um defeito crtico de sistema tem de ser reparado;
Se mudanas no ambiente do sistema (por exemplo,
atualizao do OS) tm efeitos inesperados;
Se existem mudanas de negcio que necessitam de uma
resposta muito rpida (por exemplo, o release de um
produto concorrente)
179
Reparo de emergncia
(Sommerville, 2011)
180
Processo de Manuteno
Basili (1990) props trs paradigmas

diferentes para tratar a manuteno de
software:
(i) Conserto Rpido;
(ii) Melhoria Interativa;
(iii) Reuso Total
181
Conserto Rpido
Essa abordagem corresponde normalmente

preferida pelo mantenedor, justificando a
deciso pela urgncia da manuteno
(Visaggio, 2001).
182
Melhoria Interativa
prope inicialmente adequar e atualizar a
documentao de alto nvel que ser afetada, para
ento propagar as mudanas at o nvel de cdigofonte.
183
Reuso Total
Reuso total, consiste em construir um novo software,
utilizando componentes do software antigo e outros
disponveis em um repositrio.
184
Matriz de Reastreabilidade
Matrizes de rastreabilidade so os principais
artefatos produzidos na fase de gerncia de
requisitos.
Elas relacionam os requisitos identificados a um ou
mais aspectos do sistema ou do seu ambiente
Permitem obter um entendimento de como uma
modificao em um requisito vai afetar diferentes
aspectos do sistema.
185
Matriz de rastreabilidade de dependncia: indica como os
requisitos esto relacionados uns com os outros.
Matriz de rastreabilidade requisitos
fontes: indica a fonte
de cada requisito.
Matriz de rastreabilidade requisitos
subsistemas: indica
os subsistemas que tratam os requisitos.
Matriz de rastreabilidade requisitos de usurio
casos de
uso: indica os casos de uso que detalham um requisito
funcional ou tratam um requisito no funcional ou regra de
negcio.
186
187
Regressiva a partir dos requisitos
relaciona requisitos com suas origens (outros documentos
ou pessoas);
Progressiva a partir dos requisitos
relaciona requisitos aos artefatos do projeto (planos,
modelos de anlise e projeto, cdigo etc.);
Regressiva em direo aos requisitos
relaciona artefatos do projeto aos requisitos;
Progressiva em direo aos requisitos
relaciona as fontes (p.ex., documentos que precederam o
documento de requisitos) aos requisitos relevantes.
188
189
Engenharia de Requisitos e Normas e

Modelos de Qualidade de Processos de Software
CMMI
O CMMI um modelo de qualidade de processo desenvolvido
pelo (Software Engineering Institute SEI) da Universidade de
Carnegie Mellon.
Tem como objetivo fornecer diretrizes para a definio e
melhoria de processos de software de uma organizao
Cinco nveis de maturidade na representao em estgios:
1- Inicial
2- Gerenciado
3- Definido
4- Gerenciado Quantitativamente
5- Em Otimizao
190

CMMI - Nvel 2- Gerenciado

rea de processo: Gesto de Requisitos (REQM)
SG 1 Gerenciar Requisitos
SP 1.1 Entender os requisitos.
SP 1.2 Obter comprometimento com os requisitos.
SP 1.3 Gerenciar mudanas de requisitos.
SP 1.4 Manter rastreabilidade bidirecional dos requisitos.
SP 1.5 Garantir alinhamento entre o trabalho de projeto
(planos de projeto e produtos de trabalho) e requisitos.
191

CMMI - Nvel 3- Definido

rea de Processo: Desenvolvimento de Requisitos (RD)
SG 1 Desenvolver Requisitos de Cliente
SP 1.1 Levantar necessidades.
SP 1.2 Transformar necessidades dos interessados em requisitos de cliente.
SG 2 Desenvolver Requisitos do Produto

SP 2.1 Estabelecer os requisitos do produto e de componentes do produto.
SP 2.2 Alocar requisitos de componentes do produto.
SP 2.3 Identificar requisitos de interface.
SG 3 Analisar e Validar Requisitos

SP 3.1 Estabelecer conceitos e cenrios operacionais.
SP 3.2 Estabelecer uma definio da funcionalidade e dos atributos de
qualidade requeridos.
SP 3.3 Analisar requisitos.
SP 3.4 Analisar requisitos para balancear.
SP 3.5 Validar requisitos.
192

MPS.BR
O MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX,

2011) um programa mobilizador, que tem como objetivo a
melhoria de processo do software brasileiro.
Tem como objetivo definir e aprimorar um modelo de melhoria e
avaliao de processo de software, visando preferencialmente s
micro, pequenas e mdias empresas.
Sete nveis de maturidade:
G- Parcialmente Gerenciado
F- Gerenciado,
E- Parcialmente Definido
D- Largamente Definido
C- Definido
B- Gerenciado Quantitativamente
A- Em Otimizao
193

MPS.BR - Nvel G - Parcialmente Gerenciado

rea de processo: Gerncia de Requisitos
GRE 1. O entendimento dos requisitos obtido junto aos
fornecedores de requisitos;
GRE 2. Os requisitos so avaliados com base em critrios objetivos
e um comprometimento da equipe tcnica com esses requisitos
obtido;
GRE 3. A rastreabilidade bidirecional entre os requisitos e os
produtos de trabalho estabelecida e mantida;
GRE 4. Revises em planos e produtos de trabalho do projeto so
realizadas visando identificar e corrigir inconsistncias em relao
aos requisitos;
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do
projeto.
194

MPS.BR - Nvel D - Parcialmente Gerenciado

rea de processo: Desenvolvimento de Requisitos
DRE 1. As necessidades, expectativas e restries do cliente, tanto do produto
quanto de suas interfaces, so identificadas;
DRE 2. Um conjunto definido de requisitos do cliente especificado e priorizado
a partir das necessidades, expectativas e restries identificadas;
DRE 3. Um conjunto de requisitos funcionais e no-funcionais, do produto e dos
componentes do produto que descrevem a soluo do problema a ser resolvido,
definido e mantido a partir dos requisitos do cliente;
DRE 4. Os requisitos funcionais e no-funcionais de cada componente do
produto so refinados, elaborados e alocados;
DRE 5. Interfaces internas e externas do produto e de cada componente do
produto so definidas;
DRE 6. Conceitos operacionais e cenrios so desenvolvidos;
DRE 7. Os requisitos so analisados, usando critrios definidos, para balancear as
necessidades dos interessados com as restries existentes;
195
DRE 8. Os requisitos so validados.

Engenharia Requisitos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Requisitos

Professor: Msc. Alexandre Rafael Lenz

Palestrante nos Simpsios da Sociedade Brasileira de

Nome em citaes bibliogrficas: LENZ, A. R.;

A engenharia de requisitos estabelece uma base

Introduo Engenharia de Requisitos

Roger S. Pressman. Engenharia de Software - Uma

Objetivo Geral: Estudar as caractersticas,

Mapa dos requisitos

Atividades de Controle da Qualidade

Note que muitas solues so possveis para o

Importncia dos Requisitos

Atividades Relacionadas aos Requisitos

Nos estgios iniciais de um projeto,

Atividades Relacionadas aos Requisitos

Atividades Relacionadas aos Requisitos

Atividades Relacionadas aos Requisitos

Atividades de Controle da Qualidade

Definio de Engenharia de Requisitos

A Engenharia de Requisitos o processo pelo

Definio de Engenharia de Requisitos

A Engenharia de Requisitos de Software o ramo da

As vrias definies apresentadas

Requisitos Funcionais (RFs)

Requisitos Funcionais (RFs)

Requisitos No Funcionais (RNFs)

Requisitos No Funcionais (RNFs)

Classificao - RNFs (SOMMERVILLE, 2011):

Requisitos organizacionais: so derivados de metas,

Requisitos externos: referem-se a todos os requisitos

Classificao RNFs ISO 25000:

Requisitos No Funcionais (RNFs)

Ainda que a classificao em requisitos

Requisitos de domnio na concepo de

Nveis de Descrio de Requisitos

Os requisitos devem ser redigidos de modo a

Clientes requerem descries mais abstratas.

Nveis de Descrio de Requisitos

Nveis de Descrio de Requisitos

Nveis de Descrio de Requisitos

Esses nveis de descrio de requisitos so aplicados

Requisitos de sistema so elaborados como parte dos

Documento de Especificao de Requisitos: redefine os

Viso Geral do Processo de

A estrutura ou sequncia dessas atividades

Viso Geral do Processo de

Processos de engenharia de requisitos podem

Viso Geral do Processo de

Wiegers (2003) destaca alguns benefcios que

menor quantidade de defeitos nos requisitos,

Viso Geral do Processo de

(KOTONYA; SOMMERVILLE, 1998)

Viso Geral do Processo de

Vale destacar que no h limites bem definidos

Viso Geral do Processo de

Esse processo pode ser aplicado para

Viso Geral do Processo de

Atividades do Processo de Engenharia de

(KOTONYA; SOMMERVILLE, 1998)

Dimenses do levantamento de requisitos

Entendimento do domnio da aplicao:

entendimento geral da rea na qual o sistema ser aplicado;

entendimento dos detalhes do problema especfico a ser

entender como o sistema ir afetar a organizao e como