25225_23290_RequisitosParteI

Prévia do material em texto

Roteiro da Aula 
2 
� Introdução 
� Processos 
� Tipos 
� Problemas 
� Recomendações 
� Especificação 
Introdução 
3 
� O que são Requisitos? 
� Moderno Dicionário da Língua Portuguesa 
� “1.Condição a que se deve satisfazer para que uma coisa fique 
legal e regular” 
� Os requisitos de um sistema software 
� Definir o que o sistema deve fazer 
� Suas restrições sobre suas operações e implementação 
� Exemplo: 
� “Eu quero que meu sistema permita realizar buscas por cor dos 
olhos” 
Introdução 
4 
Definição dos requsitos 
Projeto de sistema de software 
Implementação de teste de unidade 
Integração e teste de sistema 
Operação de manutenção 
Modelo Em Cascata 
Introdução 
5 
� “O começo é a parte mais importante do trabalho.” 
(Platão) 
� Muitos problemas de Engenharia de Software 
originam na fase de requisitos 
� Atraso na entrega do sistema 
� Aumento dos custos 
� Erros de arquitetura 
 
Introdução 
6 
� Portanto… 
� Uma COMPREENSÃO completa dos requisitos de 
software é fundamental para que o desenvolvimento de 
software seja bem sucedido 
� A satisfação dos requisitos especificados pelos usuários 
é a pré-condição básica para o sucesso de um software 
� Software mal especificado 
� Desapontar o usuário; 
� Causar problemas à equipe de desenvolvimento; 
� Constantes modificações 
 
Introdução 
7 
� Engenharia de Requisitos 
� Objetivo 
� SISTEMATIZAR o processo de definição dos requisitos, 
obtendo uma ESPECIFICAÇÃO CORRETA e COMPLETA dos 
requisitos (IEEE, 1991) 
� Desenvolver uma especificação COMPLETA, CONSISTENTE e 
NÃO AMBÍGUA, servindo de base para um acordo entre 
TODAS as partes envolvidas e descrevendo O QUÊ o produto 
de software irá fazer, mas não COMO ele será feito (Boehm, 
1989) 
 
8 
 
Fonte: SWEBOK v3 
9 
� Os Requisitos de Software estão intimamente 
relacionados com as outras áreas de conhecimento 
da ES 
� design, testes, manutenção, configuração, gestão, 
processos, modelos e métodos. 
� TODO Processo possui ESSA ETAPA de Requisitos 
� O Que muda São como Técnicas, uma Interação e como 
ESPECIFICAÇÕES geradas. 
� RUP 
� SCRUM 
� XP 
Processo de Requisitos 
10 
Elicitação 
• Formulários 
• Entrevistas 
Análise 
• Protótipos 
• Caso de 
Uso 
Especificação 
de requisitos 
• Documentos 
Validação de 
Requisitos 
• Documento 
de 
Validação 
Obetivo do processo: Criar e Manter um Documento de Requisitos 
• Documento de 
Requisitos 
so de Requisitos
Elicitação
• sFormulários
• EntrevistasE i
Análise
• Protótipos
• CasoC ded
Uso
Especificação
de requisitos
• osDocumento
Validação de
Requisitos
• Documento
ded
Validação
Obetivo do Requisito
• Documento de
Requisitos
so d
Ob tos
so d
Ob too proccesssoo: CCCCCCriiiaar e MMMMMMMaanntteer umm DDDooccummeentttoo de R
Requisitos 
11 
� Não é uma atividade apenas de front-end discreta 
do ciclo de vida do software 
� É SIM um processo iniciado no início de um projeto 
que continua a ser refinado ao longo do ciclo de vida 
Requisitos 
12 
� Requisito 
� Condição necessária para obtenção de certo objetivo, ou 
preenchimento de certo objetivo. 
� Especificação 
� Descrição minuciosa das características que um material, 
uma obra, ou um serviço deverão apresentar. 
� Portanto, Especificação é diferente de Requisitos 
� Especificação de Requisitos 
� Serve para documentar a análise realizada 
 
Tipos de Requisitos 
13 
� Requisitos Funcionais 
� RF são requisitos diretamente ligados a funcionalidade 
do software 
Exemplo: 
� “O sistema deve conter um formulário para a entrada dos 
resultados dos testes clínicos de um paciente”. 
 
 
 
Tipos de Requisitos 
14 
� Requisitos Não Funcionais 
� Expressam restrições que o software deve atender ou 
qualidades específicas que o software deve ter 
Exemplo: 
� “Dependendo do resultado do teste, somente o 
Supervisor pode efetuar a entrada do resultado do teste 
de um paciente. (RNF de confidencialidade)” 
� O sistema deve emitir um recibo para o cliente, com o 
tempo máximo de 8 segundos após a transação. (RF “,” 
RNF de performace). 
 
Quantificação dos Requisitos 
15 
� Requisitos de Software devem ser declarados de forma clara 
e inequívoca 
� Em particular, isso é importante para os requisitos não-
funcionais. 
� Se for o caso, a declaração deve ser de maneira quantitativa 
� Evitar que a interpretação seja feita de forma subjetiva, como 
por exemplo: 
� "o software deve ser confiável", “ 
� o software deve ser user-friendly ". 
� Dois exemplos de requisitos quantificados já foram dados 
� “Dependendo do resultado do teste, somente o Supervisor pode 
efetuar a entrada do resultado do teste de um paciente. (RNF de 
confidencialidade)” 
� O sistema deve emitir um recibo para o cliente, com o tempo 
máximo de 8 segundos após a transação. (RF “,” RNF de 
performace). 
 
Atores 
16 
� São os evolvidos do processo de requisitos de softwares 
� Usuários: grupo é composto por aqueles que vão operar o 
software 
� Clientes : Este grupo é composto por aqueles que encomendaram 
o software ou que representam mercado-alvo do software 
� Os analistas de mercado : um produto de mercado de massa não 
vai ter um cliente de comissionamento , de forma pessoal de 
marketing são muitas vezes necessários para estabelecer o que 
precisa o mercado e agir como clientes proxy. 
� Reguladores : muitos domínios de aplicação, tais como bancos e 
transportes públicos, são regulados. Software nestes domínios 
devem cumprir com os requisitos da regulamentação autoridades 
� Os engenheiros de software : Estes indivíduos têm um interesse 
legítimo em lucrar com o desenvolvimento de o software , por 
exemplo , reutilizando componentes ou de outros produtos . 
 
Problemas com Requisitos 
Elicitação Especificação 
17 
� Ignorar um grupo de clientes 
� Ignorar um único cliente 
� Omitir um grupo de 
requisitos 
� Permitir inconsistências 
entre grupos de requisitos 
� Aceitar requisito inadequado 
� Aceitar requisito incorreto, 
indefinido, ou impreciso 
� Aceitar um requisito ambíguo 
e inconsistente 
� Técnicas e Ferramentas 
Inadequadas 
� Comunicação Ineficiente 
 
 
� Documentos mal 
escritos 
� Palavras ambíguas 
� Mal divididos 
� Confusão de conceitos 
 
Recomendações 
18 
� Usar técnicas de 
comunicação 
� FAST(Facilitaded 
Application Specification 
Techniques) 
� Usar técnicas de 
Análise 
� Análise Estruturada 
� Análise Orientada a 
Objetos 
 
� Usar técnicas de 
elicitação: 
� Entrevista 
� Questionário 
� Role Playing 
� Workshop de Requisitos 
� Cenários 
� Brainstorming 
� Storyboards 
� Protótipação 
 
Recomendação número 1 – Entender Engenharia de Requisitos 
 
Recomendações 
19 
� Utilizar guias de 
recomendações de 
como elaborar uma 
especificação de 
requisitos 
� Praticar escrita, praticar 
leitura, 
Recomendação número 1 – Entender Engenharia de Requisitos 
 
Exemplos de Casos de Elicitações 
20 
� Com o objetivo de ilustrar os problemas enfrentados 
na coleta de requisitos, segue alguns casos práticos 
� Sistema de relatórios de logística 
� Sistema de denúncias 
� Sistema de venda de revistas on-line 
� Sistema de marketing 
� Sistema de TV 
Mais Recomendações 
21 
� Se você pretende ser um Engenheiro de 
Requisitos.. 
� Capacidade para compreender conceitos abstratos, 
reoorganizar esses conceitos em divisões lógicas e 
sintetizar soluções com base em cada divisão. 
� Capacidade de absorver fatos pertinentes a partir de 
fontes conflitantes ou confusas.� Capacidade de se comunicar bem de forma escrita e 
verbal. 
� Capacidade de “ver a floresta ao invés das árvores”. 
� SABER ESCREVER! 
Processo de Requisitos 
22 
Elicitação 
• Formulários 
• Entrevistas 
Análise 
• Protótipos 
• Caso de 
Uso 
Especificação 
de requisitos 
• Documentos 
Validação de 
Requisitos 
• Documento 
de 
Validação 
Obetivo do processo: Criar e Manter um Documento de Requisitos 
• Documento de 
Requisitos 
Elicitação de requisitos 
� Para complementar o que é um requisito de 
software, a sua importância sua dificuldade assita ao 
vídeo: 
� http://www.youtube.com/watch?v=t0so6Nagjns 
 
Elicitação de Requisitos 
24 
� Está preocupado com as ORIGENS dos requisitos 
de software e COMO o 
� engenheiro de software pode recolhê-los. 
� É a primeira etapa na construção de uma 
compreensão do software 
� É fundamentalmente uma atividade HUMANA e é o 
lugar onde as partes interessadas são identificados 
e as relações estabelecidas entre a equipe de 
desenvolvimento o cliente. 
� Um dos princípios fundamentais de um bom 
processo de elicitação de requisitos é o da efetiva 
comunicação entre os vários intervenientes. 
Elicitação de Requisitos 
25 
� Não é uma atividade PASSIVA e que, mesmo se as 
partes interessadas cooperativos e articulados são 
disponível, o engenheiro de software tem que 
trabalhar duro para obter as informações 
CORRETAS. 
Elicitação de requisitos 
Problemas decorrentes da coleta de requisitos!! 
Elicitação de requisitos 
Problemas decorrentes da coleta de requisitos!! 
Elicitação de requisitos 
� Técnicas 
� Entrevistas 
� Dinâmica de Grupo 
� Oficinas 
� JAD 
� Técnicas de Criatividade em Grupo 
� Brainstorming 
� Técnica de grupo nominal 
� Votação das melhores idéias 
� Delphi 
� Mapas Mentais 
� Diagrama de Afinidades 
� Técnicas de Tomada de Decisão em Grupo 
� Questionário e Pesquisas 
� Observações 
� Protótipação 
 
 
 
 
Elicitação de requisitos 
� Entrevistas 
� Meio formal ou informal de se descobrir informações das partes 
interessadas através de conversas diretas com as mesmas. 
� Normalmente é feita através de perguntas PREPARADAS ou 
espontâneas e do REGISTRO de RESPOSTAS 
� São frequentemente conduzidas individualmente, mas podem envolver 
múltiplos entrevistadores e/ou entrevistados 
 
Elicitação de requisitos 
� Entrevistas: boas práticas: 
� Deve fazer parte o planejamento ANTES da entrevista 
� Quem será entrevistado? 
� Qunto tempo para cada um? 
� Quem irá realizar a entrevista? 
� Qual a diponibilidade do entrevistador? 
� Qual a disponibilidade do entrevistado? 
� Agende com antecedência 
Elicitação de requisitos 
� Entrevistas: boas práticas: 
� Planeje o que será perguntado 
� Faça um guia de perguntas 
� Entreviste as pessoas certas! Não perca tempo! 
� Registre! Fatalmente você irá esquecer! 
� Câmeras, gravadores, lápis, papel 
� Não deixe nada mal entendido 
� Formalize a entrevista depois de realizá-la 
� (envie um e-mail com seu entendimento) 
 
Elicitação de requisitos 
� Evite fazer entrevistas “on-line” 
� Perda de informações 
� Informações redundantes 
� Informações ambíguas 
� Entrega com atraso 
� Não entregar 
Mais informações em: 
http://www.slideshare.net/fernandosantucci/treinamento-jad-joint-application-design 
Elicitação de requisitos 
� Dinâmica de grupo 
� Unem as partes interessadas e especialistas no assunto para aprender 
a respeito das suas expectativas e atitudes sobre um software 
� Um moderador treinado guia a grupo através de uma discussão 
interativa, planejada para ser mais informal do que uma entrevista 
individual. 
� Geralmente quem idealiza essa dinâmica são profissionais de RH 
� Por ser mais difícil de elaborar é pouco utilizada em desenvolvimento 
de sistemas 
� Exemplo: Jogos! 
 
 
Elicitação de requisitos 
� Oficinas 
� São sessões focadas que unem as partes interessadas 
(multidisciplinar) para definir os requisitos do produto 
� Os problemas podem ser descobertos e resolvidos mais rapidamente 
do que em sessões individuais 
� Exemplos 
� Indústria de software: Join Application Design (JAD). 
� Técnicas para condução de reuniões 
� Indústria de manufatura: Desdobramento da Função de Qualidade 
(QFD) 
 
 
 
 
Elicitação de requisitos 
� Técnicas de criatividade em grupo 
� Brainstorming 
� Técnica de Grupo Nominal 
� Amplia o Brainstorming adicionando um processo de votação para 
armazenar as várias idéias 
� Ténica Delphi 
� Detalhado nos próximos slides 
� Mapas Mentais 
� Detalhado nos próximos slides 
� Diagrama de Afinidades 
� Detalhado nos próximos slides 
 
 
 
Fonte: http://www.entrepreneurship-education.com/business-ideas.html 
Brainstorming 
 
A figura retrata bem o que é uma tempestade de idéias! (“brainstorming”) 
Fonte: http://lateralaction.com/articles/brainstorming/ 
Brainstorming 
 
Resultado de um brainstorming! 
Elicitação de Requisitos 
� Detalhando melhor a Ténica Delphi 
� Consulta um grupo de especialistas a respeito do futuros 
software através de um questionário, que é repassado 
continuadas vezes até que seja obtida uma convergência das 
respostas, um consenso, que representa uma consolidação do 
julgamento intuitivo do grupo. 
� Pressupõe-se que um jultamento coletivo bem orgnizado é 
melhor do opnião de um só indivíduo 
� Características: 
� Anonimato dos respondentes 
� Representação estatística da distribuição dos resultados 
� Feedback de respostas do grupo para reavaliação das 
rodadas 
� Recomendado quando não se dispões de dados quantitativos, 
ou estes não podem ser projetados para o futuro com segurança 
 
Elicitação de requisitos 
 
� Usados em várias áreas 
� “Identificação de novas cocepções para sistema de 
exploração de petróleo até o ano 2000, em lâminas dé 
água superiores a 1000 m” 
� Fonte: O futuro energético:Uma previsão para o ano 2000 usando o 
método Delphi. James Wright. 
 
Delphi 
Outras referências: Delphi – Uma ferramenta para apoio ao planejamento 
Prospectivo. Fonte: http://www.iea.usp.br/tematicas/futuro/projeto/delphi.pdf 
Elicitação de requisitos 
Esse é um fluxograma 
Que ilustra cada etapa 
Da técnicas Delphi 
Elicitação de requisitos 
Delphi 
 
Nos próximos slides, você verá as telas de um 
software gratuíto (sem necessidade de 
Instalação) que pode ser usado para aplicar a ténica delphi. 
 
Acesso ao software: http://armstrong.wharton.upenn.edu/delphi2/ 
 
Elicitação de requisitos 
Delphi 
 
Elicitação de requisitos 
 
 
 
 
•Use no mínimo 5 especialistas e no máximo 20 
•Os especialistas devem possuir algum conhecimento, 
mas não muito 
•Grupo pode ser Heterogêneo ou Homogêneo, depende do 
sistema. 
 
Cadastrando os especialistas! 
 
 
Elicitação de requisitos 
� Ténica Delphi 
� Leituras recomendadas: 
� Harold A. Linstone and Murray Turoff, Editors Linstone & Turoff 
(1975). The Delphi Method: Techniques and Applications : a heavily 
referenced work on this method with an extensive bibliography. 
� # Sackman, H. (1974), "Delphi Assessment: Expert Opinion, 
Forecasting and Group Process", R-1283-PR, April 1974. Brown, 
Thomas, "An Experiment in Probabilistic Forecasting", R-944-ARPA, 
1972 - the first RAND paper. 
� # Bernice B. Brown (1968). "Delphi Process: A Methodology Used 
for the Elicitation of Opinions of Experts." : An earlier paper 
published by RAND (Document No: P-3925, 1968, 15 pages) 
 
 
 
Elicitação de requisitos 
� Detalhamento dos Mapas Mentais 
� Idéias criadas através de brainstormingindividuais 
são consolidadadas num único mapa mental que 
reflete a existência de atributos comuns e diferenças 
de entendimento, além de gerar novas idéias 
 
 
Mapas Mentais 
 
Exemplo Mapas Mentais 
Enquanto acontece 
O Brainstorm 
Vc pode realizar 
O mapa mental. 
É uma maneira de 
Organizar os 
pensamentos 
Exemplo de Mapas Mentais 
 
Exemplo de Mapas Mentais 
 
Exemplo de Mapas Mentais 
 
Ferramentas de Apoio 
� Mapas Mentais 
� Ferramenta e modelos para criação de mapas 
mentais: 
� XMind: 
� http://www.xmind.net/ 
� Modelos de Mapas Mentais 
� http://www.mapasmentais.com.br/modelos/eventos/eventos.asp 
 
 
Elicitação de requisitos 
� Diagrama de afinidades 
� Permite que um grande número de idéias seja organizado em 
grupos para revisão e análise 
� Utilizado para organizar idéias e dados 
� Utilizado DEPOIS de um branistorming 
� Utilizado quando existe dificuldade em se organizar tantas idéias 
 
 
 Atenção!! Vamos usar essa técnica em nossa atividade prática!!! 
Elicitação de requisitos 
� Diagrama de afinidade: PROCESSOS 
� Registre cada idéia em um cartão 
� Agrupe idéias que parecem estar relacionadas 
� Ordene os cartões em grupos até que todos sejam 
utilizados 
 
 
 
Elicitação de requisitos 
 
 
Passo 2 – Registrar as idéias 
Passo 1 - Brainsmtorm 
Elicitação de requisitos 
 
 
Passo 3 – Agrupar as idéias = diagrama de afinidades 
Elicitação de requisitos 
� Sugestão de ferrmenta: 
http://www.discover6sigma.org/d6slab/affinity/ 
Elicitação de requisitos 
� Técnicas de tomada de decisão em grupo 
� Processo de avaliação de múltiplas alternativas onde 
uma resolução com ações futuras é esperada. Podem 
ser realizadas para gerar, classificar e priorizar os 
requisitos 
� Unanimidade 
� Todos concordam 
� Maioria 
� Mas de 50% concordam 
� Pluraridade 
� O maior bloco decide,mesmo que a maioria não seja alcançada 
� Ditadura 
� Apenas um decide 
 
 
Elicitação de requisitos 
� Questionários e Pesquisas 
� Recomendado para uma grande audiência 
� Quando uma análise estatística é necessária 
� Podem ser aplicados juntamente com entrevistas ou 
formulários 
� Não faça sem antes QUESTIONAR: 
� Qual a melhor maneira de realizar a pesquisa? 
� Como podemos ter a melhor taxa de resposta possível? 
� Devemos usar uma empresa de pesquisa? 
� Deve ser on-line ou presencial? 
 
 
Elicitação de requisitos 
� Questionário 
� Vantagens: 
� Atinge grande número de pessoas, mesmo que estejam 
dispersas geograficamente 
� Menores gastos com pessoal, não exige treinamento de quem 
vai aplicar, como por exemplo a Dinâmica de Grupo exige. 
� Garante anonimato das respostas 
� Permite que as pessoas respondam no momento que achar 
conveniente 
� Não expõe ninguém as influências das opniões pessoais do 
entrevistado 
 
 
 
 
Elicitação de requisitos 
� Questionário 
� Desvantagens: 
� Exclui algumas pessoas (deficientes visuais,analfabetos) 
� Impede o auxílio de informantes quando este não entende 
corretamente as instruções e perguntas 
� Impede o conhecimento das circunstâncias em que foi respondido 
(isso pode influenciar na resposta) 
� Não oferece garantia de que serão devolvidos 
� Precisam ser pequenos (os grandes não serão respondidos) 
 
 
 
 
 
 
 
Elicitação de requisitosdo Escopo 
� Questionários e Pesquisas: BOAS PRÁTICAS 
� Prepare seu levantamento ANTES 
� Faça um esboço no editor de texto 
� Pergunte apenas o que realmente é relevante 
� Evite um número muito grande de perguntas 
� Ninguém quer responder algo muito grande 
� Estruture a pesquisa em grupos similares e ordenados 
� Na primeira página, deixe claro os objetivos da pesquisa 
� Questões de identificação pessoal deixe no fim (contatos, 
etc) 
� Quebre em várias páginas 
� Assusta menos 
� Permite pular páginas 
 
 
 
Elicitação de requisitos 
� Questionários e Pesquisas: BOAS PRÁTICAS 
� Não confunda opções de múltpla escolha e escolha 
única 
� É comum confundir! 
� Use lógica condicional 
� Evita que pessoas não precise ler perguntas que não as 
interessa 
� 1- “Você vai a academia regularmente?” (Sim ou não?) 
� “2- Qual equipamento vc usa na academia?” 
� Antes da pergunta 2 é bom dizer que ela é necessária apenas se a 
resposta da 1 for sim. 
 
 
 
 
Elicitação de requisitos 
Questionários e Pesquisas: BOAS PRÁTICAS 
� Padronizar as opções de respostas 
� Muito satisfeito, satisfeito, não satisfeito ou 
� 1, 2, 3 para indicar satisfação. 
� Utilize imagens com moderação 
� Gasta tinta para impressão 
� Lento para carregar (on line) 
 
 
 
 
 
 
 
Elicitação de requisitos 
Questionários e Pesquisas: BOAS PRÁTICAS 
� Esteja ciente dos direitos autorais e leis de proteção de 
dados! 
� Não violar direitos autorais sobre a imagem 
� Não incluir qualquer coisa que seja difamatória 
� Se está coletando dados pessoais, esteja ciente das leis de proteção 
de dados 
� Solicitar todas as permissões necessárias para uso das informações 
 
 
 
 
 
 
 
 
Elicitação de requisitos 
� Questionários e Pesquisas: BOAS PRÁTICAS 
� Seja educado 
� O entrevistado está fazendo um favor 
� Incluir mensagem de saudação BREVE no início 
� Deixe claro a política de privacidade 
 
 
 
 
 
 
 
 
 
 
Mais informações em: 
 http://www.demographix.com/resources/online_survey_best_practice.asp 
http://pareonline.net/pdf/v10n12.pdf 
 
Recomendacões práticas para a ER sugeridas pela IEEE-830 [Byrne 1994]. 
 
Elicitação de requisitos 
� Questionários e Pesquisas: Softwares 
� Vc pode criar no Google Docs 
� Vc pode criar no Tidia 
� Vc pode procurar ferramentas gratuítas para isso! 
� Procure SEMPRE no: http://sourceforge.net/ 
 
� Mas atenção!!! Questionários on-line costumam ter 
um número pequeno de adesão! 
Elicitação de requisitos 
� Observações 
� Fornece uma maneira direta de examinar indivíduos em seu ambiente 
e como desempenham o seu trabalho ou tarefas e executam 
processos. 
� É indicado para situações de resistência na coleta de requisitos 
� Realizada por um observador que visualiza um usuário executando 
seu trabalho; ou 
� Observador participante. 
 
Elicitação 
75 
� Cenários 
� Cenários é um valioso meio para fornecimento de 
contexto para a elicitação das necessidades dos 
utilizadores. 
� Eles permitem o engenheiro de software fornecer um 
quadro para perguntas sobre as tarefas do usuário ao 
permitir Perguntas "e se" e "Como isso é feito" 
Elicitação 
76 
� Cenários 
� Notação 
� Cenários geralmente são representados por narrativas textuais, em linguagem 
natural, que, freqüentemente, são aprimoradas por gráficos, diagramas e imagens 
[RYS 2000]. Podem também ser representados através de protótipos, storyboards, 
vídeos, maquetes, ou até mesmo por situações físicas planejadas para suportar as 
atividades de um usuário [CAR 2000]. Um exemplo de cenário pode ser observado 
abaixo: 
� Maria deseja utilizar o caixa eletrônico do banco X para retirar RS 50,00 em dinheiro 
de sua conta corrente; Ela passa seu cartão no leitor do caixa eletrônico pronto para 
ser usado. O sistema valida o cartão e, em seguida, requisita a senha a Maria. Pelo 
teclado, Maria digita sua senha. O sistema valida a senha digitada e mostra na tela o 
menu de opções de transações. Maria escolhe a opção saque, tocando no botão com 
esta denominação que está na tela; em seguida escolhe R$ 50,00 no menu de 
possíveis quantidades de dinheiro. O caixa automático verifica a quantia escolhida, a 
existência de fundos, aprova a transação e libera a quantia correta e um recibo do 
saque. Maria pegao dinheiro e o recibo nos locais especificados, o sistema debita a 
quantia da conta corrente, exibe uma mensagem, pedindo para o cliente certificar-se 
de que está de posse do seu cartão magnético; e, por fim, mostra novamente o menu 
de opções de transações. 
� Mostra o cenário para o usuário de pois faz perguntas a respeito. 
 
Elicitação de requisitos 
� Protótipos 
� Modelo funcional do produto esperado 
� Permitam que as partes interessadas façam experiências com um 
modelo do seu produto final ao invés de somente discutirem 
representções abstratas dos seus requisitos 
� Protótipos suportam o conceito de elaboração progressiva 
� Quando suficientes ciclos de coletas de feedback forem realizados, os 
requisitos obtidos do mesmo estarão completos para se partir para 
fase de concepção ou construção 
� TÉCNICA MUITO PODEROSA 
� PODE SER USADO TAMBÉM NA ANÁLISE DE REQUISITOS E NA 
VALIDAÇÃO