Introdução a Requisitos - Heuber Lima | Prof. Esp. MBA, CSM – Análise de … · 2011-02-18 ·...

Análise e Levantamento de Requisitos

Introdução a Requisitos

de Requisitos

Prof. Esp. MBA Heuber G. F. Lima

Aula 1

� Apresentações

� Introdução à Análise de Requisitos

� Conclusão.

� Estudo de Caso

Agenda

Page � 2

Page � 4

Page � 5

Page � 6

O Processo da Análise de Sistemas.

MundoReal

Modelo Descritivo

ModeloConceitual

Seres,objetos,fatos,conceitos

Descrição formal da realidade

Page � 7

Modelo deImplementação

Software

Descrição informal da realidade

conceitosDescrição que pode ser processada por computador

Conjunto de Programas e Arquivos

Diretivas de mapeamento

Regras de mapeamento

Introdução

Swebok (Software Engineering Body of Knowledge) éuma iniciativa da IEEE Computer Society que tem opropósito de criar um consenso sobre as áreas deconhecimento da engenharia de software e seuescopo.

Page � 8

escopo.

Page � 9

Page � 10

Page � 11

O ciclo de vida clássico

Engenhariade Sistemas

Análise

Projeto

Codificação

Page � 12

Teste

Manutenção

De acordo com o RUP...

Page � 13

� Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade

Page � 1414

� 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

Fase de Análise de RequisitosFase de Análise de Requisitos

ANÁLISE DEREQUISITOS

Engenharia de Sistemas de Computador

PONTE

Page � 1515

REQUISITOS

Projeto de Software

Escopo do Software •Primeiro passo técnico•Analista de Sistemas

Análise de Requisitos

processo de descoberta e refinamento

� ATORES: cliente e desenvolvedor

– Cliente: reformula um conceito de função e desempenho (às vezes nebuloso)

Page � 1616

desempenho (às vezes nebuloso)

– Desenvolvedor: indagador e solucionador de problemas

� PROBLEMA: grande propensão a mal entendidos"atividade aparentemente simples torna-se complexa"

Definição: Requisitos e Especificação

� Glossário de Engenharia de Software (IEEE) e do Aurélio� Requisito (IEEE)

– Uma condição ou capacidade necessitada

Page � 1717

– Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo

– Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão

� Requisito (Aurélio)

– Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim

� Especificação :

Page � 1818

� Especificação :

– descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar

– processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida

Exemplos

�“O sistema deverá permitir o cadastro de clientes”

�“Para cada nota fiscal emitida deverá ser gerado um identificador da nota que é formado pela data da emissão da nota mais o código do vendedor”

Page � 1919

da emissão da nota mais o código do vendedor”

�“Cada item do estoque deverá ser consultado pelo seu código interno, seu código nacional e por parte do seu nome”

Exemplos

�“O sistema deve rodar em microcomputadores da linha PC que possuam microprocessador core i3 ou superior.”

�“A interface do sistema deve ser gráfica, web, de acordo com um padrão de interface dirigida a

Page � 2020

acordo com um padrão de interface dirigida a menu.”

�“Alternativamente, o sistema deve possibilitar o seu uso através de atalhos, para usuários avançados.”

Tipos de Requisitos(divisão utilizada na literatura)

�Funcionais

�Não Funcionais (de Qualidade)ISO - The International Organization for

Standardizatized

Page � 2121

Standardizatized

IEC - The International Electrotechnical Commition

(formam o sistema especializado para padronização mais conhecido)

Requisitos

�Requisitos funcionais correspondem à listagem de todas as coisas que o sistema deve fazer

�Requisitos não funcionais são restrições que se coloca sobre como o sistema deve realizar seus requisitos funcionais

Page � 22

requisitos funcionais

Requisitos Funcionais

�Requisitos funcionais evidentes são efetuados com conhecimento do usuário

�Requisitos funcionais ocultos são efetuados pelo sistema sem o conhecimento explícito do usuário

Page � 23

Requisitos Não Funcionais

�Obrigatórios

�Desejáveis

Page � 24


�de interface

�de implementação

�de eficiência

�de tolerância a falhas

Page � 25

�de tolerância a falhas

�etc.


� Associados a requisitos funcionais

� Suplementares

Page � 26


�Permanentes

�Transitórios

Page � 27

Requisitos Funcionais

�Código do requisito funcional (Ex.: F1, F2, F3, ...)

�Nome do requisito funcional (especificação curta)

�Descrição (especificação longa e detalhamento do requisito)

Page � 28

�Categoria funcional: evidente ou oculto


�Código do requisito não funcional (Ex.: NF1.1, NF1.2, ... NF2.1, NF2.2, ...)

�Nome do requisito não funcional (especificação curta)

�Restrição: especificação (longa) do requisito não funcional

�Categoria: tipo de restrição: segurança, performance,

Page � 29

�Categoria: tipo de restrição: segurança, performance, compatibilidade, etc.

�Obrigatoriedade: se o requisito é desejável ou obrigatório

�Permanência: se o requisito é permanente ou transitório

Requisitos Funcionais e Não Funcionais Associados

F1 Registrar empréstimos Oculto ( ) Descrição: O sistema deve registrar empréstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem como a data do empréstimo e valor previsto para pagamento na devolução. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF1.1 Controle de Acesso

A função só pode ser acessada por usuário com perfil de operador ou superior.

Segurança ( ) (x)

NF1.2 Identificação de Fitas

As fitas devem ser identificadas por um código de barras

Interface ( ) (x)

NF1.3 Identificação do cliente

O cliente deverá ser identificado a partir de seu nome Interface ( ) ( )

NF1.4 Tempo de registro

O tempo para registro de cada fita deve ser inferior a um segundo.

Performance (x) ( )

Page � 30

registro um segundo. NF1.5 Janela única Todas as funções relacionadas a empréstimos devem

ser efetuadas em uma única janela Interface (x) (x)

... ... ... ... ...

F2 Calcular descontos Oculto ( x ) Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF2.1 Desconto de fim de semana

Nos fins de semana, usuários que levam 4 fitas pagam apenas 3.

Especificação ( ) ( )

... ... ... ... ...

Requisitos Suplementares

Nome Restrição Categoria Desejável Permanente

S1 Tipo de Interface As interfaces do sistema devem ser implementadas como formulários acessíveis em um browser html.

Interface ( ) ( )

S2 Armazenamento de dados

A camada de persistência deve ser implementada de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro

Persistência ( ) ( x )

S3 Perfis de usuário Os perfis de usuário para acesso ao sistema são: 3. Administrador - pode efetuar todas as

Segurança ( ) ( )

Page � 31

3. Administrador - pode efetuar todas as operações. 2. Operador - pode efetuar as operações de empréstimo, devolução, pagamento e cadastramento. 1. Convidado - pode efetuar apenas consultas nos próprios dados (cliente).

... ... ... ... ...

Dilema do Engenheiro de Software

Declaração de um cliente anônimo:

“Sei que você acredita que entendeu o que acha que eu disse, mas não estou

Page � 3232

que acha que eu disse, mas não estou certo de que percebe que aquilo que

ouviu não é o que eu pretendia dizer ... ”

Requisitos de Software

�A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados:

– Funcionalidade (finalidade do produto)

– Usabilidade (esforço para utilizar, aprender o produto)

Page � 3333

– Usabilidade (esforço para utilizar, aprender o produto)

– Confiabilidade (freqüência de falhas, recuperabilidade)

– Eficiência (desempenho)

– Manutenibilidade (esforço necessário para modificar)

– Portabilidade (capacidade de transferir o produto para outros ambientes)

elementos alocados ao software

determinar domínio das informações e das funções, construir protótipo

para estabelecer os

os requisitos são conhecidos?

revisão administrativa

Plano de Desenvolvimento do Software

estabelecimento do alcancerecursos, custo cronograma

revisão

aceitável

não sim

Page � 3434

interfaces, restrições de projeto e critérios de validação

para estabelecer os requisitos

revisar e justificar recursos, custos ecronogramas

Especificação dos Requisitos

do Software

início da fase de desenvolvimento

revisão revisão técnica

revisão do plano de projeto do software

aceitável

aceitável

ATIVIDADES de ANÁLISE:

1 - Reconhecimento do problema

2 - Avaliação do problema e síntese

da solução (Modelagem)

Page � 3535

da solução (Modelagem)

3 - Especificação dos requisitos do

software

4 - Revisão

Atividade 1 Reconhecimento do Problema

A meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente.

Administrador do projeto

Page � 3636

clientesanalista desenvolvedores

Plano de projeto de software

Espec. requisitos de software

protótipo

Atividade 2 Avaliação do Problema e Avaliação do Problema e Síntese da SoluçãoSíntese da Solução� Avaliar os problemas na situação atual

� Principal Foco para o novo sistema: O QUE e não COMO :

- qual o fluxo e o conteúdo de informação

Page � 3737

- quais as funções do sistema- quais dados que o sistema produz e consome - qual o comportamento do sistema- qual as características de interface- quais são as restrições do projeto

Avaliação do Problema e Síntese Avaliação do Problema e Síntese da Soluçãoda Solução

� Sintetizar uma ou mais soluções (dentro do alcance delineado no Plano de Projeto do Software)

O processo de avaliação e síntese continua até que o

Page � 3838

O processo de avaliação e síntese continua até que o analista e o cliente concordem que o software pode ser adequadamente especificado.

É a maior área de esforço

ModelagemModelagem

�Durante a atividade de avaliação e síntese devem ser criados modelos do sistemamodelos do sistema para se compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental, além do conteúdo da informação.

Page � 3939

comportamental, além do conteúdo da informação.

�O modelo serve como fundamento para o projeto de software e como base para a criação de sua especificação

Atividade 3 Especificação de Requisitos Especificação de Requisitos

� Definição de Especificação : descrição rigorosa e minuciosa das descrição rigorosa e minuciosa das características que um material, uma obra ou um serviço deverão apresentarcaracterísticas que um material, uma obra ou um serviço deverão apresentar

– descrição do fluxo e estrutura da informação

– refinamento detalhado de todas as funções do software

– estabelecimento das características de interface

– identificação das restrições de projeto

Page � 4040

– identificação das restrições de projeto

– especificação dos critérios de validação

Atividade 4 Revisões Revisões

Devem ser efetuadas revisões técnicas e revisões no Plano de Projeto de Software� as revisões são conduzidas pelo Cliente e pelo Desenvolvedor

� a base para a revisão são os documentos produzidos na Especificação

Page � 4141

� a base para a revisão são os documentos produzidos na Especificação dos Requisitos

O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise.

Page � 42

•Engenheiro de Sistemas•Projetista de sistemas-chefe•Programador/Analista

Características do Analista de Características do Analista de SistemasSistemas- Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções" baseado em cada divisão.

2- Capacidade de absorver fatos pertinentes a

Page � 4343

2- Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas.

4- Capacidade de se comunicar bem de forma escrita e verbal.

5- Capacidade de "ver a floresta ao invés das árvores” �� (não se perder nos detalhes)

Papel do Analista de SistemasPapel do Analista de Sistemas

1- Coordenar cada uma das atividades da Análise de Requisitos de Software- comunicação com cliente- convoca pessoal de desenvolvimento durante avaliação e síntese

Page � 4444

durante avaliação e síntese2- Responsável pelo desenvolvimento do

documento de Especificação de Requisitos do Software e participa de todas as revisões

Áreas ProblemasÁreas Problemas

1. Aquisição da Informação

2. Tamanho do Sistema

(complexidade dos problemas)

3. Alterações

Page � 4545

3. Alterações

(mudanças que ocorrem durante e após a análise)

Áreas Problemas

1. Aquisição da informação

– que informação deve ser coletada e como ela deve ser representada?

– quem fornece as informações?

– que técnicas e ferramentas estão disponíveis para facilitar a coleta de informações?

Page � 4646

Áreas Problemas

2. Tamanho do sistema

– como eliminar inconsistências na especificação de grandes sistemas?

– é possível detectar omissões?

– pode um grande sistema ser efetivamente particionado para que se torne intelectualmente administrável?

Page � 4747

Áreas Problemas

3. Alterações

– como as alterações efetuadas em outros elementos do software são coordenadas com os requisitos do software?

– como se determina o impacto de uma alteração em outras partes do software aparentemente não relacionadas?

Page � 4848

– como se corrige erros na especificação para que não se gere efeitos colaterias?

Causas dos ProblemasCausas dos Problemas

� comunicação ineficiente

� técnicas e ferramentas inadequadas (especificação inadequada e imprecisa)

� tendências de se eliminar a tarefa de Especificação dos

Page � 4949

� tendências de se eliminar a tarefa de Especificação dos Requisitos

� falhas ao considerar alternativas antes que o software seja especificado

Abordagem de Engenharia de Software

� Aplicação de técnicas de comunicação sólidas

� Princípios de análise fundamentais

� Métodos de análise sistemáticos reduzirão o impacto dos problemas

Page � 5050

Responde ao pedido de ajuda do cliente

Page � 5151

Problema cuja solução é baseadaem computador

Princípios Fundamentais de AnálisePrincípios Fundamentais de Análise

� domínio de informação do problema → representado e compreendido (para que a função possa ser entendida + completamente)

Page � 5252

� modelos que descrevam a informação, a função e o comportamento do sistema → desenvolvidos (para que a informação possa ser comunicada compactamente)

Princípios de AnálisePrincípios de Análise

�modelos (e o problema) → particionados, de maneira que revele os detalhes em forma de camadas (ou hierarquicamente) (para reduzir a complexidade)

�processo de análise → mover-se da informação essencial para os detalhes de implementação (para

Page � 5353

essencial para os detalhes de implementação (para acomodar as restrições lógicas impostas por requisitos de processamento e as restrições físicas impostas por outros elementos do sistema) = (Concepções lógicas e físicas)

1°°°° princípio: Domínio da Informação

Todo software é construído para processar dados e eventos .

Dados:

Page � 5454

Dados: software embutido de tempo real para controlar o fluxo de combustível no motor de automóvel

Eventos: um sensor de pressão detecta que a pressão ultrapassa determinado valor de segurança e envia um sinal de alarme para o software de monitoração


Os dados e itens de controle residem no domíniode informação de um problema.

Encerra 3 diferentes pontos de vista:

Page � 5555

Encerra 3 diferentes pontos de vista:

Fluxo da InformaçãoFluxo da Informação : maneira pela qual os dados e o controle se modificam à medida que cada um se movimenta pelo sistema

Conteúdo da InformaçãoConteúdo da Informação : os dados e os itens de controle individuais que compreendem certo item de


Page � 5656

individuais que compreendem certo item de informação mais amplo.

- o conteúdo do item de dados cheque de pagamento é definido pelos itens que são necessários para criá-lo: nome do recebedor, quantidade líquida a ser paga, pagamento bruto, etc.

Estrutura da InformaçãoEstrutura da Informação : a organização interna de vários itens de controle e de dados

2. princípio:Modelagem

�Modelos: melhor compreensão da entidade real a ser construída

�Entidade é física (prédio): modelo idêntico, mas

Page � 5757

em escala menor

�Entidade é software:

– o modelo deve ser capaz de modelar a informação que o software transforma

– as funções (ou subfunções) que possibilitam que as transformações ocorram

– o comportamento do sistema quando a transformação está se desenvolvendo.


Os modelos concentram-se naquilo que o sistema deve fazer, não em como

ele faz.

Page � 5858

ele faz.

�Modelos fazem uso de notação gráfica e textual

�Os métodos de análise discutidos nos capítulos seguintes são métodos de modelagem

�Atividade de Modelagem é fundamental ao bom trabalho da análise


Papéis importantes do Modelo:

1) ajuda o analista a entender a informação, a função e o comportamento de um sistema, tornando a tarefa + fácil e sistemática.

2) torna-se o ponto focal para a revisão e, portanto,

Page � 5959

2) torna-se o ponto focal para a revisão e, portanto, a chave para a determinação da completitude, consistência e precisão da especificação.

3) torna-se a base para o projetoa base para o projeto, fornecendo ao projetista uma representação essencial do software, a qual pode ser "mapeada" num contexto de implementação.

3. princípio:Particionamento (decomposição)Os problemas freqüentemente são grandes demais e muito complexos

para serem compreendidos como um todo.

O particionamento divide o problema em partes mais facilmente entendidas

Através das interfaces estabelecidas entre as partes a função global do software pode ser executada.

Page � 6060

Particionamento Horizontal: decomposição funcional do problema

Particionamento Vertical: expõe detalhes crescentes

3°°°° princípio: Particionamento

Page � 6161

Particionamento horizontalParticionamento horizontal

4°°°° princípio:Concepções essenciais e de Concepções essenciais e de implementaçãoimplementaçãoA concepção essencialconcepção essencial dos requisitos do software apresenta as funções a serem realizadas sem tratar dos detalhes de implementação.

Ao se concentrar atenção na essência do problema nas primeiras etapas da análise de requisitos,

Page � 6262

nas primeiras etapas da análise de requisitos, deixa-se as opções abertas para especificar detalhes de implementação durante as últimas etapas de especificação dos requisitos e projeto de software.

A concepção de implementaçãoconcepção de implementação dos requisitos de software apresenta a manifestação das funções de processamento e estruturas de informação no mundo real.

Não deve ser interpretada como uma

4°°°° princípio:Concepções essenciais e de Concepções essenciais e de implementaçãoimplementação

Page � 6363

Não deve ser interpretada como uma representação do como. Um modelo de implementação representa o modo de operação corrente, ou seja a atribuição existente ou proposta para todos os elementos do sistema.

Especificação de Requisitos de Software

� Desenvolvida como uma conseqüência da fase de análise de requisitos� Serve como um padrão para testar se

Page � 6464

� Serve como um padrão para testar se as fases de projeto e implementação do processo de desenvolvimento de software estão corretas

Princípios de uma boa Princípios de uma boa especificaçãoespecificação (Balzer e Goldman)

1. Separefuncionalidade de implementação

2. É necessária uma linguagem de especificação de sistemas orientada ao processo

3. A especificação deve abranger o sistema do qual o software é um componente

Page � 6565

um componente

4. Uma especificação deve abranger o ambiente no qual o sistema opera

5. Uma especificação de sistema deve ser um modelo cognitivo

6. Uma especificação deve ser operacional

7. A especificação do sistema deve ser tolerante com a não completitude e ser expansível

8. Uma especificação deve ser localizada e fracamente acoplada.

A Especificação pode ser acompanhada de um PROTÓTIPOexecutável (ou em papel) e/ou um

Page � 6666

executável (ou em papel) e/ou um MANUAL PRELIMINAR DE

USUÁRIO.

Revisão da EspecificaçãoRevisão da Especificação((nível macroscópico)

Os revisores tentam garantir que a especificação seja completa, consistente e precisa. Questões:

Metas e objetivos do software permanecem consistentes com metas e objetivos do sistema?

Page � 6767

metas e objetivos do sistema?

Foram descritas as interfaces importantes para todos os elementos do sistema?

O fluxo e a estrutura de informação são adequadamente definidas para o domínio da informação?

Os diagramas são claros?

As funções importantes permanecem dentro do escopo e cada uma foi adequadamente descrita?

O comportamento do software é consistente com a informação que ele deve processar e as funções que deve executar?

As restrições de projeto são realísticas? Qual é o risco tecnológico desenvolvimento? Requisitos de software alternativos foram

Revisão da EspecificaçãoRevisão da Especificação((nível macroscópico)

Page � 6868

desenvolvimento? Requisitos de software alternativos foram considerados?

Critérios de Validação foram declarados detalhadamente? Eles são adequados para descrever um sistema bem sucedido?

Existem inconsistências, omissões ou redundâncias?

O usuário revisou o Manual Preliminar ou o protótipo?

Como as estimativas do Plano de projeto de Software foramafetadas?

Revisão da EspecificaçãoRevisão da Especificação((nível detalhado)

A preocupação é com o enunciado da especificação. Tenta-se descobrir problemas que possam estar ocultos no conteúdo da especificação

Diretrizes:

Esteja alerta para perceber conectivos persuasivos (certamente,

Page � 6969

Esteja alerta para perceber conectivos persuasivos (certamente, claramente, obviamente ) e perguntar por que eles estão presentes.

Procure termos vagos e peça esclarecimento (algum, às vezes, usualmente, freqüentemente)

Quando forem fornecidas listas que não sejam completas, certifique-se de que todos os itens sejam entendidos (evite colocar etc, tal como, assim por diante)


Esteja certo de que os limites declarados não contenham pressuposições não declaradas (“os códigos válidos variam de 0 a 100” - números inteiros, reais???)

Cuidado com verbos vagos. Há muitas maneiras de interpretá-los. (manuseado, rejeitado, pulado, processado)

Page � 7070

(manuseado, rejeitado, pulado, processado)

Cuidado com pronomes "pendentes” (o módulo I/O comunica-se com o módulo de validação de dados e seu sinal de controle está ligado. Sinal de controle de qual?).

Procure declarações que impliquem certeza (sempre, cada, todos, nunca) e depois peça prova


Quando um termo for explicitamente definido num lugar, evite utilizar outras definições para o mesmo termo (normalização dos termos: documento - arquivo)

Page � 7171

Quando uma estrutura for descrita em palavras, verifique se há um gráfico ou uma figura para auxiliar a compreensão

Quando um cálculo for especificado, desenvolva pelo menos dois exemplos.

Ferramentas de Especificação Ferramentas de Especificação AutomatizadasAutomatizadas

1a categoria: técnicas automatizadas que nada mais são do que um método manual que foi complementado com uma ferramenta CASE

Possibilitam que o analista atualize informações e rastreie as conexões entre representações novas

Page � 7272

rastreie as conexões entre representações novas e existentes do sistema

Ex: DEC Design (Digital Equipment Corp.), Design Aid(Transform Logic Corp.), Excelerator (Intersolv), IEF(Texas Instruments), ADW (Knowledgeware), STP(Interative Development Environments), Teamwork (Cadre Technologies).

2a categoria: técnicas automatizadas que fazem uso de uma notação especial (na maioria dos casos, essa é uma linguagem de especificação de requisitos) que foi explicitamente projetada para processamento usando-se uma ferramenta

Ferramentas de Especificação Ferramentas de Especificação AutomatizadasAutomatizadas

Page � 7373

processamento usando-se uma ferramenta automatizada.

Ex: SREM (linguagem de especificação: RSL), PSL/PSA (linguagem de especificação: PSL), TAGS (linguagem de especificação: IORL)

Análise de RequisitosAnálise de Requisitos ConclusãoConclusão

�Logo que a Revisão for concluída, a Especificação de Requisitos de Software é "assinada " pelo cliente e pelo desenvolvedor

�A especificação torna-se um "contrato " de desenvolvimento de software.

Page � 7474

desenvolvimento de software.

�Mudanças solicitadas depois que a Espec. for concluída serão consideradas, porém cada mudança posterior pode aumentar o custo e/ou alongar o prazo de entreg a

�Mesmo com os melhores procedimentos de revisão em andamento, uma série de problemas de especificação ainda persiste

Objetivos

� Análise Preliminar

– Levantamento de Requisitos (parcial)

– Organização de Requisitos

– Modelo Conceitual Preliminar

� Planejamento das Iterações

Page � 75

Atividades

�Conhecer a empresa

�Levantar requisitos

�Organizar requisitos

�Esboçar o modelo conceitual do sistema

Page � 76

�Esboçar o modelo conceitual do sistema

�Planejar o desenvolvimento

– Iterações

– Cronograma

– Recursos

Artefatos

� Sumário Executivo

� Documento de Requisitos

� Casos de Uso

� Modelo Conceitual

Page � 77

Sumário Executivo

Conhecimento da Empresa

�O que a empresa quer com o projeto?

�Por que ele está sendo proposto?

�Por que a empresa vai gastar dinheiro com o projeto?

�O projeto é realizável?

Page � 79

�O projeto é realizável?

�A equipe de desenvolvimento tem condições de realizar este projeto?

�O cliente tem dinheiro para pagar o desenvolvimento?

�Há tempo disponível?

�Comprar ou desenvolver?

Sumário Executivo

� O quê?

� Onde?

� Por quê?

� Como?

� 3 páginas, no máximo

Page � 80

� 3 páginas, no máximo

� Também chamado de Visão Geral do Sistema

Sumário Executivo

� Documento de texto em formato livre

Sistema Videolocadora Visão Geral do Sistema É proposto o desenvolvimento de um sistema de controle de

videolocadora, que vai informatizar as funções de empréstimo, devolução e reserva de fitas. O objetivo do sistema é agilizar o processo de empréstimo

Page � 81

reserva de fitas. O objetivo do sistema é agilizar o processo de empréstimoe garantir maior segurança, ao mesmo tempo que possibilita um melhor controle das informações por parte da gerência. Deverão ser gerados relatórios de empréstimos por cliente, empréstimos por fita e empréstimos no mês. O sistema deverá calcular automaticamente o valor dos pagamentos a serem efetuados em cada empréstimo inclusive multas e descontos devidos. A cada devolução de fitas corresponderá um pagamento, não sendo possível trabalhar com sistema de créditos. A impossibilidade de efetuar um pagamento deve deixar o cliente suspenso, ou seja, impossibilitado de emprestar novas fitas até saldar a dívida.

Documento de Requisitos

Levantamento de Requisitos

� Entrevistas

� Análise de Documentos

� Estudo Bibliográfico Comparativo

Page � 83

Requisitos

� Requisitos funcionais correspondem à listagem de todas as coisas que o sistema deve fazer

� Requisitos não funcionais são restrições que se coloca sobre como o sistema deve realizar seus requisitos funcionais

Page � 84

Revendo....Requisitos Funcionais

� Requisitos funcionais evidentes são efetuados com conhecimento do usuário

� Requisitos funcionais ocultos são efetuados pelo sistema sem o conhecimento explícito do usuário

Page � 85

Revendo.... Requisitos Não Funcionais

� Obrigatórios

� Desejáveis

� Associados a requisitos funcionais

� Suplementares

� de interface

Page � 86

� de interface

� de implementação

� de eficiência

� de tolerância a falhas

� etc.

� Permanentes

� Transitórios

Revendo...Requisitos Funcionais

� Código do requisito funcional (Ex.: F1, F2, F3, ...)

� Nome do requisito funcional (especificação curta)

� Descrição (especificação longa e detalhamento do requisito)

� Categoria funcional: evidente ou oculto

Page � 87


�Código do requisito não funcional (Ex.: NF1.1, NF1.2, ... NF2.1, NF2.2, ...)

�Nome do requisito não funcional (especificação curta)

�Restrição: especificação (longa) do requisito não funcional

�Categoria: tipo de restrição: segurança, performance,

Page � 88

�Categoria: tipo de restrição: segurança, performance, compatibilidade, etc.

�Obrigatoriedade: se o requisito é desejável ou obrigatório

�Permanência: se o requisito é permanente ou transitório

Requisitos Funcionais e Não Funcionais Associados

F1 Registrar empréstimos Oculto ( ) Descrição: O sistema deve registrar empréstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem como a data do empréstimo e valor previsto para pagamento na devolução. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF1.1 Controle de Acesso

A função só pode ser acessada por usuário com perfil de operador ou superior.

Segurança ( ) (x)

NF1.2 Identificação de Fitas

As fitas devem ser identificadas por um código de barras

Interface ( ) (x)

NF1.3 Identificação do cliente

O cliente deverá ser identificado a partir de seu nome Interface ( ) ( )

NF1.4 Tempo de O tempo para registro de cada fita deve ser inferior a Performance (x) ( )

Page � 89

registro um segundo. NF1.5 Janela única Todas as funções relacionadas a empréstimos devem

ser efetuadas em uma única janela Interface (x) (x)

... ... ... ... ...

F2 Calcular descontos Oculto ( x ) Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF2.1 Desconto de fim de semana

Nos fins de semana, usuários que levam 4 fitas pagam apenas 3.

Especificação ( ) ( )

... ... ... ... ...

Requisitos Suplementares

Nome Restrição Categoria Desejável Permanente

S1 Tipo de Interface As interfaces do sistema devem ser implementadas como formulários acessíveis em um browser html.

Interface ( ) ( )

S2 Armazenamento de dados

A camada de persistência deve ser implementada de forma que diferentes tecnologias de bancos de

Persistência ( ) ( x )

Page � 90

dados de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro

S3 Perfis de usuário Os perfis de usuário para acesso ao sistema são: 3. Administrador - pode efetuar todas as operações. 2. Operador - pode efetuar as operações de empréstimo, devolução, pagamento e cadastramento. 1. Convidado - pode efetuar apenas consultas nos próprios dados (cliente).

Segurança ( ) ( )

... ... ... ... ...

Desafios da Análise de Requisitos

� Como descobrir os requisitos

� Como comunicar os requisitos para as outras fases ou equipes do projeto

� Como lembrar dos requisitos durante o desenvolvimento e verificar se foram todos atendidos

� Como gerenciar a mudança

Page � 91

Organização dos Requisitos

� Casos de Uso

� Manutenção de Conceitos (Entidades)

� Consultas/Relatórios

Page � 92

Casos de Uso

Caso de Uso

�Um cenário de interação usuário-sistema– Ordenação de um subconjunto de requisitos funcionais, e

seus requisitos não-funcionais associados, relacionado com o caso de uso

�Pouco detalhado na fase de concepção

Page � 94

�Pouco detalhado na fase de concepção

�Bastante detalhado na fase de elaboração (refinamento de casos de uso)

�Dado um requisito funcional, ele deve aparecer em pelo menos um caso de uso– Critério de validação do caso de uso

Organizando Requisitos em Casos de Uso

Nome Atores Descrição Referências Cruzadas Emprestar Fitas

Cliente, Funcionário

O cliente se identifica e identifica as fitas que d eseja levar. O funcionário faz o registro e libera as fitas para empréstimo.

F1, F3, F5, F9, F10

Devolver Fitas


O cliente entrega ao funcionário as fitas. O funci onário faz o registro da devolução e o cliente efetua o pa gamento devido.

F2, F4, F6, F7, F8

Reservar Fitas


O cliente solicita a reserva de um ou mais filmes. O funcionár io registra a reserva.

F11, F12

Page � 95

Fitas Funcionário funcionár io registra a reserva.

Diagrama de Casos de Uso UML

Page � 96

Diagrama de Caso de Uso

� Em geral, na fase de concepção, um caso de uso não é decomposto

– Decomposição é detalhamento (fase de elaboração)

Page � 97

Granulosidade de um Caso de Uso

�Um caso de uso deve ser mono-sessão, ou seja, executado em uma única interação e não se estendendo ao longo de vários dias�Um caso de uso deve ser interativo, com informações fluindo

para dentro e para fora do sistema�Um caso de uso deve produzir uma alteração consistente na

Page � 98

�Um caso de uso deve produzir uma alteração consistente na informação armazenada– Uma seqüência de consultas puras ao sistema não caracteriza um

caso de uso

�Duração de um caso de uso: de alguns minutos a 1 hora (Larman)

Granulosidade de um Caso de Uso

� Algumas operações relativamente simples e elementares (de um único passo), como o registro de uma fita, ou de um pagamento, não devem ser consideradas como casos de uso por si só (um único passo)

Page � 99

Modelo Conceitual Preliminar

Modelo Conceitual

� A entrada para o modelo conceitual são os casos de uso

– Cada conceito ou entidade, assim como seus relacionamentos, deve aparecer direta ou indiretamente nas descrições dos casos de uso

Page � 101

Modelo Conceitual Preliminar

Page � 102

Modelo Conceitual

� Note que o modelo está incompleto

– Faltando contemplar o caso de uso Devolver Fitas

Page � 103

Manutenção de Conceitos ou Entidades

Cada conceito normalmente tem associadas operações de:

� inserção (I)

� alteração (A)

� exclusão (E)

� consulta (C)

Page � 105

Manutenção

Conceito I A E C Observação Ref. Cruzadas Cliente x x x x Só é possível excluir se não houver empréstimos associados F13 Reserva x x x x F15, F16 Fita x x x x Só é possível excluir se não houver empréstimos associados F18 Empréstimo x x A inclusão de empréstimo só pode acontecer através do

caso de uso “emprestar fitas”. Não é possível alterar um empréstimo, apenas excluir.

F17, F19

Page � 106

Consultas / Relatórios

Organização de Requisitos em Consultas

Nome Referências Cruzadas Vendas Mensais F20, F21, F22

Page � 108

Vendas Mensais F20, F21, F22 Clientes Suspensos F13, F23, F1 ... ...

Planejamento das Iterações

Planejamento do Desenvolvimento

� Alocar o desenvolvimento em ciclos iterativos de mesma duração

� Estimativa de Esforço

Page � 110

Estabelecendo Prioridades

� Casos de Uso Críticos

� Casos de Uso de Apoio

� Manutenção de Conceitos

� Consultas

Page � 111

Planejamento dos Ciclos Iterativos (Fase de Elaboração)

Ciclo Casos de

Uso Manutenção de Informações

Consultas Observações Esforço estimado

1 Emprestar - - Neste ciclo ainda não será 550 horas

Page � 112

1 Emprestar Fita (550)

- - Neste ciclo ainda não será implantado o mecanismo de persistência

550 horas

2 Devolver Fita (300)

- - Implementar mecanismo de persistência (300 horas)

600 horas

3 Reservar Filme (270)

Fita (100), Cliente (100) e Reserva (100)

- - 570 horas

4 - Emprestimo (100) todas (400) - 500 horas

Cronograma de Execução

� Considerar

– Tempo total estimado para o projeto (em hora/pessoa)

– Tempo disponível (em semanas ou meses)

– Tamanho da equipe

– Estruturação da equipe

Page � 113

Planejamento com 4 equipes

Dias: 1-10 11-20 21-30 31-40 41-50 51-60 61-70 70-90 Ciclo 1 análise projeto implementação testes

Page � 114

Ciclo 2 análise projeto implementação testes Ciclo 3 análise projeto implementação testes Ciclo 4 análise projeto implementação testes Implantação implantação

Planejamento com 2 equipes

Dias: 1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-180 181-200 201-220 Ciclo 1 análise projeto impl. testes Ciclo 2 análise projeto impl. testes Ciclo 3 análise projeto impl. testes

Page � 115

Ciclo 3 análise projeto impl. testes Ciclo 4 análise projeto impl. testes Implantação implant.

Observações

�Note que, associando requisitos não-funcionais a requisitos funcionais, a maior parte dos requisitos não-funcionais é implementada na fase de elaboração– Fase de construção: requisitos suplementares

Page � 116

– Fase de construção: requisitos suplementares

�Note também que, trabalhando com várias equipes, somente as atividades de implementação-testes são seqüênciais– Atividades de análise-projeto podem ocorrer em paralelo

Projeto do Curso

Projeto

�Fase Início (Concepção, Planejamento)– Documento constando de:

• Sumário Executivo – Documento de Visão

• Requisitos Funcionais e (Não-funcionais Associados)

• Requisitos suplementares

Page � 118

• Requisitos suplementares

• Casos de uso

• Modelo Conceitual

• Manutenção de Entidades

• Consultas / Relatórios

• Planejamento das Iterações

– Prazo de entrega: 05/09

[email protected]

Obrigado!Obrigado!

Introdução a Requisitos - Heuber Lima | Prof. Esp. MBA, CSM – Análise de … · 2011-02-18 ·...

Documents

Transcript of Introdução a Requisitos - Heuber Lima | Prof. Esp. MBA, CSM – Análise de … · 2011-02-18 ·...