4/9/2008

Cristina ngela Filipak Machado

Consultora/Avaliadora em Melhoria de Processos
Analista de Sistemas Master da CELEPAR

Agenda de Aulas

Formao:

Mestre em Informtica Aplicada (PUCPr, 2002)

Graduao em Tecnlogo em Processamento de Dados
(UFPr, 1986)
Especialista em Sistemas de Informao Japo
Especialista em Informtica Industrial CEFET

Datas

Horrio

Contedo

05 de setembro

19:00 22:30

06 de setembro

8:00 16:30

Motivao
O que requisitos
Processo de Engenharia de
Requisitos Anlise da empresa
Processo de Engenharia de
Requisitos Elicitao de
Requisitos
Tipos de requisitos (funcionais e
no-funcionais)
Norma 14596 classificao de
requisitos
Processo de Engenharia de
Requisitos -Anlise de Requisitos
Processo de Engenharia de
Requisitos - Validao de
Requisitos

Atuao Profissional:

Analista de Sistemas Master da CELEPAR

Consultora para projetos de melhoria de processos usando
CMMI, MPS.BR e normas ISO e ABNT
Professora dos cursos de especializao distncia da
Universidade Federal de Lavras (MG)
Coordenou a CE de Gerncia de Processos de Ciclo de Vida
da ABNT com participao internacional na elaborao de
Normas ISO (12207, 15288, 9000-3)
Avaliadora Lder Experiente autorizada a conduzir avaliaes
MPS.BR em qualquer nvel e Coordenadora de Avaliao da
Instituio Avaliadora SWQuality
Co-editora do guia geral v1.0, do guia de avaliao v1.0 e
v1.1 do MPS.BR e do guia de implementao nvel F v1.0
2

Agenda de Aulas
Datas

Horrio

Contedo

19 de setembro

19:00 22:30

20 de setembro

8:00 11:45

20 de setembro

11:45 16:30

Processo de Engenharia de
Requisitos Comunicao de
Requisitos
Processo de Engenharia de
Requisitos Gerncia de Requisitos
Desenvolvimento de requisitos
como derivar os requisitos para o
projeto (Casos de Uso)
Engenharia de Requisitos nos
modelos de Qualidade
Como medir requisitos
(estimativas)
Descrevendo o seu processo de
especificao de requisitos
Validando o processo de
especificao de requisitos em sala
Re-escrevendo o processo de
especificao de requisitos
Exerccio integrado sobre requisitos

4/9/2008

O QUE VOC ESPERA DESTE

MDULO ?

Ttulo: Software Requirement, Autores:

Karl Wiegers, Editora: MS Press,
Publicao: (1999), Preo mdio: 23.99

Ttulo: More About Software REquirements,

Autor: Karl Wiegers, Editora: MS Press,
Publicao: 2006, Preo mdio: U$ 19,99

10

Ao final deste mdulo o participante estar apto a:

Compreender a importncia da Engenharia de Requisitos

Identificar requisitos de negcio, usurio e produto
Compreender tcnicas de Engenharia de Requisitos
Conhecer o processo de Engenharia de Requisitos
Utilizar templates para apoiar etapas da Engenharia de
Requisitos
Utilizar os conhecimentos adquiridos em exerccios
prticos, estudos de caso e projetos

Ttulo: The Unified Software

Development Process, Autores:
Ivar Jacobson, Grady Booch, James
Rumbaugh. Editora: Addison-Wesley,
Publicao: 1999, Preo mdio: U$ 50.00

Ttulo: The Rational Unified Process Made

Easy,Autores: Per Kroll e Philippe
Kruchten, Editora: Addison-Wesley,
Publicao: 2003, Preo mdio: U$ 40.00

11

Gerentes de Projeto
Analistas de Sistemas
Desenvolvedores
Membros da equipe de Teste
Participantes de grupos de processo (EPG) e
responsveis por programas de melhoria de
processo

Ttulo: The Rational Unified Process Made

Easy, Autores: Per Kroll e Philippe
Kruchten, Editora: Addison-Wesley,
Publicao: 2003, Preo mdio: U$ 40.00

Ttulo: Project Management with the IBM Rational

Unified Process, Autores: Dennis Gibbs, Editora:
IBM Press, Publicao: Julho/2006 ISBN
0321336399, Preo mdio: U$ 40.00

12

4/9/2008

IIBA International Institute of Business Analysis

05

www.theiiba.org
Blog.theiiba.org

Setembro

sexta

Por que os projetos falham?

O que temos feito para mudar?
A engenharia de requisitos
Exerccios

Tyner Blain
Tynerblain.com/blog

BPM Forum

SWEBOK Software Engineering Boby of

Knowledge

Br.groups.yahoo.com/group/BPM-Forum/

www.swebok.org

13

16

50% da nota - trabalho para ser entregue na

aula de 18/09/2008
40% da nota - exerccios em sala de aula

O que um
projeto de
sucesso?

17

05

Setembro

sexta

Por que os projetos falham?

O que temos feito para mudar?
A engenharia de requisitos
Exerccios

Um projeto de sucesso satisfaz seus clientes

e patrocinadores com resultados que
atendem aos seus objetivos, dentro das
restries de tempo e custo, produzindo
produtos de qualidade, ...
mantendo e promovendo relaes
harmoniosas entre os envolvidos, incluindo
os executores, e contribuindo para o
aprendizado da organizao.
[Daniel Gasnier, 2000]

15

18

4/9/2008

Falhas em projetos de software continuam

sendo relatadas em relao ao atendimento
do prazo, custo, esforo e qualidade
Standish Group
31% foram cancelados
53% acima dos custos em 50%
93% atrasam

Gordon
63% projetos atrasam
42% acima do
oramento

Curtis & Statz

60% projetos atrasam

Modelos de melhoria e processo

Fonte: Standish Group, 2000 - The Chaos Report

22

Na dcada de 90 alguns estudos foram

conduzidos:
DOD (Departamento de Defesa do Estados Unidos)
Standish Group
Gordon

75% de todos os grandes sistemas

intensivos de software falham
Pobre gerenciamento por parte do
desenvolvedor e adquirente

....e no Brasil ?

Em 2002, foi conduzida uma pesquisa no

Brasil em 144 projetos, onde:

12,8% dos gerentes de projeto
desconhecem o seu custo;

41,43% dos projetos atrasaram, mas foi
considerado sucesso e muito sucesso, pelo
gerente, projetos que atrasaram 90%;

50,68% dos projetos utilizaram mtricas
para planejamento
[MACHADO, 2002]

O problema no de desempenho
tcnico

4/9/2008

70% Cronogramas longos

65% Estimativa de custo inadequada
60% Documentao excessiva
50% Mdulos com propenso a erros
35% Projetos cancelados

Se o carro tivesse a mesma evoluo do

computador um Rollys Royce custaria
$100,00 hoje. Mas, explodiria uma vez ao ano

Robert Cringely

[CAPERS, 1996]

Por que os
projetos
falham?

60% Alto custo de manuteno

50% Problemas entre o contratante e
contratado
45% manter os requisitos do usurio
30% critrios de aceitao no definidos
20% propriedade legal do software e
produtos entregues

[CAPERS, 1996]
26

Instrues
Objetivo: Contextualizar as falhas em projetos
Descrio: Liste algumas das principais falhas
que a equipe teve nos projetos de
desenvolvimento em que participou
Tempo: 15 minutos.
Forma de trabalho: equipe de 3

Requisitos no definidos de forma adequada

Requisitos incorretos
Projeto afetando um grande nmero de
departamentos ou unidades do usurio
Requisitos no esto claros
Mudanas contnuas dos requisitos
Planejamento inadequado do prazo
Mudanas contnuas dos objetivos e escopo
do projeto
Reestruturao organizacional durante o
projeto

[MACHADO, 2002]

4/9/2008

Influncia poltica no projeto

Planejamento inadequado dos recursos
necessrios
Presso excessiva de prazo
Baixa qualidade dos produtos intermedirios
e finais
Alto nvel de complexidade tcnica
Cliente resistente a mudanas
Clientes no comprometidos com o projeto
Fonte: Standish Group, The Chaos Report
[MACHADO, 2002]
34

Denver International Airport

Projeto: Inaugurao de um novo aeroporto na
cidade de Denver para substituir o antigo, cuja
capacidade estava esgotada.
Deciso: Inaugurao adiada por 25 dias
Causa: problemas na integrao do hardware e do
software do sistema de esteira de bagagens.

Prejuzo:
U$ 12.5 milhes
Fonte: Standish Group, The Chaos Report
Fonte: www.sei.cmu.edu (SECMM-95-01)

32

35

Sidney Water Corporation

Projeto: Automao de informaes de cliente e
faturamento do maior provedor de gua da
Austrlia.
Deciso: cancelado em 2002
Causa: planejamento inadequado, inmeras
solicitaes de mudanas, estouro no cronograma
e no oramento.
Prejuzo:
U$ 33.2 milhes

Fonte: Standish Group, The Chaos Report

33

Fonte: www.spectrum.ieee.org/print/1685

36

4/9/2008

ISO/IEC TR 15504
ISO/IEC 12207
ISO/IEC 9126 ...

Setembro

05
sexta

Por que os projetos falham?

O que temos feito para mudar?
A engenharia de requisitos
Exerccios

PMBOK
CMMI PRINCE2
ITIL TSP PSP ...

OO UML
CASE RUP XP
SCRUM EVO ...
XML JAVA
HTML ASP C++
.NET J2EE ...

37

40

... medida que olhamos um horizonte de uma dcada

frente, no vemos bala de prata alguma. No apenas no
existem balas de prata em vista, como a natureza do
software o torna nico, o que faz com que no exista
qualquer inveno que far pela produtividade,
confiabilidade e simplicidade do software o que a eletrnica,
os transistores e a integrao em larga escala fizeram pelo
hardware de computador.

Se tantos projetos
de TI falham, o que
est sendo feito
para mudar?

Frederick Brooks
No Silver Bullet
38

Sheila Reinehr

41

Guia

XP

SEI

Kent Beck

Modelo

IESE

PESSOAS
Jacobson, Booch e Rumbaugh
DADOS

FUNDAMENTAIS

APOIO

AQUISIO

DOCUMENTAO
GER DE CONFIG.
GARANTIA DA QUAL.
VERIFICAO
VALIDAO
REVISO CONJUNTA
AUDITORIA

FORNECIMENTO
MANUT.

Palmer & Mc Menamim

Edward Yourdon

DESENV.
OPERA.

1970

PROBLEMA

Resultado

INFRAESTRUTURA
TREINAMENTO

ISO/IEC SC7

Resultado

Chris Gane
Trish Sarson

Razo

PROJETO

SEI

RESOLUO DE PROB.

Sheila Reinehr

Participantes

ORGANIZACIONAIS
GERNCIA
MELHORIA

PROCESSO

Soluo

PRODUTO

SEI

1980

1990

1995

2000
39

Sheila Reinehr

42

4/9/2008

Normas
ISO International Organization for
Standardization

Projeto um empreendimento temporrio

que visa produzir um produto ou servio
nico.

ABNT Associao Brasileira de Normas Tcnicas

Modelos

[PMI,2004]

Universidades
Empresas
Governo

Sheila Reinehr

43

[PAULK et alli, 1994]

TSP
PSP
RUP
modelos

Ainda no publicada

modelos

normas

Sheila Reinehr

46

A parte mais difcil de construir

um sistema de software
decidir precisamente o que
construir. Nenhuma outra
parte do trabalho conceitual
to difcil quanto estabelecer
os requisitos tcnicos
detalhados (...). Nenhuma
outra parte danifica tanto o
sistema resultante se for feita
de forma errada. Nenhuma
outra parte mais difcil de
retificar posteriormente.

Processo de software pode ser definido como um

conjunto de atividades, mtodos, prticas e
transformaes que as pessoas empregam para
desenvolver e manter software e produtos
relacionados (...).

CMM-I
MPS.BR
ITIL

PMBOK
PRINCE

NBR ISO/IEC 12207

NBR ISO 9000-3
ISO/IEC TR 15504

Processo de
Gerncia de
Requisitos
(normas)

Processo de
Gerncia de
Requisitos

[BROOKS, 1987]

(modelos)

normas

Sheila Reinehr

44

Sheila Reinehr

47

Independentemente de quo bem uma

organizao gerenciada, a qualidade do
trabalho de software governada pelas
prticas dos engenheiros de software.

() produto refere-se no somente ao cdigo que

entregue, mas ao sistema como um todo. () Um
sistema o conjunto completo dos artefatos que o
representam de forma que ele possa ser
compreendido pela mquina ou pelas pessoas ()

[GIBSON, 1997]

[JACOBSON et alli, 1999]

NBR ISO/IEC 9126

NBR ISO/IEC 14598
normas
Sheila Reinehr

45

Sheila Reinehr

P-CMM

No h

modelos

normas
48

4/9/2008

Experincias passadas
Requisitos do processo

definir, analisar, simular,

medir e melhorar os
processos da
organizao

medir, controlar,
modificar e gerenciar os
projetos de software
construir o produto de
software;

Engenharia do
processo
Requisitos do projeto
Requisitos do produto

Modelo do
processo
Gerenciamento de
projeto

Gerncia de
Requisitos

Processo de
desenvolvimento
Engenharia do
produto
Produto de
software
Sheila Reinehr

05

Setembro

Sintomas Tpicos de ausncia de Gerncia de

Requisitos:
Necessidades do negcio ou do usurio no
satisfeitas
O projeto parece nunca ter fim
Desentendimentos constantes entre a equipe e o
cliente
Falta de clareza sobre as prioridades
Requisitos instveis

sexta

Por que os projetos falham?

O que temos feito para mudar?
A engenharia de requisitos
Exerccios

50

52

53

A farmcia que adquiriu o sistema de

automao expandiu a sua rede e necessita
que o sistema permita consultar o estoque
de todas as suas filiais. A equipe estimou
prazos e custos e efetuou a alterao. No
momento da implantao, o cliente disse que
havia solicitado que houvesse tambm
atualizao distribuda entre as filiais em
tempo real.

Sheila Reinehr

51

4/9/2008

REQM e custo de reparo de problemas

Problemas de Software so de
100 a 1000 vezes mais caros para se
detectar e resolver depois da implantao

Custo do Reparo do Software

Custo

Custo das Oportunidades

Perdidas

Para ajudar a entender a

necessidade do usurio

Custo dos Clientes Perdidos

Iniciao

Elaborao

Construo

Transio

Anlise de negcio no anlise de

requisitos
Analisar o negcio
Como a organizao trabalha
A razo de sua existncia
Seus objetivos e metas
Como ela busca estes objetivos
E o que ela precisa mudar para melhor atender
esses objetivos
.....

Analista de Negcio valem Ouro

Hot commodity [ Fonte CIO Magazine/2007 ]

Por que ser?

Modelagem

Para ajudar a definir uma

soluo para o negcio

[ Fonte CIO Magazine/2007 ]

De Negcio
De Processos de Negcio
De Dados
De Sistemas

Engenharia de Requisitos

Tcnicas de Entrevistas e Pesquisas

Estruturao de Requisitos
Redao de Casos de Uso
Teste

10

4/9/2008

Observar, ouvir e entender

Comunicar
Pensar sistemicamente
Modelar e organizar
Negociar e vender
Criticar e criar

Uma abordagem sistemtica para elicitar,

organizar e documentar os requisitos do
sistema e um processo que estabelece e
mantm um acordo entre o cliente e a equipe
de projeto a respeito das mudanas nos
requisitos.
[Leffingwell & Widrig, 2000]

Sheila Reinehr

Modelagem de
Negcio
Entendendo o
negcio

Processos
de
Negcio

Objetivos
de
Negcio

Objetivos
e Metas

Engenharia de
Requisitos

Requisitos
noFuncionais

Escopo do
Produto

Regras de
Negcio
Requisitos
do Usurio

Casos de
Uso
Requisitos
do Usurio

Requisitos
Funcionais

De acordo com o Institute of Electrical and

Electronics Engineers - IEEE, o processo de
aquisio, refinamento e verificao das
necessidades do cliente chamado de
engenharia de requisitos [IEEE1984].

Entendendo o
usurio

Requisitos
do Negcio

64

Um requisito descreve uma condio ou

capacidade que o sistema deve estar em
conformidade [Unified Process]
Pode ser derivado das necessidades dos
usurios, ou estabelecido em um contrato,
padro, especificao ou outro documento
imposto formalmente [IEEE]
Pode estar explcito ou implcito

Requisitos
da Soluo

11

4/9/2008

Definir o sistema
Identificar os requisitos do produto
Identificar os atributos dos requisitos, como:

Linguagem Natural
Linguagem Rigorosa (UML)
Linguagem Formais (inferncias)

O que gerncia de requisitos?

Elaborar a viso geral da soluo

Divulgar a viso geral para os envolvidos
Alinhar sua equipe com uma compreenso comum do
sistema

Assegurar que:
Sua equipe identifique, crie, teste e documente o
sistema certo para seu cliente
Todos os membros da equipe tenham acesso aos
requisitos
Os requisitos representem um contrato entre o
cliente e sua equipe

As chaves da gerncia de requisitos:

Analisar o problema
Compreender as necessidades dos envolvidos
Definir o sistema
Gerenciar o escopo do sistema
Refinar a definio do sistema
Gerenciar mudanas de requisitos

Por que os requisitos mudam:

No foram feitas as perguntas certas s pessoas
certas no momento certo
O problema que est sendo resolvido mudou
Os usurios mudaram de idia ou de ponto de
vista
Oramentos foram reduzidos
Surgimento de novas tecnologias
Concorrncia

Uma abordagem sistemtica para

identificar, documentar, organizar e
rastrear mudanas de requisitos

prioridade do cliente (alta, mdia, baixa)

valor percebido pelo cliente (alto, mdio, baixo)
estabilidade (alta, mdia, baixa)
complexidade (alta, mdia, baixa)
origem (cliente, marketing, analistas de negcio)
risco (alto, mdio, baixo)
tamanho (homens/hora)

A mudana inevitvel e positiva

Gerenciar mudanas de requisitos:

Submeter as solicitaes de mudana ao processo
de gerncia de configurao
Vincular as solicitaes aceitas aos requisitos
Analisar o impacto sobre os requisitos relacionados
Comunicar as mudanas aos envolvidos

Proteger os requisitos contra mudanas

desnecessrias

12

4/9/2008

Gerncia de Requisitos = Mudanas sob Controle

Business Analysis Planning

Enterprise
Analysis

Elicitation

Requirements
Analysis

Solution
Assessment
and
Validation

Requirements Management and Communication

Fundamentals

73

Sheila Reinehr

Setembro

06

Business Analysis Planning

sbado

Processo de Engenharia de Requisitos

Anlise da Empresa
Elicitao de Requisitos
Anlise de Requisitos

Enterprise
Analysis

Elicitation

Requirements
Analysis

Solution
Assessment
and
Validation

Requirements Management and Communication

Fundamentals

74

Especificao
Aquisio
Elicitao

Modelagem

Validao

Anlise

Analisar o Problema
Obter o acordo de todas as partes sobre o
problema a resolver
Documentar o problema e a soluo proposta
Usar uma linguagem comum para reduzir a
ambigidade

Compreender o problema que sua

soluo ir resolver

13

4/9/2008

Avaliar a situao do negcio

Descrever o negcio atual
Identificar os processos do negcio
Refinar a definio dos processos
Projetar a realizao dos processos de
negcio
Refinar os papis e responsabilidades
Explorar a automao do processo
Desenvolver um modelo de domnio

Definir o problema
Definir o modelo de negcio
Definir o escopo do projeto qual problema
o projeto ir enderear
Definir os requisitos de negcio
Definir um estudo de viabilidade em relao
ao projeto
Preparar os Casos de Uso de Negcio

Eu possuo uma clnica mdica e atendo meus pacientes a mais de 15 anos..

Poxa, eu tenho atendido tanta gente que atualmente tenho esta sala aqui
somente para guardar as fichas de meus pacientes..
As coisas que quero controlar me parecem bastante simples.. No quero
diminuir o trabalho de minha secretria quanto ao agendamento das
consultas, ela deve apenas cadastrar os novos pacientes.... Quero com este
sistema poder controlar as consultas de tal forma que o paciente entre no
meu consultrio e eu j possa ter lido todo o seu histrico.. Isto , outras
vezes que ele esteve na clnica, qual a doena que ele tinha, os sintomas, os
medicamentos que foram ministrados, etc.. Alis no me interessa o
medicamento, eu quero saber o seu princpio ativo.. que existem hoje
tantas opes de remdios ...
Ah, as crianas!!... eu tenho atendido muitas delas.!!. quero trat-las como
um paciente normal, mas preciso saber quem o responsvel por ela e
tambm quero acompanhar sua taxa de crescimento e peso....
Acho que fazer isso tudo funcionar melhor vai ser bastante simples.. Antes
que eu me esquea, tambm preciso manter os endereos de meus
pacientes, para poder enviar um carto de natal, ou um "feliz aniversrio" ...
Ah! Tambm tenho outras clnicas no interior que representam o meu
tratamento

Tenho mais de 20.000 pacientes cadastrados. Mas, nem todos aparecem,

seno estaria rico pois atendo pela Unimed, snif, snif.. Tambm atendo
particular e cobra 100,00 a consulta. Normalmente, o meu faturamento
mensal de 600.000 com todas as outras clnicas e cirurgias
O aluguel dos equipamentos para eu fazer cirurgias so caros...
Quero com este sistema melhorar o atendimento aos pacientes e tambm
controlar as minhas outras clnicas, pois acho que estou perdendo $$..
Quero que as minhas clnicas dobrem o nmero de pacientes
Sou bom e meu mtodo bom porque tenho este mtodo prprio de
atendimento e cirurgia esttica e de reparao. Mas, tem vrios outros
mdicos que acham que eles sabem mais do que eu, ento fico preocupado
com a concorrncia, porque afinal medicina no s comrcio.
Outra coisa, o meu preo acima do mercado. Mas, vale a pena!!!

Instrues
Objetivo: Compreender a anlise de negcio
Descrio: Listar os requisitos de negcio e
defina o escopo do projeto
Tempo: 30 minutos.
Forma de trabalho: equipe de 3

Business Analysis Planning

Enterprise
Analysis

Elicitation

Requirements
Analysis

Solution
Assessment
and
Validation

Requirements Management and Communication

Fundamentals

14

4/9/2008

Processo da Engenharia de Requisitos

Elicitao de Requisitos: Atividades

Establish objectives

Understand background

Organise knowledge

Collect requirements

Business
goals

Organisational
structure

Stakeholder
identification

Stakeholder
requirements

Problem to be
solved

Application
domain

Goal
prioritisation

Domain
requirements

System
constraints

Existing
systems

Domain
knowledge
filtering

Organisational
requirements

Rascunho dos Requisitos

Elicitao de Requisitos

ELICITAR: descobrir, tornar explcito, obter o mximo

de informaes para o conhecimento do objeto em
questo [SWEBOK]

ELICITAR = Eliciar + Clarear + Extrair + Descobrir ,

tornar explcito, obter o mximo de informao para
o conhecimento do objeto em questo.

Elicitao de Requisitos : Tcnicas

Tcnicas especiais que podem ser usadas para

coletar conhecimento sobre os requisitos dos
usurios

Eliciar = Fazer sair, extrair, trazer tona (a

verdade).
leiaute

Entrevistas
Leitura de documentos
Questionrios
Cenrios
Observaes e anlise sociais (etnografia)
Reuso de requisitos
Prototipagem

Elicitao de Requisitos

Algumas dificuldades ...

Usurios podem no ter uma idia precisa do
sistema por eles requerido
Usurios tm dificuldades para descrever seu
conhecimento sobre o domnio do problema
Usurios e Analistas tm diferentes pontos de vista
do problema (por terem diferentes formaes)
Usurios podem antipatizar-se com o novo sistema
e se negarem a participar da elicitao (ou mesmo
fornecer informaes errneas)
No existir muito tempo para a elicitao
Preparao inadequada dos engenheiros
Stakeholders no estarem convencidos da
necessidade de um novo sistema

O profissional de ER deve selecionar as tcnicas a

serem utilizadas e estabelecer de que maneira
elas sero integradas
importante utilizar uma tcnica de modelagem
de apoio para que os fatos elicitados fiquem
corretamente representados para futuro
tratamento
A escolha das tcnicas e seu esquema de
integrao depender do problema e da equipe
participante
O ponto importante ter conhecimento sobre
estas tcnicas e identificar onde uma tcnica
superior a outra

15

4/9/2008

Sintomas:

Falta de requisitos, requisitos documentados

pobremente que resultam em confuso entre a
equipe e o cliente
Produtos de trabalho do projeto, que interpretam
de forma inconsistente os requisitos
Tempo desordenadamente longo para obter o
acordo sobre o design do produto

Por que se preocupar com isto? Porque

Produtos no usveis e clientes insatisfeitos levam
para perda de negocios futuros
Tempo e recursos desperdiados para construir um
produto de acordo com requisitos que o cliente no
deseja, pode comprometer o seu lucro
Equipe se desgasta em refazer trabalho em que os
requisitos foram re-interpretados mais uma vez
O potencial para gastos excessivos com a finalidade
de atingir expectativas do cliente aumenta, quando
os requisitos no foram bem identificados

Funcionais e no-funcionais
Requisitos e no-requisitos
Essencial, importante, desejvel, ...
Usurio e sistema
Complexo, simples, ...
...
Produto, projeto, organizao
...

O que o software deve fazer??

O que o cliente deseja??
Quais as restries??
Quais os componentes??
Quem vai utilizar o software??
Descrio e especificao de um software
ou sistema

Descrevem a funcionalidade do produto

ou servio do software/sistema

Requisitos funcionais do usurio podem ser

sentenas de alto nvel sobre o que o
sistema deve fazer
Propostas Tcnicas e Comerciais, Manuais de
procedimentos, etc.

Requisitos funcionais do sistema devem

descrever os servios do sistema em
detalhes
Documento de requisitos refinado, arquitetura do
software, etc.

16

4/9/2008

Requisitos de Software

Restringem os requisitos funcionais

O QUE
Funcionalidade

Requisitos
de produto
Requisitos
Organizacionais
Requisitos
Externos
Requisitos
de
Produto

Restries
Confiabilidade

Requisitos
que so
uma consequncia
de

Requisitos
organizacionais
Requisitos
de fatores
so
Requisitosque
quesurgem
especificam
que oque
produto
polticas
e procedimentos
externos
sistema
e comportar
aoorganizacionais.
processo
entregueaotem
que se
dedeum modo
Ex: Padres de processos usados, requisitos
desenvolvimento.

Requisitos externos
particular
de iimplementao
etc.
Ex:Requisitos
legislativos,
exigncia
de
Ex: Velocidade
de execuo,
confiabilidade,
interoperabilidade
usabilidade, etc. etc.

Usabilidade
Eficincia
Manutenibilidade
Portabilidade
ISO/IEC 9126 / NBR 1359

Requisitos de Software
Non-functional
requirements

Product
requirements

Efficiency
requirements

Reliability
requirements

Usability
requirements

Performance
requirements

Somerville 2003

Organizational
requirements

Portability
requirements

Delivery
requirements

External
requirements

Interoperability
requirements

Implementation
requirements

Space
requirements

Ethical
requirements

Standards
requirements

Legislative
requirements

Privacy
requirements

Safety
requirements

FUNCIONALIDADE - Satisfaz as necessidades?

SUBCARACTERSTICA

PERGUNTA CHAVE

Adequao

Prope-se a fazer o que apropriado?

Acurcia

Faz o que foi proposto de forma correta?

Interoperabilidade

capaz de interagir com os sistemas

especificados?

Conformidade

Est de acordo com as normas, leis, etc.?

Segurana de Acesso

Evita acesso no autorizado a programas

e dados?
ISO/IEC 9126 / NBR 1359

Requisitos de Software
Qualidade
de produto
de software

CONFIABILIDADE - imune a falhas?

SUBCARACTERSTICA

Funcionalidade

Adequao
Acurcia
Interoperabilidade
Segurana de
acesso
Conformidade

Confiabilidade

Maturidade
Tolerncia a Falhas
Recuperabilidade

Usabilidade

Inteligibilidade
Apreensibilidade
Operacionalidade

Eficincia

Manutenibilidade

Comportamento em
relao ao tempo
Comportamento em
relao aos recursos

Analisabilidade
Modificabilidade
Estabilidade
Testabilidade

Portabilidade

Adaptabilidade
Capacidade para
ser instalado
Conformidade
Capacidade para
substituir

Maturidade

PERGUNTA CHAVE

Com que freqncia apresenta falhas por

defeitos no software?

Tolerncia a Falhas

Ocorrendo falhas, como ele reage?

Recuperao

capaz de recuperar dados em caso de falhas?

ISO/IEC 9126 / NBR 1359

17

4/9/2008

Manutenibilidade
Flexibilidade
Testabilidade

Portabilidade
Reusabilidade
Interoperabilidade

Habilidade de ser
Alterado

Adaptabilidade a
Novos Ambientes

Caractersticas
Operacionais

Corretitude
Confiabilidade

Eficincia
Integridade
Usabilidade
Modelo de McCall

Software para
Controle de Estoque

Requisitos

Benefcio Esforo

Risco

Impacto

Estabilid
ade

R1: Critrios de
salvamento,
recuperao,
classificao e filtro

Mdio
Alto

Baixo

Baixo

Baixo

Alto

R2: Capacidade de
visualizar a excluso de
um requisito da janela

Mdio

Mdio
Alto

Mdio

Baixo

Mdio

R3: Suporte ao acesso a

tipos de dados
concorrentes

Mdio

Mdio

Mdio
Baixo

Baixo

Mdio

R4: Mostrar os atributos

de um requisito a partir
de um documento texto

Mdio

Mdio

Mdio

Baixo

Mdio
Alto

R5: Wizard para a

criao de um novo
projeto

Mdio
Alto

Alto

Mdio
Alto

Alto

Mdio

Software Embutido
em Satlite

PROCESSO DE
CONSTRUO
requisitos

Caractersticas Selecionadas
usurio

Funcionalidade

requisitos
atendidos

Confiabilidade

PRODUTO

Usabilidade
Eficincia

PRODUTO COM QUALIDADE

Manutenibilidade
Portabilidade

Grau de
importncia

Estabilidade

Fonte

Tipo

Ponto de
vista

Requisitos

Esforo

Benefcios

Declarao deve ser precisa

Requisitos ambguos podem ser
interpretados de forma diferente por pessoas
diferentes (exemplo: desenvolvedores e
clientes)
Conflitos entre requisitos diferentes so
comuns em sistemas complexos

Status

Risco

Impacto

18

4/9/2008

Exemplo: em um sistema de uma nave

espacial

Para minimizar o peso, a quantidade de chips no

sistema deve ser minimizada
Para minimizar o consumo de energia, chips de
baixo consumo devem ser utilizados
Contudo, o uso de chips de baixo consumo
significa que mais chips vo ter que ser usados.
Qual o requisito mais crtico???

Inicialmente: deve definir O QUE o sistema deve

fazer e no COMO
Posteriormente: pode trazer detalhes do COMO
deve ser implementado

Falta de clareza
Preciso difcil sem tornar o documento difcil para
leitura

Confuso de requisitos
Requisitos funcionais e no funcionais tendem a ser
misturados

Fuso de requisitos

Ambigidade

Flexibilidade
A mesma coisa pode ser dita de vrias formas
diferentes na especificao

Falta de modularizao

Diversos
nveisnica??
de abstrao
Identificao
Gesto
do requisito
O requisito
pode ser composto ??

Discusso
!!! para estruturar
Estruturas de LN so
inadequadas
requisitos do sistema

usado em todo o processo de

desenvolvimento de software para garantir
a conformidade

Exemplo de formulrio para identificao de requisitos

Caracterstica de Qualidade:
Id.

Descrio do Requisito

Prioridad
e

Fonte

Alocad
o-S/N

Prioridad
e

Fonte

Alocad
o-S/N

Observaes:

Vrios requisitos diferentes podem ser expressos juntos

Os leitores e escritores do requisito devem interpretar as
mesmas palavras da mesma forma.
LN naturalmente ambgua o que torna o seu uso muito
difcil

O documento de requisitos a
documentao oficial do que requerido
dos desenvolvedores do sistema [SWEBOK]
refinado na medida que o
desenvolvimento evolui:

Id.

Descrio do Requisito

Observaes:

Para os requisitos, determinar:

quais sero alocados ou no no projeto
em qual momento (verso/iterao) do projeto
sero implementados
quem sero os responsveis

Necessidade de uma notao mais apropriada??

Podemos reus-lo??
Como solucionar alguns dos problemas citados??

19

4/9/2008

Gerenciar o escopo do
sistema
Requisito

Esforo

Valor
Agregado

001

002

003

004

Opo A: 001, 002, 003 e 004

Valor
Esforo

13

Valor/Esf

1.4

18

Opo B: 002 e 003

13 meses

Declarao deve ser precisa

Requisitos ambguos podem ser
interpretados de forma diferente por pessoas
diferentes (exemplo: desenvolvedores e
clientes)
EXEMPLO: O software deve ter visualizadores
apropriados para leitura dos documentos

Valor

12

Considere o termo visualizadores apropriados

Esforo

Valor/Esf

1.7

Inteno do usurio - visualizadores de propsito

especial para cada tipo de documento diferente

Interpretao do desenvolvedor - um visualizador
textual que mostra o contedo do documento

7 meses

Documento de Requisitos
Usurios Tpicos

Refinar a definio do sistema:

Detalhar os requisitos
Identificar os relacionamentos entre os requisitos
de software
Validar a soluo com os envolvidos (stakeholders)

System customers

Specify the requirements and

read them to check that they
meet their needs. They
specify changes to the
requirements

Managers

Use the requirements

document to plan a bid for
the system and to plan the
system development process

System engineers

Use the requirements to

understand what system is to
be developed

System test
engineers

System
maintenance
engineers

Instrues
Objetivo: Pensar no processo de elicitao de
requisitos
Descrio: Defina, a partir dos atributos dados
em sala de aula, os atributos interessantes dos
requisitos
Tempo: 15 minutos.
Forma de trabalho: equipe de 3

Use the requirements to

develop validation tests for
the system

Use the requirements to help

understand the system and
the relationships between its
parts

EX:

Instrues
Objetivo: Identificar stakeholders para a elicitao
de requisitos
Descrio: veja o enunciado do exerccio 2 e
defina os stakeholders existentes
Tempo: 10 minutos.
Forma de trabalho: equipe de 3

20

4/9/2008

Anlise: Interao entre requisitos

Outro objetivo importante da anlise de

requisitos descobrir as interaes entre
requisitos e informar os conflitos e
sobreposies entre eles

Uma matriz de interao de requisitos mostrar

como um requisito interage com outros. Os
requisitos so mostrados nas linhas e colunas
da matriz

Business Analysis Planning

Enterprise
Analysis

Elicitation

Requirements
Analysis

Solution
Assessment
and
Validation

Requirements Management and Communication

Fundamentals

Anlise
e Negociao :Atividades
Estgios
Anlise
e Negociao:

Para cada requisito que conflita, preencha 1

Para cada requisito que sobrepe-se, preencha 1000
Para cada requisito que independente, preencha
um 0

Anlise: Interao entre requisitos

R e q u ir e m e n t s a n a l y s is
N e c e s si ty
c h e c k in g

U n n e c e s sa r y
r e q u ir e m e n ts

R e q u ir e m e n ts
d is cu s s i o n

C o n s is te n c y a n d
c o m p le t e n e s s
c h e c k in g
C o n f li c ti n g a n d
i n c o m p le t e
r e q u ir e m e n ts

R e q u ir e m e n ts
p ri o r i ti s a t io n

F e a s ib il ity
c h e c k in g

I n f e a s ib le
r e q u ir e m e n ts

R e q u ir e m e n ts
a gre e m e n t

R equ i rem e nt
R1
R2
R3
R4
R5
R6

R1
0
0
1000
0
1
1

R2
0
0
0
0
0
0

R3
1000
0
0
1000
0
1000

R4
0
0
1000
0
1
1

R5
1
0
0
1
0
0

R6
1
0
1000
1
0
0

R e q u ire m e n t s n e g o t i a t i o n

Documento de Requisitos

A especificaao do requisito possui projeto

prematuro?
O requisito est combinado com outros requisitos?
O requisito est completo ?
O requisito necessrios?
O requisito est unicamente identificado?
apropriado para implementar?
Pode ser testado (verificado, validado)?
Pode ser rastreado?
Est de acordo com os objetivos de negcio?
O requisito est ambguo?
O requisito real?
... ...

Instrues
Objetivo: Definir os requisitos do produto do
exerccio 2
Descrio: Dever ser lido o exerccio 2 e, depois,
elicitado os requisitos e analisados em relao:

Prioridade

Importncia

Precedncia

Tempo: 30 minutos.
Forma de trabalho: equipe de 3

21

4/9/2008

Negociao

Problemas nos requisitos so inevitveis quando um

sistema possui muitos stakeholders. Conflitos no so
falhas, mas refletem necessidades e prioridades
diferentes entre as partes interessadas

A negociao de requisitos o processo de discusso dos

conflitos de requisitos e a busca de um compromisso no
qual todas as partes interessadas concordem

A negociao o estgio de resoluo onde as aes que

dizem respeito ao requisito so concordadas. Estas aes
podem ser:

Especificao de Requisitos: Cenrio OO

Cenrios so partes inerentes de alguns

mtodos de desenvolvimento orientados a
objeto
O termo caso de uso ou use-case (um caso
especfico do uso do sistema) usado s vezes
para se referir a um cenrio
Cenrios usando UML-Unified Modelling
Language

eliminar o requisito, sugerir modificaes ao

requisito ou elicitar mais informaes sobre o
requisito

Especificao de Requisitos

Especificao de Requisitos: Cenrio UML

A atividade de traduzir as informaes

coletadas durante a atividade de elicitao de
requisitos em um documento que defina um
conjunto de requisitos.

Atores
Atores so pessoas, sistemas ou coisas que
interagem com o sistema em desenvolvimento
<<Ator>>

Coordenador

Dois tipos de requisitos podem ser includos

nesse documento
requisitos dos usurios: so declaraes abstratas
dos requisitos de sistema para o cliente e os
usuarios finais
requisitos do sistema: so uma descriao mais
detalhada da funcionalidade a ser fornecida

Especificao de Requisitos: Cenrio

Secretria
Professora

Sistema de controle
de pre-requisitos

Especificao de Requisitos: Cenrio UML

Obteno de um Histrico Escolar

Entre no sistema
Escolha o comando emisso de histrico
Entre com o nmero de matrcula do aluno
Selecione uma impressora
Saia do sistema

Estudante

Use cases
Um use case a especificao de seqncias de
aes que um sistema, subsistema, ou classe pode
realizar, interagindo com um dos atores
Use cases podem incluir seqncias alternativas,
ou seqncias excepcionais (de erro)
Matricular aluno

Solicitar
histrico

Verificar
pr-requisitos

22

4/9/2008

Especificao de Requisitos: Cenrio UML

Diagramas de Use cases
Solicitar
histrico

<<estende>>

Instrues

Solicitar histrico do
curso atual

<<estende>>

Solicitar histrico de
todos os cursos

Estudante

<<inclue>>

Verificar
dependncias

Matricular
aluno

Secretria

Objetivo: Analisar a qualidade dos requisitos

Descrio: Uma equipe troca com a outra a sua
especificao. A equipe deve analisar, segundo os
critrios da lista de verificao se os requisitos
esto adequados ou no. Deve ser definido um
padro para a aplicao da lista de verificao e
apresentado o padro e o resultado
Tempo: 30 minutos.
Forma de trabalho: equipe de 3

Sistema de controle
de pre-requisitos

Instrues
Business Analysis Planning

Enterprise
Analysis

Elicitation

Requirements
Analysis

Solution
Assessment
and
Validation

Requirements Management and Communication

Objetivo: Verificar dependncia entre requisitos

Descrio: Definir um formato para representar a
dependncia entre os requisitos. Depois de
definido, demonstre a dependncia dos
requisitos entre si.
Tempo: 30 minutos.
Forma de trabalho: equipe de 3

Fundamentals

Essa atividade verifica os requisitos quanto a

sua pertinncia, consistncia e integralidade
Durante este processo, inevitavelmente so
descobertos erros na documentao de
requisitos. Os requisitos devem ento ser
modificados, a fim de corrigir esses
problemas

23