Modelo para Especificação dos Requisitos do Software

Referências:

IEEE Std. 830 – 1993. IEEE Recommended Practice for Software Requirements Specifications.

Filho, W.P.P. Engenharia de Software: Fundamentos, Métodos e Padrões. LTC: Rio de Janeiro, 2001.

Informações da Capa

Nome do Documento: Rastreador de Representantes via mobileIdentificação do projeto para o qual a documentação foi produzida:

Trabalho de Conclusão de Curso

Nome dos autores e das organizações que produziram o documento:

Túlio Gustavo dos Santos

Número da revisão do documento: 1Data da aprovação:Assinatura de aprovação:Lista dos números de revisões e datas de aprovação das revisões anteriores:

1 Introdução

1.1 Objetivos do documentoDescreve-se aqui o propósito da ER, especificando o público deste documento.Visa registrar os pontos do projeto, de forma que viabilize sua compreensão como um

todo e facilite possíveis manutenções ou implementação de novos recursos.

1.2 Escopo do produtoDescreve-se aqui uma primeira visão sintética do escopo do produto especificado.O sistema deverá cadastrar seus funcionários externos, tanto no aparelho celular do

funcionário, como no sistema interno da empresa. Esses aparelhos celulares enviaram suas posições globais localizadas via GPS ao sistema da alocado na empresa.

Quando a empresa recebe uma ligação de um cliente, solicitando que haja uma visita em seu estabelecimento, a atendente irá acessar o sistema, e este por sua vez irá informar qual o representante externo mais próximo e disponível para atender a solicitação, e o indicará a atendente, informando sua distância em relação ao cliente.

A atendente entrará em contato com o representante, pedindo que confirme a possibilidade de realizar a visita. Caso o representante aceite realizar a visita, o sistema irá enviar a posição (latitude e longitude) do cliente para o GPS do representante, e irá alterar automaticamente o status do representante para “em percurso”.

Após chegar ao cliente, o representante deverá informar ao sistema, clicando em “check-in”. Ao encerrar o serviço (ou visita), o representante deverá fazer um “check-out”, informando ao sistema que o chamado foi finalizado, e tornando-se novamente disponível para receber novas solitações.

1.3 Materiais de referênciaDescreve-se que a informação necessária para que todas as fontes de dados citadas na

ER possam ser recuperadas, caso necessário.

1.4 Definições e siglasDescreve-se aqui a definição de todas as siglas, abreviações e termos usados na ER.

1.5 Visão geral deste documentoDescreve-se aqui o que o restante da ER contém, indicando sua estrutura básica.

2 Descrição geral do produto

2.1 Perspectiva do produto

2.1.1 Diagrama de contextoInclui-se aqui um diagrama de contexto, onde deve ser mostrada a interface do produto

com o seu ambiente de aplicação, inclusive os diversos tipos de usuários e outros sistemas do cliente com os quais o produto deve interagir.

2.1.2 Interfaces de usuárioIdentificam-se aqui as interfaces do produto com os seus usuários humanos. Para cada

interface, detalhar o respectivo nome, caso de uso, ator e uma descrição sucinta do seu objetivo.

2.1.3 Interfaces de hardwareIdentificam-se aqui as características de hardware do sistema maior que sejam

relevantes do ponto de vista da especificação do software, tais como dispositivos especiais.

2.1.4 Interfaces de softwareIdentificam-se aqui as interfaces com outros produtos de software, tais como

aplicativos que recebem dados do produto ou enviam dados para ele, sejam on-line, através de arquivos ou através de bancos de dados.

2.1.5 Interfaces de comunicaçãoIdentificam-se aqui as características das redes de comunicação, tais como protolocos e

padrões, que exijam tratamento especial por parte desse produto.

2.1.6 Restrições de memóriaIdentificam-se aqui os limites requeridos de memória primária e secundária. Esses

limites só devem ser especificados quando isso for um requisito a ser exigido para a aceitação do produto.

2.1.7 Modos de operaçãoIdentificam-se aqui os modos requeridos de operação, tais como: interativa, em lote,

automática, realização de funções de suporte, realização de funções de backup e recuperação.

2.1.8 Requisitos de adaptação ao ambienteDefinem-se aqui possíveis requisitos de adaptação do produto aos ambientes

particulares onde ele será implantado. Por exemplo, parâmetros e métodos de configuração requeridos para ambientes específicos devem ser descritos aqui.

Número de ordem

Requisito Detalhes

1 Configuração da impressão do ticket de venda e da Nota Fiscal

Dimensões dos relatórios deverão ser configuráveis.

2.2 Funções do produtoIdentificam-se aqui as principais funções que o produto desempenhará, descrevendo de

forma sintética o objetivo de cada uma.

2.3 Características dos usuáriosDescrevem-se aqui as principais características dos grupos de usuários esperados para o

produto, tais como cargo ou função, permissão de acesso, freqüência de uso, nível de instrução, proficiência no processo de negócio e proficiência em informática.

2.4 RestriçõesDescrevem-se aqui aspectos técnicos e gerenciais que possam limitar as opções dos

desenvolvedores, tais como restrições legais.

2.5 Hipóteses de trabalhoDescrevem-se aqui fatores que não são restrições limitativas do desempenho, como na

subseção anterior, mas fatores cuja alteração requer modificações na ER, como, por exemplo, versão a ser utilizada do ambiente operacional ou plataforma de desenvolvimento.

2.6 Requisitos adiadosDescrevem-se aqui os requisitos que foram identificados durante a elaboração dessa

especificação, mas cujo atendimento se decidiu deixar para versões futuras.

3 Requisitos específicos

3.1 Interfaces externas

3.1.1 Visão geralDescreve-se aqui, de forma detalhada, todas as entradas e saídas do produto.

3.1.2 Requisitos para interfaces gráficas de usuárioSugere-se, no caso de interfaces gráficas, a inclusão dos seguintes elementos:

o Um esboço do leiaute gráfico sugerido para a interface;o Uma descrição dos relacionamentos com outras interfaces;o Um diagrama de estados, caso necessário para melhor entender-se o

comportamento requerido da interface;o Uma lista dos campos de dados da interface;o Uma lista dos comandos da interface;o Observações.

3.2 Requisitos funcionais

3.2.1 Diagramas de casos de usoIncluir todos os casos de uso que se pretende implementar em uma liberação. Pode-se

incluir ainda: um certo caso de uso e seus relacionamentos, todos os casos de uso para um certo ator.

3.2.2 Fluxos dos casos de usoo Pré-condições para a realização do caso de uso;o Fluxo principal do caso de uso, descrito na forma de uma seqüência de passos;o Fluxos alternativos do caso de uso;o Descrições mais formais, como diagramas de estado ou de atividade, se a

complexidade do caso de uso exigir;o Observações.

3.3 Requisitos não-funcionais

3.3.1 Requisitos de desempenhoRequisitos de desempenho devem ser especificados de forma quantitativa e mensurável.

3.3.2 Requisitos de dados persistentesDescrevem-se aqui estruturas lógicas de dados persistentes (que mantém seu valor após

a execução do programa) que sejam usadas pelo produto. Cada estrutura de dados pode ser, por exemplo, um arquivo convencional ou uma tabela em um banco de dados.

3.3.3 Restrições ao desenhoRestrições de projeto impostas por padrões externos, como o leiaute da nota fiscal, que

é imposto pela Secretaria de Receita.

3.3.4 Atributos de QualidadeIndica os atributos de qualidade, seguindo as características e subcaracterísticas

recomendadas pela norma ISO-9126.

4 Informações de suporte A ER deve incluir informações de suporte adequadas, tais como índices e apêndices.