Gerência de Requisitos - ufpa.br · Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações - Lab. Tecnologia de Software Objetivo da Gerência de Requisitos O

Gerência de RequisitosCarla Alessandra Lima Reis (UFPA)

www.ufpa.br/lts

I Workshop Paraense de Tecnologia de Software

- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações

Roteiro Introdução/Motivação

Visão geral da Engenharia de Requisitos

Gerência de Requisitos

Rastreabilidade

GRE no MPS.BR

Exemplos de Ferramentas

2

Introdução/Motivação

para GRE

3


Objetivo da Gerência de

Requisitos

O objetivo da Gerência de Requisitos é garantir que

os todos os requisitos aprovados sejam

adequadamente transformados em artefatos,

assim como garantir que cada artefato produzido

tenha tido sua origem em requisitos aprovados.

4


Níveis de Maturidade MPS.BR

5

Gerenciado Quantitativamente

Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização

5

Medição - MED / Gerência de Configuração - GCOAquisição - AQU / Garantia da Qualidade - GQAGerência de Portfólio de Projetos - GPP

Avaliação e Melhoria do Processo Organizacional - AMPDefinição do Processo Organizacional - DFPGerência de Reutilização - GRUGerência de Recursos Humanos - GRHGerência de Projetos - GPR (evolução)

Desenvolvimento de Requisitos - DREProjeto e Construção do Produto - PCPIntegração do Produto - ITPVerificação - VER / Validação - VAL

Gerência de Decisões - GDEDesenvolvimento para Reutilização - DRUGerência de Riscos - GRI

G

F

E

D

C

Gerência de Requisitos - GRE

Gerência de Projetos - GPR

A

BGerência de Projetos - GPR (evolução)

(sem processo específico)

Quanto custa corrigir

problemasem software?

6

7

Custo de correção


8

Custos gerados por

problemas em requisitos

Segundo Boehm e Papaccio (apud Pfleeger,

2004), o custo relativo para o conserto de um

problema de requisitos em cada fase de

desenvolvimento de sistema é:

$1 na fase de análise de requisitos

$5 na fase de projeto do sistema

$10 na fase de codificação

$20 na fase de teste de unidade

$200 após a entrega do sistema

[Conte 2007]

9

Custo de correção

[Breitman, 2007]


© Carla A. Lima Reis, 2007 10

Situação típica

11

Visão Geral da

Engenharia de

Requisitos


12

Requisitos

Um requisito é uma característica do sistema ou a descrição de

algo que o sistema é capaz de realizar, para atingir os seus

objetivos. [Pfleeger (2004)]

Um requisito é descrito como uma propriedade que o software

deve exibir para resolver algum problema no mundo real.

[SWEBOK (2004),]

[Conte 2007]


Requisitos não são apenas Software!

Sistemas podem ser compostos de subsistemas de vários tipos

System

Subsystem

1

Subsystem

2

Subsystem

3

Assembly a Assembly b Assembly c

Software Program yHardware Device x

(Alexander, 2001)

[Conte 2007]


14

Importância dos

Requisitos

Estudo feito pelo Standish Group em 1995 (Pfleeger, 2004)

350 companhias e 8.000 projetos de software

Resultados:

31% dos projetos cancelados antes de estarem completos

Em pequenas companhias, somente 16% dos projetos foram

entregues no prazo e no orçamento inicialmente estabelecidos

Em grandes companhias, apenas 9% atenderam esses critérios

[Conte 2007]


Causas para os projetos falhos –

Standish Group

Fatores de Projetos Críticos % Resp.

1. Requisitos Incompletos 13.1%

2. Falta de Envolvimento do Usuário 12.4%

3. Falta de Recursos 10,6%

4. Expectativas Irreais 9,9%

5. Falta de Apoio Executivo 9,3%

6. Mudança de Requisitos e Especificações 8,7%

7. Falta de Planejamento 8,1%

8. Sistema não mais necessário 7,5%

Requisitos estão envolvidos na maioria das causas!

16

Soa familiar?


17

Engenharia de

Requisitos

É o processo de:

Descobrir,

Analisar,

Documentar e

Verificar

...as funções e restrições do sistema

Sommerville (2003)



Atividades da Engenharia

de Requisitos

A Engenharia de Requisitos consiste de dois grupos de

atividades relacionadas:

Desenvolvimento de Requisitos (Elicitação, Análise,

Modelagem e Validação)

Gerência de Requisitos (Identificação, Configuração,

Priorização, Rastreabilidade)


Elicitação, Análise, Modelagem e Validação


Novos

requisitos

elicitados

Versões aceitas,

rastreabilidade,

progresso

O Desenvolvimento de Requisitos cria e interpreta os requisitos

A Gerência de Requisitos organiza e mantém registro dos mesmos

Atividades da Engenharia de

Requisitos

[Conte 2007]

20

Classificação de

Requisitos


21

Classificação de

Requisitos

Requisitos Funcionais

Requisitos diretamente ligados a funcionalidade

do software, descrevem as funções que o software

deve executar

Um requisito funcional descreve uma interação

entre o sistema e seu ambiente

Exemplo: “O sistema deve prover um formulário

um relatório com os resultados dos testes clínicos

de um paciente”

[Conte 2007]


22

Classificação de

Requisitos

Requisitos Não-Funcionais

São requisitos que expressam condições que o

software deve atender ou qualidades específicas

que o software deve ter

Em vez de informar o que o sistema fará, os

requisitos não-funcionais colocam restrições no

sistema

Exemplo: “As consultas ao sistema devem ser

respondidas em menos de três segundos”

[Conte 2007]


23


© Carla A. Lima Rei/ Rodrigo Reis, 2007 24

Desafio Atual no

Processo de Requisitos Gerência de Requisitos

O que se deve gerenciar?

É possível gerenciar efetivamente requisitos?

Qual o ganho com o gerenciamento?



Gerência de Requisitos Principais Objetivos da Gerência de Requisitos:

Gerenciar mudanças nos requisitos acordados

Gerenciar os relacionamentos entre os requisitos

Gerenciar as dependências entre os documentos de

requisitos e outros documentos produzidos


26


27

Mudança de Paradigma Formalização (Hazan, 2004):

Antes do Processo de Gerência de Requisitos

“Quem definiu isso? Vou tentar me lembrar...”

Depois do Processo de Gerência de Requisitos

“Quem definiu isso? Foi a área de negócio XYZ no dia 10 de

janeiro segundo consta aqui nessa ata...”


28

Mudança de Paradigma

Gerenciamento (Hazan, 2004):

Antes do Processo de Gerência de Requisitos

“Como o usuário pode estar insatisfeito com a mudança de

prazo se estamos fazendo tudo que ele quer?”

Depois do Processo de Gerência de Requisitos

“Informe ao usuário que os novos requisitos acarretarão um

desvio de 20% no prazo e 5% no custo”


29

Rastreabilidade de

Requisitos

Um requisito é rastreável se for possível

identificar:

Quem solicitou o requisito

Porque o requisito existe

Quais os requisitos relacionados

Como os requisitos se relacionam a outras

informações


30

Rastreabilidade

Seu objetivo é criar vínculos (links) entre os requisitos e outros

itens do sistema

A rastreabilidade é importante para auxiliar a avaliar o impacto

de mudanças nos requisitos (“forward” para o projeto)

E também para demonstrar a completa satisfação dos

requisitos (“backward” do projeto/design)

Rastreabilidade pode ter outros usos e propósitos:

Apoiar verificação

Criar vínculos a documentos de referência

Criar vínculos entre termos e suas definições…

31

Rastreabilidade backward/forward

Requisitos do

Usuário

Projeto do

Sistema

Especificações

do Sistema

forward – p/ avaliar o impacto de mudança

backward – p/a rastrear a origem de um componente

Links lógicos podem ser seguidos em qualquer direção


32

Ferramentas de Apoio à Gerência

dos Requisitos

Ferramentas de Gerência de Requisitos devem

oferecer facilidades para:

Identificação e Armazenamento dos Requisitos;

Gerenciamento de mudanças, que ajudem a garantir

que as mudanças solicitadas foram avaliadas e

tratadas corretamente;

Rastreabilidade, que auxiliem a encontrar

dependências entre os requisitos.

33

Recursos para Gerência dos Requisitos

- Site: www.volere.co.uk/index.htm

ReqManager (TABA)

Analyst Pro (Goda

Software, Inc.)

CaliberRM (Borland)

Catalyze (SteelTrace)

Cradle (3SL -

Structured Software

Systems Ltd)

Doors (Telelogic AB)

Objectiver (Cediti)

RDT (Igatech)

Reconcile (Compuware

Corporation)

Requisite Pro (IBM

Rational Software)


34

Exemplo de Ferramenta para Rastreabilidade

Impacto de requisitos no projeto

(em outro documento) é encontrado

por vínculos (links)


35

Matriz de Rastreabilidade

Tabela utilizada para documentar os

relacionamentos entre os requisitos

Normalmente criam-se diferentes níveis de

requisitos em uma matriz de rastreabilidade:

Requisitos do Cliente,

Requisitos do Sistema,

Módulos de Código,

Casos de Teste...


36

Matriz de Rastreabilidade(Hazan, 2004)


37



38



39

Política de Rastreabilidade de

Requisitos Ao adotar um processo de Gerenciamento de

Requisitos, a organização precisa definir sua Política

de Rastreabilidade de Requisitos que deve incluir:

A informação de rastreabilidade que será mantida;

As técnicas e ferramentas que serão utilizadas;

Processo de coleta das informações de rastreabilidade: quem e

quando

Processo de atualização das informações de rastreabilidade,

após alterações


Rastreabilidade dos

Requisitos

Estabelecimento da Rastreabilidade Bidirecional

Um mecanismo que permita rastrear a dependência

entre os requisitos, os planos do projeto e os produtos

de trabalho deve ser estabelecido, para:

Facilitar a avaliação do impacto das mudanças de

requisitos que possam ocorrer, por exemplo, nas

estimativas do escopo, nos produtos de trabalho ou nas

tarefas do projeto.

A rastreabilidade bidirecional deve ser tanto horizontal

quanto vertical


Rastreabilidade dos

Requisitos

Itens que devem ser rastreáveis

A rastreabilidade só é efetiva para a avaliação do

impacto das mudanças se existe rastreabilidade

bidirecional entre os itens com impacto no produto:

Requisitos

Produtos de trabalho

Planos do projeto

Códigos de unidade ou módulos do software

Casos de Teste


Gerência de Mudanças e

de Inconsistências

Procedimentos da Gerência de Mudanças

Durante o projeto, os requisitos podem mudar por uma série de motivos:

Requisitos adicionais podem ser incorporados no projeto e/ou

Mudanças podem ser feitas nos requisitos já existentes.

As necessidades de mudanças devem ser registradas e um histórico das decisões acerca dos requisitos deve estar disponível

Estas decisões são tomadas através da realização de análises de impacto da mudança no projeto e pode incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo.



de Inconsistências

Identificação de Inconsistências entre

requisitos e outros produtos de trabalho

A consistência entre os requisitos e os produtos de

trabalho do projeto deve ser constantemente

avaliada e os problemas identificados devem ser

corrigidos.

As inconsistências identificadas devem ser

registradas, e ações corretivas executadas a fim

de resolver as inconsistências.

As ações para correções das inconsistências

devem ser acompanhadas até que sejam

resolvidas.



de Inconsistências

Identificação de Inconsistências entre requisitos e

outros produtos de trabalho (cont.)

Quando há mudanças nos requisitos:

Devem ser identificados os impactos da mudança com a

utilização do instrumento de rastreabilidade dos requisitos

Deve-se examinar se os demais artefatos estão

consistentes com as alterações realizadas como, por

exemplo: verificar se a planilha de estimativas está

contemplando todos os requisitos e mudanças; verificar se

as mudanças dos requisitos foram incorporadas ao

escopo do projeto

GRE no MPS.BR

45


Resultados esperados

de GRE

46


Capacidade do processo Capacidade do Processo

A capacidade do processo é representada por um

conjunto de atributos de processo descrito em

termos de resultados esperados.

A capacidade do processo expressa o grau de

refinamento e institucionalização com que o

processo é executado na organização

47


48


Capacidade do Processo

49



50



51


52



53



54



55



56



57



58



59

Artefatos de GRE

60


Exemplos de artefatos

61


Exemplos de artefatos Parte de uma solicitação de mudança

62


Matriz de

Rastreabilidade

63

64

Ferramentas para

Gerência de requisitos



Gerência de Requisitos no

TABA Ferramenta para Apoio à Gerência de Requisitos

ReqManager

Vídeo disponível em www.cos.ufrj.br/taba http://ramses.cos.ufrj.br/taba/index.php?option=com_docman&task=doc_download&gid=25&Itemid=119

http://www.cos.ufrj.br/taba



Ferramenta

GatherSpace



Ferramenta

GatherSpace



Ferramenta GatherSpace

Rastreabilidade



Ferramenta RTH

(free)http://www.rth-is-

quality.com/home.php

Rastreabilidade

Testes de requisitos

Registro de defeitos

relatórios



Requisite Pro (Rational)



Caliber Analyst – Borland

www.borland.com



Caliber – diagrama de

rastreabilidade



DOORS (http://www.telelogic.com/products/doors/doors/index.

cfm)



DOORS



DOORS



DOORS



Enterprise Architect

(http://www.sparxsystems.com.au/)



Bibliografia indicada –

Parte I Pfleeger, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª edição – 2004, 8587918311

Pressman, R.S. Engenharia de Software. 6ª edição. McGraw-Hill, 2006. (http://www.rspa.com/)

COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um Guia Pratico para Desenvolvedores de Software. Bookman, 2005, 853630457X

Paula Filho, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª edição – 2003.

Sommerville, Ian. Software Engineering. (7th Edition). Addison-Wesley Publishing Co, 2006, 0321313798. (http://www.aw.com/sommerville_br)

Nuseibeh, Easterbrook Requirements Engineering - a roadmap -. (http://www-di.inf.puc-rio.br/~karin/pos/roadmap.pdf)

Neil A. Maiden and Cornelius Ncube. Acquiring COTS Software Selection Requirements. IEEE Software, 15(2):46-56, Mar 1998.

Goguen, Joseph - Requirements Engineering as the reconciliation of social and technical issues - in Requirements Engineering: Social and Technical Issues edited by Joseph Goguen and Marina Jirotka - Academic Press 1994.

Requrements Engineering in the health care domain - L. Cysneiros - RE03- IEEE Joint International Requirements Engineering Conference - Essen, Alemanha, 2003. pp.350-356.

http://www.rspa.com/

http://www.aw.com/sommerville_br

http://www-di.inf.puc-rio.br/~karin/pos/roadmap.pdf







Bibliografia

indicada/Referências Alexander I., Robertson, S., “Understanding Project Sociology by Modeling Stakeholders”,

IEEE Software, Jan – Feb 2004

Hazan, C., “Implantação de um Processo de Gestão dos Requisitos seguindo o CMMI”, VI Simpósio Internacional de Melhoria de Processo de Software, São Paulo, Nov. 2004

Pfleeger, S. “Engenharia de Software – Teoria e Prática”, 2ª Edição, Prentice Hall, 2004

SWEBOK 2004 – disponível em www.swebok.org

Leite, J.C.S.P., “Entrevistas”, em Livro Vivo : Engenharia de Requisitos, http://livrodeengenhariaderequisitos.blogspot.com/, 2007

Breitman, K. Requisitos. Minicurso – Requisitos – XXII Simpósio Brasileiro de Engenharia de Sofware 2007 – João Pessoa

Conte, T. Gerência de Requisitos. Mini-Curso. COPPE-UFRJ, 2007

Vasconcelos, A. “Visão geral sobre a engenharia de software. UFPE.

http://www.swebok.org/

http://www.sbbd-sbes2007.ufpb.br/index.php?section=minicursos



Referências na web Laboratório de Engenharia de Requisitos da UFPE

(http://www.cin.ufpe.br/~ler/home/home.html)

Livro Vivo sobre Engenharia de Requisitos, Prof. Julio Leite

(http://livrodeengenhariaderequisitos.blogspot.com/)

www.inf.puc-rio.br/~karin/pos

Cenários e Léxicos (Sl.les.inf.puc-rio.br/cel)

Artigos do Workshop de Engenharia de Requisitos (wer.inf.puc-

rio.br/WERpapers/)

http://www.cin.ufpe.br/~ler/home/home.html

http://livrodeengenhariaderequisitos.blogspot.com/

Documents

Gerência de Requisitos - ufpa.br · Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações - Lab. Tecnologia de Software Objetivo da Gerência de Requisitos O