BOAS PRATICAS NA ENGENHARIA DE REQUISITOS

Prévia do material em texto

3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 1/15
DevMedia - Versão para impressão
Boas Práticas na Engenharia de
Requisitos
Nauane Karoline Brazolino Dias
Graduanda do curso de Bacharelado em Sistemas 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 Ontologia de Domínio Para Workflow Científico.
Marco Antônio Araújo
Doutorando e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista
em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em
Informática pela UFJF.
De que se trata o artigo:
 Este artigo objetiva a apresentação de padrões para construção de Documento de
Especificação de Requisitos 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 stakeholders 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:
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 2/15
 Em projetos de software, a Engenharia de Requisitos é 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.
 
[abrir imagem em janela]
Figura 1. O processo de Engenharia de Software [3]
 Com 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 empresas. 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 produto 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 previsibilidade 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 engenharia
aplicada ao desenvolvimento de software, compreendendo um conjunto 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 descoberta se tais requisitos realmente definem o sistema tal como o
usuário deseja (validação).
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 3/15
 Na Figura 1 pode ser visto um processo de Engenharia de Software como um todo,
conhecido como Ciclo de Vida Clássico, que também pode ser executado várias vezes como
parte integrante de um ciclo de vida iterativo e incremental.
 
[abrir imagem em janela]
Figura 2. Processo de Engenharia de Requisitos [2]
Esse modelo representa o processo de Engenharia de Software como um todo e envolve as
atividades [3]:
- Análise de requisitos do software: É nessa fase que a Engenharia 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. 
- 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álise. Na Figura 2, pode-se ver a representação do processo de
Engenharia de Requisitos. 
O processo é iterativo, ou seja, pode-se voltar a uma fase que já foi feita, como em uma
espiral. As três fases principais (elicitação, especificação e validação) são divididas em
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 4/15
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 Engenharia 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
sistema 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 Especificação de Requisitos
de Software (DERS) é considerado pronto e passa-se para a próxima fase do processo de
Engenharia de Software.
 
[abrir imagem em janela]
Figura 3. Estruturado DERS
 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 elicitaçã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écnicas para tornar a construção destes requisitos mais eficaz.
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 5/15
 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 Electronics 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 Requirements 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.
- 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 documentos que forem referenciados
em outros locais do DERS, identificando cada um por autor, título, data, editora, organização,
e outros atributos quando aplicáveis. 
- Visão Global (1.5): deve apresentar de forma sucinta e resumida 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 frequentemente, 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 principais funções que o software irá
executar. 
- Características do usuário (2.3): deve descrever as características gerais dos usuários do
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 6/15
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, controles
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 requisitos 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.
 
[abrir imagem em janela]
Figura 4. Estrutura baseada no modelo de Cockburn (2005) para o DERS
 
[abrir imagem em janela]
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 7/15
Figura 5. Custos para Correção de Falhas
 Então, com essa proposta, o documento de requisitos utilizado terá o aspecto apresentado
na Figura 4.
 Com este modelo, pretende-se construir um documento completo, 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 diagramas 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áticasestão a padronização, a inspeção e a revisão do DERS.
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
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 8/15
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 stakeholders 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 requisitos 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 requisitos 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 expliquem 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 implementados 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.
 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, verificá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, todas 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 nomenclatura das funções listadas
no item 2.2 do modelo proposto (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
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 9/15
sentenças. Estes passos são compostos por ações simples, que descrevem o ator realizando
uma tarefa 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á
responsá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 rastreabilidade
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 implementados, 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 suprimidas e consideradas opcionais, dependendo do sistema que está sendo
especificado.
 O objetivo de um Caso de Uso (UC - Use Case) deve descrever para que serve esse UC em
poucas palavras. Os requisitos implementados representam a ligação dos requisitos
especificados 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 cuidado, 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, chamado 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 complexo for escrito para descrever esse UC, o seu entendimento
será prejudicado.
- Mostrar claramente quem são os atores: mostrando claramente 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
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 10/15
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
suposições sobre o projeto de interface com o usuário e usar níveis de objetivos que são
muito baixos.
 
[abrir imagem em janela]
Figura 6. Exemplo de Requisitos Funcionais
 Ou seja, ser muito específico é ruim, pois tende a aumentar desnecessariamente a
complexidade do projeto, entretanto, 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
A inspeção do DERS é muito importante para o sucesso do DERS e deve avaliar o documento
como um todo em busca de defeitos antes da validação junto ao cliente e usuários. Os erros
encontrados em um DERS podem ser: 
- 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 condiçõ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 passadas, 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
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 11/15
 O primeiro passo é descrever todos os requisitos do sistema, que devem ser elicitados com
os stakeholders. Levando em conta 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 stakeholders do projeto, o seguinte cenário foi obtido
(Figura 6).
 Nota-se que apenas um requisito foi levantado. Tendo os requisitos especificados, deve-se
construir o diagrama de casos de uso que irá implementar estes requisitos antes da descrição
de tais casos de uso. 
 
[abrir imagem em janela]
Figura 7. Exemplo de Diagrama do Caso de Uso
 
[abrir imagem em janela]
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 12/15
Figura 8. Descrição do Caso de Uso
 
[abrir imagem em janela]
Figura 9. Exemplo de Caminhos Alternativos
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 13/15
Levando-se em conta o requisito apurado, o diagrama da Figura 7 é o suficiente para
implementá-lo.
 Após elicitar os requisitos, especificá-los e criar um diagrama de casos de uso que o
implemente, é necessário descrever o caso de uso conforme pode ser observado na Figura 8.
 Com base nas prerrogativas e modelo mostrados anteriormente, 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 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.
 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 contiver o termo "validar".
Neste exemplo, os Fluxos de Exceção [E1] e [E2] ocorrerão no passo 4. 
 
[abrir imagem em janela]
Figura 10. Exemplo de Fluxo Principal com Ligação para Caminhos Alternativos
O Fluxo Principal ficará como mostrado na Figura 10.
 Uma leitura minuciosa e detalhista é importante para detectar 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 "Realizar 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á-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
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 14/15
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 diversidade 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 recuperaçã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 leitura 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 posteriormente o DERS possa ser
revisado pelo seu construtor.
Conclusão
 A Engenharia de Requisitos tem como um de seus objetivos 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 os interesses dos mesmos foram corretamente entendidos,
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 algumas 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
3/4/2014 DevMedia - Versão para impressão
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=2817&revista=impressao_27#a-2817 15/15
entendimento mais fácil.
 Algumas boas práticas facilitam a criação de um caso de uso eficaz, que será capaz de
fornecer aos interessados no projeto todas as informações que estes precisam, de maneira
objetiva e completa.
 Com um DERS completo, não ambíguo e objetivo, um projeto tem maiores chances de chegar
ao resultado esperado pelos stakeholders, ou seja, ter sucesso.