Apostila PSP Requisitos v1.2

Processo de Software da PBH/Prodabel PSP
Requisitos de Software e Casos de uso
Gerncia de Engenharia de Software (GESS-PB) Superintendncia de Arquitetura de Sistemas (SAS-PB) Diretoria de Sistemas e Informao (DS-PB) Empresa de Informtica e Informao de Belo Horizonte (Prodabel S/A)
Verso 1.2
Sumrio 1. Requisitos de software 2. Engenharia de requisitos 3. Tcnicas de levantamento (elicitao) de requisitos 4. Casos de uso 5. Modelagem de casos de uso 6. Exerccios
Processo de software PBH/Prodabel
Requisitos de software
Verso 1.2
Objetivos
Entender o que um requisito Apresentar as classificaes dos requisitos
Requisitos
Processo de software da PBH/Prodabel
C1-Introduo
Roteiro
Problemas de desenvolvimento de software Definio de requisitos Classificao dos requisitos Visibilidade Natureza Regras de negcio Requisitos e processos Interessados nos requisitos Engenharia de requisitos Desenvolvimento de requisitos Gerenciamento de requisitos
Requisitos Processo de software da PBH/Prodabel 3
Problemas do desenvolvimento de software

A parte mais difcil de construir um software decidir precisamente o que deve ser feito. Nenhuma outra parte do trabalho conceitual to difcil do que estabelecer os requisitos detalhados, incluindo todas as interfaces com pessoas, equipamentos e outros sistemas. Nenhuma parte do trabalho influencia tanto o sistema resultante se feita incorretamente. Nenhuma parte mais difcil de retificar posteriormente. (Frederick Brooks)
C1-Introduo
Problemas clssicos do desenvolvimento de software
Requisitos
Problemas com requisitos

Envolvimento insuficiente dos usurios. Crescimento dos requisitos de usurio. Requisitos ambguos. Gold plating (bala de prata). Especificaes minimalistas. Excesso de classes de usurio. Planejamento inacurado. Outros: __________________________________________
C1-Introduo
Processo de requisitos efetivo

Reduo de defeitos nos requisitos. Reduo do retrabalho de desenvolvimento. Reduo de caractersticas desnecessrias. Reduo de custos para evolues. Desenvolvimento agilizado. Reduo dos problemas de comunicao. Reduo do crescimento do escopo. Reduo do caos no projeto. Estimativas mais acuradas. Aumento da satisfao dos envolvidos.
Requisitos
O termo requisito nem sempre utilizado pela indstria de software de modo consistente. Em alguns casos, um requisito visto como uma declarao abstrata, de alto nvel, de uma funo que o sistema deve fornecer ou de uma restrio do sistema. No outro extremo, ele pode ser uma definio detalhada, matematicamente formal, de uma funo do sistema. Que definio adotar? __________________________________________
C1-Introduo
Documento de requisitos
Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um projeto de software, suas necessidades tm que ser definidas de forma suficientemente abstrata para que uma soluo a priori no seja definida. No caso de contratao externa os requisitos devem ser redigidos de modo que os diversos fornecedores possam apresentar propostas. Uma vez estabelecido o contrato, o fornecedor escolhido precisa preparar uma definio de sistema para o cliente contendo mais detalhes, de modo que o cliente possa compreender e validar o que o software far. Em ambos os casos, tem-se um documento de requisitos. Essas afirmaes mostram que a definio de requisitos deve ser feita por meio de refinamentos sucessivos, indo do conceitual em direo ao fsico.
Definio de requisitos
1. Condio ou capacidade necessria a um usurio para resolver um problema ou atingir um objetivo. 2. Condio ou capacidade que deve ser alcanada ou possuda por um sistema ou componente de sistema para satisfazer um contrato, padro, especificao ou outro documento formalmente imposto. 3. Uma representao documentada de uma condio ou capacidade como nos itens 1 e 2 acima. Fonte: [IEEE Standard Glossary of Software Engineering Terminology, 1990]
C1-Introduo
Definio de requisitos II
Requsitos so uma especificao do que deve ser implementado. Eles constituem descries de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Podem caracterizar uma restrio no processo de desenvolvimento do sistema. Fonte: Sommervile e Sawyer, Requirements Engineering, 1997].
Requisitos
11
O que requisito no
Especificao de requisitos no incluem: Detalhes de desenho; Implementao; Informaes de teste; Requisitos de projeto; Limites de recursos e tempo; necessidade de um tutorial para os usurios; Etc
C1-Introduo
Classificao dos requisitos

Quanto a visibilidade
Requisitos de usurio; Requisitos de sistema; Requisitos de desenho.
Quanto a natureza
Funcionais; No funcionais.
Requisitos
13
Classificao dos requisitos

+ Conceitual
Domnio do problema => Negcio Necessidades Requisitos de usurio Domnio da soluo => Sistema Requisitos de desenho
+ Fsico
Problema a ser resolvido
Requisitos de sistemas
Produto a ser construdo
Requisitos
14
C1-Introduo
Separao entre domnios

A separao em domnios indica que os requisitos de software tratam da soluo para um problema. O formato da pirmide reflete o volume relativo do problema: poucas necessidades podem exigir vrios requisitos. Rastreabilidade deve ser mantida entre todos os nveis.
Necessidades
Tambm conhecidas como requisitos de negcio, representam objetivos de alto nvel da organizao ou cliente que requisitou o sistema. Tipicamente so originadas do patrocinador do projeto, o adquirente. Por ex: o gerente dos usurios ou o setor de marketing. Descrevem porque a organizao est implementando o sistema os objetivos que espera-se atingir. Normalmente so contemplados num documento de viso ou proposta do projeto. Ex: Reduzir os custos operacionais [em y%]; Aumentar participao no mercado [em x%]; Implantar nova linha de produtos e servios. D um exemplo na sua rea de trabalho: ____________________________________________________
C1-Introduo
Requisitos quanto visibilidade

Requisitos de usurio: Declaraes em linguagem natural e tambm 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 restries de sistema. O documento de requisitos de sistema, tambm chamado Especificao Funcional ou de Requisitos, deve ser preciso. Ele pode servir como um contrato entre comprador e desenvolvedor.
Requisitos de desenho: Uma descrio abstrata que base para detalhes de implementao. Essa especificao acrescenta mais detalhes Especificao de Requisitos do Sistema. um documento orientado implementao.
Pblico-alvo dos documentos

Requisitos de usurio
Gerentes de clientes Usurios finais Tcnicos do cliente Gerentes do fornecedor Arquitetos de sistemas Usurios finais de sistemas Tcnicos do cliente Arquitetos de sistemas Desenvolvedores de software (eventual) Tcnicos do cliente (eventualmente) Arquitetos de sistemas Desenvolvedores de software
Requisitos de sistema
Requisitos de desenho
Requisitos
18
C1-Introduo
Exemplo de requisitos de usurio e sistema

Requisitos de usurio: O sistema deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas. Especificao de requisitos de sistema: O usurio deve dispor de recursos par definir o tipo dos arquivos externos. Cada tipo de arquivo pode ser representado como um cone especfico na tela do usurio. Quando um usurio seleciona um cone de um arquivo externo, o efeito aplicar a ferramenta associada com o tipo de arquivo representado, permitindo executa-lo.
Que software poderia ser este? ______________________________________________

Requisitos funcionais
Declaraes de funes que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como deve se comportar em dadas situaes. Descrevem as funcionalidades ou servios que um sistema oferece. Dependem do tipo de software, usurios esperados e do tipo de sistema onde o software ser utilizado. Enquanto requisitos funcionais de usurio podem ser declaraes de alto nvel do que o sistema deve fazer, requisitos funcionais de sistema devem descrever os servios do sistema em detalhes.
C1-Introduo
10
Requisitos funcionais
Especificam funcionalidades de software que os desenvolvedores devem construir para possibilitar aos usurios executar suas tarefas, satisfazendo aos requisitos de negcio. Esse tipo de requisitos descrito tradicionalmente pela sentena 'deve. Ex: O sistema deve enviar uma mensagem com a confirmao de reserva para o usurio.
Exemplos de requisitos funcionais

Sistema de biblioteca:
O usurio dever ser capaz de buscar todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele. O sistema deve prover telas apropriadas para o usurio ler documentos no repositrio de documentos. Cada pedido ser alocado a um nico identificador (ID_Pedido), que o usurio poder copiar para a rea de armazenagem permanente da conta.
Requisitos
22
C1-Introduo
11
Requisitos no funcionais
Restries sobre as funes oferecidos pelo sistema. Destacamse aqui as restries de tempo, processo e padro. Ex.: tempo de resposta, requisitos de armazenamento, confiabilidade, capacidade dos dispositivos de I/O, etc... Tambm podem ser especificados uma determinada ferramenta CASE, linguagem de programao ou processo de desenvolvimento. Podem ser mais crticos que os requisitos funcionais. Ex: ________________________________________________ Caso no sejam atendidos, o sistema pode tornar-se inutilizvel. Ex: ________________________________________________
Classificao dos requisitos no funcionais

Requisitos de produto
Requisitos organizacionais
Requisitos externos
Facilidade de uso Eficincia
Entrega Implementao Padres
Interoperabilidade ticos Legais
Desempenho Espao Confiabilidade Portabilidade Privacidade Segurana
Requisitos
24
C1-Introduo
12
Classificao dos requisitos no funcionais

Requisitos de produto: Especificam o comportamento do produto.
Requisitos organizacionais: Decorrem de polticas e procedimentos nas organizaes do cliente e/ou do desenvolvedor.
Requisitos externos: Abrangem todos os requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento.
Exemplos de requisitos no funcionais

Requisitos de produto:
Deve ser possvel que toda a comunicao necessria entre o software e o usurio seja expressa no conjunto padro de caracteres ASCII.
Requisitos de organizao:
O processo de desenvolvimento e os documentos entregues devero estar de acordo com o processo e os produtos definidos em XYZCo-SP-STAN-95.
Requisitos externos:
O sistema no dever revelar aos operadores nenhuma informao pessoal sobre os clientes alm de seus nomes e cdigo.
C1-Introduo
13
Metas e requisitos
Requisitos no funcionais podem ser difceis de estabelecer e requisitos imprecisos so difceis para verificar. Metas so teis a medida que elas esclarecem as intenes dos usurios do sistema Meta:
Uma inteno do usurio, como fcil de usar, rpido.
Requisito no funcional verificvel:

Uma sentena que use alguma mtrica que possa ser objetivamente testada.
Exemplos
Uma meta do sistema
O sistema deve ser fcil de ser usado por controladores experientes e organizado de tal forma que os erros possam ser minimizados.
Requisito no funcional verificvel

Controladores experientes devem estar aptos a usar todas as funes do sistema aps um treinamento de duas horas Aps o treinamento, o nmero mdio de erros cometidos pelos usurios experientes no pode exceder o total de dois por dia.
C1-Introduo
14
Mtricas para requisitos

Propriedades Velocidade Mtrica Transaes processadas por segundo Tempo de resposta ao usurio/evento Tempo de refresh de tela K Bytes Nmero de chips de RAM Tempo de treinamento Nmero de frames de ajuda Tempo mdio para falhar Taxa de ocorrncia de falhas Disponibilidade Tempo de reincio aps falha Porcentagem de eventos que causam falhas Probabilidade de corrupo de dados Porcentagem de declaraes dependentes de sistema alvo Nmero de sistemas alvo
Processo de software da PBH/Prodabel 29
Tamanho Facilidade de uso Confiabilidade
Robustez
Portabilidade
Requisitos
Atributos de qualidade
Os requisitos no funcionais tambm so conhecidos como atributos de qualidade (norma ISO 9126):
Viso do cliente:
Disponibilidade Eficincia Flexibilidade Integridade Interoperabilidade Confiabilidade Robustez Usabilidade
Viso do desenvolvedor:
Manutenibilidade Portabilidade Reusabilidade Testabilidade
C1-Introduo
15
Exemplos de atributos de qualidade

Disponibilidade: O sistema deve estar 99,5 % do tempo disponvel nos dias de semana de 6h s 18h. Eficincia: O sistema dever estar reservar pelo menos 25% da capacidade do processador em condies de pico. Integridade: Somente usurios que tem acesso como Auditor devem ser habilitados a visualizar dados de transaes de clientes. Interoperabilidade: O sistema deve ser capaz de importar qualquer registro vlido de funcionrio, provido pelo sistema Pessoal. Confiabilidade: No mximo cinco em cada 1.000 transaes podem falhar.
Regras de negcio
No so exatamente requisitos, pois existem fora dos limites de qualquer sistema especfico. Geralmente restringem quem pode desempenhar determinadas tarefas ou diz que o sistema deve conter certas funcionalidades.
Normalmente inclui polticas da corporao, regulaes governamentais, padres da indstria, prticas contbeis e algoritmos computacionais.
C1-Introduo
16
Regras de negcio
Uma regra de negcio uma sentena que define ou restringe algum aspecto do negcio. Tem por objetivo atender a estrutura, controlar ou influenciar o comportamento do negcio. Classificao das regras de negcio: - Fato - Restrio - Habilitador - Clculo - Inferncia
Fato
Sentenas simples verdadeiras sobre o negcio. Tipicamente descrevem associaes ou relaes entre termos de negcio relevantes. So tambm chamadas de invariantes.
Exemplos:
Cada continer deve ter um nico cdigo de barra identificador. Todo pedido deve ter uma carga de entrega. Taxas de vendas no so computadas nas cargas de envio.
C1-Introduo
17
Restries
Restringem as aes que o sistema ou usurios podem executar. Algumas palavras e frases sugerem restries como deve e no deve.
Exemplos:
Tripulao deve gozar de pelo menos 8 horas de descanso a cada 24 horas. Um cliente com menos de 18 anos deve ser associado a um responsvel.
Requisitos
35
Habilitador
Regra que dispara alguma atividade sob uma condio especfica.
Exemplos:
Se a data de expirao de um produto tiver sido atingida, o responsvel deve ser notificado por email. No ltimo dia da quinzena, gerar os relatrios gerenciais e disponibilizar aos gestores.
Requisitos
36
C1-Introduo
18
Clculo
Clculos realizados usando frmulas matemticas especficas ou algoritmos. Vrios clculos seguem regras externas as organizaes. Exemplos:
O preo total de um pedido determinado pela soma dos preos de cada item, deduzido de qualquer desconto de volume, mais taxas de vendas estaduais e federais, mais taxa de embarque e seguro Tabela de desconto:
Id Desc1 Desc2 Desc3

Requisitos
Itens vendidos 1a5 6 a 10 mais de 10
Desconto (%) 0 10 20
37
Inferncia
Regra que estabelece algum novo conhecimento baseado na verdade de certas condies. Uma inferncia cria um novo fato de outros fatos ou de clculos. So geralmente escritos no formato se ento. Exemplos:
Se o pagamento no for recebido em 30 dias corridos, o ttulo ser protestado. Produtos com taxa de toxidade maiores que 5 mg/kg so considerados perigosos.
Requisitos
38
C1-Introduo
19
Engenharia de requisitos de software
Verso 1.2
Objetivos
Apresentar o conceito de Engenharia de requisitos Apresentar a disciplina Requisitos do PSP
Requisitos
C2-Engenharia de requisitos
Roteiro
Engenharia de requisitos Processo de Software da PBH / Prodabel (PSP) MPS.BR RUP Desenvolvimento de requisitos Gerncia de requisitos
Requisitos
Engenharia de requisitos
Processo de estabelecer os servios que um cliente requer de um sistema e as restries em que o mesmo desenvolvido e ser operado. Os requisitos so a descrio dos servios de sistema e restries que so gerados durante o processo de engenharia de requisitos. Os processos usados dependem do domnio da aplicao, pessoas envolvidas e organizao.
Requisitos
Atividades da engenharia de requisitos

Desenvolvimento de requisitos
Levantamento (Elicitao) Anlise Especificao Verificao e validao
Gerenciamento de requisitos
Controle de verses Controle de mudanas
Limites entre desenvolvimento e gerenciamento de requisitos
Requisitos
Requisitos e outras disciplinas
Requisitos
Interessados nos requisitos

Indivduo ou organizao que recebe direta ou indiretamente algum benefcio do produto. Incluem os envolvidos no projeto que recebem pagam, selecionan, especificam, usam ou recebem os resultados gerados por um produto de software. Alguns exemplos de interessados so analistas, desenvolvedores, testadores, documentadores, gerentes de projeto, equipe de suporte, equipe jurdica, marketing, etc.
Conflito de interesses
Requisitos
Direitos do usurio
Esperar que o analista fale a sua lngua. Esperar que o analista compreenda o negcio. Esperar que o analista escreva a especificao de requisitos. Receber explicao do analista sobre os produtos gerados. Receber tratamento respeitoso e profissional do analista. Receber alternativas do analista. Descrever caractersticas do produto que facilitaro sua vida. Ter oportunidade de ajustar o produto para prover reuso. Receber estimativas corretas de tempo e custo. Receber informaes sobre o impacto dos pedidos de mudana. Receber um sistema que atenda aos requisitos.
Responsabilidades dos usurios (a revanche)

Explicar a terminologia da rea de negcio. Disponibilizar tempo para prover requisitos, elucid-los e atualiz-los. Ser especfico e preciso ao prover informaes para os requisitos. Tomar decises em tempo hbil sobre requisitos. No pressionar por estimativas de prazo e custo inviveis. Respeitar as estimativas de prazo e custo informadas. Definir com o analista as prioridades dos requisitos. Revisar os documentos de requisitos e avaliar prottipos. Comunicar necessidades de mudanas nos requisitos assim que souber. Seguir o processo definido para solicitar pedidos de mudana. Respeitar o processo de engenharia de requisitos.
Requisitos
11
Analista de requisitos
Analista de requisitos o indivduo que tem como responsabilidade principal coletar, analisar, documentar e validar as necessidades dos envolvidos no projeto. O analista serve como principal condutor atravs do qual os requisitos fluem dos clientes at a equipe de desenvolvimento. Avalie como isto acontece na sua rea funcional: ____________________________________________ ____________________________________________
Canais de comunicao do analista
Requisitos
13
Competncias requeridas de um analista

Habilidades:
Ouvir. Entrevistar e questionar. Analisar. Moderar. Observar. Escrever. Organizar. Modelar. Inter-relacionar. Criar.
Conhecimentos:
Engenharia de requisitos. Processo de software. Gerenciamento de projetos. Qualidade. Domnio da aplicao.
Requisitos
14
Importante
No assuma que um desenvolvedor talentoso ou usurio avanado automaticamente pode se tornar um analista de requisitos efetivo sem treinamento, material de apoio e acompanhamento. As atribuies de um analista demandam habilidades, conhecimentos e atitudes diferentes. Analise se voc tem as habilidades e conhecimentos requeridos de um analista de requisitos:
Habilidades: Conhecimentos:
Requisitos
__ Sim __ Sim
__ No __ No
15
Requisitos no PSP
Os assuntos relacionados a requisitos de software no Processo de Software da PBH/Prodabel esto disponveis no prprio processo. As principais referncias para a estruturao do fluxo so: Disciplina de Requisitos do RUP: O PSP aderente ao RUP e, por consequncia, requisitos orientam todo o processo de desenvolvimento de software. Resultados esperados do MPS.BR: Os REP especficos de Gerncia de Requisitos devem ser atendidos.
Requisitos
16
Requisitos e o RUP
Requisitos
17
Resultados Especficos (REP) de GRE

GRE 1. O entendimento dos requisitos obtido junto aos fornecedores de requisitos; GRE 2. Os requisitos de software so aprovados utilizando critrios objetivos; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida; GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir inconsistncias em relao aos requisitos; GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto.
Fluxo de requisitos do PSP
Requisitos
19
Fluxo de requisitos do PSP

Atividade Obter entendimento:
Elaborar especificao de requisitos Elaborar modelo de caso de uso
Atividade Desenvolver requisitos:

Especificar caso de uso Elaborar especificao suplementar
Atividade Gerenciar requisitos:

Registrar solicitao Analisar impacto
10
Requisitos no PSP
Principais papis :
Analista de requisitos Desenvolvedor
Principais artefatos:
Especificao de requisitos Modelo de casos de uso Caso de uso (detalhado) Especificao suplementar
Requisitos
21
Fontes de requisitos
Requisitos
22
11
Fontes de requisitos
Entrevistas e discusses com usurios potenciais. Documentos dos produtos atuais ou concorrentes. Especificao de requisitos. Relatrios de problemas e pedidos de melhoria. Pesquisas de marketing e questionrios de usurios. Observao do usurio no trabalho. Anlise de cenrios e tarefas de usurios. Eventos e respostas. Outros: _____________________________________
Outros tipos de entradas

Requisitos no relacionados com o produto, como necessidades de treinamento dos usurios. Restries de projeto como prazo e custo. Uma premissa. Informao adicional de um contexto histrico para ajudar a entender o contexto. D um exemplo de cada caso: Treinamento: __________________________________________ Projeto: ______________________________________________ Premissa: ____________________________________________ Informao adicional: ___________________________________
12
Diretrizes para explicitao de requisitos

Escreva sentenas completas com gramtica, ortografia e pontuao corretas. Mantenha pargrafos curtos e diretos. Use a voz ativa. Ex: O sistema deve fazer algo ao invs de Alguma coisa deve ser feita. Quando definir requisitos na forma O usurio deve... identifique o ator (O comprador deve...). Use termos consistentes definidos no glossrio. Evite sinnimos. Decomponha requisitos de alto nvel em requisitos mais detalhados de forma a torn-los claros e para reduzir a ambiguidade. Use listas, figuras, grficos e tabelas, se necessrio. Enfatize os trechos mais importantes de informao. Evite termos ambiguos, tais como: adequado, eficiente, flexvel, melhor, maximizar, normalmente, robusto, vrias, suficiente, amigvel
Especificao de requisitos
a base para a equipe de anlise e desenho, pois descreve funes e desempenho requeridos de um sistema baseado em computao e as regras que guiaro seu desenvolvimento. Limita cada elemento alocado ao sistema e tambm descreve as informaes (dados e controle) que constituem as entradas e sadas do sistema.
Pode ser um documento escrito, um modelo grfico, um modelo matemtico formal, uma coleo de cenrios de uso, um prottipo ou qualquer combinao dos itens citados.
13
Verificao e validao (V&V)

Verificao:
Tem como propsito confirmar que cada servio e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados. Normalmente desempenhada pela equipe tcnica.
Validao:
Tem como propsito confirmar que um produto ou componente do produto atender a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.
Verificao e Validao
Verificao: Estamos construindo certo o produto? - Ponto de vista do desenvolvedor / equipe. Validao: Estamos construindo o produto certo? - Ponto de vista do usurio final / cliente.
Requisitos
28
14
Tcnicas para V&V de requisitos

Reviso - exemplos:
Discusso de um problema tcnico na hora do caf. Apresentao do projeto de software para uma audincia de clientes, administradores e pessoal tcnico. Revises Tcnicas Formais: inclui avaliaes tcnicas de software realizadas em pequenos grupos (walkthrough).
Inspeo: anlise detalhada feita por um grupo com papis e organizao bem definidos. Testes: execuo de um programa com o objetivo de encontrar erros.
Exemplos de critrios de V&V

Os requisitos esto estruturados claramente? No h problemas de interpretao incorreta? A fonte (pessoa, regimento, documento, etc.) foi identificada? A estrutura final do requisito foi examinada pela/contra a fonte original? O requisito est definido em termos quantitativos? Quais so os requisitos relacionados a cada um? Eles esto claramente identificados atravs de uma matriz de referncia cruzada ou outro mecanismo? O requisito viola alguma regra de domnio? O requisito passvel de teste? O requisito rastrevel para os objetivos gerais? Os requisitos associados performance, comportamento e caractersticas operacionais foram estruturados claramente?
15
Exemplos de critrios de V&V

Consistente. H algum conflito de requisitos? Completo. Todas as funes requeridas pelo cliente foram includas e contm informaes para as demais atividades? Real. Os requisitos podem ser implementados com os recursos e tecnologia disponveis? Completo: cada requisito contm toda a informao necessria ao desenho e implementao? Vivel: deve ser possvel implementar cada requisito considerando as capacidades e limitaes existentes. Necessrio: devem ser descritas as capacidades realmente necessrias aos usurios. Priorizado: cada requisito deve ser priorizado. No-ambguo: todos os leitores dos requisitos tm que ter uma nica e consistente interpretao do seu significado.
Priorizao de requisitos
Projetos de software possuem limitaes de recursos que nos obrigam a definir a prioridade relativa dos requisitos. A priorizao ajuda o gerente de projeto a resolver conflitos, planejar iteraes e fazer as compensaes necessrias. Quando as expectativas do cliente so altas e o tempo curto, faz-se necessrio entregar o produto com as funcionalidades mais relevantes, o mais cedo possvel. Perguntas teis: H outra maneira de satisfazer as necessidades que esse requisito trata? Qual ser a consequncia de omitir esse requisito? Qual ser o impacto nos objetivos de negcio se o requisito no for implementado nessa iterao? Por que o usurio ficaria descontente caso esse requisito fosse adiado para a ltima iterao?
16
Priorizao de requisitos
Urgente No urgente
Peso Requisito 2 Benefcio relativo 3 1 2 6 1 2 3 6 1 Perda relativa
Importante Alta prioridade Mdia prioridade

Valor Total 7 4 7 18 Valor % 38,9 22,2 38,9 100 1 Custo relativo 2 3 1 6 -
No importante Baixa prioridade O que fazer?

0,5 Custo % 33,3 50 16,7 100 1 3 2 6 Risco relativo Risco % 16,7 50 33,3 100 Priorida de 0,93 0,30 1,17 -
RQ1 RQ2 RQ3 Total
Prioridade = Valor % / [ (custo % * peso custo) + ( risco % * peso risco) ]

Modelagem visual de requisitos

Nenhuma forma de representao de requisitos prov individualmente um entendimento completo. Normalmente, combinaes de reprentaes textuais e grficas mostram uma viso completa do sistema estudado. Alguns mecanismos visuais so: Prottipos; Tabelas e rvores de deciso; Diagramas DFD, DER, classes, estados, sequncia. Casos de uso.
17
Gerenciamento de requisitos
Os requisitos passam a compor uma baseline aps serem revisados e aprovados pelos envolvidos no processo de desenvolvimento de requisitos. Nesse momento, passam a definir o acordo entre desenvolvedores e clientes. Esse acordo a ponte entre o desenvolvimento e o gerenciamento de requisitos. O gerenciamento de requisitos envolve as seguintes atividades:
Controlar mudanas na baseline de requisitos. Manter planos de projetos de acordo com os requisitos. Controlar verses dos requisitos e documentos associados. Monitorar o status dos requisitos na baseline. Gerenciar as ligaes entre requisitos e outros produtos de trabalho.
Controle de verses de requisitos

Cada verso dos documentos de requisitos deve ser unicamente identificada. Cada membro da equipe deve ser capaz de acessar a verso corrente dos requisitos. Mudanas devem ser documentadas e comunicadas a todos envolvidos. Para minimizar confuso, conflitos e desentendimentos, somente pessoas designadas podem atualizar os requisitos e ter certeza de que o nmero de verso muda sempre que ocorrerem mudanas. Na sua viso como poderia ser feito esse controle? ______________________________________________________ ______________________________________________________
18
Monitoramento de status
Monitorar o status de cada requisito ao longo do desenvolvimento prov uma maneira mais refinada de se medir o progresso do projeto. Classificar os requisitos em status mais simples e til do que atribuir um percentual de concluso. Exemplos de status:
Proposto: requisito solicitado por pessoa autorizada. Aprovado: realizada anlise de impacto, estimativas de projeto e alocao para uma release especfica. Implementado: cdigo desenhado, escrito e testado. Verificado: funcionamento confirmado e requisito integrado. Rejeitado: requisito proposto mas no planejado para implementao em nenhuma release.
Controle de mudanas
Procedimentos que visam garantir:
Mudanas de requisitos propostas so avaliadas cuidadosamente antes de atualizadas. Responsveis tomam decises sobre mudanas solicitadas. Mudanas aprovadas so comunicadas a todos interessados. O projeto incorpora mudanas de uma maneira consistente.
Voc acha que os mecanismos de CM devem ser formais ou informais? Explique! ______________________________________________ ______________________________________________
19
Poltica de controle de mudanas

Todas as mudanas de requisitos devem seguir o processo definido. Se uma solicitao de mudana fugir ao processo, est fora! Para as mudanas no aprovadas nenhum trabalho de desenho e implementao deve ser feito. A nica atividade anlise de viabilidade. Em alguns casos o grupo gestor deve decidir se uma solicitao deve ser implementada. O contedo da base de mudanas deve ser visto por todos envolvidos. Anlise de impacto deve ser feita para toda mudana. O texto original do pedido de mudana no deve ser alterado. Cada mudana em requisitos incorporada deve ser rastrevel at o pedido aprovado. A razo de cada aprovao/reprovao deve ser registrada.
Papis no controle de mudanas

CCB (Change Control Board): grupo que decide aprovar ou rejeitar mudanas propostas para um projeto especfico. Avaliador: apoia o CCB analisando o impacto de um pedido de mudana. Pode ser um tcnico, o cliente, etc. Modificador: responsvel por realizar as mudanas em um produto de trabalho a partir das solicitaes aprovadas. Originador: quem submete um pedido de mudana. Destinatrio (Recebedor): quem recebe as novas solicitaes. Verificador: responsvel por determinar se as mudanas foram feitas corretamente.
20
Anlise de impacto
Geralmente desenvolvida por um tcnico com grande conhecimento. Possui trs aspectos:
Entender as possveis implicaes de se fazer a mudana. Identificar todos arquivos, modelos e documentos que devem ser modificados se a mudana ocorrer. Identificar tarefas necessrias para implementar a mudana e estimar o esforo, tempo e recursos necessrios.
Importante: deixar de analisar impacto no muda o tamanho da tarefa mas deixa o escopo do trabalho como uma surpresa. Voc j viu realizar-se anlise de impacto em algum projeto? ______________________________________________________
Rastreabilidade de requisitos
Rastreabilidade a caracterstica que permite acompanhar a vida de um requisito, desde a origem at a implementao. A rastreabilidade pode ajudar a:
garantir que os requisitos especificados so associados as necessidades dos clientes. garantir que todo produto de trabalho est associado aos requisitos identificados.
A restreabilidade deve ser BIDIRECIONAL, ou seja, permitir que se caminhe nos dois sentidos.
21
Matriz de rastreabilidade
Legenda:
U: o requisito da linha usa o requisito da coluna R: h um relacionamento entre os requisitos
Requisitos e ferramentas CASE
Requisitos
44
22
Requisitos
45
Requisitos
46
23
Requisitos
47
Requisitos
48
24
Referncias Bibliogrficas
WIEGERS, Karl, Software requirements, 2 edition, 2006. SOMMERVILLE, Ian, Engenharia de Software, Addison Wesley, 6 edio, 2003. PRESSMAN, Roger S., Engenharia de Software, McGraw Hill, 5 Edio, 2002.
Requisitos
49
25
Tcnicas de levantamento (elicitao) de requisitos de software

Verso 1.2
Objetivos
Apresentar as principais tcnicas para o levantamento (elicitao) de requisitos.
Tcnicas de elicitao
C3-Tcnicas de elicitao
Roteiro
Observao pessoal. Pesquisa. Questionrio. Entrevista. Reunies. Brainstorming. JAD

Tcnicas de elicitao
Observao pessoal
Consiste em conviver com situaes cotidianas. Possibilita a confirmaes recebidas como: leiaute, problemas de relacionamento, erros de procedimento, segurana do trabalho, etc. Vantagens: no interrupo das atividades, no exigncia de disponibilidade do tempo de envolvidos. Desvantagens: ausncia de evidncias formais, causar mal-estar na rea envolvida, concluses comprometedoras.
Tcnicas de elicitao
Pesquisas
Pesquisa interna: averiguao fsica de uma atividade e processo. Vantagens: percepo do pesquisador, esclarecimento de dvidas. Desvantagens: cria mal estar entre os participantes, demanda muito tempo. Pesquisa externa: utilizada quando no se dispe de qualquer experincia para descrever os requisitos. Utiliza informaes de acervos externos sociedades profissionais, peridicos, livros tcnicos e relatrios de pesquisa.
Tcnicas de elicitao
Questionrio
Instrumento que envolve os processos de preparao em formulrio, distribuio, recolhimento e tabulao. Pode ser precedido de um pr-teste. Vantagens: agilidade, custo, facilidade, abrangncia de pessoas, mensurao uniforme, anonimato, ausncia de presso por resultados imediatos. Desvantagens: manipulao de respostas antes de entregar, tendncia de utilizao de resposta padro, frieza.
Tcnicas de elicitao
Entrevista
Dilogo entre entrevistado e entrevistador. Vantagens: as perguntas podem ser alteradas (contedo, ordem, eliminao, incluso), podem ser esclarecidos pontos das perguntas, podem ser avaliadas as reaes dos entrevistados, pode-se motivar o entrevistado. Desvantagens: alcana menos pessoas, tratamento diferenciado aos entrevistados, desvios de curso, demanda tempo, avaliaes subjetivas, alteraes nas perguntas e contedo, desestimulo, impossibilidade de avaliao prvia, respostas politicamente corretas.
Tcnicas de elicitao Processo de software da PBH/Prodabel 7
Seminrio
Reunio planejada de pessoas-chave de diversas reas com o objetivo de obter informaes gerais sobre a empresa. Tambm chamada de workshops e dinmica de grupo. Vantagens: rapidez na identificao de problemas de relacionamento, estrangulamentos e viso integrada de problemas. Desvantagens: mobilizar um grande nmero de pessoas ao mesmo tempo, interferindo na rotina de trabalho da empresa.
Tcnicas de elicitao
Brainstorming
Tcnica de obteno de informaes em reunies. Etapas: Gerao de idias: No permitir crticas ou debates; Deixar a imaginao voar; Procurar quantidade; Mudar e combinar idias. Seleo de idias: Decidir com base em um limite de votos Decidir com base em discurso de campanha Juntar idias e aplicar critrios; Utilizar sistemas de pontuao.
Tcnicas de elicitao
JAD
Joint Application Design (Projeto de Aplicao Conjunta). Mtodo criado pela IBM no ano de 1977. Consiste em reunies estruturadas intensivas e em grupo, onde participam os representantes do usurio e da informtica. Cada sesso composta por uma ou mais reunies e dura de um a trs dias. Toda reunio conduzida por um facilitador (ou mediador) que visa obter o consenso de forma rpida.
Principais caractersticas do JAD

As reunies substituem as entrevistas individuais. O processo de trabalho altamente estruturado. Os papis so bem definidos. As decises so baseadas em consenso. O facilitador elimina as barreiras de comunicao. Os recursos visuais dinamizam o trabalho.
Tcnicas de elicitao
11
Reunies ao invs de entrevistas

Os usurios se sentem prestigiados e parte integrante do processo, visto que suas opinies so consideradas. As divergncias so resolvidas pelo grupo, pois todas as idias so discutidas por todos. Pode significar grande economia de tempo de desenvolvimento. Entretanto, a carga horria alocada ao projeto tende a ser maior se comparada ao uso de entrevistas individuais, devido a uma participao mais intensa dos usurios.
Processo de trabalho estruturado

Os produtos a serem alcanados so previamente discutidos e so a base de todo o trabalho. Cada sesso tem sua finalidade definida e todos os participantes conhecem os resultados esperados. Os trabalhos de cada sesso so feitos baseados em uma agenda padro adotada em todas as reunies. Somente a abordagem da sesso que varia. Os resultados so insumos para o projeto.
Papis so bem definidos

Executivo patrocinador: autoridade das reas de negcio envolvidas. Redime conflitos, estabelece as diretrizes e objetivos e abre os trabalhos. Gerente de projeto: principal contato do facilitador durante o processo. Equipe: responsvel pelo contedo da sesso. So as pessoaschave das reas envolvidas, em todos os nveis. Facilitador: Guia imparcial, garante participao e consenso. Documentador: registra decises tomadas.
Tcnicas de elicitao
14
Decises baseadas em consenso

Consenso no a unanimidade, mas a concordncia de que a soluo encontrada a melhor para o grupo. Consenso tambm aquela soluo com a qual os participantes iro conviver sem ferir suas prprias convices e valores essenciais. A forma mais produtiva de deciso em grupo aquela baseada em consenso. A conduo ao consenso a principal tarefa do facilitador.
Facilitador elimina barreiras de comunicao

O facilitador uma pessoa neutra do grupo que no avalia nem contribui com idias. Sugere mtodos que ajudem o grupo a concentrar energia em tarefas especficas. Protege todos os membros do grupo contra ataques. Garante a participao de todos de forma homognea. A presena do facilitador torna a reunio mais produtiva.
Recursos visuais dinamizam o trabalho

O andamento das sesses se beneficia do uso de recursos visuais como transparncias, slides, vdeos, flipcharts, micros etc. Todos os resultados das discusses so exibidos atravs de recursos adequados para que todos possam ver. Tais recursos estimulam os sentidos, esclarecem pontos confusos e fazem uso eficaz do tempo.
Tcnicas de elicitao
17
Detalhamento do processo JAD

Tipos de sesses JAD: gerenciais e tcnicas. Ciclo de trabalho de uma sesso: preparao, execuo e reviso. Agenda padro de uma sesso: introduo, reviso de perspectiva gerencial, abertura pelo executivo patrocinador, viso da rea de informtica, regras de conduta, abordagem da sesso, reviso de pendncias, reviso geral, avaliao da sesso. Abordagem da sesso: varia de acordo com o tipo de sesso.
Sesso de gerenciamento
Visa discutir o escopo do projeto, objetivos, metas, recursos e estratgias a serem adotadas. tipicamente a primeira sesso de um projeto, permitindo identificar suas partes componentes e prioridades. Participantes: gerentes de alto nvel e executivos das reas de negcios envolvidas, bem como o representante da rea de informtica Nmero de participantes: mximo 20
Tcnicas de elicitao
19
Sesso tcnica
Define as funes componentes do sistema, a lgica de funcionamento do negcio e de que forma os elementos se relacionam e so tratados. Devem ser orientadas par suprir as informaes necessrias criao dos modelos de dados e processos. Participantes: gerentes e supervisores das reas de negcio. Devem ser capazes de conhecer o negcio, fluxos de trabalho. Nmero de participantes: mximo 10
10
Ciclo de trabalho JAD

Devido ao seu alto grau de planejamento, estruturao e formalizao, o JAD pode ser visualizado como um ciclo de processo que engloba as fases:
Preparao; Sesso (a execuo de uma sesso); Reviso.
Tcnicas de elicitao
21
Ciclo de trabalho - preparao

Examinar adequao do JAD: avaliar em conjunto com o gerente de projeto: os riscos (para o negcio, projeto e tcnica), tamanho do projeto, domnio da metodologia, etc. Planejar: dimensionar n de sesses, durao, alocao de recursos. Elaborar a perspectiva gerencial: finalidade, escopo, objetivos e restries. Familiarizar-se com a rea de negcios: entrevistar participantes previamente. Preparar agenda da sesso: seguir padro. Preparar participantes: informar agenda e pedir exerccio de casa. Preparar ferramenta de documentao.
11
Ciclo de trabalho - sesso

Preparar ambiente: arrumao das mesas, verificao dos equipamentos audiovisuais, checklist dos materiais, preparao de pastas. Conduo da sesso: apresentao dos participantes, explicar agenda, abordar logstica, rever perspectiva gerencial, desenvolver agenda. Documentao: anotar todas as deliberaes da reunio, ler todo o material e gerar documentao. Encerramento: reviso geral da agenda, avaliao da sesso, entrega da documentao produzida.
Ciclo de trabalho - reviso

Rever documentao: verificar se informaes esto corretas, corrigir falhas de comunicao, encaminhar documentao aos participantes. Examinar avaliaes: avaliar se o mtodo est sendo efetivamente til e a satisfao dos participantes. Preparar pasta do projeto: contendo perspectiva gerencial, plano de sesses, agenda de cada sesso, lista de participantes de cada sesso, documentao produzida em cada sesso e questionrios de avaliao.
12
Elaborao da agenda JAD

Identificar a finalidade e objetivos da sesso. Identificar produtos (resultados esperados). Identificar as informaes conhecidas. Esboar as etapas da agenda. Verificar coerncia lgica das etapas. Identificar os participantes provveis. Identificar as etapas que os participantes no tem condies de realizar na sesso. Identificar os dados prvios para as sesses.
Tcnicas de elicitao
25
Agenda padro JAD

Introduo: Data, local, incio e fim previstos Objetivos: Levantamento, acompanhamento, informativa, definio de tarefas, tomada de decises, etc. Moderador, demais participantes e funes Atividades prvias Regras de conduta Abordagem da sesso: Desenvolvimento dos itens especficos da pauta Reviso Pendncias Concluses
13
Agenda padro JAD - Introduo

Reviso do JAD, papis, horrios, apresentao dos participantes e da agenda. Reviso da perspectiva gerencial: comentrios sobre a definio da alta gerncia. Abertura pelo executivo patrocinador: mostra o apoio da cpula, importncia, objetivos e motivo de escolha da equipe. Viso da rea de Informtica: questes tecnolgicas e de andamento de projeto. Regras de conduta: comportamentos indicados para sesso.
Agenda padro JAD Abordagem da sesso

Passos especficos para se alcanar os objetivos da sesso.
Finalidade Produto esperado Processo envolvido Sequncia
Tcnicas de elicitao
28
14
Agenda padro JAD Reviso

Reviso das pendncias: situao do item, responsvel e data prevista para a soluo. Reviso geral: rpida passagem pelo material produzido para verificar se o resultado est coerente e coeso, de acordo com o previsto. Avaliao da sesso: obteno do feedback dos participantes sobre o mtodo utilizado e desempenho do facilitador.
Consideraes sobre o JAD

Enquanto tcnica, o JAD prope captar os pontos principais das demais tcnicas visando tornar mais produtivas as reunies. A estrutura do JAD pressupe um trabalho considervel de documentao e atividades preliminares e posteriores. bvia a importncia e uso de reunies como mecanismos de interao entre pessoas em qualquer aspecto da sociedade. Para qualquer situao de reunio profissional pode ser seguido o modelo do JAD.
15
Exemplo de agenda JAD - Introduo

Explicao: sero explicados aspectos preliminares sobre a sesso (Durao: 10 Min.). Aspectos:
Perodo: 1, 2 e 3/4 de 2009; Horrio: 8h s 17h. Intervalo: 10h s 10h15, 15h30 s 15h45. Almoo: 12h s 13h. Recursos disponveis: Projetor, computador, quadro magntico e flipchart. Apresentao dos participantes: Nicolau dos Santos (Executivo patrocinador), Philip Kotler (Gerente de Marketing), Bill Gates (Gerente de Informtica), Domenico de Masi (Gerente de RH), Jos Silva (Facilitador) e Sra. Maria Santos (Documentadora).
Exemplo de agenda JAD Introduo

Funcionamento do JAD: O Sr. Jos Silva far uma explicao do JAD e suas principais caractersticas como trabalho em equipe, deciso por consenso, papel do facilitador, agenda, etc. Apresentao dos assuntos da agenda: Sero lidos os itens da Abordagem da Sesso. Reviso da perspectiva gerencial: Os participantes expressaro suas opinies e sugestes. Durao 50 Min.
Tcnicas de elicitao
32
16

Abertura pelo executivo patrocinador: O Sr. Nicolau dos Santos mostrar a importncia do projeto no contexto do negcio, o que a administrao pretende alcanar e por que aquela equipe foi escolhida. Durao: 15 Min. Viso da rea de informtica: O Sr. Bill Gates falar das atuais tecnologias e tendncias no escopo do projeto. Durao: 20 Min.

Regras de conduta: Sero explicadas as normas de comportamento a serem seguidas durante a sesso. So vedadas conversas em paralelo, utilizao de telefone celular, interromper a fala de outro participante, fumar durante a sesso, crticas destrutivas ou pessoais a opinio de outros participantes. Durao 5 Min. Abordagem da sesso: Nesta etapa sero discutidos os assuntos especficos da sesso. Os assuntos sero divididos em seis etapas. Durao: 3:00 H.
Tcnicas de elicitao
34
17
Exemplo de agenda - Abordagem da sesso

Tema 1: Descrio do ambiente atual
Incio: 8h. Durao: 1h. Finalidade: Descrever a situao atual e as reas de negcios. Produto esperado: descrio da situao atual, incluindo: processos atuais (possibilidades, pontos fortes e fracos, restries), situao competitiva e oportunidades para a organizao. Processo envolvido: participantes devero preencher previamente um questionrio que ser apresentado durante a sesso. Sequncia: Discusso dos pontos apresentados, brainstorming, seguido de votao.

Tema 2: Descrio dos problemas das reas.
Incio: 10 H 15. Durao: 1 H 30. Finalidade: Apontar os principais erros existentes na situao atual. Sero usados para definir e justificar objetivos e solues a serem adotadas. Produto esperado: descrio dos problemas atuais do negcio. Processo envolvido: Idem tema 1. Sequncia: Brainstorming, seguido de votao.
Tcnicas de elicitao
36
18

Tema 3: Descrio dos objetivos para a nova situao.
Incio: 13 H. Durao: 1 H. Finalidade: Listar os objetivos a serem alcanados atravs de modificaes nas reas de negcios. Os objetivos devem estar associados a problemas encontrados na etapa anterior. Produto esperado: descrio de todos os objetivos. Processo envolvido: Idem ao tema 1. Sequncia: Idem ao tema 2.
Tcnicas de elicitao
37

Tema 4: Descrio dos requisitos.
Incio: 14h. Durao: 1 H 30. Finalidade: Definio das solues (requisitos) para a nova situao esperada. Define como sero alcanados os objetivos. Produto esperado: descrio dos requisitos. Processo envolvido: Idem ao tema 1. Sequncia: Idem ao tema 1.
Tcnicas de elicitao
38
19

Tema 5: Descrio das restries para os requisitos.
Incio: 15 H 45. Durao: 30 Min. Finalidade: Definio de restries de ordem fsica, poltica, legal, que possam afetar os requisitos estabelecidos. As restries determinam limites, fronteiras e balizamentos para o sistema. Produto esperado: descrio das restries. Processo envolvido: Idem ao tema 1. Sequncia: Idem ao tema 1.
Tcnicas de elicitao
39

Tema 6: Prioridade dos requisitos.
Incio: 16 H 15. Durao: 30 Min. Finalidade: Dar prioridade aos requisitos. Produto esperado: Indicao da prioridade de cada requisito. Processo envolvido: atravs do estabelecimento dos critrios de prioridade como custo, competitividade, facilidade de implementao e posterior associao a cada requisito. Sequncia: Descrio de cada item e votao.
20
Exemplo de agenda JAD - Reviso

Reviso de pendncias: Sero resolvidas as pendncias e agendadas novas. Consiste em: Descrio da pendncia, situao, responsvel, data para soluo. Durao 5 Min. Reviso geral: Ser feita uma passagem pelo material produzido na sesso, avaliando os resultados obtidos. Durao 5 Min. Avaliao da sesso: Ser obtido o feedback de todos os participantes sobre o mtodo utilizado e sobre o comportamento do facilitador, visando adequar e melhorar o processo para as prximas sesses. Durao 5 Min.
Tcnicas de elicitao
41
Referncias bibliogrficas
Costa, Wilson Dias Da - JAD Joint Application Design, Ibpi Press, 1994. Gause, D. e Weinberg, G. Explorando Requerimentos de Sistemas, Makron Books, 1989.
Tcnicas de elicitao
42
21
Casos de uso
Verso 1.2
Objetivos
Descrever as dificuldades encontradas para se modelar sistemas com base somente em requisitos. Mostrar como os casos de uso se encaixam na modelagem de comportamento dos sistemas. Especificar as diretrizes para a escrita de casos de uso efetivos.
Requisitos
C4-Casos de uso
Roteiro
Requisitos e casos de uso Definio de caso de uso Definio de ator Relacionamentos Diagrama de caso de uso Estrutura de um caso de uso Descrio de um caso de uso Processo de modelagem de casos de uso Diretrizes para elaborao de casos de uso
Interessados nos requisitos

Clientes: Precisam saber se o sistema est sendo desenvolvido conforme desejam. Gerentes: Precisam ter um entendimento geral do que o sistema ir fazer de forma a planejar e controlar o projeto. Analistas: Precisam descrever e documentar o que o sistema ir fazer. Desenvolvedores: Precisam entender o que o sistema deve fazer para implementa-lo. Testadores: Precisam saber o que o sistema deveria fazer para poder verifica-lo.
C4-Casos de uso
Natureza dos requisitos

Domnio do problema Necessidades Requisitos de usurio Domnio da soluo
Requisitos de sistemas
Requisitos de desenho
Produto a ser construdo
Requisitos
Separao entre domnios

A separao em domnios indica que os requisitos de software tratam da soluo e no do problema. O formato da pirmide reflete o volume relativo do problema: poucas necessidades podem exigir vrios requisitos. O relacionamento de rastreabilidade deve ser mantido entre todos os nveis.
Requisitos
C4-Casos de uso
Rastreabilidade dos requisitos
N1
Nx
Ru2 Ruy
Ru1
Rs1
Rs2
Rs3
Rsz
Rd1
Rd2
Rd3
Rd4
Rdn
P: Essa figura representa rastreabilidade uni ou bidirecional? ___________________

Limitaes dos requisitos

Dados os requisitos de um caixa eletrnico:
O sistema deve permitir clientes fazer saques de suas contas. O sistema deve assegurar que o limite da conta nunca ser ultrapassado. Se um cliente tentar sacar de um caixa que no pertena a instituio em que tem conta, o sistema deve cobrar uma taxa.
Surgem as questes:
Em qual ordem essas coisas devem ser feitas (caso a ordem importe)? A taxa deve ser cobrada antes ou depois do saque?
Requisitos
C4-Casos de uso
Limitaes dos requisitos

Para um dado conjunto de requisitos, pode ser praticamente impossvel entender o que os autores dos requisitos querem que seja feito. Os requisitos normalmente so ambguos e incompletos pois no informam quando e sob quais condies os comportamentos ocorrem. A seqncia um requisito em certos casos. Os requisitos tradicionais capturam abordagens, com nfase em requisitos declarativos e sentenas do tipo deve, falhando em capturar o comportamento dinmico do sistema. Outra: ___________________________________
Modelagem de casos de uso

Um caso de uso uma forma de expressar os requisitos do sistema, especialmente seu comportamento. A idia bsica por trs da modelagem de um caso de uso a seguinte:
Capturar a essncia do que um sistema deve fazer. Para tal, deve-se inicialmente observar quem ir usar o sistema. Depois disso, deve-se pensar no que o sistema dever fazer para realizar o que o usurio necessita.
C4-Casos de uso
Casos de uso no contexto dos requisitos

Necessidades
Requisitos funcionais Casos de uso
Especificao suplementar
Especificao suplementar
P: Casos de uso so uma especificao completa de todos os requisitos? ___________

Casos de uso e requisitos

Um caso de uso contm a especificao de um conjunto de requisitos, apresentados de forma narrativa ao invs de estrutura de tpicos ou outra (lembra dos fluxogramas?). Um caso de uso coloca os requisitos no contexto da descrio de algo que o usurio deseja. A granularidade dos requisitos e dos casos de uso bastante diferente. Explique: ___________________ Casos de uso expressam comportamento: Quando bem escritos, os casos de uso especificam exatamente o que o sistema deve fazer.
C4-Casos de uso
Casos de uso e requisitos

Casos de uso so uma boa tcnica para modelagem de requisitos. Eles provm uma maneira padronizada de capturar, explorar e documentar o que um sistema deve fazer. Um caso de uso pode atender a vrios requisitos e um mesmo requisito pode ser atendido por um ou vrios casos de uso. D um exemplo: ________________________________________ Um requisito no um caso de uso e vice versa.
Casos de uso e a natureza dos requisitos

Casos de uso capturam facilmente (sob o ponto de vista do usurio) conjuntos de requisitos funcionais, descrevendo o comportamento do sistema como uma interao entre usurios ou outros sistemas e o sistema em questo, para fazer algo til, conforme seus interesses. Casos de uso no envolvem: interfaces externas, formatos de dados, regras de negcio e frmulas, algumas vezes complexas. Requisitos no funcionais so melhor descritos usando textos declarativos ou meios visuais. Descrever requisitos no funcionais por meio de casos de uso uma maneira de confundir ambos. Exemplo: _______________________________________________________
C4-Casos de uso
Modelo de casos de uso

Um modelo de caso de uso um modelo de um sistema definido em termos de casos de uso, atores e o relacionamento entre eles [OMG]. Um modelo de caso de uso pode conter um conjunto de diagramas de caso de uso, agrupados por similaridade. Modelos de caso de uso provm uma boa viso geral sobre o sistema. Entretanto, a grande fora dos casos de uso est em sua descrio textual, que ser vista mais frente.
Representao de casos de uso

Um caso de uso descreve como um ator usa um sistema para atingir um objetivo e o que o sistema faz para o ator atingir seus objetivos. Descreve uma estria de como um sistema e seus atores colaboram para um dados objetivo. A UML representa casos de uso como elipses:
Requisitos
16
C4-Casos de uso
Atores
Conjunto coerente de papis que os usurios exercem quando interagem com os casos de uso. [OMG] Aspectos chave dos atores:

Representam pessoas ou outros sistemas. Definem os papis que os usurios ou outros sistemas exercem. Esto fora do sistema, e geralmente fora do controle do mesmo. Impem requisitos que o sistema deve atender.
Requisitos
Representao de atores
Um ator define um papel que um usurio pode exercer quando interage com o sistema. Um usurio ainda pode um indivduo ou outro sistema.
A UML representa atores como bonecos:
Requisitos
18
C4-Casos de uso
Stakeholders e atores
Stakeholder algum ou algo que tem um interesse legal no comportamento do caso de uso. Obs: conceito anlogo GP. Um ator qualquer coisa que tem um comportamento. Um ator pode ser uma pessoa, companhia ou organizao, um programa de computador ou um sistema computacional Todo ator primrio, naturalmente, um stakeholder, mas alguns stakeholders nunca interagem diretamente com o sistema.
Ator primrio
o stakeholder que chama o sistema para entregar um de seus servios. Ele tem um objetivo com respeito ao sistema - que pode ser satisfeito por sua operao. Geralmente o caso de uso comea porque o ator primrio envia uma mensagem, pressiona um boto, pressiona uma tecla ou de alguma outra forma inicia a estria. Entretanto, h pelo menos duas situaes em que um UC no iniciado por um ator primrio:
Quando, por exemplo, um operador de telefone inicia o caso de uso em nome de um cliente. Quando o caso de uso acionado pelo ator tempo.
Requisitos
C4-Casos de uso
10
Atores secundrios
Atores externos que provm um servio ao sistema. Devem ser identificados a fim de achar as interfaces externas que o sistema usar e os protocolos que cruzam essas interfaces. Um ator pode ser primrio em um caso de uso e secundrio em outro. Exemplo: _________________________________________
Requisitos
21
Comunicao entre ator e caso de uso

Razes para o ator acionar o caso de uso:

Solicitar dados armazenados no sistema. Mudar dados armazenados no sistema. Informar que algo importante aconteceu em torno do sistema.
Razes para o caso de uso acionar o ator:
Informar ao ator se algo importante aconteceu com o sistema. Pedir apoio para tomada de alguma deciso. Delegar responsabilidades a atores.
Requisitos
C4-Casos de uso
11
Relacionamentos
Casos de uso e atores no existem sozinhos. A UML define diversos de relacionamentos no modelo de casos de uso:

Comunicao: Interao direta entre ator e caso de uso. a situao mais comum. Incluso: Prov a habilidade de extrair sees comuns entre dois ou mais casos de uso e coloca-las em um caso de uso separado, favorecendo o reuso. Extenso: Usado em casos onde um comportamento opcional ou excepcional inserido em um caso de uso existente. Generalizao: Usado quando elementos possuem comportamentos em comum. Ex: atores.
Requisitos
Diagramas do modelo de caso de uso
Diagrama com uma viso geral com principais atores e casos de uso. Tambm chamado, por alguns autores, Diagrama de Contexto. Diagrama somente com atores correlatos. Diagrama da perspectiva de um nico ator, mostrando casos de uso e demais atores a ele associados. Diagramas somente com casos de uso correlatos. Diagramas da perspectiva de um nico caso de uso, mostrando atores e demais casos de uso a ele associados.
Requisitos
C4-Casos de uso
12
Exemplo de diagrama de caso de uso
Detalhar pagamento
Fazer pagamento com dinheiro
Fazer pagamento com cheque
Requisitos
25
Descrio de Casos de Uso

Descrio de um conjunto de seqncias de aes, incluindo variaes, que um sistema executa para atingir um resultado de valor observvel para um ator em particular. [OMG] Aspectos chave de caso de uso:

iniciado por um ator. provido pelo sistema (responde ao ator). Pode envolver mais de um ator. Descreve como o sistema e seus atores colaboram para atender o objetivo do ator. Prov uma imagem coerente de como o sistema ser usado.
Requisitos
C4-Casos de uso
13
Descrio de um caso de uso

A UML define que os casos de uso possuem dois elementos de modelagem: uma representao grfica e uma descrio textual. Entretanto, no definido um padro para a descrio textual de um caso de uso. Portanto, a descrio de um caso de uso pode variar desde um texto livre com alguns pargrafos at uma estrutura de dados com campos bem delimitados. H vantagens e desvantagens em ambas abordagens. Ex:

Vantagem: __________________________________________ Desvantagem: _______________________________________

Requisitos
Estrutura geral de um caso de uso

Identificao
Nome
Descrio

Pr-condies Ps-condies Fluxo de eventos

Fluxo principal (mais comum) Fluxos alternativos Fluxos de exceo Sub-fluxos (deve-se evitar)
Requisitos
28
C4-Casos de uso
14
Estrutura de um caso de uso

Nome: Deve ser nico e identificar o que atingido atravs da interao entre o caso de uso e o ator. Descrio:
Pr-condies: Descrio textual que define restries quando o caso de uso deve iniciar. Ps-condies: Descrio textual que define restries quando o caso de uso termina. Fluxo de eventos: Descrio textual do que o sistema faz em relao ao caso de uso. estruturado em:
Fluxo principal: Fluxo principal ou padro. Fluxos alternativos: Fluxos com cenrios alternativos ao principal. Sub-fluxos: Subdiviso de um fluxo para fins de clareza. EVITAR!
Requisitos
29
Descrio de um caso de uso

A descrio de um caso de uso narra uma estria de como o sistema e seus atores colaboram para atingir um objetivo especfico. uma descrio passo a passo de uma forma particular de usar o sistema. A estrutura de um caso de uso narrativa por natureza. Todo caso de uso deve ter:

Incio (como o ator inicia o caso); Meio (como sistema e atores interagem); Fim (como o caso de uso encerrado).
Requisitos
C4-Casos de uso
15
Importncia da descrio textual

Cerca de 90% do modelo de caso de uso reside nas descries. Portanto, a parte mais trabalhosa de se modelar. A parte mais importante de um caso de uso a descrio. A parte mais importante da descrio o fluxo de eventos. O fluxo de eventos tem uma estrutura bem definida, baseada nos conceitos dos fluxos principal, alternativos e de exceo.
Cenrios (fluxos) e passos

Um conjunto de casos de uso uma estria j desdobrada de atores primrios perseguindo objetivos. Cada caso de uso tem um enredo cruzado e mostra o sistema alcanando o objetivo ou o abandonando. um descrio teatral. Esse enredo est presente na forma de um cenrio bsico e um conjunto de fragmentos de cenrios, como extenses dele. Cada cenrio ou fragmento comea com uma condio de acionamento que indica quando ele executado e vai at mostrar a concluso ou o abandono de seu objetivo.
C4-Casos de uso
16
Estrutura tpica de fluxo de eventos

Fluxo principal Fluxo alternativo Fluxo alternativo
Requisitos
33
Fluxo principal
Descrio, de cima para baixo, de um cenrio bastante caracterstico no qual o objetivo do ator primrio alcanado e todos interesses dos stakeholders so satisfeitos. O fluxo principal descreve a forma mais usual (padro) de se atingir os objetivos do ator principal. Todas as outras maneiras de ter sucesso e o tratamento de todas as falhas, so descritos nas extenses do fluxo principal nos fluxos alternativos e de exceo.
C4-Casos de uso
17
Organizao de cenrios
Fluxos alternativos estendem o fluxo principal para tratar as variaes e excees. Sub-fluxos podem ser usados para facilitar a leitura de um fluxo complexo. Pode ser substitudo por outro caso de uso. Pr e ps condies podem ser usadas para melhor esclarecer o escopo de um caso de uso e documentar qualquer premissa feita a respeito do estado do sistema (antes ou depois do UC). Prcondies so mais comuns que ps-condies. A descrio deve ser longa o suficiente para poder descrever a estria e simples o suficiente para no dificultar os trabalhos nem tornar o modelo complexo. Deve-se utilizar linguagem clara e objetiva.
Estrutura comum aos fluxos

Uma condio sob a qual o cenrio executado: para o cenrio principal a pr condio mais o acionador. Para um cenrio de extenso, a condio de extenso. Um objetivo a alcanar: para o principal, o nome do caso de uso. Para um cenrio de extenso, o objetivo completar o caso de uso ou ingressar no cenrio de sucesso. Um conjunto de passos de ao: formam o corpo do cenrio e seguem as mesmas regras em todo cenrio ou fragmento de cenrio. Uma condio de fim: objetivo atingido ou abandonado. Um possvel conjunto de extenses escritas como fragmentos de cenrio.
C4-Casos de uso
18
Condies de extenso
So as condies sob as quais o sistema tem um comportamento diferente (fluxos alternativos e/ou exceo). Exemplo: ... 4. Usurio solicita salvamento do arquivo ... Extenses: 4a. Sistema detecta a necessidade de salvamento 4a1. ... (passos) 4b. Salvamento falha 4b1. ... (passos)
Condies de extenso - exceo

A condio deve dizer o problema detectado. Exemplos:

Senha invlida. Rede inoperante. Cliente no responde. Dinheiro indisponvel.
Obs: no levantar cdigos de erro internos.
Racionalize e rena as falhas similares, de modo a simplificar a anlise. Avalie as condies de falhas dentro de falhas.
C4-Casos de uso
19
Exemplo de descrio de caso de uso

Nome: Registrar sinistro. Ator primrio: Atendente. Pr-condio: Segurado e aplice habilitados. Fluxo principal:
1. Atendente informa nmero da aplice do segurado. 2. Sistema retorna informaes da aplice. 3. Atendente confirma dados do segurado. 4. Sistema confirma que no h nenhum sinistro em aberto para o segurado. 5. Atendente informa detalhes do sinistro: tipo, local, data, hora, descrio. 6. Sistema valida os dados informados e gera nmero (sequencial no ano) da comunicao. 7. Atendente informa nmero da comunicao ao segurado 8. Atendente designa um agente para o atendimento. 9. Sistema solicita confirmao para fechamento da comunicao. 10. Atendente confirma operao. 10. Sistema salva os dados e envia e_mail para o agente designado.
Exemplo de descrio de caso de uso (cont.)

Fluxos alternativos: FA1. Atendente informa que ligao somente para consulta.
1. Sistema registra informao.
FA2. Atendente pode salvar os dados incompletos a qualquer momento, antes da concluso do UC.
1. Registrar comunicao com status Pendente.
FA3. Atendente altera informaes da aplice ou data do sinistro.

1. Sistema valida informaes e verifica se aplice est disponvel.
1. Atendente informa cdigo da aplice ou CPF/CGC ou nome do segurado. 2. Sistema edita aplice a partir dos dados da pesquisa. (E se no encontrar? _______________________________________________) 3. Atendente altera data ou outros dados do sinistro.
C4-Casos de uso
20
Exemplo de descrio de caso de uso

Fluxos de exceo: FE1. Informao de aplice encontrada no corresponde ao segurado: 1. Atendente informa nmero correto de aplice. FE2. Sistema no encontra aplice, a partir de detalhes: 1. Atendente informa detalhes corretos. FE3. Sistema identifica comunicao duplicada: 1. Sistema exibe lista de comunicaes existentes. 2. Atendente seleciona uma comunicao.
2a. Atendente edita comunicao.
FE4. Atendente termina sem completar informaes obrigatrias. 1. Sistema informa que transao no pode ser concluda.
Processo de modelagem de casos de uso
Requisitos
42
C4-Casos de uso
21
Estgios de escrita dos casos de uso

Estgio de escrita Propsito principal Descoberta Identificar caso de uso Breve descrio Esboo inicial Riscos atacados Desconhecer limites do sistema Resumir propsito do caso Ambiguidade na de uso definio do modelo Resumir formato e extenso -Desconhecer do caso de uso extenso, escala ou complexidade do sistema -Desconhecer casos de uso requeridos Resumir essncia do caso Facilidade de uso de uso Atividades associadas Gerenciamento de escopo Gerenciamento de escopo -Gerenciamento de escopo -Estimativa inicial -Prototipagem visando atender requisitos e atacar riscos tecnolgicos
-Desenho de interface com usurio -Prototipagem visando atender requisitos e atacar riscos tecnolgicos Descrio Permitir adicionar detalhes Nenhum (passo Nenhum (passo detalhada de forma incremental intermedirio) intermedirio) Descrio completa Prover completa -No saber exatamente -Anlise e desenho especificao funcional para o que o sistema deve -Implementao o comportamento fazer -Testes de integrao encapsulado pelo caso de -No ter uma -Testes de sistema uso especificao de -Documentao de usurio requisitos -Estimativa refinada compartilhada
Esboo essencial
Caso de uso e as disciplinas do RUP

Requisitos: O modelo de caso de uso construdo nessa disciplina. Anlise e desenho: Casos de uso so realizados pelos modelos de anlise e desenho. Aqui descrito como os objetos se relacionam para atingir o objetivo do caso de uso. Implementao: O cdigo desenvolvido para executar os casos de uso. Testes: Os casos de uso servem de base para identificar os casos de teste e procedimentos especficos.
C4-Casos de uso
22
Relacionamento entre o modelo de casos de uso e outros modelos
Expresso por
Verificado por
Implementado por Realizado por
Requisitos
45
Ciclo de escrita de caso de uso

Especifique o escopo e os limites do sistema. Identifique os atores primrios. Identifique os objetivos dos usurios para com o sistema. Selecione um caso de uso para expandir:

Capture os stakeholders e interesses; Escreva o fluxo principal; Identifique os fluxos alternativos e de exceo; Escreva os passos de tratamento de extenso; Extraia os fluxos complexos para subcasos de uso.
Reajuste o conjunto: adicione, subtraia e junte casos de uso conforme necessrio, iterativamente.
C4-Casos de uso
23
BITTNER, Kurt e SPENCE, Ian, Use Case Modeling, Addison-Wesley, 2003. COCKBURN, Alistair, Escrevendo casos de uso eficazes, Bookman, 2005. OMG, Object Management Group, UML www.omg.org, 2004.
Requisitos
47
C4-Casos de uso
24
Modelagem de casos de uso
Verso 1.2
Objetivos
Descrever as dificuldades encontradas para se modelar sistemas com base somente em requisitos. Mostrar como os casos de uso se encaixam na modelagem de comportamento dos sistemas. Especificar as diretrizes para a escrita de casos de uso efetivos.
Requisitos
C5-Modelagem casos de uso
Roteiro
Estrutura de um caso de uso Descrio de um caso de uso Processo de modelagem de casos de uso Diretrizes para elaborao de casos de uso
Requisitos
Identificao de atores
Inicie identificando os atores principais (usurios). Trabalhe do especfico para o geral. No esquea os atores de apoio. Considere todas as informaes sobre requisitos. Lembre-se que atores nem sempre so pessoas. Observe os limites (escopo) do sistema. Identifique as fontes de informao.
Requisitos
Identificao de atores
No confunda atores com os dispositivos de E/S. Ex: terminal de auto atendimento. No confunda atores com papis da organizao ou ttulos de emprego. Ex: gerente, superintendente. No generalize em excesso. Ex: ________________ Caracterize os atores e crie uma descrio breve de cada ator. Faa isto na lista de atores. Associe os atores aos tipos de usurios, stakeholders e papis destes. Ex: ___________________________
Questes para identificar atores

Quem ir utilizar o sistema? Quem ir fornecer, receber ou remover informao? Quem est interessado em determinado requisito? Quais outros sistemas devem interagir com este? Quais so os recursos externos ao sistema? Quem inicia o sistema (interao)? Quem ir manter o sistema? Existe algum ator disparado por evento ou tempo?
Lista de atores
Nome e breve descrio. Escopo (responsabilidades). Ambiente fsico de uso do sistema. Quantidade e tipo de usurios representados pelo ator (para dimensionamento da rede). Freqncia de uso (para dimensionamento da rede). Nveis de conhecimento sobre negcio e tecnologia. Faixa etria. Etc: _______________________________________
Localizao dos casos de uso

Inicie identificando as metas dos atores. Considere as necessidades de informao do usurio e sistema. No confunda caso de uso com funo. Uma funo pode corresponder a vrios casos de uso e vice-versa. No se esquea dos casos de uso de apoio e operacionais. Ex: ________________________
Questes para identificar casos de uso

Para cada ator quais so as necessidades (objetivos) que o sistema deve atender? O ator dever informar ao sistema que tipo de mudanas de estado / situaes? Quais casos de uso iro iniciar, parar, configurar, apoiar e manter o sistema? Sobre quais eventos o sistema deve ser informado? Sobre quais ocorrncias o sistema deve registrar e informar aos atores? O modelo de casos de uso representa os interesses de todos os stakeholders?
Diretrizes para elaborar fluxos de UC

Descrever como o fluxo inicia e termina. Descrever quais dados so trocados entre ator e caso de uso. prefervel descrever grupos de dados a itens elementares. No descrever detalhes de interface com o usurio a menos que seja necessrio para entender o comportamento do sistema. Ex: no descrever que tipo de boto ser utilizado. Descrever o fluxo de eventos, no somente a funcionalidade. Iniciar o fluxo com o ator (mais comum) ou o sistema. Descrever somente os eventos que pertenam ao caso de uso em questo.
Diretrizes para elaborar fluxos

Descrever o que o sistema faz e no como projetado. Detalhar o fluxo de eventos, respondendo a todas as perguntas, principalmente para os testes (que tero por base o UC). Utilizar vocabulrio simples, na medida do possvel. Escrever sentenas curtas e frases diretas. Evitar advrbios como muito, mais, ao invs, etc. Evitar terminologia vaga como informao, relevante, suficiente, etc. Utilizar pontuao correta. Deixar clara a seqncia de eventos. Destacar termos que se encontram no glossrio (jargo tcnico).
Diretrizes para escrever passos

Utilizar estrutura gramatical simples: Sujeito + verbo + objeto direto + preposio. Sistema deduz a quantia do saldo da conta Mostrar claramente quem comanda a ao: Pessoa1 Pessoa2 ou Pessoa1 Sistema Escrever com uma viso geral:
Errado: Pegar carto e senha. Deduzir quantia do saldo. Certo: Cliente insere carto e senha. Sistema deduz quantia do saldo da conta.
Requisitos

Descrever o objetivo do passo, evitando passos muito curtos Errado: Usurio pressiona a tecla Tab (Com qual objetivo?...) Certo: Usurio informa nome e endereo Mostrar a interao entre atores, no os movimentos: Errado: Sistema pergunta nome. Usurio informa nome. Sistema pergunta endereo. Excesso de detalhes! Usurio informa endereo. Usurio pressiona OK. Sistema apresenta perfil do usurio. Certo: Usurio informa nome e endereo. Sistema apresenta perfil do usurio.

Pensar em um passo como representando uma transao. Siga a estrutura:

Ator primrio envia solicitao e dados ao sistema. Sistema valida solicitao e dados. Sistema altera seu estado interno. Sistema fornece resultado.
Preferir Valida ao invs de Verifica, em aes de validao:
Errado: Sistema verifica se senha est correta. Se est, sistema apresenta aes disponveis. Certo: Sistema valida senha. Sistema apresenta aes disponveis.
Requisitos
14
Diretrizes para escrever casos de uso

Priorizar comunicao efetiva entre todos interessados. Perseguir a simplicidade ao escrever casos de uso. Lembrar-se que a audincia dos casos de uso so os usurios, que devem ser capaz de entend-los. O bom inimigo do timo. No existe perfeio na escrita de casos de uso.
Requisitos
15
Diretrizes para escrever casos de uso

Associar sempre os casos de uso aos seus atores. Nomear os casos de uso usando voz ativa. Dar a cada caso de uso uma breve descrio. Delimitar bem os casos de uso (escopo), dentro do devido domnio (nvel de detalhe). Associar casos de uso aos interessados e aos papis dos interessados. Associar os casos de uso aos requisitos e restries.
Alguns erros comuns

Cenrio sem sistema
1. Cliente passa carto e informa senha. 2. Cliente seleciona Saque e informa valor. 3. Cliente apanha dinheiro. 4. Cliente desconecta.
Cenrio sem ator primrio

1. Coleta carto e senha. 2. Coleta transao do tipo Saque. 3. Seleciona quantia desejada. 4. Valida saldo da conta. 5. Entrega o dinheiro. 6. Encerra.
Alguns erros comuns

Excesso de detalhes de interface:
1. Sistema apresenta tela de ID e senha. 2. Cliente digita ID e senha no sistema, clica em OK. 3. Sistema valida ID e senha e mostra tela Detalhes. 4. Cliente digita nome e endereo e clica em OK.
Nvel de objetivos muito baixo:

1. Usurio acessa sistema com ID e senha. 2. Sistema valida usurio. 3. Usurio fornece nome. 4. Usurio fornece endereo. 5. Usurio seleciona produto. 6. Sistema abre conexo com sistema de depsito. 7. Sistema de depsito retorna estoque atual.
Questes frequentes
Nmero excessivo de casos de uso. Soluo: _________________________________________________________ Casos de uso CRUD. Soluo: _________________________________________________________ Casos de uso excessivamente complexos. Soluo: _________________________________________________________ Casos de uso que usurios no entendem. Soluo: _________________________________________________________ Novos processos de negcio. Soluo: _________________________________________________________ Uso excessivo de relacionamentos include e extend. Soluo: _________________________________________________________
Nmero excessivo de casos de uso

Torna-se difcil o preenchimento de cada caso de em um nvel adequado de abstrao quando se tem um nmero excessivo de casos de uso. Evite criar um caso de uso para cada cenrio possvel. Ao invs disso, inclua os fluxos normal, alternativos e excees em um nico caso de uso. Tipicamente, h muito mais casos de uso do que requisitos de negcio e mais requisitos funcionais do que casos de uso.
Requisitos
20
10
Casos de uso CRUD

Por princpio, organize pequenos casos de uso do tipo Criar <item>, Recuperar <item>, Alterar <item>, Excluir <item> em um nico caso de uso Gerenciar <item>. Isso reduz consideravelmente o nmero de casos de uso e o trabalho. Separe o caso de uso Gerenciar <item> somente se a complexidade assim exigir. Outra diretriz avaliar o nvel de acesso a uma funcionalidade. Assim, o caso de uso Gerenciar <item> pode ser dividido conforme o nvel de acesso ou a informao relativa pode ficar em outro local, associado ao caso de uso. Esta situao ocorre com frequncia com relao consulta.
Requisitos
21
Casos de uso excessivamente complexos

Escreva os casos de uso em funo da essncia dos comportamentos dos atores e do sistema, ao invs de especificar cada ao em detalhes. Selecione um caminho de sucesso e derive dele vrios caminhos simples como alternativos e exceo. Tipicamente os fluxos alternativos e de exceo so mais curtos e simples do que o fluxo principal. Deixe as definies de dados para o dicionrio de dados e no para os casos de uso.
11
Casos de uso que os usurios no entendem

Se os usurios no conseguem relatar a descrio de seus processos de negcio ou tarefas do sistema, h algo de errado com os casos de uso.
Escreva casos de uso da perspectiva do usurio e no do sistema. Pea aos usurios para rev-los.
Nem sempre os casos de uso "full dressed (exaustivos) so os mais indicados. Procure ser prtico.
Novos processos de negcio

Usurios podero ter dificuldade em lidar com casos de uso se o software serve a um processo que no existe ou est sendo alterado. Avalie a possibilidade de realizar a modelagem de processos de negcio antes de iniciar a modelagem de casos de uso. Problema: PSP no aborda modelagem de negcio! Em ltima instncia, elabore um ou mais diagramas de atividade com a viso de processos e associe os casos de uso as atividades dos diagramas.
12
Uso excessivo de relacionamentos include e extend

Incluso e extenso so situaes particulares, em que se destaca um pedao do UC. Ao se trabalhar com casos de uso pela primeira vez necessrio adotar uma mudana na forma como analistas, usurios e desenvolvedores pensam sobre requisitos. Casos de uso no representam fluxos! Muitos problemas surgem ao compar-los com outras tcnicas do paradigma estruturado. Esses elementos podem acrescentar uma complexidade desnecessria para entendimento dos casos de uso. Devem ser utilizados com parcimnia.
Tratamento de detalhes
Utilize o glossrio e o modelo de domnio para capturar definies. Use o modelo de domnio para capturar detalhes no glossrio. Capture regras de negcio no modelo de domnio. Use sub-fluxos somente para simplificar descries complexas. Em excesso, atrapalha a legibilidade. Use fluxos alternativos para capturar comportamento complexo e no usual.
Requisitos
26
13
Glossrio: O problema do domnio descrito atravs de um conjunto simples de definies. Deve haver consenso a respeito (envolver o usurio). Modelo de domnio: Construdo atravs de diagramas de classe UML, a partir dos termos-chave do glossrio. particularmente importante se h relacionamentos complexos entre os objetos do domnio do problema. Especificao suplementar: Requisitos que no so claramente capturados diretamente nos casos de uso ou interferem na clareza do fluxo (tipicamente regras de negcio e requisitos no funcionais).
Detalhes de informaes: Uma informao descrita em um caso de uso pode ser composta por mais de um atributo ou campo. Geralmente pode-se trata-la em grupo. Listas de campos ou descries de dados: Cada atributo possui nomes especficos que sero usados internamente pelas classes. Deve haver um mapeamento de atributos. Detalhes de campos e verificaes: Validaes e detalhes especficos como tamanho, tipo, mscara de edio. Devem constar do dicionrio de dados. Esses itens deve fazer parte do caso de uso. As especificaes devem constar de um documento a parte que posteriormente ser associado ao caso de uso.
14
Exemplo de modelo de domnio
Requisitos
29
Exemplo de glossrio
Pedido: Um contrato entre a companhia e um cliente para prover algum conjunto de itens para uma localizao em particular de um cliente. Contm nmero e datas de pedido, envio e entrega. Item: Especifica a quantidade de um produto em particular sendo pedido. Um item consiste da quantidade de produto pedido, quantidade fornecida e o produto. Cliente: Algum que solicita produtos. Possui um nome e detalhes de contato. Produto: Alguma coisa que pode ser vendida a um cliente. A definio de um produto inclui descrio, nmero e preo unitrio
15
BITTNER, Kurt e SPENCE, Ian, Use Case Modeling, Addison-Wesley, 2003. COCKBURN, Alistair, Escrevendo casos de uso eficazes, Bookman, 2005. OMG, Object Management Group, UML www.omg.org, 2004.
Requisitos
31
16

Apostila PSP Requisitos v1.2

Enviado por

Direitos autorais:

Formatos disponíveis

Apostila PSP Requisitos v1.2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila PSP Requisitos v1.2

Enviado por

Direitos autorais:

Formatos disponíveis

Processo de Software da PBH/Prodabel PSP

Requisitos de Software e Casos de uso

Processo de software PBH/Prodabel

Processo de Software da PBH/Prodabel PSP

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Problemas do desenvolvimento de software

Processo de software PBH/Prodabel

Problemas clssicos do desenvolvimento de software

Processo de software da PBH/Prodabel

Problemas com requisitos

Processo de software PBH/Prodabel

Processo de requisitos efetivo

Processo de software PBH/Prodabel

Processo de software PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Classificao dos requisitos

Processo de software da PBH/Prodabel

Classificao dos requisitos

Problema a ser resolvido

Produto a ser construdo

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Separao entre domnios

Processo de software PBH/Prodabel

Requisitos quanto visibilidade

Pblico-alvo dos documentos

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Exemplo de requisitos de usurio e sistema

Que software poderia ser este? ______________________________________________

Processo de software PBH/Prodabel

Exemplos de requisitos funcionais

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Classificao dos requisitos no funcionais

Facilidade de uso Eficincia

Entrega Implementao Padres

Interoperabilidade ticos Legais

Desempenho Espao Confiabilidade Portabilidade Privacidade Segurana

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Classificao dos requisitos no funcionais

Exemplos de requisitos no funcionais

Processo de software PBH/Prodabel

Requisito no funcional verificvel:

Requisito no funcional verificvel

Processo de software PBH/Prodabel

Mtricas para requisitos

Tamanho Facilidade de uso Confiabilidade

Processo de software PBH/Prodabel

Exemplos de atributos de qualidade

Processo de software PBH/Prodabel

Processo de software PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Id Desc1 Desc2 Desc3