Engenharia de Software

Requisitos
Professor Marcio Victorino mcvictorino@uol.com.br
WWW.DOMINANDOTI.COM.BR

Requisitos

Os requisitos de um sistema so descries dos servios fornecidos

pelo sistema e as suas restries operacionais. Esses requisitos refletem
as necessidades dos clientes de um sistema que ajuda a resolver algum
problema.
Um requisito uma condio ou uma capacidade com a qual o
sistema deve estar de acordo.

Levantamento de Requisitos

Chegar a um acordo sobre o que o sistema deve fazer.

Prover um melhor entendimento dos requisitos do sistema.
Definir as fronteiras do sistema.
Prover uma base para o planejamento tcnico dos contedos das iteraes.
Prover uma base para a estimativa de custos.
Definir uma interface de usurio para o sistema.

Como o cliente
explicou.

Como o lder de
projeto entendeu.

Como o analista
projetou.

Como o programador
construiu.

Como o projeto foi

documentado.

Que funcionalidades
foram instaladas.

Como o cliente foi

cobrado.

Como foi mantido.

Como o consultor de
negcios descreveu.

O que o cliente
realmente queria.

Requisitos (FURPS +)
FURPS:

+:

Funcionalidade.

Restries de design.

Usabilidade.
Confiabilidade.

Requisitos
implementao.

Desempenho.

Requisitos de interface.

Suportabilidade:

Requisitos fsicos.

Possibilidade de teste.
Extensibilidade .
Adaptabilidade.
Manutenibilidade
Compatibilidade
Possibilidade de configurao
Possibilidade de instalao
5

de

Requisitos (Sommerville)
Requisitos do Usurio:
so declaraes em linguagem natural e em diagramas,
sobre as funes que o sistema deve fornecer e as
restries sob as quais deve operar.

Requisitos de Sistema:
estabelecem detalhadamente as funes e as restries de
sistema. Deve ser preciso (especificao funcional) e serve
como base para o contrato.

Especificao de Projeto de software:

uma descrio abstrata do projeto de software; que
uma base para o projeto e a implementao mais
detalhados. Essa especificao acrescenta mais detalhes
especificao de requisitos do sistema.
6

Requisitos (Sommerville)
Requisitos Funcionais:
so declaraes de funes que o sistema deve fornecer,
como o sistema deve reagir a entradas especficas e como
deve se comportar em determinadas situaes.

Requisitos no Funcionais:
so restries sobre os servios ou as funes oferecidas
pelo sistema (tempo,padro, etc).

Requisitos de Domnio:
originam-se no domnio de aplicao do sistema e refletem
caractersticas desse domnio. Podem ser funcionais ou
no funcionais.
7

Requisitos No Funcionais
(Sommerville)
Requisitos de Produto:

especificam
comportamento do software.

ou

restringem

Ex: desempenho, memria requerida, taxa de falha, proteo e

usabilidade.

Requisitos Organizacionais: so derivados das polticas e

procedimentos da organizao do cliente e do
desenvolvedor.
Ex: requisitos dos processos operacionais (uso do sistema),
requisitos do processo de desenvolvimento (escolha da linguagem
de programao) e requisitos ambientais (ambiente operacional do
sistema).

Requisitos Externos: derivam de fatores externos ao sistema

e seu processo de desenvolvimento:
Ex: requisitos reguladores, requisitos legais e requisitos ticos.
8

Requisitos No Funcionais
(Sommerville)

Requisitos Volteis
(Sommerville)
Classificao dos Requisitos volteis:

Requisitos mutveis: se modificam devido a mudanas

do ambiente no qual a organizao est operando.
Requisitos emergentes: surgem medida que a
compreenso do cliente do sistema se desenvolve
durante o desenvolvimento do sistema.
Requisitos conseqentes: Requisitos que resultam da
introduo do sistema de computao.
Requisitos de compatibilidade: Requisitos que dependem
de sistemas ou processos de negcios especficos
dentro da organizao.

10

Modelagem de Requisitos
Funcionais
O Modelo de Casos de Uso uma
representao
das
funcionalidades
externamente observveis do sistema e dos
elementos externos ao sistema que interagem
com ele.
Este modelo parte integrante da especificao
de requisitos. Na verdade, o modelo de casos
de uso molda os requisitos funcionais do
sistema.
O diagrama da UML utilizado na modelagem de
casos de uso o diagrama de casos de uso.
Composto de Casos 11de Uso, de Atores e de

Modelo de Casos de Uso

12

Modelagem de Casos de Uso

Um meio de capturar o comportamento desejado
para o sistema em desenvolvimento.
Um meio de comunicar o comportamento do
sistema.
Identificar quem ou o que interage com o
sistema e o que o sistema deve fazer.
Uma forma de se verificar se todos os requisitos
foram capturados.
Um instrumento de Planejamento.
13

Diagrama de Casos de Uso

Um caso de uso representa quem faz o que
(interage) com o sistema, sem considerar o
comportamento interno do sistema.
Casos de Uso descrevem o sistema, seu
ambiente e os relacionamentos entre o sistema
e seu ambiente.
Casos de Uso capturam os comportamentos do
sistema:
Um comportamento de sistema como o sistema age e
reage, uma atividade visvel e testvel do sistema.
14

Diagrama de Casos de Uso

Estudante se conecta no sistema
Sistema aprova conexo
Estudante solicita Informaes sobre
curso
Estudante

Matricular em
Cursos

Sistema de
Catlogo
de Cursos

Sistema exibe lista de Cursos

Estudante seleciona Cursos

Sistema transmite solicitao

Sistema confirma disponibilidade de Cursos

Catlogo de Cursos retorna

informao de curso

Sistema exibe agenda aprovada

15

Especificao de Caso de Uso.

16

Cenrio
Geralmente um caso de uso tem diversas maneiras de ser realizado. Um
cenrio a descrio de uma das maneiras pelas quais um caso de uso
pode ser realizado. Um cenrio tambm chamado de instncia de um
caso de uso. Normalmente h diversos cenrios para um mesmo caso de
uso.

17

Exemplo de Cenrios

Um cliente pretende fazer uma retirada em um Banco 24 hs:

Cenrio 1:
O cliente digita sua senha corretamente;
O cliente solicita a retirada de um valor menor que o saldo de sua conta.
A mquina tem notas suficientes.

Cenrio 2:
O cliente digita sua senha corretamente;
O cliente solicita a retirada de um valor menor que o saldo de sua conta.
A mquina no tem notas suficientes.

Cenrio 3:
O cliente digita sua senha corretamente;
O cliente solicita a retirada de um valor maior que o saldo de sua conta.
A mquina tem notas suficientes.

18

Cenrios

Podem ser utilizados na fase de testes dos sistemas.

Facilita o entendimento dos casos de uso.
Levanta os detalhes dos casos de uso.
Se o cliente digitar uma senha invlida?
Se o cliente solicitar um valor maior que seu saldo?
Se o cliente solicitar um valor menor que seu saldo, mas a mquina no possuir notas
suficiente?

19

Diagrama de Casos de Uso

Um ator representa qualquer

coisa que interage com o sistema.
Um modelo de caso de uso define
um conjunto de casos de uso,
onde cada caso de uso uma
seqncia de aes que um
sistema executa que produz um
resultado observvel de valor para
um ator em particular.

Ator

Caso de Uso
20

Ator
Um ator representa um papel que um ser humano, dispositivo de
hardware ou outro sistema pode desempenhar.

Ator
(stick man)

21

Um usurio pode ter diferentes papis

Charles como
Professor
Professor

Charles como
Charles

Estudante

Estudante

Nomes de atores devem claramente denotar o papel do ator.

22

Nomeando Casos de Uso

O nome indica o que alcanado por suas interaes com o ator.

O nome pode ter vrias palavras.
Dois casos de uso no podem ter o mesmo nome.

Matricular em Disciplina

Manter Informaes de Alunos

23

Login

Fluxo de Eventos de Casos de Uso

Possui um fluxo normal, fluxo bsico.

Vrios fluxos alternativos:
Variantes regulares do fluxo bsico.
Caso esdrxulos.

Fluxos excepcionais tratando situaes de erro.

24

Relacionamentos
Comunicao (associao).
Incluso.
Extenso.
Generalizao.

25

Relacionamento: Comunicao

Representa a informao de quais atores esto associados a que casos de

uso.
O fato de um ator estar associado a um caso de uso significa que esse ator
interage (troca informaes) com o sistema.
Um ator pode se relacionar com vrios casos de uso.

Matricular em
Cursos
Estudante

26

Sistema de
Catlogo
de Cursos

Relacionamento: Incluso

Existe somente entre casos de uso.

Indica que um caso de uso ter seu procedimento copiado num local
especificado em outro caso de uso, identificado como base.
Ex: o caso de uso Validar Correntista em uma aplicao bancria pode ser
includo em outros casos de uso: Obter Extrato, Realizar Saque, Realizar
Depsito, etc.

27

Diagrama de Casos de Uso: Incluso

Obter Extrato
<<inclui>>

<<inclui>>
Realizar Saque

Validar Correntista

Cliente
<<inclui>>
Realizar Depsito

Incluso
28

Relacionamento: Extenso
Existe somente entre casos de uso.
Utilizado para modelar situaes em que diferentes sequencias de
interaes podem ser inseridas em um caso de uso, chamado caso de uso
estendido.
Cada uma dessas diferentes sequencias representa um comportamento que
s ocorre sob certas condies, ou cuja realizao depende de escolha de
um ator.

29

Diagrama de Casos de Uso: Extenso

Substituir Texto
<<estende>>

Editar Documento
Escritor
<<estende>>
Corrigir Ortografia

Extenso
30

Diagrama de Casos de Uso

<<inclui>>

Mostrar Mapa
do Salo

Reserva
de
Restaurante
Cliente
<<estende>>
Cadastrar
Cliente

Extenso e Incluso
31

Relacionamento: Generalizao
Existe entre casos de uso e atores.
Este relacionamento permite que um caso de uso (ou ator) herde
caractersticas de um outro caso (ator) de uso mais genrico,este
ltimo normalmente chamado de casos de uso (ator) base.

32

Diagrama de Casos de Uso: Generalizao

Realizar
Pagamento

Reservar Livro

Cliente

Aluno
Devolver Livro

Realizar
Pagamento com
Carto de Crdito
Solicitar Compra
de Ttulo
Professor

Herana
33

Realizar
Pagamento
com Cheque

Relacionamentos
Use incluso: quando o mesmo comportamento se repete em mais de um caso de uso.
Use extenso: quando um comportamento opcional de um caso de uso tiver de ser descrito.
Use herana: entre atores quando precisar definir um ator que possui o comportamento de um
ator preexistente, mas que possui comportamento particular.
Use herana: entre casos de uso quando identificar dois casos de uso com comportamentos
semelhantes e um deles for uma forma especial do outro.

34

Diagrama de Casos de Uso

Corresponde a uma viso externa do sistema e representa graficamente os
atores, casos de uso e relacionamentos entre esses elementos.
O diagrama de casos de uso tem o objetivo de ilustrar em um nvel alto de
abstrao quais elementos externos interagem com as funcionalidades do
sistema.

35

Caso de Uso Concreto

Um caso de uso concreto iniciado por um ator e constitui um fluxo

completo de eventos. "Completo" significa que uma instncia do caso
de uso executa a operao inteira chamada pelo ator.

Realizar Saque
Cliente

36

Caso de Uso Abstrato

Um caso de uso abstrato propriamente nunca instanciado. Os casos de uso abstratos so

includos em, se estendem para ou generalizam outros casos de uso.
Quando um caso de uso concreto iniciado, uma instncia do caso de uso criada. Essa
instncia tambm exibe o comportamento especificado por seus casos de uso abstratos
associados. Portanto, nenhuma instncia separada criada de casos de uso abstratos.
A distino entre os dois importante porque so os casos de uso concretos que os atores
"vero" e iniciaro no sistema.
Um caso de uso abstrato tem seu nome escrito em itlico.

<<inclui>>
Realizar Saque
Cliente

37

Validar Correntista

Modelo de Casos de Uso

Um modelo que descreve os requisitos funcionais de um sistema em

termos de casos de uso.

Um modelo das funcionalidades desejadas do sistema (casos de uso) e seu

ambiente (atores).
Sistema

Caso de Uso 1

Especificao do
Caso de Uso 2

Ator
Caso de Uso 2

Fronteira
do
Sistema
Caso de Uso 3

38

Modelo de Casos de Uso

Sistema
Ator 1

Modelo Investigativo de Casos de Uso:

- Descrio da investigao
- Lista de todos os atores
- Lista de todos os casos de uso

Caso de Uso 1

Ator 2
Caso de Uso 2

Caso de Uso 3

Ator 3

Especificao Caso de Uso 1

- Breve descrio
- Fluxo de eventos

Especificao.Caso de Uso 2
- Breve descrio
- Fluxo de eventos

39

Especificao. Caso de Uso 3

- Breve descrio
- Fluxo de eventos

Modelo de Casos de Uso

Modelo de Casos de Uso

Lista
dos
Requisitos

Atores
Casos de Uso

Regras
do
Negcio

...

Glossrio

Especificaes de Casos de uso

Especificaes
Suplementares

40

Pacotes

Casos de uso semanticamente relacionados podem ser agrupados em Pacotes.

Objetivos:
Estruturar o modelo de casos de uso de uma maneira que reflita os tipos de usurios do
sistema.
Definir a ordem que os casos de uso sero desenvolvidos.
Definir o grau de correlao entre os casos de uso

Pacote
41

Pacotes
Controle
Acadmic
o

Controle
Acadmico

Cadastrar Aluno

Secretaria

Secretaria
Matricular Aluno
Emitir Histrico

Pedidos

Entregas

Estoque

Diagrama de Pacotes
42

Benefcios dos Casos de Uso

D contexto aos Requisitos.
So fceis de entender.
Facilitam o acordo com clientes.
Ilustram porque o sistema necessrio:
Casos de Uso: porque o sistema usado.
Atores: quem/o que deseja interagir com o sistema.

43

Benefcios dos Casos de Uso

Utilizados para comunicar com os usurios e experts de domnio:

Provem uma viso do produto que vai ser desenvolvido numa fase precoce do
desenvolvimento.
Assegura um entendimento mtuo dos requisitos.

Utilizado para identificar:

Quem interage com o sistema e o que o sistema deve fazer.

As interfaces que o sistema deve possuir.

Utilizado para verificar:

Se todos os requisitos foram capturados.

Se a equipe de desenvolvimento entende os requisitos.
44

Decomposio Funcional

a diviso de um problema em pequenas partes isoladas.

As partes:

Trabalham juntas para prover a funcionalidade do sistema.

Frequentemente no fazem sentido isoladas.

Casos de Uso:

No so decomposio funcional.
Mantm agrupada uma funcionalidade para descrever um uso completo do sistema.
Fornecem um contexto.

45

Decomposio Funcional
Sintomas:

Aes Corretivas:

Casos de uso muito pequenos.

Muitos casos de uso.
Casos de uso sem resultado ou valor.
Operaes de baixo nvel como nome:
Operao + objeto
Funo + dado
Exemplo: Insira Carto
Dificuldades no entendimento geral do
modelo.

Procure por um contexto maior:

Por que voc est construindo este sistema?

Ponha-se no papel de um ator

O qu o ator deseja obter?
Objetivo de quem este caso de uso vai
satisfazer?
Que valor este caso de uso adiciona?
Qual a histria por trs deste caso de uso?

46

Engenharia de Requisitos
Sommerville

47

Engenharia de Requisitos
Consiste de um processo que envolve todas as
atividades exigidas para criar e manter o
documento de requisitos de sistema, composta
pelas atividades:
Estudo da viabilidade do sistema.
Elicitao e anlise de requisitos.
Especificao de Requisitos.
Validao de requisitos.

48

Processo de Engenharia de Requisitos

49

Modelo em espiral dos processos de engenharia de

requisitos

50

Estudo de Viabilidade
A entrada para o estudo de viabilidade uma descrio
geral do sistema e de como ele ser utilizado dentro de uma
organizao.
Os resultados devem ser um relatrio que recomenda se
vale a pena ou no realizar o processo de engenharia de
requisitos e o processo de desenvolvimento do sistema.
Deve responder as seguintes perguntas:
O sistema contribui para os objetivos gerais da organizao?
O sistema pode ser implementado com a utilizao de tecnologia atual
dentro das restries de custo e de prazo?
O sistema pode ser integrado com outros sistemas j em operao?

51

Levantamento e Anlise de
Requisitos

Nessa atividade, os engenheiros de software

trabalham com os clientes e os usurios finais
do sistema para aprender sobre o domnio da
aplicao, quais servios o sistema deve
fornecer, o desempenho esperado do sistema,
restries de hardware etc.

52

Levantamento e Anlise de
Requisitos

A elicitao e a compreenso dos requisitos

stakeholders so difceis devido a vrias razes:

dos

I. Os stakeholders frequentemente no sabem o que querem do sistema de

computador a no ser em termos gerais. Eles podem achar difcil articular o que
desejam que o sistema faa ou fazem pedidos no realistas.
2. Os stakeholders expressam os requisitos naturalmente em seus prprios termos
e com o conhecimento implcito de seu trabalho. Os engenheiros de requisitos,
sem experincia no domnio do cliente, devem entender esses requisitos.
3. Diferentes stakeholders possuem diferentes requisitos, expressos de diferentes
formas. Os engenheiros de requisitos precisam considerar todas as fontes
potenciais de requisitos e descobrir pontos em comum e conflitos.
4. Fatores polticos podem influenciar os requisitos do sistema. Os gerentes podem
solicitar requisitos especficos que aumentaro sua influncia na organizao.
5. O ambiente econmico e de negcios sobre o qual a anlise realizada
dinmico. Ele muda inevitavelmente durante o processo de anlise. Portanto, a
importncia de determinado requisito pode mudar. Novos requisitos podem surgir
de novos stakeholders que no haviam sido consultados anteriormente.
53

Levantamento e Anlise de
Requisitos

As atividades de processo so:

I. Obteno de requisitos: o processo de interao com os stakeholders

no sistema para coletar seus requisitos. Os requisitos de domnio so

tambm descobertos durante essa atividade, provenientes dos
stakeholders e da documentao.
2. Classificao e organizao de requisitos: esta atividade envolve a
coleo de requisitos no estruturados, agrupa os requisitos
relacionados e os organiza em conjuntos coerentes.
3. Priorizao e negociao de requisitos: quando vrios stakeholders
participam do processo, os requisitos sero conflitantes. Esta atividade
est relacionada priorizao de requisitos, procura e resoluo de
conflitos de requisitos por meio da negociao.
4. Documentao de requisitos: os requisitos so documentados e
colocados na prxima volta da espiral. Podem ser produzidos
documentos de requisitos formais ou informais.
54

Levantamento e Anlise de
Requisitos

55

Levantamento e Anlise de
Requisitos

Tcnicas (Sommerville):
Entrevistas.
Levantamento Orientado a Ponto de Vista.
Etnografia.
Cenrios.
Casos de Uso.

Outras:
Leitura de documentos.
Questionrios.
Anlise de protocolos.
Participao ativa dos usurios (Workshop).
Reuso de requisitos.
Prototipagem.
56

Entrevistas
Entrevistas formais ou informais com os stakeholders no
sistema fazem parte da maioria os processos de engenharia
de requisitos. Nessas entrevistas, a equipe de engenharia de
requisitos formula questes para os stakeholders sobre o
sistema que eles usam e o sistema a ser desenvolvido. Os
requisitos so derivados das respostas a essas questes. As
entrevistas podem ser de dois tipos:
1. Entrevistas fechadas, nas quais o stakeholder responde a um

conjunto de perguntas predefinidas.

2. Entrevistas abertas, nas quais no existe um roteiro predefinido. A
equipe de engenharia de requisitos explora vrios assuntos com os
stakeholders no sistema e, assim, desenvolve uma compreenso
maior de suas necessidades.

57

Entrevistas
Na prtica, as entrevistas com os stakeholders so,
geralmente, uma combinao desses tipos
(fechadas e abertas).
difcil elicitar o conhecimento de domnio durante
as entrevistas por dois motivos: os especialistas de
domnio usam terminologia e jarges especficos e
alguns conhecimentos de domnio so to familiares
que so considerados difceis de explicar ou
considerados to fundamentais que no vale a pena
mencion-los.

58

Pontos de Vista

Levantamento Orientado a Pontos de Vista:

em um sistema existem vrios pontos de vista que precisam ser considerados.

Estgios:

Identificao de
Ponto de Vista

Estruturao de
Ponto de Vista

Documentao de
Ponto de Vista

59

Mapeamento de Sistema
conforme Ponto de Vista

Etnografia
Etnografia:
tcnica de observao utilizada para compreender os requisitos organizacionais e sociais. O
trabalho dirio observado e so anotadas as tarefas reais em que os participantes esto
envolvidos. O valor da etnografia est na descoberta requisitos implcitos, que refletem os
processos reais.

60

Cenrios

Cenrios:

A obteno de requisitos com base em cenrios pode ser realizadas informalmente, ou de forma um pouco
mais estruturada, com o uso de casos de uso.

De maneira geral, um cenrio deve incluir:

l. Uma descrio do que os usurios esperam do sistema no incio do cenrio.
2. Uma descrio do fluxo normal de eventos no cenrio.
3. Uma descrio do que pode dar errado e como isso tratado.
4. Informaes sobre outras atividades que podem ocorrer simultaneamente.
5. Uma descrio do estado de sistema no fim do cenrio.

61

Casos de Uso

Os casos de uso constituem uma tcnica baseada em cenrios para elicitao de

requisitos e foram introduzidos inicialmente no mtodo Objectory (Jacobsen, et
aI., 1993).
Eles se tomaram uma caracterstica fundamental da notao UML para descrio
de modelos de sistema orientado a objetos.
Em sua forma mais simples, um caso de uso identifica o tipo da interao e os
agentes envolvidos.

62

Validao de Requisitos

A validao de requisitos se ocupa de mostrar que os requisitos realmente

definem o sistema que o cliente deseja.
Enquanto a anlise trabalha com requisitos incompletos, a validao
elabora um esboo completo do documento de requisitos.
Tcnicas de validao de requisitos:

Revises de requisitos.
Prototipao.
Gerao de casos de teste.
Anlise automatizada de consistncia (linguagem formal).

63

Validao de Requisitos

Durante o processo de validao de requisitos, devem ser realizadas verificaes nos requisitos do documento de
requisitos:
1. Verificaes de validade: mais estudos e anlises podem identificar que funes adicionais e diferentes so
necessrias.
2. Verificaes de consistncia: os requisitos em um documento no devem ser conflitantes.
3. Verificaes de completeza: o documento de requisitos deve incluir requisitos que definam todas as funes e as
restries desejadas pelo usurio do sistema.
4. Verificaes de realismo: usando o conhecimento da tecnologia existente, os requisitos devem ser verificados
quanto a se realmente podem ser implementados.
5. Facilidade de verificao: deve ser possvel descrever um conjunto de testes que possa demonstrar que o sistema
entregue atende a cada requisito especificado.

64

Revises de Requisitos

Em uma reviso formal de requisitos, a equipe de desenvolvimento deve 'conduzir' o cliente

pelos requisitos de sistema, explicando as implicaes de cada requisito. A equipe de reviso
deve verificar cada requisito em termos de consistncia, bem como verificar os requisitos
como um todo em termos de completeza. Os revisores podem tambm verificar:
1. Facilidade de verificao: o requisito, conforme estabelecido, testvel de forma realstica?

2. Facilidade de compreenso: os adquirentes e os usurios finais do sistema compreendem o requisito de forma apropriada?

3. Rastreabilidade: a origem do requisito est estabelecida claramente? Talvez seja necessrio retomar fonte do requisito
para avaliar o impacto de uma mudana.

4. Adaptabilidade. O requisito adaptvel? Isto , o requisito pode ser mudado sem efeitos em grande escala sobre os outros
requisitos de sistema?

65

Revises de Requisitos

Conflitos, contradies, erros e omisses nos requisitos devem ser apontados

pelos revisores e registrados formalmente no relatrio de reviso.
, portanto, de responsabilidade dos usurios, do adquirente de sistema e do
desenvolvedor de sistema negociar uma soluo para esses problemas
identificados.

66

Engenharia de Requisitos
Pressman

67

Engenharia de Requisitos
Tem por objetivo ajudar os engenheiros de software a
compreender melhor o problema que eles vo trabalhar para
resolver.
Inclui um conjunto de tarefas que levam a um entendimento
de qual ser o impacto do software sobre o negcio, do que o
cliente quer e de como os usurios finais vo interagir com o
software.
Como todas as outras atividades de engenharia de software,
precisa ser adaptada s necessidades do processo de
software.
uma ao de engenharia de software que comea durante a
atividade de comunicao e continua durante a atividade de
modelagem.
68

Engenharia de Requisitos
Tarefas:
Concepo;
Levantamento;
Elaborao;
Negociao;
Especificao;
Validao.
Gesto.

69

Engenharia de Requisitos
Concepo:
A maioria dos projetos comea quando uma
necessidade do negcio identificada ou um
mercado ou um servio potencialmente novo
descoberto.
Os engenheiros de software perguntam uma srie
de questes livres de contexto. A inteno
estabelecer um entendimento bsico do problema,
o pessoal que quer uma soluo, a natureza da
soluo desejada e a efetividade da comunicao e
colaborao preliminares entre clientes e
desenvolvedor.
70

Engenharia de Requisitos
Levantamento:
Ajuda o cliente a definir o que necessrio.
Problemas:
problemas de escopo: limite mal definido;
problemas de entendimento: pleno entendimento do
domnio do problema;
problemas de requisitos: volatilidade.

71

Engenharia de Requisitos
Elaborao:
As informaes obtidas do cliente durante a concepo e o
levantamento so expandidas e refinadas.
Enfoca o desenvolvimento de um modelo tcnico refinado
das funes, caractersticas e restries do software.
Consiste de uma ao de modelagem de anlise.
guiada pela criao e refinamento de cenrios do
usurio.
O resultado final um modelo de anlise que define o
domnio do problema informacional, funcional e
comportamental.
72

Engenharia de Requisitos
Negociao:
Tem por objetivo reconciliar conflitos ocasionados
por clientes e usurios, por intermdio de um
processo de negociao.

Especificao:
Pode ser um documento escrito, um modelo
grfico, um modelo matemtico formal, uma
coleo de cenrios de uso, um prottipo, ou
qualquer combinao desses elementos.
o produto de trabalho final produzido pelo
engenheiro de requisitos.
73

Engenharia de Requisitos
Validao:
Os produtos de trabalho resultantes da engenharia
de requisitos so avaliados quanto qualidade.

Gesto:
A gesto de requisitos comea com a identificao.
A cada requisito atribudo um identificador. Uma
vez identificados os requisitos, tabelas de
rastreamento so desenvolvidas, cada tabela de
rastreamento relaciona os requisitos identificados a
um ou mais aspactos do sistema ou de seu
ambiente.
74

Incio do Processo de Engenharia de

Requisitos

Identificao dos interessados.

Reconhecimento dos diversos pontos de vista.
Trabalho em busca da colaborao.
Formulao das primeiras perguntas.

75

Levantamento de Requisitos
Coleta colaborativa de requisitos;
Cenrios de Uso;
Implantao da Funo de Qualidade (IFQ):
traduz as necessidades do cliente para requisitos tcnicos do
software.
concentra-se em maximizar a satisfao do cliente a partir do
processo de engenharia de software.
identifica trs tipos de requisitos:
normais: refletem os objetivos e metas estabelecidos para um
sistema durante as reunies com o cliente;
esperados: esto implcitos no produto, o cliente no se refere;
excitantes: refletem as
expectativas do cliente.

caractersticas

76

que

vo

alm

das

Gerenciamento de Requisitos
Sommerville

77

Gerenciamento de Requisitos
Os requisitos de sistemas de software de grande porte esto
sempre mudando.
O problema no pode ser totalmente definido, os requisitos
de software tendem a ser incompletos.
Durante o processo de software, o entendimento dos
stakeholders sobre o problema muda constantemente.
Esses requisitos devem ento evoluir para refletir essas
novas vises do problema.
Depois que o sistema estiver instalado, inevitavelmente
surgiro novos requisitos.
difcil para os usurios e os clientes do sistema
anteciparem quais efeitos o novo sistema causar na
organizao.
78

Gerenciamento de Requisitos
Quando os usurios adquirirem experincia com o sistema,
novas necessidades e prioridades surgem:
I. Sistemas de grande porte geralmente tm uma comunidade diversificada
de usurios. Os requisitos finais do sistema constituem inevitavelmente
um compromisso entre eles e, com a experincia, descobre-se
frequentemente que o equilbrio de apoio dado aos diferentes usurios
tem de ser mudado.
2. As pessoas que pagam por um sistema e os usurios de um sistema
raramente so as mesmas pessoas. Os clientes do sistema impem
requisitos devido a restries organizacionais e de oramento. Essas
restries podem ser conflitantes com os requisitos dos usurios finais e,
aps a entrega, novas caractersticas podem ser includas para apoio do
usurio, fazendo com que o sistema alcance suas metas.
3. O ambiente de negcios e tcnico do sistema muda aps a instalao, e
essas mudanas devem se refletir no sistema.
79

Gerenciamento de Requisitos
O gerenciamento de requisitos um processo para
compreender e controlar as mudanas dos requisitos de
sistema.
preciso manter o acompanhamento dos requisitos
individuais e manter as ligaes entre os requisitos
dependentes, de modo que seja possvel avaliar o impacto
das mudanas de requisitos.
preciso estabelecer um processo formal para fazer
propostas de mudana e lig-las aos requisitos de sistema.
O processo de gerenciamento de requisitos deve se iniciar
assim que uma verso inicial do documento de requisitos
esteja disponvel, mas deve-se iniciar o planejamento das
mudanas de requisitos durante o processo de elicitao de
requisitos.
80

Gerenciamento de Requisitos
(RUP)

O gerenciamento de requisitos um modelo

sistemtico para encontrar, documentar,
organizar e rastrear os requisitos variveis de
um sistema.
Um requisito uma condio ou uma
capacidade com a qual o sistema deve estar
de acordo.

81

Planejamento do Gerenciamento de
Requisitos
o primeiro estgio essencial no processo
de gerenciamento de requisitos.
O gerenciamento de requisitos muito
dispendioso.
Para cada projeto, o estgio de planejamento
estabelece o nvel de detalhamento
necessrio para o gerenciamento de
requisitos.

82

Planejamento do Gerenciamento de
Requisitos

Durante o estgio de gerenciamento de requisitos, deve-se

decidir sobre:
1. Identificao de requisitos. Cada requisito deve ser identificado
unicamente de modo que possa ser feita a referncia cruzada entre este
e outros requisitos para que ele possa ser usado nas avaliaes de
rastreabilidade.
2. Processo de gerenciamento de mudanas. o conjunto de atividades
que avaliam o impacto e custo das mudanas.
3. Polticas de rastreabilidade. Essas polticas definem os
relacionamentos entre os requisitos e entre os requisitos e o projeto do
sistema, que devem ser registrados, e como esses registros devem ser
mantidos.
4. Apoio de ferramentas CASE. O gerenciamento de requisitos envolve o
processamento de grandes quantidades de informaes sobre os
requisitos. As ferramentas que podem ser usadas variam desde sistemas
especializados de gerenciamento de requisitos a planilhas e sistemas
83
simples de banco de dados.

Planejamento do Gerenciamento de
Requisitos

O gerenciamento de requisitos precisa de apoio

automatizado; as ferramentas CASE para essa finalidade
devem ser selecionadas durante a fase de planejamento. O
apoio de ferramentas necessrio para:
I. Armazenamento de requisitos. Os requisitos devem ser mantidos em
um repositrio de dados seguro e gerenciado acessvel a todos os
envolvidos no processo de engenharia de requisitos.
2. Gerenciamento de mudanas. O processo de gerenciamento de
mudanas simplificado se um apoio ativo de ferramentas estiver
disponvel.
3. Gerenciamento de rastreabilidade. O apoio de ferramentas para
rastreabilidade permite que requisitos relacionados sejam obtidos.
Algumas ferramentas usam tcnicas de processamento de linguagem
natural para auxiliar na descoberta de possveis relacionamentos entre
os requisitos.
84

Gerenciamento de Mudanas de
Requisitos
Aps a aprovao do documento de
requisitos o gerenciamento de mudanas de
requisitos deve ser aplicado a todas as
mudanas propostas aos requisitos.
A vantagem de usar um processo formal para
gerenciamento de mudanas que todas as
propostas de mudana so tratadas
consistentemente, e as mudanas no
documento de requisitos so feitas de
maneira controlada.
85

Gerenciamento de Mudanas de
Requisitos

Existem trs principais estgios para um processo

de gerenciamento de mudanas:
1. Anlise do problema e especificao da mudana. O
processo se inicia com um problema de requisitos
identificado ou, s vezes, com uma proposta de mudana
especfica. Durante esse estgio, o problema ou a proposta
de mudana analisada para verificar se vlida.
2. Anlise da mudana e estimativa de custo. O efeito da
mudana proposta avaliado usando as informaes de
rastreabilidade e o conhecimento geral sobre os requisitos
do sistema.
3. Implementao da mudana. O documento de requisitos e,
quando necessrio, o projeto e a implementao de sistema
so modificados.
86

Gerenciamento de Mudanas de
Requisitos

Se uma mudana de requisitos do sistema

solicitada com urgncia, existe sempre uma
propenso a realizar a mudana no sistema e,
depois, retrospectivamente, modificar o documento
de requisitos.
Isso leva quase inevitavelmente defasagem entre
o documento de requisitos e a implementao do
sistema.
Uma vez feitas as mudanas no sistema, as
mudanas no documento de requisitos podem ser
esquecidas ou realizadas de maneira no
consistente com as mudanas no sistema.
87

Fim

Professor Marcio Victorino

88