Requisitos: Fluxo de Trabalho
Requisitos: Fluxo de Trabalho
 Cada detalhamento do fluxo de trabalho
representa uma habilidade-chave que precisa
ser aplicada para executar o gerenciamento
eficiente de requisitos.
 Os detalhamentos do fluxo de trabalho são
mostrados em uma ordem lógica e
seqüencial.
 Eles são aplicados em ordem diferente,
conforme a necessidade no decorrer do
projeto.
Detalhamento do Fluxo de
Trabalho: Analisar o Problema
Detalhamento do Fluxo de
Trabalho: Analisar o Problema
 A finalidade desse detalhamento do fluxo de
trabalho é:
 Estabelecer acordo sobre o problema a ser
resolvido,
 Identificar os envolvidos,
 Definir as fronteiras do sistema e
 Identificar restrições impostas ao sistema
Detalhamento do Fluxo de
Trabalho: Definir o Sistema
A finalidade desse detalhamento
do fluxo de trabalho é:
 Criar uma compreensão comum do sistema dentro




da equipe do projeto.
Realizar uma análise de alto nível sobre os
resultados da coleta de solicitações dos principais
envolvidos.
Refinar a visão para que contenha as características
a serem incluídas no sistema, juntamente com os
atributos adequados.
Refinar o modelo de casos de uso para incluir os
casos de uso descritos.
Documentar com mais formalidade os resultados em
modelos e documentos.
Requisitos:
Visão Geral das Diretrizes

















Associação de Comunicação
Ator
Caso de Uso
Classe de Fronteira
Diagrama de Atividades no Modelo de Casos de Uso
Diagrama de Casos de Uso
Documento de Arquitetura de Software
Encenação de Caso de Uso
Especificação de Requisitos de Software
Generalização de Ator
Generalização de Casos de Uso
Interface do Usuário (Geral)
Modelo de Casos de Uso
Pacote de Casos de Uso
Plano de Gerenciamento de Requisitos
Relacionamento de Extensão
Relacionamento de Inclusão
Visão Geral das Diretrizes
Uma associação de comunicação é uma
associação entre uma classe de ator e uma classe
de caso de uso, que indica haver interação entre
suas instâncias.
Uma instância de ator é alguém ou algo externo ao sistema
que interage com ele. 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.
Ator
Uma instância de casos de uso é uma seqüência de ações
realizadas por um sistema, que gera um resultado
observável de valor para um determinado ator. Um caso de
uso define um conjunto de instâncias de casos de uso.
Caso de Uso
Visão Geral das Diretrizes
Uma classe de fronteira modela a interação entre um ou
mais atores e o sistema.
O diagrama de atividades no modelo de casos de uso
ilustra o fluxo de eventos de um caso de uso.
Um diagrama de casos de uso mostra os atores, os casos
de uso, os pacotes de casos de uso e seus
relacionamentos.
Visão Geral das Diretrizes
Documento de Arquitetura de Software
 Visão de Implantação
Visão de Implementação
Visão de Dados
Tamanho e Desempenho
Qualidade
Referências
Metas e Restrições da Arquitetura
Visão de Casos de Uso
Visão Lógica
Visão de Processos
Uma encenação de caso de uso é uma descrição lógica e
conceitual de como um caso de uso é fornecido pela interface do
usuário, incluindo a interação necessária entre os atores e o
sistema.
Visão Geral das Diretrizes
A Especificação de Requisitos de Software (SRS)
abrange todos os requisitos do software para o sistema ou
uma parte do sistema.
A generalização de ator de um tipo de ator
(descendente) para outro tipo de ator (ascendente) indica
que o descendente herda o papel que o ascendente pode
desempenhar em um caso de uso.
Esta é uma descrição das diretrizes gerais aplicáveis
à criação de uma interface do usuário, na qual
"A interface do usuário é o que permite que as informações
sejam transmitidas entre um usuário humano e os
componentes de hardware ou software de um sistema de
computador." [IEEE, Std 610.12-1990]
Visão Geral das Diretrizes
O modelo de casos de uso é um modelo que descreve os
requisitos de um sistema em termos de casos de uso.
Um pacote de casos de uso é um conjunto de casos de
uso, atores, relacionamentos, diagramas e outros
pacotes; ele é usado para estruturar o modelo de casos
de uso dividindo-o em partes menores.
Plano de Gerenciamento de Requisitos
 Relacionamento com Outros Planos
Identificação de Itens de Rastreabilidade
 Especificação de Rastreabilidade
 Organização, Responsabilidade e
Interfaces
 Atributos de Exemplo
Seleção de Atributos
Relatórios e Medidas
Gerenciamento de Mudanças de
Requisitos
Visão Geral das Diretrizes
Relacionamento de Extensão
Um relacionamento de extensão é aquele que se estabelece entre um caso
de uso de extensão e um caso de uso base, especificando como o
comportamento definido para o caso de uso de extensão pode ser inserido no
comportamento definido para o caso de uso de base. Ele é inserido
implicitamente no sentido de que a extensão não é exibida no caso de uso
base.
Relacionamento de Inclusão
Um relacionamento de inclusão é aquele que se estabelece entre um caso
de uso base e um caso de uso de inclusão, especificando como o
comportamento definido para o caso de uso de inclusão é inserido de forma
explícita no comportamento definido para o caso de uso base.
Introdução aos
Requisitos
Finalidade
A finalidade da disciplina Requisitos é:
 Estabelecer e manter concordância com os clientes e
outros envolvidos sobre o que o sistema deve fazer.
 Oferecer aos desenvolvedores do sistema uma
compreensão melhor dos requisitos do sistema.
 Definir as fronteiras do sistema (ou delimitar o
sistema).
 Fornecer uma base para planejar o conteúdo técnico
das iterações.
 Fornecer uma base para estimar o custo e o tempo de
desenvolvimento do sistema.
 Definir uma interface de usuário para o sistema,
focando nas necessidades e metas dos usuários.
 Para atingir essas metas, é importante, antes de
tudo, compreender a definição e o escopo do
problema que tentamos resolver com este
sistema. As Regras de Negócios, o Modelo de
Casos de Uso de Negócios e o Modelo de Objetos
de Negócios desenvolvidos durante a Modelagem
do Negócio servirão como informações importantes
nesse trabalho. Os envolvidos são identificados e
as Solicitações dos Principais Envolvidos são
recolhidas, reunidas e analisadas.
Relação com Outras Disciplinas
A disciplina Requisitos está relacionada a outras
disciplinas do processo:
 A disciplina Modelagem de Negócios fornece as
Regras de Negócios, um Modelo de Casos de Uso de
Negócios e um Modelo de Objeto de Negócio,
incluindo um Modelo de Domínio e um contexto
organizacional para o sistema.
 A disciplina Análise e Design obtém suas
informações primárias (o modelo de casos de uso e o
Glossário) dos Requisitos. Falhas no modelo de casos
de uso podem ser descobertas durante a atividade de
análise e de design; solicitações de mudança são,
então, geradas e aplicadas ao modelo de casos de
uso.
 A disciplina Teste valida o sistema com base (entre
outras coisas) no Modelo de Casos de Uso. Os Casos
de Uso e as Especificações Suplementares fornecem
informações sobre os requisitos usados na definição
da missão de avaliação e nas atividades
subseqüentes de teste e avaliação.
 A disciplina Gerenciamento de Configuração e
Mudança fornece o mecanismo para controle de
mudanças dos requisitos. O mecanismo para
proposta de uma mudança consiste em enviar uma
Solicitação de Mudança, que será analisada pelo
Comitê de Controle de Mudança.
 A disciplina Gerenciamento de Projeto planeja o
projeto e cada iteração (descritas em um Plano de
Iteração). O modelo de casos de uso e o Plano de
Gerenciamento de Requisitos são informações
importantes fornecidas às atividades de planejamento
de iterações.
 A disciplina Ambiente desenvolve e mantém os
artefatos de suporte usados no gerenciamento de
requisitos e na modelagem de caso de uso, como o
Guia de Modelagem de Caso de Uso e o Guia de
Interface do Usuário.
Conceitos
 Design Centrado no Usuário
 Gerenciamento de Requisitos
 Rastreabilidade
 Requisitos
 Tipos de Requisitos
 Visão de Casos de Uso
Design centrado no usuário
Não há um consenso claro sobre o que é o design centrado no usuário. No
entanto, John Gould e seus colegas na IBM desenvolveram um método na
década de 1980 chamado Design Pensando em Usabilidade que compreende
as definições mais comumente aceitas. Ele foi desenvolvido a partir de
experiências práticas com uma série de sistemas interativos, especialmente o
Olympic Messaging System (Sistema de Mensagens Eletrônicas Olímpicas) da
IBM em 1984. O método tem quatro componentes principais, conforme é
descrito abaixo.
• Foco nos usuários
• Integração com o design
• Teste com o usuário no início
• Design iterativo
Design centrado no usuário no
RUP
Contexto
Atributos
Tarefas
Metas do uso do sistema, freqüência e duração do
desempenho, considerações sobre saúde e
segurança, alocação das atividades, passos
operacionais entre os recursos humanos e
tecnológicos. As tarefas não devem ser descritas em
termos de funções e características fornecidas por um
produto ou sistema.
Usuário (para cada
tipo ou papel
diferente)
Conhecimento, habilidade, experiência, instrução,
treinamento, atributos físicos, hábitos, preferências,
recursos.
Ambientes
Hardware, software, materiais, ambientes físico e
social, padrões relevantes, ambiente técnico, ambiente
circundante, ambiente jurídico, ambiente social e
cultural.
Gerenciamento de requisitos





O gerenciamento de requisitos é um modelo sistemático para
encontrar, documentar, organizar e rastrear os requisitos
variáveis de um sistema.
Um requisito é definido como:
Uma condição ou uma capacidade com a qual o sistema deve
estar de acordo.
Nossa definição formal de gerenciamento de requisitos trata-se
de um modelo sistemático para:
identificar, organizar e documentar os requisitos do sistema, e
estabelecer e manter acordo entre o cliente e a equipe do
projeto nos requisitos variáveis do sistema.
Os principais itens para o gerenciamento eficiente de requisitos
incluem manter uma declaração clara dos requisitos,
juntamente com atributos aplicáveis para cada tipo de requisito
e rastreabilidade para outros requisitos e outros artefatos do
projeto.
Rastreabilidade

A rastreabilidade é a capacidade de rastrear um elemento do projeto a outros
elementos correlatos, especialmente aqueles relacionados a requisitos. Os
elementos do projeto envolvidos em rastreabilidade são chamados de itens de
rastreabilidade. Os itens típicos de rastreabilidade incluem diferentes tipos de
requisitos, elementos de modelo de design e de análise, artefatos de testes
(conjuntos de testes, casos de teste, etc.) e material de treinamento e documentação
de suporte a usuário final
A finalidade de estabelecer rastreabilidade é ajudar a:







Compreender a origem dos requisitos
Gerenciar o escopo do projeto
Gerenciar mudanças nos requisitos
Avaliar o impacto no projeto da mudança em um requisito
Avaliar o impacto da falha de um teste nos requisitos (isto é, se o teste falhar, talvez o
requisito não seja atendido)
Verificar se todos os requisitos do sistema são desempenhados pela implementação
Verificar se o aplicativo faz apenas o que era esperado que ele fizesse.
Requisitos
 Um requisito é definido como "uma condição ou uma capacidade






com a qual o sistema deve estar de acordo".
As principais categorias de requisitos são:
Funcionalidade - Algo passível de execução;
Usabilidade - Facilidade de uso;
Confiabilidade - É a qualidade do sistema que nos permite confiar,
justificadamente, no serviço oferecido;
Desempenho - Pode ser definido como o conjunto de
características ou capacidades de comportamento e rendimento de
um sistema;
Suportabilidade - É um dos aspectos da qualidade de software que
se refere à habilidade dum suporte técnico de instalar, configurar e
monitorar produtos computacionais
Tipos de requisitos
Visão de caso de uso
Visão de caso de uso
 Visão Lógica - Ilustra as principais realizações de caso de uso,
subsistemas, pacotes e classes que abrangem o
comportamento significativo em termos de arquitetura.
 Visão de Processos - Ilustra a decomposição do processo do
sistema, incluindo o mapeamento das classes e dos
subsistemas para processos e threads.
 Visão de Implantação - Ilustra a distribuição do processamento
em um conjunto de nós do sistema, incluindo a distribuição
física dos processos e threads.
 Visão de Implementação - Capta as decisões de arquitetura
tomadas para a implementação
Perguntas
 Qual a importância do fluxo de trabalho?
 Como um requisito se relaciona com um
caso de uso?
 Quais são os principais artefatos gerados na
modelagem de requisitos?
 John Weverson Rodrigues Teodoro
 Edicarlos Tobias Honório Silva
 Ericson Luiz Araújo de Oliveira
 Armando Alves da Rocha Junior
 Jonatas Cândido Barbosa
 Lilian Gomes
 Ana Julia Fonseca Silva