<Nome do Projeto>

Especificação Complementar

Versão <1.0>

[Nota: O gabarito a seguir é fornecido para utilização com o Rational Unified Process. O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Um parágrafo digitado após esse estilo será automaticamente definido como normal (style=Body Text).]

[Para personalizar campos automáticos no Microsoft Word (que exibem um segundo plano cinza quando selecionados), selecione File>Properties e substitua os campos Title, Subject e Company pelas informações apropriadas para este documento. Depois de fechar o diálogo, os campos automáticos podem ser atualizados no documento inteiro, selecionando Edit>Select All (ou Ctrl-A) e pressionando F9 ou simplesmente clique no campo e pressione F9. Esse procedimento deverá ser executado separadamente para os Cabeçalhos e Rodapés. Alt-F9 alterna entre a exibição de nomes de campos e do conteúdo dos campos. Consulte a Ajuda do Word para obter informações adicionais sobre como trabalhar com campos.]

Histórico da Revisão

Data	Versão	Descrição	Autor
<dd/mmm/aa>	<x.x>	<detalhes>	<nome>

Índice

1.	Introdução	4

1.1	Objetivo	4

1.2	Escopo	4

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

1.4	Referências	4

1.5	Visão Geral	4

2.	Funcionalidade	4

2.1	<Requisito Funcional Um>	5

3.	Utilidade	5

3.1	<Requisito de Utilidade Um>	5

4.	Confiabilidade	5

4.1	<Requisito de Confiabilidade Um>	5

5.	Desempenho	5

5.1	<Requisito de Desempenho 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.	Documentação do Usuário On-line e Requisitos do Sistema de Ajuda	6

9.	Componentes Comprados	6

10.	Interfaces	6

10.1	Interfaces com o Usuário	6

10.2	Interfaces de Hardware	6

10.3	Interfaces de Software	6

10.4	Interfaces de Comunicações	7

11.	Requisitos de Licença	7

12.	Observações Legais, sobre Direitos Autorais e Outras Observações	7

13.	Padrões Aplicáveis	7

Especificação Complementar

Introdução

[A introdução da Especificação Suplementar fornece uma visão geral de todo o documento. Ela inclui o objetivo, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral desta Especificação Suplementar.

A Especificação Suplementar captura os requisitos do sistema que não são prontamente capturados nos casos de uso do modelo de caso de uso. Entre os requisitos estão incluídos:

Requisitos legais e de regulamentação, incluindo padrões de aplicativos.

Atributos de qualidade do sistema a ser criado, incluindo requisitos de utilidade, confiabilidade, desempenho e suportabilidade.

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

Objetivo

[Especifique o objetivo desta Especificação Suplementar.]

Escopo

[Uma breve descrição do escopo desta Especificação Suplementar; a qual(is) Projeto(s) ele está associado e tudo mais que seja afetado ou influenciado por este documento.]

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

[Esta subseção fornece as definições de todos os termos, acrônimos e abreviações requeridos para interpretar adequadamente a Especificação Suplementar. Essas informações podem ser fornecidas em relação ao Glossário do projeto.]

Referências

[Esta subseção fornece uma lista completa de todos os documentos mencionados em outra parte na Especificação Suplementar. Identifique cada documento por título, número do relatório se aplicável, data e organização da publicação. Especifique as origens a partir das quais as referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro documento.]

Visão Geral

[Esta subseção descreve o que o restante da Especificação Suplementar contém e explica como o documento é organizado.]

Funcionalidade

[Esta seção descreve os requisitos funcionais do sistema para os requisitos que são expressos no estilo do idioma nativo. Para muitos aplicativos, isso pode constituir o bulk do Pacote SRS e um conceito deve ser fornecido à organização desta seção. Esta seção é, geralmente, organizada por recurso, mas métodos de organização alternativos, por exemplo, organização por usuário ou organização por subsistema, também podem ser apropriados. Requisitos funcionais podem incluir conjuntos, recursos e segurança do recurso.

Onde as ferramentas de desenvolvimento de aplicativo, como ferramentas de requisitos, ferramentas de modelagem e assim por diante, são empregadas para capturar a funcionalidade, esta seção do documento fará referência à disponibilidade desses dados, indicando o local e o nome da ferramenta utilizada para capturar os dados.]

<Requisito Funcional Um>

[A descrição do requisito.]

Utilidade

[Esta seção deve incluir todos os requisitos que afetam a utilidade. Como exemplos, podemos citar o seguinte:

especifique o tempo de treinamento requerido para que usuários normais e usuários potentes se tornem produtivos em operações particulares

especifique tempos de tarefa mensuráveis para tarefas típicas ou

especifique requisitos para conformidade com padrões de utilidade comuns, por exemplo, padrões CUA da IBM ou Padrões GUI da Microsoft]

<Requisito de Utilidade Um>

A descrição do requisito.

Confiabilidade

[Os requisitos de confiabilidade do sistema devem ser especificados aqui. A seguir, são apresentadas algumas sugestões:

Disponibilidade – especifique a porcentagem de tempo disponível ( xx.xx%), as horas de utilização, o acesso de manutenção, as operações de modo degradado e similares.

MTBF (Mean Time Between Failures) – este é, geralmente, especificado em horas, mas pode também ser especificado em dias, meses ou anos.

MTTR (Mean Time To Repair)–por quanto tempo o sistema tem permissão para ficar fora de operação após ter falhado?

Exatidão –especifique a precisão (resolução) e a exatidão (por algum padrão conhecido) requeridas na saída dos sistemas.

Taxa máxima de erros ou defeitos –geralmente expressa em termos de erros/KLOC (mil linhas de código) ou erros/ponto de função.

Taxa de erros ou defeitos –categorizada em termos de erros menores, significativos e críticos: o(s) requisito(s) deve(m) definir o que quer dizer um erro “crítico”; por exemplo, perda completa de dados ou uma inabilidade completa para utilizar determinadas partes da funcionalidade do sistema.]

<Requisito de Confiabilidade Um>

[A descrição do requisito.]

Desempenho

[As características do desempenho do sistema devem ser esboçadas nesta seção. Inclua tempos de resposta específicos. Onde aplicável, faça referência a Casos de Uso relacionados por nome.

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

Rendimento do processamento (por exemplo, transações por segundo)

Capacidade (por exemplo, o número de clientes ou transações que o sistema pode acomodar)

Modos de degradação (que é o modo aceitável de operação quando o sistema foi degradado de alguma maneira)

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

<Requisito de Desempenho Um>

[A descrição do requisito.]

Suportabilidade

[Esta seção indica os requisitos que aprimorarão a suportabilidade ou a capacidade de manutenção do sistema que está sendo construído, incluindo padrões de codificação, convenções de nomenclatura, bibliotecas de classe, acesso de manutenção, utilitários de manutenção.]

<Requisito de Suportabilidade Um>

[A descrição do requisito.]

Restrições de Design

[Esta seção deve indicar as restrições de design no sistema que está sendo construído. As restrições de design representam decisões de design que foram obrigatórias e às quais deve-se aderir. Os exemplos incluem linguagens de software, requisitos de processo de software, utilização prescrita de ferramentas de desenvolvimento, restrições de arquitetura e design, componentes comprados, bibliotecas de classes e assim por diante.]

<Restrição de Design Um>

[A descrição do requisito.]

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

[Descreve os requisitos, se houver, para a documentação do usuário on-line, sistemas de ajuda, ajuda sobre observações e assim por diante.]

Componentes Comprados

[Esta seção descreve os componentes comprados a serem utilizados com o sistema, as restrições aplicáveis de licença ou uso e os padrões associados de compatibilidade/interoperabilidade ou interface.]

Interfaces

[Esta seção define as interfaces que devem ser suportadas pelo aplicativo. Ela deve conter especificidade adequada, protocolos, portas, endereços lógicos e assim por diante, para que o software possa ser desenvolvido e verificado em comparação com os requisitos da interface.]

Interfaces com o Usuário

[Descreva as interfaces com o usuário que devem ser implementadas pelo software.]

Interfaces de Hardware

[Esta seção define as interfaces de hardware que devem 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 de software para outros componentes do sistema de software. Estas podem ser componentes comprados, componentes reutilizados de outro aplicativo ou componentes que estão sendo desenvolvidos para subsistemas fora do escopo desta SRS, mas com os quais este aplicativo de software deve interagir.]

Interfaces de Comunicações

[Descreva as interfaces de comunicações para outros sistemas ou dispositivos como redes locais, dispositivos seriais remotos e assim por diante.]

Requisitos de Licença

[Define os requisitos de reforço de licença ou outros requisitos de restrição de uso que devem ser exibidos pelo software.]

Observações Legais, sobre Direitos Autorais e Outras Observações

[Esta seção descreve as isenções legais necessárias, garantias, observações sobre direitos autorais, observações sobre patente, wordmark, marca registrada ou problemas de conformidade de logotipo para o software.]

Padrões Aplicáveis

[Esta seção descreve, por referência, os padrões aplicáveis e as seções específicas desses padrões que se aplicam ao sistema que está sendo descrito. Por exemplo, isso pode incluir padrões jurídicos, de qualidade e reguladores, padrões de mercado para utilidade, interoperabilidade, internacionalização, conformidade com o sistema operacional e assim por diante.]

<Nome da Empresa>

<Nome do Projeto>	Versão: <1.0>
Especificação Complementar	Data: <dd/mmm/aa>
<identificador do documento>

Confidencial	(<Nome da Empresa>, 2006	Página 7

Especificação Complementar

<Nome do Projeto>

Luis Tadeu Castilho

2005-11-10

Rational

<Company Name>