metodologia de desenvolvimento de sistemas requisitos
TRANSCRIPT
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 1 de 33
Metodologia de Desenvolvimento de Sistemas
Requisitos
20/08/2002
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 2 de 33
Controle de Versão do manual da
Disciplina Requisitos
Versão Controle Data Razões para alteração Responsável
1 0 20/08/2002 Versão Original C. Eduardo M.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 3 de 33
Índice
1 Objetivo....................................................................................................................4
2 Envolvidos na elaboração deste manual ..................................................................4
3 Siglas, Abreviações e Sinônimos .............................................................................4
4 Referências..............................................................................................................6
5 Notação utilizada neste manual ...............................................................................6
6 Disciplina Requisitos ................................................................................................6
6.1 Elicitar Requisitos..............................................................................................8 6.1.1 Detalhamento Gráfico (IDEF3) – Elicitar Requisitos .................................11
6.2 Efetuar Mapeamento Requisitos .....................................................................15 6.2.1 Detalhamento Gráfico (IDEF3) – Efetuar Mapeamento Requisitos...........17
6.3 Revisar Mapeamento Requisitos.....................................................................20 6.3.1 Detalhamento Gráfico (IDEF3) – Revisar Mapeamento Requisitos ..........22
6.4 Validar Requisitos com Cliente........................................................................24 6.4.1 Detalhamento Gráfico (IDEF3) – Validar Requisitos com Cliente .............26
6.5 Estimar software .............................................................................................29 6.5.1 Detalhamento Gráfico (IDEF3) – Estimar software...................................31
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 4 de 33
1 Objetivo
Este documento formaliza a disciplina de Requisitos para a MDS do Grupo Verdi, identificando as atividades e processos a executar para que seja realizado o mapeamento dos requisitos (funcionais através de diagramas Use Case e não funcionais através da lista de requisitos).
2 Envolvidos na elaboração deste manual
EMPRESA NOME ATIVIDADES EXECUTADAS
Marcos Yeisho Tome Revisão dos documentos
Gestão do projeto MDS
Vlademir Bovaroti Revisão dos documentos
João Gubolin Revisão dos documentos
Lúcia Hirata Revisão dos documentos
Verdados
Marcos Blasques Revisão dos documentos
Eduardo Marquioni Geração dos documentos
Gestão do projeto MDS
Fabiano Santos Geração dos documentos
Choose Technologies
Andréa Sales Customização SA2001
3 Siglas, Abreviações e Sinônimos
ITEM DESCRIÇÃO
CASE Computer Aided Software Engineering
Elicitar Realizar levantamento.
MDS Metodologia de Desenvolvimento de Sistemas.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 5 de 33
ITEM DESCRIÇÃO
Requisito Segundo o IEEE1, um requisito é definido como:
(1) Uma condição ou capacidade necessitada por um usuário para resolver um problema ou atingir um objetivo.
(2) Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade.
Uma representação documentada de uma condição ou capacidade como em (1) ou (2).
Requisito funcional São requisitos que precisam fazer parte do produto de software e que envolvem funcionalidade. Derivam diretamente das necessidades de negócio. São especificados através de diagramas Use Case. São exemplos de requisitos funcionais: “calcular valor de comissão de venda” e “emitir relatório mensal de vendas”.
Requisito não funcional
São requisitos que precisam fazer parte do produto de software, mas que não correspondem a funcionalidades propriamente ditas. Não são especificados através de diagramas Use Case. Envolvem normalmente a utilização de padrões vigentes, definição de atributos de qualidade como performance e facilidade de uso, e outros aspectos técnicos de nível mais físico, como o sistema operacional, linguagem de programação e sistema gerenciador de banco de dados a ser utilizado.
Devem ser representados também como requisitos não funcionais restrições de integração, migração de dados e compatibilidade com sistemas legados.
SA System Architect – Ferramenta CASE
TI Tecnologia da Informação
Use Case Caso de Uso � Diagrama da técnica Orientação a Objetos, suportado inclusive pela UML.
UML Unified Modeling Language
1 Instituto de Engenharia Elétrica e Eletrônica
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 6 de 33
4 Referências
• Manual Técnico Use Case;
• Apostila Treinamento Use Case.
5 Notação utilizada neste manual
Produtos gerados (documentação).
Técnicas utilizadas (na elaboração de diagramas).
Dica ou lembrete.
Não faça.
Tarefas a executar.
6 Disciplina Requisitos
Disciplina na qual são formalizados os requisitos funcionais e não funcionais do sistema. Os requisitos funcionais serão formalizados na lista de requisitos e, graficamente, através de diagramas Use Case e Use Case Detalhado. Os requisitos não funcionais serão formalizados na lista de requisitos.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 7 de 33
A0 1-Disciplina Requisitos (IDEF0) System Architect
Tue Aug 06, 2002 11:39 Comment
Choose Technologies Verdados
A0 0
A0 0
A0 0
A0 0
A0 0
Ferramenta CASE
Lista Requisitos preliminares Sumário Executivo
do Projeto
Solicitação estimativa software
Manutenção aprovada
Planilha de estimativa
Use Cases Detalhados
Lista de Requisitos
Diagramas Use Case Detalhados revisados e validados
Diagramas Use Case revisados e validados
Necessidades do Negócio
Gerente de Projeto
Cliente Analista de Negócios
Técnica Use Case
Solicitação correção requisitos
Diagramas Use Case para validação
Solicitação correção técnica Use Cases
Check list Revisor Gerente de Projeto
Analista de Negócios
Use Cases
Diagramas IDEF0 revisados e validados
Esforço
Quantidade Pontos por Use Case
Pontos por Use Case
Técnica Use Case
Disciplina Requisitos
Cliente Analista de Negócios
Solicitação de Alteração
Diagramas IDEF3 revisados e validados
Elicitar Requisitos
Efetuar Mapeamento
Requisitos Revisar Mapeamento
Requisitos Validar Requisitos
com Cliente
Estimar software
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 8 de 33
6.1 Elicitar Requisitos
A0 1-Disciplina Requisitos (IDEF0)System Architect
Tue Aug 06, 2002 11:39Comment
Choose TechnologiesVerdados
A00
Validar Requisitos comCliente
A00
Estimar software
A00
Elicitar Requisitos
A00
Revisar MapeamentoRequisitos
A00
EfetuarMapeamentoRequisitos
FerramentaCASE
Lista RequisitospreliminaresSumário Executivo
do Projeto
Solicitaçãoestimativa software
Manutençãoaprovada
Planilha deestimativa
Use CasesDetalhados
Lista de Requisitos
Diagramas Use CaseDetalhados revisados e validados
Diagramas Use Caserevisados e validados
Necessidadesdo Negócio
Gerente de Projeto
ClienteAnalista deNegócios
Técnica Use Case
Solicitação correção requisitos
Diagramas Use Casepara validação
Solicitação correção técnica Use Cases
Check listRevisorGerente de Projeto
Analista deNegócios
Use Cases
Diagramas IDEF0revisados e validados
Esforço
Quantidade Pontospor Use Case
Pontos por Use Case
Técnica Use Case
DisciplinaRequisitos
ClienteAnalista deNegócios
Solicitaçãode Alteração
Diagramas IDEF3revisados e validados
Descrição Atividade na qual serão identificados os requisitos que farão parte do
software (tanto funcionais quanto não funcionais).
- Os requisitos funcionais são resultado direto da MPN, no sentido em que via de regra corresponderão a processos de negócio que serão informatizados ou terão a informatização reavaliada, em função de mudanças na forma de execução do negócio.
- Os requisitos não funcionais são identificados em função das características técnicas a que o produto de software deverá atender. Normalmente esses requisitos são extraídos a partir de padrões adotados ou recomendados pela Organização (linguagem de programação, sistema gerenciador de banco de dados, estratégia de distribuição, etc), além de necessidade de integração com sistemas legados. A identificação dos requisitos não funcionais é de suma importância pois irão fazer parte das avaliações de ajustes de estimativas.
Esta atividade pode ser iniciada de 2 formas distintas:
1. quando os diagramas gerados durante a Modelagem de Negócio necessitarem ser mapeados em requisitos através de técnicas de Análise de Sistemas (use case);
2. após a validação com o cliente, e este apontar não conformidades - que podem ser resultantes de incompatibilidade entre o modelo de negócio e os use cases, da ausência de mapeamento de funcionalidades necessárias omitidas ou pelo excesso de funcionalidades recomendadas.
Para definições de requisitos funcionais e requisitos não funcionais, vide o capítulo "Siglas, Abreviações e Sinônimos" no manual da disciplina Requisitos.
Detalhamento Gráfico (IDEF3)
Entradas Descrição
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 9 de 33
Entradas Descrição
Solicitação correção requisitos
Corresponde à lista de não conformidades identificadas durante a validação pelo cliente dos diagramas Use Case.
Estas não conformidades podem se referir a:
- Incompatibilidade da execução dos use cases com o modelo de negócio definido;
- Funcionalidades necessárias não mapeados nos diagramas use case;
- Funcionalidades desnecessárias mapeados nos diagramas use case.
Diagramas IDEF0 revisados e validados
Corresponde aos diagramas IDEF0 revisados e validados pelo cliente, com a garantia que representem as atividades do negócio em questão de maneira pertinente e fidedigna - tanto para o modelo AS-IS quanto TO-BE.
Diagramas IDEF3 revisados e validados
Corresponde aos diagramas IDEF3 revisados e validados pelo cliente, com a garantia que representem os processos do negócio em questão de maneira pertinente e fidedigna - tanto para o modelo AS-IS quanto TO-BE.
Sumário Executivo do Projeto
Corresponde ao documento Sumário Executivo do Projeto, versionado, quando recebida uma solicitação do usuário e posterior aprovação do Diretor da TI Compartilhada.
O Sumário Executivo do Projeto pode não ser enviado quando se tratar de manutenção corretiva e que não provoque impacto nas regras de negócio.
Solicitação de Alteração
Corresponde à Solicitação de Serviço que foi classificada como manutenção corretiva ou evolutiva.
Saídas Descrição
Lista Requisitos preliminares
Corresponde à lista preliminar de requisitos funcionais e não funcionais do projeto de software a ser desenvolvido, devidamente formalizados na lista de requisitos.
Nos casos de manutenção, a lista de requisitos preliminares terá embutida o relatório de impacto.
Regras de Negócio Descrição
Disciplina Requisitos Metodologia de Desenvolvimento de Sistemas do Grupo Verdi, disciplina que trata Requisitos.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 10 de 33
Insumos Descrição
Analista de Negócios Vide Matriz de Papéis e Responsabilidades para definição.
Cliente Vide Matriz de Papéis e Responsabilidades para definição.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 11 de 33
6.1.1 Detalhamento Gráfico (IDEF3) – Elicitar Requisitos
1. Elicitar Requisitos (IDEF3 Process Flow)System Architect
Tue Aug 06, 2002 10:56Comment
Choose TechnologiesVerdados
Elaborar lista preliminarde requisitos nãofuncionais
Identificar processos denegócio afetados
Identificar processos denegócio afetados
Elaborar listapreliminar derequisitos funcionais
Receber SumárioExecutivo do Projeto
Receber IDEF3
Receber Solicitaçãode Alteração
Receber IDEF0
Receber IDEF0
Receber SumárioExecutivo do Projeto
Receber IDEF3
Coletar padrõestécnicos vigentes
Identificarnecessidadestécnicas
Enviar estimativaesforço ao cliente
Enviar relatório deimpacto ao cliente
Solicitarestimativa esforço
Gerar relatório deimpacto
Analisar impactono softwareconstruído
Manutenção
NovoDesenvolvimento
OJ
OJ
&J
&J
&J
OJ
OJ
L
L
LL
L
L
LL
L
L
L
L
L
LLL
L
L
L
L
L
L
L
L
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 12 de 33
Lista de Requisitos
Relatório de Impacto (apenas para manutenções)
Recomendações de escrita para requisitos:
Com o objetivo de facilitar a escrita e a leitura dos requisitos, estes devem ser descritos em linguagem natural, em sentenças curtas e simples e terminologia clara. Observe:
� Escrever sentenças curtas;
� Evitar o uso de "e", para não correr o risco de definir dois requisitos em um;
� Evitar o uso de jargões, abreviações e acrônimos, a menos que se tenha certeza de possuir o mesmo entendimento para todos os stakeholders
2.
� Não utilizar o mesmo termo com significados diferentes;
� Utilizar um dicionário de dados;
� Utilizar a voz ativa nas sentenças;
� Ser cuidadoso com o vocabulário e a gramática.
É altamente arriscado não avaliar análise de impacto em casos de manutenção, pois a documentação pode não ser atualizada e/ou prazos podem ser subestimados.
Gerar lista de requisitos
Gerar relatório de impacto (apenas para manutenções)
Processo Descrição
Cenário: Novo Desenvolvimento
Receber IDEF0 Processo em que o Analista de Negócios recebe os diagramas IDEF0 criados/atualizados e devidamente validados durante a execução da Disciplina Modelagem de Negócio.
Receber IDEF3 Processo em que o Analista de Negócios recebe os diagramas IDEF3 criados/atualizados e devidamente validados durante a execução da Disciplina Modelagem de Negócio.
2 stakeholders são todos os envolvidos (partes interessadas) do projeto
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 13 de 33
Processo Descrição
Cenário: Novo Desenvolvimento
Receber Sumário Executivo do Projeto
Processo em que o Analista de Negócios recebe o Sumário Executivo do Projeto para que possa identificar funcionalidades e características necessárias ao produto de software.
Identificar processos de negócio afetados
Processo em que o Analista de Negócios identifica quais atividades de negócio, fluxos e processos de software serão transformados e/ou atualizados em produto de software.
Durante a execução deste processo o analista deve estar atento às funcionalidades (requisitos funcionais) que o software deverá ter atualizadas ou criadas.
Elaborar lista preliminar de requisitos funcionais
Processo em que o Analista de Negócios formaliza os requisitos funcionais do produto de software na Lista de Requisitos.
Identificar necessidades técnicas
Processo em que o Analista de Negócios avalia necessidades de integração com sistemas legados, migração de dados, atributos de performance e segurança para que possam ser identificados requisitos não funcionais do produto de software.
Coletar padrões técnicos vigentes
Processo em que o Analista de Negócios coleta informações relativas a:
- Diretriz Estratégica de TI da Organização;
- Ambiente de TI do cliente (mainframe, cliente servidor, WEB, ...);
para que possa identificar os requisitos não funcionais do produto de software.
Elaborar lista preliminar de requisitos não funcionais
Processo em que o Analista de Negócios formaliza os requisitos não funcionais do produto de software na Lista de Requisitos.
Processo Descrição
Cenário: Manutenção
Receber Solicitação de Alteração
Vide descrição do fluxo de entrada Solicitação de Alteração.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 14 de 33
Processo Descrição
Cenário: Manutenção
Analisar impacto no software construído
Processo em que o Analista de Negócios identifica, no(s) software(s) existente(s), as alterações que serão necessárias ser executadas para atender à necessidade de manutenção. Devem ser avaliados impactos candidatos relativos a:
- Documentação de Negócio (IDEF0 e IDEF3);
- Diagramas Use Case;
- Diagramas Use Case Detalhados;
- Modelo de Classes Conceitual;
- Modelo de Classes de Implementação;
- Diagrama Entidade Relacionamento;
- Diagrama de Seqüência;
- Diagrama de Componentes;
- Protótipos de Telas;
- Telas;
- Programas fonte;
- Tabelas.
Uma vez identificados os candidatos a alteração, o Analista de Negócios deve avaliar quais artefatos terão que efetivamente ser alterados.
Esta avaliação deve ser realizada tanto para o software que terá a manutenção propriamente dita, bem como para todos aqueles que mantém interface direta com ele.
Gerar relatório de impacto
Processo em que o Analista de Negócios formaliza quais artefatos técnicos efetivamente precisarão ser atualizados em função da alteração requisitada.
Solicitar estimativa esforço
Processo em que o analista de negócios solicita ao gerente do projeto a aplicação da Planilha de Estimativa com Pontos por Use Case para identificar o esforço necessário à manutenção.
Enviar estimativa esforço ao cliente
Processo em que o esforço necessário à manutenção é informado ao cliente.
Enviar relatório de impacto ao cliente
Processo em que é enviado ao cliente o relatório contendo os artefatos que necessitarão passar por alteração em função da manutenção requisitada.
Demais processos Idem cenário Novo Desenvolvimento.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 15 de 33
6.2 Efetuar Mapeamento Requisitos
A0 1-Disciplina Requisitos (IDEF0)System Architect
Tue Aug 06, 2002 11:39Comment
Choose TechnologiesVerdados
A00
Validar Requisitos comCliente
A00
Estimar software
A00
Elicitar Requisitos
A00
Revisar MapeamentoRequisitos
A00
EfetuarMapeamentoRequisitos
FerramentaCASE
Lista RequisitospreliminaresSumário Executivo
do Projeto
Solicitaçãoestimativa software
Manutençãoaprovada
Planilha deestimativa
Use CasesDetalhados
Lista de Requisitos
Diagramas Use CaseDetalhados revisados e validados
Diagramas Use Caserevisados e validados
Necessidadesdo Negócio
Gerente de Projeto
ClienteAnalista deNegócios
Técnica Use Case
Solicitação correção requisitos
Diagramas Use Casepara validação
Solicitação correção técnica Use Cases
Check listRevisorGerente de Projeto
Analista deNegócios
Use Cases
Diagramas IDEF0revisados e validados
Esforço
Quantidade Pontospor Use Case
Pontos por Use Case
Técnica Use Case
DisciplinaRequisitos
ClienteAnalista deNegócios
Solicitaçãode Alteração
Diagramas IDEF3revisados e validados
Descrição Atividade na qual os requisitos funcionais serão mapeados através da
criação de diagramas Use Case e/ou Use Case Detalhado.
Para ambos os tipos de diagrama, a criação somente será considerada concluída quando todos os objetos constantes naqueles diagramas estiverem devidamente desenhados, descritos e com rastreabilidade para o ambiente de negócio identificada na ferramenta CASE.
Esta atividade pode ser iniciada de 3 formas distintas:
1. após a criação/atualização da lista de requisitos, quando o analista de negócios irá formalizar os requisitos funcionais através de Use Cases;
2. após a revisão técnica do mapeamento, quando houver não conformidades técnicas identificadas pelo revisor nos diagramas criados;
3. quando, em manutenções, o cliente aprovar uma análise de impacto que envolva necessidade de atualização em requisitos funcionais (via use case) ou não funcionais (via lista de requisitos).
Detalhamento Gráfico (IDEF3)
Entradas Descrição
Solicitação correção técnica Use Cases
Corresponde às não conformidades técnicas identificadas durante a revisão técnica pelo revisor dos diagramas Use Case.
Manutenção aprovada Corresponde à aprovação pelo cliente do relatório de impacto de uma alteração requisitada a um produto de software.
Lista Requisitos preliminares
Corresponde à lista preliminar de requisitos funcionais e não funcionais do projeto de software a ser desenvolvido, devidamente formalizados na lista de requisitos.
Nos casos de manutenção, a lista de requisitos preliminares terá embutida o relatório de impacto.
Saídas Descrição
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 16 de 33
Saídas Descrição
Use Cases Detalhados Corresponde aos diagramas Use Case Detalhados elaborados (desenho e descrição, na ferramenta CASE).
Use Cases Corresponde aos diagramas Use Case elaborados (desenho, descrição e rastreabilidade para o ambiente de negócios, na ferramenta CASE).
Regras de Negócio Descrição
Técnica Use Case Notação e regras da técnica Use Case, segundo a UML.
Insumos Descrição
Analista de Negócios Vide Matriz de Papéis e Responsabilidades para definição.
Ferramenta CASE Ferramenta CASE utilizada pela Organização para criação de diagramas técnicos - SA 2001 - versão 8.5.24 (ou superior).
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 17 de 33
6.2.1 Detalhamento Gráfico (IDEF3) – Efetuar Mapeamento Requisitos
Recebersolicitaçãocorreção técnica
1. Efetuar Mapeamento Requisitos (IDEF3Process Flow)
System ArchitectTue Aug 06, 2002 10:45
CommentChoose Technologies
Verdados
Estabelecerrastreabilidade comatividade de negócio naCASE
Elaborar diagramasUse Case Detalhado naCASE
Elaborar diagramasUse Case na CASE
Descrever diagramasUse Case Detalhadona CASE
Descrever diagramasUse Case na CASE
Recebernecessidade deMapeamentoRequisitos
Recebermanutençãoaprovada
Enviar diagramaspara revisãotécnica
Receber listarequisitosfuncionais
&J
XJ
OJ
OJ
L L
L
L
L
L
L
L
L
L
L
L
L
L
Diagrama Use Case
Diagrama Use Case Detalhado
Use Case
Use Case Detalhado
Durante a elaboração dos diagramas Use Case Detalhado, pode ser interessante elaborar “rascunhos” de protótipos de telas na própria ferramenta CASE, que são “atachados” como filhos dos objetos de interface.
Aplique refinamento de use cases apenas quando os diagramas Use Case estiverem relativamente estáveis.
Deixar de estabelecer rastreabilidade com a atividade de negócio que originou o use case dificulta a análise de impacto nos casos de manutenção.
Elaborar diagramas Use Case
Descrever diagramas Use Case
Elaborar Use Case Detalhado
Descrever diagramas Use Case Detalhado
Enviar diagramas para revisão
Processo Descrição
Receber lista requisitos funcionais
Processo em que o Analista de Negócios recebe a lista de requisitos funcionais para poder identificar os Use Cases necessários ao software.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 18 de 33
Processo Descrição
Receber solicitação correção técnica
Processo em que o analista de negócios recebe as não conformidades técnicas identificadas durante a revisão, para que possa proceder com os ajustes necessários. Essas não conformidades estarão descritas no Documento Lista de Não Conformidades.
Receber necessidade de Mapeamento Requisitos
Processo em que o Analista de Negócios inicia o mapeamento de requisitos (quando se tratar de um novo desenvolvimento).
Receber manutenção aprovada
Processo em que são iniciados os trabalhos do papel envolvido (vide Matriz de Papéis e Responsabilidades) quando se tratar de uma manutenção que teve relatório de impacto aprovado pelo cliente.
Elaborar diagramas Use Case na CASE
Processo em que o Analista de Negócios cria e/ou atualiza os diagramas Use Case na ferramenta CASE utilizada na Organização. A elaboração envolve:
- Criação/Atualização dos Use Cases;
- Criação/Atualização das associações em Use Cases (refinamento/estruturação de Use Case);
- Criação/Atualização de Atores.
Descrever diagramas Use Case na CASE
Processo em que são descritos na ferramenta CASE:
- Os atores de use cases;
- Os use cases;
- As associações entre atores e use cases e entre use cases.
Estabelecer rastreabilidade com atividade de negócio na CASE
Processo em que é informada na ferramenta CASE qual atividade de negócio (IDEF0) originou o use case para que possa ser facilitada a análise de impacto posterior, quando necessária.
Elaborar diagramas Use Case Detalhado na CASE
Processo em que o Analista de Negócios cria e/ou atualiza os diagramas Use Case Detalhado na ferramenta CASE utilizada na Organização. A elaboração envolve:
- Criação/Atualização de objetos de interface;
- Criação/Atualização de objetos de controle;
- Criação/Atualização de objetos de dados (informação);
- Criação/Atualização de Atores.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 19 de 33
Processo Descrição
Descrever diagramas Use Case Detalhado na CASE
Processo em que são descritos na ferramenta CASE:
- Os objetos de interface;
- Os objetos de controle;
- Os objetos de dados (informação).
Enviar diagramas para revisão técnica
Processo em que o analista de negócios envia os diagramas criados para que sejam revisados quanto às técnicas utilizadas.
Note que o envio para revisão deve ocorrer tanto para o modelo AS-IS quanto para o TO-BE, quando for o caso.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 20 de 33
6.3 Revisar Mapeamento Requisitos
A0 1-Disciplina Requisitos (IDEF0)System Architect
Tue Aug 06, 2002 11:39Comment
Choose TechnologiesVerdados
A00
Validar Requisitos comCliente
A00
Estimar software
A00
Elicitar Requisitos
A00
Revisar MapeamentoRequisitos
A00
EfetuarMapeamentoRequisitos
FerramentaCASE
Lista RequisitospreliminaresSumário Executivo
do Projeto
Solicitaçãoestimativa software
Manutençãoaprovada
Planilha deestimativa
Use CasesDetalhados
Lista de Requisitos
Diagramas Use CaseDetalhados revisados e validados
Diagramas Use Caserevisados e validados
Necessidadesdo Negócio
Gerente de Projeto
ClienteAnalista deNegócios
Técnica Use Case
Solicitação correção requisitos
Diagramas Use Casepara validação
Solicitação correção técnica Use Cases
Check listRevisorGerente de Projeto
Analista deNegócios
Use Cases
Diagramas IDEF0revisados e validados
Esforço
Quantidade Pontospor Use Case
Pontos por Use Case
Técnica Use Case
DisciplinaRequisitos
ClienteAnalista deNegócios
Solicitaçãode Alteração
Diagramas IDEF3revisados e validados
Descrição Atividade que recebe os diagramas Use Case e Use Case Detalhado
criados, para que sejam submetidos a uma revisão em relação à técnica (notação e regras).
Detalhamento Gráfico (IDEF3)
Entradas Descrição
Use Cases Detalhados Corresponde aos diagramas Use Case Detalhados elaborados (desenho e descrição, na ferramenta CASE).
Use Cases Corresponde aos diagramas Use Case elaborados (desenho, descrição e rastreabilidade para o ambiente de negócios, na ferramenta CASE).
Saídas Descrição
Diagramas Use Case para validação
Corresponde aos diagramas Use Case e Use Case Detalhado revisados (inclusive descrições) tecnicamente sem não conformidades, que serão submetidos à validação do cliente.
Solicitação correção técnica Use Cases
Corresponde às não conformidades técnicas identificadas durante a revisão técnica pelo revisor dos diagramas Use Case.
Regras de Negócio Descrição
Técnica Use Case Notação e regras da técnica Use Case, segundo a UML.
Insumos Descrição
Revisor Vide Matriz de Papéis e Responsabilidades para definição.
Gerente de Projeto Vide Matriz de Papéis e Responsabilidades para definição.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 21 de 33
Insumos Descrição
Check list Artefato utilizado para realizar a revisão técnica, que contém os itens a serem revisados pelo inspetor durante a revisão do mapeamento realizado.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 22 de 33
6.3.1 Detalhamento Gráfico (IDEF3) – Revisar Mapeamento Requisitos
Identificar analistapara revisão
1. Revisar Mapeamento Requisitos (IDEF3Process Flow)
System ArchitectTue Aug 06, 2002 10:58
CommentChoose Technologies
Verdados
Receber diagramasUse Case criados
Receber diagramasUse Case Detalhadocriados
Disponibilizar paravalidação derequisitos
Coletar check-listUse Case
Solicitar correçãotécnica
Avaliar revisãoAplicar check-listaos diagramas
XJ
&J
OJ
NÃO foi encontradanão conformidade
Foi encontradanão conformidade
LLL
L
LL
L
L
Lista de Não Conformidades para Requisitos preenchida.
É recomendável que o próprio analista de negócios execute o check-list antes de enviar os diagramas para revisão. A maioria das eventuais não conformidades serão detectadas pelo próprio analista de negócios, antes que o revisor inicie seu trabalho quando seguida esta prática.
Não se esqueça que a revisão realizada neste momento é técnica: o revisor não deve se preocupar com a revisão dos requisitos – que será feita posteriormente com o cliente.
Como o nome sugere, esta revisão possui caráter técnico, e devem ser evitados atritos entre o revisor e o autor dos diagramas revisados no que tange às não conformidades encontradas.
Eleger analista para realizar a revisão;
Executar a revisão;
Gerar relatório Lista de Não Conformidades para Requisitos.
Processo Descrição
Receber diagramas Use Case criados
Corresponde ao fato de o revisor receber os diagramas Use Case criados pelo analista de negócios para que possa proceder com a revisão.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 23 de 33
Processo Descrição
Receber diagramas Use Case Detalhado criados
Corresponde ao fato de o revisor receber os diagramas Use Case Detalhado criados pelo analista de negócios para que possa proceder com a revisão.
Identificar analista para revisão
A identificação do analista para revisão se dá através de envio de e-mail do analista de negócios que elaborou os diagramas ao Gerente de Projeto, informando a localização da enciclopédia para inspeção. O Gerente de Projeto irá identificar o revisor que irá realizar a revisão (de acordo com as atividades de cada analista de sua equipe), e encaminhar o e-mail ao escolhido.
Coletar check-list Use Case
Corresponde ao ato de o revisor coletar a versão vigente do check-list de Use Case para que possa realizar a inspeção.
A versão vigente do check-list encontra-se no diretório de rede que se refere à disciplina de Requisitos.
Aplicar check-list aos diagramas
Processo em que o revisor executa o check-list item a item, confrontando-os com os diagramas criados pelo analista de negócios. Corresponde à revisão técnica propriamente dita.
Avaliar revisão Processo em que o revisor verifica, após o término da revisão, se foi gerada alguma não conformidade técnica.
Solicitar correção técnica
Caso a revisão identifique alguma não conformidade, esta deverá ser informada ao analista de negócios que criou os diagramas, para que ele possa proceder com a correção técnica.
A informação se dá através do envio do check-list preenchido, mais a Lista de Não Conformidades com os devidos comentários ao analista que solicitou a revisão.
Disponibilizar para validação de requisitos
Caso a revisão não identifique nenhuma não conformidade, os diagramas Use Case e/ou Use Case Detalhado serão disponibilizados para que o analista de negócios possa realizar a validação dos requisitos junto ao cliente - para verificar se a solução de software proposta pelo analista atende às necessidades do negócio.
A informação se dá através do envio do check-list preenchido sem comentários de não conformidades ao analista que solicitou a revisão.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 24 de 33
6.4 Validar Requisitos com Cliente
A0 1-Disciplina Requisitos (IDEF0)System Architect
Tue Aug 06, 2002 11:39Comment
Choose TechnologiesVerdados
A00
Validar Requisitos comCliente
A00
Estimar software
A00
Elicitar Requisitos
A00
Revisar MapeamentoRequisitos
A00
EfetuarMapeamentoRequisitos
FerramentaCASE
Lista RequisitospreliminaresSumário Executivo
do Projeto
Solicitaçãoestimativa software
Manutençãoaprovada
Planilha deestimativa
Use CasesDetalhados
Lista de Requisitos
Diagramas Use CaseDetalhados revisados e validados
Diagramas Use Caserevisados e validados
Necessidadesdo Negócio
Gerente de Projeto
ClienteAnalista deNegócios
Técnica Use Case
Solicitação correção requisitos
Diagramas Use Casepara validação
Solicitação correção técnica Use Cases
Check listRevisorGerente de Projeto
Analista deNegócios
Use Cases
Diagramas IDEF0revisados e validados
Esforço
Quantidade Pontospor Use Case
Pontos por Use Case
Técnica Use Case
DisciplinaRequisitos
ClienteAnalista deNegócios
Solicitaçãode Alteração
Diagramas IDEF3revisados e validados
Descrição Atividade na qual os diagramas Use Case serão apresentados ao cliente
para que ele possa validar se sua necessidade, que originou o contato com a área de TI foi efetivamente compreendida, mapeada e se ele concorda com a solução de software que foi concebida até o momento.
Apresentar ao cliente significa realizar leitura conjunta de todos os diagramas e descrições associadas a eles.
Detalhamento Gráfico (IDEF3)
Entradas Descrição
Diagramas Use Case para validação
Corresponde aos diagramas Use Case e Use Case Detalhado revisados (inclusive descrições) tecnicamente sem não conformidades, que serão submetidos à validação do cliente.
Saídas Descrição
Solicitação correção requisitos
Corresponde à lista de não conformidades identificadas durante a validação pelo cliente dos diagramas Use Case.
Estas não conformidades podem se referir a:
- Incompatibilidade da execução dos use cases com o modelo de negócio definido;
- Funcionalidades necessárias não mapeados nos diagramas use case;
- Funcionalidades desnecessárias mapeados nos diagramas use case.
Lista de Requisitos Corresponde à lista de requisitos (funcionais e não funcionais) refinada em relação a sua versão anterior, em função do mapeamento através dos diagramas Use Case e consequente maior visibilidade do produto de software a gerar.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 25 de 33
Saídas Descrição
Diagramas Use Case revisados e validados
Corresponde aos diagramas Use Case revisados e validados pelo cliente, com a garantia que atendem às necessidades do negócio em questão de maneira viável.
Esses diagramas Use Case serão utilizados para refinamento da solução de software através de outros diagramas da orientação a objetos (Disciplina Análise e Design) e também para a definição de casos de testes (Disciplina Testes).
Diagramas Use Case Detalhados revisados e validados
Corresponde aos diagramas Use Case Detalhados revisados e validados pelo cliente, com a garantia que atendem às necessidades do negócio em questão de maneira viável.
Esses diagramas Use Case Detalhados serão utilizados para refinamento da solução de software através de outros diagramas da orientação a objetos (Disciplina Análise e Design) e também para a definição de casos de testes (Disciplina Testes).
Regras de Negócio Descrição
Necessidades do Negócio
Corresponde às necessidades apontadas pelo o negócio que originaram a necessidade do desenvolvimento ou manutenção do software.
Insumos Descrição
Analista de Negócios Vide Matriz de Papéis e Responsabilidades para definição.
Cliente Vide Matriz de Papéis e Responsabilidades para definição.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 26 de 33
6.4.1 Detalhamento Gráfico (IDEF3) – Validar Requisitos com Cliente
1. Validar Requisitos com Cliente (IDEF3Process Flow)
System ArchitectTue Aug 06, 2002 10:48
CommentChoose Technologies
Verdados
Disponibilizar Use CaseDetalhado para Análise eDesign
Disponibilizar Use Casepara Análise e Design
Comunicar gerente doprojeto - Requisitos
Enviar paracorreção requisitos
Anotar ajustes emrequisitos
Apresentardiagramas UseCase Detalhado
Apresentardiagramas UseCase
Agendar reuniãovalidaçãorequisitos
Avaliar diagramascom cliente
OJ
&J
XExistem ajustes derequisitos a realizar?O
J
OJ
Não
Sim L
L
L
L
L
L
L
L
L L
L
L
Requisitos aprovados
Como a técnica em uso durante a disciplina requisitos é Use Case, tenha sempre em mente que o desenho (diagrama) representa apenas cerca de 25% do conteúdo do diagrama (os restantes 75% estão na descrição dos use cases: caminhos básico e alternativo). Com isso, mais importante que “ensinar” o cliente a ler use cases, é validar o conteúdo descritivo dos diagramas.
Se houver tempo, realizar anotações de ajustes durante a validação, para evitar necessidade de nova reunião para elicitação (tempo do cliente).
Não inicie refinamentos em diagramas antes de validar os já existentes (inclusive descrições) com o cliente para evitar retrabalho.
Agendar reunião de validação de requisitos;
Realizar reunião de validação de requisitos.
Processo Descrição
Agendar reunião validação requisitos
O analista de negócios entra em contato com o cliente para agendar reunião de validação, e marca uma data e horário para a validação dos requisitos formalizados via Use Case.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 27 de 33
Processo Descrição
Apresentar diagramas Use Case
O analista de negócios, na data e hora marcadas apresenta os diagramas Use Case para o cliente.
Apresentar diagramas Use Case Detalhado
O analista de negócios, na data e hora marcadas apresenta os diagramas Use Case Detalhado para o cliente.
Avaliar diagramas com cliente
Durante a apresentação dos diagramas, o analista de negócios deve realizar a leitura, em conjunto com o cliente de todos os diagramas e descrições associadas a eles.
Representa alto risco para o projeto de software não realizar esta avaliação em conjunto.
Anotar ajustes em requisitos
O analista de negócios deve, durante a avaliação, realizar anotações de todos os comentários realizados pelo cliente que caracterizem reprovação dos requisitos em relação a cada um dos diagramas ou descrições apresentadas.
Representa alto risco para o projeto de software não anotar estes comentários durante a reunião de validação (podem ocorrer esquecimentos posteriores).
Uma boa prática é realizar as anotações no próprio corpo do diagrama, durante a validação.
A reprovação dos requisitos pelo cliente pode ser originada por:
- Incompatibilidade da execução dos use cases com o modelo de negócio definido;
- Funcionalidades necessárias não mapeados nos diagramas use case;
- Funcionalidades desnecessárias mapeadas nos diagramas use case.
Enviar para correção requisitos
Processo em que o analista de negócios, de posse das anotações realizadas, se prepara para realizar nova elicitação de requisitos.
Disponibilizar Use Case para Análise e Design
Processo em que os diagramas Use Case são disponibilizados para que possam ocorrer refinamentos (disciplina Análise e Design da MDS).
Corresponde ao "elo" entre as disciplinas de Requisitos e Análise e Design.
Para mais detalhes, vide a descrição do fluxo de saída "Diagramas Use Case revisados e validados".
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 28 de 33
Processo Descrição
Disponibilizar Use Case Detalhado para Análise e Design
Processo em que os diagramas Use Case Detalhado são disponibilizados para que possam ocorrer refinamentos (disciplina Análise e Design da MDS).
Corresponde ao "elo" entre as disciplinas de Requisitos e Análise e Design.
Para mais detalhes, vide a descrição do fluxo de saída "Diagramas Use Case Detalhados revisados e validados".
Comunicar gerente do projeto - Requisitos
Processo em que o analista de negócios comunica ao gerente do projeto a situação do Mapeamento de Requisitos. Envolve enviar ao gerente do projeto a enciclopédia contendo os diagramas Use Case criados.
Esta comunicação é fundamental para que o gerente possa proceder com o planejamento das próximas etapas do projeto de software, bem como atualizar seu relatório de acompanhamento.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 29 de 33
6.5 Estimar software
A0 1-Disciplina Requisitos (IDEF0)System Architect
Tue Aug 06, 2002 11:39Comment
Choose TechnologiesVerdados
A00
Validar Requisitos comCliente
A00
Estimar software
A00
Elicitar Requisitos
A00
Revisar MapeamentoRequisitos
A00
EfetuarMapeamentoRequisitos
FerramentaCASE
Lista RequisitospreliminaresSumário Executivo
do Projeto
Solicitaçãoestimativa software
Manutençãoaprovada
Planilha deestimativa
Use CasesDetalhados
Lista de Requisitos
Diagramas Use CaseDetalhados revisados e validados
Diagramas Use Caserevisados e validados
Necessidadesdo Negócio
Gerente de Projeto
ClienteAnalista deNegócios
Técnica Use Case
Solicitação correção requisitos
Diagramas Use Casepara validação
Solicitação correção técnica Use Cases
Check listRevisorGerente de Projeto
Analista deNegócios
Use Cases
Diagramas IDEF0revisados e validados
Esforço
Quantidade Pontospor Use Case
Pontos por Use Case
Técnica Use Case
DisciplinaRequisitos
ClienteAnalista deNegócios
Solicitaçãode Alteração
Diagramas IDEF3revisados e validados
Descrição Atividade na qual é calculado o esforço necessário para desenvolver o
software em questão.
Detalhamento Gráfico (IDEF3)
Entradas Descrição
Use Cases Corresponde aos diagramas Use Case elaborados (desenho, descrição e rastreabilidade para o ambiente de negócios, na ferramenta CASE).
Lista Requisitos preliminares
Corresponde à lista preliminar de requisitos funcionais e não funcionais do projeto de software a ser desenvolvido, devidamente formalizados na lista de requisitos.
Nos casos de manutenção, a lista de requisitos preliminares terá embutida o relatório de impacto.
Solicitação de Alteração
Corresponde à Solicitação de Serviço que foi classificada como manutenção corretiva ou evolutiva.
Diagramas IDEF3 revisados e validados
Corresponde aos diagramas IDEF3 revisados e validados pelo cliente, com a garantia que representem os processos do negócio em questão de maneira pertinente e fidedigna - tanto para o modelo AS-IS quanto TO-BE.
Diagramas IDEF0 revisados e validados
Corresponde aos diagramas IDEF0 revisados e validados pelo cliente, com a garantia que representem as atividades do negócio em questão de maneira pertinente e fidedigna - tanto para o modelo AS-IS quanto TO-BE.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 30 de 33
Entradas Descrição
Solicitação estimativa software
Corresponde a uma solicitação de realização de estimativa de software que pode ser realizada a qualquer momento, durante, antes de iniciar ou mesmo após encerrar o desenvolvimento ou a manutenção do software. A realização de estimativas após o encerramento do desenvolvimento ou manutenção do software é recomendável para que possam ser identificados desvios em relação às estimativas anteriores e, conseqüentemente, refinamento de dados históricos.
Saídas Descrição
Quantidade Pontos por Use Case
Unidade de medida para software.
Esforço Esforço necessário para o projeto de software.
Regras de Negócio Descrição
Pontos por Use Case Regras da técnica que permite estimativa de software através de Use Cases.
Insumos Descrição
Planilha de estimativa Planilha Excel que possibilita a estimativa de software a partir de use cases.
Gerente de Projeto Vide Matriz de Papéis e Responsabilidades para definição.
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 31 de 33
6.5.1 Detalhamento Gráfico (IDEF3) – Estimar software
1. Estimar software (IDEF3 Process Flow)System Architect
Tue Aug 06, 2002 10:24Comment
Choose TechnologiesVerdadosReceber solicitação de
estimativa de software
Disponibilizarquantidade de Pontospor Use Case
Disponibilizar esforçonecessário
Receber fatoresambiente dedesenvolvimento
Receber fatoresequipe do projeto
Receber fatorestécnicos dosoftware
Receber IDEFs
Receber UseCases
Preencher planilhaPontos por UseCase&
J
OJ
&J
L
L
L
L
L
L
L
L
L
L
L
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 32 de 33
Estimativa de Pontos por Use Case
Estimativa de Esforço
Estimativa de Pontos por Use Case
É bastante recomendável que sejam realizadas várias contagens de pontos por use case ao longo do desenvolvimento. Alguns exemplos de momentos em que pode haver recontagem:
- Nos estágios iniciais, antes de iniciar o projeto propriamente dito (para uma visão inicial do esforço);
- Após a realização da Modelagem de Processos de Negócio (para refinar a visão anterior do esforço);
- Após a elaboração dos diagramas de Use Cases (para refinar a visão anterior do esforço);
- Após a execução da disciplina Análise e Design (para refinar a visão anterior do esforço);
- Após a implementação (para refinar a visão anterior do esforço);
- Após os testes (para refinar a visão anterior do esforço).
A cada nova recontagem, caso o esforço seja significativamente maior que o estimado anteriormente, deve haver uma renegociação de prazo e custo do projeto com o cliente.
Os erros/divergências de esforço identificados entre uma contagem e outra de Pontos por Use Case devem ser encarados como “aprendizados” para realização de estimativas futuras.
É extremamente arriscado avançar em projetos de desenvolvimento sem realizar nenhum tipo de estimativa (limita o aprendizado Organizacional).
Estimar esforço através do uso da planilha de Pontos por Use Case.
Processo Descrição
Receber Use Cases Processo em que o Gerente de Projeto recebe os diagramas Use Case criados/atualizados.
Para mais detalhes, consulte o "Manual Técnico - EstimativaPontosUseCase".
MDS
Disciplina Requisitos
Disciplina Requisitos Última impressão 3/10/2006 10:06:00 Página: 33 de 33
Processo Descrição
Receber IDEFs Processo em que o Gerente de Projeto recebe os diagramas IDEF0 e/ou IDEF3 criados/atualizados durante a execução da Disciplina Modelagem de Negócio.
Receber fatores técnicos do software
Para informações quanto a este processo, consulte o "Manual Técnico - EstimativaPontosUseCase" - capítulo 6.3: Ponderação de Fatores Técnicos.
Receber fatores equipe do projeto
Para informações quanto a este processo, consulte o "Manual Técnico - EstimativaPontosUseCase" - capítulo 6.4: Ponderação de Fatores de Equipe e do Ambiente.
Receber fatores ambiente de desenvolvimento
Para informações quanto a este processo, consulte o "Manual Técnico - EstimativaPontosUseCase" - capítulo 6.4: Ponderação de Fatores de Equipe e do Ambiente.
Receber solicitação de estimativa de software
Processo em que o Gerente de Projeto recebe e/ou identifica a necessidade de realizar uma estimativa.
Preencher planilha Pontos por Use Case
Processo em que as informações necessárias à estimativa são preenchidas na planilha de estimativa de Pontos por Use Case.
Para mais detalhes, consulte o "Manual Técnico - EstimativaPontosUseCase".
Disponibilizar quantidade de Pontos por Use Case
Processo no qual é informada a quantidade de Pontos estimada para o software.
Para mais detalhes, consulte o "Manual Técnico - EstimativaPontosUseCase".
Disponibilizar esforço necessário
Processo no qual é informada a quantidade de esforço estimada para o software.
Para mais detalhes, consulte o "Manual Técnico - EstimativaPontosUseCase".