O Documento Requisitos de Software DRS

Prévia do material em texto

1 
O Documento Requisitos de Software – DRS 
 
1 – INTRODUÇÃO 
O propósito de um DRS é definir num documento, utilizando o ponto de vista do desenvolvedor, 
o que o software deve fazer. O DRS deve ser completo e cobrir todos os requisitos declarados 
no DRU. 
 
O DRS deve ter detalhamento o suficiente para permitir implementação do software sem 
envolvimento do usuário. Entretanto, o tamanho e o conteúdo do DRS devem refletir o tamanho 
e a complexidade do produto software. Ele não deve cobrir todos os aspectos de 
implementação e, embora deva ser completo, quanto menor ele for, mais legível e ele revisável 
será. 
 
O DRS é um produto obrigatório da fase RS e tem um papel fundamental na documentação do 
produto software. Os autores do DRS não devem ir além dos limites deste papel. Isto significa 
que: 
- o DRS não deve incluir detalhes ou terminologia de implementação, exceto se forem 
colocados no DRU como restrições; 
- as descrições de funções devem conter o que o software deve fazer; 
- é mandatório evitar o registro de “como fazer”; 
- o DRS deve evitar a especificação de hardware ou equipamento, exceto se estes foram 
colocados no DRU como restrições. 
 
2 – ESTILO 
O DRS deve ser sistemático, rigoroso, claro, consistente e modificável. Tanto quanto possível, 
os requisitos de software devem ser colocados em termos quantitativos para aumentar sua 
verificabilidade. 
 
2.1 – Clareza 
Um DRS é “claro “ se cada requisito não tem ambigüidade e seu significado é claro para 
todos os leitores. 
Se uma linguagem de especificação de requisitos é utilizada, textos explicativos, escritos 
em linguagem natural, devem ser incluídos no DRS, para torná-lo mais compreensível 
àqueles não familiarizados com a linguagem de especificação. 
 
2.2 – Consistência 
O DRS deve ser consistente. Existem vários tipos de inconsistências: 
- termos diferentes utilizados para indicar a mesma coisa; 
- o mesmo termo utilizado para indicar coisas diferentes; 
- atividades incompatíveis ocorrendo ao mesmo tempo; 
- atividades ocorrendo na ordem errada. 
Quando um termo tiver múltiplos significados , um significado único para o termo deve 
ser definido num glossário e somente este significado deve ser utilizado no documento. 
Um DRS é consistente se nenhum conjunto de requisitos individuais conflitam. Métodos 
e ferramentas ajudam a achar inconsistências. 
 
 
 2 
2.3 – Modificabilidade 
 A modificabilidade permite que se faça mudanças de forma fácil, completa e consistente. 
Quando um requisito duplica ou se sobrepõe a outro, a inclusão de referências cruzadas 
ajuda a preservar a modificabilidade. 
 
3 – EVOLUÇÃO 
O DRS deve ser colocado sob controle formal de mudanças pelo desenvolvedor tão logo ele 
seja aprovado. Novos requisitos podem ser adicionados e velhos requisitos podem sofrer 
modificações ou mesmo serem eliminados. Se o DRS está sendo desenvolvido por um grupo 
de pessoas, o controle do documento pode se iniciar no começo da fase RS. 
O Plano Gerencial de Configuração de Software para a fase RS deve definir um processo 
formal de mudança para identificar, controlar, rastrear e relatar mudanças projetadas tão logo 
elas sejam identificadas. Mudanças aprovadas nos requisitos devem ser registradas no DRS, 
inserindo registros de mudanças no documento e uma folha de status do documento no início 
do DRS. 
 
4 – RESPONSABILIDADE 
Não importa quem tenha escrito o DRS, a responsabilidade por esse documento é do 
desenvolvedor. É ele que deve indicar pessoas com habilidades analíticas provadas para 
escrever o DRS. Membros do grupo de projeto e implementação devem participar da revisão 
formal, RS/R, pois eles podem aconselhar sobre a viabilidade técnica de requisitos. 
 
5 – MÍDIA 
Usualmente, se assume que o DRS é um documento em papel. No entanto, ele pode ser 
distribuído eletronicamente aos participantes que tenham acesso aos equipamentos 
necessários. 
 
6 – CONTEÚDO = ESTRUTURA DO DOCUMENTO 
O DRS deve ser compilado de acordo com um padrão e o padrão recomendado aqui utiliza as 
recomendações da AISI / IEEE Std 830-1993 “Recommended Practice for Software 
Requirements Specifications”. A descrição do modelo lógico é a única adição significativa. 
A seção 1 resume o propósito do DRS e do produto. A seção 2 fornece uma visão geral do 
projeto e do produto. A seção 3 deve conter o material definitivo do que deve ser executado. O 
documento deve conter também um glossário de termos e para os DRS grandes, com mais de 
50 páginas, incluir ainda, uma tabela de conteúdo. Referências devem ser fornecidas quando 
apropriado. Um DRS não deve referenciar documentos futuros do Ciclo de Vida do Software . 
Um DRS não deve conter material ASC – A Ser Confirmado ou ASD – A Ser Definido, a partir 
do momento em que o DRS for para a revisão formal da fase RS / R. 
 
6.1 Estrutura do Documento 
 
A estrutura recomendada do DRS é mostrada a seguir: 
 
Informações gerais do documento: 
• Resumo (abstract) 
• Tabela de Conteúdo 
• Folha de Status do Documento 
• Registro de Mudanças no documento 
 3 
 
1. INTRODUÇÃO 
 
 1.1 Propósito 
 1.2 Abrangência 
 1.3 Definições, Acrogramas e Abreviações 
 1.4 Referências 
 1.5 Visão Geral 
 
2. DESCRIÇÃO GERAL 
 
2.1 Relação com projetos atuais 
2.2 Relação com projetos passados e futuros 
2.3 Função e propósito 
2.4 Considerações ambientais 
2.5 Relação com outros sistemas 
2.6 Restrições gerais 
2.7 Descrição do modelo 
 
3. REQUISITOS ESPECÍFICOS 
 
( As funções seguintes podem ser reagrupadas ao redor de funções de nível maior) 
 
3.1 Requisitos funcionais 
3.2 Requisitos de desempenho 
3.3 Requisitos de interface 
3.4 Requisitos operacionais 
3.5 Requisitos de recurso 
3.6 Requisitos de verificação 
3.7 Requisitos Testes de Aceitação 
3.8 Requisitos de documentação 
3.9 Requisitos de “security” 
3.10 Requisitos de portabilidade 
3.11 Requisitos de qualidade 
3.12 Requisitos de confiabilidade 
3.13 Requisitos de manutenabilidade 
3.14 Requisitos de “safety” 
 
4. MATRIZ DE RASTREABILIDADE 
 
 
Nota: Material relevante, mas inadequado para inclusão nos títulos apresentados 
anteriormente deve ser inserido em apêndices adicionais. Se não existe material 
para uma seção, então a frase “não aplicável” deve ser inserida e a numeração 
preservada. 
 
 
 
 4 
 
6.1 – Preenchimento do Documento 
 
1. INTRODUÇÃO 
Esta seção descreve resumidamente, tanto o propósito do DRS como do produto. 
 
1.1 Propósito (do documento) 
A subseção deve: 
1. definir o propósito do DRS específico; 
2. especificar o leitor provável do DRS. 
 
1.2 Abrangência (do software) 
A subseção deve: 
1. identificar pelo nome o(s) produto(s) software a ser(em) produzido(s),; 
2. explicar o que o software proposto fará, (e não fará, se necessário); 
3. descrever benefícios, objetivos e metas relevantes, tão precisamente quanto 
possível. 
 
Nota: Todo documento deve ser consistente com especificações de alto nível, se elas 
existirem. 
 
1.3 Definições, Acrogramas e Abreviações 
Esta subseção deve fornecer definições de todos os termos, acrogramas e 
abreviações utilizadas no DRS, ou referenciar outros documentos onde as 
encontrar. 
 
1.4 Referências 
Esta subseção fornece uma lista completa de todos os documentos e referências 
aplicáveis. Cada documento deve ser identificado por seu título, autor e datas. 
Cada documento deve ser marcado como aplicável ou referência. Se apropriado, 
número do relatório, nome do jornal e organização publicadora deve ser incluído. 
 
1.5 Visão Geral (do documento) 
Esta subseção: 
1. descreve o que o resto do DRS contém; 
2. explica como o DRS é organizado. 
 
2. DESCRIÇÃO GERALEsta seção descreve os fatores gerais que afetam o produto e seus requisitos. Na 
seção não se define requisitos específicos, mas apenas os tornam mais fáceis de 
serem entendidos. 
 
2.1 Relação com projetos atuais 
Esta subseção descreve o contexto do projeto em relação aos projetos atuais. A 
subseção deve identificar quaisquer outros projetos relevantes que o 
desenvolvedor está executando para o iniciador. O projeto pode ser independente 
de outros, ou ser parte de um projeto maior. 
 5 
Estes projetos maiores devem ser identificados. Uma descrição detalhada da 
interface do produto com o sistema maior deve ser feita na subseção 2.5 
( Relação com outros subsistemas) deste documento. 
 
2.2 Relação com projetos passados e futuros 
Esta subseção descreve o contexto do projeto em relação aos projetos passados 
e futuros. A subseção deve identificar projetos que o desenvolvedor executou para 
o iniciador, no passado e também projetos que o desenvolvedor espera executar 
no futuro, se conhecido. 
 
Se o produto vai substituir um produto existente, as razões para a substituição 
deste produto devem ser sumariadas nesta subseção. 
 
2.3 Função e propósito 
A subseção discute o propósito do produto. Deve expandir os pontos já 
apresentados na seção 1.2 deste documento. 
 
2.4 Considerações ambientais 
Esta seção deve sumariar: 
- o ambiente físico do sistema alvo, isto é, onde o sistema será utilizado e por 
quem. A subseção do DRU 2.4 (Características do Usuário) pode fornecer 
material útil para este tópico. 
- o ambiente de hardware no sistema alvo, isto é, qual ou quais computadores o 
sistema de software deve rodar. 
- o ambiente operacional no sistema alvo, isto é, quais sistemas operacionais 
serão utilizados. 
- o ambiente de hardware no sistema de desenvolvimento , isto é, qual ambiente 
de software é utilizado para desenvolvimento, ou quais ferramentas de 
software serão utilizadas. 
 
2.5 Relação com outros sistemas 
Esta subseção descreve em detalhes o relacionamento do produto com outros 
sistemas , por exemplo, o produto software é: 
- um sistema independente? 
- um subsistema de um sistema maior? 
- uma substituição de outro sistema? 
 
Se o produto é um subsistema de um sistema maior, então a subseção deve: 
- sumariar as características essenciais do sistema maior; 
- identificar os subsistemas com os quais este sistema tem interface; 
- sumariar o hardware do computador e equipamento periférico que será 
utilizado. 
 
Um diagrama de blocos pode ser apresentado mostrando os componentes 
principais do projeto ou sistema maior, as interconexões e interfaces externas. 
 
O DRU contém uma subseção, 2.1 (Perspectiva do Produto) que pode fornecer 
material relevante para esta seção. 
 6 
 
 
 
 
2.6 Restrições gerais 
Esta subseção deve descrever quaisquer itens que limitam as opções do 
desenvolvedor para o software que está sendo construído. Ela deve fornecer 
informações de antecedentes e procurar justificar as restrições. O DRU possui a 
seção 2.3 (Restrições Gerais) que pode conter material relevante para esta 
subseção. 
 
2.7 Descrição do modelo 
Esta subseção deve incluir uma descrição “top-down” do modelo lógico. 
Diagramas, tabelas, e textos explicativos podem ser incluídos. 
A funcionalidade de cada nível deve ser descrita , permitindo ao leitor um 
“walkthrough” no modelo, nível por nível, função por função e fluxo por fluxo. A 
subseção deve conter uma descrição das partes mais importantes, mas sem 
grande detalhamento, em termos de diagramas de fluxo de dados e 
especificações funcionais de baixo nível. Pode ser necessário incluir comentários 
suplementares. Recomenda-se a linguagem natural. 
 
3. REQUISITOS ESPECÍFICOS 
Os requisitos de software são detalhados nesta seção. Cada requisito deve ter um 
identificador único. Requisitos essenciais devem ser marcados como tal. Para a 
liberação incremental, cada requisito deve incluir uma medida de prioridade de modo 
que o desenvolvedor possa decidir o cronograma de produção. Referências que 
rastreiem os requisitos de software com o DRU devem acompanhar cada requisito de 
software. Quaisquer outras fontes devem ser especificadas. Cada requisito de 
software deve ser verificável. 
 
Os requisitos funcionais devem ser estruturados utilizando a abordagem “top-down”. 
Requisitos não funcionais podem aparecer em todos os níveis de hierarquia de 
funções, e pelo princípio da herança, aplicar a todos os requisitos funcionais abaixo 
deles. Requisitos não funcionais podem ser ligados aos requisitos funcionais por 
referências cruzadas ou agrupando-os fisicamente juntos no documento. 
 
Se um requisito não funcional aparece num nível mais baixo, ele se superpõe a 
qualquer requisito deste tipo, que apareça num nível mais alto. Funções críticas, por 
exemplo, podem ter requisitos de “safety” e confiabilidade mais apertado do que 
aqueles de funções não críticas. 
 
Requisitos específicos devem ser escritos em linguagem natural pois isto os tornam 
mais compreensíveis aos não especialistas. A dificuldade está no fato de que a 
linguagem natural permite o aparecimento de inconsistências, ambigüidade e 
imprecisão. Estas propriedades indesejáveis podem ser evitadas utilizando 
linguagens de especificação de requisitos. Tais linguagens vão desde a linguagem 
natural estruturada ao Z, VDM e LOTOS. 
 
 7 
Cada requisito de software deve ser rastreado com a fase seguinte PA e com a fase 
anterior RU. Esta exigência depende da existência de uma identificação única dos 
requisitos. 
 
Para o software ser aceito, seus requisitos essenciais devem ser cumpridos. Se um 
requisito de software é essencial, isto deve ser claramente registrado. Requisitos não 
essenciais devem ser marcados com uma medida de desejabilidade (por exemplo, 
escala 1, 2 ou 3). A prioridade de um requisito mede a seqüência e o tempo exato em 
que a funcionalidade relacionada se torna disponível. Se a transferência é deslocada 
de modo que algumas partes entrem em operação antes de outras, cada requisito 
deve ser marcado com uma medida de prioridade. 
 
Requisitos instáveis devem ser marcados. Estes requisitos podem ser dependentes 
de realimentação das fases RU, RS e PA. Um marcador geralmente utilizado é o 
acrograma “ASC”. 
 
A fonte de cada requisito de software deve ser marcada, utilizando-se por exemplo, o 
identificador do requisito, um documento de referência cruzada, ou mesmo um nome 
de pessoa ou grupo. Rastreabilidade para trás depende de cada requisito estar 
explicitamente marcado e sua fonte no DRU estar referenciada. 
 
Cada requisito de software deve ser verificável. A clareza aumenta a verificabilidade . 
A melhoria da clareza garante que cada requisito de software esteja bem separado 
dos outros. Um requisito de software é verificável se algum método pode ser 
determinado para demonstrar objetivamente que o software o implementa 
corretamente. 
 
 
 
4. MATRIZ DE RASTREABILIDADE DOS REQUISITOS 
 
 
MATRIZ DE RASTREABILIDADE DE REQUISITOS 
DRS rastreado contra DRU 
 
Data: dd / mm / aaaa 
Página 1 de n 
 
 
Projeto: ACADEMIA 
 
Identificador 
RU 
Identificador 
RS 
 
 
SUMÁRIO DE REQUISITOS DO USUÁRIO