• Nenhum resultado encontrado

PROCESSO DE REQUISITOS

N/A
N/A
Protected

Academic year: 2022

Share "PROCESSO DE REQUISITOS"

Copied!
53
0
0

Texto

(1)

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

(2)

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)

3

Usuários de um documento de requisitos

Usuários de um documento de requisitos

(4)

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)

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

(6)

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)

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

(8)

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)

9

Desafio é Transformar...

Analista de Requisitos de Software

Requisitos de propriedades

do domínio

Especificação

Programa de Computadores

Com isso! - É FUNDAMENTAL:

(10)

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)

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

(12)

• 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)

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

(14)

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)

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

(16)

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)

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

(18)

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)

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

(20)

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)

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.

(22)

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)

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.

(24)

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)

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)

(26)

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)

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

(28)

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)

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

(30)

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)

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

(32)

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)

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.

(34)

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)

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

(36)

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)

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.

(38)

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)

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

(40)

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)

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

(42)

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)

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

(44)

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)

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.

(46)

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)

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

(48)

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)

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

(50)

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)

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

(52)

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)

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

Referências

Documentos relacionados

Mãos para fora, protegendo uma escrita seca de corpo molhado Anfíbio esse lugar.. Ela não obedece a gravidade sobe e toma todo o corpo folhas e

Após 96 horas, houve um aumento no consumo, com o aumento de 100 para 160 ninfas, que não diferiu significativamente da densidade 220; com 280 ninfas disponíveis houve um

Inscrições na Biblioteca Municipal de Ourém ou através do n.º de tel. Organização: Município de Ourém, OurémViva e grupos de teatro de associações e escolas do

Graças ao apoio do diretor da Faculdade, da Rede de Museus e em especial da Pro Reitoria de Extensão, o CEMEMOR tem ampliado e mantido suas atividades junto

•   O  material  a  seguir  consiste  de  adaptações  e  extensões  dos  originais  gentilmente  cedidos  pelo 

Este trabalho foi realizado com o objetivo de avaliar a quantidade de lodo de esgoto produzido pela ETE Belém, estação que produz lodo aeróbio e utiliza a caleação como método

Deste modo, o adequado zoneamento e sua observância são fundamentais para a conciliação da preservação ou conservação de espécies, hábitats e paisagens dentre outras e

Se a pessoa do marketing corporativo não usar a tarefa Assinatura, todos as pessoas do marketing de campo que possuem acesso a todos os registros na lista de alvos originais