Engenharia Requisitos - Método RON

Engenharia de Requisitos – Fator de Sucesso em Projetos de Software

Eduard

o C

astr

o

1

Eduardo Castro [email protected]

www.quaddract.com.br

Análise de Negócio

e

Engenharia de Requisitos

Fator de Sucesso em

Projetos de Software

www.quaddract.com.br

mailto:[email protected]

http://www.quaddract.com.br/


Eduard

o C

astr

o

2

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


Eduard

o C

astr

o

3

Causas de Fracasso

em

Projetos de Software


Eduard

o C

astr

o

4

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.

Causas de Fracasso


Eduard

o C

astr

o

5

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

Causas de Fracasso


Eduard

o C

astr

o

6


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

Causas de Fracasso


Eduard

o C

astr

o

7


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

Causas de Fracasso


Eduard

o C

astr

o

8

Evolução do Problema


Eduard

o C

astr

o

9

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



Eduard

o C

astr

o

10

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



Eduard

o C

astr

o

11



Eduard

o C

astr

o

12

Importância dos Requisitos


Eduard

o C

astr

o

13 13

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



Eduard

o C

astr

o

14

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



Eduard

o C

astr

o

15


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


Eduard

o C

astr

o

16

Processo de

Construcao de

Software


Eduard

o C

astr

o

17 17

• Desenvolver sistemas é

automatizar processos de negócio

Eduardo Castro

Análise do Negócio


Eduard

o C

astr

o

18

Relação entre

Processo de Negocio e

Software

Nucleo de Gestao de Resultados

Software

Processo de

Negócio

(BPM)

Conjunto de

Tarefas

Conjunto de

Requisitos

Automação

LP BD

Define


Eduard

o C

astr

o

19

Infra estrutura do processo de construção de software

Mapeamento

de

Processo

Definição

dos

Requisitos

Engenharia de

Software

(SEI)

Gerencia de

Projeto

(PMI)

Controle

e

Monitoramento

Analise de

Negócio

(BPM)

Desenvolvimento

Teste

Manutenção

Cliente Equipe Técnica Gestão

Nucleo de Gestao de Resultados


Eduard

o C

astr

o

20

Nucleo de Gestão de Resultado


Eduard

o C

astr

o

21



Eduard

o C

astr

o

22 22

• "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)



Eduard

o C

astr

o

23 23

• Processo Definido, Requisitos

Identificados, Software com

Qualidade e TI com governança.

Lucia Bastos & Eduardo Castro



Eduard

o C

astr

o

24


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.


Eduard

o C

astr

o

25

• 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



Eduard

o C

astr

o

26

Processo de Negócio


Eduard

o C

astr

o

27

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)

Processo


Eduard

o C

astr

o

28

Sistemas de Informação

DADOS

PROCESSO

INFORMAÇÃO

SISTEMA DE INFORMAÇÃO – S.I.


Eduard

o C

astr

o

29

SISTEMA DE INFORMAÇÃO – S.I.


DADOS

PROCESSO

INFORMAÇÃO Mapeamento do

Processo

Identificação do

Problema

Análise do

Problema

Proposta de

Solução


Eduard

o C

astr

o

30

Mapeamento

do

Processo

Identificação

do

Problema

Análise do

Problema

Análise

do

Negócio

Viabilidade

Produção e

Gerência

de

Requisitos

Definição

dos

Objetivos

Proposta

de

Solução

Funcionalidades

e

Recursos

Definição

dos

Requisitos

Engenharia

de

Requisitos

Análise do Negócio e Requisitos

Descrição

do

Processo


Eduard

o C

astr

o

31



Eduard

o C

astr

o

32

• 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



Eduard

o C

astr

o

33


Requisitos • Definem o que é solicitado ao software fazer e

com quais limitações ele é requisitado a operar

para atender a necessidade do negócio.


• Propõe métodos, técnicas e ferramentas que

auxiliam o processo de descoberta,

documentação e gestão dos requisitos que o

software deve atender.

Gerenciamento de Requisitos

• Gerenciar as mudanças que ocorrem nos

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;


Eduard

o C

astr

o

34


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


Eduard

o C

astr

o

35


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


Eduard

o C

astr

o

36


• A engenharia de requisitos engloba os processos de

produção e gerência de requisitos.


Eduard

o C

astr

o

37

Produção de Requisitos


Eduard

o C

astr

o

38 38

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.



Eduard

o C

astr

o

39

Proposta

de

Solução

Elicitação Análise e

Negociação

Definição dos

Requisitos

Análise do

Negócio

Validação


Produção de

Requisitos

Identificação

das Fontes de

Informação

Análise dos

Requisitos

Documentação

dos Requisitos

Protótipo do

Sistemas


Eduard

o C

astr

o

40

Gerencia de Requisitos


Eduard

o C

astr

o

41



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


Eduard

o C

astr

o

42

Plano de

Gerencia de

Requisitos

Rastreabilidade Controle de

Mudança

Gerencia de

Configuração

Controle de

Mudança

Qualidade dos

Requisitos



Relação entre

Requisitos e

Artefatos

Analise de

Impacto das

Mudanças

Controle de

Versionamento

Padrão de Gestão

e Produção de

Requisitos


Eduard

o C

astr

o

43

Documento de Requisitos


Eduard

o C

astr

o

44

• Dois tipos de DOCUMENTO de REQUISITOS

Clientes Projetistas

Especificação

dos Requisitos Definição

dos Requisitos

•Lista do que o Cliente espera que o

sistema faça;

•Compreensível ao Cliente;

•Consenso entre Cliente e Analista;

•Redefine os requisitos em termos

técnicos;

•Compreensível para o Projetista

•Consenso entre Analista e

Desenvolvedor

•Envolve Modelagem



Eduard

o C

astr

o

45

• 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



Eduard

o C

astr

o

46 46

Processo RON

Requisitos

Orientado ao Negócio

(Eduardo Castro, Direitos Reservados)


Eduard

o C

astr

o

47 47

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

Processo RON®


Eduard

o C

astr

o

48 48


Definição dos Requisitos

Disciplinas

Fases

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

Proposta de Solução

Prototipação

Teste

Gerência de Requisitos

Disciplinas de Apoio

Gerência de Projeto

Métrica de Software

Administração de Dados

Processo RON®

Eduardo José Ribeiro de Castro


Eduard

o C

astr

o

49 49

RON

VISÃO

SISTÊMICA

Pontos de Automação

Melhoria do Sistema Requisitos

Orientado ao

Negócio

Preocupação com a

solução

ESTRATÉGICA

Processo de Negócio

Inicio Fim

Processo RON®


Eduard

o C

astr

o

50

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


Eduard

o C

astr

o

51 51

• 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

Tipos de Requisitos


Eduard

o C

astr

o

52

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

Tipos de Requisitos


Eduard

o C

astr

o

53

• 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

Tipos de Requisitos


Eduard

o C

astr

o

54

Estudo de Caso


Eduard

o C

astr

o

55

Para o sistema descrito a seguir

(Compras NET), escrever os requisitos

funcionais, complementares, regras de

negócio e não funcionais que forem

identificados.

Estudo de Caso


Eduard

o C

astr

o

56

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

Estudo de Caso


Eduard

o C

astr

o

57

Busca

Produto

Adiciona

Produto Achou ?

Possui

Cadastro?

Solicita

Usuário e

Senha

FIM

Cadastra

Usuario e

Senha

Cadastra

Endereço

de Entrega

Sim

Não

Finaliza?

Sim

Não

Não

Sim Seleciona

Opção de

Compra

Confirma

Compra

Sistema

Envia

e-mail

Valida

Usuário e

Senha

Fecha a

Venda

Estudo de Caso

Visualiza

Produto

Modifica

Produto

Inicio Processo de Compra na WEB


Eduard

o C

astr

o

58

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)

Estudo de Caso


Eduard

o C

astr

o

59

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)

Estudo de Caso


Eduard

o C

astr

o

60

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)

Estudo de Caso


Eduard

o C

astr

o

61

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/;

Estudo de Caso


Eduard

o C

astr

o

62

Rastreabilidade


Eduard

o C

astr

o

63

Rastreabilidade

Requisitos Funcionais x Requisitos Complementares

Estudo de Caso

Req.Complementar

Req. Funcionais

RC01 RC02 RC03 RC04 RC05 RC06 RC07 RC08 RC09 RC10

RF01 x

RF02 x

RF03 x

RF04 x

RF05 x

RF06 x

RF07 x

RF08 x

RF09 x

RF10 x

RF11 x

RF12 x


Eduard

o C

astr

o

64

Rastreabilidade

Requisitos Funcionais x Regras de Negocio

Estudo de Caso

Regras de Neg.

Req. Funcionais

RNG01 RNG02 RNG03 RNG04 RNG05 RNG06 RNG07

RF03 x x

RF07 x

RF08 x

RF09 x

RF10 x

RF12 x


Eduard

o C

astr

o

65

Modelagem de Requisitos

Analise O.O.


Eduard

o C

astr

o

66

– 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

Estudo de Caso


Eduard

o C

astr

o

67

Estudo de Caso


Eduard

o C

astr

o

68

Modelagem de Requisitos

Analise Estruturada


Eduard

o C

astr

o

69

– 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

Estudo de Caso


Eduard

o C

astr

o

70

Estudo de Caso


Eduard

o C

astr

o

71

Estudo de Caso

Analise do Negocio – DAN

Problema

Solução

Analise de Requisitos – DDR

RF, RC, RNG

RNF

Protótipo

Analise do Sistema – UML

DCU

DC

Especificação

DS

Analise do Banco de Dados – MER

DER

Desenvolvimento – Linguagem Programação

Código

Analista Negocio

Analista

Requisitos

Analista

Sistema

Administrado de Banco de Dados

Desenvolvedor

Gere

nte

do

Pro

jeto


Eduard

o C

astr

o

72

Estudo de Caso

Analise do Negocio – DAN

Problema

Solução

Analise de Requisitos – DDR

RF, RC, RNG

RNF

Protótipo

Analise do Sistema – UML

DCU

DC

Especificação

DS

Analise do Banco de Dados – MER

DER

Desenvolvimento – Linguagem Programação

Código

Analista Negocio

Analista

Requisitos

Analista

Sistema

Administrado de Banco de Dados

Desenvolvedor

Gere

nte

do

Pro

jeto


Eduard

o C

astr

o

73

Technology

Engenharia Requisitos - Método RON