Análise e Gerenciamento de Requisitos com Casos de Uso

Módulo 2Introdução ao Gerenciamento de

Requisitos com Caso de Uso

Objetivos

• Definir os conceitos-chave da gerência de requisitos.• Identificar os fatores que contribuem para o sucesso ou

falha do projeto.• Descrever como o Gerenciamento de Requisitos

aumenta as chances de sucesso do projeto.• Definir as qualidades de um conjunto de requisitos.

– verificável, rastreável, não ambíguo.• Conhecer o Workflow de gerência de requisitos com

UP, papéis, e artefatos.

Algumas situações familiares…

Nós construímos tudo o que vc pediu!

Certo, mas não é o que eu quero

Por que vc não nos disse que queria aquela funcionalidade?

Você não perguntou!

Hummm... Eu acho que ele faz desse jeito!

Eu tive uma idéia para uma função nova, você deixa a gente colocá-la no sistema?

Sem problema!

Visão Geral

Sistema a ser

construído

Necessidades

Requisitos de Software

DesignProcedimentos de Teste

Docs do usuário

Características Domínio da Solução

Domínio do Problema

Rastreabilidade

ProblemProblema

Definições

• Requisitos– Uma necessidade do processo de negócio que o

sistema deverá sanar.

• Gerenciamento de Requisitos– Uma abordagem sistemática para:

• Detalhar, organizar, e documentar requisitos. • Estabelecer e manter acordos entre cliente / usuário e

equipe de projeto nas requisições de mudanças.• Controlar e registrar a evolução do atendimento aos

requisitos.

O que Requisitos de Software especificam?

Entradas Saídas

Funções

Requisitos nãofuncionais(Ex.: Performance)

Restrições de Design

(Ex.: Ambientes)

Sistema

DefiniçõesRequisições do StakeholderExpressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do steakholder.

Requisitos de SoftwareRequisito FuncionalDescrição das funções que os steakholders precisam que o software faça. Definem a funcionalidade desejada do software.Requisito não funcionalQualidades técnicas globais de um software, como manutenibilidade, usabilidade, desempenho e várias outras. Normalmente são descritos de maneira informal, controversa, e são difíceis de validar.

RestriçãoUma limitação no design do sistema ou nos processos usados para construir o sistema.

CaracterísticaUm serviço externamente observável, diretamente no sistema, que atende a um ou mais requisições do stakeholder.

Exemplo: Sistema de MatrículaRequisição do Stakeholder Precisa de menor despesa geral no registro. Professores precisam de acesso imediato a grade de aulas.

RestriçãoOpera no Main Frame DEC VAX da Universidade.

Requisito de SoftwareFuncionalO caso de uso começa quando o estudante seleciona a opção de menu “Matricular”. O sistema apresenta uma lista de cursos disponíveis…

Não-FuncionalDisponibilidade de 99% dos 24/7(3.65 dias off-line por ano)

CaracterísticaUma árvore de navegação para visualizar a grade de aulas, por semestre e por turma.

Caracterização das Definições

Based on Leffingwell & Widrig, 1999

Requisitos de Software

Restrições de Design

Requisitos Funcionais

Requisitos não funcionais

Tipos de Requisitos

Requisições do Stakeholder

Características

O queComo

Necessidades do Stakeholder

Características do Produto ou Sistema

Requisitos de Software

Especificação de Design Procedimentos de Teste Planos de Documentação

Requisitos existem em vários níveis

O queComo

O queComo

Gerência de Requisitos Não é Fácil• Requisitos:

– Nem sempre são óbvios.– Vêm de várias fontes.– Nem sempre é fácil de expressar claramente em

palavras.– São inter-relacionados e relacionados a outras

entregas do processo de desenvolvimento de software.

– Tem propriedades únicas.– Mudam.– São difíceis de controlar quando em grande

número.

Gerenciamento Requer Estratégia

RM Plan

Gerenciamento Efetivo de Requisitos

• Manter um claro estabelecimento dos requisitos requer: – Boa qualidade dos requisitos– Atributos aplicáveis para cada tipo de requisito– Rastreamento para outros requisitos e outros artefatos do

projeto

O OBJETIVO é entregar produtos de qualidade, no tempo e no orçamento, que atendam às reais

necessidades do usuário.

O que é um “Produto com Qualidade” ?

• Qualidade: Velhos Conceitos – Satisfaz os documentos de requisitos. – Passa nos testes de sistema.– Adere ao processo de desenvolvimento.

• Qualidade: Conceitos Modernos– Entende todas as necessidades do usuário. – Continuamente revisa todos os artefatos para

garantir que atendem às necessidades.

Paradigma baseado em Resultados Paradigma baseado em Resultados

Paradigma baseado em atividades Paradigma baseado em atividades

Dimensões de Qualidade

Componentes do FURPS+

FFunctionality Conjunto de características, segurança, e requisitos em geral

UU sability Fatores humanos, estéticos, consistência, documentação

RR eliability(Confiabilidade) Frequência / severidade

da falha, recuperabilidade, previsibilidade, MTBF (Mean Time Between Failures )

PPerformance Velocidade, uso de recursos, processamento, tempo de resposta

SS upportability

Testabilidade Extensível Adaptabilidade ManutenívelCompatibilidade Configurável

Disponibilidade InstalávelLocalizável Robustez

“No Prazo e No Custo”

Tempo

Quanto de trabalho nós

podemos fazer?

Recursos

Orçamento

ScopeScopeScopeEscopo

Atendendo às reais necessidades do cliente

Característica 1: O sistema deve...

Característica 2: O sistema deve

Característica 3: O sistema deve

Característica 4: O sistema deve

Característica 5: O sistema deve

Característica n: O sistema deve…

Como determinar prioridade?

O que é um baseline?

Como sabemos quais são as necessidades?

TempoData de Início

do ProjetoData-Alvo do Lançamento

Possibilitar acordo entre os envolvidos

Objetivos de sistema

VerificaçãoRequisitos

ClienteGrupo de Usuários

Sistema a ser construído

Requisitos

O Objetivo

Quais fatores contribuem para o sucesso do Projeto?

10. Outros aspectos9. Estimativas confiáveis8. Uso de métodos formais7. Requisitos básicos firmes

6. Infra de Software padronizada

5. Escopo controlado4. Objetivos Negociais claros

3. Gerente experiente2. Envolvimento do Usuário

1. Suporte da Gerência Executiva

Os Dez Motivos

28% dos projetos completados no prazo e custos.

49% dos projetos ultrapassam

as estimativas iniciais.- Tempo estoura em média 63%.- Custo ultrapassa em média 45%.

23% dos projetos são cancelados antes de sua conclusão.

Fatores de Sucesso

Standish Group, ‘99 (www.standishgroup.com)

Tamanho é importante

Taxa deSucesso

(%)

Standish Group, ‘99 (www.standishgroup.com)

Sucesso pelo Tamanho do Projeto

0

10

20

30

40

50

60

Tamanho do Projeto ($)

Menos de $750K

$750K a $1.5M

$1.5M a $3M

$3M a $6M

$6M a $10M

Mais de $10M

O alto custo dos Requisitos Errados

Custo relativo para reparar erros: Quando Introduzidos X Quando reparados.

100

2.5

5

10

25

.5 - 1Em tempo de Requisitos

Design

Codificação

Teste Unitário

Teste de Aceitação

Manutenção

“Os resultados mostram como corrigir erros

encontrados nos requisitos custa até 200 vezes menos do que em estágios mais avançados do ciclo de

vida”

Boehm 1988

A regra do 1-10-100

Ajuda para Projetos serem bem sucedidos

• Análise dos Problemas– Entender o Problema.– Obter o entendimento com os stakeholders.– Estabelecimento claro dos objetivos de negócio.

• Elicitação de Requisitos– Identificar quem utilizará o sistema (atores).– Elicitar como o sistema será usado (casos de uso).

• Gerenciamento de Requisitos– Especificar os requisitos de forma completa. – Gerenciar expectativas, mudanças, e erros.– Controlar quebra de escopo.– Listar todos os membros da equipe.

Qualidades do Conjunto de requisitos de software

• Correto– É a descrição correta sobre o que o sistema deve

fazer.

• Completo– Descreve todos os requisitos significantes para o

contexto do negócio e do usuário.

• Consistente– Não está em conflito com outros requisitos.

• Não ambíguo– Está sujeito a apenas UM entendimento.

Leffingwell & Widrig (1999). IEEE 830-1993, § 4.3.2, 1994

• Verificável– Pode ser testado sem grandes custos.

• Classificável por importância e estabilidade– Pode ser classificado por importância para o cliente e

estabilidade do requisito em si.• Modificável

– Mudanças não afetam a estrutura do todo.• Rastreável

– A origem de cada requisito pode ser apontada.• Claro

– Compreendido por usuários e desenvolvedores.

Leffingwell & Widrig (1999). IEEE 830-1993, § 4.3.2, 1994

Qualidades do Conjunto de requisitos de software

IEEE 830-1993, § 4.3.2, 1994

- O sistema suporta acima de 1000 usuários simultâneos.- O sistema deve responder a qualquer consulta em 500ms.- A cor deve ser um agradável verde sombreado.- O sistema deve estar disponível em 24 x 7.- O sistema deve exportar visões dos dados em formato texto, separado por vírgula de acordo com o leiaute...

Qualidades de um Requisito: Verificável

• Um requisito é verificável se: – É algo finito, em que uma pessoa ou máquina (com custo

viável) pode checar se o produto atende ao requisito definido junto ao usuário.

Estes requisitos são verificáveis?Se não, qual o melhor modo de definí-los?

Qualidades de um requisito: Rastreável

Requisições do Stakeholder

Características

SuplementarCasos de Uso

ref - IEEE 830

“A deve ir de B para C”

“A deve ir de B para C”

“A deve ir de B para C”

Qualidades de um Requisito: Não ambíguo

• O requisito é não ambíguo se tiver apenas uma interpretação.

Requisito A

Como realizar os requisitos.O Modelo de Design especifica componentes de um sistema ou suas interfaces com outros sub-componentes.

Como saber se os requisitos estão sendo atendidos.

Um caso de teste especifica uma forma de testar um cenário de caso de uso.

Quando os requisitos atendem.O Plano de desenvolvimento de software especifica cronograma, planos de verificação e validação, e planos de gerenciamento de configuração.

Design

Adapted from Alan Davis

O que NÃO é um Requisito?

Verificação

Dados deProjeto

Artefatos Usados para Gerenciar Requisitos

Onde o problema é definido?Onde os stakeholders e usuários são listados?Onde os ambientes e plataformas são identificadas?

Onde os casos de uso são mantidos?

Onde o vocabulário comum está descrito?

Visão

Especificações de Caso de uso

Glossário

Especificação Suplementar

Onde os requisitos não funcionais estão localizados?

Onde as Necessidades e Requisições dos stakeholders são capturadas?

Requisições do Stakeholder

Revisão: Introdução ao RMUC1. O que é um Requisito?2. O que é Gerenciamento de Requisitos?3. Que fatores contribuem para o sucesso do projeto?4. Quais membros da equipe são envolvidos na

Gerência de Requisitos e como?5. Saberia explicar a regra de 1-10-100?6. Quais são algumas das qualidades dos requisitos?7. Quais são alguns dos tipos de requisitos não-

funcionais?8. Por que usar UML?9. Por que usar um processo de desenvolvimento?