Sei sulla pagina 1di 36

Engenharia de

Software I
Requisitos
Finalidade do fluxo de Requisitos

A finalidade deste fluxo é:

• Chegar a um acordo com o cliente e o utilizador sobre o


Que o sistema deve fazer.
• Oferecer ao desenvolvedor um melhor entendimento dos
requisitos do sistema.
• Delimitar o escopo sistema.
• Prover uma base para o planejamento do conteúdo
das iterações.
• Definir uma interface do sistema com o usuário.
Artefatos mais relevantes do fluxo de
requisitos
Modelo de caso de uso
Descrição do Atributos
Problema dos Requisitos

actores
Casos de Uso
Glossário Matriz de
rastreabilidade

...
Especificações
Suplementares Especificações de Caso de Uso
Descrição do Problema
(Documento de Visão)
• Mostra a descrição geral do problema a ser resolvido
com o sistema (necessidades), bem como as
funcionalidades básicas do sistema (características).

Descrição do
problema
Glossário

 Define termos importantes para o projeto e garante


a captura de um vocabulário comum.

Glossário
Modelo de casos de uso

Modelo de
casos de uso
 Introdução
 Pacotes de casos de uso
 Diagramas de casos de uso
Actores Casos de Uso
 Especificações de casos de
usos

Especificações de Casos de Uso


Modelo de casos de uso

Use Cases
direcionam o
trabalho desde os
requisitos até os
testes

Realizado por Verificado por


Implementado por
Exemplo de Diagrama de
Casos de Uso
Solicitar extrato

Consultar saldo

Cliente Sacar dinheiro

Realizar depósito

Transferir
entre contas

Alterar senha
Especificação de caso de uso
 Um caso de uso define
um conjunto de instâncias Modelo de caso de uso
de casos de uso, no qual
cada instância é uma
seqüência de ações
actores
realizada por um sistema
que produz um resultado Casos de Uso
de valor observável para
determinado actor.

...
Especificações de Use Case
Diagramas de atividades
• Diagramas de atividades:
– Podem ser usados para representar graficamente
o fluxo de eventos (fluxo básico + fluxos alternativos)
– São compostos de:
• atividades
• transições
• Decisões
• São muito usados para modelar atividades
concorrentes.
Diagrama de atividades:
exemplo
Especificações Suplementares
 Descrevem requisitos não-
funcionais:
 Confiabilidade
 Desempenho (performance)
 Segurança
 Distribuição
 Adequação a Padrões
 Restrições de Hardware e Especificações Suplementares
Software
 etc.
Conceitos
• Requisito: uma condição ou uma capacidade
com a qual o sistema deve estar de acordo.

• Requisitos Funcionais: especificam ações


que um sistema deve ser capaz de executar,
sem levar em consideração restrições físicas.
Os requisitos funcionais especificam,
portanto, o comportamento de entrada e
saída de um sistema
Requisitos não-funcionais
• Devem ser testáveis, para isso devem ser
mensuráveis!

• Precisam estar definidos em números e


nomes
– O sistema precisa ser rápido. Quão rápido?
– O sistema deve ser implementado numa
plataforma robusta. Que plataforma?
Requisitos não funcionais x
casos de uso

• Associados a um caso de uso específico

• Associados a todo o sistema

• Para serem atendidos podem gerar novos


casos de uso

15
Fluxo de Requisitos - Visão da Atividade

Desenvolver Elicitar
Documento de necessidades
Visão dos Stakeholders
Analista de
Sistema
Revisor de
Estruturar o
Encontrar Actores e Requisitos
Modelo de UC
Gerenciar Capturar um Casos de Uso
Dependências vocabulário comum

Especificador Detalhar UC Revisar os


de UC Requisitos

Prototipar a
Modelar a
Projetista da Interface com o Usuário
Interface com o Usuário
Interface com o Usuário

Arquiteto Priorizar UC
Atividade: Desenvolver
Documento de Visão
• Nesta atividade, o Analista de Sistemas deve
identificar os stakeholders, definir os limites
do sistema e descrever as características
primárias do sistema. A execução da
atividade deve produzir o documento de
Visão que apresenta uma visão geral dos
requisitos do projeto.
Atividade: Gerenciar
Dependências
• Nesta atividade, o Analista de Sistemas deve
obter um entendimento dos atributos dos
requisitos, o que auxilia no gerenciamento do
escopo do projeto e da aplicação. A execução
da atividade deve produzir o artefato Atributos
dos Requisitos e Matriz de Rastreabilidade.
Atividade: Elicitar Necessidades
dos Stakeholders
• Nesta atividade, o Analista de Sistemas
deve entender o que os stakeholders
esperam do sistema, coletar informações e
necessidades que o sistema deve cumprir
e priorizar as necessidades dos
stakeholders.
• A execução da atividade tem como
artefatos resultantes o documento de
Necessidades dos Stakeholders e o
Modelo de casos de uso, brevemente
esboçado.
Atividade: Capturar um
Vocabulário Comum
• Nesta atividade, o Analista de Sistemas deve
definir um vocabulário comum que pode ser
usado em descrições dos sistema.

• A execução da atividade deve produzir o


Glossário.
Atividade: Encontrar Actores e
Casos de Uso
• Nesta atividade, o Analista de Sistemas
esboça a funcionalidade do sistema, define o
que será feito pelo sistema e o que será feito
fora do sistema, define quem e o que
interagirá com o sistema, divide o modelo em
pacotes com actores e casos de uso e cria os
diagramas do modelo de casos de uso. A
execução desta atividade produz o Modelo de
Casos de Uso e as Especificações
Suplementares.
Atividade: Priorizar Casos de
Uso
• Nesta atividade, o Arquiteto deve definir o conjunto
de cenários de casos de uso que serão analisados
na iteração atual (o conjunto de cenários e casos
de uso que representam alguma funcionalidade
significativa e o conjunto de casos de uso que têm
uma cobertura arquitetural substancial ou que
ilustram um ponto específico e delicado da
arquitetura).

• A execução da atividade deve produzir uma versão


inicial do documento de Arquitetura de Software e
um refinamento do Glossário e do Plano de
Iteração.
Prioridades de Casos de Uso

• Essencial para gerenciar os requisitos e para


montar as iterações

• Deve-se definir as prioridades de todos os


casos de uso, as quais podem ser:
– Essencial
– Importante
– Desejável
Atividade: Estruturar o Modelo
de Casos de Uso
• Nesta Atividade, o Analista de Sistemas extrai
o comportamento dos casos de uso que
necessitam ser considerados como abstratos
e encontra novos actores abstratos que
definem papéis que são compartilhados por
vários outros actores. A execução desta
atividade produz um refinamento do Modelo
de Casos de Uso.
Por que estruturar o modelo?

• Extrair descrições de funcionalidades


genéricas e compartilhadas que podem ser
usadas por mais de um caso de uso.

• Extrair descrições de funcionalidades


adicionais que possam estender descrições
específicas

• Facilitar o entendimento do modelo


Atividade: Detalhar Casos de
Uso
• Nesta atividade, o Especificador de Casos de
Uso descreve o fluxo de eventos dos casos
de uso em detalhes de forma que o cliente e
os usuários possam entender.

• A execução da atividade tem como resultado


a descrição de Casos de Uso, as
Especificações Suplementares e os Atributos
dos Requisitos e Matriz de Rastreabilidade
atualizados
Quando e por que detalhar os
casos de uso?
• Quando?
– após fazer levantamento dos principais casos de
uso do sistema
• Por que?
– descrever detalhes do caso de uso
– descrever fluxo de eventos e outras propriedades
– uniformizar entendimento entre clientes, usuários
e equipe de desenvolvimento
Fluxo de eventos básico

• Série de passos que compõem um caso


de uso.

• Sugestões:
– Concentre-se inicialmente na funcionalidade
básica/central do caso de uso
– Pense nos fluxos secundários depois!
Fluxos secundários

• Só devem ser analisados e descritos após a


descrição dos fluxos básicos.

• Fluxos alternativos
– situações especiais (saque além do limite para um
cliente especial)

• Fluxos de erro
– situações de erro
Atividade: Modelar a Interface
com o Usuário
• Nesta atividade, o Designer de Interface com
o Usuário constrói um modelo de interface
com o usuário que suporta o melhoramento
da usabilidade.
• A execução desta atividade produz os
StoryBoards dos casos de uso e a definição
das Classes de Fronteira, representando
janelas da interface com o usuário.
Atividade: Prototipar a Interface
com o Usuário
• Nesta atividade, o Designer de Interface com
o Usuário deve criar um protótipo de interface
gráfica.
Protótipo de interface com o
usuário

• Ferramenta para compreensão do caso


de uso
– o nível de detalhes deve ser adequado ao
usuário
• Facilidade para a descrição de críticas
básicas
– tamanho e tipo dos campos
– máscaras de edição
Atividade: Revisar os Requisitos

• Nesta atividade, o Revisor de Requisitos


formalmente verifica os resultados do fluxo de
requisitos conforme a visão do cliente do
sistema. A execução da atividade deve
apresentar como resultado uma versão
aprovada ou rejeitada com as respectivas
alterações dos artefatos de requisitos.
Requisitos - Visão dos artefatos

Analista de Especificador
Sistema de UC
Responsável por Responsável por

Casos
Visão Necessidades Modelo de Especificação Glossário Atributos dos
dos Stakeholders Requisitos de Uso Pacote de
Use Case Suplementar
e Use Case
Matriz de
Rastreabilidade

Arquiteto Projetista
da Interface com o Usuário Revisor de
Responsável por
Requisitos
Responsável por

Documento Classes de Fronteira


de Arquitetura UC Protótipo da
de Software Storyboard Interface com o usuário
O Documento de Requisitos
simplificado: Estrutura
• Introdução
• Descrição Geral do Sistema
• Requisitos Funcionais (casos de uso)
• Requisitos Não Funcionais
• Descrição da Interface com o usuário
Fim

Potrebbero piacerti anche