DOCUMENTO DE REQUISITOS

ID documento: Data: // Responsvel pelo documento: ID Projeto: Verso :

HISTRICO DE REVISES
Data de criao/ atualizao Descrio da(s) Mudana(s) Ocorrida(s) Autor Verso do Documento ID. Solicitao de Mudana

1 INTRODUO 1.1 Objetivo

Este documento tem por objetivo apresentar os requisitos que o sistema deve atender em diferentes nveis 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 necessrio, o qu no far(o). Descrever a aplicao do software a ser especificado, incluindo benefcios relevantes, objetivos e metas. Ser consistente com as especificaes de mais alto nvel (tal como a especificao de requisitos do sistema), se existirem.>

1.3 Definies, Siglas e Abreviaes

<Fornecer as definies de todos os termos, acrnimos e abreviaes necessrias para interpretar de modo apropriado a ERS. >

1.4 Referncias
< Fornecer uma lista completa de todos os documentos referenciados na ERS. Identificar cada documento pelo ttulo, nmero do relatrio (se aplicvel), data e organizao que publicou. Especificar a(s) origem(s) das referncias, ou seja, onde e/ou com quem podem ser obtidas.>

1.5 Viso Geral

O Captulo 2 fornece uma descrio geral do produto, tendo como pblico-alvo os clientes. Dessa forma, esse captulo uma sntese dos requisitos que o sistema dever atender para auxiliar ao negcio do cliente. So descritos: a perspectiva e funes do produto, as caractersticas dos usurios e os limites, suposies e dependncias que influenciem a eficcia e eficincia do sistema. No Captulo 3, os requisitos descritos no captulo 2 so detalhados ao ponto de serem teis para os analistas e programadores do sistema.

2 DESCRIO GERAL DO PRODUTO

<Tem por objetivo descrever fatores gerais do produto e seus requisitos, fornecendo um contexto para esses requisitos os quais so definidos em detalhes no captulo 3 da ERS.>

2.1 Perspectiva do Produto

<Deve ser descrito de maneira resumida, de forma textual, sem detalhamento (1/2 pgina, no mximo, pois trata-se de uma descrio geral), pois as interfaces mencionadas nessa seo sero detalhadas na seo 3.1 (Requisitos de Interface Externa). Segundo o padro 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 disponvel na Locadora Fulano de Tal. O sistema ter interface com leitores de cdigos 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 prpria locadora. Todas as informaes relativas aos clientes, tais como: x, y, z; e informaes histricas das locaes sero armazenadas. O texto pode incluir (no obrigatoriamente, pois depende do caso) informaes 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 iro realizar essas interfaces. -Interfaces do Usurio: Caractersticas lgicas das interfaces entre o produto e seus usurios, como por exemplos: formatos de telas, aspectos de otimizao da interface com o usurio do sistema (por ex, mensagens curtas ou longas, definir que um usurio pode utilizar o sistema aps x horas de treinamento), padro de relatrios ou menus de consulta, acesso por nveis de usurios, mensagens, dentre outros. -Interfaces de Hardware: se o produto interage com dispositivos de hardware, estes devem ser especificados (por exemplo, impressoras, scanners, relgios de ponto, catracas eletrnicas ou outros dispositivos eletrnicos com o qual o produto ir comunicar-se). -Interfaces de Software: especificar o uso de outros softwares necessrios (banco de dados, sistemas operacionais, software para capturar imagem, ou outros softwares aplicativos de mesma natureza). -Interfaces de Comunicao: especificar tipos de comunicao necessrios para o funcionamento do produto. Por exemplo, o software que responsvel pelo gerenciamento da catraca precisa comunicar-se com as mesmas por meio de um partranado. Como, ento, dever ser implementada essa comunicao? Isso deve ser descrito aqui sem detalhes. -Limites de Memria: especificar os limites mnimos de memria primria e secundria. -Operaes: rotinas de inicializao (definir nveis de acesso; processamento; backup e restaurao do sistema). -Requisitos para adaptao de situao: especificar situaes em que o software deve ser adaptado antes da instalao. Por exemplo: em um sistema que necessite a conexo com a internet. Se no momento da instalao o computador no estiver conectado, o sistema identifica e grava os dados em um arquivo temporrio e, quando restabelecer a conexo, os dados so recuperados deste arquivo temporrio e a instalao pode concluda. Outro exemplo refere-se s adaptaes necessrias para a instalao do software em outra verso do S.O. >

2.2 Funes do Produto

< Nessa seo deve ser fornecido um resumo das principais funes que o software deve realizar. Alm disso, pode ser inserido algum diagrama, tal como Diagrama de Casos de Uso, para mostrar a fronteira do sistema e para fornecer uma viso geral do comportamento do sistema (para que ele usado e por quem).

Por exemplo: O Sistema de Locadora de Vdeo deve manter os dados dos clientes, dos DVD s comprados de fornecedores registrados e das locaes e devolues realizadas por cada um dos clientes. Deve, tambm, permitir que o cliente faa a reserva de filmes, deve manter dados das contas a pagar e a receber e permitir a emisso do cupom fiscal.

Diagrama de Casos de Uso

<Actor Name>
(f rom Actors)

<<communicate>> <Use Case Name>

(from <Use Case Name>)

> 2.3 Caractersticas do Usurio

< Descrever o nvel educacional dos usurios do sistema, bem como a sua experincia e o conhecimento sobre informtica para que seja diagnosticada a necessidade de treinamento especfico. Deve fornecer as razes pelas quais certos requisitos so especificados.>

2.4 Limites, Suposies e Dependncias

< Descrever itens que limitem as opes do desenvolvedor, tais como: Normas regulamentadoras, Limitaes do hardware, consideraes de segurana, requisitos de confiabilidade, Linguagem de programao. Com relao s suposies e dependncias, descrever qualquer fator que afeta os requisitos expressos na ERS. Por exemplo: A no aquisio do ponto eletrnico far com que o sistema no tenha o seu total desempenho, pois a entrada de dados ser feita manualmente, inserindo somente as excees do ponto dirio, ou seja, a falta dos funcionrios.>

2.5 Requisitos Adiados

< Identificar os requisitos, que foram levantados, mas que por alguma razo sero adiados para verses futuras do sistema.>

3 REQUISITOS ESPECFICOS
<Essa seo deve conter todos os requisitos do software com um nvel 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 seo 2.3 (perspectiva do produto) com relao s interfaces externas, sem repetir informao. Esses requisitos referemse aos requisitos no funcionais >

3.1.1 Interfaces do Sistema

<caso o software em questo tenha que ser integrado com algum j existente>

3.1.2 Interfaces do Usurio

<Deve ser descrito como o usurio vai interagir com o sistema, sem mostrar graficamente as telas, pois existe uma seo especfica para isso. Descrever como ser o formato padro das telas e relatrios, quais os procedimentos a serem adotados em caso de erros, para que servem e como sero apresentadas as mensagens do sistema para o usurio (por exemplo, no sero exibidas mensagens em caixas de dilogo, mas atravs de um label em um determinado local da tela. As mensagens exibidas em caixas de dilogos sero somente para erros do sistema que s podem ser resolvidas pelo desenvolvedor).>

3.1.3 Interfaces de Software

<descrever os detalhes dos softwares necessrios para o desenvolvimento e execuo do software em questo. Isso inclui nome, mnemnico, especificao numrica, verso e fonte>

3.1.4 Interfaces de Hardware

<Com relao interface de hardware, por exemplo, a ERS dever detalhar como ser realizada a interface em questo. Se for um relgio 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 funcionrios ser da marca XXXX, modelo YYYY, etc. O relgio ponto gera um arquivo com a extenso txt, o qual possui a seguinte estrutura em cada uma das linhas:
CDIGO_FUNCIONRIO: 4 caracteres, DATA: 10 caracteres, HORRIO: 5 caracteres Ex.: CODFUN 43219 43219 DATA 05/09/2003 05/09/2003 ... HORRIO 7:30 11:30

> 3.1.5 Interfaces de Comunicao

<Especificar os tipos de comunicao utilizados para integrao com outros perifricos e tecnologias. Ex: par-tranado, protocolos de comunicao, etc>

3.2 Requisitos de Desempenho

<Especificar os requisitos numricos estticos e dinmicos sobre o software ou uma interao humana com o software. Os requisitos numricos estticos podem incluir: o nmero de terminais suportado, o nmero de usurios simultneos suportado, a quantidade e o tipo de informao a ser manipulado. Os requisitos numricos dinmicos podem incluir, por exemplo, o nmero de transaes e tarefas e a quantidade de dados a ser processado dentro de determinado perodo de tempo e condies de pico de sobrecarga. Todos esses requisitos devem ser declarados em termos mensurveis. Por ex: 95 % das transaes devem ser processadas em menos de 1 segundo.>

3.3 Outros Requisitos

<Descrever aqui restries do projeto que podem ser impostas por conformidade a padres, limitaes de hardware, e por outros requisitos no funcionais: manutenibilidade, portabilidade, confiabilidade, requisitos ticos, requisitos de entrega, etc. >

3.4 Funes
< Sero descritas todas as funes do produto. Esses requisitos funcionais podem ser representados por meio de texto estruturado em linguagem natural, mas tambm podem ser representados por meio de casos de uso, dentre outras maneiras. A seguir, sero apresentadas duas alternativas para documentar os requisitos. Alternativa 1) As funes so descritas por meio de um texto estruturado em linguagem natural e para cada funo so descritos os itens de entrada necessrios (dados/informao) e os itens de sada gerados, alm das regras de negcio que iro influenciar as funes. Essas funes podem ser classificadas em: Funes Bsicas: referem-se s operaes CRUD (create, read, update, delete) necessrias para a execuo das funes fundamentais. Esse conjunto de operaes pode ser denominado Gerenciar dados de ..... Funes Fundamentais: referem-se s transaes de negcio (movimentaes), que realmente agregam valor ao negcio; Funes de Sada: referem-se s funes que geram informaes de sada relevantes para atender s necessidades do cliente (por exemplo, relatrios com cruzamento de informaes). Nesse caso, devem ser descritos no s os itens de entrada (filtros), mas tambm os itens de sada (informaes) pertinentes. Observaes: 1) importante que cada funo 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 funo bsica, fundamental ou sada externa (B, F, S) e um nmero sequencial. Ex: RF_B1. e RF_B2. para funes bsicas, RF_F1., RF_F2. para funes fundamentais e RF_S1., RF_S2. para funes de sada externa).

2) no devem ser citados aqui os campos das possveis tabelas do sistema , tais
como, cdigos sequenciais criados para facilitar na implementao. Aqui devero ser citados apenas os itens de informao relacionados s funes do sistema. 3) As funes de gerenciamento do usurio, backup e restaurao do sistema no sero citadas aqui, uma vez que j foram descritas no item 2.3 Perspectiva do Produto. EXEMPLO: Em um sistema de locadora de vdeo: FUNES BSICAS RF_B1. Gerenciar cliente: o usurio pode inserir, consultar, alterar e deletar os dados pessoais do cliente (nome, endereo, cep, cidade, estado, CPF, data de nascimento, e-mail e fone para contato). RF_B2. Gerenciar vdeo: o usurio pode inserir, consultar, alterar e deletar os dados relacionados aos vdeos (cdigo do vdeo, ttulo, gnero, quantidade, preo de locao ). FUNES FUNDAMENTAIS RF_F1. Efetuar Reserva: o cliente pode fazer a reserva de determinado vdeo. Para isso so necessrios os seguintes itens de informao: dados pessoais do cliente, dados do vdeo, data e hora da reserva. Caso o cliente ainda no esteja cadastrado no sistema, necessrio realizar um cadastro mesmo que somente com os itens obrigatrios: nome, CPF e fone. RF_F2. Efetuar Locao: o cliente pode locar um vdeo, caso este no esteja reservado. So necessrios os itens de informao: dados pessoais do cliente, dados do vdeo, preo da locao, data da locao e data para devoluo (o cliente pode devolver o vdeo sem adicionais ao preo da locao em at 3 dias, aps a data da locao). O registro da locao deve ser vinculado uma conta a receber. RF_F3. Efetuar Devoluo: no ato da devoluo so necessrios os itens de informao: dados do cliente, dados do vdeo e data de devoluo. Caso a data de devoluo tenha ultrapassado os 3 dias aps a locao, deve ser calculada uma multa de 10% sobre o valor da locao por dia de atraso. RF_F4. Dar Baixa das contas a receber: o cliente pode optar por efetuar o pagamento no ato da locao ou da devoluo. Sendo assim, deve ser registrada a data do pagamento e o valor pago, e deve ser gerado um cupom fiscal contendo as informaes pertinentes locao e ao pagamento. RF_F5. Comprar vdeos por parte da locadora (incluindo contas a pagar): .... RF_F6. Dar Baixa das contas a pagar: .... FUNES DE SADA RF_S1. Listagem dos Clientes que mais locaram em determinado perodo: o usurio entra com o perodo e como sada tem-se uma lista contendo o nome, telefone de contato e e-mail de todos os clientes que mais locaram. RF_S2. Balancete do ms:... 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 tambm denominado Modelo de Domnio, um modelo que pode ser utilizado como preliminar para a elaborao futura do modelo de dados do sistema. Esse tem por objetivo a visualizao dos conceitos do domnio. Para a elaborao do modelo conceitual utiliza-se da representao do diagrama de classes da UML,

entretanto, so colocados somente o nome do conceito, os seus atributos mais relevantes e as multiplicidades. importante ressaltar que um conceito, no necessariamente, ser uma classe de implementao. Alternativa 2) Elaborar uma Lista de Funcionalidades na qual sero descritas todas as funes do sistema (requisitos funcionais), detalhadamente, inclusive as operaes CRUD (que no sero consideradas CDU). Na coluna Referncia deve ser colocado um identificador corresponde ao requisito funcional. Exemplo: RF_1, RF_2. A coluna Categoria deve ser preenchida com Evidente (a funo deve ser executada, e o usurio deve estar ciente da execuo. Ex.: Registrar Venda, Processar Pagamento) ou Oculta (deve ser executada, mas de modo transparente para o usurio. Ex.: Dar baixa na qtde de um produto no estoque) Exemplo: Referncia RF_B1 RF_F1 RF_F1.1 RF_F1.2

Funes Gerenciar cliente Efetuar Reserva Verificar cadastro do cliente Registrar reserva

Categoria Evidente Evidente Oculta Oculta

A seguir, realizar as Especificaes dos Casos de Uso Essenciais (sem definir consideraes tecnolgicas). Cada caso de uso (CDU) pode ser especificado usando um template (tal como o definido no RUP e mostrado, a seguir). Seo do CDU Nome do Caso de Uso Breve Descrio Fluxo Bsico Fluxos Alternativos Requisitos Especiais Pr-Condies Ps-Condies Relacionamentos Comentrio Comear com um verbo. Descrio em alto nvel do CDU. Um caminho tpico, incondicional e otimista do cenrio de sucesso. Cenrios Alternativos de sucesso ou fracasso. Requisitos no funcionais relacionados. O que precisa ser verdade antes da realizao do CDU. O que precisa ser verdade quando da finalizao bem sucedida. 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 tambm denominado Modelo de Domnio, um modelo que pode ser utilizado como preliminar para a elaborao futura do modelo de dados do sistema. Esse tem por objetivo a visualizao dos conceitos do domnio. Para a elaborao do modelo conceitual utiliza-se da representao do diagrama de classes da UML, entretanto, so colocados somente o nome do conceito, os seus atributos mais relevantes e as multiplicidades. importante ressaltar que um conceito, no necessariamente, ser uma classe de implementao. >

VOLATILIDADE DOS REQUISITOS RQ Alta Mdia Baixa

MATRIZ DE RASTREABILIDADE - REQUISITOS CLIENTE X PRODUTO RQC RQ

MATRIZ DE RASTREABILIDADE - REQUISITOS FUNCIONAIS E NO FUNCIONAIS DO PRODUTO RQC RQ

MATRIZ DE RASTREABILIDADE - REQUISITOS DO PRODUTO X COMPONENTES Com RQ

APNDICE 1 - LISTA DE REQUISITOS DO CLIENTE

<Aqui so descritos os requisitos do cliente, da forma como eles os expe. 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. ... >

APNDICE 2 - COMPONENTES EMPREGADOS

<Aqui so identificados os componentes utilizados no projeto, inclusive os j existentes em uma Biblioteca. 1. <componente 1> 2. <componente 2> 3. <componente 3> 4. ... > APNDICE 3 - PROTTIPOS <Aqui so inseridos os prottipos, caso tenham sido construdos para auxiliar no levantamento e anlise dos requisitos>