Você está na página 1de 4

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 Não refletir as reais necessidades dos
Requisitos não-funcionais clientes.
Requisitos de usabilidade Podem ser documentados de forma
inconsistente e/ou incompleta.
Mudanças
Desentendimentos
Técnicas para Elicitação Documento de Requisitos
Entrevista Resumo sobre o domínio da aplicação, a importância
do sistema para o negócio e os perfis dos potenciais
Leitura de documentos usuários
Questionários Requisitos Funcionais
Requisitos não-funcionais
Análise de protocolos
Restrições de hardware/performance
Participação ativa dos usuários Fronteiras/Interface com outros sistemas
Observações e análise sociais Arquitetura de Alto Nível (Preliminar)
! Física
Reuso de requisitos
! Modelo Conceitual
Glossário

Use Cases: Diagramação de


Validação de Requisitos
Requisitos Funcionais
Revisões Comportamento do sistema do ponto de
Prototipagem vista de seus usuários – qualquer
entidade externa que interage com o
Contrato com o cliente 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: Análise de Requisitos x
Diagrama de Classes Agentes Móveis
Melhorar o entendimento do domínio e A análise de requisitos em um
reduzir os riscos de não identificar desenvolvimento orientado a agentes é tal
requisitos do sistema qual em um sistema orientado a objetos.
Apenas a mobilidade real de entidades do
Um bom modelo inclui apenas domínio da aplicação deve ser documentada,
conceitos do domínio, excluindo caso exista, sem levar em consideração
detalhes de projeto. 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