Engenharia de Software (1 semestre 2018) Parte 1

Prévia do material em texto

Ciência da Computação /
Sistemas de Informação
Material de Apoio da
Disciplina Engenharia de
Sotware
1
 
Taxa 
de 
falhas 
tempo 
curvas reais 
curva idealizada 
1 – Software
Define-se software como um conjunto de instruções que, quando executados, produzem a
função e o desempenho desejados, as estruturas de dados necessárias ao programa e os manuais que
descrevem a sua operação. Observa-se a aplicação do software em diferentes áreas, como: 
 Processamento de Informações – Sistemas de Informação;
 Aeronáutica;
 Telecomunicações;
 Saúde; e
 Entretenimento ...
A utilização de software dobra a cada 2 anos.
1.1 – Características Especiais do Software
O software possui algumas características especiais, listadas a seguir:
● Produto muito novo, menos de 50 anos;
● Produto lógico (abstrato);
● Não se desgasta (vide figura abaixo);
2
● O software não é manufaturado, mas desenvolvido;
● Flexibilidade de aplicação;
● Mudança constante de Requisitos;
● A aplicação em diferentes áreas pode gerar muitos riscos
● Durante a sua vida, o software enfrentará mudanças (manutenção). Quando essas
mudanças são feitas, é provável que novos defeitos sejam introduzidos, fazendo com que
a curva do índice de falhas apresente picos. Lentamente, o nível do índice de falhas
mínimo começa a se elevar - o software esta se deteriorando devido às mudanças; e
● Toda a falha de software indica um erro no projeto ou no processo pôr meio do qual o
projeto foi traduzido em código executável. 
1.2 – Problemas no Desenvolvimento de Software
Alguns problemas encontrados no desenvolvimento de Software:
● Obtenção dos requisitos do usuário;
● Diversas iterações com o usuário para obter o produto final;
● Dificuldade de manutenção;
● Crescimento na complexidade dos sistemas;
● Dificuldade de integração;
● Pouca reutilização, dificuldade de transferência de tecnologia; e
● Falta de metodologias amplamente aceitas e empregadas.
Devido a estes problemas, algumas conseqüências são identificadas:
● Apenas 10% dos projetos terminam no prazo e no orçamento estimados;
● 60% dos projetos ultrapassam o orçamento significativamente;
● De 25 a 30% dos projetos maiores são cancelados antes da implantação;
● O projeto médio tem um atraso de 1 ano e custo de 100% acima do orçamento;
● O projeto típico gasta 50% de seu tempo em testes; e
● Taxa típica de erros: 1 a 10 erros para cada 1000 linhas de código após a implantação
● Os custos de manutenção representam 80% dos recursos disponíveis.
A ocorrência destes problemas gerou a Crise do Software. Buscando solucionar, ou
reduzir, a ocorrência dos mesmos, foi criada a Engenharia de Software.
3
1.3 – Engenharia de Software
Apesar da evolução das ferramentas de informática, observa-se ainda a dificuldade no
desenvolvimento de software com qualidade, ou seja, que atinja os requisitos (explícitos e
implícitos) do usuário. Além disso, outras questões podem ser observadas no desenvolvimento de
software, como por exemplo:
Isso acontece, principalmente, devido ao desenvolvimento de software ocorrer, muitas
vezes, sem a aplicação de alguma forma de controle e planejamento do seu projeto. Observa-se,
portanto, a necessidade de se modificar a forma de produção de software, utilizando-se um processo
para orientar o seu desenvolvimento.
Para evitar isso, a proposta da Engenharia de software é possibilitar o desenvolvimento
adequado do software, visando:
● O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter
economicamente um software que seja confiável funcione eficientemente em máquinas
reais;
● Introduzir metodologias para o desenvolvimento do software, da mesma forma que nas
outras engenharias, com o emprego de modelos;
● Inclusão de Procedimentos, Métodos e Ferramentas, dentro de uma Metodologia bem
definida; e
● Ainda não existe uma Metodologia amplamente aceita.
A utilização da Engenharia de Software tem como principais objetivos:
● Reduzir o custo e o tempo de desenvolvimento;
● Possibilitar uma melhor gerência do processo de desenvolvimento;
● Facilitar o trabalho em grupo; e
● Aumentar a qualidade do produto.
4
2 – Processo de Software
Define-se Processo de Software como “um arcabouço (conjunto) onde se encontram todas as
tarefas necessárias para construir software de alta qualidade.”
Na busca pela qualidade, a base da Engenharia de Software é o processo, possibilitando o
controle gerencial do projeto, estabelecendo o contexto no qual os métodos serão aplicados, os
artefatos são produzidos, os marcos são estabelecidos e as modificações são geridas, assegurando
conseqüentemente, a qualidade.
Apoiados pelos processos, os métodos indicam “como fazer” para construir um software.
Para a realização dos métodos são aplicadas ferramentas, cujo objetivo é automatizar ou semi-
automatizar os mesmos.
Logo, define-se a engenharia de Software como uma tecnologia em camadas, conforme
apresentado na próxima figura.
No processo de software define-se um pequeno número de atividades de arcabouço
aplicáveis ao desenvolvimento de qualquer software, independente do seu tamanho e complexidade.
Estas atividades englobam:
 Comunicação – levantamento de requisitos com o cliente;
 Planejamento – estabelecimento do plano de trabalho;
 Modelagem – criação de modelos representativos do software;
 Construção – geração de código; e 
 Implantação – entrega do produto ao cliente.
Além dessas atividades, o processo possui ainda uma série de ações complementares,
denominadas atividades guarda-chuva, que apóiam o desenvolvimento. Estas atividades incluem,
por exemplo: a Gestão de risco, a Gestão de Configuração, entre outras.
5
Foco na qualidade
Processos
Métodos
Ferramentas
2.1 – Principais Modelos de Processo de Software
Um modelo de ciclo de vida do software deve conter a descrição precisa dos produtos de
software gerados e dos critérios de término para cada fase, pois sem os mesmos o modelo em
questão é considerado de pouca utilidade prática.
A escolha de um modelo de processo de software deve considerar as características do
sistema, os métodos e as ferramentas a serem utilizados, os prazos e custos e ainda, os produtos de
software a serem entregues. Nas próximas seções serão apresentados diferentes modelos
prescritivos de processo de software
2.2 – Modelo em Cascata
O modelo em Cascata (Waterfall), também chamado de Clássico, é o mais tradicional
processo de desenvolvimento de software. Este modelo sugere uma abordagem seqüencial para o
desenvolvimento de software, aplicando as atividades de maneira linear.
Em cada fase desenvolvem-se artefatos (produtos de software) que servem de base para as
fases seguintes. A figura a seguir apresenta o esquema deste modelo.
Este modelo possui como vantagem principal a simplicidade para a sua aplicação e gerência.
No entanto, algumas desvantagens podem ser observadas:
 Projetos reais raramente segue este fluxo seqüencial;
 Dificuldade do cliente em declarar todas as suas necessidades no início do projeto; e
 Demora em apresentar resultados ao cliente.
6
Comunicação
Planejamento
Modelagem
Construção
Implantação
2.3 – Modelo Incremental
Este modelo foi proposto como uma alternativa ao modelo em cascata, aplicando-o
iterativamente, visando a elaboração de um produto operacional a cada incremento. Os primeiros
incrementos são versões simplificadas do produto final, mas oferecem capacidades que servem ao
usuário, além de servir como uma plataforma de avaliação.
Em cada iteração uma parte é concebida como a menor unidadeque pode ser implementada
e ainda assim fornecer alguma funcionalidade útil para os usuários. A próxima figura apresenta o
esquema deste modelo.
Em cada iteração do ciclo acrescentam-se novas funcionalidades ao software. Este modelo
possui como vantagem o fato de apresentar constantemente novas versões aos usuários. Pode ser
aplicado também quando não houver mão-de-obra disponível para uma implementação completa,
ou quando for necessário gerenciar riscos técnicos. No entanto, algumas críticas podem ser feitas:
 Sem uma estrutura de gerenciamento e controle eficaz, o modelo pode deteriorar-se; e
 A premissa de que o sistema em desenvolvimento será flexível bastante para acomodar
todas as evoluções, pode não ser realista em muitas circunstâncias.
7
Tempo Decorrido
Incremento n
Comunicação
Planejamento
Modelagem
Construção
Implantação
Incremento 2
Incremento 1
Comunicação
Planejamento
Modelagem
Construção
ImplantaçãoComunicação
Planejamento
Modelagem
Construção
Implantação
F
u
n
c
i
o
n
a
l
i
d
a
d
e
...
2.4 – Prototipagem 
Em algumas situações, o cliente consegue definir apenas um conjunto de objetivos gerais do
software, não identificando claramente seus requisitos. Em uma situação dessas, a prototipagem
pode ser empregada em conjunto com outros modelos para auxiliar no entendimento do sistema.
Os objetivos do software são estabelecidos na comunicação com o cliente. A partir daí, um
protótipo descartável é elaborado com o intuito de facilitar a compreensão do sistema por parte dos
usuários. 
Apesar da prototipagem poder ser aplicada como um modelo, em geral ela é mais utilizada
como uma técnica para entendimento do sistema. A próxima figura apresenta o esquema deste
modelo.
Vantagens da prototipagem:
 Maior participação e comprometimento dos clientes e usuários; e
 Os resultados são apresentados mais rapidamente.
Críticas:
 Forte dependência das linguagens e ambientes utilizados, bem como da experiência da
equipe;
 O cliente tende a considerar o protótipo como versão final, podendo comprometer a
qualidade do projeto; e
8
Comunicação
Construção do Protótipo
Implantação e Feedback
Modelagem
Plano Rápido
 O desenvolvedor tende a fazer concessões na implementação, a fim de colocar um
protótipo em funcionamento rapidamente. Estas concessões podem se tornar parte
integrante do sistema.
2.5 – Modelo Espiral
Proposto por Boehm em 1988 como forma de integrar os diversos modelos existentes,
eliminando suas dificuldades e explorando seus pontos fortes. Combina a natureza iterativa da
prototipagem com os aspectos controlados e sistemáticos do modelo cascata. 
No modelo Espiral, assume-se que o processo de desenvolvimento ocorre em ciclos, cada
um contendo fases de avaliação e planejamento onde a opção de abordagem para a próxima fase (ou
ciclo) é determinada.
Neste modelo acrescenta-se a Análise dos Riscos ao ciclo de vida para auxiliar as decisões a
respeito da próxima iteração. A próxima figura apresenta o esquema deste modelo.
Apesar deste modelo reunir as melhores características dos outros, algumas críticas podem
ser feitas:
 Exige gerentes e técnicos experientes;
 Uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de
múltiplas partes do projeto, as tarefas gerenciais para acompanhamento e controle do
projeto são mais complexas; 
9
 
Comunicação com o 
cliente 
Planejamento 
Análise de 
Risco 
Engenharia 
Construção e Entrega Implantação 
 É necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem
como para determinar os indicadores de custo e progresso mais adequados. 
2.6 – Outros Modelos de Processo de Software
Como a Engenharia de Software ainda está evoluindo, novos modelos estão sendo
apresentados, como:
• Desenvolvimento Baseado em Componentes;
• Desenvolvimento Ágil;
• Técnicas de quarta geração.
2.6.1 – Desenvolvimento Baseado em Componentes
O Desenvolvimento Baseado em Componentes ou Engenharia de Sistemas Baseada em
Componentes (CBSE) a princípio parece bastante semelhante à engenharia de software
convencional ou orientada a objetos. O processo começa quando uma equipe de software estabelece
os requisitos para um sistema a ser construído usando técnicas de coleta de requisitos
convencionais. 
Um projeto arquitetural é estabelecido, mas ao invés de passar imediatamente a tarefas de
projeto mais detalhadas, a equipe examina os requisitos para determinar que subconjunto é mais
adequado à composição, do que à construção. Isto é, a equipe formula as seguintes questões para
cada requisito do sistema:
 Componentes comerciais prontos para uso (COTS) estão disponíveis para
implementar o requisito?
 Componentes reusáveis, internamente desenvolvidos, estão disponíveis para
implementar o requisito?
 As interfaces dos componentes disponíveis são compatíveis com a arquitetura do
sistema a ser construído?
10
2.6.2 – Desenvolvimento Ágil e XP
A Engenharia de Software vem há anos criando técnicas de modelagem, projeto e
desenvolvimento de sistemas. Dentre os desafios dos pesquisadores da área, pode-se citar a
preocupação em desenvolver softwares com qualidade garantida, no prazo estabelecido e sem
alocar recursos além do previsto. No entanto, muitas das metodologias criadas são consumidoras de
muitos recursos, aplicando-se principalmente a grandes sistemas.
A eXtreme Programming faz parte de uma serie de métodos denominados ágeis (agile),
estes métodos foram inicialmente considerados leves (lightweight) para diferenciá-los dos métodos
tradicionais de desenvolvimento considerados pesados (heavyweight), os quais seriam baseados na
produção de uma grande quantidade de documentação e modelos para guiar a programação. 
Ao contrario dos métodos tradicionais que são orientados ao planejamento, previsibilidade e
ao controle, os métodos ágeis são orientados a construção, testes e principalmente, às pessoas. As
metodologias ágeis enfatizam os aspectos humanos, as relações pessoais, uma vez que buscam
valorizar o pensamento criativo dos indivíduos envolvidos no projeto, onde o conhecimento é fator
importante para o sucesso do projeto. 
No desenvolvimento ágil a metodologia deve produzir conhecimento não apenas
documentação. Mas isto não significa que nos ambientes ágeis não existe documentação, apenas
deixa de existir a filosofia de que “tudo tem que ser documentado” e sim documentar apenas o
necessário uma vez que a documentação apenas auxilia e não guia o desenvolvimento.
Na próxima figura podemos comparar a XP ao modelo tradicional de desenvolvimento de
software.
Como se vê na figura, o modelo em cascata estabelece uma ordenação linear no que diz
respeito à realização das diferentes etapas, já o modelo iterativo é um modelo de processo de
11
desenvolvimento que busca contornar algumas das limitações existentes no modelo cascata. Já a XP
trabalha com iterações de menor tamanho possível, contendo os requisitos de maior valor para o
negócio, sendo assim, a equipe produz um conjunto reduzido de funcionalidades e coloca em
produção rapidamente de modo que o cliente já possa utilizar o software no dia-a-dia e se beneficiar
dele.
Há diversos relatos em que afirma-se a obtenção de melhores resultados com a utilização de
métodos ágeis do que com os métodos tradicionais. No entanto, por terem estes métodos, em sua
maioria, uma publicação recente, é ainda incipiente a pesquisa e a comprovação acadêmica sobre o
assunto.
2.7 – RUP
O Unified Process ouRational Unified Process (RUP), é um processo de desenvolvimento
de software baseado no Processo Unificado, que consiste nas melhores práticas comerciais para
obter-se um processo de desenvolvimento de software bem definido. 
Este é o contexto para o RUP, um processo de desenvolvimento de software concentrado em
assegurar a produção de sistemas de qualidade de forma repetível e previsível. O RUP foi
concebido tomando como base três conceitos fundamentais: Dirigido por casos de uso; Centrado em
arquitetura; e Iterativo e Incremental.
Os processos de desenvolvimento de software objetivam transformar os requisitos do
usuário em um software. O RUP consiste em um processo de desenvolvimento Orientado a Objetos
que adota como padrão adotado para representação dos modelos a Unified Modeling Language
(UML). Deve-se ressaltar que a UML é apenas uma linguagem para representação e não constitui
um processo de desenvolvimento completo.
O Rational Unified Process é um processo de engenharia de software. Ele fornece uma
abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organização de
desenvolvimento. Seu objetivo é assegurar a produção de software de qualidade que satisfaça as
necessidades de seus usuários finais dentro de prazo e orçamento previsíveis. É desenvolvido e
mantido pela Rational Software e integrado com seu conjunto de ferramentas de desenvolvimento
de software. Por fim, captura muitas das melhores práticas no desenvolvimento moderno de
software de forma satisfatória para uma grande faixa de projetos e organizações.
Rational Unified Process é um processo de desenvolvimento iterativo e incremental, no qual
o software não é implementado em um instante no fim do projeto, mas é, ao contrário, desenvolvido
e implementado em partes. A cada iteração deste processo utiliza-se quatro fases, a saber:
12
Concepção, Elaboração, Construção e Transição. 
Durante a Concepção ou Início (Inception), estabelece-se a lógica do domínio da aplicação
para o projeto e decide o escopo do projeto. É aqui que se obtém o comprometimento do
patrocinador do projeto para seguir adiante. Nesta fase compreende-se o problema da tecnologia
empregada por meio da definição dos use cases mais críticos. Define-se aqui o caso de negócio e
escopo do projeto
Na Elaboração (Elaboration), coleta-se requisitos mais detalhados, faz uma análise e um
projeto de alto nível para estabelecer uma arquitetura básica, e cria um plano para a construção do
sistema. Deve-se analisar o domínio do problema, estabelecer a arquitetura, desenvolver o plano do
projeto e eliminar elementos de alto risco.
A fase de Construção (Construction) consiste de várias iterações, nas quais cada iteração
constrói software de qualidade de produção, testado e integrado, que satisfaz um subconjunto de
requisitos de projeto. Cada iteração contém todas as fases usuais do ciclo de vida da análise, do
projeto, da implementação e do teste.Desenvolve-se o software e prepara-se o mesmo para a
transição para os usuários. Além do código, também são produzidos os casos de teste e a
documentação
Mesmo com este tipo de processo iterativo, algum trabalho tem que ser deixado para ser
feito no fim, na fase de Transição (Transition). Nesta fase são realizados os treinamentos dos
usuários e a transição do produto para utilização.Este trabalho pode incluir também testes beta e
ajuste de performance.
Os projetos variam de acordo com o volume de formalidade que eles têm. Projetos de muita
formalidade têm muitos documentos formais a serem entregues, reuniões formais, encerramentos
formais. Projetos de pouca formalidade podem ter uma fase de concepção que consiste de um bate-
papo de uma hora com o patrocinador do projeto e um plano que cabe em uma folha de papel.
Naturalmente quanto maior o projeto, mais formalidade precisa. O fundamental de cada fase ainda
acontece, mas de formas bem diferentes.
Após a fase de Transição de uma iteração completa, o produto pode voltar a percorrer cada
uma das fases para se produzir uma nova versão do produto. 
Cada uma das quatro fases do RUP é dividida em iterações, onde cada uma delas é um ciclo
completo de desenvolvimento resultando em uma versão de um produto executável que constitui
um subconjunto do produto final. Cada iteração é organizada em fluxos de trabalho (workflows) de
processo, com uma ênfase diferente em cada fase. Os fluxos de trabalho de processo do RUP são:
 Gerenciamento de Projeto (Project Managment);
 Modelagem Comercial ou de Negócio (Business Modeling);
13
 Requisitos ou Exigências (Requirements);
 Análise e Projeto (Analisys & Design);
 Implementação (Implementation);
 Testes (Test);
 Distribuição ou Entrega (Deployment);
 Gerência de Configuração e Mudanças (Configuration and Change
Managment); e
 Ambiente (Enviroment).
A figura a seguir apresenta o relacionamento entre as fases e o esforço de desenvolvimento
em cada fluxo de trabalho de processo.
Na figura, o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do
processo como se desdobra. Já o eixo vertical representa os fluxos essenciais do processo, que
agrupa logicamente as atividades por natureza.
14
3 – Engenharia de Requisitos
Uma das primeiras atividades do processo de desenvolvimento de software, independente do
modelo empregado, é o entendimento das necessidades do sistema, para garantir que as expectativas
dos clientes vão ser atendidas.
Ou seja, deve-se:
 Entender o que o cliente deseja;
 Analisar as necessidades;
 Avaliar a Exeqüibilidade;
 Negociar uma solução razoável;
 Especificar a solução de maneira não ambígua;
 Validar a especificação; e
 Gerenciar os requisitos.
Observação: Requisito é uma condição necessária para a obtenção de certo objetivo ou para
preenchimento de certo fim dentro do domínio da aplicação. Sendo assim, os Requisitos de
Software são Requisitos que o produto a ser desenvolvidos deve possuir.
3.1 – Definição
É o uso sistemático de princípios, técnicas, linguagens e ferramentas comprovadas para
análise, documentação, evolução continuada das necessidades dos usuários e especificação do
comportamento externo de um sistema para satisfazer as necessidades do usuário, que sejam
efetivas em termos de custos. Visa, principalmente, o entendimento escrito do problema.
Algumas considerações importantes:
 É uma abordagem sistemática, ou seja, constituída por um conjunto de processos
estruturados para extrair, validar e manter os requisitos de um sistema;
 Composta principalmente por atividades de Análise (identificar) e Documentação
(validar); e
 Constitui a ponte entre a comunicação com o cliente, a documentação gerada, o projeto e
15
o desenvolvimento.
A Engenharia de Requisitos é composta pelos seguintes passos:
 Concepção
 Levantamento (Especificação)
 Elaboração
 Negociação
 Especificação
 Validação 
 Gestão de Requisitos
3.2 – Tipos de Requisitos
Existem dois tipos de requisitos:
 Os Requisitos Funcionais que correspondem à listagem de todas as coisas que o sistema
deve fazer. Os requisitos funcionais apresentam uma descrição das diversas funções que
clientes e usuários querem ou precisam que o software ofereça; e
 Os Requisitos Não-Funcionais que descrevem as propriedades de um software, como
manutenibilidade, usabilidade, desempenho, custos e várias outras. Estes requisitos
interferem na forma como o sistema deve realizar seus requisitos funcionais.
Exemplos de Requisitos Não-Funcionais:
 a base de dados deve ser protegida para acesso apenasde usuários autorizados
 o tempo de resposta do sistema não deve ultrapassar 30 segundo
 o software deve ser operacionalizado no sistema Linux
 o tempo de desenvolvimento não deve ultrapassar seis meses
 Velocidade
o Transações processadas/segundo
o Tempo de resposta ao usuário
 Tamanho
16
o Tamanho em bytes do software final
o Memória
 Facilidade de uso
o Tempo de treinamento necessário
o Número de telas de ajuda
 Confiabilidade
o Tempo médio para falhar
o Taxa de ocorrência de falhas
o Probabilidade de indisponibilidade
 Robustez
o Tempo de reinício após falha
o Porcentual de eventos que causam falhas
 Portabilidade
o Número de ambientes operacionais nos quais o sistema pode rodar
A próxima figura apresenta uma classificação dos requisitos não-funcionais.
17
3.3 – Concepção 
O primeiro passo da Engenharia de requisitos é a Concepção, onde é realizada a definição
do escopo e a natureza do problema, a análise da sua viabilidade, o reconhecimento dos
interessados (stakeholders).
Observação: Stakeholders são as pessoas que têm interesse direto no sistema a ser desenvolvido ou
que se beneficie dele. Deve-se observar que para cada classe de interessados, podem ser definidos
diferentes pontos de vista, gerando requisitos conflitantes.
Na literatura, é sugerido que, nesta fase, os engenheiros de software adotem a estratégia do
P&R (pergunta e resposta), empregando questões de livre contexto. As perguntas não são fixas,
podendo surgir novas perguntas durante a realização das entrevistas. As perguntas são elaboradas e
respondidas a partir das seguintes fontes de informação:
Interessados (stakeholders), como clientes, usuários e desenvolvedores;
 Documentos
 Livros
 Sistemas de Software
18
 Livros relacionados a aplicação em discussão; e
 Documentos mais referenciados pelos atores.
3.4 – Levantamento de Requisitos
Neste passo busca-se descobrir, tornar explícito (elicitar), obter o máximo de informações
para o conhecimento do software em questão. Para tanto, é necessário:
 Identificar as fontes de informação
 Coleta de fatos
 Comunicação
Pretende-se, portanto, conhecer o domínio de aplicação do software, identificando e
coletando os requisitos (funcionais e não-funcionais) de forma organizada. Este passo deve ser
realizado em conjunto com todos os envolvidos, inclusive e de forma especial, os interessados.
Alguns problemas são comuns durante a execução destas atividades:
 Problemas de entendimento
o Interessados não compreendem o domínio
o Interessados omitem informações
o Interessados possuem visões conflitantes
o Interessados definem requisitos ambíguos
o Interessados definem requisitos impossíveis de serem tratados (economicamente ou
tecnologicamente)
 Problema de escopo
 Problemas de volatilidade
Em um levantamento de requisitos, geralmente um engenheiro de software se depara com
duas importantes questões:
• Entre os muitos relatórios, formulários e documentos gerados pelos membros de uma
organização, quais deverão ser objeto de investigação?
• Pode haver um grande número de pessoas afetadas pelo sistema de informação proposto.
19
Quais delas devem ser entrevistadas, observadas ou questionadas?
3.4.1 – Técnicas para Levantamento de Requisitos
Servindo de base para todas as técnicas de levantamento de requisitos, entre elas
investigação, entrevistas e observação, estão as decisões cruciais dizendo respeito do que examinar
e a quem questionar ou observar. Estas decisões podem ser apoiadas por uma abordagem
estruturada chamada amostragem. 
A Amostragem é o processo de seleção sistemática de elementos representativos de uma
população. Quando os elementos selecionados em uma amostragem são analisados, pode-se assumir
que esta análise revelará informações úteis acerca da população como um todo.
Por que usar amostragem?
• diminuir custos;
• acelerar o processo de levantamento de informações;
• eficiência: a informação tende a ser mais apurada, já que menos elementos podem ser
analisados, mas estes podem ser analisados com mais detalhes;
• reduzir tendências.
A Investigação de documentos é uma técnica que auxilia no levantamento de requisitos,
pois nos documentos pode-se identificar os temos comuns do sistema que pretende-se desenvolver e
as informações necessárias para a empresa.
A técnica de estudos etnográficos é proveniente das disciplinas de Antropologia , que
consiste no estudo de um objeto por vivência direta da realidade onde este se insere. Permitindo
analisar a componente social das tarefas desempenhadas numa dada organização tornam-se, no
âmbito da Engenharia de Requisitos, extremamente úteis para ultrapassar a dificuldade que existe
na recolha dos requisitos derivados de formas rotineiras e tácitas de trabalhar. 
O objetivo deste estudo é identificar o modo como realmente as pessoas executam as suas
funções que muitas vezes difere da forma como as definições dos processos sugerem que elas
devem fazer; como ocorre a cooperação e conhecimento das atividades entre as pessoas. 
Esta técnica se refere a uma análise da componente social das tarefas desempenhadas numa
dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de
esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as
20
quais interage. Através de uma observação direta das atividades realizadas durante um período de
trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando
técnicas convencionais. Esta observação pode ser acompanhada de registros áudio/vídeo, porém não
convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado.
Nesta técnica assume-se que o interessado observado desempenha as suas funções "corretamente“.
Portanto, é necessário ter cuidado na escolha do(s) interessado(s) a observar. 
Outra alternativa para levantamento de requisitos é a utilização de Cenários. Esta técnica
pode ser definida como uma forma de levar as pessoas a imaginar o comportamento de um sistema.
Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores
podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de
uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os
cenários devem incluir os seguintes elementos: 
• Estado do sistema no início do cenário
• Seqüência de eventos esperada (na ausência de erros) no cenário. 
• Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes
erros serão tratados. 
• Outras atividades que podem ser executadas ao mesmo tempo que as deste cenário
• Estado do sistema depois de o cenário terminar. 
Pode-se, também, aplicar entrevistas com representantes dos usuários do sistema. Nestas
entrevistas, em geral, são aplicados os seguintes tipos de questões:
 Questões subjetivas: permitem respostas “abertas”
o O que você acha de ...?
o Explique como você ...?
 Questões objetivas: limitam as respostas possíveis
o Ex: Quantos ...? Quem ...?
o Quanto tempo ...? Qual das seguintes informações ...?
Estas entrevistas podem ser estruturadas de diferentes formas:
 Estrutura de Pirâmide - inicia com questões bastante detalhadas, geralmente objetivas, e,
21
à medida que a entrevista progride, questões mais gerais, subjetivas, são colocadas;
 Estrutura de Funil - inicia com questões gerais subjetivas e, à medida que a entrevista
avança, perguntas mais específicas, usando questões objetivas, são feitas;
 Estrutura de Diamante - Combinaçãodas duas estruturas anteriores, começa com
questões objetivas (específicas), passa para questões gerais e fecha com questões
específicas; e
 Não estruturada.
3.5 – Elaboração do Documento de Requisitos
O documento de requisitos do sistema deve ser composto por sentenças em linguagem
natural, seguindo determinados padrões. Neste curso será adotado o padrão IEEE-830, que contém
os seguintes itens:
1. Introdução
1.1. Propósito
1.2. Escopo
1.3. Definições
1.4. Referências
1.5. Visão Geral
2. Descrição Geral
2.1 Perspectivas do Produto
2.2. Funções do Produto
2.3. Características do Usuário
2.4. Restrições
2.5. Dependências
3. Requisitos Específicos
3.1. Requisitos Funcionais
3.2. Requisitos Não-Funcionais
Deve-se ressaltar que nem todos os itens serão sempre necessários. Com relação aos
22
requisitos funcionais, algumas regras devem ser observadas:
Iniciar os requisitos com “ O sistema deverá...”
O requisitos devem estar organizados logicamente. Por exemplo, inicialmente todos os
requisitos de entrada depois os de processamento e por último os requisitos de saída.
Cada requisito deve ter um identificador único, por exemplo, um número, para posterior
referência, e deve conter sempre uma única ação.
23
	1 – Software
	1.1 – Características Especiais do Software
	1.2 – Problemas no Desenvolvimento de Software
	1.3 – Engenharia de Software
	2 – Processo de Software
	2.1 – Principais Modelos de Processo de Software
	2.2 – Modelo em Cascata
	2.3 – Modelo Incremental
	2.4 – Prototipagem
	2.5 – Modelo Espiral
	2.6 – Outros Modelos de Processo de Software
	2.6.1 – Desenvolvimento Baseado em Componentes
	2.6.2 – Desenvolvimento Ágil e XP
	2.7 – RUP
	3 – Engenharia de Requisitos
	3.1 – Definição
	3.2 – Tipos de Requisitos
	3.3 – Concepção
	3.4 – Levantamento de Requisitos
	3.4.1 – Técnicas para Levantamento de Requisitos
	3.5 – Elaboração do Documento de Requisitos