<Nome do Projeto>

Especificação Suplementar

 

Versão <1.0>

 

[Observação: O template a seguir é fornecido para uso com o Rational Unified Process (RUP). O texto entre colchetes e exibido em itálico, em azul (estilo=InfoBlue), é fornecido para orientar o autor e deverá ser excluído antes da publicação do documento. Qualquer parágrafo inserido após esse estilo será definido automaticamente como normal (estilo=BodyText).]

 

 

 


Histórico da Revisão

Data

Versão

Descrição

Autor

<dd/mmm/aa>

<x.x>

<detalhes>

<nome>

 

 

 

 

 

 

 

 

 

 

 

 

 


Índice Analítico

1.       Introdução         

1.1     Finalidade     

1.2     Escopo     

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

1.4     Referências     

1.5     Visão Geral     

2.       Funcionalidade     

2.1     <Requisito Funcional Um>     

3.       Usabilidade

3.1     <Requisito de Usabilidade Um>     

4.       Confiabilidade

4.1     <Requisito de Confiabilidade Um>     

5.       Desempenho       

5.1     <Requisito de Desempenho Um>     

6.       Suportabilidade    

6.1     <Requisito de Suportabilidade Um>     

7.       Restrições de Design   

7.1     <Restrição de Design Um>     

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

9.       Componentes Comprados 

10.            Interfaces               

10.1     Interfaces de Usuário     

10.2     Interfaces de Hardware     

10.3     Interfaces de Software     

10.4     Interfaces de Comunicações     

11.            Requisitos de Licenciamento               

12.            Observações Legais, de Direitos Autorais etc               

13.            Padrões Aplicáveis               


Especificação Suplementar

1.                  Introdução

[A introdução da Especificação Suplementar deve fornecer uma visão geral de todo o documento. Ela deve incluir a finalidade, 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 de sistema que não são capturados imediatamente nos casos de uso do modelo de casos de uso. Entre os requisitos estão incluídos:

·         Requisitos legais e reguladores, incluindo padrões de aplicativo.

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

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

1.1               Finalidade

[Especifique a finalidade desta Especificação Suplementar.]

1.2               Escopo

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

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

[Esta subseção deve fornecer as definições de todos os termos, acrônimos e abreviações necessárias à adequada interpretação da Especificação Suplementar.  Essas informações podem ser fornecidas mediante referência ao Glossário do projeto.]

1.4               Referências

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

1.5               Visão Geral

[Esta subseção deve descrever o que o restante da Especificação Suplementar contém e deve explicar como o documento está organizado.]

2.                  Funcionalidade

[Esta seção descreve os requisitos funcionais do sistema que são expressos no estilo de linguagem natural. Para muitos aplicativos, isso poderá constituir o volume do Pacote SRS e deve-se refletir muito para organizar esta seção. Normalmente, ela é organizada por recurso, mas métodos de organização alternativos como, por exemplo, organização por usuário ou organização por subsistema, também podem ser apropriados.  Entre os requisitos funcionais podem estar incluídos conjuntos de recursos, capacidades e segurança.

Quando as ferramentas de desenvolvimento de aplicativos, como ferramentas de requisitos, ferramentas de modelagem, entre outras, forem utilizadas para capturar a funcionalidade, esta seção fará referência à disponibilidade desses dados, indicando o local e o nome da ferramenta usada para capturar os dados.]

2.1               <Requisito Funcional Um>

[A descrição do requisito deve ser feita aqui.]

3.                  Usabilidade

[Esta seção deve incluir todos os requisitos que afetam a usabilidade. Estes são alguns exemplos:

·         especifique o tempo de treinamento necessário para que usuários normais e usuários com conhecimentos avançados se tornem produtivos em operações específicas

·         especifique períodos de tempo mensuráveis para tarefas típicas ou

·         especifique requisitos que estejam em conformidade com os padrões comuns de usabilidade como, por exemplo, os padrões CUA da IBM ou os padrões GUI da Microsoft]

3.1               <Requisito de Usabilidade Um>

A descrição do requisito.

4.                  Confiabilidade

[Os requisitos de confiabilidade do sistema devem ser especificados aqui. Abaixo, algumas sugestões:

·         Disponibilidade - especifique a porcentagem de tempo disponível ( xx.xx%), as horas de uso, o acesso à manutenção, as operações de modo degradado etc.

·         Tempo Médio entre Falhas (MTBF) - normalmente especificado em horas, mas também poderá ser especificado em termos de dias, meses ou anos.

·         Tempo Médio para Reparo (MTTR) - quanto tempo o sistema poderá ficar sem funcionar após uma falha?

·          Exatidão - especifique a precisão (resolução) e exatidão (através de algum padrão conhecido) necessárias na saída dos sistemas.

·         Taxa máxima de erros ou defeitos - geralmente expressa em termos de erros/KLOC (thousands of lines of code, milhares de linhas de código) ou de erros/ponto de função.

·         Taxa de erros ou defeitos - categorizados em termos de erros pouco importantes, importantes e críticos: o(s) requisito(s) devem definir o que se entende por um erro "crítico" (ex: perda total de dados ou total incapacidade de usar determinadas partes da funcionalidade do sistema).]

4.1               <Requisito de Confiabilidade Um>

[A descrição do requisito deve ser feita aqui.]

5.                  Desempenho

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

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

·         Taxa de transferência (ex: transações por segundo)

·         Capacidade (ex: o número de clientes ou de transações que podem ser acomodados pelo sistema)

·         Modos de degradação (o modo aceitável de operação quando o sistema tiver sido degradado de alguma maneira)

·         Utilização de recursos: memória, disco, comunicações etc.]

5.1               <Requisito de Desempenho Um>

[A descrição do requisito deve ser feita aqui.]

6.                  Suportabilidade

[Esta seção indica todos os requisitos que aprimorarão a suportabilidade ou manutenibilidade do sistema que está sendo criado, incluindo padrões de codificação, convenções de nomeação, bibliotecas de classes, acesso à manutenção e utilitários de manutenção.]

6.1               <Requisito de Suportabilidade Um>

[A descrição do requisito deve ser feita aqui.]

7.                  Restrições de Design

[Esta seção deve indicar todas as restrições de design referentes ao sistema que está sendo criado. As restrições de design representam decisões de design que foram impostas e devem ser obedecidas.  Entre os exemplos desse tipo de restrição estão linguagens de software, requisitos de processo de software, uso prescrito de ferramentas de desenvolvimento, restrições de design e de arquitetura, componentes comprados, bibliotecas de classes etc.]

7.1               <Restrição de Design Um>

[A descrição do requisito deve ser feita aqui.]

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

[Descreva os requisitos, se houver, de documentação de usuário on-line, sistemas de ajuda, observações sobre ajuda etc.]

9.                  Componentes Comprados

[Esta seção descreve todos os documentos comprados a serem usados no sistema, quaisquer restrições de utilização ou de licenciamento aplicáveis e quaisquer padrões associados de compatibilidade/interoperabilidade ou de interface.]

10.             Interfaces

[Esta seção define as interfaces que devem ser suportadas pelo aplicativo. Ela deve conter especificidades, protocolos, portas e endereços lógicos adequados, entre outros, para que o software possa ser desenvolvido e verificado em relação aos requisitos de interface.]

10.1            Interfaces de Usuário

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

10.2            Interfaces de Hardware

[Esta seção define todas as interfaces de hardware que devem ser suportadas pelo software, incluindo a estrutura lógica, os endereços físicos, o comportamento esperado etc. ]

10.3            Interfaces de Software

[Esta seção descreve as interfaces de software com outros componentes do sistema de software. Poderão 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 esse aplicativo de software deve interagir.]

10.4            Interfaces de Comunicações

[Descreva todas as interfaces de comunicações com outros sistemas ou dispositivos como, por exemplo, redes locais, dispositivos seriais remotos etc.]

11.             Requisitos de Licenciamento

[Esta seção define todos os requisitos de imposição de licenciamento ou outros requisitos de restrição de utilização que devem ser exibidos pelo software.]

12.             Observações Legais, de Direitos Autorais etc

[Esta seção descreve todos os avisos legais necessários, garantias, observações sobre direitos autorais, observações sobre patentes, logomarcas, marcas comerciais ou problemas de conformidade com logotipos referentes ao software.]

13.             Padrões Aplicáveis

[Esta seção descreve, por meio de referências, todos os padrões aplicáveis e as seções específicas desses padrões que se aplicam ao sistema que está sendo descrito. Entre esses padrões estão incluídos, por exemplo, padrões reguladores, de qualidade e legais, padrões de indústria referentes à usabilidade, interoperabilidade, internacionalização, compatibilidade com o sistema operacional etc.]