22E0FB69-3A65-4928-9D5D-F323BC80D73B

Prévia do material em texto

Engenharia de
Requisitos de
Software
06/11/2024, 11:25 AM
Página 1 de 25
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de
Brasília
Apresentação 
Fonte: https://goo.gl/HbAS5T
Na aula anterior, você estudou o que representa um requisito de
software, os principais problemas encontrados para identificá-los e os
tipos de requisitos existentes.
Pôde constatar que a obtenção dos requisitos para a construção de um
sistema informatizado é muito importante, posto que uma coleta
malfeita e sem os detalhes necessários pode induzir a produção de um
sistema que não atenda plenamente às necessidades do cliente.
Nesta aula, você conhecerá as etapas que compõem a Engenharia de
Requisitos, como podem ser levantados os requisitos essenciais
relativos ao software, e as técnicas disponíveis para extrair os
conhecimentos necessários para o desenvolvimento do software.
Mãos à obra!
06/11/2024, 11:25 AM
Página 2 de 25
Vídeo 
Unidade 01 - Aula 02 - Engenharia de Requisitos (MSc. Ed…
06/11/2024, 11:25 AM
Página 3 de 25
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de
Brasília
Conteúdo 
Introdução à Engenharia de Software
Segundo  Pressman   (2006), o processo de engenharia de requisitos visa
garantir que o sistema gerado por esses requisitos atenda adequadamente às
necessidades e satisfaça as expectativas dos clientes. O autor afirma ainda
que:
a engenharia de requisitos fornece um mecanismo adequado para
entender o que o cliente deseja, analisar as necessidades, avaliar a
exequibilidade, negociar uma solução razoável, especificar a solução
de maneira não ambígua, validar a especificação e administrar os
requisitos à medida que eles são transformados num sistema em
operação. (PRESSMAN, 2006, p.250)
Assim, com o processo de engenharia de requisitos, espera-se que o sistema
atenda ao propósito estabelecido e atinja o objetivo esperado pelo cliente.
Perceba que este é um processo complexo que exige muita habilidade do
engenheiro de software, conhecido no mercado como analista de requisitos.
Ainda assim, esta é uma atividade que independe de paradigma. Seja qual for o
paradigma de engenharia de software adotado, a análise de requisitos deverá
ser levada em consideração e, quanto mais sólida e bem feita for essa
atividade, maiores as chances de se chegar a um projeto que tenha qualidade.
Continuando com Pressman (2006), o processo de engenharia de requisitos
pode ser descrito em cinco passos distintos, a saber: elicitação de requisitos,
análise e negociação de requisitos, especificação de requisitos, validação de
requisitos e gestão de requisitos. A seguir, você estudará cada um deles.
06/11/2024, 11:25 AM
Página 4 de 25
Mobile User
Elicitação de Requisitos
Esta etapa consiste em retirar a correta informação dos clientes. É necessário
perguntar-lhes qual será o propósito do sistema, quais as informações a serem
geradas pelo sistema e que serão necessárias para o negócio, e como será a
utilização do sistema. Apesar de parecer fácil, na prática, pode não ser assim
tão simples. Pressman (2006) aponta alguns motivos que podem gerar
dificuldades no processo de elucidação dos requisitos.
Problemas de escopo:  os limites do sistema são mal definidos. Muitas
vezes, não se sabe ao certo quais os assuntos abrangidos e até onde o
sistema deve ir. Há clientes/usuários que especificam detalhes técnicos
desnecessários, que podem confundir, no lugar de esclarecer.
Problemas de entendimento:  os clientes/usuários, muitas vezes, não
entendem completamente o domínio do problema, não sabem direito o
que é ou não necessário, têm dificuldade de comunicar as necessidades
ao analista de requisitos, omitem informações que acreditam ser
“óbvias”, especificam mal os requisitos, sendo conflitantes com os
requisitos de outros usuários, ambíguos ou mesmo impossíveis de se
testar.
Problemas de volatilidade:  um requisito pode ser visto de maneiras
diferentes por pessoas diferentes. Isso pode gerar mudanças nos
requisitos, à medida que o projeto se encontra em andamento. Da mesma
forma, os processos de negócios também evoluem e mudam com o
tempo e isso pode representar mudanças nos requisitos do sistema.
O levantamento ou elicitação de requisitos de um sistema consiste de uma
etapa muito importante no desenvolvimento de projetos. Um bom
levantamento de requisitos poderá poupar tempo e dinheiro no decorrer do
projeto. Entender aquilo que o cliente deseja (ou o que o cliente acredita que
precisa) e compreender as regras do negócio, também chamadas de
processos do negócio, consiste no cerne que move essa questão. Aliado ao
levantamento de requisitos existe o mapeamento dos processos, vital para a
melhoria dos resultados obtidos pelo levantamento de requisitos.
Levantamento de requisitos é o nome comumente usado para a atividade de
descoberta dos requisitos.
06/11/2024, 11:25 AM
Página 5 de 25
Mobile User
Pressman (2006) utiliza a expressão “elicitação de requisitos”, neologismo do
inglês  requirements elicitation, também muito vista nas várias edições do
livro Requirements Engineering de Kotonya e Ian Sommerville  (1998). Nesta
disciplina, será adotada a expressão  levantamento de requisitos, a qual é
bastante difundida na indústria de desenvolvimento de software.
Saber exatamente o que o cliente quer pode parecer uma atividade simples,
mas, infelizmente, não é. Pelo contrário, essa tarefa é bastante complexa e
difícil de ser executada. Isso ocorre por vários motivos. Pressman (2006) cita
alguns deles, a saber: o volume de informações a ser considerado pode ser
bastante extenso, pode ocorrer a má informação por parte dos
clientes/usuários, pode ocorrer a má interpretação por parte dos analistas de
requisitos, as compreensões das partes envolvidas podem estar sujeitas a
ambiguidades, entre outros.
O cliente/usuário, na grande maioria das vezes, começa a solicitação com a
expressão: “Eu só queria um sisteminha... coisa simples... basta um
cadastro...”. No entanto, quando paramos para analisar a demanda do usuário,
descobrimos que não é bem assim. Naturalmente, surgem novas demandas,
necessidades antes ignoradas são incorporadas, informações tornam-se
essenciais e passam a ser requeridas e a tendência normal do sistema é
crescer. Não é incomum você encontrar no mercado um sistema que passou
pela fase de modelagem de negócios com um determinado tamanho e dobrou,
ou até triplicou esse tamanho, quando começou a etapa de levantamento de
requisitos e/ou de construção.
Além disso, o cliente/usuário, muitas vezes, não passa a informação de
maneira correta, ou passa de maneira incompleta. Isso, na grande maioria das
vezes, não é por mal ou de propósito, simplesmente acontece, seja por não ter
uma visão do todo, ou por ter uma compreensão equivocada do domínio do
problema, ou ainda por não saber passar a informação adiante. É comum, por
exemplo, o cliente dizer uma coisa e seu interlocutor entender outra.
Porém, o contrário também pode ser verdadeiro. Muitas vezes, o usuário diz o
correto, de maneira bastante clara, mas falta o entendimento completo do
domínio do problema por parte do analista de requisitos; assim, ele entende
algo de maneira equivocada daquela que foi expressa pelo cliente/usuário.
06/11/2024, 11:25 AM
Página 6 de 25
Mobile User
As ambiguidades acontecem porque, geralmente, consultam-se várias pessoas
com visões diferentes sobre o mesmo problema. São diferentes
conhecimentos, entendimentos diversos sobre o domínio do problema,
divergências sobre o assunto a ser tratado, pretensões antagônicas dentro da
corporação e vários outros motivos.
Sommerville e Kotonya (1998) mostram quatro dimensões do processo de
levantamento de requisitos: domínio da aplicação, problema a ser resolvido,
necessidades e restrições dos stakeholders, e contexto do negócio.
Figura 1 – As Quatro Dimensões do Levantamento de Requisitos.
Fonte: Adaptado de Sommerville e Kotonya (1998, p.55)
A figura 1 representa as dimensõesdo processo de levantamento de
requisitos. Leia com atenção as explicações sobre cada uma dessas
dimensões:
06/11/2024, 11:25 AM
Página 7 de 25
Mobile User
Entendimento do domínio da aplicação –  Consiste em ter um
conhecimento geral da área onde o sistema será aplicado. Por exemplo,
para um sistema acadêmico universitário, você terá que entender como é
o funcionamento de uma universidade.
Problema a ser resolvido –  Os detalhes específicos dos problemas do
contexto em que o sistema será instalado devem ser entendidos. Durante
o entendimento do problema, você se especializa e amplia o
conhecimento do domínio geral da aplicação. Em um sistema acadêmico,
você deve saber como é o processo de matrícula, como será a escolha
das disciplinas pelos alunos, entre muitos outros conhecimentos.
Entendimento do negócio –  Os sistemas, geralmente, existem para
apoiar algum negócio. Você deverá saber como o sistema afetará o
negócio da organização, como funcionará a interação com as diversas
áreas do negócio, e como ele ajudará a atingir os objetivos do negócio.
Necessidades e restrições dos stakeholders – Stakholders são aquelas
pessoas que são afetadas, de alguma maneira, pelo sistema. Podem ser
usuários finais, gerentes de departamento da empresa na qual o sistema
será instalado, gerentes de projeto, projetistas, desenvolvedores, clientes,
patrocinador do projeto etc. Você deve entender, em detalhes, suas
necessidades, como o sistema apoia seu negócio. Você deve entender os
processos de trabalho que o sistema automatizará e os papéis existentes
no sistema nesses processos de trabalho.
Continuando com Sommerville e Kotonya (1998), vemos que um bom processo
de levantamento de requisitos deve incluir quatro atividades críticas, conforme
ilustrado na figura 2.
a) Definição de Objetivos
Neste estágio, devem ser estabelecidos os objetivos globais da organização,
metas genéricas do negócio, descrição do problema a ser resolvido, por que o
sistema pode ser necessário, restrições do sistema como orçamento,
cronograma e restrições de interoperabilidade.
b) Aquisição de Conhecimento Organizacional
Este é um estágio muito importante, em que os analistas de requisitos
recolhem e entendem informações básicas essenciais sobre o sistema. Essas
informações podem ser sobre onde o sistema será instalado, sobre o domínio
06/11/2024, 11:25 AM
Página 8 de 25
Mobile User
da aplicação, ou mesmo sobre algum sistema que porventura exista, e que
será substituído pelo que está sendo especificado.
c) Organização do Conhecimento
O conhecimento adquirido nas etapas anteriores deve ser reunido e
organizado. Deve haver a identificação dos envolvidos, seus papéis na
organização, priorização de objetivos e o descarte do conhecimento que não
contribuirá diretamente para os requisitos do sistema.
d) Coleta dos requisitos dos stakeholders
Este estágio é o que muitas pessoas acreditam ser o levantamento de
requisitos propriamente dito. Ele envolve a consulta aos envolvidos, para
descobrir seus requisitos, a derivação dos requisitos oriunda do domínio da
aplicação e a organização que está adquirindo o sistema.
Observe a figura 2, que apresenta um processo genérico de levantamento de
requisitos.
Figura 2 – Processo Genérico de Levantamento de Requisitos.
Fonte: Sommerville e Kotonya (1998, p.59)
Na figura 2, você pode observar que existem quatro caixas, com algumas
atividades que devem ser realizadas, comentadas a seguir:
Estabelecimento dos objetivos do levantamento de requisitos, em que
existe a necessidade de entendimento dos objetivos, dos problemas que
devem ser solucionados e das restrições do sistema.
Compreender a estrutura, em que é necessário verificar a estrutura da
organização, dos domínios das aplicações e quais são os sistemas
06/11/2024, 11:25 AM
Página 9 de 25
Mobile User
existentes nela.
Organização do conhecimento, identificando os stakeholders, priorizando
as metas e filtrando os domínios existentes em termos de
conhecimentos.
Coleta de requisitos, na qual são ouvidos os  stakeholders  identificados
anteriormente, entendendo o domínio de todos os requisitos coletados e
organizando-os.
Muitas vezes, um analista de requisitos se depara com uma situação parecida
com a apresentada na charge. Para coletar os requisitos do software, muitas
vezes, o próprio cliente não sabe exatamente o que quer. Em situações como
essa, o analista de requisitos deve utilizar todos os seus conhecimentos e
técnicas para entender exatamente o que precisa ser feito para atender bem o
cliente.
Técnicas de Levantamento de Requisitos
Para Refletir 
Faça uma reflexão sobre a charge apresentada na figura 3:
Figura 3 – Entendimento dos Requisitos.
Fonte: https://goo.gl/LvNhhA 
06/11/2024, 11:25 AM
Página 10 de 25
Mobile User
Podemos encontrar várias técnicas de levantamento de requisitos. A literatura
está cheia delas. Pressman (2006) cita algumas, que serão abordadas nos
tópicos a seguir.
Entrevista
Esta é uma das técnicas mais utilizadas. Pressman (2006) faz analogia com o
primeiro encontro de adolescentes, em que ninguém sabe o que dizer, o que
fazer, o que perguntar, com medo de ser mal compreendido.
Gause e Weinberg   (apud PRESSMAN, 2006) aconselham a formulação de
questões livres de contexto. O objetivo dos primeiros encontros é possuir um
entendimento básico do problema, um conhecimento genérico sobre a
organização, sobre o domínio do problema e sobre os stakeholders envolvidos.
As primeiras perguntas devem ter foco no cliente, nos objetivos globais da
organização, e nos benefícios que o sistema trará para a organização. Seguem
alguns exemplos de perguntas propostas por Pressman:
Quem é o patrocinador do projeto?
Quais serão os usuários do sistema? [não literal]
Quais serão os benefícios de ordem econômica, fornecidos pelo sistema
para a organização?
Há outra fonte para a solução que você necessita?
Existe um sistema, mesmo que não informatizado, que atende ao
processo de negócio?
Caso o sistema seja implantado, quais serão os benefícios para a
organização?
Haverá redução nos custos dos processos?
Questões desse tipo são capazes de identificar os envolvidos no projeto e,
consequentemente, os benefícios que serão alcançados com a construção do
sistema em questão.
Pressman (2006) também propõe outras questões importantes, que permitem
ao analista de requisitos compreender melhor o domínio do problema e
ambientar-se com os assuntos da organização, obrigando o cliente a verbalizar
seus pensamentos e, principalmente, dizer como ele imagina o funcionamento
da solução:
Como você caracterizaria boas saídas as quais seriam geradas por uma
06/11/2024, 11:25 AM
Página 11 de 25
Mobile User
solução bem-sucedida?
Quais os problemas que essa solução enfrentaria?
Você pode mostrar (ou descrever) o ambiente no qual a solução será
utilizada?
Tópicos especiais de desempenho ou restrições afetarão o modo pelo
qual a solução é abordada?
Gause e Weinberg (apud PRESSMAN, 2006) propõem a elaboração de uma
lista abreviada de meta-questões, capazes de conceder efetividade à reunião:
Você realmente está apto a responder essas questões?
Em relação a este assunto, você oficialmente responde pela empresa?
As questões levantadas são relevantes para o seu problema?
Você está respondendo a muitas questões?
Existe outra pessoa que pode fornecer outra informação?
Há alguma outra questão que deixei de perguntar e que gostaria de
comentar?
A técnica de entrevista ajuda a estabelecer um bom relacionamento entre a
equipe de projeto e os clientes/usuários. Ela possibilita a definição de um
escopo, completa as informações para solicitação do produto, mas, segundo
Pressman, deve ser usada apenas no início, pois depois passa a não ter a
mesma eficácia. Portanto, essa solução sozinha passa a não ser mais
suficiente.
Segundo Sommerville e Kotonya (1998), há dois tipos de entrevista:
1. Entrevista fechada, em que os clientes/usuários respondem um conjunto
fechado de perguntas.
2. Entrevista aberta, em que não existe uma agenda pré-definida. Começacom um pequeno número de questões pré-definidas, mas depois as
perguntas e respostas são abertas e há uma discussão entre analistas e
clientes, em que os usuários dizem o que eles querem do sistema.
Existem mais dois tópicos importantes que devem ser levados em
consideração ao se fazer uma entrevista:
O analista de requisitos deve possuir mente aberta e estar disposto a
ouvir o cliente/usuário, pois, caso não haja disposição por parte do
analista, fica difícil encontrar um ponto a ser explorado, deixando a
06/11/2024, 11:25 AM
Página 12 de 25
Mobile User
entrevista muito vaga e pouco aprofundada.
Os clientes/usuários devem ser o ponto de partida para a discussão.
Pode ser uma pergunta, uma proposta de requisitos, ou um sistema já
existente. Simplesmente dizer “me diga o que você quer” não trará
informações úteis. Em geral, as pessoas acham mais fácil falar quando
há um contexto bem definido do que falar em termos gerais, sem um
direcionamento.
FAST
Em muitos casos, o relacionamento entre as equipes começa a ficar
desgastado. Muitas vezes, há uma guerra não declarada entre a equipe de
projeto e os clientes/usuários. Um festival de documentos para serem
assinados, gerentes de projeto tentando fazer homologações “à força”, clientes
afirmando que pediram determinada funcionalidade e não foram atendidos,
usuários reclamando de um determinado comportamento que não funciona da
maneira esperada por ele, enfim, vários mal-entendidos entre as equipes e
também problemas de relacionamento.
A solução proposta por Pressman (2006) para o problema relatado acima é o
FAST, do Inglês: Facilitated Application Specification Techniques. Essa técnica
prega a união entre as equipes, tanto a de projeto quanto a de
clientes/usuários, com o objetivo de identificar os problemas e encontrar
soluções conjuntas. Também prega a negociação de diferentes abordagens,
para que se estabeleça um consenso e a especificação de um conjunto
preliminar de requisitos, para que assim o projeto possa andar de maneira
eficiente.
Existem duas implementações bastante difundidas do FAST, o projeto conjunto
de aplicações – JAD,  Joint Application Design  – da IBM, e o METHOD,
da Performance Resources.
Leia com atenção as diretrizes básicas para uma reunião FAST:
Reunião em lugar neutro, com analistas e clientes.
Estabelecimento de regras para preparação e participação.
A proposição de uma agenda que seja formal, capaz de cobrir os pontos
importantes e, ao mesmo tempo, informais, para encorajar o fluxo de
ideias.
06/11/2024, 11:25 AM
Página 13 de 25
Mobile User
A presença de um facilitador, podendo ser um cliente, desenvolvedor ou
uma pessoa de fora, que controla a reunião.
A utilização de um mecanismo de definição, que podem ser folhas de
rascunho, flipchart, papel autoadesivo, quadro de avisos eletrônico, salas
de conversa ou mesmo um fórum virtual.
Estabelecer como meta a identificação do problema, propor soluções,
negociar abordagens diferentes, especificar um conjunto preliminar de
requisitos da solução.
Nos dias anteriores à reunião, algumas listas devem ser solicitadas aos
participantes, tais como:
Lista de objetos que cercam o ambiente do sistema, produzidos pelo
sistema, usados pelo sistema, que permitem desempenhar suas funções.
Listas de serviços, processos ou funções, que manipulam ou interagem
com os objetos.
Lista de restrições, como, por exemplo, custo, tamanho, regras de
negócio e critérios de desempenho como velocidade e precisão.
Cabe destacar que as listas não podem ser exaustivas, mas devem refletir a
percepção de cada um sobre o contexto do sistema.
QFD (Quality Function Deployment)
Desdobramento da função de qualidade, ou  Quality Function Deployment  –
QFD (Pressman, 2006), é uma técnica japonesa de gestão da qualidade, que
tem por finalidade capturar as necessidades do cliente, para que sejam
traduzidas em requisitos técnicos do software. A técnica se concentra em
maximizar a satisfação do cliente a partir do processo de engenharia de
software. Para isso, a QFD dá ênfase ao entendimento daquilo que representa
valor para o cliente; posteriormente, esses valores são desdobrados por meio
do processo de engenharia. A técnica classifica os requisitos em três tipos:
a. Normais: são aqueles que deixam os clientes satisfeitos quando as
metas são atingidas devido à utilização desses requisitos.
b. Esperados: são os requisitos implícitos. Esses requisitos são tão
fundamentais, que os clientes nem se referem a eles de maneira explícita,
mas geram uma grande insatisfação no cliente, caso ocorra a falta de
algum deles. Como exemplo, podemos citar a facilidade na operação e na
06/11/2024, 11:25 AM
Página 14 de 25
Mobile User
instalação, confiabilidade do sistema, atender às necessidades de
maneira correta etc.
c. Excitantes: são os requisitos que superam as expectativas, que
surpreendem positivamente os clientes. Assim, costumam gerar um
resultado bastante satisfatório quando estão presentes. Exemplo de
requisito excitante pode ser um relatório sabidamente útil e prático, mas
que não havia sido solicitado.
A técnica consiste em realizar reuniões com os clientes, para que haja o
desdobramento de funções cujo enfoque é o de determinar o valor de cada
função a ser utilizada no sistema. É necessário também executar o
desdobramento da informação, cuja essência é identificar corretamente
objetos de dados e eventos que farão parte do sistema. Para finalizar,
realizamos o desdobramento de tarefas, para que o comportamento do
sistema seja examinado dentro do contexto do seu ambiente. A análise de
valor determina a prioridade de forma relativa dos requisitos determinados
durante cada um dos três desdobramentos.
A técnica QFD utiliza entrevistas com os usuários, observação, levantamento e
exames de dados históricos, muitas vezes, relatórios de problemas e dados
sem nenhum tratamento, para o levantamento de requisitos. Esses dados são
colocados em uma espécie de tabela – chamada de tabela da voz do cliente –
a qual é revisada com o cliente. Assim, é utilizado um grande número de
diagramas, matrizes e métodos de avaliação para levantar os requisitos
esperados e então tentar derivar os requisitos importantes.
Cenários
Os usuários de sistema gostam de relatar sua rotina funcional. Gostam mais
de contar sobre seu dia a dia no trabalho do que de pensar e/ou tentar
imaginar como seria sua vida, caso já estivessem usufruindo do sistema.
Assim, torna-se bem útil a utilização dos cenários, para que haja uma grande e
clara descoberta de requisitos.
Essa técnica consiste no usuário simular as suas interações com o sistema,
dizer quais são as informações relevantes que ele utilizará no sistema para
realizar as suas obrigações, além das informações de saída esperadas. É a
descrição das tarefas a serem realizadas por um usuário que executa um
determinado papel.
06/11/2024, 11:25 AM
Página 15 de 25
Mobile User
A descoberta de cenários ajuda os engenheiros de software a entender melhor
o contexto da aplicação, e com um número determinado de cenários é possível
fazer um grande número de alternativas de solução para o problema.
Os cenários são as partes-chave da utilização de métodos de análise
orientados a objetos. É por meio deles que serão descritos os casos de uso,
objeto de nosso estudo na aula reservada à Análise e Requisitos, etapa
seguinte que iremos tratar da Engenharia de Requisitos.
Os cenários podem ser escritos de diversas formas, mas, segundo
Sommerville e Kotonya (1998), devem incluir algumas informações básicas,
tais como:
descrição do estado do sistema antes do início do cenário;
fluxo normal dos eventos no cenário;
exceções ao fluxo normal dos eventos;
informações sobre outras atividades que podem acontecer de forma
simultânea;
descrição do estado do sistema depois da execução completa do
cenário.
A seguir, é apresentado o exemplo de um cenário, em que um gerente de banco
utiliza o sistema para a abertura de conta para um determinado cliente. Este
cenário contém apenas o “caminho feliz”, no qual o fluxo acontecesem erros:
O gerente seleciona a opção de abertura de conta.
O sistema disponibiliza a tela de cadastro de conta.
O gerente entra com as informações necessárias ao cadastro.
O sistema valida as informações.
O gerente solicita o cartão magnético para o cliente.
O gerente solicita o talão de cheques para o cliente.
O cenário é encerrado.
Casos de Uso
Os casos de uso se assemelham mais a uma forma de estruturar do que
propriamente levantar requisitos, embora sirvam para encontrar mais
requisitos quando são utilizados na validação das informações junto ao
usuário.
06/11/2024, 11:25 AM
Página 16 de 25
Mobile User
Os casos de uso são então uma junção de cenários, classificados em fluxo
básico e alternativo, atores, restrições, pré-condições, pós-condições,
definições e regras de negócio. Conheça cada um deles.
Fluxo básico – Consiste no caminho feliz. O cenário com o fluxo básico é
aquele que deve ou deveria acontecer na grande maioria das vezes. É o
atendimento pelo sistema à funcionalidade levantada pelo analista de
requisitos junto ao cliente/usuário. É justamente o que aquela tarefa deve
fazer, a sua finalidade principal. É a sequência básica dos
acontecimentos, a narrativa dos passos a serem seguidos no decorrer da
interação do ator com o sistema. São os passos a serem seguidos.
Fluxo alternativo  – Acontece quando há uma exceção no fluxo natural
das coisas. Por exemplo, alguma informação que deveria constar e não
está presente. Para resolver esse problema, o sistema pode pedir a
informação ausente, registrar um erro, redirecionar a execução do
sistema, entre outras opções.
Atores  – Atores são essenciais em um caso de uso. São aqueles que
interagem com a funcionalidade. Pode ser uma pessoa, que representa
um papel, ou um sistema externo, ou seja, uma entidade de fora do
sistema que é responsável por interagir com o sistema. Um papel pode
ser encarado como um conjunto de características comuns a um ator que
se relaciona com o sistema. Por exemplo, uma pessoa com papel de
funcionário pode executar tarefas reservadas a um funcionário qualquer,
como pesquisar dados do cliente, enquanto que apenas o funcionário
com papel de gerente pode conceder mais crédito no cheque especial.
Restrições – As restrições significam aquelas circunstâncias que devem
ser obedecidas pelo caso de uso. É algo que, enquanto aquela situação
não for atendida, restringe a conclusão do caso de uso. Por exemplo,
quando o usuário solicitar um cadastro qualquer, alguns campos devem
ser de preenchimento obrigatório. Enquanto esses campos não
possuírem valores, não será possível concluir a operação.
Pré e pós-condições – Pré-condição é quando um caso de uso só pode
ser iniciado se determinada situação tiver sido alcançada. Por exemplo, o
usuário só poderá interagir com determinada funcionalidade se ele
estiver logado no sistema. Pós-condição é a situação em que deve se
encontrar o sistema depois da realização daquele caso de uso.
Pré e pós-condições – Pré-condição é quando um caso de uso só pode
ser iniciado se determinada situação tiver sido alcançada. Por exemplo, o
06/11/2024, 11:25 AM
Página 17 de 25
Mobile User
usuário só poderá interagir com determinada funcionalidade se ele
estiver logado no sistema. Pós-condição é a situação em que deve se
encontrar o sistema depois da realização daquele caso de uso. Um
exemplo de pós-condição seria de um caso de uso Incluir Cliente. Nesse
sentido, uma pós-condição é que no final da execução do caso de uso
todas as informações dos clientes tenham sido validadas e o cliente
gravado no banco de dados.
Definições  – Podemos dizer que as definições fazem parte da
especificação do caso de uso. É comum que uma organização tenha uma
cultura e vocabulário próprios; mesmo assim, um termo pode ter dois ou
mais significados, a depender do departamento. Por isso, devemos
utilizar definições para que um termo utilizado no sistema seja
suficientemente claro para todos os envolvidos.
Regras de Negócio – Todo o sistema deve acontecer estando restrito a
determinadas regras de negócio. São as especificações e definições que
determinam o fluxo dos acontecimentos. As regras de negócio podem
estabelecer novas definições, condições, restrições, entre outros. Muitas
vezes, as regras de negócio estão em um documento diferente da
especificação do caso de uso, isso porque muitas regras de negócio não
são exclusivas do caso de uso. Elas pertencem a todo o sistema, por isso
são colocadas em um lugar único e o caso de uso apenas referencia essa
regra de negócio.
Você estudará mais sobre casos de uso e cenários na aula Modelagem e
Análise de Requisitos, em que serão apresentados novos termos,
nomenclatura, notação gráfica, enfim, tudo aquilo necessário para você poder
fazer uma boa modelagem ao analisar os requisitos. 
Para Refletir 
Analise o mapa mental apresentado na figura 4:
Figura 4 – Técnicas de Levantamento de Requisitos.
06/11/2024, 11:25 AM
Página 18 de 25
Mobile User
Nesta aula, você compreendeu que o processo de engenharia de
requisitos visa garantir que o sistema gerado por esses requisitos
atenda às necessidades e satisfaça as expectativas dos clientes. A
Gestão de Requisito é um conjunto de atividades que ajuda a
equipe de projeto a identificar, controlar e rastrear requisitos e
modificações de requisitos em qualquer época, à medida que o
Fonte: https://goo.gl/tV1Ggp 
Você deve ter observado que o mapa mental apresenta informações
sobre o que deve ser feito em termos de Levantamento de Requisitos e a
Técnica de Levantamento de Requisitos a ser utilizada. Essa é uma
ferramenta muito útil! Pense que você pode utilizar um software para
essa finalidade, já imaginando como será o levantamento e qual é a
melhor técnica a ser considerada. Imagine que você levantará requisitos
em uma empresa que contará com a presença de mais ou menos 10
pessoas, de departamentos e interesses diferentes. Você pode baixar o
aplicativo  FreeMind , que é um software  free,  e pode gerar como
exercício um mapa mental da situação, para facilitar o registro de ideias.
 
06/11/2024, 11:25 AM
Página 19 de 25
projeto prossegue. Também foi abordada a Elicitação de
Requisitos, entendendo os detalhes do sistema de que o cliente
necessita e as técnicas que podem ser utilizadas para obtenção e
consolidação dos requisitos iniciais do sistema.
Na próxima aula, será abordada a Análise dos Requisitos de
Software, dando continuidade ao tratamento dos requisitos
levantados na Elicitação de Software.
Bons estudos!
06/11/2024, 11:25 AM
Página 20 de 25
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de
Brasília
Na Prática 
"Prezado(a) estudante,
Esta seção é composta por atividades que objetivam
consolidar a sua aprendizagem quanto aos conteúdos
estudados e discutidos. Caso alguma dessas
atividades seja avaliativa, seu (sua) professor (a)
indicará no Plano de Ensino e lhe orientará quanto aos
critérios e formas de apresentação e de envio."
Bom Trabalho!
Algumas das atividades propostas nesta aula são interdependentes
e complementares, com o intuito de possibilitar uma visão geral das
diversas etapas que compõem a Engenharia de Requisitos, indo
desde as informações iniciais coletadas junto ao cliente, até o
momento em que a documentação necessária ao desenvolvimento
do sistema esteja pronta para a próxima etapa do Processo de
Desenvolvimento do ciclo de vida de desenvolvimento de software, a
Análise e Projeto de Software.
Segue a relação das atividades que são interdependentes e
complementares:
Unidade I
Aula 1 – Atividade 3
06/11/2024, 11:25 AM
Página 21 de 25
Aula 1 – Atividade 3
Aula 3 – Atividade 2
Aula 3 – Atividade 3
Aula 3 – Atividade 4
Aula 4 – Atividade 3
Aula 4 – Atividade 4
Começamos a entender o que representa a Engenharia de Requisitos e qual é
a sua real utilidade no desenvolvimento de sistemas informatizados. Foram
apresentados alguns problemas na Elicitação de Requisitos, que é a primeira
etapa da Engenharia de Requisitos. Elaboreuma tabela com quatro colunas,
a saber:
Coluna 1: Problemas com Elicitação de Requisitos,
Coluna 2: Descrição do problema,
Coluna 3: Exemplo de Problema e
Coluna 4: Impacto no desenvolvimento, classificando esse problema
como CRÍTICO, NORMAL ou IMPARCIAL. Quando um problema for
CRÍTICO, indica que o impacto é muito grande em todo o projeto.
Quando é NORMAL, indica que o impacto no projeto é moderado e
quando for IMPARCIAL, indica que não há impacto no projeto, não
afetando o custo, nem o cronograma de desenvolvimento.
Sommerville e Kotonya  (1998) mostram quatro dimensões do processo de
levantamento de requisitos: domínio da aplicação, problema a ser resolvido,
necessidades e restrições dos  stakeholders  e contexto do negócio. Com
base no que você aprendeu, preencha a tabela a seguir, com a descrição das
dimensões e exemplos práticos.
Dimensão  Descrição  Exemplo Prático 
Atividade 1 - Problemas com Elicitação de Requisitos 

Atividade 2 - Dimensões do Levantamento de Requisitos 

06/11/2024, 11:25 AM
Página 22 de 25
     
     
     
     
     
Você estudou a Engenharia de Requisitos e as suas cinco etapas. Foi
apresentada a Elicitação de Requisitos e eventuais problemas que ocorrem
com a identificação dos requisitos que compõem um sistema
computadorizado.
Para solucionar alguns problemas, existem a Técnicas de Elicitação de
Requisitos. Foram apresentadas apenas algumas técnicas, mas existem
outras.
Faça uma pesquisa, procurando conhecer as Técnicas de Elicitação de
Requisitos Brainstorm e JAD – Joint Application Development.
Após levantar as informações por meio da pesquisa, organize uma tabela
com o nome da técnica, sua descrição e suas principais características.
Atividade 3 - Técnicas de Elicitação de Requisitos 

06/11/2024, 11:25 AM
Página 23 de 25
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de
Brasília
Saiba Mais 
Para ampliar seu conhecimento a respeito desse assunto, veja abaixo a(s)
sugestão(ões) do professor:
Assista ao vídeo “Problemas Processo Desenvolvimento de
Software ”, da ISD Brasil, para obter mais detalhes sobre o
processo.
Leia o artigo “ENGENHARIA DE REQUISITOS: uma análise das
técnicas de levantamento de requisitos ”, de Samuel Fabiano
Barbosa Silva.
06/11/2024, 11:25 AM
Página 24 de 25
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de
Brasília
Referências 
DAVIS, A. M. Software Requirements: objects, functions and states.
Englewood Cliffs, New Jersey: Prentice Hall. 1993.
KOTONYA, G.; SOMMERVILLE, I.  Requirements
Engineering:processes and techniques (worldwide series in
computer science). Wiley, 1998.
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática.
2. ed. São Paulo: Pearson Education do Brasil, 2007.
PRESSMAN, Roger S. PENTEADO, Rosângela Delloso
(Trad.).  Engenharia de software. 6. ed. Rio de Janeiro: McGrawHill,
2006.
PRESSMAN, Roger S.  Engenharia de software:  Uma abordagem
Profissional. 7. ed. São Paulo: McGraw-Hill, 2011.
SOMMERVILLE, Ian.  Engenharia de software.  9. ed. São Paulo:
Pearson Addison Wesley, 2011.
06/11/2024, 11:25 AM
Página 25 de 25