Engenharia Requisitos - Método RON

Eduardo Castro

www.quaddract.com.br

Análise de Negócio
e
Engenharia de Requisitos
Fator de Sucesso em
Projetos de Software

Eduardo Castro
eduardo@quaddract.com.br
www.quaddract.com.br
1 Engenharia de Requisitos – Fator de Sucesso em Projetos de Software

Eduardo Castro
Instrutor
Eduardo José Ribeiro de Castro
Formação Acadêmica:
• Mestre em Gestão do Conhecimento e Tecnologia da Informação – UCB - 2005
• Especialista em Analise de Sistemas – EDF - 1990
• Graduado em Ciências Contábeis – UNICEUB – 1989
Atividades Profissionais:
• Gerente de Projetos há mais de 12 anos na área de desenvolvimento de software.
• Consultor na área de Engenharia de Software e Engenharia de Requisitos
• Coordenador da Pós-Graduação em Engenharia de Requisitos de Software do
Uniceub
• Professor dos Cursos de Tecnólogo em Analise e Desenvolvimento de Sistemas do
UniCEUB e Bacharelado em Ciência da Computação da UCB onde ministra, entre
outras, as seguintes disciplinas:
– Analise de Requisitos
– Analise e Projeto Estruturado de Sistemas
– Análise e Projeto Orientado e Objetos
– Gerencia de Projeto
– Engenharia de Software
– Gestão da Tecnologia da Informação


Eduardo Castro

Causas de Fracasso
em
Projetos de Software


Eduardo Castro
Causas de Fracasso
REQUISITOS X QUALIDADE

• Leffingwell ressalta que 40% a 60% de todos os problemas
encontrados em um projeto são causados por falhas no processo
de requisitos (ausência ou à não utilização de um processo de
definição de requisitos adequado).

• As conseqüências da falta de um processo de requisitos eficaz têm
sido a produção de softwares que não refletem as necessidades
reais dos clientes.

• Como os requisitos constituem a base para o desenvolvimento do
software, então, requisitos de má qualidade geram software com
qualidade inadequada.


Eduardo Castro
Causas de Fracasso
Principais causas de fracasso
TÉCNICA

• Poucos analistas fazem uso de técnicas no momento de elicitar e
analisar os requisitos de um sistema.

• Desenvolvedores, de uma forma geral, têm uma visão simplista do
processo de software.
– Entendem que todo sistema computacional é tão somente
linhas de código e que quanto mais cedo se começar a
codificar um sistema, maior será a chance de sucesso.
– definem, eles próprios, os requisitos dos sistemas


Eduardo Castro
Causas de Fracasso
GERENCIAL

• É comum que projetos sejam iniciados e continuados mesmo com
falhas nas informações dos usuários
• É necessário obter o conhecimento do negócio e das
necessidades do usuário
– que devem ser escritos para serem lidos e entendidos por
clientes, gerentes e arquitetos de sistemas


Eduardo Castro
Causas de Fracasso

• Falhamos quando perdemos o controle do
processo de construção, permitindo que
cliente e gerentes interfiram diretamente na
equipe e no processo de desenvolvimento do
sistema.


Eduardo Castro

Evolução do Problema


Eduardo Castro
• Esse problema é tão antigo e conhecido na área de
desenvolvimento de software, que na década de 70
alguém teve a idéia de fazer o seguinte desenho
ilustrando a situação.


Eduardo Castro
• Alguém que esteja começando uma carreira de analista
ou desenvolvedor de software poderá imaginar que um
problema tão antigo já foi solucionado, ou, que pelo
menos, o seu impacto nos projetos de software tenha
sido minimizado.

• Que grande engano!

• O problema é ainda tão crítico, que o desenho foi revisto
e adequado aos nossos dias.


Eduardo Castro


Eduardo Castro

Importância dos
Requisitos


Eduardo Castro
Importância dos Requisitos
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

13

Eduardo Castro
• Uma compreensão completa do problema e a
definição dos requisitos do software e sua
especificação minuciosa é fundamental para
o processo de desenvolvimento obter um
software com alta qualidade.
• Não importa quão bem projetado ou
codificado está um programa, se ele for mal
analisado e especificado desapontará o
usuário e trará aborrecimentos ao
desenvolvedor.


Eduardo Castro
• Requisitos mal definidos, ou que não
atendam as expectativas dos clientes,
exigem reparos durante o desenvolvimento
do software.
• A manutenção do projeto de software eleva
drasticamente seus custos, podendo levá-
lo ao fracasso.


Eduardo Castro

Processo de
Construcao de
Software


Eduardo Castro
Análise do Negócio

• Desenvolver sistemas é
automatizar processos de negócio
Eduardo Castro

17

Eduardo Castro
Nucleo de Gestao de Resultados
Relação entre
Processo de Negocio e
Software

Conjunto de Processo de
Tarefas Negócio
(BPM)

Define Automação

Conjunto de
Software
Requisitos

LP BD


Eduardo Castro
Nucleo de Gestao de Resultados
Infra estrutura do processo de construção de software

Cliente Equipe Técnica Gestão

Analise de Engenharia de Gerencia de
Negócio Software Projeto
(BPM) (SEI) (PMI)

Definição
dos
Requisitos
Mapeamento Controle
de e
Desenvolvimento
Processo Monitoramento
Teste

Manutenção


Eduardo Castro
Nucleo de Gestão de Resultado


Eduardo Castro



Eduardo Castro

• "A primeira regra de qualquer
tecnologia utilizada nos negócios é que
a automação aplicada a um processo
eficiente aumentará a eficiencia.

• A segunda é que a automação aplicada
a um processo ineficiente aumentará
a ineficiência.”
(Bill Gates)

22

Eduardo Castro

• Processo Definido, Requisitos
Identificados, Software com
Qualidade e TI com governança.
Lucia Bastos & Eduardo Castro

23

Eduardo Castro
Segundo o BABOK 2.0, a Análise de Negócio é
definida como:

• Conjunto de tarefas e técnicas utilizadas para
o trabalho como um elo de ligação entra as
partes interessadas (stakeholders) para
entender a estrutura, as políticas e as
operações de uma organização bem como os
problemas envolvidos, e recomendar soluções
que permitam que esta possa alcançar seus
objetivos.


Eduardo Castro
• A analise do negócio de um Sistema de
Informação deve ser realizada buscando
identificar os elementos que a compõem e
os processos utilizados para
transformação dos dados em informação

• Essa análise do processo nos permite
analisar o negócio, identificar os problemas e
propor soluções


Eduardo Castro

Processo de Negócio


Eduardo Castro
Processo
Conceitos gerais
• “Conjunto de recursos e atividades inter-relacionadas
que transformam insumos (entradas) em produtos
(saídas).” (ISO, 1990)

• “Um processo é um grupo de atividades realizadas
numa seqüência lógica com o objetivo de produzir um
bem ou um serviço que tem valor para um grupo
específico de clientes.” (Hammer e Champy, 1994)


Eduardo Castro
Sistemas de Informação

SISTEMA DE INFORMAÇÃO – S.I.

PROCESSO

DADOS INFORMAÇÃO


Eduardo Castro
SISTEMA DE INFORMAÇÃO – S.I.

PROCESSO

DADOS Mapeamento do INFORMAÇÃO
Processo

Identificação do
Problema

Análise do
Problema

Proposta de
Solução


Eduardo Castro
Análise do Negócio e Requisitos

Análise Proposta Definição
do de dos
Negócio Solução Requisitos

Descrição Mapeamento Identificação Produção e
Análise do Definição
do do do Gerência
Problema dos
Processo Processo Problema de
Objetivos
Requisitos

Viabilidade Funcionalidades Engenharia
e de
Recursos Requisitos


Eduardo Castro



Eduardo Castro
• O que é um REQUISITO ?
“Podemos conceituar requisitos como
sendo uma ação a ser executada por um sistema,
possuindo características e condições próprias e
que devem ser atendidas conforme as
necessidades de negócio do usuário.”

Carlos Vazquez - FATTO


Eduardo Castro
Requisitos • Definem o que é solicitado ao software fazer e
com quais limitações ele é requisitado a operar
para atender a necessidade do negócio.
Engenharia de • Propõe métodos, técnicas e ferramentas que
Requisitos auxiliam o processo de descoberta,
documentação e gestão dos requisitos que o
software deve atender.
Gerenciamento de • Gerenciar as mudanças que ocorrem nos
Requisitos
requisitos já acordados;

• Gerenciar relacionamentos entre os requisitos;

• Gerenciar as dependências entre os documentos
de requisitos e outros documentos produzidos
durante o processo de engenharia de software;


Eduardo Castro
• A ER é uma sub-área da Engenharia de
Software que estuda o processo de produção e
gerência dos requisitos que o software deverá
atender.

• O objetivo da ER é fornecer métodos,
procedimentos e ferramentas que forneçam
suporte adequado às tarefas de produção e
gerência dos requisitos do sistema.

• Foi estabelecida como disciplina independente
em 1993, quando da criação do IEEE
International Symposyum on Requirements
Engineering (RE’93).


Eduardo Castro
• A tendência natural das organizações que
trabalham sem um processo de ER tem sido
identificar os requisitos rapidamente de maneira
informal e iniciar a codificação.
• Este é o processo “codifica-remenda” até a
produção de uma versão com qualidade adequada
ou o cancelamento do projeto.

• Estes projetos freqüentemente estouram o prazo e
o orçamento.

• É importante lembrar que o esforço e o custo do
retrabalho são maiores do que os investimentos
em ER, buscando desenvolver o projeto certo da
primeira vez.


Eduardo Castro
• A engenharia de requisitos engloba os processos de
produção e gerência de requisitos.


Eduardo Castro

Produção de Requisitos


Eduardo Castro
Produção de Requisitos

• Os 4 subprocessos:

– Elicitação
• Identificação da fonte de informação. Obtenção dos dados
e fatos
– Análise e Negociação de Requisitos
• Obter entendimento sobre as funcionalidades do sistema.
Avaliar e revisar o escopo do software.
– Definiçao dos Requisitos
• 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.

38

Eduardo Castro
Produção de
Requisitos

Análise do Identificação
Negócio das Fontes de Análise dos Documentação Protótipo do
Informação Requisitos dos Requisitos Sistemas

Proposta
Análise e Definição dos
de Elicitação Validação
Negociação Requisitos
Solução


Eduardo Castro

Gerencia de Requisitos


Eduardo Castro
Subprocessos da Gerência de Requisitos:

– Gerência de Qualidade dos Requisitos
• Define o padrão de produção e
verificação da qualidade dos
requisitos.

– Controle de Mudanças dos Requisitos
• Controla as solicitações de mudança
do cliente.

– Controle de Produção dos Requisitos
• Controla a identificação dos
requisitos.

– Rastreabilidade
• Relação entre as fontes dos
requisitos, entre os requisitos
propriamente ditos, e entre requisitos
e os outros produtos (artefatos) da
engenharia de software.
– Gerência de Configuração
• Controla versões dos requisitos e
artefatos (armazenamento,
manipulação, liberação).


Eduardo Castro

Controle de Relação entre Analise de Controle de Padrão de Gestão
Mudança Requisitos e Impacto das Versionamento e Produção de
Artefatos Mudanças Requisitos

Plano de
Controle de Gerencia de Qualidade dos
Gerencia de Rastreabilidade
Mudança Configuração Requisitos
Requisitos


Eduardo Castro

Documento de Requisitos


Eduardo Castro
• Dois tipos de DOCUMENTO de REQUISITOS

Clientes Projetistas

Definição Especificação
dos Requisitos dos Requisitos
•Redefine os requisitos em termos
•Lista do que o Cliente espera que o técnicos;
sistema faça; •Compreensível para o Projetista
•Compreensível ao Cliente; •Consenso entre Analista e
•Consenso entre Cliente e Analista; Desenvolvedor
•Envolve Modelagem


Eduardo Castro
• Documentação de Requisitos

– Não importa o método, deve-se manter um
conjunto de documentos que registrem os
requisitos

– Esse conjunto será utilizado durante todo o
desenvolvimento e manutenção do sistema


Eduardo Castro

Processo RON
Requisitos
Orientado ao Negócio

(Eduardo Castro, Direitos Reservados)

46

Eduardo Castro
Processo RON®

• 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
e disciplinas.
• Cada disciplina com seu conjuntos de atividades
e artefatos necessários a definição de requisitos
a partir das funcionalidades de um software
definido pelo usuário.

47

Eduardo Castro
Processo RON®
Eduardo José Ribeiro de Castro

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

Análise do
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
Projeto de Dados Software

48

Eduardo Castro
Processo RON®

VISÃO
SISTÊMICA
Pontos de Automação

Inicio Fim
Processo de Negócio

Requisitos Melhoria do Sistema
Preocupação com a Orientado ao
solução Negócio
ESTRATÉGICA
RON
49

Eduardo Castro

Tipos de Requisitos
Método Requisitos Orientado ao Negócio - RON


Eduardo Castro
Tipos de Requisitos
• Requisitos
“Podemos conceituar requisitos como sendo
uma ação a ser executada por um sistema,
possuindo características e condições
próprias e que devem ser atendidas
conforme as necessidades de negócio do
usuário.”
Carlos Vazquez - FATTO

51

Eduardo Castro
Tipos de Requisitos
• Requisitos de Negócio
• Correspondem aos objetivos de negócio - ou do cliente - que
devem ser satisfeitos pelo sistema.
• Deve explicitar suas restrições e premissas bem como prazo
e custo
• Requisitos de Usuário
• Descrevem os objetivos geral, específicos e as
funcionalidades que o software deverá oferecer, sob o ponto
de vista do negócio, de modo que sejam compreensíveis
aos usuários
• Requisitos do Software
• Descrevem os requisitos (ações) que o sistema deve possuir
para que os usuários possam executar suas atividades, de
modo a atingir os objetivos do negócio.


Eduardo Castro
Tipos de Requisitos
• Requisitos do Software:
• Funcionais
• (funcionalidades, ações do sistema)
• Ex.: O sistema deve gerar extrato bancário
• Complementares
• (características e propriedades funcionais)
• Ex.: O sistema deve gerar extrato bancário contendo
nome, hora, data, saldo e movimentação
• Regras de Negócio
• (norma, condição, padrão para execução das funcionalidades)
• Ex.: Quando o sistema gerar o extrato bancário o sistema
deve apresentar a movimentação dos 5 último dias
• Não Funcionais (Norma ISO 9126)
• (características de qualidade do software)
• Ex.: Quando o sistema gerar o extrato bancário o sistema
deve apresentar a movimentação dos 5 último dias


Eduardo Castro

Estudo de Caso


Eduardo Castro
Estudo de Caso

Para o sistema descrito a seguir
(Compras NET), escrever os requisitos
funcionais, complementares, regras de
negócio e não funcionais que forem
identificados.


Eduardo Castro
Estudo de Caso
Compras NET
• O cliente navega pelo site e adiciona itens desejados ao
carrinho de compras. Se não encontrar o produto desejado,
pode usar a opção de busca.
• Durante sua navegação no site, o cliente pode ver o conteúdo
de seu carrinho de compras, alterando quantidades ou
excluindo itens.
• Quando o cliente finalizar a compra, ele deve se identificar
com seu login/senha. Caso não seja ainda cadastrado, deverá
fazê-lo antes de prosseguir. Em seguida, informa o endereço
de entrega daquela compra e detalha a opção de pagamentos
(dados do cartão de crédito ou para pagamento por boleto
bancário).
• Confirmada a compra, o sistema fecha a venda e envia um e-
mail informando ao cliente o status da compra (aguardando
confirmação do cartão de credito ou do pagamento do boleto).

Eduardo Castro
Estudo de Caso
Inicio
Processo de Compra na WEB
Não

Sim
Busca Adiciona Visualiza Modifica
Achou ? Finaliza?
Produto Produto Produto Produto

Não
Sim

Seleciona Cadastra Valida Sim
Solicita
Possui
Opção de Endereço Usuário e Cadastro? Usuário e
Compra de Entrega Senha Senha
Não

Sistema Cadastra
Confirma Fecha a Usuario e
Envia
Compra Venda Senha
e-mail

FIM


Eduardo Castro
Estudo de Caso
Requisitos Funcionais
Sub-Processo Seleciona Produto
RF1 – O sistema deve buscar produto (rc01)
RF2 – O sistema deve adicionar produto (itens do carrinho) (rc02)
RF3 – O sistema deve visualizar produtos (itens do carrinho) (rc3) (rng1)
(rng2)
RF4 – O sistema deve excluir produto (itens do carrinho) (rc01)
RF5 – O sistema deve alterar quantidade produto (itens do carrinho) (rc02)
RF6 – O sistema deve finalizar pedido (fechar carrinho) (rc04) (rgn3) (rgn4)
(rgn5) (rgn6)

Sub-Processo Seleciona Realiza Compra
RF7 – O sistema deve identificar cliente (rc5)
RF8 – O sistema deve cadastrar cliente (rc6)
RF9 – O sistema deve cadastrar endereço de entrega (rc7)
RF10 – O sistema deve permitir ao cliente selecionar opção de pagamento
(rc08)
RF11 – O sistema deve confirmar a compra (rc9) (rng7)
RF12 – O sistema deve enviar e-mail de status (rc10)

Eduardo Castro
Estudo de Caso
Requisitos Complementares
Sub-Processo Seleciona Produto
RC1 – o sistema deve permitir pesquisar nome do produto (RF1) (RF4)
RC2 – o sistema deve permitir selecionar nome e quantidade (RF2) (RF5)
RC3 – o sistema deve exibir produto, quantidade, valor e total ao visualizar
produto (carrinho) (RF3)
RC4 – o sistema deve permitir registrar nome, data e hora ao finalizar o pedido
(RF6)
Sub-Processo Seleciona Realiza Compra
RC5 – o sistema deve identificar o cliente por usuário e senha ao finalizar o
pedido (RF7)
RC6 – o sistema deve cadastrar usuário e senha (RF8)
RC7 – o sistema deve cadastrar endereço, bairro, cidade e cep (RF9)
RC8 – o sistema deve exibir as seguintes opções de pagamento: cartão de
crédito e boleto bancário (RF10)
RC9 – o sistema deve registrar nome, data, hora, produto e quantidade ao
confirmar o pedido (RF11)
RC10 – o sistema deve informar o status da compra (aguardando confirmação
do cartão de credito ou do pagamento do boleto) ao finalizar a compra (RF12)

Eduardo Castro
Estudo de Caso
Regras de Negócio
RNG1 – quando o cliente visualizar os produtos (carrinho) o sistema
deve permitir alteração de quantidade de itens (RF3)
RNG2 – quando o cliente visualizar os produtos (carrinho) o sistema
deve permitir exclusão de itens (RF3)
RNG3 – quando o cliente finalizar o pedido o sistema deve identificar
cliente (RF7)
RNG4 – quando o cliente finalizar o pedido e o cliente não for
cadastrado o sistema deve permitir cadastrar cliente (RF8)
RNG5 – quando o cliente finalizar o pedido o sistema deve cadastrar
endereço de entrega (RF9)
RNG6 – quando o cliente finalizar o pedido o sistema deve permitir
selecionar tipo de pagamento (RF10)
RNG7 – quando o cliente confirmar a compra o sistema deve enviar e-
mail informando status da compra (RF12)


Eduardo Castro
Estudo de Caso
Requisitos não funcionais
• 1. Confiablidade
– O sistema deve garantir que a atualização de dados será feita de forma atômica e imediata,
sempre com registro histórico;
– O sistema deve realizar backups diariamente após a 00:00 hrs;
• 2. Eficiência
– O sistema deve responder a qualquer pesquisa, inclusão, alteração e exclusão em tempo
inferior a 3 (três) segundos;
– O sistema deve garantir que as atualizações dinâmicas de informação única não devem
exceder 1 (um) segundo;
• 3. Portabilidade
– O sistema deve ser executado em em microcomputadores de arquitetura IBM PC, com
processadores Intel P4 2.5Ghz com 512Mb de memória RAM e HD de 40Gb com sistema
operacional Windows XP;
– O sistema deve ser portável para GNU/Linux, com ambiente Desktop GNOME, em máquina
de mesma configuração;
• 4. Usabilidade
– O sistema deve focar em eficiência, fornecendo teclas de atalho para todas as ações mais
importantes;
– O sistema deve seguir as Diretrizes de Interface Humana do projeto GNOME:
http://developer.gnome.org/projects/gup/hig/;


Eduardo Castro

Rastreabilidade


Eduardo Castro
Estudo de Caso
Rastreabilidade

Requisitos Funcionais x Requisitos Complementares

Req.Complementar
RC01 RC02 RC03 RC04 RC05 RC06 RC07 RC08 RC09 RC10
Req. Funcionais
RF01 x
RF02 x
RF03 x
RF04 x
RF05 x
RF06 x
RF07 x
RF08 x
RF09 x
RF10 x
RF11 x
RF12 x


Eduardo Castro
Estudo de Caso
Rastreabilidade

Requisitos Funcionais x Regras de Negocio

Regras de Neg.
RNG01 RNG02 RNG03 RNG04 RNG05 RNG06 RNG07
Req. Funcionais
RF03
x x
RF07
x
RF08
x
RF09
x
RF10
x
RF12
x


Eduardo Castro

Modelagem de Requisitos
Analise O.O.


Eduardo Castro
Estudo de Caso
– Os requisitos funcionais e regras de negócio são
avaliadas de forma a elaborar o diagrama de caso de
uso
– Os casos de uso podem modelar 1 ou um conjunto
de requisitos funcionais que sejam necessários a um
determinado ator realizar sua tarefa.
– Os atores são identificados dos elementos envolvidos
no processo e definidos no Documento de Definição
de Requisitos - DDR


Eduardo Castro
Estudo de Caso


Eduardo Castro

Modelagem de Requisitos
Analise Estruturada


Eduardo Castro
Estudo de Caso
– Os requisitos funcionais, requisitos complementares
e regras de negócio são avaliadas de forma a
elaborar o Diagrama de Contexto - DC e
posteriormente o Diagrama de Fluxo de Dados - DFD
– Os fluxos de dados se relacionam diretamente aos
Requisitos Funcionais - RF, tendo em vista que cada
RF obrigatoriamente possui Requisitos
Complementar que representa os dados.
– As entidades são identificadas dos elementos
envolvidos no processo e definidos no Documento de
Definição de Requisitos - DDR


Eduardo Castro
Estudo de Caso


Eduardo Castro
Estudo de Caso
Analise do Negocio – DAN
Problema Analista Negocio
Solução
Gerente do Projeto

Analise de Requisitos – DDR
RF, RC, RNG
Analista
RNF
Requisitos
Protótipo
Analise do Sistema – UML
DCU
DC Analista
Especificação Sistema
DS
Analise do Banco de Dados – MER
DER
Administrado de Banco de Dados
Desenvolvimento – Linguagem Programação
Código Desenvolvedor


Eduardo Castro


Engenharia Requisitos - Método RON

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Engenharia Requisitos - Método RON

Similaire à Engenharia Requisitos - Método RON (20)

Engenharia Requisitos - Método RON