1
PROCESSO DE REQUISITOS
Criação do documento de requisitos de software
Meta desta etapa!
Apresentar modelos de Documento de
Requisitos
Diferenciar Requisitos, Gerenciamento
e Engenharia de Requisitos
Apresentar o Processo de Engenharia de
Requisitos
Documento de requisitos de software
• O documento de requisitos de software é a declaração oficial do que é demandado dos desenvolvedores do sistema.
• Deve incluir ambas, uma definição de requisitos do usuário e uma especificação de requisitos do sistema.
• NÃO é um documento de projeto. Na medida do possível, deve definir O QUE o sistema deve fazer ao invés de COMO deve fazê-lo.
•
Muitos métodos ágeis argumentam que a produção de um documento de requisitos é um desperdício de tempo pois esses mudam rapidamente.
•
Portanto, o documento estará sempre desatualizado.
•
Métodos ágeis, tais como XP usam a engenharia de requisitos incrementais e expressam os requisitos como “estórias de usuário".
•
O que é prático para os sistemas de negócios, mas problemático para sistemas que exigem várias análises pré- entrega (por exemplo, sistemas críticos) ou sistemas desenvolvidos por várias equipes.
Requisitos e Métodos ágeis
3
Usuários de um documento de requisitos
Usuários de um documento de requisitos
•
As informações no documento de requisitos dependem do tipo de sistema e da abordagem de desenvolvimento usada.
•
Normalmente, os sistemas desenvolvidos de forma incremental terão menos detalhes no documento de requisitos.
•
Os padrões dos documentos de requisitos foram concebidos, tendo como exemplo, a norma IEEE.
•
Esses são aplicáveis, principalmente, aos requisitos para projetos de engenharia de sistemas de grande porte.
Variabilidade do documento de requisitos
A estrutura de um documento de requisitos
5
A estrutura de um documento de requisitos
Modelos de Documentos de Requisitos
•
Capa
•
Histórico de Revisão
•
Sumário
•
Introdução
•
Objetivo
•
Escopo
•
Glossário
•
Requisitos Funcionais
•
Requisitos Não Funcionais
•
Diagrama de Casos de Uso
•
Outros Diagramas
•
Especificação de Caso de Uso
•
Matriz de Rastreabilidade
Fundamentos de Requisitos – (conceitos)
• Definem o que é solicitado ao sistema fazer
• Com quais limitações o sistema deve operar
Requisitos
• Mudanças que ocorrem nos requisitos já acordados;
• Relacionamentos entre os requisitos;
• Dependências entre os documentos de requisitos e outros documentos
Gerenciamento de Requisitos
• Métodos, técnicas e ferramentas que auxiliam o processo de descoberta, documentação e gestão dos requisitos que o software deve atender
Engenharia de Requisitos
Na prática!
O Sistema que queremos deve fazer isto, isto ..., e nesse caso também isto
Sim, sim, estou anotando.
Pode continuar...o que
mais você quer?
7
Na prática!
Conversei com os usuários e basicamente este é o sistema que teremos que desenvolver
Ótimo, começaremos a especificar os requisitos agora mesmo!!!
Na prática! MESES DEPOIS...
Sr. Usuário, após o emprego das mais modernas técnicas de especificação,
produzimos este documento que descreve
minuciosamente o sistema
Ótimo... 150 páginas. Tudo
isso? OK, vamos analisar
e o mais breve possível
voltamos a conversar
Na prática! 5 SEMANAS DEPOIS...
Sr. Analista, nosso pessoal analisou com cuidado o documento. Tivemos muita dificuldade e dúvidas em entendê-lo. Mas o que percebemos é que NÃO FOMOS CORRETAMENTE ENTENDIDOS!!!
Como não? Tudo que aí está, foi fruto de nosso entendimento pessoal.
REALMENTE VOCÊS NÃO SABEM O QUE QUEREM!!!
Discussão...
1. Quais erros podemos apontar na história anterior?
2. Como minimizar estes erros?
9
Desafio é Transformar...
• Analista de Requisitos de Software
Requisitos de propriedades
do domínio
Especificação
Programa de Computadores
Com isso! - É FUNDAMENTAL:
Processo de Engenharia de Requisitos Informações de
sistemas existentes
Necessidades das partes envolvidas
Padrões organizacionais
Regulamentações
Informações sobre Domínio
Especificação de requisitos
Modelos
Processo de Engenharia de Requisitos Informações de
sistemas existentes
Necessidades das partes envolvidas
Padrões organizacionais
Regulamentações
Informações sobre Domínio
Especificação de requisitos
Modelos
Entradas Processamento Saídas
11
Processo de Requisitos
•
1. Processo de requisitos variam nas empresas
• Maturidade Técnica
• Cultura Organizacional
• Domínio de aplicação
•
2. Não existe um processo ideal
•
3. Objetivos do processo de requisitos
• Estabelecer e manter concordância com os stakeholders
• Oferecer uma compreensão melhor dos requisitos do sistema
• Definir as fronteiras do sistema
• Fornecer uma base para estimar o custo e tempo
• Definir uma interface de usuário para o sistema
Processo de Engenharia de Requisitos
Processo de Requisitos
• Entradas
• Entradas
• Informação sobre os requisitos dos softwares a serem substituídos, ou de outros software que interagem com o sistema que está sendo Especificado
Informações de sistemas
existentes
• Descrições do que os stakeholders precisam do sistema
Necessidades das partes envolvidas
Proces so de Engenharia de Re quisit o s
Processo de Requisitos
• Entradas
13
Processo de Requisitos
• Entradas
• Tanto os padrões utilizados na organização relacionados com práticas de desenvolvimento, qualidade etc...
como com o ambiente organizacional
Padrões organizacionais
• Leis, regulamentações externas, como de saúde, ambiental, de segurança e que se aplicam ao sistema
Regulamentações
• Informações gerais sobre domínio de aplicação do sistema
Informações sobre o Domínio
Proces so de Engenhari a de Re quisit o s
Processo de Requisitos
• Saídas
Discursão
•
Verdadeiro ou Falso
• O ideal é só conversar com o usuário no início e no final do processo de requisitos
• É adequado realizar validações parciais nos requisitos
• Quanto mais tarde no processo de desenvolvimento for descoberto um erro mais barato será a sua correção
• Informações de softwares que interagem com o sistema que está sendo especificado são entradas do processo de requisitos
PROCESSO DE REQUISITOS - Stakeholders
•
Processo de requisitos de software
• É um processo interdisciplinar...
• As pessoas envolvidas no processo de Engenharia de Requisitos possuem backgrounds diferentes
•
O que é mesmo um stakeholder?
• São todas as pessoas afetadas direta ou indiretamente pelo sistema.
• Por exemplo, quem tem conta corrente é stakeholder de um sistema desenvolvido pelo Banco Central do Brasil e que permite o bloqueio de contas pela internet, à disposição dos juízes (BacenJud)
• Para cada sistema temos uma variedade enorme de stakeholders, com diferentes perfis e backgrounds
• O que acaba por dificultar o processo de requisitos
15
PROCESSO DE REQUISITOS - Stakeholders
•
Exemplo de stakeholders?
• Engenheiros de software responsáveis pelo desenvolvimento (Responsáveis pelo desenvolvimento)
• Usuários finais do sistema (Utilização direta)
• Clientes ou patrocinadores ($$)
• Os fiscais que verificaram se o sistema satisfaz os requisitos legais
• Especialistas de domínio (Quem realmente entende!)
É muito importante correta identificação do conjunto dos stakeholders
PROCESSO DE REQUISITOS - Atividades
ELICITAÇÃO DE REQUISITOS
•
Vamos olhar agora especificamente a Elicitação de Requisitos
O processo de Requisitos
ELICITAÇÃO DE REQUISITOS
•
Consiste em:
• Descobrir
• Explicitar
•
Obter o máximo de informações para o entendimento do objeto em questão
•
Refere-se ao processo de extração de informação sobre a(s) funcionalidade(s) requisitada(s) e outras propriedades do sistema
•
“É o primeiro estágio na construção e entendimento do
problema (correto e completo!!) que o software deve
resolver” [SWEBOK]
17
ELICITAÇÃO DE REQUISITOS
• Elicitação FAZ
•
Identificação de fontes de informação
•
Comunicação
•
Coleta
• Elicitação USA
•
Pessoal
•
Métodos
•
Ferramentas
• Elicitação DEPENDE DE
•
Pontos de Vista
ELICITAÇÃO DE REQUISITOS
•
Processo de Elicitação de Requisitos
ELICITAÇÃO DE REQUISITOS - Processo
•
Processo de Elicitação de Requisitos
•
Definir Objetivos
• objetivos gerais do negócio
• descrição geral do problema a ser resolvido
• por que o sistema é necessário
• limitações do sistema
ELICITAÇÃO DE REQUISITOS - Processo
•
Processo de Elicitação de Requisitos
•
Adquirir Conhecimento do Background
• informações sobre a organização onde o sistema será instalado,
• o domínio de aplicação do sistema,
• informações de outros sistemas existentes
19
ELICITAÇÃO DE REQUISITOS - Processo
•
Processo de Elicitação de Requisitos
•
Organizar o conhecimento
• O conhecimento coletado deve ser organizado
ELICITAÇÃO DE REQUISITOS - Processo
•
Processo de Elicitação de Requisitos
•
Coletar requisitos
• Os stakeholders do sistema devem ser consultados para a descoberta de seus requisitos
• Técnicas de elicitação
ELICITAÇÃO DE REQUISITOS - Processo
•
Coleta de fatos
•
Leitura de documentos
•
Observação
•
Entrevistas
•
Reuniões
•
Questionários
•
Antropologia
•
Participação ativa dos atores
•
Bases de Requisitos não funcionais
•
Engenharia Reversa
•
Reutilização
ELICITAÇÃO DE REQUISITOS - Processo
• Técnicas de elicitação de requisitos
• Utilizadas para extrair informações
•
Área delicada: nem sempre o usuário consegue exprimir suas necessidades, tarefas, etc.
• As técnicas são complementares entre si
• Servem para estruturar “conversas”
•
O objetivo maior é extrair informação , seja uma
ou outra técnica sendo utilizada
21
ELICITAÇÃO DE REQUISITOS - Processo
• Técnicas de elicitação de requisitos
•
Entrevistas
• O analista conversa com com diferentes stakeholders para obter um entendimento dos requisitos
• Conduzir entrevistas com um grupo restrito de stakeholders.
• Lista de perguntas elaboradas para se obter uma compreensão dos problemas reais e das possíveis soluções.
•
Leitura de Documentos
• O analista busca documentação que possa dar suporte ao entendimento e extração dos requisitos
•
Questionários
• Pode funcionar como uma pesquisa qualitativa
• Permite análises estatísticas
ELICITAÇÃO DE REQUISITOS - Processo
• Técnicas de elicitação de requisitos
•
Prototipação
• Uma abordagem valiosa para clarear requisitos.
• Levam os usuário a um contexto onde conseguem entender melhor quais informações eles precisam prover
• Geralmente, mais adequado do que apresentar documentos de texto
•
Workshops, reuniões facilitadas
• Trabalhar com grupos pode agregar mais do que trabalhar individualmente
• Bom porque conflitos nos requisitos surgem antecipadamente
• Uso da técnica de brainstorming, para em seguida o facilitador conduzir o grupo na organização.
ELICITAÇÃO DE REQUISITOS - Processo
• Técnicas de elicitação de requisitos
•
Cenários
• Busca uma sequência específica de ações que ilustra comportamentos
• O mais comum tipo de cenário é o caso de uso (descrição de comportamento do sistema em termos de sequências de ações)
•
Existem diversas outras técnicas...
• Entender necessidades produzir requisitos
Discussão...
• Sobre Processo de requisitos
• Associação de Colunas
( a) Modelos ( , ) Entrada
( b) Elicitação ( , ) Saída
( c) Necessidades das partes envolvidas ( , ) NDR ( d) Entrevistas
( e) Especificação de requisitos
( f) Padrões organizacionais
23
Brainstorming
• Brainstorming é uma dinâmica de grupo em que as pessoas, de forma organizada e com oportunidades iguais, fazem um grande esforço mental para opinar sobre determinado assunto.
• A técnica de brainstorming tem várias aplicações:
• Desenvolvimento de novos produtos
• Desenvolver ideias para campanhas de publicidade.
• Resolução de problemas
Brainstorming
• Procedimento
1º Define-se o problema;
2º Estabeleça um grupo de trabalho – 6 a 12 pessoas;
3º Prepare a sessão –
Definir funções, Reforças regras e tempo de duração 4º Gere ideias – cerca de 30 minutos;
5º Organize e avaliar – equipe avaliadora de membros (ímpar);
6º Apresentar lista de ideia.
Brainstorming
• Funções
• Moderador:
• É líder de grupo, deve ser familiar com o processo de brainstorming e ter facilidade em manter-se relaxado, e numa atmosfera descontraída.
• Secretário:
• O secretário deve ter facilidade na escrita rápida. Este vai ter que tomar nota de uma numerosa lista de ideias que vão ser geradas. As ideias não têm, necessariamente, de ser escritas exatamente da mesma forma que são ditas. O nome da pessoa que sugere as ideias não deve ser anotado, já que o anonimato encoraja a liberdade de expressão.
• Membros:
• Devem ser escolhidas pessoas que tenham alguma experiência com o problema em causa. É necessário não misturar os chefes com os trabalhadores. Devem escolher-se pessoas que estejam no mesmo patamar da hierarquia na organização. A maioria das pessoas não se consegue libertar nem ser suficientemente criativo diante do seu chefe.
Brainstorming
•
Regras
• Críticas não são permitidas:
• Esta é provavelmente a regra mais importante. Não é permitido o julgamento das ideias por parte dos membros. Nesse momento o moderador deve atuar e coibir o julgamento de ideias inibidas.
• Criatividade é bem-vinda:
• Esta regra é utilizada para encorajar os participantes a sugerir qualquer ideia que lhe venha à mente, sem preconceito e sem medo que isso o vá avaliar imediatamente.
• Quantidade é necessária:
• Quanto mais ideias forem geradas, mais hipóteses há de encontrar uma boa ideia. Quantidade gera qualidade.
• Combinação e aperfeiçoamento são necessários:
• O objetivo desta regra é encorajar a geração de ideias adicionais para a construção e reconstrução sobre as ideias dos outros.
25
Prática
•
Mini Workshop de Requisitos
•
Objetivo: Delimitar o escopo do sistema que vai interligar o controle de estacionamento de um shopping com a central da Polícia Civil, a fim de identificar carros roubados que estejam entrando no shopping
•
Utilização de brainstorming (tempestade de ideias)
•
Regras
•
Expressar ideias livremente
•
Evitar atitude crítica
•
Registrar ideias
•
Fechar um consenso
•
Documentar o escopo (sugestão: lista de funcionalidades)
Prática
• Mini Workshop de Requisitos
• Situação:
• Nas salas de aula da nossa faculdade é comum, principalmente por parte do sexo feminino, conflitos quanto a temperatura das centrais de ar, pois são mais suscetíveis ao frio que os homens.
• Problema:
• Encontrar uma maneira de ajuntar a temperatura de ambientes climatizados que agrade as pessoas que estão em um mesmo ambiente.
•
• Utilização de brainstorming (tempestade de ideias)
• Regras
• Expressar ideias livremente
• Evitar atitude crítica
• Registrar ideias
• Fechar um consenso
• Documentar o escopo (sugestão: lista de funcionalidades)
PROCESSO DE REQUISITOS - Atividades
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
•
Vamos olhar agora especificamente a Análise e Negociação de Requisitos
O processo de Requisitos
27
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• Objetivos:
• atividades que visam descobrir problemas com os requisitos e chegar a acordos para a sua resolução de forma a satisfazer todos os interessados no sistema
• na fase de elicitação já se realizam atividades de análise e negociação
• análise e negociação de requisitos são atividades que incidem sobre conjuntos incompletos de requisitos
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• a análise e negociação de requisitos é normalmente um processo complexo
• requer pessoas com competências específicas
• baseia-se muito no julgamento e experiência dos participantes
• não é possível transformar este processo numa
abordagem estruturada e sistemática
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
Processo de Análise de Requisitos
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
•
Processo de Análise de Requisitos
• Verificação da necessidade
• Alguns requisitos podem não contribuir ou até mesmo divergir dos objetivos do negócio ou da organização
• Verificação da consistência e completude
• Busca de requisitos contraditórios e de todos os serviços e limitações oriundas das necessidades dos usuários
• Verificação da viabilidade
• Os requisitos são avaliados para saber se são viáveis, levando em consideração o orçamento e o tempo disponível
29
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
•
Análise de requisitos
• É importante analisar se os requisitos estão precisamente definidos
• Para que possam ser validados
• Suas implementações verificadas
• E seus custos estimados
• O objetivo principal é descobrir incompletude e inconsistências!
• Incompletude quer dizer que nem todos os requisitos foram elicitados, levantados, e surge a sensação que está faltando algo,
• Inconsistência está relacionada com as contradições que podem existir entre os requisitos.
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
•
Negociação
•
Chegar a um acordo em relação a opções mais adequadas aos interesses dos stakeholders
•
Definir as prioridades dos requisitos
•
Definir novas iterações de elicitação, análise e/ou desenvolvimento
•
chegar a um acordo em relação a requisitos que estão
em conflito
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
•
A classificação dos requisitos é parte do processo de análise
• Requisitos funcionais e não funcionais
• Requisitos do produto e do processo
• Quanto a prioridades dos requisitos
• Quanto ao escopo dos requisitos
• Quanto a volatilidade/estabilidade
• Entre outras...
•
Interessante a classificação quanto ao impacto na arquitetura
• Identificar aqueles requisitos que são arquiteturalmente críticos
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• TÉCNICAS
•
Checklist
• o requisito poderia ser decomposto em sub-requisitos?
• o requisito é mesmo necessário?...
• o requisito implica a utilização de software não convencional?
• o requisito está de acordo com os objetivos do negócio?
• o requisito é ambíguo?
• o requisito é realista?
• o requisito é "testável"?
31
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• Técnicas
•
Análise do Escopa
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• Técnicas
•
Análise de Dependência
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• Técnicas
•
Atribuição de Prioridades
• Definir prioridades na análise e implementação dos requisitos
• Classificação:
• alta, média, baixa, n/s
• essencial, importante, desejável, a ser decidido
•Ex:
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
• Técnicas - Organização
•
Classificação:
• agrupamento de requisitos para melhor manipulação e visualização
•
Exemplos:
• atendimento, vendas, pesquisa, etc.
•
Número sequencial
• número sequencial numa hierarquia do documento
• número sequencial dentro de uma categoria: RF001, RNF005,...
33
DOCUMENTAÇÃO DE REQUISITOS
• Vamos olhar agora especificamente a Documentação de Requisitos
• A documentação de requisitos está relacionada com a produção de um conjunto de documentos que possam ser sistematicamente revisados, evoluídos e aprovados.
DOCUMENTAÇÃO DE REQUISITOS
•
Documento de Requisitos
• Especificação do produto a ser desenvolvido, em termos das necessidades e características mais importantes.
• Por conter uma descrição dos requisitos centrais pretendidos, proporciona a base contratual para requisitos técnicos mais detalhados
• Glossário
• Define termos importantes usados pelo projeto
• Modelo de Caso de Uso
• O modelo de casos de uso é um modelo das funções pretendidas do sistema e como será sua interação com o ambiente.
DOCUMENTAÇÃO DE REQUISITOS
•
Protótipo de Interface com Usuário
• Representação dos campos, comandos e navegabilidade entre as telas da aplicação
•
Especificações de Casos de Uso
• Sequência de ações realizada pelo sistema que produz um resultado de valor observável para determinado ator.
• Utilizado para detalhar cada requisito com seus fluxos de processamento.
• As informações contidas em documentos desse tipo serão a base para a implementação e realização de testes.
•
Matrizes de Rastreabilidade
• Repositório de dependências e atributos dos requisitos com o objetivo de facilitar o gerenciamento de requisitos
DOCUMENTAÇÃO DE REQUISITOS
• Plano de Gerenciamento de Requisitos
•
Descreve a documentação de requisitos, os tipos de
requisitos e seus respectivos atributos de requisitos,
especificando as informações e os mecanismos de
controle que devem ser coletados e usados para
avaliar, relatar e controlar mudanças nos requisitos
35
VALIDAÇÃO DE REQUISITOS
• Vamos olhar agora especificamente a Validação de Requisitos
VALIDAÇÃO DE REQUISITOS
• A validação de requisitos deve certificar que os requisitos realmente definem o sistema que o usuário quer
• Alguns aspectos dos requisitos devem ser estudados
• Validade
• Consistência
• Completude
• Realismo
• Validação de requisitos engloba Validação e Verificação
• Validação: A documentação deve ser validada para garantir que os engenheiros entenderam os requisitos, que a vontade do usuário está realmente atendida pelo que foi documentado
• Verificação: A documentação deve ser verificada conforme os padrões organizacionais, e deve estar entendível, consistente e completa
Introdução a UML
Modelagem com Casos de uso
Unified Modeling Language
História e evolução da UML
•
UML É FERRAMENTA
• A UML é uma linguagem para modelagem de softwares, ela é utilizada no processo de definição do software, na análise e estruturação de como o programa será implementado.
• Ela permite que os desenvolvedores de software possam modelar seus programas de forma unificada, isso quer dizer que qualquer pessoa que entenda UML poderá entender a especificação de um software.
• O Objetivo da UML é descrever “o que fazer”, “como fazer”,
“quando fazer” e “porque deve ser feito”.
37
História e evolução da UML
• Para modelar os sistemas a UML possui um conjunto de diagramas que devem ser utilizados em combinação para obter todas as visões do sistema.
• A UML é utilizada para modelar sistemas escritos no padrão orientado a objetos, portanto para todas as definições existentes na orientação a objetos haverá um diagrama correspondente.
• Exemplo:
• Uma classe,
• um objetos,
• a comunicação dos objetos e etc.
História e evolução da UML
• Na criação da UML estão envolvidos três personagens: Jim Rumbaugh, Grady Booch e Ivar Jacobson.
Em 1997 a UML foi adotada como padrão pela OMG (Object Management Group). Que é uma organização internacional que aprova padrões abertos para aplicações orientadas a objetos.
História e evolução da UML
• Benefícios
•
Reduzir o esforço de manutenção
•
Reduzir o retrabalho
•
Gestão de conhecimento
• Conhecimento do projeto na empresa e não nas pessoas
História e evolução da UML
• Imagine a construção sem projeto
39
História e evolução da UML
História e evolução da UML
Custo de Desenvolvimento X
Custo de Manutenção
Custo de um erro por fase de desenvolvimento
História e evolução da UML
• A UML divide seus diagramas em Estruturais e Comportamentais;
Diagramas Estruturais da UML
•
Usados para visualizar, especificar, construir e documentar aspectos estáticos de um sistema.
• Diagrama de Classe
• Diagrama de Objetos
• Diagrama de Componentes
• Diagrama de Implantação
• Diagrama de Pacotes
• Diagrama de Estrutura
41
Diagramas Estruturais da UML
•
Diagrama de Caso de Uso
• É o diagrama comportamental mais utilizado na modelagem de sistemas, ele representa uma funcionalidade do sistema.
• Ajuda a definir a sequência de ações executadas por um ou mais atores e pelo próprio sistema para produzir resultados para um ou mais atores.
• Seu foco é identificar os objetivos do usuário, em vez das funções do sistema através da análise de como o ator, de forma externa, interage com as funcionalidades do sistema.
• Cada caso de uso no diagrama deve ter um documento correspondente determinando o seu comportamento.
• Para identificar os atores do diagrama o analista deve primeiro identificar as áreas da empresa que serão afetadas pelo software.
Como especificar requisito com casos de uso?
•
O que é casos de uso?
• Os casos de uso é uma das técnicas usadas para descrever requisitos de um dado sistema
• Casos de uso é uma técnica da UML baseada em cenários que identificam os atores em uma interação em si.
• Modelo gráfico de alto nível
Fonte: Sommerville, 2011
de uso?
•
Objetivo do caso de uso:
•
Entender a dinâmica da atividade Localizar Atores e Casos de Uso para iniciarmos a obtenção do Modelo de Caso de Uso
Como especificar requisito com casos de uso?
Principais Componentes do Modelo de Caso de Uso
• Ator:
• Entidade externa que interage com os casos de uso;
• Caso de uso:
• Especifica uma
funcionalidade completa do sistema. É sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execução de um caso de uso);
43
Como especificar requisito com casos de uso?
Processo de Modelagem de Caso de Uso
Como especificar requisito com casos de uso?
• Ator
• Uma instância de ator é alguém ou algo externo ao sistema que interage com ele.
• Classe de Ator
• Uma classe de ator define um conjunto de instâncias de ator, no qual cada uma desempenha o mesmo papel em relação ao sistema.
• Exemplo: Gerentes de vendas acessando um mesmo relatório gerencial
Normalmente um ator inicia a sequência de interações com o sistema
Localizar Atores do Sistema
de uso?
•
Atore pode ser...
• Pessoas
• Empregado, Cliente, Gerente, Almoxarife, Vendedor
• Organizações
• Empresa Fornecedora, Agência de Impostos, Administradora de Cartões
• Equipamentos
• Leitora de Código de Barras, Sensor
• Outros sistemas
• Sistema de Cobrança, Sistema de Estoque de Produtos
Localizar Atores do Sistema
Como especificar requisito com casos de uso?
•
Exemplo de Atores em Sistemas
• Sistema Bancário
• Cliente, gerente, caixa, diretores...
• Hospital
• Paciente, atendentes, profissionais de saúde, gerência,...
• Compras, vendas e estoque
• Comprador, fornecedor, almoxarifado, vendedor, cliente, ...
Localizar Atores do Sistema
45
Como especificar requisito com casos de uso?
•
Como identificar um ator ?
• As respostas às seguintes perguntas auxiliam na identificação dos atores:
1. Quem utiliza a principal funcionalidade do sistema?
2. Quem vai precisar de suporte do sistema para realizar suas tarefas diárias?
3. Quem precisa manter, administrar e deixar o sistema "rodando"?
4. Quais dispositivos de hardware o sistema precisa manipular?
5. Com quais outros sistemas o sistema precisa interagir?
6. Quem ou o quê tem interesse nos resultados produzidos pelo sistema?
Localizar Atores do Sistema
Como especificar requisito com casos de uso?
Existem algumas perguntas básicas que podem ajudar a descobrir os atores.
•
1) Que órgãos, empresas ou pessoas utilizarão o sistema?
•
2) Existem outros sistemas que irão se comunicar com o sistema que será construído?
•
3) Alguém deve ser informado de alguma ocorrência do
sistema.
de uso?
• Generalização/Especialização
Organizar atores
Localizar Atores do Sistema
Como especificar requisito com casos de uso?
• Atores são fundamentais para a descoberta dos casos de uso
• Pois um caso de uso é uma sequência de ações realizada por um sistema que produz um resultado de valor observável para determinado ator
• Todos os casos de uso juntos devem descrever a funcionalidade completa do sistema (requisitos)
Identificar Casos e Uso
47
Como especificar requisito com casos de uso?
•
Como identificar um Caso de Uso ?
• As respostas às perguntas abaixo podem auxiliar a identificar os Casos de Uso.
1. Quais funções o ator requer do sistema? O que o ator precisa fazer?
2. Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informação dentro do sistema?
3. Ator precisa ser notificado de eventos do sistema? O ator precisa notificar o sistema sobre algum evento?
4. Trabalho diário do ator poderia ser simplificado ou tornado mais eficiente por meio de novas funcionalidades do sistema?
5. Quais entradas e saídas o sistema precisa?
6. Quais os principais problemas com o atual sistema?
Identificar Casos e Uso
Como especificar requisito com casos de uso?
• Generalização/Especialização
Organizar casos de uso
Identificar Casos e Uso
de uso?
•
Criar interações
• É uma associação de comunicação ou associação entre uma classe de ator e uma classe de caso de uso, que indica haver interação entre suas instâncias
•
Um ator se comunica com os casos de uso por vários motivos, por exemplo:
• Para iniciar um caso de uso
• Para solicitar dados do sistema
• Para alterar os dados armazenados no sistema
Descrever como Atores e Casos de Uso Interagem
Como especificar requisito com casos de uso?
• Comunicação
• Representa a informação de quais atores estão associados a quais casos de uso
• O fato de um ator estar associado a um caso de uso significa que esse ator interage (troca informações) com o sistema
• Um ator pode se relacionar com mais de um caso de uso
Descrever como Atores e Casos de Uso Interagem
49
Como especificar requisito com casos de uso?
•
Organizar casos de uso e atores em pacotes
•
Um pacote de casos de uso é um conjunto de casos de uso, atores e relacionamentos.
•
É usado para organizar o modelo de casos de uso dividindo-o em partes menores.
•
Facilita o entendimento
Empacotar Casos de Usos e Atores
Como especificar requisito com casos de uso?
1
• Agrupamento dos passos anteriores
2
• Resulta no diagrama de casos de uso
Apresentar o Modelo de Casos de Uso em Diagramas do Casos de Uso
de uso?
Apresentar o Modelo de Casos de Uso em Diagramas do Casos de Uso
Como especificar requisito com casos de uso?
• Extensão
• Criados para modelar comportamentos opcionais ou excepcionais
• São executados somente face a certas condições
• Inclusão
• Em um relacionamento de inclusão, há um momento exato para se invocar o caso de uso incluído
• Casos de uso de inclusão são sempre executados
Apresentar o Modelo de Casos de Uso em Diagramas do Casos de Uso Relacionamento entre casos de uso
51
Como especificar requisito com casos de uso?
Apresentar o Modelo de Casos de Uso em Diagramas do Casos de Uso Relacionamento entre casos de uso
Ferramentas CASE
•
Ferramentas UML
• Software que auxiliam na tarefa de criação do diagrama
• Exemplos de Software
• Astah – JUDE
• Violet UML
• Visual-paradigm
• ArgoUML
• Microsoft Visio
Exemplo
•
CENÁRIO: Caixa Automático
• Atividades:
• Cliente de banco pode usar um caixa automático para
• Sacar dinheiro, Transferir dinheiro ou Consultar o saldo da conta
• Ator:
• Cliente
• Casos de Uso:
• Sacar dinheiro, transferir dinheiro e consultar saldo
• Restrições:
• Usuário deve realizar autenticação no caixa eletrônico
Exercício
•
Cenário:
• Gustavo deseja um APP para dispositivos móveis que permita o controle de tarefas, onde cada tarefa contenha um número de prioridade, representado por um valor real, isso permite intervalos intermediários. Além da prioridade o cadastro deve possuir: o nome da tarefa, o(s) usuário(s) responsável(eis) pela tarefa a data limite da execução (se houver), o percentual já concluído e o detalhe da tarefa.
O sistema deverá possuir um controle de acesso através de Login e senha a ser cadastrado por um administrador. O administrador poderá atribuir a um ou mais usuários a execução de uma tarefa.
• Para cada tarefa deverá ser possível incluir itens que descrevem suas execução. Para cada um desses itens deve ser cadastrado:
• A descrição da execução.
• O percentual correspondente de conclusão.
• A data da execução (quando for concluído).
• Quando uma tarefa receber 100% da execução, essa deve ser movida automaticamente para a lista de tarefas concluídas, podendo ser apagada, se for o caso.
53
Exercício
•
Com base no Exercício anterior realize as seguintes tarefas:
• Identifique quem são os atores do sistema
• Identifique quais são os possíveis casos de uso
• Descreva como eles interagem
• Elabore um modelo de caso de uso