Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros.
Boas Práticas na Engenharia de Requisitos
Nauane Karoline Brazolino
Dias
naniedias@gmail.com
Graduanda do curso de Bacharelado em Sis-
temas de Informações pelo Centro de Ensino
Superior de Juiz de Fora (CES/JF).Estagiária da
Prefeitura de Juiz de Fora e integrante do grupo
de pesquisa do projeto Modelagem de Ontolo-
gia de Domínio Para Workflow Científico.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas
e Computação pela COPPE/UFRJ. Especialis-
ta em Métodos Estatísticos Computacionais
e Bacharel em Matemática com Habilita-
ção em Informática pela UFJF. Professor e
Coordenador do curso de Bacharelado em
Sistemas de Informação do Centro de Ensino
Superior de Juiz de Fora. Professor do curso
de Bacharelado em Sistemas de Informação
da Faculdade Metodista Granbery. Professor
do curso de Bacharelado em Ciência da Com-
putação da Faculdade Governador Ozanam
Coelho. Professor e Diretor do Curso Superior
de Tecnologia em Análise e Desenvolvimento
de Sistemas da Fundação Educacional D.An-
dré Arcoverde. Analista de Sistemas da Pre-
feitura de Juiz de Fora. Editor da Engenharia
de Software Magazine.
14 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos
C
om os avanços tecnológicos que
vem ocorrendo nas últimas dé-
cadas e a visível diminuição do
custo do hardware, a informação passa
a ser um recurso estratégico das empre-
sas. O software se tornou, então, a força
motora desta nova era. A integridade das
informações oferecidas por um software
pode diferenciar uma empresa de suas
concorrentes.
O software é capaz de manipular o pro-
duto mais importante para uma empresa
– a informação, e por isso é tão caro. Para
evitar que a parte mais cara dos sistemas
computadorizados fosse desenvolvida
com baixa qualidade e pouca previsi-
bilidade de custo e recursos, surgiram
técnicas de Engenharia de Software.
A Engenharia de Software surgiu com
o objetivo de definir e aplicar métodos
que pudessem ajudar no processo de
construção, manutenção e implantação
de software.
A Engenharia de Software pode ser
entendida, então, como a disciplina de
De que se trata o artigo?
Este artigo objetiva a apresentação de padrões para
construção de Documento de Especi�cação de Re-
quisitos de Software (DERS) e também mostrar boas
práticas para sua elaboração, de forma a facilitar a
comunicação entre os stakeholders.
Para que serve?
Obedecendo a padrões para desenvolvimento do
DERS, esse documento apresentará melhor qualidade,
representando, consequentemente, o que os stakehol-
ders esperam do projeto de software que está sendo
desenvolvido, tornando possível que o projeto seja
implementado com maior possibilidade de sucesso,
abrangendo as necessidades dos usuários.
Em que situação o tema é útil?
Em projetos de software, a Engenharia de Requisi-
tos é normalmente empregada como uma das fases
preliminares. É através da Engenharia de Requisitos
que os analistas descobrem as reais necessidades
do cliente e transferem-nas para o DERS. Utilizando
os padrões mostrados neste artigo, é possível criar
um DERS com maior qualidade.
engenharia aplicada ao desenvolvimento
de software, compreendendo um con-
junto de etapas que envolvem métodos,

ferramentas e procedimentos que possibilitam o controle do
processo de desenvolvimento de software, ocupando-se de
todos os aspectos, desde os estágios iniciais de especificação
do sistema até a manutenção desse sistema, oferecendo ao
profissional uma base para a construção de software de alta
qualidade produtivamente.
A Engenharia de Requisitos pode ser vista como uma sub-área
da Engenharia de Software, cujo principal objetivo é a obtenção
de uma especificação correta e completa dos requisitos.
Este artigo propõe apresentar a Engenharia de Requisitos
e seu principal produto, o Documento de Especificação de
Requisitos de Software (DERS), e mostrar boas práticas para
a construção do mesmo.
A Engenharia de Requisitos
O principal objetivo da Engenharia de Requisitos é criar
e manter documentos de requisitos de sistemas, chamado
de Documento de Especificação de Requisitos de Software
(DERS) [2]. O processo de engenharia de requisitos, como um
todo, contém quatro grandes sub-processos que são: em quais
aspectos o sistema é útil ao negócio (estudo de viabilidade),
descoberta de requisitos (elicitação e análise), conversão de
tais requisitos em um formato padrão (especificação) e desco-
berta se tais requisitos realmente definem o sistema tal como
o usuário deseja (validação).
Na Figura 1 pode ser visto um processo de Engenharia de
Software como um todo, conhecido como Ciclo de Vida Clás-
sico, que também pode ser executado várias vezes como parte
integrante de um ciclo de vida iterativo e incremental.
Figura 1. O processo de Engenharia de Software [3]
Esse modelo representa o processo de Engenharia de Softwa-
re como um todo e envolve as atividades [3]:
• Análise de requisitos do software: É nessa fase que a Enge-
nharia de Requisitos é aplicada. Os requisitos do sistema são
coletados baseados no conhecimento de domínio do software,
assim como funções requeridas, comportamento, desempenho
e interface.
• Projeto: projeto de software é na verdade um processo de
vários passos que foca em quatro atributos distintos: estrutura
de dados, arquitetura do software, representação de interface
e detalhes de procedimentos (algorítmicos).
• Codificação: o projeto é traduzido em linguagem de máquina
através de uma linguagem de programação.
• Testes: Os testes focam em descobrir erros e definir que
determinadas entradas irão realmente produzir os resultados
esperados.
E NG E NHARIA DE RE QU IS ITOS
• Suporte: O software certamente irá precisar de modifica-
ções após ser entregue ao cliente. Essas modificações podem
ocorrer por causa de erros que tenham sido encontrados, novas
funcionalidades, melhoria de desempenho ou adaptação de
funcionalidades existentes.
Neste “modelo” de Engenharia de Software, a Engenharia
de Requisitos encontra-se na primeira fase - a fase de Análi-
se. Na Figura 2, pode-se ver a representação do processo de
Engenharia de Requisitos.
Figura 2. Processo de Engenharia de Requisitos [2]
O processo é iterativo, ou seja, pode-se voltar a uma fase que
já foi feita, como em uma espiral. As três fases principais (eli-
citação, especificação e validação) são divididas em subfases.
A elicitação, que é responsável por coletar os requisitos, foi
dividida em Elicitação dos Requisitos do Sistema e Elicitação
dos Requisitos de Usuário. A fase de especificação foi dividida
em Especificação dos Requisitos de Sistema e Modelagem,
Especificação dos Requisitos de Usuário e Especificação dos
Requisitos de Negócio. E a fase de Validação foi dividida em
Estudo de Viabilidade, Prototipação e Revisões.
Acompanhando a linha de evolução dos processos de Enge-
nharia de Requisitos, começa-se com a elicitação dos requisitos
de usuário e a especificação dos requisitos de negócio para
realizar um estudo de viabilidade. Concluído este processo, é
feita a elicitação dos requisitos do sistema, a especificação dos
requisitos do usuário e a especificação dos requisitos de siste-
ma e modelagem. Nesse ínterim é possível reavaliar alguma
pendência nos processos feitos anteriormente, visando uma
melhoria dos mesmos. O próximo passo é a prototipação, que
irá mostrar aos stakeholders um primeiro cenário do software.
Em seguida são feitas as revisões apuradas na validação feita
com os stakeholders. Caso esteja tudo feito de acordo com as
pretensões dos interessados no projeto, o Documento de Es-
pecificação de Requisitos de Software (DERS) é considerado
pronto e passa-se para a próxima fase do processo de Enge-
nharia de Software.
Edição 27 - Engenharia de Software Magazine 15
 Nem sempre é fácil identificar corretamente os requisitos
de software, até mesmo devido à natureza abstrata própria
de um projeto de software. Porém, se esse processo não for
bem feito, o DERS ficará comprometido, inviabilizando toda
a fase de projeto, que é a fase seguinte à fase de Análise.
São muitos os problemas que podem acontecer durante
todo o processo de desenvolvimento e implementação de
um software, e problemas relacionados à base da construção
do software, ou seja, os requisitos desse software, podem
gerar impactos negativos no final da construção. Requisitos
incompletos ou defeituosos podem causar problemas no
produto de software final.
Muitos projetos têm falhado devido a problemas na elici-
tação, tais como requisitos incompletos, mal entendidos ou
ambíguos. Faz-se necessário então que esses requisitos sejam
bem construídos de maneira que expressem exatamente o
que o usuário deseja, da maneira que ele deseja e a forma
como poderá ser feito. Por isso é importante conhecer técni-
cas para tornar a construção destes requisitos mais eficaz.
Todo o trabalho feito nas fases iniciais de Engenharia de
Requisitos (viabilidade, elicitação, análise e especificação)
gera como resultado o DERS. O DERS é o documento oficial
do que deverá ser implementado pelos desenvolvedores do
sistema [2].
O Documento de Especificação de Requisitos de
Software
O DERS, segundo o IEEE (Institute of Electrical and Elec-
tronics Engineers), deve ser completo e não ambíguo, sendo
responsável por auxiliar os clientes de software a descrever
com precisão o que eles desejam obter, e desenvolvedores
de software a entender exatamente o que o cliente deseja.
Ainda segundo o IEEE, para os clientes, desenvolvedores e
outros indivíduos ligados ao projeto, um bom DERS deve
prover diversos benefícios, tais como:
• Estabelecer a base de acordo entre os clientes e a empresa
fornecedora sobre o que o software irá fazer;
• Reduzir o esforço de desenvolvimento;
• Prover uma base para estimativas de custo e prazos;
• Prover uma base para validação e verificação do produto;
• Facilitar a manutenção do produto de software final.
Um DERS conta com alguns padrões indicados para sua
elaboração. O IEEE elaborou um documento que contém
padrões e práticas recomendadas para a criação do DERS
chamado IEEE Recommended Practice for Software Re-
quirements Specification - Práticas Recomendadas para a
Especificação de Requisitos de Software. Segundo essas
práticas, o DERS deve ter uma estrutura tal como mostrada
na Figura 3.
As seções devem, então, ser preenchidas da seguinte
maneira:
• Propósito (1.1): deve delinear o propósito particular
deste DERS e especificar para quem está sendo feito esse
documento.
16 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos
Figura 3. Estrutura do DERS
• Escopo (1.2): deve especificar o produto software a ser
produzido, nomeando-o; explicar o que o produto irá fazer e,
se necessário, o que não irá fazer, descrever as aplicações do
software que está sendo especificado, incluindo benefícios,
objetivos e metas relevantes.
• Definições, siglas e abreviaturas (1.3): deve prover a definição
de todos os termos, siglas e abreviaturas que são necessárias
para entender este DERS.
• Referências (1.4): deve prover uma lista de todos os docu-
mentos que forem referenciados em outros locais do DERS,
identificando cada um por autor, título, data, editora, organi-
zação, e outros atributos quando aplicáveis.
• Visão Global (1.5): deve apresentar de forma sucinta e resu-
mida o que os capítulos restantes do DERS irão tratar.
• Perspectiva do produto (2.1): deve colocar o produto na
perspectiva de outros produtos relacionados. Se é um produto
independente, isso deve ser dito aqui. Caso contrário, se é um
componente de um sistema maior, o que ocorre frequentemen-
te, então esta subseção deve relatar as interfaces entre esse
software e o sistema, além dos requisitos do sistema maior
para a funcionalidade deste software.
• Funções do produto (2.2): deve prover um índice das prin-
cipais funções que o software irá executar.
• Características do usuário (2.3): deve descrever as caracte-
rísticas gerais dos usuários do produto.
• Restrições (2.4): deve descrever qualquer outro item que
limite as opções do produto, tais como políticas de controle,
limitações de hardware, interface com outras aplicações, con-
troles de segurança, entre outros itens que forem relevantes.
• Pressupostos e Dependências (2.5): deve listar todos os fatores
que afetem os requisitos definidos.
• Requisitos Específicos (3): contém a definição dos requisi-
tos de software. É o principal capítulo do DERS, pois é nesta
seção que os requisitos funcionais e não funcionais estarão
definidos.
Esse modelo apresentado é o padrão que o IEEE indica.
Cockburn (2005) apresenta uma complementação a este
modelo, onde utiliza um modelo semelhante ao modelo do
IEEE, acrescido de um capítulo para descrição de casos de
uso que implementem os requisitos funcionais especificados.

Casos de uso representam a interação do sistema com seus
usuários e servem como um meio de comunicação entre os
envolvidos no projeto e são geralmente descritos em forma
textual, embora possam ser descritos de outra maneira, tal
como fluxogramas, diagramas, entre outras. Assim, utilizando
casos de uso, o usuário revê os diagramas e as especificações
para determinar se o analista realmente capturou os requisitos
do sistema. Por este motivo, é essencial que os diagramas e
as especificações mostrem ao usuário os aspectos essenciais
para que o software seja desenvolvido. Dessa forma, o modelo
do IEEE ganha um capítulo para facilitar a fase de validação
junto aos stakeholders.
Então, com essa proposta, o documento de requisitos utili-
zado terá o aspecto apresentado na Figura 4.
Figura 4. ��������� ������� �� ������ �� �������� ������ ���� � ����
Com este modelo, pretende-se construir um documento com-
pleto, que consiga atingir de forma objetiva e completa todos
os requisitos do software, além de utilizar os casos de uso para
mostrar ao usuário o software que será projetado. De acordo
com a Figura 4, foram inseridos dois itens, um para os diagra-
mas de caso de uso, que deve seguir o padrão da UML (Unified
Modeling Language), e o outro com a descrição minuciosa
dos casos de uso. Assim, pode-se mostrar aos interessados no
projeto mais detalhadamente o que se pretende como intuito
de aumentar a acuidade do DERS. Quando um processo de
requisitos é ineficaz, o DERS não reflete as necessidades reais
do cliente, o que gera um software de baixa qualidade. Segundo
estudos, de 40% a 60% de todos os problemas encontrados em
um projeto de software são causados por falhas no processo de
requisitos. Se a fase de engenharia de requisitos for bem feita,
esses problemas poderiam ser detectados e corrigidos a um
custo muito mais baixo. De acordo com o quadro da Figura 5,
o custo para corrigir um defeito na fase de testes supera em
mais de 30 vezes o custo para corrigir a mesma falha durante
a fase de requisitos. Com essa análise, podemos facilmente
detectar que boas práticas de engenharia de requisitos que
procurem evitar a propagação de falhas para outras fases
podem trazer benefícios como a redução de custo do projeto.
Entre estas boas práticas estão a padronização, a inspeção e a
revisão do DERS.
E NG E NHARIA DE RE QU IS ITOS
Figura 5. Custos para Correção de Falhas
Boas Práticas para Construção do DERS
De acordo com o modelo apresentado na Figura 3 (e ampliado
na Figura 4), os itens 1 e 2 abordam outros aspectos do software
e do projeto de software que não são, por si só, requisitos do
software. Esses dois itens devem ser escritos obedecendo as
orientações do IEEE e as especificações da empresa.
O item 3, conforme apresentado na Figura 3, configura-se
então como o capítulo mais importante, pois será através deste
item que o software será especificado e é com base neste item
que o cliente irá validar o produto. Os itens 4 e 5 também são
importantes, pois são uma maneira de mostrar aos stakehol-
ders a primeira visão do projeto.
Requisitos Específicos
No item de Requisitos Específicos (item 3 conforme modelo
apresentado na Figura 4) do DERS devem-se descrever os re-
quisitos de software, que serão funcionais e não-funcionais.
Os requisitos funcionais são aqueles que dizem respeito à
funcionalidade do software, o que ele deve fazer. Esses re-
quisitos descrevem como o sistema deve reagir a particulares
entradas e saídas e como deve agir em determinadas situações.
Se necessário, também podem ser incluídos requisitos que ex-
pliquem o que o sistema não será capaz de fazer. Os requisitos
não-funcionais são restrições aos serviços e funções oferecidos
pelo sistema. Geralmente se aplicam ao sistema como um
todo e não são, geralmente, aplicados individualmente a uma
característica ou serviço do sistema. Entre esses requisitos se
encontram, por exemplo, os requisitos de desempenho, de
segurança, de entrada e saída, entre outros.
Descrever bem estes requisitos é fundamental para que o DERS
se torne um bom DERS, pois serão estes os requisitos implemen-
tados pelos casos de uso que serão diagramados e desenhados
nos diagramas e especificações dos casos de uso (itens 4 e 5
conforme modelo apresentado na Figura 4). Entretanto, nem
sempre é fácil descrever tais requisitos e sua forma depende
muito do software que está sendo descrito [2]. É difícil então
escolher um padrão geral para criação destes requisitos.
Edição 27 - Engenharia de Software Magazine 17
 Porém, apesar das diferenças entre cada projeto de software,
que irão gerar requisitos muito diferentes em cada DERS, o
IEEE apresenta algumas características que devem ser comuns
a todos os requisitos. O IEEE recomenda que um requisito
deve ser correto, não ambíguo, completo, consistente, veri-
ficável, modificável e rastreável. Ainda é recomendável que
os requisitos sejam organizados de forma a facilitar a leitura
do documento. Isso pode ser feito agrupando requisitos que
tenham alguma funcionalidade em comum.
Diagrama de Casos de Uso
O diagrama de casos de uso deve mostrar, graficamente, to-
das as funções que um sistema precisará desempenhar e, para
sua construção, deve obedecer aos padrões da UML.
De maneira geral, os casos de uso deverão ter a mesma no-
menclatura das funções listadas no item 2.2 do modelo pro-
posto (Figura 4). Esta prática é recomendada de forma a gerar
um documento sem ambiguidades e que será mais facilmente
lido pelo usuário.
Cada categoria de usuário do sistema, desde que tenha um
nível de acesso diferente, deve ser representada por um ator
que irá ter acesso às funções do sistema representadas pelos
casos de uso. Cada um desses casos de uso será descrito no
item 5 da especificação.
Descrição dos Casos de Uso
Os casos de uso são muito indicados para o DERS porque
rapidamente se aprende a ler um caso de uso. “Os casos de
uso são [...] populares porque contam uma história coerente
de como o sistema irá se comportar em uso. Os usuários do
sistema conseguem ver o que este novo sistema será” [2]. Com
um caso de uso bem feito, é possível mostrar aos usuários o
que o sistema se propõe a fazer e validar com o usuário se esta
perspectiva está correta.
Um caso de uso é escrito em linguagem natural e é constituído
por uma sequência de sentenças. Estes passos são compostos
por ações simples, que descrevem o ator realizando uma ta-
refa ou passando informação para um outro ator. Um caso de
uso tem normalmente, ao menos, dois finais possíveis, um de
sucesso e outro de erro. Um caso de uso sempre será respon-
sável por implementar, pelo menos, um requisito funcional
do sistema. Todos os requisitos funcionais do sistema devem
estar ligados a um ou mais casos de uso. Essas ligações entre
casos de uso e requisitos é necessária para permitir a rastre-
abilidade dos requisitos. Uma vez que um requisito mude, é
possível, através dos casos de uso aos quais ele está ligado, ver
qual o impacto da mudança e aplicá-la a todo o documento,
mantendo-o íntegro.
Um caso de uso pode especificar objetivo, requisitos im-
plementados, atores, prioridade, pré-condições, frequência
de uso, pós-condições, fluxo principal, fluxos alternativos,
fluxos de exceção, validações, regras de negócio e protótipo
de interfaces. Algumas dessas informações podem ser supri-
midas e consideradas opcionais, dependendo do sistema que
está sendo especificado.
18 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos
O objetivo de um Caso de Uso (UC – Use Case) deve descre-
ver para que serve esse UC em poucas palavras. Os requisitos
implementados representam a ligação dos requisitos especi-
ficados no item de Requisitos Específicos (item 3) com o UC
que está sendo descrito. Os atores são os usuários específicos
do UC e deve ser um dos usuários do sistema. A prioridade
de um UC normalmente é descrita como Alta, Média ou Baixa,
assim como a frequência de uso, e essas duas informações serão
importantes no momento de desenvolvimento do software,
caso seja necessário priorizar o desenvolvimento de parte do
software. As pré-condições dizem respeito às condições que
deverão ser respeitadas antes do início do caso de uso, ou seja,
como o caso de uso não será chamado caso esta restrição não
seja cumprida, essas condições não irão gerar fluxo de exceção
e não precisarão de validação. Mas é importante tomar cuida-
do, uma condição que nem sempre é verdadeira não pode ser
classificada como uma pré-condição. Caso uma condição seja
verdadeira com algumas ressalvas deve-se criar uma validação
referente a isto e gerar fluxos de exceção, e não apontá-la como
uma pré-condição. A pós-condição descreve em que o caso de
uso modificou o sistema.
Os fluxos são a parte principal do caso de uso. Um caso de
uso deve conter todos os cenários, tanto de sucesso quanto
de falha. A melhor maneira de organizar o texto é escrever o
cenário de sucesso principal, ou fluxo principal, como uma
sequência numerada simples de passos que é executada do
acionamento até a conclusão. Depois disso, devem-se descrever
os outros cenários, sendo os cenários de sucesso alternativos,
chamados de fluxos alternativos, e os cenários de falha, cha-
mado de fluxos de exceção.
Algumas boas práticas para escrever um caso de uso de
forma eficaz são [2]:
• Utilizar gramática simples: o principal objetivo do UC é
mostrar, de forma clara, o que o sistema faz. Se um texto com-
plexo for escrito para descrever esse UC, o seu entendimento
será prejudicado.
• Mostrar claramente quem são os atores: mostrando claramen-
te quais são os atores do UC, fica mais fácil para os stakeholders
compreenderem o UC e as suas funções.
• Incluir todas as ações: na descrição do UC não adianta
apenas colocar a descrição de sucesso do mesmo. É preciso
colocar todas as ações, de sucesso e de falha. Todas as ações
que puderem ser tomadas pelos atores poderão gerar caminhos
alternativos, e esses devem ser descritos.
• Validar (nunca verificar): o termo validar é preferível ao
termo verificar, pois deixa claro que o sistema irá validar os
dados inseridos de acordo com as regras de negócio e restrições
para os valores.
• Mencionar o tempo apenas opcionalmente: não é obrigatório
mencionar o tempo, pois fica implícito que um passo ocorre
logo após o anterior.
Os erros mais comuns são estender desnecessariamente os
casos de uso e descrever com uma precisão desnecessária,
omitir o sujeito das sentenças (omitindo também o ator), fazer
 E NG E NHARIA DE RE QU IS ITOS

suposições sobre o projeto de interface com o usuário e usar

níveis de objetivos que são muito baixos.
Ou seja, ser muito específico é ruim, pois tende a aumentar
desnecessariamente a complexidade do projeto, entretanto,
Figura 6. Exemplo de Requisitos Funcionais
também não se deve ser objetivo demais, omitindo pontos
importantes do caso de uso.
Cockburn (2005) diz que “há apenas um formato de sentença
usado na escrita de passo de ação no caso de uso: uma sentença
no presente, com verbo ativo na voz ativa, descrevendo um
ator alcançando com sucesso um objetivo que move o processo
adiante”. Um bom exemplo disso é: “O ator seleciona a opção
Incluir Cliente.”

A Inspeção do DERS Figura 7. ������� �� �������� �� ���� �� ���

A inspeção do DERS é muito importante para o sucesso do
DERS e deve avaliar o documento como um todo em busca Após elicitar os requisitos, especificá-los e criar um diagrama
de defeitos antes da validação junto ao cliente e usuários. Os de casos de uso que o implemente, é necessário descrever o
erros encontrados em um DERS podem ser: caso de uso conforme pode ser observado na Figura 8.
• Omissão: é todo erro relativo a alguma informação que não
foi descrita, ou seja, que não está presente no DERS. Pode
ser algum requisito que não foi incluído, falta de resposta do
sistema a alguma situação, falta da definição de termos, entre
outras omissões.
• Ambiguidade: ocorre sempre que alguma informação estiver
descrita de forma a poder causa confusão ou dúvida.
• Inconsistência: é alguma sentença que contradiz algo que
foi dito anteriormente no documento.
• Fato Incorreto: é quando um fato descrito no DERS não é
verdadeiro ou não pode ser executado, de acordo com as con-
dições especificadas no domínio da aplicação.
• Informação Estranha: são as informações que não pertencem
ao DERS, não sendo necessárias para o entendimento do mesmo.
Esse problema também contempla as informações que são pas-
sadas, mas não são utilizadas em nenhum momento no DERS.

É altamente recomendável que a inspeção do DERS seja feita

por um outro profissional, que não o responsável por criar o
DERS.

Estudo de Caso
Com base na estrutura apresentada, apresentaremos a partir
de agora um estudo de caso.

Construção do DERS Figura 8. ��������� �� ���� �� ���

O primeiro passo é descrever todos os requisitos do sistema,
que devem ser elicitados com os stakeholders. Levando em con-
ta que neste estudo de caso deseja-se apenas realizar o login,
então se devem descrever apenas os requisitos diretamente
ligados a esta funcionalidade. Ao conversar com os stakehol-
ders do projeto, o seguinte cenário foi obtido (Figura 6).
Nota-se que apenas um requisito foi levantado. Tendo os re-
quisitos especificados, deve-se construir o diagrama de casos
de uso que irá implementar estes requisitos antes da descrição
de tais casos de uso. Levando-se em conta o requisito apurado,
o diagrama da Figura 7 é o suficiente para implementá-lo.
Com base nas prerrogativas e modelo mostrados anterior-
mente, construiu-se a descrição acima. Pode-se visualizar
um quadro com as informações básicas descritas. Há ainda a
descrição dos campos do formulário Login, que é parte deste
caso de uso, e o Fluxo Principal – que são as ações do ator
dentro do caso de uso.
Inspeção do DERS
A inspeção do DERS, como dito anteriormente, deve ser
feita por outros membros da equipe, que não aquele que foi

Edição 27 - Engenharia de Software Magazine 19

responsável por sua criação. Esta pessoa terá maior facilidade
em encontrar os defeitos do documento, pois terá que entender
o documento com sua leitura, e através deste exercício poderá
conseguir encontrar defeitos. Os defeitos de um DERS o tornam
de difícil compreensão.
Ao ler o fragmento de DERS apresentado, percebe-se que não
há fluxos alternativos, mostrando os caminhos alternativos de
sucesso e de falha. A Figura 9 mostra os possíveis caminhos
alternativos que deveriam estar no documento.
Figura 9. Exemplo de Caminhos Alternativos
O Fluxo Principal também deve ser alterado para indicar
em que momento ocorrem os fluxos alternativos. O Fluxo
Alternativo [A1], por exemplo, ocorre no passo 3 do Fluxo
Principal, pois o ator, ao invés de escolher a opção Login,
escolhe a opção Cancelar. O mesmo vale para o [A2]. Já os
Fluxos de Exceção normalmente ocorrem no passo que con-
tiver o termo “validar”. Neste exemplo, os Fluxos de Exceção
[E1] e [E2] ocorrerão no passo 4. O Fluxo Principal ficará como
mostrado na Figura 10.
Figura 10. ������� �� ����� ��������� ��� ������� ���� ��������
Alternativos
Uma leitura minuciosa e detalhista é importante para detec-
tar todos os eventuais defeitos que possam existir no DERS.
Consultando a Figura 7, pode-se notar que o caso de uso foi
denominado “Entrar no Sistema”, enquanto na descrição do
mesmo (Figura 8), percebe-se que o termo utilizado foi “Rea-
lizar login”. Este é, geralmente, um dos defeitos mais comuns
em um DERS, tratando-se de uma inconsistência. Quando se
trata de um sistema pequeno como o descrito neste exemplo,
é fácil perceber que o caso de uso do diagrama é o caso de
uso que está sendo descrito. Porém, este problema torna-se
ainda mais grave quando pensado em um sistema maior. A
terminologia empregada deve obedecer a um padrão. Neste
caso, deve-se escolher apenas um dos dois termos e utilizá-
20 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos
los ao longo de todo o DERS para descrever o caso de uso.
Pode-se mudar no diagrama ou na descrição, mas os dois têm
que ter a mesma nomenclatura.
Outro tipo de defeito – ambiguidade – pode ser notado
durante a descrição do caso de uso. Na descrição dos campos
está escrito que existe um campo Nome, porém ao visualizar
o protótipo da tela, percebe-se a existência de um campo
Usuário, e nenhum campo Nome. Esses termos também não
podem diferir, pois atrapalham o entendimento do DERS. A
mesma coisa para a opção Entrar descrita na seção Campos,
que é chamada Opção Login na seção Fluxo Principal, e é
desenhada como um botão Login no formulário. A diversi-
dade de vocabulário pode ser uma fonte de inconsistências
no documento, gerando ambiguidade. Um só termo utilizado
para denominar diversos elementos, ou vários termos para
determinar uma mesma situação, pode gerar interpretações
errôneas.
Outro erro incomum é o de Omissão. Observa-se na Figura 8
que não existe uma opção para recuperação de senha. Essa
opção é comum a formulários de login, pois o usuário pode
eventualmente esquecer sua senha e o sistema deve prover
uma maneira de recuperá-la.
Mesmo sabendo-se que é necessário um ponto para recupe-
ração de senha, o Fluxo Alternativo [A2] pode ser visto como
uma Informação Inconsistente, pois com base no presente
documento, não pode ser executada.
Analisando o protótipo de tela proposto, ainda é possível
encontrar um outro defeito, que pode ser categorizado com
um Fato Estranho. Nota-se que o formulário tem três botões,
sendo que apenas dois dos quais estão sendo utilizados e
descritos pelo caso de uso. O terceiro botão “Fechar” parece
ser um botão que está sobrando e, por isso, configura-se
como um defeito.
Ainda é possível encontrar outros defeitos com uma lei-
tura atenciosa. Por exemplo, quais são os níveis de acesso?
Esse é um defeito de omissão. Pode ser que, ao completar o
DERS, essa definição fosse feita, mas nesse momento ela não
existe. É sempre importante delimitar o software, de forma
que não sejam encontradas omissões ou ambiguidades. Um
documento íntegro é muito importante para a construção de
um bom software.
Categorizar defeitos é um processo um pouco subjetivo e
depende da interpretação do inspetor do documento. Por isso
é importante fazer uma leitura minuciosa e atenta, marcando
os defeitos encontrados e justificando-os, para que posterior-
mente o DERS possa ser revisado pelo seu construtor.
Considerações Finais
A Engenharia de Requisitos tem como um de seus objeti-
vos a criação do Documento de Especificação de Requisitos
de Software (DERS). O DERS é construído com o intuito de
conseguir descrever o que o usuário deseja antes de começar
a implementar o projeto.
Quando um DERS é bem construído, através de sua avalia-
ção junto aos stakeholders do projeto, é possível descobrir se
 E NG E NHARIA DE RE QU IS ITOS

os interesses dos mesmos foram corretamente entendidos, Referências Bibliográficas

fazendo as necessárias correções a um custo muito inferior
se comparado a custos em outras etapas do projeto.
Criar um bom DERS nem sempre é fácil, mas seguindo al-
gumas diretrizes, como as do IEEE, pode-se criar um DERS
consistente e completo. Adicionando casos de uso ao DERS
ainda é possível chegar mais próximo aos stakeholders, pois
trata-se de uma linguagem de entendimento mais fácil.
Algumas boas práticas facilitam a criação de um caso de
COCKBURN, Alistair. Escrevendo Casos de Uso Eficazes. Bookman, Porto Alegre: 2005.
SOMMERVILLE, Ian. Software Engineering 8th. 8ª ed. Pearson: Essex, England: 2007.
PRESSMAN, Roger S. Software Engineering - A Practitioner’s Approach. 5ª ed. Mc Graw Hill:
Boston, Estados Unidos: 2001.
Dê seu feedback sobre esta edição! Feedback
eu

s
Dê
uso eficaz, que será capaz de fornecer aos interessados no A Engenharia de Software Magazine

sobre e
projeto todas as informações que estes precisam, de maneira tem que ser feita ao seu gosto.

s
ta
objetiva e completa.
edição
Para isso, precisamos saber o que você, leitor, acha da revista!
Com um DERS completo, não ambíguo e objetivo, um projeto Dê seu voto sobre este artigo, através do link:
tem maiores chances de chegar ao resultado esperado pelos
www.devmedia.com.br/esmag/feedback
stakeholders, ou seja, ter sucesso.

Edição 27 - Engenharia de Software Magazine 21