Escolar Documentos
Profissional Documentos
Cultura Documentos
Analisederequisitossoftwarev28 090829201326 Phpapp01
Analisederequisitossoftwarev28 090829201326 Phpapp01
rildosan@uol.com.br rildo.santos@companyweb.com.br
Contedo:
Sobre o Autor Analise de Requisitos de Software Sobre a Apresentao Introduo 1 Requisitos de Software
Sobre o autor:
Coach e Consultor de Gesto de Negcios, Inovao e Tecnologia para a Gesto 2.0, a Gesto gil. A Gesto gil ajuda as empresas a responder mais rpido as demandas de negcio e mudanas. A Gesto 2.0, abrange Planejamento Estratgico, Gesto por Processos geis, Gesto de Projetos geis, Tecnologia da Informao (Mtodos geis), Inovao e Liderana. Minha Experincia: Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia de Software. Formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie.
Rildo Santos
Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM. Conheo Mtodos geis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Servio), RUP/UP - Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA. Possuo fortes conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de Projetos e GRC - Governance, Risk and Compliance), SOX, Basel II e PCI; E experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Conhecimento dos principais frameworks e padres: ITIL, Cobit, ISO 27001 e ISO 15999; Desempenhei diversos papis como: Estrategista de Negcio, Gerente de Negcio, Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicaes, Seguro, Sade, Comunicao, Segurana Pblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs. Possuo as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International Institute of Business Analysis (Canada) Onde estou: Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/
Verso 28
Sobre o Apresentao
Esta apresentao discute e fornece informao sobre o Ciclo de Requisitos de Software, indo da elicitao at a especificao de requisitos de software. abordado as principais tcnicas, ferramentas e melhores prticas para desenvolvimento da especificao de requisitos
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
Introduo
Introduo
Fases
Fluxos de Trabalho Concepo Elaborao
Modelagem de Negcios
Nosso escopo
Construo Transio
Opcional
Gerncia de Configurao Gerncia de Projeto Ambiente
Iteraes Preelim. Iter. #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1
Iteraes
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
Introduo
Requisitos de Software
Requisitos de Software
Objetivo desta parte:
apresentar e discutir o Ciclo de Requisitos de Software: Identificao, Elicitao, Anlise, Especificao e Validao
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
Introduo
Um cenrio comum:
Verso 28
Requisitos de Software
Requisitos
Verso 28
10
Requisitos de Software
Verso 28
11
Requisitos de Software
Elicitao de Requisitos
Analise de Requisitos de Software
A elicitao de requisitos corresponde a identificar junto aos clientes/usurios quais so os objetivos do sistema, o que deve ser acompanhado, como o sistema se encaixa no contexto das necessidades do negcio e, finalmente, como ser a utilizao do sistema no dia-a-dia. A parte mais rdua na construo de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correes posteriores. " F. Brook Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razes desta dificuldade: Problemas de escopo: Os limites do sistema so geralmente definidos de forma incompleta, ou os clientes/usurios especificam detalhes tcnicos desnecessrios; Problemas de compreenso: Os clientes/usurios geralmente no esto completamente certos das necessidades, tm uma pouca compreenso ou do domnio do seu negcio, omitem informaes que julgam bvias e etc. Problemas de volatilidade: Os requisitos mudam o tempo todo.
12
Verso 28
Requisitos de Software
Elicitao de Requisitos
Analise de Requisitos de Software
Para ajudar a superar estes problemas, os desenvolvedores devem abordar os requisitos de forma simples, prtica e organizada. Alguns passos so recomendados para atividade de Elicitao de Requisitos de Software: - Avaliar a viabilidade tcnica e de negcio para o sistema proposto; - Identificar as pessoas que vo auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais; - Definir o ambiente tcnico no qual o sistema ser instalado; - Identificar regras de domnio que limitam a funcionalidade ou desempenho do software que ser construdo; - Definir um ou mais mtodos de elicitao de requisitos; - Solicitar participao de vrias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista; - Identificar claramente a justificativa de existncia para cada requisito registrado; - Identificar requisitos ambguos que sero candidatos a prototipao. Os documentos criados como conseqncia da atividade de elicitao de requisitos iro depender do tamanho do software/sistema que ser construdo.
Verso 28
13
Elicitao de Requisitos
Para a maioria dos sistemas, estes documentos de trabalho incluem:
- As necessidades e viabilidade estruturadas; - O limite de escopo do software/sistema; - Lista de clientes, usurios e outros stakeholders* que participaram da atividade de elicitao de requisitos; - Descrio do ambiente tcnico do sistema; - Lista de requisitos e as regras de domnio aplicveis a cada um. - Conjunto de cenrios de uso capazes de prover uma idia do uso do sistema ou produto sob diferentes condies de operao; - Qualquer prottipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos. Cada um destes documentos deve ser revisado por todas as pessoas que tenham participado da elicitao de requisitos.
Stakeholder = Todos os clientes interessados no contexto de requisitos, pode ser uma pessoa ou entidade
Verso 28
14
Requisitos de Software
Elicitao de Requisitos
Objetivos da Elicitao de Requisitos:
Obter conhecimento relevante para o problema e prover o mais correto entendimento de o que esperado do software/sistema;
Tcnicas para Elicitao de Requisitos: - Cenrios: representar tarefas que executam e as que desejam executar - Tcnicas tradicionais: questionrios, entrevistas, anlise de documentao existente - Tcnicas de elicitao de grupo: Dinmica de grupo - Prototipao: quando existe alto grau de incerteza e necessita de um rpido feedback
Verso 28
15
Requisitos de Software
Regras de negcio
Documento de Requisitos
Documentos
16
17
Regras de negcio
Documento de Requisitos
Documentos
Verso 28
18
19
Verso 28
20
Reunies e Workshops
Documentos e sistemas
Verso 28
21
Planejamento
Elicitao de Requisitos
Documentao
Documento de Viso
Verso 28
22
Identificao e Elicitao de Requisitos As informaes podem ser identificadas ou encontradas em diversas fontes:
- Usurios; - Documentos; - Especificaes tcnicas; - Clientes; - Sistemas legados - Patrocinadores; - Analista de Negcio - Domain Experts - Especialista em uma ou mais rea de negcio
Verso 28
23
Existem vrias tcnicas, todas elas possuem seus prprios conceitos, vantagens e desvantagens, que podem ser usada nesta atividade entre elas esto:
- Reunies formais; - Reunies informais; - Entrevistas; - Questionrios; - Workshop; - Brainstorming; - JAD (Join Application Development) - Fast; - Anlise de Documentos; - Manual de Sistemas Legados.
Verso 28
24
Identificao e Elicitao de Requisitos Quais as informaes que devo identificar, levantar e coletar ?
Aps a atividade de Identificao/Elicitao de Requisitos, atravs de alguma tcnica formal ou informal, as seguintes informaes que devemos obter so: Entendimento do problema, identificao da lista dos principais usurios, lista dos principais Requisitos, identificao dos Riscos e as Restries do software.
Da podemos organizar as informaes da seguinte maneira: - Contexto (Declarao do problema e Diagrama de Contexto); - Identificao dos usurios e entidades externas; - Identificao dos Requisitos; - Identificao dos Riscos e - Identificao das Restries.
Verso 28
25
- Declarao do problema:
uma descrio narrativa, que apresenta de forma concisa e clara s necessidades dos usurios. Esta narrativa tambm deve descrever o cenrio atual e as necessidades futuras. A linguagem usada neste documento pode ser tcnica ou de negcios, entretanto, evite o usar jarges que no se enquadram no escopo do problema.
- Diagrama de Contexto:
Estabelece quais so as fronteiras do software e principais funcionalidades, ou seja, onde as responsabilidades do software comeam e quando acabam.
Verso 28
26
Stakeholders podem ser pessoas ou entidades que influenciam a construo do software. Exemplo: - Usurios, porque definem os requisitos - Gerentes, Diretores, Patrocinadores porque influenciam atravs de tomada de deciso.
Verso 28
27
Verso 28
28
Requisitos
Requisitos Funcionais
Definem as funcionalidades do sistema. O que sistema deve fazer.
Requisitos No-Funcionais
Declaram as caractersticas que o sistema deve possuir e que esto relacionadas s suas funcionalidades.
Requisitos de Software
Verso 28
29
Os requisitos funcionais descrevem o que o sistema deve fazer, isto , as funes necessrias para atender os objetivos do sistema.
Exemplo:
- Cadastrar Clientes; - Fazer Anlise de Crdito; - Fazer uma Transao com Banco de Dados; - Cadastrar um Registro de Atendimento; - Imprimir Relatrio - etc.
Verso 28
30
Os requisitos no funcionais dizem respeito as caractersticas do software, exemplos: performance, portabilidade, segurana, usabilidade e etc. Estas caractersticas descrevem tambm a qualidade do servio (QoS). A no considerao ou esquecimento desses fatores na Workflow de Requisitos constitui uma das principais razes de uma eventual insatisfao dos usurios com relao a um software. Os requisitos no funcionais tambm so chamamos de RNF ou Requisito Suplementares. Exemplos de RNF:
Verso 28
31
Este documento possibilita a identificao, extrao e classificao dos requisitos - Requisitos funcionais e - Requisitos no funcionais.
Verso 28
32
Declarao do Problema Exemplo: Acompanhamento das estatsticas de aprendizado do aluno e da turma (professor)
Informao: Relatrio de aproveitamento do aluno e da turma (s) Requisitos Funcionais: O sistema deve registrar as principais aes de cada usurio. O sistema deve fornecer um relatrio do aproveitamento do aluno. O relatrio de aproveitamento do aluno deve conter o tempo de uso do software, o nmero de exerccios feitos, o nmero de acertos e o de erros. O sistema deve fornecer um relatrio do aproveitamento da turma. O relatrio de aproveitamento da turma deve conter a mdia e o desvio-padro dos seguintes dados: tempo de uso do software, nmero de exerccios feitos, nmero de acertos e erros de cada exerccio. Requisitos No-Funcionais: O sistema deve usar grficos comparativos do aproveitamento do aluno com a mdia da turma O sistema deve usar cores na construo dos grficos O tempo de resposta na elaborao do relatrio no pode ser superior a 15 segundos.
Verso 28
33
Verso 28
34
- Tecnologia: Uso de tecnologias emergentes; Integrao com legado - Recursos: Oramento estreito; Contratao de Terceiros - Habilidade: Falta de domnio da tecnologia (conhecimento e experincia) - Requisitos: Requisitos no so plenamente conhecidos
Verso 28
35
Verso 28
36
Objetivo: Fazer uma descrio da viso do software Este documento tem as as seguintes sees:
- Declarao do Problema; - Lista dos Stakeholders - Lista dos Requisitos - Lista de Riscos - Lista das Restries
Verso 28
37
Documento de Viso:
Data: ________ | Autor: ________ | Reviso: ____ ndice: 1.0 - Introduo 1.1 Objetivo do documento 1.2 Escopo 1.3 Abreviaturas, Siglas e etc. 2.0 Contexto 2.1 Declarao do Problema 3.0 Lista de Stakeholders 3.1 Stakeholders primrios 3.2 Stakeholders segundrios 4.0 Lista dos Requisitos 4.1 Requisitos funcionais 4.2 Requisitos no funcionais 5.0 Lista dos Riscos 6.0 Lista das Restries 6.1 Software 6.2 Hardware 6.3 Ambiente e Tecnologia
Verso 28
38
Anlise de Requisitos
Objetivo desta parte: apresentar e discutir as atividades da anlise de requisitos de software
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
39
Anlise de Requisitos
Regras de negcio
Documento de Requisitos
Documentos
Verso 28
40
Anlise de Requisitos
Requisitos: Condio necessria para a obteno de certo objetivo, ou para o preenchimento de certo objetivo.
O Documento de Viso um artefato importante na Anlise de Requisitos, destacamos algumas razes: - Da perspectiva da engenharia de software, a elicitao de requisitos talvez a mais parte mais critica do processo de desenvolvimento de software. Estudos indicam que os requisitos, s detectados depois do software implementado ou erros na anlise de requisitos, so at 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Verso 28
41
Anlise de Requisitos
Anlise de Requisitos
Analise de Requisitos de Software
A Anlise de Requisitos deve ser: Correta: Quando cada requisito expresso nela for encontrado no software; No Ambgua: Cada requisito deve ter somente uma interpretao; Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos relacionados a qualidade do servio (tambm conhecidos como requisitos no funcionais) Consistente: Quando no existir conflito entre os requisitos; Verificvel: Quando for possvel verificar/validar cada requisito; Modificvel: Quando os requisitos podem ser facilmente alterados.
Verso 28
42
Anlise de Requisitos
Anlise de Requisitos
Analise de Requisitos de Software
Atividades da Anlise de Requisitos A anlise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades, classificando e detalhando os requisitos encontrados na coleta. Os requisitos funcionais sero descritos em detalhes. E os requisitos no funcionais sero classificados.
Verso 28
43
Anlise de Requisitos
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padro para esta atividade. Veja o exemplo: Lista de Requisitos funcionais
Autor: Reviso: Data Atualizao:
Nome
Cdigo
Descrio
Fazer Reserva RF01E Esta funcionalidade dever permitir o usurio (funcionrio) a fazer reserva de apartamentos, as aes que estaro disponveis so: criar, remover, alterar e consultar reservas. Cada reserva dever ter um cliente e um apartamento e respectiva perodo)
Verso 28
44
Anlise de Requisitos
id
Nome da Regra
Descrio da Regra de Negcio A confirmao do registro de reserva de apartamento deve ocorrer aps o pagamento de 25% do valor da estadia. Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem preferncia de data e tipo de apartamento. No perodo de baixa a estao (de mar a jun e ago a nov) o valor da diria tem um desconto de 40%. Para que agilizar o atendimento manter a satisfao do cliente as consultas de reserva devem ser feitas em no mximo 30 segundos.
Data Nome / Equipe RFS Verso 2.1 Status Vigente
RN01
01/01/08
Requisitos Funcional
RN: RN01 ID RFC01 Nome: Reserva Nome Registrar Reserva de Apartamento Descrio: Servio de Atendimento e Reserva de Apartamento Descrio Esta funcionalidade dever permitir o usurio (funcionrio) a fazer reserva de apartamentos, as aes que estaro disponveis so: criar, cancelar, alterar e consultar reservas.
Verso 28
45
Anlise de Requisitos
Agora vamos descrever os Requisitos No Funcionais. Entretanto, precisamos categorizar estes requisitos, as mais frequente so:
- Performance: Tempo de resposta - Segurana: Uso de senhas, certificados digitais e etc.. - Usabilidade: Identidade Visual e Interfaces amigveis - Disponibilidade: O software deve estar disponvel para usurio 24x7. Exemplo: Tolerncia a falha - Flexibilidade: Capacidade de adaptao quando um requisito muda - Portabilidade: Capacidade de se adaptar a outros ambientes (sistemas operacionais) - Escalabilidade: Capacidade de responder aumento de carga (novos usurios) Outras categorias como Integrao, Processamento, Manutenvel e etc.
Verso 28
46
Anlise de Requisitos
Bem vamos descrever os requisitos no funcionais. Como na descrio dos Requisitos funcionais, precisamos ter um padro Lista de Requisitos No funcionais
Categoria: Performance
Autor:
Req. Funcional Cdigo RNFP1 Descrio
Reviso:
Data Atualizao:
Fazer Consulta
As consultas que sero realizadas pelo cliente no podero exceder ao tempo de resposta de 15 segundos
Por que preciso de um cdigo ? Este cdigo tem como objetivo facilitar a rastreabilidade. Ele pode ser usado no Formulrio de Caso de Uso, por exemplo, desta forma conseguiremos identificar qual o caso de uso que realiza este RNF, no caso de mudanas.
Verso 28
47
Anlise de Requisitos
Autor:
RF / Aplicao Cdigo RNFU1 Descrio
Reviso:
Data Atualizao:
Aplicao Aplicao
As cores, as fontes e logotipos devem seguir o Manual de Identidade Visual da empresa. As interfaces com usurio devem seguir padro de interfaces estabelecido pelo Manual de Sistema
RNFU2
Verso 28
48
Anlise de Requisitos
Cliente Colaborador
Verso 28
49
Anlise de Requisitos
Verso 28
50
Anlise de Requisitos
Verso 28
51
Anlise de Requisitos
Verso 28
52
Anlise de Requisitos
Data: ________ | Autor: ________ | Reviso: ____ ndice: 1.0 - Introduo 1.1 Objetivo do documento 1.2 Escopo 2.0 Descrio dos Requisitos Funcionais 3.0 Descrio dos Requisitos No Funcionais 4.0 Lista dos Stakeholders (clientes e usurios) 4.1 Stakeholders primrios 4.2 Stakeholders segundrioss 5.0 Plano de Mitigao de Riscos
Verso 28
53
Anlise de Requisitos
Mitos e Lendas:
Analise de Requisitos de Software
O que dito: - Usurios no entendem do negcio... - Requisitos so estticos... - Achar que tem a soluo, mesmo antes de conhecer todo o problema...
Entretanto, a realidade outra... - Requisitos no so estticos, eles mudam constantemente... - Fazer amplas discusses que envolvam o maior nmero de pessoas que conheam o negcio, antes de apresentar uma a soluo
Verso 28
54
55
Regras de negcio
Documento de Requisitos
Documentos
Verso 28
56
Documento de Viso
Requisitos Funcionais
Requisitos No Funcionais
Restries de Projeto
Documento de Requisitos
Especificao de Requisitos
Arquitetura do Software
Casos de Uso
Seqncia Classes
Colaborao
Implementao
Distribuio
Verso 28
57
Objetivos:
Identificar os atores; Identificar os casos de uso; Desenhar os casos de uso e Escrever cenrios.
Verso 28
58
Calcular Total
Cliente
Emitir NF
59
Verso 28
Verso 28
60
Caso de Uso uma representao grfica e semntica da interao do usurio e o sistema. Os diagramas de caso de uso so usados para capturar os requisitos funcionais do sistema. Ajuda o entendimento do contexto dos requerimentos do sistema. Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organizao funcional.
Verso 28
61
Definio: Caso de Uso uma descrio de um conjunto de seqncias de aes, inclusive variantes, que um sistema pode produzir um resultado de valor observvel por um ator. A representao grfica uma elipse.
Caso de Uso
Gerenciar Reserva
Ator
Usurio Nome
Verso 28
62
Verso 28
63
Em dada Loja virtual, podemos o seguinte cenrio de Compra de um produto: O cliente navega no catlogo de itens e adiciona os itens desejado sua cesta de compra. Quando o cliente deseja pagar, fornece os dados do carto de crdito e confirma a compra. O sistema solicita o endereo de entrega para o pedido. O sistema verifica a autorizao do carto de crdito e confirma a transao imediatamente enviando um e-mail para o usurio.
Este um dos cenrio que pode acontecer. Se houver algum problema, com a autorizao da transao do carto de crdito teremos um novo cenrio.
Verso 28
64
Autorizao de acesso. O usurio executa a aplicao, o sistema exibe a janela de identificao que pede a identificao do usurio, ou seja, seu nome e sua senha, O usurio informa seu nome e sua senha, o sistema valida as informaes e d a autorizao de acesso ao sistema. Se senha for invalida ou nome neste caso teremos um novo cenrio.
Verso 28
65
Uso caso de uso descreve o qu um sistema (ou subsistema, classe, ou interface) faz, ele no especifica como isso feito. Ao fazer uma modelagem, importante manter clara a separao de questes entre a viso interna e externa. Podemos especificar o comportamento de um caso de uso pela descrio do fluxo de eventos no texto de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e quando o caso de uso interage com os atores e o fluxo bsico e fluxo alternativo do comportamento. Tipos de fluxos: Fluxo de eventos principal e Fluxo alternativo de eventos.
Verso 28
66
Verso 28
67
Opcionalmente podemos acrescentar outros itens ao Formulrio de Caso Uso. Exemplos: - Nome ou cdigo dos Requisitos (RN e RNF) que esto associados a este caso de uso
Verso 28
68
Verso 28
Verso 28
70
Gerente de Educo
Gerar catalogo
Pedir lista dos matriculados Sistema de cobrana Matrcula nos Cursos Professor
Verso 28
71
Verso 28
72
Verso 28
73
Verso 28
74
Funcionrio
Recepcionista
Gerente de Reservas
Verso 28
75
Locadora de Automveis
Devolver Veculo
<<include>>
<<include>>
<<extend>>
Consulta Cliente
Calcular Multa
Verso 28
76
Acompanhar Pedido
<<include>>
Verso 28
77
Fazer Check IN Fazer Check OUT Gerenciar Reserva Receber Pagamento <<include>> <<include>>
Verso 28
78
Os atores no fazem parte do sistema - eles representam qualquer um e qualquer coisa que faa interao com sistema. Podendo ser uma pessoa, software, hardware e etc.
Uma ator pode: - Apenas fornecer informaes ao sistema - Apenas receber informaes do sistema - Fornecer e receber informaes ao sistema Tipicamente os atores so identificados nas Declaraes de Problemas (Documento de Viso) ou atravs de entrevistas com os usurios e outros envolvidos no processo, como, Gerente, Especialista em Negcio, Analista de Sistema e Analista de Negcio, por exemplo. As seguintes questes podem ser usadas para identificar o atores: - Onde o sistema ser usado ? - Quais reas sero usurias do sistema ? - O sistema usar recurso externo ? - Quem ser o responsvel pelo sistema ? - Quem sero os usurios do sistema ?
Verso 28
79
Exemplo: No domnio de ponto de venda, algum pode definir um caso de uso chamado Imprimindo o Recibo, quando de fato, a operao de impresso meramente um passo no processo muito mais abrangente do caso de uso Comprar Itens
Lembre-se: Um caso de uso uma descrio completa de processo, que inclui outros passos ou transaes.
Verso 28
80
Documento de Requisitos
Verso 28
81
Especificao de Requisitos:
3
Formulrio
Cenrios
Usurio Ator
Associao
Verso 28
82
Escrevendo os Cenrios:
Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva. Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa que no tem disponibilidade de apartamento para o perodo informado pelo cliente e oferece um outro tipo de apartamento. O cliente aceita o apartamento e ento o funcionrio confirma a reserva.
Cenrios
Verso 28
83
Escrevendo os Cenrios:
Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa que no tem disponibilidade de apartamento para o perodo informado pelo cliente e oferece um outro tipo de apartamento. O cliente no aceita a proposta do funcionrio e a reserva no confirmada.
Cenrios
Verso 28
84
Cenrios
Formulrio
Pr- condio
Verso 28
85
Nome: Gerenciar Reserva Ponto de ativao: Este caso de uso comea quando o funcionrio do setor de reserva recebe uma solicitao de reserva Ator: Funcionrio Objetivo: Fazer reservar de apartamentos Pr-condio: Solicitao de reserva Fluxo Normal:
Fluxo Alternativo:
Verso 28
Verso 28
87
Especificao de Requisitos:
3
Formulrio
Cenrios
Verso 28
88
Verso 28
89
Mitos e Lendas
Requisitos no so Casos de Uso;
Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo: Caso de Uso Fazer Busca, est associado a dois requisitos: (RF) Fazer Buscar (RNF) O tempo de resposta para transao deve ser 10 segundos (Desempenho)
Verso 28
90
Verso 28
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2 - Identifique tambm os ATORES e seus respectivos PAPIS; 3 - D um nome para o CASO DE USO, lembre-se que este nome deve ser nico no modelo; 4 - Escreva os CENRIOS para o CASO DE USO; 5 - Compile os CENRIOS em nico FORMULRIO e 6 - Faa o Diagrama de Caso de Uso (Use Rational Rose para fazer isto).
Verso 28
92
Pr-condio: <descrever a pr-condio> Fluxo Normal: <descrever o fluxo normal> Fluxo Alternativo: <descrever o fluxo alternativo>
Ps-condio: <descrever a ps-condio> RF: <informar os cdigo ou nomes dos RFs> RNF: <informar os cdigo ou nomes dos RNFs>
Verso 28
93
Escrever cenrios
Escrever Formulrio Fazer Diagrama de Caso de Uso
Rational Rose
Refinar Diagrama de Casos de Uso Neste momento vamos refinar o Diagrama de Caso de Uso: 1 - Identificar os pontos de extenso 2 - Identificar as generalizaes 3 - Identificar os pontos de incluso
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
94
Sem include:
Com include:
<<include>>
Buscar Apartamento
Funcionrio
Gerenciar Reserva
<<include>>
Funcionrio
Gerenciar Reserva
Cadastrar Cliente
Verso 28
95
Cancelar Check IN
<<extend>>
Recepcionista
Fazer Check IN
<<include>>
Recepcionista
Fazer Check IN
<<include>>
Consultar Reserva
Consultar Cliente
Verso 28
96
Sem include:
Com include:
<<include>>
Consultar Cliente
<<include>>
Recepcionista
Consultar Reserva
<<include>>
Recepcionista
Receber Pagamento
Verso 28
97
Validao de Requisitos
Objetivo desta parte: apresentar as principais tcnicas para validao de requisitos de software.
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
98
Validao de Requisitos
Regras de negcio
Documento de Requisitos
Documentos
Verso 28
99
Validao de Requisitos
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usurio deseja. Validao importante uma vez que o custo para remover um erro de requisitos grande. Pequeno Check List de Requisitos: Validade. O sistema fornece as funes que melhor atende as necessidades do usurio? Consistncia. Existem conflitos de requisitos? Completeza. Todas as funes necessrias para o cliente esto includas?
Verso 28
100
Validao de Requisitos
Tcnicas de validao de requisitos Reviso de requisitos: - Anlise manual sistemtica dos requisitos Prototipao: - Uso de um modelo executvel do sistema para checar os requisitos. Gerao de casos de teste: - Desenvolver testes para validar a implementao dos requisitos. Anlise automatizada da consistncia: - Uso de ferramenta para verificar a consistncia do modelo.
Reviso de requisitos: - Revises regulares devem ocorrer durante a formulao da definio dos requisitos - Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revises - As revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre os desenvolvedores, clientes e usurios pode resolver problemas em estgios iniciais
Verificao de revises: - Verificabilidade. O requisito realisticamente testvel? - Compreensibilidade. O requisito propriamente entendido? - Rastreabilidade. A origem do requisito claramente estabelecida? - Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros requisitos?
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
101
Validao de Requisitos
O Caso de Teste deve especificar a sada esperada e os resultados esperados do processamento. Numa situao ideal, no desenvolvimento de casos de teste, se espera encontrar o subconjunto dos casos de teste possveis com a maior probabilidade de encontrar a maioria dos erros. Os Casos de Uso so a base para os Casos de Teste
Verso 28
102
Validao de Requisitos
Cenrio
Fluxo Normal Entrada: nome e senha Fluxo Alternativo 1 Entrada: nome e senha
Cliente
Cenrio 1
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
103
Validao de Requisitos
Tcnicas de validao de requisitos Verificao de Consistncia Automatizada:
Relatrio
Processador de Requisitos
Anlise de Requisitos
Verso 28
104
105
Requisitos so inevitavelmente incompletos e inconsistentes: Novos requisitos surgem durante o processo de desenvolvimento. Diferentes pontos de vista possuem diferentes requisitos e esses so freqentemente contraditrios. Mudanas nos requisitos:
- A prioridade dos requisitos podem mudar para atender novas demandas de negcio
- Requisitos podem sofrer alterao quando muda a regra de negcio; - As pessoas que pagam pelo software/sistema podem especificar os requisitos de maneira conflitantes com os requisitos das pessoas que iro utilizar o software/sistema. - A empresa e o ambiente tcnico do software/sistema se modificam durante o processo de desenvolvimento
Verso 28
106
Requisitos iniciais
Requisitos modificados
tempo
Verso 28
107
108
A identificao dos requisitos: Como os requisitos so individualmente identificados Um processo de mudana de gerenciamento: O processo seguinte anlise de uma mudana de requisito Polticas de rastreabilidade: A quantidade de informaes (histrico) sobre o relacionamento entre requisitos que mantida. Como rastrear as mudanas de requisitos e seus possveis impactos. Suporte ferramenta: O suporte ferramenta necessrio para auxiliar no Gerenciamento de Mudanas de Requisitos
Verso 28
109
- Rastreabilidade preocupa-se com as relaes entre requisitos, suas fontes e o projeto do software/sistema
Rastreabilidade de fonte: Links de requisitos para stakeholders que propuseram os requisitos Rastreabilidade de requisitos: Links entre requisitos dependentes Rastreabilidade do projeto: Links dos requisitos para o projeto
Verso 28
110
Verso 28
111
Principais estgios: - Anlise do problema e especificao da mudana. Discute-se os problemas com os requisitos e prope-se mudanas. - Anlise e custo da mudana. Avalia-se os efeitos da mudana em outros requisitos do sistema. - Implementao das mudanas. O documento de requisitos e outros documentos so alterados de forma a refletir as mudanas.
implementao da mudana
Requisito Alterado
Verso 28
112
Verso 28
113
Verso 28
114
Contedo:
Tcnicas para identificao/elicitao de requisitos: - JAD - FAST Documento de Requisitos - Padro IEEE/ANSI 830-1993:
Verso 28
115
Anexo
JAD (Join Application Development)
A tcnica JAD desenvolvida na IBM no fim dos anos 70 visa criar sesses de trabalho estruturadas, atravs de uma dinmica de grupo e recursos visuais, em que analistas e usurios trabalham juntos para projetar um sistema, desde os requisitos bsicos at o layout de telas e relatrios, prevalecendo a cooperao e o entendimento [PORTELLA1994]. Os desenvolvedores ajudam os usurios a formular os problemas e explorar possveis solues, envolvendo-os e fazendo com que eles se sintam participantes do desenvolvimento
JAD se baseia em quatro princpios bsicos: 1. Dinmica de grupo, com a utilizao de sesses de grupo facilitadas para aumentar a capacidade dos indivduos; 2. Uso de tcnicas audiovisuais para aumentar a comunicao e o entendimento; 3. Manuteno do processo organizado e racional; e 4. Utilizao de documentao-padro, que preenchida e assinada por todos os participantes de uma sesso. A tcnica JAD tem duas grandes etapas: planejamento, cujo objetivo elicitar e especificar requisitos; e projeto, em que se lida com o projeto do software. Nesta monografia somente ser tratada a primeira etapa. Os participantes de uma sesso de JAD desempenham seis diferentes papis: lder da sesso, representantes do usurio, especialista, analista, representantes dos sistemas de informao e patrocinador executivo.
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
116
Anexo
JAD (Join Application Development)
continuao
A tcnica pode ser usada tanto para elicitar como nas fases iniciais da especificao de requisitos. Ela ajuda a identificar os assuntos que podem necessitar de rastreamento e fornece uma perspectiva multifacetada dos requisitos. Sesses de JAD permitem aos analistas coletar simultnea e eficientemente uma grande quantidade de requisitos do sistema junto a uma gama de usurios-chave. So teis por considerar necessidades especficas dos usurios. JAD tambm pode ser usada em conjunto com outra tcnica de elicitao como, por exemplo, a prototipao. medida que os requisitos so obtidos nas sesses, pode-se construir um prottipo que demonstre alguma funcionalidade destes requisitos.
Verso 28
117
Anexo
FAST (facilited application specification technique): Combina: identificao do problema, negociao e especificao de um conjunto preliminar de requisitos. Diretrizes bsicas: - Encontro de clientes e desenvolvedores em local neutro - Estabelecer regras para preparao e participao; - sugerida uma agenda cobrindo todos os pontos importantes e que encoraja o livre fluxo de idias; - Facilitador(cliente,desenvolvedor, ou elemento externo) para controlar o encontro.
Verso 28
118
Anexo
Documento de Requisitos: Formato do documento de especificao de requisitos sugerido pela IEEE/ANSI 8301993: Estrutura do Documento: 1.0 Introduo 1.1 propsito do documento de requisitos 1.2 escopo do produto 1.3 definies, acrnimos e abreviaes 1.4 referncias 1.5 viso geral do restante do documento 2.0 Descrio geral 2.1 perspectiva do produto 2.2 funes do produto 2.3 caractersticas do usurio 2.4 restries gerais 2.5 suposies e dependncias 3. Requisitos (Especficos) os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do sistema, especificar requisitos lgicos de banco de dados,restries de projeto, caractersticas de qualidade. 4. Apndices 5. ndice
Verso 28 Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
119
Notas:
Marcas Registradas: Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial so de responsabilidade de seus proprietrios. O autor informa no estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde j o autor informa que o uso apenas ilustrativo e/ou educativo, no visando ao lucro, favorecimento ou desmerecimento do produto/fabricante. Melhoria e Reviso: Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema ou erro envie um e-mail. Criticas e Sugestes: Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor envie um e-mail.
120
Licena:
Verso 28
121
Rildo F Santos
rildosan@uol.com.br rildo.santos@companyweb.com.br