Disciplina

ENGENHARIA DE REQUISITOS

Unidade 2
Classificação de Requisitos de Software

Aula 1
Especificação de requisitos

Introdução

Olá, estudante!
Nesta aula, você aprenderá como realizar a especificação dos requisitos de software,
classificando os requisitos em funcionais e não funcionais e identificando-os de forma correta.
Apresentaremos métodos de levantamento destes requisitos e como você poderá definir os
requisitos necessários para a sua aplicação de forma assertiva. É preciso ter em mente que esta
fase é a mais importante em todo processo de desenvolvimento de uma aplicação, de modo que
um requisito não especificado corretamente poderá levar a graves consequências para o seu
projeto, até mesmo podendo não satisfazer corretamente às necessidades dos patrocinadores
(clientes), culminando no fracasso do produto criado.
Bons estudos!
Disciplina

ENGENHARIA DE REQUISITOS

Processos de especificação de requisitos

A primeira parte de um projeto de software é o processo de especificação dos requisitos de um

sistema, independentemente da metodologia de desenvolvimento adotada pela equipe.
Todo o processo de especificação de requisitos requer entrevistas com o cliente (ou seus
representantes, que denominamos de parte interessada no produto), com o intuito de escrever
um artefato descrevendo o requisito, sua importância para o sistema e a sua prioridade no
desenvolvimento do produto. Porém, nem sempre o cliente consegue descrever com clareza
como a aplicação que será construída deverá funcionar, ou seja, como os requisitos da aplicação
precisarão estar especificados e construídos e como será a interação entre eles.
O objetivo do processo de levantamento de requisitos é auxiliar a equipe de desenvolvimento na
construção da aplicação. Portanto, precisará conter as regras de negócio, as regras de validação
(aceitação) e as respostas esperadas para a ação (requisito ou funcionalidade) realizada no
sistema.
Requisitos podem ser classificados como sendo de usuário ou de sistema. Requisitos de usuário
são especificados em linguagem natural, sem muito detalhamento (ou seja, nível macro), muitas
vezes utilizando diagramas auxiliares para representação da funcionalidade aos usuários finais.
Requisitos de sistema, por sua vez, são descrições detalhadas de como os requisitos do usuário
devem funcionar e interagir entre si, representando o nível de entendimento necessário para a
equipe de desenvolvimento poder implementar o produto desejado.
É importante que você tenha mais de uma visão de um mesmo requisito (a macro e a detalhada),
tendo em vista que cada visão será apresentada a pessoas diferentes (cliente ou desenvolvedor)
Disciplina

ENGENHARIA DE REQUISITOS

e precisará ter o entendimento comum para todas elas.

A escrita de um requisito pode ser feita, a princípio, em linguagem natural, ou seja, em linguagem
simples e concisa, que expresse a necessidade do usuário. Cada requisito precisa especificar
apenas uma função do sistema ou produto que será desenvolvido.
A linguagem natural estruturada, conforme menciona Sommerville (2011), também pode ser
utilizada, na qual um formulário padrão pode ser preenchido com os campos que estarão
envolvidos no requisito e suas respectivas descrições, fornecendo informações técnicas sobre a
funcionalidade que está sendo especificada.
Para auxiliar no processo de especificação de um requisito, alguns diagramas ou documentos
podem ser construídos, como os diagramas de caso de uso ou o documento da história (ou
estória) de usuário.
Caso de uso
Um caso de uso terá, por objetivo, descrever, de forma visual, um cenário que represente a
interação do usuário com o sistema. Desse modo, é possível conhecer quais os atores que
estarão envolvidos em cada interação e quais funcionalidades o sistema provê.
A Figura 1 apresenta um exemplo de como um caso de uso pode ser elaborado.

Fonte: elaborada pela autora.

A Figura 1 apresenta, para um exemplo de manipulação de livros através de um sistema, as

operações básicas que um usuário externo poderá fazer, como a inserção de um novo livro, a
alteração de um livro já cadastrado e a consulta a livros.
História (ou estória) de usuário
Em times que adotaram metodologias ágeis para o desenvolvimento de novos produtos, como a
SCRUM, as histórias de usuário são escritas como documentos que substituirão o documento de
especificação de requisitos e diagramas auxiliares (como os casos de uso), apresentando como
Disciplina

ENGENHARIA DE REQUISITOS

a interação acontecerá entre o usuário final e a funcionalidade do sistema, qual a resposta

esperada e quais os critérios de aceitação para que o requisito possa ser dado como pronto (ou
seja, que satisfaça a necessidade do usuário).
Um exemplo de história de usuário para o cenário de inclusão de novo livro, apresentado na
Figura 1, ficaria como exibido no Quadro 1.

Fonte: elaborado pela autora.

Requisitos funcionais
Disciplina

ENGENHARIA DE REQUISITOS

Os requisitos funcionais representam as ações do sistema que serão utilizadas pelo usuário final,
ou seja, como o sistema (ou aplicação) deverá reagir às interações do usuário. Em suma, será
toda função disponível ao usuário final e que se espera que o sistema forneça (seu propósito).
É importante que, ao realizar o mapeamento das funcionalidades que o sistema deve prover, a
escrita englobe apenas um único requisito por vez. Além de facilitar o desenvolvimento pela
equipe de programação, facilitará o entendimento do usuário final e a validação dos requisitos
com as reais necessidades das partes interessadas (stakeholders).
Estes requisitos precisam estar mapeados no documento de especificação de requisitos,
elaborado pela equipe de levantamento das especificações do produto, e precisam estar em
linguagem clara e com o detalhamento adequado para que os desenvolvedores possam realizar
a codificação.
Disciplina

ENGENHARIA DE REQUISITOS

Quando os requisitos de um sistema são mapeados, é fundamental que o cliente defina quais
devem ser priorizados, ou seja, quais agregarão mais valor ao produto que será entregue ao final
do projeto. Essa priorização, caso o time esteja trabalhando em cima de metodologias ágeis para
desenvolvimento de sistemas, poderá ser alterada ao longo do projeto. Para metodologias
tradicionais, como a cascata, é fundamental que todo o processo de especificação de requisitos
seja totalmente definido antes do projeto começar de fato, sem a possibilidade de alteração após
o início da construção.
Alguns exemplos de requisitos funcionais são:

Cadastro de dados de entidades mapeadas (livro, carro, pessoa, jogo etc.).

Alterações de dados.
Consultas.
Extração de relatórios.
Remoção de dados.

Muitas vezes, o cliente que está auxiliando a equipe de desenvolvimento a mapear os requisitos
funcionais não tem total clareza sobre como a funcionalidade deve ser provida pelo sistema,
deixando dubiedades ou até detalhes técnicos do negócio (como as regras de validação) ocultos
até o momento da implementação.
Para sanar qualquer eventual dúvida ou falta de clareza na especificação de requisitos, é
importante a utilização de recursos que auxiliem a parte interessada na validação deles, como a
prototipação. Protótipos funcionais, que apresentarão o layout da tela e uma funcionalidade
simulada através de linguagens voltadas para a camada de apresentação (como a Javascript),
darão uma maior clareza ao usuário final, o qual, por sua vez, poderá realizar ajustes para atender
às suas expectativas.
Todos os protótipos construídos na fase do levantamento de requisitos e da validação dos
requisitos funcionais serão reaproveitados na fase de implementação do sistema pela equipe de
desenvolvedores.
Uma questão importante, quando se trata de requisitos funcionais, é que eles precisam estar
definidos de forma completa e consistente, ou seja, o usuário precisa definir todas as
funcionalidades necessárias para o sistema, e estas funcionalidades não podem ter critérios
contraditórios. Como critérios contraditórios, entende-se que uma funcionalidade não pode ter
um critério que é desfeito por outra funcionalidade.

Requisitos não funcionais

Disciplina

ENGENHARIA DE REQUISITOS

Requisitos não funcionais, por sua vez, são aqueles que servem como suporte aos funcionais,
mas que não são percebidos (ou visíveis) ao usuário final. Exemplo desta categoria de requisito
são os requisitos de performance, segurança, auditoria de informações (logs) e os demais
requisitos que servem de suporte para o correto funcionamento dos requisitos visíveis
(funcionais).
Esta categoria de requisitos é mais crítica para o sistema que os requisitos funcionais, tendo em
vista que, caso aconteça alguma ação indevida do usuário final, como conseguir entrar no
sistema sem ter passado pelas etapas de validação de autenticação, todo o sistema estará
comprometido, podendo até mesmo ser invalidado.
É comum que requisitos não funcionais estejam espalhados por várias partes do sistema,
englobando, inclusive, mais de um requisito funcional, até mesmo pela sua natureza
(performance, segurança etc.).
O mapeamento dos requisitos não funcionais acontece através do entendimento de quais são as
necessidades de restrição das partes interessadas, como restrição de segurança, orçamento,
interoperabilidade com outros sistemas, políticas organizacionais, legislação de privacidade e
segurança ou normas de segurança interna.
Conforme apresentado por Sommerville (2011) e Pressman e Maxim (2021), a origem dos
requisitos não funcionais podem ser:

Requisitos de produto: restringem o comportamento da aplicação, como questões de

desempenho, taxa aceitável de falhas, proteção e usabilidade do sistema.
Requisitos organizacionais: originados de políticas empresariais ou do cliente, como os
processos operacionais, processo de desenvolvimento (como a definição de uma
linguagem de programação específica), ambiente de desenvolvimento ou normas de
processo que precisam ser utilizadas.
Disciplina

ENGENHARIA DE REQUISITOS

Requisitos externos: abrangendo todo requisito externo ao sistema e seu desenvolvimento,

como leis, interoperabilidade com sistemas externos, ética etc.

Fonte: adaptada de Sommerville (2011).

A Figura 2 apresenta um resumo dos tipos de requisitos não funcionais, de acordo com as
categorias anteriormente apresentadas.
É relativamente comum que as partes interessadas ditem os requisitos não funcionais como
metas ou objetivos do sistema, como a facilidade de uso ou performance. Um ponto importante
é que, caso sejam especificados desta forma, os requisitos não funcionais podem ser difíceis de
serem testados, tornando-se um ponto subjetivo do sistema e abrindo brechas para diversos
entendimentos.
A forma ideal para que um requisito não funcional seja especificado é quantitativamente, ou seja,
da forma mais objetiva possível (de preferência com números), a fim de que possam ser
validados ou mensurados. Porém, nem todo requisito não funcional poderá ser medido
quantitativamente, o que indica que métricas precisam ser adotadas para justificar ou validar a
implementação correta destes requisitos.
Outro ponto importante de ser destacado é que, no documento de especificação de requisitos, é
difícil realizar a separação entre os requisitos funcionais dos não funcionais, tendo em vista que,
em muitos casos, requisitos não funcionais podem englobar um ou mais dos requisitos
funcionais. Caso não se deixe clara a delimitação entre a funcionalidade provida pelo sistema e
os requisitos não funcionais que estão envolvidos nesta funcionalidade, o entendimento poderá
ficar confuso para a equipe de desenvolvimento. Portanto, quando se tem um requisito não
funcional interligado a um requisito funcional, você deverá fazer o destaque na parte que engloba
o requisito não funcional.
Disciplina

ENGENHARIA DE REQUISITOS

Videoaula: Especificação de requisitos

Este conteúdo é um vídeo!

Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.

Olá, estudante! Neste vídeo, você aprenderá técnicas para levantamento e especificação de
requisitos funcionais e não funcionais, como montar o documento de especificação de requisitos
e um modelo de como escrever histórias de usuário. Por ser a fase mais importante para o
desenvolvimento de um software, é muito importante que você entenda e conheça as diversas
abordagens para escrita e apresentação de requisitos, que serão importantes para os mais
diversos stakeholders (ou seja, partes interessadas no projeto).

Saiba mais

O artigo Como escrever requisitos de software de forma simples e garantir o mínimo de erros no
sistema/app?? apresenta como especificar requisitos de uma aplicação de forma simplificada,
minimizando os erros.
A ferramenta OpenReq é gratuita e voltada para o gerenciamento de requisitos.
Disciplina

ENGENHARIA DE REQUISITOS

A ferramenta SIGERAR também é gratuita e voltada para o gerenciamento e a rastreabilidade dos

requisitos durante todo o ciclo de vida da aplicação.

Referências

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: Mc Graw Hill
Education, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.

Aula 2
Atividades da engenharia de requisitos

Introdução
Disciplina

ENGENHARIA DE REQUISITOS

Olá, estudante!
Nesta aula, você aprenderá quais critérios podem ser levados em consideração no momento de
priorizar os requisitos de uma aplicação para seu desenvolvimento, assim como as técnicas que
podem ser utilizadas para auxiliar o processo de priorização e as ferramentas que podem auxiliar
no processo de priorização.
A priorização dos requisitos especificados é fundamental para que as funcionalidades mais
importantes, ou seja, aquelas que agregam mais valor ao negócio do cliente e,
consequentemente, ao produto construído, sejam antecipadas em relação àquelas menos
prioritárias (que agregam menos valor ao produto).
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao
visto na aula, mas esteja sempre buscando novas formas de se atualizar.
Bons estudos!

Critérios de priorização e negociação de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

Após a fase de entrevistas para o levantamento de requisitos junto ao cliente, é preciso priorizar
os requisitos, de modo a começar a construção do produto pelos requisitos que agregam mais
valor ao produto, ou seja, que sejam mais importantes ao usuário final.
Esta priorização dos requisitos levantados deve acontecer após os requisitos terem sido
agrupados em grupos com requisitos similares. A conclusão desta etapa resulta num modelo de
arquitetura do produto que será desenvolvido, apresentando onde cada requisito se encaixa no
modelo.
Quando um produto envolve diferentes áreas e, consequentemente, possui diferentes
patrocinadores, cada qual com seus respectivos requisitos, é comum ocorrerem conflitos de
interesses. Estes conflitos podem ser resolvidos com a priorização dos requisitos, após reuniões
de alinhamento entre estas diferentes partes interessadas e analisando a relação entre benefício
do desenvolvimento versus custo para implementação.
Muitas vezes, algumas funcionalidades dependem da implementação de outras, o que ocasiona
na priorização destes pré-requisitos, para que as demais funções dependentes possam ser
codificadas.
Quando um consenso não é alcançado, através de reuniões com os stakeholders (partes
interessadas), fica muito difícil para o analista de requisitos ou o líder de projetos indicar para a
equipe de desenvolvimento quais funcionalidades agregam mais valor, tendo em vista que isso
dependerá do negócio do cliente e de todas as questões que envolvem o projeto, como prazo e
limitação de orçamento.
Quando nos referimos às metodologias tradicionais de desenvolvimento de projetos, como a
cascata, a priorização dos requisitos deverá estar concluída antes que a fase de implementação
Disciplina

ENGENHARIA DE REQUISITOS

do produto seja iniciada e não poderá ser alterada após este início. Sendo assim, um erro no
planejamento desta priorização poderá ocasionar em invalidação do produto pelo cliente, no
momento da entrega e validação, causando prejuízo tanto para o cliente quanto para a empresa
que desenvolveu o produto.
Em equipes que seguem as metodologias de desenvolvimento ágeis, como a SCRUM, para cada
ciclo de entrega deverá ser feita a priorização dos requisitos que serão detalhados e
implementados pela equipe. Estes requisitos detalhados são provenientes de uma lista com os
requisitos macros, priorizados de acordo com a necessidade do cliente. Ao longo do processo de
desenvolvimento, é possível alterar a prioridade dos requisitos, conforme as necessidades forem
mudando, de modo a sempre adequar o que será entregue ao cliente com a sua real necessidade
do momento.
A priorização não dependerá do detalhamento dos requisitos para acontecer, de modo que tornar
o processo mais simples, até mesmo ainda utilizando o nível macro de especificação, poderá
facilitar o entendimento das partes interessadas e, consequentemente, o processo como um
todo.
Uma outra questão importante a ser levada em consideração no momento da priorização dos
requisitos é a complexidade técnica e a dificuldade de implementação. Esta percepção é tida
pela equipe de desenvolvimento, que pode, junto ao cliente, auxiliar a resolução de conflitos de
interesses das partes interessadas e definir quais funcionalidades estarão presentes na próxima
entrega do produto.

Técnicas de priorização de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

Para realizar o processo de priorização de requisitos, é fundamental a utilização de técnicas de

priorização, tendo em vista que muitos conflitos de interesses podem existir entre os
patrocinadores, resultando em diferentes pontos de vista em termos de quais requisitos devem
ser antecipados em sua implementação.
Nem sempre é algo trivial para a equipe de desenvolvimento, principalmente ao analista de
requisitos, ao líder técnico ou ao product owner (dono do produto, na metodologia SCRUM) inferir
quais as funcionalidades que mais agregam valor ao sistema que está sendo desenvolvido e
atendem às principais necessidades do cliente. Sendo assim, é imprescindível a participação do
cliente neste processo de priorização, mas este, por sua vez, pode também ter dificuldades em
definir o grau de importância dos requisitos levantados.
Para auxiliar na classificação dos requisitos, em termos de priorização, existem as técnicas de
priorização, como a utilização de escalas de priorização, similares às apresentadas na Tabela 1.
Conhecida como Nominal Scale, esta técnica considera que requisitos que estejam organizados
dentro do mesmo grupo possuem o mesmo nível de importância e, consequentemente, a mesma
prioridade.
Disciplina

ENGENHARIA DE REQUISITOS

Fonte: adaptado de Generoso (2019).

O Quadro 1 apresenta a classificação pelo nível de criticidade do requisito, agrupado na escala

alto, médio ou baixo. A partir desta priorização, busca-se entrar em consenso com as partes
interessadas sobre quais requisitos serão implementados em cada entrega do produto.
Requisitos que sejam mandatários para a implementação de outras funcionalidades tendem a
ser classificados como de maior prioridade, tendo em vista que a interdependência com outros
requisitos é alta.
Uma escala semelhante, que agrupa os requisitos em termos de quão essencial este o é para
agregar valor ao produto, é apresentada no Quadro 2.
Disciplina

ENGENHARIA DE REQUISITOS

Fonte: adaptado de Generoso (2019).

O Quadro 2 apresenta uma classificação por obrigatoriedade dos requisitos para o produto, de
modo que se tem como essencial aquele requisito obrigatório no sistema/aplicação; condicional
para os requisitos que agregam melhorias, mas que a falta não implica invalidação do produto;
por último, os requisitos tidos como opcionais, que podem ou não ser implementados, não
fazendo falta caso não estejam presentes.
Uma técnica amplamente utilizada para priorização dos requisitos junto aos stakeholders se
baseia na quantidade de dependências de uma funcionalidade em relação às demais e na
preferência das partes interessadas em termos do que pode estar agregando mais valor ao
produto. Essa técnica depende muito do fator humano para sua aplicação, tendo em vista que as
dependências são informadas pela equipe de desenvolvimento, com base em experiências
anteriores dos membros da equipe.
A técnica Ordinal Scale, por sua vez, realiza a comparação entre dois requisitos para avaliar qual
dos dois será mais importante ao produto. O objetivo será montar uma lista ordenada com as
funcionalidades listadas por ordem de implementação.
Existe também a técnica Ratio Scale, que utiliza uma escala de decisão para decidir pela
priorização dos requisitos de forma mais precisa que as outras duas técnicas (ordinal e nominal),
já que identifica a diferença relativa entre os requisitos. As técnicas ordinal e nominal auxiliarão
apenas na classificação dos requisitos.

Ferramentas na engenharia de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

Não somente técnicas de priorização de requisitos são importantes para ordenar, de forma
coerente com as necessidades do usuário final, as funcionalidades especificadas para o produto.
Existem também ferramentas que podem auxiliar no processo de priorização.
Com as ferramentas, é possível enxergar com mais precisão os relacionamentos entre os
requisitos, assim como fatores que podem classificá-los como mais ou menos prioritários, em
relação às outras funcionalidades.
A primeira ferramenta que apresentaremos é a Matriz de Priorização. Com ela, é possível
estabelecer quais funcionalidades precisam ser implementadas em qual ordem, de acordo com
critérios claros e bem definidos, evitando descumprimento de prazos e garantindo foco naquilo
que realmente precisa estar pronto. Ela é construída em formato de tabela, gráfico ou quadrante,
ficando a cargo da equipe qual a melhor forma de representação.
Disciplina

ENGENHARIA DE REQUISITOS

Um benefício da utilização da Matriz de Priorização é que as partes interessadas estarão cientes

dos prazos estabelecidos para construção de cada funcionalidade, se acontecerá algum atraso
ou imprevisto, sendo possível renegociar prazos ou alterar a ordem de prioridade de algum
requisito de forma mais consciente.
Para montar sua tabela, os seguintes passos precisam ser seguidos:

1. Listagem das funcionalidades que precisarão ser priorizadas.

2. Estabelecimento de critérios de seleção, representando quais condições serão levadas em
consideração para a seleção dos requisitos. Podem ser considerados critérios a urgência,
gravidade, tendência, benefício, satisfação do cliente etc.
3. Atribuir uma pontuação para cada critério especificado, utilizando-se uma escala (como de
1 a 5), onde 1 representa pouco importância para o critério e 5 muita importância para o
critério. Esta escala deverá ser utilizada para todos os requisitos envolvidos.
4. Montar uma tabela com as informações levantadas, na qual as linhas conterão as
funcionalidades (requisitos), e as colunas, os critérios especificados, preenchendo qual a
“nota” atribuída para cada critério, conforme a funcionalidade.
5. Associar as pontuações para cada funcionalidade, executando operações, como soma,
multiplicação ou divisão, que serão aplicadas conforme o método de matriz escolhido. O
resultado desta etapa será o ranqueamento de cada demanda, que expressará a ordem de
prioridade que deverá ser seguida pela equipe de desenvolvimento.

Matrizes de Priorização podem ser, conforme apresenta Justo (2019), dos seguintes tipos:

GUT: considerará critérios, como a urgência, a gravidade e a tendência, realizando a

operação de multiplicação ao final do processo de atribuição de pesos (na escala de 1 a 5
para cada critério).
BASICO: considera os seguintes critérios: benefícios para a empresa, abrangência dos
resultados, satisfação do cliente, investimento requerido, cliente externo satisfeito e
operacionalidade simples. Cada critério receberá uma pontuação, obedecendo à escala de
1 a 5, aplicando a operação de soma em vez da multiplicação.
RICE: considera os critérios reach (quantidade de pessoas impactadas pela
funcionalidade); impact (impacto da demanda, que pode ser classificado em massivo (3
pontos), grande (2 pontos), médio (1 ponto), baixo (0,5 ponto) e mínimo (0,25 ponto));
confidence (nível de confiança no resultado, também classificado em escala, que pode ser
alto (100%), médio (80%), baixo (50%) e mínimo (20%)); effort (esforço ou tempo
necessário para implementar a demanda). O resultado é feito através da operação de
multiplicação das pontuações atribuídas para os critérios de reach, impact e confidence,
dividindo o resultado pelo effort.
4X4: considera dois critérios, que podem ser escolhidos como os mais importantes por
quem estiver montando a matriz. A partir daí, um gráfico cartesiano pode ser construído
com notas atribuídas aos dois critérios, variando na escala de 1 a 4.

Videoaula: Atividades da engenharia de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

Este conteúdo é um vídeo!

Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.

Olá, estudante! Neste vídeo, você aprenderá a importância da priorização dos requisitos
especificados para uma aplicação, como utilizar técnicas de negociação de conflitos de
interesses, por parte dos stakeholders envolvidos, além de quais as técnicas mais adequadas
para a realização desta priorização, tão importante ao produto que será construído. Aprenderá
também quais ferramentas poderão ser utilizadas para auxiliar este processo.

Saiba mais

Para exemplos de utilização de Matriz de Priorização, recomendo a explicação deste artigo

Matriz GUT (Matriz de Priorização), que também possui um modelo para construção da Matriz de
Priorização GUT.

Referências
Disciplina

ENGENHARIA DE REQUISITOS

GENEROSO, M. A. P. Dependency Rank: método de priorização de requisitos baseado nas

relações de dependência identificadas por PLN. 2019. Dissertação (Mestrado em Informática) –
Universidade Federal do Paraná, Curitiba, 2019. Disponível em:
[Link]
idpessoal=54589&idprograma=40001016034P5&anobase=2019&idtc=1424. Acesso em: 28 maio
2022.
JUSTO, A. S. Matriz de Priorização: Como organizar e selecionar projetos, processos e chamados
em 6 passos. Euax, 2019. Disponível em: [Link]
priorizacao/. Acesso em: 28 maio 2022.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.

Aula 3
Análise de requisitos

Introdução
Disciplina

ENGENHARIA DE REQUISITOS

Olá, estudante!
Nesta aula, você aprenderá como um requisito é mantido e gerenciado ao longo do ciclo de vida
de um projeto, assim como sobre os cenários de uso dos requisitos e como elaborar casos de
uso para os requisitos elucidados.
Você verá exemplos práticos de elaboração do diagrama de casos de uso e o nível de abordagem
que deverá adotar para escrever seus requisitos funcionais e não funcionais.
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao
visto na aula, mas esteja sempre buscando novas formas de se atualizar.
Bons estudos!

Requisitos no ciclo de vida do projeto

Disciplina

ENGENHARIA DE REQUISITOS

Após a fase de coleta inicial dos requisitos funcionais e não funcionais de um sistema, do
processo de validação dos requisitos junto ao cliente e, por fim, da priorização conforme a
necessidade das partes interessadas, é chegada a hora da implementação do produto.
Ao dar início à fase de codificação, a equipe de desenvolvimento poderá ter dúvidas quanto ao
que está escrito no documento de especificação de requisitos, ou história de usuário, sendo
necessário perguntar ao analista que realizou as entrevistas com o cliente, evitando retrabalhos e
codificação errada pela falha no entendimento.
Muitas vezes, durante o processo de construção da aplicação, o cliente se dá conta de que o que
está sendo desenvolvido não irá, de fato, satisfazer suas expectativas com o produto, solicitando
mudanças nos requisitos previamente levantados. Em metodologia tradicional de
desenvolvimento, como a cascata, que os requisitos precisam estar totalmente levantados e
validados antes do início da fase de construção da aplicação, uma alteração posterior de
qualquer requisito pode representar a invalidação do projeto ou, em casos menos drásticos,
causar atraso no prazo de entrega acordado, com reflexos no orçamento, que será maior.
Já para projetos que utilizem metodologias ágeis ou que permitam modificações após a fase de
especificação de requisitos inicial, é possível alterar o documento de especificação e/ou história
de usuário, para que se adeque às novas necessidades apontadas pelo cliente. O time de
desenvolvedores, por sua vez, precisará adequar a aplicação que está sendo construída ao que
foi solicitado como ajustes, garantindo que a entrega de valor ao usuário será feita.
A priorização dos requisitos é um outro fator que também pode ser alterado a qualquer momento
do ciclo de vida do projeto, sempre buscando respeitar o nível de importância de cada requisito,
definido pelas partes interessadas.
Disciplina

ENGENHARIA DE REQUISITOS

Durante as fases de testes e entrega, após a apresentação ao cliente do que foi construído, ainda
podem ser solicitados ajustes, que precisarão ser negociados com o analista de requisitos (ou
product owner, em caso de utilização da metodologia ágil SCRUM), para que o time de
desenvolvedores possa fazer o melhor para atender às solicitações, respeitando o orçamento e o
prazo acordados.
Uma vez que a aplicação seja entregue ao cliente final, novos requisitos e necessidades ainda
podem surgir, o que precisará realizar um gerenciamento de mudanças, por parte do analista
responsável pela fase de levantamento de requisitos iniciais, para garantir que, mesmo após a
solicitação das alterações nos requisitos já levantados (e, muitas vezes, até já implementados), o
histórico das alterações possa ser mantido.
Garantir que o documento de requisitos esteja de acordo com a realidade do código construído
auxiliará o entendimento de novos integrantes da equipe de desenvolvedores, da mesma forma
que dirimir eventuais dúvidas futuras sobre as regras de negócio pelos membros da equipe de
desenvolvimento e/ou manutenção (sustentação).
Alguns fatores podem desencadear alterações ou surgimento de novas funcionalidades.
Sommerville (2011) e Pressman e Maxim (2021) destacam, como sendo os principais, os
seguintes:

Alteração nos equipamentos de hardware disponíveis, em legislações ou prioridades do

negócio.
Diferença de interesses entre os patrocinadores e os usuários finais do sistema que está
em desenvolvimento.
Conflito de interesses em sistemas com muitos interessados, gerando necessidades e
prioridades diferentes e, em muitos casos, até contraditórias.

Cenários de uso de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

A especificação de um requisito se inicia pela sua forma macro, ou seja, pela descrição simples
da funcionalidade que deve ser provida pela aplicação. Deste modo, em um primeiro momento, o
cliente não especificará detalhes de quais regras de negócio a funcionalidade implementará, nem
quais os tipos de campos existentes que serão manipulados ou até quais os perfis que terão
acesso e quais não terão.
Para garantir que a equipe de desenvolvimento possa entender, de forma técnica, o que está
sendo solicitado pelo cliente, é preciso que ocorra um detalhamento de como o requisito deverá
funcionar, com suas regras de negócio, interações com outras telas (ou módulos do sistema e
até de outros sistemas, caso ocorra), permissões de acesso ou utilização da funcionalidade,
mensagens de erro que devem ser apresentadas, em caso de alguma inconsistência na entrada
de dados, entre outras questões técnicas.
A este detalhamento de um requisito damos o nome de cenários de caso de uso. Os tipos de
cenários de caso de uso existentes podem ser classificados como:

Principal: fluxo considerado esperado para a funcionalidade mapeada, ou seja, o “caminho

feliz” com as entradas esperadas e a resposta esperada para o requisito.
Alternativos: fluxos que podem estar mapeando ações adversas que o usuário pode estar
executado, que foge do caminho principal a ser percorrido, como ausência de
preenchimento de campos obrigatórios, escolhas de opções que não sejam a opção para o
fluxo principal etc. São ações que alteram o comportamento da aplicação, ao ponto de
desviar as respostas fornecidas como padrão.
Exceção: um fluxo de exceção compreende erros ou bugs que podem acontecer durante a
execução de uma funcionalidade. Por exemplo: se você está executando uma
funcionalidade de pagamento de uma compra e a máquina do cartão não consegue
estabelecer uma conexão com o banco responsável pelo cartão que está sendo utilizado,
então aconteceu um fluxo de exceção.
Disciplina

ENGENHARIA DE REQUISITOS

Os cenários de caso de uso se aplicam somente aos requisitos funcionais do sistema, já que
estes representam as ações que devem ser implementadas e providas ao usuário final. Os
requisitos não funcionais acabam fazendo parte do detalhamento dos casos de uso funcionais,
tendo em vista que são considerados transversais e acabam englobando uma ou mais
funcionalidades do sistema.
Quanto mais fluxos alternativos forem levantados e documentados, assim como as possíveis
exceções que podem acontecer, melhor será a resposta do sistema ao comportamento do
usuário e mais “blindada” sua aplicação estará contra os mais variados tipos de comportamento
de seus usuários finais. As exceções serão úteis para apresentar mensagens amigáveis ao
usuário final, em caso de alguma falha acontecer.
Um fluxo alternativo aparece no diagrama de caso de uso como uma ação estendida, utilizando a
indicação <<extend>>. Um exemplo está apresentado na Figura 1

Fonte: elaborada pela autora.

Conforme ilustrado na Figura 1, o ator Usuário RH poderá utilizar a funcionalidade Cadastrar

aluno, que deverá ter, como fluxo alternativo, a situação na qual um aluno já está cadastrado.
Então, Aluno já cadastrado estende da funcionalidade Cadastrar aluno.

Caso de uso de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

Para escrever um requisito, de forma que seja validado pelo cliente e possa, posteriormente, ser
implementado pela equipe de desenvolvimento, é preciso que haja uma concordância em relação
a como o sistema deve se comportar entre todos os envolvidos (stakeholders) como
patrocinadores.
É preciso, para que a validação do requisito possa ocorrer, que várias visões de um mesmo
requisito sejam elaboradas, iniciando-se pela especificação em linguagem natural, que se
converterá em diagramas de casos de uso, para traduzir, visualmente, as interações entre os
diferentes papéis na aplicação e as funcionalidades por ela providas.
Um diagrama de caso de uso apresentará, segundo Larman (2000), de forma visual e clara, todas
as interações entre um determinado ator (usuário final, por exemplo) e as funções por ele
usadas, conforme apresentado na Figura 2.
Disciplina

ENGENHARIA DE REQUISITOS

Fonte: elaborada pela autora.

A Figura 2 apresenta um exemplo de diagrama de caso de uso para uma aplicação de cadastro
de alunos. Neste caso, o ator (usuário do RH) poderá executar as funções de cadastrar aluno,
alterar cadastro de aluno e desativar cadastro de aluno. Para outros atores, outras
funcionalidades podem ser associadas, deixando claro para os stakeholders envolvidos quais
papéis de usuário poderão fazer que tipo de ação no sistema.
Um caso de uso possui alguns elementos visuais básicos para sua construção:

Ator: usuário ou sistema que realizará uma funcionalidade na aplicação.

Casos de uso: ações que representarão os requisitos funcionais e que serão executadas
pelo ator.
Relacionamentos: setas que indicam o fluxo de quem executará qual ação. Poderão
representar uma resposta (quando o sistema fornece um retorno para o ator ou outra
funcionalidade) ou uma requisição (quando o ator executa alguma ação).

Um ator pode ser também um outro sistema ou módulo, que possua algum tipo de interação com
a aplicação que será construída. Um bom exemplo é a integração entre diferentes sistemas, em
uma mesma organização, para compartilhamento de informações e/ou utilização de APIs, tanto
para realização de consultas como cadastros de dados.
Após a construção de todos os casos de uso, mapeando a interação entre os diferentes atores e
as funcionalidades providas pela aplicação, será necessário detalhar os casos de uso mapeados,
ou seja, especificar os fluxos do caso de uso, seja um fluxo principal (entradas e respostas
esperadas) ou fluxos alternativos (entradas faltantes, com caracteres não permitidos, sequência
de comandos inadequada etc.).
Disciplina

ENGENHARIA DE REQUISITOS

Os fluxos alternativos servirão como critérios de validação da correta implementação do caso de

uso, da mesma forma que acontece com o fluxo principal. Caso algum problema seja encontrado
pela equipe que está realizando os testes na funcionalidade, o fluxo no qual o desvio de
comportamento foi notado será apontado para que a equipe de desenvolvimento possa realizar
as devidas correções.
Além dos diagramas de casos de uso, outros diagramas UML podem ser utilizados para dar mais
clareza aos interessados, em termos de entendimento das funcionalidades especificadas, como
os diagramas de sequência.

Videoaula: Análise de requisitos

Este conteúdo é um vídeo!

Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.

Olá, estudante! Neste vídeo, você aprenderá a importância do gerenciamento dos requisitos ao
longo de um projeto, como escrever um caso de uso e qual o nível de abordagem adequado para
as visões macro e detalhada de um requisito, seja ele funcional ou não funcional. Serão
apresentados exemplos práticos, para que você possa compreender toda a teoria abordada.
Bons estudos!

Saiba mais
Disciplina

ENGENHARIA DE REQUISITOS

Uma boa ferramenta gratuita para gerenciamento de requisitos e acompanhamento do trabalho

do time de desenvolvimento é a Trello ou a Ummense.
Para criar seus diagramas de caso de uso gratuitamente, você poderá utilizar a Yuml, a Ceately
ou a Visual Paradigm.

Referências
Disciplina

ENGENHARIA DE REQUISITOS

LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientado a

objetos. Porto Alegre, RS: Bookman, 2000.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: Mc Graw Hill
Education, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011

Aula 4
Modelagem de requisitos

Introdução
Disciplina

ENGENHARIA DE REQUISITOS

Olá, estudante!
Nesta aula, você aprenderá quais são os artefatos gerados no processo de levantamento de
requisitos, além da forma como o levantamento de requisitos acontece com metodologias ágeis
e quais artefatos são construídos e mantidos com estas metodologias. Abordaremos também os
requisitos voltados para sistemas autoadaptativos, voltados para sistemas que podem alterar
seu comportamento em tempo de execução, conforme sua necessidade, refletida pelo ambiente
no qual estão inseridos, sem nenhuma intervenção humana.
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao
visto na aula, mas esteja sempre buscando novas formas de se atualizar.
Bons estudos!

Artefatos do levantamento de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

Artefatos são produtos gerados como resultados de uma fase (ou processo). Quando nos
referimos à fase da especificação de requisitos, os artefatos gerados são elaborados como
resultado das entrevistas com o cliente, para levantamento das funcionalidades da aplicação que
será desenvolvida, assim como do refinamento destes requisitos e das eventuais mudanças que,
eventualmente, podem ocorrer nos requisitos já especificados.
O documento de especificação de requisitos é tido como o principal documento que conterá os
requisitos (funcionais e não funcionais) necessários para que a equipe de desenvolvimento
possa construir a aplicação. Este documento precisa ser criado e mantido, com as devidas
atualizações, ao longo de todo projeto, tendo em vista que é por ele que os desenvolvedores se
basearão e, em caso de dúvidas em regras de negócio, consultar.
Ainda neste documento, é importante constar os diagramas que foram construídos para as
diferentes visões dos requisitos, facilitando o processo de validação pelo cliente (e demais
partes interessadas). Então, diagramas de caso de uso e diagramas de sequência podem fazer
parte do texto que precede os requisitos especificados.
A Figura 1 apresenta um exemplo de um diagrama de sequência para o cadastro de um paciente
no sistema.
Disciplina

ENGENHARIA DE REQUISITOS

Fonte: elaborada pela autora.

Conforme apresentado na Figura 1, o ator usuário interagirá com a tela de cadastro de pacientes
para que um paciente seja inserido no banco de dados da aplicação. O objetivo deste diagrama é
apresentar uma sequência de passos que serão executados e/ou retornados pelo/ao cliente. O
cliente, então, iniciará a interação com o sistema a partir do preenchimento dos dados da tela do
cadastro de paciente que terão os dados validados (ou não) pela classe paciente. Caso os dados
não sejam validados corretamente, seguindo as regras de negócio, mensagens de dados
inválidos ou paciente já cadastrado poderão ser retornadas ao ator (usuário), interrompendo o
fluxo. Se o processo de validação for concluído com sucesso, então os dados serão inseridos no
banco de dados e uma mensagem de paciente cadastrado com sucesso será retornada ao
usuário que criou a requisição.
Os diagramas de caso de uso apresentarão as interações entre os atores e as funcionalidades do
sistema, enquanto os diagramas de sequência apresentarão a sequência de passos para uma
determinada funcionalidade, desde a criação da requisição pelo usuário final até a resposta
entregue pelo sistema, após o processamento da requisição, numerando a ordem dos passos.
Outro artefato importante são as requisições de mudança, geradas sempre que um requisito já
especificado precisa sofrer alterações (apenas para se adequar à necessidade do usuário final)
ou quando uma nova funcionalidade será implementada no sistema (caracterizando a
manutenção evolutiva).
Quando se utiliza a prototipação como ferramenta auxiliar para validação das funcionalidades
pelo cliente, os protótipos construídos também são considerados artefatos de saída desta fase,
já que serão repassados à equipe de desenvolvimento para que o design já acordado para o
sistema possa ser mantido.
A Figura 2 apresenta um exemplo de diagrama de caso de uso para o cenário apresentado na
Figura 1.
Disciplina

ENGENHARIA DE REQUISITOS

Fonte: elaborada pela autora.

Conforme apresentado na Figura 2, a visão do caso de uso tende a ser mais macro que a visão
apresentada no diagrama de sequência, que detalhará, para cada item de caso de uso, os passos
necessários para executar a ação. Sendo assim, o diagrama de caso de uso visa apresentar, de
forma resumida, todas as interações possíveis de um ator no sistema.
Outro ponto importante, que também gera um artefato da fase de especificação de requisitos, é o
documento contendo o glossário dos termos do negócio, que serão aplicados ao longo da
construção do sistema. Muitas vezes, um mesmo termo pode ter diferentes significados,
dependendo do contexto no qual é utilizado. O glossário servirá como nivelamento para que
todos, independentemente de qual setor pertençam, possam ter o mesmo entendimento a
respeito dos conceitos utilizados pelo negócio.
Após o acordo a respeito do design do sistema e dos demais documentos já mencionados, é
importante que você especifique o modelo de arquitetura que servirá de base para a construção
do sistema, com os elementos de rede que serão utilizados, suas interconexões, a conexão com
outros sistemas (caso ocorra), entre outros pontos importantes para que, tanto os componentes
de hardware sejam visíveis quanto, em termos de sistema, a disposição das camadas da
aplicação e suas respectivas classes possam ser especificadas. O modelo de arquitetura de
classes do sistema servirá como base para a equipe de desenvolvimento, enquanto o modelo de
arquitetura de hardware poderá ser apresentado e validado pelos stakeholders.

Levantamento ágil de requisitos

Disciplina

ENGENHARIA DE REQUISITOS

As metodologias ágeis de desenvolvimento têm por objetivo simplificar o processo de

construção de software, de modo a atender de forma efetiva às necessidades do cliente. Isso é
possível devido às constantes entregas parciais do produto, o que faz com que o cliente dê
feedbacks constantes e não precise esperar tanto tempo (meses até) para utilizar o produto, uma
vez que as partes entregues já podem ser implantadas em produção e já podem ser utilizadas
pelo usuário final.
Conforme Beck et al. (2001), é mais importante uma aplicação em funcionamento que manter
uma documentação abrangente e detalhada, o que implica a necessidade de simplificar o
processo de documentação da aplicação somente ao essencial. Comentários de código e o
documento contendo as histórias ou estórias (fica a cargo do time escolher a melhor
Disciplina

ENGENHARIA DE REQUISITOS

denominação) de usuário serão, talvez, as únicas documentações disponíveis em um projeto que

seja construído através destas metodologias.
Diferente do processo tradicional, no qual todos os requisitos (funcionais e não funcionais)
precisam ser especificados antes do início do processo de codificação, com a metodologia ágil é
possível especificar apenas um conjunto de requisitos logo no começo, tidos como os mais
importantes para o negócio e para a necessidade dos patrocinadores, porém essa lista pode
crescer ao longo do andamento do projeto.
Para times que utilizam o framework SCRUM, um dos mais adotados pelas equipes de
desenvolvimento na atualidade para desenvolvimento de projetos ágeis, os requisitos podem ter
níveis de especificação e detalhamento diferentes, conforme apresenta Schwaber e Sutherland
(2013), a depender da fase na qual eles se encontram:

Backlog do produto: nesta fase, os requisitos estão especificados em sua forma macro,
sem nenhum tipo de detalhamento, ainda não se encontrando prontos para que a equipe de
desenvolvimento possa codificá-los. Antes do início do projeto, os requisitos levantados se
encontram nesse estágio, podendo ser inseridos novos requisitos à medida que se dá o
andamento do projeto.
Backlog da sprint: nesta fase, um conjunto de requisitos macro, retirados do conjunto que
compõe o backlog do produto, serão refinados junto ao cliente e, após todos os detalhes de
suas regras de negócio, serão julgados pela equipe de desenvolvedores, conforme suas
experiências passadas e o tempo disponível para o próximo ciclo de desenvolvimento
(sprint), que definirão quais tarefas serão entregues ao final da próxima sprint. Tudo que
tiver definido como compondo o conjunto do backlog da sprint deverá ser entregue ao
cliente para homologação ao final do ciclo.

O refinamento de um requisito retirado do conjunto do backlog do produto é feito através de um

documento denominado história (ou estória) de usuário, que deverá conter todas as regras de
negócio envolvidas na implementação do requisito, os papéis que utilizarão a funcionalidade,
assim como as regras de validação (chamadas de critérios de aceitação).
É importante que um membro da equipe de desenvolvimento esteja com sólidos conhecimentos
do negócio e tenha contato direto com o cliente, sendo sua “voz” dentro da equipe, sanando
qualquer dúvida que, eventualmente, os desenvolvedores possam ter acerca dos detalhes de
implementação do requisito. Este papel, dentro de uma equipe ágil, é denominado product owner
(ou dono do produto). Deverá ser a primeira pessoa a quem os desenvolvedores deverão recorrer
em caso de dúvidas. Caso este não saiba ou precise esclarecer algo sobre o negócio com o
cliente, de forma direta, então somente esta pessoa realizará este contato.

Requisitos autoadaptativos
Disciplina

ENGENHARIA DE REQUISITOS

Conforme Batista (2022), aplicações autoadaptáveis são aquelas capazes de moldar seu
comportamento, alterando-o conforme necessário, para se adequar ao meio que está inserido.
Sendo assim, é possível realizar avaliações que, como resultado, podem acarretar melhoria de
desempenho da aplicação ou até modificar um comportamento tido como errado (ou que
estejam causando falhas), sem que ocorra intervenção humana para esta adaptação.
O intuito pelo qual existem aplicações autoadaptáveis é a necessidade de se gerenciar
aplicações complexas, necessidade de tratamento de condições inesperadas e, inclusive, a
incerteza acerca dos requisitos da aplicação.
Aplicações com as características de adaptação possuem propriedades, dentro de conjuntos
bem definidos e conhecidos, caracterizadas por self-*. Cada categoria de propriedade self-*
definirá um tipo de comportamento adaptável, como apresenta Batista (2022):

Autoconfiguração: capacidade de responder a mudanças através da autoconfiguração,

podendo instalar, atualizar, integrar, compor e decompor entidades de software.
Autocura: capacidade de se recuperar de interrupções, podendo, inclusive, se antecipar a
problemas, tomando as medidas necessárias para evitar uma falha.
Auto-otimização: capacidade de gerenciamento de desempenho e alocação de recursos,
satisfazendo os requisitos não funcionais dos diversos stakeholders da aplicação.
Autoproteção: capacidade de detectar problemas com segurança e se recuperar de
possíveis falhas. Tanto pode defender a aplicação contra-ataques maliciosos como pode
mitigar os efeitos de um ataque e tomar as precauções necessárias para proteção.
Disciplina

ENGENHARIA DE REQUISITOS

Requisitos autoadaptáveis, por comporem aplicações que podem ajustar seu comportamento
em tempo de execução, conforme as diversas variáveis que são analisadas, passam a ser
analisadas em tempo de execução.
Quando nos referimos ao processo de levantamento de requisitos para aplicações
autoadaptáveis, é importante mencionar o nível de incerteza destes requisitos, o que torna o
processo de elucidação das funcionalidades parcialmente incompleto. Em uma aplicação
tradicional, sem a característica de adaptação, as funcionalidades precisam ser mapeadas logo
no princípio do projeto, com um alto grau de certeza, ou seja, para cada requisição de entrada,
uma resposta esperada já é conhecida ainda na fase de especificação.
Uma forma apresentada por Batista (2022) para a elucidação de requisitos para aplicações
autoadaptáveis é a utilização do método de perguntas para os requisitos essenciais de
autoadaptação:

Onde: perguntas relacionadas com pontos onde ocorrem a necessidade de mudança. O

que será alterado e em qual camada? Auxilia na localização do problema a ser resolvido
com a adaptação.
Quando: perguntas relacionadas ao tempo no qual adaptações precisam ocorrer, como a
decisão de quando uma mudança será possível ser realizada, se existe algum momento
específico para aplicação, conforme necessidade do sistema, e qual a frequência de
alteração.
O quê: definem quais atributos ou artefatos do sistema serão alterados por conta da
adaptação.
Por quê: apresenta a motivação para a construção do sistema adaptativo.
Quem: definem o nível de integração humana e automação da aplicação.
Como: define como os requisitos adaptáveis serão configurados e quais as condições mais
adequadas para a adaptação.

Videoaula: Modelagem de requisitos

Este conteúdo é um vídeo!

Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.

Olá, estudante! Neste vídeo, você aprenderá, de forma prática, exemplos de artefatos resultantes
da fase de levantamento de requisitos utilizando metodologia tradicional em cascata, assim
como um exemplo de escrita de uma história de usuário na metodologia ágil. Por último, você
verá os requisitos voltados para aplicações autoadaptativas e como podem ser especificados.
Bons estudos!
Disciplina

ENGENHARIA DE REQUISITOS

Saiba mais

O guia para o SCRUM foi atualizado em 2020. Para conferir as atualizações e conhecer mais
sobre o framework ágil SCRUM, acesse O Guia Definitivo para o Scrum: As Regras do Jogo
Uma ferramenta gratuita para auxiliar na escrita de histórias de usuário é a Miro. Você poderá
também contar com a ferramenta Trello, gratuita, para a escrita das histórias de usuário e o
acompanhamento do progresso do time de desenvolvimento.

Referências
Disciplina

ENGENHARIA DE REQUISITOS

BATISTA, A. P. Decomposição de requisitos de confiabilidade para sistemas autodaptativos

utilizando o NFR framework. 2022. Trabalho de Conclusão de Curso (Graduação em Engenharia
de Software) – Universidade Federal do Ceará, Quixadá, 2022. Disponível em:
[Link] Acesso em: 6 jun.
2022.
BECK, K. et al. Manifesto para desenvolvimento ágil de software. [S. l.]: [s. n.], 2001. Disponível
em: [Link] Acesso em: 6 jun. 2022.
SCHWABER, K.; SUTHERLAND, J. Um guia definitivo para o SCRUM: as regras do jogo. Scrum,
2013. Disponível em: [Link]
[Link]. Acesso em: 6 jun. 2022.

Aula 5
Revisão da unidade

Analisar e ser capaz de classificar os principais tipos de requisitos de

software
Disciplina

ENGENHARIA DE REQUISITOS

Nesta unidade, você aprendeu que a fase de especificação de requisitos é considerada a mais
importante para o processo de desenvolvimento de uma nova aplicação. É nesta fase, a partir
das entrevistas feitas com o cliente, que as funcionalidades da aplicação serão levantadas em
sua forma inicial.
Após a necessidade das partes interessadas no produto (stakeholders) ser mapeada em
requisitos funcionais (que representam as ações que, de fato, o sistema proverá) e não
funcionais (que representam as necessidades secundárias, como segurança, autenticação,
auditorias etc.), o documento de especificação de requisitos será criado e repassado para a
equipe de desenvolvedores, que dará início à fase de codificação da aplicação.
Ao longo do ciclo de vida do projeto, é possível que os requisitos mapeados, inicialmente, sofram
alterações, que deverão ser refletidas no documento de especificação de requisitos, mantendo-o
sempre atualizado. Essas alterações podem surgir oriundas da percepção do cliente que alguma
regra importante faltou ou está incompleta, até mesmo após a validação dos artefatos gerados
como resultado da fase de levantamento de requisitos.
Artefatos são os produtos gerados como resultado de uma fase, que servirão de subsídios para a
próxima fase do projeto. Para a fase da especificação de requisitos, os artefatos resultantes
mais comuns são:

Documento de especificação de requisitos: contendo o mapeamento de todos os requisitos

do sistema, sejam funcionais ou não funcionais.
Diagramas de caso de uso ou outros tipos de diagramas UML: por serem um recurso visual,
é comum que diagramas UML sejam criados, como os de caso de uso (que apresentarão a
Disciplina

ENGENHARIA DE REQUISITOS

relação entre os atores do sistema e os requisitos por eles utilizados) e diagramas de

sequência (que apresentarão o fluxo de uma funcionalidade, desde a interação inicial do
usuário até a resposta retornada).
Protótipos das telas do sistema: mostrarão ao cliente uma prévia de como o sistema se
apresentará visualmente, com disposição de campos na tela, esquema de cores, estilização
e demais recursos visuais.

Durante o processo de levantamento de requisitos, é importante que o cliente indique quais as

funcionalidades que agregarão maior valor ao produto, conforme suas expectativas. Dessa
forma, é feita a priorização dos requisitos, que pode ser alterado ao longo do andamento do
projeto. Caso o produto tenha muitos interessados e, consequentemente, conflito de interesses
naquilo que deverá ser prioridade, é importante a utilização de técnicas de priorização, com a
finalidade de se chegar a um consenso de benefício comum.
Com o advento das metodologias ágeis, principalmente do framework SCRUM, o processo de
desenvolvimento foi otimizado para que o cliente pudesse estar mais próximo ao produto,
fornecendo feedbacks constantes e validando as entregas com suas reais necessidades. Um
ponto que ficou enxuto com o SCRUM foram os artefatos resultantes da fase de levantamento de
requisitos. O documento de especificação de requisitos, complexo e demorado de ser elaborado,
foi substituído pelas histórias de usuário, mais simples e rápido de ser escrito.
Você também aprendeu sobre os requisitos voltados para aplicações autoadaptáveis, que são
especificados de forma incompleta, tendo em vista a incerteza da aplicação, que, em tempo de
execução, pode alterar seu comportamento de acordo com análises do ambiente ou interações
do usuário.

Videoaula: Revisão da unidade

Este conteúdo é um vídeo!

Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.

Olá, estudante! Neste vídeo, faremos um resumo de todo o conteúdo abordado a respeito da fase
de especificação de requisitos, utilizando tanto a metodologia tradicional (em cascata) quanto a
metodologia ágil SCRUM. Abordaremos os artefatos, fazendo um comparativo entre as duas
metodologias, a forma de trabalho com SCRUM e as diferenças na priorização dos requisitos
entre as duas metodologias.
Bons estudos!

Estudo de caso
Disciplina

ENGENHARIA DE REQUISITOS

Você é funcionário de uma grande organização, que foi contratada para desenvolver uma nova
aplicação WEB com o objetivo de realizar agendamento de consultas on-line em uma clínica
médica.
Foi definido que você, por já ter conhecimento em análise de requisitos, participaria do processo
de especificação dos requisitos junto ao cliente, envolvendo-se no processo de entrevistas e
escrevendo os documentos de especificação de requisitos e/ou histórias de usuário.
Um outro analista de requisitos da sua empresa, anteriormente, já tinha feito algumas entrevistas
iniciais de levantamento de requisitos, com participação do cliente, que culminaram com a
elucidação dos principais requisitos funcionais e não funcionais da aplicação.
Para a aplicação, algumas ações básicas já foram especificadas em reuniões com o cliente, tais
quais:

Cadastro de usuário no sistema.

Cadastro de perfil de usuário no sistema.
Atribuição de perfil de usuário a usuário.
Cadastramento de agenda do médico.
Marcação de consultas para um médico.
Cancelamento de consulta agendada.

Os requisitos não funcionais definidos para a aplicação foram:

Autenticação baseada em usuário e senha. Senha precisa ter um padrão forte, com, no
mínimo, oito caracteres, sendo pelo menos uma letra maiúscula, uma minúscula, um
caractere especial e dois números.
Somente será possível acessar as funcionalidades de cadastramento de usuário, cadastro
de perfil e associação de perfil ao usuário para usuários com perfil administrador no
Disciplina

ENGENHARIA DE REQUISITOS

sistema.
Somente será possível acessar o agendamento de consultas caso o usuário esteja logado
no sistema.

Tendo em vista os requisitos listados, elabore um documento de especificação de requisitos

contendo:

Diagrama de caso de uso para os requisitos levantados.

Detalhamento da especificação de requisitos para cada requisito funcional, contendo entre
um e três fluxos alternativos para cada requisito.
Considerar, para cada requisito funcional, os requisitos não funcionais, englobando-os na
escrita da especificação do requisito.

Após a elaboração do documento de especificação de requisitos, escolha três dos requisitos

funcionais listados e elabore a história de usuário correspondente, seguindo o modelo de escrita
apresentado em aula. A história de usuário precisará ter os respectivos critérios de validação do
requisito, regras de exceção (se houverem). Lembrando que, para as histórias de usuário, os
requisitos não funcionais são escritos nos critérios de validação.
Reflita

Elabore as regras de negócio conforme seu entendimento sobre o processo.

Para o documento de especificação de requisitos, criar, inicialmente, os diagramas de caso
de uso.
Para as histórias de usuário, considerar a “persona”, isto é, o perfil de usuário que realizará
a ação.

Videoaula: Resolução do estudo de caso

Este conteúdo é um vídeo!

Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.

Para resolver o estudo de caso, será preciso, inicialmente, criar os diagramas de caso de uso do
documento de especificação de requisitos. Para isso, você poderá utilizar as sugestões de
ferramentas on-line mencionadas ao longo das aulas, especificando o ator como o perfil do
usuário que realizará a ação (funcionalidade) no sistema.
Crie uma seção do documento para apresentar os diagramas criados (um diagrama por ator, ou
seja, por perfil no sistema). Após isso, elabore o detalhamento dos requisitos, conforme a tabela
apresentada em aula, nomeando conforme a ordem de prioridade para o requisito, seguindo-se
da descrição da funcionalidade e dos fluxos alternativos. Elabore os fluxos alternativos como
Disciplina

ENGENHARIA DE REQUISITOS

“caminhos” que desviem do fluxo padrão definido (para isso, é preciso que você defina qual será
o fluxo padrão para cada requisito). Caso a funcionalidade possa apresentar algum tipo de erro,
que precise ser tratado para ser apresentado ao usuário final, elabore os fluxos de exceção. Caso
nenhum fluxo de exceção seja definido, não terá problemas.
Após a escrita detalhada de cada requisito, que estará presente no documento de especificação
de requisitos em formato de tabela (com cada requisito representando uma tabela diferente, com
seu detalhamento e fluxos alternativos), está na hora de partir para a escrita das histórias de
usuário.
Para a escolha de quais dos requisitos serão escritos em formato de história de usuário, é
preciso definir quais deles agregarão maior valor ao usuário final, priorizando-os. Desta forma,
escreva as histórias de usuário, considerando sempre a “persona”, isto é, o perfil de usuário que
utilizará a função no sistema, definindo a ação que será executada e qual o objetivo que ele
atingirá ao realizar tal ação.
As histórias de usuário precisarão ficar escritas em um documento à parte do de especificação
de requisitos.
Lembre-se de que é preciso especificar, como critério de validação, os requisitos não funcionais
em cada história que necessite. Por exemplo: se o usuário só poderá acessar a funcionalidade
caso esteja devidamente autenticado no sistema, o critério de validação para a funcionalidade
especificará que o acesso só poderá acontecer caso o usuário esteja logado no sistema e tenha
perfil com a devida permissão de acesso.

Resumo visual
Disciplina

ENGENHARIA DE REQUISITOS

Fonte: elaborada pela autora.

Fonte: elaborada pela autora.

Referências
Disciplina

ENGENHARIA DE REQUISITOS

AGUIAR, F. Product Backlog Building: um guia prático para criação e refinamento de backlog para
produtos de sucesso. Porto Alegre, RS: Caroli, 2021.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 9. ed. São Paulo, SP:
AMGH, 2021