Template Documento Requisitos.odt

(1)

Cliente: Nome do Cliente

Nome do sistema

DOCUMENTO DE REQUISITOS

Versão 1

Nome da Empresa (equipe)

(2)

Revisões do Documento

Revisões são melhoramentos na estrutura do documento e também no seu conteúdo. O objetivo primário desta tabela é a fácil identificação da versão do documento. Toda modificação no documento deve constar nesta tabela.

Data Versão Descrição Autor

Dd/mm/aaaa 1.0 • Criação do Documento Dd/mm/aaaa 01/01/15 • Alterações em …...

(3)

Tipo de Licença do Documento

Este trabalho está licenciado sob uma Licença Creative Commons Atribuição-Compartilhamento pela mesma licença 2.5 Brazil. Para ver uma cópia desta licença, visite

http://creativecommons.org/licenses/by-sa/2.5/br/ ou envie uma carta para Creative Commons, 559, Nathan Abbott Way, Stanford, California 94305, USA.

(4)

ÍNDICE

(5)

1.

1. INTRODUÇÃO

INTRODUÇÃO

Este documento especifica os requisitos do Sistema xxxx para a xxxx xxxxx, fornecendo aos desenvolvedores as informações necessárias para a execução de seu projeto e implementação, assim como para a realização dos testes e homologação.

Esta introdução fornece as informações necessárias para fazer um bom uso deste documento, explicitando seus objetivos e as convenções que foram adotadas no texto. As demais seções apresentam a especificação deste sistema e estão organizadas como descrito abaixo:

Seção 2 - Descrição geral do produto/serviço: apresenta uma visão geral do produto/serviço, caracterizando qual é o seu escopo e descrevendo seus usuários. Seção 3 - Requisitos funcionais: lista e descreve os requisitos funcionais do produto/serviço, especificando seus objetivos, funcionalidades, atores e prioridades. Seção 4 - Requisitos não funcionais: especifica todos os requisitos não funcionais do produto/serviço, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurança, distribuição, adequação a padrões e requisitos de hardware e software.

1.1

(6)

1.2Convenções, termos e abreviações (Como este documento é

estruturado e como deve ser entendido)

A correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir.

1.2.1Identificação dos Requisitos

Por convenção, a referência a requisitos é feita através do identificador do requisito, de acordo com o esquema abaixo:

[<identificador de tipo de requisito><identificador do requisito>] O identificador de tipo de requisito pode ser:

 RF – requisito funcional  RNF – requisito não-funcional

Identificador do requisito é um número, criado sequencialmente, que determina que aquele requisito é único para um determinado tipo de requisito.

Ex: RF1, RF2, RNF1, RNF2.

1.2.2Prioridades dos Requisitos

Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável”.

Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.

Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.

Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

1.2.3Especificação de Requisitos

As especificações dos requisitos deste documento obedecem às propriedades enumeradas a seguir:

● Não ambiguidade: Todas as especificações devem, idealmente, ter uma única

interpretação.

● Completude: Descrever cada aspecto significante e relevante do sistema e

deve incluir detalhes a respeito de todas as informações.

● Consistência: Não devem existir requisitos contraditórios na especificação.

(7)

● Verificabilidade: Quando o sistema for projetado e implementado, deverá ser

possível verificar se os projetos de implementação satisfazem os requisitos originais.

● Validação: O usuário/cliente deve ser capaz de ler e entender a especificação

de requisitos e, então, indicar se os requisitos refletem as suas ideias.

● Modificação: Alterações devem ser feitas facilmente, sem a necessidade de

que tais modificações sejam realizadas em toda a especificação.

● Compreensão: Clientes, usuários, analista, projetistas e engenheiros devem

ser capazes de entender os requisitos.

● Rastreamento: Devem ser feitas referencias entre os requisitos, aspectos de

projetos e implementação.

1.2.4Tabelas Relacionadas aos Requisitos

Em algumas tabelas de relatórios do sistema (como a tabela explicativa 1) existe o símbolo ‘>’ na coluna “Nome do Campo”. Esta foi a simbologia adotada para representar sub-níveis no relatório. Para o primeiro sub-nível ’>’; para o segundo ‘>>’ e assim sucessivamente.

Podem existir vários sub-níveis ‘>’ para um determinado nível, assim como vários sub-níveis ‘>>’ para um sub-nível ‘>’. A tabela abaixo exemplifica o texto anteriormente descrito:

Nome do Campo Descrição do Campo

Nome do curso Nome da disciplina

Lista de alunos: Lista de alunos matriculados na disciplina > RGM

> Nome do aluno

> Lista de notas do aluno: >> Nota 1

>> Nota 2

> Quantidade de faltas

Tabela Explicativa 1 – Notas dos Alunos na Disciplina 1.2.5Termos e abreviações do sistema

Para um melhor entendimento, alguns termos técnicos estão relacionados abaixo:

Termo Descrição

Login Nome de uma conta de usuário de sistema. Por exemplo, em uma conta de email, o login é o que fica antes do símbolo arroba "@": login_do_usuario@empresa.br.

Apelido Mesmo que Login. Usado por alguns atores.

Autenticação Processo de identificação de um usuário. Geralmente usando-se

(8)

Login e Senha.

Usuário Uma pessoa que tem acesso ao sistema para determinada finalidade ou necessidade.

Ator Classificação ou tipo de usuário. Uma pessoa que tem um papel ou responsabilidade definida dentro de um sistema.

LDAP Sigla para Lightweight Directory Access Protocol. Serviço de rede com capacidade de armazenar dados sobre pessoas, recursos e organizações.

Referência: http://www.openldap.org

1.2.6Termos e abreviações do cliente

Segue abaixo os termos e abreviações usados na NOME DA EMPRESA ONDE SERA DESENVOLVIDO O SISTEMA.

Termo Descrição

TCC Trabalho de conclusão de curso

LDB Lei de Diretrizes e Bases da Educação Nacional

2.

(9)

3.

3. VISÃO GERAL DO CLIENTE

VISÃO GERAL DO CLIENTE

A NOME DA EMPRESA, criada DATA CRIAÇÃO E QUEM CRIOU, é um órgão vinculado administrativamente NOME DA EMPRESA, responsável pelo ....

4.

4. VISÃO GERAL DO PRODUTO/SERVIÇO

VISÃO GERAL DO PRODUTO/SERVIÇO

O ... terá como característica principal auxiliar a ... no controle e armazenamento de informações referentes ... e as atividades de seus ...

4.1Abrangência do sistema

O sistema estará inserido principalmente na rotina de trabalho ..., auxiliando no desempenho de ...

Haverá também, mediante devida avaliação, a necessidade de ... acessarem informações gerenciais e relatórios específicos ...

Os dados armazenados por este sistema também servirão de alimentação para outros sistemas ...

4.2Sistemas relacionados (se houver)

O NOME DO SISTEMA se relacionará com outros sistemas dentro da ... Pode-se classificar este relacionamento em duas formas:

● Sistemas Fracamente Acoplados: São sistemas que não compartilham os

mesmos recursos como o banco de dados. O relacionamento com esses sistemas fica então restrito a geração e importação de dados.

● Sistemas Fortemente Acoplados: São sistemas que estarão intimamente

ligados. Compartilhando os mesmos dados e recursos. Desta forma, as informações atualizadas em um sistema refletem automaticamente no outro sistema.

4.2.1Sistemas Fracamente Acoplados (se houver)

NOME DO SISTEMA: DESCRIÇÃO BREVE DO SISTEMA. NOME DO SISTEMA: DESCRIÇÃO BREVE DO SISTEMA.

4.2.2Sistemas Fortemente Acoplados (se houver)

COMENTAR ONDE O SISTEMA ESTARA INSERIDO E SE FARA COMARTILHAMENTO OU INTEGRACAO DE DADOS COM OUTROS SISTEMAS IMPORTANTES

4.2.3Diagrama de Contexto

Segue abaixo uma representação gráfica do relacionamento entre o Sistema de NOME DO SISTEMA e os demais sistemas.

(10)

4.3 Descrição dos Tipos de Usuários (Atores)

4.3.1NOME DO ATOR

DESCRIÇÃO E RESPONSABILIDADE DESTE ATOR

4.3.2NOME DO ATOR

DESCRIÇÃO E RESPONSABILIDADE DESTE ATOR

4.4Hierarquia dos Usuários (se houver)

Segue abaixo a representação de hierarquia dos usuários do sistema, onde cada usuário de um nível tem acesso a todas as funcionalidades dos usuários dos níveis subordinados a ele.

DESENHO DE HIERARQUIA

4.5Acúmulo de Funções dos Usuários (se houver)

Existem alguns casos em que um usuário poderá exercer papéis diferentes dentro do sistema de forma acumulativa. Os casos de acúmulo de funções estão listados abaixo:

1. DESCREVER QUAIS E PORQUE

Os demais cargos e funções relacionados na seção 3.3 não podem acumular entre si.

4.6Módulos do Sistema (se houver)

O sistema acadêmico estará dividido em XXXXXX módulos principais: 1. Módulo – DESCRIÇAO E QUAIS ATORES UTILIZARAO 2. Módulo – DESCRIÇAO E QUAIS ATORES UTILIZARAO 3. Módulo – DESCRIÇAO E QUAIS ATORES UTILIZARAO

5.

(11)

6.

6. REQUISITOS FUNCIONAIS

REQUISITOS FUNCIONAIS

6.1Definições Gerais do Sistema

Nesta seção estão agrupados os requisitos funcionais relacionados ao acesso dos usuários ao sistema.

6.1.1Cadastros Gerais

[RF9] Cadastrar Instituição

Atores: Módulo:

O sistema deverá conter o cadastro da Instituição de Ensino para fins de impressão de relatórios. Ele deverá permitir apenas 1 (uma) Instituição de ensino, neste caso a XXXXX.

Nome da Instituição Nome de identificação

Endereço (Logradouro, número, bairro, cidade, CEP., etc) Ato de Criação Lei que informa a criação da instituição de ensino. Lista de dados Recredenciamento Listagem de dados referente ao recredenciamento

da instituição.

>Recredenciamento Ato que renova o credenciamento da instituição. Para os relatórios será utilizada sempre o recredenciamento mais recente.

>Validade DD/MM/AAAA

Tabela 1 - Campos para o Cadastro de Instituição

Prioridade: X Essencial Importante Desejável

[RF10] Alterar Cadastro da Instituição

Atores: Módulo:

Será permitido ao usuário do sistema alterar dados incorretos ou que necessitem de modificação no cadastro da instituição. Os dados definidos na 9] poderão ser alterados, exceto os dados referentes ao Recredenciamento, que deverão ocorrer no 11].

(12)

[RF5] Excluir Instituição Ator:

Módulo:

O ... poderá excluir o acesso de qualquer instituição cadastrada no sistema a medida que isso seja necessário.

6.1.2

(13)

6.2Requisitos de Relatórios do Sistema

6.2.1 Relatórios

[RF209] Padrão para cabeçalho e rodapé

Os relatórios deverão ter um padrão de layout segundo o especificado abaixo. Para os relatórios que exigirem mais informações, deverá ser informado no seu requisito.

Cabeçalho Geral Data, hora e página

Nome do relatório

Descrição por Curso/Turma (curso e turma, somente curso)

Corpo do Relatório

Assinatura do Relatório (quando tiver) Rodapé

[RF210] Modelos de cabeçalhos

A maioria dos relatórios utilizarão o Modelo 1, onde o nome do setor deverá ser de acordo onde será impresso o relatório.

Cabeçalho geral Modelo 1

LOGO _{NOME DA EMPRESA}

Nome do setor. Ex.: Diretoria d....

O cabeçalho de Modelo 2 será usado no relatório de registro de diploma, onde conterá o Brasão do Estado

Cabeçalho geral Modelo 2

NOME DA EMPRESA

XXXXXXXXXXX XXXXXXXXXXX XXXXXXXXX

(14)

[RF212] Assinatura dos Relatórios

Os relatórios que precisam de assinatura deverão seguir as seguintes normas, de acordo onde o relatório for impresso:

XXXXXXXXX XXXXXXXXX

Os dados necessários para o campo de assinatura dos relatórios são:

Espaço para assinatura _______________________________ Nome Nome da pessoa que irá assinar o documento Cargo O gênero do cargo deverá ser respeitado de acordo

com o sexo da pessoa. Principalmente para assinatura do(a) reitor(a).

Poderão ser:

● CARGO ● CARGO 1 ● CARGO 2

Tabela 1 - Campos da Assinatura de Relatórios

O sistema deverá controlar apenas o titular do cargo de chefia em questão, não sendo necessário o controle de suplentes ou de vices.

Exemplo do campo de assinatura:

_______________________________________ Nononononon nonon nononn nononononon

CARGO

[RF214] Visão dos relatórios

Os relatórios do sistema estarão divididos dentro dos módulos cada um com sua visão.

Dentro do módulo XXXXXXX somente poderá acessar os XXXXXXXXXXX

6.2.2Relatórios Relacionados XXXXXX

[RF215] Relatório de XXXX Atores:

(15)

DESCRIÇÃO DO REQUISITO

Cabeçalho Geral Modelo 1 Nome do relatório =

Corpo do relatório Nome do

Exemplo: 3ª série

(se tiver habilitação, colocar no relatório, senão omite-se)

Assinatura do Relatório (De acordo com o chefe de onde foi emitido o relatório) Rodapé – Endereço da unidade onde foi emitido o relatório

Tabela 1 - Campos para o ...

Exemplo:

7.

(16)

8.

8. REQUISITOS NÃO FUNCIONAIS

REQUISITOS NÃO FUNCIONAIS

Esta seção contém os requisitos não funcionais do sistema. Para uma melhor organização deste documento, utilizamos as subseções abaixo para agrupar os requisitos não funcionais relacionados.

8.1Disponibilidade e Portabilidade

[RNF1] Disponibilidade do Sistema

O sistema deverá ser disponível ...

[RNF2] Disponibilidade do Sistema Para ....

O sistema deverá permitir o ... a partir de suas residências.

Prioridade: Essencial X Importante Desejável

[RNF3] Portabilidade

O sistema poderá ser acessado a partir de estações de trabalho que possuam sistemas operacionais GNU/Linux ou Microsoft Windows.

8.2Segurança e Confiabilidade

[RNF4] Criptografia

A comunicação entre o computador do usuário ... deverá ser cifrada para impedir que usuários mal intencionados venham a denegrir a integridade dos dados do sistema.

[RNF5] Backup

Deverá ser possível de...

[RNF6] Histórico de Ações

O sistema deverá armazenar ...

(17)

8.3Padronização e Conformidade

[RNF7] Padronização Internacional

Para os módulos do sistema desenvolvidos em formato WEB, utilizados por um navegador de Internet, deverão ser observados os seguintes padrões internacionais:

1. ISO-8859-1 – Padrão internacional de caracteres para a língua latina;

2. W3C – (World Wide Web Consortium) Padrões de desenvolvimento para a interoperabilidade de sistemas na Internet.

[RNF8] Formato de Datas

As datas do sistema deverão estar no formato DD/MM/AAAA. E em alguns casos específicos estarão no formato MM/AAAA.

[RNF9] Normas e Legislações

O sistema deverá estar de acordo com as normas da XXXXX, bem como de leis XXXXXX

8.4Acessibilidade e Usabilidade

[RNF10] Apreensibilidade

O sistema deverá ser de fácil utilização.

[RNF11] Inteligibilidade

O sistema deverá ser de fácil compreensão para o usuário. XXXXXXXXXXX

[RNF12] Operacionalidade

O sistema deverá permitir que o usuário controle os dados de forma segura e consistente. XXXXXXXXX

8.5Eficiência

[RNF13] Tempo de Resposta

O sistema deverá responder satisfatoriamente as demandas XXXXXXXXXXX

(18)

9.

9. ANEXOS

ANEXOS

(19)

Nome 1 EMPRESA DESENVOLVEDORA Nome 2 CONTRATANTE Testemunha 1 EMPRESA Testemunha 2 CONTRATANTE Documento de Requisitos