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) Autor Versão do ID.

criação/ Ocorrida(s) Documento Solicitação
atualização de
Mudança
                             
                             
                             
                             
                             
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

<Fornecer as definições de todos os termos, acrônimos e abreviações necessárias
para interpretar de modo apropriado a ERS. >

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

<Tem por objetivo descrever fatores gerais do produto e seus requisitos, fornecendo
um contexto para esses requisitos os quais são definidos em detalhes no capítulo 3 da
ERS.>

2.1 Perspectiva do Produto

<Deve ser descrito de maneira resumida, de forma textual, sem detalhamento (1/2
página, no máximo, pois trata-se de uma descrição geral), pois as interfaces
mencionadas nessa seção serão detalhadas na seção 3.1 (Requisitos de Interface
Externa). Segundo o padrão IEEE, se o produto a ser desenvolvido for parte de um
sistema maior a ERS deverá identificar quais as interfaces existentes entre esse
sistema e o produto a ser desenvolvido.

Exemplo 1:
O sistema funcionará em um PC AT atualmente disponível na Locadora Fulano de Tal.
O sistema terá interface com leitores de códigos de barras para simplificar o processo
de alugar e devolver uma fita, e com impressoras do tipo tal para emitir os recibos
para os clientes e para a própria locadora. Todas as informações relativas aos
clientes, tais como: x, y, z; e informações históricas das locações serão armazenadas.

O texto pode incluir (não obrigatoriamente, pois depende do caso) informações sobre:

-Interfaces do Sistema: Normalmente um software faz parte de um sistema (sistema

administrativo) maior existente dentro de uma empresa. A ERS deve listar as
interfaces do sistema para com o produto, identificando as funcionalidades do
software que irão realizar essas interfaces.

-Interfaces do Usuário: Características lógicas das interfaces entre o produto e seus

usuários, como por exemplos: formatos de telas, aspectos de otimização da interface
com o usuário do sistema (por ex, mensagens curtas ou longas, definir que um
usuário pode utilizar o sistema após x horas de treinamento), padrão de relatórios ou
menus de consulta, acesso por níveis de usuários, mensagens, dentre outros.

-Interfaces de Hardware: se o produto interage com dispositivos de hardware, estes

devem ser especificados (por exemplo, impressoras, scanners, relógios de ponto,
catracas eletrônicas ou outros dispositivos eletrônicos com o qual o produto irá
comunicar-se).

-Interfaces de Software: especificar o uso de outros softwares necessários (banco de

dados, sistemas operacionais, software para capturar imagem, ou outros softwares
aplicativos de mesma natureza).

-Interfaces de Comunicação: especificar tipos de comunicação necessários para o

funcionamento do produto. Por exemplo, o software que é responsável pelo
gerenciamento da catraca precisa comunicar-se com as mesmas por meio de um par-
trançado. Como, então, deverá ser implementada essa comunicação? Isso deve ser
descrito aqui sem detalhes.

-Limites de Memória: especificar os limites mínimos de memória primária e

secundária.

-Operações: rotinas de inicialização (definir níveis de acesso; processamento; backup

e restauração do sistema).

-Requisitos para adaptação de situação: especificar situações em que o software deve

ser adaptado antes da instalação. Por exemplo: em um sistema que necessite a
conexão com a internet. Se no momento da instalação o computador não estiver
conectado, o sistema identifica e grava os dados em um arquivo temporário e, quando
restabelecer a conexão, os dados são recuperados deste arquivo temporário e a
instalação pode concluída. Outro exemplo refere-se às adaptações necessárias para a
instalação do software em outra versão do S.O.
>

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.

Diagrama de Casos de Uso

<<communicate>>

<Use Case Name>

<Actor Name>
(from <Use Case Name>)
(f rom Actors)

>

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
<Essa seção deve conter todos os requisitos do software com um nível de
detalhamento suficiente para possibilitar aos projetistas/desenvolvedores projetarem
um sistema que atenda a esses requisitos.>

3.1 Requisitos de Interface Externa

<Detalhar o que foi descrito de forma sucinta na seção 2.3 (perspectiva do produto)
com relação às interfaces externas, sem repetir informação. Esses requisitos referem-
se aos requisitos não funcionais >
3.1.1 Interfaces do Sistema
<caso o software em questão tenha que ser integrado com algum já existente>

3.1.2 Interfaces do Usuário

<Deve ser descrito como o usuário vai interagir com o sistema, sem mostrar
graficamente as telas, pois existe uma seção específica para isso. Descrever como
será o formato padrão das telas e relatórios, quais os procedimentos a serem
adotados em caso de erros, para que servem e como serão apresentadas as
mensagens do sistema para o usuário (por exemplo, não serão exibidas mensagens
em caixas de diálogo, mas através de um label em um determinado local da tela. As
mensagens exibidas em caixas de diálogos serão somente para erros do sistema que
só podem ser resolvidas pelo desenvolvedor).>

3.1.3 Interfaces de Software

<descrever os detalhes dos softwares necessários para o desenvolvimento e
execução do software em questão. Isso inclui nome, mnemônico, especificação
numérica, versão e fonte>

3.1.4 Interfaces de Hardware

<Com relação à interface de hardware, por exemplo, a ERS deverá detalhar como
será realizada a interface em questão. Se for um relógio de ponto, por exemplo, como
será o layout do arquivo que será emitido pelo equipamento ao sistema. Por exemplo:
O equipamento para a leitura do ponto dos funcionários será da marca XXXX, modelo
YYYY, etc. O relógio ponto gera um arquivo com a extensão txt, o qual possui a
seguinte estrutura em cada uma das linhas:
CÓDIGO_FUNCIONÁRIO: 4 caracteres, DATA: 10 caracteres, HORÁRIO: 5 caracteres
Ex.:

CODFUN DATA HORÁRIO

43219 05/09/2003 7:30
43219 05/09/2003 11:30
...
>
3.1.5 Interfaces de Comunicação
<Especificar os tipos de comunicação utilizados para integração com outros periféricos
e tecnologias. Ex: par-trançado, protocolos de comunicação, etc>
3.2 Requisitos de Desempenho
<Especificar os requisitos numéricos estáticos e dinâmicos sobre o software ou uma
interação humana com o software. Os requisitos numéricos estáticos podem incluir: o
número de terminais suportado, o número de usuários simultâneos suportado, a
quantidade e o tipo de informação a ser manipulado. Os requisitos numéricos
dinâmicos podem incluir, por exemplo, o número de transações e tarefas e a
quantidade de dados a ser processado dentro de determinado período de tempo e
condições de pico de sobrecarga. Todos esses requisitos devem ser declarados em
termos mensuráveis. Por ex: “95 % das transações devem ser processadas em menos
de 1 segundo”.>

3.3 Outros Requisitos

<Descrever aqui restrições do projeto que podem ser impostas por conformidade a
padrões, limitações de hardware, e por outros requisitos não funcionais:
manutenibilidade, portabilidade, confiabilidade, requisitos éticos, requisitos de entrega,
etc.
>

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

<Aqui são descritos os requisitos do cliente, da forma como eles os expõe. Muitas
vezes, um requisito de cliente transforma-se em N requisitos do sistema.
1. <requisito 1 do cliente>
2. <requisito 2 do cliente >
3. <requisito 3 do cliente>
 4. ...
>

APÊNDICE 2 - COMPONENTES EMPREGADOS

<Aqui são identificados os componentes utilizados no projeto, inclusive os já
existentes em uma Biblioteca.
1. <componente 1>
2. <componente 2>
3. <componente 3>
4. ...
>

APÊNDICE 3 - PROTÓTIPOS
<Aqui são inseridos os protótipos, caso tenham sido construídos para auxiliar no
levantamento e análise dos requisitos>