Importância dos Requisitos de Software

Prévia do material em texto

www.professormarco.com.br 
Profª CLAUDIA ABREU PAES 
Brooks Jr., em um antigo artigo publicado pela IEEE Computer, entitulado como No Silver Bullet: Essence and 
Accidents in Software Engineering (IEEE Computer, abril 1987), define: “A parte mais árdua na construção de um 
sistema de software é decidir o que construir. Nenhuma outra parte do trabalho compromete mais o sistema se for 
feito de forma imprópria. Nenhuma outra parte é mais difícil de corrigir a posteriori.” 
Para os mais tecnicistas (e até muitos analistas), certamente existe uma grande dificuldade em compreender a 
veracidade desta mensagem. É comum nos preocupamos bastante é com a linguagem de programação, base de 
dados ou quaisquer outros recursos no tocante a base tecnológica. Contudo, cometemos uma grave e custosa 
infração: definir o que realmente o sistema deve fazer; quais são as entradas disponíveis e as saídas esperadas para 
o sistema. 
Nesta disciplina, teremos a oportunidade de compreender a importância na definição dos requisitos de software, 
identificando como ela contribui para o desenvolvimento de um sistema de qualidade, ou seja, que os objetivos 
estão alinhados com a necessidade, evitando surpresas ou pouco entendimento sobre o que realmente se deseja. O 
término do estudo dessa disciplina propiciará uma visão sobre os benefícios de se conhecer bem os requisitos 
desejados, e como estes irão proporcionar um sucesso no que diz respeito a assertividade do produto de 
desenvolvimento de software, ou seja, em um sistema que realmente satisfação as necessidades dos usuários. 
Ao final dessa disciplina você será capaz de: 
•Apresentar os conceitos fundamentais e importância dos requisitos no processo de desenvolvimento de software. 
•Compreender o que vem a ser qualidade, e como podemos desenvolver um sistema com qualidade. 
•Apresentar as atividades envolvidas para elicitação e validação dos requisitos, evidenciando a importância de cada 
uma delas e as diferentes técnicas utilizadas, bem como o relacionamento entre elas. 
•Ter uma visão sobre a engenharia de requisitos de software. 
•Desenvolver senso crítico do aluno mostrando a necessidade do gerenciamento de requisitos para apoiar cada 
atividade do ciclo de vida de software. 
1 - Identificar o conceito de requisitos. 
2 - O que é qualidade de software. 
3 - Relacionar a importância dos requisitos para o desenvolvimento de software com qualidade. 
Certamente que você deve está familiarizado sobre o conceito da palavra “sistema”, aonde este representa um tipo 
de rotina; ou seja, quando estamos construindo um software, na realidade estamos transferindo uma seqüenciada 
operação definida e seqüencial, de acordo com o seu funcionamento. Por exemplo, uma grande montadora de 
veículos encomenda um sistema para fazer com que “braços” mecânicos possam executar a tarefa de alocar as 
peças para que o carro seja construído. Portanto, o software opera sobre o hardware para que o computador possa 
desenvolver a determinada ação. 
Portanto, antes de se pensar em questões tecnológicas(Ambiente de desenvolvimento, linguagens de programação, 
banco de dados a ser utilizado), é preciso ter a concepção correta do que se está sendo solicitado. Se não 
conseguirmos compreender corretamente o que precisamos sistematizar, temos grande risco de não entregarmos o 
que se desejava no referido software. 
 
Levantamento de Requisito 
O processo de levantamento de requisito está vinculado para garantir qualidade no produto que vamos entregar. 
Mas você sabe definir o que é qualidade? Segundo o Aurélio, atribui-se o termo qualidade a algo e/ou alguém que 
possui uma superioridade, excelência. 
Para qualquer empresa, ter qualidade nos seus processos para seu é ter uma estratégia competitiva, principalmente 
para aquela que desenvolve software. A muito tempo já deixamos de ter a visão que qualidade é algo voltado a 
classes sociais mais ricas. É preciso definir ou escolher um determinado padrão de qualidade a ser seguido nas 
atividades para o desenvolvimento do sistema, a fim de poder acompanhar em diferentes estágios se está tudo em 
conformidade com as normas estabelecidas, e por fim garantir a qualidade do software. 
É perceptível atualmente um significativo movimento em busca da qualidade. Adventos de várias transformações no 
mundo, as organizações precisam produzir produtos e serviços de qualidade, não mais como uma estratégia de 
diferenciação de mercado, mas como uma condição de subsistência. 
Mas qual o caminho para um produto de qualidade? Como atingir a qualidade do produto de software? Variáveis 
como: qualidade de software, garantia da qualidade e custo da qualidade também são assuntos que exige análise. 
Lembre-se que, qualquer empresa precisa ser rentável, e a qualidade tem seus custos. 
Qualidade de Software 
Para facilitar nossa compreensão na definição da palavra qualidade, Pressman (2006) atribuiu o alcance da qualidade 
de software como uma consequência formal no desenvolvimento; para tanto, estima-se que seja colocada em 
prática e não somente uma idéia ou desejo que uma organização venha a ter. Ele cita as seguintes colocações sobre 
qualidade de software: 
Definir explicitamente o termo qualidade de software, quando o mesmo é dito. 
Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software 
exiba alta qualidade. 
Realizar atividades de segurança da qualidade em cada projeto de software. 
Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como consequência, a 
qualidade no produto final. 
Sendo assim, qualidade se consegue nos fragmentos do processo, não apenas no começo do projeto ou no seu final 
realizando testes, mas sim dentro do contexto visa abranger toda a engenharia de software, contando como a 
colaboração de todos os envolvidos no projeto. 
 
Portanto, isso consiste em realizar a qualidade tanto do processo quanto o produto. 
No processo, podemos quantificar a sua qualidade através de métricas para qualidade e no produto com as técnicas 
de verificação e validação. Essas atividades podem ser, por exemplo, avaliações como as citadas pela ISO 9000, 
auditorias, inspeções formais, testes, revisões. Ainda no processo podemos usar os métodos de garantia da 
qualidade no formato de auditorias e reportes para a alta gerência, além de avaliações constantes do processo e 
análise estatística de controle do processo. 
No produto os métodos de garantia da qualidade são revisões, inspeção formal e testes, além de revisão dos 
resultados do teste realizada por profissionais altamente capacitados, auditorias do produto e testes realizados pelo 
cliente. 
Controle da Qualidade e Garantia da Qualidade 
Não podemos confundir os conceitos e a aplicação dos termos Controle da Qualidade e Garantia da Qualidade. Para 
que possam utilizá-los adequadamente, acompanhe na tabela abaixo diferenças entre estas duas atividades: 
Garantia da qualidade: 
 
Controle da Qualidade: 
 
Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de software 
é orientado a produto e está dentro do domínio do controle da qualidade. 
Gerenciamento da Qualidade 
De acordo com o PMBOK do PMI, na versão 2004, os processos de gerenciamento da qualidade do projeto detêm 
todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de 
qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização. Eles desenvolvem o 
sistema de gerenciamento da qualidade através da política, dos procedimentos e dos processos de planejamento da 
qualidade, garantia da qualidade e controle da qualidade, com atividades de melhoria contínua dos processos 
conduzidas do início ao fim, conforme adequado. 
Com isso os três principais processos são: 
Planejamento da Qualidade: identificação dos padrões de qualidade relevantespara o projeto e determinação de 
como satisfazê-los. 
Garantia da Qualidade: Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto 
emprega todos os processos necessários para atender aos requisitos. 
Controle da Qualidade: Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de 
acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um 
desempenho insatisfatório. 
Há diversas semelhanças entre os conceitos usados no PMBOK e os conceitos da própria ISSO. Com isso, é possível 
ainda relacionar estes três processos do PMBOK com as definições de qualidade de processo, qualidade de projeto, 
controle da qualidade e garantia da qualidade. 
A norma ISO 9000 estabelece um padrão para a qualidade de software. 
Ela aponta um conjunto de características de trata de um produto, processo ou sistema que está adequado os 
requisitos inicialmente estipulados para estes. “A ISO 9001 é de longe a estrutura de qualidade melhor estabelecida, 
sendo utilizada atualmente por mais de 750 mil organizações em 161 países, e define o padrão não só para sistemas 
de gestão da qualidade, mas para sistemas de gestão em geral.” 
Enfim, alcançar um produto de software de maneira mais assertiva, que consegue o problema de maneira correta e 
que entrega dentro de um tempo e lugar que satisfazem ao cliente, inicia com a identificação dos requisitos. Então 
devemos primeiramente levantamos as pessoas, os processos e recursos que estão envolvidos, e buscar então 
evidenciar suas ações e documentá-las, da maneira mais detalhadamente necessária para que não haja dúvidas do(s) 
respectivo(s) comportamento(s). 
Nesta aula, você: 
 Compreendeu sobre a definição de requisitos de sistemas. 
 Aprendeu sobre os conceitos de qualidade no aspecto do desenvolvimento de software. 
 Analisou que os requisitos representam o foco de deve receber muita importância, caso desejemos atingirmos um 
software com qualidade. 
 1. 
 Qual o objetivo da área de requisitos de sistema? 
 1) Identificar quem vai desenvolver o sistema. 
 2) Informar qual a ISO deve ser utilizada naquele sistema. 
 3) Programa computacional para estabelecer regras para a qualidade. 
 4) Sistema de apoio aos gerentes para aprimoramento de veículos. 
 5) Levantar os dados para a definição correta e completa para o sistema a ser desenvolvido. 
 5 
 2. 
 O que significa a sigla ISO? 
 1) Empresa internacional que desenvolve software. 
 2) Empresa internacional de padronização de processos. 
 3) Empresa internacional de requisitos de software. 
 4) Empresa internacional de validação de requisitos. 
 5) Empresa internacional de banco de dados. 
 2 
 3. 
 Qual a norma da ISO que trata sobre gestão da qualidade? 
 1) 9001 
 2) 9010 
 3) 9100 
 4) 1900 
 5) 0190 
 1 
 
Nesta aula, você irá: 
 
1 - Aprender sobre a classificação dos requisitos de níveis. 
2 - Identificar os níveis em nível de sistema. 
3 - Identificar os níveis em nível de usuário. 
4 - Reconhecer as características de requisitos de sistema e requisitos de usuário. 
 
Conforme estudamos na aula anterior, definir bem requisitos é um passo importante para alcançarmos o 
desenvolvimento de um projeto de determinado software com qualidade. Independente das características que 
defina maior ou menor, a primeira iniciativa será identificar o que se espera do sistema. Notadamente o sistema a 
ser desenvolvido substituirá ou aperfeiçoará algum outro existente ou automatizar um processo que atualmente não 
está sendo realizado por computador. 
Quando falamos em requisitos, estamos identificando algo intrínseco ao sistema, ou seja, alguma característica que 
deverá ser capaz de efetivamente realizar, visando assim atingir os objetivos macros que motivaram o início do 
projeto. Podemos também dizer que requisitos apontam a conduta desejada de um sistema. 
Os requisitos classificados por níveis estão vinculado na linguagem ou ambiente do teor da especificação para 
determinada finalidade, com o intuito de consegui ser entendível, evitando que qualquer anomalia na qualidade da 
informação disposta imponha obstáculos para se alcançar plenamente o resultado esperado. E não adianta apenas 
constar, mas a compreensão do que se preciso tem que ser clara. 
Na figura ao lado (Sommerville, pág. 58), temos um exemplo descrito detalhadamente, que visam atender diferentes 
necessidades de informações. Por exemplo, nele estão visíveis para o programador saber qual(ais) a(s) regra(s) para 
se atingir o objetivo esperado, e o que o usuário deve efetivar no momento de obter o resultado daquele 
processamento. Todos estes devem sempre fornecer a dimensão exata dentro da especificidade do cenário, sendo 
claro e sem ambigüidades, para evitar desencontros e/ou desentendimentos. 
 
Requisitos classificados por níveis 
Para então contemplar todos os envolvidos no processo de levantamento de requisitos, de maneira que 
compreendam o cenário proposto para resolução de determinada necessidade que culminou na tarefa de 
desenvolver um sistema, dividimos os requisitos em dois níveis: 
Sistema e Usuário 
 
 
 
Requisitos de sistema 
No tocante aos requisitos de sistema, estes já são especificados para um grupo de leitores que detém de uma 
experiência, seja no negócio como na área de tecnologia da informação, nas especificidades da empresa. Precisa não 
necessariamente entender de detalhes tecnológicos, mas estima-se que ostente algum tipo de experiência, dotando-
o da capacidade de, por exemplo, identificar os insumos já presentes e aqueles também necessários, mas que não 
estão sendo gerados, para se alcançar uma determinada informação e com base na regra do negócio, aplicada e 
requerida pelo cliente. 
Um exemplo que facilita a compreensão é vinculado a software de jogos eletrônicos. Sempre ao comprar 
(recomenda-se) analisar quais são as características mínimas exigidas para que o jogo possa funcionar em um 
determinado computador. As informações ali dispostas são consideradas, obrigatórias, pois define os componentes 
e configurações para que seja possível usufruir das emoções dos jogos. Portanto, são requisitos do sistema. 
 
Importante destacar que nada impede que os requisitos de sistema e/ou de usuário estejam disponíveis, ou seja, 
possam ser lidos por pessoas sem conhecimento apropriado (salvo por questões de confidencialidade); portanto, o 
documento está sendo disponível a todos, contudo, o grau de a relevância está mais associados àqueles que detém 
vínculo com determinado perfil de informação. 
 
A seguir, veremos sobre mais dois tipos de requisitos, porém estes agora mais voltado para características mais 
internas dos próprios requisitos, que apontam pela funcionalidade do requisito, o que justifica então a presença 
dele, tanto de maneira mais direta (requisito funcional), como indireta (requisitos não funcional). 
Nesta aula, você: 
 Compreendeu sobre a classificação dos requisitos; 
 Aprendeu sobre requisitos de sistema e requisitos de usuário; 
 Analisou a abrangência de cada nível de requisito. 
Na próxima aula, você estudará sobre os assuntos seguintes: 
 Classificação de requisitos por tipos; 
 Requisitos Funcionais; 
 Requisitos Não Funcionais. 
 
1. 
 Quais são os níveis de detalhamento que os requisitos precisam atender? 
 1) Sistema e Produção. 
 2) Usuário e Desenvolvimento. 
 3) Sistema e Usuário. 
 4) Desenvolvimento e Produção. 
 5) Usabilidade e interação. 
 3 
 2. 
 São exemplos de requisitos de usuário: 
 1) O sistema deve gerar um relatório de contas a pagar. 
 2) Quando estoque atingir o mínimo cadastrado, o sistema deve verificar nos estoques das outras lojas, antes de 
autorizar a compra. 
 3) O sistema deve solicitar nome de usuário e senha para o controle de acesso. 
 4) Após o fechamento do caixa, seráimpresso um relatório de movimentação. 
 5) Será criado um módulo de auditoria para a checagem no histórico da movimentação. 
 1 
 3. 
 O requisito de sistema: 
 1) É um manual do usuário. 
 2) É um Documento que descreve a empresa contratada para desenvolver o software. 
 3) É o setor da empresa que desenvolve o sistema. 
 4) Identifica as regras para encontrar e/ou produzir o resultado esperado. 
 5) Especificado apenas para grupo de leitores com pouca experiência. 
 4 
 Nesta aula, você irá: 
 
1 - Identificar o que é um requisito funcional e não-funcional. 
 2 - Quais as características de um requisito funcional. 
 3 - Quais as características de um requisito não-funcional. 
 4 - Compreender as diferenças entre os requisitos funcionais e não-funcionais. 
 
Antes de entrarmos nas características que definem a classificação de requisitos, é importante enfatizar que um 
sistema não é concluído com apenas um tipo de requisito. E que também não existe algum que é mais ou menos 
importante. Recapitulando o que já estudamos, requisitos definem o que o sistema deve fazer; portanto, quando 
eles são evidenciados, entende-se que devem ser contemplados e inseridos no software. 
Sommerville (2011, pág. 60), destaca que os requisitos devem especificar todos os intentos do cliente, e que sejam 
de forma clara – os quais denominam pelo conceito de completude e consistência. Um fato que vamos estudar na 
próxima aula: as pessoas que fazem parte da empresa cliente, nem sempre são precisos em identificar corretamente 
um contexto. 
Classificação dos Requisitos 
Funcionais, Não funcionais e Interface. 
Exemplo Prático 
Relativo ao sistema a ser desenvolvido, pede-se: deve disponibilizar um grid na tela, que permitirá a visualização dos 
dados relativos a nossa conta bancária (saldo disponível para o saque). Essas informações poderão ser acessadas 
apenas com o interesse do cliente. Portanto, o grid somente será ativado (e também pode ser desativado) através 
do clique em um botão. Esse grid não poderá durar mais do que 3 segundos para aparecer ao cliente. 
Separando corretamente os requisitos especificados no exemplo acima, visto que não houve preocupação em de 
distinguir – ou seja, temos uma aglutinação de requisitos, o resultado seria: 
Funcional - Sistema deve possuir um módulo para saque. - No módulo de saque deve ser disponibilizado um grid 
para a visualização do saldo. - O grid pode ser ativado ou desativado, dependendo do interesse do cliente. 
Não Funcional - Software deve possuir características de confiabilidade, pois trabalha com dados sensíveis (saldo de 
conta). - O tempo máximo para visualizar as informações no grid é de 3 segundos. 
Muitas vezes é difícil discernir entre quais requisitos são funcionais e quais não são. Essa prática vem com o tempo e 
com a experiência e, por isso, para quem não trabalha diretamente com análise, é sempre bom exercitar. O processo 
de análise é uma das fases mais complexas do projeto de software. Vamos ainda continuar falando sobre o processo 
de elicitação de requisitos e de análise em geral em próximas ocasiões. 
Requisitos Funcionais 
Os requisitos funcionais são aqueles que estabelecem e descrevem as funcionalidades do sistema desejadas pelos 
clientes, ou seja, retratam “O QUE” se espera que o software faça. Então, por exemplo, uma empresa determinada 
está com interesse em ter um sistema que gerencie o seu cadastro de fornecedor. Ela deseja acabar com um 
cadastro de fornecedor atualmente realizado em fichas. Para tanto, encomendou um sistema que possibilite 
cadastrar e armazenar todos os dados daqueles que lhe fornece produtos e/ou serviços. 
Também foi solicitado que pudesse ser emitido um relatório de todos os fornecedores que não conseguiram 
entregar no prazo estabelecido, citando o motivo e o número do pedido, além de outros relatórios que são 
importantes para os gerentes da empresa. Todos estes são exemplos de requisitos funcionais. Mediante este 
cenário, tudo que envolver funcionalidades ou serviços que se espera do sistema no tratamento para o controle do 
fornecedor será um requisito funcional. Por exemplo: o sistema deve disponibilizar o cadastro dos campos “A”, “B” e 
“C”. 
Requisitos Não Funcionais 
Os requisitos não funcionais envolvem fatores para o sucesso do produto a ser entregue porque atua diretamente 
com a satisfação dos usuários na operação do software. São exemplos de características de requisitos não funcionais 
que devem ser avaliadas: 
Funcionalidade: Está vinculado a finalidade do produto. É preciso entender as características de quem e o que foi 
pedido. 
Usabilidade: Esforço para utilizar o sistema; aprendizagem do produto; acessibilidade, principalmente por público de 
necessidades especiais 
Confiabilidade: Relacionado a freqüência de falhas, e, quando ocorrerem, qual o tempo necessários para a 
recuperação do ambiente, caso ocorra alguma indisponibilidade. 
Eficiência: Característica relacionada ao desempenho do sistema relativo a quantidade da demanda gerada quando 
ele estiver em atividade. 
Manutenibilidade: Esforço necessário para modificar o sistema para possíveis cenários, sejam eles novos ou 
resultado de ajustes para atender alguma nova característica. 
Portabilidade: Capacidade de transferir o produto para outros ambientes. 
São exemplos de requisitos não-funcionais: 
- Software deve ser operável por deficientes visuais. 
- Tempo de resposta do sistema não deve ultrapassar 10 segundos. 
- Software deve ter módulo de backup. 
- A base de dados deve ser acessível apenas para autorizados. 
Tipos de Requisitos Não-Funcionais 
Na abaixo, temos uma abrangente descrição dos tipos de requisitos não funcionais, a qual nos permite ter uma 
noção mais exata sobre as características necessárias para enquadrarmos um item como um requisito não funcional. 
 
 
Métricas para Especificar Requisitos Não Funcionais 
Mediante o cenário muito intangível (mas que precisa obter um métrica), detalhamos na tabela abaixo, as principais 
métricas para especificar requisitos não funcionais. Acompanhe então cada medida que pode ser utilizada em 
relação a uma determinada propriedade do requisito.
 
Resumindo então a diferença entre os requisitos funcionais e não funcionais, podemos dizer que o primeiro tem 
características tangíveis (é mais fácil observar), enquanto o outro trata de questões intangíveis, e que podem 
obter diversas maneiras de ser avaliado, ou seja, vai depender diretamente do contexto computacional e do tipo 
do sistema a ser produzido. 
Nesta aula, você: 
 Aprendeu mais sobre a classificação de requisitos; 
 Compreendeu o conceito de requisitos funcionais e não funcionais; 
 Analisou as características que definem se um determinado requisito é funcional ou não funcional. 
Na próxima aula, você estudará sobre os assuntos seguintes: 
 Definição de skateholders; 
 Levantamento de requisitos; 
 Técnicas para levantamento de requisitos. 
 
1. 
 Quais são os dois tipos de requisitos? 
 1) Funcionais e Sistema. 
 2) Usuário e não funcionais. 
 3) Funcionais e não funcionais. 
 4) Sistema e Usuário. 
 5) Usuário e funcionais. 
 3 
 2. 
 Selecione a opção que exemplifica um requisito funcional: 
 1) Sistema deve dispor de recursos de confiabilidade. 
 2) Sistema deve gerar um relatório de vendas. 
 3) Sistema deve gastar não mais que 1 segundo para registrar a venda. 
 4) Sistema deve ter um ambiente de fácil uso. 
 2 
 3. 
 Selecione a opção que exemplifica um requisito não funcional: 
 1) Sistema deve emitir relatório de produtos que mais são vendidos. 
 2) Sistema deve possuir um acesso controlado por uma senha. 
 3) Sistema somente deve permitir alteração de preço com usuário do tipo “Gerente”. 
 4) Sistema deve permitir processo de cópia de segurança. 
 5) Sistema deve manter cadastro de clientes. 
 4 
 
Garantia da Qualidade Controleda Qualidade 
a) Garantia da qualidade garante que o processo é 
definido e apropriado. 
b) Metodologia e padrões de desenvolvimento são 
exemplos de garantia da qualidade. 
c) Garantia da qualidade é orientada a processo. 
d) Garantia da qualidade é orientada a prevenção. 
e) Foco em monitoração e melhoria de processo. 
f) As atividades são focadas no inicio das fases no 
ciclo de vida de desenvolvimento de software. 
g) Garantia da qualidade garante que você está 
fazendo as coisas certas e da maneira correta. 
a) As atividades de controle da qualidade focam na 
descoberta de defeitos em pontos específicos. 
b) Um exemplo de controle da qualidade poderia ser: 
"Os requisitos definidos são os requisitos certos?". 
c) Controle da qualidade é orientado a produto. 
d) Controle da qualidade é orientado a detecção. 
e) Inspeções e garantia de que o produto de trabalho 
atenda aos requisitos especificados. 
f) As atividades são focadas no final das fases no ciclo 
de vida de desenvolvimento de software. 
g) Controle da qualidade garante que os resultados do 
seu trabalho são os esperados conforme requisitos. 
Aula 04: Identificação dos Stakeholders e Técnicas de Levantamento de Requisitos 
Nesta aula, você irá: 
 
1 - Conhecer o conceito de stakeholders. 
2 - Identificar características dos stakeholders. 
3 - Conhecer técnicas de levantamento de requisitos. 
4 - Relacionar cenários distintos e as melhores técnicas de levantamento de requisitos a serem aplicadas. 
 
Uma vez que já definimos uma estrutura e classificação para o desenvolvimento de um projeto de software com 
controle e garantia da qualidade, vamos na aula de tratar de identificar e detalhar sobre as pessoas que tenham 
e/ou sejam afetados por um software. Porque, também independente de tecnologia, certamente um projeto que 
atua na área da engenharia de software, contemplará a participação direta ou indireta, ativa ou passiva, de pessoas. 
E justamente nesse perfil de um indivíduo que em algum momento influi algum tipo de interesse, participação, etc., 
sobre um determinado software, a este caracterizamos como um stakeholder. 
Stakeholder 
Antes de levantarmos as considerações específicas da engenharia de software, vamos buscar um entendimento mais 
amplo do que vem a ser um stakeholder, permitindo assim que possamos compreender, por exemplo, que não é 
somente na Computação que existem, mas em todo em qualquer sistema (computacional ou não), sempre teremos 
agentes diretos ou indiretos, que irão compor ou sofrer das suas características. 
Com foco então em um ciclo de vida do software é possível claramente saber que ele é composto por diversas e 
distintas responsabilidades que estão vinculadas as pessoas, grupos e entidades. Dentre essas responsabilidades que 
podemos aqui elucidar, são exemplos: o responsável pelo financiamento, o projeto, o desenvolvimento, o teste, o 
uso e a manutenção do software. A todos estes chamamos de stakeholder. 
 A palavra vem de da seguinte composição: 
Stake  interesse, participação, risco; Holder aquele que possui. 
Portanto, todos aqueles que de alguma maneira é afetado pelo software, é um stakeholder (reveja sua resposta da 
questão vinculada ao questionamento da tela anterior). Então é correto afirmar que toda a preocupação no tocante 
ao correto desenvolvimento de um sistema e demais recursos de infra-estrutura, por sua vez, tem o duplo objetivo 
de facilitar o cumprimento das responsabilidades dos stakeholders, quanto atender às suas necessidades. 
 
Acompanhando acima, tente identificar a atividade da empresa que possa conter todos os usuários com base nos 
“pensamentos” citados nas caixas. Também procure distinguir quais deles seriam colaboradores e quais 
representam o(s) cliente(s), e, principalmente, sinalize quais serão os stakeholders desse cenário. 
Segundo Summerville (2009), podemos definir da seguinte forma: 
“Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou 
preocupações sobre a realização da arquitetura.” 
 
Exemplos de Stakeholders 
Com base então no que já aprendemos, podemos então relacionar os seguintes exemplos e atribuições de 
stakeholders no desenvolvimento de um projeto de software: 
Gerente de Projeto – Responsável em organizar e conduzir as equipes em suas responsabilidades. Como gestor, 
precisa manter harmonia no desenvolvimento do projeto, supervisionando a execução das tarefas, observar os 
processos, sustentar e fomentar o equilíbrio entre os stakeholders, etc. 
Analista de Sistema – Responsável em analisar quais as características o que deverá ter o produto a ser 
desenvolvido para atingir o objetivo final, ou seja, o que o cliente espera. Para isso, busca analisar as especificidades 
inerentes ao determinado software. 
Programador – São os responsável em efetivamente desenvolver do software. Cabe a ele a implementação das 
linhas de códigos que construirão a identidade lógica do software. 
Patrocinador – Popularmente é quem “paga a conta”. É aquele que libera os recursos, custeia a produção do projeto. 
Ele será o responsável por prover financeiramente a arquitetura necessária para o desenvolvimento de software. 
Cliente (usuário) – É aquele que, a partir de uma necessidade, faz a encomenda de um software. Portanto, é quem 
vai usufruir do produto a ser entregue. seja ele apenas um ou um grupo de usuários. 
Contudo, além destes supracitados, podemos ter muitos outros stakeholders – que não são tão elementares, mas 
possuem algum tipo de interesse. Por exemplo: 
 
Para contextualizar melhor, acompanhe o exemplo abaixo: 
uma pessoa qualquer que ficou no carro aguardando o amigo ou parente devolver um filme, tem grande interesse 
no desempenho do sistema utilizado pela locadora. caso contrário, o tempo de espera será maior do que o previsto. 
Portanto, tanto quem está no carro aguardando, como quem está na locadora para devolver o filme, são 
stakeholders. 
Características dos Stakeholders 
São outras características dos stakeholders: 
São específicos para cada projeto. Possuem anseios e objetivos distintos em um projeto. São atores fundamentais 
para detalhamento do que deve ser desenvolvido. 
Mediante então a todos esse envolvimento, fato que pode atrapalhar consideravelmente o êxito de um projeto de 
software é a ocorrência de uma falha no levantamento dos stakeholders. Tal realidade pode representar que o 
gerente de projeto não estará pensando nas necessidades de todos os envolvidos. como conseqüência, podemos ter 
um software que não atende aquilo que o cliente esperava, e de que deverá ser revisto e ajustado posteriormente. 
Portanto, gerará desgastes de recursos, além da insatisfação daquele que encomendou o sistema. 
Entretanto, o gerente de projeto deve observar bem seus objetivos e não procurar stakeholders por todos lados, o 
que culminará em um cenário difícil de gerenciar. Deve haver limitação no escopo daqueles que afetam e/ou serão 
afetados pelo projeto. Caso contrário, com um pouco de imaginação, pode-se considerar stakeholder até a mulher 
do gerente de projeto que deixará de sair com o marido no fim de semana porque ele terá que trabalhar! 
Concluindo essa primeira etapa de nossa aula, esperamos que você possa ter entendido toda o envolvimento e 
influência dos stakeholders em um projeto de software, suas relações e inter-dependência na concepção e uso de 
um determinado sistema. 
Técnicas para levantamento de Requisitos 
Diferentemente do que pode representar a melhor das iniciativas, acionar os programadores para começarem a 
escrever linhas de códigos não deve ser o foco de atenção para o projeto de software, a abertura para toda a 
atividade de desenvolvimento de software deve ser o levantamento de requisitos. 
Como já sabemos, a fonte das informações inerentes ao que queremos automatizar está com os futuros usuários, os 
quais atualmente já desenvolvem as mesmas tarefas, de forma manualou automática. Além que o cliente não 
estabelece claramente todas as regras relativas ao negócio. e quem está sendo contratado desconhece as 
especificidades referente ao processo que atualmente está em execução. 
Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as atividades que veremos 
a seguir. 
 
Apesar de aparentemente parecer elementar, o problema de não saber especificar corretamente o que o sistema 
deverá fazer é muito rotineiro. Realidades como: 
(a) de um usuário principal do sistema não saber o que quer que o sistema faça ou sabe e não consegue/quer 
transmitir para o analista. Ou (b) requisitos identificados, mas que não exprimem a realidade. e (c) não estão em 
concordância com os requisitos informados por pessoas diferentes, são constantes na elaboração dos requisitos. 
Um stakeholder ou informação errada afetará em perda de tempo e dinheiro para ambas as partes envolvidas no 
desenvolvimento do sistema. É preciso aferir e revisar os requisitos. 
No tocante ao do analista responsável pelo levantamento dos requisitos, dois fatores contribuem para o baixo grau 
de satisfação dos usuários, o que aumenta consideravelmente a perspectiva do erro. São eles: 
Não utiliza uma técnica adequada para extrair os requisitos do sistema. 
Descrever os requisitos do sistema de modo pouco claro, com ambigüidades, sem consistência com todos os 
aspectos significativos do sistema proposto. 
Como contramedida para atacar primeiro item acima, vamos agora estudar sobre as técnicas de levantamento de 
requisitos, detalhando seu conceito e suas respectivas vantagens e desvantagens, que podem ser utilizadas em 
conjunto pelo analista. 
Etnografia 
A etnografia é caracterizada como uma técnica de observação, aonde o analista buscar uma familiarização do 
cliente, seus valores, sua história. Ela pode ser utilizada para compreender os requisitos sociais e organizacionais, 
que facilitem compreensão da política organizacional e da sua cultura. 
Workshops 
Trata-se de uma técnica de elicitação desenvolvida em grupo, usada em uma reunião estruturada. São integrantes 
do grupo que participaram do workshop: 
Equipe de analistas. Seleção dos stakeholders mais envolvidos no contexto em que o sistema atuará. 
A principal estratégia do workshop tem é acionar o trabalho em equipe. Há um facilitador neutro cujo papel é 
conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em 
processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador. 
Uma vez encerrado, serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o 
sistema a ser desenvolvido. Aspectos considerados importantes para o sucesso são: 
A postura do condutor do seminário - mediador e observador. Deve possuir dia, hora, local, horário de início e de 
término. destacando o assunto a ser debatido e sua documentação. 
Entrevistas 
A entrevista também é uma das técnicas de levantamento de requisitos. Tradicionalmente mais simples de utilizar, 
produz bons resultados na fase inicial de obtenção de dados. Sobre a entrevista, deve-se considerar: 
O entrevistador dê margem ao entrevistado para expor as suas idéias; Ter um plano de entrevista para que seja 
mantido o foco no cerne do assunto principal; Evita que a entrevista fique longa, deixando o entrevistado cansado e 
não produzindo bons resultados. 
Questionários: 
Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de 
verificação e questões com espaços em branco. 
Um ambiente oportuno para o uso de questionário é quando há diversos grupos de usuários que podem estar em 
diversos locais diferentes do país. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários 
selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as 
pessoas em todos os locais. 
Questionários 
Identifique todos os destinatários que o receberão. 
Realize a distribuição junto com instruções detalhadas sobre seu preenchimento. 
Defina e informe o prazo para devolução do questionário. 
Documente o resultado da análise e consolidação das respostas dos participantes. 
Envie uma cópia com as informações levantadas para o participante, como sendo uma forma de agradecimento e 
consideração pelo tempo dedicado a pesquisa. 
 
Brainstorming 
Brainstorming é uma técnica para geração de idéias. Uma idéia preliminar gerada serve como incentivo para que 
outras apareçam, sejam concordantes ou não, propiciando um aprimoramento e compartilhamento de todos os 
envolvidos. Pode ser estabelecida uma ou várias reuniões. O número de idéias geradas deve ser bem grande, pois 
quanto mais idéias forem propostas, maior será a chance de aparecerem boas idéias. Os participantes também 
devem ser encorajados a combinar ou enriquecer as idéias de outros e, para isso, é necessário que todas as idéias 
permaneçam visíveis a todos os participantes. 
Uma vez definido que esta é a técnica mais apropriada para determinada situação, as próximas etapas necessárias 
para conduzir uma sessão de brainstorming estão elencadas nos balões em destaque. 
Seleção dos participantes ou grupo de trabalho: Estes devem ser selecionados em função direta com as 
contribuições que possam oferecer durante a sessão. É aconselhável sempre a presença de pessoas que estejam 
sempre bem informadas, sejam de diferentes grupos. 
Prepara a sessão: Duração e local do encontro, bem como o que será tratado. 
Explicar a técnica e as regras a serem seguidas: Definir os conceitos básicos de brainstorming e as regras a serem 
seguidas durante a sessão. 
Gerar ou produzir uma boa quantidade de idéias: Os participantes geram tantas idéias quantas forem exigidas pelos 
tópicos que estão sendo o objeto do brainstorming. Os participantes são convidados, um por vez, a dar uma única 
idéia. Se alguém tiver problema, passa a vez e espera a próxima rodada. 
Analisar as idéias: Revisar a produção de idéias, destacando as mais valiosas definidas pelo grupo e classificando-as 
com prioridades. 
Prototipagem 
Protótipo tem por alvo explorar requisitos vinculados a um produto que possua aspectos críticos, implementando de 
maneira mais rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo é aconselhado para: 
 
As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios 
gráficos, entre outras. Um dos principais benefícios que podemos relacionar são as reduções dos riscos na 
construção do sistema, pois é possível detectar se o usuário chave já verificou o que o analista captou nos requisitos 
do produto. 
São elementos para o sucesso na elaboração dos protótipos: 
Seleção do ambiente de prototipagem; Compreender os objetivos do protótipo por parte de todos os interessados 
no projeto; Focar em áreas que estejam com maior dificuldade na compreensão. Rapidez na construção. 
JAD 
Por fim, não menos importante, vamos apresentar uma técnica de grande adesão pelos analistas a fim de realizar o 
levantamento de requisitos: JAD (Joint Application Design). É uma técnica destinada a principalmente promover 
cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores. Com a intenção de facilitar a 
criação de uma visão compartilhada do que o produto de software deve ser, ela ajuda os usuários e desenvolvedores 
a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido. Tal fato estabelece sentimento 
de envolvimento, posse e responsabilidade com o sucesso do produto. 
Possui quatro princípios básicos: 
Dinâmica de grupo: São realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a 
força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitosdo sistema. 
Uso de técnicas visuais: Para aumentar a comunicação e o entendimento. 
Manutenção do processo organizado e racional: O JAD emprega a análise top down e atividades bem definidas. 
Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada 
nível de detalhe recebe a devida atenção. 
Utilização de documentação padrão: Preenchida e assinada por todos os participantes. Este documento garante a 
qualidade esperada do projeto e promove a confiança dos participantes. 
 
Nesta aula, você: 
 Compreendeu o que é um stakeholders. 
 Aprendeu sobre técnicas para levantamento de requisitos. 
 Analisou diferentes estratégicas para um bom levantamento de requisitos. 
 
O que vem na próxima aula: 
 Documento de Requisitos de Software. 
 Composição do Documento de Requisitos de Software. 
 Utilidade e validade do Documento de Requisitos de Software. 
 
 
 
 
1. 
Qual a composição da palavra stakeholder? 
 1) Stake = intresse; Holder = constrói. 
 2) Stake = zelo; Holder = participa. 
 3) Stake = interesse; Holder = possui. 
 4) Stake = fator; Holder = participa. 
 5) Stake = interesse = Holder = faz. 
 3 
2. 
São exemplos de técnicas de levantamento de requisitos: 
 1) Stakeholders, etnografia, JAD. 
 2) Etnografia, prototipagem, JAD. 
 3) Assembléia, questionário, entrevista. 
 4) Viagem, debate, questionário. 
 5) Debate, reunião, etnografia. 
 2 
3. 
Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os 
stakeholders desejam do sistema. Qual a etapa do levantamento de requisitos que compreende a atividade descrita? 
 1) Compreensão de domínio. 
 2) Coleta de requisitos. 
 3) Verificação de requisitos. 
 4) Alteração de requisitos. 
 5) Rastreamento de requisitos. 
 3 
Aula 05: Documentação de Requisitos de Software 
Nesta aula, você irá: 
 
1. Aprender sobre o documento de requisitos. 
2. Reconhecer a importância da elaboração do documento de requisitos. 
3. Verificar os pontos prioritários e a atenção na redação de um documento. 
4. Compreender quem são os envolvidos no processo de criação de um documento de requisitos. 
5. Verificar a composição de um documento de requisitos. 
Até essa etapa, conseguimos estabelecer uma boa perspectiva de todo o contexto que envolve um projeto relacionado a 
desenvolvimento de software. Mesmo para aqueles que já atuam na área de desenvolvimento de sistema, mas a cada aula vamos 
adicionando necessidades e entendendo que não basta codificar uma sequência lógica de um procedimento em uma 
determinada linguagem de programação, mas que existem métodos que auxiliam e estabelecem modelos para que possamos 
alcançar um resultado mais aderente e satisfatório junto ao cliente. 
 
 Tudo que estamos estudando nessa disciplina é para fazer com que entendamos bem do problema, da sistemática já ou se 
existente - quem está contratando, além de estabelecer um elo entre o que se espera e o que será entregue. 
 
Conceito 
De acordo com Sommerville (2009): 
“o documento de requisitos de software, às vezes chamado de Especificação de Requisitos de Software (SRS – do inglês Software 
Requeriments Specification), é uma declaração oficial do que os desenvolvedores do sistema devem implementar”. 
Enfim, como sabemos que a área de requisitos de sistemas tem total ligação com o fator qualidade para o 
desenvolvimento de software, o documento de requisitos trata então de indicar e detalhar sobre os componentes a 
serem inseridos no sistema que está sendo construído. Uma vez concluído, se comportar como uma bússola que 
detalha quais as ferramentas a serem estabelecidas ao término do projeto. Como tudo o que vimos até agora, não 
seria diferente com este documento. 
Enfim, não é simplesmente criar um documento no editor de texto e digitar os itens e seus respectivos conceitos. É 
preciso ter disciplina e orientação para alcançar um documento que seja acessível e entendido pelos diversos 
participantes do projeto, evitando que ele seja o primeiro recurso de desentendimento e dificuldade para a 
compreensão do que está sendo desenvolvido. 
Portanto, vamos então conhecer sobre o documento de requisitos de software! 
Objetivo 
 
 
Exemplo 
Veja o exemplo abaixo, retirado do livro do PFLEEGER (Engenharia de Software – Teoria e Prátíca – 2ª Edição, pág. 140): 
Em 1995, a Organização Australiana de Defesa e Tecnologia relatou os resultados de uma pesquisa sobre problemas 
com especificação de requisitos na Marinha. Um dos problemas destacados foi a disparidade no nível das 
especificações. Isto é, alguns requisitos foram especificados em um nível alto e outros em um nível muito baixo. A 
disparidade era composta de diversas situações: 
Algumas vezes, os analistas de requisitos utilizaram diferentes estilos de escrita, especialmente em área diferentes 
do sistema. 
A diferença de experiência entre os analistas levou a diferentes níveis de detalhes nos requisitos. 
Na tentativa de reutilizar os requisitos a partir de sistemas anteriores, os analistas empregaram diferentes formatos 
e estilos de escrita. 
Os analistas, algumas vezes, mesclaram requisitos com soluções parciais, levando a sérios problemas para o projeto 
de uma solução com boa relação custo-benefício. 
Frequentemente, os requisitos foram excessivamente especificados, quando os analistas identificaram tipos 
específicos de computadores e linguagens de programação assumiram uma solução específica ou impuseram 
processos e protocolos não apropriados. 
Algumas vezes, os requisitos foram pouco especificados, especialmente ao descreverem o ambiente de operação, 
manutenção, simulação para treinamento, computação administrativa e tolerância a falhas. 
Exemplos de usuário 
Conforme apontando em Sommerville (2009) na Figura 1, são estes exemplos de usuários de um documento de 
requisitos de software: 
Clientes do Sistema: Especificam e lêem os requisitos para verificar se estes satisfazem suas necessidades. Os 
clientes especificam as alterações nos requisitos. 
Gerentes: Usam documentos de requisitos para planejar uma proposta para o sistema e para planejar o processo de 
desenvolvimento do sistema. 
Engenheiros de Sistemas: Usam os requisitos para entender o sistema que será desenvolvido. 
Engenheiros de Testes de Sistemas: Usam os requisitos para desenvolver testes de validação de sistema. 
Engenheiros de Manutenção de Sistema: Usam requisitos para entender o sistema e os relacionamentos entre suas 
partes. 
Da mesma particularidade que existe em um projeto de software, tornando-o único em algum(ns) ponto(s), toda a 
informação a ser disposta no documento de requisitos tem total vínculo com o perfil do sistema a ser desenvolvido. 
Portanto, podemos encontrar documentos com o foco sobre a definição de requisitos de usuários e os requisitos não 
funcionais, ou que envolva requisitos de sistemas e requisitos funcionais, bem como outras combinações entre eles. 
Ainda sob o aspecto de fatos particulares, outro aspecto que deve também ser definido é o nível de detalhamento a 
ser utilizado para descrição dos requisitos no documento. 
Perfil de um Documento 
Então agora, mais contextualizados sobre o perfil de um documento de requisitos, passaremos para uma nova etapa, 
na qual iremos aprender detalhes sobre a sua estrutura, conhecendo o que pode ser considerado para a sua criação. 
Para tal finalidade, utilizaremos a composição definido por Sommerville (2009) – bibliografia básica de nossa 
disciplina, a qual está disposta abaixo: 
Prefácio: Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma 
justificativa para a criação de uma nova versão e um resumo das mudanças feitas em cada versão. 
Introdução: Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e 
explicar como ele vai funciona com outros sistemas. Tambémdeve descrever como o sistema atende aos objetivos 
globais do negócio ou estratégicos da organização que encomendou o software. 
Glossário: Deve definir os termos técnicos usados no documento. Não deve conter suposições sobre o conhecimento 
ou experiência do leitor. 
Definição de requisitos de usuário: USUÁRIO:Deve descrever os serviços oferecidos ao usuário. Os requisitos não 
funcionais do sistema também devem ser descritos nessa seção. Essa descrição pode usar linguagem natural, 
diagramas ou outras notações compreensíveis para os clientes. Normas produtos que devem ser seguidos devem 
sem especificados. 
Modelos do sistema: Pode incluir modelos gráficos do sistema que mostram relacionamentos entre os componentes 
do sistema, o sistema e seu ambiente. 
Evolução do sistema: Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como 
quaisquer mudanças previstas, em decorrência da evolução do hardware, de mudanças nas necessidades do usuário, 
etc. Essa seção é útil para projetistas de sistemas, pois pode ajudá-los a evitar decisões capazes de restringir 
possíveis mudanças futuras no sistema. 
Apêndices: Deve fornecer informações detalhadas e especificas em relação à aplicação em desenvolvimento, além 
das descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações 
mínimas do sistema. Requisitos de banco de dados definem a organização lógica dos dados usados pelo sistema e os 
relacionamentos entre esses dados. 
Índice: Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um 
índice de diagramas, de funções, dentre outros que sejam pertinentes. 
 
Nesta aula, você: 
 Compreendeu sobre a necessidade e importância da elaboração de um documento de requisitos de 
sistemas. 
 Aprendeu a estrutura e componentes de um documento de requisito. 
 Analisou uma proposta para elaboração de um documento de requisito. 
 
1. 
 É uma característica do documento de requisitos: 
 1) Totalmente técnico. 
 2) Lido apenas pelos programadores e analista de sistemas. 
 3) Lido apenas pelos clientes e pelo patrocinador do projeto. 
 4) Documento gerencial, restrito à cúpula da organizacional. 
 5) Por várias pessoas que tenham envolvimento no projeto do software. 
 5 
 2. 
 Fazem parte da estrutura de um documento de requisitos: 
 1) Prefácio, introdução e definição do ambiente de trabalho do cliente. 
 2) Introdução, lista programadores e índices. 
 3) Definição de requisitos de usuário, modelos do sistema e evolução do sistema. 
 4) Configuração do sistema operacional, detalhamento da equipe de projetistas e apêndices. 
 5) Definição de requisitos de usuário, introdução e a norma ISO correspondente. 
 3 
 3. 
 São usuários de um documento de requisitos: 
 1) Clientes do sistema. 
 2) Entidades não governamentais. 
 3) Fornecedores da empresa que solicita o software. 
 4) Os bancos e outras instituições financeiras. 
 5) Todos citados nos itens anteriores. 
 1 
 
Nesta aula, você irá: 
 
1. Identificar o conceito e os processos de engenharia de requisitos. 
2. Identificar o conceito sobre viabilidade de requisitos. 
3. Reconhecer a importância da atividade de análise de viabilidade. 
4. Realizar a análise de viabilidade de um projeto de software. 
Aula 06: Engenharia de Requisitos e Estudos de Viabilidade 
Nessa etapa iremos imergir detalhar nos conteúdos sobre a engenharia de requisitos, inclusive nossa aula de hoje 
iniciar pelos fundamentos dessa área, destacando a importância no resultado de um software que atenda as 
necessidades dos usuários. 
Serão trabalhadas quatro atividades da área de requisitos, com base na seguinte ordem: Viabilidade, Elicitação, 
Validação e Gerenciamento. 
Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não temos 
um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema, 
certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os sistemas 
os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a padronização o 
procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido. 
Engenharia de Requisitos 
Engenharia é uma palavra que costuma sempre nos lembrar sobre processos relacionados a criação, ampliação e/ou 
reforma. Também é comum pensarmos em criação – mediante a engenharia civil. Então, quando pensamos em um 
engenheiro, estamos pensando em algum tipo de construção. Pois bem, existem várias variáveis que o profissional 
da área deve atentar-se antes de simplesmente, por exemplo, estudar as composições físicas ou químicas mais 
apropriadas. Para isso, ele precisa averiguar! 
Portanto, quando falamos em engenharia de requisitos, estamos a tratar de um processo que define atividades para 
uma produção e, do documento de requisitos de software, o qual foi estudado na unidade anterior. Este importante 
documento para direcionamento do sistema a ser desenvolvidos. Para atingir esse objetivo, temos uma 
sistematização de um processo para definir o perfil do software. 
 
A premissa básica então para a engenharia de requisitos de software é definir o que deve ser feito; ou seja, é um 
trabalho de interpretação. Ela não se preocupa no como deve ser feito. Com isso, questões tecnológicas como 
linguagem de programação, sistema gerenciador de banco de dados, topologias de redes de computadores, não 
representam o cerne a ser detalhado, mas sim todas as necessidades que os “humanos” esperam da “máquina”. 
Na figura 1, temos a definição do processo de engenharia de requisitos: 
 
Análise de Requisitos 
Conforme citado no início de nossa aula, teremos uma aula para tratar cada um dos componentes do processo. 
Por enquanto, trataremos apenas de explicar o modelo de maneira geral. O estudo de viabilidade aponta então se o 
projeto está adequado para responder a contento ao que a empresa quer, e que esteja apoiado nas condições dos 
recursos disponíveis. Este gera então um relatório a qual aponta as conclusões e devidas justificativas. Ou seja, o 
projeto pode ser cancelado antes mesmo de qualquer digitação de linha de código. 
Na análise de requisitos, segundo passo do processo, que busca identificar entre os stakeholders as funcionalidades 
ideais e fundamentais para o software. 
Definição dos requisitos, como o nome já sugere, é responsável em receber todas as informações referente a análise 
de requisitos e promover então o que será especificado como requisito para o sistema que será definido. 
Por fim, a fim de consolidar o processo com o nível de detalhe e especificidade necessários, são descritos todos os 
requisitos que já estão definidos. 
 Importante observar que a partir do 2º passo(Análise de Requisitos), temos setas bidirecionais, que estabelece que 
pode haver um retorno entre as atividades, principalmente mediante a identificação de um erro na fase anterior 
àquela que está sendo executada no momento. Lembre-se que ao término do processo, tudo que estiver contido no 
documento de requisito de software deve ser atendido plenamente; portanto, o lapso culminará em um sistema 
sem qualidade. 
No contexto Na figura 2 está disposta um modelo mais completo, em espiral, do processo de engenharia de 
requisitos, segundo proposta por Sommerville (2011): 
 
Figura 2 - Processo de Engenharia de Software em Espiral (Sommerville, 2011) 
Estudos de Viabilidade 
Para todo projeto que estimamos realizar, seja ele para nós ou para a empresa a qual colaboramos, uma pergunta 
muito básica e fundamental sempre deve ser respondida: Será que contribui para os meus objetivos? 
Uma estimativa realizada para verificar se as necessidades do usuário podem ser satisfeitas usando correntes de 
software e hardware, à custo e prazo efetivo. 
A partirentão do resultado alcançado da reflexão a partir desse questionamento, é que no tocante a área da 
tecnologia da informação e que estamos estudando, vamos então adicionar os seguintes questionamentos: Dadas 
as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais 
associadas ao projeto, será que o sistema pode ser implementado? Caso haja necessidade de internação entre 
diferentes sistemas, será que esta é possível? 
Conforme o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e 
organizacional, se o projeto é viável e se representará uma solução capaz de ser executada e de agregar valor. 
Portanto, muito antes de pensarmos em requisitos, temos que saber se o sistema pode ser concluído e/ou mantido, 
por exemplo. São outros exemplos de questões que devem ser avaliadas: 
 
Analisando dos itens supracitados, percebemos que a questão mais crítica é a primeira, já que um sistema que não 
contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não 
se justifica. Apesar de parecer óbvio, frequentemente constata-se que um determinado software não contribui para 
os objetivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por 
falta de clareza na definição dos objetivos da organização, porém ele foi desenvolvido ou até mesmo já adquirido. 
Os Stakeholders no Estudo de Viabilidade 
No estudo de viabilidade, é comum termos várias fontes de informações. Tipicamente, temos os seguintes 
stakeholders: 
Quem poderá fornecer esta informação serão os utilizadores dos sistemas atuais e do sistema a implementar. 
Os responsáveis pelos departamentos nos quais o sistema será usado. 
Técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes). 
Responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão 
qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados). 
Deve, portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta 
informação, procedendo-se de seguida a escolha de todos os dados disponíveis para permitir mais exatidão e visões 
no âmbito do projeto, permitindo realmente avaliar a sua viabilidade. 
A partir das conclusões obtidas, outra atividade no processo de estudo de viabilidade é a produção de um relatório e 
deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, 
temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível. 
Nesta aula, você: 
 Aprendeu o conceito de engenharia de requisitos. 
 Compreendeu o conceito de estudos de viabilidade. 
 Aprendeu a importância da atividade de estudos de viabilidade. 
 Analisou o que deve ser tratado em um documento de estudos de viabilidade. 
 
1. 
 Qual a premissa básica para a engenharia de requisitos: 
 1) Como fazer e o quê fazer? 
 2) Como fazer? 
 3) O que fazer? 
 4) Definir o stakeholder. 
 5) Definir uma estrutura de software. 
 3 
 2. 
 É processo da engenharia de requisitos: 
 1) Definir stakeholders. 
 2) Analisar requisitos. 
 3) Definir uma estrutura de software. 
 4) Definir arquitetura de rede. 
 5) Definir sistema gerenciador de banco de dados. 
 2 
 3. 
 Qual o objetivo da análise de viabilidade sobre um determinado projeto? 
 1) Gerar um relatório sócio-ambiental do projeto. 
 2) Gerar um relatório técnico da área de TI. 
 3) Gerar um relatório para os fornecedores envolvidos no projeto. 
 4) Gerar um relatório sobre os custos, prazos e benefícios do projeto. 
 5) Gerar um relatório de financeiro do projeto. 
 4 
 
Aula 7: ELICITAÇÃO DE REQUISITOS 
1. Aprender sobre o conceito da elicitação de requisitos. 
2. Compreender o processo de elicitar requisitos. 
3. Reconhecer a importância da elicitação de requisitos para projetos. 
Seja bem-vindo a segunda etapa das nossas aulas sobre as atividades da área de requisitos. 
Continuaremos imersos nos conteúdos sobre a engenharia de requisitos; nossa aula de hoje trabalhar sobre a 
elicitação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos 
usuários. Revisando sobre as quatro atividades da área de engenharia de requisitos (principalmente se precisa 
revisar algum assunto), veja ordem abaixo: 
Aula 6 - Viabilidade. 
Aula 7 – Elicitação. 
Aula 8 – Validação. 
Aula 9 – Gerenciamento. 
Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não temos 
um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema, 
certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os sistemas 
os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a padronização o 
procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido. 
Portanto, caso tenha o desejo em atuar na área de projetos, certamente lhe será requerido conhecer bem sobre as 
atividades inerentes a engenharia de requisitos, no tocante a entender o real problema do seu cliente. Tendo em 
mãos essa importante informação, terás grandes possibilidades de um resultado mais apurado e correto. Faça um 
bom proveito! 
Vamos lá! 
Finalidade de um Software 
Conforme tratamos no início do estudo da disciplina, é preciso saber e fazer saber a(s) finalidade(s) de um software. 
Portanto, um fundamental questionamento que precisa ficar bem esclarecido para todos os envolvidos é: 
O QUE REALMENTE QUEREMOS? 
 
Análise do Exemplo 
A figura anterior demonstra um cenário que envolve dois fatores: céu com nuvens e uma grama verde. Apenas estes 
são substancialmente suficientes para diferentes interpretações, sujeitando a diversas soluções que não 
compreende a resolução efetiva do que se queria. Importante ver que nem mesmo o próprio cliente soube explicar 
com exatidão o que ele queria. 
Podemos então rapidamente transferir ao cliente a responsabilidade pela não conformidade do produto entregue; 
destituindo-nos de qualquer culpa, então friamente nos posicionamos: “lhe entregamos o que foi pedido!” 
Seria então esse o perfil mais adequado? Certamente que se queremos ser uma empresa de referência para 
segmentos de software e/ou engenharia de requisitos, definitivamente, NÃO! 
Então imagine um cenário em que o cliente esteja apresentando suas necessidades e seus objetivos para um sistema 
computacional. Lá estão alguns diretores e representantes da empresa contratada: 
- Queremos que o sistema faça: isso, isso, aquilo, isso juntamente com aquilo... 
- Também podemos então adicionar aquilo outro que vi no do meu colega, que pertence aquela empresa (detalhe: a 
empresa é de outro segmento comercial). 
Então, quando do uso da palavra (de terno e gravata), fala de maneira convincente: 
- Tudo anotado e esclarecido. Tenho certeza que ficará muito satisfeito com o que lhe entregaremos. 
A diretoria reúne os usuários que serão “beneficiados” com o sistema; fala sobre como a vida deles mudará – 
inclusive já está levantando quantos deverão permanecer na empresa. 
Faz o convite para o representante da contratada para prestar esclarecimento. 
Novamente, ele faz uma apresentação do seu currículo e em quer resultará o projeto. Detalhe: alguns funcionários 
começam a especular perigo de demissão em massa. 
Então soa a pergunta: 
- Alguém tem alguma sugestão? 
O genro de um dos diretores levanta-se na plateia e saúda a iniciativa como sendo de tempos modernos para a 
organização, pedindo aos presentes uma salva de palmas. 
Depois de algum tempo de espera eis que o documento de requisitos de software está pronto. E é remetido para 
análise."A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma 
outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma 
outra parte oferece tanta dificuldade para efetuar correções posteriores." — Fred Brook 
Elicitação 
ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão. 
Sob o escopo do analista de negócios, a elicitação é a atividade responsável em compreender as necessidades e 
preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam. Portanto, é preciso saber 
que existe uma distinção entre “elicitar” e “levantar”, uma vez que o primeiro termo é mais abrangente é o foco na 
extração das necessidades verdadeiras, que podem ou não estar explícitas. 
A atividade da elicitação dos requisitos não é habitualmente desenvolvida forma isolada, visto que a identificação de 
requisitos costuma aparecer de forma cíclica durante sessões tanto de levantamento quando de validação, portanto 
requer uma combinação de técnicas para que seja completa. Conforme estudamos na primeira unidade, as técnicas 
de levantamento de requisitos são: brainstorming, análise documental, entrevistas, observação, prototipagem, 
workshops de requisitos e pesquisa/questionários. 
No tocante as tarefas inerentes ao processo da elicitação dos requisitos, temos: a preparação, condução, 
documentação e confirmação dos resultados da elicitação. 
A elicitação de requisitos envolve o processo de identificar junto aos stakeholders, frente ao sistema ou produto, os 
seguintes pontos: 
1. Os alvos a serem alcançados; 2. Os pontos a serem acompanhados; 3. Como se encaixa no contexto das 
necessidades do negócio; 4. O comportamento ou operacionalização da solução na rotina da empresa. 
 
Problemas de escopo: excesso ou falta de detalhamento. Os clientes/usuários desconhecem o que é importante (ou 
até mesmo quer ocultar), inibindo os limites do sistema, o que dificulta uma definição completa. 
Problemas de compreensão: omitem informações que julgam óbvias; clientes/usuários desconhecem ou estão em 
dúvidas sobre as necessidades e como seu papel é fundamental; é leigo ou limitado no conhecimento de seu 
ambiente computacional ou do domínio do seu negócio e etc. 
 Problemas de volatilidade: mudanças constantes nos requisitos. 
 
Independente do tamanho do que esteja sendo construídos, os produtos da utilização dos passos trabalho incluem: 
• Ter totalmente bem estruturadas as necessidades e viabilidade; bem como, a definição do limite de escopo do 
sistema ou produtos; 
• A relação de clientes, usuários e outros stakeholders que participaram da atividade de elicitação de requisitos; 
• Conhecimento descritivo do ambiente técnico do sistema; 
• A lista de requisitos e suas respectivas aplicações regras de domínio. 
• Cenários de uso que promovem uma concepção do uso do sistema sob diferentes condições de operação; 
• Informação de um modelo que eventualmente tenha sido desenvolvido para melhor definir os requisitos. 
• Revisões realizadas por todas as pessoas que tenham participado da elicitação de requisitos. 
Nesta aula, você aprendeu: 
 Compreendeu a necessidade de processo de elicitação de requisitos. 
 Perfil do analista de negócios, responsável na condução de elicitação de requisitos. 
 Analisou que a elicitar requisitos faz parte de qualquer projeto. 
Atenção aos pdfs desta aula. 
 
 
 
 
1. 
Sob a ótica do que estudamos nessa aula, representa um fator que contribuiu para insucesso nos projetos de software. 
 1) Reuniões longas. 
 2) Ausência da diretoria. 
 3) Requisitos mal identificados. 
 4) Inveja e problemas de relacionamento interno. 
 5) Muitas pessoas envolvidas. 
 3 
2. 
São tarefas inerentes ao processo da elicitação dos requisitos: 
 1) A preparação, condução e documentação da elicitação. 
 2) Entrevistas, condução e preparação da elicitação. 
 3) Questionários, entrevistas e condução da elicitação. 
 4) Feedback, preparação e condução de elicitação. 
 5) Condução, questionários e documentação da elicitação. 
 1 
3. 
Importantes qualidades para o analista de negócio, principalmente vinculado a elicitação de requisitos. 
 1) Organizado, fala e ouve muito. 
 2) Criativo, organizado e ouve pouco. 
 3) Observador, bom questionador e fala muito. 
 4) Escreve bem, fala e ouve muito. 
 5) Criativo, organizado e observador. 
 5 
Aula 08: VALIDAÇÃO DE REQUISITOS 
1. Identificar mais uma atividade da engenharia de requisitos. 
2. Reconhecer o processo de validação de requisitos. 
3. Verificar o motivo e a importância da validação de requisitos. 
O processo de validação de requisitos é também uma fase importante na elaboração de um documento de 
requisitos. Mesmo atendendo as etapas de elicitação, pode incorrer que erros passem despercebidos na etapa, 
pode criar certos problemas quando esses erros forem detectados numa fase posterior, ou seja, o documento de 
requisitos já terá sido validado pelo cliente. 
Na etapa de elicitação aprendemos que vamos levantar e evidenciar o requisito. Agora, vamos DEMONSTRAR que 
conseguimos compreender e definir bem as características a serem incorporadas no software. Para este momento, 
o contratado é quem assume o papel principal, sendo o foco da comunicação; o contratante acompanha e avalia. 
Esse processo da engenharia de requisitos trata em especial dos critérios relacionados à consistência, precisão, 
contextualização de requisitos levantados no processo de identificação e descoberta e de análise e negociação de 
requisitos. 
Documento de requisitos de software 
Segue uma relação de propriedades que são avaliadas no tocante ao documento de requisitos de software pela 
equipe responsável na validação: 
• Completude e consistência; 
• Conformidade com os padrões; 
• Conflitos de requisitos; 
• Erros técnicos; 
• Requisitos ambíguos. 
Sommerville destaca que “o custo para consertar um problema de requisitos por meio de uma mudança no 
sistema é geralmente muito maior do que o custo para consertar erros de projetos ou codificação. A razão para 
isso é que a ocorrência de mudança dos requisitos normalmente significa que o projeto e a implementação do 
sistema devem ser alterados”. 
Daí então a característica crítica nessa atividade, e o destaque como sendo um dos mais importantes 
na engenharia de requisitos. Tendo em visto que um documento de requisitos bem definido permite aos 
envolvidos atuar de maneira consistente nas incoerências e inconformidades no desenvolvimento de um produto 
de software. Perceba que também o contexto da validação nos permite a identificação destas mesmas 
incoerências na fase anterior à versão final do relatório de requisitos, o que proporciona um nível de acerto maior, 
e minimiza consideravelmente uma detecção vindoura destas incoerências numa fase posterior, ou, pior ainda, até 
mesmo na finalização do sistema. 
Sommerville (Engenharia de Software, 2009) enfatiza ser possível afirmar que o processo de validação de 
requisitos está para o documento de requisitos assim como a fase de testes unitários e de sistema está para a fase 
de desenvolvimento de um projeto de software. 
É encontrado e provado pela literatura que detectar um erro em fases finalistas de um projeto, pode chegar a ser 
danoso a ponto de incompatibilizar a continuidade, visto que pode ser tão custosa que não existe recursos para 
comportá-la. Por isso, a atenção deve ser constante e minuciosa. 
São exemplos dos problemas que o processo de validação pode solucionar: 
• Não conforme as normas de qualidade do projeto e da empresa; 
• Descrição pouco clara dos requisitos; • Ambiguidade entre requisitos; 
• Falhas na modelagem dos requisitos; • Conflitos entre requisitos; 
• Requisitos não realistas; • Ausência de informação. 
Insumos e produtos gerados pela atividade da validação de requisitosNa figura abaixo, segue uma síntese no tocante aos insumos e produtos gerados pela atividade da validação de 
requisitos. 
 
A partir da compreensão do que na figura anterior, claramente conseguimos ter a percepção de um sistema da 
informação, contendo: entrada, processamento e saída. Com base nesse modelo, então define-se que o processo 
de validação de requisitos têm como entrada o arcabouço oriundo dos processo de: 
(a) análise e elicitação de requisitos; 
(b) das normas de qualidade da organização; 
(c) conhecimento empírico obtido contido na empresa, principalmente vindo de outros projetos ou de 
skateholders experientes no assunto. Na etapa de processamento temos a validação dos requisitos, que gera 
como saída uma lista de problemas que devem ser resolvidos e ações que são combinadas. 
Passaremos então a estudar sobre as técnicas existentes para o processo de validação. 
Revisão dos Requisitos 
É uma técnica, como o nome já sugere, a qual são analisados e revisados sistematicamente todos os requisitos 
elicitados, executando um checagem no tocante a erros e inconsistências. 
É uma boa prática para esta técnica uma reunião formal com representantes ou especialistas de todas as áreas, 
tanto do contratante como do contratado. Portanto, todas as equipes deverão ter representação. São 
recomendadas as seguintes providências: 
• Planejamento do que será revisado. 
• Estabelecer e convidar os envolvidos. 
• Definir local e tempo para a reunião. 
• Escolher para condução alguém “livre de vícios”, ou seja, que não estava integrado à equipe desenvolveu o 
documento de requisito. 
• Realizar procedimento de checklists para os requisitos e nas relações entre eles. 
• Distribuir previamente todos os documentos a serem utilizados na reunião. 
• Apresentar cada requisitos individualmente. 
• Discutir e anotar comentários para cada requisito que apresenta erro ou inconsistência. 
• Estabelecer um período de soluções após todo o término dos relatos apurados nas análises. 
• Apurar a qualidade final do documento de requisitos. 
No tocante ao item 10, segue na tabela abaixo questões e respectivos atributos de qualidade que devem ser 
considerados na apuração: 
 
 
Prototipagem 
A fim de estabelecer uma demonstração mais didática sobre o projeto, desenvolve-se um protótipo para que os 
stakeholders possam compreender de maneira mais exata o funcionamento do sistema. “Nessa abordagem para 
avaliação, um modelo executável do sistema é demonstrado para os usuários finais e clientes.” (Sommerville, 
2009). O objetivo é tornar mais fácil a fase de validação de requisitos, visto que, através da demonstração visual, 
tornar-se mais intuitivo detectar inconsistências e problemas nos requisitos. 
Experientes nessa técnica evidenciam algumas preocupações para sua adoção: 
A qualidade do protótipo poderá levar a desilusões para os utilizadores finais, visto do ambiente projetado para os 
testes não ser aprazível aos usuários, principalmente no tocante as telas do sistema (as interfaces). 
Mediante a anuência do que foi apresentado com teste, incentivar os programadores a uma baixa qualidade nas 
interfaces. 
O tempo gasto no desenvolvimento do protótipo em detrimento dos prazos estabelecidos para o projeto. 
Testes de Requisitos 
Uma propriedade importante para cada requisito é o de ser testável. Para cada requisito funcional deve ser 
possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema 
cumpre o requisito na integra. Caso tal propriedade não esteja presente, ou até mesmo se for muito difícil testá-lo; 
tal circunstância indica a necessidade de uma retificação. 
A realidade implica em uma probabilidade considerável para que todo o requisito que não pode ser testado 
muito provavelmente será instituidor de problemas. Deve-se então reconsiderar a presença deste, buscando por 
alternativas testáveis. 
Então quando da realização dos testes, deve-se tomar nota das características observadas quanto ao requisitos em si 
(identificador, requisitos relacionados), como aqueles relacionados aos testes (descrição, problemas, comentários, 
recomendações, etc.). 
Nesta aula, você: 
 Aprendeu sobre mais uma atividade da engenharia de requisitos. 
 Analisou o processo de validação de requisitos. 
 Compreendeu a importância da validação de requisitos para o documento de requisitos de software. 
 
1. 
 A validação de requisitos atua no foco de qual documento? 
 1) Documento financeiro. 
 2) Documento de recursos humanos. 
 3) Documento de requisitos de software. 
 4) Documento de programadores. 
 5) Documento de analistas de sistemas. 
 3 
 2. 
 São algumas propriedades analisadas pelo processo de validação no tocante ao documento de requisitos de software. 
 1) Completude e consistência. 
 2) Volume de dimensão. 
 3) Modelo de página para impressão. 
 4) Formatação do texto adequado ao modelo da empresa. 
 5) Correção ortográfica. 
 1 
 3. 
 O produto gerado pela validação de requisitos contempla: 
 1) Relatório financeiro e contábil do investimento a ser realizado. 
 2) Informações confidenciais sobre a empresa contratante e da contratada. 
 3) Erros de ortografia, acentuação e concordância no texto. 
 4) Atributos que definem a linguagem de programação a ser utilizada. 
 5) Lista de problemas que devem ser resolvidos e ações que são combinadas. 
 5 
Aula 09: Gerenciamento de requisitos 
1. Conhecer mais uma atividade da engenharia de requisitos. 
2. Identificar a função da atividade de gerenciamento de requisitos. 
3. Reconhecer a importância do controle de mudanças. 
Seja bem-vindo a última etapa das nossas aulas sobre as atividades da área de requisitos. 
Encerramos hoje os conteúdos sobre a engenharia de requisitos; nossa aula trabalhará assunto sobre o 
gerenciamento de requisitos, destacando a importância no resultado de um software que atenda as necessidades 
dos usuários. 
Revisando sobre as quatro atividades da área de engenharia de requisitos (principalmente se precisa revisar algum 
assunto), veja ordem abaixo: 
• Aula 6 - Viabilidade; 
• Aula 7 – Elicitação; 
• Aula 8 – Validação; 
• Aula 9 – Gerenciamento. 
Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não 
temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema, 
certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os 
sistemas os requisitos mudam.” (Sommerville, 2009). 
Com base nesse cenário, tornar-se necessário então a padronização o procedimento, para ter maior convicção da 
acertabilidade do que está sendo desenvolvido. 
Portanto, caso tenha o desejo em atuar na área de projetos, certamente lhe será requerido conhecer bem sobre as 
atividades inerentes a engenharia de requisitos, no tocante a entender o real problema do seu cliente. Tendo em 
mãos essa importante informação, terás grandes possibilidades de um resultado mais apurado e correto. 
Faça um bom proveito! 
Vamos lá! 
Evolução dos Requisitos 
 
 
E toda alteração em um ambiente aonde os recursos utilizados são alterados, requer uma análise geral dos 
impactos a serem gerados pela alteração a ser aplicada. 
E justamente nesse escopo é que temos as maiores dificuldades. Portanto, o que torna complexo o gerenciamento 
dos requisitos variáveis não se trata especificamente na circunstância que um requisito mudado provocará mais ou 
menos tempo gasto na aplicação no sistema de um atributo novo, mas também que a mudança em um requisito 
propiciará impacto em outros requisitos, gerando uma cadeia de acontecimentos que devem ser avaliados. 
Mudanças de Requisitos 
Uma realidade muito comum também é uma vez que o sistema venha a ser implantado, sua utilização regular 
proporciona levantamento de novos requisitos. Humanamente é difícil que usuários e clientes