metodologia de desenvolvimento de sistemas requisitos

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



Controle de Versão do manual da


Versão Controle Data Razões para alteração Responsável

1 0 20/08/2002 Versão Original C. Eduardo M.

MDS



Í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



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



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



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



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


Cliente Analista de Negócios

Solicitação de Alteração


Elicitar Requisitos

Efetuar Mapeamento

Requisitos Revisar Mapeamento

Requisitos Validar Requisitos

com Cliente

Estimar software

MDS



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


Diagramas Use Casepara validação


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


Solicitaçãode Alteração


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





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.


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.


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.


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



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



6.1.1 Detalhamento Gráfico (IDEF3) – Elicitar Requisitos

1. Elicitar Requisitos (IDEF3 Process Flow)System Architect



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



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




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.


Cenário: Manutenção

Receber Solicitação de Alteração

Vide descrição do fluxo de entrada Solicitação de Alteração.

MDS




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



6.2 Efetuar Mapeamento Requisitos




A00


A00

Estimar software

A00

Elicitar Requisitos

A00


A00


FerramentaCASE


do Projeto




Use CasesDetalhados

Lista de Requisitos




Gerente de Projeto


Técnica Use Case






Use Cases


Esforço


Pontos por Use Case

Técnica Use Case





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




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.




Saídas Descrição

MDS



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


Técnica Use Case Notação e regras da técnica Use Case, segundo a UML.

Insumos Descriçã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



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


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




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




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



6.3 Revisar Mapeamento Requisitos




A00


A00

Estimar software

A00

Elicitar Requisitos

A00


A00


FerramentaCASE


do Projeto




Use CasesDetalhados

Lista de Requisitos




Gerente de Projeto


Técnica Use Case






Use Cases


Esforço


Pontos por Use Case

Técnica Use Case





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



Use Cases Detalhados Corresponde aos diagramas Use Case Detalhados elaborados (desenho e descrição, na ferramenta CASE).


Saídas Descriçã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.


Corresponde às não conformidades técnicas identificadas durante a revisão técnica pelo revisor dos diagramas Use Case.


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



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



6.3.1 Detalhamento Gráfico (IDEF3) – Revisar Mapeamento Requisitos

Identificar analistapara revisão

1. Revisar Mapeamento Requisitos (IDEF3Process Flow)



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.


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




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



6.4 Validar Requisitos com Cliente




A00


A00

Estimar software

A00

Elicitar Requisitos

A00


A00


FerramentaCASE


do Projeto




Use CasesDetalhados

Lista de Requisitos




Gerente de Projeto


Técnica Use Case






Use Cases


Esforço


Pontos por Use Case

Técnica Use Case





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.




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


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:



- 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



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


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


Cliente Vide Matriz de Papéis e Responsabilidades para definição.

MDS



6.4.1 Detalhamento Gráfico (IDEF3) – Validar Requisitos com Cliente

1. Validar Requisitos com Cliente (IDEF3Process Flow)



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.


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




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:



- 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




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



6.5 Estimar software




A00


A00

Estimar software

A00

Elicitar Requisitos

A00


A00


FerramentaCASE


do Projeto




Use CasesDetalhados

Lista de Requisitos




Gerente de Projeto


Técnica Use Case






Use Cases


Esforço


Pontos por Use Case

Técnica Use Case





Descrição Atividade na qual é calculado o esforço necessário para desenvolver o

software em questão.








Corresponde à Solicitação de Serviço que foi classificada como manutenção corretiva ou evolutiva.


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.


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




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.


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



6.5.1 Detalhamento Gráfico (IDEF3) – Estimar software

1. Estimar software (IDEF3 Process Flow)System Architect


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



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.


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




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.


Disponibilizar quantidade de Pontos por Use Case

Processo no qual é informada a quantidade de Pontos estimada para o software.


Disponibilizar esforço necessário

Processo no qual é informada a quantidade de esforço estimada para o software.


metodologia de desenvolvimento de sistemas requisitos

Documents