Engenharia

Nesta seção você encontra artigos voltados para testes, processo,

modelos, documentação, entre outros.

Boas Práticas na Engenharia de Requisitos

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

C
Nauane Karoline Brazolino om os avanços tecnológicos que práticas para sua elaboração, de forma a facilitar a
Dias vem ocorrendo nas últimas dé- comunicação entre os stakeholders.
naniedias@gmail.com
cadas e a visível diminuição do
Graduanda do curso de Bacharelado em Sis-
temas de Informações pelo Centro de Ensino custo do hardware, a informação passa Para que serve?
Superior de Juiz de Fora (CES/JF).Estagiária da a ser um recurso estratégico das empre- Obedecendo a padrões para desenvolvimento do
Prefeitura de Juiz de Fora e integrante do grupo sas. O software se tornou, então, a força DERS, esse documento apresentará melhor qualidade,
de pesquisa do projeto Modelagem de Ontolo- motora desta nova era. A integridade das representando, consequentemente, o que os stakehol-
gia de Domínio Para Workflow Científico.
informações oferecidas por um software ders esperam do projeto de software que está sendo
Marco Antônio Pereira Araújo pode diferenciar uma empresa de suas desenvolvido, tornando possível que o projeto seja
maraujo@devmedia.com.br concorrentes. implementado com maior possibilidade de sucesso,
Doutor e Mestre em Engenharia de Sistemas O software é capaz de manipular o pro- abrangendo as necessidades dos usuários.
e Computação pela COPPE/UFRJ. Especialis- duto mais importante para uma empresa
ta em Métodos Estatísticos Computacionais – a informação, e por isso é tão caro. Para Em que situação o tema é útil?
e Bacharel em Matemática com Habilita-
ção em Informática pela UFJF. Professor e
evitar que a parte mais cara dos sistemas Em projetos de software, a Engenharia de Requisi-
Coordenador do curso de Bacharelado em computadorizados fosse desenvolvida tos é normalmente empregada como uma das fases
Sistemas de Informação do Centro de Ensino com baixa qualidade e pouca previsi- preliminares. É através da Engenharia de Requisitos
Superior de Juiz de Fora. Professor do curso bilidade de custo e recursos, surgiram que os analistas descobrem as reais necessidades
de Bacharelado em Sistemas de Informação técnicas de Engenharia de Software. do cliente e transferem-nas para o DERS. Utilizando
da Faculdade Metodista Granbery. Professor
do curso de Bacharelado em Ciência da Com-
A Engenharia de Software surgiu com os padrões mostrados neste artigo, é possível criar
putação da Faculdade Governador Ozanam o objetivo de definir e aplicar métodos um DERS com maior qualidade.
Coelho. Professor e Diretor do Curso Superior que pudessem ajudar no processo de
de Tecnologia em Análise e Desenvolvimento construção, manutenção e implantação
de Sistemas da Fundação Educacional D.An- de software. engenharia aplicada ao desenvolvimento
dré Arcoverde. Analista de Sistemas da Pre-
feitura de Juiz de Fora. Editor da Engenharia
A Engenharia de Software pode ser de software, compreendendo um con-
de Software Magazine. entendida, então, como a disciplina de junto de etapas que envolvem métodos,

14 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos

 E NG E NHARIA DE RE QU IS ITOS

ferramentas e procedimentos que possibilitam o controle do • Suporte: O software certamente irá precisar de modifica-
processo de desenvolvimento de software, ocupando-se de ções após ser entregue ao cliente. Essas modificações podem
todos os aspectos, desde os estágios iniciais de especificação ocorrer por causa de erros que tenham sido encontrados, novas
do sistema até a manutenção desse sistema, oferecendo ao funcionalidades, melhoria de desempenho ou adaptação de
profissional uma base para a construção de software de alta funcionalidades existentes.
qualidade produtivamente.
A Engenharia de Requisitos pode ser vista como uma sub-área Neste “modelo” de Engenharia de Software, a Engenharia
da Engenharia de Software, cujo principal objetivo é a obtenção de Requisitos encontra-se na primeira fase - a fase de Análi-
de uma especificação correta e completa dos requisitos. se. Na Figura 2, pode-se ver a representação do processo de
Este artigo propõe apresentar a Engenharia de Requisitos 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 Figura 2. Processo de Engenharia de Requisitos [2]
integrante de um ciclo de vida iterativo e incremental.
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
Figura 1. O processo de Engenharia de Software [3] Requisitos de Negócio. E a fase de Validação foi dividida em
Estudo de Viabilidade, Prototipação e Revisões.
Esse modelo representa o processo de Engenharia de Softwa- Acompanhando a linha de evolução dos processos de Enge-
re como um todo e envolve as atividades [3]: nharia de Requisitos, começa-se com a elicitação dos requisitos
• Análise de requisitos do software: É nessa fase que a Enge- de usuário e a especificação dos requisitos de negócio para
nharia de Requisitos é aplicada. Os requisitos do sistema são realizar um estudo de viabilidade. Concluído este processo, é
coletados baseados no conhecimento de domínio do software, feita a elicitação dos requisitos do sistema, a especificação dos
assim como funções requeridas, comportamento, desempenho requisitos do usuário e a especificação dos requisitos de siste-
e interface. ma e modelagem. Nesse ínterim é possível reavaliar alguma
• Projeto: projeto de software é na verdade um processo de pendência nos processos feitos anteriormente, visando uma
vários passos que foca em quatro atributos distintos: estrutura melhoria dos mesmos. O próximo passo é a prototipação, que
de dados, arquitetura do software, representação de interface irá mostrar aos stakeholders um primeiro cenário do software.
e detalhes de procedimentos (algorítmicos). Em seguida são feitas as revisões apuradas na validação feita
• Codificação: o projeto é traduzido em linguagem de máquina com os stakeholders. Caso esteja tudo feito de acordo com as
através de uma linguagem de programação. pretensões dos interessados no projeto, o Documento de Es-
• Testes: Os testes focam em descobrir erros e definir que pecificação de Requisitos de Software (DERS) é considerado
determinadas entradas irão realmente produzir os resultados pronto e passa-se para a próxima fase do processo de Enge-
esperados. 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- Figura 3. Estrutura do DERS
tação, tais como requisitos incompletos, mal entendidos ou
ambíguos. Faz-se necessário então que esses requisitos sejam • Escopo (1.2): deve especificar o produto software a ser
bem construídos de maneira que expressem exatamente o produzido, nomeando-o; explicar o que o produto irá fazer e,
que o usuário deseja, da maneira que ele deseja e a forma se necessário, o que não irá fazer, descrever as aplicações do
como poderá ser feito. Por isso é importante conhecer técni- software que está sendo especificado, incluindo benefícios,
cas para tornar a construção destes requisitos mais eficaz. objetivos e metas relevantes.
Todo o trabalho feito nas fases iniciais de Engenharia de • Definições, siglas e abreviaturas (1.3): deve prover a definição
Requisitos (viabilidade, elicitação, análise e especificação) de todos os termos, siglas e abreviaturas que são necessárias
gera como resultado o DERS. O DERS é o documento oficial para entender este DERS.
do que deverá ser implementado pelos desenvolvedores do • Referências (1.4): deve prover uma lista de todos os docu-
sistema [2]. mentos que forem referenciados em outros locais do DERS,
identificando cada um por autor, título, data, editora, organi-
O Documento de Especificação de Requisitos de zação, e outros atributos quando aplicáveis.
Software • Visão Global (1.5): deve apresentar de forma sucinta e resu-
O DERS, segundo o IEEE (Institute of Electrical and Elec- mida o que os capítulos restantes do DERS irão tratar.
tronics Engineers), deve ser completo e não ambíguo, sendo • Perspectiva do produto (2.1): deve colocar o produto na
responsável por auxiliar os clientes de software a descrever perspectiva de outros produtos relacionados. Se é um produto
com precisão o que eles desejam obter, e desenvolvedores independente, isso deve ser dito aqui. Caso contrário, se é um
de software a entender exatamente o que o cliente deseja. componente de um sistema maior, o que ocorre frequentemen-
Ainda segundo o IEEE, para os clientes, desenvolvedores e te, então esta subseção deve relatar as interfaces entre esse
outros indivíduos ligados ao projeto, um bom DERS deve software e o sistema, além dos requisitos do sistema maior
prover diversos benefícios, tais como: para a funcionalidade deste software.
• Estabelecer a base de acordo entre os clientes e a empresa • Funções do produto (2.2): deve prover um índice das prin-
fornecedora sobre o que o software irá fazer; cipais funções que o software irá executar.
• Reduzir o esforço de desenvolvimento; • Características do usuário (2.3): deve descrever as caracte-
• Prover uma base para estimativas de custo e prazos; rísticas gerais dos usuários do produto.
• Prover uma base para validação e verificação do produto; • Restrições (2.4): deve descrever qualquer outro item que
• Facilitar a manutenção do produto de software final. limite as opções do produto, tais como políticas de controle,
limitações de hardware, interface com outras aplicações, con-
Um DERS conta com alguns padrões indicados para sua troles de segurança, entre outros itens que forem relevantes.
elaboração. O IEEE elaborou um documento que contém • Pressupostos e Dependências (2.5): deve listar todos os fatores
padrões e práticas recomendadas para a criação do DERS que afetem os requisitos definidos.
chamado IEEE Recommended Practice for Software Re- • Requisitos Específicos (3): contém a definição dos requisi-
quirements Specification - Práticas Recomendadas para a tos de software. É o principal capítulo do DERS, pois é nesta
Especificação de Requisitos de Software. Segundo essas seção que os requisitos funcionais e não funcionais estarão
práticas, o DERS deve ter uma estrutura tal como mostrada definidos.
na Figura 3.
As seções devem, então, ser preenchidas da seguinte Esse modelo apresentado é o padrão que o IEEE indica.
maneira: Cockburn (2005) apresenta uma complementação a este
• Propósito (1.1): deve delinear o propósito particular modelo, onde utiliza um modelo semelhante ao modelo do
deste DERS e especificar para quem está sendo feito esse IEEE, acrescido de um capítulo para descrição de casos de
documento. uso que implementem os requisitos funcionais especificados.

16 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos

 E NG E NHARIA DE RE QU IS ITOS

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 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
Figura 4. ��������� ������� �� ������ �� �������� ������ ���� � ���� importantes, pois são uma maneira de mostrar aos stakehol-
ders a primeira visão do projeto.
Com este modelo, pretende-se construir um documento com-
pleto, que consiga atingir de forma objetiva e completa todos Requisitos Específicos
os requisitos do software, além de utilizar os casos de uso para No item de Requisitos Específicos (item 3 conforme modelo
mostrar ao usuário o software que será projetado. De acordo apresentado na Figura 4) do DERS devem-se descrever os re-
com a Figura 4, foram inseridos dois itens, um para os diagra- quisitos de software, que serão funcionais e não-funcionais.
mas de caso de uso, que deve seguir o padrão da UML (Unified Os requisitos funcionais são aqueles que dizem respeito à
Modeling Language), e o outro com a descrição minuciosa funcionalidade do software, o que ele deve fazer. Esses re-
dos casos de uso. Assim, pode-se mostrar aos interessados no quisitos descrevem como o sistema deve reagir a particulares
projeto mais detalhadamente o que se pretende como intuito entradas e saídas e como deve agir em determinadas situações.
de aumentar a acuidade do DERS. Quando um processo de Se necessário, também podem ser incluídos requisitos que ex-
requisitos é ineficaz, o DERS não reflete as necessidades reais pliquem o que o sistema não será capaz de fazer. Os requisitos
do cliente, o que gera um software de baixa qualidade. Segundo não-funcionais são restrições aos serviços e funções oferecidos
estudos, de 40% a 60% de todos os problemas encontrados em pelo sistema. Geralmente se aplicam ao sistema como um
um projeto de software são causados por falhas no processo de todo e não são, geralmente, aplicados individualmente a uma
requisitos. Se a fase de engenharia de requisitos for bem feita, característica ou serviço do sistema. Entre esses requisitos se
esses problemas poderiam ser detectados e corrigidos a um encontram, por exemplo, os requisitos de desempenho, de
custo muito mais baixo. De acordo com o quadro da Figura 5, segurança, de entrada e saída, entre outros.
o custo para corrigir um defeito na fase de testes supera em Descrever bem estes requisitos é fundamental para que o DERS
mais de 30 vezes o custo para corrigir a mesma falha durante se torne um bom DERS, pois serão estes os requisitos implemen-
a fase de requisitos. Com essa análise, podemos facilmente tados pelos casos de uso que serão diagramados e desenhados
detectar que boas práticas de engenharia de requisitos que nos diagramas e especificações dos casos de uso (itens 4 e 5
procurem evitar a propagação de falhas para outras fases conforme modelo apresentado na Figura 4). Entretanto, nem
podem trazer benefícios como a redução de custo do projeto. sempre é fácil descrever tais requisitos e sua forma depende
Entre estas boas práticas estão a padronização, a inspeção e a muito do software que está sendo descrito [2]. É difícil então
revisão do DERS. 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, O objetivo de um Caso de Uso (UC – Use Case) deve descre-
que irão gerar requisitos muito diferentes em cada DERS, o ver para que serve esse UC em poucas palavras. Os requisitos
IEEE apresenta algumas características que devem ser comuns implementados representam a ligação dos requisitos especi-
a todos os requisitos. O IEEE recomenda que um requisito ficados no item de Requisitos Específicos (item 3) com o UC
deve ser correto, não ambíguo, completo, consistente, veri- que está sendo descrito. Os atores são os usuários específicos
ficável, modificável e rastreável. Ainda é recomendável que do UC e deve ser um dos usuários do sistema. A prioridade
os requisitos sejam organizados de forma a facilitar a leitura de um UC normalmente é descrita como Alta, Média ou Baixa,
do documento. Isso pode ser feito agrupando requisitos que assim como a frequência de uso, e essas duas informações serão
tenham alguma funcionalidade em comum. importantes no momento de desenvolvimento do software,
caso seja necessário priorizar o desenvolvimento de parte do
Diagrama de Casos de Uso software. As pré-condições dizem respeito às condições que
O diagrama de casos de uso deve mostrar, graficamente, to- deverão ser respeitadas antes do início do caso de uso, ou seja,
das as funções que um sistema precisará desempenhar e, para como o caso de uso não será chamado caso esta restrição não
sua construção, deve obedecer aos padrões da UML. seja cumprida, essas condições não irão gerar fluxo de exceção
De maneira geral, os casos de uso deverão ter a mesma no- e não precisarão de validação. Mas é importante tomar cuida-
menclatura das funções listadas no item 2.2 do modelo pro- do, uma condição que nem sempre é verdadeira não pode ser
posto (Figura 4). Esta prática é recomendada de forma a gerar classificada como uma pré-condição. Caso uma condição seja
um documento sem ambiguidades e que será mais facilmente verdadeira com algumas ressalvas deve-se criar uma validação
lido pelo usuário. referente a isto e gerar fluxos de exceção, e não apontá-la como
Cada categoria de usuário do sistema, desde que tenha um uma pré-condição. A pós-condição descreve em que o caso de
nível de acesso diferente, deve ser representada por um ator uso modificou o sistema.
que irá ter acesso às funções do sistema representadas pelos Os fluxos são a parte principal do caso de uso. Um caso de
casos de uso. Cada um desses casos de uso será descrito no uso deve conter todos os cenários, tanto de sucesso quanto
item 5 da especificação. de falha. A melhor maneira de organizar o texto é escrever o
cenário de sucesso principal, ou fluxo principal, como uma
Descrição dos Casos de Uso sequência numerada simples de passos que é executada do
Os casos de uso são muito indicados para o DERS porque acionamento até a conclusão. Depois disso, devem-se descrever
rapidamente se aprende a ler um caso de uso. “Os casos de os outros cenários, sendo os cenários de sucesso alternativos,
uso são [...] populares porque contam uma história coerente chamados de fluxos alternativos, e os cenários de falha, cha-
de como o sistema irá se comportar em uso. Os usuários do mado de fluxos de exceção.
sistema conseguem ver o que este novo sistema será” [2]. Com Algumas boas práticas para escrever um caso de uso de
um caso de uso bem feito, é possível mostrar aos usuários o forma eficaz são [2]:
que o sistema se propõe a fazer e validar com o usuário se esta • Utilizar gramática simples: o principal objetivo do UC é
perspectiva está correta. mostrar, de forma clara, o que o sistema faz. Se um texto com-
Um caso de uso é escrito em linguagem natural e é constituído plexo for escrito para descrever esse UC, o seu entendimento
por uma sequência de sentenças. Estes passos são compostos será prejudicado.
por ações simples, que descrevem o ator realizando uma ta- • Mostrar claramente quem são os atores: mostrando claramen-
refa ou passando informação para um outro ator. Um caso de te quais são os atores do UC, fica mais fácil para os stakeholders
uso tem normalmente, ao menos, dois finais possíveis, um de compreenderem o UC e as suas funções.
sucesso e outro de erro. Um caso de uso sempre será respon- • Incluir todas as ações: na descrição do UC não adianta
sável por implementar, pelo menos, um requisito funcional apenas colocar a descrição de sucesso do mesmo. É preciso
do sistema. Todos os requisitos funcionais do sistema devem colocar todas as ações, de sucesso e de falha. Todas as ações
estar ligados a um ou mais casos de uso. Essas ligações entre que puderem ser tomadas pelos atores poderão gerar caminhos
casos de uso e requisitos é necessária para permitir a rastre- alternativos, e esses devem ser descritos.
abilidade dos requisitos. Uma vez que um requisito mude, é • Validar (nunca verificar): o termo validar é preferível ao
possível, através dos casos de uso aos quais ele está ligado, ver termo verificar, pois deixa claro que o sistema irá validar os
qual o impacto da mudança e aplicá-la a todo o documento, dados inseridos de acordo com as regras de negócio e restrições
mantendo-o íntegro. para os valores.
Um caso de uso pode especificar objetivo, requisitos im- • Mencionar o tempo apenas opcionalmente: não é obrigatório
plementados, atores, prioridade, pré-condições, frequência mencionar o tempo, pois fica implícito que um passo ocorre
de uso, pós-condições, fluxo principal, fluxos alternativos, logo após o anterior.
fluxos de exceção, validações, regras de negócio e protótipo
de interfaces. Algumas dessas informações podem ser supri- Os erros mais comuns são estender desnecessariamente os
midas e consideradas opcionais, dependendo do sistema que casos de uso e descrever com uma precisão desnecessária,
está sendo especificado. omitir o sujeito das sentenças (omitindo também o ator), fazer

18 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos

 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- Com base nas prerrogativas e modelo mostrados anterior-
ta que neste estudo de caso deseja-se apenas realizar o login, mente, construiu-se a descrição acima. Pode-se visualizar
então se devem descrever apenas os requisitos diretamente um quadro com as informações básicas descritas. Há ainda a
ligados a esta funcionalidade. Ao conversar com os stakehol- descrição dos campos do formulário Login, que é parte deste
ders do projeto, o seguinte cenário foi obtido (Figura 6). caso de uso, e o Fluxo Principal – que são as ações do ator
Nota-se que apenas um requisito foi levantado. Tendo os re- dentro do caso de uso.
quisitos especificados, deve-se construir o diagrama de casos
de uso que irá implementar estes requisitos antes da descrição Inspeção do DERS
de tais casos de uso. Levando-se em conta o requisito apurado, A inspeção do DERS, como dito anteriormente, deve ser
o diagrama da Figura 7 é o suficiente para implementá-lo. 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 los ao longo de todo o DERS para descrever o caso de uso.
em encontrar os defeitos do documento, pois terá que entender Pode-se mudar no diagrama ou na descrição, mas os dois têm
o documento com sua leitura, e através deste exercício poderá que ter a mesma nomenclatura.
conseguir encontrar defeitos. Os defeitos de um DERS o tornam Outro tipo de defeito – ambiguidade – pode ser notado
de difícil compreensão. durante a descrição do caso de uso. Na descrição dos campos
Ao ler o fragmento de DERS apresentado, percebe-se que não está escrito que existe um campo Nome, porém ao visualizar
há fluxos alternativos, mostrando os caminhos alternativos de o protótipo da tela, percebe-se a existência de um campo
sucesso e de falha. A Figura 9 mostra os possíveis caminhos Usuário, e nenhum campo Nome. Esses termos também não
alternativos que deveriam estar no documento. 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.
Figura 9. Exemplo de Caminhos Alternativos Mesmo sabendo-se que é necessário um ponto para recupe-
ração de senha, o Fluxo Alternativo [A2] pode ser visto como
O Fluxo Principal também deve ser alterado para indicar uma Informação Inconsistente, pois com base no presente
em que momento ocorrem os fluxos alternativos. O Fluxo documento, não pode ser executada.
Alternativo [A1], por exemplo, ocorre no passo 3 do Fluxo Analisando o protótipo de tela proposto, ainda é possível
Principal, pois o ator, ao invés de escolher a opção Login, encontrar um outro defeito, que pode ser categorizado com
escolhe a opção Cancelar. O mesmo vale para o [A2]. Já os um Fato Estranho. Nota-se que o formulário tem três botões,
Fluxos de Exceção normalmente ocorrem no passo que con- sendo que apenas dois dos quais estão sendo utilizados e
tiver o termo “validar”. Neste exemplo, os Fluxos de Exceção descritos pelo caso de uso. O terceiro botão “Fechar” parece
[E1] e [E2] ocorrerão no passo 4. O Fluxo Principal ficará como ser um botão que está sobrando e, por isso, configura-se
mostrado na Figura 10. 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
Figura 10. ������� �� ����� ��������� ��� ������� ���� ��������
Alternativos um bom software.
Categorizar defeitos é um processo um pouco subjetivo e
Uma leitura minuciosa e detalhista é importante para detec- depende da interpretação do inspetor do documento. Por isso
tar todos os eventuais defeitos que possam existir no DERS. é importante fazer uma leitura minuciosa e atenta, marcando
Consultando a Figura 7, pode-se notar que o caso de uso foi os defeitos encontrados e justificando-os, para que posterior-
denominado “Entrar no Sistema”, enquanto na descrição do mente o DERS possa ser revisado pelo seu construtor.
mesmo (Figura 8), percebe-se que o termo utilizado foi “Rea-
lizar login”. Este é, geralmente, um dos defeitos mais comuns Considerações Finais
em um DERS, tratando-se de uma inconsistência. Quando se A Engenharia de Requisitos tem como um de seus objeti-
trata de um sistema pequeno como o descrito neste exemplo, vos a criação do Documento de Especificação de Requisitos
é fácil perceber que o caso de uso do diagrama é o caso de de Software (DERS). O DERS é construído com o intuito de
uso que está sendo descrito. Porém, este problema torna-se conseguir descrever o que o usuário deseja antes de começar
ainda mais grave quando pensado em um sistema maior. A a implementar o projeto.
terminologia empregada deve obedecer a um padrão. Neste Quando um DERS é bem construído, através de sua avalia-
caso, deve-se escolher apenas um dos dois termos e utilizá- ção junto aos stakeholders do projeto, é possível descobrir se

20 Engenharia de Software Magazine - Boas Práticas na Engenharia de Requisitos

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