<Sigla do Projeto>

Especificação Suplementar

Histórico de Revisão

Data	Versão	Autor	Revisor	Observação
<dd/mm/aaaa>	<v.v>	<Descrição>

Índice

1.	Introdução	4

1.1	Escopo	4

1.2	Definições, Acrônimos e Abreviações	4

1.3	Referências	4

2.	Funcionalidade	4

2.1	<Requisito Funcional Um>	4

3.	Usabilidade	5

3.1	<Requisito de Usabilidade Um>	5

4.	Confiabilidade	5

4.1	<Requisito de Confiabilidade Um>	5

5.	Performance	5

5.1	<Requisito de Performance Um>	6

6.	Suportabilidade	6

6.1	<Requisito de Suportabilidade Um>	6

7.	Restrições de Design	6

7.1	<Restrição de Design Um>	6

8.	Requisitos da Documentação On-line do Usuário e do Sistema de Help	6

9.	Componentes Adquiridos	6

10.	Interfaces	6

10.1	Interfaces de Usuário	6

10.2	Interfaces de Hardware	6

10.3	Interfaces de Software	6

10.4	Interfaces de Comunicação	7

11.	Requisitos de Licenciamento	7

12.	Aspectos Legais, Direitos Autorais e Outros	7

13.	Padrões Aplicáveis	7

14.	Aprovação	7

Especificação Suplementar

Introdução

[A introdução da Especificação Suplementar fornece um overview de todo o documento. Isto inclui o objetivo, escopo, definições, acrônimos, abreviações, referências e overview da Especificação Suplementar.

A Especificação Suplementar captura os requisitos do sistema, que não foram prontamente capturados nos use-cases do modelo de use-cases. Tais requisitos incluem:

Requisitos legais e reguladores, incluindo padrões de aplicação.

Atributos de qualidade do sistema a ser construído, incluindo requisitos de usabilidade, confiabilidade, performance e suportabilidade.

Outros requisitos tais como de sistemas operacionais e ambientes, requisitos de compatibilidade e restrições de design.]

Escopo

[Uma breve descrição do escopo da Especificação Suplementar, a qual(ais) projeto(s) ela está associada, e qualquer outra coisa que seja afetada ou influenciada por este documento.]

Definições, Acrônimos e Abreviações

[Esta subseção fornece as definições de todos termos, acrônimos e abreviações requeridos para a apropriada interpretação da Especificação Suplementar. Estas informações podem ser fornecidas pela referência ao Glossário do projeto.]

Referências

[Esta subseção fornece uma lista completa de todos os documentos referenciados em qualquer ponto da Especificação Suplementar. Identifica cada documento por título, número do relatório, se aplicável, data e responsável pela publicação. Especifica as fontes nas quais as referências podem ser obtidas. Estas informações devem ser fornecidas como referência a um apêndice ou a outro documento.]

Funcionalidade

[Esta seção descreve os requisitos funcionais do sistema quando estes estiverem descritos em uma linguagem natural. Para muitas aplicações, esta seção constitui a maior parte do pacote de ERS e deve-se pensar em como será a organização desta seção. Esta seção é tipicamente organizada por características, mas métodos de organização alternativos podem ser apropriados, por exemplo, organização por usuário ou organização por subsistema. Requisitos funcionais podem incluir conjuntos de características, capacidades e segurança.

Quando existem ferramentas para auxiliar na identificação de funcionalidades – tais como ferramentas de requisitos, ferramentas de modelagem e afins – esta seção do documento deve se referir à disponibilidade dos dados, indicando a localização e o nome da ferramenta utilizada.]

<Requisito Funcional Um>

[Descrição negocial do requisito. Do que se trata, para que serve, a quem atende e a qual outro requisito está relacionado (como pré ou pós-condição).]

Usabilidade

[Esta seção inclui todos os requisitos que afetam a usabilidade da aplicação. Por exemplo:

Especificar o tempo de treinamento necessário para um usuário normal e um usuário com mais cultura de informática para tornarem-se produtivos, realizando operações particulares.

Especificar mensurações de tempos para tarefas típicas do sistema ou usar base das novas usabilidades dos requisitos do sistema, baseado em outros sistemas que o usuário conhece e gosta.

Especificar requisitos que utilizem padrões de usabilidade comuns, tais como padrões IBM’s CUA, padrões Microsoft GUI.]

<Requisito de Usabilidade Um>

[Descrição do requisito.]

Confiabilidade

[Requisitos de confiabilidade do sistema devem ser especificados nesta seção. Algumas sugestões estão a seguir:

Disponibilidade – especifica a porcentagem de tempo que o sistema fica disponível – no ar – (xx,xx%), horas de uso, acesso para manutenção, degradação dos módulos operacionais etc;

Tempo Médio Entre falhas (MTBF) – esta medida é usualmente feita em horas, mas pode também ser feita em dias, meses ou anos;

Tempo Médio para Reparos (MTTR) – quanto tempo é permitido que o sistema fique fora de operação após ocorrência de uma falha? ;

Exatidão – especifica precisão (resolução) e precisão (sobre padrões estabelecidos) sobre as saídas requisitadas para o sistema;

Ocorrência máxima de bugs ou taxa de defeitos – usualmente expresso em número de bugs por milhares de linhas de código (bugs/KLOC) ou bugs por pontos-função (bugs/pontos-função);

Bugs ou taxa de defeito – classificados em bugs menores, significantes e críticos; o(s) requisito(s) deve(m) definir o que significa um bug “crítico”, por exemplo, perda completa dos dados ou completa impossibilidade de utilização de determinada parte de uma funcionalidade do sistema.]

<Requisito de Confiabilidade Um>

[Descrição do requisito.]

Performance

[As características de performance do sistema devem ser citadas nessa seção. Inclua tempos específicos de resposta. Quando aplicável, referencie os Use-Cases relacionados por nome.

Tempo de resposta para uma transação (médio, máximo)

Throughput (por exemplo, transações por segundo)

Capacidade (por exemplo, o número de conexões cliente ou o número de transações que o sistema suporta)

Modalidades de degradação (qual é o modo de operação aceitável quando o sistema for degradado de alguma maneira)

Utilização de recursos: memória, disco, comunicação e assim por diante.]

<Requisito de Performance Um>

[Descrição do requisito.]

Suportabilidade

[Esta seção indica quaisquer requisitos que melhorarão a suportabilidade ou manutenção do sistema sendo desenvolvido, incluindo padrões de codificação, convenções de nomenclatura, bibliotecas de classes, facilidades de manutenção e utilitários de manutenção.]

<Requisito de Suportabilidade Um>

[Descrição do requisito.]

Restrições de Design

[Nessa seção é necessário que se indique quaisquer restrições de design do sistema que está sendo desenvolvido. As restrições de design representam decisões impostas e que devem também ser incorporadas. Exemplos: incluem linguagens de programação, requisitos de processos de software, ferramentas de desenvolvimento pré-definidas, bibliotecas de classes, entre outros.]

<Restrição de Design Um>

[Descrição da restrição.]

Requisitos da Documentação On-line do Usuário e do Sistema de Help

[Descreve os requisitos, se houver algum, para documentação on-line, sistema de help, considerações do help “Sobre”, help sensitivo ao contexto, entre outros.]

Componentes Adquiridos

[Esta seção descreve quaisquer componentes adquiridos para serem utilizados com o sistema, restrições de uso ou licenciamento e padrões associados à compatibilidade/interoperabilidade ou interface.]

Interfaces

[Esta seção define as interfaces que deverão ser suportadas pela aplicação. Deve conter uma especificação adequada, protocolos, portas e endereços lógicos, e assim por diante. De maneira que o software possa ser desenvolvido e verificado contra os requisitos de interface.]

Interfaces de Usuário

[Descreve as interfaces de usuário que serão implementadas pelo software.]

Interfaces de Hardware

[Esta seção define quaisquer interfaces de hardware que deverão ser suportadas pelo software, incluindo estrutura lógica, endereços físicos, comportamento esperado, e assim por diante.]

Interfaces de Software

[Esta seção descreve as interfaces do software com outros componentes do sistema. Estes podem ser componentes adquiridos, componentes reutilizados de outras aplicações ou componentes sendo construídos para subsistemas fora do escopo desta ERS, mas com os quais o sistema deverá interagir.]

Interfaces de Comunicação

[Descreve quaisquer interfaces de comunicação com outros sistemas ou dispositivos, tais como redes locais (LAN), dispositivos seriais remotos, e assim por diante.]

Requisitos de Licenciamento

[Define quaisquer requisitos impostos pelo licenciamento ou outros requisitos, quanto às restrições de utilização que devem ser incorporadas pelo software.]

Aspectos Legais, Direitos Autorais e Outros

[Descreve aspectos a serem considerados relativos a impedimentos legais, garantia, direitos autorais, patentes, wordmark, trademark ou questões de concessão de utilização de logomarca para o software.]

Padrões Aplicáveis

[Esta seção descreve por referência quaisquer padrões aplicáveis e as seções específicas de cada um desses padrões, que se aplicam ao sistema sendo descrito. Por exemplo, isso poderia incluir padrões legais, de qualidade e reguladores, padrões de indústria para usabilidade, interoperabilidade, internacionalização, aderência ao sistema operacional, e assim por diante.]

Aprovação

Estou ciente e de acordo com as informações passadas por mim para composição deste documento e com o conteúdo do mesmo. Neste momento o documento possui o status de Pré-homologado, devido a não haver, de minha parte, quaisquer observações a fazer. Também estou de acordo com o encaminhamento deste documento para avaliação técnica da equipe de Análise e Projeto da Basis. Caso esta equipe não tenha qualquer tipo de observação ao que consta no documento, o mesmo passará a ter status de Homologado e, qualquer mudança a partir deste momento será tratada como Solicitação de Alteração, tendo que passar pelo trâmite definido, em acordo feito entre CLIENTE e Basis. Caso a equipe de Análise e Projeto da Basis, tenha alguma observação a fazer, este documento irá retornar, para que seja de meu conhecimento e aceite quaisquer tipos de alterações. Contudo, é possível que os protótipos de telas, justamente por serem protótipos, sofram melhorias quando efetivamente implementadas. Estas melhorias têm por objetivo garantir maior facilidade e simplicidade de operação do sistema. A partir disto o documento terá sua "Homologação".

Concordo que, após implementação e testes do caso de uso pela Basis, serei responsável pela homologação final do produto gerado. Esta homologação é composta pela utilização dos programas entregues ao CLIENTE, verificando se suas funções estão de acordo com o que foi solicitado por mim. Esta atividade de homologação não pode ser transferida para pessoas que não participaram do detalhamento e pré-homologação do caso de uso.

O CLIENTE e a Basis comprometem-se a avisar com antecedência mínima de três (3) dias quando será a homologação final do caso de uso implementado.

Brasília, <dia> de <mês> de <ano>.

<Nome Completo>

<Função - Setor>

<Nome Completo>