Processo

eXtreme
Requiriments
XR

Eduardo José Ribeiro de Castro, MSc

Fernando de Albuquerque Guimarães, MSc
Direitos reservados
 Elementos Conceituais

2
 Elementos Conceituais

Business Process Management (BPM)

• Processo é “um conjunto fim-a-fim completo de
atividades que juntas criam valor para o cliente”
(Beyond Reengineering, Michael Hammer, Harper
Business, 1996)
• Processo é a unidade básica de valor do negócio em
uma empresa

Motivação
• No final do século passado, o redesenho de funções
de negócio como processos tornou-se a estratégia
estabelecida para reduzir custos, tempos de ciclo e
melhorar a qualidade e satisfação de clientes
3
 Elementos Conceituais

Conceito de Qualidade de Software

• “Conformidade a requisitos funcionais e de

desempenho, explicitamente declarados, a
padrões de desenvolvimento claramente
documentados e a características implícitas que são
esperadas de todo o software profissionalmente
desenvolvido.”
Pressman, Roger

4
 Elementos Conceituais

Conceito de Qualidade de Software

• “Conformidade a requisitos funcionais e de

desempenho, explicitamente declarados, a
padrões de desenvolvimento claramente
documentados e a características implícitas que são
esperadas de todo o software profissionalmente
desenvolvido.”
Pressman, Roger

5
 Elementos Conceituais

Processo de Desenvolvimento
• O desenvolvimento do produto deve seguir um modelo baseado em um
processo de software. Este processo consiste numa seqüência de
etapas que envolvem atividades, restrições e recursos para alcançar um
resultado desejado.
• O primeiro modelo proposto pela engenharia de software, modelo em
cascata, define as etapas em seqüência. Neste modelo, uma etapa
dever ser finalizada antes de a próxima começar.
• Em 1988, Boehm sugeriu um modelo de processo em espiral,
combinando as atividades de desenvolvimento com o gerenciamento de
risco, de modo a minimizar e controlar os riscos do projeto.

6
 Elementos Conceituais

Processo de Desenvolvimento
• A metodologia a ser empregada no desenvolvimento da ferramenta
utilizará a abordagem iterativa proposta por Philippe Kkruchten em
1995. Este novo modelo combina o modelo em cascata e o modelo em
espiral, incorporando novos conceitos da Engenharia de Software.
• Nesta abordagem, as atividades que ocorrem em cada fase do modelo
em cascata podem ser “refinadas” durante várias iterações do projeto.
E, como no modelo em espiral, cada iteração é planejada para
minimizar os riscos inerentes a cada estágio do desenvolvimento.
• Uma iteração incorpora uma seqüência livre de atividades (modelagem
de negócio, proposta de solução, definição de requisitos, etc., em
proporções variáveis de acordo com a fase do ciclo de desenvolvimento
que a iteração está localizada). O foco da iteração depende em que
fase esta se encontra.

7
 Elementos Conceituais

Engenharia de Requisitos

1. Elicitação
Produção de 2. Análise e Negociação
Requisitos 3. Documentação
4. Validação
Engenharia de
Requisitos
1.Rastreabilidade
Gerência 2.Gerenciamento de Mudanças
de Requisitos 3.Gerenciamento de Configuração
4.Gerenciamento da Qualidade dos
Requisitos

8
 Elementos Conceituais

Engenharia de Requisitos

• Os 4 subprocessos da Produção de Requisitos:

– Elicitação
• Identificação da fonte de informação. Obtenção dos dados e
fatos
– Análise
• Obter entendimento sobre as funcionalidades do sistema.
Avaliar e revisar o escopo do software.
– Documentação
• Definição e conversão dos requisitos em alguma forma-padrão;
Documento de Definição de Requisitos
– Validação
• Verificação se os requisitos realmente definem o sistema que o
cliente deseja; Protótipo.

9
 Elementos Conceituais

Engenharia de Requisitos

• Os 4 subprocessos da Gerência de Requisitos:

– Gerência de Mudanças
• Controla as solicitações de mudança do cliente
– Gerência de Configuração
• Controla as versões dos artefatos
– Gerência de Qualidade dos Requisitos
• Define o padrão de produção e verificação da qualidade dos
requisitos
– Rastreabilidade
• Relação entre as fontes dos requisitos, os requisitos
propriamente ditos e outros artefato

10
 Processo XR
eXtreme Requirements
(Eduardo Castro, Direitos Reservados)

11
 Processo eXtreme Requirements

• Com base nos conceitos de Engenharia de Software

(IEEE), de Qualidade de Software (ISO 9126),
Gestão de Processo de Negócio (BPM) e dos
processo de Engenharia de Requisitos (IEEE) foi
construído um processo para definição de requisitos
composto de fases, disciplinas, atividades e
artefatos necessários a construção de requisitos
para definição das funcionalidades de um software.

12
 Processo eXtreme Requirements®
Eduardo José Ribeiro de Castro®

Fases
Disciplinas Elicitação Análise Documentação Validação

Modelagem de
Negócio
Proposta de
Solução
Definição dos
Requisitos

Prototipação

Teste
Gerência de
Requisitos

Disciplinas de Apoio
Gerência de Administração Métrica de
13 Projeto de Dados Software
 Processo eXtreme Requirements

Fases:
1. Elicitação
• O objetivo principal da fase de elicitação de requisitos é organizar e
analisar os documentos, normas, leis, estrutura, responsáveis que
compõem o processo de negócio em estudo, buscando obter
conhecimento do domínio do problema.

2. Análise
• O objetivo da fase de análise de requisitos é avaliar e revisar o escopo
do software por meio de um processo de descoberta, refinamento,
revisão e validação, obtendo um entendimento sobre as
funcionalidades do sistema.
• O processo de avaliação e síntese continua até que o analista e o cliente
concordem que o software pode ser adequadamente definido gerando
assim uma proposta de solução.

14
 Processo eXtreme Requirements

Fases:
3. Documentação
• O documento de requisitos de um software contém os requisitos
identificados e desejados pelo cliente a partir da proposta de solução
descrita na fase de análise.
• São definidos todos os requisitos funcionais, complementares e não
funcionais do software
• São identificadas as regras de negócio que indicam a condição para que
aquele requisito possa ser implementado e executado.
• Este documento serve como um meio de comunicação entre o
projetista do software e o usuário, a fim de estabelecer um “acordo”
acerca do software pretendido.

4. Validação
• A validação representa a atividade em que obtemos o aceite do cliente
sob determinado artefato
• No cenário de engenharia de requisitos, esta atividade significa aprovar
junto ao cliente os requisitos que foram definidos

15
 Processo eXtreme Requirements

Etapas:
1. Modelagem de Negócio
• Atividade: Análise do negócio, organograma, responsáveis, área(s)
de automação, fluxo de atividades e identificação de problemas.
• Artefato: Documento de Análise

2. Proposta de Solução
• Atividade: Para cada problema identificado na etapa anterior é
proposta solução contendo os objetivo geral, objetivos específicos,
suas principais funcionalidades e fluxo de atividades do processo
atualizado.
• Artefato: Proposta de Solução

3. Definição dos requisitos

• Atividade: A partir dos objetivos específicos e suas principais
funcionalidades são identificados os requisitos do software
(funcionais, complementares e não funcionais), as regras de
negócio, matriz de rastreabilidade e priorização dos requisitos.
• Artefato: Documento de Definição de Requisitos - DDR
16
 Processo eXtreme Requirements

Etapas:
4. Prototipação
• Atividade: A partir da definição dos requisitos do software é
construído um protótipo de Baixa Fidelidade de forma a facilitar a
comunicação entre o usuário e os analistas de requisitos e validar
as funcionalidades e requisitos identificados.
• Artefato
Artefato: Protótipo de Baixa Fidelidade (não funcional)
5. Teste
• Atividade: A partir da análise do negócio podem ser executados
testes de verificação e validação entre os objetivos específicos,
suas principais funcionalidades, requisitos do software
identificados, regras de negocio e prioridades definidas.
• Artefato: Documento de Teste de Requisitos
6. Gerência de Requisitos
• Atividade: Durante todo o processo XR a Gerência de requisitos é
responsável pela rastreabilidade de requisitos, gerência de
mudança, gerencia de configuração e gerencia da qualidade dos
requisitos.
• Artefato: Plano de Gerência de Requisitos
17
 Processo eXtreme Requirements

• Estas fases e disciplinas têm como objetivo

construir, de forma organizada e estruturada, de
uma visão mais geral para a mais específica, o
entendimento do sistema de informação que se
pretende automatizar, qual(is) o(s) processo(s) que
o compõem e seus problemas.
• Esta prática facilita a aplicação de técnicas de
contagem (métrica de software) logo no inicio do
projeto.

18
 Processo eXtreme Requirements

• A partir da Modelagem de Negócio e do mapeamento

do seu processo (fluxo de atividades) é possível
identificar e compreender a seqüência lógica das
atividades que visam a transformação dos dados em
informação.
• Esta compreensão auxilia na descrição dos problemas
que são passíveis de automação.
• Com essa modelagem e descrição dos problemas, é
possível gerar uma proposta de solução que
contenham os objetivos geral e específicos para sua
automação.
• Os objetivos específicos devem ser descritos e suas
funcionalidades identificadas.
• Um novo fluxo de atividades é gerado, corrigindo e/ou
19 otimizando o processo atual.
 Processo eXtreme Requirements

• A partir dos objetivos específicos e suas principais

funcionalidades, são identificados os requisitos do
software (funcionais, complementares, não
funcionais), as regras de negócio e elaborado o
documento de definição de requisitos.
• Este documento tem de ser validado pelo usuário de
forma a orientar a construção do software.
• Tendo por base o documento de definição de
requisitos é construído um protótipo de baixa
fidelidade com o intuito de validar, junto ao usuário,
os requisitos e regras de negócio identificados.

20
 Processo eXtreme Requirements

• O protótipo auxilia na validação e verificação dos

requisitos.
• A disciplina de teste verifica se os requisitos estão
atendendo aos objetivos específicos e suas
funcionalidades e se o protótipo contem todos os
requisitos definidos.
• A gerencia de requisitos acompanha todo o
processo, mantendo a rastreabildiade dos
requisitos, o controle de mudança e configuração e a
qualidade dos requisitos produzidos e da
documentação construída.

21
 Processo eXtreme Requirements

Definição
Processo de Negócio
dos Requisitos

Proposta Documentação
Análise Modelagem Análise do
de e
do Negócio do Processo Problema
Solução Validação

Definição
Projeto de de
Definição de Requisitos
Software

22
 Processo eXtreme Requirements

• Os requisitos do software construídos a partir de

uma visão sistêmica de todo o processo facilitam a
identificação de pontos ou de oportunidades de
automação, possibilitando a integração entre
diversos sistemas.

• Esta prática leva a uma melhora considerável da

aplicação dos recursos financeiros, pessoal, de
hardware e software, gerando expectativas de
menores custos, prazos mais realísticos e melhora
na qualidade do software.

23
 Processo eXtreme Requirements

VISÃO SISTÊMICA

Pontos de Automação

Inicio Fim
Processo de Negócio

eXtreme
Requirements Melhoria do Sistema
Preocupação com a
solução
ESTRATÉGICA XR

24
 Para Refletir

“ Para fazer as coisas de maneira diferente, você

precisa ver as coisas de maneira diferente.”
Paul Allaire, CEO da
Xerox Corporation

“ Se não mudarmos o rumo, chegaremos exatamente

aonde estamos indo.”
Provérbio antigo

25
 Referências Bibliográficas
• BALDAM, Roquemar de Lima, ET AL. Gerenciamento de Processos de
negócios: BPM – Business Process Management – 1ª. edição São Paulo:
Érica, 2007
• COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um Guia Pratico para
Desenvolvedores de Software. Bookman, 2005
• DINSMORE, Paul - Como se tornar um Profissional em Gerenciamento de
Projetos - 2ª Edição;
• LEFFINGWELL, Dean Managing Software Requirements, Second Edition: A
Use Case Approach, ed. Pearson , 2003
• PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª
edição – 2004
• PRESSMAN, Roger. S. Engenharia de software: um enfoque prático. 3. ed.
São Paulo: Makron Books, 1995.
• SOMMERVILLE, Ian.Engenharia de Software. 6ª ed. São Paulo: Addison
Wesley, 2003
• SWEBOK - Guide to the Software Engineering Body of Knowledge
26
(www.swebok.org)
 OBRIGADO.

ejrcastro@gmail.com

eduardo@quaddract.com.br
Perguntas ?