Apostila Psp Requisitos v1.2

Processo de Software da PBH/Prodabel PSP

Requisitos de Software e Casos de uso

Gerência de Engenharia de Software (GESS-PB) Superintendência de Arquitetura de Sistemas (SAS-PB) Diretoria de Sistemas e Informação (DS-PB) Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A) Versão 1.2

Sumário

1. Requisitos de software 2. Engenharia de requisitos 3. Técnicas de levantamento (elicitação) de requisitos 4. Casos de uso 5. Modelagem de casos de uso 6. Exercícios

Processo de software PBH/Prodabel

C1-Introdução 1

Processo de Software da PBH/Prodabel – PSP

Gerência de Engenharia de Software (GESS-PB)

Superintendência de Arquitetura de Sistemas (SAS-PB)

Diretoria de Sistemas e Informação (DS-PB)

Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A)

Versão 1.2

Requisitos de software

Requisitos Processo de software da PBH/Prodabel 2

Objetivos

• Entender o que é um requisito

• Apresentar as classificações dos requisitos


C1-Introdução 2


Roteiro• Problemas de desenvolvimento de software

• Definição de requisitos

• Classificação dos requisitos

− Visibilidade

− Natureza

• Regras de negócio

• Requisitos e processos

• Interessados nos requisitos

• Engenharia de requisitos

− Desenvolvimento de requisitos

− Gerenciamento de requisitos


Problemas do desenvolvimento de software

• “A parte mais difícil de construir um software é decidirprecisamente o que deve ser feito.

• Nenhuma outra parte do trabalho conceitual é tão difícil do que estabelecer os requisitos detalhados, incluindo todasas interfaces com pessoas, equipamentos e outrossistemas.

• Nenhuma parte do trabalho influencia tanto o sistemaresultante se feita incorretamente.

• Nenhuma parte é mais difícil de retificar posteriormente.”

(Frederick Brooks)


C1-Introdução 3


Problemas clássicos do desenvolvimento de software


Problemas com requisitos• Envolvimento insuficiente dos usuários.

• Crescimento dos requisitos de usuário.

• Requisitos ambíguos.

• Gold plating (bala de prata).

• Especificações minimalistas.

• Excesso de classes de usuário.

• Planejamento inacurado.

• Outros:

• __________________________________________


C1-Introdução 4


Processo de requisitos efetivo• Redução de defeitos nos requisitos.

• Redução do retrabalho de desenvolvimento.

• Redução de características desnecessárias.

• Redução de custos para evoluções.

• Desenvolvimento agilizado.

• Redução dos problemas de comunicação.

• Redução do crescimento do escopo.

• Redução do caos no projeto.

• Estimativas mais acuradas.

• Aumento da satisfação dos envolvidos.


Requisitos

• O termo requisito nem sempre é utilizado pelaindústria de software de modo consistente.

• Em alguns casos, um requisito é visto como umadeclaração abstrata, de alto nível, de uma funçãoque o sistema deve fornecer ou de uma restrição do sistema.

• No outro extremo, ele pode ser uma definiçãodetalhada, matematicamente formal, de uma funçãodo sistema.

• Que definição adotar?

• __________________________________________


C1-Introdução 5


“Documento de requisitos”• Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um projeto de software, suas necessidadestêm que ser definidas de forma suficientemente abstrata para queuma solução “a priori” não seja definida.

• No caso de contratação externa os requisitos devem ser redigidosde modo que os diversos fornecedores possam apresentarpropostas.

• Uma vez estabelecido o contrato, o fornecedor escolhido precisapreparar uma definição de sistema para o cliente contendo maisdetalhes, 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 afirmações mostram que a definição de requisitos deve ser feita por meio de refinamentos sucessivos, indo do “conceitual” emdireção ao “físico”.


Definição de requisitos

1. Condição ou capacidade necessária a um usuáriopara resolver um problema ou atingir um objetivo.

2. Condição ou capacidade que deve ser alcançada oupossuída por um sistema ou componente de sistemapara satisfazer um contrato, padrão, especificaçãoou outro documento formalmente imposto.

3. Uma representação documentada de uma condiçãoou capacidade como nos itens 1 e 2 acima.

Fonte: [IEEE Standard Glossary of Software Engineering Terminology, 1990]


C1-Introdução 6


Definição de requisitos II

“Requsitos são uma especificação do que deveser implementado. Eles constituem descriçõesde como o sistema deve se comportar, ou umapropriedade ou atributo do sistema. Podemcaracterizar uma restrição no processo de desenvolvimento do sistema.”

Fonte: Sommervile e Sawyer, Requirements Engineering, 1997].


O que requisito não é

• Especificação de requisitos não incluem:

−Detalhes de desenho;

− Implementação;

− Informações de teste;

−Requisitos de projeto;

− Limites de recursos e tempo;

− necessidade de um tutorial para os usuários;

− Etc…


C1-Introdução 7


Classificação dos requisitos

• Quanto a visibilidade

– Requisitos de usuário;

– Requisitos de sistema;

– Requisitos de desenho.

• Quanto a natureza

– Funcionais;

– Não funcionais.


Classificação dos requisitos

Necessidades

Requisitos de usuário

Domínio dasolução

=> SistemaRequisitos de sistemas

Requisitos de desenho

Domínio do problema

=> Negócio

Produto a ser construído

+ Conceitual

+ Físico

Problema a ser resolvido


C1-Introdução 8


Separação entre domínios• A separação em domínios indica que osrequisitos de software tratam da solução para um problema.

• O formato da pirâmide reflete o volume relativodo problema: poucas necessidades podem exigirvários requisitos.

• Rastreabilidade deve ser mantida entre todos osníveis.


Necessidades• Também conhecidas como requisitos de negócio, representamobjetivos de alto nível da organização ou cliente que requisitou o sistema. Tipicamente são originadas do patrocinador do projeto, o adquirente. Por ex: o gerente dos usuários ou o setor de marketing.

• Descrevem porque a organização está implementando o sistema– os objetivos que espera-se atingir. Normalmente sãocontemplados num documento de visão ou proposta do projeto.

• Ex: “Reduzir os custos operacionais [em y%]”; “Aumentarparticipação no mercado [em x%]”; “Implantar nova linha de produtos e serviços”.

• Dê um exemplo na sua área de trabalho:

• ____________________________________________________


C1-Introdução 9


Requisitos quanto à visibilidade• Requisitos de usuário: Declarações em linguagem natural e também em diagramas sobre as funções que o sistema devefornecer e as restrições sob as quais deve operar.

• Requisitos de sistema: Estabelecem detalhadamente as funçõese restrições de sistema. O documento de requisitos de sistema, também chamado Especificação Funcional ou de Requisitos, deve ser preciso. Ele pode servir como um contrato entre comprador e desenvolvedor.

• Requisitos de desenho: Uma descrição abstrata que é base paradetalhes de implementação. Essa especificação acrescenta maisdetalhes à Especificação de Requisitos do Sistema. É um documento orientado à implementação.


Público-alvo dos documentos


•Gerentes de clientes•Usuários finais•Técnicos do cliente•Gerentes do fornecedor•Arquitetos de sistemas

•Usuários finais de sistemas•Técnicos do cliente•Arquitetos de sistemas•Desenvolvedores de software (eventual)

•Técnicos do cliente(eventualmente)•Arquitetos de sistemas•Desenvolvedores de software

Requisitos de sistema



C1-Introdução 10


Exemplo de requisitos de usuário e sistema

• Requisitos de usuário:

– “O sistema deve oferecer um meio de representar e acessararquivos externos criados por outras ferramentas.”

• Especificação de requisitos de sistema:

– “O usuário deve dispor de recursos par definir o tipo dos arquivos externos.

– Cada tipo de arquivo pode ser representado como um íconeespecífico na tela do usuário.

– Quando um usuário seleciona um ícone de um arquivoexterno, o efeito é aplicar a ferramenta associada com o tipode arquivo representado, permitindo executa-lo.”

Que software poderia ser este?

______________________________________________


Requisitos funcionais• Declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em dadas situações.

• Descrevem as funcionalidades ou serviços que um sistema oferece.

• Dependem do tipo de software, usuários esperados e do tipo de sistema onde o software será utilizado.

• Enquanto requisitos funcionais de usuário podem ser declarações de alto nível do que o sistema deve fazer, requisitos funcionais de sistema devem descrever osserviços do sistema em detalhes.


C1-Introdução 11


Requisitos funcionais

• Especificam funcionalidades de software queos desenvolvedores devem construir parapossibilitar aos usuários executar suas tarefas, satisfazendo aos requisitos de negócio.

• Esse tipo de requisitos é descritotradicionalmente pela sentença 'deve‘.

• Ex: “O sistema deve enviar uma mensagemcom a confirmação de reserva para o usuário”.


Exemplos de requisitos funcionais

• Sistema de biblioteca:

– “O usuário deverá ser capaz de buscar todo o conjunto inicial de banco de dados ou selecionarum subconjunto a partir dele.

– O sistema deve prover telas apropriadas para o usuário ler documentos no repositório de documentos.

– Cada pedido será alocado a um único identificador(ID_Pedido), que o usuário poderá copiar para a área de armazenagem permanente da conta.”


C1-Introdução 12


Requisitos não funcionais

• Restrições sobre as funções oferecidos pelo sistema. Destacam-se aqui as restrições de tempo, processo e padrão.

• Ex.: tempo de resposta, requisitos de armazenamento, confiabilidade, capacidade dos dispositivos de I/O, etc...

• Também podem ser especificados uma determinada ferramentaCASE, linguagem de programação ou processo de desenvolvimento.

• Podem ser mais críticos que os requisitos funcionais.

Ex: ________________________________________________

• Caso não sejam atendidos, o sistema pode tornar-se inutilizável.

Ex: ________________________________________________


Classificação dos requisitos não funcionais

Facilidade de uso

Desempenho

Espaço

Eficiência

Confiabilidade

Portabilidade

Requisitos de produto

Entrega

Implementação

Padrões

Requisitos organizacionais

Interoperabilidade

Éticos

Privacidade

Segurança

Legais

Requisitos externos

Requisitos não funcionais


C1-Introdução 13


Classificação dos requisitos não funcionais

• Requisitos de produto: Especificam o comportamento do produto.

• Requisitos organizacionais: Decorrem de políticas e procedimentos nas organizações do cliente e/ou do desenvolvedor.

• Requisitos externos: Abrangem todos os requisitosprocedentes de fatores externos ao sistema e ao seuprocesso de desenvolvimento.


Exemplos de requisitos não funcionais

• Requisitos de produto:

– “Deve ser possível que toda a comunicação necessáriaentre o software e o usuário seja expressa no conjuntopadrão de caracteres ASCII”.

• Requisitos de organização:

– “O processo de desenvolvimento e os documentosentregues deverão estar de acordo com o processo e osprodutos definidos em XYZCo-SP-STAN-95”.

• Requisitos externos:

– “O sistema não deverá revelar aos operadores nenhumainformação pessoal sobre os clientes além de seus nomese código”.


C1-Introdução 14


Metas e requisitos

• Requisitos não funcionais podem ser difíceis de estabelecer e requisitos imprecisos são difíceis paraverificar.

• Metas são úteis a medida que elas esclarecem as intenções dos usuários do sistema

• Meta:

– Uma intenção do usuário, como “fácil de usar”, “rápido”.

• Requisito não funcional verificável:

– Uma sentença que use alguma métrica que possa ser objetivamente testada.


Exemplos

• Uma meta do sistema

– “O sistema deve ser fácil de ser usado porcontroladores experientes e organizado de tal forma que os erros possam ser minimizados.”

• Requisito não funcional verificável

– “Controladores experientes devem estar aptos a usar todas as funções do sistema após um treinamento de duas horas

– Após o treinamento, o número médio de erroscometidos pelos usuários experientes não podeexceder o total de dois por dia.”


C1-Introdução 15


Métricas para requisitos

Porcentagem de declarações dependentes de sistema alvo

Número de sistemas alvo

Portabilidade

Tempo de reinício após falha

Porcentagem de eventos que causam falhas

Probabilidade de corrupção de dados

Robustez

Tempo médio para falhar

Taxa de ocorrência de falhas

Disponibilidade

Confiabilidade

Tempo de treinamento

Número de frames de ajuda

Facilidade de uso

K Bytes

Número de chips de RAM

Tamanho

Transações processadas por segundo

Tempo de resposta ao usuário/evento

Tempo de refresh de tela

Velocidade

MétricaPropriedades


Atributos de qualidade

• Visão do cliente:

• Disponibilidade

• Eficiência

• Flexibilidade

• Integridade

• Interoperabilidade

• Confiabilidade

• Robustez

• Usabilidade

• Visão do

desenvolvedor:

• Manutenibilidade

• Portabilidade

• Reusabilidade

• Testabilidade

• Os requisitos não funcionais também são conhecidoscomo atributos de qualidade (norma ISO 9126):


C1-Introdução 16


Exemplos de atributos de qualidade• Disponibilidade: “O sistema deve estar 99,5 % do tempo disponível nos dias de semana de 6h às 18h”.

• Eficiência: “O sistema deverá estar reservar pelo menos 25% da capacidade do processador em condições de pico”.

• Integridade: “Somente usuários que tem acesso como Auditor devem ser habilitados a visualizar dados de transações de clientes”.

• Interoperabilidade: “O sistema deve ser capaz de importarqualquer registro válido de funcionário, provido pelo sistemaPessoal”.

• Confiabilidade: “No máximo cinco em cada 1.000 transaçõespodem falhar”.


Regras de negócio

• Não são exatamente requisitos, pois existem fora dos

limites de qualquer sistema específico.

• Geralmente restringem quem pode desempenhardeterminadas tarefas ou diz que o sistema deve contercertas funcionalidades.

• Normalmente inclui políticas da corporação, regulações governamentais, padrões da indústria, práticas contábeis e algoritmos computacionais.


C1-Introdução 17


Regras de negócio

• Uma regra de negócio é uma sentença que define ourestringe algum aspecto do negócio. Tem porobjetivo atender a estrutura, controlar ou influenciar o comportamento do negócio.

• Classificação das regras de negócio:

- Fato

- Restrição

- Habilitador

- Cálculo

- Inferência


Fato

• Sentenças simples verdadeiras sobre o negócio. Tipicamente descrevem associações ou relações entre termos de negócio relevantes. São também chamadasde invariantes.

• Exemplos:

− “Cada contêiner deve ter um único código de barraidentificador”.

− “Todo pedido deve ter uma carga de entrega”.

− “Taxas de vendas não são computadas nas cargas de envio”.


C1-Introdução 18


Restrições

• Restringem as ações que o sistema ou usuários podemexecutar. Algumas palavras e frases sugeremrestrições como ‘deve’ e ‘não deve’.

• Exemplos:

− “Tripulação 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 responsável”.


Habilitador

• Regra que dispara alguma atividade sob uma condiçãoespecífica.

• Exemplos:

− “Se a data de expiração de um produto tiver sido atingida, o responsável deve ser notificado por email”.

− “No último dia da quinzena, gerar os relatórios gerenciais e disponibilizar aos gestores”.


C1-Introdução 19


Cálculo

• Cálculos realizados usando fórmulas matemáticas específicas oualgoritmos. Vários cálculos seguem regras externas as organizações.

• Exemplos:

− “O preço total de um pedido é determinado pela soma dos preços de cadaitem, deduzido de qualquer desconto de volume, mais taxas de vendasestaduais e federais, mais taxa de embarque e seguro”

− Tabela de desconto:

20mais de 10Desc3

106 a 10Desc2

01 a 5Desc1

Desconto (%)Itens vendidosId


Inferência

• Regra que estabelece algum novo conhecimentobaseado na verdade de certas condições. Umainferência cria um novo fato de outros fatos ou de cálculos. São geralmente escritos no formato “se …então”.

• Exemplos:

− “Se o pagamento não for recebido em 30 dias corridos, o títuloserá protestado”.

− “Produtos com taxa de toxidade maiores que 5 mg/kg sãoconsiderados perigosos”.


C2-Engenharia de requisitos 1






Versão 1.2

Engenharia de requisitos de software


Objetivos

• Apresentar o conceito de Engenharia de requisitos

• Apresentar a disciplina Requisitos do PSP




Roteiro

• Engenharia de requisitos

• Processo de Software da PBH / Prodabel (PSP)

• MPS.BR

• RUP

• Desenvolvimento de requisitos

• Gerência de requisitos


Engenharia de requisitos

• Processo de estabelecer os serviços que um clienterequer de um sistema e as restrições em que o mesmo é desenvolvido e será operado.

• Os requisitos são a descrição dos serviços de sistema e restrições que são gerados durante o processo de engenharia de requisitos.

• Os processos usados dependem do domínio daaplicação, pessoas envolvidas e organização.




Atividades da engenharia de requisitos

• Desenvolvimento de requisitos

− Levantamento (Elicitação)

− Análise

− Especificação

− Verificação e validação

• Gerenciamento de requisitos

− Controle de versões

− Controle de mudanças


Limites entre desenvolvimento e gerenciamento de requisitos




Requisitos e outras disciplinas


Interessados nos requisitos

• Indivíduo ou organização que recebe direta ouindiretamente algum benefício do produto.

• Incluem os envolvidos no projeto que recebempagam, selecionan, especificam, usam ourecebem os resultados gerados por um produto de software.

• Alguns exemplos de interessados sãoanalistas, desenvolvedores, testadores, documentadores, gerentes de projeto, equipede suporte, equipe jurídica, marketing, etc.




Conflito de interesses


Direitos do usuário

• Esperar que o analista fale a sua língua.

• Esperar que o analista compreenda o negócio.

• Esperar que o analista escreva a especificação de requisitos.

• Receber explicação do analista sobre os produtos gerados.

• Receber tratamento respeitoso e profissional do analista.

• Receber alternativas do analista.

• Descrever características do produto que facilitarão sua vida.

• Ter oportunidade de ajustar o produto para prover reuso.

• Receber estimativas corretas de tempo e custo.

• Receber informações sobre o impacto dos pedidos de mudança.

• Receber um sistema que atenda aos requisitos.




Responsabilidades dos usuários (a “revanche”)

• Explicar a terminologia da área de negócio.

• Disponibilizar tempo para prover requisitos, elucidá-los e atualizá-los.

• Ser específico e preciso ao prover informações para os requisitos.

• Tomar decisões em tempo hábil sobre requisitos.

• Não pressionar por estimativas de prazo e custo inviáveis.

• Respeitar as estimativas de prazo e custo informadas.

• Definir com o analista as prioridades dos requisitos.

• Revisar os documentos de requisitos e avaliar protótipos.

• Comunicar necessidades de mudanças nos requisitos assim que souber.

• Seguir o processo definido para solicitar pedidos de mudança.

• Respeitar o processo de engenharia de requisitos.


Analista de requisitos

• Analista de requisitos é o indivíduo que tem comoresponsabilidade principal coletar, analisar, documentar e validar as necessidades dos envolvidos no projeto.

• O analista serve como principal condutor através do qual os requisitos fluem dos clientes até a equipe de desenvolvimento.

• Avalie como isto acontece na sua área funcional:

____________________________________________

____________________________________________




Canais de comunicação do analista


Competências 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.

• Domínio da aplicação.




Importante

• Não assuma que um desenvolvedor talentoso ouusuário avançado automaticamente pode se tornarum analista de requisitos efetivo sem treinamento, material de apoio e acompanhamento.

• As atribuições de um analista demandamhabilidades, conhecimentos e atitudes diferentes.

• Analise se você tem as habilidades e conhecimentosrequeridos de um analista de requisitos:

• Habilidades: __ Sim __ Não

• Conhecimentos: __ Sim __ Não


Requisitos no PSP

• Os assuntos relacionados a requisitos de software no Processode Software da PBH/Prodabel estão disponíveis no próprioprocesso.

• As principais referências para a estruturação do fluxo são:

• Disciplina de Requisitos do RUP: O PSP é aderente ao RUP e, por consequência, requisitos orientam todo o processo de desenvolvimento de software.

• Resultados esperados do MPS.BR: Os REP específicos de Gerência de Requisitos devem ser atendidos.




Requisitos e o RUP


Resultados Específicos (REP) de GRE

� GRE 1. O entendimento dos requisitos é obtido junto aosfornecedores de requisitos;

� GRE 2. Os requisitos de software são aprovados utilizando

critérios objetivos;

� GRE 3. A rastreabilidade bidirecional entre os requisitos e osprodutos de trabalho é estabelecida e mantida;

� GRE 4. Revisões em planos e produtos de trabalho do projetosão realizadas visando identificar e corrigir inconsistências em

relação aos requisitos;

� GRE 5. Mudanças nos requisitos são gerenciadas ao longo do

projeto.




Fluxo de requisitos do PSP


Fluxo de requisitos do PSP

• Atividade “Obter entendimento”:– Elaborar especificação de requisitos

– Elaborar modelo de caso de uso

• Atividade “Desenvolver requisitos”:– Especificar caso de uso

– Elaborar especificação suplementar

• Atividade “Gerenciar requisitos”:– Registrar solicitação

– Analisar impacto




Requisitos no PSP

• Principais papéis :– Analista de requisitos

– Desenvolvedor

• Principais artefatos:– Especificação de requisitos

– Modelo de casos de uso

– Caso de uso (detalhado)

– Especificação suplementar


Fontes de requisitos




Fontes de requisitos• Entrevistas e discussões com usuários potenciais.

• Documentos dos produtos atuais ou concorrentes.

• Especificação de requisitos.

• Relatórios de problemas e pedidos de melhoria.

• Pesquisas de marketing e questionários de usuários.

• Observação do usuário no trabalho.

• Análise de cenários e tarefas de usuários.

• Eventos e respostas.

• Outros: _____________________________________


Outros tipos de entradas• Requisitos não relacionados com o produto, como necessidadesde treinamento dos usuários.

• Restrições de projeto como prazo e custo.

• Uma premissa.

• Informação adicional de um contexto histórico para ajudar a entender o contexto.

• Dê um exemplo de cada caso:

Treinamento: __________________________________________

Projeto: ______________________________________________

Premissa: ____________________________________________

Informação adicional: ___________________________________




Diretrizes para explicitação de requisitos• Escreva sentenças completas com gramática, ortografia e pontuação

corretas. Mantenha parágrafos curtos e diretos.

• Use a voz ativa. Ex: “O sistema deve fazer algo” ao invés de “Alguma coisadeve ser feita”.

• Quando definir requisitos na forma “O usuário deve...” identifique o ator (“O comprador deve...”).

• Use termos consistentes definidos no glossário. Evite sinônimos.

• Decomponha requisitos de alto nível em requisitos mais detalhados de forma a torná-los claros e para reduzir a ambiguidade.

• Use listas, figuras, gráficos e tabelas, se necessário.

• Enfatize os trechos mais importantes de informação.

• Evite termos ambiguos, tais como: adequado, eficiente, flexível, melhor, maximizar, normalmente, robusto, várias, suficiente, amigável…


Especificação de requisitos

• É a base para a equipe de análise e desenho, poisdescreve funções e desempenho requeridos de um sistema baseado em computação e as regras queguiarão seu desenvolvimento.

• Limita cada elemento alocado ao sistema e tambémdescreve as informações (dados e controle) queconstituem as entradas e saídas do sistema.

• Pode ser um documento escrito, um modelográfico, um modelo matemático formal, umacoleção de cenários de uso, um protótipo ouqualquer combinação dos itens citados.




Verificação e validação (V&V)

• Verificação:

− Tem como propósito confirmar que cada serviço e/ou

produto de trabalho do processo ou do projetoatende apropriadamente os requisitos especificados.

− Normalmente desempenhada pela equipe técnica.

• Validação:

− Tem como propósito confirmar que um produto ou

componente do produto atenderá a seu uso

pretendido quando colocado no ambiente para o qual

foi desenvolvido.


Verificação e Validação

� Verificação: “Estamos construindo certo o

produto?”

- Ponto de vista do desenvolvedor / equipe.

� Validação: “Estamos construindo o produto

certo?”

- Ponto de vista do usuário final / cliente.




Técnicas para V&V de requisitos

• Revisão - exemplos:

• Discussão de um problema técnico na hora do café.

• Apresentação do projeto de software para uma audiênciade clientes, administradores e pessoal técnico.

• Revisões Técnicas Formais: inclui avaliações técnicasde software realizadas em pequenos grupos(walkthrough).

� Inspeção: análise detalhada feita por um grupo com papéis e organização bem definidos.

� Testes: execução de um programa com o objetivode encontrar erros.


Exemplos de critérios de V&V• Os requisitos estão estruturados claramente? Não há problemas de

interpretação 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 são os requisitos relacionados a cada um? Eles estãoclaramente identificados através de uma matriz de referência cruzadaou outro mecanismo?

• O requisito viola alguma regra de domínio?

• O requisito é passível de teste?

• O requisito é rastreável para os objetivos gerais?

• Os requisitos associados à performance, comportamento e características operacionais foram estruturados claramente?




Exemplos de critérios de V&V• Consistente. Há algum conflito de requisitos?

• Completo. Todas as funções requeridas pelo cliente foramincluídas e contêm informações para as demais atividades?

• Real. Os requisitos podem ser implementados com os recursos e tecnologia disponíveis?

• Completo: cada requisito contém toda a informação necessária aodesenho e implementação?

• Viável: deve ser possível implementar cada requisito considerandoas capacidades e limitações existentes.

• Necessário: devem ser descritas as capacidades realmentenecessárias aos usuários.

• Priorizado: cada requisito deve ser priorizado.

• Não-ambíguo: todos os leitores dos requisitos têm que ter umaúnica e consistente interpretação do seu significado.


Priorização de requisitos• Projetos de software possuem limitações de recursos que nos obrigam a

definir a prioridade relativa dos requisitos. A priorização ajuda o gerente de projeto a resolver conflitos, planejar iterações e fazer as compensaçõesnecessárias.

• Quando as expectativas do cliente são altas e o tempo é curto, faz-se necessário entregar o produto com as funcionalidades mais relevantes, o maiscedo possível.

• Perguntas úteis:

• Há outra maneira de satisfazer as necessidades que esse requisito trata?

• Qual será a consequência de omitir esse requisito?

• Qual será o impacto nos objetivos de negócio se o requisito não for implementado nessa iteração?

• Por que o usuário ficaria descontente caso esse requisito fosse adiadopara a última iteração?




Priorização de requisitos

O que fazer?Média prioridadeNão urgente

Baixa prioridadeAlta prioridadeUrgente

Não importanteImportante-

0,3050350322,2421RQ2

1,1733,3216,7138,9732RQ3

-100610061001866Total

Prioridade

Risco%

Riscorelativo

Custo%

Custorelativo

Valor%

ValorTotal

Perdarelativa

Benefíciorelativo

Requisito

0,9316,7133,3238,9713RQ1

--0,5-1--12Peso

Prioridade = Valor % / [ (custo % * peso custo) + ( risco % * peso risco) ]


Modelagem visual de requisitos

• Nenhuma forma de representação de requisitos provêindividualmente um entendimento completo.

• Normalmente, combinações de reprentações textuais e gráficas mostram uma visão completa do sistemaestudado. Alguns mecanismos visuais são:

• Protótipos;

• Tabelas e árvores de decisão;

• Diagramas DFD, DER, classes, estados, sequência.

• Casos de uso.




Gerenciamento de requisitos• Os requisitos passam a compor uma baseline após seremrevisados 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 mudanças na baseline de requisitos.

• Manter planos de projetos de acordo com os requisitos.

• Controlar versões dos requisitos e documentos associados.

• Monitorar o status dos requisitos na baseline.

• Gerenciar as ligações entre requisitos e outros produtos de trabalho.


Controle de versões de requisitos

• Cada versão dos documentos de requisitos deve ser unicamenteidentificada. Cada membro da equipe deve ser capaz de acessara versão corrente dos requisitos. Mudanças devem ser documentadas e comunicadas a todos envolvidos.

• Para minimizar confusão, conflitos e desentendimentos, somentepessoas designadas podem atualizar os requisitos e ter certezade que o número de versão muda sempre que ocorreremmudanças.

• Na sua visão como poderia ser feito esse controle?

______________________________________________________

______________________________________________________




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 queatribuir um percentual de conclusão. Exemplos de status:

• Proposto: requisito solicitado por pessoa autorizada.

• Aprovado: realizada análise de impacto, estimativas de projeto e alocação para uma release específica.

• Implementado: código desenhado, escrito e testado.

• Verificado: funcionamento confirmado e requisito integrado.

• Rejeitado: requisito proposto mas não planejado paraimplementação em nenhuma release.


Controle de mudanças

• Procedimentos que visam garantir:

• Mudanças de requisitos propostas são avaliadascuidadosamente antes de atualizadas.

• Responsáveis tomam decisões sobre mudanças solicitadas.

• Mudanças aprovadas são comunicadas a todos interessados.

• O projeto incorpora mudanças de uma maneira consistente.

• Você acha que os mecanismos de CM devem ser formais ou informais? Explique!

______________________________________________

______________________________________________




Política de controle de mudanças• Todas as mudanças de requisitos devem seguir o processo definido. Se uma

solicitação de mudança fugir ao processo, está fora!

• Para as mudanças não aprovadas nenhum trabalho de desenho e implementação deve ser feito. A única atividade é análise de viabilidade.

• Em alguns casos o grupo gestor deve decidir se uma solicitação deve ser implementada.

• O conteúdo da base de mudanças deve ser visto por todos envolvidos.

• Análise de impacto deve ser feita para toda mudança.

• O texto original do pedido de mudança não deve ser alterado.

• Cada mudança em requisitos incorporada deve ser rastreável até o pedidoaprovado.

• A razão de cada aprovação/reprovação deve ser registrada.


Papéis no controle de mudanças

• CCB (Change Control Board): grupo que decide aprovar ourejeitar mudanças propostas para um projeto específico.

• Avaliador: apoia o CCB analisando o impacto de um pedido de mudança. Pode ser um técnico, o cliente, etc.

• Modificador: responsável por realizar as mudanças em um produto de trabalho a partir das solicitações aprovadas.

• Originador: quem submete um pedido de mudança.

• Destinatário (Recebedor): quem recebe as novas solicitações.

• Verificador: responsável por determinar se as mudanças foramfeitas corretamente.




Análise de impacto

• Geralmente desenvolvida por um técnico com grandeconhecimento. Possui três aspectos:

• Entender as possíveis implicações de se fazer a mudança.

• Identificar todos arquivos, modelos e documentos que devem ser modificados se a mudança ocorrer.

• Identificar tarefas necessárias para implementar a mudança e estimar o esforço, tempo e recursos necessários.

• Importante: deixar de analisar impacto não muda o tamanho datarefa mas deixa o escopo do trabalho como uma surpresa.

• Você já viu realizar-se análise de impacto em algum projeto?

______________________________________________________


Rastreabilidade de requisitos

• Rastreabilidade é a característica que permiteacompanhar a vida de um requisito, desde a origem atéa implementação.

• A rastreabilidade pode ajudar a:

• garantir que os requisitos especificados são associados as necessidades dos clientes.

• garantir que todo produto de trabalho está associado aosrequisitos identificados.

• A restreabilidade deve ser BIDIRECIONAL, ou seja, permitir que se caminhe nos dois sentidos.




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
















Referências Bibliográficas

• WIEGERS, Karl, Software requirements, 2ºedition, 2006.

• SOMMERVILLE, Ian, Engenharia de Software, Addison Wesley, 6ª edição, 2003.

• PRESSMAN, Roger S., Engenharia de Software, McGraw Hill, 5ª Edição, 2002.


C3-Técnicas de elicitação 1






Versão 1.2

Técnicas de levantamento (elicitação)

de requisitos de software

Técnicas de elicitação Processo de software da PBH/Prodabel 2

Objetivos

• Apresentar as principais técnicas para o levantamento (elicitação) de requisitos.




Roteiro

• Observação pessoal.

• Pesquisa.

• Questionário.

• Entrevista.

• Reuniões.

• Brainstorming.

• JAD


Observação pessoal

• Consiste em conviver com situações cotidianas.

• Possibilita a confirmações recebidas como: leiaute, problemas de relacionamento, erros de procedimento, segurança do trabalho, etc.

• Vantagens: não interrupção das atividades, nãoexigência de disponibilidade do tempo de envolvidos.

• Desvantagens: ausência de evidências formais, causar mal-estar na área envolvida, conclusõescomprometedoras.




Pesquisas

• Pesquisa interna: averiguação física de umaatividade e processo.

• Vantagens: percepção do pesquisador, esclarecimento de dúvidas.

• Desvantagens: cria “mal estar” entre osparticipantes, demanda muito tempo.

• Pesquisa externa: utilizada quando não se dispõede qualquer experiência para descrever osrequisitos. Utiliza informações de acervos externossociedades profissionais, periódicos, livros técnicose relatórios de pesquisa.


Questionário• Instrumento que envolve os processos de preparação em formulário, distribuição, recolhimento e tabulação.

• Pode ser precedido de um pré-teste.

• Vantagens: agilidade, custo, facilidade, abrangência de pessoas, mensuração uniforme, anonimato, ausência de pressão por resultadosimediatos.

• Desvantagens: manipulação de respostas antes de entregar, tendência de utilização de respostapadrão, frieza.




Entrevista

• Diálogo entre entrevistado e entrevistador.

• Vantagens: as perguntas podem ser alteradas(conteúdo, ordem, eliminação, inclusão), podem ser esclarecidos pontos das perguntas, podem ser avaliadas as reações dos entrevistados, pode-se motivar o entrevistado.

• Desvantagens: alcança menos pessoas, tratamentodiferenciado aos entrevistados, desvios de curso, demanda tempo, avaliações subjetivas, alterações nasperguntas e conteúdo, desestimulo, impossibilidade de avaliação prévia, respostas politicamente corretas.


Seminário

• Reunião planejada de pessoas-chave de diversasáreas com o objetivo de obter informações geraissobre a empresa.

• Também chamada de workshops e dinâmica de grupo.

• Vantagens: rapidez na identificação de problemasde relacionamento, estrangulamentos e visãointegrada de problemas.

• Desvantagens: mobilizar um grande número de pessoas ao mesmo tempo, interferindo na rotina de trabalho da empresa.




Brainstorming• Técnica de obtenção de informações em reuniões. Etapas:

• Geração de idéias:

• Não permitir críticas ou debates;

• Deixar a imaginação voar;

• Procurar quantidade;

• Mudar e combinar idéias.

• Seleção de idéias:

• Decidir com base em um limite de votos

• Decidir com base em discurso de campanha

• Juntar idéias e aplicar critérios;

• Utilizar sistemas de pontuação.


JAD

� Joint Application Design (Projeto de Aplicação Conjunta).

� Método criado pela IBM no ano de 1977.

� Consiste em reuniões estruturadas intensivas e em grupo, onde participam os representantes do usuário e da informática.

� Cada sessão é composta por uma ou mais reuniões e dura de um a três dias.

� Toda reunião é conduzida por um facilitador (ou mediador) que visa obter o consenso de forma rápida.




Principais características do JAD

� As reuniões substituem as entrevistas individuais.

� O processo de trabalho é altamente estruturado.

� Os papéis são bem definidos.

� As decisões são baseadas em consenso.

� O facilitador elimina as barreiras de comunicação.

� Os recursos visuais dinamizam o trabalho.


Reuniões ao invés de entrevistas

� Os usuários se sentem prestigiados e parte integrante do

processo, visto que suas opiniões são consideradas.

� As divergências são resolvidas pelo grupo, pois todas as

idéias são discutidas por todos.

� Pode significar grande economia de tempo de

desenvolvimento. Entretanto, a carga horária alocada ao

projeto tende a ser maior se comparada ao uso de

entrevistas individuais, devido a uma participação mais

intensa dos usuários.




Processo de trabalho estruturado

� Os produtos a serem alcançados são previamente discutidos e são a base de todo o trabalho.

� Cada sessão tem sua finalidade definida e todos os participantes conhecem os resultados esperados.

� Os trabalhos de cada sessão são feitos baseados em uma agenda padrão adotada em todas as reuniões. Somente a abordagem da sessão é que varia.

� Os resultados são insumos para o projeto.


Papéis são bem definidos

� Executivo patrocinador: autoridade das áreas de negócio envolvidas. Redime conflitos, estabelece as diretrizes e objetivos e abre os trabalhos.

� Gerente de projeto: principal contato do facilitador durante o processo.

� Equipe: responsável pelo conteúdo da sessão. São as pessoas-chave das áreas envolvidas, em todos os níveis.

� Facilitador: Guia imparcial, garante participação e consenso.

� Documentador: registra decisões tomadas.




Decisões baseadas em consenso

� Consenso não é a unanimidade, mas a concordância de que a solução encontrada é a melhor para o grupo.

� Consenso também é aquela solução com a qual os participantes irão conviver sem ferir suas próprias convicções e valores essenciais.

� A forma mais produtiva de decisão em grupo é aquela baseada em consenso.

� A condução ao consenso é a principal tarefa do facilitador.


Facilitador elimina barreiras de

comunicação� O facilitador é uma pessoa neutra do grupo que não avalia nem contribui com idéias.

� Sugere métodos que ajudem o grupo a concentrar energia em tarefas específicas.

� Protege todos os membros do grupo contra ataques.

� Garante a participação de todos de forma homogênea.

� A presença do facilitador torna a reunião mais produtiva.




Recursos visuais dinamizam o

trabalho� O andamento das sessões se beneficia do uso de

recursos visuais como transparências, slides,

vídeos, flipcharts, micros etc.

� Todos os resultados das discussões são exibidos

através de recursos adequados para que todos

possam ver.

� Tais recursos estimulam os sentidos, esclarecem

pontos confusos e fazem uso eficaz do tempo.


Detalhamento do processo JAD

� Tipos de sessões JAD: gerenciais e técnicas.

� Ciclo de trabalho de uma sessão: preparação, execução e revisão.

� Agenda padrão de uma sessão: introdução, revisão de perspectiva gerencial, abertura pelo executivo patrocinador, visão da área de informática, regras de conduta, abordagem da sessão, revisão de pendências, revisão geral, avaliação da sessão.

� Abordagem da sessão: varia de acordo com o tipo de sessão.




Sessão de gerenciamento

� Visa discutir o escopo do projeto, objetivos, metas, recursos e estratégias a serem adotadas. Étipicamente a primeira sessão de um projeto, permitindo identificar suas partes componentes e prioridades.

� Participantes: gerentes de alto nível e executivos das áreas de negócios envolvidas, bem como o representante da área de informática

� Número de participantes: máximo 20


Sessão técnica

� Define as funções componentes do sistema, a lógica de funcionamento do negócio e de que forma os elementos se relacionam e são tratados.

� Devem ser orientadas par suprir as informações necessárias à criação dos modelos de dados e processos.

� Participantes: gerentes e supervisores das áreas de negócio. Devem ser capazes de conhecer o negócio, fluxos de trabalho.

� Número de participantes: máximo 10




Ciclo de trabalho JAD

� Devido ao seu alto grau de planejamento,

estruturação e formalização, o JAD pode ser

visualizado como um ciclo de processo que engloba

as fases:

− Preparação;

− Sessão (a execução de uma sessão);

− Revisão.


Ciclo de trabalho - preparação� Examinar adequação do JAD: avaliar em conjunto com o gerente de projeto: os riscos (para o negócio, projeto e técnica), tamanho do projeto, domínio da metodologia, etc.

� Planejar: dimensionar nº de sessões, duração, alocação de recursos.

� Elaborar a perspectiva gerencial: finalidade, escopo, objetivos e restrições.

� Familiarizar-se com a área de negócios: entrevistar participantes previamente.

� Preparar agenda da sessão: seguir padrão.

� Preparar participantes: informar agenda e pedir “exercício de casa”.

� Preparar ferramenta de documentação.




Ciclo de trabalho - sessão

� Preparar ambiente: arrumação das mesas, verificação dos equipamentos audiovisuais, checklist dos materiais, preparação de pastas.

� Condução da sessão: apresentação dos participantes, explicar agenda, abordar logística, rever perspectiva gerencial, desenvolver agenda.

� Documentação: anotar todas as deliberações da reunião, ler todo o material e gerar documentação.

� Encerramento: revisão geral da agenda, avaliação da sessão, entrega da documentação produzida.


Ciclo de trabalho - revisão

� Rever documentação: verificar se informações estão corretas, corrigir falhas de comunicação, encaminhar documentação aos participantes.

� Examinar avaliações: avaliar se o método está sendo efetivamente útil e a satisfação dos participantes.

� Preparar pasta do projeto: contendo perspectiva gerencial, plano de sessões, agenda de cada sessão, lista de participantes de cada sessão, documentação produzida em cada sessão e questionários de avaliação.




Elaboração da agenda JAD

� Identificar a finalidade e objetivos da sessão.

� Identificar produtos (resultados esperados).

� Identificar as informações conhecidas.

� Esboçar as etapas da agenda.

� Verificar coerência lógica das etapas.

� Identificar os participantes prováveis.

� Identificar as etapas que os participantes não tem condições de realizar na sessão.

� Identificar os dados prévios para as sessões.


Agenda padrão JAD� Introdução:

− Data, local, início e fim previstos

− Objetivos: Levantamento, acompanhamento, informativa, definição de tarefas, tomada de decisões, etc.

− Moderador, demais participantes e funções

− Atividades prévias

− Regras de conduta

� Abordagem da sessão:

− Desenvolvimento dos itens específicos da pauta

� Revisão

− Pendências

− Conclusões




Agenda padrão JAD - Introdução

� Revisão do JAD, papéis, horários, apresentação dos participantes e da agenda.

� Revisão da perspectiva gerencial: comentários sobre a definição da alta gerência.

� Abertura pelo executivo patrocinador: mostra o apoio da cúpula, importância, objetivos e motivo de escolha da equipe.

� Visão da área de Informática: questões tecnológicas e de andamento de projeto.

� Regras de conduta: comportamentos indicados para sessão.


Agenda padrão JAD – Abordagem da

sessão� Passos específicos para se alcançar os

objetivos da sessão.

− Finalidade

− Produto esperado

− Processo envolvido

− Sequência




Agenda padrão JAD – Revisão

� Revisão das pendências: situação do item,

responsável e data prevista para a solução.

� Revisão geral: rápida passagem pelo material

produzido para verificar se o resultado está coerente e

coeso, de acordo com o previsto.

� Avaliação da sessão: obtenção do feedback dos

participantes sobre o método utilizado e desempenho

do facilitador.


Considerações sobre o JAD� Enquanto técnica, o JAD propõe captar os pontos principais das demais técnicas visando tornar mais produtivas as reuniões.

� A estrutura do JAD pressupõe um trabalho considerável de documentação e atividades preliminares e posteriores.

� É óbvia a importância e uso de reuniões como mecanismos de interação entre pessoas em qualquer aspecto da sociedade.

� Para qualquer situação de reunião profissional pode ser seguido o modelo do JAD.




Exemplo de agenda JAD - Introdução� Explicação: serão explicados aspectos preliminares sobre a sessão (Duração: 10 Min.). Aspectos:

− Período: 1, 2 e 3/4 de 2009;

− Horário: 8h às 17h. Intervalo: 10h às 10h15, 15h30 às 15h45. Almoço: 12h às 13h.

− Recursos disponíveis: Projetor, computador, quadro magnético e flipchart.

− Apresentação dos participantes: Nicolau dos Santos (Executivo patrocinador), Philip Kotler (Gerente de Marketing), Bill Gates (Gerente de Informática), Domenico de Masi (Gerente de RH), José Silva

(Facilitador) e Sra. Maria Santos (Documentadora).


Exemplo de agenda JAD – Introdução

� Funcionamento do JAD: O Sr. José Silva fará uma explicação do JAD e suas principais características como trabalho em equipe, decisão por consenso, papel do facilitador, agenda, etc.

� Apresentação dos assuntos da agenda: Serão lidos os itens da Abordagem da Sessão.

� Revisão da perspectiva gerencial: Os participantes expressarão suas opiniões e sugestões. Duração 50 Min.





� Abertura pelo executivo patrocinador: O Sr. Nicolau dos Santos mostrará a importância do projeto no contexto do negócio, o que a administração pretende alcançar e por que aquela equipe foi escolhida. Duração: 15 Min.

� Visão da área de informática: O Sr. Bill Gates falará das atuais tecnologias e tendências no escopo do projeto. Duração: 20 Min.



� Regras de conduta: Serão explicadas as normas de comportamento a serem seguidas durante a sessão. São vedadas conversas em paralelo, utilização de telefone celular, interromper a fala de outro participante, fumar durante a sessão, críticas destrutivas ou pessoais a opinião de outros participantes. Duração 5 Min.

� Abordagem da sessão: Nesta etapa serão discutidos os assuntos específicos da sessão. Os assuntos serão divididos em seis etapas. Duração: 3:00 H.




Exemplo de agenda - Abordagem da sessão

� Tema 1: Descrição do ambiente atual

− Início: 8h. Duração: 1h.

− Finalidade: Descrever a situação atual e as áreas de negócios.

− Produto esperado: descrição da situação atual, incluindo: processos atuais (possibilidades, pontos fortes e fracos, restrições), situação competitiva e oportunidades para a organização.

− Processo envolvido: participantes deverão preencher previamente um questionário que será apresentado durante a sessão.

− Sequência: Discussão dos pontos apresentados, brainstorming, seguido de votação.



� Tema 2: Descrição dos problemas das áreas.

− Início: 10 H 15. Duração: 1 H 30.

− Finalidade: Apontar os principais erros existentes na

situação atual. Serão usados para definir e justificar

objetivos e soluções a serem adotadas.

− Produto esperado: descrição dos problemas atuais do

negócio.

− Processo envolvido: Idem tema 1.

− Sequência: Brainstorming, seguido de votação.





� Tema 3: Descrição dos objetivos para a nova situação.

− Início: 13 H. Duração: 1 H.

− Finalidade: Listar os objetivos a serem alcançados através de

modificações nas áreas de negócios. Os objetivos devem estar

associados a problemas encontrados na etapa anterior.

− Produto esperado: descrição de todos os objetivos.

− Processo envolvido: Idem ao tema 1.

− Sequência: Idem ao tema 2.



� Tema 4: Descrição dos requisitos.

− Início: 14h. Duração: 1 H 30.

− Finalidade: Definição das soluções (requisitos) para a nova

situação esperada. Define como serão alcançados os

objetivos.

− Produto esperado: descrição dos requisitos.







� Tema 5: Descrição das restrições para os requisitos.

− Início: 15 H 45. Duração: 30 Min.

− Finalidade: Definição de restrições de ordem física, política, legal, que possam afetar os requisitos estabelecidos. As restrições determinam limites, fronteiras e balizamentos para o sistema.

− Produto esperado: descrição das restrições.





� Tema 6: Prioridade dos requisitos.

− Início: 16 H 15. Duração: 30 Min.

− Finalidade: Dar prioridade aos requisitos.

− Produto esperado: Indicação da prioridade de cada requisito.

− Processo envolvido: através do estabelecimento dos critérios de prioridade como custo, competitividade, facilidade de implementação e posterior associação a cada requisito.

− Sequência: Descrição de cada item e votação.




Exemplo de agenda JAD - Revisão

� Revisão de pendências: Serão resolvidas as pendências e agendadas novas. Consiste em: Descrição da pendência, situação, responsável, data para solução. Duração 5 Min.

� Revisão geral: Será feita uma passagem pelo material produzido na sessão, avaliando os resultados obtidos. Duração 5 Min.

� Avaliação da sessão: Será obtido o feedback de todos os participantes sobre o método utilizado e sobre o comportamento do facilitador, visando adequar e melhorar o processo para as próximas sessões. Duração 5 Min.


Referências bibliográficas

� Costa, Wilson Dias Da - JAD Joint Application

Design, Ibpi Press, 1994.

� Gause, D. e Weinberg, G. Explorando

Requerimentos de Sistemas, Makron Books, 1989.


C4-Casos de uso 1






Versão 1.2

Casos de uso


Objetivos

� Descrever as dificuldades encontradas para se modelar sistemas com base somente emrequisitos.

� Mostrar como os casos de uso se encaixam namodelagem de comportamento dos sistemas.

� Especificar as diretrizes para a escrita de casosde uso efetivos.


C4-Casos de uso 2


Roteiro� Requisitos e casos de uso

� Definição de caso de uso

� Definição de ator

� Relacionamentos

� Diagrama de caso de uso

� Estrutura de um caso de uso

� Descrição de um caso de uso

� Processo de modelagem de casos de uso

� Diretrizes para elaboração de casos de uso


Interessados nos requisitos

� Clientes: Precisam saber se o sistema está sendodesenvolvido 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 sistemadeveria fazer para poder verifica-lo.


C4-Casos de uso 3


Natureza dos requisitos

Necessidades


Domínio dasolução

Requisitos de sistemas


Domínio do problema

Produto a ser construído


Separação entre domínios� A separação em domínios indica que os

requisitos de software tratam da solução e nãodo problema.

� O formato da pirâmide reflete o volume relativodo problema: poucas necessidades podem exigirvários requisitos.

� O relacionamento de rastreabilidade deve ser mantido entre todos os níveis.


C4-Casos de uso 4


Rastreabilidade dos requisitos

N1

Ru1 Ru2

Nx

Ruy

Rs1 Rs2 Rs3 Rsz

Rd1 Rd2 Rd3 Rd4 Rdn

P: Essa figura representa rastreabilidade uni ou bidirecional? ___________________


Limitações dos requisitos• Dados os requisitos de um caixa eletrônico:

– O sistema deve permitir clientes fazer saques de suas contas.

– O sistema deve assegurar que o limite da contanunca será ultrapassado.

– Se um cliente tentar sacar de um caixa que nãopertença a instituição em que tem conta, o sistemadeve cobrar uma taxa.

• Surgem as questões:– Em qual ordem essas coisas devem ser feitas

(caso a ordem importe)?– A taxa deve ser cobrada antes ou depois do

saque?


C4-Casos de uso 5


Limitações dos requisitos• Para um dado conjunto de requisitos, pode ser

praticamente impossível entender o que osautores dos requisitos querem que seja feito.

• Os requisitos normalmente são ambíguos e incompletos pois não informam quando e sob quais condições os comportamentos ocorrem.

• A seqüência é um requisito em certos casos.• Os requisitos tradicionais capturam abordagens,

com ênfase em requisitos declarativos e sentenças do tipo “deve”, falhando em capturar o comportamento dinâmico do sistema.

• Outra: ___________________________________


Modelagem de casos de uso

• Um caso de uso é uma forma de expressaros requisitos do sistema, especialmente seucomportamento.

• A idéia básica por trás da modelagem de um caso de uso é a seguinte:–Capturar a essência do que um sistema deve

fazer. Para tal, deve-se inicialmente observarquem irá usar o sistema.

–Depois disso, deve-se pensar no que o sistema deverá fazer para realizar o que o usuário necessita.


C4-Casos de uso 6


Casos de uso no contexto dos requisitos

Necessidades

Requisitos

funcionais

Requisitos

não funcionaisCasosde uso

Especificaçãosuplementar

Especificaçãosuplementar

P: Casos de uso são uma especificação completa de todos os requisitos? ___________


Casos de uso e requisitos� Um caso de uso contém a especificação de um

conjunto de requisitos, apresentados de forma narrativa ao invés de estrutura de tópicos ou outra(lembra dos fluxogramas?).

� Um caso de uso coloca os requisitos no contexto dadescrição de algo que o usuário deseja.

� A granularidade dos requisitos e dos casos de uso ébastante diferente. Explique: ___________________

� Casos de uso expressam comportamento: Quandobem escritos, os casos de uso especificamexatamente o que o sistema deve fazer.


C4-Casos de uso 7


Casos de uso e requisitos

� Casos de uso são uma boa técnica paramodelagem de requisitos. Eles provêm umamaneira padronizada de capturar, explorar e documentar o que um sistema deve fazer.

� Um caso de uso pode atender a vários requisitose um mesmo requisito pode ser atendido por um ou vários casos de uso. Dê um exemplo: ________________________________________

� Um requisito não é 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 usuário) conjuntos de requisitos funcionais, descrevendo o comportamento do sistema como uma interação entre usuários ououtros sistemas e o sistema em questão, para fazer algo útil, conforme seus interesses.

� Casos de uso não envolvem: interfaces externas, formatos de dados, regras de negócio e fórmulas, algumas vezes complexas.

� Requisitos não funcionais são melhor descritos usando textosdeclarativos ou meios visuais.

� Descrever requisitos não funcionais por meio de casos de uso éuma maneira de confundir ambos. Exemplo:

_______________________________________________________


C4-Casos de uso 8


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 provêm uma boa visãogeral sobre o sistema. Entretanto, a grande forçados casos de uso está em sua descrição textual,

que será vista mais à frente.


Representação de casos de uso� Um caso de uso descreve como um ator usa um

sistema para atingir um objetivo e o que o sistemafaz para o ator atingir seus objetivos.

� Descreve uma estória de como um sistema e seusatores colaboram para um dados objetivo.

� A UML representa casos de uso como elipses:


C4-Casos de uso 9


Atores

� “Conjunto coerente de papéis que os usuáriosexercem quando interagem com os casos de uso”. [OMG]

� Aspectos chave dos atores:

− Representam pessoas ou outros sistemas.

− Definem os papéis que os usuários ou outrossistemas exercem.

− Estão fora do sistema, e geralmente fora do controledo mesmo.

− Impõem requisitos que o sistema deve atender.


Representação de atores� Um ator define um papel que um usuário pode

exercer quando interage com o sistema. Um usuário ainda pode um indivíduo ou outrosistema.

� A UML representa atores como bonecos:


C4-Casos de uso 10


Stakeholders e atores

� Stakeholder é alguém ou algo que tem um interesse legal no comportamento do caso de uso. Obs: conceito análogo à GP.

� Um ator é qualquer coisa que tem um comportamento. Um ator pode ser uma pessoa, companhia ou organização, um programa de computador ou um sistema computacional

� Todo ator primário, é naturalmente, um stakeholder, mas alguns stakeholders nuncainteragem diretamente com o sistema.


Ator primário� É o stakeholder que chama o sistema para entregar um

de seus serviços. Ele tem um objetivo com respeito aosistema - que pode ser satisfeito por sua operação.

� Geralmente o caso de uso começa porque o atorprimário envia uma mensagem, pressiona um botão, pressiona uma tecla ou de alguma outra forma inicia a estória.

� Entretanto, há pelo menos duas situações em que um UC não é iniciado por um ator primário:

− Quando, por exemplo, um operador de telefone inicia o casode uso em nome de um cliente.

− Quando o caso de uso é acionado pelo ator “tempo”.


C4-Casos de uso 11


Atores secundários

� Atores externos que provêm um serviço aosistema.

� Devem ser identificados a fim de achar as interfaces externas que o sistema usará e osprotocolos que cruzam essas interfaces.

� Um ator pode ser primário em um caso de uso e secundário em outro. Exemplo:

_________________________________________


Comunicação entre ator e caso de uso

� Razões 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.

� Razões para o caso de uso acionar o ator:

− Informar ao ator se algo importante aconteceu com o sistema.

− Pedir apoio para tomada de alguma decisão.

− Delegar responsabilidades a atores.


C4-Casos de uso 12


Relacionamentos

� Casos de uso e atores não existem sozinhos.

� A UML define diversos de relacionamentos no modelo de casos de uso:

− Comunicação: Interação direta entre ator e caso de uso. É a situação mais comum.

− Inclusão: Provê a habilidade de extrair seções comunsentre dois ou mais casos de uso e coloca-las em um casode uso separado, favorecendo o reuso.

− Extensão: Usado em casos onde um comportamentoopcional ou excepcional é inserido em um caso de usoexistente.

− Generalização: Usado quando elementos possuemcomportamentos em comum. Ex: atores.


Diagramas do modelo de caso de uso

• Diagrama com uma visão geral com principaisatores e casos de uso. Também chamado, poralguns autores, “Diagrama de Contexto”.

• Diagrama somente com atores correlatos.

• Diagrama da perspectiva de um único ator, mostrando casos de uso e demais atores a eleassociados.

• Diagramas somente com casos de uso correlatos.

• Diagramas da perspectiva de um único caso de uso, mostrando atores e demais casos de uso a eleassociados.


C4-Casos de uso 13


Exemplo de diagrama de caso de uso

Detalhar pagamento

Fazer pagamento com

dinheiro

Fazer pagamento com

cheque


Descrição de Casos de Uso� “Descrição de um conjunto de seqüências de

ações, incluindo variações, que um sistemaexecuta para atingir um resultado de valorobservável 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 colaborampara atender o objetivo do ator.

− Provê uma imagem coerente de como o sistema seráusado.


C4-Casos de uso 14


Descrição de um caso de uso

� A UML define que os casos de uso possuem doiselementos de modelagem: uma representação gráfica e uma descrição textual.

� Entretanto, não é definido um padrão para a descrição

textual de um caso de uso.

� Portanto, a descrição de um caso de uso pode variardesde um texto livre com alguns parágrafos até umaestrutura de dados com campos bem delimitados.

� Há vantagens e desvantagens em ambas abordagens. Ex:

− Vantagem: __________________________________________

− Desvantagem: _______________________________________


Estrutura geral de um caso de uso

� Identificação

− Nome

� Descrição

− Pré-condições

− Pós-condições

− Fluxo de eventos

� Fluxo principal (mais comum)

� Fluxos alternativos

� Fluxos de exceção

� Sub-fluxos (deve-se evitar)


C4-Casos de uso 15


Estrutura de um caso de uso� Nome: Deve ser único e identificar o que é atingido

através da interação entre o caso de uso e o ator.

� Descrição:

− Pré-condições: Descrição textual que define restriçõesquando o caso de uso deve iniciar.

− Pós-condições: Descrição textual que define restriçõesquando o caso de uso termina.

− Fluxo de eventos: Descrição textual do que o sistema fazem relação ao caso de uso. É estruturado em:

� Fluxo principal: Fluxo principal ou padrão.

� Fluxos alternativos: Fluxos com cenários alternativos ao principal.

� Sub-fluxos: Subdivisão de um fluxo para fins de clareza. EVITAR!


Descrição de um caso de uso

� A descrição de um caso de uso narra uma estória de como o sistema e seus atores colaboram para atingir um objetivo específico.

� É uma descrição 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:

− Início (como o ator inicia o caso);

− Meio (como sistema e atores interagem);

− Fim (como o caso de uso é encerrado).


C4-Casos de uso 16


Importância da descrição textual

� Cerca de 90% do modelo de caso de uso reside nas descrições. Portanto, é a parte maistrabalhosa de se modelar.

� A parte mais importante de um caso de uso é a descrição.

� A parte mais importante da descrição é o fluxo de eventos.

� O fluxo de eventos tem uma estrutura bemdefinida, baseada nos conceitos dos fluxosprincipal, alternativos e de exceção.


Cenários (fluxos) e passos� Um conjunto de casos de uso é uma estória já

desdobrada de atores primários perseguindoobjetivos. Cada caso de uso tem um enredocruzado e mostra o sistema alcançando o objetivoou o abandonando. É um descrição “teatral”.

� Esse enredo está presente na forma de um cenáriobásico e um conjunto de fragmentos de cenários, como extensões dele.

� Cada cenário ou fragmento começa com umacondição de acionamento que indica quando ele éexecutado e vai até mostrar a conclusão ou o abandono de seu objetivo.


C4-Casos de uso 17


Estrutura típica de fluxo de eventos

Fluxo principal

Fluxo alternativo

Fluxo alternativo


Fluxo principal

� Descrição, de cima para baixo, de um cenáriobastante característico no qual o objetivo do atorprimário é alcançado e todos interesses dos stakeholders são satisfeitos.

� O fluxo principal descreve a forma mais usual (padrão) de se atingir os objetivos do atorprincipal.

� Todas as outras maneiras de ter sucesso e o tratamento de todas as falhas, são descritos nasextensões do fluxo principal nos fluxos alternativose de exceção.


C4-Casos de uso 18


Organização de cenários

� Fluxos alternativos estendem o fluxo principal para tratar as variações e exceções.

� Sub-fluxos podem ser usados para facilitar a leitura de um fluxocomplexo. Pode ser substituído por outro caso de uso.

� Pré e pós condições podem ser usadas para melhor esclarecer o escopo de um caso de uso e documentar qualquer premissa feitaa respeito do estado do sistema (antes ou depois do UC). Pré-condições são mais comuns que pós-condições.

� A descrição deve ser longa o suficiente para poder descrever a estória e simples o suficiente para não dificultar os trabalhos nemtornar o modelo complexo. Deve-se utilizar linguagem clara e objetiva.


Estrutura comum aos fluxos� Uma condição sob a qual o cenário é executado: para o

cenário principal é a pré condição mais o acionador. Para um cenário de extensão, é a condição de extensão.

� Um objetivo a alcançar: para o principal, é o nome do caso de uso. Para um cenário de extensão, o objetivo é completar o caso de uso ou ingressar no cenário de sucesso.

� Um conjunto de passos de ação: formam o corpo do cenário e seguem as mesmas regras em todo cenário ou fragmento de cenário.

� Uma condição de fim: objetivo atingido ou abandonado.

� Um possível conjunto de extensões escritas como fragmentosde cenário.


C4-Casos de uso 19


Condições de extensão� São as condições sob as quais o sistema tem um comportamento

diferente (fluxos alternativos e/ou exceção).

� Exemplo:

...

“4. Usuário solicita salvamento do arquivo”

...

� Extensões:

“4a. Sistema detecta a necessidade de salvamento”

“4a1. ...” (passos)

“4b. Salvamento falha”

“4b1. ...” (passos)


Condições de extensão - exceção� A condição deve dizer o problema detectado.

Exemplos:

− “Senha inválida”.

− “Rede inoperante”.

− “Cliente não responde”.

− “Dinheiro indisponível”.

Obs: não “levantar” códigos de erro internos.

� Racionalize e reúna as falhas similares, de modo a simplificar a análise.

� Avalie as condições de falhas dentro de falhas.


C4-Casos de uso 20


Exemplo de descrição de caso de usoNome: Registrar sinistro.Ator primário: Atendente.Pré-condição: Segurado e apólice habilitados.

Fluxo principal:1. Atendente informa número da apólice do segurado. 2. Sistema retorna informações da apólice. 3. Atendente confirma dados do segurado.4. Sistema confirma que não há nenhum sinistro em aberto para o segurado.5. Atendente informa detalhes do sinistro: tipo, local, data, hora, descrição.6. Sistema valida os dados informados e gera número (sequencial no ano) da

comunicação.7. Atendente informa número da comunicação ao segurado8. Atendente designa um agente para o atendimento.9. Sistema solicita confirmação para fechamento da comunicação.10. Atendente confirma operação.10. Sistema salva os dados e envia e_mail para o agente designado.


Exemplo de descrição de caso de uso(cont.)

Fluxos alternativos:

FA1. Atendente informa que ligação é somente para consulta.

1. Sistema registra informação.

FA2. Atendente pode salvar os dados incompletos a qualquermomento, antes da conclusão do UC.

1. Registrar comunicação com status “Pendente”.

FA3. Atendente altera informações da apólice ou data do sinistro.

1. Sistema valida informações e verifica se apólice está disponível.

1. Atendente informa código da apólice ou CPF/CGC ou nome do segurado.

2. Sistema edita apólice a partir dos dados da pesquisa.

(E se não encontrar? _______________________________________________)

3. Atendente altera data ou outros dados do sinistro.


C4-Casos de uso 21


Exemplo de descrição de caso de usoFluxos de exceção:

FE1. Informação de apólice encontrada não corresponde ao segurado:

1. Atendente informa número correto de apólice.

FE2. Sistema não encontra apólice, a partir de detalhes:

1. Atendente informa detalhes corretos.

FE3. Sistema identifica comunicação duplicada:

1. Sistema exibe lista de comunicações existentes.

2. Atendente seleciona uma comunicação.

2a. Atendente edita comunicação.

FE4. Atendente termina sem completar informações obrigatórias.

1. Sistema informa que transação não pode ser concluída.


Processo de modelagem de casos de uso


C4-Casos de uso 22


Estágios de escrita dos casos de usoEstágio de escrita Propósito principal Riscos atacados Atividades associadas

Descoberta Identificar caso de uso Desconhecer limites do sistema

Gerenciamento de escopo

Breve descrição Resumir propósito do caso de uso

Ambiguidade na definição do modelo

Gerenciamento de escopo

Esboço inicial Resumir formato e extensão do caso de uso

-Desconhecer extensão, escala ou complexidade do sistema-Desconhecer casos de uso requeridos

-Gerenciamento de escopo-Estimativa inicial-Prototipagem visando atender requisitos e atacar riscos tecnológicos

Esboço essencial Resumir essência do caso de uso

Facilidade de uso -Desenho de interface com usuário-Prototipagem visando atender requisitos e atacar riscos tecnológicos

Descrição detalhada

Permitir adicionar detalhes de forma incremental

Nenhum (passo intermediário)

Nenhum (passo intermediário)

Descrição completa Prover completa especificação funcional para o comportamento encapsulado pelo caso de uso

-Não saber exatamente o que o sistema deve fazer-Não ter uma especificação de requisitos compartilhada

-Análise e desenho-Implementação-Testes de integração-Testes de sistema-Documentação de usuário-Estimativa refinada


Caso de uso e as disciplinas do RUP� Requisitos: O modelo de caso de uso é construído

nessa disciplina.

� Análise e desenho: Casos de uso são realizados pelosmodelos de análise e desenho. Aqui é descrito comoos objetos se relacionam para atingir o objetivo do caso de uso.

� Implementação: O código é desenvolvido paraexecutar os casos de uso.

� Testes: Os casos de uso servem de base paraidentificar os casos de teste e procedimentosespecíficos.


C4-Casos de uso 23


Relacionamento entre o modelo de casos de uso e outros modelos

Expresso por

Realizado por

Implementado por

Verificado por


Ciclo de escrita de caso de uso

� Especifique o escopo e os limites do sistema.

� Identifique os atores primários.

� Identifique os objetivos dos usuários 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 exceção;

− Escreva os passos de tratamento de extensão;

− Extraia os fluxos complexos para subcasos de uso.

� Reajuste o conjunto: adicione, subtraia e junte casos de uso conforme necessário, iterativamente.


C4-Casos de uso 24



� 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.


C5-Modelagem casos de uso 1






Versão 1.2

Modelagem de casos de uso


Objetivos� Descrever as dificuldades encontradas para se modelar sistemas com base somente emrequisitos.

� Mostrar como os casos de uso se encaixam namodelagem de comportamento dos sistemas.

� Especificar as diretrizes para a escrita de casosde uso efetivos.




Roteiro� Estrutura de um caso de uso

� Descrição de um caso de uso

� Processo de modelagem de casos de uso

� Diretrizes para elaboração de casos de uso


Identificação de atores

� Inicie identificando os atores principais (usuários).

� Trabalhe do específico para o geral.

� Não esqueça os atores de apoio.

� Considere todas as informações sobre requisitos.

� Lembre-se que atores nem sempre são pessoas.

� Observe os limites (escopo) do sistema.

� Identifique as fontes de informação.




Identificação de atores� Não confunda atores com os dispositivos de E/S. Ex: terminal de auto atendimento.

� Não confunda atores com papéis da organização outítulos de emprego. Ex: gerente, superintendente.

� Não generalize em excesso. Ex: ________________

� Caracterize os atores e crie uma descrição breve de cada ator. Faça isto na lista de atores.

� Associe os atores aos tipos de usuários, stakeholderse papéis destes. Ex: ___________________________


Questões para identificar atores

� Quem irá utilizar o sistema?

� Quem irá fornecer, receber ou remover informação?

� Quem está interessado em determinado requisito?

� Quais outros sistemas devem interagir com este?

� Quais são os recursos externos ao sistema?

� Quem inicia o sistema (interação)?

� Quem irá manter o sistema?

� Existe algum ator disparado por evento ou tempo?




Lista de atores� Nome e breve descrição.

� Escopo (responsabilidades).

� Ambiente físico de uso do sistema.

� Quantidade e tipo de usuários representados peloator (para dimensionamento da rede).

� Freqüência de uso (para dimensionamento da rede).

� Níveis de conhecimento sobre negócio e tecnologia.

� Faixa etária.

� Etc: _______________________________________


Localização dos casos de uso

� Inicie identificando as metas dos atores.

� Considere as necessidades de informação do usuário e sistema.

� Não confunda caso de uso com função. Umafunção pode corresponder a vários casos de uso e vice-versa.

� Não se esqueça dos casos de uso de apoio e operacionais. Ex: ________________________




Questões para identificar casos de uso� Para cada ator quais são as necessidades (objetivos) que o sistema deve atender?

� O ator deverá informar ao sistema que tipo de mudanças de estado / situações?

� Quais casos de uso irão iniciar, parar, configurar, apoiar e manter o sistema?

� Sobre quais eventos o sistema deve ser informado?

� Sobre quais ocorrências 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 são trocados entre ator e caso de uso. É preferível descrever grupos de dados a itenselementares.

� Não descrever detalhes de interface com o usuário a menosque seja necessário para entender o comportamento do sistema. Ex: não descrever que tipo de botão será utilizado.

� Descrever o fluxo de eventos, não somente a funcionalidade.

� Iniciar o fluxo com o ator (mais comum) ou o sistema.

� Descrever somente os eventos que pertençam ao caso de uso em questão.




Diretrizes para elaborar fluxos

� Descrever o que o sistema faz e não como é projetado.

� Detalhar o fluxo de eventos, respondendo a todas as perguntas, principalmente para os testes (que terão por base o UC).

� Utilizar vocabulário simples, na medida do possível.

� Escrever sentenças curtas e frases diretas.

� Evitar advérbios como “muito”, “mais”, “ao invés”, etc.

� Evitar terminologia vaga como “informação”, “relevante”, “suficiente”, etc.

� Utilizar pontuação correta.

� Deixar clara a seqüência de eventos.

� Destacar termos que se encontram no glossário (jargão técnico).


Diretrizes para escrever passos

� Utilizar estrutura gramatical simples: Sujeito + verbo + objeto direto + preposição.

“Sistema deduz a quantia do saldo da conta”

� Mostrar claramente quem comanda a ação:

“Pessoa1 … Pessoa2” ou “Pessoa1 … Sistema”

� Escrever com uma visão geral:

− Errado:“Pegar cartão e senha. Deduzir quantia do saldo.”

− Certo: “Cliente insere cartão e senha.”“Sistema deduz quantia do saldo da conta.”




Diretrizes para escrever passos� Descrever o objetivo do passo, evitando passos muito curtos

− Errado:“Usuário pressiona a tecla Tab” (Com qual objetivo?...)− Certo:“Usuário informa nome e endereço”

� Mostrar a interação entre atores, não os movimentos:

− Errado: “Sistema pergunta nome.”“Usuário informa nome.”“Sistema pergunta endereço.”“Usuário informa endereço.”“Usuário pressiona OK.”“Sistema apresenta perfil do usuário.”

− Certo:“Usuário informa nome e endereço.”“Sistema apresenta perfil do usuário.”

Excesso de detalhes!


Diretrizes para escrever passos� Pensar em um passo como representando uma transação. Sigaa estrutura:

− Ator primário envia solicitação e dados ao sistema.

− Sistema valida solicitação e dados.

− Sistema altera seu estado interno.

− Sistema fornece resultado.

� Preferir “Valida” ao invés de “Verifica”, em ações de validação:

− Errado:

“Sistema verifica se senha está correta”.

“Se está, sistema apresenta ações disponíveis”.

− Certo:

“Sistema valida senha”.

“Sistema apresenta ações disponíveis”.




Diretrizes para escrever casos de uso

� Priorizar comunicação efetiva entre todos interessados.

� Perseguir a simplicidade ao escrever casos de uso.

� Lembrar-se que a audiência dos casos de uso são osusuários, que devem ser capaz de entendê-los.

� “O bom é inimigo do ótimo”. Não existe perfeição naescrita de casos de uso.


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 descrição.

� Delimitar bem os casos de uso (escopo), dentro do devidodomínio (nível de detalhe).

� Associar casos de uso aos interessados e aos papéis dos interessados.

� Associar os casos de uso aos requisitos e restrições.




Alguns erros comuns…� Cenário sem sistema

1. Cliente passa cartão e informa senha.

2. Cliente seleciona Saque e informa valor.

3. Cliente apanha dinheiro.

4. Cliente desconecta.

� Cenário sem ator primário

1. Coleta cartão e senha.

2. Coleta transação 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 endereço e clica em OK.

� Nível de objetivos muito baixo:

1. Usuário acessa sistema com ID e senha.

2. Sistema valida usuário.

3. Usuário fornece nome.

4. Usuário fornece endereço.

5. Usuário seleciona produto.

6. Sistema abre conexão com sistema de depósito.

7. Sistema de depósito retorna estoque atual.




Questões frequentes� Número excessivo de casos de uso.

Solução: _________________________________________________________

� Casos de uso CRUD.

Solução: _________________________________________________________

� Casos de uso excessivamente complexos.

Solução: _________________________________________________________

� Casos de uso que usuários não entendem.

Solução: _________________________________________________________

� Novos processos de negócio.

Solução: _________________________________________________________

� Uso excessivo de relacionamentos include e extend.

Solução: _________________________________________________________


Número excessivo de casos de uso

� Torna-se difícil o preenchimento de cada caso de em um nível adequado de abstração quando se tem um númeroexcessivo de casos de uso.

� Evite criar um caso de uso para cada cenário possível. Ao invés disso, inclua os fluxos normal, alternativos e exceções em um único caso de uso.

� Tipicamente, há muito mais casos de uso do querequisitos de negócio e mais requisitos funcionais do que casos de uso.




Casos de uso CRUD� Por princípio, 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 número de casos de uso e o trabalho.

� Separe o caso de uso Gerenciar <item> somente se a complexidade assim exigir.

� Outra diretriz é avaliar o nível de acesso a uma funcionalidade. Assim, o caso de uso Gerenciar <item> pode ser divididoconforme o nível de acesso ou a informação relativa pode ficarem outro local, associado ao caso de uso. Esta situação ocorrecom frequência com relação à consulta.


Casos de uso excessivamente complexos

• Escreva os casos de uso em função da essência dos comportamentos dos atores e do sistema, ao invés de especificar cada ação em detalhes.

• Selecione um caminho de sucesso e derive dele várioscaminhos simples como alternativos e exceção.

• Tipicamente os fluxos alternativos e de exceção são maiscurtos e simples do que o fluxo principal.

• Deixe as definições de dados para o dicionário de dados e não para os casos de uso.




Casos de uso que os usuários não entendem

� Se os usuários não conseguem relatar a descrição de seus processos de negócio ou tarefas do sistema, háalgo de errado com os casos de uso.

� Escreva casos de uso da perspectiva do usuário e nãodo sistema. Peça aos usuários para revê-los.

� Nem sempre os casos de uso "full dressed“(exaustivos) são os mais indicados. Procure ser prático.


Novos processos de negócio

� Usuários poderão ter dificuldade em lidar com casos de uso se o software serve a um processo que não existeou está sendo alterado.

� Avalie a possibilidade de realizar a modelagem de processos de negócio antes de iniciar a modelagem de casos de uso.

Problema: PSP não aborda modelagem de negócio!

� Em última instância, elabore um ou mais diagramas de atividade com a visão de processos e associe os casosde uso as atividades dos diagramas.




Uso excessivo de relacionamentosinclude e extend

� Inclusão e extensão são situações particulares, em que se destaca um “pedaço” do UC.

� Ao se trabalhar com casos de uso pela primeira vez é necessárioadotar uma mudança na forma como analistas, usuários e desenvolvedores pensam sobre requisitos.

� Casos de uso não representam fluxos!Muitos problemassurgem ao compará-los com outras técnicas do paradigmaestruturado.

� Esses elementos podem acrescentar uma complexidadedesnecessária para entendimento dos casos de uso.

� Devem ser utilizados com parcimônia.


Tratamento de detalhes

� Utilize o glossário e o modelo de domínio para capturardefinições.

� Use o modelo de domínio para capturar detalhes no glossário.

� Capture regras de negócio no modelo de domínio.

� Use sub-fluxos somente para simplificar descriçõescomplexas. Em excesso, atrapalha a legibilidade.

� Use fluxos alternativos para capturar comportamentocomplexo e não usual.





� Glossário: O problema do domínio é descrito através de um conjunto simples de definições. Deve haver consenso a respeito(envolver o usuário).

� Modelo de domínio: Construído através de diagramas de classeUML, a partir dos termos-chave do glossário. É particularmenteimportante se há relacionamentos complexos entre os objetos do domínio do problema.

� Especificação suplementar: Requisitos que não são claramentecapturados diretamente nos casos de uso ou interferem na clarezado fluxo (tipicamente regras de negócio e requisitos nãofuncionais).



� Detalhes de informações: Uma informação descrita em um caso de uso pode ser composta por mais de um atributoou campo. Geralmente pode-se trata-la em grupo.

� Listas de campos ou descrições de dados: Cada atributopossui nomes específicos que serão usados internamentepelas classes. Deve haver um mapeamento de atributos.

� Detalhes de campos e verificações: Validações e detalhesespecíficos como tamanho, tipo, máscara de edição. Devem constar do dicionário de dados.

� Esses itens deve fazer parte do caso de uso. As especificações devem constar de um documento a parte que posteriormente será associado ao caso de uso.




Exemplo de modelo de domínio


Exemplo de glossário� Pedido: Um contrato entre a companhia e um cliente paraprover algum conjunto de itens para uma localização emparticular de um cliente. Contém número e datas de pedido, envio e entrega.

� Item: Especifica a quantidade de um produto emparticular sendo pedido. Um item consiste da quantidadede produto pedido, quantidade fornecida e o produto.

� Cliente: Alguém que solicita produtos. Possui um nomee detalhes de contato.

� Produto: Alguma coisa que pode ser vendida a um cliente. A definição de um produto inclui descrição, número e preço unitário





� 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.

Documents

Apostila Psp Requisitos v1.2