Curso de Requisitos Módulo 02: Requisitos de Software Requisitos de Software, Técnicas de...

Curso de RequisitosMódulo 02: Requisitos de Software

Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas,

Necessidades e Principais Artefatos

Introdução à Gerencia de Requisitos: 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–A condição ou capacidade que o sistema

deve possuir.

• 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.

O que Requisitos de Software especificam?

Entradas Saídas

FunçõesRequisitos nãofuncionais(Ex.: Performance)

Restrições de Design

(Ex.: Ambientes)

Sistema

DefiniçõesRequisições do StakeholderUma expressão independente de solução de um estado desejado pelo stakeholder da solução ou sujeito ao domínio.

Requisitos de SoftwareRequisito FuncionalUm requisito que especifica, de uma perspectiva caixa-preta, como uma solução que interage com o mundo externo. Requisito não funcionalUm requisito que expressa, de uma perspectiva caixa-preta, os atributos de qualidade da solução.

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 de um Sistema de Registro em CursoRequisiçã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 o comando “register for course”. 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 de visualizar a grade de aulas, por semestre e por turma.

Caracterização das Definições

Based on Leffingwell & Widrig, 1999


Restrições de Design

Requisitos Funcionais

Requisitos não funcionais

tipos de Requisitos

Requisições do Stakeholder

Características

Propriedade medidaVelocidade trans. Devem proc. 5 segTamanho K bytesUsabilidade tempo de treinamento/ quadros de ajudaConfiabilidade tempo médio de falhas/ tx de ocorrencia de falhasPortabilidade sistemas operacionais utilizados

• Tipos de não funcionaisProduto : confiabilidade,segurança, desempenho, capacidade e portabilidade

Organização: métodos, linguagens e ferramenta ex.: linguagem livre

Externo : legado de dados q não pertence a organização, legislação

Requisitos de Domínio

• Características das regras de negócio do sistema

ex.: no Rup tem um repositório para descrever as regras

o cliente pode sacar no máximo 5 mil reais por dia

- o cliente pode retirar no máximo 3 vídeos por dia

- prazo entrega de no máximo de 3 dias para qualquer qtde pega

- para usar o TED só com valores acima de 5 mil

- o cadastro tem que ser renovado a cada ano

-

ter cuidado de não colocar validação

O queComo

Necessidades do Stakeholder

Características do Produto ou Sistema


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 porque…

• Requisitos: –Nem sempre são óbvios.–Vem de várias fontes.–Nem sempre é fácil de expressar claramente em

palavras.–São interelacionados e relacionados a outras

entregas do processo de desenvolvimento de software.

–Tem propriedades únicas ou valores de propriedade.

–Mudam.–São difíceis de controlar quando em grande

número.

Gerenciamento Requer Estratégia

RUCS10:RM Plan

RM Plan

Gerenciamento de Requisitos efetivo

• 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

As 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 atividades Paradigma baseado em atividades

Paradigma baseado em Resultados Paradigma baseado em Resultados

Dimensões de QualidadeComponentes do FURPS+

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

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

RR eliabilityFrequência/severidade da falha, recuperabilidade, previsibilidade,

acurária, MTBF

PPerformance Velocidade, uso de recrusos, throughput, tempo de resposta

SS upportability

Testabilidade Extensível Adaptabilidade ManutenívelCompatibilidade Configurável

Disponibilidade InstalávelLocalizável Robustez

On Time and On Budget

Tempo

Quanto de trabalho nós

podemos fazer?

Recursos

Orçamento

ScopeScopeScope

Escopo

Atendendo as reais necessidades do cliente

Característica 1: O sistema deve...

Característica 2: 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 um acordo entre os envolvidos

Objetivos de sistema

VerificaçãoRequisitos

ClienteGrupo de Usuários

Sistema a ser construído

Adapted from Al Davis

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 experiente

2. Envolvimento do Usuário

1. Suporte da Gerência Executiva

Os Dez Motivos

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

28% dos projetos são completadosno orçamento e prazo. 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

Tamanho é importante

0

10

20

30

40

50

60

Project Size ($)

less than $750K

$750K to $1.5M

$1.5M to $3M

$3M to $6M

$6M to $10M

Over $10M

Taxa deSucesso

(%)

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

Sucesso pelo Tamanho do Projeto

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

“All together, the results show as much as a 200:1

cost ratio between finding errors in the requirements and

maintenance stages of the software

lifecycle.”

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.

Envolvendo toda a Equipe com os Requisitos

• Desenvolvedores, Testadores, e Autores–Ajuda a desenvolveder as práticas de

gerenciamento de requisitos.–Monitora a aderência às boas práticas.–Verifica o processo de elicitação.–Documenta requisitos.–Participa das revisões sobre os requisitos.–Participa como membro do Comitê de Controle

de Mudanças (CCM).–Revisa as matrizes de rastreabilidade.–Verifica qualidade, testabilidade, e completude.

O resultado é pior quando a qualidade é baixa

??

?

?

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.

Qualidades do Conjunto de Requisitos (cont.)

• 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

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 IEEE.

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”



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 espefica componentes de um sistema ou suas interfaces com outros sub-componentes.

Como saber se os requisitos estão sendo atendidos.

Um Test Suite contém um conjunto de scripts de teste e logs de teste.

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

O que NÃO é um Requisito?

Verificação

Dados deProjeto

RUP: Um Framework para Gerência de Requisitos

Disciplina de Requisitos: Detalhes do Workflow

Papéis e Artefatos

Quais artefatos são usadosOnde 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

Onde estamos na disciplina de Requisitos?

Análise do Problema: Atividades e Artefatos

Análise do Problema• É o processo de entender os problemas

do mundo real, e como eles se relacionam com as necessidades dos stakeholders, e propor soluções para atender a estas necessidades.

• Qual o objetivo da Análise de Problemas?–Ter um melhor entendimento antes de

começar o desenvolvimento.–Identificar as causas-raiz.–Ajudar na identificação da solução.

• Evitar o: “Sim, mas…”–Minimizar o trabalho extra. Qual o problema

real?

Definição do ProblemaUm problema pode ser definido como uma

diferença entre as coisas como são percebidas e como são desejadas.

(Problema)

Percebido Desejado

Passos para a Análise do Problema

• Identificar os stakeholders.

• Entender as causas-raiz.

• Chegar a um entendimento sobre os problemas.

• Identificar as restrições do sistema e do projeto.

• Identificar e validar a solução em relação as causas-raiz.

• Definir a fronteira (escopo) do sistema.

Elicitar Requisitos

Expandir a lista de soluções do stakeholder.

Roadmap da Análise de Problemas

Escolher as melhores soluções para alcançar os

objetivos.

Melhor solução identificada

Problema validado/ajustado

Problema de Negócio Definido

Problema Atual identificado e definido

Identifique stakeholders para o problema.

Análise da Causa-Raiz.

Reavaliar qual é a melhor idéia de solução.

Entendimento dos Problemas no Contexto dos

Objetivos de Negócio.

Problema de

Negócio

Idéia de Solução ou

Oportunidade

Stakeholders: Definições

• Stakeholder –Um indivíduo que é materialmente afetados

por uma saída do sistema ou do projeto que está produzindo o sistema.

• Representante do Stakeholder–Um stakeholder representa um ou mais

stakeholders. Eles estão diretamente envolvidos na direção, concepção, e no escopo do projeto.

Identificar os Stakeholders• Cada grupo de stakeholders precisa de um

representante.

• Nem todos os grupos de stakeholders precisam ser consultados.–Vários irão fornecer os requisitos.

• Clientes, usuários, administradores do sistema

–Vários podem não fornecer requisitos.• Acionistas da empresa

Quem destes são stakeholders nos seus projetos?

Descrever Stakeholders no Documento de Visão

Stakeholder DigitadorRepresentante Kelly HansenDescrição UsuárioTipo O digitador é tipicamente um técnico com conhecimentos

em informática. O digitador é treinado e experiente no uso do atual sistema batch de registro.

Responsabilidades O digitador é responsável por administrar o cadastro de cursos para cada período letivo. Isto inclui a supervisão administrativa e de permissão de acesso aos dados.

Critério de Sucesso

Conseguir manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula.

Envolvimento A responsabilidade primária dos digitadores será manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula.Também será requerido da área de matrículas….

Entregas Gestor de Revisão – especialmente nas funcionalidades requisitadas pela área de Matrículas.

Comentários/ Preocupações

Nenhum

Quais problemas estão por trás dos problemas?

Técnicas do Diagrama de Espinha de Peixe

Liste as causas que contribuem para o problema detectado.Continue perguntando “Por que?” (expanda cada raia).

Problema de negócio que foi

percebido.

Sem banco à noite

Morosidade

Quer privacidade

quando sacar

Clientes insatisfeitos com nossos serviços.

Banco

s nos

aer

opor

tos

Mais

pon

tos d

e

aten

dimen

to

Filas g

rand

es e

lent

as

nas f

iliais

Análise do Problema – Validando a soluçãoTécnicas do Diagrama de Espinha de Peixe

Liste as razões que justificam a solução.Continue perguntando “Por que?” (expanda cada raia).

Solução percebida para os problemas.

Sem banco à noite

Morosidade

Quer privacidade

quando sacar

Mais Máquinas de Auto

Atendimento.

Banco

s nos

aer

opor

tos

Mais

pon

tos d

e

aten

dimen

to

Filas g

rand

es e

lent

as

nas f

iliais

Ben

efíc

ioB

enef

ício

EsforçoEsforço20%20%

80%80%

Foco nos que mais contribuem – Lei de Pareto

Classifique por ordem. Use a regra do 80-20 para focar nas principais causas responsáveis pelas grandes porções de problema.

20% do esforço originam em 80%

de benefício.

20% do esforço originam em 80%

de benefício.

Compreender o contexto maior do problema

• A falta de entendimento do negócio e seus objetivos aumenta o risco.

• O problema está em algum componente do processo/empresa?

• A equipe entende qual o domínio do problema?

• A solução do problema cria oportunidades de melhoria do processo?

Disciplinas de Modelagem de Negócio e Requisitos

Modelagem de Negócio Requisitos

Modelos de Negócio• Modelo de Organização estrutural e dinâmico.

–Processos de Negócio–Estrutura Organizacional–Papéis e responsabilidades

• Visualize a organização e seus negócios.

• Ajude a entender os problemas atuais.

• Identifique potenciais melhorias.

• Derive e valide os requisitos de sistema necessários à Organização.

Produtos Entregas Eventos

Descrever o problema no Documento de Visão

Especificações de Manual do Usuário

Especificações de Design

Requisições do

Stakeholder

Documento de Visão

Especificação SuplementarModelo de

Caso de Uso

Definição do Problema

Documento de Visão• As mesmas informações para gerência,

marketing, e equipe de projeto.• Fornece o feedback inicial do cliente.• Promove uma compreensão única do produto. • Define escopo e prioridade em alto-nível das

requisições do stakeholder e suas características.

• Um documento em nível de sistema que descreve o “que” e “porquê” do produto.

Visão

Estrutura do Documento de Visão

1. Introdução2. Posicionamento3. Descrições do Stakeholder e Usuário4. Visão Geral do Produto5. Características do Produto6. Restrições 7. Faixas de Qualidade8. Precedência e Prioridade9. Outros Requisitos do Produto10. Requisitos de Documentação11. Anexo 1 – Atributos das Características

Obtendo o Entendimento do ProblemaDescrição do Problema

Visão

O problema de (descreva o problema)

afeta (os stakeholders afetados pelo problema)

O impacto disto é que

(qual o impacto do problema)

Uma solução de sucesso seria

(listar vários benefícios-chave de negócio para uma solução de sucesso)

Identificar as Restrições

Econômicas

Técnicas

De ambiente

Sistêmicas

Políticas

Viabilidade

Identificar as melhores soluções de negócio

• Identificar as várias soluções para os problemas principais.–Técnico, não-técnico, ou ambos.

• Escolher a que:–Melhor resolve as causas-raiz.–Suporta os objetivos de negócio.

• Obter os requisitos que permitem implementar a solução.

Definir a fronteira da solução de sistema

ManutençãoComunicações Relatórios

Novo Sistema

Outros sistemas

UsuáriosSistemasLegados

Atores ajudam a definir a fronteira do sistema

PC

Fronteira do sistema?

ServidorPC

PC

PC

Quem é o ator? Os módulos do sistema ou o usuário?

Servidor

Usuário

PC

Capturando o Vocabulário comum do sistema

• Definir os termos usados no projeto.

• Ajudar a previnir mal-entendidos.

Glossário

Capturar o Vocabulário Comum

• Começar o mais cedo possível.

• Continua durante todo o projeto.

Visualize o Glossário como um modelo de Domínio

Cliente Acao Cliente. Transacao1..2 11..* *

Transacao geral TransferenciaLimite Credito

Curso de Requisitos Módulo 02: Requisitos de Software Requisitos de Software, Técnicas de...

Documents

Transcript of Curso de Requisitos Módulo 02: Requisitos de Software Requisitos de Software, Técnicas de...