<Nome do Projeto>

Especificação de Requisitos de Software

Para <Subsistema ou Recurso>

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.	Descrição Geral	4

3.	Requisitos Específicos	5

3.1	Funcionalidade	5

3.1.1	<Requisito Funcional Um>	5

3.2	Utilidade	5

3.2.1	<Requisito de Utilidade Um>	6

3.3	Confiabilidade	6

3.3.1	<Requisito de Confiabilidade Um>	6

3.4	Desempenho	6

3.4.1	<Requisito de Desempenho Um>	6

3.5	Suportabilidade	7

3.5.1	<Requisito de Suportabilidade Um>	7

3.6	Restrições de Design	7

3.6.1	<Restrição de Design Um>	7

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

3.8	Componentes Comprados	7

3.9	Interfaces	7

3.9.1	Interfaces com o Usuário	7

3.9.2	Interfaces de Hardware	7

3.9.3	Interfaces de Software	7

3.9.4	Interfaces de Comunicações	8

3.10	Requisitos de Licença	8

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

3.12	Padrões Aplicáveis	8

4.	Informações de Suporte	8

Especificação de Requisitos de Software

Introdução

[A introdução da SRS (Especificação de Requisitos de Software) fornece uma visão geral de toda a SRS. Ela inclui o objetivo, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral da SRS.]

[Nota: O documento SRS captura os requisitos de software completos para o sistema ou uma parte dele. A seguir, é apresentado um esboço de SRS típico para um projeto utilizando apenas requisitos tradicionais, de estilo de idioma nativo—sem modelo de caso de uso. Ele captura todos os requisitos em um único documento, com seções aplicáveis inseridas das Especificações Suplementares (que podem não ser mais necessárias). Para obter um gabarito de um SRS utilizando modelo de caso de uso, que consiste em um pacote contendo Casos de Uso do modelo de caso de uso e Especificações Suplementares aplicáveis e outras informações de suporte, consulte rup_srsuc.dot.]

[Muitas disposições diferentes de um SRS são possíveis. Consulte [IEEE830-1998] para uma elaboração adicional dessas explicações e também outras opções para a organização de SRS.]

Objetivo

[Especifique o objetivo desta SRS. A SRS descreve completamente o comportamento externo do aplicativo ou subsistema identificado. Descreve também requisitos não funcionais, restrições de design e outros fatores necessários para fornecer uma descrição completa e abrangente dos requisitos para o software.]

Escopo

[Uma breve descrição do aplicativo de software a que a SRS se aplica, o recurso ou outro agrupamento de subsistemas, a qual(is) modelo(s) de Caso de Uso 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 SRS. 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 SRS. 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 SRS contém e explica como o documento é organizado.]

Descrição Geral

[Esta seção da SRS descreve os fatores gerais que afetam o produto e seus requisitos. Esta seção não determina requisitos específicos. Em vez disso, ela fornece um segundo plano para esses requisitos, que são definidos em detalhes na Seção 3, e facilita o seu entendimento. Inclui itens como:

•	perspectiva do produto

•	funções do produto

•	características do usuário

•	restrições

•	premissas e dependências

•	subconjuntos de requisitos]

Requisitos Específicos

[Esta seção da SRS contém todos os requisitos de software para um nível de detalhe suficiente para permitir que os designers projetem um sistema para satisfazer esses requisitos e que os testadores testem se o sistema satisfaz esses requisitos. Ao utilizar o modelo de caso de uso, esses requisitos são capturados nos Casos de Uso e nas especificações suplementares aplicáveis. Se o modelo de caso de uso não for utilizado, o esboço para especificações suplementares poderá ser inserido diretamente nesta seção, conforme mostrado abaixo.]

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 também podem ser apropriados; por exemplo, organização por usuário ou organização por subsistema. 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 similares, são empregadas para capturar a funcionalidade, esta seção do documento pode se referir à 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 inclui todos os requisitos que afetam a utilidade. Por exemplo,

especifique o tempo de treinamento requerido para um usuário normal e um usuário potente para que se torne produtivo em operações particulares

especifique tempos de tarefa mensuráveis para tarefas típicas ou baseie os novos requisitos de utilidade do sistema em outros sistemas que os usuários conheçam e gostem

especifique requisito para conformidade com padrões de utilidade comuns, como padrões GUI da Microsoft padrões CUA da IBM]

<Requisito de Utilidade Um>

[A descrição do requisito aparece aqui.]

Confiabilidade

[Os requisitos de confiabilidade do sistema devem ser especificados aqui. Algumas sugestões são:

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 assim por diante.

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—especifica a precisão (resolução) e a exatidão (por algum padrão conhecido) requeridas na saída do sistema.

Taxa Máxima de Erros ou Defeitos—geralmente expressa em termos de erros por mil linhas de código (erros/KLOC) ou erros por ponto de função (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 de desempenho do sistema são 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, como memória, disco, comunicações e assim por diante.

<Requisito de Desempenho Um>

[A descrição do requisito aparece aqui.]

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 e utilitários de manutenção.]

<Requisito de Suportabilidade Um>

[A descrição do requisito aparece aqui.]

Restrições de Design

[Esta seção indica 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 aparece aqui.]

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 similares 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. Estes 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, o padrão aplicável 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.]

Informações de Suporte

[As informações de suporte facilitam a utilização da SRS. Elas incluem:

Índice

Índice

Apêndices

Estes podem incluir storyboards de caso de uso ou protótipos de interface com o usuário. Quando os apêndices são incluídos, a SRS deve determinar explicitamente se os apêndices devem ou não ser considerados parte dos requisitos.]

<Nome da Empresa>

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

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

Especificação de Requisitos de Software

<Nome do Projeto>

Luis Tadeu Castilho

2005-11-10

Rational

<Company Name>