Análise de Requisitos

Análise de Requisitos – O que o sistema deve fazer e sobre quais

limitações deve operar.
Diagramas Use Case Fases:
Ferramentas para Desenvolvimento e ! Elicitação
Verificação de Aplicações (Ênfase em ! Documentação
Serviços de Telecomunicações) – PCT –
! Validação
2001.2
Patrícia D. L. Machado

Tipos de requisitos Problemas com Requisitos

Requisitos funcionais
Requisitos não-funcionais
Requisitos de usabilidade
Não refletir as reais necessidades dos
clientes.
Podem ser documentados de forma
inconsistente e/ou incompleta.
Mudanças
Desentendimentos
 Técnicas para Elicitação
Entrevista
Leitura de documentos
Questionários
Análise de protocolos
Participação ativa dos usuários
Observações e análise sociais
Reuso de requisitos
Validação de Requisitos
Revisões
Prototipagem
Contrato com o cliente
Documento de Requisitos
Resumo sobre o domínio da aplicação, a importância
do sistema para o negócio e os perfis dos potenciais
usuários
Requisitos Funcionais
Requisitos não-funcionais
Restrições de hardware/performance
Fronteiras/Interface com outros sistemas
Arquitetura de Alto Nível (Preliminar)
! Física
! Modelo Conceitual
Glossário
Use Cases: Diagramação de
Requisitos Funcionais
Comportamento do sistema do ponto de
vista de seus usuários – qualquer
entidade externa que interage com o
sistema
Captura de requisitos
Planejamento de iterações
Validação
 Diagrama de Use Cases Diagrama de Use Cases
Cada use case representa uma unidade
Reserva Livro
coerente de funcionalidade. Em outras
palavras, uma tarefa a qual o sistema dará
Cliente suporte
da Pega Livro
Biblioteca emprestado Ator – interage com o sistema na realização
(ator) da tarefa.
! Representa um papel e não indivíduos
Devolve Livro ! Pessoa ?
! Apenas aquele que se beneficia ?

Use Case: Descrição Detalhada Captura de Use Cases

Use Case: Submeter artigo
Atores: Autor
Descrição: O autor requisita um formulário de
Identifique os atores
submissão de artigos. O autor preenche o Para cada ator, descubra:
formulário de submissão e anexa o seu
artigo. ! Que use cases são importantes para ele
Seqüência típica de eventos ! Use cases nos quais tome parte para o benefício
Ação do ator Resposta do sistema de outros
1. Inicia quando um autor requisita um 2. O sistema envia um formulário de Problema: use cases importantes podem não
formulário de submissão de artigos. submissão de artigos para o autor.
ser identificados !
3. O autor preenche o formulário de 4. O formulário realiza a verificação ! Ex: envio de contas mensais a clientes. Que
submissão e anexa o artigo. semântica.
atores se beneficiam ?
5. O formulário retorna para o coordenador
do programa. ! Potenciais atores: clientes. Empresa ? Correios ?
Seqüências alternativas: ! Inclusão de atores que não se beneficiam com a
Linha 4: Algum campo foi preenchido de forma incorreta ou foi deixado em branco. Indica erro. tarefa " decisão de projeto
 Modelo Conceitual:
Diagrama de Classes
Melhorar o entendimento do domínio e
reduzir os riscos de não identificar
requisitos do sistema
Um bom modelo inclui apenas
conceitos do domínio, excluindo
detalhes de projeto.
Análise de Requisitos x
Agentes Móveis
A análise de requisitos em um
desenvolvimento orientado a agentes é tal
qual em um sistema orientado a objetos.
Apenas a mobilidade real de entidades do
domínio da aplicação deve ser documentada,
caso exista, sem levar em consideração
nenhuma solução específica baseada em
mobilidade de código/dados.

Referências
Larman. Applying UML and Patterns.
Prentice Hall, 2002.
Rational Unified Process. On-Line
Collection.
Stevens & Pooley. Using UML –
Software Engineering with Objects and
Components. Addison-Wesley. 2000.
1.4 OMG UML