UPE – Universidade de Pernambuco
Documento de
Requisitos
Projeto: {nome}
Data <dd/mm/yyyy> Autor (es) <nome(s)> ID do
Documento < id_document > Versão do
Histórico da Revisão
Data Versão Descrição Autor
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
1.3 Definições, Acrônimos e Abreviações 4 1.4 Prioridades dos Requisitos 4
1.5 Referências 5
1.6 Visão Geral 5
2. Definição de Atores ou Papéis 5
3. Requisitos 5 3.1 Funcionais 5 3.2 Não Funcionais 5 3.2.1 Usabilidade 5 3.2.2 Confiabilidade 6 3.2.3 Desempenho 6 3.2.4 Suportabilidade 7 3.2.5 Restrições de Design 7
4. Diagrama de Caso de Uso 7
Especificação dos Requisitos de Software
1. Introdução
[A introdução da Especificação de Requisitos de Software (SRS) fornece uma visão geral de todo o documento. Ela contém a finalidade, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral da SRS.]
[Observação: A SRS captura todos os requisitos de software do sistema ou de uma parte do sistema. A seguir, há um esquema de SRS típico para um projeto que utiliza a modelagem de casos de uso. Esse artefato consiste em um pacote contendo casos de uso do modelo de casso de uso, Especificações Suplementares aplicáveis e outras informações de suporte. Para ter acesso a um template de uma SRS que não utilize a modelagem de casos de uso, que captura todos os requisitos em um único documento, com as seções aplicáveis inseridas a partir das Especificações Suplementares (que não serão mais necessárias), consulte o arquivo denominado rup_srs.dot.]
[É possível organizar a SRS de várias maneiras diferentes. Consulte o padrão [IEEE93] para obter explicações mais detalhadas, assim como outras opções de organização de uma SRS.]
1.1 Finalidade
[Especifique a finalidade desta Especificação de Requisitos de Software. A SRS descreve totalmente o comportamento externo do aplicativo ou do subsistema identificado. Ela também descreve requisitos não-funcionais, restrições de design e outros fatores necessários para fornecer uma visão completa e
abrangente dos requisitos do software.]
1.2 Escopo
[Uma breve descrição do aplicativo de software ao qual se aplica a Especificação de Requisitos de
Software, do recurso ou de outro agrupamento de subsistemas, do(s) modelo(s) de Casos de Uso
associado(s) a ela e de tudo o que for 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 necessárias à adequada interpretação da Especificação de Requisitos de Software. Essas informações podem ser fornecidas mediante referência ao Glossário do projeto.]
1.4 Prioridades dos Requisitos
Para estabelecer a prioridade dos requisitos, foram adotadas as denominações “essencial”, “importante” e “desejável”.
Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.
Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.
Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.
da Especificação de Requisitos de Software. Identifique cada documento 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.6 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 está organizado.]
2. Definição de Atores ou Papéis
[Nessa seção devem ser explicitados e descritos quais são os atores do sistema, que podem ser usuários humanos ou sistemas computacionais externos.
Um mesmo usuário pode assumir, em diferentes momentos, diferentes papéis no sistema, o que também deve ser explicitado.]
3. Requisitos
3.1 Funcionais
ID Description Use Cases
[RF01] UC1
UC2 [RF02]
3.2 Não Funcionais
3.2.1 Usabilidade
[Esta seção contém todos os requisitos que afetam a usabilidade. Por exemplo,
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 baseie os requisitos de usabilidade do novo sistema em outros sistemas que os usuários conheçam e gostem
especifique requisitos de forma que estejam em conformidade com padrões de usabilidade comuns como, por exemplo, os padrões CUA da IBM ou os padrões GUI da Microsoft]
ID Description
[RNFU01]
3.2.2 Confiabilidade
[Os requisitos de confiabilidade do sistema devem ser especificados aqui. A seguir, há 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 a exatidão (através de algum padrão conhecido) necessárias na saída do sistema.
Taxa Máxima de Erros ou Defeitos — geralmente expressa em termos de erros por milhares de linhas de código (erros/KLOC) ou de erros por ponto de função (erros/ponto de função).
Taxa de Erros ou Defeitos — categorizada em termos de erros pouco importantes, importantes e críticos: o(s) requisito(s) deve(m) definir o que se entende por um erro “crítico”; por exemplo, a perda total de dados ou uma total incapacidade de usar determinadas partes da funcionalidade do sistema.]
ID Description
[RNFC01]
[RNFC02]
3.2.3 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 como, por exemplo, transações por segundo
Capacidade como, por exemplo, o número de clientes ou de transações que o sistema pode acomodar
Modos de degradação (o modo aceitável de operação quando o sistema tiver sido degradado de alguma maneira)
A utilização de recursos como, por exemplo, memória, disco, comunicações, etc.
ID Description
3.2.4 Suportabilidade
[Esta seção indica todos os requisitos que irão aprimorar a suportabilidade ou a 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.]
ID Description
[RNFS01]
[RNFS02]
3.2.5 Restrições de Design
[Esta seção indica 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.]
ID Description
[RNFR01]
[RNFR02]
4. Diagrama de Caso de Uso
[Nesse ponto deve ser incluído o diagrama UML de casos de uso do sistema.
Alternativamente pode ser elaborado um diagrama de caso de uso por módulo funcional. Nesse caso, ele deve ser incluído na seção referente ao seu módulo – Seção 4.1 ou equivalente, por exemplo.]
5. Descrição dos Casos de Uso
Numero do UC:
U01
Nome do UC [Nome que sintetiza a função do caso de uso]
Objetivo Descrição
[Lista de objetivos dos Casos de Uso] [Nesse ponto deve ser incluída a descrição do caso de uso, que deve apresentar claramente o seu objetivo. Um único parágrafo é suficiente para isso.]
Atores [Relação de atores que iniciam o caso de uso] Prioridade [Prioridade do caso de uso em relação aos demais] [X] Essencial [ ] Importante [ ] Desejável Pré-condições Pós-condições
As pré-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. Uma pré-condição corresponde ao estado no qual o sistema deve estar antes que o caso de uso seja executado/iniciado.
As pós-condições de um caso de uso podem ser
apresentadas na forma de uma lista enumerada. As pós-condições correspondem aos estados nos quais o sistema pode se encontrar imediatamente após o término da execução de um caso de uso.
Cenário principal de Sucesso (Fluxo básico)
O fluxo básico de eventos provê uma descrição detalhada das ações/estímulos do usuário e das respostas do sistema que irão ocorrer durante a execução do caso de uso, sob condições normais e esperadas. A finalização dessa seqüência de passos ou interações faz com que o objetivo
estabelecido pelo nome e pela descrição do caso de uso seja atingido.
Sendo assim, essa seqüência deve ser escrita de forma a explicitar quais interações entre o ator e o sistema são necessárias para se atingir o propósito do caso de uso. Isso é apresentado na forma de uma lista enumerada de ações executadas pelo ator, alternadas por respostas providas pelo sistema. Ações ou fluxos alternativos simples podem ser incluídos na seqüência de eventos do fluxo
básico.Porém, se o fluxo alternativo for mais complexo e não puder ser descrito com poucas sentenças, então, deve ser utilizado uma seqüência separada para descrevê-lo. Utilize a seção de
Fluxos Alternativos para isso.
Um fluxo básico de eventos pode ser identificado pelo rótulo “X.0”, onde X é o ID do caso de uso.
Extensões (ou Fluxo alternativo)
Fluxos alternativos mais complexos devem ser descritos separadamente, porém mantendo a referência para o fluxo básico associado.
Cada fluxo alternativo representa comportamentos alternativos que freqüentemente ocorrem devido a exceções geradas no fluxo principal
Inicie cada fluxo alternativo indicando explicitamente em que ponto do fluxo básico ele pode ocorrer e as condições sob as quais ele é executado.
Eventualmente, parte do fluxo básico pode ser retomado após o término de um fluxo alternativo e, nesse caso, o ponto de retorno deve ser explicitado.
O uso de fluxos alternativos aumentam a legibilidade do caso de uso. Tenha em mente que casos de uso são somente descrições textuais e seu propósito principal é documentar o comportamento do sistema sob o ponto de vista do usuário de maneira clara, concisa e compreensível.
