• Nenhum resultado encontrado

<Nome da Empresa> <Nome do Projeto> Especificação de Requisitos de Software Para <Subsistema ou Recurso>

N/A
N/A
Protected

Academic year: 2022

Share "<Nome da Empresa> <Nome do Projeto> Especificação de Requisitos de Software Para <Subsistema ou Recurso>"

Copied!
1
0
0

Texto

(1)

<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.]

(2)

Histórico da Revisão

Data Versão Descrição Autor

<dd/mmm/aa> <x.x> <detalhes> <nome>

(3)

Í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

2.1 Relatório Sintético de Modelo de Casos de Uso 5

2.2 Premissas e Dependências 5

3. Requisitos Específicos 5

3.1 Relatórios de Caso de Uso 5

3.2 Requisitos Suplementares 5

4. Informações de Suporte 5

(4)

Especificação de Requisitos de Software

1. Introdução

[A introdução da SRS (Especificação de Requisitos de Software) 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 da SRS.]

[Nota: A SRS captura os requisitos de software completos para o sistema ou uma parte do sistema. A seguir, é apresentado um esboço de SRS típico para um projeto utilizando o modelo de caso de uso. Este artefato consiste em um pacote contendo casos de uso do modelo de caso de uso e das Especificações Suplementares aplicáveis e outras informações de suporte. Para obter um gabarito de uma SRS não utilizando o modelo de caso de uso, que 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), consulte o arquivo intitulado rup_srs.dot.]

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

1.1 Objetivo

[Especifique o objetivo desta Especificação de Requisitos de Software. 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.]

1.2 Escopo

[Uma breve descrição do aplicativo de software a que a Especificação de Requisitos de Software 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.]

1.3 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 de Requisitos de Software. Essas informações podem ser fornecidas em relação ao Glossário do projeto.]

1.4 Referências

[Esta subseção fornece uma lista completa de todos os documentos mencionados em outra parte na Especificação de Requisitos de Software. Identifique cada documento pelo seguinte: título, número do relatório (se for o caso), data e organização responsável pela 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.]

1.5 Visão Geral

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

2. Descrição Geral

[Esta seção da Especificação de Requisitos de Software descreve os fatores gerais que afetam o produto

(5)

2.1 Relatório Sintético de Modelo de Casos de Uso

[Se estiver utilizando o modelo de caso de uso, esta seção conterá uma visão geral do modelo de caso de uso ou do subconjunto do modelo de caso de uso que é aplicável a esse subsistema ou recurso. Isso inclui uma lista de nomes e descrições breves de todos os casos de uso e agentes, juntamente com diagramas e relacionamentos aplicáveis. Consulte o Relatório Sintético de Modelo de Casos de Uso, que pode ser utilizado como um anexo neste ponto.]

2.2 Premissas e Dependências

[Esta seção descreve qualquer possibilidade técnica chave, disponibilidade de subsistema ou componente ou outras premissas relacionadas ao projeto nas quais a viabilidade do software descrito por esta Especificação de Requisitos de Software pode ser baseada.]

3. Requisitos Específicos

[Esta seção da Especificação de Requisitos de Software contém todos os requisitos de software em um nível de detalhes suficiente para permitir que os designers projetem um sistema que satisfaça 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.]

3.1 Relatórios de Caso de Uso

[No modelo de caso de uso, os casos de uso freqüentemente definem a maioria dos requisitos funcionais do sistema, juntamente com alguns requisitos não funcionais. Para cada caso de uso no modelo de caso de uso acima, ou seu subconjunto, consulte, ou coloque, o relatório de caso de uso nesta seção.

Certifique-se de que cada requisito esteja claramente etiquetado.]

3.2 Requisitos Suplementares

[As Especificações Suplementares capturam requisitos que não estão incluídos nos casos de uso. Os requisitos específicos das Especificações Suplementares, que são aplicáveis a este subsistema ou recurso, devem ser incluídos aqui e refinados ao nível de detalhe necessário para descrever este subsistema ou recurso. Eles podem ser capturados diretamente neste documento ou mencionados como Especificações Suplementares separadas, que podem ser utilizadas como um anexo neste ponto. Certifique-se de que cada requisito esteja claramente etiquetado.]

4. Informações de Suporte

[As informações de suporte facilitam a utilização da Especificação de Requisitos de Software. 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 Especificação de Requisitos de Software deve determinar explicitamente se os apêndices devem ou não ser considerados parte dos requisitos.]

Referências

Documentos relacionados

Do projeto pedagógico foram extraídas treze competências, tomando como base, o método de Rogério Leme em sua obra: APLICAÇÃO PRÁTICA DE GESTÃO DE PESSOAS POR

c.4) Não ocorrerá o cancelamento do contrato de seguro cujo prêmio tenha sido pago a vista, mediante financiamento obtido junto a instituições financeiras, no

Objetivo: Garantir estimativas mais realistas e precisas para o projeto, ao considerar nesta estimativa o esforço necessário (em horas ou percentual do projeto) para

- Se o estagiário, ou alguém com contacto direto, tiver sintomas sugestivos de infeção respiratória (febre, tosse, expetoração e/ou falta de ar) NÃO DEVE frequentar

Local de realização da avaliação: Centro de Aperfeiçoamento dos Profissionais da Educação - EAPE , endereço : SGAS 907 - Brasília/DF. Estamos à disposição

A estabilidade do corpo docente permanente permite atribuir o conceito muito bom, segundo os parâmetros da área, para o item 2.2 (pelo menos 75% dos docentes permanentes foram

Além de serem gravados no cartão, os dados são transmitidos através de um módulo de rádio frequência transmissor para um receptor do modelo, onde há um outro PIC capaz de

São muitos os problemas ambientais causados pelo crescimento urbano, o poder público não acompanha esse crescimento com investimentos em obras de infraestrutura, são ocupados