E Book

Volte ao Sumário
Navegue entre os capítulos
ENGENHARIA DE
REQUISITOS
1
Didática no Ensino
Volte ao Sumário
BRANDÃO, Daniel dos Santos, 2020 -

Engenharia de Requisitos - Jupiter Press - São Paulo/SP
61 páginas;
Palavras chaves: 1. Engenharia 2. Requisitos 3. Requisito Funcional 4. Requisi-

to não funcional
1
Didática no Ensino
*
Volte ao Sumário
SUMÁRIO
INTRODUÇÃO...................................................................................................................................................3
1. FASES DE CONCEPÇÃO E ELABORAÇÃO.................................................................................4
1.1 FASE DE CONCEPÇÃO..............................................................................................................5
1.2 FASE DE ELABORAÇÃO...........................................................................................................7
s
1.3 LEVANTAMENTO DE REQUISITOS....................................................................................8
1.4 PREPARAÇÃO PARA ELICITAÇÃO DE REQUISITOS...............................................11
2. DISCIPLINAS E TÉCNICAS DE MODELAGEM DE REQUISITOS....................................13
2.1 CONFIRMANDO A ELICITAÇÃO.........................................................................................16
2.2 MODELAGEM DE REQUISITOS..........................................................................................17
2.3 FLUXO DE PROCESSO DE MODELAGEM...................................................................19
3. ESTIMATIVA DE CUSTOS E PRAZOS NA ENGENHARIA DE REQUISITOS..............23
3.1 ESTIMATIVA DE PRAZOS E CRONOGRAMA ..............................................................24
3.2 ESTIMATIVA DE CUSTOS E ORÇAMENTO...................................................................27
4. ANÁLISE E GERENCIAMENTO DE RISCOS...............................................................................29
4.1 APLICAÇÃO DO GERENCIAMENTO DE RISCOS.....................................................30
4.2 PADRÃO DE PROJETO DE SOFTWARE.........................................................................32
4.3 GERENCIAMENTO DE CONFLITOS................................................................................35
4.4 MAIORES RISCOS NO DESENVOLVIMENTO DE SOFTWARE........................36
5. FERRAMENTAS DE ANÁLISE E GERÊNCIA DE REQUISITOS.........................................41
5.1 FERRAMENTAS VISUAIS..........................................................................................................42
5.2 COMPARATIVO DE FERRAMENTAS................................................................................49
6. IMPLEMENTAÇÃO DE RESULTADOS COM O MPS.BR......................................................52
6.1 PADRÃO DE QUALIDADE DE SOFTWARE NO BRASIL.........................................52
6.2 PROCESSOS DE PROJETO....................................................................................................54
CONSIDERAÇÕES FINAIS.........................................................................................................................56
REFERÊNCIAS BIBLIOGRÁFICAS........................................................................................................58
* A navegação deste e-book por meio de botões interativos pode variar de funcionalidade dependendo de cada leitor de PDF.
2
Didática no Ensino
Volte ao Sumário
INTRODUÇÃO
A engenharia de requisitos é uma parte importante ou uma subárea da

engenharia de software. Através dela, os profissionais da área de desenvolvimento
de sistemas podem levantar, descobrir e elencar as diferentes necessidades
dos usuários de uma aplicação em uso ou de um software que ainda precisa ser
desenvolvido. Atender a tais necessidades é a tarefa do engenheiro de requisitos
ou de um engenheiro de software, analista de sistemas e outros perfis que exercem
tal função.
Um requisito se trata da necessidade ou problema apresentado por um cliente

e/ou usuário de uma solução de software. De tais problemas, uma documentação
precisa ser escrita e definida, a partir da aplicação de diferentes técnicas e
metodologias com o intuito de descrever a problemática a ser solucionada com
um novo ou com a melhoria de um produto de software.
Por mais que tenhamos diferentes metodologias e formas de se programar

e criar softwares, a engenharia de requisitos existe como um elo de ligação entre
os usuários finais - requisitantes do software - e a equipe de desenvolvimento,
podendo passar por outros perfis profissionais de dentro de uma organização,
caso a necessidade exija. A partir disso, temos um campo fértil a ser explorado,
com técnicas e ferramentas capazes de aprimorar e até mesmo acelerar a forma
como desenvolvemos softwares, que por diferentes motivos, têm evoluído muitos,
graças à internet e as novas formas de comunicação e tecnologias da informação
como um todo.
A partir disso, espera-se que ao final deste módulo seja capaz de distinguir os
conceitos relacionados a requisitos e ao desenvolvimento de software, passando
por especificações técnicas, metodologias e diferentes formas de se atingir tais
objetivos.

3
Didática no Ensino
Volte ao Sumário
1. FASES DE CONCEPÇÃO E ELABORAÇÃO
Podemos dizer que todo sistema ou software nasce a partir de alguma

necessidade dos usuários. De maneira geral, os problemas ou as “dores” de quem
precisa de um software precisa ser transcrito em algumas definições a fim de que
quem for desenvolver aquele artefato possa realmente tentar compreender em
que contexto a solução deverá se encaixar para o usuário final de software. As
primeiras fases de um projeto de software abrangem as citadas no título deste
tópico: Concepção e Elaboração.
As fases iniciais abrangem o levantamento da tal necessidade do usuário,

entendendo e traduzindo os problemas existentes nos chamados requisitos.
Requisito pode ser definido como a necessidade ou o problema que o usuário ou
cliente possa ter. De acordo com a IEEE e seu dicionário padrão (2017), requisito
é uma condição ou capacidade que deve:
• ser necessária para um usuário resolver um problema ou alcançar um objetivo;

• satisfazer uma especificação em um sistema ou em um componente;
• possuir representação documentada.
Isso nos leva a dizer que requisitos são fundamentais em todo o processo de
software, em todas as etapas de seu projeto de desenvolvimento, como podemos
ver na Figura 1 a seguir.
Figura 1: Fases e Disciplinas de um projeto de software

Fonte: Adaptado de Kruchten (2003)
4
Didática no Ensino
Volte ao Sumário
Dada a Figura 1, podemos observar que entre as fases de um projeto de

software, a de concepção (também chamada de iniciação) é a etapa onde se
concentra o levantamento do problema a ser resolvido, fase essa onde se pode
realizar o levantamento de requisitos à cargo da engenharia de requisitos, uma
subdivisão da engenharia de software específica para estudos relativos a elicitação
dos tais requisitos.
De acordo com Sommerville (2011), o objetivo da Engenharia de Requisitos

é oferecer ao engenheiro de software, métodos, técnicas e ferramentas que
auxiliem o processo de compreensão e registro dos requisitos que o software
deve atender (SOMMERVILLE, 2011).
Percebe-se, então, que se tem na fase de concepção uma maior concentração

das tarefas (ou disciplinas) relativas a regra de negócio e de requisitos, justamente
o momento do projeto onde se tenta entender a partir da visão do usuário o
que se precisa desenvolver. Nesta fase, temos as definições iniciais do projeto
de software, traduzido da linguagem do usuário para a dos desenvolvedores e
profissionais de TI (Tecnologia da Informação), o chamado código-fonte.
A partir disso, um grande salto é dado, chegando à próxima fase, chamada

de Elaboração. Dependendo da metodologia empregada no projeto, essa fase
concentra tanto a documentação inicial, juntamente com a definição e refinamento
dos requisitos, assim como a modelagem inicial e as tarefas de implementação,
que é onde os programadores colocam em prática os conhecimentos teóricos
obtidos no design do software, através do uso de linguagens de programação,
de consultas a banco de dados (como SQL) e as de estilo (CSS) e marcação de
hipertexto (HTML), para sistemas web por exemplo.
1.1 FASE DE CONCEPÇÃO

A gestão de um projeto de software tem sido facilitada ao longo do tempo.
Desde o surgimento dos softwares, por mais complexos que eles tenham se
tornado, podemos dizer que as ferramentas e técnicas presentes nesse processo
tem ajudado os profissionais a tomarem as melhores decisões possíveis em se
tratando de manter ou gerenciar seus projetos.
Mas, mesmo estando em um estado mais evoluído, por que gerenciar projetos
ainda pode ser tão difícil? No dia a dia das empresas de desenvolvimento, ainda
temos visto muitos projetos falharem, e isso é visto com frequência especialmente
no desenvolvimento de software. Algumas destas dificuldades decorrem da
5
Didática no Ensino
Volte ao Sumário
natureza inerente do produto que está sendo criado, já outras estão relacionadas
com a gestão ou o perfil da equipe a ser gerido. Entre o problemas comuns
relacionados a software podemos destacar alguns, como:
• Intangibilidade: O software, ao contrário do hardware, é intangível. Como resulta-

do, o software pode ser tornar mais difícil de gerenciar porque não contém marcos
visíveis para medir progresso e qualidade.
• Complexidade: A grande complexidade de um software torna difícil para as pessoas
compreendê-lo, criando não apenas problemas técnicos, mas também de gestão.
• Volatilidade dos requisitos: Os requisitos de software estão sob constante pressão
por mudança. Isso se dá porque o software pode ser alterado mais facilmente do
que hardware, levando o cliente a requerer mais da entrega final dada a tal flexibili-
dade.
Nisso, o peso sobre o gerenciamento de projetos acaba recaindo sobre

algumas características bastante visíveis mas, por vezes, difíceis de serem
combatidas. Entre as dificuldades relacionadas à gestão, as seguintes são as mais
frequentemente citadas por profissionais e em literaturas sobre gerenciamento
de projetos:
• Metas e especificações mal definidas;

• Falta de plano de projeto;
• Prazos e orçamentos fora da realidade;
Embora alguns projetos falhem por razões técnicas, a maioria das falhas de
projeto são causadas por pessoas que ignoram os princípios da boa gestão de
projetos. Por isso, antes mesmo da fase de concepção ou iniciação ser começada,
é importante saber os princípios da gestão de projetos e como eles podem ser
aplicados ao desenvolvimento de softwares.
Com isso em mente, podemos dizer que o objetivo fundamental da fase

de concepção é determinar a viabilidade do projeto. Nessa fase, os requisitos
precisam ser examinados no contexto do ambiente de negócio, em um processo
onde alternativas são definidas e avaliadas e estimativas de custo, cronograma
e risco são feitas. Essa fase é concluída na decisão de prosseguir ou não com
o projeto. Muitos projetos não avançam além deste estágio pois se mostram
tecnicamente impraticáveis por serem muito arriscados ou por seus custos
projetados superarem seus benefícios ao final do projeto.
Todos esses aspectos são fundamentais, uma vez que o custo ou as condições
de entrega (que incluem prazo e escopo do projeto) podem ser extrapolados
ou entregues de maneira a não atender aos anseios dos stakeholders (partes
6
Didática no Ensino
Volte ao Sumário
envolvidas e interessadas no produto final). Por isso, o levantamento de requisitos

se torna etapa importante no processo, uma vez que a gestão de um projeto só
conseguirá obter sucesso se todas as disciplinas e fases consigam seguir seu
curso natural, levando em consideração possíveis problemas durante o processo,
que podem ser corrigidos durante seu ciclo de vida, desde que se tenha um apoio
de técnicas e metodologias apropriadas desde o início do projeto.
Tendo tudo isso como base, veremos como as etapas precisam ser respeitadas
e cada fase poderá ter suas disciplinas atendidas conforme o ciclo mantém
seu curso. Como forma de aprofundar mais nas etapas iniciais do processo de
desenvolvimento de software, veremos um pouco mais sobre a fase de elaboração
a seguir.
1.2 FASE DE ELABORAÇÃO

Na fase de elaboração (por vezes chamada de fase de planejamento), as
estimativas de desempenho, custo e cronograma são refinadas a um ponto em
que detalha os planos para a execução do projeto e o que pode (e/ou deve) ser
feito. Nesta etapa, orçamentos e cronogramas são desenvolvidos, a equipe do
projeto é formada e um sistema de gerenciamento de projeto é estabelecido para
orientar a gestão do projeto. Dentro das metodologias ágeis, esta etapa pode ser
dividida em ciclos, permitindo que o projeto se desenvolva de maneira cíclica e
iterativa.
Particularmente nessa etapa, a interação com o cliente é bastante importante

para o sucesso do projeto de software. À medida que um número crescente de
novos projetos se torna mais estratégico e envolve reengenharia de processos
de negócios, a gestão de mudanças organizacionais se torna parte integrante
do gerenciamento de projetos. Além da abordagem tradicional de gerência de
projetos que é com foco no controle de custos, cronograma e desempenho
técnico, esta fase se destaca na importância de dois fatores na gestão desses
processos de software: visibilidade e compromisso.
A base para um projeto de desenvolvimento de software bem-sucedido é

um forte planejamento inicial. Muitas falhas de projeto podem ser atribuídas a um
planejamento inicial inadequado. Começar a construir uma casa pensando no
teto é, sem dúvidas, uma falha arquitetural. Por isso, muitas vezes será necessário
que mesmo estando na fase de elaboração, a volta a fase inicial de concepção seja
necessária para que prazos e orçamentos irreais, metas e objetivos mal definidos
e falta de plano de projeto sejam revistas e não sejam a causa para o fracasso do
projeto.
7
Didática no Ensino
Volte ao Sumário
Levando em consideração as fases de Concepção e Elaboração, é nesse

momento em que o ciclo de planejamento começa com o estabelecimento de
metas e objetivos e onde se determina os requisitos para o sistema. Os requisitos
oferecem uma melhor visão direcionada para o projeto, ajudando a definir as
entregas. Uma entrega é um resultado tangível apresentado após a conclusão de
uma dada tarefa.
Assim, podemos dizer que cada entrega realiza uma tarefa para um ou mais
requisitos de sistema. A entrega de uma dessas etapas pode ser via formulários,
um documento, um relatório ou até mesmo um manual ou hardware instalado. É
importante que durante a fase de elaboração as definições estejam claras para que
não ocorram equívocos nas entregas essenciais. Para que erros sejam evitados,
é importante que os requisitos sejam definidos o mais cedo possível. Em muitos
casos, pode ser necessário construir e testar um protótipo para desenvolver uma
boa compreensão do sistema quanto às suas necessidades e requisitos. Um
protótipo é particularmente útil em situações onde o cliente não tem certeza
sobre os requisitos que ele mesmo levantou, em casos de um sistema bastante
complexo.
O quadro a seguir descreve as principais atividades que as fases de concepção

e elaboração estão envolvidas e as ações de gestão adequadas para cada uma.
Concepção Elaboração
Identificar necessidades Preparar planos de trabalho
Estabelecer metas Definir orçamento
Determinar a viabilidade Desenvolver cronograma
Preparar proposta Definir equipe do projeto
Estimar tempo e recursos Construir e testar protótipos
Identificar as pessoas-chave Obter a aprovação para a próxima
fase
Quadro 1 - Características e tarefas das fases de Concepção e Elaboração de Software
1.3 LEVANTAMENTO DE REQUISITOS

Como definido anteriormente, requisitos são a tradução das necessidades ou
problemas levantados junto aos usuários que, em uma documentação, formam as
tarefas e objetivos a serem desenvolvidos no projeto de software. Sem uma boa
definição de requisitos, provavelmente teremos um retrabalho enorme ou não
8
Didática no Ensino
Volte ao Sumário
atingiremos o objetivo proposto de atender a necessidade do usuário.
Sommerville (2011) classifica os requisitos de software como requisitos de

sistema e requisitos de usuário. Os requisitos de sistema seriam os passos que
precisam ser dados no sistema para que ele apresente o resultado desejado. Já o
requisito de usuário seria a definição simples de um problema ou necessidade de
um cliente.
Na prática, esses requisitos são geralmente definidos como requisitos

funcionais (RF) ou requisitos não funcionais (RNF). Os requisitos funcionais
representam os requisitos de usuário, já os não funcionais os de sistema, as
necessidades que um sistema tem para que funcione de maneira correta.
A definição dos requisitos apresenta uma fundamental importância para o
desenvolvimento de software de maneira espontânea e natural, visto que sua
definição de maneira desejável provavelmente diminuirá muito o número de
futuros problemas e retrabalhos, pois fundamentará o entendimento de maneira
clara enquanto o software for sendo desenvolvido. Tanto a documentação de
requisitos funcionais quanto de não funcionais são igualmente instrumentos
à sua própria maneira. Ambos os tipos de requisitos coexistem como forma de
complementarem um ao outro, ou seja, um é diretamente afetado pelo outro.
Mas, mesmo assim, nem todos os requisitos não funcionais (RNF)

correspondem diretamente a um requisito funcional (RF). A instalação e
configuração do servidor, por exemplo, é um requisito não funcional que tem
impacto na estabilidade de todo um sistema, mas sem uma relação direta de 1
para 1 com qualquer requisito funcional singular. Isso acontece pelo fato de um
RNF poder estar ligado ou atender a mais de um RF, como no exemplo citado da
configuração de um servidor.
Para termos os requisitos bem definidos, algumas etapas precisam ser

vistas com cautela, como a de levantamento de requisitos. A importância do
levantamento de requisitos é frequentemente subestimada em vários níveis.
Quando os orçamentos são estreitos, os prazos são apertados e o escopo é cada
vez menor, a documentação dos requisitos tende a ser a primeira entrega a ser
concluída e a última a ser considerada. Isso deveria surpreender, mas acaba
se tornando uma praxe de mercado - bastante danosa, diga-se de passagem
- especialmente quando você considera que ignorar um processo completo
de coleta de requisitos significa sacrificar um ponto de referência sólido para
verificações e balanços em toda a produção de um sistema, colocando em risco
as expectativas do cliente, da equipe e dos usuários finais, deixando muito espaço
9
Didática no Ensino
Volte ao Sumário
para erros e ambiguidades futuras.
À primeira vista, o processo de levantamento e a documentação de requisitos

podem parecer intimidantes, mas não precisa ser. Veremos a seguir algumas
razões em dar importância aos requisitos e ao processo de gerenciamento e coleta
de requisitos, sugerindo algumas técnicas a serem consideradas e abordagens
a fim de descrever a documentação dos requisitos. Veremos que, embora a
documentação de requisitos possa ser complicada, o processo não precisa ser. O
objetivo de uma documentação pautada em regras preestabelecidas é fornecer
aos envolvidos no processo uma abordagem simplificada e intuitiva para definição
de requisitos que resultem em uma documentação que represente a realidade
do que se está desenvolvendo.
Segundo PRESSMAN (2011), o gerenciamento de requisitos é importante

por duas razões principais:
• A documentação dos requisitos serve como um ponto de referência para documen-

tar a evolução de um projeto, suas partes móveis e sua implementação;
• A documentação de requisitos serve como um plano para o cliente entender melhor
o que esperar do projeto (o quê, onde, quando e por que do projeto).
Além de definir o que eles podem esperar, parte do planejamento de

gerenciamento de requisitos deve definir o que não se deve esperar. Incluir uma
seção de suposições e/ou exclusões por parte do cliente é uma abordagem
inteligente para eliminar o risco da temida “imaginação do cliente”. A qualidade
do gerenciamento de requisitos está diretamente relacionada com a habilidade
de gerenciar um projeto, a busca de reduzir áreas nebulosas sobre as expectativas
do cliente.
Na grande maioria das vezes, um cliente será receptivo ao aumento de

escopo desde que isso não aumente também o orçamento demandado. Muitas
vezes será preciso “educar” o cliente de maneira a deixar bem claro sobre por que
um recurso será abordado (ou não abordado) e, em seguida, documentar a lógica
por trás dessa abordagem dentro dos requisitos. Com isso feito, a probabilidade
de aceitação por parte do cliente será maior por ele fazer parte dessa decisão.
Nesse sentido, os stakeholders são mais propensos a fornecer sua aprovação e,
mais adiante, quando estiverem na fase de teste de aceitação do usuário, teremos
vantagens logo de início para que eles entendam o porquê por trás da solução
desenvolvida pela equipe de TI.
10
Didática no Ensino
Volte ao Sumário
Uma descoberta completa dos requisitos de negócios quase nunca está

disponível de maneira tão clara para o analista. Na verdade, raramente os requisitos
podem ser pesquisados rapidamente como se reunissemos informações para
um trabalho de conclusão ou para uma prova avaliativa. Muitos dos requisitos
comerciais ou técnicos acabam por não serem documentados, permanecendo
apenas nas mentes das partes interessadas, no feedback que ainda não foi obtido
dos usuários finais e em um estudo de fluxogramas e pesquisas que ainda não
foram criados. Por isso, os requisitos devem ser eliciados ou elaborados, e a
metodologia para fazer isso deve ser lógica e apropriada a cada caso.
A importância da elicitação não pode ser exagerada, pois ela é a base de

qualquer projeto de requisitos. Conforme Davey et al (2009), erros cometidos
na elicitação têm sido mostrados muitas vezes como as principais causas de falha
ou abandono de sistemas e isso tem um custo muito grande, seja na perda total
ou na despesa de consertar os erros. O estudo adequado e a preparação para a
elicitação podem ajudar muito na prevenção desses tipos de erros.
1.4 PREPARAÇÃO PARA ELICITAÇÃO DE REQUISITOS

O objetivo do levantamento e elicitação de requisitos é identificar
completamente as necessidades, riscos e suposições de negócios associados a
qualquer projeto. Em projetos de software, a definição do modelo de processos
é uma etapa importante, que irá impactar toda a cadeia de acontecimentos, do
início ao fim de todo o ciclo. Modelos de processo de software, com algumas
exceções, todos evoluíram a partir do modelo clássico em cascata, desenvolvido
no final dos anos 1960 e início dos anos 1970.
O uso de um modelo de software processo de desenvolvimento reduz

a complexidade do processo por dividir um projeto em uma série de etapas
básicas. O ponto de terminação para cada etapa é claramente definida por um
conjunto distinto de entregáveis, por exemplo, uma especificação de requisitos
ou módulos de software codificados e testados. Os modelos cíclicos permitem
que a cada fase ou etapa concluída uma nova possa ser iniciada, completando o
ciclo de processos de desenvolvimento.
A elicitação de requisitos é uma etapa importante dentro do desenvolvimento

de uma aplicação. Para sua definição, é necessário que seja feita uma preparação
a fim de absorver os requisitos de maneira correta. A primeira etapa na elicitação
de requisitos é obter uma compreensão abrangente e precisa da regra de negócio
do projeto. Durante o processo de elicitação, o forte entendimento de um analista
da necessidade do negócio ajudará na manutenção de tais requisitos contra o
11
Didática no Ensino
Volte ao Sumário
aumento de escopo e encarecimento do projeto, bem como selecionar as partes

interessadas adequadas e as técnicas de elicitação apropriadas.
A próxima etapa de um analista na elicitação de requisitos é garantir que

uma quantidade adequada e mista de stakeholders sejam garantidas durante
o projeto. Pois, como observa o BABOK 2.0 (IIBA, 2015), um bom analista deve
envolver ativamente as partes interessadas na definição de requisitos. Ainda
de acordo com o BABOK, as partes interessadas de um projeto podem incluir
clientes/usuários finais, fornecedores, o gerente de projeto, analista de qualidade,
reguladores, patrocinadores do projeto, suporte operacional, especialistas no
assunto de domínio e especialistas no assunto de implementação. Um analista
deve recrutar a participação das partes interessadas apropriadas com base nas
necessidades de negócios exclusivas de seu projeto. As técnicas e metodologias
para elicitação de requisitos serão apresentadas a seguir, na próxima seção deste
documento.
12
Didática no Ensino
Volte ao Sumário
2. DISCIPLINAS E TÉCNICAS DE MODELAGEM DE

REQUISITOS
Depois que um analista identificar e recrutar as partes interessadas, a escolha

do método pelo qual se levantará os requisitos é aconselhável para que se abrevie
o tempo para conduzir esses métodos envolvendo as partes interessadas com
a maior antecedência possível para assegurar a participação adequada de suas
partes. Tendo feito isso, o terreno estará pronto para poder ser colocada em
prática a elicitação de requisitos, podendo ser utilizadas técnicas próprias para
tal modalidade. Depois de recrutar as partes interessadas adequadas, um analista
deve determinar as melhores técnicas para elicitar requisitos. Os métodos de
elicitação de requisitos comumente usados, conforme identificado pelo BABOK
(2015), que incluem:
Brainstorming
Esse método é utilizado por diferentes áreas. Na engenharia de requisitos,
um analista deve tentar obter um representante de cada grupo de partes
interessadas participantes na sessão de brainstorming. Um facilitador deve
garantir que, embora os participantes se sintam livres para propor novas ideias
e soluções, permaneçam focados na necessidade de negócios em questão e
não se envolvam em aumento de escopo, enfeitando demais os requisitos ou se
distraiam com outras questões de negócios. Todas as ideias devem ser registradas
para que não sejam perdidas. O método de brainstorming é particularmente útil
se o seu projeto não tiver uma escolha vencedora clara para uma solução, ou se as
soluções propostas existentes forem consideradas inadequadas. O processo de
brainstorming e a análise de acompanhamento resultante ajudarão a garantir que
a melhor solução possível seja alcançada para qualquer objetivo de negócio.
Análise de documentos
A análise de documentos envolve a coleta e revisão de toda a documentação
existente que seja pertinente ao seu objetivo de negócios ou que possa conter
dados relacionados a uma solução relevante. De acordo com o BABOK, essa
documentação pode incluir planos de negócios, estudos de mercado, contratos,
solicitações de propostas, declarações de trabalho, memorandos, diretrizes
existentes, procedimentos, manuais de treinamento, literatura de produtos
concorrentes, análises comparativas de produtos publicadas, relatórios de
problemas, sugestões de clientes, logs e especificações de sistema existentes,
entre outros. Em outras palavras, qualquer coisa escrita relacionada ao projeto
pode ser útil. Este tipo de elicitação é especialmente útil quando o objetivo
13
Didática no Ensino
Volte ao Sumário
é atualizar um sistema existente ou quando a compreensão de um sistema

existente irá aprimorar um novo sistema. No entanto, a análise de documentos
por si só raramente é suficiente para extrair completamente todos os requisitos
de qualquer projeto.
Análise de interface
Visa analisar cuidadosamente a maneira como um usuário interage com um
aplicativo ou como um aplicativo interage com outro. De acordo com o BABOK,
uma análise de interface completa irá descrever o propósito de cada interface
envolvida e extrair detalhes de alto nível sobre ela, incluindo a descrição de seu
conteúdo. Esse tipo de elicitação é essencial para soluções de software que quase
sempre envolvem aplicativos interagindo entre si e/ou usuários interagindo com
aplicativos. Mas, a análise de interface também pode ser útil para soluções que
não sejam de software (como definir entregas de terceiros, por exemplo).
Entrevistas
Entrevistas individuais estão entre os tipos mais populares de elicitação
de requisitos, e por um bom motivo: elas dão ao analista a oportunidade de
discutir em profundidade os pensamentos de uma parte interessada e obter
sua perspectiva sobre a necessidade do negócio e a viabilidade de soluções
potenciais. Independentemente de o analista optar por uma entrevista estruturada
(com perguntas pré definidas) ou não estruturada (com conversas abertas), ele
deve compreender totalmente a necessidade do negócio para conduzir uma
entrevista bem-sucedida. É uma boa prática para um analista compartilhar suas
notas de entrevista com o entrevistado depois para garantir que não houve mal-
entendidos e para movimentar os pensamentos do entrevistado para quaisquer
insights adicionais.
Observação
A observação é bastante útil ao considerar um projeto que mudará ou
aprimorará os processos atuais. De acordo com BABOK, dois tipos básicos de
observação estão disponíveis para um analista: observação passiva (onde o
analista apenas observa alguém trabalhando, mas não interrompe ou engaja
o trabalhador de qualquer forma) e a observação ativa (onde um analista faz
perguntas ao longo do processo para ter certeza de que ela entendeu e até mesmo
experimentou partes do trabalho).
Prototipagem
A prototipagem é especialmente valiosa para as partes interessadas, como
14
Didática no Ensino
Volte ao Sumário
os clientes e usuários finais que podem não compreender todos os aspectos

técnicos dos requisitos, mas se relacionarão melhor com uma representação
visual do produto final. O processo de prototipagem é normalmente iterativo,
melhorando à medida que mais informações e avaliações são coletadas das
partes interessadas. A prototipagem pode ser uma tela interativa (normalmente
consistindo em HTML para aplicações web), um mock-up (simulação de tela
que pode ser feita em slides do PowerPoint), um fluxo de navegação (como um
diagrama do Visio) ou um storyboard. Protótipos simples e descartáveis (como
esboços a lápis) podem ser feitos nos estágios iniciais da descoberta e protótipos
mais detalhados e interativos podem ser feitos assim que os requisitos de
negócios forem identificados. No último estágio de protótipo, mais detalhado, os
recursos do protótipo devem atender às necessidades de negócios previamente
identificadas, conforme descrito nos requisitos.
Workshops de requisitos
O Workshop envolve a reunião de stakeholders previamente identificadas
em um ambiente estruturado por um período de tempo definido, a fim de
eliciar, refinar ou editar requisitos. Para ter sucesso, os workshops de requisitos
devem incluir um gravador (ou alguém que registre em uma ata) para registrar
a entrada dos participantes e um facilitador para direcionar a discussão. Como
os participantes também podem fazer um brainstorm juntos e ouvir a opinião
uns dos outros, eles podem fornecer feedback imediato e refinamentos para
as necessidades de negócios identificadas, o que pode garantir uma elicitação
rápida e eficaz dos requisitos. Essa técnica é empregada na metodologia Design
Sprint, por exemplo.
Pesquisa ou questionário
Embora evitem a oportunidade de conversas pessoais diretas, as pesquisas
são úteis para reunir dados rapidamente de um grande grupo de participantes.
Como softwares de pesquisa online gratuitos estão prontamente disponíveis
(como os Forms de Google e Microsoft, por exemplo), as pesquisas são uma
forma barata de coletar dados objetivos de clientes ou usuários finais em
potencial. Tal como acontece com a seleção de interessados, uma pesquisa ou
questionário bem-sucedido deve ter participantes bem escolhidos. As pesquisas
podem ser estruturadas para oferecer uma série de opções finitas para feedback,
ou podem oferecer informações abertas, dependendo das necessidades do
projeto em questão. Pesquisas abertas são úteis para uma descoberta mais
ampla das necessidades de negócios; no entanto, quanto maior o número de
participantes em pesquisas abertas, mais difícil e demorada será a análise. O texto
da pesquisa deve ser bastante preciso. É uma boa prática para um analista solicitar
educadamente que os participantes da pesquisa respondam dentro de um prazo
15
Didática no Ensino
Volte ao Sumário
razoável e que mantenham qualquer informação comercial proprietária contida

na pesquisa como confidencial.
A natureza do projeto de um analista ditará o nível de detalhe que uma

das técnicas vistas deve abranger. Tal como acontece com as entrevistas, as
observações e análises de uso do usuários (buscando analisar a experiência do
usuário) formam boas práticas para o analista fornecer notas de suas análises
e uma descrição verbal de sua compreensão do trabalho para um revisor, a fim
de se certificar de que não houve mal-entendidos do processo. Como observa
o BABOK, algumas técnicas como a de questionários podem ser úteis quando a
população é grande o suficiente e as questões abordadas são claras o suficiente
para todos os interessados.
Citando diretamente o que o BABOK (2015, p. 38), “As partes interessadas

frequentemente consideram a prototipagem um meio concreto de identificar,
descrever e validar suas necessidades de interface.”. Isso reforça que algumas
técnicas e metodologias são mais focadas no usuário do que na equipe de
desenvolvimento em si. Pois, enquanto a documentação bem definida fica mais
a cargo de explicar aos analistas e programadores, a prototipagem, storyboard
e storytelling acabam por representar de maneira mais clara ao usuário final
(geralmente leigo) como será o produto final, baseado em seus requisitos.
2.1 CONFIRMANDO A ELICITAÇÃO

As necessidades de negócios do projeto de software e a combinação das
partes interessadas determinarão qual ou quais métodos de elicitação citados
anteriormente são os melhores para a necessidade em questão. A elicitação
normalmente não ocorre apenas antes dos requisitos, mas em todo o projeto,
durante a descoberta, a modelagem e até mesmo durante testes.
Sempre que a elicitação ocorre durante o ciclo de vida de um projeto, os

mesmos princípios se aplicam para torná-lo bem-sucedido, com a combinação
correta de partes interessadas, uma compreensão completa da necessidade do
negócio, técnicas de elicitação devidamente selecionadas e atenção meticulosa
aos detalhes.
Uma vez que os métodos de elicitação tenham sido empregados, um analista

deve documentar a elicitação rapidamente, enquanto ela ainda está fresca em
sua mente, compartilhando os resultados com todos os envolvidos de maneira
apropriada, a fim de confirmar sua concordância com as descobertas. Este
16
Didática no Ensino
Volte ao Sumário
estágio é essencial para garantir que o analista entendeu com precisão e as partes
interessadas comunicaram com precisão as necessidades do projeto. A elicitação
serve, então, como pesquisa básica para a fase de criação de requisitos. Assim
que o analista tiver material suficiente, ele pode começar a elaborar os requisitos.
A análise pode ser apoiada na modelagem de negócio para melhor compreensão
do alvo a ser atingido.
A modelagem de negócio é uma das formas de estabelecer disciplinas que

realizam o mapeamento das regras de negócio. Os objetivos da modelagem de
negócios são:
• Entender a estrutura e a dinâmica da organização na qual um sistema será implanta-

do (a organização-alvo).
• Entender os problemas atuais na organização alvo e identificar potenciais de melho-
ria.
• Garantir que clientes, usuários finais e desenvolvedores tenham um entendimento
comum da organização de destino.
• Derivar os requisitos de sistema necessários para oferecer suporte à organização de
destino.
A modelagem de negócios é parte integrante do RUP (Rational Unified

Process). A disciplina de modelagem de negócios RUP consiste em fornecer uma
visão das estruturas e processos de negócios da organização em relação a um
projeto específico, identificando o escopo apropriado do projeto e mostrando
como o sistema se encaixa e suporta o negócio. Isso é extremamente importante
para um projeto, mas não é suficiente para a empresa; a disciplina de modelagem
de negócios abrange as mesmas atividades que a disciplina de modelagem de
requisitos, mas em nível corporativo.
2.2 MODELAGEM DE REQUISITOS

O produto derivado do RUP descreve a necessidade de modelar no
nível corporativo, mas como não há nenhum mecanismo dentro do RUP para
representar os problemas entre os sistemas de forma adequada, ele não faz jus
ao conceito nem fornece uma maneira explícita de compartilhar informações
entre projetos. Por isso, o RUP se torna mais completo ao juntarmos ele a outras
disciplinas e processos. Para atingir seus objetivos, a disciplina de modelagem
de negócios descreve como desenvolver uma visão da organização de destino
e, com base nessa visão, definir os processos, funções e responsabilidades dessa
organização em um modelo de caso de uso de negócios e um modelo de objeto
de negócios.
17
Didática no Ensino
Volte ao Sumário
Complementarmente a esses modelos, alguns artefatos podem ser

desenvolvidos, como a especificação complementar de negócios e um glossário,
que possa traduzir os termos levantados e elicitados a fim de que os requisitos
possam refletir fielmente o que se pretende ter ao final do ciclo de vida do projeto.
Os esforços de modelagem de negócios de uma empresa devem explorar uma
ampla gama de questões. Como resultado, o modelo de negócios corporativo é,
na verdade, composto de uma coleção de artefatos menores conforme o quadro a
seguir nos apresenta. Os problemas de negócios que a serem explorados incluem
os seguintes artefatos:
Artefato Descrição
Especificação de regras de Definição das restrições que influenciam ou orientam o funcionamento diário de um
negócios negócio ou organização.
Modelo de processo de ne- Captura os processos de negócios fundamentais, as entidades externas (clientes,
gócios fornecedores, parceiros ou concorrentes) e os principais fluxos de trabalho entre
eles.
Modelo de domínio de ne- Descreve as principais entidades de interesse para uma organização e seus relacio-
gócio namentos.
Declaração de missão Uma declaração das estratégias a serem seguidas para alcançar a visão de negócio.
Visão de negócio Uma declaração das metas principais de uma organização.
Modelo de organização Uma definição da localização, posições, unidades organizacionais e seus inter-rela-
cionamentos dentro de uma empresa.
Quadro 2 - Artefatos relativos a problemas de negócios

O desenvolvimento do documento de modelagem de negócios de uma

organização começa com uma visão ampla de todo o negócio. Isso não significa
que você modelará todos os processos do negócio, pois, alguns aspectos serão
ignorados, dando ênfase aquilo que tem a ver com o problema a ser resolvido
com o software a ser desenvolvido. Significa dizer que seu modelo irá além do
escopo de um único projeto.
O objetivo aqui é capturar os fundamentos do negócio, trabalhando com

os stakeholders em um modelo abrangente, mas superficial - sem detalhes que
não competem saber ou estejam fora do escopo do problema a ser resolvido. É
precisa identificar e priorizar áreas de importância para que possam ser exploradas
em detalhes pelos esforços de modelagem de negócios de equipes de projeto
individuais.
As regras de negócio de uma empresa devem definir uma visão geral precisa
e de alto nível do negócio e deve conter informações que sejam relativamente
estáveis ao longo do tempo. Por exemplo, dentro de um banco, a necessidade de
18
Didática no Ensino
Volte ao Sumário
processar transações bancárias de varejo existe há séculos, mas a maneira como

isso ocorre mudou drasticamente ao longo do tempo - a necessidade de alto nível
é estável, enquanto os detalhes são muito fluidos.
2.3 FLUXO DE PROCESSO DE MODELAGEM

Devido aos passos necessários para obter requisitos maduros, diversas
disciplinas e técnicas podem ser empregadas, como vimos anteriormente. O
fluxo de processo de modelagem se trata de descrever os passos a serem dados,
de maneira lógica, como uma sugestão sequencial de etapas a serem cumpridas
com o objetivo de se chegar aos requisitos refinados.
Para se obter um projeto de sucesso, nunca é muito cedo para começar a

reunir e documentar os requisitos do projeto. Na verdade, quanto mais cedo
melhor. A seguir, estão as etapas sobre como reunir requisitos, conduzindo você
por um processo completo de coleta de requisitos. Essas etapas auxiliam a finalizar
a documentação de requisitos por meio da colaboração da equipe, verificações
e balanços e educação do cliente. O fluxo sugerido está apresentado na Figura 3.
Figura 2 - Fluxo de processos de modelagem de requisitos

Fonte: Elaborada pelo autor
As etapas descritas no fluxo da Figura 2 são exemplos de um passo a passo

a ser dados a fim de se obter ao final o documento de requisitos que atendam
as demandas internas e externas entre as equipes de desenvolvimento e os
stakeholders. Para melhor entendimento, vamos descrever cada uma das etapas
e suas tarefas e objetivos envolvidos.
Tome Nota
Em cada reunião em que se fizer, seja interna com sua equipe de projeto ou
externa com seu cliente, é essencial que se faça anotações. Gerentes de projetos
19
Didática no Ensino
Volte ao Sumário
precisam se concentrar no andamento do projeto, logo, é importante que todos

façam suas anotações mas que também haja alguém responsável por fazer uma
anotação “oficial”, com a perspectiva de capturar itens de ação, necessidades
de esclarecimento, oportunidades para pesquisas ou discussões adicionais e
quaisquer outras informações importantes discutidas nas reuniões. Na hora da
reunião, pode parecer que todos lembrarão do que foi falado. Mas, confiar apenas
na memória não é uma boa prática profissional.
Revise os requisitos criados

Fornecer requisitos criados desde as primeiras reuniões sempre que possível
deve estar no cronograma e orçamento do projeto. A orientação criativa é
inestimável para os desenvolvedores. O ideal é que se tenha wireframes e designs
de interface de usuário completos para dispositivos móveis e desktops criados por
algum aplicativo próprio para isso, a fim de irmos modelando requisitos conforme
o ciclo continua.
Depois de reunir tais designs, é importante compartilhar com todos os

envolvidos os modelos criados. Certifique-se de salvar as versões finais desses
designs em um só lugar, separado de quaisquer versões anteriores, para que
sua equipe tenha absoluta certeza de que estão fazendo referência aos ativos
finais do criativo. O versionamento de documentos nasce antes mesmo de se ter
versionamento de código.
Faça anotações
Depois de entregar os resultados desde as primeiras reuniões até a revisão
de requisitos, é importante continuar anotando os elementos que vão surgindo.
Anote os insights mesmo enquanto ainda são ideias hipotéticas. Cada elemento
requer uma anotação. Use uma ferramenta como Invision ou Skitch para fazer
anotações nos designs de tela, por exemplo.
Normalmente, se começa anotando as ideias, partindo das anotações feitas

em cada reunião. Mas, pensando que se quer chegar a uma documentação
completa, é benéfico manter a mentalidade de “primeiras ideias” em mente ao
produzir uma solução. Dito isso, é preciso elaborar as versões das anotações, com
data e nome dos envolvidos em cada parte desses processos. Isso servirá como
um histórico ou log do que acontece ao longo do projeto.
Escreva o documento de requisitos

Ao mergulhar na documentação, é bom lembrar que a primeira tentativa
20
Didática no Ensino
Volte ao Sumário
na documentação de requisitos é sempre a mais difícil. Isso geralmente é uma

verdade, pois quando não se tem um documento anterior para aproveitar, a
criação do zero requer dedicação por parte do analista. Como auxílio, existem
modelos de documentação de requisitos que servem como base para um projeto
de software.
Faça uma entrevista interna
Depois de concluir o primeiro rascunho da documentação de requisitos, é

importante que novas revisões aconteçam. A realização de uma entrevista ou
bate papo interno a fim de rever o que já se tem levantado de requisitos pode ser
fundamental. Nesta parte do processo de coleta de requisitos, deve-se agendar
outra reunião interna com sua equipe de projeto para revisar a documentação de
seus requisitos todos juntos.
Esta é uma verificação e equilíbrio internos finais para garantir sua

compreensão da implementação. Se possível, pede-se à equipe que analise a
documentação de seus requisitos antes da reunião para que eles possam estar
prontos com suas perguntas e feedback. Em entrevistas internas, identifica-
se lacunas no entendimento e verifique a consistência da documentação de
requisitos.
Como parte da fase de revisão interna, é preciso fazer as revisões necessárias

na documentação, com base em discussões internas. Por fim, a documentação
de requisitos revisada poderá ser passada a equipe e stakeholders para uma visão
final e aprovação.
Criar tarefas
Agora que temos um documento de requisitos elaborado e revisado, é hora de
passar a documentação de requisitos para sua equipe de desenvolvimento. O ideal
é que os desenvolvedores ou o líder de desenvolvimento executem a construção
de tarefas para passarmos a fase de construção. Embora algumas organizações
possam operar sob um processo em que os gerentes de projeto criem todas as
tarefas, algumas metodologias apontam que os próprios desenvolvedores criem
suas próprias tarefas. Isso permite que os desenvolvedores criem tarefas de uma
forma que se adapte à sua abordagem de desenvolvimento, mais fáceis de serem
colocadas em ação.
21
Didática no Ensino
Volte ao Sumário
As seis etapas citadas são exemplos de aplicação prática da modelagem de

requisitos, passando por etapas de reuniões, entrevistas e acompanhamento de
cada um dos passos necessários para a elicitação de requisitos no contexto de um
projeto de software.
22
Didática no Ensino
Volte ao Sumário
3. ESTIMATIVA DE CUSTOS E PRAZOS NA ENGENHARIA

DE REQUISITOS
A engenharia de requisitos tem por base para todas as atividades de

planejamento a Estrutura Analítica do Projeto (EAP). Ela decompõe o projeto
hierarquicamente em estruturas bem definidas, tarefas ou atividades gerenciáveis.
Uma EAP pode ter a forma de uma tabela ou de um diagrama. O número de
níveis de detalhe depende principalmente do tamanho do projeto e preferências
pessoais do gerente de projeto ou da organização.
Por isso, é importante que todas as atividades necessárias para concluir o

projeto sejam incluídas na EAP e atribuídas a um indivíduo ou uma organização
específica de forma inequívoca. A EAP fornece a estrutura fundamental para
programação, orçamento e controle de projetos. Uma vez que a EAP foi definida,
a estimativa do processo pode começar. O exemplo de diagrama da Figura 3
mostra os relacionamentos hierárquicos entre as várias tarefas de um projeto.
Figura 3 - Estrutura Analítica do Projeto

Fonte: Elaborada pelo autor (2020).
Dentro de um fluxo de projeto de software, o primeiro passo ideal é estimar o

tamanho do software a ser desenvolvido. A qualidade dessa estimativa influencia
diretamente as estimativas de custo e cronograma. Isto é também a parte mais
difícil do processo de estimativa, visto que muitas vezes é mal feito, evidenciando
muitos estouros de custo e atrasos no cronograma do projeto.
Existem métricas de tamanho do produto que são comumente usadas em

projetos de software, as mais comuns são as de linhas de código (LOC) e pontos
de função (PF). A abordagem de linhas de código requer uma estimativa do
número de linhas de código-fonte, normalmente estimado por analogia com
projetos anteriores semelhantes. A análise de pontos de função, por outro lado,
23
Didática no Ensino
Volte ao Sumário
não requer conhecimento prévio de código fonte. Ele é baseado em uma medida
sintética de funcionalidade de acordo com as regras de negócio. O número de
PF é determinado a partir de uma soma ponderada de entradas, saídas, consultas,
arquivos e interfaces com outros programas.
O ponto de função bruto é a contagem ajustada para a complexidade

técnica e fatores ambientais para chegar a uma estimativa final do ponto de
função. Os pontos de função levam a estimativas razoavelmente confiáveis e são
independentes de linguagens de programação. Sua análise pode ser feita quase
totalmente automatizada com o uso de ferramentas de estimativa de software
comercial que suportam análise de pontos de função.
Existem outras métricas, como a por Pontos por Casos de Uso (PCU) que tem
o objetivo de medir recursos de projetos de software de acordo com a quantidade
e complexidades de casos de uso. Essa métrica é geralmente empregada quando
se trabalha sob o paradigma orientado a objetos (OO).
3.1 ESTIMATIVA DE PRAZOS E CRONOGRAMA

Existem duas abordagens fundamentais para o custo e cronograma do
projeto de software: de cima para baixo (top-down) e de baixo para cima (bottom-
up). A abordagem de cima para baixo tenta estimar o custo total do projeto e
cronograma, normalmente usando software automatizado com modelos de
estimativa de custos. Este processo consiste em converter a medida de tamanho
para esforço em termos de pessoal/mês e duração do projeto em quantidade de
dias ou meses.
Embora vários algoritmos e regras básicas estejam disponíveis, todas as

estimativas precisam ser ajustadas à produtividade organizacional e outros
fatores que influenciam na produtividade. A estimativa geral do tamanho é então
usada para alocar o esforço em tarefas específicas e atividades a fim de programar
marcos de entregas de cada atividade.
Já a abordagem de baixo para cima começa com a estimativa das

necessidades das pessoas e um cronograma para as tarefas mais baixas,
agregando-as a estimativas de nível superior. Em um comparativo, a abordagem
de cima para baixo leva a estimativas superiores, enquanto a abordagem de baixo
para cima tende a incutir propriedade e compromisso com o plano em todos os
níveis da equipe do projeto (DAVEY et al, 2008).
24
Didática no Ensino
Volte ao Sumário
Para obter o melhor de ambos os métodos, muitas empresas usam as duas

abordagens em conjunto de forma iterativa. A abordagem de cima para baixo
é usada para definir diretrizes para o projeto como um todo, enquanto uma
abordagem de baixo para cima é usada para desenvolver estimativas detalhadas
de custo e cronograma dentro das restrições estabelecidas pela abordagem
de cima para baixo. Este método requer vários ciclos de estimativas antes de
convergir para uma estimativa satisfatória.
Ferramentas comerciais de estimativa de software produzem cronogramas

nominais alcançáveis por uma equipe eficiente trabalhando em boas condições.
Muitas ferramentas também fornecem recursos para fazer compensações de
custo e cronograma. Como exemplo, o horário pode ser reduzido adicionando
mais membros a uma equipe, mas ao contrário de outros tipos de projetos,
o desenvolvimento de software não permite compressão significativa de
cronograma. De acordo com pesquisa publicada por Buratti (2014), praticamente
todos os esforços para comprimir a programação em mais do que 25% do nominal
não são bem-sucedidos.
Um bom cronograma é bastante desafiador, mas deve ser razoável, alcançável

e deve ter o comprometimento de toda a equipe do projeto. O melhor caminho para
obter compromisso em uma equipe é ter cada tarefa estimada pelos indivíduos ou
grupos responsáveis por completá-lo, como vimos no tópico 2. O cronograma para
grandes projetos geralmente é dividido em um cronograma mestre, mostrando
apenas atividades e marcos principais, apoiando programações de nível inferior
para atividades detalhadas.
A forma mais comum de apresentar informações de cronograma é o gráfico

de Gantt. Ele retrata as atividades em uma escala de tempo horizontal. Os gráficos
de Gantt são populares porque são bem compreendidos e fáceis de se criar e rever.
No entanto, eles não são adequados para mostrar as inter-relações entre as várias
tarefas (que tarefa deve ser concluída antes de outra começar, por exemplo). A
Figura 4 a seguir representa um gráfico de Gantt para um cronograma entre os
meses de janeiro a junho.
25
Didática no Ensino
Volte ao Sumário
Figura 4 - Gráfico de Gantt

Fonte: Elaborado pelo Autor (2020).
Uma análise de rede do cronograma ou diagrama de rede é uma

representação gráfica de um cronograma mostrando cada atividade em
sequência e o tempo que leva para terminar cada uma. É usado para identificar
datas de início antecipadas e atrasadas, bem como datas de término antecipadas
e atrasadas, para as partes incompletas das atividades do cronograma do
projeto. Essa análise também ajuda a determinar o caminho crítico, a análise
de variações hipotéticas e a compactação do cronograma. Um cronograma
através do diagrama de rede é a ferramenta apropriada para mostrar tais inter
relações.
A análise de rede do cronograma mais comumente usada são PERT (Program

Evaluation and Review Technique ou Programa de Avaliação e Revisão) e CPM
(Critical Path Method ou Método do Caminho Crítico). Ambos os métodos são
bastante semelhantes no uso de fluxo gráficos para mostrar as inter-relações entre
as tarefas. O PERT trabalha com três perspectivas: otimista, pessimista e mais
provável. Por sua vez, o CPM foca na avaliação do caminho crítico do processo.
A Figura 5 nos mostra a ideia de um diagrama de rede que representa tarefas e o
tempo estimado para seu desenvolvimento.
Figura 5 - Exemplo de um diagrama de rede

26
Didática no Ensino
Volte ao Sumário
Uma vantagem do diagrama de rede e do gráfico de Gantt é que eles

podem ser usados para identificar e rastrear o caminho crítico de um projeto.
O caminho crítico é o conjunto de atividades ao longo do caminho que levam
mais tempo para serem concluídas (linhas mais espessas). Em geral, o caminho
crítico determina quando o projeto estará realmente completado. As tarefas no
caminho crítico requerem gerenciamento especial atenção porque qualquer
atraso de cronograma nessas tarefas leva a um correspondente atraso em todo o
cronograma, o que impactará na data de conclusão do projeto.
Deve-se notar que um projeto pode ter vários caminhos críticos e que
as variações na duração das tarefas podem mudar um caminho crítico de um
conjunto de atividades para outro. O caminho crítico também é útil para identificar
riscos graves de programação. É comum que ferramentas mais completas de
gerenciamento de software incluam os meios de se criar e exibir ambas as formas
de se apresentar os cronogramas, tanto o diagrama de redes como o gráfico de
Gantt.
3.2 ESTIMATIVA DE CUSTOS E ORÇAMENTO

As tarefas principais de estimativa são focadas em determinar e medir custos
e orçamento. Os custos do projeto de software são gerados principalmente pelos
custos de pessoal. O número de horas de trabalho pode ser derivado diretamente
das estimativas de tamanho do projeto com a ajuda de ferramentas de estimativa
automatizadas ou usando o próprio banco de dados histórico da empresa.
Em todo caso, as estimativas devem ser ajustadas para corresponder às

capacidades e experiência da equipe, além dos níveis de habilidade. A estimativa
também deve cobrir todas as atividades que são identificadas na estrutura analítica
do projeto (EAP), incluindo gerenciamento de projetos e todas as funções de
suporte, como garantia de qualidade.
Além dos custos diretos de mão de obra, a estimativa pode incluir todos os
custos diretos não trabalhistas e custos diretos ou indiretos. Os custos de mão de
obra direta são determinados multiplicando as horas de trabalho por taxas de mão
de obra apropriadas para cada item da EAP. Custos diretos não laborais são todos
os outros encargos aplicados ao projeto, incluindo tarefas que são terceirizadas,
consultores, viagens e custos de material.
O orçamento total do projeto é determinado pela agregação de todos os

custos indiretos. É uma boa prática incluir alguma reserva de gestão para possíveis
27
Didática no Ensino
Volte ao Sumário
problemas e imprevistos por contingência. Uma reserva de 5 a 10 por cento não

é incomum e pode ser ainda maior para projetos de alto risco. O orçamento (com
os fundos de contingência removidos) é destinado a organizações ou indivíduos
designados ao projeto de acordo com a EAP.
O orçamento se torna a linha de base para controle do projeto, fornecendo

padrões contra os quais o desempenho do projeto pode ser medido. Uma
ferramenta útil para gerentes de projeto é um custo cumulativo baseado na
curva de tempo x custo, às vezes chamada de curva S. Ela fornece visibilidade ao
representar o orçamento graficamente em função do tempo de acordo com os
cronogramas do projeto, como visto na Figura 6 a seguir:
Figura 6 - Curva de custo acumulado ou curva S

Ao longo do diagrama, podemos perceber que a estimativa de custo pode

ir evoluindo e se tornando uma curva em formato de S conforme os custos e o
tempo vão avançando. É natural que o custo acabe se elevando caso o projeto
se torne demorado em demasia para chegar a entrega final. Com isso, uma
progressão do custo sofre acréscimos, visto que geralmente um profissional de
desenvolvimento de software tem seu pagamento estimado por sua habilidade
ou função no projeto por hora trabalhada.
28
Didática no Ensino
Volte ao Sumário
4. ANÁLISE E GERENCIAMENTO DE RISCOS
A gestão de riscos é uma parte importante da gestão de projetos de software.

Na fase de planejamento ou de elaboração, o gerente de projeto precisa realizar
uma análise realista de avaliação dos riscos e desenvolver um plano de controle
de tais riscos levantados.
De acordo com Buratti (2014), os três principais fatores que influenciam o

risco do projeto são:
• Tamanho do projeto;
• Estrutura do projeto;
• Experiência com tecnologia.
Percebe-se que, quanto maior o projeto, menos estruturado ele tende a ser
(ou seja, os requisitos não estão bem definidos e é provável que mude durante
o projeto). E, no geral, quanto menor a experiência da equipe com a tecnologia
do projeto, maior o risco de encontrarmos problemas. Buratti (2014) ainda
recomenda uma abordagem de contingência ao adotar uma estratégia apropriada
de gestão de projeto para cada tipo de risco. Um conjunto de ferramentas de
gestão está disponível para implementar cada estratégia, que inclui ferramentas
de integração externas, ferramentas de integração interna e ferramentas formais
de planejamento e controle.
Projetos com relativamente ou pouca estrutura podem se beneficiar de

ferramentas de integração externa que criam ligações eficazes entre a equipe do
projeto e o cliente da organização. Tais ferramentas devem incluir as tarefas de:
• Selecionar o gerente de projeto e os principais membros da equipe do cliente orga-

nização;
• Representação frequente do cliente nas reuniões de revisão do projeto;
• Ampla distribuição de relatórios de status na organização do cliente.
Para um bom acompanhamento pelas partes envolvidas, é fundamental que

todo processo seja exposto de maneira clara e franca. Problemas observados
antes de acontecerem diminuem consideravelmente o risco de um projeto.
Projetos envolvendo novas tecnologias devem contar mais com ferramentas de
integração interna que são projetadas para aprimorar a competência técnica da
equipe e operação como uma unidade integrada. As ferramentas de integração
29
Didática no Ensino
Volte ao Sumário
interna típicas incluem:
• Membros de equipe altamente experientes;

• Gerente de projeto com forte gestão técnica e de projeto fundo;
A contingência para gerenciamento de riscos aborda a forma como os riscos

podem ser categorizados e assim analisados em 3 vertentes. Existem três eixos
em que a abordagem de contingência de gerenciamento de risco se apoia:
Estrutura, Tamanho e Tecnologia. A Figura 7 a seguir apresenta uma abordagem
de contingência para gerenciamento de risco.
Figura 7 - Abordagem de Contingência para Gerenciamento de Riscos

Fonte: Elaborado pelo autor
Como apresentado na Figura 7, a estrutura se apoia em ferramentas de

integração externa, como em servidores de dados e recursos necessários para um
sistema funcionar. O eixo tecnologia é firmado com ferramentas de integração
interna, sendo muito importante como forma de se chegar a soluções através
de softwares a serem desenvolvidos. O eixo tamanho tem a ver com o escopo
ou limites do tamanho do projeto em si e leva em consideração ferramentas de
planejamento e controle, a fim de equilibrar tanto a estrutura como as tecnologias
empregadas no projeto.
4.1 APLICAÇÃO DO GERENCIAMENTO DE RISCOS

Projetos envolvendo novas tecnologias devem contar bastante com
ferramentas de integração interna que são projetadas para aprimorar a
competência técnica da equipe e operação como uma unidade integrada. As
ferramentas de integração interna típicas incluem:
30
Didática no Ensino
Volte ao Sumário
• Membros de equipe altamente experientes;

• Gerente de projeto com forte e profunda gestão técnica de projetos;
• Reuniões frequentes de status da equipe
Grandes projetos, principalmente aqueles com uma alta estrutura, devem

ser gerenciados por ferramentas formais de planejamento e controle. Essas
ferramentas, descritas com mais detalhes a seguir, representam uma abordagem
altamente disciplinada e sistemática para o projeto planejamento e controle. Eles
incluem cronogramas formais, orçamentos e procedimentos de rastreamento
para controle de gestão.
Embora a escolha da abordagem de gestão adequada para lidar com risco

do projeto em alto nível é importante, uma avaliação de risco mais detalhada é
necessária para lidar com riscos potenciais específicos. A avaliação de risco inclui:
• Identificação de risco;
• Análise de risco;
• Priorização de riscos;
O objetivo da identificação de risco é desenvolver uma lista de riscos que

podem gerar impacto no resultado do projeto. A análise de risco consiste em
avaliar a exposição ao risco, a probabilidade e o impacto de cada risco. A priorização
de riscos produz uma lista de riscos priorizando-os por impacto que eles possam
ocasionar, se tornando a base para o planejamento do gerenciamento de risco.
Um bom plano deve abordar todos os principais riscos, identificar planos de
contingência para lidar com eles e definir o processo de monitoramento dos
riscos.
No Brasil, existe um modelo de qualidade de software que visa a busca

constante da melhoria na qualidade de processos de software, chamado de
MPS.BR (Melhoria do Processo de Software Brasileiro). Proposto pela Softex
(Associação para Promoção da Excelência do Software Brasileiro), que possui
sede em Brasília mas mantém escritórios regionais a fim de dar apoio e formar
uma comunidade onde todos os agentes envolvidos em software no Brasil
possam ajudar a fomentar boas práticas no desenvolvimento de sistemas. Nisso,
as questões de qualidade e de gerenciamento de risco estão incluídas.
Em seu guia de implementação, a seção 7 (sete) aborda a Gerência de

Riscos, também chamada de GRI. Segundo o MPS.BR, a gerência de riscos tem
31
Didática no Ensino
Volte ao Sumário
por finalidade analisar, tratar, identificar e monitorar os riscos tanto no âmbito da

organização como do projeto de software (MPS.BR, 2013). Além desta organização
brasileira, a nível internacional temos a IEEE que estabelece através do padrão
1540 seu processo para gerenciamento de riscos. A ISO/IEC possui seu padrão
12207 com o mesmo objetivo, definindo um subprocesso para gerência de riscos.
O PMBOK (Project Management Body of Knowledge), projeto que funciona
como um manual ou padrão de boas práticas na gestão de projetos, também
apresenta sua seção exclusiva para lidar com gerenciamento de riscos, tendo 6
(seis) subprocessos associados.
Uma forma útil para monitoramento de risco é uma lista com os principais
riscos que deve ser mantida e atualizada com frequência para identificar sempre
os maiores riscos por ordem de prioridade. Isso pode (e deve) ser feito com um
plano de gestão de software compatíveis com a necessidade de cada projeto,
cuja importância veremos no próximo tópico.
4.2 PADRÃO DE PROJETO DE SOFTWARE

O planejamento do projeto culmina em um plano de projeto de software. Esse
plano deve levar em consideração, além de aspectos como requisitos, escopo
do projeto e toda parte de projeto, aspectos técnicos e gerenciais, também a
gestão de riscos. Este é um documento que descreve a abordagem geral para
o desenvolvimento de software, especifica todas as entregas, requisitos de
recursos, cronogramas, orçamentos e organização responsabilidades e define os
processos de gestão.
Além disso, o plano descreve todos os fatores de risco e estratégias de gestão

de risco, descrevendo como as mudanças são gerenciadas e a qualidade deve ser
garantida. É um documento que deixa clara a situação do projeto para a gestão,
membros da equipe e os stakeholders escolhidos por parte do cliente. É como
um roteiro que serve para guiar os membros da equipe do projeto.
Ele estabelece o custo e a linha de base do cronograma para gerenciar e

controlar o projeto. Portanto, torna-se uma parte efetiva do sistema de controle de
projeto. E, para testar a adequação de um plano de projeto, o gerente de projeto
deve se perguntar:
• O plano me permite gerenciar o projeto com eficácia?

• Fornece informações suficientes para os membros da equipe planejar e fazer o tra-
balho deles?
• Tem o comprometimento da alta administração e da equipe?
32
Didática no Ensino
Volte ao Sumário
O gerente de projeto (GP) geralmente é selecionado no final da fase

conceitual, fase em que o projeto já está aprovado. O gerente de projeto é a
pessoa responsável pela gestão de todo o projeto. Sua principal responsabilidade
é dirigir e coordenar todas as atividades para cumprir os objetivos do projeto
dentro orçamento e cronograma. Esta função é bastante diferente da função
do técnico líder ou desenvolvedor, cuja responsabilidade é principalmente pela
integridade técnica do produto.
Gerenciar um projeto é um grande desafio. O perfil deste tipo de gerente

requer que seja uma pessoa bastante organizada, de preferência apaixonada e
orientada a objetivos. O GP precisa entender o que os projetos têm em comum e
saber bem oseu papel estratégico na forma como as organizações podem obter
o sucesso. As responsabilidades específicas do gerente de projeto incluem o
seguinte:
• Reportando-se à alta administração

• Comunicação com usuários
• Planejamento e programação
• Coordenar as atividades do projeto
• Orçamento, cronograma, risco e controle de qualidade
• Gestão de Pessoas
• Entregando Resultados
De acordo com o PMI (online) - Project Management Institute - instituto

internacional que tem por objetivo equalizar as normas e boas práticas em
gerenciamento de projetos, os gerentes de projeto são agentes de mudança.
São eles quem definem os objetivos do projeto e usam suas habilidades e
conhecimentos para inspirar um senso de propósito compartilhado na equipe do
projeto. Funcionam bem sob pressão e se sentem confortáveis com mudanças e
complexidade em ambientes dinâmicos.
Eles podem alternar prontamente entre o quadro geral de tarefas e os

detalhes pequenos, mas cruciais, sabendo quando se concentrar em cada
um. Os gerentes de projeto cultivam as habilidades pessoais necessárias para
desenvolver confiança e comunicação entre todas as partes interessadas do
projeto: os stakeholders e aqueles que farão uso dos resultados do projeto, assim
como aqueles que comandam os recursos necessários e os membros da equipe
do projeto.
O gerenciamento de projetos pressupõe o uso de um conjunto de

ferramentas amplo e flexível, de técnicas que resolvem atividades complexas e
33
Didática no Ensino
Volte ao Sumário
interdependentes em tarefas e subtarefas que são documentadas, monitoradas

e controladas. A partir do uso de instrumentos próprios de gestão, adaptam
a abordagem de metodologias ao contexto e às restrições de cada projeto,
sabendo que não existe um tamanho único para todo e qualquer tipo de projeto,
principalmente na área de software.
O uso correto do gerenciamento de projeto pode atender a toda variedade

de projetos, permitindo com que gerentes e profissionais que trabalham nos
projetos estejam sempre melhorando suas próprias habilidades e as das equipes
por meio de análises de lições aprendidas na conclusão de cada projeto.
A gestão de risco é o processo de identificação, avaliação e controle de

ameaças ao capital e lucros de uma organização. Essas ameaças ou riscos podem
ter origem em uma ampla variedade de fontes, incluindo incerteza financeira,
responsabilidades legais, erros de gestão estratégica, acidentes e desastres
naturais. Ameaças à segurança de TI, riscos relacionados a dados e as estratégias
de gerenciamento de risco para aliviá-los, tornaram-se uma das principais
prioridades das empresas digitalizadas nos tempos modernos.
Como resultado, um plano de gerenciamento de risco inclui cada vez mais

os processos das empresas para identificar e controlar ameaças aos seus ativos
digitais, incluindo dados corporativos proprietários, informações de identificação
pessoal de um cliente e propriedade intelectual. Em tempos de LGPD (Lei Geral
de Proteção de Dados) e seus equivalentes internacionais, todo cuidado é pouco
e é de extrema importância que coordenadores, diretores e gestores de um modo
geral tomem cuidados extremos quanto à segurança e os riscos a qual seu projeto
de software poderá estar envolvido.
Todas as empresas e organizações enfrentam o risco de eventos inesperados

e prejudiciais que podem custar dinheiro à empresa ou fazer com que ela feche
permanentemente. O gerenciamento de riscos permite que as organizações
tentem se preparar para o inesperado, minimizando os riscos e custos extras antes
que eles aconteçam.
Para que tenhamos êxito, um plano de projeto de software precisa estar bem
alicerçado em seções e tópicos que esclareçam os aspectos organizacionais de
um projeto. Um plano típico é descrito pela IEEE , no seu documento chamado
em português de Plano Padrão IEEE para Projeto de Software (IEEE Standard for
Software Project Management Plans, 1987), apresentado em português conforme
34
Didática no Ensino
Volte ao Sumário
o quadro a seguir:
1. Introdução
1.1 Visão Geral do Projeto
1.2 Entregáveis do Projeto
1.3 Evolução do Plano de Gerenciamento de Projeto de Software
1.4 Materiais de Referência
1.5 Definições e acrônimos
2. Organização do Projeto
2.1 Modelo de Processo
2.2 Estrutura Organizacional
2.3 Limites e interfaces organizacionais
2.4 Responsabilidades do Projeto
3. Processo de Gestão
3.1 Objetivos e prioridades de gestão
3.2 Suposições, Dependências e Restrições
3.3 Gestão de Risco
3.4 Mecanismos de monitoramento e controle
3.5 Plano de Pessoal
4. Processo Técnico
4.1 Métodos, Ferramentas e Técnicas
4.2 Documentação de Software
4.3 Funções de Apoio ao Projeto
5. Pacotes de trabalho, cronograma e orçamento
5.1 Pacotes de Trabalho
5.2 Dependências
5.3 Requisitos de Recursos
5.4 Orçamento e Alocação de Recursos
5.5 Cronograma
6. Componentes Adicionais
7. Índice
8. Apêndices
Quadro 2 - Plano Padrão de Projeto de Software segundo IEEE
4.3 GERENCIAMENTO DE CONFLITOS

Os conflitos fazem parte da vida diária do gerente de projeto. Eles surgem
desde problemas dentro da equipe, bem como de lidar com partes interessadas
externas. Clientes e stakeholders mais leigos tendem a ter problemas para
entender o porquê de alguns custos ou prazos serem acima ou abaixo do esperado
por eles. Cada projeto tem fontes abundantes de conflito potencial. As fontes mais
comuns incluem competição por recursos escassos, diferenças relacionadas a
objetivos e os meios para alcançá-los e divergências sobre custo, cronograma ou
compensações técnicas.
35
Didática no Ensino
Volte ao Sumário
Alguns conflitos também surgem das relações interpessoais.

Independentemente da causa, os gerentes de projeto não podem ignorar
os conflitos, eles devem identificá-los à medida que surgem, compreender a
natureza de suas causas e resolvê-las em seus estágios iniciais. Não fazer isso pode
interromper seriamente um projeto e levar a atrasos desnecessários e estouros de
custo.
Conflitos internos tornam-se risco ao projeto uma vez que podem custar caro
seja pela exigência do aumento de escopo e requisitos do projeto de software ou
pela troca de mão de obra de algum profissional envolvido. Até mesmo a troca de
tecnologias, sejam tipos de servidores físicos ou de linguagem de programação,
afetam em custos e prazos, mudando o que foi antes projetado e se tornando um
risco a conclusão do projeto.
Muitas falhas de projeto podem ser atribuídas a uma falha nas comunicações.
Por isso, é responsabilidade do gerente do projeto criar um ambiente para uma
boa comunicação dentro da equipe e gerenciar o processo de comunicação
com as partes interessadas externas, particularmente com a organização do
cliente. Em um projeto eficaz, os gerentes mantêm todas as partes envolvidas
informadas, evitando surpreender o cliente. O sucesso também não depende
apenas de estruturas de relatórios formais. Linguagem corporal em uma reunião
de status muitas vezes pode fornecer mais informações do que um relatório de
status escrito.
Quando uma entidade toma uma decisão de criar um software, ela se expõe
a uma série de riscos. O total de tais riscos depende do tipo de instrumento que
for projetado. Esses riscos incluem questões financeiras e podem ser na forma
de alto risco, volatilidade nos requisitos, abertura de exceções etc. Assim, com
o objetivo de minimizar e controlar os riscos, os gestores de projetos praticam a
gestão de riscos. Não dar a devida importância à gestão de risco ao tomar decisões
de projeto pode causar estragos no processo ao longo do tempo, levando ao
rompimento de contrato (que não exclui processos por via judicial).
4.4 MAIORES RISCOS NO DESENVOLVIMENTO DE SOFTWARE

O reconhecimento de que o desenvolvimento de software possui certa
complexidade de prever e planejar é natural, visto que o software é algo
intangível e frequentemente envolve um grande número de partes interessadas.
Essa combinação de fatores pode criar uma série de riscos que precisam ser
considerados e gerenciados desde o início de um projeto de software.
36
Didática no Ensino
Volte ao Sumário
Embora possamos estimar a ameaça que esses riscos terão em um projeto

de software, a probabilidade e o impacto de sua ocorrência variam dependendo
da metodologia que se está usando. Experientes profissionais da área de software
apresentam vários tipos de riscos que um projeto está suscetível. Na perspectiva
de um gerente de projetos, é de se esperar que alguns problemas ocorram,
como já citamos anteriormente, mas também existem meios para se prevenir ou
minimizar os impactos e riscos de um projeto. A seguir, apresentaremos alguns
dos principais riscos que podem tornar um projeto inviável.
Estimativas imprecisas
Embora as estimativas sejam uma parte muitas vezes inevitável do
desenvolvimento de software (por pressão dos clientes ou stakeholders para obter
um preço ou prazo), elas podem criar risco se as estimativas criarem expectativas
que não podem ser atendidas. Estimativas imprecisas ocorrem quando a duração
de um projeto, marco ou iteração é subestimada pelo grupo do projeto. As
estimativas de software podem causar problemas entre desenvolvedores e
clientes porque aumentam os prazos do projeto e, portanto, também as despesas
com o projeto.
Variações de escopo
As variações de escopo ocorrem quando o escopo de uma iteração muda
depois que um período de tempo foi acordado. Devido ao valor de receber
feedback frequente do cliente, as partes interessadas ou proprietários do produto
muitas vezes pedem para variar o escopo de um projeto. No entanto, a variação do
escopo cria um risco grave para os projetos. Quando um escopo varia, isso afeta
significativamente a capacidade dos desenvolvedores de seguir o cronograma
original de um projeto.
Por isso, gerenciar as expectativas do cliente sobre como a variação do

escopo pode impactar as estimativas originais de um projeto é uma estratégia de
mitigação importante para esse risco. Usar uma métrica de variação para medir as
mudanças de escopo permite maior visibilidade ao cliente de como as solicitações
impactarão o projeto. A seguir temos algumas estratégias valiosas para lidar com
variações de escopo:
• Iterações curtas e gerenciáveis ( usando metodologia Ágil) permitem oportunidades

mais frequentes de refletir e variar o escopo do projeto;
• Elaboração de apenas trabalhos priorizados.
•
• Engajamento do usuário final
37
Didática no Ensino
Volte ao Sumário
Este risco ocorre quando um produto é lançado no mercado, mas os usuários

são resistentes a mudanças ou há conflito entre os usuários, por exemplo. Garantir
que os usuários de um produto realmente adotem o software estará diretamente
relacionado ao seu sucesso. No caso de uma empresa que desenvolve software
para um cliente externo, isso se correlaciona com a lucratividade.
No caso do desenvolvimento de um software para uso interno, ele pode

determinar se o software realmente melhorará a produtividade dentro da
empresa. Para melhorar o engajamento do usuário, pode-se surpreender com a
simples estratégia de ouvir os usuários. De acordo com Buratti (2014), algumas
estratégias de mitigação possíveis para este risco incluem:
• Teste de usuário e pesquisas;

• Prototipação;
• Lançamentos frequentes;
• Teste beta.
Essas estratégias de mitigação são muito mais fáceis de aplicar usando o

desenvolvimento ágil. A chance de baixo envolvimento do usuário final é muito
mais provável para projetos que seguem uma metodologia em cascata (método
mais tradicional de desenvolvimento de software). Isso ocorre porque esses tipos
de projetos são, muitas vezes, incapazes de se adaptar ao feedback do usuário
final durante o desenvolvimento. A natureza do desenvolvimento em cascata não
requer variações de escopo.
Expectativas das partes interessadas

Embora se fale sobre o gerenciamento das expectativas das partes
interessadas como uma estratégia de mitigação, a adoção dessa estratégia pode,
por si só, se tornar um risco do projeto. As partes interessadas são pessoas ou
grupos que podem impactar ou serão impactados por um resultado do projeto de
software. Essas partes interessadas podem variar de proprietários de negócios à
equipe de desenvolvimento ou até mesmo investidores no projeto. É essa relação
próxima com o resultado do projeto que torna o gerenciamento das expectativas
de cada uma dessas partes interessadas um desafio.
Para Macedo e Salgado (2015), definir as expectativas com as partes

interessadas estão relacionada em algumas características importantes, como:
• Comunicação efetiva;
• Obter aprovação frequente e reconhecimento do projeto de uma parte interessada;
• Seguir metodologias de desenvolvimento testadas;
38
Didática no Ensino
Volte ao Sumário
• Envolver as partes interessadas em reuniões importantes;

• Certificar-se de que as partes interessadas mantenham linhas de feedback constan-
tes p
ara boa comunicação com as equipes de desenvolvimento.
Código de má qualidade
Quando a qualidade de um projeto não se alinha com as expectativas das
partes interessadas, existe um risco significativo de que o projeto não seja bem-
sucedido. Pode parecer meio óbvio, mas o código-fonte de baixa qualidade pode
ocorrer por vários motivos, por exemplo, quando os projetos são subestimados e
os desenvolvedores se apressam para concluir a iteração.
Um código ruim ou de baixa qualidade pode significar várias coisas. O código

pode ser difícil de ler, o que significa que é difícil para outros desenvolvedores
revisar ou fazer alterações. Pode ter sido apressado e lançado sem teste, portanto
cheio de bugs que poderiam ter sido evitados. Em outras palavras, um código de
baixa qualidade cria um risco de déficit técnico.
Déficit técnico é essencialmente qualquer código que diminui a agilidade

de um projeto de software no longo prazo. Normalmente, ele é criado por meio
de atalhos ao escrever o código, a fim de atingir objetivos mais rapidamente.
No entanto, a qualidade do código é importante porque reduz o esforço de
desenvolvimento de longo prazo de um projeto, tornando o projeto mais fácil de
entender, manter e escalar (crescimento).
Para podermos melhorar a qualidade do código produzido, é importante que

os desenvolvedores mantenham um alto padrão para seu código. Isso pode ser
feito considerando as seguintes estratégias:
• Revisões de código;
• Padrões e guias de codificação claros;
• Teste de todo o código;
• Nomear um Gerente de Produto dedicado para monitorar a qualidade do projeto e
assumir a responsabilidade de todos os interessados p
elo sucesso e falhas;
• Desenvolvimento em pares;
A maneira de trabalhar reflete no resultado, em se tratando de linhas de código

isso não é muito diferente. O uso de frameworks, linguagens de programação mais
atualizadas e a leitura de manuais podem ser fatores que fazem toda a diferença
no desenvolvimento de um software de qualidade e com menor riscos.
39
Didática no Ensino
Volte ao Sumário
Gerenciamento de risco inadequado

O gerenciamento de risco inadequado pode ocorrer quando qualquer um
dos riscos específicos do projeto não é devidamente reconhecido e solucionado
pelas partes interessadas. O gerenciamento de risco adequado para um projeto
de desenvolvimento de software precisa respeitar o caminho, começando pelo
reconhecimento de que os riscos existem. A estratégia de se omitir ou fingir que
pode entregar software sem enfrentar nenhum desses problemas só causará
estresse e problemas a serem resolvidos a longo prazo.
Uma solução ideal passa por considerar estratégias de busca dos riscos desde
o início e continuar tal busca ao longo do projeto de software. Existem muitos
riscos ao construir um software e, se um risco for efetivamente identificado, ele
pode ser solucionado. É importante que se determine quais riscos são específicos
ao projeto e defina métodos para resolvê-los desde o início do projeto. Para ajudar
a identificar o impacto que um risco específico pode ter no projeto de software, é
possível usar uma matriz de risco. Para determinar quais são os maiores riscos em
um projeto, é preciso determinar o impacto e a probabilidade de ocorrência do
risco.
Mas, com certeza, existem outros tipos de riscos. Os citados aqui foram
apenas os mais frequentes e os de maior destaque no cenário de desenvolvimento
de softwares. Infelizmente, os riscos geralmente só se tornam evidentes quando
algo dá errado em um projeto. Portanto, é importante ficar bem claro desde o
início quem é responsável por quais aspectos do projeto e quando ele deve ser
entregue, a fim de determinar quem deve cuidar para que cada aspecto de risco
seja mitigado o mais rápido possível.
40
Didática no Ensino
Volte ao Sumário
5. FERRAMENTAS DE ANÁLISE E GERÊNCIA DE

REQUISITOS
Manter uma boa comunicação é algo difícil na engenharia de requisitos. A

conversa entre usuários finais e especialistas em TI pode se comparar a duas pessoas
de países diferentes, falando línguas diferentes. Ou seja, ambos têm experiências
diferentes e, portanto, muitos mal-entendidos ocorrem frequentemente,
sem muitas vezes serem percebidos, até chegar a um ponto mais adiante do
projeto. Isso pode gerar problemas financeiros e desvantagens oportunas, cujo
envolvimento inicial dos usuários finais para os requisitos elicitação pode ser um
remédio preventivo. Mas, a comunicação entre usuários finais e especialistas de
TI é um problema da engenharia de requisitos.
Estudos mostram que 60% das falhas do projeto saem de alguma das fases da
engenharia de requisitos e muitas vezes não são descobertos até o final do projeto
ou quando o sistema já concluiu seu ciclo de vida (Marcelo e Salgado, 2015). Como
já vimos quando tratamos dos riscos em projetos de software, quanto mais tarde o
erro for detectado, mais caro é a retificação. Uma vez que requisitos ausentes ou
incompletos fazem com que os projetos falhem, é importante encontrar soluções
para melhorar a qualidade dos requisitos.
Os engenheiros de software esperam requisitos bem formulados, escritos

de forma detalhada e com uma especificação formal. Para os usuários finais,
desenvolver tais especificações é muito difícil e demorado. É por isso que os
analistas de requisitos devem escrevê-los com o apoio das partes interessadas.
Existem muitos métodos e técnicas para induzir o usuário a definir bem requisitos,
muito úteis para os analistas de requisitos. Beyer et al (2015) afirmam que entrevistas
tradicionais, pesquisas e workshops são usados principalmente, mas nem sempre
são o mais adequado. Para preencher a lacuna de comunicação entre usuários
finais e especialistas em TI, técnicas e ferramentas são frequentemente utilizadas.
Existem diferentes abordagens para encontrar ferramentas úteis ao usuário

para se obter requisitos. Uma abordagem é encontrar uma linguagem comum
entre os usuários finais, analistas de requisitos e engenheiros de software por
meio da visualização. Outra abordagem consiste em registrar um requisito
ou necessidade utilizando um aplicativo de gravação de áudio para registrar
conversas informais e reuniões de trabalho.
41
Didática no Ensino
Volte ao Sumário
Mesmo que a participação do usuário final na engenharia de requisitos seja

muito importante, atualmente não é usado com freqüência. As razões podem ser
encontradas no grande gasto de tempo para organizar e realizar pesquisas, bem
como no tempo que leva para entender os requisitos dos usuários. O objetivo
do envolvimento do usuário em engenharia de requisitos é melhorar o processo
de design, facilitar a implementação e abordar os princípios éticos do projeto.
O envolvimento do usuário pode ser realizado ao desenvolver especificações
de requisitos, validando os requisitos, apoiando o projeto detalhado e o
desenvolvimento, revisando as especificações, inspecionando protótipos e
aceitando as versões lançadas.
Para chegar a esse objetivo de interação com o usuário, existem ferramentas

e aplicações próprias para isso que permitem desenhar e modelar os requisitos
de maneira bastante prática. OpenProposal é um ferramenta de visualização que
espera que o usuário final desenhe requisitos em suas telas e envie posteriormente
para especialistas de TI. A visualização imediata integra o usuário final desde o
início até o processo de descrição de requisitos. O iRequire é um aplicativo de
elicitação de requisitos, que os usuários finais podem utilizar a nível local para
esboçar requisitos. Já o ConTexter é uma ferramenta usada em um ecossistema
de TI onde um grande público pode relatar seu feedback para diferentes sistemas
que precisam ser identificados.
5.1 FERRAMENTAS VISUAIS

Existem muitas soluções para aquisição de requisitos de maneira visual,
mas principalmente para analistas de requisitos e engenheiros de software, por
exemplo Diagramas de casos de uso UML, mockups, técnicas de prototipagem
rápida. Com tais tipos de ferramentas, os usuários finais podem dar um feedback
mas precisam de uma certa experiência em TI. É por isso que autores e profissionais
da área indicam que as ferramentas focadas no usuário final são necessárias,
pois podem descrever suas necessidades de forma natural por meio de auxílio
visual. Buratti (2014) afirma que a visualização ajuda o usuário final a identificar
seus requisitos e é mais intuitivo e fácil de usar do que as linguagens textuais. Para
entendermos como diferentes ferramentas podem auxiliar de maneira visual
os usuários e os analistas a compreenderem os requisitos, veremos a seguir a
especificação de algumas delas.
5.1.1 OpenProposal
A abordagem OpenProposal é baseada na ferramenta de anotação Annotate!
Pro, onde os usuários finais podem anotar os requisitos quando eles acontecerem.
Possui uma visualização imediata para abordagem de sistemas abrangentes,
42
Didática no Ensino
Volte ao Sumário
em que o usuário final está envolvido desde o início. De acordo com Rashid et
al (2008), o OpenProposal permite aos usuários anotar suas solicitações de
recursos, erros ou solicitações de aprimoramento diretamente em seu espaço de
trabalho de aplicativos e enviar essas solicitações para o analista de de requisitos.
Assim, os usuários finais participam ativamente no processo de desenvolvimento
de software por meio do envio de requisitos para software, bem como software
em desenvolvimento.
Temos na Figura 8 o fluxo de trabalho da engenharia de requisitos com o

usuário final participando do processo. A OpenProposal é baseada neste fluxo
de trabalho apresentado na Figura 8.
Figura 8 - Fluxo de processos do OpenProposal

Fonte: Elaborado pelo autor (adaptado de Rashid et al, 2008)
No fluxo de trabalho proposto pelo OpenProposal existem três atores

principais: o usuário final, o analista de requisitos e o engenheiro de software , bem
como cinco ações: especificar, discutir, priorizar, decidir e implementar. Os usuários
finais participam principalmente da especificação e atividades de discussão. Os
analistas de requisitos são responsáveis pela gestão das demandas de requisitos
e devem buscar compreender os interesses dos envolvidos nas discussões, na
atribuição de prioridades e na tomada de decisões. Eles também podem propor
novos requisitos. Por sua vez, o foco principal dos engenheiros de software é
entender as propostas do usuário, implementá-las corretamente e contribuir com
conhecimento técnico profissional para todas as demais atividades.
43
Didática no Ensino
Volte ao Sumário
A abordagem OpenProposal é estruturada em três componentes principais,

o OpenProposal Annotation Tool, OpenProposal Mediator e OpenProposal
Issue-Tracker. A OpenProposal Annotation Tool (ou ferramenta de anotação
OpenProposal) é baseada na ferramenta de anotação Annotate! Pro. Ele
reúne os requisitos anotados (capturas de tela, anotações, metadados) em uma
especificação XML que é enviada ao OpenProposal Mediator (o mediador).
O mediador cria um novo problema no OpenProposal Issue-Tracker com as
especificações recebidas. A partir disso, o problema agora pode ser discutido
e avaliado na ferramenta Issue-Tracker. Uma lista de requisitos enviados fica
disponível na ferramenta de anotação do OpenProposal.
O OpenProposal se destina a apoiar o processo de desenvolvimento de

software para equipes de desenvolvimento cujos membros da equipe podem
estar em locais diferentes (trabalho remoto) e podem melhorar a comunicação
com os recursos visuais do OpenProposal. A pesquisa feita por Rashid et al (2008)
também mostrou que o software pode melhorar a colaboração entre usuários finais
e engenheiros de software e tem um desempenho melhor do que ferramentas
convencionais. A Figura 9 apresenta a tela de utilização do OpenProposal que
servirá como forma de descrevermos o funcionamento da ferramenta de modo
geral.
Figura 9 - Interface do OpenProposal

Fonte: Rashid et al (2008).
Conforme a Figura 9, o conjunto de ferramentas OpenProposal pode ser
44
Didática no Ensino
Volte ao Sumário
acessado a partir da barra de ferramentas (no topo da Figura 9) e oferece quatro

ferramentas relacionadas à anotação. A ferramenta “Adicionar” (1) permite aos
usuários especificar uma posição onde eles gostariam de ter um novo objeto na
tela. A ferramenta “Remover” (3) é o inverso, o elemento existente é marcado
como supérfluo. Com a ferramenta “Mover” (2), os usuários primeiro selecionam
um área que deve ser movida para um local diferente na área de trabalho de
aplicativos, em seguida, para a nova área-alvo. A ferramenta “Comentário” (4)
pode ser usada para sugestões de outras ferramentas que não são capazes de
expressar diretamente, bem como de refinar e adicionar mais detalhes aos outros
anotações das ferramentas.
Ainda de acordo com a Figura 9, os usuários podem pausar a anotação, caso

queiram mudar o layout do aplicativo que estão anotando (A). Todas as anotações
são representadas como objetos que podem ser editados, movidos ou excluídos
sempre que os usuários quiserem. Assim que terminarem suas anotações, os
usuários podem enviar suas solicitações para a plataforma de colaboração (H).
Antes de enviar, o usuário é solicitado a incluir um título e uma descrição de maneira
textual. Os usuários podem sair do aplicativo a qualquer momento, clicando no X
no canto superior direito da tela.
5.1.2 iRequire
Geralmente, os usuários finais participam de técnicas de elicitação por meio
de entrevistas e workshops para discutir suas necessidades, mas muitas práticas
podem ser esquecidas se uma estiver fora do contexto. Isso exige a documentação
dos requisitos no momento em que acontecem. O iRequire é uma abordagem
para uma ferramenta para uso do usuário final.
Hoje em dia, os usuários finais estão familiarizados com dispositivos móveis,

portanto, uma aplicação como o iRequire surge como algo convencional,
uma vez que funciona como um aplicativo para dispositivo móvel. Os usuários
podem documentar suas necessidades quando e onde quiserem, tendo o tempo
necessário para terminar sua avaliação. Uma vantagem dos dispositivos móveis é
que eles suportam a documentação com diferentes tipos de mídia, como imagem,
áudio, vídeo e texto. Beyer et al (2008) introduzem três etapas de elicitação para
iRequire:
1. Obtenção de Informações e Contexto: Fornece percepções do ambiente do

usuário final com texto, imagem, áudio e vídeo.
2. Obtenção de Necessidades: Documenta as necessidades futuras com descrições
textuais ou gravações de áudio.
3. Obtenção de Justificativa/Tarefa: Explicação textual ou com uma gravação de áu-
45
Didática no Ensino
Volte ao Sumário
dio a importância de um requisito ou qual tarefa é suportada pelo requisito.
Para manter a flexibilidade, a ordem das etapas pode ser executada como
se quiser, embora a sequência descrita acima seja sugerida. É importante notar
que o iRequire não é uma ferramenta de brainstorming, ela se concentra nos
requisitos descobertos durante o trabalho diário. Depois de reunir os requisitos,
os analistas de requisitos podem analisar e transcrevê-los em uma especificação
de requisitos formal. A implementação do iRequire é baseada em um aplicativo
para smartphone. As telas são estruturadas em um assistente de quatro etapas,
que permite uma orientação passo a passo para o usuário final (Figura 10).
Figura 10 - Interface do iRequire

Fonte: Seyff et al (2010).
Na primeira tela apresentada na Figura 10 (à esquerda), os objetos relevantes

são capturados com fotos. A tela dois (Figura 10, à direita) é onde está a real
necessidade, descrita com a gravação de um áudio ou a escrita de um texto. Na
tela três (veja na Figura 11, à esquerda) a justificativa ou tarefa é registrada ou
descrita. A tela quatro (veja na figura 11, à direita) mostra um resumo do requisito
capturado, que deve ser confirmado antes de ser armazenado no banco de dados.
46
Didática no Ensino
Volte ao Sumário
Figura 11 - Outras telas da Interface do iRequire

Fonte: Seyff et al (2010).
Observe que, em todas as telas, temos os botões voltar (back), avançar

(new need) e informações (i), bem como um teclado virtual. Além da entrada do
usuário final, informações relevantes como localização ou hora da documentação
é capturada automaticamente usando GPS e captura de data e hora (timestamp).
Nesta fase, os requisitos coletados são armazenados localmente, portanto,

se for de interesse distribuir as informações para outros participantes, a ferramenta
permite que novos usuários sejam incluídos no processo. A proposta do iRequire
vai além de levantar requisitos, permitindo ter um sistema automatizado de
transcrição para uma documentação formal. Em seu artigo, Seyff et al (2010)
apresentam um estudo de avaliação que concluiu que os usuários finais eram
capazes de executar suas tarefas regulares sem ser interrompido ao registrar suas
necessidades.
A ferramenta tem evoluído com o tempo, permitindo a avaliação do iRequire

e seu processo por parte do usuário, apontando necessidades de melhoria, seus
benefícios ou limitações. Outros recursos foram acoplados desde a primeira
versão do software, com tecnologias adicionais, como Bluetooth e RFID (tipos de
comunicação sem fio com fácil conexão e detecção por outros dispositivos).
47
Didática no Ensino
Volte ao Sumário
5.1.3 ConTexter
Proposto por Schneider et al (2014), o ConTexter é uma solução que vai além
de um simples aplicativo. Em locais públicos, as pessoas são confrontadas com
muitos sistemas diferentes para os quais fraquezas e falhas são percebidas. Muitas
vezes as pessoas gostam de dar feedback, se isso puder ser feito de uma maneira
fácil e sem esforço. O ConTexter fornece tal abordagem.
Ele é implementado como um aplicativo de dispositivo móvel bastante

acessível com feedback rápido e facilmente acesso. Ele também explora os
recursos dos dispositivos móveis como informações de contexto, geográficas
e posições lógicas no ecossistema de TI, que podem ser identificadas por meio
de sensores como GPS, WLAN, Bluetooth e URLs atualmente conectados. A
proposta é de um ecossistema de TI simplificado com dois objetos para os quais o
feedback pode ser dado.
Em seu fluxo, a parte interessada fornece informações de contexto com

o dispositivo móvel, com os melhores destinatários sendo selecionados
e apresentados ao usuário para que ele possa decidir a quem enviar seus
apontamentos. A Figura 12 apresenta as capturas de tela do aplicativo móvel
ConTexter.
Figura 12 - Telas de interface do ConTexter

Fonte: Schneider et al (2014)
Para um estudo de caso, é apresentado um cenário de serviços universitários,

software e outros objetos universitários usando o ConTexter. A tela mais à
esquerda (Figura 12) mostra como escolher uma categoria de feedback, a
visualização ao meio apresenta a decisão de um destinatário final e, à direita, o
formulário de feedback para envio é exibido. Muitas questões em aberto podem
ser incorporadas adicionando campos e, portanto, ampliando a pesquisa junto ao
48
Didática no Ensino
Volte ao Sumário
usuário. Uma extensão permite o envio de áudio e vídeo como anexo. Atualmente
Schneider et al (2014) ainda trabalham em versões para iOS (iPhone) e Android.
5.1.4 Helix RM
O Helix RM facilita a colaboração com várias partes interessadas - capturando
requisitos simultaneamente, realizando revisões, sabendo o que está aprovado
e, o mais importante, estando ciente das mudanças. Com Helix RM, é possível
definir uma taxonomia rica de tipos de requisitos e seus relacionamentos para
garantir especificações completas de requisitos e simplificar a decomposição de
requisitos.
Como uma ferramenta autônoma, Helix RM fornece o gerenciamento

de requisitos. Mas, o software possui componentes adicionais no contexto da
plataforma Helix ALM, podendo com isso realizar a rastreabilidade para frente
e para trás a fim de produzir relatórios de maneira bastante rápida, verificar a
cobertura de teste de requisitos e até mesmo rastrear requisitos para alterações no
código-fonte (no caso de requisitos alterados após o início da fase de construção
do software). A Figura 13 apresenta uma interface padrão do Helix RM.
Figura 13: Interface do Helix RM

Fonte: Elead ALM (2020)
5.2 COMPARATIVO DE FERRAMENTAS

Como forma de preencher a lacuna de comunicação entre usuários finais e
especialistas em TI, diferentes abordagens para ferramentas de usuário final foram
49
Didática no Ensino
Volte ao Sumário
apresentadas. Com ferramentas de visualização, os usuários finais podem anotar

os requisitos de uma forma mais natural e próxima de sua linguagem habitual
diária. Os aplicativos móveis são baseados em um dispositivo que o usuário final
já está familiarizado, portanto, as necessidades de documentação podem ser
facilmente integradas em atividades rotineiras.
Em um ecossistema de TI, todos podem ser usuários finais. Em tal sistema

existem muitos sistemas que devem ser identificados para que os requisitos sejam
submetidos ao sistema de maneira correta. Todas essas abordagens diferentes
foram implementadas como uma ferramenta ou protótipo. Estudos realizados,
em sua maioria, concluíram melhorias necessárias mas que o uso de ferramentas
para elicitar requisitos é algo que contribui muito em um menor gasto de tempo e
energia no levantamento de requisitos. As ferramentas apresentadas devem ser
refinadas e fornecer insights mais profundos para o envolvimento do usuário final.
Possuindo muitas características semelhantes, também apresentam características
que fazem com que elas possam ser experimentadas por profissionais e clientes
de software, a fim de que a ideal seja selecionada para uso.
Por fim, o quadro 3 representa um resumo das ferramentas apresentadas.

Porém, é preciso enfatizar o esforço para envolver os usuários finais na abordagem
inicial e de fácil utilização.
Ferramenta Benefícios Limitações

OpenProposal Os usuários finais desenham suas Uso de modelos pode precisar de suporte;
próprias necessidades com a ajuda de Os usuários finais devem
um modelo; Plataforma de rastrea-
mento e discussão; cumprir acordo de privacidade dos dados espontaneamente;
Melhora a colaboração entre os usuá- Sem transcrição automática.
rios finais e especialistas em TI.
iRequire Os usuários finais coletam seus Sem transcrição automática.
requisitos durante
atividades diárias sem
alterar muito sua rotina diária;
ConTexter Feedback para múltiplos Sem transcrição automática.

sistemas
Helix RM Captura requisitos simultaneamente; Custo para personalização e suporte.
Realiza revisões constantes;
Permite saber o que está aprovado
em tempo real
Quadro 3 - Comparativo entre características das diferentes ferramentas
De maneira geral, o gerenciamento de requisitos tem foco em soluções
50
Didática no Ensino
Volte ao Sumário
onde os usuários finais possam participar de todo o processo da melhor maneira

possível. Uma das principais limitações é a dificuldade de comunicação entre
usuários e especialistas em TI, uma vez que o conhecimento técnico de ambos são
particulares, muitas vezes sendo o maior obstáculo. Os gerentes de projeto têm
buscado o uso das ferramentas aqui apresentadas justamente para que sua forma
de gerenciar projetos evolua, a fim de melhor transcrever os requisitos coletados
- de preferência de maneira automática - e inserindo numa documentação formal
pelo modo mais ágil possível.
51
Didática no Ensino
Volte ao Sumário
6. IMPLEMENTAÇÃO DE RESULTADOS COM O MPS.BR
A qualidade de software requer cuidados preventivos e paliativos ao longo

de todo o projeto de software. Para que essa qualidade seja mantida, existem
aspectos estruturais que precisam ser mantidos, assim como boas práticas e
regras de aceitação mínima, sempre no intuito de se ter um padrão de projeto
aceitável. Desde antes do levantamento de requisitos, todo cuidado é pouco, visto
que a necessidade do usuário final precisa ser bem atendida, mas o custo para se
atingir isso precisa sempre ser bem calculado.
Existem instituições em todo o mundo que visam manter a qualidade

dos processos e serviços de software. A nível mundial temos alguns padrões
como o ITIL (Information Technology Infrastructure Library ou Biblioteca de
Infraestrutura em Tecnologia da Informação) como um conjunto de práticas
que visa nortear o gerenciamento dos serviços de TI. Temos também o PMBOK
(Project Management Body of Knowledge ou Conjunto de Conhecimentos
em Gerenciamento de Projetos) é uma espécie de padronização mais focada a
gestão de processos e de projetos de software, sendo bastante empregado por
empresas e na formação de gerentes de projetos.
Mas, em se tratando de qualidade, outras instituições também aparecem.

Temos a IEEE (Institute of Electrical and Electronic Engineers ou Instituto de
Engenharia Elétrica e Eletrônica) que possui seus padrões internacionais, auxiliando
nas normas em se tratando das várias engenharias, principalmente a elétrica/
eletrônica e de software. A ISO (International Organization for Standardization
ou Organização Internacional para Padronização) é, talvez, dessas instituições, a
mais famosa. Ela é responsável por aprovar padrões em diversas áreas técnicas.
Suas normais mais famosas são a ISO 9000/9001, ISO 14000. O padrão ISO/IEC
9126 é o que dita sobre qualidade em produto de software - IEC é a International
Electrotechnical Commission ou Comissão Eletrotécnica Internacional.
6.1 PADRÃO DE QUALIDADE DE SOFTWARE NO BRASIL

A nível de Brasil, temos o MPS.BR (Melhoria de Processos do Software
Brasileiro). Ele foi criado em 2003 pela Softex (Associação para Promoção da
Excelência do Software Brasileiro) com o objetivo de melhorar a qualidade
do software produzido no país, tendo como ponto de partida algumas ações
norteadoras (SILVA, 2013).
52
Didática no Ensino
Volte ao Sumário
O desenvolvimento do MPS-BR se deu em base nas normas internacionais

como as já citadas ISO/IEC 9126, mas também as ISO/IEC 12207 e ISO/IEC
15504, além da CMMI (Capability Maturity Model Integration), sendo adaptado
a realidade do mercado de software brasileiro. Em muitos aspectos, o modelo
de capacidade e maturidade integrado proposto no CMMI formam a base do
modelo brasileiro de acompanhamento da qualidade de software. Aspectos
como a gestão de projetos, acompanhamento dos riscos e da qualidade, além da
fase de desenvolvimento em si dos produtos de software.
De acordo com SILVA (2013) e com a documentação oficial do MPS.BR,

existem sete níveis de maturidade de software que servem como forma de analisar
em que patamar uma empresa ou equipe de software está a fim de atender a
qualidade básica de software. Esses níveis são:
• A - Em Otimização
• B - Gerenciado Quantitativamente
• C - Definido
• D - Largamente Definido
• E - Parcialmente Definido
• F - Gerenciado
• G - Parcialmente Gerenciado
Os níveis são alcançados de acordo com o grau de implantação do modelo

em seu projeto de software, sendo escalado de baixo para cima. Ou seja, o nível
G é o primeiro a ser implementado e o nível A é o nível máximo que a empresa
poderá atingir. E, para se alcançar o patamar máximo, vários processos precisam
ser realizados ou implantados a fim de termos uma avaliação, feita por instituição
externa e imparcial. O Site oficial da Softex (online, 2020) descreve quatro passos
para a avaliação MPS.BR para chegar a comprovação dos níveis de maturidade da
organização. Esses passos são:
Passo 1 - Implementação do modelo MPS.BR: Primeiramente, a

organização precisa implementar os processos em uma ou mais de suas unidades
organizacionais no modelo e nível MPS adequados ao seu negócio: Software,
Serviço, Gestão Pessoas ou uma combinação destes.
Passo 2 - Contratação da instituição avaliadora: A empresa precisa

selecionar e contratar uma Instituição Avaliadora (IA-MPS) habilitada pela Softex.
O site oficial possui uma lista de Instituições Avaliadoras. Existem restrições a serem
consideradas na contratação de uma avaliação MPS a fim de se ter idoneidade e
transparência no processo.
53
Didática no Ensino
Volte ao Sumário
Passo 3 - Avaliação oficial: A avaliação oficial acontece em um período que

pode levar entre três e seis meses. Ela é realizada em etapas que abrangem a
avaliação inicial, elaboração, avaliação final e auditoria.
Passo 4 - Publicação do resultado oficial: A avaliação MPS.BR é considerada

validada após sua publicação no portal da Softex.
Ao longo desse processo, profissionais responsáveis deverão assumir o papel

de representantes da implantação do MPS na organização postulante. Segundo
a própria Softex (online) “as avaliações MPS.BR devem ter a participação de um
ou mais representantes da empresa na equipe de avaliação”. Este passo precisa
ser realizado antes do início do processo de avaliação e pode ser feito, a qualquer
momento, também pelo portal (Softex, online, 2020). No total são três diferentes
modelos de processo do MPS: MPS para Software, para Serviços e para Gestão
de Pessoas (RH). Cada um deles possui seu conjunto de regras e processos a
serem implantadas a fim de se obter uma avaliação que homologue como bem-
sucedido tal modelo.
6.2 PROCESSOS DE PROJETO

O guia geral do MPS para software - em sua versão 2020 - apresenta
nove seções que norteiam os processos a serem implantados e gerenciados ao
longo de um projeto de software. A seção 9 trabalha com a descrição detalhada
dos processos, tendo a subdivisão de Processos de Projeto (9.1) e Processos
Organizacionais (9.2).
6.2.1 Gerência de Projeto

No guia Geral MPS de software, o tópico 9.1 apresenta o descritivo relativo aos
processos de Gerência de Projetos (GPR). Segundo o próprio guia, seu propósito
é “estabelecer e manter atualizados planos que definam as atividades, recursos,
riscos, prazos e responsabilidades do projeto.” (SOFTEX, online). Esse processo
também visa demonstrar como está o andamento do projeto a fim de permitir
que correções sejam feitas caso haja algum tipo de desvio que possa atrapalhar o
desempenho do projeto de maneira significativa.
6.2.2 Gerência de Configuração e Requisitos

Na sequência, temos o processo GCO (Gerência de Configuração) e a GRE
(Gerência de Requisitos), cujo propósito é “definir, gerenciar e manter atualizado
os requisitos das partes interessadas e do produto, garantindo que inconsistências
54
Didática no Ensino
Volte ao Sumário
entre os requisitos, os planos e os produtos de trabalho sejam identificadas”

(SOFTEX, online). Temos também a DRE (Desenvolvimento de Requisitos),
que também trabalha dentro do contexto da REQ (Engenharia de Requisitos),
no intuito de verificar a criação e desenvolvimento dos requisitos de software,
englobando seu processo de levantamento, definição e documentação.
6.2.3 Gerência de Risco

Os aspectos relativos a riscos de desenvolvimento estão na guia de
Implementação, na parte 5, que trata sobre a fundamentação para implementação
do nível C do MPS. O tópico número sete deste guia detalha os aspectos
da gerência de riscos (GRI), seus propósitos, fundamentação teórica e os
resultados esperados nos processos envolvidos. O propósito da GRI, segundo
o guia de implantação do MPS, “é identificar, analisar, tratar, monitorar e reduzir
continuamente os riscos em nível organizacional e de projeto” (Softex, online). Ela
varia desde o nível G (mais baixo do processo) até o nível C, mais acima, sendo
acompanhado também pela GPR (Gerência de Projetos).
55
Didática no Ensino
Volte ao Sumário
CONSIDERAÇÕES FINAIS
Ao término deste módulo, podemos concluir que os requisitos são parte

fundamental na estrutura dos softwares. Uma vez que adotamos os requisitos
como as reais necessidades das partes envolvidas no projeto de software, é
primordial que tenhamos um levantamento e elicitação dos requisitos de maneira
prioritária. A engenharia de software, da qual a engenharia de requisitos faz
parte como uma espécie de desdobramento, precisa estar em sintonia entre as
necessidades dos stakeholders e a aplicação dos conhecimentos de negócio
junto a equipe de desenvolvimento. A partir disso, podemos perceber a real
necessidade de elencar requisitos com qualidade para que os riscos do projeto
sejam consideravelmente baixos.
Nesse aspecto, é elementar que se utilizem diferentes metodologias e

formas de se desenvolver softwares. Sobre isso, a engenharia de requisitos é
de fundamental importância pois existe justamente como um elo de ligação
entre os usuários finais - responsáveis por requisitar o software - e a equipe de
desenvolvimento, passando por outros perfis profissionais de dentro de uma
organização, que podem ser especialistas na regra de negócio ou especialistas
de TI (Tecnologia da Informação).
Logo, o uso de técnicas e ferramentas que aperfeiçoem os processos iniciais

de análise até os métodos que podem acelerar o desenvolvimento de softwares,
precisam ser adotados, caso queiramos um êxito completo. Tais ferramentas, por
diferentes motivos, têm evoluído muito, graças à internet e as novas formas de
comunicação e tecnologias da informação como um todo. O encurtamento da
distância entre as pessoas envolvidas também causa um impacto positivo no
levantamento de requisitos e, em consequência, no desenvolvimento de software
pautado na qualidade do produto final.
De modo geral, vimos que os requisitos passam por diferentes fases de um

projeto, já que eles estarão sendo criados e/ou alterados desde as fases iniciais
(concepção e elaboração), passando pela fase de construção ou desenvolvimento,
indo até a última etapa, já que podem sofrer alterações ou até mesmo novas
inclusões, de acordo com o andamento do projeto. Usando ferramentas
apropriadas e com apoio visual, podemos permitir que o usuário final faça parte
de todo o processo, desde a definição dos requisitos iniciais, seu refinamento e a
colocação de tais requisitos como funcionalidades práticas do sistema, como um
RF (Requisito Funcional) ou um RNF (Requisito Não Funcional).
56
Didática no Ensino
Volte ao Sumário
Por fim, deixamos claro que os papéis precisam ser respeitados. O usuário
final e o time de stakeholders são tão importantes como os analistas de requisitos,
analistas de sistemas e engenheiros de software. Todos formarão um só time
que, coeso, levarão o projeto ao sucesso, com a entrega de um produto final de
qualidade, sendo mensurado, analisado e validado até que se tenha o software
totalmente pronto e em uso (e até mesmo depois disso).
57
Didática no Ensino
Volte ao Sumário
REFERÊNCIAS BIBLIOGRÁFICAS
BEYER, H., HOLTZBLATT, K.: Apprenticing with the customer.

Communications of the ACM, vol.38, no. 5, pp.45-52. ACM Press, New York
(2015).
BURATTI, Robson. Desenvolvimento De Software Web Para Gestão De

Competências Em Projetos De Software. Disponível em: http://repositorio.
roca.utfpr.edu.br/jspui/bitstream/1/6916/1/FB_DESIDM_I_2014_04.pdf. Acesso
em: 14 dez. 2020.
DAVEY, Bill, et al. Requirements Elicitation: What’s Missing? Disponível em:

Informing Science and Information Technology. Vol. 5, 2008. http://proceedings.
informingscience.org/InSITE2008/IISITv5p543-551Davey466.pdf
Elead ALM. Helix RM - Requirements Management. Disponível em: <https://

www.eleadalm.com/products/helix-rm>. Acesso em 24 dez. 2020.
IEEE. EEE/ISO/IEC 12207-2017 - ISO/IEC/IEEE International Standard -

Systems and software engineering -- Software life cycle processes. Disponível
em: https://standards.ieee.org/standard/12207-2017.html. Acesso em: 08 dez.
2020.
_____. IEEE Standard for Software Project Management Plans. Disponível

em: http://cs.bilkent.edu.tr/~cagatay/cs413/1058.1-1987_00025325.pdf. Acesso
em 20 dez. 2020.
IIBA, International Institute of Business Analysis. BABOK - Um guia para o

Corpo de Conhecimento de Análise de Negócios. 3ª edição. São Paulo, 2015.
KRUCHTEN, Philippe. Introdução ao RUP – Rational Unified Process. 2ª

Edição, Rio de Janeiro: Editora Ciência Moderna, 2003.
MACEDO, Mateus Henrique Basso; SALGADO, Eduardo Gomes.

Gerenciamento de Risco Aplicado ao Desenvolvimento de Software. Revista
Sistema e Gestão, UFF. Disponível em: https://doi.org/10.7177/sg.2015.V10.
58
Didática no Ensino
Volte ao Sumário
N1.A13. Acesso em 22 dez. 2020.
MPS.BR. Guia de Implementação – Parte 5: Fundamentação para

Implementação do Nível C do MR-MPS-SW:2012. Disponível em: <https://www.
softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_de_Implementacao_
Parte_5_2013..pdf>. Acesso em: 22 dez. 2020.
PMI. Who are Project Managers? Disponível em: https://www.pmi.org/

about/learn-about-pmi/who-are-project-managers. Acesso em 14 dez. 2020.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7ª
ed. São Paulo: Bookman, 2011.
RASHID, A., WIESENBERGER, J., MEDER, D., BAUMANN, J.: Bringing
Developers and Users closer together: The OpenProposal story. Multikonferenz
Wirtschaftsinformatik, 2008.
SCHNEIDER, K., MEYER, S., PETERS, M., SCHLIEPHACKE, F., MORSCHBACK,
J., AGUIRRE, L.: Feedback in Context: Supporting the Evolution of IT-Ecosystems.
In: Ali, M., Vierimaa, M., Oivo, M. (eds.) Product-Focused Software Process
Improvement. LNCS, vol. 6156. Springer 2014.
SEYFF, N., GRAF, F., MAIDEN, N.: Using Mobile RE Tools to Give End-
Users their Own Voice. In: 18th IEEE International Requirements Engineering
Conference, pp. 37-46, IEEE Press, New York (2010).
SILVA, Daiany. O que é o MPS-BR? Disponível em: https://blogdaqualidade.
c o m . b r / o - q u e - e - o - m p s - b r / # : ~ : te x t = O % 2 0 M P S % 2 D B R % 2 0 o u % 2 0
Melhoria,de%20software%20nas%20empresas%20brasileiras. Acesso em 28
dez. 2020.
SOFTEX. MPS.br. Disponível em: https://softex.br/mpsbr/. Acesso em: 28
dez. 2020.
____. Guia Geral MPS de Software. Disponível em: http://www.lucianoaguiar.
com.br/wp-content/uploads/dlm_uploads/2020/02/MPS.BR_Guia_Geral_
Software_2020.pdf. Acesso em: 28 dez. 2020.
SOMMERVILLE, I. Engenharia de software. 9ª edição. São Paulo: Addison
Wesley, 2011.
59
Didática no Ensino
Volte ao Sumário
Desenho Instrucional: Veronica Ribeiro

Supervisão Pedagógica: Laryssa Campos
Revisão pedagógica: Camila Martins / Cássio Lima
Design editorial/gráfico: Darlan Conrado
2021
60
Didática no Ensino

E Book

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

E Book

Enviado por

Direitos autorais:

Formatos disponíveis

Volte ao Sumário

Navegue entre os capítulos

BRANDÃO, Daniel dos Santos, 2020 -

Palavras chaves: 1. Engenharia 2. Requisitos 3. Requisito Funcional 4. Requisi-

A engenharia de requisitos é uma parte importante ou uma subárea da

Um requisito se trata da necessidade ou problema apresentado por um cliente

Por mais que tenhamos diferentes metodologias e formas de se programar

1. FASES DE CONCEPÇÃO E ELABORAÇÃO

Podemos dizer que todo sistema ou software nasce a partir de alguma

As fases iniciais abrangem o levantamento da tal necessidade do usuário,

• ser necessária para um usuário resolver um problema ou alcançar um objetivo;

Figura 1: Fases e Disciplinas de um projeto de software

Dada a Figura 1, podemos observar que entre as fases de um projeto de

De acordo com Sommerville (2011), o objetivo da Engenharia de Requisitos

Percebe-se, então, que se tem na fase de concepção uma maior concentração

A partir disso, um grande salto é dado, chegando à próxima fase, chamada

1.1 FASE DE CONCEPÇÃO

• Intangibilidade: O software, ao contrário do hardware, é intangível. Como resulta-

Nisso, o peso sobre o gerenciamento de projetos acaba recaindo sobre

• Metas e especificações mal definidas;

Com isso em mente, podemos dizer que o objetivo fundamental da fase

envolvidas e interessadas no produto final). Por isso, o levantamento de requisitos

1.2 FASE DE ELABORAÇÃO

Particularmente nessa etapa, a interação com o cliente é bastante importante

A base para um projeto de desenvolvimento de software bem-sucedido é

Levando em consideração as fases de Concepção e Elaboração, é nesse

O quadro a seguir descreve as principais atividades que as fases de concepção

1.3 LEVANTAMENTO DE REQUISITOS

atingiremos o objetivo proposto de atender a necessidade do usuário.

Sommerville (2011) classifica os requisitos de software como requisitos de

Na prática, esses requisitos são geralmente definidos como requisitos

Mas, mesmo assim, nem todos os requisitos não funcionais (RNF)

Para termos os requisitos bem definidos, algumas etapas precisam ser

para erros e ambiguidades futuras.

À primeira vista, o processo de levantamento e a documentação de requisitos

Segundo PRESSMAN (2011), o gerenciamento de requisitos é importante

• A documentação dos requisitos serve como um ponto de referência para documen-

Além de definir o que eles podem esperar, parte do planejamento de

Na grande maioria das vezes, um cliente será receptivo ao aumento de

Uma descoberta completa dos requisitos de negócios quase nunca está

A importância da elicitação não pode ser exagerada, pois ela é a base de

1.4 PREPARAÇÃO PARA ELICITAÇÃO DE REQUISITOS

O uso de um modelo de software processo de desenvolvimento reduz

A elicitação de requisitos é uma etapa importante dentro do desenvolvimento

aumento de escopo e encarecimento do projeto, bem como selecionar as partes

A próxima etapa de um analista na elicitação de requisitos é garantir que

2. DISCIPLINAS E TÉCNICAS DE MODELAGEM DE

Depois que um analista identificar e recrutar as partes interessadas, a escolha

é atualizar um sistema existente ou quando a compreensão de um sistema

os clientes e usuários finais que podem não compreender todos os aspectos

razoável e que mantenham qualquer informação comercial proprietária contida

A natureza do projeto de um analista ditará o nível de detalhe que uma

Citando diretamente o que o BABOK (2015, p. 38), “As partes interessadas

2.1 CONFIRMANDO A ELICITAÇÃO

Sempre que a elicitação ocorre durante o ciclo de vida de um projeto, os

Uma vez que os métodos de elicitação tenham sido empregados, um analista

A modelagem de negócio é uma das formas de estabelecer disciplinas que

• Entender a estrutura e a dinâmica da organização na qual um sistema será implanta-

A modelagem de negócios é parte integrante do RUP (Rational Unified

2.2 MODELAGEM DE REQUISITOS

Complementarmente a esses modelos, alguns artefatos podem ser

O desenvolvimento do documento de modelagem de negócios de uma

O objetivo aqui é capturar os fundamentos do negócio, trabalhando com