Agenda. Agenda. Gerência de Requisitos Estratégia Tecnologia da Informação Ltda 2

(1)

Gerência de Requisitos

(2)

Agenda

g

Requisitos na Engenharia de Software

Processo de Engenharia de Requisitos (E.R.)

C i ã E t di t d R i it

Comunicação e Entendimento de Requisitos Documentação de Requisitos Aceitação de Requisitos R t bilid d d R i it Agenda Rastreabilidade de Requisitos Consistência de Requisitos Agenda

(3)

Motivação

ç

3

Requisitos são a base para aferição da

qualidade

→ Todos os modelos de processo indicam a Gerência

de Requisitos como um passo inicialq p

3

A experiência mostra que o investimento em

qualidade de requisitos tem excelente retorno

→ Satisfação dos envolvidos

M t b lh

→ Menos re-trabalho → Maior produtividade

(4)

(5)

Definição de Requisito

3

Segundo o Dicionário Aurélio

→ (1) condição necessária para a obtenção de

certo objetivoj

• Um requisito para se ingressar no programa de

mestrado da UFG é ter um diploma de graduação reconhecido pelo MEC

→ (2) exigência legal

• Um requisito para se emitir uma carteira de

motorista para os brasileiros é ter 18 anos de idade ou mais

(6)

Um Requisito em Software é

3

(1) uma condição ou capacidade de que um

usuário necessita para resolver um problema

ou atingir um objetivo

→ O usuário necessita imprimir uma nota fiscal

3

(2) uma condição ou capacidade que precisa

ser atingida por um sistema para satisfazer

um contrato, norma, especificação ou algum

outro documento

→ Os cálculos efetuados pelo sistema devem ter

(7)

Requisito ou Restrição?

3

Requisitos costumam ser associados a

→ uma necessidade específica do usuário que o

sistema deve atender

• O sistema deve ser capaz de emitir boleto de

cobrança com código de barras

uma restrição que o projeto ou o produto

→ uma restrição que o projeto ou o produto

(sistema) dele resultante deve obedecer

• Tamanho máximo do código-objeto deve serTamanho máximo do código objeto deve ser

16Kbytes

3 A requirement is a statement of a system service

or constraint

(8)

Quem define Requisitos?

3

Todos os envolvidos (stakeholders) em um

projeto de software têm requisitos

→ Gerentes, diretores, desenvolvedores,Gerentes, diretores, desenvolvedores,

testadores, projetistas, etc.

→ Cada envolvido possui expectativas e → Cada envolvido possui expectativas e

necessidades que “o projeto ou o produto

(sistema) dele resultante deve obedecer”

( )

3

Requisitos devem refletir as necessidades

dos envolvidos e não apenas dos usuários

dos envolvidos, e não apenas dos usuários

(9)

Requisitos na Engenharia de Software

Requisitos definem

como o sistema será construído

Os recursos do projeto devem ser especificados em p j p

função dos requisitos que devem ser atendidos

o que o sistema deve fazerq

O problema que o software precisa resolver deve ser

entendido e representado em termos de requisitos

em que condições o sistema deve operar

O ambiente de operação e o comportamento que o p ç p q

sistema deve realizar devem ser claramente definidos como requisitos

(10)

Engenharia de Requisitos

A Engenharia de Requisitos (ER) pesquisa

abordagens para controlar requisitos

A disciplina de ER envolve diversos

processos

1) Elicitação (identificação)

)

ç

(

ç )

2) Análise (modelagem e negociação)

3) D

t ã (

ifi

ã )

3) Documentação (especificação)

4) Avaliação (validação)

(11)

Contexto da ER

Platão

Contexto da ER

O início é a parte

mais importante do trabalho

Aquisição de Sistema

Engenharia de Requisitos

(12)

Gerência de Requisitos

Erros em requisitos causam

atraso (ou cancelamento) da entrega do sistema software que não atende as necessidades dos

envolvidos envolvidos

Erros em requisitos são causados por

falta de compreensão falta de compreensão

mudanças descontroladas

A Gerência de Requisitos é responsável por A Gerência de Requisitos é responsável por

minimizar esses erros

Ela cuida da execução eficiente dos diversos ç

(13)

Problemas relacionados a requisitos

q

Sintomas Possíveis Causas Práticas Recomendadas Sintomas Possíveis Causas Práticas Recomendadas Não atendimento d id d Interpretação incorreta d i it bi üid d Modelagem Visual WYSIWYG das necessidades dos usuários

dos requisitos; ambigüidade; comunicação deficiente WYSIWYG Protótipos Produto sem qualidade Instabilidade ou insuficiência de requisitos Aprovação e Controle de Mudanças em Requisitos Prejuízos ou pendências judiciais q Mudanças no escopo do software Análise de impacto de Mudanças em Requisitos judiciais do software Mudanças em Requisitos

(14)

Taxonomias de Requisitos

q

3

Existem inúmeras classificações de requisitos

→ Muitas delas são incompatíveis entre sip

3

O importante é não omitir requisitos

As classes de requisitos devem englobar todas as

→ As classes de requisitos devem englobar todas as

possibilidades

Requisitos são inicialmente alocados ao

3

Requisitos são inicialmente alocados ao

Sistema de Informação

(15)

Exemplos de Requisitos de Sistema

p

q

3

O sistema deve

→ manter registros de materiais bibliográficos, incluindomanter registros de materiais bibliográficos, incluindo

livros, periódicos, jornais e revistas, vídeos e áudio, relatórios, slides, CDs e DVDs, ,

→ permitir consulta por título, autor ou ISBN → oferecer acesso via browser

→ oferecer acesso via browser

→ suportar pelo menos 20 transações por segundo

ser demonstrável para o público cliente da biblioteca

→ ser demonstrável para o público cliente da biblioteca

(16)

Tipos de Requisitos de Software

Requisitos Genéricos

Apresentam uma visão geral do sistema

O sistema deve manter registros de todos os materiais da

Locadora incluindo fitas de vídeo DVD e cartuchos de jogos Locadora incluindo fitas de vídeo, DVD e cartuchos de jogos

Requisitos Funcionais

Especificam a funcionalidade do sistema

O sistema deve permitir que o usuário procure uma fita por

título, diretor, ator, ou categoria de filme., , , g

Requisitos de Implementação

Definem como o sistema deve ser implementado Definem como o sistema deve ser implementado

(17)

Tipos de Requisitos de Software

Requisitos de Desempenho

São restrições sobre a velocidade de execução

O sistema deve atender pelo menos 10 transações por

segundo segundo

Requisitos de Usabilidade

Descrevem como o sistema deve ser usado

As funções disponíveis para o público devem ser

demonstráveis em menos de 10 minutos

Requisitos de Segurança

São restrições sobre o acesso e a guarda do software São restrições sobre o acesso e a guarda do software

O acesso ao sistema deve ser controlado por senha. A

(18)

Outras Taxonomias de Requisitos

3 Requisitos Funcionais

O que e quando o sistema deve realizar?

→ O que e quando o sistema deve realizar? → Existem diferentes modos de operação?

3 Requisitos de Documentação 3 Requisitos de Documentação

→ Qual a documentação que o sistema deve gerar? Para

quem? E em que formato?

3 Requisitos de Dados

→ Qual o formato utilizado para entrada e saída? → Os dados devem ser mantidos por qual período?

→ Qual a correção e precisão de cálculos necessárias?

R i it d I t f

(19)

Outras Taxonomias de Requisitos

3 Requisitos de Qualidade

→ em que grau os requisitos de qualidade referente à → em que grau os requisitos de qualidade referente à

eficiência, utilizabilidade, manutenibilidade, confiabilidade e portabilidade devem ser satisfeitos

3 Requisitos de Ambiente Físico 3 Requisitos de Ambiente Físico

→ Onde o sistema vai funcionar?

→ Será em apenas um local ou vários?p

→ Há restrições ambientais (ex: temperatura, umidade, etc)?

3 Fatores humanos (requisitos de uso)

Q i i t ? E i t dif t ti d

→ Quem vai usar o sistema? Existem diferentes tipos de

usuário? Algum tem necessidades especiais?

→ Há padrões de IHC?p

→ Qual o nível de experiência de cada usuário? → Que tipo de treinamento deve ser realizado?

(20)

Outras Taxonomias de Requisitos

3

Propriedades Emergentes

→ Requisitos do sistema que só aparecem quando q q p q

todos os subsistemas são integrados

• Confiabilidade • Manutenibilidade • Desempenho • Usabilidade • Segurança Restrição de Acesso

(21)

Dificuldades com Requisitos

3 Estabelecer uma compreensão homogênea na equipe de desenvolvimento

equipe de desenvolvimento

→ Equipe compreende técnicos e usuários envolvidos

3 Refletir as reais necessidades dos usuários e do negócio

→ Garantir consistência e/ou completitude

M difi i it já f d d

3 Modificar requisitos que já foram acordados

→ Isto vai acontecer!

3 Controlar custos de desenvolvimento de requisitos 3 Controlar custos de desenvolvimento de requisitos

→ de 15 a 40 por cento do orçamento e do cronograma

de desenvolvimento!

3 O que fazer?

(22)

Processo de Engenharia de Requisitos

3

Um Processo de Engenharia de Requisitos é

→ um conjunto de atividades estruturadas para

desenvolvimento de requisitos de sistemas q

→ Não há um “Processo Ideal”

• O Processo deve ser adequado para as • O Processo deve ser adequado para as

necessidades de cada organização

→ Idealmente os processos de requisitos e de → Idealmente, os processos de requisitos e de

projeto de software deveriam ser separados • Na prática isto é em geral impossívelNa prática isto é, em geral, impossível

(23)

Gerenciar Requisitos

Problema Espaço do Problema problema Necessidades Produto a ser construído Características ser construído Use-cases e requisitos Espaço da solução

Testes Design Doc. usuário

(24)

Gerenciamento de Requisitos

q

3 Acompanha a tradução das solicitações dos clientes e

usuários em um conjunto de necessidades e características usuários em um conjunto de necessidades e características (features) do sistema

→ Detalhados, por sua vez, em especificações de requisitos

funcionais e não-funcionais funcionais e não-funcionais

→ Estas especificações detalhadas são traduzidas em procedimentos

de teste, design e documentação do usuário

3 Garante a correspondência (traceability) entre produtos 3 Garante a correspondência (traceability) entre produtos,

permitindo

→ Avaliar o impacto em uma mudança de requisitos

A li i t f lh d t t d i it

→ Avaliar o impacto em uma falha de teste de requisitos → Gerenciar o escopo do projeto

→ Verificar se os requisitos estão sendo atendidos pela q p

(25)

O Processo de Engenharia de Sistemas

System requirements engineering System validation Architectural design engineering System integration Requirements

partitioning developmentSub-system

Software requirements

pa t t o g p

requirements engineering

(26)

O Processo de Engenharia de Sistemas

3 Engenharia de Requisitos de Sistema

→ Estabelece os requisitos para o Sistema de Informação de

f í l t d l id

forma compreensível para todos os envolvidos

3 Projeto Arquitetural

D õ i b i

→ Decompõe o sistema em subsistemas

3 Particionamento de Requisitos

→ Aloca requisitos aos subsistemas

3 Engenharia de Requisitos de Software

(27)

O Processo de Engenharia de Sistemas

3

Desenvolvimento de subsistema

→ Subsistemas de hardware e software são projetados p j

e implementados em paralelo

3

Integração de Sistema

→ Subsistemas de hardware e software são integrados

para formar o Sistema de Informação para formar o Sistema de Informação

3

Validação de Sistema

O Si t d I f ã é lid d l ã

→ O Sistema de Informação é validado com relação

(28)

Engenharia de Sistemas

g

O que é? Software é parte de um Quais são os passos? O que é? Software é parte de um

sistema. As demais partes também devem ser ser identificadas,

requisitos eliciados, analisados,

Quais são os passos?

Objetivos e requisitos operacionais são eliciados. Uma especificação é produzida e validada. Controle é requisitos eliciados, analisados,

especificados, modeladas e validadas.

produzida e validada. Controle é exercido sobre mudanças.

Qual o resultado?

Represen-tação do sistema Fornece

caracte-Quem faz? Engenheiros de

sistemas visam compreender os re-quisitos junto aos clientes/usuários.

tação do sistema. Fornece caracte-rísticas operacionais, funcionais, comportamentais e visão da

arquitetura quisitos junto aos clientes/usuários.

Por que é importante? “Não se

arquitetura.

Como assegurar que fiz corretamente? Elicie os

req isitos a alie os q anto à vê a floresta pelas árvores” requisitos, avalie-os quanto à

(29)

Motivação

ç

Nada é mais difícil e incerto do que Nada é mais difícil e incerto do que conduzir a introdução de uma nova ordem de coisas.

Machiavelli Machiavelli

(30)

Engenharia de sistemas

g

3

Objetivo

3

Objetivo

→

Analisar

P j t

→

Projetar

→

Organizar elementos de um sistema

3

Sistema pode ser

Serviço

→

Serviço

→

Produto

T

l i

que transforma ou

(31)

Objetivos em detalhes

j

Engenharia de Sistema

Colocar software em um contexto

→ Colocar software em um contexto → Atribuir um papel para software

C t ft d i l t

(32)

É importante entender o contexto

p

(fato)

Engenharia de Sistema

(fato) Inclui

Engenharia de Software

(33)

Linha do tempo

p

Engenharia de Sistema

(34)

Ênfase da Engenharia de Sistemas

g

3

Sistemas Educacionais

3

Sistemas de Segurança

S s e as de Segu a ça

3

Sistemas Políticos, ...

SISTEMAS BASEADOS EM COMPUTADOR (SBC)( )

(35)

Sistema baseado em computador (SBC)

p

C j t j d l t j bj ti

3 Conjunto ou arranjo de elementos cujo objetivo

beneficia-se

do processamento de informações

El t d SBC 3 Elementos de SBCs:

→ Software (programas, dados, documentos)

Hardware

Software

→ Hardware

→ Pessoas (usuários e operadores)

→ Bases de dados (coleção de informações) → Bases de dados (coleção de informações) → Documentação (descrição do sistema)

→ Procedimentos (define uso de cada elemento)

(36)

Engenheiro de Sistemas

g

3

Pode definir vários modelos: uma solução

completamente automatizada, uma

semi-automatizada ou uma não semi-automatizada

Influência relativa dos elementos (pessoas, software e hardware) varia conforme o modelo

(37)

SBC

Software é um dos elementos cujas interações

j

ç

realizam trabalho útil

Pessoas

Hardware

BD

Software

Procedimentos Procedimentos

(38)

Engenharia de Sistema (tipos)

g

( p )

3

SBC apóia

3

SBC apóia

→

Empresa comercial

E

h i d

d

ó i

Engenharia de processos de negócios

3

SBC é parte de

→

Produto

(39)

Exemplos

p

E

h i d

d

ó i

3

Engenharia de processos de negócios

→ Sistema de Informação para auxiliar o departamento

d l

de pessoal

→ SI para auxiliar o controle de estoque

SI ili d d li

→ SI para auxiliar o cadastro de clientes

3

Engenharia de produtos (produção)

→ Software de controle de automóvel → Software de controle de um robô → Software de central telefônica

(40)

Hierarquia da engenharia de sistemas

g

Visão do mundo Negócio ou produto (supermercado) Domínio de interesse Visão do domínio Visão do domínio (vendas) Elemento de sistema Visão de elemento (software de caixa) Engenharia Visão detalhada Engenharia de Software Visão detalhada

(41)

Sistema versus Software

Nã d i ã t d ft

3 Não se seduza por visão centrada em software

3 Considere todos os elementos do sistema antes de se concentrar no software

se concentrar no software

3 Sistemas complexos são uma hierarquia de macro elementos que também são sistemas

elementos que também são sistemas

3 Uma boa engenharia de sistemas inicia-se com uma clara compreensão do contexto — a visão do mundo clara compreensão do contexto a visão do mundo — e então progressivamente o foco se estreita até que os detalhes técnicos sejam compreendidos

(42)

Processo de Modelagem

Engenharia de Sistemas

g

3

Modelos são criados para ...

→

Definir e representar processos

→

Definir e representar processos

→

Representar suposições

→

Definir componentes exógenos e endógenos

→

Representar ligações

p

g ç

→

Comunicar o entendimento sobre o assunto

R i t

ã

tilh d

(43)

Simulação de sistemas

ç

3

Simulação envolve

3

Simulação envolve

→ Quais os dados (objetos do negócio)? → Quais os relacionamentos entre eles? → Como os dados fluem na empresa?

3

Por que simular?

→ Eliminar problemas reduzir custos → Eliminar problemas, reduzir custos

(44)

Engenharia de Processos de Negócios

N ó i

f ti

t

i f

ã

g

3

Negócio que efetivamente usa informação

3

Analisar e Projetar

→ Dados e relacionamentos (p. ex.: cliente e produto) → Softwares que transformam dadosq

→ Infra-estrutura tecnológica (hardware e software)

3

O que é preciso?

→ Definição da hierarquia

(45)

Linha do tempo

Engenharia de Processos de Negócios

p

Engenharia de Sistema

Planejamento estratégico de informação Análise de Área do Negócio

Engenharia de Software

(definição de requisitos de SI)

(46)

Hierarquia

q

Planejamento estratégico de informação

Empresa

Visão do mundo

área

Visão de domínio _{Análise de área de negócio}

Sistema de informação Visão de elementos Engenharia de ft Visão de elementos software

(47)

Visão de mundo

3 Planejamento estratégico de informação

ó é

→ Todo o negócio é visto como uma entidade → Identifica domínios (finanças, vendas, ...)

D fi d d i í i t d

→ Define dados visíveis a todos

→ Define relacionamento entre os dados

Define como fluem os dados entre domínios

→ Define como fluem os dados entre domínios → Define objetivos

Isola fatores de sucesso

(48)

Visão do domínio

A áli d á d ó i

3 Análise de área de negócio

→ Detalhes de dados

Requisitos funcionais

→ Requisitos funcionais

→ Identificados por domínio

→ Responde ao que é exigido em um negócio → Responde ao que é exigido em um negócio → Reduz o escopo do planejamento estratégico

3 Objetivoj

→ Isolar oportunidade de sistema de informação

(49)

Observação

ç

3

Engenheiro de software não se envolve

3

Engenheiro de software não se envolve

com

Pl j t E t té i d I f ã (PEI)

em geral

→ Planejamento Estratégico de Informação (PEI) → Análise de Área do Negócio (AAN)

3

Engenheiro de software envolve-se com

→ Definição de requisitos de SI (suporte ao ç q ( p

negócio)

Se não foram realizadas

Então o risco do projeto é muito alto!

(50)

Resumo

3

Planejamento estratégico de informação

Obj i é i

Visão do

Mundo _→ _{Objetivos estratégicos}

→ Fatores de sucesso

Mundo

→ Modelo da empresa é criado

3

Análise de área de negócio

Visão de

→ Serviços e processos são modelados

→ São estabelecidos relacionamentos entre eles

Domínio

(51)

Engenharia de produtos

g

p

T d i d j d li t d t

3 Traduzir desejos do cliente em um produto

3 Software, hardware, dados e pessoas (definir) 3 Infra-estrutura de suporte

→ Tecnologia para conectar componentes → Documentos, vídeos, ...

3 Visão de mundo

→ engenharia de requisitos

3 Visão de domínio

(52)

Hierarquia

q

P d t Engenharia de Produtos Produto Engenharia de requisitos Visão do mundo software hardware Engenharia de componentes dados pessoas Visão de domínio função

dados _{Comportamento} Análise

Projeto Visão de elementos Engenharia de software Projeto Construção Construção Visão detalhada

(53)

Problema em aberto

3

Como assegurar que a especificação do

sistema atende as necessidades dos clientes?

3

Engenharia de Requisitos

i d li d j

Mecanismos para entender o que o cliente deseja, analisar necessidades, avaliar a exeqüibilidade, negociar uma solução razoável

negociar uma solução razoável, especificar solução não-ambígua,

validar a especificação e gerenciar requisitos

Software Requirements Engineering Thayer and Dorfman, IEEE Press 1997 IEEE Press, 1997

(54)

Eliciar requisitos

q

Nã é i l ? 3 Não é simples?

→ Basta perguntar ao cliente, ao usuário, ...

e registrar as informações obtidas

→ e registrar as informações obtidas

3 Por que é difícil?

Fronteiras do sistema mal definidas

→ Fronteiras do sistema mal definidas

→ Clientes não estão seguros do que precisam

→ Clientes não entendem as capacidades e limitações do p ç

ambiente computacional

→ Clientes omitem informações “óbvias”

Cli t ifi i it t ditó i t

(55)

Eliciar requisitos

q

E i t

di t i

li i

t i

bl

3

Existem diretrizes para eliminar tais problemas

→ Avaliar a viabilidade técnica

→ Identificar pessoas que conhecem a organização → Identificar restrições, ...

3

Existem métodos

→ IBIS, JAD, CORE, QFD, SSM, FAST, ..., , , , , ,

Issues in Requirements Elicitation

Mi h l G Ch i t l & K C K

Michael G. Christel & Kyo C. Kang

(56)

Análise e Negociação de Requisitos

g

ç

q

3 Após coletados, os requisitos são analisados

→ Categoriza e organiza em subconjuntos → Valida relacionamento com outros

→ Examina requisito quanto à consistência

V ifi i õ bi üid d

→ Verifica omissões e ambigüidade

→ Classifica (risco, prioridade, custo, ...)

A ó li d i it ã i d

3 Após analisados, requisitos são negociados

→ Conflitos

P i id d

(57)

Análise e Negociação de Requisitos

g

ç

q

Engenharia de Requisitos

3

Perguntas e respostas obrigatórias

→ Cada requisito é consistente com o objetivo do

produto? p

→ Todos os requisitos foram especificados? → Todos são necessários ao objetivo?

→ Todos são necessários ao objetivo?

→ Quem deu origem ao requisito? Há conflitos?

Cada requisito é viável tecnicamente no

→ Cada requisito é viável tecnicamente no

ambiente em que será desenvolvido? Cada requisito pode ser testado?

(58)

Especificação de Requisitos

p

ç

q

E

ifi

ã

d

i t d

i

3

Especificação pode ser registrada via

→ Documento escrito → Modelo gráfico

→ Modelo formal

→ Coleção de cenários (casos de uso) → Protótipo ou combinação destes

3

Modelo de especificação pode ser seguido

(59)

Validação de Requisitos

ç

q

3

Avaliação da qualidade

→ Padronização da especificaçãoç p ç → Adequação aos propósitos

3

Equipe de revisão inclui

3

Equipe de revisão inclui

→ Engenheiros de sistema, clientes, usuários, ...

Ch kli

d

3

Checklists devem ser empregadas

→ Tornam o trabalho mais objetivo → Evitam omissões

(60)

Gerência de Requisitos

q

3

Identifica, controla e acompanha alterações

nos requisitos em qualquer momento do projeto

3

Para isto é preciso

Identificar unicamente cada requisito

→ Identificar unicamente cada requisito → Estabelecer conexões

Clientes X Requisitos

• Clientes X Requisitos

• Requisitos derivados X Requisitos geradores

Classificação (categoria) X Requisitos

(61)

Requisitos, segundo Brooks

q

, g

A parte mais difícil da construção de um

sistema de software é decidir o que construir.

N h

t

t t d

Nenhuma outra causa tantos danos

se feita de forma errada.

h

é i difí il d

i i

Nenhuma outra é mais difícil de corrigir.

Frederick Brooks

No Silver Bullet: Essence and Accidents of Software Engineering No Silver Bullet: Essence and Accidents of Software Engineering IEEE Computer, vol 20(4), 1987, pp. 10-19

(62)

Especificação de sistema

p

ç

P d t fi l d h i d i it 3 Produto final da engenharia de requisitos 3 Base para engenharia de software

3 Para um sistema baseado em computador

→ Descreve funções

Descre e o desempenho

→ Descreve o desempenho → Descreve restrições

3 Delineia cada elemento de sistema 3 Delineia cada elemento de sistema

3 Descreve dados e controle que servem de entrada e saída do sistema

(63)

Modelagem de sistema

g

3

Para especificar é preciso um modelo

→ Software pode ser modelado como entrada-p

processamento-saída

3

Outras visões pode ser acrescentadas

→ Interface com o usuário

Manutenção e teste

→ Manutenção e teste

→ Visão orientada a objetos

Um modelo fornece uma “grande fotografia” do que construir. Nem todo detalhe precisa ser especificado. p p

(64)

Resumo

3 Sistema de Informação inclui pessoas, software, e hardware

3 Engenharia de sistemas ajuda a traduzir as

necessidades do cliente em um modelo de sistema 3 Inicie com a visão do mundo

3 Especialize esta visão naquela do domínio

3 Cada elemento é tratado pela sua engenharia

3 A engenharia de sistemas produz a

Especificação

3 A engenharia de sistemas produz a

Especificação

(65)

Documento de Requisitos

U

d E

h i d

d i

3

Um processo de Engenharia deve produzir um

Documento de Requisitos

→ Artefato (formal?) para definição dos requisitos

3

É uma ferramenta usada para comunicação

entre usuários, desenvolvedores e gerentes

Deve contemplar os requisitos de todos os

→ Deve contemplar os requisitos de todos os

envolvidos (stakeholders) e não apenas dos usuários diretos

(66)

Conteúdo do Documento de Requisitos

3

Deve descrever uma visão geral do sistema

3

Deve descrever uma visão geral do sistema

→ regras de negócio atendidas pelo sistema

serviços e funções que o sistema deve prover

→ serviços e funções que o sistema deve prover → propriedades e restrições para sua operação

definições de interfaces e integração

→ definições de interfaces e integração

→ informações sobre o domínio de aplicação

t i õ b d

→ restrições sobre os processos usados para

desenvolver o sistema

descrição do hardware em que o sistema irá

(67)

Conteúdo do Documento de Requisitos

3

O documento deve conter

3

O documento deve conter

→

Introdução

• Visão geral do sistema

• Necessidades de negócio suportadas peloNecessidades de negócio suportadas pelo

sistema

Glossário

→

Glossário

(68)

Usuários do documento de requisitos

q

3 Clientes do sistema

→ especificam os requisitos e lêem o documento para

verificar que eles correspondem às suas necessidades 3 Gerentes de Projeto

→ usam o documento para planejar o processo de

d l i

desenvolvimento

3 Desenvolvedores e Mantenedores

→ usam o documento para compreender o sistema

3 Testadores

(69)

Proposta de Estrutura do documento

3 IEEE/ANSI 830-1998IEEE/ANSI 830 1998 3. Requisitos específicos 1. Introdução

→ Propósito do documento,

q p

→ abrangendo requisitos

funcionais, não funcionais e de interface

escopo do produto,

definições, acrônimos e siglas, referências e visão

de interface 4. Apêndices → documentos complementares, geral do restante do documento 2. Descrição Geral

normas, leis, etc.

5. Índice 2. Descrição Geral

→ Perspectiva do produto:

funções, características dos usuários restrições dos usuários, restrições gerais, hipóteses e

(70)

Resultado da Engenharia de Requisitos

g

q

Especificação de Requisitos de Software

Na ausência de tal documento, bem escrito:

• desenvolvedores não sabem o que construir clientes não sabem o que esperar

(71)

Especificação de Requisitos

3

Requisitos são geralmente escritos em

linguagem natural suplementados por

diagramas e equações

g

q ç

→ Figuras complementam, mas não especificam

requisitos! requisitos!

3

Alguns problemas

uso de condições complexas e confusas

→ uso de condições complexas e confusas → terminologia inconsistente e ambígua

redatores supõem que leitores conhecem o

→ redatores supõem que leitores conhecem o

(72)

Propostas para Especificação de Requisitos

3

Requisitos são mais lidos do que escritos

→ invista na elaboração de requisitos legíveis e

compreensíveisp

→ não suponha que o leitor tem o mesmo nível de

conhecimento que o redator do documentoq

→ requisitos devem descrever o problema (caso

contrário se transformam em restrições)ç )

→ aloque tempo para revisão e re-elaboração do

documento documento

(73)

Diretivas para especificação

D fi

t d

t

l

ti

d

3

Defina um meta-documento ou algum tipo de

padrão para descrição de requisitos

→

a IEEE 830 pode ser um ponto de partida

3

Use uma linguagem simples consistente e

3

Use uma linguagem simples, consistente e

concisa

ã

h

l it

t

i l i

→

não suponha que o leitor use a sua terminologia

3

Faça revisão e garantia da qualidade da

g

especificação

→

a qualidade do produto depende disso!

→

a qualidade do produto depende disso!

(74)

Diretivas para especificação

S l

t

li

t

l

t

3

Suplemente a linguagem natural com outras

descrições dos requisitos

→

use diagramas de maneira apropriada

(complementando, não substituindo texto)

(

p

,

)

• fórmulas e exemplos são úteis

3

Especifique requisitos quantitativamente

3

Especifique requisitos quantitativamente

(75)

Processos em Engenharia de Requisitos

3

Um processo é um conjunto organizado de

atividades para transformar entradas em

saídas

3

Descrições de processos encapsulam

3

Descrições de processos encapsulam

conhecimento e permitem a sua reutilização

Exemplos de descrições de processos

→ Exemplos de descrições de processos

• Manual de Instrução da máquina de lavar

Livro de receitas

• Livro de receitas

• Manual de procedimentos bancários

Manual da qualidade para desenvolvimento de software

(76)

Processo de Engenharia de Requisitos

g

q

Sistemas Existentes Especificação Processo de Engenharia Necessidades de Usuários Padrões Requisitos Acordados Especificação do Sistema Engenharia de Requisitos Padrões Organizacionais

Leis, Normas e , Modelos do Regulamentos

Informações do D í i

Sistema

3 Envolve criatividade, capacidade de abstração, interatividade

com um grupo heterogêneo de pessoas visão de engenharia

Domínio

com um grupo heterogêneo de pessoas, visão de engenharia, experiência e conhecimento do problema

(77)

Requisitos no Modelo Cascata

Systemy System requirements specification requirements

engineering _{Softw are} requirements

engineering

S f

Softw are requirements specification

Softw are design specification Softw are

design

Programming and unit testing

Executable software system

Completed system System testing System operation Completed system operation

(78)

Requisitos no Modelo Espiral

Informal statement of requirements

Decision point: Accept document or re-enter spiral

Requirements elicitation _{Requirements analysis and} negotiation Agreed requirements Requirements document and validation report S TART Requirements documentation Requirements validation

(79)

Requisitos no Modelo de Prototipação

AC TIONS Understand problem Establish outline requirements Select prototyping system Develop prototype Evaluate prototype Req. engineer

Domain expert Req. engineer_{End user}

Softw are

engineer Req. engineer_{Softw are}

End-user Domain expert

RO LES

o e pe

End-user End-user Project manager

So w e

engineer Req. engineer Software engineer

(80)

Cuidados no processo de E R

Cuidados no processo de E.R.

3

O processo de E.R. deve garantir que não haja

p

g

q

j

→ Falta de envolvimento dos clientes ou dos técnicos → Omissão de necessidades do negóciog

→ Conflitos de linguagem → Requisitos q

• Ambíguos não mensuráveis inconsistentes • Incorretos implícitos incompletos

→ Falta de gerência de requisitos

• Responsabilidades indefinidas

(81)

Caso de Sucesso Taj-Mahal

j

Produto

Desenvolver

Desejo

Eliciar Shah Jehan requisitos Shah Jehan

(82)

Situação típica

p

Sobre as orelhas.

Ok orelhas.

(83)

O que é comum e indesejável?

q

j

Estou aqui para coletar os Estou aqui para coletar os

requisitos, levará só 30 minutos!

O sr Está O sr. Está

de acordo? _{Sim, não é o que} combinamos?

(84)

9 meses depois de muito esforço e

p

ç

atrasos ...

Ficou pronto!!??

_O

_{é i}

_?

(85)

Como evitar esta situação?

ç

Qual foi o

problema?

(86)

Entender o problema é o primeiro passo

p

(87)

Quais as reais necessidades?

Q

Engenheiro de requisitos Cliente (Usuário)

(88)

Eliciar requisitos

q

Não há o que capturar,

Você se sente melhor, hoje?

Não há o que capturar,

tem-se que eliciar!

_{Não sei doutor,}

sinceramente sinceramente.

Resultado só

ocorre após

várias sessões!

(89)

Definindo o sistema

Cuidado!

Trecho com alto índice de acidentes! E R

Solução

Problema

E.R

Solução

Problema

(90)

O que os “bons” fazem?

q

í

3 Usam modelos compreensíveis

(DFDs, DTEs, OO, ...)

3 Portal web interno acessível aos 3 Portal web interno acessível aos

interessados

3 ER executada em várias rodadas 3 Protótipos

3 Alocação de 15% a 40% do esforço total

para ER para ER

3 Revisões constantes com os usuários 3 Integração de processos (técnico e g ç p (

(91)

Atividades do Processo de E.R.

Gerência

Elicitação Negociação

e Análise Documentação Validação

Aspirações dos Clientes Documento de Requisitos Requisitos Clientes, Conhecimento do Domínio, Sistemas q Modelos do Sistema Requisitos Acordados Sistemas Existentes, Leis e

Normas, e mais ... _Aquisição Desenvolvimento / Manutençãoç

(92)

Ferramentas de suporte

p

3

Ferramentas CASE automatizam muitos

d E

h i d S ft

processos da Engenharia de Software

→ No entanto, o apoio à E.R. ainda é limitado devido à

informalidade e a variabilidade do processo informalidade e a variabilidade do processo

3

Há duas grandes classes de ferramentas

→ Ferramentas de Modelagem e Validação

• apóiam o desenvolvimento de modelos para especificação

do sistema e a verificação da completitude e da do sistema e a verificação da completitude e da consistência desses modelos

→ Ferramentas de Gerência → Ferramentas de Gerência

(93)

Teoria x Prática

Supostos benefícios

Algumas referências sobre Engenharia de Requisitos

Propostas teóricas

Realidade constatada

(94)

Arquitetura de CASE para E.R.

Browser de Sist. Consulta

Documento de Conversor de Req. a Req. Sist Rastreament BD d Req. em Ling. Nat. Conversor de Req. / Sist. Rastreament. Req. Relat de BD de Requisitos Conversor p/ Proc.Texto Relat. de Rastreabilidade Ger.Relatório Sist. Contr. Mudanças Relat. de Requisitos

(95)

Elicitação de Requisitos

3 A identificação de requisitos começa quando

se reconhece que existe um problema que necessita de uma

ç

q

→ se reconhece que existe um problema que necessita de uma

solução

→ surge uma idéia ou necessidade novag

3 Técnicas para descoberta e compreensão de requisitos

→ Etnografia, Análise de Tarefas, Análise de Cenários → Etnografia, Análise de Tarefas, Análise de Cenários → Projeto Centrado no Usuário, Ergonomia, Semiótica

→ Técnicas de Reunião, Projeto Participativo (JAD, FAST), j p ( , ) → Workshops, Entrevistas, Questionários, Problem Frames → Teoria de Agentes, Prototipação, Brainstormg p ç

(96)

Barreiras na Elicitação de Requisitos

3

Há dificuldades de

ç

q

3

Há dificuldades de

→ comunicação com o usuário

→ entendimento completo do problema → negociação de interesses conflitantes → organização das informações

→ controle de mudanças → controle de mudanças → trabalho em equipe

validação dos requisitos

(97)

Exemplo: Aeroporto de Denver

p

3 O aeroporto tem área para aterrissagem de 3 jatos ao p p g j

mesmo tempo

→ O sistema de controle de bagagem teria uma esteira de 29 km com

capacidade de transportar as bagagens de 20 companhias aéreasp p g g p

→ Este sistema seria controlado por 100 computadores ligados em

rede, 5000 sensores eletrônicos, 400 receptores de radio, 56 leitoras de código de barra

→ Tudo orquestrado para enviar as bagagens aos seu destino de

forma segura, correta e rápida através de carrinhos inteligentes

3 Data programada de inauguração: Out/1993p g g ç

3 Valor do contrato do Sistema: US$ 234 milhões 3 Custos do atraso: US$ 1 milhão/dia

I ã d A t F /1995 ( i t d

3 Inauguração do Aeroporto: Fev/1995 (com o sistema de

bagagem provisório)

(98)

Razões do Insucesso

3 Problema principal: escopo e requisitos mal definidos e instáveis 3 Foram desperdiçados cerca de $193 milhões

3 Foram desperdiçados cerca de $193 milhões

→ O atraso por dia gerava custos de 1 milhão em juros e custos operacionais → A empresa desenvolvedora do sistema (BAE) não tinha previsão de

quando o sistema estaria em funcionamento quando o sistema estaria em funcionamento

3 Na implantação verificou-se

→ a falta de funcionalidades que não foram previstas no levantamento de

requisitos requisitos

→ funções que foram definidas, mas não operavam corretamente

3 A BAE, líder mundial em sistemas de bagagens, propôs um prazo

inicial de 4 anos inicial de 4 anos

3 Prazo contratual, estabelecido por exigência do cliente, foi de 2 anos

→ Durante o desenvolvimento foram realizadas 17 grandes alterações nos

requisitos, uma delas com custo de $ 100 milhões requisitos, uma delas com custo de $ 100 milhões

(99)

Fatores Humanos na E R

Fatores Humanos na E. R.

3 A E.R. reúne uma diversidade de papéis

→ Alguns estão mais interessados no problema a ser

resolvido, outros na solução que será proposta

Desenvolvedores e seus gerentes usuários e seus gerentes

• Desenvolvedores e seus gerentes, usuários e seus gerentes,

agentes reguladores externos, especialistas no domínio, ...

3 O sucesso do processo depende de fatores sociais eO sucesso do processo depende de fatores sociais e organizacionais

→ Diversidade de conhecimentos, de terminologia e de , g

objetivos individuais e organizacionais

→ Personalidade e status de cada ator no processo → Influência política de cada ator na organização → Influência do grupo em indivíduos

(100)

Comunicação Desenvolvedor X Usuário

ç

Visão dos Desenvolvedores _{Visão dos Usuários}

D l d ã

3 Usuários não sabem o que

querem

3 Desenvolvedores não

entendem as necessidades operacionais

3 Usuário pedem sem

necessidade

3 Usuários não conseguem

3 Desenvolvedores colocam

muita dificuldade em qualquer pequena solicitação

3 Usuários não conseguem

transmitir o que eles querem

3 Usuários têm muitas

p q ç

3 Desenvolvedores querem

definir o que os usuários devem fazer 3 Usuários têm muitas necessidades puramente políticas U á i ã b devem fazer 3 Desenvolvedores não conseguem transformar necessidades em um sistema

3 Usuários não sabem necessidades em um sistema

(101)

Comunicação Desenvolvedor X Usuário

ç

Visão dos Desenvolvedores Visão dos Usuários

3

Usuários se recusam a

t

bilid d

3

Desenvolvedores estão

t

d

ter responsabilidade

pelo sistema

U á i

ã

tã

sempre atrasados

3

Desenvolvedores

i

3

Usuários não estão

compromissados com

o projeto

sempre querem mais

tempo e menos esforço

D

l d

ã

o projeto

3

Usuários mudam de

idéia e não

3

Desenvolvedores são

incapazes de atender

rapidamente as

idéia e não

permanecem dentro do

planejamento

rapidamente as

necessidades de

modificação

planejamento

modificação

(102)

Técnicas de Análise e Documentação

ç

3 Envolvem representação, verificação e validação de i it

requisitos

→ Métodos formais (VDM, Z, Lógica)

Mé d d

→ Métodos estruturados

→ Métodos Orientados a Objetos

3 Dificuldades

→ Classificar requisitos e estabelecer prioridades → Detectar, negociar e resolver conflitos

→ Identificar os limites do sistema e como ele deve interagir

bi t com o seu ambiente

(103)

Especificação de Software

p

ç

3 Especificações são definições que descrevem várias perspectivas do software

→ visão macroscópica: Especificação de Requisitos representações intermediárias: Artefatos de Design → representações intermediárias: Artefatos de Design → visão detalhada: Código de Programas, DDL, etc.

3 Uma especificação de requisitos devep ç q

· ser a base para o desenvolvimento

· permitir o controle da qualidade do produto · permitir o controle da qualidade do produto

· estabelecer a comunicação entre o pessoal envolvido no projeto auxiliar no entendimento do problema

· auxiliar no entendimento do problema · validar o design e o produto resultante

(104)

Especificação de Requisitos

p

ç

q

3 Descrição textual

→ descrição dos dados, relações e funções do sistema

3 Modelagem através de métodos específicos

S ft i l

→ Software convencional

• Diagrama de fluxo de dados

• Diagrama entidade relacionamentog • Diagrama de transição de estados → Software orientado a objetos

Di d d

• Diagrama de casos de uso • Diagramas de classes

• Diferentes de transição de estadoç

(105)

Tratamento de Requisitos

(106)

Tratamento de Requisitos

q

3 O slide anterior mostra uma visão geral (etapas) do workflow de Requisitos 3 O slide anterior mostra uma visão geral (etapas) do workflow de Requisitos

→ As atividades da etapa “Analyze the Problem” serão mostradas em destaque no

próximo slide

3 Os objetivos deste workflow sãoOs objetivos deste workflow são

→ Estabelecer e manter o entendimento entre clientes e outros stakeholders sobre o

que o sistema deve fazer e porquê

→ Prover aos desenvolvedores do sistema um melhor entendimento dos requisitos

do sistema do sistema

→ Definir os limites do sistema

→ Prover uma base para o planejamento do conteúdo técnico das interações, e para

a estimativa de custo e tempo para desenvolver o sistema

→ Definir uma interface para o usuário enfatizando suas necessidades e objetivos

3 Para atingir estes objetivos, este workflow descreve como definir uma visão

do sistema e traduzir a visão em um modelo de casos de uso que, com as especificações suplementares define os requisitos detalhados do sistema especificações suplementares, define os requisitos detalhados do sistema

(107)

Atividades da Disciplina de Requisitos

O slide mostra as atividades e papéis envolvidos na execução deste workflow N d t No destaque as atividades envolvidas na etapa “Analisar o Problema” Analisar o Problema Problema O agrupamento destas atividades para a

execução desta etapa, juntamente com os papéis e artefatos l i d ã relacionados são mostrados no próximo slide

(108)

Detalhamento de “Analisar o Problema”

Para cada uma das atividades o processo fornece os passos que fornece os passos que devem ser seguidos Por exemplo, para a atividade “Encontrar atores e casos de uso” os passos são:

Encontre atores -Encontre atores

-Encontre casos de uso -Descreva como atores e casos interagem e casos interagem -Empacote casos e atores -Apresente o Modelo em diagramas de casos

(109)

Documento de Visão

Define o Escopo

9Qual é o problema que queremos resolver com o produto? 9 Quais são as causas para que o problema exista?

9 Quais são as causas para que o problema exista? 9 Como o problema afeta os envolvidos no projeto? 9 Quem são os usuários do sistema?

9 Quais os benefícios que o produto trará para os usuários? 9 Porque o produto precisa se desenvolvido?

9 Quem será afetado pelos produtos do sistema? 9 Quem será afetado pelos produtos do sistema?

9 Quem irá avaliar e aprovar o sistema quando ele for implantado? 9 Existe algum outro usuário interno ou externo cujas necessidades g j também serão atendidas?

(110)

Requisitos obscuros exigem ciclo evolutivo

q

g

Concepção Elaboração Construção Transição Fase

Preliminar Elab#1 Elab#2 Const_#1 Const_#2 Const_#N Trans_#1 Trans_#2

Iteração

tempo

Escopo Arquitetura Primeira Release Escopo Arquitetura Primeira Release

versão do Produto operacional

(111)

Ciclo de Vida Evolutivo – Fase de Concepçãopç

¾ b l d j di d li i

¾ Estabelecer o escopo do projeto e as condições de limite, incluindo uma visão operacional, critérios de aceitação, o que faz parte do produto e o que não faz

¾ Identificar os processos críticos do sistema, os cenários básicos de operação que conduzirão os principais compromissos de design

¾ Mostrar pelo menos uma arquitetura candidata de suporte a alguns destes cenários

¾ Estimar o custo e o cronograma para todo o projeto

¾ Estimar os riscos potenciais e fontes de imprevisibilidade

(112)

Ciclo de Vida Evolutivo – Fase de Elaboração

¾ Assegurar que a g q arquitetura, os requisitos e planosq , q p estão estáveis

¾ Garantir que os riscos foram suficientemente mitigados

¾ Tratar os riscos significativos do ponto de vista de arquitetura

¾ Produzir um odu u protótipop o ó po

(113)

Ciclo de Vida Evolutivo – Fase de Construção

¾ Minimizar os custos de desenvolvimento otimizando os recursos e evitando re-trabalho

¾ Produzir versões “úteis” (alfa, beta e outras de teste)

¾ G i i d i id d i id d

¾ Garantir qualidade com produtividade e praticidade

¾ Completar a análise, design, desenvolvimento e testes de todas f i lid d i it d

as funcionalidades requisitadas

¾ Desenvolver interativa e incrementalmente uma aplicação completa pronta para ser entregue à comunidade usuária

completa, pronta para ser entregue à comunidade usuária

¾ Decidir se a aplicação, os sites e os usuários estão todos prontos para receber a aplicação

para receber a aplicação

¾ Conseguir algum grau de paralelismo no trabalho das equipes de desenvolvimento

(114)

Ciclo de Vida Evolutivo – Fase de Transição

¾ Disponibilidade do beta teste para validação do novo sistema em função das expectativas do usuário

¾ Disponibilidade do beta teste e operação paralela com relação ao legado que está sendo substituído

¾ Conversão do banco de dados operacional

¾ Treinamento dos usuários e da equipe de manutenção

¾ Iniciativas de marketing, distribuição e força de venda

¾ A i id d d j i ã d lh i d

¾ Atividades de ajuste tais como correção de erros, melhoria de desempenho e usabilidade

¾ A li ã d d t t d d ité i d

(115)

Critérios de Sucesso para o Ciclo Evolutivo

Recursos di í i

Produto suficientemente maduro para os clientes

Aceite dos usuários disponíveis

para a próxima fase

Aceite dos usuários ou fim do ciclo de vida

Concepção Elaboração Construção Transição

tempo

Escopo Arquitetura Primeira Release versão do Produto operacional

Entender o problema

Entender a solução Tem uma solução Entender a solução Tem uma solução

(116)

Exemplos de boas práticas de E. R.

3 Definir uma estrutura de documento padrãoDefinir uma estrutura de documento padrão 3 Definir precisamente termos básicos

3 Usar cenários para eliciar requisitos

3 Identificar univocamente cada requisitoq 3 Especificar requisitos quantitativamente

3 Usar listas de verificação para análise e validação 3 Estabelecer políticas para gerência de requisitosp p g q

(117)

Exemplos de boas práticas de E. R.

p

3 Reutilizar requisitos de outros projetos 3 Melhorar continuamente o processo

3 Entender o problema antes de começar a documentar p ç modelos

3 Desenvolver protótipos que auxiliem ao usuário p p q visualizar como seus requisitos serão atendidos

3 Registrar a origem e a justificativa de cada requisitoRegistrar a origem e a justificativa de cada requisito 3 Utilizar múltiplas visões dos requisitos

3 Priorizar requisitos 3 Priorizar requisitos

(118)

Qualidade de Requisitos

Q

q

3

Requisitos com qualidade evitam re-trabalho

→ 75% dos erros são detectados depois das fases de

codificação e teste de unidadesç

• 45% destes erros são erros de especificação e projeto • Apenas 9% são erros de codificaçãope as 9% são e os de cod cação

3

56% de todos os erros detectados em um

software são devido a problemas na

Engenharia de Requisitos

(119)

Qualidade de Requisitos

Q

q

3

Erros Típicos em Requisitos

→ 49% fatos incorretos → 31% omissões → 31% omissões → 13% inconsistências 5% bi üid d → 5% ambigüidades → 2% outros erros

3

Esses erros são riscos para o projeto

→ Tenha um plano de contingência → Tenha um plano de contingência

(120)

Checklist para Qualidade de Requisitos

p

Q

q

→ os objetivos do sistema estão bem definidos? → os objetivos do sistema estão bem definidos?

→ os requisitos definidos estão explícitos, corretos,

completos e consistentes entre si? completos e consistentes entre si?

→ eles refletem as necessidades de todos os

envolvidos? envolvidos?

→ há margem para interpretações subjetivas de

requisitos? requisitos?

(121)

Checklist para Qualidade de Requisitos

p

Q

q

os diagramas são claros e fáceis de entender?

→

os diagramas são claros e fáceis de entender?

→

as funções estão adequadamente descritas?

→

os riscos do projeto foram considerados?

→

existem fatos implícitos, redundâncias ou

→

existem fatos implícitos, redundâncias ou

omissões?

todas as interfaces para outros elementos do

→

todas as interfaces para outros elementos do

sistema, inclusive com o usuário, foram

d fi id ?

(122)

Verificação Contínua de Qualidade

ç

Q

Minha aplicação responde

Confiabilidade

responde satisfatoriamente ? Minha aplicação faz

o que é preciso ?

• Verificação da sustentabilidade

das operações da aplicação

Funcionalidade

q p

• Verificação de cada

cenário de uso

Desempenho

p

• Teste de desempenho sob

carga esperada e no pior caso Requisitos:

Funcionais

(123)

Gerenciar Mudanças

As Solicitações de Mudanças têm sua origem em varias fontes através das iterações do ciclo de vida do produto

Entradas Cliente/Usuário Final Requisitos Marketing Nova Característica Canal único de aprovações Modelagem Novo Requisito Processo de Aprovação das Decisões de aprovações Codificadores T t d Testes Código Bug Suporte Técnico/ á Decisões _Testadores Manutenção Testes Usuário Final Solicitação de Mudança

(124)

Maturidade do Processo de ER

3

Nível inicial

→ Nenhum processo de ERp

→ Problemas clássicos de requisitos são recorrentes,

incluindo

• Volatilidade de requisitos • Stakeholders insatisfeitos • Alto custo de re-trabalho

• Sucesso depende de experiência e habilidades p p

(125)

Maturidade do Processo de ER

3

Nível repetível

→ Padrões definidos para documento de requisitosp q

• Verificação do padrão em todos os projetos

→ Políticas e procedimentos estabelecidos para p p

gerenciar mudanças em requisitos

• Visibilidade das decisões • Negociação

(126)

Maturidade do Processo de ER

Ní el definido 3 Nível definido

→ Padrões definidos para documento de requisitos

→ Políticas e procedimentos estabelecidos para todas as → Políticas e procedimentos estabelecidos para todas as

atividades da ER

→ Processo de ER definido com base em boas práticas e

adaptado às necessidades da empresa adaptado às necessidades da empresa

→ Programa de melhoria contínua da ER ativo em todos os

projetos

G ti d t di t d i it

• Garantia de entendimento de requisitos • Comprometimento com os requisitos • Rastreabilidade de requisitosq

(127)

Artefatos Típicos

p

3

Entendimento de requisitos

→ Critérios para identificação de fornecedores de p ç

requisitos

→ Critérios para avaliação e aceitação de requisitosp ç ç q → Resultados de análise de critérios

→ Requisitos acordados → Requisitos acordados

(128)

Artefatos Típicos

p

3

Comprometimento com requisitos

→ Análise de impacto e viabilidade de requisitosp q

→ Documento de avaliação e aceitação de mudanças

em requisitosq

→ Alocação de stakeholders (e não só do Analista) em

atividades que envolvem análise de requisitosq q