1 2
Unidade 4
Documentação de Requisitos
É a atividade de representar os resultados da Engenharia de Requisitos em um
documento oficial e formal contendo os requisitos do sistema que descrevem o que o
mesmo irá fazer, em um nível apropriado de detalhes, sem descrever como fazê-lo
(Brackett, 1990, Davis, 1993, Sommerville & Sawyer, 1997, Thayer & Dorfman, 1997,
p.1, IEEE, 1998).
Kotonya & Sommerville (1998) e Dorfman (1997) definem que o documento
de requisitos é uma declaração oficial dos requisitos de um sistema descrevendo:
1. o escopo e os objetivos do software;
2. os serviços e funções que o software deve fornecer;
3. as restrições sob as quais o software deve operar;
4. as propriedades gerais do software, tais como atributos de qualidade e
desempenho;
5. as definições de outros softwares com os quais deve interagir;
6. as informações sobre o domínio de aplicação do software;;
7. as restrições ao processo de desenvolvimento adotado.
Também deve ser documentada a fonte dos requisitos (uma pessoa, um grupo ou
documento, por exemplo), os problemas que se pretende resolver (Lamsweerde, 2000),
além das razões e justificativas da escolha de cada solução ou decisão tomada, as
demais alternativas consideradas, os fatores avaliados e as argumentações que guiaram
cada decisão ou solução. Essas informações adicionais são chamadas na literatura de
design rationale e fornecem uma visão mais rica sobre o software e o processo de
tomada de decisão, proporcionando, ainda, melhorias significativas na gerência de
dependências, na colaboração, no reuso, manutenção, aprendizagem e na própria
documentação (Lee, 1997, Burge & Brown, 2000).
Profa. Denise Franzotti Togneri
Para que um documento de requisitos esteja bem escrito deve possuir alguns
atributos. Segundo Davis (1993), ele deve ser:
• correto: cada um dos requisitos declarados será implementado;
• sem ambigüidades: cada requisito tem somente uma interpretação;
• completo;
• verificável: deve existir um processo efetivo de custo finito através do qual
seja possível verificar se o software atende os requisitos declarados;
• consistente: uma ERS é consistente se (1) nenhum requisito declarado está
em conflito com outros documentos e (2) nenhum subconjunto de requisitos
declarado está em conflito;
• entendível pelos usuários
• modificável: sua estrutura e estilo permitem que qualquer mudança em um
requisito possa ser feita de forma simples, completa e consistente;
• rastreável: se cada requisito documentado tiver rastreabilidade;
• independente do projeto do sistema;
• comentado: classificar cada requisito em essencial, desejável ou opcional ;
• conciso;
• organizado: os requisitos contidos na ERS são fáceis de localizar.
Não há um nome padrão para esse documento, podendo ser adotado, dentre
outros, "Especificação de Requisitos de Software (ERS)", "Documento de Requisitos"
ou "Especificação Funcional" (Sommerville & Sawyer, 1997). Uma boa ERS fornece
muitos benefícios, tais como: (1) facilita a comunicação dos requisitos; (2) reduz o
esforço de desenvolvimento, pois sua preparação força os usuários e clientes1 a
considerar, de forma rigorosa, todos os requisitos, evitando retrabalho nas fases
posteriores; (3) fornece uma base realística para estimativa de custos e cronogramas; (4)
1
Os usuários são as pessoas que operam ou interagem diretamente com o produto de software (IEEE,
1998). Os clientes são as pessoas responsáveis pela contratação e aceitação do produto de software
(Bracket, 1990); normalmente, decidem os requisitos a serem desenvolvidos (IEEE, 1998) e estão mais
interessados nos resultados da utilização do software pelos usuários do que no software em si (Leite,
2001).
Profa. Denise Franzotti Togneri
 3 4
fornece uma base para verificação e validação; (5) facilita a transferência do software
para novos usuários e/ou máquinas e (6) serve como base para futuras manutenções ou
incremento de novas funcionalidades (IEEE, 1998, Nuseibeh & Easterbrook, 2000).
O documento de requisitos pode ser usado por diferentes pessoas (Faulk, 1996,
Sommerville & Sawyer, 1997):
1. clientes e patrocinadores, que usam o documento para fornecer uma base
contratual para seu desenvolvimento;
2. usuários e especialistas de domínio, que lêem o documento para verificar
se ele representa suas necessidades e, caso necessário, especificar
mudanças a serem feitas, durante o desenvolvimento ou após implantação;
3. gerentes responsáveis pelo planejamento, custos e cronograma, que usam
o documento para o planejamento do projeto, sua licitação para
desenvolvimento e como base para medição;
4. engenheiros de software, responsáveis pelas atividades subseqüentes de
projeto e implementação, que usam o documento para entender o que será
desenvolvido;
5. engenheiros de teste, que usam o documento para derivar os casos de testes
que validarão se o software construído está de acordo com os requisitos
especificados;
6. equipe de garantia da qualidade, que usa o documento como base para
verificação e validação;
7. equipe de manutenção do sistema, que mantém e modifica o software após
ter sido implantado. Usa o documento de requisitos para entender as
características iniciais do software e os relacionamentos entre suas
diferentes partes.
De forma geral, os requisitos podem ser descritos em linguagem natural
(português, espanhol, inglês, ...), em notações e linguagens semi-formais ou formais ou
qualquer combinação dessas formas (Nuseibeh & Easterbrook, 2000, Pressman, 2000) e
Profa. Denise Franzotti Togneri
sua adoção deve ser apropriada para o problema a ser resolvido (Davis, 1993, IEEE,
1998).
A linguagem natural é bastante usada por facilitar a comunicação e ser
extremamente expressiva e flexível, mas é pobre para capturar as semânticas do modelo,
possibilita ambigüidades, pode gerar inconsistências, falta de acurácia e dificuldade para
verificar completeza (Saiedian, 1997, Loucopoulos & Karakostas, citados por
Easterbrook, 2001). No entanto, pode ser usada, desde que haja uma revisão
independente para identificar os problemas e corrigi-los (Davis, 1993, IEEE, 1998).
Como exemplo, pode-se citar a Lista de Eventos (McMenamin & Palmer, 1991) e a
proposta para especificação de requisitos documentando-os através de declarações
chamadas de “shall statements” (IEEE, 1998).
Uma notação semi-formal captura a estrutura e alguma semântica e pode
permitir alguma verificação de consistência, animação, etc. (Loucopoulos &
Karakostas, citados por Easterbrook, 2001). Como exemplo, pode-se citar a Linguagem
de Modelagem Unificada (UML - Unified Modeling Language) (Booch et al., 1998), os
diagramas de fluxo de dados e os diagramas de entidades e relacionamentos (Yourdon,
1990, McMenamin & Palmer, 1991, Pompilho, 1995). A notação semi-formal é bastante
utilizada por ser apropriada para o entendimento dos usuários (Sommerville & Sawyer,
1997), mas existem alguns problemas com essa notação, tais como a falta de uma
semântica precisa que possa ser usada para verificar ou raciocinar sobre as propriedades
do software, além de possibilitar "livre" interpretação (Saiedian, 1997).
Os métodos formais fornecem uma linguagem formal para descrever um artefato
de software de tal forma que provas formais sejam possíveis, em princípio, sobre as
propriedades do artefato assim expresso (Vienneau, 1997). No entanto, requerem um
tempo maior de aprendizado, além de não serem legíveis para usuários não técnicos
(IEEE, 1998).
Dentro da atividade de documentação, a modelagem - a construção de
descrições abstratas que possam ser interpretadas de forma correta - é uma atividade
fundamental. Os modelos podem ser usados para representar uma grande variedade de
produtos gerados durante o processo de engenharia de requisitos. Além disto, muitas
abordagens de modelagem também podem ser usadas como ferramentas de elicitação, à
medida que a notação e os modelos parcialmente produzidos são usados para se obter
Profa. Denise Franzotti Togneri
 5 6
mais informações. Na literatura encontram-se várias propostas para abordagens de
modelagem. Nuseibeh & Easterbrook (2000) propõem algumas categorias para as
abordagens da modelagem:
1. Modelagem organizacional: o contexto da maioria das atividades de
engenharia de requisitos e dos sistemas de software é a organização na qual
o desenvolvimento ocorre ou o software irá operar. A modelagem da
organização e sua análise lidam com o entendimento de sua estrutura, as
regras de negócio que afetam sua operação, seus objetivos, atividades e a
responsabilidade dos membros envolvidos, bem como os dados que geram e
manipulam. Neste contexto, a modelagem organizacional visa capturar o
objetivo do sistema descrevendo o comportamento da organização no qual o
sistema irá operar. Este comportamento pode ser descrito em termos de
objetivos ou metas organizacionais e as atividades e recursos associados.
Outros preferem modelar a empresa em termos de regras de negócios,
workflows e os serviços que irá fornecer. Modelar metas e objetivos é
particularmente útil pois as metas de negócios de alto nível podem ser
refinadas como parte do processo de elicitação, levando a requisitos que
possam ser operacionalizados;
2. Modelagem de Dados: Large computer-based systems, especially
information systems use and generate large volumes of information. This
information needs to be understood, manipulated and managed. Careful
decisions need to be made about what information the system will need to
represent, and how the information held by the system corresponds to the
real world phenomena being represented. Data modeling provides the
opportunity to address these issues in RE. Traditionally, Entity-Relationship-
Attribute (ERA) modelling is used for this type of modelling and analysis.
However, object-oriented modelling, using class and object hierarchies, are
increasingly supplanting ERA techniques.
3. Behavioural Modeling: Modelling requirements often involves modelling the
dynamic or functional behaviour of stakeholders and systems, both existing
and required. The distinction between modelling an existing system, and
modelling a future system is an important one, and is often blurred by the use
Profa. Denise Franzotti Togneri
of the same modelling techniques for both. Early structured analysis methods
suggested that one should start by modelling how the work is currently
carried out (the current physical system), analyse this to determine the
essential functionality (the current logical system), and finally build of model
of how the new system ought to operate (the new logical system). Explicitly
constructing all three models may be overkill, but it is nevertheless useful to
distinguish which of these is being modelled. A wide range of modelling
methods are available, from structured to object-oriented methods, and from
soft to formal methods. These methods provide different levels of precision
and are amenable to different kinds of analysis. Formal methods (for
example, based on Z) can be difficult to construct, but are also amenable to
automated analysis. On the other hand, soft methods provide rich
representations that non-technical stakeholders find appealing, but are often
difficult to check automatically.
4. Domain Modelling: A significant proportion of the RE process is about
developing domain descriptions. A model of the domain provides an abstract
description of the world in which an envisioned system will operate.
Building explicit domain models provides two key advantages: they permit
detailed reasoning about (and therefore validation of) what is assumed about
the domain, and they provide opportunities for requirements reuse within a
domain. Domain-specific models have also been shown to be essential for
building automated tools, because they permit tractable reasoning over a
closed world model of the system interacting with its environment;
5. Modelling Non.Functional Requirements (NFRs): Non-functional
requirements (also known as quality requirements) are generally more
difficult to express in a measurable way, making them more difficult to
analyse. In particular, NFRs tend to be properties of a system as a whole, and
hence cannot be verified for individual components. Recent work by both
researchers and practitioners has investigated how to model NFRs and to
express them in a form that is measurable or testable. There also is a growing
body of research concerned with,particular kinds of NFRs, such as safety,
security, reliability, and usability.
Profa. Denise Franzotti Togneri
 7 8
6. Analysing Requirements Models: A primary benefit of modelling
requirements is the opportunity this provides for analysing them. Analysis
techniques that have been investigated in RE include requirements
animation, automated reasoning (e.g., analogical and case-based reasoning
and knowledgebased critiquing), consistency checking (e.g., model
checking), and a variety of techniques for validation and verification (V&V).
Apesar da ERS não ser um documento de projeto, não existe, no entanto, um
limite muito claro entre a Engenharia de Requisitos e o início da fase de Projeto do
Software. Davis (1993) denomina esse problema de dilema "o que versus como". À
medida que os requisitos vão sendo obtidos na engenharia de requisitos ("o que"), eles
vão sendo organizados, agrupados e documentados na hierarquia proposta para o
projeto de arquitetura ("como"), de forma a organizar uma estrutura de sub-sistemas
para o projeto (Davis, 1993, Dorfman, 1997, Sommerville & Sawyer, 1997).
Não existe um único critério para o agrupamento dos requisitos. Davis (1993)
sugere que os requisitos podem ser agrupados por estímulos externos, características,
respostas do sistema, mesmos objetos do mundo real, classes de usuários ou classes de
funções. Em aplicações complexas típicas, a melhor forma de organizar os requisitos é
em uma hierarquia de múltiplos níveis, onde cada nível corresponde a um critério de
agrupamento. A organização dos requisitos facilita a percepção de pontos omissos e
conflitantes nos requisitos e então um novo ciclo deve ser iniciado.
Diferentes organizações produzem tipos diferentes de documento de requisitos,
com diferentes níveis de abstração. Em alguns casos, o documento de requisitos é uma
descrição bastante pequena e abstrata de um sistema. Em outros casos, é uma
especificação bastante detalhada e precisa da funcionalidade do sistema. O nível de
detalhes do documento de requisitos deve ser decidido caso a caso e depende das
expectativas dos clientes, dos procedimentos da organização, dos padrões ou
regulamentos externos que se deve seguir e do tipo de requisito. Existem várias formas
de estruturar o documento de requisitos, dependendo do tipo de sistema que está sendo
desenvolvido, do nível de detalhes incluído nos requisitos, das práticas da organização,
do orçamento disponível e do cronograma (Kotonya & Sommerville, 1998).
Profa. Denise Franzotti Togneri
Sommerville e Sawyer (1997) e Pressman (2001) propuseram algumas
diretrizes a serem observadas com objetivo de melhorar a estrutura e organização do
documento de requisitos. Dentre elas, pode-se destacar:
1. Definir uma estrutura padrão para o documento: o documento de
requisitos deve ter uma estrutura comum, definida como um padrão da
organização e deve ser verificado como parte do processo de garantia de
qualidade do documento. Sabe-se que a estrutura de uma ERS depende do
problema a ser resolvido, dos costumes e práticas da organização, dos
processos e do tipo de sistema a ser desenvolvido. Sendo assim, é
necessário ter variantes a partir do padrão único que permitam, por
exemplo, que algumas seções sejam opcionais;
2. Explicar como usar o documento: deve-se incluir na introdução, uma seção
explicando como usar o documento relacionando a quem o mesmo se
destina, que seções são mais apropriadas para cada classe de leitores, a
experiência técnica necessária para entender cada seção, ponteiros para
seções de visão geral, que devem ser lidas para adquirir um entendimento
geral dos requisitos antes de considerar a especificação detalhada e uma
descrição sobre a ordem em que as seções devem ser lidas;
3. Incluir um sumário de requisitos, contendo o objetivo do sistema e seus
principais requisitos, apresentados em uma lista numerada, uma tabela ou
de forma gráfica;
4. Incluir uma seção explicando por que o sistema é necessário e como irá
contribuir para os objetivos gerais de negócio da organização;
5. Definir termos especializados em um glossário;
6. Organizar o leiaute do documento para facilitar a leitura;
7. Auxiliar os leitores a encontrar a informação, incluindo no documento de
requisitos recursos tais como listas de conteúdo e índices e organizando os
requisitos em capítulos, seções e sub-seções identificadas;
8. Tornar o documento fácil de alterar.
Profa. Denise Franzotti Togneri