DOCUMENTO DE REQUISITOS



DOCUMENTO DE REQUISITOS

ID documento:       Data:   /  /     Versão :      

Responsável pelo documento:      

ID Projeto:      

HISTÓRICO DE REVISÕES

|Data de |Descrição da(s) Mudança(s) Ocorrida(s) |Autor |Versão do |ID. Solicitação de|

|criação/ | | |Documento |Mudança |

|atualização | | | | |

|      |      |      |      |      |

|      |      |      |      |      |

|      |      |      |      |      |

|      |      |      |      |      |

|      |      |      |      |      |

1 – INTRODUÇÃO

1.1 Objetivo

Este documento tem por objetivo apresentar os requisitos que o sistema deve atender em diferentes níveis de detalhamento. Dessa forma, serve como acordo entre as partes envolvidas – cliente e analista/desenvolvedor.

1.2 Escopo

<

• Identificar o(s) produto(s) de software a ser(em) produzido(s) pelo nome.

• Explicar o quê o(s) produto(s) de software fará(ão) e, se necessário, o quê não fará(ão).

• Descrever a aplicação do software a ser especificado, incluindo benefícios relevantes, objetivos e metas.

• Ser consistente com as especificações de mais alto nível (tal como a especificação de requisitos do sistema), se existirem.>

1.3 Definições, Siglas e Abreviações

1.4 Referências

<

• Fornecer uma lista completa de todos os documentos referenciados na ERS.

• Identificar cada documento pelo título, número do relatório (se aplicável), data e organização que publicou.

• Especificar a(s) origem(s) das referências, ou seja, onde e/ou com quem podem ser obtidas.>

1.5 Visão Geral

O Capítulo 2 fornece uma descrição geral do produto, tendo como público-alvo os clientes. Dessa forma, esse capítulo é uma síntese dos requisitos que o sistema deverá atender para auxiliar ao negócio do cliente. São descritos: a perspectiva e funções do produto, as características dos usuários e os limites, suposições e dependências que influenciem a eficácia e eficiência do sistema.

No Capítulo 3, os requisitos descritos no capítulo 2 são detalhados ao ponto de serem úteis para os analistas e programadores do sistema.

2 – DESCRIÇÃO GERAL DO PRODUTO

2.1 Perspectiva do Produto

2.2 Funções do Produto

< Nessa seção deve ser fornecido um resumo das principais funções que o software deve realizar. Além disso, pode ser inserido algum diagrama, tal como Diagrama de Casos de Uso, para mostrar a fronteira do sistema e para fornecer uma visão geral do comportamento do sistema (para que ele é usado e por quem).

Por exemplo:

O Sistema de Locadora de Vídeo deve manter os dados dos clientes, dos DVD´s comprados de fornecedores registrados e das locações e devoluções realizadas por cada um dos clientes. Deve, também, permitir que o cliente faça a reserva de filmes, deve manter dados das contas a pagar e a receber e permitir a emissão do cupom fiscal.

[pic]

>

2.3 Características do Usuário

<

Descrever o nível educacional dos usuários do sistema, bem como a sua experiência e o conhecimento sobre informática para que seja diagnosticada a necessidade de treinamento específico. Deve fornecer as razões pelas quais certos requisitos são especificados.>

2.4 Limites, Suposições e Dependências

<

Descrever itens que limitem as opções do desenvolvedor, tais como: Normas regulamentadoras, Limitações do hardware, considerações de segurança, requisitos de confiabilidade, Linguagem de programação.

Com relação às suposições e dependências, descrever qualquer fator que afeta os requisitos expressos na ERS. Por exemplo: A não aquisição do ponto eletrônico fará com que o sistema não tenha o seu total desempenho, pois a entrada de dados será feita manualmente, inserindo somente as exceções do ponto diário, ou seja, a falta dos funcionários.>

2.5 Requisitos Adiados

<

Identificar os requisitos, que foram levantados, mas que por alguma razão serão adiados para versões futuras do sistema.>

3 – REQUISITOS ESPECÍFICOS

3.1 Requisitos de Interface Externa

3.1.1 Interfaces do Sistema

3.1.2 Interfaces do Usuário

3.1.3 Interfaces de Software

3.1.4 Interfaces de Hardware

3.1.5 Interfaces de Comunicação

3.2 Requisitos de Desempenho

3.3 Outros Requisitos

3.4 Funções

<

Serão descritas todas as funções do produto. Esses requisitos funcionais podem ser representados por meio de texto estruturado em linguagem natural, mas também podem ser representados por meio de casos de uso, dentre outras maneiras.

A seguir, serão apresentadas duas alternativas para documentar os requisitos.

Alternativa 1) As funções são descritas por meio de um texto estruturado em linguagem natural e para cada função são descritos os itens de entrada necessários (dados/informação) e os itens de saída gerados, além das regras de negócio que irão influenciar as funções.

Essas funções podem ser classificadas em:

• Funções Básicas: referem-se às operações CRUD (create, read, update, delete) necessárias para a execução das funções fundamentais. Esse conjunto de operações pode ser denominado “Gerenciar dados de ....”.

• Funções Fundamentais: referem-se às transações de negócio (movimentações), que realmente agregam valor ao negócio;

• Funções de Saída: referem-se às funções que geram informações de saída relevantes para atender às necessidades do cliente (por exemplo, relatórios com cruzamento de informações). Nesse caso, devem ser descritos não só os itens de entrada (filtros), mas também os itens de saída (informações) pertinentes.

Observações:

1) é importante que cada função tenha um identificador, a fim de facilitar a rastreabilidade desse requisito. Sugere-se que seja utilizado RF (requisito funcional) seguido de um underline, uma letra indicando se é função básica, fundamental ou saída externa (B, F, S) e um número sequencial. Ex: RF_B1. e RF_B2. para funções básicas, RF_F1., RF_F2. para funções fundamentais e RF_S1., RF_S2. para funções de saída externa).

2) não devem ser citados aqui os campos das possíveis tabelas do sistema, tais como, códigos sequenciais criados para facilitar na implementação. Aqui deverão ser citados apenas os itens de informação relacionados às funções do sistema.

3) As funções de gerenciamento do usuário, backup e restauração do sistema não serão citadas aqui, uma vez que já foram descritas no item 2.3 – Perspectiva do Produto.

EXEMPLO: Em um sistema de locadora de vídeo:

FUNÇÕES BÁSICAS

RF_B1. Gerenciar cliente: o usuário pode inserir, consultar, alterar e deletar os dados pessoais do cliente (nome, endereço, cep, cidade, estado, CPF, data de nascimento, e-mail e fone para contato).

RF_B2. Gerenciar vídeo: o usuário pode inserir, consultar, alterar e deletar os dados relacionados aos vídeos (código do vídeo, título, gênero, quantidade, preço de locação ).

FUNÇÕES FUNDAMENTAIS

RF_F1. Efetuar Reserva: o cliente pode fazer a reserva de determinado vídeo. Para isso são necessários os seguintes itens de informação: dados pessoais do cliente, dados do vídeo, data e hora da reserva. Caso o cliente ainda não esteja cadastrado no sistema, é necessário realizar um cadastro mesmo que somente com os itens obrigatórios: nome, CPF e fone.

RF_F2. Efetuar Locação: o cliente pode locar um vídeo, caso este não esteja reservado. São necessários os itens de informação: dados pessoais do cliente, dados do vídeo, preço da locação, data da locação e data para devolução (o cliente pode devolver o vídeo sem adicionais ao preço da locação em até 3 dias, após a data da locação). O registro da locação deve ser vinculado à uma conta a receber.

RF_F3. Efetuar Devolução: no ato da devolução são necessários os itens de informação: dados do cliente, dados do vídeo e data de devolução. Caso a data de devolução tenha ultrapassado os 3 dias após a locação, deve ser calculada uma multa de 10% sobre o valor da locação por dia de atraso.

RF_F4. Dar Baixa das contas a receber: o cliente pode optar por efetuar o pagamento no ato da locação ou da devolução. Sendo assim, deve ser registrada a data do pagamento e o valor pago, e deve ser gerado um cupom fiscal contendo as informações pertinentes à locação e ao pagamento.

RF_F5. Comprar vídeos por parte da locadora (incluindo contas a pagar): ....

RF_F6. Dar Baixa das contas a pagar: ....

FUNÇÕES DE SAÍDA

RF_S1. Listagem dos Clientes que mais locaram em determinado período: o usuário entra com o período e como saída tem-se uma lista contendo o nome, telefone de contato e e-mail de todos os clientes que mais locaram.

RF_S2. Balancete do mês:...

RF_S3. Fila de espera referente à reserva: ...

RF_S4. Listagem de Clientes inadimplentes: ...

Para complementar o entendimento dos requisitos, sugere-se elaborar o Modelo Conceitual, ou também denominado Modelo de Domínio, um modelo que pode ser utilizado como preliminar para a elaboração futura do modelo de dados do sistema. Esse tem por objetivo a visualização dos conceitos do domínio. Para a elaboração do modelo conceitual utiliza-se da representação do diagrama de classes da UML, entretanto, são colocados somente o nome do conceito, os seus atributos mais relevantes e as multiplicidades. É importante ressaltar que um conceito, não necessariamente, será uma classe de implementação.

Alternativa 2) Elaborar uma Lista de Funcionalidades na qual serão descritas todas as funções do sistema (requisitos funcionais), detalhadamente, inclusive as operações CRUD (que não serão consideradas CDU).

Na coluna Referência deve ser colocado um identificador corresponde ao requisito funcional. Exemplo: RF_1, RF_2. A coluna Categoria deve ser preenchida com Evidente (a função deve ser executada, e o usuário deve estar ciente da execução. Ex.: Registrar Venda, Processar Pagamento) ou Oculta (deve ser executada, mas de modo transparente para o usuário. Ex.: Dar baixa na qtde de um produto no estoque)

Exemplo:

|Referência |Funções |Categoria |

|RF_B1 |Gerenciar cliente |Evidente |

|RF_F1 |Efetuar Reserva |Evidente |

|RF_F1.1 |Verificar cadastro do cliente |Oculta |

|RF_F1.2 |Registrar reserva |Oculta |

A seguir, realizar as Especificações dos Casos de Uso Essenciais (sem definir considerações tecnológicas). Cada caso de uso (CDU) pode ser especificado usando um template (tal como o definido no RUP e mostrado, a seguir).

|Seção do CDU |Comentário |

|Nome do Caso de Uso |Começar com um verbo. |

|Breve Descrição |Descrição em alto nível do CDU. |

|Fluxo Básico |Um caminho típico, incondicional e otimista do cenário de sucesso. |

|Fluxos Alternativos |Cenários Alternativos de sucesso ou fracasso. |

|Requisitos Especiais |Requisitos não funcionais relacionados. |

|Pré-Condições |O que precisa ser verdade antes da realização do CDU. |

|Pós-Condições |O que precisa ser verdade quando da finalização bem sucedida. |

|Relacionamentos |Os relacionamentos que envolvem os CDUs, tais como include e extend. |

Ainda, para os CDUs que possuem atividades concorrentes, pode-se elaborar um Diagrama de Atividades.

Para complementar o entendimento dos requisitos, sugere-se elaborar o Modelo Conceitual, ou também denominado Modelo de Domínio, um modelo que pode ser utilizado como preliminar para a elaboração futura do modelo de dados do sistema. Esse tem por objetivo a visualização dos conceitos do domínio. Para a elaboração do modelo conceitual utiliza-se da representação do diagrama de classes da UML, entretanto, são colocados somente o nome do conceito, os seus atributos mais relevantes e as multiplicidades. É importante ressaltar que um conceito, não necessariamente, será uma classe de implementação.

>

VOLATILIDADE DOS REQUISITOS

| RQ |Alta |Média |Baixa |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

MATRIZ DE RASTREABILIDADE - REQUISITOS CLIENTE X PRODUTO

RQC

RQ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

MATRIZ DE RASTREABILIDADE - REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS DO PRODUTO

RQC

RQ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

MATRIZ DE RASTREABILIDADE - REQUISITOS DO PRODUTO X COMPONENTES

Com

RQ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

APÊNDICE 1 - LISTA DE REQUISITOS DO CLIENTE

APÊNDICE 2 - COMPONENTES EMPREGADOS

APÊNDICE 3 - PROTÓTIPOS

-----------------------

Diagrama de Casos de Uso

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

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download