Aula 1.

1 - Introdução à Engenharia de Software

Os processos de desenvolvimento de software estão cada vez mais sofisticados, dentro

das boas práticas de tecnologia da informação e comunicação e parte disso é resultado
da engenharia de software. O termo engenharia de software se tornou comum nos
diferentes constructos acadêmicos e profissionais da área de tecnologia de forma mais
ampla. Você já teve curiosidade em compreender o que é engenharia de software e
como ela surgiu?

É nessa perspectiva que conduzimos a Unidade 1. Há de se compreender, portanto, qual

a origem e o histórico da engenharia de software, bem como seus princípios e diferentes
áreas de conhecimento envolvidas nas etapas de desenvolvimento de software.

Esta Unidade está organizada em quatro seções que abordam, na sequência, os seguintes
conteúdos:

 Histórico.
 Conceitos e importância.
 Princípio de desenvolvimento de software.
 Áreas de conhecimento.

Bons estudos!

Objetivos

 Conhecer o histórico da engenharia de software.

 Compreender o conceito e a importância da engenharia de software.
 Relacionar os princípios de desenvolvimento de software.
 Conhecer as áreas de conhecimento correlatas às diferentes etapas de
desenvolvimento de software.

Desafio
Vamos visitar o Portal da IEEE Computer Society?

Acessando o Portal da IEEE Computer Society você vai poder navegar e ter acesso a
diferentes tipos de conteúdos da área de tecnologia da informação e comunicação, nos
âmbitos profissionais, educativos e de pesquisa e desenvolvimento. Nesse espaço, você
também pode fazer o download da versão mais atual do Guide to the Software
Engineering Body of Knowledge (SWEBOK Guide).
 Fonte: Computer.org, 2020.
O procedimento para download do SWEBOK é muito simples. Você precisa apenas
fazer um rápido registro, informando seu nome, propósito de uso do SWEBOK e o e-
mail para o qual deverá ser encaminhado o acesso ao arquivo .pdf do SWEBOK.

Conteúdo
Histórico

A engenharia de software surgiu no contexto da crise do software, como uma alternativa

de estruturar diferentes técnicas e metodologias para o desenvolvimento de softwares. A
crise do software aconteceu nos anos de 1970, decorrente dos problemas enfrentados
nas atividades de desenvolvimento de software em função da falta de padronização,
processos bem definidos, metodologias e documentação, essenciais para o ciclo de vida
de qualquer software.

Ainda nos anos de 1970, com a tecnologia em geral se constituindo e se tornando cada
vez mais comercial, os sistemas começaram a ter estruturas mais complexas e, em
paralelo, se tornaram também mais complexos os problemas decorrentes da falta de
documentação, de técnicas, de teste e de rastreabilidade.
A expressão crise do software foi utilizada pela Association for Computing
Machinery (1972), que foi a primeira associação dedicada à educação e ciência em
tecnologia. Como parâmetros para o estabelecimento da expressão crise do software,
a Association for Computing Machinery elencou (no âmbito de desenvolvimento de
software): o não cumprimento dos prazos; os orçamentos realizados que ultrapassavam
os orçamentos previstos; requisitos de software ausentes ou em não conformidade;
códigos confusos e de difícil manutenção; e consequente baixa qualidade de software.

Os recorrentes problemas apresentados pelos sistemas de baixa qualidade fizeram

emergir a necessidade do estabelecimento de métodos e técnicas que trouxesse
economia e efetividade para o processo de desenvolvimento de software com uso de
ferramentas específicas e também com a previsão de treinamento para todos os atores
envolvidos nas diferentes etapas do ciclo de vida de software. O ciclo de vida do
software, nesse contexto, refere-se à reunião dos processos, atividades e tarefas
envolvidas nas etapas de desenvolvimento, uso e manutenção de diferentes tipos de
software, desde a concepção da ideia de sua criação até o término de seu uso. De forma
sumária, as atividades fundamentais para o desenvolvimento de software são: análise e
definição de requisitos; prototipagem; codificação; testagem; e integração. Essas
atividades podem conter variações, incrementos ou adequações, dependendo do modelo
utilizado para o desenvolvimento de sistemas.

Figura 1 - Atividades Fundamentais da Engenharia de Software

Fonte: Elaborado pelo autor, 2020.

Para Mafra e Travassos (2006), considerando os problemas ocasionados pela
imaturidade nos processos de desenvolvimento de software, há de se posicionar algumas
questões para evitá-los (os problemas), tais como:

1. Em qual tecnologia investir, visto que existem várias possibilidades tecnológicas

e cada uma delas tem suas potencialidades e prometem aprimorar a
produtividade e a qualidade no desenvolvimento de software?
 2. Como metrificar o custo, o tempo e o esforço nos processos de desenvolvimento
de software?
3. Como aferir o retorno sobre o investimento?
4. Como avaliar as melhores circunstâncias para a recomendação e adoção de
diferentes tecnologias?

Em uma visão global do histórico da engenharia de software, há quatro eixos que

podem ser considerados: (i) a necessidade de profissionalização da área; (ii) o papel das
mulheres no contexto da tecnologia da informação e comunicação; (iii) a estrutura
processual; e (iv) os custos tanto de software, mas também dos hardwares envolvidos.

A necessidade de profissionalização da área de tecnologia da informação, assim como a

sua classificação como uma área de conhecimento, fez com que os processos de
desenvolvimento de software fossem repensados. Da mesma forma, os papéis e
responsabilidades dos envolvidos nas etapas de construção de software também
precisavam ter suas funções e atribuições definidas de modo a aprimorar o sistema de
informações em fábrica de software.

As mulheres tiveram papel de destaque na implementação das estruturas de

comunicação e informação informatizadas. Mulheres como Grace Hopper e Margaret
Hamilton contribuíram sobremaneira para o desenvolvimento das tecnologias que
dariam base para o contexto tecnológico atual. Grace Hopper, por exemplo, foi
responsável pelo desenvolvimento dos primeiros compiladores e também da ideia de
linguagens de programação independentes, e essa foi a gênese para a implementação do
COBOL. Ela foi cientista da computação e almirante da Marinha dos Estados Unidos da
América. Por outro lado, Margaret Heafield Hamilton, engenheira do laboratório de
instrumentalização de software do Massachusetts Institute of Technology (MIT). Mesmo
tendo nomes de expressão no histórico da engenharia de software e suas influências nas
tecnologias modernas, as profissões relacionadas à tecnologia da informação e
comunicação foram consideradas, por muito tempo, como predominantemente
masculinas. Entretanto, este cenário mudou e as mulheres estão cada vez mais presentes
no contexto das novas tecnologias da informação e comunicação, bem como no
universo das startups. Para Sousa e Melo (2009, p.3), as estatísticas sobre a inserção da
mulher nas esferas organizacionais refletem, como um fato já consolidado, o aumento
da participação feminina no mercado de trabalho brasileiro. As autoras apontam ainda
que o acesso mais amplo e mais frequente a cargos de liderança e comando também é
sinal da efetividade dessa mudança social.

A crescente participação da mulher no mercado de trabalho imprime novos contornos

às relações de gênero e de poder nas empresas. Esse fenômeno sinaliza movimentos e
processos de instalação do empoderamento da mulher. Associa-se ao alcance de bem-
estar e de reconhecimento das relações sociais, representando um desafio às relações
patriarcais e à manutenção dos privilégios do gênero masculino. Consiste na tomada
de consciência pela mulher de sua habilidade e competência para produzir, criar, gerir
e transformar sua própria vida e seu entorno, tornando-se protagonista de sua história
(SOUSA; MELO, 2009, p.1).
No eixo da estrutura processual, o estabelecimento de fluxos, processos, atividades e
tarefas tornou-se essencial para o desenvolvimento de qualquer tipo de sistemas de
informação. Por outro lado, demanda um trabalho analítico robusto para que o fluxo
informacional tenha suas entradas e saídas em conformidade às funcionalidades
previstas para os sistemas. Processo, neste contexto, é o termo designado para a divisão
do trabalho de desenvolvimento de software em fases (em nível macro); e também é o
termo utilizado para definir estruturas codificadas (em nível micro).

Sobre o eixo dos custos de software e hardware histórico dos processos de

desenvolvimento de projetos das organizações é muito importante para definir
orçamentos de manutenção de software. Se for possível medir o tamanho da nova
funcionalidade que será agregada ao sistema fica mais fácil definir o valor que a
manutenção representará para a empresa. Assim, os custos para a empresa podem
aumentar ou diminuir de acordo com as novas funcionalidades medidas. Se a
quantidade de nova funcionalidade for determinada e adicionada ao produto básico, o
custo unitário de manutenção pode de fato cair, enquanto o gasto real permanece
constante ou aumenta. Sobre a proporcionalidade dos custos de manutenção, caso estes
crescem e, ao mesmo tempo, a taxa de crescimento dos pontos de função for maior,
significa que as taxas de manutenção estão em decréscimo.

A engenharia de software tem acompanhado o aprimoramento das tecnologias da

informação e comunicação e, em sua linha do tempo, assumiu diferentes características,
desde as mais clássicas até as mais contemporâneas.

Figura 2 – Linha do Tempo

Fonte: Elaborado pelo autor, 2020.

O infográfico da linha do tempo do histórico da engenharia de software apresenta 05
(cinco) marcos principais. É claro que existem outros acontecimentos relevantes, mas
esses são os principais para o nosso contexto de desenvolvimento de software. O termo
engenharia de software foi definido entre 1945 e 1965, mas foi a partir deste período
que se estabeleceu, sobretudo, em função da crise do software como já apontamos. De
1985 até 1989, a importância dos projetos e programas de software emergiu,
metodologias mais definidas e geração de documentações robustas, processuais e
detalhadas. A Internet e, consequentemente, os sistemas baseados em Internet se tornam
mais massivos entre 1990 e 1999. Nos anos 2000, surgem as metodologias leves, ou
metodologias ágeis, com menor ênfase em documentação e maior ênfase em
produtividade.

Conceitos

Antes de definirmos o que é engenharia de software, vamos relembrar o que é software?

Software é o conjunto de blocos e componentes lógicos que processam dados por meio
de sistemas e computadores. Trata-se de um conjunto de instruções (rotinas) que
controlam o funcionamento de computadores e também as funcionalidades dos
sistemas. Ou seja, de forma sumária, software é a parte lógica do computador,
incluindo, basicamente, os sistemas operacionais e os demais programas ou sistemas
neles envolvidos.

E o que seria engenharia? Engenharia pode ser definida como uma área que reúne
regras, métodos, técnicas e ferramentas para a construção de algo, por meio do
conhecimento científico, técnico ou empírico.

Considerados os conceitos de software e engenharia, podemos chegar a uma definição

inicial sobre engenharia de software, como sendo o conjunto de métodos, técnicas e
ferramentas utilizadas para o desenvolvimento de softwares. Estes métodos permitem o
desenvolvimento, a gestão, a arquitetura e os testes de diferentes tipos de software.

Para Pressman (2006), a definição mais abrangente para a engenharia de software é

como a aplicação de uma abordagem sistemática, disciplinada e quantificável, com
vistas ao desenvolvimento, operação e manutenção do software, ou seja, aplicação da
engenharia de software.

Bauer (1972) definiu a engenharia de software como o estabelecimento e uso de sólidos

princípios de engenharia para que se possa obter um software economicamente viável,
que seja confiável e que funcione eficientemente em máquinas reais. Ou seja, para
superar os problemas da crise do software, utiliza-se a abordagem da engenharia ao
desenvolvimento de software, aliando processos de melhoria contínua, metodologias e
técnicas e ferramentas para ampliar a produtividade da equipe de desenvolvimento e
consequente qualidade do software (PRESSMAN, 2006).

Segundo Savi, Wangenheim e Borgatto (2011), a engenharia de software é a aplicação

de abordagens sistemáticas, disciplinadas e quantificadas ao desenvolvimento, operação
e manutenção de software. Ainda segundo os autores, o profissional que atua na área de
engenharia de software precisa entender e saber aplicar teorias, modelos e técnicas
correntes para sistematicamente analisar e desenvolver artefatos de software com
qualidade. Precisa ter conhecimentos sobre gerenciamento de projetos e ser capaz de
conciliar objetivos de projeto conflitantes e considerar questões organizacionais.
Também precisa ter habilidades de trabalho em equipe, liderança, negociação e
resolução de conflitos.

Figura 3 – Eixos Principais

Fonte: Elaborado pelo autor, 2020.

Trazendo a engenharia de software para o contexto da programação de computadores,
podemos definir três eixos: (i) teoria; (ii) abstração; e (iii) design. Transversal a estes
eixos, está a estrutura de dados, que é a unidade temática das áreas de tecnologia da
informação e comunicação responsável pelo estudo dos diversos mecanismos de
organização de dados para garantir o íntegro processamento do fluxo informacional.

O eixo teoria traz as definições, os axiomas, as provas e as interpretações para o

desenvolvimento de software. O eixo abstração define modelos, minimundos, modelos
para desenhar soluções, simplificações e compreensões de sistemas complexos. Por fim,
o eixo design apresenta os requisitos, as especificações de sistemas, modelagem e
design e processos de teste de software.

Qual seria, portanto, a diferença entre programas e softwares?

O termo programa está mais relacionado à informática, como sendo um conjunto de

códigos, rotinas e instruções que descrevem e executam comandos a serem realizados
por um computador. Trata-se de um conjunto de código fonte compilado, sequenciados
em linguagem de programação específica e com forma executável.

Figura 4 – Características fundamentais da Engenharia de Software

 Fonte: Elaborado pelo autor, 2020.
O termo software está mais presente no contexto da tecnologia da informação e
comunicação e se diferencia dos programas porque, mesmo sendo um conjunto de
código fonte compilado e executável, contém manuais com procedimentos operacionais,
além de documentação sobre sua concepção, estrutura, funcionalidade, modelos de
dados e documentação que garante sua escalabilidade e manutenção. O software não é o
mesmo o tempo todo. Isso quer dizer que existem variáveis externas e mudanças
tecnológicas que influenciam na sua continuidade e na sua adaptabilidade.

Princípios de Desenvolvimento de Software

Para a constituição das etapas de desenvolvimento de software no âmbito da engenharia

de software, foram estabelecidos princípios para os relacionamentos, metodologias,
tecnologias e ferramentas a serem alocadas para o desenvolvimento de produtos e
serviços de tecnologia da informação e comunicação. Ou seja, desde a concepção da
ideia do software, passando pelas etapas de desenvolvimento, até sua entrega e
utilização, são cadenciadas várias etapas que demandam, inclusive, perspectivas
multidisciplinares.

Lembre-se do conceito de engenharia de software apresentado na seção anterior. Apenas

para relembrarmos, apresentamos também o conceito do Institute of Electrical and
Electronics Engineers (IEEE) sobre engenharia de software, que a resume como a
aplicação prática e planejada da engenharia ao software, por meio de abordagens
metodológicas sistematizadas, disciplinada e metrificada ao seu desenvolvimento,
operação e manutenção (MOREIRA, 2012).

Figura 5 - IEEE

Fonte: IEEE, 2020.

O IEEE contém vários capítulos distribuídos em diferentes países, incluindo o Brasil e
se define como a maior organização do mundo de profissionais da área tecnológica
dedicados ao avanço da tecnologia em benefício da humanidade, com vistas à
diversidade, equidade e inclusão, usando a tecnologia para a redução das diferenças e da
discriminação.

A base da engenharia de software estabelecida em metodologias clássicas e ágeis, com

ferramentas e profissionais especializados premissas-chaves que apoiam o processo de
desenvolvimento de software como um todo. Aqui, podemos relacionar oito premissas:

1. Formalidade.
2. Ausência de conflitos de interesse.
3. Modularização.
4. Abstração.
5. Mudanças preditivas.
6. Requisitos.
7. Generalidade.
8. Incremento.

Por outro lado, Hooker (1999) já aspirava alguns princípios para a engenharia de
software. À ocasião, ele levantou sete princípios e os considerou como gerais porque
percebeu que poderiam ser adotados em todas as camadas da engenharia de software,
individualmente, ou no conjunto de camadas como um todo. Hooker (1999) elencou os
sete princípios como:

Figura 6 – Princípios da Engenharia de Software

 Fonte: Hooker, 1999. (Adaptado)
Observe que Hooker (1999) traz os princípios no imperativo, mas sua relação é mais
prospectiva no sentido de se ter, como engenheiro de software, uma visão ampla com
enfoque nos desejos do cliente, nas tecnologias emergentes e na adaptabilidade dos
sistemas de informação.

Tratando especificamente cada princípio, temos que:

1. A razão pela qual tudo existe (the reason it all exists): o software a ser
desenvolvido tem que ter um propósito específico para o cliente. Ou seja, o
cliente é o detentor de todos os requisitos funcionais e não funcionais e cabe a
ele tal definição. Para a engenharia de software cabe a análise de aplicabilidade
técnica e a transposição disso tudo ao contexto das tecnologias da informação e
comunicação, avaliando também sobre o que realmente é necessário ao negócio
do cliente como um todo, sobre o que é supérfluo e sobre o que realmente agrega
valor ao sistema de informações, seguindo as regras de negócio estabelecidas
pelo cliente. Assim, é importante que o engenheiro de software leve o seu cliente
a se questionar sobre a relevância das funcionalidades que pede implementação.
Caso exista dúvida, ou a resposta seja de que não é relevante, é melhor não
implementar e dedicar os esforços de desenvolvimento para os requisitos
essenciais. Justifique esse valor, pois esse é o princípio base para todos os
demais.
2. Mantenha as coisas simples (keep it simple): Hooker (1999) considera a
importância de se manter a simplicidade dos processos sem inibir sua
complexidade. Você sabe de onde veio a frase “menos é mais”? Ludwig Mies
van der Rohe foi um renomado arquiteto alemão, nacionalizado norte-
americano, que trouxe sofisticação aos traços da arquitetura com adoção de
traços geométricos claros, limpos, simples e sofisticados. Ele trouxe frases
famosas como “less is more” (menos é mais) para referir-se à questão de que a
 beleza está nas coisas simples; e “God is in the details” (Deus está nos detalhes),
para dizer que, não é preciso exagerar nas obras, pois basta o necessário
(SCHULZE, 1985). Esse preâmbulo é importante para que tenhamos em mente
que, os melhores sistemas de informação são aqueles que entregam exatamente o
que o cliente quer, sem burocracia, de forma integrada e correspondente ao
parque tecnológico de sua organização.
3. Mantenha o estilo/visão (maintain the vision): o software deve seguir a
identidade conceitual de seu requisitante, seja uma pessoa física ou uma pessoa
jurídica. Deve-se primar também pela compatibilidade de seus recursos aos
recursos já existentes nos demais serviços de tecnologia da informação e
comunicação da empresa. É preciso, portanto, manter a arquitetura da
informação coerente. Essa arquitetura de software que traz um sistema intensivo
é também descrita pelo IEEE, assim como há padronização pela ISO/IEC
42010:2007, o qual traz normas e padronizações para Sistemas e Engenharia de
Software - Prática recomendada para descrição de arquitetura de sistemas
intensivos de software (ISO/IEC/IEEE 42010:2011).
4. O que você produz, outros consumirão (what you produce, others will
consume): ao se desenvolver um determinado software, é preciso ter em mente
que outras pessoas o utilizarão e que isto se dará ao longo de um período, ou
seja, dentro do ciclo de vida do software. Então, deve-se primar por códigos
limpos, reutilizáveis, de fácil manutenção, atualização e escalabilidade. Pense
em “escrever códigos” dentro de diferentes “linguagens” de programação. Ou
seja, como uma escrita de um romance, uma obra literária, a escrita de códigos
também precisa ter lógica, coerência e clareza. Em todos os casos, é necessário
pensar em documentação.
5. Esteja aberto para o futuro (be open to the future): a tecnologia não para de
avançar. Então, todo desenvolvimento de software deve contemplar
possibilidades de portabilidade e de escalabilidade, bem como condições
arquitetônicas de integração, modulação e reuso. Por outro lado,
conforme Santos e Carvalho (2009, p.46), “com a acelerada mudança causada
pelas tecnologias da informação e comunicação (TICs), vários países do mundo
passam a estruturar normas para amenizar as desigualdades que as TICs podem
causar.” Observe que isso vale para todos os constructos sociais. Um exemplo
disso é o programa sociedade da informação:

O Programa Sociedade da Informação tem por objetivo indicar rumos

para os diversos setores da sociedade, a fim de enfocar melhor
diferentes iniciativas que conjuntamente contribuam para impactos
positivos das tecnologias de informação e comunicação [...] bem como
encurtar os atrasos aos países centrais (TAKAHASHI, 2000, p.27).

6. Planeje com antecedência, com vistas ao reuso (plan ahead for reuse): O
planejamento dos sistemas de informação é essencial. É preciso rascunhar,
desenhar, modelar os sistemas de informação. Quanto maior for o tempo em
planejamento, menor será o esforço. A visão sistêmica sobre o produto de
software leva à compreensão de suas potencialidades e possibilidades de reuso,
integração. Assim, dentro de uma perspectiva preditiva, os(as) profissionais em
engenharia de software devem analisar custos, esforços, módulos, possibilidades
e capacidades que o software possa vir a ter. Isso contribui sobremaneira para
que os clientes possam prospectar avanços e melhorias tecnológicas, outras
 possibilidades integrativas, avaliar o retorno sobre o investimento, bem como
sobre qual será o legado de sua tecnologia para sua instituição.
7. Pense (think): parece óbvio, mas este sétimo princípio é um dos mais
importantes. Analisar, refletir, experienciar, fazer testes, são ações que trazem
recompensas para os processos de desenvolvimento de software. Essas
recompensas podem ser figuradas como possibilidades de uso das tecnologias
mais apropriadas e também com tecnologias emergentes. Modelagem bem
pensada resulta em sistemas complexos e eficientes, orientados à modularização,
ao reuso, à integração e a um ciclo de vida estável.

Áreas de Conhecimento

A engenharia de software reúne diferentes áreas que são cadenciadas de forma

interdisciplinar, envolvendo diversas especialidades da área de tecnologia da
informação e comunicação.

Você conhece o SWEBOK? O Guide to the Software Engineering Body of

Knowledge (SWEBOK) é um guia que descreve um corpo de conhecimento sobre
engenharia de software, elencando 15 áreas de conhecimento (knowledge areas (KAs)),
resumindo conceitos básicos relacionados às etapas de desenvolvimento de software
(BOURQUE; FAIRLEY, 2014). O SWEBOK é mantido por uma comunidade de
tecnologia da informação e comunicação e regulado pela IEEE Computer
Society (BOURQUE; FAIRLEY, 2014).

O SWEBOK está em sua versão 3.0 SWEBOK Guide. Esse guia também tem
reconhecimento internacional pela ISO Technical Report 19759. O SWEBOK traz
novas ferramentas, métodos, tipos de software e boas práticas para o desenvolvimento
de software, desde a concepção da ideia de software até sua ambientação in loco,
considerando processos de métricas, estatísticas, volume entre outros elementos
inerentes ao planejamento de software. A Figura a seguir, por exemplo, é uma
adaptação do processo de definição inicial de objetivos, tal qual representado pelo
SWEBOK (BOURQUE; FAIRLEY, 2014).

Figura 7 - Processo de Definição Inicial de Objetivos

 Fonte: SWEBOK, 2014. (Adaptada)
A Figura anterior mostra a relação entre objetivos, estimativas e planejamento. Os
objetivos de software relacionam fatores externos à organização. Ou seja, trazem as
necessidades e regras de negócio, os requisitos funcionais e não funcionais definidos
pelos clientes e validados de forma colaborativa e também as expectativas de
orçamento. As estimativas de software relacionam fatores internos à organização, a qual
tem que avaliar suas capacidades e limitações e metrificar o esforço e a duração para o
desenvolvimento de software.

O planejamento deve ser obrigatório tanto para clientes quanto para desenvolvedores.
No caso dos desenvolvedores de software, é preciso dividir os objetivos, de forma
especificada, em atividades e marcos (milestones) de modo a facilitar a previsibilidade e
a construção modular. A abordagem ganha-ganha significa que, nos aspectos iniciais da
negociação, é importante que todos tenham vantagens (tanto clientes, quanto
organizações de desenvolvimento de software). Isso gera parceria e fidelização.

As 15 áreas de conhecimento (KAs) do SWEBOK (BOURQUE; FAIRLEY, 2014) são

classificadas de forma hierárquica correlacionando as etapas de desenvolvimento de
software, como uma alternativa para profissionalizar os processos de desenvolvimento
de software, mas também para delimitar as áreas, que podem ser denominadas de
disciplinas.

1. Requisitos de software.
2. Desenho de software.
3. Construção de software.
4. Testes de software.
5. Manutenção de software.
6. Gestão de configuração de software.
7. Gestão de engenharia de software.
8. Processos de engenharia de software.
9. Ferramentas e métodos.
10. Qualidade de software.
11. Prática profissional de engenharia de software.
12. Economia na engenharia de software.
13. Fundamentos de computação.
14. Fundamentos de matemática.
15. Fundamentos de engenharia.
Fundamentalmente, as dez primeiras áreas de conhecimento referem-se às etapas de
linha de produção de software: (1) requisitos, (2) projeto, (3) construção, (4) testes, (5)
manutenção, (6) configuração, (7) gerenciamento, (8) processo, (9) ferramentas e
métodos, (10) qualidade. De forma geral, o objetivo é a promoção de uma visão
holística da engenharia de software (BOURQUE; FAIRLEY, 2014).

1. Requisitos de software: ao levantar os requisitos de software e requisitos de

sistemas, é preciso defini-los em funcionais ou não funcionais, com base em
técnicas apropriadas, elencando processos e propriedades emergentes. Sobre os
processos, são definidos os modelos atores, processos de gestão, suporte,
qualidade e melhorias. A análise de requisitos é feita considerando a perspectiva
conceitual e a perspectiva arquitetônica do software. Os requisitos são
prototipados e validados com a apresentação de documentação completa.
2. Desenho de software: os fundamentos de desenho de software trazem o
conceito e o contexto do software, considerando elementos gráficos, de interface
com usuário, acessibilidade e qualidade, ergonomia e esquemas de interação,
localização e internacionalização. Esta área de conhecimento também contempla
famílias de programas e Frameworks, além das definições de padrões e estilos
arquitetônicos. Questões de concorrência, controle de eventos e persistência de
dados também são desenvolvidas nesta área de conhecimento.
3. Construção de software: nesta área de conhecimento, são definidas e também
construídas tecnologias, com base em planejamento e métricas, visando a
redução de complexidade, antecipação de mudanças e construção de códigos
verificáveis, padronizados e reutilizáveis. O desenvolvimento de APIs,
parametrização, exceções, tolerância a falhas, middleware também são
realizados na área de conhecimento construção de software. Há outros
elementos, como ajuste fino e análise de performance, ambientes de
desenvolvimento e ferramentas de teste unitário e para construção de GUI.
4. Teste de software: a área de conhecimento de teste de software traz as
questões-chaves, critérios avaliativos e terminologias relacionadas aos processos
de testagem com princípios e técnicas bem definidas. Os testes são realizados
conforme os níveis, alvos e objetivos definidos pela equipe de desenvolvimento
de software. Para a realização dos testes de software são definidas técnicas
específicas que podem ser baseadas em código, falhas, uso, modelos, entre
outras.
5. Manutenção de software: para que os processos de manutenção de software
sem efetivos, é preciso que se estabeleçam técnicas de compreensão de
programa, reengenharia, engenharia reversa, migração e avaliação de
descontinuidade.
6. Gestão de configuração de software: a gestão de conhecimento de software é
realizada por meio de planejamento com base em contextos organizacionais,
definição de premissas e restrições e a elaboração de um planejamento
específico que preveja requisição, avaliação e aprovação de serviços de
mudança. Em paralelo, são definidos processos de auditoria de software, tanto
sob perspectiva funcional quanto física.
7. de engenharia de software: a iniciação e a definição do escopo de software são
itens geridos por esta área de conhecimento que determina e negocia todos os
requisitos, características e outros processos de software. Nesse contexto, são
avaliados os riscos, a qualidade, os recursos alocados e os esforços envolvidos
para o desenvolvimento de software. Os riscos precisam ser classificados
 conforme sua complexidade. Por outro lado, há de se definir o plano de
implementação que preveja critérios de aquisição, contratação e fornecimento,
incluindo avaliação de terceira parte.
8. Processo de engenharia de software: a gestão e infraestrutura de processos de
software definem ciclo de vida de software, relacionando categorias, modelos e
métodos, com vistas à qualidade do sistema de informações.
9. Métodos e modelos de engenharia de software: os princípios da engenharia de
software compõem a modelagem de software, sejam comportamental ou
estrutural, como um todo, envolvendo elementos de sintaxe, com condições, pré
e pós condições, análise semântica e pragmática, relacionando sistemas
completos, corretos e rastreáveis.
10. Qualidade de software: conceituar o que é qualidade não é uma tarefa tão
simples porque varia muito dependendo da área. Então, para área de tecnologia
da informação e comunicação, a qualidade pode ser metrificada por alguns
pontos, tais como custo, tempo de entrega, escopo, segurança, padrões de cultura
e ética. A verificação da qualidade deve ser feita com técnicas que contenham
critérios claros e objetivos.

Finalizando a Unidade

Esperamos que você tenha apreendido, após a leitura desta Unidade, os aspectos
introdutórios relacionados à engenharia de software, no contexto da tecnologia da
informação, bem como os princípios envolvidos nas áreas e etapas de desenvolvimento
de softwares especialistas e generalistas.

Especificamente, você teve a oportunidade de navegar em conteúdos relacionados ao

histórico da engenharia de software, relacionando sua importância, princípios e
diferentes áreas de conhecimento envolvidas nas etapas de desenvolvimento de
software.

Dica do Professor
Para saber um pouco mais sobre os aspectos introdutórios e outras curiosidades
relacionadas à engenharia de software, recomendamos a leitura do relatório técnico de
Lima et al. (2014), publicado em 2014, que traz possíveis ameaças à validade de
experimentos que envolvam prática ágil em metodologia de pair
programming (programação em pares). Você pode acessar essa obra buscando a
seguinte referência nas bases científico-acadêmicas:

LIMA, Vagner Carlos Marcolino; NETO, Adolfo Gustavo Serra Seca; EMER, Maria
Claudia Figueiredo Pereira. INVESTIGAÇÃO EXPERIMENTAL E PRÁTICAS
ÁGEIS: AMEAÇAS À VALIDADE DE EXPERIMENTOS ENVOLVENDO A
PRÁTICA ÁGIL PROGRAMAÇÃO EM PAR. Revista Eletrônica De Sistemas de
Informação, v. 13, n. 1, p. 1, 2014.

Saiba Mais
Você sabia que a carreira do(a) engenheiro(a) de software é regulada por um conselho
profissional?

É isso mesmo. O registro profissional habilita o(a) profissional para o pleno exercício
da sua função, de forma regulamentada, com funções, atribuições, responsabilidades,
direitos e garantias muito bem definidas.

As profissões relacionadas às diferentes áreas de tecnologia da informação e

comunicação são consideradas profissões do futuro pelo seu potencial transformador,
inclusivo e direcionado às diferentes necessidades das pessoas, sobretudo com o
desenvolvimento de inteligência artificial. Nesse contexto, o Brasil figura a primeira
posição da América Latina e está dentro dos dez países do mundo em mercado de
softwares.

Voltando ao contexto da formação em engenharia de software, desde 2018, a profissão

passou a ser regulamentada com registro junto ao Conselho Regional de Engenharia e
Agronomia (CREA), o qual demanda habilidades e competências essenciais para a
atuação na área.

Assista ao vídeo “O que um Engenheiro de Software faz?”, do canal Código Fonte TV.
O vídeo tem aproximadamente 8 minutos e traz interessantes reflexões sobre a
profissão.

Aula 1.2 - Introdução a Requisitos de Software

Introdução

Ao desenvolver um projeto, serviço ou produto, geralmente, é necessário que sejam

especificados os seus requisitos. Essa é uma atividade presente em vários contextos. O
projeto de desenvolvimento de um avião, por exemplo, contém requisitos de segurança,
aerodinâmica, autonomia de voo, quantidade de assentos, carga a ser transportada, além
de inúmeros outros. Assim como a criação de um novo automóvel também necessita da
especificação dos seus requisitos, como tipo de combustível, espaço interno, potência do
motor, características específicas para o público-alvo etc.

Além disso, em todas as disciplinas de engenharia, após a definição dos requisitos, é

necessário propor modelos que, baseados nesses requisitos, guiarão o desenvolvimento
dos vários equipamentos que irão compor o produto final, como peças, aparelhos,
circuitos, ou qualquer outra característica previamente definida.

Outro subsídio importante para o desenvolvimento desses produtos é

a metodologia escolhida. A conjuntura obtida entre a boa condução dessa proposta
metodológica, com o levantamento adequado dos requisitos, e modelos bem
construídos, é essencial para o sucesso de um projeto.

Requisitos de Software

Independentemente da metodologia de desenvolvimento escolhida, a confecção do

sistema sempre contará com a etapa de requisitos. Por meio deles é que somos capazes
de saber o propósito do sistema, para que ele servirá, quais serão as necessidades a
serem atendidas, os objetivos a serem alcançados, como será a forma de trabalho no
sistema, as suas regras de negócio, além das restrições dos mais variados tipos, como as
tecnológicas, as legais, as comportamentais, entre outras.

Booch, Rumbaugh e Jacobson (2005, p.246) definem requisito como:

Uma característica de projeto, uma propriedade ou um comportamento de um sistema.

Ao estabelecer os requisitos do sistema, você está declarando um contrato,
estabelecido entre as coisas externas ao sistema e o próprio sistema, declarando o que
se espera que seja feito pelo sistema. Na maior parte, você não precisa se preocupar
com o que o sistema faz, você deve apenas cuidar para que ele o faça.
Figura 1 – Nem sempre é simples para o cliente fazer-se entender.

Fonte: https://goo.gl/HfX2JX
Conforme ilustrado na figura 1, a atividade de levantamento de requisitos é fundamental
para o sucesso ou fracasso de um software. Requisitos mal levantados e/ou mal
especificados comprometem todo o projeto. Caso seja levado adiante um projeto
inicialmente defeituoso, pode ser bastante difícil reverter a situação. Geralmente, quanto
mais tarde for feita a correção dos requisitos, mais caro será o projeto.

Imagine que o requisito tenha sido levantado, o sistema tenha sido projetado,
construído, testado e, só então, quando a funcionalidade implementada chegou para o
solicitante (cliente), foi verificado que daquela forma o sistema não atende aos anseios
do usuário. Veja quanto desperdício de tempo, dinheiro e recursos em geral! O custo de
manutenção também aumenta exponencialmente quando o requisito mal especificado
for corrigido somente após a implementação.

Entretanto, quando bem especificados, os requisitos fazem com que o sistema atenda ao
propósito estabelecido pelo solicitante. Os requisitos estabelecidos se transformarão nas
funcionalidades geradoras das informações previamente esperadas pelo usuário, com
isso, o projeto terá mais qualidade e mais chances de cumprir o cronograma e os custos
preestabelecidos.

Na metodologia de desenvolvimento de software, os requisitos de software são

encarados como uma disciplina, que possui as seguintes finalidades:

 Estabelecer e manter concordância com os clientes e outros investidores sobre o

que o sistema deve fazer.
 Oferecer aos desenvolvedores do sistema uma compreensão melhor dos
requisitos do sistema.
 Definir os limites do sistema (ou delimitar o sistema).
 Fornecer uma base para planejar o conteúdo técnico das iterações.
 Fornecer uma base para estimar o custo e o tempo de desenvolvimento do
sistema.
 Definir uma interface de usuário para o sistema, focando as necessidades e
metas dos usuários.

Para Refletir

Analise a charge da figura 2:

Figura 2 - Código de Barras.

Fonte: https://goo.gl/BLi6yC
Será que a mensagem apresentada pelo sistema está correta? O que você pensa que saiu
errado na produção desse sistema?

Existe alguma relação do que está acontecendo com os requisitos de software?

Analisando a situação, provavelmente, a mensagem especificada para ser implementada

no terminal foi a seguinte: “LEIA O CÓDIGO DE BARRAS”. Caso o desenvolvedor
tivesse se colocado no lugar do usuário, levando em consideração que nem todos têm a
mesma familiaridade com os equipamentos eletrônicos, e tivesse definido a mensagem:
“POSICIONE O DOCUMENTO PARA A LEITURA DO CÓDIGO DE BARRAS”,
certamente geraria menos dúvidas, sim?

Tipos de Requisitos de Software

Segundo Kotonya e Ian Sommerville (1998), existem vários tipos de requisitos, tais
como:

 Requisitos genéricos, que estabelecem, em linhas gerais, o que o sistema deve

fazer. Um exemplo deve permitir que o cliente consiga fazer tudo o que for
preciso para realizar negócios com a empresa.
 Requisitos funcionais, que definem partes de funcionalidades dos sistemas. Um
exemplo de requisito funcional seria a funcionalidade Cadastrar Cliente.
 Requisitos de implementação, que dizem como o sistema deve ser
implementado. Um exemplo desse requisito seria que o sistema deve ser
desenvolvido na linguagem Java.
 Requisitos de performance, que especificam o mínimo aceitável para o
desempenho do sistema. Um exemplo desse requisito seria que o sistema deve
executar as suas transações com o tempo mínimo de um segundo.
 Requisitos de usabilidade, que demonstram como o sistema deve ser usado. Um
exemplo desse requisito seria que o sistema deve executar as suas transações
com o mínimo de cliques possível.

Além dessa classificação, os requisitos também podem ser classificados

como funcionais e não funcionais, conforme abordado a seguir.

Requisitos Funcionais

Os requisitos funcionais são aqueles que delineiam o comportamento do sistema. Eles

especificam as ações que um sistema deve ser capaz de executar, ou seja, descrevem o
que se espera que o software faça. Os requisitos funcionais estabelecem as
funcionalidades de que o sistema deve dispor, pois especificam o comportamento de
entrada e saída do sistema. Podemos citar como exemplos de requisitos funcionais, o
cadastramento de clientes, a realização de um saque em conta corrente, a emissão de
uma nota fiscal, ou mesmo a realização de uma venda.

Requisitos Não Funcionais

Os requisitos não funcionais são aqueles que expressam como o sistema deve ser feito.
Eles descrevem atributos do sistema ou atributos do ambiente do sistema. Em geral,
relacionam-se com padrões de qualidade, como confiabilidade, performance, robustez
etc. Os requisitos não funcionais também são essenciais, pois definem o grau de
eficiência para a tarefa a qual o sistema se propõe a fazer. Portanto, eles indicam as
qualidades do sistema, enfatizando as características que ele deverá possuir.

Podemos citar os seguintes exemplos de requisitos não funcionais:

 o sistema deve ser desenvolvido na linguagem Java;

 o sistema deve ter seus dados copiados diariamente, no final do dia;
 o sistema deve ter condições de identificar quem realizou as transações com a
criação de log;
 o sistema deve ser preparado para ser executado em rede;
 o sistema deve estar disponível de segunda a sexta-feira, das 7h às 22h.
Veja que, nessa classificação, os requisitos não funcionais englobam as definições de
implementação, performancee usabilidade, propostas por Kotonya e Ian Sommerville
(1998).

Outras Observações

Como existem vários tipos diferentes de requisitos, não é possível definir padrões de
escrita ou definir a melhor maneira de especificação de requisitos. Isso dependerá de
quem escreve, de quem lê, do domínio de aplicação do sistema e das práticas gerais de
organização e desenvolvimento dos requisitos.

Para garantir que toda essa prática de levantamento e classificação dos requisitos,
negociação com os clientes e gerenciamento dos possíveis problemas seja trabalhada de
maneira eficiente, a ponto de resultar em uma especificação clara e organizada, é
necessário fazer uso da engenharia de requisitos.

Esse assunto será amplamente explorado na próxima aula, na qual conhecerá detalhes
de todas as etapas que compõem a Engenharia de Requisitos.

Para Refletir

Suponha que um determinado cliente solicitou a você que desenvolva uma aplicação
para ser implantada em uma nova loja que ele pretende inaugurar nos próximos meses.

Em um levantamento inicial, o sistema necessita que sejam criadas transações para

cadastrar os clientes, cadastrar os produtos, gerar um orçamento inicial para o cliente,
finalizar uma venda a partir do orçamento e emitir a nota fiscal. Esse sistema será
executado em computadores com o sistema operacional Windows, os dados
armazenados no MySQL e os computadores estão interligados por uma rede interna.

Pense nos requisitos iniciais desse projeto e procure identificar quais são os Requisitos
Funcionais e Não Funcionais.

Para pensar a respeito dos requisitos iniciais, lembre-se dos conceitos de requisitos
funcionais, que são as funcionalidades que serão desenvolvidas para atender os
processos de negócios do cliente, e que os requisitos não funcionais serão os requisitos
que darão suporte ao funcionamento dos requisitos não funcionais.

Nesta aula, você observou que, ao se desenvolver um projeto, serviço ou produto,

geralmente, é necessário que sejam especificados os seus requisitos. Por meio deles é
que somos capazes de compreender o propósito do sistema, para que ele servirá, quais
serão as necessidades a serem atendidas, quais são os objetivos a serem alcançados,
como será a forma de trabalho no sistema, entre outras coisas. Na próxima aula, você
estudará o processo de engenharia de requisitos que visa garantir que o sistema
gerado por esses requisitos atenda adequadamente às necessidades e satisfaça as
expectativas dos clientes.

Até mais!
 Aula 1.3 - Engenharia de Requisitos de Software
Introdução à Engenharia de Software

Segundo Pressman (2006), o processo de engenharia de requisitos visa garantir que o

sistema gerado por esses requisitos atenda adequadamente às necessidades e satisfaça as
expectativas dos clientes. O autor afirma ainda que:

a engenharia de requisitos fornece um mecanismo adequado para entender o que o

cliente deseja, analisar as necessidades, avaliar a exequibilidade, negociar uma
solução razoável, especificar a solução de maneira não ambígua, validar a
especificação e administrar os requisitos à medida que eles são transformados num
sistema em operação. (PRESSMAN, 2006, p.250)
Assim, com o processo de engenharia de requisitos, espera-se que o sistema atenda ao
propósito estabelecido e atinja o objetivo esperado pelo cliente. Perceba que este é um
processo complexo que exige muita habilidade do engenheiro de software, conhecido no
mercado como analista de requisitos.

Ainda assim, esta é uma atividade que independe de paradigma. Seja qual for o
paradigma de engenharia de software adotado, a análise de requisitos deverá ser levada
em consideração e, quanto mais sólida e bem feita for essa atividade, maiores as
chances de se chegar a um projeto que tenha qualidade.

Continuando com Pressman (2006), o processo de engenharia de requisitos pode ser

descrito em cinco passos distintos, a saber: elicitação de requisitos, análise e negociação
de requisitos, especificação de requisitos, validação de requisitos e gestão de requisitos.
A seguir, você estudará cada um deles.

Elicitação de Requisitos

Esta etapa consiste em retirar a correta informação dos clientes. É necessário perguntar-
lhes qual será o propósito do sistema, quais as informações a serem geradas pelo
sistema e que serão necessárias para o negócio, e como será a utilização do sistema.
Apesar de parecer fácil, na prática, pode não ser assim tão simples. Pressman (2006)
aponta alguns motivos que podem gerar dificuldades no processo de elucidação dos
requisitos.

 Problemas de escopo: os limites do sistema são mal definidos. Muitas vezes, não se
sabe ao certo quais os assuntos abrangidos e até onde o sistema deve ir. Há
clientes/usuários que especificam detalhes técnicos desnecessários, que podem
confundir, no lugar de esclarecer.
 Problemas de entendimento: os clientes/usuários, muitas vezes, não entendem
completamente o domínio do problema, não sabem direito o que é ou não necessário,
têm dificuldade de comunicar as necessidades ao analista de requisitos, omitem
informações que acreditam ser “óbvias”, especificam mal os requisitos, sendo
conflitantes com os requisitos de outros usuários, ambíguos ou mesmo impossíveis de
se testar.
 Problemas de volatilidade: um requisito pode ser visto de maneiras diferentes por
pessoas diferentes. Isso pode gerar mudanças nos requisitos, à medida que o projeto se
encontra em andamento. Da mesma forma, os processos de negócios também evoluem e
mudam com o tempo e isso pode representar mudanças nos requisitos do sistema.
O levantamento ou elicitação de requisitos de um sistema consiste de uma etapa muito
importante no desenvolvimento de projetos. Um bom levantamento de requisitos poderá
poupar tempo e dinheiro no decorrer do projeto. Entender aquilo que o cliente deseja
(ou o que o cliente acredita que precisa) e compreender as regras do negócio, também
chamadas de processos do negócio, consiste no cerne que move essa questão. Aliado ao
levantamento de requisitos existe o mapeamento dos processos, vital para a melhoria
dos resultados obtidos pelo levantamento de requisitos.

Levantamento de requisitos é o nome comumente usado para a atividade de descoberta

dos requisitos.

Pressman (2006) utiliza a expressão “elicitação de requisitos”, neologismo do

inglês requirements elicitation, também muito vista nas várias edições do
livro Requirements Engineering de Kotonya e Ian Sommerville (1998). Nesta
disciplina, será adotada a expressão levantamento de requisitos, a qual é bastante
difundida na indústria de desenvolvimento de software.

Saber exatamente o que o cliente quer pode parecer uma atividade simples, mas,
infelizmente, não é. Pelo contrário, essa tarefa é bastante complexa e difícil de ser
executada. Isso ocorre por vários motivos. Pressman (2006) cita alguns deles, a saber: o
volume de informações a ser considerado pode ser bastante extenso, pode ocorrer a má
informação por parte dos clientes/usuários, pode ocorrer a má interpretação por parte
dos analistas de requisitos, as compreensões das partes envolvidas podem estar sujeitas
a ambiguidades, entre outros.

O cliente/usuário, na grande maioria das vezes, começa a solicitação com a expressão:

“Eu só queria um sisteminha... coisa simples... basta um cadastro...”. No entanto,
quando paramos para analisar a demanda do usuário, descobrimos que não é bem assim.
Naturalmente, surgem novas demandas, necessidades antes ignoradas são incorporadas,
informações tornam-se essenciais e passam a ser requeridas e a tendência normal do
sistema é crescer. Não é incomum você encontrar no mercado um sistema que passou
pela fase de modelagem de negócios com um determinado tamanho e dobrou, ou até
triplicou esse tamanho, quando começou a etapa de levantamento de requisitos e/ou de
construção.

Além disso, o cliente/usuário, muitas vezes, não passa a informação de maneira correta,
ou passa de maneira incompleta. Isso, na grande maioria das vezes, não é por mal ou de
propósito, simplesmente acontece, seja por não ter uma visão do todo, ou por ter uma
compreensão equivocada do domínio do problema, ou ainda por não saber passar a
informação adiante. É comum, por exemplo, o cliente dizer uma coisa e seu interlocutor
entender outra.

Porém, o contrário também pode ser verdadeiro. Muitas vezes, o usuário diz o correto,
de maneira bastante clara, mas falta o entendimento completo do domínio do problema
por parte do analista de requisitos; assim, ele entende algo de maneira equivocada
daquela que foi expressa pelo cliente/usuário.

As ambiguidades acontecem porque, geralmente, consultam-se várias pessoas com

visões diferentes sobre o mesmo problema. São diferentes conhecimentos,
entendimentos diversos sobre o domínio do problema, divergências sobre o assunto a
ser tratado, pretensões antagônicas dentro da corporação e vários outros motivos.

Sommerville e Kotonya (1998) mostram quatro dimensões do processo de levantamento

de requisitos: domínio da aplicação, problema a ser resolvido, necessidades e restrições
dos stakeholders, e contexto do negócio.

Figura 1 – As Quatro Dimensões do Levantamento de Requisitos.

Fonte: Adaptado de Sommerville e Kotonya (1998, p.55)

A figura 1 representa as dimensões do processo de levantamento de requisitos. Leia com

atenção as explicações sobre cada uma dessas dimensões:

 Entendimento do domínio da aplicação – Consiste em ter um conhecimento geral da

área onde o sistema será aplicado. Por exemplo, para um sistema acadêmico
universitário, você terá que entender como é o funcionamento de uma universidade.
 Problema a ser resolvido – Os detalhes específicos dos problemas do contexto em que
o sistema será instalado devem ser entendidos. Durante o entendimento do problema,
você se especializa e amplia o conhecimento do domínio geral da aplicação. Em um
sistema acadêmico, você deve saber como é o processo de matrícula, como será a
escolha das disciplinas pelos alunos, entre muitos outros conhecimentos.
  Entendimento do negócio – Os sistemas, geralmente, existem para apoiar algum
negócio. Você deverá saber como o sistema afetará o negócio da organização, como
funcionará a interação com as diversas áreas do negócio, e como ele ajudará a atingir os
objetivos do negócio.
 Necessidades e restrições dos stakeholders – Stakholders são aquelas pessoas que são
afetadas, de alguma maneira, pelo sistema. Podem ser usuários finais, gerentes de
departamento da empresa na qual o sistema será instalado, gerentes de projeto,
projetistas, desenvolvedores, clientes, patrocinador do projeto etc. Você deve entender,
em detalhes, suas necessidades, como o sistema apoia seu negócio. Você deve entender
os processos de trabalho que o sistema automatizará e os papéis existentes no sistema
nesses processos de trabalho.

Continuando com Sommerville e Kotonya (1998), vemos que um bom processo de

levantamento de requisitos deve incluir quatro atividades críticas, conforme ilustrado na
figura 2.

a) Definição de Objetivos
Neste estágio, devem ser estabelecidos os objetivos globais da organização, metas
genéricas do negócio, descrição do problema a ser resolvido, por que o sistema pode ser
necessário, restrições do sistema como orçamento, cronograma e restrições de
interoperabilidade.

b) Aquisição de Conhecimento Organizacional

Este é um estágio muito importante, em que os analistas de requisitos recolhem e
entendem informações básicas essenciais sobre o sistema. Essas informações podem ser
sobre onde o sistema será instalado, sobre o domínio da aplicação, ou mesmo sobre
algum sistema que porventura exista, e que será substituído pelo que está sendo
especificado.

c) Organização do Conhecimento
O conhecimento adquirido nas etapas anteriores deve ser reunido e organizado. Deve
haver a identificação dos envolvidos, seus papéis na organização, priorização de
objetivos e o descarte do conhecimento que não contribuirá diretamente para os
requisitos do sistema.

d) Coleta dos requisitos dos stakeholders

Este estágio é o que muitas pessoas acreditam ser o levantamento de requisitos
propriamente dito. Ele envolve a consulta aos envolvidos, para descobrir seus requisitos,
a derivação dos requisitos oriunda do domínio da aplicação e a organização que está
adquirindo o sistema.

Observe a figura 2, que apresenta um processo genérico de levantamento de requisitos.

Figura 2 – Processo Genérico de Levantamento de Requisitos.

Fonte: Sommerville e Kotonya (1998, p.59)

Na figura 2, você pode observar que existem quatro caixas, com algumas atividades que
devem ser realizadas, comentadas a seguir:

 Estabelecimento dos objetivos do levantamento de requisitos, em que existe a

necessidade de entendimento dos objetivos, dos problemas que devem ser solucionados
e das restrições do sistema.
 Compreender a estrutura, em que é necessário verificar a estrutura da organização, dos
domínios das aplicações e quais são os sistemas existentes nela.
 Organização do conhecimento, identificando os stakeholders, priorizando as metas e
filtrando os domínios existentes em termos de conhecimentos.
 Coleta de requisitos, na qual são ouvidos os stakeholders identificados anteriormente,
entendendo o domínio de todos os requisitos coletados e organizando-os.

Para Refletir

Faça uma reflexão sobre a charge apresentada na figura 3:

Figura 3 – Entendimento dos Requisitos.

Fonte: https://goo.gl/LvNhhA
Muitas vezes, um analista de requisitos se depara com uma situação parecida com a
apresentada na charge. Para coletar os requisitos do software, muitas vezes, o próprio
cliente não sabe exatamente o que quer. Em situações como essa, o analista de
requisitos deve utilizar todos os seus conhecimentos e técnicas para entender
exatamente o que precisa ser feito para atender bem o cliente.

Técnicas de Levantamento de Requisitos

Podemos encontrar várias técnicas de levantamento de requisitos. A literatura está cheia

delas. Pressman (2006) cita algumas, que serão abordadas nos tópicos a seguir.

Entrevista
Esta é uma das técnicas mais utilizadas. Pressman (2006) faz analogia com o primeiro
encontro de adolescentes, em que ninguém sabe o que dizer, o que fazer, o que
perguntar, com medo de ser mal compreendido.

Gause e Weinberg (apud PRESSMAN, 2006) aconselham a formulação de questões

livres de contexto. O objetivo dos primeiros encontros é possuir um entendimento
básico do problema, um conhecimento genérico sobre a organização, sobre o domínio
do problema e sobre os stakeholders envolvidos. As primeiras perguntas devem ter foco
no cliente, nos objetivos globais da organização, e nos benefícios que o sistema trará
para a organização. Seguem alguns exemplos de perguntas propostas por Pressman:

 Quem é o patrocinador do projeto?

 Quais serão os usuários do sistema? [não literal]
 Quais serão os benefícios de ordem econômica, fornecidos pelo sistema para a
organização?
 Há outra fonte para a solução que você necessita?
 Existe um sistema, mesmo que não informatizado, que atende ao processo de negócio?
 Caso o sistema seja implantado, quais serão os benefícios para a organização?
 Haverá redução nos custos dos processos?

Questões desse tipo são capazes de identificar os envolvidos no projeto e,

consequentemente, os benefícios que serão alcançados com a construção do sistema em
questão.

Pressman (2006) também propõe outras questões importantes, que permitem ao analista
de requisitos compreender melhor o domínio do problema e ambientar-se com os
assuntos da organização, obrigando o cliente a verbalizar seus pensamentos e,
principalmente, dizer como ele imagina o funcionamento da solução:

 Como você caracterizaria boas saídas as quais seriam geradas por uma solução bem-
sucedida?
 Quais os problemas que essa solução enfrentaria?
 Você pode mostrar (ou descrever) o ambiente no qual a solução será utilizada?
 Tópicos especiais de desempenho ou restrições afetarão o modo pelo qual a solução é
abordada?

Gause e Weinberg (apud PRESSMAN, 2006) propõem a elaboração de uma lista

abreviada de meta-questões, capazes de conceder efetividade à reunião:
  Você realmente está apto a responder essas questões?
 Em relação a este assunto, você oficialmente responde pela empresa?
 As questões levantadas são relevantes para o seu problema?
 Você está respondendo a muitas questões?
 Existe outra pessoa que pode fornecer outra informação?
 Há alguma outra questão que deixei de perguntar e que gostaria de comentar?

A técnica de entrevista ajuda a estabelecer um bom relacionamento entre a equipe de

projeto e os clientes/usuários. Ela possibilita a definição de um escopo, completa as
informações para solicitação do produto, mas, segundo Pressman, deve ser usada apenas
no início, pois depois passa a não ter a mesma eficácia. Portanto, essa solução sozinha
passa a não ser mais suficiente.

Segundo Sommerville e Kotonya (1998), há dois tipos de entrevista:

1. Entrevista fechada, em que os clientes/usuários respondem um conjunto fechado de

perguntas.
2. Entrevista aberta, em que não existe uma agenda pré-definida. Começa com um
pequeno número de questões pré-definidas, mas depois as perguntas e respostas são
abertas e há uma discussão entre analistas e clientes, em que os usuários dizem o que
eles querem do sistema.

Existem mais dois tópicos importantes que devem ser levados em consideração ao se
fazer uma entrevista:

 O analista de requisitos deve possuir mente aberta e estar disposto a ouvir o

cliente/usuário, pois, caso não haja disposição por parte do analista, fica difícil
encontrar um ponto a ser explorado, deixando a entrevista muito vaga e pouco
aprofundada.
 Os clientes/usuários devem ser o ponto de partida para a discussão. Pode ser uma
pergunta, uma proposta de requisitos, ou um sistema já existente. Simplesmente dizer
“me diga o que você quer” não trará informações úteis. Em geral, as pessoas acham
mais fácil falar quando há um contexto bem definido do que falar em termos gerais,
sem um direcionamento.

FAST
Em muitos casos, o relacionamento entre as equipes começa a ficar desgastado. Muitas
vezes, há uma guerra não declarada entre a equipe de projeto e os clientes/usuários. Um
festival de documentos para serem assinados, gerentes de projeto tentando fazer
homologações “à força”, clientes afirmando que pediram determinada funcionalidade e
não foram atendidos, usuários reclamando de um determinado comportamento que não
funciona da maneira esperada por ele, enfim, vários mal-entendidos entre as equipes e
também problemas de relacionamento.

A solução proposta por Pressman (2006) para o problema relatado acima é o FAST, do
Inglês: Facilitated Application Specification Techniques. Essa técnica prega a união
entre as equipes, tanto a de projeto quanto a de clientes/usuários, com o objetivo de
identificar os problemas e encontrar soluções conjuntas. Também prega a negociação de
diferentes abordagens, para que se estabeleça um consenso e a especificação de um
conjunto preliminar de requisitos, para que assim o projeto possa andar de maneira
eficiente.
Existem duas implementações bastante difundidas do FAST, o projeto conjunto de
aplicações – JAD, Joint Application Design – da IBM, e o METHOD, da Performance
Resources.

Leia com atenção as diretrizes básicas para uma reunião FAST:

 Reunião em lugar neutro, com analistas e clientes.

 Estabelecimento de regras para preparação e participação.
 A proposição de uma agenda que seja formal, capaz de cobrir os pontos importantes e,
ao mesmo tempo, informais, para encorajar o fluxo de ideias.
 A presença de um facilitador, podendo ser um cliente, desenvolvedor ou uma pessoa de
fora, que controla a reunião.
 A utilização de um mecanismo de definição, que podem ser folhas de
rascunho, flipchart, papel autoadesivo, quadro de avisos eletrônico, salas de conversa
ou mesmo um fórum virtual.
 Estabelecer como meta a identificação do problema, propor soluções, negociar
abordagens diferentes, especificar um conjunto preliminar de requisitos da solução.

Nos dias anteriores à reunião, algumas listas devem ser solicitadas aos participantes, tais
como:

 Lista de objetos que cercam o ambiente do sistema, produzidos pelo sistema, usados
pelo sistema, que permitem desempenhar suas funções.
 Listas de serviços, processos ou funções, que manipulam ou interagem com os objetos.
 Lista de restrições, como, por exemplo, custo, tamanho, regras de negócio e critérios de
desempenho como velocidade e precisão.

Cabe destacar que as listas não podem ser exaustivas, mas devem refletir a percepção de
cada um sobre o contexto do sistema.

QFD (Quality Function Deployment)

Desdobramento da função de qualidade, ou Quality Function Deployment – QFD
(Pressman, 2006), é uma técnica japonesa de gestão da qualidade, que tem por
finalidade capturar as necessidades do cliente, para que sejam traduzidas em requisitos
técnicos do software. A técnica se concentra em maximizar a satisfação do cliente a
partir do processo de engenharia de software. Para isso, a QFD dá ênfase ao
entendimento daquilo que representa valor para o cliente; posteriormente, esses valores
são desdobrados por meio do processo de engenharia. A técnica classifica os requisitos
em três tipos:

a. Normais: são aqueles que deixam os clientes satisfeitos quando as metas são atingidas
devido à utilização desses requisitos.
b. Esperados: são os requisitos implícitos. Esses requisitos são tão fundamentais, que os
clientes nem se referem a eles de maneira explícita, mas geram uma grande insatisfação
no cliente, caso ocorra a falta de algum deles. Como exemplo, podemos citar a
facilidade na operação e na instalação, confiabilidade do sistema, atender às
necessidades de maneira correta etc.
c. Excitantes: são os requisitos que superam as expectativas, que surpreendem
positivamente os clientes. Assim, costumam gerar um resultado bastante satisfatório
quando estão presentes. Exemplo de requisito excitante pode ser um relatório
sabidamente útil e prático, mas que não havia sido solicitado.
A técnica consiste em realizar reuniões com os clientes, para que haja o desdobramento
de funções cujo enfoque é o de determinar o valor de cada função a ser utilizada no
sistema. É necessário também executar o desdobramento da informação, cuja essência é
identificar corretamente objetos de dados e eventos que farão parte do sistema. Para
finalizar, realizamos o desdobramento de tarefas, para que o comportamento do sistema
seja examinado dentro do contexto do seu ambiente. A análise de valor determina a
prioridade de forma relativa dos requisitos determinados durante cada um dos três
desdobramentos.

A técnica QFD utiliza entrevistas com os usuários, observação, levantamento e exames

de dados históricos, muitas vezes, relatórios de problemas e dados sem nenhum
tratamento, para o levantamento de requisitos. Esses dados são colocados em uma
espécie de tabela – chamada de tabela da voz do cliente – a qual é revisada com o
cliente. Assim, é utilizado um grande número de diagramas, matrizes e métodos de
avaliação para levantar os requisitos esperados e então tentar derivar os requisitos
importantes.

Cenários
Os usuários de sistema gostam de relatar sua rotina funcional. Gostam mais de contar
sobre seu dia a dia no trabalho do que de pensar e/ou tentar imaginar como seria sua
vida, caso já estivessem usufruindo do sistema. Assim, torna-se bem útil a utilização dos
cenários, para que haja uma grande e clara descoberta de requisitos.

Essa técnica consiste no usuário simular as suas interações com o sistema, dizer quais
são as informações relevantes que ele utilizará no sistema para realizar as suas
obrigações, além das informações de saída esperadas. É a descrição das tarefas a serem
realizadas por um usuário que executa um determinado papel.

A descoberta de cenários ajuda os engenheiros de software a entender melhor o

contexto da aplicação, e com um número determinado de cenários é possível fazer um
grande número de alternativas de solução para o problema.

Os cenários são as partes-chave da utilização de métodos de análise orientados a

objetos. É por meio deles que serão descritos os casos de uso, objeto de nosso estudo na
aula reservada à Análise e Requisitos, etapa seguinte que iremos tratar da Engenharia de
Requisitos.

Os cenários podem ser escritos de diversas formas, mas, segundo Sommerville e

Kotonya (1998), devem incluir algumas informações básicas, tais como:

 descrição do estado do sistema antes do início do cenário;

 fluxo normal dos eventos no cenário;
 exceções ao fluxo normal dos eventos;
 informações sobre outras atividades que podem acontecer de forma simultânea;
 descrição do estado do sistema depois da execução completa do cenário.

A seguir, é apresentado o exemplo de um cenário, em que um gerente de banco utiliza o

sistema para a abertura de conta para um determinado cliente. Este cenário contém
apenas o “caminho feliz”, no qual o fluxo acontece sem erros:

 O gerente seleciona a opção de abertura de conta.

  O sistema disponibiliza a tela de cadastro de conta.
 O gerente entra com as informações necessárias ao cadastro.
 O sistema valida as informações.
 O gerente solicita o cartão magnético para o cliente.
 O gerente solicita o talão de cheques para o cliente.
 O cenário é encerrado.

Casos de Uso
Os casos de uso se assemelham mais a uma forma de estruturar do que propriamente
levantar requisitos, embora sirvam para encontrar mais requisitos quando são utilizados
na validação das informações junto ao usuário.

Os casos de uso são então uma junção de cenários, classificados em fluxo básico e
alternativo, atores, restrições, pré-condições, pós-condições, definições e regras de
negócio. Conheça cada um deles.

 Fluxo básico – Consiste no caminho feliz. O cenário com o fluxo básico é aquele que
deve ou deveria acontecer na grande maioria das vezes. É o atendimento pelo sistema à
funcionalidade levantada pelo analista de requisitos junto ao cliente/usuário. É
justamente o que aquela tarefa deve fazer, a sua finalidade principal. É a sequência
básica dos acontecimentos, a narrativa dos passos a serem seguidos no decorrer da
interação do ator com o sistema. São os passos a serem seguidos.
 Fluxo alternativo – Acontece quando há uma exceção no fluxo natural das coisas. Por
exemplo, alguma informação que deveria constar e não está presente. Para resolver esse
problema, o sistema pode pedir a informação ausente, registrar um erro, redirecionar a
execução do sistema, entre outras opções.
 Atores – Atores são essenciais em um caso de uso. São aqueles que interagem com a
funcionalidade. Pode ser uma pessoa, que representa um papel, ou um sistema externo,
ou seja, uma entidade de fora do sistema que é responsável por interagir com o sistema.
Um papel pode ser encarado como um conjunto de características comuns a um ator que
se relaciona com o sistema. Por exemplo, uma pessoa com papel de funcionário pode
executar tarefas reservadas a um funcionário qualquer, como pesquisar dados do cliente,
enquanto que apenas o funcionário com papel de gerente pode conceder mais crédito no
cheque especial.
 Restrições – As restrições significam aquelas circunstâncias que devem ser obedecidas
pelo caso de uso. É algo que, enquanto aquela situação não for atendida, restringe a
conclusão do caso de uso. Por exemplo, quando o usuário solicitar um cadastro
qualquer, alguns campos devem ser de preenchimento obrigatório. Enquanto esses
campos não possuírem valores, não será possível concluir a operação.
 Pré e pós-condições – Pré-condição é quando um caso de uso só pode ser iniciado se
determinada situação tiver sido alcançada. Por exemplo, o usuário só poderá interagir
com determinada funcionalidade se ele estiver logado no sistema. Pós-condição é a
situação em que deve se encontrar o sistema depois da realização daquele caso de uso.
 Pré e pós-condições – Pré-condição é quando um caso de uso só pode ser iniciado se
determinada situação tiver sido alcançada. Por exemplo, o usuário só poderá interagir
com determinada funcionalidade se ele estiver logado no sistema. Pós-condição é a
situação em que deve se encontrar o sistema depois da realização daquele caso de uso.
Um exemplo de pós-condição seria de um caso de uso Incluir Cliente. Nesse sentido,
uma pós-condição é que no final da execução do caso de uso todas as informações dos
clientes tenham sido validadas e o cliente gravado no banco de dados.
 Definições – Podemos dizer que as definições fazem parte da especificação do caso de
uso. É comum que uma organização tenha uma cultura e vocabulário próprios; mesmo
assim, um termo pode ter dois ou mais significados, a depender do departamento. Por
 isso, devemos utilizar definições para que um termo utilizado no sistema seja
suficientemente claro para todos os envolvidos.
 Regras de Negócio – Todo o sistema deve acontecer estando restrito a determinadas
regras de negócio. São as especificações e definições que determinam o fluxo dos
acontecimentos. As regras de negócio podem estabelecer novas definições, condições,
restrições, entre outros. Muitas vezes, as regras de negócio estão em um documento
diferente da especificação do caso de uso, isso porque muitas regras de negócio não são
exclusivas do caso de uso. Elas pertencem a todo o sistema, por isso são colocadas em
um lugar único e o caso de uso apenas referencia essa regra de negócio.

Você estudará mais sobre casos de uso e cenários na aula Modelagem e Análise de
Requisitos, em que serão apresentados novos termos, nomenclatura, notação gráfica,
enfim, tudo aquilo necessário para você poder fazer uma boa modelagem ao analisar
os requisitos.

Para Refletir

Analise o mapa mental apresentado na figura 4:

Figura 4 – Técnicas de Levantamento de Requisitos.

Fonte: https://goo.gl/tV1Ggp

Você deve ter observado que o mapa mental apresenta informações sobre o que deve ser
feito em termos de Levantamento de Requisitos e a Técnica de Levantamento de
Requisitos a ser utilizada. Essa é uma ferramenta muito útil! Pense que você pode
utilizar um software para essa finalidade, já imaginando como será o levantamento e
qual é a melhor técnica a ser considerada. Imagine que você levantará requisitos em
uma empresa que contará com a presença de mais ou menos 10 pessoas, de
departamentos e interesses diferentes. Você pode baixar o aplicativo FreeMind, que é
um software free, e pode gerar como exercício um mapa mental da situação, para
facilitar o registro de ideias.
 Nesta aula, você compreendeu que o processo de engenharia de requisitos visa
garantir que o sistema gerado por esses requisitos atenda às necessidades e satisfaça
as expectativas dos clientes. A Gestão de Requisito é um conjunto de atividades que
ajuda a equipe de projeto a identificar, controlar e rastrear requisitos e modificações
de requisitos em qualquer época, à medida que o projeto prossegue. Também foi
abordada a Elicitação de Requisitos, entendendo os detalhes do sistema de que o
cliente necessita e as técnicas que podem ser utilizadas para obtenção e consolidação
dos requisitos iniciais do sistema.

Na próxima aula, será abordada a Análise dos Requisitos de Software, dando

continuidade ao tratamento dos requisitos levantados na Elicitação de Software.

Bons estudos!