ENGENHARIA DE REQUISITOS

CLEYTON V. C. MAGALHÃES
 CLEYTON V. C. MAGALHÃES

ENGENHARIA DE REQUISITOS

1.ª EDIÇÃO

RECIFE
FACULDADE SÃO MIGUEL
2019
Copyright © 2019 Faculdade São Miguel. Todos os direitos reservados.

Direção geral
Maria Antonieta Alves Chiappetta

Direção editorial
George Bento Catunda

Capa, projeto gráfico e editoração eletrônica

George Bento Catunda

Revisão
Annara Mariane Perboire da Silva
Cleyton Vanut C. de Magalhães

Editora responsável
Faculdade São Miguel
1.ª Edição – 2019

Dados Internacionais de Catalogação na Publicação (CIP) de acordo com ISDB

M188e
Magalhães, Cleyton V.C.
Engenharia de requisitos / Cleyton V.C. Magalhães. Recife: Faculdade São
Miguel, 2019.
33 p.: il.

Inclui referências bibliográficas.

Material produzido para os cursos EAD da Faculdade São Miguel.

1. Engenharia de requisitos. 2. Requisitos não-funcionais. 3.

Adaptação dinâmica. 4. Requisitos de qualidade. 5. Especificação de
requisitos. 6. Elicitação de requisitos. I. Título.

CDU – 004.414.22

Elaborado por Hugo Carlos Cavalcanti | CRB-4 2129

SUMÁRIO

1. CONTEXTUALIZANDO OS REQUISITOS DE SOFTWARE ....................................................... 7

1.1Introdução ................................................................................................................................ 7
1.2 Os requisitos no processo de desenvolvimento ...................................................................... 9
1.3 Tipos de requisitos ................................................................................................................ 12

2. O PROCESSO DA ENGENHARIA DE REQUISITOS ............................................................... 16

3. DOCUMENTO DE REQUISITOS .............................................................................................. 25

CONCLUSÃO ................................................................................................................................ 31

REFERÊNCIAS ............................................................................................................................. 32
APRESENTAÇÃO

Olá! Suponho que você já tenha ouvido falar um pouco sobre o processo de desenvolvimento de
software, certo? Não?! Deixaeu te explicar então: esse processo define o conjunto de atividades que
serão executadas por uma equipe de desenvolvimento de software na construção de um sistema. No
contexto das empresas de desenvolvimento de software, em que muitas possuem vários projetos de
software ao mesmo tempo e grandes equipes de desenvolvimento, definir um processo para determinar e
organizar como, quando e por quem as atividades vão ser feitas é muito importante. Por exemplo: alguém
precisa se reunir com o cliente para entender quais as funcionalidades que ele precisa no sistema, além
disso, é necessário que uma equipe desenvolva o sistema em uma linguagem de programação, e mais
ainda: o sistema precisa ser testado. Tantas atividades, feitas por diferentes pessoas precisam ser
planejadas, coordenadas, executadas e validadas, e por isso é necessário um processo bem definido para
que as coisas sejam feitas e entregues no prazo e com qualidade. As diferentes formas de organizar como
um software vai ser construído são estudadas pela Engenharia de Software, uma disciplina da
computação que se preocupa com a especificação, o desenvolvimento e a manutenção de um sistema
computacional.

No processo de desenvolvimento de software, a primeira etapa é chamada de Engenharia de Requisitos

que, de maneira informal, podemos definir como uma conversa com o interessado na construção do
sistema para coletar o máximo de informações úteis sobre como ele deseja que seja o seu software.
Além de coletar essas informações, é importante como estruturar e organizar estas informações em um
documento para que os programadores possam criar o sistema. Isso mesmo, como os programadores
normalmente não estão nessas conversas com os clientes, eles precisam que as pessoas que as
coletaram (os analistas) documentem essas informações, que são chamadas de requisitos, para que eles
possam usá-las para criar o sistema. Esta é uma das principais etapas do processo, já que, quanto mais
cedo encontramos possíveis erros na elicitação dos requisitos, mais cedo podemos corrigi-los. Preste
atenção nos conceitos apresentados neste caderno e observe os modelos e exemplos usados. Uma dica
importante: Utilize as atividades apresentadas aqui e crie exemplos semelhantes para treinar a elicitação
de requisitos.

Em resumo, o caderno está organizado da seguinte forma: o capítulo 1 uma introdução à etapa de
Engenharia de requisitos e onde ela se encaixa no processo de desenvolvimento de software. O capítulo 2
mostra as atividades realizadas na Engenharia de requisitos. No capítulo 3, você encontrará um modelo e
exemplos de um documento de requisitos, que é utilizado para detalhar todas as informações de um
sistema de informação.

Então, vamos lá?

Bons estudos!

6
1.CONTEXTUALIZANDO OS REQUISITOS DE SOFTWARE

1.1Introdução

Você já visitou alguma empresa de desenvolvimento de software? Já chegou a ver alguma matéria na TV
ou na internet sobre como é uma empresa desse tipo? Caso não conheça tão bem o mercado de software,
vamos entender um pouco esse contexto. As empresas de software são organizações formadas por
pessoas com habilidades técnicas para construir e comercializar sistemas computacionais. Como qualquer
outro tipo empresa, as empresas de software podem variar em relação à quantidade de funcionários, ao
tipo de tecnologias usadas (linguagens de programação, ferramentas) e também em relação aos
processos que ela usa no dia a dia. Por exemplo, uma empresa pode adotar um processo de
desenvolvimento mais tradicional, em que as entregas realizadas ao cliente podem demorar um
determinado tempo, enquanto outra empresa pode preferir práticas ágeis, como o Scrum, que possui
partes do software entregáveis em um prazo mais curto. Seja qual for o modelo de processo usado, a
etapa de coleta de requisitos é uma das mais importantes. Vamos entender essa importância analisando
alguns cenários:

Cenário 1: você precisa fazer um projeto da faculdade para a disciplina de programação. O

professor dividiu a turma em algumas equipes e pediu para que vocês criassem um sistema de vendas de
camisetas. Provavelmente, a equipe conseguiria criar esse sistema em algumas semanas. Nesse caso,
mesmo que o sistema possuísse algumas falhas, mas que realizasse as vendas de camisetas na
apresentação do projeto, os alunos provavelmente passariam na disciplina.
Cenário 2: uma loja que deseja vender suas camisetas online, fazendo entregas para todo o Brasil,
ou seja: um alto fluxo de vendas diárias, processamentos de compras em cartão de crédito, geração de
boletos, agendamento de entregas, sistema de trocas, e muitas outras necessidades que a loja possa vir a
ter. O projeto não parece mais tão simples de fazer como o anterior, certo?

No cenário 2, o dono dessa loja precisaria procurar uma empresa de desenvolvimento de software que
pudesse criar esse sistema para ele. No Brasil o mercado de software tem crescido bastante, e existem
diversas empresas que poderiam ser contratadas pelo dono dessa loja, e ele teria que levar em
consideração muitas coisas para escolher a empresa que o ajudaria a desenvolver o seu sistema, como o
custo e o prazo de entrega do sistema.

7
EXERCÍCIO 1:
Para entender um pouco do mercado de software e saber alguns serviços oferecidos por empresas
desenvolvedoras, imagine que você é o dono da loja de camisetas que mencionei acima e que você quer
vender essas camisetas no Brasil (ou em outros países também, caso você seja mais visionário). Para
isso você precisaria de um sistema online.

Pesquise na internet o termo: "Empresa de desenvolvimento de software".

Navegue pelos sites de empresas que você encontrar e veja os serviços que elas oferecem. Tente
também localizar algumas próximas ao lugar que você mora para ajudar a escolher qual empresa você
entraria em contato para criar este sistema para a loja de camisetas.

No mercado de software quando se tem projetos de escopo grande e que envolvem contratos de alto
custo é preciso definir diversos fatores que possam garantir que ao fim do processo de desenvolvimento, o
software possua um alto nível de qualidade e que principalmente atenda todas às expectativas das
pessoas que vão usá-lo.

Mas por que essas tais "expectativas" precisam ser atendidas? Vamos a um exemplo: você não gostaria
que alguém fizesse um saque em sua conta bancária com uma autenticação falsa, não é mesmo? Outro
caso: usar aquele sistema que trava de 15 em 15 segundos é muito chato, concorda? Pior que isso: os
controladores de um avião no qual você está voando passam por uma pane. Tenso! né? Por isso,
pensando em evitar problemas como esses, que às vezes envolvem um alto risco caso essas falhas
aconteçam, aspectos como segurança, performance, usabilidade e muitos outros relacionados ao bom
funcionamento de um software devem ser muito bem discutidos por todos os stakeholders (pessoas
envolvidas no desenvolvimento) do projeto para garantir que o software faça o que deve fazer. Mas onde
isso tudo começa? Isso mesmo: na produção dos requisitos.

Pesquise por "requisitos de software" na internet, como na figura 1. Você pode encontrar definições para
requisitos como as seguintes: "requisitos são descrições do que o sistema deve fazer", ou como
"necessidades do software do cliente" ou ainda "requisitos são as funcionalidades de um determinado
sistema". E a internet está certa. Requisitos são, de fato, o conjunto de solicitações (demandas ou
especificações) que um cliente deseja que um software que vai ser construído possua.

8
 Figura 1. Definição de requisitos de software. Fonte: Google

Vejamos mais um exemplo: o dono de um hotel quer um sistema online para gerenciar as reservas de
seus hóspedes. Então, um dos requisitos desse sistema seria "Realização de reservas". Neste contexto, o
hóspede poderia também desejar cancelar a reserva, ou alterar a data de sua reserva. Estas ações que o
sistema deve possuir também são requisitos. Os critérios de realização desta reserva, como por exemplo,
se o cliente precisa ter feito login antes de realizar a reserva ou se ele precisa de um código de
confirmação via mensagem SMS para finalizar sua solicitação também são detalhes que precisam ser bem
esclarecidos na definição dos requisitos. Em resumo, os requisitos detalham como um negócio funciona no
mundo real para garantir que o um software que será construído para ser utilizado neste negócio reflita as
atividades e ações realizadas no negócio.

1.2 Os requisitos no processo de desenvolvimento

Definir os requisitos de um software é apenas o começo de um processo bem maior que envolve várias
fases e atividades. Existem diversas formas de organizar estas fases e as atividades que compõem cada
fase (figura 2). Para isso, são usados alguns modelos que definem como a equipe e as atividades devem
ser organizadas para realizar o desenvolvimento. Existem modelos com uma estrutura mais rígida,
chamados tradicionais (como o modelo cascata, por exemplo) e metodologias ágeis, que buscam deixar o
processo mais dinâmico com práticas que visam acelerar o processo de construção do software.

O modelo cascata, citado anteriormente, define que as fases do desenvolvimento devem ser sequenciais,
sendo que uma nova fase é iniciada apenas quando a anterior foi finalizada. Por exemplo, todos os
requisitos do sistema devem ser definidos no começo do projeto e ao finalizar esta fase, passa-se para a
fase de projeto/design. Usando esse método, não é possível retornar para a fase anterior. Isso significa

9
que não é possível retornar à fase anterior caso um requisito precise mudar. Quando um problema é
encontrado na etapa de testes, por exemplo, é preciso retornar à etapa inicial e passar pelas demais fases
novamente. Portanto, é preciso definir muito bem os requisitos no início do projeto. Nesse modelo, o
projeto é entregue ao cliente apenas quando é finalizado. Vale lembrar que o modelo cascata não é o
único modelo tradicional, os modelos iterativo-incremental e evolucionário, por exemplo, surgiram com
base no cascata e também são considerados tradicionais.

Já os métodos ágeis são baseados em práticas iterativas que garantem entregas mais frequentes de
pequenos "pedaços do software" ao cliente. No caso do Scrum, uma das metodologias ágeis mais
utilizadas no mundo, o desenvolvimento é dividido em Sprints, que são espaços de tempo (normalmente
duas semanas) em que determinadas features (requisitos ou funcionalidades) são planejadas,
desenvolvidas, testadas e apresentadas ao cliente. Dessa forma, caso haja problemas ou erros no
desenvolvimento, elas podem ser corrigidas na sprint seguinte. XP, Crystal e FDD também são
considerados métodos ágeis.

EXERCÍCIO 2:
Pesquise sobre modelos de processo de software tradicionais e metodologias ágeis. Considerando o
sistema do cenário 2 do início do capítulo, também usado no exercício 1, qual o modelo de processo você
acredita que seria adequado?

Apesar destas diferenças entre os modelos, as etapas de desenvolvimento em ambos os tipos de

metodologia são basicamente as mesmas. Vejamos então que fases podem compor um processo de
desenvolvimento genérico (figura 2):

Figura 2. Processo genérico de desenvolvimento de software. Fonte: Próprio autor.

Requisitos - Esta é a etapa em que os requisitos são levantados. O analista responsável por esta tarefa
reúne-se com o cliente para entender quais os requisitos que ele deseja que existam no software que vai
ser construído. O responsável por esta atividade pode realizar as seguintes tarefas (que serão mais bem
especificadas mais adiante):

10
 ● Elicitação de requisitos;
● Identificação das fontes de informação;
● Conhecer técnicas de levantamento de requisitos;
● Modelagem;
● Análise de requisitos;
● Validação e verificação;
● Gerência de requisitos.

Projeto/Design:
A fase de projeto e design serve para definir como o sistema será estruturado, de forma a ter
documentações claras que permitam um bom desenvolvimento aos programadores. Aspectos como a
arquitetura do sistema, linguagem de programação que será utilizada, sistema gerenciador de banco de
dados, e outros são definidos nesta fase. Também são criados artefatos (como diagramas UML) que
permitam ter visões gerais e mais específicas do sistema. O diagrama de caso de uso, por exemplo, ajuda
a ter uma visão dos requisitos funcionais de um sistema e os atores responsáveis pela realização destes
requisitos (figura 3).

Figura 3. Diagrama de caso de uso para um sistema bancário simplificado.

Fonte: Próprio autor.

Implementação:
Nesta etapa os requisitos que foram levantados, ou seja, as funcionalidades que o software terá, serão
codificados em uma linguagem de programação para que o sistema possa ser executado.

Testes
A etapa de testes busca a garantia de que o software construído possui qualidade. Neste momento, uma
série de testes é criada e executada de forma a garantir que o sistema funcione de acordo com os
requisitos identificados no começo do processo. Uma série de testes de diversos tipos são projetados e
executados. Se os testes passam, significa que a qualidade do software está adequada e caso falhem, os
bugs encontrados precisam ser resolvidos antes que o software seja entregue ao cliente.
Existem várias categorias de teste, ou seja, maneiras de agrupar casos testes a serem executados no
sistema. Por exemplo: testes funcionais, testes de segurança, testes de performance, testes de carga,
testes de usabilidade, testes de instalação são algumas dessas categorias.

11
Um bom exemplo de um conjunto de testes de segurança pode ser relacionado a um sistema bancário.
Nesse caso seriam necessários testes como apresentados abaixo:

Exemplos de Testes de Segurança de um sistema bancário

- Verificar que uma operação (saque ou depósito) só será realizada após a inserção e validação do
cartão referente àquela conta.
- verificar a autenticação do cliente antes de realizar um saque (senha ou digital);
- verificar se uma operação é cancelada após determinado tempo (20 segundos, por exemplo) de
inatividade no sistema.

Quanto à forma de execução dos testes, estes podem ser feitos das seguintes maneiras:
- manual : o testador executa manualmente os testes. Por exemplo, o testador acessa um website,
faz login na página com credenciais válidas e verifica se o acesso foi liberado.
- automáticos : scripts são criados de forma a realizar os testes automaticamente e seus resultados
validados através de uma ferramenta de automação. O mesmo exemplo de realizar login pode ser
executado automaticamente por um script, que irá preencher automaticamente os campos de
usuário e senha, além de validar se o acesso foi liberado.

A etapa de testes é muito importante para garantir um alto nível de qualidade ao produto, evitar que erros
que tenham sido incluídos em alguma das etapas anteriores persistam no sistema e sejam encontrados
pelo seu usuário final.

Implantação
É a fase em que o software é implantado no ambiente em que ele será executado. Dentre as atividades
que acontecem nesta fase pode-se incluir a liberação, instalação e ativação do produto.

1.3 Tipos de requisitos

Agora que você sabe o que são requisitos e onde eles se encaixam no processo de desenvolvimento de
software vamos entender um pouco mais sobre eles? Como vimos anteriormente, o levantamento (ou seja,
a identificação) dos requisitos de um software acontece logo no início do processo de desenvolvimento,
antes dos programadores começarem a criar o sistema usando uma linguagem de programação. Mas por
onde começar essa identificação? Se você quer ter uma documentação clara, é importante saber que os
requisitos podem ser classificados como:

Requisitos Funcionais: Os requisitos funcionais definem como o sistema deve reagir a determinadas
entradas e como deve se comportar em determinadas condições. Como o próprio nome diz, está
relacionado às funcionalidades do sistema. De acordo com Sommerville (2008), eles podem ainda definir o

12
que o sistema não deve fazer. Os requisitos funcionais vão depender muito do tipo de negócio e de
usuários que utilizarão software, por isso, precisam ser muito bem detalhados. Veja o exemplo abaixo de
requisito funcional de um sistema de vendas online (Considere o código RF01 como "Requisito Funcional
01"):

RF01 - Visualizar Detalhes do Pedido

Para cada pedido de um cliente, o sistema deve apresentar todas as informações do pedido (itens, preço
unitário, preço total, etc.).

Requisitos Não Funcionais:

Os requisitos não funcionais não estão diretamente ligados às funcionalidades de um sistema. Restrições,
ou propriedades relacionadas a tempo, de resposta, desempenho, etc. A figura 4 apresenta um gráfico
com os requisitos não funcionais definidos por Sommerville (2008), que estão detalhados logo abaixo:

a) Requisitos do Produto: neste caso, o produto precisa se comportar de forma particular no em

aspectos como velocidade de execução, confiabilidade, etc
b) Requisitos Organizacionais ou de processo: Dependem de procedimentos organizacionais,
como padrões de processo ou requisitos de implementação, por exemplo.
c) Requisitos Externos: Depende de fatores que não estão relacionados ao sistema nem aos
processos organizacionais, como por exemplo, fatores ligados à legislação da empresa.

13
 Figura 4. Requisitos funcionais segundo Sommerville (2008). Fonte: DevMedia
(https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-funcionais/9525)

Requisito não funcional do produto

RNF01 - Todas as consultas realizadas no banco de dados não devem exceder 6
segundos

RNF02 - A apresentação dos detalhes de cada pedido deve ser padronizada.

Requisito não funcional organizacional

RNF03 - Todos os relatórios devem seguir o mesmo padrão quando exportados em PDF.

Requisitos de Domínio: Estes requisitos são relacionados ao domínio da aplicação e podem refletir
cálculos específicos, por exemplo, em um determinado negócio um supervisor não pode receber um
salário inferior a um funcionário supervisionado por ele.

Outro exemplo seria, no caso de um sistema que possua documentos com restrições de direitos autorais:

14
RD01 - Todos os relatórios com base em arquivos com direitos autorais devem exigir uma chave de
acesso antes de serem abertos.

Requisitos do Usuário: Os requisitos do usuário podem ser considerados como uma forma mais
simplificada de escrever os requisitos funcionais e não funcionais. Requisitos do usuário são importantes
para stakeholders que não tem conhecimento técnico suficiente para compreender todos os detalhes
técnicos presentes nos requisitos funcionais e não funcionais.
Entretanto, Sommerville (2008) alerta para alguns problemas que podem ocorrer ao escrever requisitos de
usuário, como por exemplo, a falta de clareza pelo fato de usar linguagem natural.

Requisitos de Sistema:
Os requisitos do sistema são descrições bem mais detalhadas do que os requisitos do usuário e precisam
definir muito claramente o sistema, pois serão usados na fase de projeto do sistema. Juntamente com os
artefatos que são criados na fase seguinte (projeto), os requisitos são usados para estruturar o sistema e
são muito importantes para a etapa de desenvolvimento.

Exercício 3:
Para o sistema do cenário do do início do capítulo, crie:

a) uma breve descrição do sistema (que pode ser fictício ou você pode visitar algum negócio real
para inspirar seu processo de elicitação de requisitos).
b) Uma lista de alguns requisitos funcionais (funcionalidades) do sistema.

15
2. O PROCESSO DA ENGENHARIA DE REQUISITOS

A Engenharia de requisitos é um processo que possui todas as atividades relacionadas à identificação das
necessidades de um software. É um processo que começa com a comunicação com o cliente, passa por
etapas de análise e modelagem dos requisitos e é finalizada com a entrega de um documento com o
detalhamento dos requisitos do sistema. É importante lembrar que assim o processo de software como um
todo pode variar, a depender de vários aspectos já apresentados (tamanho da empresa, escopo do
sistema, etc.). Entretanto, existem algumas etapas básicas que compõem o processo da engenharia de
requisitos, são elas:

Figura 5. Etapas da Engenharia de requisitos. Fonte: Próprio autor.

Etapa 1. Análise da Viabilidade

Antes de iniciar de fato a elicitação dos requisitos, é importante realizar um estudo da viabilidade do
projeto, para verificar se a realização do projeto é viável tanto do ponto de vista organizacional, quanto do
tecnológico. Portanto, nesta etapa, os stakeholders (envolvidos) do projeto realizam reuniões para
determinar questões como:

O sistema proposto realmente contribui com objetivos da organização?

Vejamos um exemplo: considere um negócio de vendas de camisetas estampadas localizado em uma

cidade pequena. Este negócio atualmente, não conseguiria realizar envio das camisetas para todo o
Brasil. Seria viável criar um sistema web para vendas online destas camisetas? Provavelmente um
sistema web não traria muitas contribuições para este negócio, pois a loja não possui estrutura para
realizar as entregas das camisetas. Portanto, neste caso não seria viável seguir com o projeto e
começar com a elicitação de requisitos.

16
Veja outra questão que pode ser verificada em um estudo de viabilidade de um projeto:

Considerando possíveis restrições tecnológicas ou organizacionais relacionadas ao

projeto, o sistema pode ser desenvolvido?

Vamos imaginar novamente a loja de venda de camisetas estampadas e outros produtos personalizados.
Desta vez, a loja pretende vender os produtos no Brasil e também em outros países. Além disso, o cliente
(dono da loja de camisetas) exige que os desenvolvedores usem uma determinada linguagem de
programação na construção do seu sistema, porém, a equipe desenvolvedora desconhece esta
linguagem. Neste caso, também é inviável prosseguir como projeto, uma vez que a equipe
desenvolvedora não possui habilidades tecnológicas suficientes para desenvolver o projeto.
Entretanto, se a equipe de desenvolvimento estiver familiarizada com a linguagem que o cliente deseja
que seja usada no desenvolvimento do sistema, então o processo poderia seguir para a fase seguinte: a
elicitação dos requisitos.

EXERCÍCIO 4:
Pense naquele cenário 2 da loja de camisetas apresentado lá do capítulo 1. Que aspectos poderiam
INVIABILIZAR O PROJETO?

Etapa 2. Elicitação de requisitos

Após verificar se o projeto é viável, o processo segue para a fase de elicitação de requisitos, também
chamada de levantamento ou identificação dos requisitos. Esta fase busca obter o máximo de informação
possível sobre o negócio em questão para que o sistema criado atenda aos objetivos deste negócio. Você
deve lembrar que os requisitos precisam ser muito bem definidos, para evitar que as funcionalidades
sejam construídas e executem errada. Quando um requisito é mal definido, ele acaba sendo mal
interpretado pelos desenvolvedores, consequentemente implementado de forma errada. Quanto mais
tarde este erro for descoberto, maior o custo associado ao retrabalho para consertá-lo.

As atividades que acontecem na elicitação de requisitos envolvem a identificação das fontes de

informação, realização da coleta de fatos, e comunicação. A figura 6 detalha estas atividades.

17
 Figura 6. Atividades realizadas na elicitação de requisitos. Fonte: próprio autor.

Técnicas para elicitação de requisitos

Existem algumas técnicas para a elicitação de requisitos, de forma a obter o máximo de informação
importante para a definição dos requisitos. Como apresentado na figura 5, na etapa de coleta de fatos, é
possível realizar entrevistas e aplicar questionários para identificar os requisitos, e estas técnicas podem
ser usadas dependendo da situação. Vejamos quando usá-las.

Técnica 1 - Entrevistas: São úteis na fase inicial de coleta de dados e consideradas simples de se
realizar. Entretanto, deve-se estar atento à alguns fatores ao realizar estes tipos de coleta e tentar evitar
situações que possam dificultar a coleta. Veja alguns exemplos desses casos:
● O entrevistador deve evitar induzir respostas do entrevistado, pois isso pode direcionar as ideias do
entrevistado para respostas que não refletem de fato os requisitos.
● A relação pessoal entre o entrevistador e o entrevistado pode influir nas respostas, por exemplo,
caso o entrevistado não se sinta confortável com a pessoa que realizará as entrevistas, pode dar
respostas rápidas que para que o tempo da entrevista seja reduzido.
● Caso um novo sistema venha a dificultar a atuação de um colaborador no seu trabalho, ele pode
dificultar propositalmente o fornecimento de informações.

EXERCÍCIO 5:
Monte um pequeno ROTEIRO DE ENTREVISTA, com algumas perguntas para coletar sistemas para o
sistema de vendas de camisetas do cenário 2 do capítulo 1.
Relembre o cenário: uma loja que deseja vender suas camisetas online, fazendo entregas para todo o
Brasil, ou seja: um alto fluxo de vendas diárias, processamentos de compras em cartão de crédito,
geração de boletos, agendamento de entregas, sistema de trocas, e muitas outras necessidades que a
loja possa vir a ter.

18
Técnica 2 - Questionários: O uso de questionários também é considerado ideal para o início da coleta de
dados. No caso de uso deste instrumento de coleta, deve-se preocupar com a formulação das perguntas.
Para obter informações claras é importante que os respondentes compreendam bem as questões. Neste
caso, pode-se usar questionários piloto antes da aplicação real para que sejam propostas melhorias no
questionário. Além disso, questionários muito longos podem fazer com que as pessoas respondam o
questionário sem muito comprometimento para não levar tanto tempo.

Ele pode ser usado como uma forma de complementar as perguntas da entrevista. O uso de um
questionário após a análise da entrevista, poderia servir para complementar perguntas que foram pouco
exploradas na entrevista.

EXERCÍCIO 6:
Monte um pequeno questionário para esclarecer melhor perguntas que podem ter sido respondidas pelo
cliente de forma vaga na entrevista.

Técnica 3 - Cenários: Pensar como o sistema irá se comportar em determinadas condições é uma das
maneiras de levantar os requisitos. Através de cenários é possível fazer com que as pessoas imaginem as
funcionalidades de um sistema e como será a interação com elas de forma mais clara. Veja um exemplo
de um cenário:

O estado do sistema em determinado momento.

Ex.: O estado do sistema bancário após a inserção do cartão deve mostrar a tela com opções de saque,
depósito e configurações da conta.

Técnica 4 - Workshop de requisitos: Esta técnica trata-se de uma reunião mais estruturada com a
participação de uma equipe de analistas e representantes do cliente para definir os requisitos. Neste tipo
de técnica busca-se usar processos bem definidos de negociação e promover alguns momentos mais
dinâmicos para deixar um clima mais descontraído entre os envolvidos.

Etapa 3. Análise de requisitos

O objetivo desta etapa é revisar o escopo do software e produzir uma especificação consistente dos
requisitos levantados na fase anterior. A análise de requisitos pode possuir as seguintes atividades:

Classificação de requisitos: Trata de agrupar os requisitos semelhantes em conjuntos para que se tenha
uma visão melhor do comportamento do sistema. Voltemos ao exemplo do sistema de caixa bancário. Vamos
agrupar os requisitos que são relacionados a transferências e pagamentos.

19
Requisitos funcionais de transferência bancária

RF11 - Realizar uma transferência de uma conta corrente para poupança

RF12 - Realizar uma transferência de um conta poupança para uma conta-corrente
...
RFn - Realizar uma transferência de uma conta corrente para uma conta corrente em outro
banco

No exemplo acima, considere que podem existir n requisitos relacionados a transferências, por isso os
requisitos foram codificados como RF11, RF12 e RFn, ou seja, poderiam haver os requisitos RF14, RF15, até
RFN. O mesmo acontece nos exemplos a seguir, referente a pagamentos.

Requisitos funcionais de transferência bancária

RF20 - Realizar um pagamento de um boleto

RF21 - Realizar pagamento de um convênio.
...

Priorização dos requisitos: Esta atividade define um nível de prioridade para cada um dos requisitos.
Esse nível pode ser definido de diferentes formas (1 a 5, ou alta/média/baixa). Essa priorização serve para
definir o quão importante é uma funcionalidade e se ela deve receber atenção no desenvolvimento antes
das outras.

Veja no exemplo abaixo a priorização de alguns requisitos. A tabela 1 mostra que os requisitos 11 e 12
possuem alta prioridade. A prioridade pode definir que estes requisitos demandam mais esforço que os
demais e precisam ser desenvolvidos antes, por exemplo.

Tabela 1 - Priorização de requisitos.

Requisito Prioridade

RF11 - Realizar uma transferência de uma conta corrente para poupança Alta

RF12 - Realizar uma transferência de um conta poupança para uma Alta

conta-corrente

RF13 - Apresentar comprovante de uma transferência Baixa

RFn - Realizar uma transferência de uma conta corrente para uma conta Média
corrente em outro banco

Eliminação de conflitos: Considerando que o processo de elicitação de requisitos envolve diversos

stakeholders com backgrounds diferentes, algum conceito ou regra de negócio pode gerar algum tipo de
conflito. Estes conflitos precisam ser eliminados o mais breve possível. Um exemplo de conflito pode estar

20
relacionado justamente à priorização. As pessoas envolvidas no processo podem considerar níveis
diferentes de priorização.

Exemplo de conflito: Imagine que o cliente gostaria que o requisito: "Gerar taxa" em um sistema de Hotel
gerasse uma taxa de 10% para cada reserva, porém os analistas entenderam que essa taxa seria de 20%
em cima do valor da reserva. Claramente trata-se de um conflito que precisa ser resolvido antes do início
da construção do sistema.

EXERCÍCIO 7:
Crie uma lista de requisitos funcionais e não funcionais para o sistema de vendas de camisetas online.
Lembre de numerá-los com um código e agrupar requisitos semelhantes caso seja necessário.

Etapa 4. Modelagem.

A etapa de modelagem tem o objetivo de representar de forma estática e dinâmica o que o sistema deve
fazer através de determinados modelos e técnicas. Os modelos criados nesta etapa representam os
requisitos detalhados no documento de requisitos, fornecem uma visão do domínio do sistema, e ajudam
a estruturar os requisitos de forma que os programadores possam entender vários aspectos do sistema.

A técnica de modelagem de software mais utilizada é a UML (Unified Modeling Language), que possui
diversos tipos de diagramas com diferentes propósitos (Diagrama de caso de uso, Diagrama de classe,
Diagrama de sequência, etc.). O diagrama de caso de uso é utilizado para representar os requisitos
funcionais de um software. É um artefato comumente usado para comunicação interna da equipe de
desenvolvimento e também para comunicação com o cliente.

Diagrama de caso de uso

Este diagrama define as funcionalidades do sistema do ponto de vista do usuário. Por exemplo: o usuário
do nosso exemplo do sistema bancário pode realizar saques, depósitos, etc. Neste caso, o diagrama
representa essas ações que o usuário pode realizar no sistema, de forma direta. Detalhes de como as
funcionalidades são executadas não são incluídos neste diagrama. Trata-se de um diagrama simples que
possui basicamente os seguintes elementos:

● Cenário: Sequência de eventos derivados de uma ação do usuário com o sistema.

● Ator: representado por um boneco, define os usuários do sistema.
● Caso de uso: Determina uma tarefa (ação) ou uma funcionalidade realizada pelo ator.
● Relacionamentos: fazem a relação entre um ator com um caso de uso

Veja um exemplo de um diagrama de caso de uso:

21
Cenário: Este diagrama representa uma modelagem simplificada de um software de caixa bancário. Neste
sistema, o usuário pode realizar saques, depósitos, transferências e pagamentos. Quando efetuadas,
todas essas operações precisam ser registradas na conta do cliente obrigatoriamente. O cliente pode
solicitar um empréstimo, que precisa ser liberado pelo gerente da agência.
Atores: Cliente e Gerente

Figura 7. Diagrama de caso de uso de um sistema bancário básico. Fonte: Próprio autor.

Note que o existem alguns relacionamentos marcados com a palavra <<include>>. Este tipo de
relacionamento define que a um caso de uso deve ser obrigatoriamente executado após outro. Ou seja,
sempre que um empréstimo é solicitado, é preciso que uma liberação seja feita pelo gerente. Ou ainda,
sempre que uma transferência for feita, a movimentação na conta deve ser registrada.

Bem, esse diagrama está longe de representar um sistema bancário em sua totalidade. Vamos então
colocar mais algumas funcionalidades no diagrama? Serão incluídos agora no cenário a funcionalidade de
ver o saldo da conta, ver o extrato, e realizar recargas de celular. Ao fazer a recarga, o usuário terá a
opção (não obrigatória) de repetir a recarga no mesmo telefone com o mesmo valor.

22
 Figura 8. Diagrama de caso de uso com incrementos no cenário anterior. Fonte: Próprio autor.

Nesse novo diagrama, podemos ver agora um relacionamento representado com a palavra <<extend>>.
Este relacionamento representa uma ação opcional, ou seja, repetir a recarga de celular, nesse caso, é
uma ação opcional após realizar uma primeira recarga.

Obs.: Você pode criar diagramas de caso de uso utilizando a ferramentas de modelagem UML Astah
Community. Disponível em: http://astah.net/editions/community

Etapa 5. Validação de requisitos

Esta etapa é responsável pela verificação da qualidade dos requisitos: sua consistência, precisão e
rastreabilidade. Essa fase garante que inconsistências nos requisitos sejam removidas antes de prosseguir
para a fase de projeto, garantindo que requisitos mal elicitados sejam descobertos apenas em fases mais
adiante no processo. A validação de requisitos pode corrigir problemas como:

1. Descrições incompletas dos requisitos.

2. Requisitos mal elicitados
3. Possíveis conflitos nos requisitos que não foram identificados na análise
4. Requisitos que não refletem a realidade

Para eliminar possíveis problemas de compreensão, redundância, consistência e rastreabilidade é

possível utilizar um método de revisão dos requisitos, que tem o objetivo de identificar os problemas e

23
resolvê-los. Nessa revisão pode-se usar um checklist com questões que avaliam a qualidade dos
requisitos. Um exemplo desse checklist pode ser encontrado na tabela 2:

Tabela 2. Checklist de validação de qualidade de requisitos.

Atributo Questão Sim Não

Compreensibilidade Termos específicos e siglas referentes ao negócio aparecem no

glossário do documento de requisitos?

Compreensibilidade A descrição dos requisitos é clara?

Compreensibilidade O requisito precisa de outro para ser compreendido?

Ambiguidade Existem requisitos usando o mesmo termo com sentidos diferentes?

Rastreabilidade Cada requisito possui um código identificador que permita associá-los

posteriormente aos casos de teste?

Organização, Requisitos relacionados estão agrupados?

rastreabilidade

Estas são algumas das questões que podem ser utilizadas para validar a qualidade de um documento de
requisitos. O atributo compreensibilidade possui questões relacionadas ao entendimento dos requisitos
pelas partes envolvidas no desenvolvimento. Ambiguidade possui questões de inconsistências, por
exemplo no uso de terminologias. Questões de rastreabilidade ajudam no processo de identificação dos
requisitos e sua associação com outros itens de outros artefatos do processo.

EXERCÍCIO 8:
Crie um checklist de validação para analisar os requisitos gerados no exercício 7.

24
3. DOCUMENTO DE REQUISITOS

O documento de requisitos possui todas as informações relevantes identificadas no processo da

Engenharia de requisitos e é o principal artefato gerado nesse processo. A criação do documento pode
variar, a depender do processo adotado pela equipe desenvolvedora do software, logo, uma empresa
pode preferir usar seu próprio modelo com itens específicos a seus projetos ou usar um documento mais
geral.

O documento em si pode ser criado em um editor de textos, por exemplo, que irá agrupar todas as
informações sobre os requisitos. Porém, algumas ferramentas mais específicas podem ser usadas para
cada atividade, por exemplo:

● O NFR Framework é usado para modelar de Requisitos Não-Funcionais;

● UML é usado para modelar softwares Orientados a Objetos;
● BMPN pode ser usado para modelagem de processos de negócios.

Vamos ver agora um exemplo de documento de alguns itens que podem compor o documento de
requisitos.

Modelo de Documento de Requisitos

1 - Informações Gerais

a) Visão Geral

<Nesta seção você deve apresentar uma visão geral de como o documento está organizado.>
Obs.: Note que todos os exemplos mencionados abaixo, estão relacionados com o diagrama de
caso de uso apresentado na descrição da etapa de modelagem de requisitos na seção 2 deste
caderno de estudo que refere-se a um sistema bancário. Evidentemente, um sistema bancário seria
muito mais complexo, teria mais funcionalidades e usuários. Porém, por fins didáticos, o sistema
foi simplificado de forma a não deixar os exemplos complexos demais.

Exemplo:
Seção 1: Apresenta as informações gerais do documento e termos e abreviações usadas.
Seção 2: Apresenta uma descrição geral do sistema, define a abrangência do sistema e detalha os
usuários.
Seção 3: Detalha os requisitos funcionais.

25
Seção 4: Descreve os requisitos não-funcionais.

b) Termos e abreviações

<Caso o sistema proposto possua qualquer termo específico ou abreviação que será usada no restante do
documento, eles devem ser adicionados aqui.>

Exemplo (Sistema bancário):

- BAI (Bank Administration Institute): é um formato de arquivo usado em relatórios de saldo de
gerenciamento de caixa eletrônico.
- UI (User Interface): O termo UI será usado para designar a interface gráfica do sistema

c) Definição de Prioridades dos requisitos

<Aqui devem ser inseridas as definições de prioridade que serão usadas para classificar os requisitos.
Caso seja 1 - 5, deve-se deixar explícito o que cada um dos números representa. Caso seja alta, média ou
baixa, deve-se descrever o que cada um deles representa. Também pode-se adotar a classificação do
exemplo abaixo>

Essencial requisitos classificados como essenciais são aqueles que sem eles o sistema não funcionaria.
Requisitos com essa prioridade precisam ser implementados obrigatoriamente.
Importante requisitos importantes são aqueles que permitem que o sistema funcione, porém sem eles, o
sistema não funciona de forma adequada. Este tipo de requisito precisa ser implementado, mas caso não
seja possível, o sistema pode ser implantado mesmo assim.
Desejável requisitos classificados como desejáveis são requisitos mais básicos e que não comprometem
o funcionamento do sistema caso não sejam implementados.

2- Descrição Geral do sistema

a) Abrangência e sistemas relacionados

<Aqui deve ser descrito o que o sistema deverá fazer de maneira ampla. caso o sistema tenha relação
com algum outro sistema, deve-se mencionar nesta seção>

Exemplo fictício de descrição:

O BankOnline é um sistema para uso em caixas eletrônicos do Banco "Bank" que atua nas capitais São
Paulo, Rio de Janeiro, Salvador, Recife e Fortaleza. O sistema deve permitir que os clientes do banco

26
realizem saques, depósitos, pagamentos de boletos, convênios, e solicitação de empréstimos. O sistema
BankOnline é conectado com ao sistema de serviço de proteção ao crédito (SPC) para que possa liberar
ou não empréstimos.

b) Descrição dos usuários

<Aqui devem ser inseridos detalhes sobre os usuários do sistema. >

Exemplo:
Administrador: No BankOnline, o administrador é o responsável por liberar empréstimos solicitados pelos
clientes. Um administrador também pode ser cliente do banco.

Cliente: O cliente é o usuário que pode realizar saques, depósitos, pagamentos de boletos e convênios, e
solicitação de empréstimos.

3 - Requisitos funcionais

<Aqui você deve colocar os requisitos da forma mais detalhada possível. Os requisitos devem estar
associados aos casos de uso. Você o incluir o diagrama nesta seção para facilitar a associação entre os
casos de uso e os requisitos. Em sistemas maiores, que possuem muitos casos de uso, lembre-se de
agrupá-los>

Modelo:

[RF001] <Nome do caso de uso>

Descrição do requisito: <Forneça uma descrição do requisito>
Atores envolvidos: <informe o(s) ator(es) do caso de uso >
Prioridade: ⬜Essencial ⬜ Importante ⬜Desejável
Entradas: <Forneça os dados de entrada para esta funcionalidade>
Pré-condições: <Determine quais as pré-condições necessárias para que esta funcionalidade seja
executada>
Saídas e pós-condições: <Determine quais as pré-condições necessárias para que esta funcionalidade
seja executada>
Fluxo Principal <Descreva a sequência de passos principais para executar esta funcionalidade. Por
exemplo: os passos que levam a realizar um login com sucesso.>
Fluxo secundário <Descreva a sequência de passos para executar esta funcionalidade em casos
alternativos. Por exemplo, um fluxo que foge da sequência básica de passos de um login, seria tentar
realizar um acesso a uma conta com um cartão inválido. O fluxo seria interrompido..>

[RF0n…] <Usar os mesmos itens de RF001, para cada requisito do sistema>

27
Lembre-se que você pode agrupar os requisitos. Por exemplo, no sistema bancário, os requisitos
referentes a Saque podem ser agrupados em uma subseção chamada "requisitos referentes à função
Saque". Outro grupo pode ter requisitos sobre depósito ,etc.

Exemplo:

Vejamos agora um outro exemplo. Considere o diagrama de caso de uso apresentado na seção 2.

_______________________________________________________________________

[RF001] Ver saldo

Descrição do requisito: Este requisito representa o caso de uso "ver saldo". O usuário deve acessar a
opção ver saldo e verificar qual o saldo da sua conta.
Atores envolvidos: Cliente
Prioridade: X Essencial ⬜ Importante ⬜Desejável
Requisitos associados: Nenhum
Entradas: Não existem entradas para este requisito.
Pré-condições: O cliente precisa ter sido autenticado no sistema usando o cartão e senha.
Saídas e pós-condições: As saídas deste requisito é o valor do saldo.
Fluxo Principal
1. Após autenticado no sistema, no menu principal, o cliente deve clicar na função "ver saldo".
2. O Saldo é apresentado ao cliente.
Fluxo secundário
Neste caso, não existem fluxos secundários.
_______________________________________________________________________

[RF002] Realizar saque

Descrição do requisito: Este requisito representa o caso de uso "realizar saque". O usuário deve acessar
a opção "saque" no menu principal para acessar esta função.

28
Atores envolvidos: Cliente
Prioridade: X Essencial ⬜ Importante ⬜Desejável
Requisitos associados: (RFXXX) Registrar movimentação na conta.
Entradas: Valor do saque // Autenticar novamente com o cartão e senha (ou digital).
Pré-condições: O cliente precisa ter sido autenticado no sistema usando o cartão e senha.
Saídas e pós-condições: A saída é o valor requisitado para o saque.

Fluxo Principal

1. Após autenticado no sistema, no menu principal, o cliente deve clicar na função "Saque".
2. O sistema solicita o valor do saque. O usuário digita o valor e clica em "Confirmar".
[FluxoSecundario001] (a partir daqui, o sistema pode levar para o FluxoSecundario001, caso não
haja saldo disponível).
3. O sistema libera o valor solicitado.
4. O sistema registra a movimentação na conta.

Fluxo secundário
[FluxoSecundario001] Valor solicitado para o saque maior que o indisponível na conta.
1. O sistema apresenta a seguinte mensagem: "O saldo na conta é insuficiente para o valor solicitado".

4 - Requisitos não-funcionais

<Aqui devem ser descritos os requisitos não funcionais do sistema. Evidentemente, estes requisitos
dependem do software que está sendo desenvolvido. Você pode descrever requisitos dos tipos:
Usabilidade, Confiabilidade, Segurança, Hardware, Portabilidade, etc.>

Modelo:

Requisitos não-funcionais de <descreva o tipo de requisito>

RNF001 - <Nome do Requisito>

Descrição: <Descreva aqui as informações sobre este requisito não funcional>
Prioridade: ⬜Essencial ⬜ Importante ⬜Desejável

RNF00n - <Nome do Requisito>

Descrição: <Descreva aqui as informações sobre este requisito não funcional>
Prioridade: ⬜Essencial ⬜ Importante ⬜Desejável

Exemplo:

Requisitos não-funcionais de Usabilidade

RNF001 - Facilidade de uso

Descrição: Usuários com pouca familiaridade com sistemas bancários podem precisar de orientação de
funcionários da agência.
Prioridade: ⬜Essencial ⬜ Importante X Desejável

29
Requisitos não-funcionais de Portabilidade

RNF002 - Portabilidade do sistema

Descrição: O sistema bancário BankOnline funcionará exclusivamente em máquinas com o sistema
operacional Linux.
Prioridade: X Essencial ⬜ Importante ⬜ Desejável

Requisitos não-funcionais de Confiabilidade

RNF002 - Disponibilidade do sistema

Descrição: O sistema bancário BankOnline deve estar disponível 95% do tempo em que os caixas estão
disponíveis ao acesso dos clientes.
Prioridade: X Essencial ⬜ Importante ⬜ Desejável

EXERCÍCIO 9:

Crie um documento de requisitos, usando o modelo apresentado acima, para o sistema do cenário 2,
usado nos demais exercícios do caderno.

30
CONCLUSÃO

Terminamos! Neste caderno você viu aspectos gerais sobre Engenharia de Software, vimos como o
processo de desenvolvimento de software pode ser organizado dependendo de vários aspectos, como o
contexto da empresa ou dos projetos e por fim, vimos com detalhe como definir os requisitos de um
sistema. Como mencionado várias vezes neste caderno, as atividades e documentos gerados no processo
de desenvolvimento podem mudar, portanto, sinta-se livre para pesquisar outros modelos de documentos
de requisitos.

31
REFERÊNCIAS

SOMMERVILLE, Ian. Engenharia de Software. 9.ed. São Paulo: Ed. Pearson, 2011.

MACHADO, Felipe Nery. Análise e Gestão de Requisitos de Software: Onde Nascem os

Sistemas. 2.ed. São Paulo: Ed. Erica, 2014.

PRESSMAN, Roger S. et al. Engenharia de Software: uma abordagem profissional. 7.ed.

São Paulo: Ed. MCGRAW-HILL BRASIL, 2011.

32