Laboratório de Programação
Projeto de Software – Eng. De Requisitos e UML
George Cabral
Definindo o Sucesso do Software
Clientes satisfeitos
 Eles estão satisfeitos
quando você:




Atende às expectativas
Entrega no prazo
Entrega no orçamento
O Sucesso começa com
a Gerência de Requisitos !!
Como os Projetos podem ter sucesso?


Análise do Problema

Entenda o problema

Obtenha concordância dos envolvidos
Levantamento dos Requisitos



Identifique quem usará o sistema (atores)
Descubra como o sistema será usado (casos de uso)
Gerência de Requisitos




Especifique os requisitos completamente
Gerencie expectativas, mudanças e erros
Controle o aumento do escopo
Defina a equipe e a mantenha informada
Fatores de Falha dos Projetos
 Objetivos não estavam claros
 Ignorar um grupo de clientes
 Requisitos e especificações incompletos
 Requisitos e especificações instáveis (mudanças)
 Omitir um grupo de requisitos
 Permitir inconsistências entre grupos de requisitos
 Aceitar requisito inadequado, incorreto, indefinido, ou impreciso
 Aceitar um requisito ambíguo e inconsistente
Mas o que são Requisitos?



Os requisitos de um sistema de computação
constituem uma especificação das características e
propriedades do sistema ou
Uma descrição do que o sistema deve fazer, de como
ele deve se comportar, bem como das suas restrições
de operação.
É importante ressaltar que os requisitos descrevem
"o que o sistema deve fazer"- e também "o que ele
não deve fazer"- sem dizer "o como fazer".
Requisitos e Especificação

Requisito (IEEE)



Uma condição ou capacidade necessitada por um usuário
para resolver um problema ou alcançar um objetivo
Uma condição ou capacidade que deve ser satisfeita por um
sistema para satisfazer um contrato ou um padrão
Especificação:


descrição rigorosa e minuciosa das características que um
material, uma obra, ou um serviço deverá apresentar
processo de representação dos requisitos de uma forma que
leva à implementação bem-sucedida
Importância da Especificação Correta

Não importa quão bem projetado ou codificado está um programa,
se ele for mal analisado e especificado desapontará o usuário e
trará aborrecimentos ao desenvolvedor
Análise de Requisitos
Definição e
especificação
de requisitos
Documento
de requisitos
7
8
Validação
dos requisitos
Entrada do
processo
Entendimento
do domínio
Coleta de
requisitos
6
1
Atrib. Prioridade
5
4
2
3
Classificação
Resolução
de conflito
Entendimento do Domínio


Desenvolver sistemas envolve domínios além de
software e hardware
Podemos ter que entender sobre





Contabilidade
Saúde
Supermercados
Mercado
Etc.
Coleta de Requisitos



A coleta de requisitos é feita através de técnicas
Nesta etapa, os requisitos são simplesmente
documentados à medida que são coletados
Resulta em documento preliminar (draft)
Classificação dos Requisitos


Esta etapa consiste basicamente em agrupar os
diversos requisitos coletados em categorias bemdefinidos
Por exemplo


Requisitos Funcionais: descrevem o comportamento do
sistema, suas ações para cada entrada, ou seja, é
aquilo que descreve o que tem que ser feito pelo
sistema.
Requisitos não funcionais: expressam como deve ser
feito. Em geral se relacionam com padrões de
qualidade como confiabilidade, performance, robustez,
etc.
Problema da Análise de Requisitos



Stakeholders em geral não sabem o que querem
Stakeholders expressam requisitos em sua
terminologia
Stakeholders diferentes podem gerar requisitos
conflitantes
Problema da Análise de Requisitos


Fatores políticos e organizacionais podem
influenciar os requisitos do sistema
Requisitos mudam durante o processo de
análise. Stakeholders novos podem surgir e o
ambiente de trabalho muda
Resolução de Conflitos



É normal que ocorram requisitos conflitantes
Por exemplo
 R-23: O sistema deve ...
 R-45: O sistema não deve ...
Cliente/usuário deve ser consultado para
resolver conflitos (ambigüidades)
Atribuição de Prioridade



Alguns requisitos são mais urgentes que
outros
É essencial determinar a prioridade dos
requisitos junto ao cliente
Requisitos de maior prioridade são
considerados em primeiro lugar
Prioridade

Requisitos podem ser vistos em três classes
distintas




Essenciais
Importantes
Desejáveis
Em princípio, sistema deve resolver todos os
requisitos de essenciais para desejáveis
Exemplo de Prioridade

[RF001] Consulta X ao B.D. deve retornar
dados A, B, C


[RNF001] Consulta X ao B.D. deve visualizar
dados segundo padrão Y


Prioridade: Essencial
Prioridade: Importante
[RNF010] Consulta X ao B.D. deve usar cores
azuis nos resultados

Prioridade: Desejável
Validação dos Requisitos



Será que realmente entendi o que o
cliente deseja?
Devo me certificar de que não houve
falha em nossa interação (comunicação)
Há diversas técnicas de validação
Validação de Requisitos


Demonstrar que os requisitos definem o
sistema que o cliente realmente deseja
Custos com erros de requisitos são altos

Consertar um erro de requisitos após
entrega do sistema pode custar mais de
100 vezes o custo de um erro de
implementação
Técnicas de Validação de Requisitos

Revisões de Requisitos


Prototipação


Análise manual sistemática dos requisitos
Uso de modelo executável do sistema para avaliar
requisitos
Geração de Casos de Teste

Desenvolver testes específicos para os requisitos
para avaliá-los
Gerenciamento de Requisitos

Gerenciamento de requisitos é o
processo de controlar as mudanças dos
requisitos durante


O processo da engenharia de requisitos
E desenvolvimento do sistema
Gerenciamento de Requisitos

Requisitos são inevitavelmente incompletos e
inconsistentes


Requisitos novos surgem durante o processo de
acordo com mudanças nas necessidades do
negócio e um entendimento melhor do sistema é
desenvolvido
Diferentes pontos de vista têm diferentes
requisitos e esses geralmente são contraditórios
Rastreamento


Responsável por dependências entre
requisitos, suas origens e projeto do
sistema
Rastreamento de Origem

Associação entre requisitos e stakeholders
que propuseram tais requisitos
Rastreamento

Rastreamento de Requisitos


Rastreamento de Projeto


Associação entre requisitos dependentes
Associação dos requisitos com o projeto
Usar hipertexto ou referência cruzada

Ou matriz de rastreamento
Estrutura de um Documento
de Requisitos








1.
2.
3.
4.
5.
6.
7.
8.
Introdução
Definição dos Requisitos do Usuário
Especificação dos Requisitos do Sistema
Arquitetura do Sistema
Modelos do Sistema
Evolução do Sistema
Apêndices
Índice
Documento de Requisitos

Fonte: IEEE/ANSI (830-1998)

1. Introdução





1.1
1.2
1.3
1.4
1.5
Propósito do documento
Escopo do sistema
Glossário, acrônimos e abreviaturas
Referências
Descrição do resto do documento
Documento de Requisitos

Fonte: IEEE/ANSI (830-1998)

2. Descrição geral





2.1
2.2
2.3
2.4
2.5
Perspectiva do produto
Funções do produto
Características dos usuários
Restrições gerais
dependências
Documento de Requisitos

Fonte: IEEE/ANSI (830-1998)

3. Requisitos específicos

requisitos funcionais, não-funcionais, GUI
com o usuário:
 funcionalidade, interfaces externas,
desempenho, restrições, atributos do
sistema, caract. qualidade, ...
Documento de Requisitos


4. Arquitetura do Sistema
5. Modelos do Sistema








Diagrama de Atores
Modelo de Caso de Uso
Modelo de Análise
Modelo de Projeto
Diagrama de Pacotes
6. Evolução do Sistema (Futuro)
7. Apêndices
8. Índice
Abreviações e Glossário
Abreviação
Significado
Explicação / Condição ou situação no sistema
A
Administrador
Usuário com maiores privilégios no sistema
AT
Auto-treinamento
Um dos três perfis de avaliação. O operador/treinando solicita ao sistema
uma avaliação que lhe é montada de modo randômico a partir de alguns
parâmetros
CT
Certificação Técnica
Um dos três perfis de avaliação. Os supervisores (RL/RS) agendam com
antecedência dia e hora da avaliação. É o teste que certifica o
treinando/operador.
O
Operador
Usuário. Treinando que realiza as avaliações.
RL
Responsável Local
Usuário. Responsável, na unidade da empresa, por um grupo de
operadores. Propõe, elimina e valida questões e avaliações.
RS
Responsável Setorial
Usuário. Responsável por um setor da empresa. Coordena um ou mais
RL. Propõe, elimina e valida questões e avaliações.
TO
Treinamento
Orientado
Um dos três perfis de avaliação. Serve para os RS/RL diagnosticarem o
estágio da aprendizagem dos operadores.
V
Validador
Usuário. Checa e valida as questões propostas pelos RS/RL.
M
Módulo
Refere-se aos módulos do sistema.
Backup
Refere-se à cópia de dados de um dispositivo para o outro com o objetivo
de posteriormente os recuperar (os dados), caso haja algum problema.
Logon
É a ação necessária para acessar um sistema computacional restrito
inserindo uma identificação, podendo esta ser ou não única para cada
usuário, e a senha relacionada a ela. Uma vez logado, o usuário passa a
ser identificado no sistema, sendo restringido ou permitido a acessar
recursos do sistema.
UML
O que é um modelo?

Construímos modelos para compreender
melhor o sistema que estamos
desenvolvendo.

Um modelo é uma simplificação da realidade.

Um modelo pode ser estrutural ou
comportamental.
O que é um modelo?
O que é um modelo?
Por que modelar software?

Ajuda a ter uma visão geral do sistema

Permite especificar a estrutura e o
comportamento do sistema

Proporciona um guia para a construção do
sistema

Documenta as decisões tomadas
O que é a UML?

Unified Modeling Language (UML) é...
... uma linguagem gráfica para visualizar, especificar, construir e
documentar os artefatos de um sistema de software.
... resultado da unificação das notações utilizadas nos métodos
Booch, OMT (Object Modeling Technique) e OOSE (ObjectOriented Software Engineering).
... adotada por grande parte da indústria de software e por
fornecedores de ferramentas CASE como linguagem padrão de
modelagem.
… utilizada com qualquer processo de desenvolvimento já que é
independente dele.
A UML é uma Linguagem para
Visualização

No processo de desenvolvimento de sistemas de software,
é quase impossível a visualização de toda a estrutura de
um sistema sem o uso de modelos que a represente.

A UML fornece os símbolos gráficos para a representação
de artefatos de software.

Por trás de cada símbolo empregado na notação da UML,
existe uma sintaxe e uma semântica bem-definidas.

Dessa maneira, um desenvolvedor poderá usar a UML
para escrever seu modelo, diminuindo a ambigüidade em
sua interpretação.
A UML é uma Linguagem para Construção

Os modelos de UML podem ser diretamente
”traduzidos” para várias linguagens de programação.



Isso significa que é possível mapear os modelos da
UML para linguagens de programação tais como, Java,
C++ e Visual Basic.
Esse mapeamento permite a realização de uma
engenharia de produção: geração de código a partir
de um modelo em UML.
O processo inverso, a engenharia reversa, também é
possível, com a reconstrução de um modelo a partir de
sua implementação.
A UML é uma Linguagem para
Documentação

Cada modelo criado é um artefato do software
Diagrama de Casos de Uso
Diagrama de Classes
blogSystem
Criar Blog
Criar Comentario
<<include>>
Usuario
<<include>>
-dtCriacao:Date
-titulo:String
-dono:UsuarioBlog
-conteudos :Vector
Ler Nota
1
dono
U s u a rio B l o g
Ler Comentario
<<include>>
-email:String
0..*
usuario
usa
1
+notificarEx clus ao:void
Remover Comentario
Remover Conteudo
1
+criarNota:void
+ex ibirConteudo:void
+comentar:void
+lerComentarios:Vector
+removerC onteudo:void
+lerNotas :Vector
+Blog
: SIM
autor
: AnalisadorMatricula
0..*
Remover Nota
C o n te u d o
0..*
Dono do blog
Diagrama de Seqüência
B lo g
0..*
Ler Conteudo
Criar Nota
-dtCriacao:Date
-texto:String
-autor:Us uarioBlog
1: submeterFormulario(f)
+Conteudo
+ex ibirConteudo:void
N o ta
-comentarios:Vector
-attribute1:int
+comentar:void
+lerComentarios:Vector
+finaliz e:void
C o m e n ta r io
0..*
+finaliz e:void
2: adicionar(a,d )
…
Uma linguagem de diagramas
Diagramas de Seqüência
Diagramas de Colaboração
Diagrama de Casos de Uso
Diagramas de Classe
Modelos
Diagramas de Estado
Diagramas de Atividade
Diagramas de Objetos
Diagramas de Componentes
Diagrama de Deployment
Ponto de Vista Estático
Ponto de Vista Dinâmico
Casos de Uso
Este caso de uso é responsável por autenticar um usuário
do sistema.
Descrição
Narrativa
Pré-condição: nenhuma
Pós-condição: um usuário válido é logado e sua sessão
é registrada no sistema.
Fluxo de eventos principal
1. O cliente informa login e senha.
2. O sistema verifica se o login e a senha são válidos
(verifica-se se o login e senha pertencem a uma conta).
3. O sistema registra o início de uma sessão de uso.
Fluxos secundários
- No passo 2, se o login ou a senha forem inválidos, o
sistema exibe uma mensagem e volta ao passo 1.
Diagrama de Casos de Uso
Solicitar
histórico
<<estende>>
Solicitar histórico do
semestre atual
<<estende>>
Solicitar histórico de
todos os semestres
Estudante
Sistema de controle
de pré-requisitos
<<inclui>>
Matricular
aluno
Verificar
dependências
Secretária
Diagrama de Classes
Cliente
Pedido
-codigo: Integer
-dataRecebido
-total: Currency
0..*
 faz
-nome: String
-endereco: String
-dataPrimeiraCompra: Date
-dataUltimaCompra: Date
-totalComprado: Currency
1
+confirmar()
+cancelar()
-calcularTotal():Currency
gerarNovoCodigo: String
#creditoPermitido: Currency
#nivelCredibilidade()
itens
Item de Pedido
-quantidade: Integer
-preco: Currency
-emEstoque: Boolean
Cliente pessoa-jurídica
nomeContato: String
telefones[1..10]: String
CGC: String
FAX[1..3]: String
Cliente pessoa-física
nome: String
CPF: String
numCartaoCredito
colocarListaNegra()
*
Produto
representante
de vendas
*
Empregado
IPessoa
Diagrama de Objetos
Curso
Professor
ministra
-matrícula: String
-nome: String
[1..3]
-codDisciplina: String
[1..5] -descrição: String
-codTurma: String
Aluno
* -matrícula: String
-nome: String
[0..10]
-período: Integer
p1: Professor
p2: Professor
matricula: "205-6712-09"
nome: "Jaelson Castro"
c1: Curso
: Curso
c2: Curso
: Curso
codCurso: "IF291"
descrição: "MPS"
codTurma: I7
c3: Curso
codCurso: "IF185"
descrição: "AER"
codTurma: I6
: Aluno
: Aluno
: Aluno
: Aluno
: Aluno
:aluno
Bill
matricula: "219846534"
nome: "Nelson Mandella"
:aluno
matricula: "562746134"
nome: "John Major"
: Aluno
Lewinsky
Diagrama de Sequência
: ClienteAtor
: TelaLogin
: ControladorLogin
: CadastroContas
efetuarLogin(login, senha)
efetuarLogin(login, senha)
existeConta(login, senha)
registraSessao(login)
Diagrama de Colaboração
Janela de entrada
de pedido
1: preparar()
p: Pedido
1.1.2.1: estoqueBaixo :=
verif icEstoqueBaixo()
1.1: *[para cada item do pedido]
preparar()
1.1.1 : emEstoque := verif icar()
1.1.2 : [emEstoque] remover()
: ItemPedido
1.1.3 : [emEstoque]
<<criar>>
:ItemEntrega
:ItemEstoque
1.1.2.2 [estoqueBaixo]
<<criar>>
:ItemRenovEstoque
Diagrama de Estados
cartãoInserido
Ativo
Ocios o
Validando
fazerManutenção
M anute nção
cancelar
H
[continuar]
Se le cionando
Proce s s ando
[não continuar]
e ntry / le rCartão
e xit / e je tarCartão
Im prim indo
Diagrama de atividades
Pessoa
H
Procurar bebida
[sem café]
[achou café]
Colocar café
no filtro
Adicionar água à
máquina
[sem Coca]
[achou Coca]
Pegar
xícara
Pegar lata
de Coca
Colocar filtro
na máquina
Ligar máquina
Filtrar café
Colocar café na
xícara
Beber
H
Diagrama de Componentes
Cadastro.exe
<<link>>
Usuários
FormCadastro.html
Banco
<<link>>
Autenticacao.exe
Principal.html
FormEntrada.html
Senhas
Diagrama de Implantação
PC - G309
Nestscape
Communicator
5.0
Principal.html
servidorWeb
FormCadastro.html
Autenticação.exe
servidorDeArquivos
Cadastro.exe
FormEntrada.html
servidorBancoDeDados
SGBD
O SGBD a ser
utilizado ainda
não foi escolhido.
Atores: Especialização
É possível definir
tipos gerais de atores
e especializá-los
usando o
relacionamento de
especialização
Cliente
ClienteEspecial
Bibliografia
 The Unified Modelling Language User
Guide (Grady Booch)
 The Unified Modelling Language Reference
Manual (James Rumbaugh)
 The Unified Software Development Process
(Ivar Jacobson)
 UML Distilled (Martin Fowler)