PRDS 2008

Requisitos de Software e UML Básico

Janaína Horácio [e-mail] Agenda

• Requisitos
– O que é ?
– Objetivos?
– Atividades?
– ...

• UML
– O que é ?
– Modelos
– ...

• Casos de Uso
– O que é ?
– Componentes
– …
17/01/2008

Janaína Horácio © LES/PUC-Rio

2

Requisitos

• Descrição das necessidades ou dos desejos de um produto.
• É a parte mais crítica e propensa a erros no desenvolvimento de software
• Objetivo
– Identificar os requisitos que serão satisfeitos
– Documentar
– Facilitar a comunicação
17/01/2008

Janaína Horácio © LES/PUC-Rio

3

Requisitos
• O processo de Engenharia de Requisitos é composto por quatro atividades de alto nível (Soares, 2005):
– Identificação.
– Análise e negociação.
– Especificação e documentação.
– Validação.

17/01/2008

Janaína Horácio © LES/PUC-Rio

4

Requisitos
• Os seguintes artefatos são recomendados na fase de requisitos: – Um texto de visão geral
– Clientes
– Objetivos
– Funções do sistema
– Atributos do sistema

17/01/2008

Janaína Horácio © LES/PUC-Rio

5

Requisitos
• Onde Coletar os Requisitos?
– Fontes Humanas
– Ambiente onde o Sistema Funcionará
– Estudos de Viabilidade (técnica, financeira)
– Análises de Mercado
– Planos de Negócios
– Análise de Produtos Competidores
– Conhecimento do Domínio
17/01/2008

Janaína Horácio © LES/PUC-Rio

6

Requisitos
• Requisito Funcional
– A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz.

• Requisito Não-Funcional
– Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa e são difíceis de validar.

17/01/2008

Janaína Horácio © LES/PUC-Rio

7

Requisitos
• Uma boa especificação de requisitos deve ser:
– Clara e não-ambígua
– Completa
– Correta
– Compreensível
– Consistente
– Concisa
– Confiável
17/01/2008

Janaína