2016 Livro Proprietario - Requisitos de Sistemas PDF

REQUISITOS DE
SISTEMA
autor
SAULO FRANÇA AMUI
1ª edição
SESES
rio de janeiro 2015
Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza.
Autor do original saulo frança amui
Projeto editorial roberto paes
Coordenação de produção gladis linhares
Coordenação de produção EaD karen fernanda bortoloti
Projeto gráfico paulo vitor bastos
Diagramação bfs media
Revisão linguística amanda carla duarte aguiar
Imagem de capa alphaspirit | dreamstime.com
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2015.
Dados Internacionais de Catalogação na Publicação (cip)
A529r Amui, Saulo

Requisitos de sistemas / Saulo Amui.
Rio de Janeiro : SESES, 2015.
152 p. : il.
isbn: 978-85-5548-031-7
1. Requisitos de software. 2. Qualidade de software.

3. Processos de software. 4. Gestão de requisitos. I. SESES. II. Estácio.
cdd 005.1
Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063
Sumário
Prefácio 7
1. Conceitos Gerais 9
Objetivos 10
1.1 Introdução 11
1.2 Conceitos de qualidade 11
1.2.1 Histórico 12
1.2.2 Conceitos 14
1.2.3 Gestão da Qualidade 16
1.2.4 Processos de Software Sem Controle 17
1.2.5 Processos de Software Bem Controlados 17
1.2.6 Implantação de um Programa de Qualidade 18
1.3 Processo de Qualidade de Software 19
1.4 Métricas de Qualidade de Software 22
1.5 Garantia da Qualidade de Software (SQA) 25
1.6 Estatística da Garantia da Qualidade de Software 30
1.7 Revisões técnicas 31
1.8 Revisões informais 34
1.9 Revisões Técnicas Formais 35
1.9.1 Diretrizes de revisão 35
1.10 Confiabilidade de software 37
Atividades 40
Reflexão 41
Referências bibliográficas 42
2. Processos de Ciclo de Vida e Qualidade 45
Objetivos 46
2.1 Introdução 47
2.2 Normas de qualidade de produtos de software 48
2.2.1 Qualidade de Produtos de Software - ISO 9126 48
2.2.2 Guias para a Avaliação da Qualidade - ISO 14598 50
2.2.3 Qualidade de Pacotes de Software - ISO 12119 52
2.2.4 A Série ISO 9000 53
2.3 Processos Fundamentais 60
2.4 Processos de apoio 62
2.5 Processos organizacionais 63
2.6 Processos de Adaptação 65
Atividades 66
Reflexão 66
3. Análise e Especificação de Requisitos 69
Objetivos 70
3.1 Introdução 71
3.2 Descrição do projeto do software 71
3.2.1 Plano de Projeto 75
3.3 O entendimento das necessidades do projeto 76
3.4 Levantamento de Requisitos 78
3.4.1 Levantamento orientado a ponto de vista 80
3.4.2 Cenários 84
3.4.3 Etnografia 86
3.5 A especificação dos requisitos 87
3.5.1 Requisitos funcionais e não funcionais 90
3.5.1.1 Requisitos funcionais 90
3.5.1.2 Requisitos não-funcionais 91
3.6 A definição do software 92
Atividades 93
Reflexão 94
4. Gerenciamento de Requisitos 97
Objetivos 98
4.1 Introdução 99
4.2 Gerenciamento de Requisitos 99
4.3 Gerenciamento de mudanças 103
4.4 Rastreabilidade de requisitos 108
4.5 Gerência da qualidade de requisitos 110
4.6 Validação de requisitos 114
Atividades 115
Reflexão 116
5. Modelagem do Projeto - UML 119
Objetivos 120
5.1 Introdução 121
5.2 A modelagem do software 121
5.2.1 Modelagem ágil 124
5.3 UML (Unified Modeling Language) 128
5.3.1 Aplicação 130
5.4 Casos de Uso 130
5.4.1 Diagramas de Caso de Uso 132
5.4.2 Descrição de Casos de Uso 135
5.5 Diagramas de Classes 135
5.6 Diagrama de Objetos 136
5.7 Diagramas de estados 137
5.8 Diagramas de sequência 137
5.9 Diagrama de Colaboração 139
5.10 Diagrama de Atividade 139
5.11 Diagrama de Componentes 140
5.12 Diagrama de Execução 141
Atividades 142
Reflexão 142
Gabarito 144
Prefácio
Prezados(as) alunos(as),
Os requisitos de um sistema são as peças fundamentais para o desenvolvi-

mento de software e sistemas de qualquer natureza. A qualidade dos requisitos
de um sistema irá influenciar diretamente na qualidade do resultado final do
produto de software. Conhecer seus conceitos, padrões, aspectos de seu geren-
ciamento e saber analisá-los é de extrema importância em todo o processo de
desenvolvimento de software e há uma grande necessidade das pessoas envol-
vidas conhecê-los muito bem.
Inicialmente, discutiremos os principais conceitos de requisitos, relacio-
nando-os com a qualidade de software e observando suas relações com a garan-
tia da qualidade, bem como a importância das revisões técnicas, tanto formais
quanto às informais. Veremos como que este conjunto de associações estão re-
lacionadas à confiabilidade do software.
O uso de normas de qualidade, por meio de institutos e órgãos responsáveis
por normatizar certos processos e itens de verificação, muito contribuem para
o avanço da maturidade das empresas, devido à busca constante de melhorias
e por atenderem a padrões internacionais que visam a qualidade. Além destes
pontos, algumas normas ainda trazem uma relação direta com os processos da
organização, separando-as em níveis de maturidade, o que favorece a atuação
ou o foco em áreas chaves para irem sendo incorporadas a cada estágio. Os re-
quisitos de sistemas vão sendo cada vez mais bem estruturados por meio de
documentos adequados e completos para a organização.
Um dos principais pontos para o desenvolvimento de um software está asso-
ciado à análise e especificação de requisitos, além de uma completa descrição
do projeto do software que está sendo proposta, compreendendo bem as neces-
sidades do projeto. Com isto, o uso adequado e eficaz nos métodos de levanta-
mento de requisitos bem como sua especificação, tornam-se fatores essenciais
para um bom desenvolvimento.
Veremos ainda que os requisitos de sistemas sofrem mudanças e por isto é
necessário o uso de um gerenciamento de requisitos, para que seja capaz de ge-
renciar mudanças, efetuar rastreabilidade de requisitos e validação dos mesmos.
7
Por fim, uma vez que estes requisitos de sistemas foram devidamente le-
vantados, anotados e especificados, parte-se para a modelagem do projeto de
software e, para isto, utiliza-se algumas técnicas e ferramentas que irão contri-
buir para o desenho do software, modelando-o e expressando algumas situa-
ções funcionais, comportamentais por meio de diagramase outras formas de
notação visual.
Aproveite a leitura e os estudos para tentar transportar os conceitos apren-
didos em sua vida prática, ou tentando observá-los em uso em empresas e nos
ambientes adequados.
Bons estudos!
1
Conceitos Gerais
Neste primeiro capítulo começaremos tratando de um assunto de extrema
importância para o software e que lida com aspectos essenciais para o seu bom
funcionamento, que é a qualidade de software. Introduziremos o conceito de
requisitos sob a ótica da qualidade, envolvendo qualidade de software, revisões
técnicas e confiabilidade.
Requisitos de software eram conhecidos antigamente como as funções que
um sistema oferecia. Atualmente, requisitos de software é tratado com maior
abrangência do que simplesmente suas funções, envolvendo pontos como os
objetivos, propriedades, padrões, restrições, especificações e tudo aquilo que
for necessário para atender a necessidade do cliente dentro dos objetivos pro-
postos em um software. Assim, podemos entender requisitos de software como
algo que é proposto no sistema ou alguma restrição em seu desenvolvimento.
Para se ter um software de qualidade, os seus processos de desenvolvimen-
to e a qualidade de seus requisitos são fundamentais para que isto aconteça.
Compreender bem as necessidades do cliente, suas funcionalidades, suas limi-
tações e todos os aspectos associados à estes requisitos, também contribuem
fortemente para um produto final de qualidade.
Veremos a importância das revisões técnicas neste processo e também tra-
taremos de assuntos relacionados à confiabilidade, já que falhas nos requisitos
representam uma das maiores causas de insucesso nos projetos de software.
Bons estudos!
OBJETIVOS
Neste capítulo teremos como objetivo:
• Aprender os principais conceitos de qualidade.

• Conhecer a garantia da qualidade de software
• Aprender sobre revisões técnicas.
• Discutir sobre os aspectos relacionados à confiabilidade de software.
10 • capítulo 1
1.1 Introdução
Requisitos são fundamentais para projetos de desenvolvimento de software,
uma vez que documenta as definição de uma propriedade ou comportamento
esperado de um produto ou serviço.
De acordo com Dorfman e Thayer, requisitos podem ser definidos como
“uma capacidade de software que o usuário necessita de modo a resolver um
problema ou alcançar um objetivo”. Uma outra definição também apresentada
pelos mesmos autores pode ser vista como: “uma capacidade de software que
deve ser disponibilizada por um sistema ou componente de sistema de modo a
satisfazer um contrato, padrão, especificação ou outra formalidade imposta”.
Os requisitos definem características, atributos, qualidade ou habilidades
que um sistema, ou parte deste, deve constar para atender as necessidades dos
usuários.
Segundo Ian Sommerville, os requisitos são geralmente definidos nas fa-
ses inciais de um projeto e tem a utilidade de especificar o que deverá ser im-
plementado na fase de codificação ou desenvolvimento, propriamente dita,
podendo descrever uma facilidade encontrada do ponto de vista do usuário,
qualquer propriedade ou restrição geral do sistema ou ainda uma restrição ao
desenvolvimento do sistema (SAYÃO e BREITMAN, 2014).
Um ponto bem importante de ser observado é relação direta e significativa
que existe entre a qualidade dos requisitos e qualidade do produto final do sof-
tware. Deste modo, vamos estudar melhor os conceitos de qualidade para com-
preendermos suas relações com os processos de desenvolvimento de software
e a importância dos requisitos neste contexto.
1.2 Conceitos de qualidade

Qualidade é uma palavra muito difícil de ser definida, não é?
O que é bom para um pode ser ruim para outros, o bonito para uma pessoa
pode ser feio ou não tão bonito para outros e enfim, chega a ser uma questão
pessoal sobre o que é ter qualidade.
Se perguntarmos para um empresário que trabalha na administração de
uma manufatura ele terá uma definição na ponta da língua a qual diz que “qua-
lidade é estar em conformidade com as exigências dos clientes”. Esta é uma
capítulo 1 • 11
definição muito usada na área da administração e é baseada na visão da opera-
ção, na área de engenharia de produção.
Segundo Slack et al. (1996), a definição de Qualidade é bem mais ampla
e obedece a cinco categorias ou abordagens: Abordagem Transcendental,
Baseada em Manufatura, Baseada no Usuário, Baseada em Produto e Baseada
em Valor. Como percebemos, é um assunto bastante vasto!
Mas a engenharia de software, lembrando, é uma área que provém da enge-
nharia tradicional logo, os conceitos que existem na administração e engenha-
ria de produção serão aplicados também na engenharia de software.
A Qualidade de software pode ser definida segundo alguns autores
(KOSCIANSKI e SOARES, 2007) como um conjunto de atributos de software
que devem ser satisfeitos de modo que o software atenda às necessidades dos
usuários. Como podemos ver, o conceito aplicado ao software é parecido com o
encontrado na administração e engenharia tradicional.
Portanto, qualidade não é apenas um diferencial de mercado para a empre-
sa conseguir vender e lucrar mais, é um pré-requisito que a empresa deve con-
quistar para conseguir colocar o produto no Mercado Global.
1.2.1 Histórico
Quando tratamos sobre qualidade, é necessário buscar os princípios que com-

põem esta área de estudo.
Nas empresas em geral, a palavra qualidade está relacionada com uma
técnica de administração chamada Qualidade Total. Esta técnica é multidis-
ciplinar, ou seja, envolve várias áreas administrativas simultaneamente e em
conjunto com o objetivo de obter melhores bens e serviços pelo menor custo e
atender às expectativas dos clientes.
A Qualidade Total está baseada nos estudos de Frederick Taylor, Walter
Shewhart e Peter Drucker, principalmente após o fim da segunda guerra mun-
dial, momento no qual as indústrias precisavam repor as baixas em várias áreas.
Estes estudos buscavam conceber um modelo para aumentar a eficiência,
racionalizar os métodos de trabalho, a crença no homem econômico, a divisão
e a hierarquização do trabalho, a relevância da organização formal.
Baseado nestes objetivos, podemos notar que são os mesmos que qualquer
empresa de software ou relacionada com software deseja. Sendo assim, a quali-
dade de software provém destes estudos também.
12 • capítulo 1
Na verdade a qualidade de software praticamente nasceu junto com a enge-
nharia de software pois foi um momento em que era necessário estabelecer re-
gras, práticas e processos para o desenvolvimento de melhores softwares. Logo,
é um conceito contemporâneo à engenharia de software.
A Engenharia de Software, iniciou-se na década de 70 quando especialistas
em computação de vários países se reuniram para discutir os problemas de
desenvolvimento de software da época. Durante esta conferência houve uma
grande quantidade de debate sobre o tema que os participantes escolheram
chamar de “Software Crisis” ou “Software Gap”. Entre os principais problemas,
relacionados a este tema, que foram descritos durante a conferência estavam:
• Projetos realizados acima do orçamento;

• Projetos finalizados acima do tempo esperado;
• Produtos de software de baixa qualidade;
• Produtos de software sem atender aos requisitos do cliente;
• Projetos ingerenciáveis e com código difícil de se manter.
Comparando com a década de 70 percebemos que a Engenharia de Software

evoluiu bastante. Muitos métodos, técnicas e teorias com o objetivo de resolver
(ou tentar) os problemas tratados na conferência foram desenvolvidos.
A maioria destas evoluções veio como resultado do aprendizado produzido
em projetos reais e fizeram com que a Engenharia de Software amadurecesse
muito e fosse divulgada na comunidade em geral.
Ao longo desta história uma subárea que tem ganhado forças na luta contra
o que foi denominado de “Crise de Software” é a área de conhecimento denomi-
nada Qualidade de software, que está onipresente na Engenharia de Software
como um todo, pois ela está incluída nas preocupações das demais subáreas.
Esta área de conhecimento tem como objetivo principal garantir a qualida-
de do software através da definição e normatização de processos de desenvol-
vimento. Por este motivo, os modelos aplicados na garantia da qualidade de
software focam no processo de desenvolvimento como forma de garantir a qua-
lidade final do produto.
Saber os conceitos, técnicas, abordagens e demais conceitos sobre qualida-
de de software é um fator fundamental para saber como consegui-la.
Comparando com a administração, que toma como base as normas de qua-
lidade da ISO, segundo a norma ISO 9000, a qualidade é o grau em que um con-
junto de características inerentes a um produto, processo ou sistema cumpre
os requisitos inicialmente estipulados para estes.
capítulo 1 • 13
A ISO (International Organization for Standardization – Organização Internacional para
Padronização) 9000 é na verdade um grupo de normas técnicas que estabelecem
um modelo de gestão da qualidade para qualquer tipo de organização, de qualquer
tamanho. A ISSO foi fundada em 1947 e possui como função a promoção de normas
de produtos e serviços, para que a qualidade dos mesmos seja permanentemente me-
lhorada. Estas normas estabelecem requisitos para a melhoria dos processos internos,
maior capacitação dos colaboradores, monitoramento do ambiente de trabalho, verifi-
cação da satisfação dos clientes, colaboradores e fornecedores, num processo contí-
nuo de melhoria do sistema de gestão da qualidade. O uso das normas ISO é vantajosa
para as organizações uma vez que lhes confere maior organização, produtividade e
credibilidade.
1.2.2 Conceitos
Qualidade de software pode ser definida como um conjunto de atributos de sof-

tware que devem ser satisfeitos de modo que o software atenda às necessidades
dos usuários. A determinação dos atributos relevantes a cada sistema depende
do domínio da aplicação, das tecnologias utilizadas, das características especí-
ficas do projeto e das necessidades do usuário e da organização.
Vários fatores afetam a percepção da qualidade do desenvolvimento e do
software, entre eles podemos destacar:
• Tamanho e complexidade do software;

• Numero de pessoas envolvidas;
• Métodos técnicas e ferramentas utilizadas;
• Custo x Benefício do sistema;
• Custo associado aos erros;
A qualidade pode ser vista por vários pontos de vista diferentes, como o pon-
to de vista do usuário, que busca a facilidade de uso, desempenho, confiabi-
lidade e preço, entre outros. Ponto de vista do desenvolvedor que espera que
software tenha baixa taxa de erros, facilidade de manutenção e conformidade
com os requisitos, entre outros. E da organização que deseja que o software seja
desenvolvido dentro dos prazos propostos e viáveis para ela, que tenha uma boa
previsão de custos e boa produtividade depois de implantado.
14 • capítulo 1
Para que tenhamos a qualidade total do software precisamos garantir a qua-
lidade do processo de desenvolvimento, mesmo que esta não garanta a qualida-
de do produto final, mas é um indicativo que a organização é capaz de produzir
bons produtos.
As duas vertentes - qualidade de produto e qualidade de processo - são com-
plementares e interdependentes. Espera-se que a qualidade do processo e fa-
bricação tenha um impacto positivo sobre o software obtido. Entretanto, tal
objetivo será atingido se houver uma compreensão clara de que os processos
devem fornecer todos os mecanismos necessários para especificar o produto e
controlar a fabricação.
Sendo assim, para alcançar a qualidade, utiliza-se de melhoria de proces-
sos, implementada através de modelos abstratos ou formais que permitem aos
engenheiros especificar, projetar, implementar e manter sistemas de software,
avaliando e garantindo suas qualidades. Além disto, deve oferecer mecanismos
para se planejar e gerenciar o processo de desenvolvimento.
A implantação de um sistema de qualidade no desenvolvimento de software
permite um aumento de produtividade, uma melhoria da qualidade do produ-
to final e um aumento da satisfação dos clientes e da própria empresa.
Para que um software seja considerado “de qualidade”, é necessário que
este tenha conformidade com alguns conceitos:
• Correção: deve funcionar de forma correta. Satisfazendo as suas especifi-

cações sem falhas ou erros;
• Integridade: suas especificações satisfazem os requisitos dos usuários e
da organização;
• Flexibilidade: deve prever que o usuário pode agir de forma não esperada
e deve ser capaz de resistir a eventuais situações sem falhas;
• Confiabilidade: deve se comportar como esperado e não falhar em situa-
ções inesperadas;
• Eficiência: deve realizar suas tarefas em tempo adequado à complexidade
de cada um deles. E devem utilizar de modo eficiente os recursos de hardware
disponíveis;
• Reusabilidade: os componentes do software devem permitir ser reutiliza-
dos em outras aplicações;
• Usabilidade: deve ser fácil de aprender e de usar, permitindo maior pro-
dutividade do usuário, flexibilidade de utilização e aplicação e proporcionar
satisfação ao usuário;
capítulo 1 • 15
• Manutenibilidade: deve permitir fácil manutenção para que correções ou
atualizações sejam realizadas de modo fácil e eficiente;
• Evolutibilidade: deve permitir expansão de suas funcionalidades para
atender novos requisitos ou incorporar novas tecnologias;
• Portabilidade: deve poder ser executado no maior número possível de
equipamentos;
• Interoperabilidade: deve ser capaz de interagir com diferentes sistemas
e plataformas.
1.2.3 Gestão da Qualidade
A gestão da qualidade de software visa assegurar o nível de qualidade que o sof-

tware exige. A gestão da qualidade de software esta calcada na gestão do proces-
so de desenvolvimento de software.
O processo de desenvolvimento de software é composto basicamente de
três etapas básicas de acordo com a figura 1.1.
Análise de sistema
Definição
Análise de requisitos
Projeto
Construção Codificação
Teste
Entendimento
Manutenção Modificação
Revalidação
Figura 1.1 – Processo de desenvolvimento de software.
A qualidade do software será proveniente do gerenciamento deste processo,

através do controle eficaz de suas atividades. Inclui-se também no processo de
gerenciamento o controle e treinamento de pessoal, procedimentos e utiliza-
ção de ferramentas, obtendo desta forma um processo de software muito bem
definido.
16 • capítulo 1
O controle do processo consiste na competência em controlar o processo de
software e influencia na capacidade da organização de atingir metas de custo,
qualidade e cronograma.
1.2.4 Processos de Software Sem Controle
Um processo de software sem controle resulta em processos improvisados pe-

los desenvolvedores e gerência. Não é rigorosamente seguido e o cumprimento
das metas não é controlado. O processo passa a ser altamente dependente da
qualidade e experiência dos profissionais envolvidos.
E diminui a visão de progresso e qualidade do processo.
A qualidade do produto fica comprometida e os prazos dificilmente são
cumpridos. Possui alto risco quando é necessária a utilização de novas tecnolo-
gias, por depender diretamente da experiência dos profissionais. Além de tor-
nar muito difícil prever a qualidade final do produto.
O processo passa a ser constantemente reativo a situações inesperadas e
problemas ao invés de ser pró-ativas, não havendo tempo para melhorias. De
forma geral, o “fogo” esta sob controle, mas esta quase sempre “apagando in-
cêndios”, fazendo com que os envolvidos tenham “queimaduras” constantes.
Com isso sempre sobram “cinzas” que podem facilmente voltar a se incendiar
mais tarde.
1.2.5 Processos de Software Bem Controlados
Um processo de software bem controlado deve ser coerente com as linhas de

ação para que o trabalho seja efetivamente concluído. Deve ser definido, docu-
mentado e melhorado constantemente. Um processo de software precisa ser
bem compreendido e utilizado de forma efetiva e completa, deve estar sempre
ativo mesmo nas situações mais complicadas em que aparentemente possam
tornar as atividades mais complexas.
Desta forma será visível o apoio da alta administração e até mesmo de ou-
tras gerências.
Um processo bem controlado precisa de fidelidade ao processo e deve
ser objeto de auditoria constante. Para tal são utilizadas medições do produ-
to e do processo. Além disso, é necessário que o processo seja instituciona-
lizado, tornando-se parte da infraestrutura da organização, pois processos
capítulo 1 • 17
institucionalizados permanecem, mesmo depois que as pessoas que original-
mente os definiram deixam a organização ou o processo. Ficando a cargo da
cultura organizacional transmitir o processo adiante.
1.2.6 Implantação de um Programa de Qualidade
Na instalação de um programa de qualidade, é necessário que se estabeleça

uma anistia geral, ou seja, o que aconteceu até aquele momento, não é culpa de
ninguém. A principal meta é enfrentar os problemas existentes, em benefício
de todos. Contudo, os seguintes aspectos devem ser contínua e dinamicamen-
te avaliados e melhorados: a estratégia geral da empresa, o planejamento, e os
meios disponíveis com vistas ao estabelecimento de condições favoráveis, para
se alcançar os objetivos almejados.
Um programa de melhoria da qualidade leva ao estabelecimento de um
sistema de qualidade, que deve envolver aspectos técnicos e culturais, que são
igualmente importantes. O aspecto técnico envolve o desenvolvimento de pa-
drões e procedimentos para implementar a qualidade em todas as atividades.
O aspecto cultural está diretamente relacionado com a aceitação da qualidade
por todos os indivíduos da organização. Para se iniciar um programa de quali-
dade pode-se seguir as seguintes etapas:
• Preparação de uma política de qualidade: a iniciativa da elaboração de

um programa de qualidade deve advir do topo da gerência, formulando uma
política de qualidade, a ser publicada e comunicada de tal forma que seja en-
tendida e implementada em todos os níveis da organização.
• Estabelecimento de um suporte à qualidade: criação de um comitê de
condução da qualidade e uma equipe de melhoria da qualidade. O comitê dire-
ciona as estratégias, estabelece a equipe de melhoria da qualidade, autoriza e
aprova o orçamento, e fornece suporte de alto nível para o programa de qualida-
de. A equipe de melhoria da qualidade estima as necessidades da organização,
e projeta, planeja e monitora o sistema de qualidade.
O planejamento de um programa de qualidade tem as seguintes etapas:
• Estimativa da organização: medição da prática corrente, através de um

padrão apropriado, onde a organização seleciona o índice que melhor lhe
satisfaça.
18 • capítulo 1
• Projeto do sistema de qualidade: os resultados da estimativa da organi-
zação são analisados, os objetivos de seu sistema de qualidade são definidos e,
então, a equipe de melhoria da qualidade projeta-o, gerando a primeira versão
do manual de qualidade.
• Plano de implementação do programa de qualidade: com a primeira ver-
são do manual de qualidade, a equipe de melhoria da qualidade pode determi-
nar o montante de trabalho necessário para a implementação do sistema de
qualidade e, convenientemente, elaborar cronogramas e atividades, estabele-
cer marcos e alocar recursos para este fim.
• Implementação de um programa cultural: para um programa de quali-
dade ter sucesso é necessário o suporte de toda a organização e, para isto, um
programa cultural deve ser cuidadosamente planejado e implementado desde
cedo, para a formação de consciências voltadas para a qualidade, e encorajar a
participação de todos.
• Implementação do programa técnico: envolve a adoção de um ciclo de
vida, o desenvolvimento de procedimentos e padrões, a seleção e implementa-
ção de métodos e ferramentas, a definição e implementação de um programa
de medição, e o treinamento.
• Revisão e avaliação: componentes do sistema de qualidade, procedimen-
tos e padrões, métodos, ferramentas e recursos devem ser revistos regularmen-
te e devem ser tomadas ações para assegurar sua contínua efetividade.
1.3 Processo de Qualidade de Software

Um processo de software consiste de uma série de atividades que garantem,
técnica e administrativamente, que o software pode ser desenvolvido de manei-
ra organizada, disciplinada e previsível.
Uma das maiores dificuldades encontradas pelas empresas de software é o
gerenciamento de seus processos de software, para tal são utilizados modelos
de processo de software.
O objetivo de um modelo de processo é descrever formalmente e organiza-
damente todas as atividades que devem ser seguidas para obtenção segura de
um produto de software.
A escolha de um modelo apropriado é importante para poder ir de encontro
às metas da organização e saber o grau em que esse modelo será implementado.
capítulo 1 • 19
Um modelo de processo ao ser usado, é estabelecida uma linguagem co-
mum a todos a qual facilita a comunicação e o entendimento entre todos. Uma
estrutura é oferecida para se priorizar as ações e auxilia-se nas comparações
com diversas comunidades diferentes.
Por outro lado os modelos são simplificações do mundo real não sendo su-
ficientemente abrangentes. Interpretações e adaptações dos modelos a situa-
ções particulares devem ser ajustadas aos objetivos do negócio e serem reali-
zadas com muito cuidado e estudo. E é necessário muito bom senso para se
utilizar modelos corretamente e com visão de negócio.
Existem diversos modelos de qualidade de software que podem ser utiliza-
dos de acordo com os objetivos e organização da empresa. Estes modelos serão
estudados mais profundamente em um tema futuro. Por hora nos basta saber
que existem e do que tratam, de acordo com a tabela 1.1.
Os modelos de qualidade normalmente são exemplificados tomando grandes empresas

como clientes. Porém existem alguns modelos específicos para pequenas equipes de
desenvolvimento. Entre eles podemos destacar o PSP (Personal Software Process)
• http://www.sei.cmu.edu/library/abstracts/reports/05sr003.cfm: é o artigo principal
e introdutório ao PSP. Em inglês
• http://campus.fortunecity.com/princeton/117/psp/psp.htm. Este artigo traz alguns
dos principais conceitos e técnicas do PSP.
• http://wwww.doctum.com.br/unidades/cataguases/graduacao/sistemade
informacao/artigos/Renato_PSPm_JIISIC06.pdf: artigo muito interessante sobre
melhoria de processo de software individual.
NORMA COMENTÁRIOS
ISO 9126 Características da qualidade de produtosde software.
NBR 13596 Versão brasileira da ISO 9126.
Guias para a avaliação de produtos de software, baseados na utilização prática
ISO 14598 da norma ISO 9126.
Características da qualidade de pacotes de software (software de prateleira, ven-
ISO 12119 dido com um produto embalado).
IEEE P1061 Standard for Software Quality Metrics Methodology (produto de software).
Software Life Cycle Process. Norma para a qualidade do processo de desenvol-
ISO 12207 vimento de software.
Sistemas de qualidade – Modelo para garantia de qualidade em projeto, desenvol-
NBR ISO 9001 vimento, instalação e assistência técnica (processo).
20 • capítulo 1
NORMA COMENTÁRIOS
Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para
NBR ISO 9000-3 o processo de desenvolvimento de software.
Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de Software
do Departamento de Defesa dos USA) para avaliação da qualidade do processo
CMM de desenvolvimento de software. Não é uma norma ISO, mas é muito bem aceita
no mercado.
Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software.
SPICE ISO 15504 Ainda não é uma norma oficial ISO, mas o processo está em andamento.
Tabela 1.1 – Modelos de qualidade. Fonte: adaptado de BARRETO JÚNIOR (2014, p. 1).
O CMM é um modelo de qualidade de software bastante usado no mercado. Ele, assim

como outros modelos, quantifica o nível de maturidade na qual uma determinada equi-
pe ou organização possui em relação ao desenvolvimento de software.
O CMM em especial divide as organizações em cinco níveis de maturidade: Ini-
cial, Repetível, Definido, Gerenciado e Otimizado. O objetivo do CMM é fazer com que
a organização atinja níveis de excelência na produção de software. Além disso, por
meio desta classificação de maturidade, muitos clientes usam estes níveis como forma
de pré-requisito para que um determinado fornecedor de software possua para poder
prestar o serviço.
Como é mostrado na tabela 1.1, não existe uma norma ISO 9000 especifica-
mente para o software porém ela estabelece princípios gerais que podem ser
aplicados ao software.
A ISO 9000 descreve vários aspectos do processo de qualidade e exibe os
padrões e procedimentos organizacionais que a empresa deve definir. Eles
devem ser documentados em um manual de qualidade da organização. A de-
finição do processo deve incluir descrições da documentação necessária para
demonstrar que os processos definidos foram seguidos durante o desenvolvi-
mento do produto.
Porém, como foi dito que a ISO9000 pode ser aplicada com variantes para
o software. A figura 1.2 mostra o relacionamento entre o manual de qualidade
e os planos de qualidade de projeto individual e estes podem ser projetos de
software.
capítulo 1 • 21
Modelos de
Qualidade ISO 9000
É usado para desenvolver
Manual de
Documentos Processo de qualidade
qualidade da
da organização
organização
É usado para desenvolver Conhecido
como
Gerenciamento de
Plano de qualidade Plano de qualidade Plano de qualidade qualidade do projeto
Projeto 1 Projeto 2 Projeto 3
Figura 1.2 – ISO 9000 e o gerenciamento de qualidade.
1.4 Métricas de Qualidade de Software

Um projeto de software é um processo de tomada de decisão, onde métricas
podem ser usadas para fornecer uma base de identificação de procedimentos,
que não estejam em conformidade com os alvos pretendidos, e medidas de atri-
butos de projeto, além de auxiliar na elaboração de novas soluções, que levem
à melhoria da qualidade.
Em 1977, McCall propôs um modelo para avaliação da qualidade de softwa-
re. Esse modelo envolve um conjunto de fatores que avalia o software de três
pontos de vista distintos, que englobam todos os conceitos de qualidade.
• Operação do produto (usando-o): correção, confiabilidade, eficiência, in-

tegrabilidade e usabilidade.
• Revisão do produto (mudando-o): manutenibilidade, flexibilidade e
evolutibilidade
• Transição do produto (mudando-o para que funcione em um ambiente
diferente): portabilidade, reusabilidade e interoperabilidade.
22 • capítulo 1
O modelo de McCall esta organizado em três níveis:
• Fatores (para especificar): descrevem a visão externa do software, como

visto pelo usuário.
• Critérios (para construir): descrevem a visão interna do software, ou seja,
como é vista por quem está desenvolvendo.
• Métricas (para controlar): composta por escalas e medidas para avaliar
(com notas de 0 a 10, sim/não, Proporção)
Mas existem fatores subjetivos de qualidade que influenciam as notas, por-

tanto é difícil ou até mesmo impossível desenvolver medidas diretas dos fato-
res de qualidade.
Sendo assim, é definido um conjunto de métricas para desenvolver expres-
sões que poderão ser utilizadas para avaliar cada um dos fatores, por exemplo:
Fq = c1 x1 + c2 m2 +  + cn x m
Onde:
Fq: Nota para o fator de qualidade de software
cn : coeficiente (peso) da métrica m
mn: métricas que afetam o fator de qualidade
Segundo McCall, as métricas podem estar na forma de uma lista de

conferência (checklist), que é usada para “graduar” atributos específicos
do software. O esquema de graduação proposto por McCall é uma escala
de 0 (baixo) a 10 (elevado). As seguintes métricas são usadas no esquema de
graduação.
• Auditabilidade: a facilidade com que se pode checar a conformidade aos

padrões.
• Acurácia: a precisão das computações e do controle.
• Comunidade de comunicação (Communication Commonality): o grau
em que interfaces padrões, protocolos e larguras de banda (bandwidths) são
usados.
• Inteireza: o quanto a implementação total da função requerida foi
conseguida.
capítulo 1 • 23
• Concisão: a compactação do programa em termos de linhas de código.
• Consistência: o uso de técnicas de projeto e documentação uniformes ao
longo do projeto de desenvolvimento de software.
• Comunidade de dados (Data Commonality): o uso de estruturas e tipos
de dados padrões ao longo do programa.
• Tolerância a erros: o dano que ocorre quando o programa encontra um erro.
• Eficiência de execução: o desempenho de run-time de um programa.
• Expansibilidade: o quanto o projeto de arquitetura, procedimental e de
dados podem ser ampliados.
• Generalidade: a amplitude de aplicação em potencial de componentes do
programa.
• Independência de hardware: o quanto o software é desvinculado do har-
dware em que opera.
• Instrumentação: o quanto o programa monitora sua própria operação e
identifica erros que venham a ocorrer.
• Modularidade: a independência funcional dos componentes do
programa.
• Operabilidade: a facilidade de operação de um programa.
• Segurança: a disponibilidade de mecanismos que controlem ou protejam
programas e dados.
• Auto-documentação: o quanto o código-fonte apresenta documentação
significativa.
• Simplicidade: o quanto um programa pode ser entendido sem dificuldade.
• Independência do software básico: o quanto um programa é indepen-
dente de particularidades não-padronizadas de linguagens de programação
não padrão, das características de sistemas operacionais e de outras situações
ambientais.
• Rastreabilidade: a capacidade de rastrear uma representação de projeto
ou componente de programa até os requisitos.
• Treinamento: o quanto o software auxilia no sentido de ajudar novos usu-
ários a aplicarem o sistema.
O peso dado a cada métrica de qualidade de software depende dos produtos

e preocupações locais. Os fatores de qualidade descritos por McCall e seus co-
legas representam uma dentre uma série de “listas de conferência” sugeridas
para a qualidade de software.
24 • capítulo 1
Existem algumas ferramentas que podem auxiliar uma equipe nas questões de qualida-
de de software. Entre elas podemos destacar:
• http://www-142.ibm.com/software/products/br/pt/subcategory/rational/SW730:
É o pacote da Rational (IBM) para suporte ao desenvolvimento de software. Esta pá-
gina contém links para os seus diversos produtos na área de qualidade de software.
Destaque para o Quality Manager.
• http://www.microsoft.com/visualstudio/pt-br/solutions/software-quality: alternati-
vas da Microsoft por meio de seu ambiente integrado de desenvolvimento Visual Studio.
• http://blog.prasabermais.com/category/ferramentas-de-software/: Links para diver-
sas ferramentas gratuitas e open-source para a qualidade de software.
1.5 Garantia da qualidade de software (SQA)

De acordo com Rapchan (2011, p. 5), a Garantia da qualidade de software
(Software Quality Assurance - SQA) pode ser definida como “o conjunto de
atividades executadas com o propósito de gerar confiança para o cliente e para a
administração da organização de que os requisitos da qualidade especificados
serão atingidos”, e de acordo com a ISO 8402, como o “conjunto de atividades
planejadas e sistemáticas, implementadas no sistema da qualidade e
demonstradas como necessárias, para prover confiança adequada de que uma
entidade atenderá os requisitos para a qualidade” (RAPCHAN, 2011, p. 5).
As normas básicas para Garantia da Qualidade são: ISO 9001, ISO 9002 e ISO
9003 (RAPCHAN, 2011, p. 5).
A garantia da qualidade é o “processo de auditoria dos requisitos da qua-
lidade e dos resultados das medições de controle da qualidade para garantir
que sejam usados os padrões de qualidade e definições operacionais (métricas)
apropriados”. (MARSHALL, 2006, p.175). Este processo proporciona a melhoria
contínua de todos os processos da qualidade, com o propósito de reduzir os
desperdícios e as atividades sem valores agregados, o que contribui para que
os processos sejam operados com mais eficiência e eficácia. A auditoria veri-
fica se todas “as atividades estão de acordo com a política, os processos e os
procedimentos” (PMBOK, 2004, p.189) que foram previamente estabelecidas
pela organização, objetivando registrar as conformidades e não conformidades
e recomendar as ações corretivas e/ou preventivas que forem necessárias.
capítulo 1 • 25
Desta forma, todo o esforço a ser empregado para efetuar correções do
problema deve ter como resultado uma redução no custo da qualidade e uma
maior aceitação do produto por parte do cliente (BUENO, 2010, p. 6).
A Garantia da qualidade assegura a qualidade do produto final e por isso
ela está presente em todas as fases do desenvolvimento de um software. Sendo
assim, o SQA envolve todo o processo de desenvolvimento de software, execu-
tando monitorações e melhorias de processos de acordo com a necessidade.
Isto faz com que os padrões e procedimentos acordados estejam sendo segui-
dos e garantindo que problemas sejam encontrados e que as ações corretivas
também sejam aplicadas adequadamente. Esse tipo de ação tem uma orienta-
ção preventiva. O IEEE 610.12-1990 cita qualidade de software como “(1) Um
padrão planejado e sistemático de todas as ações necessárias para fornecer
confiança adequada que um item ou produto está em conformidade com os re-
quisitos técnicos estabelecidos. (2) Um conjunto de atividades projetadas para
avaliar o processo pelo qual produtos são desenvolvidos ou manufaturados”
(MARTINHO, 2008).
Segundo Martinho (2008), a SQA pode também ser entendida e formada por
um grupo de pessoas que estão relacionadas e empregadas através de todo o
ciclo de vida de engenharia de software que positivamente influenciam e quan-
tificam a qualidade do software que está sendo entregue. Assim, a SQA não é
somente uma atividade associada de forma exclusiva às atividades de desenvol-
vimento de software, mas sim atividades que se expandem durante todo o ciclo
de vida de desenvolvimento de software.
Ainda de acordo com Martinho (2008), a garantia da qualidade de software
envolve:
1. Um processo de SQA;
2. Tarefas específicas de garantia da qualidade e controle da qualidade (inclusive
revisões técnicas e uma estratégia de testes multiescalonados);
3. Prática efetiva de engenharia de software (métodos e ferramentas;
4. Controle de todos os artefatos de software e as mudanças feitas nesses produtos;
5. Um procedimento para garantir a conformidade com os padrões de desenvolvi-
mento de software (quando aplicáveis) e;
6. Mecanismos de medição e de relatórios.
(PRESSMAN, 2011, p. 388)
26 • capítulo 1
No entanto, empresas que não possuem o grupo ou processos de SQA tem
uma tendência a apresentar os seguintes indicadores de falta de qualidade,
conforme Lewis (2004) (MARTINHO, 2008):
• O software que foi entregue frequentemente apresenta falhas;

• Inaceitáveis consequências de falhas de sistemas, desde financeiras até cenários
reais de aplicação;
• Sistemas não estão frequentemente disponíveis para uso pretendido;
• Sistemas são frequentemente muito caros;
• Custo de detectar e remover defeitos são excessivos.
Por outro lado, empresas que possuem o grupo ou processo de SQA im-
plementados e a sua aplicação de maneira adequada e correta, apresenta que
(MARTINHO, 2008):
• A remoção de erros acontece no momento em que se é barato corrigir;

• Melhoria da qualidade do produto;
• O SQA é um recurso para a melhoria de processo;
• Estabelecimento de um banco de dados de métricas como: planejamento, taxas de
falhas e outros indicadores da qualidade.
Elementos de Garantia da Qualidade de Software

"A garantia da qualidade de software engloba um amplo espectro de preocupações e
atividades que se concentram na gestão da qualidade de software e que podem ser
sintetizadas da seguinte maneira:
Padrões: o IEEE, a ISO e outras organizações de padronizações produziram uma
ampla gama de padrões para engenharia de software e os respectivos documentos. Os
padrões podem ser adotados voluntariamente por uma organização de engenharia de
software ou impostos pelo cliente ou outros interessados. O papel da SQA é garantir
que padrões que tenham sido adotados sejam seguidos e que todos os produtos resul-
tantes estejam em conformidade com eles.
capítulo 1 • 27
Revisões e auditorias: As revisões técnicas são uma atividade de controle de
qualidade realizada por engenheiros de software para engenheiros de software. Seu
intuito é o de revelar erros. Auditorias são um tipo de revisão efetuado pelo pessoal de
SQA com o intuito de assegurar-se de que as diretrizes de qualidade estejam sendo se-
guidas no trabalho de engenharia de software. Por exemplo, uma auditoria do processo
de revisão pode ser realizada para garantir que as revisões estejam sendo realizadas de
maneira que conduza à maior probabilidade de descoberta de erros.
Testes: Os testes de software são uma função de controle de qualidade com um
objetivo principal - descobrir erros. O papel da SQA é garantir que os testes sejam pla-
nejados apropriadamente e conduzidos eficientemente de modo que se tenha a maior
probabilidade possível de alcançar seu objetivo primário.
Coleta e análise de erros/defeitos: A única forma de melhorar é medir o nosso
desempenho. A SQA reúne e analisa dados de erros e defeitos para melhor compre-
ender como os erros são introduzidos e quais atividades de engenharia de software
melhor se adequam para sua eliminação.
Gerenciamento de mudanças: As mudanças são um dos aspectos mais nega-
tivos de qualquer projeto de software. Se não forem administradas apropriadamente,
podem gerar confusão, e confusão quase sempre leva a uma qualidade inadequada.
A SQA garante que práticas adequadas de gerenciamento de mudanças tenham sido
instituídas.
Educação: Toda organização de software quer melhorar suas práticas de enge-
nharia de software. Um fator fundamental para o aperfeiçoamento é a educação dos
engenheiros de software, seus gerentes e outros interessados. A organização de SQA
assume a liderança no processo de aperfeiçoamento do software e é um proponente
fundamental e patrocinador de programas educacionais.
Gerência dos fornecedores: Adquirem-se três categorias de software de forne-
cedores externos de software - pacotes prontos, comerciais (por exemplo, Microsoft
Office, oferecidos ao usuário em embalagens), um shell personalizado que fornece um
esqueleto básico, personalizado de acordo com as necessidades do comprador e sof-
tware sob encomenda que é projetado e construído de forma personalizada a partir de
especificações fornecidas pela empresa-cliente. O papel do grupo de SQA é garantir
software de alta qualidade por meio da sugestão de práticas específicas de garantia da
qualidade que o fornecedor deve (sempre que possível) seguir, e incorporar exigências
de qualidade como parte de qualquer contrato com um fornecedor externo.
28 • capítulo 1
Administração da segurança: Com o aumento dos crimes cibernéticos e novas
regulamentações governamentais referentes à privacidade, toda organização de sof-
tware deve instituir políticas que protejam os dados em todos os níveis, estabelecer
proteção através de firewalls para as aplicações da Internet (WebApps) e garantir que
o software não tenha sido alterado internamente, sem autorização. A SQA garante o
emprego de processos e tecnologias apropriadas para ter a segurança de software
desejada.
Proteção: O fato de o software ser quase sempre um componente fundamental
de sistemas que envolvem vidas humanas (por exemplo, aplicações na indústria auto-
motiva ou aeronáutica), o impacto de defeitos ocultos pode ser catastrófico. A SQA
pode ser responsável por avaliar o impacto de falhas de software e por iniciar as etapas
necessárias para redução de riscos.
Administração de riscos: Embora a análise e a redução de riscos seja preocupa-
ção dos engenheiros de software, o grupo de SQA garante que as atividades de gestão
de riscos sejam conduzidas apropriadamente e que planos de contingência relaciona-
dos a riscos tenham sido estabelecidos.
Além de cada uma dessas preocupações e atividades, a SQA trabalha para garan-
tir que atividades de suporte ao software (por exemplo, manutenção, suporte on-line,
documentação e manuais) sejam realizadas ou produzidas tendo a qualidade como
preocupação dominante."
(PRESSMAN, 2011, p. 389)
CONEXÃO
Recursos para a Gestão da Qualidade
(PRESSMAN, 2011, p. 390) relaciona em seu livro dezenas de recursos para a gestão
da qualidade disponíveis na internet, incluindo associações de profissionais, organizações de
padrões e fontes de informação genéricas. Veja a relação:
• American Society for Quality (ASQ) Software Division

• www.migre.me/oIuNQ
• Association for Computer Machinery
• www.acm.org
capítulo 1 • 29
• Data and Analysis Center for Software (DACS)
• www.dacs.dtic.mil
• lnternational Organization for Standardization (ISO)
• www.iso.ch
• ISO SPICE
• www.isospice.com
• Malcolm Baldridge National Quality Award
• www.quality.nist.gov
• Software Engineering lnstitute
• www.sei.cmu.edu
• Testes de Software e Engenharia da Qualidade
• www.stickyminds.com
• Recursos sobre o Seis Sigma
• www.isixsigma.com
• www.asq.org/sixsigma
• TickiT lnternational: Tópicos sobre certificação em qualidade
• www.tickit.org/international.htm
1.6 Estatística da Garantia da Qualidade de

Software
A garantia da qualidade de software também pode ter um componente esta-

tístico, por meio de uso de técnicas estatísticas para estimar a qualidade de
software. Ao executar o código com um pequeno conjunto de casos de testes
aleatórios pode gerar resultados úteis para estimar a qualidade. Este processo
também é chamado pode prova do software.
A média dos erros encontrados pode ser usada como estimativa para a mé-
dia de erros no projeto final.
Se a porcentagem de execuções corretas é alta, obviamente é um sinal que
o desenvolvimento está seguindo na direção correta, caso contrário, algu-
mas ações de correção devem ser tomadas para poder alterar o processo de
desenvolvimento.
30 • capítulo 1
Pressman (2011, p. 393) propõe as seguintes etapas para a estatística da
qualidade de software:
1. Informações sobre erros e defeitos de software são coletadas e classificadas.

2. É feita uma tentativa de associar cada erro e defeito a sua causa subjacente (por
exemplo, a não adequação às especificações, erros de projeto, violação de padrões,
comunicação inadequada com o cliente).
3. Usando o princípio de Pareto (80% dos defeitos podem ser associados a 20% de
todas as possíveis causas), são isoladas os 20% (as poucas causas vitais) .
4. Assim que as poucas causas vitais tiverem sido identificadas, prossegue-se para
a correção dos problemas que provocaram os erros e defeitos.
Estas etapas propostas e ações representam um passo importante para a

adoção de uma gestão de qualidade relacionada às mudanças e adaptações aos
processos de acordo com os erros encontrados.
1.7 Revisões técnicas

As revisões técnicas (RT) de software tem um papel muito valioso para a gestão
da qualidade, já que elas funcionam como uma espécie de filtro e podem ser
aplicadas em diferentes momentos ao longo do processo de desenvolvimen-
to de software, contribuindo para a revelação de erros, falhas ou defeitos que
podem ser sanados e eliminados. Assim, as revisões técnicas deixam o traba-
lho mais purificado, do ponto de vista da engenharia de software, incluindo os
aspectos de modelos de requisitos e de projeto, bem como dados de teste e o
código-fonte.
De acordo com Pressman (2011, p. 376), as revisões técnicas fazem parte das
muitas ações exigidas como parte de boas práticas da engenharia de software.
É requerido muita dedicação de nossa parte, em cada ação realizada para este
fim. Definir um conjunto de métricas para poder avaliar a eficácia é muito im-
portante para a organização, já que o esforço disponível para o projeto é finito.
capítulo 1 • 31
Freedman e Weinberg discutem a necessidade de revisões da seguinte maneira:
O trabalho técnico precisa de revisão pela mesma razão que o lápis precisa de
borracha: Errar é humano. A segunda razão para precisarmos de revisões técnicas é
que embora as pessoas sejam boas para “descobrir” alguns de seus próprios erros,
vários tipos de erros escapam mais facilmente daquele que os cometeu do que de
outras pessoas externas. O processo de revisão é, portanto, a resposta para a oração
de Robert Burns:
Oh! que uma força conceda poder para nos vermos como os outros nos veem.
Uma revisão - qualquer revisão - é uma forma de usar a diversidade de um grupo
de pessoas para :
1. Apontar aperfeiçoamentos necessários no produto de uma única pessoa ou de
uma equipe.
2. Confirmar aquelas partes de um produto em que aperfeiçoamentos são indesejá-
veis ou desnecessários.
3. Obter trabalho técnico de qualidade mais uniforme, ou pelo menos mais previsível;
qualidade que possa ser alcançada sem revisões, de modo a tornar o trabalho técnico
mais gerenciável.
Mesmo um pequeno subconjunto de métricas, reunidas para cada revisão

a ser realizada, podem oferecer uma boa visão da situação, muito embora pos-
sam ser difinidas muitas outras métricas para as RTs. Pressman (2011, p. 376)
relaciona alguma destas métricas:
• Esforço de preparação, Ep - o esforço (em homens/hora) exigido para revisar um

produto resultante antes da reunião de revisão.
• Esforço de avaliação, Ea - o esforço (em homens/hora) que é despendido durante
a revisão em si.
• Reformulação esforço, Re - o esforço (em homens/hora) dedicado à correção dos
erros revelados durante a revisão.
• Tamanho do artefato de software, TPS - uma medida do tamanho do artefato
de software que foi revisto (por exemplo, o número de modelos UML ou o número de
páginas de documento ou então o número de linhas de código).
32 • capítulo 1
• Erros secundários encontrados, Errsec - o número de erros encontrados que
podem ser classificados como secundários (exigindo menos para ser corrigidos do que
algum esforço pré-especificado).
• Erros graves encontrados, Errgraves - o número de erros encontrados que podem
ser classificados como graves (exigindo mais para ser corrigidos do que algum esforço
pré-especificado).
Vale ainda ressaltar que essas métricas podem ser ainda mais refinadas se
associar o tipo de artefato de software que foi revisto para as métricas.
Bugs, erros e defeitos

O objetivo do controle da qualidade de software e da gestão da qualidade em geral é,
em sentido mais amplo, eliminar problemas de qualidade no software. Tais problemas
são conhecidos por diversos nomes - bugs, falhas, erros ou defeitos, apenas para citar
alguns. Esses termos são sinônimos ou existem diferenças sutis entre eles?
Existe uma distinção clara entre erro (um problema de qualidade encontrado antes
de o software ser liberado aos usuários finais) e defeito (um problema de qualidade
encontrado apenas depois de o software ter sido liberado aos usuários finais). Essa
distinção é feita porque os erros e os defeitos podem acarretar impactos econômicos,
comerciais, psicológicos e humanos muito diferentes. Os engenheiros de software têm
a missão de encontrar e corrigir o maior número possível de erros antes dos clientes
e/ ou usuários finais. Devem-se evitar defeitos - pois (de modo justificável) criam uma
imagem negativa do pessoal de software.
É importante notar, entretanto, que a distinção temporal entre erros e defeitos feita
neste livro não é um pensamento dominante. O consenso geral na comunidade de
engenharia de software é que defeitos e erros, falhas e bugs são sinônimos. Ou seja,
o momento em que o problema foi encontrado não tem nenhuma influência no termo
usado para descrevê-lo. Parte do argumento a favor desta visão é que, muitas vezes,
fica difícil fazer uma distinção clara entre pré e pós-entrega (consideremos, por exem-
plo, um processo incrementai usado no desenvolvimento ágil).
capítulo 1 • 33
Independentemente da maneira escolhida para interpretar esses termos ou do
momento em que um problema é descoberto, o que importa efetivamente é que os
engenheiros de software devem se esforçar - muitíssimo - para encontrar problemas
antes que seus clientes e usuários finais os façam. Caso tenha maior interesse nes-
sa questão, uma discussão razoavelmente completa sobre a terminologia envolvendo
bugs pode ser encontrada em www.softwaredevelopment.ca/bugs.shtml.
(PRESSMAN, 2011, p. 374)
As revisões técnicas também podem possuir diferentes abordagens em re-

lação ao seu nível de formalidade. Elas podem ser categorizadas em revisões
informais ou em revisões técnicas mais formais, sendo que cada uma possui
suas formas de abordagem.
1.8 Revisões informais

As revisões informais podem ser constituídas de ações que visam revisar, dis-
cutir, mas de modo informal, como o próprio nome sugere. Teste de mesa de
um artefato de engenharia de software, juntamente com um colega, bem como
reuniões informais (com pelo menos mais de duas pessoas), são exemplos de
reuniões informais e estas visam geralmente, revisar um artefato ou ainda al-
guns aspectos orientados a revisões da programação em pares.
Devido a falta de planejamento ou preparação para estas reuniões infor-
mais, sua eficácia pode ser muito inferior em relação às reuniões com aborda-
gens mais formais, pois são desprovidas de uma série de pontos importantes
para dar continuidade ou atender os pontos que são discutidos ou que foram
tratados nesta reunião. O fato de não ter um follow-up, uma agenda e uma es-
trutura adequada para condução e anotação de uma pauta, podem comprome-
tem sua eficácia. No entanto, um simples teste pode revelar erros que, de outra
forma, poderiam propagar ainda mais na gestão da qualidade.
Uma maneira de tentar aumentar esta eficácia, nas reuniões informais do
tipo teste de mesa, seria desenvolver um conjunto de listas de verificação sim-
ples para cada artefato produzido pela equipe de software. As questões levanta-
das na lista de verificação são genéricas, mas servirão como guia para os reviso-
res verificarem o produto resultante (PRESSMAN, 2011, p. 380).
34 • capítulo 1
1.9 Revisões Técnicas Formais
A revisão técnica formal ou RTF pode ser tratada como uma atividade de con-
trole da qualidade de software realizada por engenheiros de software (e outros
profissionais). Neste tipo de revisão a abordagem é mais formal e exige uma es-
trutura em termos de planejamento e organização para que ela ocorra. Segun-
do Pressman (2011, p. 381), as RTF tem como objetivos: (1) descobrir erros na
função, lógica ou implementação para qualquer representação do software; (2)
verificar se o software que está sendo revisado atende aos requisitos propostos;
(3) garantir que o software foi representado de acordo com padrões predefini-
dos; (4) obter software que seja desenvolvido de maneira uniforme; e (5) tornar
os projetos mais gerenciáveis. Um ponto interessante de se observar é que além
disso, a RTF também serve como base de treinamento, possibilitando que en-
genheiros mais novos observem diferentes abordagens para análise, projeto e
implementação de software, contribuindo ainda mais para a qualidade.
Para ter sucesso e ser bem-sucedida, em cada reunião formal técnica, é
imprescindível a participação de todos os envolvidos e que esta seja planeja-
da e controlada apropriadamente, como por exemplo, por meio de diretrizes
estabelecidas.
1.9.1 Diretrizes de revisão
Para a realização de uma RTF, devem-se estabelecer previamente diretrizes, e

estas serem distribuídas a todos os revisores, contar com a anuência de todos
e, então, segui-las à risca. Em algumas situações uma revisão não controlada
pode ser pior do que não fazer nenhuma revisão. Pressman (2011, p. 383) apre-
senta um conjunto mínimo de diretrizes para revisões técnicas formais:
1. Revisar o produto, não o produtor. Uma RTF envolve pessoas e egos. Con-
duzida de forma apropriada, a RTF deve deixar todos os seus participantes com uma
agradável sensação de dever cumprido. Conduzido de forma imprópria, a RTF pode
assumir a aura de uma inquisição. Os erros devem ser apontados gentilmente; o clima
da reunião deve ser descontraído e construtivo; o intuito não deve ser o de causar
embaraços ou menosprezo. O líder da revisão deve conduzir a reunião de revisão de tal
forma a garantir que o clima seja mantido e as atitudes sejam apropriadas; além disso,
deve interromper imediatamente uma revisão que começou a sair do controle.
capítulo 1 • 35
2. Estabelecer uma agenda e mantê-la. Um dos principais males de reuniões
de todos os tipos é desviar do foco. Uma RTF deve ser mantida em seu rumo e prazo
estabelecidos. O líder da revisão tem a responsabilidade de manter o cronograma da
reunião e não deverá ficar receoso em alertar as pessoas quando ela estiver saindo do
foco.
3. Limitar debates e refutação. Quando uma questão é levantada por um revisor,
talvez não haja um acordo universal sobre seu impacto. Em vez de perder tempo de-
batendo a questão, o problema deve ser registrado para posterior discussão, fora da
reunião.
4. Enunciar as áreas do problema mas não tentar resolver todo o problema
registrado. Uma visão não é uma sessão para resolução de problemas. A solução de
um problema pode, muitas vezes, ser realizada pelo próprio produtor ou com a ajuda de
apenas outro colega. A resolução de problemas deve ser adiada para depois da reunião
de revisão.
5. Tomar notas. Algumas vezes é uma boa ideia para o registrador fazer aponta-
mentos em um quadro, de modo que os termos e as prioridades possam ser avaliados
por outros revisores à medida que as informações são registradas. Alternativamente, as
anotações podem ser introduzidas diretamente em um notebook.
6. Limitar o número de participantes e insistir na preparação antecipada.
Duas cabeças funcionam melhor do que uma, mas catorze cabeças não funcionam,
necessariamente, melhor do que quatro. Mantenha o número de pessoas envolvidas
no mínimo necessário. Entretanto, todos os membros da equipe de revisão devem se
preparar com antecedência. O líder da revisão deve solicitar comentários escritos (for-
necendo uma indicação de que o revisor reviu o material).
7. Desenvolver uma lista de verificação para cada artefato que provavelmen-
te será revisado. A lista de verificação ajuda o líder da revisão a estruturar a RTF e
auxilia cada revisor a se concentrar nas questões importantes. As listas de verificação
devem ser desenvolvidas para análise, projeto, código e até mesmo para o teste dos
artefatos.
8. Alocar os recursos e programar o tempo para as RTFs. Para as revisões
serem eficazes, elas devem ser programadas como tarefas durante a gestão de qua-
lidade . Além disso, deve-se programar o tempo para as inevitáveis modificações que
ocorrerão como resultado de uma RTF.
36 • capítulo 1
9. Realizar treinamento significativo para todos os revisores. Para serem efica-
zes, todos os participantes de uma revisão deveriam receber algum treinamento formal.
O treinamento deve enfatizar tanto questões relacionadas a processos, como o lado
psicológico das revisões.
10. Revisar revisões iniciais. Um interrogatório pode ser benéfico na descoberta de
problemas com o próprio processo de revisão. Os primeiros artefatos a serem revisados
devem ser as próprias diretrizes de revisão.
Devido às diversas variáveis envolvidas, como por exemplo o número de

participantes, o tipo de artefatos resultantes, o momento, o tempo adequado,
a duração e a abordagem que será feita, é importante notar que estes fatores
podem causar impactos significativos na revisão. Assim, em função deste con-
junto de fatores, é recomendado que a organização avalie as melhores práticas
e abordagens, avaliando seus resultados dentro do contexto local de onde está
sendo realizado as RTFs.
1.10 Confiabilidade de software

A confiabilidade é um importante elemento da qualidade global do software,
tanto que, se um sistema falhar com frequência e de modo repetitivo, pouco
importará se outros fatores de qualidade de software estão de acordo. O softwa-
re em questão estará com a confiança e credibilidade comprometida, com sua
qualidade final afetada.
O uso de dados históricos e de desenvolvimento permitem mensurar e es-
timar, diferentemente de outros fatores de qualidade. Pressman (2011, p. 395)
define a confiabilidade de software em termos estatísticos como “a probabili-
dade de operação sem falhas de um programa de computador em um dado am-
biente por um determinado tempo”. Para exemplificar este conceito, estima-se
que o programa X tenha uma confiabilidade de 0,999 depois de decorridas dez
horas de processamento. Portanto, isto quer dizer que, se o programa X tiver
que ser executado 1.000 vezes e precisar de um total de dez horas de tempo de
processamento (tempo de execução), é provável que ele opere corretamente
(sem falhas) 999 vezes (PRESSMAN, 2011, p. 395).
capítulo 1 • 37
Uma questão sempre presente quando se trata do assunto de confiabilidade
é a respeito do significado do termo “falha”. Falha pode ser considerada como a
falta de conformidade com os requisitos de software. Mesmo dentro dessa defi-
nição existem algumas variações, podendo ser apenas problemáticas ou catas-
tróficas. Conforme Pressman (2011, p. 395), uma determinada falha pode ser
corrigida em segundos, enquanto outras podem necessitar de semanas ou até
mesmo meses para serem corrigidas. Em outras situações, complicando ainda
mais o problema, a correção de uma falha pode, na realidade, resultar na intro-
dução de outros erros que resultarão em outras falhas.
Silva Filho (2014) ressalta um importante ponto, dizendo que a confiabi-
lidade de software acaba se tornando uma propriedade determinante para o
produto, pois ela é observável pelos usuários, mostrando a necessidade de as-
segurar a qualidade e sua capacidade de não apresentar falhas quando está em
produção (uso).
Outro atributo importante dos sistemas de software é a disponibilidade, que
pode ser compreendida como sendo a probabilidade de, em qualquer instante de
tempo, um sistema funcionar de modo satisfatório num determinado ambiente.
Ou seja, é a probabilidade de um sistema estar disponível quando necessário. A
disponibilidade pode ser determinada pela relação (SILVA FILHO, 2014):
Disponibilidade = ((MTTF) / (MTTF + MTTR)) x 100%

onde:
MTTF (Mean Time to Failure) é o tempo médio até a ocorrência de falha.
MTTR (Mean Time to Repair) é o tempo médio de reparo.
A confiabilidade e a disponibilidade, como atributos de qualidade, consti-

tuem a base da Engenharia de Confiabilidade de Software (ECS), a qual é defini-
da “como o estudo quantitativo do comportamento operacional de sistemas de
software com base nos requisitos de usuários relativo à confiabilidade” (SILVA
FILHO, 2014).
A Engenharia de Confiabilidade de Software ou ECS, abrange técnicas de
engenharia para desenvolver e oferecer manutenção a sistemas de software nos
quais a confiabilidade pode ser avaliada de modo quantitativo. Com o objetivo
de estimar e prever adequadamente a confiabilidade de sistemas de software,
dados das falhas de software necessitam ser medidos durante as fases de de-
senvolvimento e operacional (SILVA FILHO, 2014).
38 • capítulo 1
De acordo com Silva Filho (2004), a ECS inclui:
• Medição de confiabilidade de software, a qual inclui estimativa e previsão com o uso

de modelos de confiabilidade de software.
• Atributos e métricas de projeto de produtos, processo de desenvolvimento, arquite-
tura de sistema, ambiente operacional do software e suas implicações sobre a confia-
bilidade.
• Aplicação deste conhecimento na especificação e projeto da arquitetura de software
do sistema, desenvolvimento, testes, uso e manutenção.
• Para tanto, torna-se necessária a coleta de dados de falhas. Esses dados são cole-
tados para se fazer a medição da confiabilidade de software. Essa coleta compreende:
• Contagem de falhas – esse tipo de dado faz o rastreamento da quantidade de falhas
detectadas por unidade de tempo;
• Tempo médio entre falhas – esse tipo de dado faz o rastreamento dos intervalos entre
falhas consecutivas.
Além destes pontos, a ECS também requer a medição de confiabilidade de

software que envolve duas atividades: estimação e previsão de confiabilidade. A
atividade de estimação determina a confiabilidade de software atual aplicando
técnicas estatísticas de inferência aos dados de falhas obtidos durante o teste
do sistema ou durante a operação do sistema. Esta é uma importante medida
que considera a confiabilidade obtida desde um instante passado até o instan-
te atual. Seu principal objetivo é avaliar a confiabilidade atual e determinar se o
modelo de confiabilidade está bem ajustado (SILVA FILHO, 2014).
Já a atividade de previsão determina a confiabilidade de software em uma
perspectiva futura baseada em métricas de software e medidas disponíveis.
Dependendo do estágio de desenvolvimento, a previsão pode envolver diferen-
tes técnicas como (SILVA FILHO, 2014):
• Quando os dados de falhas estão disponíveis – Por exemplo, o software encon-

tra-se em testes ou no estágio operacional. Neste caso, as técnicas de estimação po-
dem ser usadas para parametrizar e verificar os modelos de confiabilidade de software,
os quais realizam previsão de confiabilidade de software futura.
capítulo 1 • 39
• Quando os dados de falhas não estão disponíveis – Por exemplo, quando o sof-
tware ainda encontra-se na fase de projeto ou implementação. Neste caso, as métricas
obtidas do processo de desenvolvimento de software e as características do produto
resultante podem ser utilizadas para determinar a confiabilidade de software durante
a fase de testes.
Segurança e Confiabilidade
“Não obstante, a confiabilidade e a segurança de software estejam estreitamente re-
lacionadas, é importante compreender a sutil diferença entre elas. A confiabilidade de
software usa a análise estatística para determinar a probabilidade de que uma falha de
software venha a ocorrer. Entretanto, a ocorrência de uma falha não necessariamente
resulta num risco ou deformação. A segurança de software examina as maneiras se-
gundo as quais as falhas resultam em condições que podem levar a uma deformação.
Ou seja, as falhas não são consideradas no vazio, mas são avaliadas no contexto de um
sistema inteiro computadorizado
Segurança de software é um atividade de garantia de qualidade de software que
se concentra na identificação e avaliação de casualidades em potencial que possam
exercer um impacto negativo sobre o software e fazer com que todo o sistema falhe.
Logo que as casualidades a nível de sistema são identificadas, técnicas de análise
são usadas para definir a gravidade e a probabilidade de ocorrência, tais como, análise
em árvore, lógica de tempo real ou modelos de rede de Petri. Após as casualidades
serem identificadas e analisadas, os requisitos relacionados à segurança podem ser
especificados para o software”.
(BUENO e CAMPELO, 2014, p. 16)
ATIVIDADES
Vamos praticar um pouco os conceitos aprendidos. Responda às seguintes questões:
01. A qualidade de software é uma área de conhecimento da engenharia de software que

objetiva garantir a qualidade do software através da definição e normatização de processos
de desenvolvimento. Para que um software seja considerado “de qualidade”, é necessário
que este tenha conformidade com alguns conceitos. Marque a alternativa que representa o
conceito de Eficiência:
40 • capítulo 1
a) Deve realizar suas tarefas em tempo adequado à complexidade de cada um deles. E
devem utilizar de modo eficiente os recursos de hardware disponíveis.
b) Deve permitir expansão de suas funcionalidades para atender novos requisitos ou incor-
porar novas tecnologias.
c) Deve funcionar de forma correta. Satisfazendo as suas especificações sem falhas ou
erros.
d) Deve ser fácil de aprender e de usar, permitindo maior produtividade do usuário, flexibi-
lidade de utilização e aplicação e proporcionar satisfação ao usuário.
e) Suas especificações satisfazem os requisitos dos usuários e da organização.
02. Quais são os principais objetivos da revisões técnicas fomais (RTF)?
03. Usando a definição de qualidade de software proposta neste capítulo, você acredita que
seja possível criar um produto útil que gere valor mensurável sem usar um processo eficaz?
Justifique sua resposta.
04. Na sua avaliação, o que pode ser considerado um software de boa qualidade? Justifique.
05. Qualidade e segurança são a mesma coisa? Explique.
REFLEXÃO
A área de qualidade, tanto na engenharia tradicional, quanto na engenharia de software é
sem dúvida bastante polêmica e discutida. Porém, após termos estudado os tópicos deste
capítulo, podemos perceber que o comprometimento da organização em adotar esses pa-
drões é muito importante.
Não adiantaria um esforço somente da equipe de software de uma organização para a
equipe atingir padrões de excelência no desenvolvimento de software.
Normalmente, a adoção de um programa de qualidade aplicado ao software está relacio-
nada com a adoção da empresa como um todo a assumir compromissos de melhoria da qua-
lidade de seus produtos e serviços. Porém, isso é um pouco difícil de encontrar no mercado,
mas felizmente tem mudado, pois as empresas estão sentindo a necessidade de mudança
em busca de melhores padrões e práticas, pois os seus clientes começaram a exigi-los e
cobram as empresas de software por eles.
capítulo 1 • 41
Portanto, trata-se de um fator de vantagem competitiva para as empresas de software. O
gestor de TI também tem que se preocupar com estas questões porque lidar com fornecedo-
res de software e suas equipes é um fator muito importante para o sucesso de seus projetos.
LEITURA
Existem muitos materiais, artigos e livros bons na área de qualidade de software.
• Qualidade de Software - 2ª ed., Novatec, livro dos autores André Koscianski e Michel dos
Santos Soares, de 2007. Este livro aborda as principais tecnologias, metodologias e proces-
sos utilizados atualmente em desenvolvimento de software.
• Molinari, L. Testes de Software: produzindo sistemas melhores e mais confiáveis. São
Paulo: Érica, 2006.
• Rocha, A.R.C.; Maldonado, J. C.; Weber, K. C. Qualidade de Software: teoria e prática. São
Paulo: Prentice Hall, 2001.
Anualmente, a Sociedade Brasileira de Computação (SBC) promove um simpósio na-
cional na área de qualidade de software. Os anais destes eventos são grandes referências e
recomendações de ampliação dos horizontes nesta área.
REFERÊNCIAS BIBLIOGRÁFICAS
BARRETO JÚNIOR, J.; Qualidade de Software. Disponível em: <http://www2.unemat.br/
rhycardo/download/qualidade_em_software.pdf>. Acessado em: 16 dez 2014.
BUENO, C. F. S.; CAMPELO, G. B.; Qualidade de Software. UFPE. Disponível em: <http://
sistemas.riopomba.ifsudestemg.edu.br/dcc/materiais/1022789570_Qualidade%20
de%20Software.pdf>. Acesso em: 17 dez 2014.
BUENO, L. C.; Gestão da Qualidade Como um Desafio à Manutenção de Software.
Monografia. Instituto Superior de Administração e Economia do Mercosul. 2010. 8p.
DORFMAN, M.; THAYER, R.; Standards, Guidelines and Examples of System and Sof-
tware Requirements Engineering, Institute of Electrical and Electronics Engineers,
Inc., 1990.
KOSCIANSKI, A.; SOARES, S. Qualidade de software. 2. ed. São Paulo: Novatec, 2007.
MARTINHO, F.; Qualidade, Qualidade de Software e Garantia da Qualidade de Software são
as mesmas coisas?. 2008. Disponível em: <http://www.testexpert.com.br/?q=node/669>.
Acesso em: 17 jan 2015.
42 • capítulo 1
PRESSMAN, R. S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill, 2011.
780p.
RAPCHAN, F.; A Norma ISO 9000-3. UFES. 2011. Disponível em: <http://www.geocities.
ws/chicorapchan/artigos/9000-3.pdf>. Acesso em: 17 jan 2015.
SAYÃO, M; BREITMAN, K K. Gerência de Requisitos. Disponível em <http://www-di.inf.
puc-rio.br/~karin/TELECOM/index_files/gerencia_req.pdf>. Acesso em: 24 nov de 2014.
SILVA FILHO, A. M.; Confiabilidade de Software. Revista Engenharia de Software Ma-
gazine. Ed. 8. Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-
8-confiabilidade-de-software/11312>. Acesso em: 11 dez 2014.
SLACK, N. et al. Administração da produção. São Paulo: Atlas, 1996.
capítulo 1 • 43
44 • capítulo 1
2
Processos de Ciclo
de Vida e Qualidade
Neste capítulo vamos estudar alguns modelos ou padrões de qualidade apli-
cados ao software. Veremos que existem muito mais detalhes do que simples-
mente documentar o sistema por meio de manuais técnicos.
Vimos no capítulo 1 o conceito de qualidade aplicada ao processo de sof-
tware. Verificamos que a qualidade está muito mais ligada ao processo do que
necessariamente ao produto final.
É muito importante que o profissional de TI conheça esses modelos e os
avalie a fim de aplicá-los em possíveis projetos nos quais possa haver algum
tipo de desenvolvimento ou até mesmo em empresas de desenvolvimento.
Trataremos dos processos de ciclo de vida e qualidade, com uma aborda-
gem sobre as normas de qualidade de produtos de software e os processos fun-
damentais, de apoio, organizacionais e de adaptação.
Bons estudos!
OBJETIVOS
• Conhecer algumas das principais normas de qualidade de produtos de software.

• Abordar sobre os processos fundamentais.
• Abordar sobre os processos de apoio.
• Abordar sobre os processos organizacionais.
46 • capítulo 2
2.1 Introdução
Para que a organização que produz software tenha sua qualidade reconhecida
em todo o mundo, seus processos devem respeitar padrões de qualidade defi-
nidos pela comunidade de software (SILVA, 2006, p. 9).
Um aspecto interessante da qualidade é que não basta que ela exista. Ela
deve ser reconhecida pelo cliente. Por causa disso, é necessário que exista al-
gum tipo de certificação oficial, emitida com base em um padrão ou modelo
de qualidade. Alguns tipos de certificados são bastante conhecidos, como por
exemplo os certificados de qualidade da série ISO-9000 (BARRETO JÚNIOR,
2014, p. 1).
A norma ISO-9000, por exemplo, foi criada pela ISSO (International
Organization for Standardization) para permitir que todas as empresas do mun-
do possam avaliar e julgar sua qualidade. Existindo um padrão único mundial,
uma empresa do Brasil, mesmo não tendo nenhum contato com uma outra em-
presa na Europa, pode garantir a ela a qualidade de seu trabalho (BARRETO
JÚNIOR, 2014, p. 1).
A certificação em uma norma ou padrão ocorre quando uma empresa ob-
tém um certificado oficial (documento) o qual indica que a empresa possui
conformidade com uma determinada norma ou padrão.
Segundo Silva (2006, p. 9), desde a década de 1980, iniciaram-se esforços
para melhoria de processos de software, com o objetivo de melhorar a qualida-
de, aumentar a produtividade e diminuir os custos. Diferentes modelos são uti-
lizados dependendo do mercado alvo das organizações de software (ROCHA et
al., 2001). As principais normas e modelos de qualidade difundidos atualmente
são: ISO 9000 (ISO, 2000), ISO/IEC 12207 (ISO/IEC, 1995), ISO/IEC 15504 (ISO/
IEC, 2003), CMMI (SEI, 2001) e MPS.BR (SOFTEX, 2006).
Neste capítulo iremos abordar alguns dos modelos ou padrões mais conhe-
cidos e utilizados, relacionados à qualidade de software.
A ISO é uma entidade internacional criada com o objetivo de padronizar normas, testes
e certificações entre os países.
Para se obter um certificado da ISO 9000 são necessários alguns passos:
11. Adquirir e estudar as normas pretendidas
capítulo 2 • 47
12. Implementar um sistema de gestão da qualidade segundo os requisitos da norma
pretendida, inclusive para software
13. Solicitar que um órgão certificador credenciado faça a avaliação do sistema im-
plantado.
O certificado obtido normalmente tem validade por 3 anos a contar da data de au-
ditoria de certificação. A empresa passa por avaliações periódicas durante esse período
de 3 anos. No Brasil, o INMETRO é o órgão do governo responsável pelo credencia-
mento das instituições avaliadora que realizam a certificação de sistemas de qualidade.
2.2 Normas de qualidade de produtos de

software
Quando pensamos em qualidade, normalmente pensamos em parâmetros de

comparação do tipo físicos como forma, tamanho, conforto, velocidade e etc.
Mas e no caso de software? Como estabelecer estes padrões de comparação?
Nas próximas seções vamos estudar alguns deles.
2.2.1 Qualidade de Produtos de Software - ISO 9126
A ISO publicou uma norma que representa uma padronização mundial para a
qualidade de produtos de software, trata-se da norma ISO/IEC 9126 e foi publi-
cada em 1991.
Esta norma é uma das mais antigas da área de qualidade de software e pos-
sui uma tradução para o Brasil, publicada em agosto de 1996 como NBR 13596.
Esta norma apresenta um conjunto de características que devem ser verifi-
cadas em um software para que ele seja considerado um “software de qualida-
de”. O conjunto consiste de 6 grupos divididos em alguns subgrupos (BARRETO
JÚNIOR, 2014, p. 5).
48 • capítulo 2
A figura 2.1 e a tabela 2.1 mostram o conjunto desta norma.
de
abilida
apt
Adeq
uaç Ad
Acurácia ão e de instalação
uldad
Fac
Interoperabilidade Coexistência
Segurança Capacidade para substituir
Fu Con
e form
idad idade co
cional
nc
a fun m a portabilidade
Conformidade com
de
ion
lida
bilidade
alid
Maturida
de alisa
An
abi
a de
Tolerância e falh ificabilidade
as Mod
rt
Po
Recuperabilidade Confi Estabilidade
ab ade
Conformidade com a confiab
ilidade ilid nibilid Testabilidade
ade ute Con
Man formi
dade co
m a manutenibilidade
Inteligibil
idad
e ISO 9126-1
Apreensibilid de Ef
ici m relação ao tempo
ade
l i da ê rtam
ento e
Operabilidade
Us a bi nc
ia Co
mpo
lação aos recursos
Atratividade Comportamento em re
Confo
de rmidade com
bilida a eficiência
Conformidade com a usa
Figura 2.1 – Norma ISO 9126-1. Fonte: Elaborado pelo autor.
CARACTERÍSTICA SUBCARACTERÍSTICA PERGUNTA CHAVE

Propõe-se a fazer o que é
Adequação
apropriado?
Faz o que foi proposto de forma
Acurácia
correta?
Funcionalidade Interage com os sistemas espe-
Interoperabilidade
(satisfaz as necessidades?) cificados?
Está de acordo com as normas,
Conformidade
leis, etc.?
Evita acesso não autorizado aos
Segurança de acesso
dados?
Com que frequência apresenta
Maturidade
falhas?
Confiabilidade Ocorrendo falhas, como ele
Tolerância a falhas
(é imune a falhas?) reage?
É capaz de recuperar dados em
Recuperabilidade
caso de falha?
É fácil entender o conceito e a
Inteligibilidade
aplicação?
Usabilidade
Apreensibilidade É fácil aprender a usar?
(é fácil de usar?)
Operacionabilidade É fácil de operar e controlar?
capítulo 2 • 49
Tempo Qual é o tempo de execução?
Eficiência
(é rápido e enxuto?) Quanto recurso usa? Durante
Recursos
quanto tempo?
É fácil de encontrar uma falha,
Analisabilidade
quando ocorre?
Modificabilidade É fácil modificar e adaptar?

Manutenibilidade
(é fácil de modificar?) Há grande risco quando se faz
Estabilidade
alterações?
É fácil testar quando se faz
Testabilidade
alterações?
É fácil adaptar a outros ambien-
Adaptabilidade
tes?
É fácil instalar em outros am-
Portabilidade Capacidade de ser instalado
bientes?
(é fácil de usar em outro
Está de acordo com padrões de
ambiente?) Conformidade
portabilidade?
É fácil usar para substituir
Capacidade. de substituir
outro?
Tabela 2.1 – Norma ISO 9126. Fonte: BARRETO JÚNIOR (2014, p. 5).
Essa norma não é muito extensa porém define detalhadamente o que se

pretende avaliar em cada grupo e subgrupo.
Embora a norma ISO 9126/NBR 13596 enumere as características e subca-
racterísticas de um software, ela ainda não define como dar uma nota a um sof-
tware em cada um destes itens. Se você não está familiarizado com o processo
de avaliação de software, pode ter dificuldades em tentar utilizar a norma. Se
você pretende avaliar um software segundo esta norma, deve tentar atribuir va-
lores (como se fossem notas ou conceitos) a cada uma das subcaracterísticas.
2.2.2 Guias para a Avaliação da Qualidade - ISO 14598
É fácil perceber a necessidade de mais detalhes sobre como avaliar a qualidade de

um software. As características e subcaracterísticas da norma ISO/IEC 9126 apenas
começaram o trabalho. Faltava definir, em detalhes, como atribuir um conceito
para cada item. Afinal, sem uma padronização, que valor teria uma avaliação?
A ISO, consciente deste problema, está finalizando o trabalho em um con-
junto de Guias para a Avaliação da Qualidade segundo a norma ISO/IEC 9126.
Estes guias descrevem, detalhadamente, todos os passos para que se avalie um
software (BARRETO JÚNIOR, 2014, p. 8).
50 • capítulo 2
Esta nova norma traz muitos recursos interessantes aos avaliadores, já que
trata o processo de avaliação em grande detalhe. Ela leva em conta a existência de
três grupos interessados em avaliar um software, o que define os três tipos bási-
cos de certificação conforme mostra a tabela 2.2 (BARRETO JÚNIOR, 2014, p. 8):
CERTIFICAÇÃO QUEM REALIZA? FINALIDADE

Empresas que desenvolvem Melhorar a qualidade de seu próprio
De 1ª parte
software produto
Determinar a qualidade do produto que
De 2ª parte Empresas que adquirem software
irão adquirir
Emitir documento oficial sobre a qualidade
De 3ª parte Empresas que fazem certificação
de um software
Tabela 2.2 – Certificações da ISO14598. Fonte: BARRETO JÚNIOR (2014, p. 8).
Esta norma é constituída, na verdade, de seis documentos distintos, relacio-

nados entre si mostrados na tabela 2.3:
NORMA NOME FINALIDADE

14598-1 Visão Geral Ensinar a utilizar as outras normas do grupo
14598-2 Planejamento e Gerenciamento Sobre como fazer uma avaliação, de forma geral
Como avaliar sob o ponto de vista de quem desen-

14598-3 Guia para Desenvolvedores
volve
Como avaliar sob o ponto de vista de quem vai
14598-4 Guia para Aquisição
adquirir
Como avaliar sob o ponto de vista de quem certi-
14598-5 Guia para Avaliação
fica
Detalhamento sobre como avaliar cada caracte-
14598-6 Módulos de Avaliação
rística
Tabela 2.3 – Documentos da ISO14598. Fonte: adaptado de BARRETO JÚNIOR (2014, p. 8).
Resumidamente, esta nova norma complementa a ISO/IEC 9126 e permite

uma avaliação padronizada das características de qualidade de um software.
É importante notar que esta norma entra em detalhes mínimos, incluindo
modelos para relatórios de avaliação, técnicas para medição das caracterís-
ticas, documentos necessários para avaliação e fases da avaliação, o que não
ocorre na norma ISO 9126.
capítulo 2 • 51
2.2.3 Qualidade de Pacotes de Software - ISO 12119
Esta norma foi publicada em 1994 e trata da avaliação de pacotes de software,

também conhecidos como “software de prateleira”. Além de estabelecer os re-
quisitos de qualidade para este tipo de software, ela também destaca a neces-
sidade de instruções para teste deste pacote, considerando estes requisitos. A
norma divide-se em itens, da seguinte forma (BARRETO JÚNIOR, 2014, p. 9):
1. Escopo
2. Definições
3. Requisitos de qualidade
a) Descrição do Produto: descreve o produto, de forma a ajudar o comprador
em potencial, servindo como base para testes. Cada declaração deve ser correta
e testável. Deve incluir declarações sobre funcionalidade, confiabilidade, usabili-
dade, eficiência, manutenibilidade e portabilidade.
b) Documentação do usuário: deve ser completa, correta, consistente, fácil de
entender e capaz de dar uma visão geral do produto.
c) Programas e dados: descreve em detalhes cada uma das funções do sof-
tware, incluindo declarações sobre funcionalidade, confiabilidade, usabilidade, efi-
ciência, manutenibilidade e portabilidade.
4. Instruções para teste
a) Pré-requisitos de teste: Lista de itens necessários ao teste, incluindo docu-
mentos incluídos no pacote, componentes do sistema e material de treinamento.
b) Atividades de teste: Instruções detalhadas sobre os procedimentos de tes-
te, inclusive instalação e execução de cada uma das funções descritas.
c) Registro de teste: Informações sobre como os testes foram realizados, de tal
forma a permitir uma reprodução destes testes. Deve incluir parâmetros utilizados,
resultados associados, falhas ocorridas e até a identidade do pessoal envolvido.
d) Relatório de teste: Relatório incluindo: identificação do produto, hardware
e software utilizado, documentos utilizados, resultados dos testes, lista de não
conformidade com os requisitos, lista de não conformidade com as recomenda-
ções, datas, etc.
Tabela 2.4 – Divisão da norma ISO 12119.
Um dos grandes méritos desta norma está na profundidade com que são
descritas cada uma das características e subcaracterísticas mencionadas na
52 • capítulo 2
norma 9126. A norma inclui detalhes que devem estar presentes no produto,
tais como (BARRETO JÚNIOR, 2014, p. 10):
• Documentação do usuário de fácil compreensão

• Um sumário e um índice remissivo na documentação do usuário
• Presença de um Manual de instalação com instruções detalhadas
• Possibilidade de verificar se uma instalação foi bem sucedida
• Especificação de valores limites para todos os dados de entrada, que deverão ser
testados
• Operação normal mesmo quando os dados informados estão fora dos limites espe-
cificados
• Consistência de vocabulário entre as mensagens e a documentação
• Função de auxílio (help) com recursos de hipertexto
• Mensagens de erro com informações necessárias para a solução da situação de erro
• Diferenciação dos tipos de mensagem: confirmação, consulta, advertência e erro
• Clareza nos formatos das telas de entrada e relatórios
• Capacidade de reverter funções de efeito drástico
• Alertas claros para as consequências de uma determinada confirmação
• Identificação dos arquivos utilizados pelo programa
• Identificação da função do programa que está sendo executada no momento
• Capacidade de interromper um processamento demorado
• Outras características importantes são a ênfase nos testes e os modelos de relató-
rios incluídos. Tudo isso facilita grandemente o trabalho do avaliador.
2.2.4 A Série ISO 9000
Esta série é um conjunto de normas da ISO que define padrões para garantia e
gerenciamento da qualidade. Veja algumas destas normas a seguir:
NORMA TRATA DE
Modelo para garantia da qualidade em projeto, desenvolvimento, produção,

ISO 9001 instalação e assistência técnica
ISO 9002 Modelo para garantia da qualidade em produção e instalação
capítulo 2 • 53
NORMA TRATA DE
ISO 9003 Modelo para garantia da qualidade em inspeção e ensaios finais
ISO 9000-1 Diretrizes para a escolha entre as normas ISO 9001, 9002 e 9003
ISO 9000-3 Orientação para a aplicação da ISO 9001 em Software
Tabela 2.5 – Normas da ISO 9000. Fonte: BARRETO JÚNIOR (2014, p. 11).
De acordo com Barreto Júnior (2014, p. 11), entre as normas 9001, 9002 e
9003, a primeira é a que mais possui aderência ao desenvolvimento e manu-
tenção de software. Como toda norma deste grupo, ela é usada para garantir
que um fornecedor atende aos requisitos especificados nos diversos estados do
desenvolvimento. Estes estágios incluem projeto, desenvolvimento, produção,
instalação e suporte.
O Padrão ISO 9001:2000

A descrição a seguir define os elementos básicos do padrão ISO 9001:2000.
Informações completas sobre o padrão podem ser obtidas da lnternational Organization
for Standardization (www.iso.ch) e outras fontes na Internet (por exemplo, www.praxiom.
com).
• Estabelecer os elementos de um sistema de gestão da qualidade.
• Desenvolver, implementar e aperfeiçoar o sistema.
• Definir uma política que enfatize a importância do sistema.
• Documentar o sistema de qualidade.
• Descrever o processo.
• Produzir um manual operacional.
• Desenvolver métodos para controlar (atualizar) documentos. Estabelecer métodos
para manutenção de registros.
• Dar suporte ao controle e à garantia da qualidade.
• Promover a importância da qualidade entre todos os interessados.
• Focar na satisfação do cliente.
• Definir um plano de qualidade que atenda aos objetivos, às responsabilidades e à
autoridade.
• Definir mecanismos de comunicação entre os interessados. Estabelecer mecanismos
de revisão para um sistema de gestão da qualidade.
54 • capítulo 2
• Identificar métodos de revisão e mecanismos de feedback. Definir procedimentos de
acompanhamento.
• Identificar recursos de qualidade, incluindo elementos de pessoal, treinamento e in-
fraestrutura. Estabelecer mecanismos de controle. Para planejamento.
• Para as necessidades do cliente.
• Para as atividades técnicas (por exemplo, análise, projeto, testes).
• Para monitoramento e gerenciamento de projetos. Definir métodos para reparação.
• Avaliar dados e métricas de qualidade.
• Definir a abordagem para processos e aperfeiçoamento contínuos da qualidade.
(PRESSMAN, 2011, p. 398)
A ISO 9000:2000 é baseada em um conjunto de princípios de gerenciamento de

qualidade, definidos a partir da experiência de várias organizações (ISO, 2000):
• Princípio 1 - Foco no cliente: Dado que as organizações dependem de seus clientes,
é recomendável que atendam às suas necessidade atuais e futuras e aos seus requisi-
tos e procurem exceder as suas expectativas.
• Princípio 2 - Liderança: Líderes estabelecem a unidade de propósito e o rumo da
organização. Convém que criem e mantenham um ambiente onde as pessoas estejam
totalmente envolvidas no propósito de atingir os objetivos da organização.
• Princípio 3 - Envolvimento de pessoas: Pessoas de todos os níveis são a essência de
uma organização. Seu envolvimento possibilita o aproveitamento de suas habilidades
por toda a organização.
• Princípio 4 - Abordagem de processo: Um resultado desejado é alcançado mais

eficientemente quando suas atividades e recursos são gerenciados como um processo.
• Princípio 5 - Abordagem sistêmica para a gestão: Identificar, entender e gerenciar
os processos inter-relacionados como um sistema contribui para a eficácia e eficiência
da organização no sentido desta atingir os seus objetivos.
• Princípio 6 - Melhoria contínua: Convém que a melhoria contínua do desempenho
global da organização seja seu objetivo permanente.
• Princípio 7 - Abordagem factual para tomada de decisão: Decisões eficazes são
baseadas na análise de dados e informações.
• Princípio 8 - Benefícios mútuos nas relações com os fornecedores: Pelo fato de or-
ganização e fornecedores serem interdependentes, uma relação de benefícios mútuos
aumenta a capacidade de ambos em agregar valor.
(SILVA, 2006, p. 10)
capítulo 2 • 55
A norma ISO 9000-3 (não confundir com ISO 9003!) traz os roteiros para
aplicar a ISO 9001 especificamente na área de desenvolvimento, fornecimento
e manutenção de software. Todas as orientações giram em torno de uma “situ-
ação contratual”, onde uma outra empresa contrata a empresa em questão para
desenvolver um produto de software. Veja na tabela 2.6 abaixo os processos de-
finidos na ISO 9000-3 (BARRETO JÚNIOR, 2014, p. 12):
GRUPO ATIVIDADE
Responsabilidade do fornecedor
ESTRUTURA DO SISTEMA DE QUALIDADE Responsabilidade do comprador
Análise crítica conjunta
Análise crítica do contrato
Especificação dos requisitos do comprador
Planejamento do desenvolvimento
Projeto e implementação
ATIVIDADES DO CICLO DE VIDA Testes e validação
Aceitação
Cópia, entrega e instalação
Manutenção
Gerenciamento de configuração
Controle de documentos
Registros da qualidade
Medição
ATIVIDADES DE APOIO Regras, convenções
Aquisição
Produto de software incluído
Treinamento
Tabela 2.6 – Processos definidos na ISO 9000-3. Fonte: BARRETO JÚNIOR (2014, p. 10).
O processo de certificação de uma empresa de software segundo as nor-

mas ISO 9001 / 9000-3 segue um conjunto de passos bem definidos (BARRETO
JÚNIOR, 2014, p. 10):
1. A empresa estabelece o seu sistema de qualidade.

2. A empresa faz uma solicitação formal a um órgão certificador, incluindo detalhes do
negócio da empresa, escopo da certificação solicitada e cópia do manual de qualidade.
3. O órgão certificador faz uma visita à empresa, colhe mais dados e explica o pro-
cesso de certificação.
4. O órgão certificador verifica se a documentação do sistema de qualidade está de
acordo com a norma ISO.
56 • capítulo 2
5. O órgão certificador envia uma equipe à empresa com fins de auditoria. Nesta vi-
sita, será verificado se todos na empresa cumprem o que está documentado no manual
de qualidade.
6. O órgão certificador emite o certificado de qualidade.
7. O órgão certificador realiza visitas periódicas à empresa para assegurar que o
sistema continua sendo efetivo.
CONEXÃO
No site http://www.12207.com há uma página que lista os padrões de processo de software.
Por meio desta página você consegue maiores informações sobre o cada norma e encon-
tra os links que lhe direcionará diretamente à página de cada norma. Vale a pena conferir:
http://migre.me/oIBCn
De acordo com Wazlawick (2013, p. 363), a série 9000 é conhecida como um con-
junto de normas que enfatiza a documentação de processos e procedimentos. Ela
estabelece quatro níveis de documentação cada vez mais detalhados e complexos:
a) Nível 1: neste nível genérico é exigido basicamente um manual geral de qualida-

de explicando a política e o sistema de qualidade, bem como a estrutura organizacional
da empresa e os papéis ou responsabilidades.
b) Nível 2: neste nível, os processos são documentados pelos manuais de proce-
dimentos. Eles devem abranger todas as atividades ligadas ao desenvolvimento e for-
necimento de software, independentemente do ciclo de vida adotado, estabelecendo
como as atividades devem ser executadas, quais suas dependências e quais os perfis
de responsáveis (Capítulo 2).
c) Nível 3: neste nível devem ser detalhadas as instruções sobre como proceder
para o eficaz funcionamento do sistema de qualidade, abrangendo as atividades de
teste, inspeção, especificações, modelo e requisitos de qualidade etc. (Zahran, 1997).
d) Nível 4: neste nível devem ser mantidos os registros de qualidade, ou seja, resul-
tados de testes e inspeções que comprovam que as atividades do sistema de qualidade
documentado no nível 3 são efetivamente executadas.
(WAZLAWICK, 2013, p. 363)
capítulo 2 • 57
A documentação relacionada ao sistema de qualidade também pode ser
classificada segundo outros critérios, de acordo com Wazlawick (2013, p. 363):
• Documentação da qualidade: todos os documentos que estabelecem processos,

políticas e regras sobre como executar as atividades relacionadas à qualidade.
• Registros da qualidade: resultados dos processos de avaliação da qualidade que
indicam que os documentos da qualidade não são apenas letra morta, mas que são
efetivamente usados na empresa.
Espera-se que os documentos de qualidade sejam estabelecidos e, à medida

que amadurecem, alcancem certa estabilidade, embora nunca devam estagnar.
Já os registros da qualidade são criados diariamente para cada projeto em de-
senvolvimento na empresa.
Além das normas relacionadas à qualidade, existem outras normas e mode-
los voltados para processos e entre estas normas vale destacar a ISO/IEC 12207,
que atua com praticamente todos os aspectos do ciclo de vida de um software,
servindo de base para várias outras normas, pois trata de assuntos que envol-
vem desde a concepção do software até a sua descontinuidade. Esta norma,
apresenta uma divisão de processos que podem ser assim divididas: Processos
Fundamentais, Processos de Apoio, Processos Organizacionais e ainda os
Processos de Adaptação (figura 2.2 e tabela 2.7).
Processos Fundamentais Processos de Apoio
Aquisição Documentação
Fornecimento Gerencia de Configuração

Garantia de Qualidade
Operação Verificação
Validação
Desenvolvimento Adapatação
Revisão Conjunta
Manutenção Auditoria
Resolução de Problemas
Processos Organizacionais
Gerência Infra-estrutura
Melhoria Treinamento
Figura 2.2 – Estrutura de processos da ISO/IEC 12207.
58 • capítulo 2
Iniciação
Preparação de pedido de proposta
Aquisição Preparação e atualização do contrato
Monitoração do fornecedor
Aceitação e conclusão
Iniciação
Preparação de resposta
Contrato
Fornecimento
Planejamento
Revisão e avaliação
PROCESSOS FUNDAMENTAIS DO CICLO DE VIDA
Entrega e conclusão
Implementação do processo
Análise dos requisitos do sistema
Projeto da arquitetura do sistema
Análise dos requisitos do software
Projeto da arquitetura do software
Projeto detalhado do software
Desenvolvimento
Codificação e teste do software
Integração do software
Teste de qualificação do software
Integração do sistema
teste de qualificação do sistema
Apoio à aceitação do software
Teste operacional
Operação
Operação do sistema
Suporte ao usuário
Análise do problema e da modificação
Implementação da modificação
Manutenção
Revisão/aceitação da manutenção
Migração
Descontinuação do software
capítulo 2 • 59
Projeto e desenvolvimento
Documentação
Produção
Manutenção
Identificação da configuração
Gerência de Controle da configuração
configuração Relato da situação da configuração
Avaliação da configuração
Gerência da liberação e distribuição
PROCESSOS DE APOIO
Garantia da quali- Garantia do produto
dade Garantia do processo
Sistemas de garantia da qualidade
Verificação
Verificação
Validação
Validação
Revisão conjunta Revisões de gerenciamento do projeto
Revisões técnicas
Auditoria
Auditoria
Resolução de Implementação do processo
problema Resolução de problema
Iniciação e definição do escopo
Planejamento
Gerência Execução e controle
PROCESSOS ORGANIZACIONAIS
Revisão e avaliação
Conclusão
Estabelecimento do processo
Melhoria Avaliação do processo
Melhoria do processo
Infra-estrutura Estabelecimento da infra-estrutura
Manutenção da infra-estrutura
Treinamento Desenvolvimento do material de treinamento
Implementação do plano de treinamento
Tabela 2.7 – Processos de ciclo de vida de software da ISO/IEC 12207.
2.3 Processos Fundamentais

A fim de alcançar diferencial competitivo, muitas empresas de todo o mundo,
inclusive do Brasil, vem usando a norma ISO/IEC 12207 como referência em re-
60 • capítulo 2
lação aos seus processos, já que a globalização da economia tem influenciado
as empresas produtoras e prestadoras de serviços a atingirem níveis de quali-
dade e produtividade de forma bem competitiva (NOGUEIRA, 2003, p. 7). De
acordo com Nogueira (2003, p. 7), “ela tem por objetivo auxiliar os envolvidos
na produção de software a definir seus papéis, por meio de processos bem de-
finidos, e assim proporcionar às organizações que a utilizam um melhor en-
tendimento das atividades a serem executadas nas operações que envolvem, de
alguma forma, o software”.
Os processos fundamentais inicialmente atendem à contratação entre o ad-
quirente e o fornecedor (aquisição e fornecimento) e a execução do desenvolvi-
mento, da operação ou manutenção de produtos de software durante o ciclo de
vida do software (NOGUEIRA, 2003, p. 7).
O planejamento é realizado de modo precário nas empresas de desenvolvi-
mento devido a ausência constante de documentação entre o desenvolvedor e
o adquirente, que está realizando a aquisição do produto ou do serviço. A ilusão
de pensarem que estas ações de planejamento, com especificações adequadas
de requisitos, poderiam ser “perda de tempo”, traz uma resistência em ambas
as partes interessadas em gerar documentação, afetando todo o planejamen-
to do projeto. Isto faz com que muitos desenvolvedores iniciem diretamente o
desenvolvimento (codificação) e como consequência, depois são levados a um
processo interminável de correção e manutenção, causando um significativo
desgaste da relação comercial entre as partes, além do não cumprimento dos
prazos de entrega e do custo do projeto que acumula prejuízos intangíveis, a
partir de estimativas aleatórias e inadequadas.
De maneira sintética, os processos fundamentais envolvem o início e exe-
cução do desenvolvimento, operação ou manutenção do software durante o seu
ciclo de vida (BARRETO JÚNIOR, 2014, p. 13). Para efeito de organização, a 12207
divide os processos em quatro grandes famílias (WAZLAWICK, 2013, p. 40):
• Aquisição: visa à obtenção do produto ou serviço relacionado à informáti-

ca que satisfaça as necessidades da empresa. Define as atividades do adquiren-
te, bem como as necessidades de adquirir um produto, sistema ou serviço de
software. Trata também da seleção do fornecedor.
• Fornecimento: seu objetivo é fornecer um produto ou serviço a terceiros.
Aqui é definido as atividades do fornecedor e determina os procedimentos e
recursos necessários.
capítulo 2 • 61
• Desenvolvimento: é definido como o processo de transformar um con-
junto de requisitos em um produto executável, definindo as atividades do de-
senvolvedor em análise de requisitos, projeto, codificação, integração, testes,
instalação e aceitação.
• Operação: tem como objetivo iniciar e manter o produto operando em
seu local definitivo, bem como prestar serviços aos usuários. É definido as ati-
vidades do operador, como a operação do produto de software e o suporte ope-
racional aos usuários.
• Manutenção: seu propósito é modificar o produto, removendo erros e
adequando-o a novos contextos. É definido as atividades do mantenedor, tra-
tando ainda dos problemas envolvidos, necessidades de melhoria e adaptação.
2.4 Processos de apoio

De acordo com Nogueira (2003, p. 9) os processos de apoio auxiliam e contri-
buem para o sucesso e a qualidade do projeto de software, sendo “empregado
e executado quando necessário para documentação, gerência de configuração,
garantia da qualidade, processo de verificação, processo de validação, revisão
conjunta, auditoria e resolução de problemas”.
Nogueira (2003, p. 9) ainda faz uma observação importante sobre a docu-
mentação do software e os processos de verificação e validação, relacionados
aos processos de apoio:
A documentação do software será a última tarefa que o desenvolvedor irá se preocupar,

sendo tratado como se não tivesse que acontecer antes do desenvolvimento propria-
mente dito, a fim de ser possível acompanhar se os requisitos do projeto foram atendi-
dos ou se nem foram especificados no momento oportuno. Os processos de verificação
e validação ocorrem unilateralmente, ou seja, “este requisito era óbvio, nem precisava
mencionar”, e para atender as necessidades do adquirente, este processo será repetido
por inúmeras vezes, alongando a manutenção e atrasando o funcionamento e atendi-
mento as necessidades do negócio (NOGUEIRA, 2003, p. 9).
É importante ressaltar que embora o objetivo dos processos de apoio seja

apoiar os processos fundamentais, não são eles que compõem as atividades
62 • capítulo 2
de desenvolvimento propriamente ditas. Os processos de apoio envolvidos são
(WAZLAWICK, 2013, p. 40):
• Documentação: tem como propósito criar e manter informações sobre o

produto e o processo de desenvolvimento. Envolvem os registros de informa-
ções do processo e atividade do ciclo de vida, de forma que estes documentos
possam ser distribuídos a todos os envolvidos.
• Gerência de configuração: seu objetivo é gerenciar e manter a consistên-
cia entre todas as versões dos produtos do trabalho, de forma a manter também
sua integridade. Para isto, é necessário realizar a identificação e definição dos
itens que irão compor o software, gerenciar e controlar as modificações, além
de garantir a integridade.
• Garantia de qualidade: tem como objetivo garantir que os produtos e ser-
viços estejam em conformidade com normas e padrões predefinidos, sendo
consistentes em relação aos requisitos.
• Verificação: tem como propósito garantir ou confirmar que os produtos
refletem e atendem completamente os requisitos especificados.
• Validação: objetiva garantir ou confirmar que os requisitos especificados
são os realmente desejados pelo cliente, validando o produto de software.
• Revisão conjunta: tem como objetivo manter um entendimento comum
entre os diversos interessados a respeito do produto, do processo ou do serviço.
As revisões são realizadas nos níveis de gerenciamento e técnico e são executa-
das durante toda a vigência do contrato.
• Auditoria: tem o propósito de prover uma avaliação, independentemente
dos produtos e processos, determinando ainda uma adequação do produto aos
requisitos, planos e contrato.
• Resolução de problemas: objetiva assegurar que todos os problemas le-
vantados sejam resolvidos, definindo um processo para analisá-los e resolvê
-los, bem como identificar tendências de novas ocorrências.
2.5 Processos organizacionais

Os processos organizacionais tem como propósito estabelecer e implementar
uma estrutura constituída pelos processos de ciclo de vida e pelo pessoal en-
volvido no desenvolvimento do software. Estes processos geralmente são em-
capítulo 2 • 63
pregados fora do domínio de projetos e contratos específicos, no entanto, o
aprendizado a partir dos ensinamentos destes projetos e contratos muito con-
tribuem para a melhoria da organização, por meio dos processos de Gerência,
Infra-estrutura, Melhoria e Treinamento (NOGUEIRA, 2003, p. 10).
O porte da empresa influencia no processo de gerência, sendo que existem
casos em que poderá existir uma pessoa responsável e em outras situações, o
próprio desenvolvedor pode assumir este papel de gerente. Note que, assumir
o papel não é o mesmo que ter a função. Assim, uma pessoa com a função de
desenvolvedor poderá assumir um papel de gerente, com responsabilidades
sobre o projeto, diferentemente de ser o gerente de projetos e executar práticas
pertinentes à esta função.
Sobre este assunto, Nogueira (2003, p. 10) comenta sobre a importância da
figura do gerente:
Para implementar os processos de infra-estrutura, melhoria e treinamento, é funda-

mental a figura de gerência que exercerá acompanhamento das necessidades do pro-
jeto e seus devidos ajustes quanto a estrutura necessária para um desenvolvimento
dentro dos requisitos do projeto, do dinamismo necessário para melhoria contínua do
processo e os devidos treinamentos para adequação das tecnologias especificadas
nos requisitos (NOGUEIRA, 2003, p. 10).
Segundo Barreto Júnior (2014, p. 14), os processos organizacionais imple-

mentam uma estrutura constituída de processo de ciclo de vida e pessoal asso-
ciados, o que faz melhorar de forma contínua a estrutura da organização e os
seus processos.
Desta forma, os processos organizacionais garantem o funcionamento da
organização. São eles (WAZLAWICK, 2013, p. 40):
• Gerência: visa organizar e controlar a realização dos projetos, bem como

seu desempenho, abrangendo as atividades genéricas de gerenciamento. O ge-
rente é o responsável pelo gerenciamento do produto, do projeto, das tarefas
de aquisição, fornecimento, desenvolvimento, operação, manutenção e apoio
e outras atividades relacionadas.
64 • capítulo 2
• Infraestrutura: tem como objetivo manter um ambiente de trabalho ade-
quado para qualquer outro processo, incluindo hardware, software, ferramen-
tas, um conjunto de técnicas, padrões e recursos. São utilizados no desenvolvi-
mento, operação e manutenção do software.
• Melhoria: visa permitir que os processos sejam continuamente adap-
tados, visando à otimização do trabalho, por meio de atividades de medição,
avaliação, controle e melhoria de processos do ciclo de vida de software. Estes
processos são aplicados pelo adquirente, fornecedor, desenvolvedor, operador,
mantenedor ou até mesmo por gerentes de outros processos.
• Treinamento ou recursos humanos: objetiva manter os recursos huma-
nos capacitados para o melhor desempenho possível de suas funções. consi-
derando ainda que outros processos são dependentes de pessoal qualificado.
2.6 Processos de Adaptação

Os processos de adaptação definem as atividades necessárias para adaptar a
norma ISO/IEC 12207 para ser aplicada na organização ou em projetos. De acor-
do com Nogueira (2003, p. 10), “a adaptação deve ser executada com base em
alguns fatores que diferenciam uma organização ou projeto de outros, dentre
os quais a estratégia de aquisição, modelos de ciclo de vida de projeto, caracte-
rísticas de sistemas e software e cultura organizacional”. Com a existência dos
processos de adaptação, a organização consegue adaptar a norma a qualquer
projeto desta ou em até mesmo ao modelo de ciclo de vida, cultura e técnica de
desenvolvimento nela empregada.
Ainda, segundo Nogueira (2003, p. 10), tem-se notado um movimento das
empresas para adoção de normas e modelos de maturidade do processo de de-
senvolvimento de software, buscando melhor produtividade e com ênfase em
promover uma reengenharia nos processos de desenvolvimento de software,
que até então eram basicamente vindos da experiência dos “desenvolvedores
de código” e não de gestores de projetos de grande expressão, e que assumem
papel de alta relevância nas empresas para se obter vantagens competitivas
num mercado global que busca a informação certa no momento certo.
Cada organização possui seus fatores que a fazes diferenciar das outras,
abrangendo diferentes estratégias de aquisição, modelos de ciclo de vida de
projeto, características de sistemas e a cultura organizacional. Neste contexto,
capítulo 2 • 65
pode-se mencionar ainda a norma ISO/IEC 15504, por tratar de qualidade e ní-
veis de capacidade em processo de software. A norma 15504, também conheci-
da como SPICE, é considerada uma evolução da ISO/IEC 12207 (WAZLAWICK,
2013, p. 41).
ATIVIDADES
01. Na sua opinião, quais seriam as principais dificuldades para uma empresa ou organiza-
ção implantar uma norma de qualidade de produtos de software? Justifique.
02. É possível desenvolver softwares sem qualquer tipo de controle de processos? Quais
seriam os impactos na qualidade deste software? Explique.
03. Toda empresa de desenvolvimento de softwares devem implantar uma norma de quali-
dade a ser seguida? Qual sua opinião sobre este ponto? Justifique.
04. Quais as principais normas de qualidade associadas à software utilizadas no Brasil. Ex-
plique.
05. Por que processos afetam a qualidade do software? Explique.
REFLEXÃO
Vimos neste capítulo que existem algumas normas de qualidade de produtos de software
que são fundamentais para as empresas seguirem padrões e oferecerem produtos de quali-
dade com vantagem competitiva.
Será que todas as empresas de desenvolvimento de software estão preparadas para
aplicarem normas de qualidade ou ainda aplicarem processos estruturados de acordo com
certos padrões? Podemos notar que há a necessidade de um envolvimento de toda a empre-
sa para que estas normas e padrões sejam efetivadas dentro da organização, sendo neces-
sário principalmente o apoio da alta gerência e das diferentes áreas funcionais.
Os processos fundamentais, de apoio, organizacionais e adaptativos são importantes
para que a empresa tenha uma estrutura sólida e madura em relação aos seus processos, e
se isto ocorrer, ela está garantindo o resultado final principal que é a produção de softwares
como produtos finais de qualidade.
66 • capítulo 2
LEITURA
Além dos materiais e documentos das próprias normas de qualidade, há umam infinidade de
materiais e artigos relacionados à elas, bem como capítulos exclusivos em livros de Enge-
nharia de Software em partes que tratam de qualidade de software e, naturalmente, nos livros
específicos deste assunto (Qualidade de Software).
Kiscianski, A.; Soares, M. S. Qualidade de Software. São Paulo: Novatec, 2007.
PRESSMAN, Roger S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill, 2011.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Práticas, 1a Edição, Elsevier, 2013.
Qualidade de Software - artigo de José Barreto Júnior com uma excelente abordagem sintetizada
sobre qualidade de software e suas principais normas.
http://migre.me/oKTuZ
Qualidade de Software - outro artigo sobre qualidade de software, com uma abordagem mais técnica e
comparativa, de autoria de Bueno, C. F. S. e Campelo, G. B., ambos da UFPE.
http://migre.me/oKTyu
BARRETO JÚNIOR, J.; Qualidade de Software. Disponível em: <http://www2.unemat.br/rhycardo/
download/qualidade_em_software.pdf>. Acessado em: 16 dez 2014.
ISO/IEC 12207, Information Technology - Software life cycle processes, 1995.
ISO/IEC 15504 Information Technology – Process Assessment – Part 1: Concepts ans
Vocabulary, 2003.
ISO 9000:2000, Sistemas de gestão da qualidade – Fundamentos e vocabulário, 2000.
NOGUEIRA, M. Qual a Importância da Adoção da Norma ISO 12207 Nas Empresas de
Desenvolvimento de Software?. X SIMPEP. 2003. Disponível em: <http://www2.dem.inpe.br/ijar/
ISO%2012207%20Artigo.pdf>. Acesso em: 18 dez 2014.
PRESSMAN, R. S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill, 2011. 780p.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER K. C. Qualidade de Software: Teoria e Prática. 1a.
Edição. Editora Prentice Hall. São Paulo. 2001.
SEI, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method
Definition Document, CMU/SEI-2001-HB-001, 2001.
SILVA, B. C. C.; Processos e Ferramentas para o Desenvolvimento de Software Livre: Um estudo
de caso. Mestrado; UFES; 2006; 93p.
capítulo 2 • 67
SOFTEX, MPS.BR – Melhoria de Processo do Software Brasileiro: Guia Geral, Versão 1.0, 2005b.
Disponível em: <www.softex.br/mpsbr>. Acesso em: 12 jan 2015.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Práticas, 1ª Edição, Elsevier, 2013. 506p.
68 • capítulo 2
3
Análise e
Especificação de
Requisitos
A análise e especificação de requisitos compõem uma etapa de grande impor-
tância e impacto no projeto de software. Veremos neste capítulo sobre alguns
pontos que envolvem as etapas de projeto, partindo desde a sua descrição, o
entendimento das necessidades envolvidas, levantamento e especificação de
requisitos até a definição do software propriamente dito.
Muitos projetos se iniciam sem a devida clareza de seus requisitos e muitas
vezes estes são levantados a partir das necessidades dos clientes. Estes clientes,
por sua vez, também nem sempre estão seguros de tudo o que querem para
o software ou sistema a ser desenvolvido e com isso muitos requisitos podem
surgir ou serem modificados ao longo do processo de desenvolvimento. A análi-
se prévia, bem estruturada, o uso de técnicas adequadas para levantamento de
requisitos e a sua especificação, contribuem para o sucesso do projeto.
A especificação de requisitos determina e limita com maior segurança as
atividades que deverão ser cumpridas, já que é a partir destes requisitos que
foram levantados e agora especificados, validados pelo cliente, que se iniciará e
apoiará todo o processo de desenvolvimento do software.
A partir deste capítulo, poderemos aprofundar um pouco mais nos con-
ceitos de requisitos de sistema e conseguiremos cada vez mais ampliar o nos-
so entendimento acerca da importância e de suas aplicações em projetos de
software.
Bons estudos!
OBJETIVOS
• Abordar sobre a descrição do projeto do software.

• Discutir a importância e o entendimento das necessidades do projeto.
• Aprender sobre levantamento de requisitos.
• Aprender sobre a especificação dos requisitos.
• Discutir a definição do software.
70 • capítulo 3
3.1 Introdução
O entendimento completo dos requisitos de software é um ponto fundamental
para o sucesso de um projeto de software e este certamente trará problemas ao
cliente/usuário se a sua análise de requisitos tiver sido mal realizada, indepen-
dente da precisão com a qual um software venha a ser projetado e implementa-
do (MAZZOLA, 2010, p. 63).
De acordo com Mazzola (2010, p. 63), a Análise de Requisitos “é uma tarefa
que envolve, antes de mais nada um trabalho de descoberta, refinamento, mo-
delagem e especificação das necessidades e desejos relativos ao software que
deverá ser desenvolvido”. A tarefa de análise de requisitos envolve tanto o clien-
te como o desenvolvedor, que desempenharão um papel de grande importân-
cia, cabendo ao cliente a formulação (de modo concreto) das necessidades em
termos de funções e desempenho, enquanto que o desenvolvedor atua como
questionador, consultor e busca solucionar os problemas levantados.
A Análise de requisitos é uma etapa muito significativa no processo de de-
senvolvimento de um software, principalmente porque ela faz a associação en-
tre os elementos que irão constituir o software e o projeto deste. Assim, ela per-
mite que o engenheiro de sistemas especifique as necessidades do software em
termos de funcionalidades e de desempenho, estabeleça as interfaces do sof-
tware com os outros elementos do sistema e também especificar as restrições
de projeto (MAZZOLA, 2010, p. 63). Além disto, ela ainda permite que engenhei-
ros de software, analistas ou modeladores elaborem mais as necessidades bási-
cas estabelecidas durante as tarefas de concepção, levantamento e negociação,
que fazem parte da engenharia de requisitos (PRESSMAN, 2011, p. 151).
3.2 Descrição do projeto do software

De acordo com Pressman (2011, p. 207), o projeto de software reside no núcleo
técnico da engenharia de software e é adotado em qualquer modelo de proces-
sos de software utilizado. O projeto é iniciado assim que os requisitos de sof-
tware tiverem sido analisados e modelados, preparando e deixando apto para
avançar para a fase de construção (geração de código e testes).
Primeiramente, um projeto de software consiste na elaboração de uma pro-
posta para a obtenção de um contrato a fim da realização do trabalho, incluin-
do a estimativa de custos e de cronograma (ZAMPAR e SOUZA, 2014).
capítulo 3 • 71
O projeto é o início de qualquer coisa ligada a engenharia, por exemplo, um engenheiro
civil não manda construir um prédio sem antes elaborar um planta, verificar o terreno
e outras coisas que denominamos de projeto, assim também é no desenvolvimento de
software você não pode construir nada sem antes projetar, mas como todo engenheiro,
antes mesmo de projetar alguma coisa deve-se ser desenvolvido um estudo para verifi-
car se o desenvolver do projeto é viável, cria-se também mecanismos de rastreamento
deste projeto para ver se tudo o que ele projetou esta acontecendo conforme o previs-
to, isto na engenharia de software é chamado de Gerência de Projeto que é o primeiro
aspecto do projeto de software (FORCHESATTO, 2012, p. 12).
Qualidade é a palavra que define a importância do projeto de software, e é

na etapa de Projeto em que a qualidade é incorporada na engenharia de softwa-
re. O projeto nos fornece representações de software que podem ser avaliadas
e analisadas em termos de qualidade. A única maneira em que podemos tradu-
zir precisamente os requisitos dos interessados em um produto ou sistema de
software finalizado, é por meio de Projeto . O projeto de software serve como
base para todas as demais atividades de apoio e da engenharia de software que
seguem. Sem a existência de projeto, aumenta-se o risco de construir um siste-
ma instável - um sistema que apresentará falhas quando forem feitas pequenas
alterações; um sistema com grande possibilidade de ser difícil de ser testado;
um sistema em que a qualidade qualidade não pode ser avaliada até uma fase
mais avançada do processo de software, quando o tempo é diminuto e muito
dinheiro já foi gasto (PRESSMAN, 2011, p. 208).
O projeto de software é um processo iterativo, com ciclos que se repetem
através do qual os requisitos são traduzidos em uma espécie de “planta” para
construir o software. Inicialmente, a planta representa uma visão geral (holís-
tica) do software. O projeto é representado em um alto nível de abstração - um
nível que pode ser associado diretamente ao objetivo específico do sistema e
aos requisitos mais detalhados de dados, funcionalidade e comportamento
(PRESSMAN, 2011, p. 209). À medida em que as iterações ocorrem, esta repre-
sentação vai mudando mais para o baixo nível, tornando-se cada vez mais pró-
ximo de especificações que permitirão sua execução, do ponto de vista do de-
senvolvimento das atividades.
72 • capítulo 3
Vale a pena salientar que o planejamento e o gerenciamento de projetos de
software abrangem produto, processo e pessoas que vão estar envolvidas no
projeto (ZAMPAR e SOUZA, 2014). As pessoas envolvidas e interessadas no pro-
jeto, como um todo, também são chamadas de stakeholders.
Stakeholder: é uma palavra muito usada em várias áreas como administração, projetos
e obviamente em software. Ela se refere a uma pessoa ou a um grupo interessado em
um determinado assunto e que deve estar de acordo em comum com o que está sendo
proposto. Normalmente o stakeholder é a parte que financia o projeto financeiramente
e responde na empresa por ele.
Zampar e Souza (2014) destacam que o gerenciamento de projetos de sof-

tware é fundamental na Engenharia de Software e que quando o gerenciamen-
to é realizado de forma incorreta resulta em falha, acarretando atraso, custo
elevado e requisitos mal especificados. Ou seja, um projeto de Engenharia de
Software deve estar estruturado em um planejamento adequado, para que se
possa gerenciar de forma condizente a sua realização.
A necessidade de gerenciamento é um fator claro na distinção entre o de-
senvolvimento profissional de software e a programação em nível amador. De
acordo com Sommerville (2006, p. 60), “o gerenciamento de projetos de sof-
tware é necessário porque a engenharia de software profissional está sempre
sujeita a restrições de orçamento e de prazo”. A organização que desenvolve o
software é que estabelece estas restrições e o trabalho do gerente de projeto
de software deve garantir e assegurar que o projeto de software cumpra todas
essas restrições e entregar um produto de software que contribua para as metas
da empresa. Segundo Zampar e Souza (2004), o gerente de software tem a fun-
ção de administrar os cronogramas e planos, para que não ocorram imprevis-
tos no prazo e no orçamento do projeto.
Os gerentes de software executam o mesmo tipo de trabalho que outros ge-
rentes de projeto de engenharia. No entanto, a engenharia de software difere de
outros tipos de engenharia em uma série de pontos e modos que podem tomar
o gerenciamento de software particularmente difícil. Sommerville (2006, p. 60)
cita algumas dessas diferenças:
capítulo 3 • 73
1. O produto é intangível - O gerente do projeto de construção de um navio ou de
um projeto de engenharia civil pode ver o produto sendo desenvolvido. Se há um atraso
na programação, o efeito no produto é visível. Partes da estrutura estão obviamente
inacabadas. O software é intangível; não pode ser visto ou tocado. Os gerentes de pro-
jeto de software não podem ver o progresso, eles dependem de outras pessoas para
produzir a documentação necessária, a fim de examinar o progresso.
2. Não há processo de software-padrão - Não temos uma compreensão clara
das relações entre o processo de software e os tipos de produto. Nas disciplinas de
engenharia com longo histórico, o processo é experimentado e testado. O processo de
engenharia para determinados tipos de sistema, como uma ponte, é bem compreendi-
do. Nossa compreensão do processo ele software se desenvolveu significativamente
nos últimos anos. Contudo, ainda não podemos prever com certeza quando um proces-
so de software específico poderá causar problemas de desenvolvimento.
3. Grandes projetos de software são, frequentemente, projetos únicos - Os
grandes projetos de software são normalmente diferentes de projetos anteriores. Os
gerentes, portanto, na verdade, têm ampla experiência anterior, que pode ser utilizada
para reduzir a incerteza nos planos. Consequentemente, é mais difícil prever problemas.
Além disso, as rápidas mudanças tecnológicas em computadores e nas comunicações
desatualizam as experiências prévias. As lições aprendidas com essas experiências
podem não ser transferíveis para novos projetos.
Segundo Sommerville (2006, p. 61), é impossível dar uma descrição do tra-

balho-padrão de um gerente de software, pois o trabalho varia muito, depen-
dendo da organização e do produto a ser desenvolvido. No entanto, a maioria
dos gerentes assume a responsabilidade, em algum estágio, por algumas das
seguintes atividades ou por todas elas, como:
• elaboração de propostas
• planejamento e programação de projetos
• custo do projeto
• monitoramento e revisões de projetos seleção e avaliação de pessoal
• elaboração de relatórios e apresentações
No planejamento de projeto são descritos as atividades que vão ser execu-

tadas, os marcos de referências a serem atingidos e os produtos gerados por
um projeto. É elaborado um plano para controlar o desenvolvimento e nele são
colocados os objetivos do projeto (ZAMPAR e SOUZA, 2014).
74 • capítulo 3
A gestão de projetos define alguns pontos importantes, como quem, o que,
quando e o porquê dos projetos. Ela ainda faz uso de processos e ferramentas
de gestão os quais servem para ajudar o gerente de projetos e equipe a orga-
nizar, documentar, rastrear e relatar as atividades e progresso de um projeto.
Dentro desse contexto, o plano de projeto compreende (SILVA FILHO, 2015):
• Escopo de projeto bem definido;

• Um roadmap dos artefatos a serem entregues;
• Documentação de papéis e responsabilidades dos participantes;
• Uma linguagem ‘comum’ para comunicação das atividades do projeto,
bem como a rastreabilidade e relatórios dessas atividades;
• Mecanismos de resolução de conflitos e mitigação ou atenuação de riscos.
3.2.1 Plano de Projeto
De acordo com Silva Filho (2015), o plano de projeto é um dos documentos pro-
duzidos na condução de um projeto, funcionando como :
• Um ‘integrador’ entre diversas ações do projeto;

• Mecanismo de comunicação para os stakeholders;
• Captura e documenta a evolução do projeto à medida que ele vai sendo
executado e novas informações vão sendo disponibilizadas.
O gerenciamento da execução do plano de projeto tem o objetivo de realizar

o trabalho definido na descrição do escopo do projeto. Durante toda a execução
do plano de projeto, o gerente de projeto se baseia nesse documento para to-
mar ações corretivas visando alcançar o conjunto de metas planejadas em con-
cordância com o que foi definido no plano. Nesse sentido, o plano de projeto
deve conter (SILVA FILHO, 2015):
• Como os processos de gerência serão utilizados;

• Como as mudanças serão monitoradas e controladas;
• Milestones com datas de pontos estratégicos para avaliação do projeto;
• Baselines para cronograma, custo e qualidade;
• Calendário para recursos utilizados;
capítulo 3 • 75
• Mecanismos de comunicação para os stakeholders;
• Definição de revisões para resolução de pontos em aberto e/ou pendentes;
• Planos de outras áreas de conhecimento (como, comunicação e qualidade).
O plano de projeto é determinante para o sucesso de um projeto, pois ele

identifica os artefatos que deverão ser entregues e quando e, igualmente impor-
tante, informa os recursos necessários para realizar as entregas (de artefatos)
indicando as dependências existentes para essas entregas (SILVA FILHO, 2015).
Conjunto de tarefas genéricas para projeto

1. Examinar o modelo do domínio de informação e projetar estruturas de dados
apropriadas para objetos de dados e seus atributos.
2. Usar o modelo de análise, selecionar um estilo de arquitetura apropriada ao sof-
tware.
3. Dividir o modelo de análise em subsistemas de projeto e alocá-los na arquitetura:
• Certificar-se de que cada subsistema seja funcionalmente coeso.
• Projetar interfaces de subsistemas.
• Alocar classes ou funções de análise para cada subsistema.
4. Criar um conjunto de classes ou componentes de projeto:
• Traduzir a descrição de classes de análise em uma classe de projeto.
• Verificar cada classe de projeto em relação aos critérios de projeto; considerar
questões de herança.
• Definir métodos e mensagens associadas a cada classe de projeto.
• Avaliar e selecionar padrões de projeto para uma classe ou um subsistema de
projeto.
(PRESSMAN, 2011, p. 212)
3.3 O entendimento das necessidades do

projeto
No levantamento de requisitos deve-se atentar para quatro entendimentos fun-

damentais que deve-se levar em consideração, segundo Medeiros (2015):
76 • capítulo 3
1. Entendimento do Domínio da Aplicação onde entende-se, de uma ma-
neira geral, a área na qual o sistema será aplicado;
2. Entendimento do Problema onde entende-se os detalhes do problema
específico a ser resolvido com o auxílio do sistema a ser desenvolvido;
3. Entendimento do Negócio onde busca o entendimento de como o siste-
ma afetará a organização e como contribuirá para que os objetivos do negócio e
os objetivos gerais da organização sejam atingidos; e por fim o
4. Entendimento das Necessidades e das Restrições dos Interessados
onde entende-se as demandas de apoio para a realização do trabalho de cada
um dos interessados no sistema, entende-se os processos de trabalho a serem
apoiados pelo sistema e o papel de eventuais sistemas existentes na execução e
condução dos processos de trabalho.
Mello (2005) aborda que o entendimento das necessidades do cliente po-
dem ser fornecidas por processos adequados da engenharia de requisitos, que
trata de negociar uma solução possível, descrever os requisitos de forma clara e
concisa e gerenciar as mudanças que ocorrem ao longo do ciclo de vida do sof-
tware. O processo de engenharia de requisitos pode ser descrito como um pro-
cesso interativo e continuado de entendimento das necessidades do usuário
e tradução destas necessidades em um futuro produto de software. De acordo
com Mello (2005), este processo pode ser dividido em cinco atividades:
1. Levantamento (ou elicitação) de requisitos, que envolve a coleta organizada

dos requisitos de negócio;
2. Análise e negociação de requisitos, que procura catalogar e classificar os re-
quisitos em subconjuntos, negociar prazos de liberações de acordo com a importância
dos requisitos para o cliente;
3. Especificação de requisitos, que documenta a funcionalidade do software, me-
tas de qualidade e restrições que irão servir de base para o processo de desenvolvi-
mento de software;
4. Validação de requisitos, que verifica se todos os requisitos do sistema foram
declarados de forma não ambígua e em sintonia com as necessidades do cliente; e,
5. Gestão de requisitos, que procura identificar, controlar e rastrear requisitos e
modificações de requisitos a qualquer momento no ciclo de vida do software.
Destas atividades, vamos aprofundar um pouco mais nas que envolvem o

levantamento de requisitos e a especificação destes.
capítulo 3 • 77
3.4 Levantamento de Requisitos
O levantamento de requisitos (também chamado elicitação de requisitos) en-
volve uma das principais partes do processo que terá como resultado o desen-
volvimento de um software, pois é esta a atividade responsável por entender
aquilo que o cliente deseja ou necessita, ou ainda, aquilo que o cliente conse-
gue enxergar como necessidade para o seu negócio.
De acordo com Pressman (2011, p. 133), no levantamento de requisitos há
uma combinação de elementos que abrangem a resolução de problemas, ela-
boração, negociação e especificação. Para estimular e encorajar uma aborda-
gem colaborativa e orientada às equipes em relação ao levantamento de requi-
sitos, os interessados trabalham juntos para identificar o problema, propondo
elementos da solução, negociando diferentes abordagens e especificando um
conjunto preliminar de requisitos da solução.
Medeiros (2015) aponta que o levantamento de requisitos é a fase inicial do
processo de engenharia de requisitos, sendo que nessa atividade levam-se em
conta as necessidades dos usuários e clientes, informações de domínio, siste-
mas já existentes na organização, regulamentos vigentes, leis, etc, com o obje-
tivo de entender a organização como um todo, seus processos, necessidades,
possibilidades de melhorias e as restrições existentes, preocupando-se na des-
coberta dos requisitos.
Existem diversas técnicas que podem ser utilizadas para o levantamento de
requisitos, como por exemplo: entrevistas; questionários; observação do am-
biente e dos indivíduos nas suas tarefas cotidianas na organização; análise de
documentos existentes na organização; cenário de interação entre o usuário
final e o sistema onde o usuário pode simular a sua interação com o sistema ex-
plicando para o analista o que ele está fazendo e de que informações ele precisa
para realizar a tarefa; prototipagem onde uma versão preliminar do sistema,
muitas vezes não operacional e descartável, é apresentada ao usuário para cap-
turar informações específicas sobre seus requisitos de informação, observação
reações; dinâmica de grupo; e diversas outras técnicas que também podem ser
empregadas (MEDEIROS, 2015).
A figura 3.1 apresenta um modelo genérico do processo de levantamento e
análise. É importante ressaltar que cada organização terá sua própria versão ou
uma versão mais definida desse modelo geral, dependendo de fatores locais,
como a perícia da equipe, o tipo de sistema em desenvolvimento, os padrões
utilizados, entre outros (SOMMERVILLE, 2006, 105).
78 • capítulo 3
As atividades do processo de levantamento de requisitos, segundo
Sommerville (2006, p. 105) são:
• Compreensão do domínio - Os analistas devem desenvolver sua compreensão do

domínio da aplicação. Por exemplo. se for exigido um sistema para um supermercado,
o analista deverá descobrir como operam os supermercados.
• Coleta de requisitos - É o processo de interagir com os stakeholders do sistema
para descobrir seus requisitos. Obviamente, a compreensão do domínio se desenvolve
mais durante essa atividade.
• Classificação - Essa atividade considera o conjunto não estruturado dos requisitos
e os organiza em grupos coerentes.
• Resolução de conflitos - Quando múltiplos stakeholders estão envolvidos, os requi-
sitos apresentarão conflitos. Essa atividade se ocupa de encontrar e solucionar esses
conflitos.
• Definição das prioridades - Em qualquer conjunto de requisitos, alguns serão mais
importantes do que outros. Esse estágio envolve a interação com os stakeholders, para
descobrir os requisitos mais importantes.
• Verificação de requisitos - Os requisitos são verificados, a fim de se descobrir se
eles são completos e consistentes e se estão em concordância com o que os stakehol-
ders realmente desejam do sistema.
Especificações
Validação dos dos requisitos
requisitos
Compreensão
Priorização Documento de
Início do do domínio
requisitos
processo
Coleta de Resolução de
requisitos conflitos
Classficação
Figura 3.1 – Processo de levantamento e análise de requisitos. Fonte: Sommerville (2006

p. 106).
capítulo 3 • 79
O levantamento e a análise de requisitos é um processo iterativo, com
feedback contínuo de cada atividade para as outras, como pode ser observado
na figura X. O ciclo começa com a compreensão do domínio e termina com a
verificação dos requisitos. Com sito, a compreensão dos requisitos pelo analista
melhora a cada fase do ciclo.
Diversos problemas podem ocorrer durante a atividade de levantamento de
requisitos, sendo que os principais identificados, de acordo com Santos (2004,
p. 24), são:
• O conhecimento do domínio do negócio encontra-se espalhado por diversos meios,

tais como: livros, sistemas existentes, manuais de operação, envolvidos, etc.;
• O tempo escasso e a disponibilidade dos envolvidos;
• Fatores políticos e organizacionais, podendo não ser muito clara sua existência aos
envolvidos;
• Os envolvidos não sabem exatamente o que fazem, o que precisam e o que querem
que seja desenvolvido.
Outro ponto a ser considerado, conforme ressalta Santos (2004, p. 24), além
dos itens dos principais problemas, citados acima, há, principalmente no
Brasil, a instabilidade política e social que faz com que os requisitos sejam fre-
qüentemente alterados, de forma muito dinâmica.
Como vimos, existem várias técnicas para realizar o levantamento e análise
dos requisitos, como entrevistas, leitura de documentos, questionários, análise
de protocolos, participação dos usuários, reuso de requisitos, prototipagem,
levantamento orientado a ponto de vista, cenários, observação e análises so-
ciais ou etnografia. Veremos três técnicas relevantes e eficientes:
3.4.1 Levantamento orientado a ponto de vista
A concepção e utilização de um sistema é composto por vários stakeholders,

sendo que cada um tem uma visão do sistema. A visão de um conjunto comum
de stakeholders é chamada de ponto de vista.
Esta abordagem é conhecida como análise de multiperspectivas, e é impor-
tante, pois não há uma única maneira ou perspectiva de analisar um sistema e
80 • capítulo 3
seus requisitos. Estes requisitos podem ser vistos de maneiras diferentes por
stakeholders diferentes.
Por exemplo, se considerar um sistema de biblioteca de forma ampla, pode-
mos identificar facilmente pelo menos cinco pontos de vista:
1. Ponto de vista dos gestores: preocupado Preocupado com os serviços

prestados pela biblioteca e seu impacto nos resultados;
2. Ponto de vista do atendente: preocupado na maneira de utilização do
sistema para atender os clientes
3. Ponto de vista do usuário: preocupado em buscas eficientes e acesso ao
sistema via Internet;
4. Ponto de vista do Sindicato: preocupado nos efeitos da implantação do
sistema sobre a alteração no nível de ocupação e deveres, assim como o ofereci-
mento de novas vagas, ou cortes dos trabalhadores;
5. Ponto de vista das leis de direitos autorais: preocupado com a reprodu-
ção, digitalização e disponibilização do conteúdo dos livros pelo sistema.
Os pontos de vista podem ser encarados de três formas diferentes, como fon-
tes ou drenos de dados, frameworks de representação e receptores de serviços.
Quando os pontos de vista são responsáveis por produzir ou consumir da-
dos dizemos que eles são fontes ou drenos de dados. Neste caso a análise envol-
ve verificar quais dados são produzidos e consumidos e que suposições sobre
as fontes de dados são válidas.
Os pontos de vista que representam tipos específicos de modelos de siste-
ma são conhecidos como Frameworks de Representação. Eles podem ser com-
parados entre si para saber quais são os requisitos existentes usando uma úni-
ca representação.
Os pontos de vistas que são externos ao sistema e recebem seus serviços são
conhecidos como receptores de serviços.
Nesta técnica utilizamos o método VORD (Viewpoint Oriented Requisites
Definition) para obtenção e análise, a Figura 3.2 representa um esquema deste
método.
capítulo 3 • 81
Identificação dos
pontos de
Estruturação dos
vista
pontos de
vista Documentação dos
pontos de
Mapeamento dos
vista
PV para o
sistema
Figura 3.2 – Método VORD.
O processo começa com a Identificação dos pontos de vista, os quais rece-

bem serviços do sistema, assim são identificados os serviços fornecidos a cada
um.
Após isso, inicia-se a estruturação dos pontos de vista agrupando-os
hierarquicamente.
Serviços comuns são fornecidos em níveis mais altos na hierarquia e her-
dados por ponto de vista de nível inferior. Feita a estruturação é necessário
revisar a documentação, refinando a descrição dos pontos de vista e serviços
identificados.
Finalizada a documentação, deve-se transformar a análise em um projeto
orientado a objetos, mapeando os pontos de vista no sistema planejado.
Durante a identificação do ponto de vista utilizam-se formulários padrões
para o ponto de vista para o serviço, nas tabelas 3.3 e 3.4 são apresentados no
modelo.
Projeto orientado a objetos (POO) é um tipo de projeto de sistema que leva em consi-
deração a tecnologia de orientação a objetos.
Por ora, a orientação a objetos é um paradigma de análise, projeto e programação
de sistemas de software baseado na composição e interação entre diversas unidades
de software chamadas de objetos.
82 • capítulo 3
MODELO DE PONTO DE VISTA
REFERÊNCIA Nome do ponto de vista.
ATRIBUTOS Atributos que fornecem informações sobre o ponto de vista.
Referência para um conjunto de cenários de eventos descrevendo

EVENTOS como o sistema reage a eventos do ponto de vista.
SERVIÇOS Referência a um conjunto de descrições de serviço.
SUB_PVS Nomes dos sub-pontos de vista.
MODELO DE SERVIÇO
REFERÊNCIA Nome do serviço.
RAZÕES Razões pelas quais o serviço é fornecido.
Referência para uma lista de especificações de serviço, que podem

ESPECIFICAÇÃO ser expressas em diversas notações.
PVS Nomes de pontos de vista que recebem o serviço.
REQUISITOS Requisitos não funcionais que restringem o serviço.
Referência a uma lista de objetos do sistema que fornecem os

FORNECEDOR serviços.
Tabelas 3.3 e 3.4 – Modelo de formulários.
A identificação dos pontos de vista é provavelmente o estágio mais difícil.

Aqui devem ser identificados todos os serviços e ponto de vista do sistema. Uma
boa abordagem para isto realização de um brainstorming (do inglês - tempesta-
de de ideias). Um brainstorming nada mais é do que uma reunião em que todos
falam acerca de um assunto ou, no caso no sistema a ser desenvolvido, com o
objetivo de se obter ideias, ou o caso, requisitos.
Uma pessoa fica então responsável por anotar os serviços e pontos de vista,
referenciando as cores, por exemplo, preto para serviço precisa parar. De vista,
Picada serviço deve ser alocado um ponto de vista.
Com todos os serviços e pontos de vista identificados e separados, deve-se
então agrupá-los e definir as entradas de cada um, organizando-os em hierar-
quia de herança. Depois de organizados detalham-se cada um utilizando-se as
tabelas apresentadas anteriormente.
capítulo 3 • 83
3.4.2 Cenários
Em algumas situações é mais fácil reunir analistas e usuários para simular si-
tuações reais e necessárias no futuro sistema do que tentar estabelecer as ne-
cessidades por meio de outros métodos mais abstratos. Para isto são usados os
cenários.
Os cenários servem para revelar detalhes que não foram percebidos e adi-
cioná-los aos esboços dos requisitos. O estabelecimento dos cenários pode ser
feito informalmente com os analistas trabalhando com os usuários principais
ou fomentadores do projeto a fim de identificar os usuários operacionais e cap-
tar detalhes, ou outras formas.
Os cenários são muito usados nos métodos ágeis de desenvolvimento. Por
permitir um ambiente de simulação e ser simples, os envolvidos compreendem
facilmente o objetivo das sessões e atividades e conseguem assim avaliar, cri-
ticar e fazer sugestões tendo como consequência a reorganização dos compo-
nentes e tarefas do sistema. O interessante é que os participantes podem ter co-
nhecimentos e formações heterogêneas contribuindo assim para um ambiente
propício de elicitação dos requisitos.
Desta forma, o cenário permite que situação futuras possam ser previstas
pelos analistas e usuários levando a ações para tratá-las no sistema e nos pro-
cessos envolvidos.
Cenários podem ser descritos de duas formas, como Cenários de Eventos e
como Casos de Usos.
Cenários de eventos podem ser usados para descrever como um sistema res-
ponde à ocorrência de um algum evento específico, tal como “iniciar uma tran-
sação”. Cada evento distinto é mostrado em um cenário de evento separado.
Segundo Vord, há uma convenção diagramática para cenários de eventos.
Os cenários de eventos devem conter os dados fornecidos e saídas, as informa-
ções de controle, o processamento das exceções e o próximo evento esperado.
Nele os dados de entrada são representados por Elipses. As informações de
controle são setas que entram no topo da caixa, os dados saem pelo lado direito
da caixa. Exceções são mostradas na base da caixa e o nome do próximo é repre-
sentado pela caixa com borda espessa. Assim mostra a figura 3.4.
84 • capítulo 3
Cartão
Presente
Cartão
Cartão Válido Usuário OK
Número da
conta
PIN
Número da Validar
conta usuário Número da
Tempo esgotado conta
Selecionar
Devolver cartão PIN incorreto serviço
Informar PIN
Cartão inválido
Devolver cartão
PIN incorreto
Cartão roubado Devolver cartão
Reter cartão
Figura 3.4 – Diagrama de cenário de eventos.
A maioria dos métodos não inclui formas para descrever exceções. No exem-
plo acima as exceções são: tempo-esgotado, cliente não fornece PIN, cartão in-
válido e cartão roubado.
Casos de uso é uma alternativa mais estruturada do uso de cenários. Um
caso de uso representa uma unidade discreta da interação entre um usuário
(humano ou máquina) e o sistema. É importante notar que não descreve como
o software deverá ser construído, mas sim como ele deverá se comportar quan-
do estiver pronto.
Casos de uso é uma técnica do padrão UML que será estudado no capítulo
5, ele baseia-se em cenários, identifica os atores em interação e descreve como
a interação ocorrerá. Um conjunto de casos de uso deveria descrever todas as
possíveis interações com o sistema.
A UML (Unified Modeling Language) não é uma metodologia de desenvolvimento e

está bastante relacionada com o paradigma de orientação a objetos que será visto nas
próximas unidades também.
A UML permite que desenvolvedores visualizem os produtos de seus trabalhos em
diagramas padronizados por meio de uma notação gráfica. É uma notação independen-
te de processos de software.
capítulo 3 • 85
A figura 3.5 apresenta um diagrama com um caso de uso de um sistema de
biblioteca onde o usuário da biblioteca pode fazer o empréstimo do livro e ad-
ministrar sua conta. O pessoal da biblioteca pode alterar cadastro e cadastrar
usuário e administrar o catálogo de livros. E o Fornecedor pode fornecer e ca-
dastrar novos livros no catálogo de livros.
Serviços de empréstimo
Usuário da
biblioteca
Administração de usuário
Pessoal da
biblioteca
Serviços de catálogo
Fornecedor
Figura 3.5 – Casos de uso.
3.4.3 Etnografia
Etnografia consiste no estudo por vivência direta da realidade em que se insere.

Permite analisar o componente social e organizacional das tarefas, tornando-
se extremamente útil nas dificuldades do levantamento de requisitos.
Na prática um cientista social, externo à organização, passa algum tempo
analisando as atividades das pessoas e os processos da organização, sem que
estas necessitem lhe explicar o seu trabalho. Este estudo geralmente mostra
com mais riqueza de detalhes o trabalho e os processos, em comparação com
as descrições e modelos de sistema que por ventura possam existir.
O estudo etnográfico mostra os requisitos derivados da maneira como as
pessoas realmente trabalham em vez da maneira como as definições sugerem
que elas deveriam trabalhar. Mostra também requisitos que são derivados da
cooperação e conhecimento das atividades de outras pessoas.
86 • capítulo 3
Entretanto ele não é uma técnica completa, e sempre deve ser usada com
outra técnica de elicitação.
3.5 A especificação dos requisitos

A especificação é, também outra fase importante, pois é por meio dela que tan-
to o desenvolvedor quanto o cliente terão uma forma de documentar o que foi
acordado nas fases anteriores.
De modo objetivo, a especificação é a descrição sistemática e abstrata do
que o software deve fazer, a partir daquilo que foi analisado. Ela apresenta a
solução de como os problemas levantados na análise serão resolvidos pelo sof-
tware. Tem como objetivo descrever de maneira sistemática quais as proprieda-
des funcionais são necessárias para resolver o problema do domínio. Além dela
servir para este detalhamento da funcionalidade que deverá ser implementada,
a especificação é também a forma de comunicação sistemática entre analistas
e projetistas do software (LEITE, 2000b).
Os softwares e sistemas computacionais, em sua maioria, são desenvolvidos
para sanarem uma necessidade existente no mundo real, levantadas e trazidas
pelo cliente ou por aqueles que compreendem o domínio do negócio em que
o problema a ser solucionado está inserido. Desta forma, modelar uma parte
do mundo real, bem como o domínio de aplicação em que este software esta-
rá inserido, é uma atividade extremamente importante para se compreender a
necessidade e a importância do sistema a ser construído e definir os requisitos
que tornam o sistema útil.
Neste contexto, é imprescindível conhecermos o significado de requisitos.
De acordo com Leite (2000b), “requisitos são objetivos ou restrições estabele-
cidas por clientes e usuários do sistema que definem as diversas proprieda-
des do sistema. Os requisitos de software são, obviamente, aqueles dentre os
requisitos de sistema que dizem respeito a propriedades do software”. Sendo
assim, um conjunto de requisitos pode ser definido como uma condição ou
capacidade necessária que o software deve possuir para que o usuário possa
resolver um problema ou atingir um objetivo ou para atender as necessidades
ou restrições da organização ou dos outros componentes do sistema (LEITE,
2000b).
capítulo 3 • 87
Sommerville (2006, p. 82) traz ainda algumas outras definições sobre requisi-
tos, como os requisitos do usuário e requisitos de sistema, além de apresentar sua
definição sobre especificação de projeto de software, como pode ser visto abaixo:
1. Requisitos do usuário são declarações, em linguagem natural e também em

diagramas, sobre as funções que o sistema deve fornecer e as restrições sob as quais
deve operar.
2. Requisitos de sistema estabelecem detalhadamente as funções e as restri-
ções de sistema. O documento de requisitos de sistema, algumas vezes chamado de
especificação funcional, deve ser preciso. Ele pode servir como um contrato entre o
comprador do sistema e o desenvolvedor do software.
3. Especificação de projeto de software é uma descrição abstrata do projeto
de software que é uma base para o projeto e a implementação mais detalhados. Essa
especificação acrescenta mais detalhes à especificação de requisitos do sistema.
(SOMMERVILLE, 2006, p. 82)
Estes dois tipos de requisitos apresentam diferentes níveis de especificação

de sistema. Isto é muito útil porque comunicam informações sobre o sistema
para diferentes tipos de leitores (usuários e desenvolvedores). A Tabela 3.5 ilus-
tra a diferença entre os requisitos de usuários e os de sistemas, mostrando como
um requisito de usuário pode ser expandido em diversos requisitos de sistema,
já que estes trazem um maior detalhamento das funções e restrições de sistema.
Os requisitos do usuário são escritos para gerentes do cliente e dos fornece-
dores que, geralmente, não possuem um conhecimento técnico detalhado do
sistema, como pode ser visto na figura 7. Por outro lado, a especificação de requi-
sitos de sistema deve ser destinada aos profissionais técnicos de nível sênior e
os gerentes de projeto envolvidos. Novamente, ela será utilizada pelo gerente do
cliente e do fornecedor. Nada impede que os usuários finais de sistemas possam
ler ambos os documentos. Assim, a especificação de projeto de software é um
documento orientado à implementação. Ele deve ser escrito para os engenheiros
de software que desenvolverão o sistema (SOMMERVILLE, 2006, p. 82).
Existem outros tipos de requisitos utilizados dentro da Engenharia de
Requisitos, relacionados com taxonomia das qualidades do software. Esta
identificação do tipo de requisito auxilia no tratamento específico a ele ofer-
tado, de forma a garantir coesão e agilidade na tradução tanto para quando da
88 • capítulo 3
especificação de requisitos (FAGUNDES,2011, p. 9). Estes requisitos podem ser
divididos em requisitos funcionais e requisitos não funcionais.
Definição dos requisitos do usuário

1. O software deve permitir acesso a arquivos remotamente pela internet.
Especificação dos requisitos de sistema
1. O usuário deve ter a possibilidade de definir o tipo dos arquivos que serão aces-
sados.
2. Cada tipo de arquivo pode ter uma ferramenta online associada que pode ser
aplicada a ele para abrí-lo.
3. Poderá existir um ícone específico para cada tipo de arquivo.
4. Devem ser fornecidos recursos para o ícone que representa um arquivo, a ser
definido pelo usuário.
5. Quando um usuário seleciona um ícone que representa um arquivo, o efeito dessa
seleção é aplicar a ferramenta associada com o tipo de arquivo ao arquivo representado
pelo ícone selecionado.
Tabela 3.5 – Requisitos do usuário e do Sistema. Fonte: Adaptado de Sommerville (2006, p. 83).
Gerentes de clientes
Usuários finais de sistemas
Requisitos
Engenheiros do cliente
do usuário
Gerentes do fornecedor
Arquitetos de sistemas

Engenheiros do cliente
Requisitos
Gerentes do fornecedor
do sistema
Arquitetos de sistemas
Desenvolvedores de software

Especificação Engenheiros do cliente
de projeto Gerentes do fornecedor
de software Arquitetos de sistemas
Desenvolvedores de software
Figura 3.6 – Leitores de diferentes tipos de especificações. Fonte: SOMMERVILLE (2006,

p. 83).
capítulo 3 • 89
3.5.1 Requisitos funcionais e não funcionais
Segundo Sommerville (2006, p. 83), os requisitos de sistema de software são,

freqüentemente, classificados como funcionais ou não-funcionais ou como re-
quisitos de domínio:
• Requisitos funcionais: São declarações de funções que o sistema deve fornecer,

como o sistema deve reagir a entradas específicas e como deve se comportar em
determinadas situações. Em alguns casos, os requisitos funcionais podem também ex-
plicitamente declarar o que o sistema não deve fazer.
• Requisitos não-funcionais: São restrições sobre os serviços ou as funções ofe-
recidos pelo Sistema. Entre ele: destacam-se restrições de tempo, restrições sobre o
processo de desenvolvimento, padrões, entre outros.
• Requisitos de domínio: São requisitos que se originam do domínio de aplicação do
sistema e que refletem características desse domínio. Podem ser requisitos funcionais
ou não funcionais.
Sommerville (2006, p. 84) ainda afirma que a distinção entre esses diferen-
tes tipos de requisitos não é tão clara como sugerem essas definições simples.
Para exemplificar, pode-se imaginar um requisito de usuário relacionado à
proteção. Inicialmente, parece ser um requisito não funcional. No entanto,
quando desenvolvido com mais detalhes, pode levar a outros requisitos que
são claramente funcionais, como a necessidade de incluir recursos de autoriza-
ção de usuários no sistema. Assim, embora seja útil classificar os requisitos de
maneira quando os discutimos, devemos lembrar que essa é, na verdade, uma
distinção artificial.
3.5.1.1 Requisitos funcionais
Os requisitos funcionais definem uma função que deverá existir no sistema,

descrevendo a funcionalidade desejada ou os serviços que se espera que o sis-
tema forneça. O termo função é usado no sentido genérico de operação que
pode ser realizada pelo sistema, seja por meio de comandos dos usuários ou
seja pela ocorrência de eventos internos ou externos ao sistema (LEITE, 2000b).
90 • capítulo 3
Eles dependem do tipo de software que está sendo desenvolvido, dos usuários
de software que se espera verificar e do tipo de sistema que está sendo desen-
volvido. Quando expressos como requisitos de usuário, eles são normalmente
descritos de um modo bastante geral, mas os requisitos funcionais de sistema
descrevem a função de sistema detalhadamente, suas entradas e saídas, exce-
ções etc (SOMMERVILLE, 2006, p. 84).
Aqui podemos citar alguns exemplos de requisitos funcionais:
• “o sistema deve permitir calcular a receita diária, semanal, mensal, tri-

mestral, semestral e anual das compras efetuadas durante estes períodos.”
• “o software deverá realizar notificações por email a cada compra efetuada.”
• “os participantes do curso poderão emitir seus certificados online em for-
mato PDF.”
• “deverá existir um bloco no alto e à direta da tela para o usuário efetuar
login no sistema.”
É importante salientar que o a especificação de um requisito funcional tem

como objetivo determinar o que se espera que o software ou sistema faça, sem
se preocupar neste momento em como ele irá fazer esta ação ou solicitação. De
acordo com Leite (2000b), é importante diferenciar a atividade de especificar
requisitos da atividade de especificação que ocorre durante a fase de desenho
(design) do software, pois nesta fase deve-se tomar a decisão de quais serão as
funções que o sistema efetivamente terá para satisfazer àquilo que os usuários
desejam. Outro ponto que merece ser lembrado é que estes requisitos funcio-
nais terão diferentes níveis de detalhamento, de acordo com a sua destinação,
como descritos no documento de especificação entre requisitos de usuários e
requisitos de sistema.
3.5.1.2 Requisitos não-funcionais
Requisitos não-funcionais estão relacionados ao uso do sistema e quanto às

qualidades globais de um software, como manutenibilidade, confiabilidade,
usabilidade, desempenho, segurança, disponibilidade, custos e várias outras
como também as tecnologias envolvidas. Normalmente estes requisitos são
descritos de maneira informal, podendo ainda ser controversos (por exemplo,
o gerente quer segurança mas os usuários querem facilidade de uso) e difíceis
de validar (LEITE, 2000b).
capítulo 3 • 91
Alguns exemplos de requisitos não-funcionais podem ser vistos na tabela 3.6:
ID REQUISITOS NÃO-FUNCIONAIS TIPO

RNF01 Não poderão ocorrer perdas de informações Segurança
RNF02 Visitantes anônimos não poderão ter acesso à Extranet Segurança
RNF03 Um perfil de usuários pode ter mais de um tipo de permissão Segurança
RNF04 O sistema deverá comportar com velocidade satisfatória Desempenho
RNF05 O sistema deverá ter alta disponibilidade Confiabilidade
RNF06 O sistema deverá ser executado em qualquer navegador Usabilidade
Tabela 3.6 – Requisitos não-funcionais.
Leite (2000b) faz uma importante observação ao tratar que a necessidade de

se estabelecer os requisitos de forma precisa é crítica na medida que o tamanho
e a complexidade do software aumentam, pois os requisitos exercem influência
uns sobre os outros. Para ilustrar esta situação, pode se ver em um caso onde o
requisito deve ter grande portabilidade, como por exemplo, ser implementado
em Java, e isto pode implicar em que o requisito desempenho não seja satisfei-
to, pois programas em Java são, em geral, mais lentos.
3.6 A definição do software

A definição do software representa a definição de todos os seus componentes.
Uma vez estabelecido seus requisitos, suas funcionalidades e todos os seus
componentes, além dos domínios da regra de negócio de onde ele estará inse-
rido, o software tem a sua definição e quanto mais claro isto for, melhor para o
negócio e para todos os envolvidos.
A fase de definição do software ocorre em conjunto com outras atividades
como a modelagem de processos de negócios e análise de sistemas, mais no
início dos processos de desenvolvimento de software. Nesta atividade, diversos
profissionais buscam conhecer a situação atual e a identificar os problemas
para que possam elaborar propostas de solução de sistemas computacionais
que resolvam tais problemas levantados ou conhecidos. Dentre as propostas
apresentadas, deve-se fazer um estudo de viabilidade, incluindo análise custo
-benefício, para que seja decidido qual solução será a escolhida (LEITE, 2007).
O resultado desta atividade deve incluir a decisão realizada entre a aquisi-
ção ou desenvolvimento do sistema, devendo ainda indicar informações sobre
92 • capítulo 3
hardware, software, pessoal, procedimentos, informação e documentação.
Desta forma, a decisão tenha sido tomada pelo desenvolvimento do sistema,
no escopo da engenharia de software, é necessário elaborar o documento de
proposta de desenvolvimento de software. Esse documento, na maioria das ve-
zes é a base de um contrato de desenvolvimento (LEITE, 2007).
Esta atividade de definição do software conta também com os profissionais
de engenharia de software, visando identificar os requisitos de software e mode-
los de domínio que serão utilizados na fase de desenvolvimento (codificação).
Leite (2007) ressalta que, além destes pontos, o engenheiro pode vir a elaborar
um plano de desenvolvimento de software, a partir dos requisitos, indicando
em detalhes os recursos necessários (humanos e materiais), bem como as es-
timativas de prazos e custos (cronograma e orçamento). Outro ponto aponta-
do pelo autor é que não existe um consenso sobre o que caracteriza o final da
fase de definição do software, de forma clara. Isto pode variar de acordo com
o modelo de processo de desenvolvimento adotado. Em algumas propostas, a
fase de definição é considerada concluída com a apresentação da proposta de
desenvolvimento apenas. Em outros modelos de processo, considera que o sof-
tware apenas está completamente definido com a especificação de requisitos e
com a elaboração do plano de desenvolvimento de software. Assim, de acordo
com o modelo de processo adotado, as atividades da fase de desenvolvimento
podem ser iniciadas mesmo que a fase de definição não esteja ainda completa-
mente concluída.
ATIVIDADES
01. Cite pelo menos 3 problemas que podem ocorrer durante a atividade de levantamento
de requisitos.
02. Explique a técnica de levantamento de requisitos baseada em cenários e dê um exemplo.
03. Cite um exemplo de requisito não-funcional e explique o seu conceito.
04. A elicitação dos requisitos é a tarefa de comunicar-se com os usuários e clientes para
determinar quais são os requisitos de sistema. Analise a frase abaixo, referente à requisitos
de software especificados para um sistema de gestão de pessoal, expresso por um cliente:
capítulo 3 • 93
“É necessário que o software calcule os salários dos diaristas e mensalistas e emita
relatórios mensais sumarizados por tipo de salário. Entretanto, a base de dados deve estar
protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de
resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o in-
vestimento nesse sistema. Devo lembrar que os relatórios individuais dos departamentos,
nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em
razão dos adiantamentos e vales que recebem. É fundamental que o software seja opera-
cionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e
custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar
da data de início do projeto.”
Assinale a alternativa que contém apenas requisitos funcionais:
a) emita relatórios mensais sumariados por tipo de salário e necessito, ainda, forte geren-
ciamento de risco, prazo e custo.
b) necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de dados deve
estar protegida e com acesso restrito aos usuários autorizados.
c) calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departa-
mentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenal-
mente.
d) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e
entrega do produto final não pode ultrapassar o prazo de oito meses.
e) é fundamental que o software seja operacionalizado usando código aberto e emita rela-
tórios mensais sumariados por tipo de salário.
05. Defina o que são requisitos, com suas palavras.
REFLEXÃO
Um projeto de software pode ser mais complexo do que aparenta. Definir o software também
pode ser uma tarefa árdua e não tão simples como inicialmente pode parecer ser. Compre-
ender bem as necessidades do projeto, levantar com precisão os requisitos e ter certeza que
todos os requisitos foram levantados, lembrados, considerados e bem descritos, por meio de
sua especificação, pode ser algo que nem sempre seja possível de se realizar. Em muitos
projetos, nem mesmo o cliente sabe ao certo o que ele quer e mesmo que saiba, lidamos
com requisitos voláteis, sujeitos a alterações no decorrer do projeto e desdobramentos de
situações inesperadas ou não previstas.
94 • capítulo 3
O levantamento e a especificação de requisitos são fundamentais para o sucesso de
um projeto de software, afinal, é por meio deles que os requisitos serão definidos e conse-
quentemente as atividades serão distribuídas e gerenciadas para atingir as expectativas e
necessidades do cliente, por meio de diferentes processos. Neste meio, há uma camada
de gerenciamento de projetos que trabalha diretamente com aspectos da engenharia de
software, que irá estabelecer seus processos dentro de um método escolhido, com técnicas
de levantamento de requisitos, documentação e outras atividades relacionadas ao desenvol-
vimento do produto de software, enquanto que a área de projeto, cuidará, entre outras coisas,
da estimativa de custo, recursos, prazo e tudo que envolve negociações com o cliente antes
e durante todo o processo.
Assim, podemos considerar que a análise e especificação de requisitos são essenciais
para o desenvolvimento de software e que suas atividades relacionadas determinam a quali-
dade e o andamento do projeto, juntamente com os seus processos. O levantamento de re-
quisitos é uma das partes mais importantes do processo de software e fazê-lo sem nenhuma
metodologia ou qualquer tipo de conhecimento desta atividade, certamente trará um projeto
com grandes chances de fracasso ou vários retrabalhos.
LEITURA
Em geral, a maioria dos livros de engenharia de software são excelentes fontes de estudo na
área da engenharia de requisitos, envolvendo suas técnicas de levantamento, especificação
e tudo o que é necessário para a definição do software.
• PRESSMAN, Roger S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill,
2011.
• MACHADO, F. N. Análise e gestão de requisitos de software: onde nascem os sis-
temas. São Paulo: Érica, 2011.
• LIMA, A. S. UML 2.0: do requisito à solução. São Paulo: Érica, 2009.
• WAZLAWICK, R. S. Engenharia de Software: Conceitos e Práticas, 1a Edição, Elsevier,
2013.
FAGUNDES, R. M., Engenharia de Requisitos - Do perfil do analista de requisitos ao
desenvolvimento de requisitos com UML e RUP. Salvador, 2011. 216p.
capítulo 3 • 95
FORCHESATTO, A. L.; Apostila Engenharia de Software. UNOESC. 2012. 43p.
LEITE, J. C.; Análise e Especificação de Requisitos. 2000b. Disponível em: <http://www.dimap.ufrn.
br/~jair/ES/c4.html>. Acesso em: 10 dez 2014.
LEITE, J. C.; Engenharia de Software: Ciclo de Vida do Software. 2007. Disponível em: <http://
engenhariadesoftware.blogspot.com.br/2007/02/ciclo-de-vida-do-software-parte-1.html>. Acesso
em: 19 dez 2014.
LEITE, J. C.; O Processo de Desenvolvimento de Software. 2000. Disponível em: <http://www.
dimap.ufrn.br/~jair/ES/c2.html>. Acesso em: 10 dez 2014.
MAZZOLA, V. B. Engenharia de Software - Conceitos Básicos, Apostila, 2010. Disponível em:
<https://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf>. Acesso em: 17
dez 2014.
MEDEIROS, H.; Introdução a Engenharia de Requisitos. Disponível em: <http://www.devmedia.
com.br/introducao-a-engenharia-de-requisitos/29454>. Acesso em: 11 jan 2015.
MELLO, J. A. B.; Uma Metodologia para Engenharia de Requisitos para Pequenas Equipes de
Desenvolvimento de Software. Rev. Ciên. Empresariais da UNIPAR, Toledo, v.6, n.1, 2005. 97-111p.
SANTOS, J. H. A.; Gerência de Mudanças de Requisitos: uma proposta de aplicação a um
estudo de caso. Mestrado. UFRGS. 2004. 107p. Disponível em: <http://www.lume.ufrgs.br/
bitstream/handle/10183/4118/000452937.pdf?sequence=1>. Acesso em: 12 jan 2015.
SILVA FILHO, A. M.; Plano de Projeto. Revista Engenharia de Software Magazine. Ed. 3. Disponível
em: <http://www.devmedia.com.br/artigo-engenharia-de-software-3-plano-de-projeto/9527>. Acesso
em: 16 jan 2015.
SOMMERVILLE, I. Engenharia de Software, 6ª edição. Editora Pearson do Brasil, 2003. 292p.
ZAMPAR, F.; SOUZA, K.; Gestão de projeto e a metodologia ITIL. Disponível em: <http://www.
devmedia.com.br/gestao-de-projeto-e-a-metodologia-itil/25617>. Acesso em: 08 dez 2014.
96 • capítulo 3
4
Gerenciamento de
Requisitos
Neste capítulo estudaremos sobre o gerenciamento de requisitos, envolvendo
suas mudanças, a rastreabilidade destes requisitos, bem como a gerência da
qualidade de requisitos e validação.
Como discutimos no capítulo anterior, alguns requisitos não são totalmen-
te estáveis e estes são passíveis de mudanças ou alterações ao longo do ciclo
de desenvolvimento do software. Existem muitas causas para estas mudanças
ou alterações nos requisitos, podendo envolver falta de clareza inicial por par-
te do cliente, falta de clareza das regras de negócio de onde o software estará
inserido, mudanças de leis ou fatores externos e ainda a descoberta de novas
funcionalidades não previstas inicialmente ou ajustes à requisitos que foram
definidos inicialmente.
Para estas mudanças, alterações, adições e até mesmo exclusão de requisi-
tos, é necessário que haja uma eficiente gestão destes requisitos, bem como o
controle das mudanças, sabendo e sendo possível efetuar o seu rastreamento
até a origem destes requisitos, como por exemplo o contexto ao qual ele foi cria-
do, a área funcional de uma empresa e o pessoal envolvido no levantamento
destes requisitos.
Após todo o processo de gerenciamento de requisitos e gerenciamento das
mudanças, é necessário ainda que se tenha um bom controle da gerência da
qualidade destes requisitos, bem como um processo seguro e que atendas am-
bas as partes do projeto envolvendo a validação destes requisitos.
Vamos lá?!
OBJETIVOS
• Aprender sobre o gerenciamento de requisitos.

• Compreender o gerenciamento de mudanças.
• Conhecer sobre rastreabilidade de requisitos.
• Aprender sobre gerência da qualidade de requisitos.
• Conhecer a validação de requisitos.
98 • capítulo 4
4.1 Introdução
Uma das atividades fundamentais no desenvolvimento de software é a etapa de
Gerenciamento de Requisitos. Os Requisitos são essenciais para a definição da
arquitetura do sistema, para a implementação e validação do sistema final. É
um processo de controle do desenvolvimento, tendo como referência a baseli-
ne de requisitos. Assim, durante este processo são mantidos planos, artefatos e
atividades de desenvolvimento consistentes com os requisitos definidos para o
software (SAYÃO e BREITMAN, 2014 , p. 1).
O gerenciamento de requisitos deve manter um controle padrão sobre im-
plementações e manutenções, de forma que as demandas dos clientes e usuá-
rios possam ser atendidas em todas as fases do projeto, garantindo a excelência
do produto (De BONA e SANTOS, 2012)..
Na Gerência de Requisitos os requisitos necessários para a construção do
produto devem ser entendidos, documentados, revisados e controlados, tanto
quanto a sua inclusão, mas, principalmente, quanto às modificações. O contro-
le possibilita trabalhar com estimativas de realização do desenvolvimento do
produto, dentro de um cronograma definido, e o seu devido acompanhamento
(SANTOS, 2004, p. 29).
4.2 Gerenciamento de Requisitos

Gerenciamento de requisitos é o processo de gerenciar as alterações no requi-
sito durante o processo de levantamento de requisitos e desenvolvimento de
sistemas. É um conjunto de atividades que ajuda a equipe do projeto a iden-
tificar, controlar e rastrear requisitos e e modificações em qualquer época do
desenvolvimento.
“O Gerenciamento de Requisitos é uma área chave importante dentro do
CMM (Capability Maturity Model – SEI/CMU), a qual visa identificar a necessi-
dade de se estabelecer um entendimento entre o que o Cliente está solicitando
e o que a Equipe de Projeto entende ser a solicitação” (SANTOS, 2004, p. 29).
No processo de desenvolvimento de software as modificações nos requisi-
tos ocorrem sistematicamente, desde o levantamento de requisitos até durante
a operação do sistema em produção. Isso se justifica pois há o aparecimento de
erros, conflitos, inconsistência nos requisitos, novas demandas e prioridades
capítulo 4 • 99
dos clientes, problemas técnicos, mudanças no negócio, concorrentes, mudan-
ças no ambiente externo e no ambiente de software, bem como possíveis mu-
danças organizacionais (MEDEIROS, 2015).
Há, durante o processo de desenvolvimento e operação de software, o pos-
sível e provável surgimento de novos requisitos e a necessidade de mudanças
nos requisitos existentes. Este processo, também conhecido como evolução
de sistemas, acontece como resultado de mudanças no meio ambiente onde o
próprio sistema de software está inserido. Se o macrosistema muda os sistemas
de software devem acompanhar esta mudança ou ficarão cada vez menos úteis
(SAYÃO e BREITMAN, 2014 , p. 5).
O gerenciamento dos requisitos visa, justamente, dirimir problemas oca-
sionados por estas mudanças. “O Processo de Gerencia de Requisitos envolve
atividades que ajudam a equipe a identificar, controlar e rastrear requisitos e
gerenciar mudanças de requisitos em qualquer momento ao longo do ciclo de
vida do software” (MEDEIROS, 2015).
A primeira etapa á a identificação de novo requisito, com o uso de tabelas
de rastreamento, que identificam como os requisitos novos interagem com os
requisitos ou funções já existentes.
Devido a novas necessidades do negócio ou melhora na compreensão do
sistema e dos requisitos, é usual que surjam novos requisitos durante o proces-
so. Além de alterações nos requisitos podem ocorrer mudanças nas prioridades
dos requisitos, devido a mudanças nos pontos de vista e alterações no negócio
durante o desenvolvimento.
Os requisitos podem ser divididos em dois grupos:
• Requisitos permanentes: são requisitos estáveis. Derivam da atividade

principal e por isso não sofrem alterações durante o processo. Ex: requisitos do
sistema hospitalar - médico, pacientes, etc.
• Requisitos voláteis: são requisitos que podem mudar durante ou depois
do desenvolvimento. Ex: Políticas governamentais sobre assistência médica.
Para Sommerville (2007), os requisitos voláteis podem ser cartacterizados

como mutáveis, emergentes, consequentes e de compatibilidade.
• Mutáveis: se modificam por causa das mudanças, do ambiente no qual a

empresa está operando.
100 • capítulo 4
• Emergentes: surgem à medida que a compreensão do sistema evolui du-
rante o desenvolvimento.
• Consequentes: resultam da introdução do sistema computacional.
• Compatibilidade: dependem de sistemas ou processos específicos das
organização.
Não há um processo ideal para as organizações, mas processos adaptados e

apropriadas para cada realidade, permitindo orientações mais precisas e redu-
zindo a probabilidade de erros e esquecimentos. “Adaptar um processo para as
necessidades internas é sempre a melhor escolha ao invés de impor um proces-
so à organização” (MEDEIROS, 2015).
O planejamento é o primeiro estágio do processo de gerenciamento de re-
quisitos. É um estágio dispendioso, sendo que para cada projeto há o estabe-
lecimento do nível de detalhes exigidos para o gerenciamento de requisitos.
Durante o estágio de gerenciamento de requisitos, decide-se sobre:
• Identificação de requisitos - Cada requisito precisa ser identificado de modo único,

para que possa ser feita a referência cruzada deste com os outros requisitos e para que
ele possa ser utilizado nas avaliações de facilidade de rastreamento.
• Processo de gerenciamento de mudanças - Trata-se do conjunto de atividades
que avalia o impacto e o custo das mudanças.
• Políticas de facilidade de rastreamento - Essas políticas definem as relações en-
tre os requisitos e entre os requisitos e o projeto de sistema que devem ser registrados
e também como esses registros devem ser mantidos.
• Suporte de ferramentas CASE - O gerenciamento de requisitos envolve processar
uma grande quantidade de informações sobre os requisitos. As ferramentas que po-
dem ser utilizadas vão desde sistemas especializados de gerenciamento de requisitos
até planilhas de cálculo e sistemas simples de bancos de dados.
O gerenciamento de requisitos demanda um apoio automatizado e é na fase

de planejamento que as ferramentas CASE utilizadas devem ser escolhidas. O
apoio de ferramentas é necessário para:
capítulo 4 • 101
• Armazenamento de requisitos - Os requisitos devem ser mantidos em um depósi-
to de dados seguro, gerenciado, que seja acessível por todos os envolvidos no processo
ele engenharia de requisitos.
• Gerenciamento de mudanças - Esse processo é simplificado se o apoio de ferra-
mentas ativas estiver disponível.
• Gerenciamento de facilidade de rastreamento - Como foi discutido antes, o apoio
de ferramentas para a rastreabilidade permite que são descobertos requisitos relacio-
nados. Estão disponíveis algumas ferramentas que utilizam técnicas de processamento
de linguagem natural, para ajudar a descobrir as possíveis relações entre os requisitos.
Requisitos segundo Agilistas

[...] “a corrente agilista defende a simplificação dos requisitos, legando todo detalha-
mento a acordos tácitos firmados com o cliente, que deve ter presença constante. Essa
escola defende a definição simplificada das funcionalidades pelo uso de Histórias de
Usuário.
A forma dada a essas histórias assemelham-se muito à maneira como os Casos
de Uso eram descritos em seu princípio, numa fase pré-UML que costumo chamar de
gestacional (dos Casos de Uso), quando surgiram estudos propondo a Análise Orienta-
da a Objetos. Consiste na identificação do ator seguido da ação que ele deseja realizar,
seguido das regras de negócio vigentes sobre aquele uso.
Essa é uma forma simplificada e mais livre de redigir. Porém, o preço dessa liber-
dade é a abertura a ambiguidades, indefinições e até mesmo histórias descritas exaus-
tivamente. Esta última tendo sido a maior queixa sobre Casos de Uso, abrindo espaço
para o surgimento da técnica de Histórias de Usuário.
Todavia, num cenário em que os problemas não se apresentem e a descrição seja
realmente resumida, esse conjunto de histórias são, em verdade, uma lista das necessi-
dades do cliente, aproximando-se da visão do sistema. Isso exatamente porque não se
deseja, com as histórias, obter uma descrição detalhadas de todos os usos.
Por ser representada mais por uma corrente do que por um processo definido, não
há declaração formal sobre como obter as informações, embora seja mais difundido o
uso de mapas mentais para orientar as partes interessadas nessa atividade.”
(FAGUNDES, 2011, p. 22 )
102 • capítulo 4
Neste artigo você pode encontrar ferramentas que auxiliam no controle do gerencia-
mento de requisitos:
• http://migre.me/oIEKM
Neste outro artigo, além de abordar as normas de qualidade utilizadas em desen-
volvimento de softwares, no final há também uma análise de ferramentas para a gestão
de requisitos e mudanças:
• http://migre.me/oIEZg
4.3 Gerenciamento de mudanças

As mudanças em um ambiente de desenvolvimento são inevitáveis. Quando o
sistema ainda está sendo desenvolvido os requisitos continuam mudando. As
razões para mudanças são de vários tipos, entre outras (SAYÃO e BREITMAN,
2014 , p. 6):
• Os sistemas são complexos e isso impõe mudanças

• Requisitos equivocados ou mal definidos devem sofrer ajustes ao longo
do processo de desenvolvimento,
• Mudanças no ambiente: regras de negócios, leis, políticas internas,
• Adição de novas funcionalidades mais avançadas com o intuito de criar
vantagens,
• Mudanças tecnológicas,
• Mudanças no comportamento dos clientes.
O fato é que os sistemas de informação devem evoluir constantemente,

de maneira que atenda às necessidades de seus usuários no atual ambiente
corporativo.
Este fenômeno é particular a sistemas de informação e foi destacado por
Manny Lehman. “Este tipo de sistema, também conhecido como sistema
do tipo E (evolutionary) se caracteriza por, uma vez instalado, tornar-se par-
te do meio ambiente e acabar alterando seus próprios requisitos” (SAYÃO e
BREITMAN, 2014 , p. 6).
capítulo 4 • 103
A mudança nos requisitos é denominada de volatilidade; a gerência de re-
quisitos tem como parte das suas atividades controlar mudanças. O CMM defi-
ne mudanças como: As alterações que precisam ser feitas nos requisitos e arte-
fatos de software.
É necessário que as alterações dos requisitos sejam:
• Identificadas e avaliadas
• Avaliadas considerando o risco
• Documentadas
• Planejadas
• Comunicadas aos grupos e indivíduos envolvidos
• Acompanhadas até a finalização
O gerenciamento de mudanças de requisitos (figura 4.1) deve ser aplicado a

todas as mudanças propostas para os requisitos. O benefício de se ter um pro-
cesso formalizado para gerir as mudanças é que, desta forma, todas as propos-
tas de mudanças são tratadas de maneira consistente e de forma controlada.
Há três estágios principais em um processo de gerenciamento de mudanças
(SOMMERVILLE, 2006, p. 121):
6. Análise do problema e especificação da mudança - O processo começa

com uma proposta de mudança ou com a identificação de um problema com os
requisitos. Nesse estágio, é realizada a análise do problema ou da proposta de
mudança, a fim de verificar sua validade.
7. Análise e custo da mudança - O efeito da mudança proposta é avaliado,
de acordo com a facilidade de rastreamento e o conhecimento geral dos requi-
sitos do sistema. O custo da mudança é estimado de acordo com as modifica-
ções no documento de requisitos, no projeto de sistemas e na implementação.
Concluindo essa etapa, decide-se sobre prosseguir com a alteração de requisi-
tos ou não.
8. Implementação de mudanças - O documento de requisitos e, se neces-
sário, o projeto de sistema e a implementação são modificados. De modo a faci-
litar, o documento de requisitos deve ser organizado, bem como os programas,
minimizando referências externas e tornando as seções do documento tão mo-
dulares quanto possível.
104 • capítulo 4
Problema identificado
O processo de gerenciamento demanda um con-
junto de tarefas que proporcionem o gerenciamento
e mapeamento entre as dependências dos requisi-
tos e as solicitações de modificações e/ou inclusões
Análise do (SANTOS, 2004, p. 18).
problema e
especificação Em função de possíveis divergências na percep-
da mudança ção do projeto, podem ocorrer problemas na difi-
culdade, por parte de analistas de requisitos e de
negócios, de se estabelecer o entendimento com as
partes interessadas sobre o tratamento de definições
posteriores de requisitos ou alteração de escopo da
Análise e custo solução (FAGUNDES, 2011, p. 206).
da mudança
Implementação de
mudanças
Figura 4.1 – Gerenciamento de mudanças de requisitos.

Requisitos revisados Fonte: (SOMMERVILLE, 2006, p. 122).
Na visão do cliente, qualquer resolução sobre o projeto que facilite que este
cumpra sua missão é bem vinda, incluindo alterações. Porém para os desenvol-
vedores não é assim:
já para a equipe de desenvolvimento, o objeto é tudo aquilo que foi definido no projeto
e alterações de escopo demandam necessariamente renegociação de prazo e custo -
modificações que não impliquem mudança do escopo são toleráveis, mas podem ser
sujeitas, sob a ótica do desenvolvedor, a mudanças no cronograma em função de fa-
tores como criticidade, proximidade com o prazo, dimensão da mudança (FAGUNDES,
2011, p. 206).
capítulo 4 • 105
Uma forma de resolver ou gerir estas discrepâncias é a separação precisa
entre o escopo do produto, como definido na disciplina de Gerenciamento de
Projetos, e a especificação de requisitos, elaborada durante a Engenharia de
Requisitos (FAGUNDES, 2011, p. 206).
Desta forma, toda mudança que resulte na modificação do Documento de
Visão deve passar por uma negociação. Sendo assim, determinadas inclusões
ou exclusões no projeto devem passar por um ajuste no acordo, por modificar o
escopo do produto (FAGUNDES, 2011, p. 206).
Alterações que não modificam a visão e o escopo do projeto não demandam
tantos ajustes, mas também não são nulas do ponto de vista de negociação. O
esforço de modificação é variável de acordo com o momento em que ela é sus-
citada e de acordo com a análise de impacto fundamentada na rastreabilidade
dos requisitos (FAGUNDES, 2011, p. 206).
Assim, é muito importante firmar previamente com o cliente uma visão
compartilhada de como se dará o processo de solicitações de mudança, bem
como as revisões do planejamento decorrentes destas mudanças. É uma forma
de evitar surpresas e fortalecer os laços de confiança e parceria entre a equipe
de desenvolvimento e o cliente (FAGUNDES, 2011, p. 210).
Para o gerente de requisitos o mais importante é estabelecer uma prática
consistente para a mudança dos requisitos. É fundamental o estabelecimento
de um processo claro para o tratamento de mudanças. Este processo precisa es-
tar acertado e definido com os membros da equipe de desenvolvimento e usu-
ários (SAYÃO e BREITMAN, 2014 , p. 8). Os pontos que devem ser observados
com relação a possíveis mudanças, dentro do processo de gerenciamento de
requisitos podem ser divididos em:
• Entradas - quais condições devem ser satisfeitas antes de iniciar o

processo
• Tarefas - detalhar quais são as tarefas envolvidas neste processo, determi-
nando quem será responsável pela sua execução e o formato em que os resulta-
dos devem ser comunicados
• Verificação - definir etapas onde os resultados obtidos são verificados de
modo a garantir consistência e qualidade
• Saídas - definir um critério claro que indique que o processo chegou ao fim.
106 • capítulo 4
Na figura 4.2 apresentamos um exemplo de processo de mudança de requi-
sitos, proposto por Karl Wiegers.
Solicitante submete
solicitação de mudança
Submetida
Avaliador realiza
análise de impacto
Gerente decide NÃO

Avaliada realizar a mudança Rejeitada
Gerente decide
realizar mudança.
Aponta reponsável
para execução
Aprovada Mudança Cancelada
Verificação
falhou Responsável fez
a mudança e
pesquisa verificação
Mudança
Mudança Cancelada Cancelada
Realizada
Verificador
confirma
mudança
Verificação não
foi necessária. Verificada Mudança Cancelada
Modificador
instala produto
Modificador
instala
produto
Final
Figura 4.2 – processo de requisição de mudança em requisito, proposto por Karl Wiegers.
Fonte: Sayão e Breitman (2014 , p. 8).
capítulo 4 • 107
4.4 Rastreabilidade de requisitos
A rastreabilidade não é algo físico ou garantido simplesmente pelo registro dos
requisitos, mas é a possibilidade de se identificar, a partir certo requisito, as de-
pendências diretas e indiretas. Esta e uma qualidade do registro de requisitos,
que auxilia a avaliar o impacto de uma mudança nos requisitos de uma solução
(FAGUNDES, 2011, p.12).
A rastreabilidade de requisitos é uma das atividades preconizadas pelos
modelos de qualidade como CMM, CMMI, MPS.BR e ISO 9001. Em suma, a
rastreabilidade pode ser compreendida como o conjunto de ligações entre as
fontes dos requisitos, os requisitos propriamente ditos e outros artefatos como
componentes e casos de teste. “Por fontes dos requisitos consideramos tanto
o cliente ou usuário que trouxe uma necessidade, como documentos da orga-
nização, padrões a serem seguidos e também legislação pertinente” (SAYÃO e
BREITMAN, 2014 , p. 12).
Para que seja possível realizar de modo eficiente o gerenciamento de re-
quisitos, principalmente quanto a modificação de requisitos é necessário que
cada requisito seja identificado de modo único, para que seja possível realizar
a transferência cruzada com os outros requisitos, possibilitando, deste modo,
utilizá-lo nas avaliações de rastreamento em possíveis alterações de requisitos.
Cada alteração deve ter seu impacto e custos avaliados, para tal, utilizam-se
políticas de rastreamento que define as relações entre os requisitos e o projeto
do sistema.
O rastreamento pode ser realizado de diferentes formas, entre elas devemos
destacar as seguintes:
• Rastreamento de origem, em que é realizada a associação entre os requi-

sitos e os stakeholders que propuseram tal requisito.
• Rastreamento de requisitos, em que é identificada a associação de um
determinado requisito com a dependência existente com outros requisitos.
• Rastreamento de projeto, em que é identificada a associação de um re-
quisito com o projeto como um todo.
Para a melhor visualização do rastreamento o ideal é utilizar-se de uma

representação gráfica de referência cruzada ou matriz de rastreamento.
Neste modelo os requisitos são dispostos nas linhas e colunas de uma tabela e
108 • capítulo 4
suas dependências são representadas por letras ou símbolos, de acordo com a
tabela 4.3.
RED. ID 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 U R
1.2 U R U
1.3 R R
2.1 R U U
2.2 U
2.3 R U
3.1 R
3.2 R
U = utiliza recursos especificados no requisito da coluna
R = relação fraca entre os requisitos
Tabela 4.3 – Matriz de rastreamento.
Rastreabilidade (por Raul S. Wazlawick)

"Rastreabilidade ou controle de rastros refere-se a um dos princípios da Engenharia de
Software cuja implementação ainda implica significativa dificuldade.
Manter um controle de rastros entre módulos de código não é difícil, porque as
dependências entre os módulos costuma ser indicada de forma sintática pelos próprios
comandos da linguagem (importou uses, por exemplo). Contudo, manter controle de
rastros entre artefatos de análise e design não é tão simples. A rastreabilidade é impor-
tante, porque, quando são feitas alterações em artefatos de análise, design ou código, é
necessário manter a consistência com outros artefatos, caso contrário a documentação
fica rapidamente desatualizada e inútil.
A técnica de rastreabilidade mais utilizada nas ferramentas CASE é a matriz de
rastreabilidade, que associa elementos entre si, por exemplo, casos de uso e seus res-
pectivos diagramas de sequência ou classes e módulos de programa. Porém, esse tipo
de visualização matricial torna-se impraticável à medida que a quantidade de elementos
cresce, especialmente se o controle das relações entre os elementos precisar ser feito
manualmente (Cleland-Huang, Zemont & Lukasik, 2004).
Também são reportadas pesquisas que procuram automatizar a recuperação de
relações de rastreabilidade entre artefatos a partir de evidências sintáticas. Porém, em
razão das escolhas arbitrárias dos nomes de artefatos (falta de padrão), esses sistemas
capítulo 4 • 109
de recuperação costumam retornar muitos falso-positivos, o que inviabiliza seu uso
(Settimi, Cleland-Huang, Khadra, Mody, Lukasik & de Palma, 2004).
Outra abordagem, ainda experimental, é apresentada por Santos e Wazlawick
(2009). Consiste em modificar a maneira como os elementos são criados nos editores
de diagramas das ferramentas CASE, de forma que, com exceção dos requisitos que
são produzidos externamente, outros elementos quaisquer (como casos de uso, clas-
ses, código, diagramas etc.) só podem ser criados como uma derivação de algum outro
elemento que já exista.
Dessa forma, sempre que um item é criado no repositório do projeto, um rastro é
automaticamente criado entre ele e o elemento que lhe deu origem. Apenas itens que
representam requisitos (que vêm do cliente, ou seja, são externos ao projeto) podem
ser adicionados ao repositório sem que isso ocorra por derivação de outros itens."
(WAZLAWICK, 2013, p. 320)
4.5 Gerência da qualidade de requisitos

Buscando a qualidade é importante que a Especificação de Requisitos de Sof-
tware atenda a alguns preceitos de qualidade de software, conforme definidos
por padrões internacionais (como, por exemplo, o IEEE, o CMM e o SPICE).
Para tanto a especificação deve ser (SANTOS, 2004, p. 22):
ESPECIFICAÇÕES: DETALHAMENTO
Tudo o que está sendo descrito sobre os requisitos deve
CORRETA realmente expressar sua realidade – ser o que realmente
é.
Os requisitos devem ter apenas uma interpretação, acor-
dada entre os usuários e os desenvolvedores. As dúvidas
PRECISA podem ser dirimidas com um dicionário de termos, que
deve ser declarado para resolver as dúvidas que surgirem.
Deve refletir todas as decisões de especificação que
foram tomadas ao longo de sua discussão, envolvendo
os usuários e os desenvolvedores. Deve trazer de forma
bem clara e definida a sua funcionalidade, desempenho
COMPLETA desejado, restrições de projeto (técnicas e não técnicas),
atributos necessários e, caso exista, relacionamento com
outras aplicações. Procurar contemplar todas as situações
possíveis.
110 • capítulo 4
ESPECIFICAÇÕES: DETALHAMENTO
Não ter nenhum conflito ou sobreposição a outros requi-
CONSISTENTE sitos.
Definir prioridades de acordo com a importância, es-
tabilidade e complexidade. Dentro destes critérios, os
requisitos podem ser:
a) essencial: requisito sem o qual o produto não
atende às necessidades do usuário;
b) desejável: sua existência aumenta o valor do
PRIORIZADA produto, mas se por alguma necessidade não for
contemplado não afeta de forma substancial a uti-
lização do produto;
c) opcional: requisito que poderá ser incluído caso
haja disponibilidade de prazo e orçamento, caracte-
rizando-se como a última prioridade a ser atendida;
A princípio todos os requisitos devem ser verificáveis. Ele
será verificável se existir um processo finito que possa ser
VERIFICÁVEL executado por uma pessoa ou máquina e, principalmente,
que mostre sua conformidade com o solicitado.
A mudança de todo e qualquer requisito pode ser realiza-
MODIFICÁVEL da de forma fácil, completa e consistente.
Permite que seja facilmente verificada sua consequência
quando ocorrer uma modificação. Há a necessidade de se
RASTREÁVEL fazer a rastreabilidade nos dois sentidos, ou seja, verificar
qual o impacto a ser causado nos requisitos dependentes
e dos quais depende.
Que a especificação dos requisitos seja facilmente
reutilizável, ou seja, se tivermos alguma funcionalidade
REUTILIZÁVEL a ser referenciada por um outro requisito que não seja
necessário descrevê-la novamente.
Tabela 4.4 – Qualidade de requisitos. Fonte: Adaptado de ÁVILA e SPÍNOLA (2014).
A gerência precisa, neste sentido, se responsabilizar pela criação e manu-

tenção de uma infra-estrutura necessária para atividades de verificação que
tornem possível a investigação da qualidade dos requisitos que estão sendo de-
finidos (ÁVILA e SPÍNOLA, 2014).
capítulo 4 • 111
Gestão de Qualidade efetiva
Uma gestão de qualidade efetiva estabelece a infraestrutura que dá suporte a qual-
quer tentativa de construir um produto de software de alta qualidade. Os aspectos
administrativos do processo criam mecanismos de controle e equilíbrio de poderes que
ajudam a evitar o caos no projeto - um fator-chave para uma qualidade inadequada. As
práticas de engenharia de software permitem ao desenvolvedor analisar o problema e
elaborar uma solução consistente , aspectos críticos na construção de software de alta
qualidade. Finalmente, as atividades de apoio como o gerenciamento de mudanças e
as revisões técnicas têm muito a ver com a qualidade, assim como qualquer outra parte
da prática de engenharia de software (PRESSMAN, 2011, p. 360).
Segundo o CMM a gerência de requisitos é a revisão dos requisitos antes de

serem incorporados ao projeto. É necessário (SAYÃO e BREITMAN, 2014, p. 19):
• Identificar requisitos incompletos ou ausentes

• Determinar a clareza dos requisitos e se são possíveis de serem imple-
mentados, consistentes e verificáveis
• Revisar requisitos com problemas potenciais
• Negociar compromissos com os grupos envolvidos
A maior parte dos requisitos de software para sistemas de informação são

escritos utilizando-se linguagem natural. Uma série de potenciais problemas
podem surgir por esta falta de formalidade na captura dos requisitos. Os pro-
blemas mais comuns são:
PROBLEMAS DESCRIÇÃO EXEMPLO

Falta de clareza ou duplo sen- “O sistema deve enviar relatórios
tido de frases ou expressões. de produtividade dos programa-
Este tipo de requisito leva a dores, analistas ou desenvolve-
Ambiguidade
interpretações erradas ou in- dores do projeto mensalmente
consistentes das necessidades ou quando requisitado.”
reais dos usuários.
Requisitos que deixam de fora Curva S (Planejado X Realizado)
parte da informação necessária de um projeto
à sua compreensão.
Requisitos incompletos
Cadastro de iniciativas estra-
tégicas
112 • capítulo 4
PROBLEMAS DESCRIÇÃO EXEMPLO
Estes são requisitos que conca- No evento de falha da rede
tenam vários requisitos em um elétrica, o sistema deve enviar
só. Estes requisitos devem ser mensagem de erro ao usuário,
Requisitos múltiplos
separados para facilitar a tarefa salvar a configuração atual do
de priorização e gerência de sistema e os dados entrados,
mudanças. até então.
São aqueles requisitos que não O sistema deve mostrar o total
estabelecem claramente qual do pedido à medida que os
deve ser a ação do sistema códigos dos produtos vão sendo
Requisitos com alternativas frente a uma dada situação. De entrados no pedido, a não ser
modo geral contém frases do que se trate de um produto
tipo mas, com exceção, apesar, promocional.
e quando.
São requisitos mal redigidos que Na improvável eventualidade de
podem causar confusão e mal falha no sistema de refrigeração,
entendidos. Um erro muito co- o sistema deve mandar mensa-
mum é o excesso de informação gem para a chave admin.
Requisitos mal escritos
Identificar e associar as inter-
venções que são complementa-
res às outras
É de conhecimento comum a O sistema X deve ser seguro

gerentes de projeto a máxima
"você não pode gerenciar o que O sistema C deve processar
não pode medir". Um requisito depósitos rapidamente
Requisitos inverificáveis
inverificável é escrito de modo
que fica impossível de assegurar
que o sistema é capaz de
atênde-lo.
Tabela 4.5 – Problemas nos requisitos. Fonte: Adapatdo de SAYÃO e BREITMAN (2014 ,
p. 19).
Desta forma, é fundamental que os requisitos sejam “completos, corretos,

consistentes, realistas, necessário, passível de ser priorizado, verificável e ras-
treável” (MEDEIROS, 2015).
4.6 Validação de requisitos

A validação de requisitos consiste em demonstrar que os requisitos levantados
definem o sistema que o cliente realmente quer. O custo de correção de um sis-
tema com erro de requisitos pode chegar a cem vezes o custo de simples erros
de implementação, daí a importância de sua validação.
capítulo 4 • 113
Validar ou checar os requisitos consiste em verificar se o sistema provê as
funções que atendem as necessidades do cliente. Verificar a consistência dos
requisitos, se não conflitos entre eles.
Verificar a completude, se todas as funções requeridas pelo cliente estão
incluídas na descrição do sistema. O Realismo, se os requisitos podem ser
implementados dentro dos prazos e recursos financeiros, tecnológicos e de
pessoal disponível para tal. E finalmente verificar de os requisitos podem ser
verificados.
Para realizar a validação de forma eficiente utilizamos algumas técnicas
como revisão de requisitos, prototipação, geração de casos de teste e análise
automatizada da consistência.
• Revisão de requisitos: consiste da análise manual sistemática dos requi-

sitos. Deve ser realizada por uma equipe de engenheiros de software.
• Prototipação: realiza-se a criação de protótipos executáveis do sistema
como forma de verificar e testar a viabilidade e a consistência dos requisitos
levantados.
• Geração de casos de teste: consiste em desenvolver testes que verifiquem
os requisitos levantados.
• Análise automatizada da consistência: consiste em verificar a consistên-
cia de uma descrição de requisitos estruturada utilizando ferramentas automa-
tizadas, entretanto poucas vezes isso é possível.
Além de realizar a validação dos requisitos é necessário revisar os requisi-

tos. Estas revisões devem ser realizadas regularmente enquanto a definição dos
requisitos está sendo formulada. Esta tarefa deve envolver tanto o cliente quan-
do os analistas do sistema.
Revisões podem ser feitas de forma formal ou informal e para isso é impor-
tante uma boa comunicação logo nos estágios iniciais. As revisões devem veri-
ficar os seguintes itens:
• Verificabilidade: se o requisito pode ser testado de forma realística.

• Compreensibilidade: se o requisito está bem compreendido.
• Rastreabilidade: se a origem do requisito pode ser identificada.
• Adaptabilidade: se o requisito pode ser mudado sem grande impacto em
outros requisitos, e se não, qual impacto causará.
114 • capítulo 4
A verificação e validação (V & V) de software, tem como objetivo mostrar que
um sistema está de acordo com suas especificações e que ele atende às expecta-
tivas do cliente comprador do sistema.
Esse processo envolve verificar processos, como por meio de inspeções e revisões, em
cada estágio do processo de software, desde a definição elos requisitos dos usuários
até o desenvolvimento elo programa. A maior parte dos custos de validação, contudo,
é observada depois da implementação, quando o sistema operacional é testado (SOM-
MERVILLE, 2006, p. 50).
A não ser que sejam pequenos programas, os sistemas não devem ser tes-
tados como uma unidade isolada, ‘monolítica’. Os grandes sistemas são for-
mados por subsistemas, que são construídos a partir de módulos, que são
compostos por procedimentos e funções. Os testes devem ser realizados incre-
mentalmente, ou seja, o processo de teste deve evoluir em estágios, em conjun-
to com a implementação do sistema (SOMMERVILLE, 2006, p. 50).
ATIVIDADES
01. Existe algum software que gerencia os requisitos de um sistema? Você conhece? Se
conhecer, explique basicamente o seu funcionamento. Se não conhece, pesquise na internet
algum software voltado para a gerência de requisitos e o seu funcionamento.
02. Quais técnicas você utilizaria para rastrear requisitos de software? Explique.
03. Na sua opinião, o fato de haver muitas mudanças de requisitos pode influenciar na es-
colha do métodos de desenvolvimento do software? Por que?
04. Quais critérios você utilizaria para avaliar se os requisitos são de qualidade? Justifique.
05. Quais são os principais pontos que devem ser decididos durante o estágio de gerencia-
mentos de requisitos? Explique.
capítulo 4 • 115
REFLEXÃO
Podemos considerar que se os requisitos forem bem levantados, bem descritos e especifica-
dos, não teremos problemas quanto à mudanças futuras? Será que temos condições de de-
senvolver softwares com requisitos sendo alterados a todo momento? Qual é o limite disto? E
quando envolvemos muitas pessoas ou muitos grupos de diferentes áreas funcionais de uma
empresa; será que conseguiríamos rastrear todos os seus pedidos ou suas necessidades
que foram revertidos em requisitos? E para avaliarmos a qualidade de requisitos; como isto
é feito? Quem os valida? São perguntas relativamente simples e comuns que poderíamos
fazer a todo o momento, mas com uma certa complexidade em responder ou principalmente,
em gerenciar na prática. A engenharia de software nos mostra processos, ferramentas, mé-
todos e técnicas para respondê-las e como lidar com estas situações comuns e sérias em
um projeto de desenvolvimento de software. Mudar requisitos pode ser um grave problema,
chegando até mesmo a limitar algumas ações, enquanto que em outras metodologias ou em
outras abordagens, pode ser tratado como algo previsível e esperado, tendo condições de
agir e trabalhar com esta situação de mudanças.
LEITURA
Como comentamos no capítulo anterior, os livros de engenharia de software são excelentes
fontes de leitura na área da engenharia de requisitos e neles há uma abordagem com mais
profundidade acerca dos assuntos tratados neste capítulo.
• PRESSMAN, Roger S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill, 2011.
• WAZLAWICK, R. S. Engenharia de Software: Conceitos e Práticas, 1a Edição, Elsevier,
2013.
• SOMMERVILLE, Ian. Engenharia de Software, 9ª edição. Editora Pearson do Brasil, 2011.
• A revista Engenharia de Software, na sua edição 13 trouxe um excelente artigo sobre
Rastreabilidade que merece ser lido.
• http://migre.me/oKWiW
116 • capítulo 4
ÁVILA, A. L.; SPÍNOLA, R. O.; Introdução à Engeharia de Requisitos. Revista Engenharia de
Software. Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-
engenharia-de-requisitos/8034>. Acesso em 12 dez 2014.
De BONA, G.; SANTOS, I. R. Gerenciando requisitos com MPS.BR. Revista Engenharia de Software,
Ed. 63, 2012. Disponível em: <http://www.devmedia.com.br/gerenciando-requisitos-com-mps-
br/29375>. Acesso em: 15 dez 2014.
CLELAND-HUANG J, ZEMONT G, LUKASIK W. A Heterogeneous Solution
for Improving the Return on Investrnent of Requirements Traceability.12th IEEE
International Conference on Requirements Engineering, 2004; 230-239.
FAGUNDES, R. M., Engenharia de Requisitos - Do perfil do analista de requisitos ao
desenvolvimento de requisitos com UML e RUP. Salvador, 2011. 216p.
MEDEIROS, H.; Introdução a Engenharia de Requisitos. Disponível em: <http://www.devmedia.
com.br/introducao-a-engenharia-de-requisitos/29454>. Acesso em: 11 jan 2015.
SANTOS, J. H. A.; Gerência de Mudanças de Requisitos: uma proposta de aplicação a um
estudo de caso. Mestrado. UFRGS. 2004. 107p. Disponível em: <http://www.lume.ufrgs.br/
bitstream/handle/10183/4118/000452937.pdf?sequence=1>. Acesso em: 12 jan 2015.
SANTOS, R. N. & WAZLAWICK, R. S. Rastreabilidade Indutiva Aplicada a
Artefatos de Software. VI Experimental Software Engineering Latin American
Workshop, 2009.
SAYÃO, M; BREITMAN, K K. Gerência de Requisitos. Disponível em <http://www-di.inf.puc-rio.
br/~karin/TELECOM/index_files/gerencia_req.pdf>. Acesso em: 24 nov de 2014.
SETTIMI, R., CLELAND-HUANG, J., KHADRA, O. B., MODY, J., LUKASIK,
W. & De PALMA, C. Supporting Software Evolution through Dynarnically Retrieving Traces to
UML Artifacts. Proceedings of the Principies of Software Evolution, 2004.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Práticas, 1ª Edição, Elsevier, 2013. 506p.
capítulo 4 • 117
118 • capítulo 4
5
Modelagem do
Projeto - UML
A modelagem do projeto de software envolve atividades fundamentais que irão
contribuir diretamente no desenvolvimento ou codificação de um sistema. Ela
trata do desenho do software, a sua modelagem, podendo explorar previamen-
te vários recursos e simular por meio de modelagens o seu funcionamento.
Usar um ambiente de modelagem que permita analisar, identificar possí-
veis falhas ou melhorias antes de aplicar diretamente em um ambiente de de-
senvolvimento, é de extrema importância para o sucesso do projeto.
Como modelar envolve notações gráficas, é desejável que se faça estas no-
tações, desenhos e símbolos dentro de padrões que sejam internacionalmente
conhecidos e que estes funcionem adequadamente dentro das regras de negó-
cio que os softwares a serem desenvolvidos estejam inseridos. Para estas no-
tações e sua padronização, existem modelos que podem ser utilizados como
é o caso da UML (Unified Modeling Language), que é uma linguagem de mo-
delagem unificada, representada por alguns diagramas específicos, como por
exemplo os de casos de uso e diagramas de sequência e de classes.
A UML é muito utilizada em projetos que envolvem o paradigma de progra-
mação orientado a objetos. Esta técnica é usada largamente em vários tipos de
aplicações e mostra-se como uma tendência que vai ser usada ainda mais.
Muitas técnicas encontradas na área de engenharia de software dependem
dos conceitos apresentados neste capítulo e espero que isto sirva também para
a sua carreira.
OBJETIVOS
• Aprender sobre a modelagem do software.

• Conhecer os conceitos de casos de uso.
• Aprender sobre diagramas de sequências.
• Aprender sobre diagramas de classes.
120 • capítulo 5
5.1 Introdução
A modelagem de software traz alguns benefícios importantes, melhorando
a comunicação entre os envolvidos no projeto, melhorando o planejamento
e também reduzindo riscos e custos. No entanto, muitos desenvolvedores e
gerentes não compreendem ou não usam adequadamente os recursos que a
modelagem pode oferecer. Em outras situações, é necessário ter um esforço
de convencimento à gerência superior, mesmo a modelagem estando aí duran-
te muitos anos contribuindo para visualização daquilo que será desenvolvido
e permitindo adoção de padrões visuais que muito facilitam a integração da
equipe e o entendimento daquilo que está sendo proposto, justificando alguns
dos benefícios apontados.
Por meio da modelagem, é possível utilizar recursos visuais para representar
tipos de informações distintas, como por exemplo usar diagramas para a arquite-
tura geral do sistema, dependências do sistema, complexidade, fluxo de informa-
ções através de sistemas, requerimentos do negócio, organização e estrutura do
banco de dados, código fonte - incluindo quase todos os aspectos do desenvolvi-
mento orientado a objetos, configurações da instalação, entre outros.
5.2 A modelagem do software

Um sistema ao ser desenvolvido precisa ser modelado como um conjunto de
componentes e de relações entre esses componentes e esta ação faz parte dos
requisitos do sistema e da atividade de projeto. Geralmente a modelagem é ilus-
trada graficamente em um modelo de arquitetura de sistema, que permite ao lei-
tor uma visão geral da organização do sistema, conforme descreve Sommerville
(2006, p. 22):
A arquitetura do sistema é, geralmente, retratada como um diagrama de blocos, mos-

trando os subsistemas principais e as interconexões entre esses subsistemas. Cada
subsistema é sentado por um retângulo, no diagrama de blocos, e a existência de uma
relação entre os subsistemas é indicada por flechas que ligam esses retângulos. Os
relacionamentos indicados podem incluir fluxo de dados, uma relação de ‘usa’/’usado
por’ ou algum outro tipo de relação de dependência (SOMMERVILLE, 2006, p. 22).
capítulo 5 • 121
Esse esquema gráfico está ilustrado na figura 5.1, que exibe a decomposição
de um sistema de alarme antifurtos em seus componentes principais. Observe
que os diagramas de blocos devem ser complementados por breves descrições
de cada subsistema, como indica a tabela 5.1 (SOMMERVILLE, 2006, p. 22).
Sensores de Sensores de
movimento janela
Controlador
de alarme
Sintetizador Discador
Alarme
de voz de telefone
Figura 5.1 – Um sistema simples de alarme antifurto. Fonte: adaptado de Sommerville (2006,
p. 22).
SUBSISTEMAS DESCRIÇÃO
Sensor de movimento Detecta movimento nos cômodos monitorados pelo sistema.
Sensor de janela Detecta a abertura de janelas externas do edifício.
Controlador de alarme Controla a operação do sistema.
Alarme Emite um aviso sonoro quando um intruso é detectado.
Sintetizador de voz Sintetiza uma mensagem de voz dando a localização do possível intruso.
Discador de telefone Faz as chamadas para avisar a segurança, a polícia, etc.
Tabela 5.1 – Funcionalidade de subsistemas no sistema de alarme antifurtos. Fonte: adapta-

do de Sommerville (2006, p. 22)
A implementação de um bom software está diretamente relacionada às ati-

vidades de modelagem, pois por meio dela constrói-se modelos para comuni-
car a estrutura e o comportamento desejados do sistema, visualizar e controlar
a arquitetura do mesmo e compreender melhor o sistema que está sendo elabo-
rado (SOUZA e SOUZA, 2014).
Um sistema pode ser projetado a partir de diferentes modelos para de-
senvolver a modelagem do software. Considerando que um modelo é uma
122 • capítulo 5
simplificação da realidade, criado para facilitar o entendimento de sistemas
complexos, estes modelos podem abranger planos detalhados, assim como
planos mais gerais com uma visão panorâmica do sistema. Assim, todos os
sistemas podem ser descritos sob diferentes aspectos, com a utilização de mo-
delos diversos, onde cada modelo será, portanto, uma abstração específica do
sistema. Os modelos podem ser voltados para a estrutura, dando ênfase à orga-
nização do sistema, ou podem ser voltados ao comportamento, dando ênfase à
dinâmica do sistema (SOUZA e SOUZA, 2014).
Souza e Souza (2014) citam quatro objetivos principais para se criar modelos:
• Eles ajudam a visualizar o sistema como ele é ou como desejamos que ele seja;
• Eles permitem especificar a estrutura ou o comportamento de um sistema;
• Eles proporcionam um guia para a construção do sistema;
• Eles documentam as decisões tomadas no projeto.
Por meio dos modelos, consegue-se obter múltiplas visões do sistema, par-
ticionando a complexidade do sistema para facilitar sua compreensão, e atuan-
do como meio de comunicação entre os participantes do projeto. Portanto, uma
linguagem de modelagem padronizada, tal como a UML (Unified Modeling
Language), é fundamental para a construção e o entendimento de bons mode-
los (SOUZA e SOUZA, 2014).
Dica: A documentação de sistema é uma decisão de negócio, não uma decisão

técnica.
É importante reconhecer que cada vez que você decide manter um modelo ou do-
cumento, está realizando uma troca importante- você está renunciando a novas funcio-
nalidades para escrever a documentação. Quando você pára e pensa a respeito disso,
essa troca é uma decisão de negócio, não técnica. Você está trocando funcionalidade
de negócio por um possível risco de diminuição de benefícios que é gerar apenas arte-
fatos permanentes que descrevem o sistema. Portanto, você deve ir até seus clientes e
pedir permissão para investir os recursos deles desta forma, mostrando as vantagens e
desvantagens de fazê- lo. Algumas vezes, eles escolherão manter os artefatos que você
sugeriu e outras vezes aceitarão o risco de não tê-los e diminuir a carga do trabalho. É
uma decisão deles, não sua.
Fonte: Ambler (2004, p. 50)
capítulo 5 • 123
5.2.1 Modelagem ágil
Com um conjunto de práticas formadas por princípios e valores para serem

aplicados nos projetos de softwares, a Modelagem Ágil (MA) é uma metodolo-
gia baseada na prática para a modelagem e desenvolvimento eficaz de sistemas.
Apesar dela não definir procedimentos detalhados de como desenvolver um
tipo de modelo, ela oferece práticas simples de modelagem (RIBEIRO, 2014).
Há dois motivos fundamentais para modelar: para compreender o que se
está construindo ou para melhorar a comunicação na equipe ou com os clien-
tes do projeto. É possível escolher modelar os requisitos do sistema com um
diagrama de casos de uso ou com um conjunto de definições de regras de ne-
gócio. Também, existe a opção de desenvolver modelos para analisar aqueles
requisitos ou formular uma arquitetura de alto nível ou um desenho detalhado
para seu sistema. Independente da escolha, o objetivo é compreender melhor
um ou mais aspectos de seu sistema. Em outras palavras, o uso dos modelos
tem como finalidade auxiliar a explorar o material com o qual está trabalhan-
do. Além disso, também é possível utilizar modelos para a comunicação entre
membros da equipe ou com agentes externos (AMBLER, 2004, p. 26).
O desenvolvimento de software por meio da utilização de modelagem ágil
não significa o desenvolvimento com pouca modelagem, mas o uso de técnicas
em consonância com os requisitos do projeto. Usualmente utiliza-se a aborda-
gem iterativa para a especificação, desenvolvimento e entrega de software. Esta
abordagem foi criada com o intuito de dar suporte ao desenvolvimento de apli-
cações de negócios nas quais os requisitos de sistema mudam constantemente
durante o desenvolvimento (RIBEIRO, 2014).
A Modelagem ágil tem três objetivos (RIBEIRO, 2014):
1. Definir e mostrar a forma de colocar em prática valores, princípios e práticas rela-

tivas a uma modelagem simples e eficaz;
2. Lidar com a questão de como aplicar as técnicas ágeis nos projetos de software;
3. Discutir como se podem melhorar as atividades de modelagem adotando os mé-
todos ágeis.
124 • capítulo 5
E tem como princípios (RIBEIRO, 2014):
• Satisfazer o cliente através da entrega adiantada e contínua de software de valor;

• Aceitar mudanças de requisitos, mesmo que seja no final do desenvolvimento;
• Entregar software funcionando com frequência, com preferência aos períodos mais
curtos;
• As pessoas relacionadas a negócios e a equipe de desenvolvedores devem trabalhar
em conjunto durante o desenvolvimento do projeto;
• É preciso construir projetos ao lado de pessoas motivadas;
• O método mais eficaz e eficiente de transmitir informações é através da conversa
pessoal;
• Software funcional é a medida primária de progresso;
• Processos de desenvolvimento ágil promovem um ambiente sustentável. Os envol-
vidos no projeto precisam ser capazes de manter indefinidamente passos constantes;
• Contínua atenção a excelência técnica e ao bom design, tende a aumentar a agilidade;
• Simplicidade;
• As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis;
• Em intervalos regulares a equipe reflete em como ficar mais efetiva, então, organiza-
se e otimiza seu comportamento de acordo .
Atualmente, existem vários métodos ágeis como exemplo a Extreme

Programming (XP), Scrum e Crystal (RIBEIRO, 2014).
Na realidade, a MA é apenas um conjunto de técnicas que refletem os prin-
cípios e valores de muitos desenvolvedores de software mais vividos. A pergun-
ta poderia ser colocada: se existe algo como modelagem ágil, é possível dizer
que existem modelos ágeis? A resposta é sim (AMBLER, 2004, p. 28).
Para melhor compreender a Modelagem Ágil, é necessário entender a dife-
rença entre modelo e modelo ágil. “Um modelo é uma abstração que descreve
um ou mais aspectos de um problema ou uma solução possível para ele. Os
modelos são pensados tradicionalmente como diagramas e sua respectiva do-
cumentação”(AMBLER, 2004, p. 30).
capítulo 5 • 125
O modelo ágil é um modelo que cumpre seu propósito, sendo compreensí-
vel para seu público; simples, preciso, suficiente, consistente e detalhado; e o
investimento realizado na sua criação e manutenção agrega valor positivo ao
projeto (AMBLER, 2004, p. 31).
• Os modelos ágeis cumprem seu propósito;

• Os modelo ágeis são compreensíveis;
• Os modelos ágeis são suficientemente precisos;
• Os modelos ágeis são suficientemente consistente;
• Os modelos ágeis são suficientemente detalhados;
• Os modelos ágeis proporcionam valor positivo;
• Os modelos ágeis são os mais simples possíveis.
(AMBLER, 2004, p. 32)
Seguem abaixo pontos que descrevem o escopo da Modelagem Ágil, facili-

tando o seu entendimento:
• A MA é uma atitude, não um processo prescritivo;

• A MA é um suplemento dos métodos preexistentes; não uma metodologia completa;
• A MA é complementar aos processos de modelagem;
• A MA é uma maneira de trabalhar em conjunto de modo eficaz para alcançar os ob-
jetivos dos clientes do projeto;
• A MA é eficaz e trata de eficácia;
• A MA é algo que funciona na prática; não uma teoria acadêmica;
• A MA não é uma bala de prata (silver bullet*);
• A MA foi feita para o desenvolvedor médio, mas não é uma substituição de pessoas
competentes;
• A MA não é um ataque à documentação;
• A MA não é um ataque às ferramentas CASE.
(AMBLER, 2004, p. 32)
126 • capítulo 5
Fazendo a UML Funcionar na Prática
As seguintes estratégias devem ajudá-lo a fazer a UML trabalhar para você na
prática:
Use a UML como sua base de modelagem. Para o desenvolvimento orientado
a objetos ou baseado em componentes, você deve usar a UML como um conjunto bá-
sico de técnicas de modelagem que é então suplementado com outras técnicas para
satisfazer às suas necessidades específicas. Além disso, eu não substituiria a UML por
outros artefatos. Embora esteja convencido de que minha própria notação para mode-
lagem de classes (Ambler, 1995) seja superior à da UML, na realidade, ela não é de
uso comum e, portanto, se você utilizá-la dificultará a compreensão dos diagramas para
outras pessoas, o que reduzirá a comunicação na equipe de projeto.
Adote um subconjunto básico da notação. Se você precisar de apenas 20%
da notação da UML para realizar 80% do trabalho de modelagem, comece com esses
20% básicos.
Eduque todos os desenvolvedores na UML.

Cuidado com a propaganda exagerada. Um efeito colateral infeliz da popula-
ridade da UML é que os vendedores, consultores e até os metodologistas a utilizam
muito para fazer marketing. É bom um consultor ser especialista em UML, mas o que
você realmente precisa é de um especialista em desenvolvimento. Sempre que uma
nova tecnologia, como a XML ou a .NET ou uma nova técnica, como a XP, é lançada, os
membros da comunidade UML se apressam em seguir a moda e escrever livros como
"[Nova Palavra da Moda] e a UML" ou "UML para [Nova Palavra da Moda]". Na minha
opinião, em vez de fazer a pergunta "Como aplicamos a UML com a [Nova Palavra da
moda]?", eles deveriam perguntar "Como modelamos uma aplicação baseada em [Nova
Palavra da moda]?".
Fonte: AMBLER (2004, p. 169)
capítulo 5 • 127
5.3 UML (Unified Modeling Language)
Foi desenvolvida uma linguagem de modelagem unificada, denominada UML
- Unified Modeling Language, com o intuito de padronizar a notação utiliza-
da na representação dos sistemas. A UML, apresentada por Booch, Jacobson e
Rumbaugh (2000), foi criada a partir dos principais métodos orientados a ob-
jetos. A UML pode ser utilizada em sua notação, independente do processo de
software adotado (MACHADO e PEREIRA, 2006). Cada um dos autores possuía
sua própria forma de criar modelos e a UML é a união dessas três abordagens,
adicionando novos conceitos e visões de linguagem (SOUZA e SOUZA, 2014).
A UML é uma linguagem que trouxe a possibilidade de padronizar a mode-
lagem orientada a objetos, de forma que qualquer sistema possa ser modelado
qualquer sistema possa ser modelado, atualizado e compreendido. Antes disso
havia diversos padrões para se criar modelos de software, o que dificultava o
trabalho pela falta de padronização (SOUZA e SOUZA, 2014).
“A UML é uma linguagem muito expressiva, abrangendo todas as visões ne-
cessárias ao desenvolvimento e implantação de sistemas de software em geral”
(SOUZA e SOUZA, 2014).
UML pode ser empregada para visualização, especificação, construção e
documentação de artefatos de software, sendo uma linguagem padrão para a
elaboração da arquitetura de projetos de software que aborda o caráter estático
e dinâmico do sistema a ser analisado (SOUZA e SOUZA, 2014).
Já no período de modelagem a UML considera todas as futuras caracterís-
ticas do sistema, relacionadas a trocas de mensagens entre as diversas partes
do sistema, o padrão arquitetural adotado e os padrões de projeto utilizados
(SOUZA e SOUZA, 2014).
A linguagem UML é usada no desenvolvimento dos mais diversos sistemas, variando

desde sistemas de pequeno porte, tais como um sistema de comércio eletrônico para
uma livraria, a sistemas de grande porte, como um sistema de transações bancárias. Ela
pode abranger várias características de um sistema em um de seus diagramas, sendo
aplicada nas diferentes atividades do desenvolvimento de software, desde a especifica-
ção de requisitos até a implementação e os testes (SOUZA e SOUZA, 2014).
A UML imprime a necessidade de que o analista modele o sistema como

estado da arte da orientação a objetos. Como dito anteriormente, o fato dela
contemplar o estado estático, bem como o dinâmico dos objetos e classes mo-
delados, faz com que ela seja bastante interessante.
128 • capítulo 5
Há uma confusão conceitual com relação a UML. Ela é uma linguagem de
modelagem e não um método de desenvolvimento. Na UML não há a sequên-
cia de passos para se desenvolver um software nem para se modelar. O foco
da UML é representar o sistema utilizando diagramas comuns e integrados e
envolvendo as questões estáticas e dinâmicas de um sistema de informação.
A UML permite elaborar diversos diagramas. Estes diagramas podem ser
para visualização, especificação, construção e documentação de diversas par-
tes do sistema em diversas etapas do ciclo de vida. São vários os tipos de diagra-
mas que permitem modelar aspectos dinâmicos do sistema por meio da UML
(LEITE, 2000b). Os diagramas da UML são apresentados na tabela 5.2.
DIAGRAMA DE Diagrama de casos de uso

COMPORTAMENTO EXTERNO
Diagrama de classes
DIAGRAMAS DE
COMPORTAMENTO INTERNO
Diagrama de objetos
Diagrama de sequência
Diagrama de colaboração
DIAGRAMAS ESTRUTURAIS
Diagrama de estados
Diagrama de atividades
Diagrama de componentes
DIAGRAMAS DE
IMPLEMENTAÇÃO
Diagramas de execução
Tabela 5.2 – Diagramas da UML.
capítulo 5 • 129
5.3.1 Aplicação
Devido a quantidade de diagramas presentes na UML, é possível usá-las prati-

camente em qualquer tipo de sistema mesmo os que não estejam aplicando a
tecnologia orientada a objetos.
Os diagramas permitem que eles possam ser aplicados em diferentes fases
de desenvolvimento dos ciclos de vida já estudados, desde a especificação da
análise até o final do projeto nas fases de testes.
A aplicação principal da UML é descrever qualquer tipo de sistema em ter-
mos de diagramas orientados a objetos. Ela pode ser inclusive usada para mo-
delar sistemas mecânicos, sem uso de software.
A maioria dos sistemas existentes possuem características de tempo real,
banco de dados, interação com o usuário por meio de telas e outras. A UML
suporta modelagens para todos estes tipos.
Os seguintes links mostram exemplos de aplicação da modelagem UML:

• http://migre.me/oDEbg
• Contém um exemplo completo com vários diagramas sobre um mesmo sistema.
• http://migre.me/oDEeG
• Possui vários links com modelos UML completos
• http://migre.me/oDEfG
• Neste artigo o autor mostra um exemplo de modelagem passo a passo.
5.4 Casos de Uso

Vale ressaltar que um caso de uso modela uma interação completa entre um
ator e o sistema. Geralmente, cada requisito funcional gera pelo menos um
caso de uso. É importante ter cuidado para não detalhar, criar muitos casos de
uso, já que o excesso de detalhes pode gerar maior gasto de tempo na modela-
gem, sem contribuir para a qualidade do produto final (MELLO, 2005, p. 107).
Há diversas maneiras de descrever casos de uso. Pode ser desde uma des-
crição de alto nível, com poucas sentenças até uma descrição expandida, com
maior detalhamento do diálogo entre ator e sistema (MELLO, 2005, p. 108).
130 • capítulo 5
As descrições expandidas são importantes em casos de uso em grandes pro-
jetos, pois nestes o trabalho tende a ser dividido em diversas equipes e a co-
municação é executada por escrito. Já em equipes menores, o natural é que a
mesma equipe seja responsável por todo o trabalho de desenvolvimento, desde
os requisitos até a implantação e suporte (MELLO, 2005, p. 108).
Os casos de uso foram definidos como parte da metodologia de Jacobson:
Object-oriented Analysis and Design - The User Case Driven Approach. A lin-
guagem de modelagem UML apresenta notações para a representação de casos
de uso (LEITE, 2000b).
Um caso de uso é capaz de especificar o comportamento do sistema a ser de-
senvolvido. Porém não especifica como este comportamento será implementa-
do. “Os comportamentos descrevem as funções da aplicação que caracterizam
a funcionalidade do sistema. Um caso de uso representa o que o sistema faz e
não como o sistema faz, proporcionando uma visão externa e não interna do
sistema” (LEITE, 2000b).
O processo de desenvolvimento é direcionado pelos casos de uso. Baseando-
se no modelo de casos de uso os desenvolvedores elaboram os modelos de pro-
jeto e implementacão.
São os responsáveis pelos testes que têm o objetivo de garantir que os com-
ponentes do modelo de implementação cumpram corretamente os objetivos
estabelecidos nos casos de uso. Assim, percebe-se que os casos de uso, além
de iniciarem o processo de desenvolvimento, também o mantêm em coesão.
“Direcionado a casos de uso significa que o processo de desenvolvimento exe-
cuta uma seqüência de tarefas derivadas dos casos de uso. Eles são especifica-
dos, projetados e servem de base para a construção dos casos de teste”(MAR-
TINS, 2014).
De acordo com Falbo (2002), os casos de uso têm dois importantes papéis:
1. Eles capturam os requisitos funcionais de um sistema. Um modelo de caso

de uso define o comportamento de um sistema (e a informação associada) através de
um conjunto de casos de uso. O ambiente do sistema é definido pela descrição dos
diferentes usuários. Estes usuários utilizam o sistema através de um número de casos
de uso.
capítulo 5 • 131
2. Eles oferecem uma abordagem para a modelagem de sistemas. Para ge-
renciar a complexidade de sistemas reais, é comum apresentar os modelos do sistema
em um número de diferentes visões. Em uma abordagem guiada por casos de uso, po-
de-se construir uma visão para cada caso de uso, isto é, em cada visão são modelados
apenas aqueles elementos que participam de um caso de uso específico. Um particular
elemento pode, é claro, participar de vários casos de uso. Isto significa que um modelo
do sistema completo só é visto através de um conjunto de visões - uma por caso de uso.
Encontra-se todas as responsabilidades de um elemento de modelo, olhando todos os
casos de uso onde este tem um papel.
Casos de uso são uma ferramenta essencial na captura dos requisitos de um

sistema, e possuem um papel fundamental no planejamento e controle de pro-
jetos iterativos (FALBO, 2002).
A primeira atividade a ser realizada no desenvolvimento, propriamente
dito, A é a captura dos casos de uso. Normalmente, a maioria dos casos de uso
é gerada durante a fase de levantamento de requisitos, mas outros casos de uso
podem ser descobertos à medida que o trabalho prossegue. Todo caso de uso é
um requisito potencial e, enquanto um requisito não é capturado, não é possí-
vel planejar como tratá-lo (FALBO, 2002).
Geralmente, em primeiro lugar, casos de uso são listados e discutidos, para
só então, se realizar alguma modelagem. Entretanto, em alguns casos, a mode-
lagem conceitual ajuda a descobrir casos de uso (FALBO, 2002).
5.4.1 Diagramas de Caso de Uso
Com o objetivo de descrever e definir os requisitos funcionais do sistema, são

utilizados os diagramas de caso de uso. O modelo de caso de uso consiste de
atores e casos de uso. Nos diagramas atores representam uma entidade externa
ao sistema como um usuário, um hardware ou outro sistema que interage com
sistema modelado. O diagrama representa uma sequência de ações executadas
pelo sistema ao receber um dado do ator.
“Um caso de uso é representado por uma elipse. Cada caso de uso distin-
gue-se de um outro por um nome que normalmente é um verbo seguido do seu
objeto” (LEITE, 2000b).
132 • capítulo 5
Os casos de uso mostram o comportamento do sistema, cenários que o sis-
tema percorre em resposta ao estímulo de um ator.
Os atores são conectados a casos de uso por uma associação representadas por uma
linha. O comportamento associado a cada caso de uso pode ser descrito como um
cenário. Cada cenário descreve textualmente o fluxo de eventos ou seqüência que
caracteriza o comportamento do ator e as respostas do sistema. Um cenário é uma
instância do caso de uso (LEITE, 2000b).
O relacionamento entre um ator e um caso de uso representa a participação

deste ator no caso de uso. Existem, também, dois outros tipos de relacionamen-
tos entre casos de uso:
• Relacionamento estender - é representado graficamente por uma seta

com um o estereótipo <<extends>>, mostrando que o caso de uso destino pode
incluir o comportamento especificado pelo caso de uso origem.
• Relacionamento usar - é representado por uma seta com o estereótipo
<<uses>>, mostrando que o caso de uso origem inclui o comportamento espe-
cificado pelo caso de uso destino.
Estabelecer limites
Atualizar contas
Gerente comercial Sistema de contabilidade

<<uses>>
Analisar riscos
Avaliar negócio
<<uses>>
Fechar preços
Ator
Analista comercial
Registrar negócios
Generalização Vendedor
<<extends>>
Negócios com
Caso de uso
limites excedidos
Figura 5.2 – Diagrama de casos de uso. Fonte: Fowler e Scott (2004).
capítulo 5 • 133
Pode-se dizer que um diagrama de casos de uso é formado por (LEITE,
2000b):
• Casos de uso
• Atores
• Relacionamentos de dependência, generalizações e associações
Seguem abaixo as regras para modelar os requisitos de software de um sis-
tema (LEITE, 2000b):
• Estabeleça o contexto do sistema identificando os atores (usuários e sistemas exter-

nos) associados a ele.
• Para cada ator, considere o comportamento que cada um deles espera ou requer que
o sistema possua, para que as suas metas sejam satisfeitas.
• Considere cada um destes comportamentos esperados como casos de uso, dando
nomes para cada um deles.
• Analise os casos de uso tentando identificar comportamentos comuns a mais de
um deles. Defina esta parte comum como caso de uso genérico, estabelecendo um
relacionamento de generalização. Tente identificar outros relacionamentos, como a de-
pendência entre casos de uso que incluem o comportamento de outros .
• Modele estes casos de uso, atores e seus relacionamentos em diagramas de casos
de uso.
• Complemente estes casos de uso com notas que descrevam requisitos não-funcionais.
Além das regras acima, há algumas informações importantes que auxiliam

na construção de diagramas mais claros (LEITE, 2000b).
• Dê nomes que comuniquem o seu propósito.

• Quando existirem relacionamentos, distribua os casos de uso de maneira a minimizar
os cruzamentos de linhas.
• Organize os elementos espacialmente de maneira que aqueles que descrevem com-
portamento associados fiquem mais próximos.
• Use notas para chamar a atenção de características importantes - as notas não são
apenas para os requisitos não funcionais.
• Não complique o diagrama, coloque apenas o que é essencial para descrever os re-
quisitos. O diagrama deve ser simples sem deixar de mostrar o que é relevante.
134 • capítulo 5
5.4.2 Descrição de Casos de Uso
Um caso de uso deve descrever o que um sistema faz. Apenas o diagrama de

caso de uso não conseguiria cumprir este objetivo. Desta forma, é importante
que o comportamento de um caso de uso tenha seu fluxo de eventos descrito
textualmente, de maneira que um agente externo possa compreendê-lo. “Ao es-
crever o fluxo de eventos, deve-se incluir como e quando o caso de uso inicia e
termina, quando o caso de uso interage com os atores e outros casos de uso e
quais são as informações transferidas e o fluxo básico e fluxos alternativos do
comportamento” (FALBO, 2002, p. 26).
Após ter o conjunto inicial de casos de uso estabilizado, é importante que
cada um deles seja descrito com maior detalhamento. Primeiramente, deve-se
descrever o fluxo de eventos principal (básico). Variantes do curso básico de
eventos e erros que possam vir a ocorrer devem ser descritos em cursos alterna-
tivos. É usual que um caso de uso tenha apenas um único curso básico, porém
inúmeros cursos alternativos (FALBO, 2002, p. 26).
5.5 Diagramas de Classes

Ao conjunto de objetos com propriedades, comportamento, relacionamentos
e semântica comuns, dá-se o nome de Classe. Uma classe pode ser entendida
como um esqueleto ou modelo para se criar objetos. “Objeto é uma abstração
que representa uma entidade do mundo real, podendo ser algo concreto (com-
putador, carro) ou abstrato (transação bancária, histórico, taxa de juros)” (TA-
CLA, 2013, p. 7).
O diagrama de classes talvez seja o diagrama mais importante e usado na
UML. É ele quem modela a estrutura estática das classes de um sistema. No
diagrama são mostradas as associações entre as classes e seus tipos, a espe-
cificação das classes, especializações e generalizações e os agrupamentos em
pacotes.
O interessante do diagrama de classes é que ele pode ser implementado
usando alguma linguagem de programação orientada a objetos. Existem várias
ferramentas CASE que após o desenho do diagrama de classes gera o código em
Java, C++, C#, etc.
capítulo 5 • 135
Veja um exemplo de um diagrama de classes na figura 5.3.
Cliente
1
Possui
0..*
Contrato de Refere a
Veículo alugado
aluguel 0..1
0..* Tipo de veículo
Possui
1 Caminhão Carro sport Carro de passeio
Companhia de
aluguel de veículos
Figura 5.3 – Diagrama de classes. Fonte: Fowler e Scott (2004).
5.6 Diagrama de Objetos

É uma variação do diagrama de classes e possui praticamente a mesma nota-
ção. A diferença é que este mostra objetos que foram instanciados das classes.
Ele mostra o sistema em um determinado momento. Usa a mesma notação do
diagrama de classes, mas com duas exceções: os objetos são escritos com os no-
mes sublinhados e todas as instâncias em um relacionamento são mostradas.
Os diagramas de objetos são úteis para exemplificar diagramas de objetos
muito complexos, ajudando em sua compreensão. São também usados para
mostrar a colaboração dinâmica dos objetos.
Pablo: cliente
Nome: “Pablo F. Barros”

Idade: 20
CPF: 94168912-15
2678: contrato de aluguel 2679: contrato de aluguel
Num_contrato: 2678 Num_contrato: 2679

Veículo: “BMW 914” Veículo: “Audi V8”
Figura 5.4 – Diagrama de objetos.
136 • capítulo 5
5.7 Diagramas de estados
Mostra todos os estados possíveis dos objetos de uma classe, bem como os
eventos que devem ocorrer que provocam a tais mudanças de estado. Eles mos-
tram o comportamento dinâmico de um sistema, mostrando o ciclo de vida de
um objeto.
A UML utiliza como notação para diagramas de estados a notação proposta
por Harel. Nesta notação, um diagrama de estados é um grafo dirigido cujos no-
dos representam estados e cujos arcos representam transições entre estados.
Estados são representados graficamente por elipses ou retângulos com bordas
arredondadas e transições são representadas por segmento de retas dirigidas.
O estado inicial é representado por um ponto de início e podem existir vários
pontos de finalização.
Subir (andar)
No térreo Subindo
Chegar no térreo
Indo para Chegar no andar Subir (andar)

o térreo
Chegar no andar
Descendo Parado
Descer (andar)
Tempo de espera
Figura 5.5 – Diagrama de estados.
5.8 Diagramas de sequência
Em um diagrama de seqüência, um objeto é mostrado como um retângulo com uma

linha vertical pontilhada anexada. Esta linha é chamada de linha de vida do objeto e
representa a “vida” do objeto durante a interação. Cada mensagem é representada por
uma seta cheia entre as linhas de vida de dois objetos. A ordem na qual as mensagens
ocorrem é mostrada do alto para o pé da página. Cada mensagem é rotulada com pelo
menos o nome da mensagem. Adicionalmente, pode incluir também seus argumentos
e alguma informação de controle (FALBO, 2002, p. 71).
capítulo 5 • 137
O diagrama de sequência, mostrado na figura 5.6, tem como objetivo repre-
sentar a interação e relacionamento entre os objetos possibilitando assim visu-
alizar a sequência de mensagens trocadas entre eles.
Os objetos são mostrados em linhas verticais. No caso da figura 6, os objetos
são: computador, servidor de impressão, impressora e fila.
A sensação temporal do diagrama é percebido analisando-o no sentido ver-
tical, de cima para baixo. As mensagens enviadas por cada objeto são represen-
tadas por setas entre os objetos relacionados.
No diagrama do exemplo, as mensagens são:
• imprimir (arquivo);
• impressora livre;
• impressora ocupada.
Como podemos perceber, existem dois eixos no diagrama de sequência: o

eixo vertical que mostra a linha de vida de cada objeto e o diagrama horizontal
que mostra o fluxo de mensagens trocadas entre eles.
O diagrama de sequência normalmente está associado ao comportamento
de um único caso de uso e, também, podem representar um determinado cená-
rio do sistema.
Servidor de
Computador Impressora Fila
impressão
(Impressora livre)
Imprimir (arquivo) Imprimir (arquivo)
(Impressora ocupada)
Imprimir (arquivo)
Figura 5.6 – Diagrama de sequência.
Para facilitar a compreensão de um diagrama de sequência, é possível utili-

zar uma técnica que consiste em colocar descrições de texto dos acontecimen-
tos do lado esquerdo do diagrama de sequência (FALBO, 2002).
138 • capítulo 5
5.9 Diagrama de Colaboração
Mostra a colaboração dinâmica entre os objetos, porém mostra a sequência
cronológica do cenário que esta sendo modelado.
Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o dia-
grama de sequência, mas se a ênfase for o contexto do sistema, é melhor dar
prioridade ao diagrama de colaboração.
O diagrama de colaboração é desenhado como um diagrama de objeto,
onde os diversos objetos são mostrados juntamente com seus relacionamen-
tos. As setas de mensagens são desenhadas entre os objetos para mostrar o
fluxo de mensagens entre eles. As mensagens são nomeadas, que entre outras
coisas mostram a ordem em que as mensagens são enviadas. O diagrama de
colaboração também pode conter objetos ativos, que executam paralelamente
com outros.
Computador (Impressora ocupada) Fila

1.2: Armazenar (arquivo)
1: Imprimir (arquivo)
(Impressora livre)
Servidor de 1.1: Imprimir (arquivo)
Impressora
impressão
Figura 5.7 – Diagrama de colaboração.
5.10 Diagrama de Atividade

A figura 5.8 mostra um típico diagrama de atividades.
Os diagramas de atividade são representações gráficas de fluxos de infor-
mações de atividades sequenciais e ações nestas atividades. O diagrama supor-
ta escolhas, iterações e concorrência (paralelismo).
Os diagramas podem ser usados basicamente para descrever os fluxos de
negócio e operacionais passo a passo dentro de um sistema. Em resumo, o dia-
grama de atividades mostra o fluxo de controle geral do sistema.
capítulo 5 • 139
Na Figura 8 é possível perceber o fluxo de informações de uma determinada
atividade do sistema. No caso a atividade é a “Imprimir arquivo()”. Perceba que
este diagrama pode mostrar como deverá ser a implementação deste método
de uma classe de impressão, por exemplo.
Mostrar caixa de
(Disco cheio)
mensagem
“Disco cheio”
Imprimir arquivo ( )
Mostrar caixa de
(Espaço em disco) mensagem
“Imprimindo”
Impressora
Remover caixa imprimir (arquivo) Criar arquivo
de mensagem Postscript
Figura 5.8 – Diagrama de atividade.
5.11 Diagrama de Componentes

A figura 5.9 mostra um diagrama de componentes da UML. Observe que exis-
tem arquivos .dll e .exe de uma parte de um sistema que está sendo modelado
pela UML.
Pela figura, é possível perceber que o diagrama de componentes mostra
os vários componentes em um sistema e suas dependências. É um diagrama
físico.
Um componente pode ser um módulo físico do sistema. Pode ser um paco-
te de software, uma biblioteca (dll por exemplo), enfim, os componentes são
a implementação na arquitetura física do que foi especificado na arquitetura
lógica do sistema.
As dependências entre os componentes, representadas pelas linhas trace-
jadas, mostram como mudanças em um componente podem causar mudan-
ças em outros componentes. Existem vários tipos de dependência porém o uso
mais comum na representação é a comunicação entre os componentes.
140 • capítulo 5
Gerenciador de Gráficos Gerenciador de
comunicação banco de
dados
Comm.dll Graficos.dll
Db.dll
Aplicação
App.exel
Figura 5.9 – Diagrama de componente. Fonte: Fowler e Scott (2004).
5.12 Diagrama de Execução

Mostra a arquitetura física do sistema (hardware e software), juntamente com
as conexões entre si. Pode-se também mostrar os tipos de conexão entre eles.
É a última descrição física da topologia do sistema, descrevendo a estrutura de
hardware e software que executam em cada sistema.
O diagrama de execução é composto por componentes, que possuem a
mesma simbologia dos componentes do diagrama de componentes, nodes,
que significam objetos físicos que fazem parte do sistema, podendo ser uma
máquina cliente numa LAN, uma máquina servidora, uma impressora, um ro-
teador, etc., e conexões entre estes nodes e componentes que juntos compõem
toda a arquitetura física do sistema.
Cliente A:
Pentium 200 <<TCP/IP>>
MMX Servidor de
Servidor de SQL<<TCP/IP>> banco de
aplicação:
dados:
HP/UX
ORACLE
Cliente B: <<TCP/IP>>
Pentium 200
MMX
Figura 5.10 – Diagrama de execução.
capítulo 5 • 141
ATIVIDADES
01. Você conhece algum software que trabalha com modelagem? Se sim, cite e comente
sobre ele. Caso não conheça, pesquise alguns dos mais utilizados na internet e comente suas
principais características.
02. A UML pode ser considerada uma metodologia de desenvolvimento de sistemas. Esta
afirmação esta correta? Justifique.
03. Nos diagramas de casos de uso, o que ou quem pode ser considerado atores? Justifique
e dê um exemplo.
04. Em quais situações é recomendável utilizar diagramas de sequência? Justifique.
05. Em quais situações é recomendável utilizar diagramas de classes? Justifique.
REFLEXÃO
Modelar para construir. Isto não lhe parece óbvio? Evidentemente que para a área de softwa-
re isto não seria diferente e assim como ocorre em outras áreas da engenharia, a engenharia
de software também possui suas formas de notações, métodos e técnicas para efetuar pro-
jetos de sistema. O paradigma de orientação a objetos é uma forma de fundamentar outras
áreas do conhecimento na engenharia de software.
Imagine se todos no mundo, em diferentes países, adotassem à seu modo os seus crité-
rios e padrões de desenhos ao modelar algo. Como seria? Consegue imaginar a dificuldade
que seria se cada país, ou ainda em diferentes regiões de um mesmo país tivessem várias
formas de anotar um determinado procedimento, uma ação, um processo, uma classe, um
objeto e assim por diante?
A UML traz esta possibilidade junto à necessidade de se padronizar notações por meio
de uma linguagem unificada de modelagem. Ela permite que diagramas sejam utilizados e
interpretados por pessoas com conhecimento técnico de todas as partes do mundo, propor-
cionando um ganho nas anotações, esquemas e diagramas dando sentido à modelagem de
sistemas de todo os tipos, com diferentes focos, por meio de seus diagramas.
142 • capítulo 5
Enfim, atualmente temos disponíveis vários métodos, técnicas, ferramentas e modelos
a serem seguidos e aperfeiçoados no mundo da engenharia de software e por isso, os tra-
balhos e atividades relacionadas aos requisitos de sistema tendem otimizar e melhorar cada
vez mais.
LEITURA
Além de livros e guias que são fundamentais para complementar o estudo sobre modelagem
e UML, na internet existem vários tutoriais a materiais que muito contribuem para a apren-
dizagem.
• http://migre.me/oKWVm - Este link leva à um site (Case-Tools) contém várias ferramentas
UML gratuitas e proprietárias. É necessário realizar um cadastro.
• UML.org - O site da principal referência da UML, onde os novos padrões são estabelecidos
e divulgados.
• http://migre.me/oKXbj - Link para um excelente site sobre introdução a UML, em inglês.
• Booch, G.; Rumbaugh, J.; Jacobson, I. UML: guia do usuário. São Paulo: Campus, 2006.
Excelente livro com uma boa visão sobre UML.
AMBLER, S. W.; Modelagem Ágil - Práticas eficazes para a Programação Extrema e o Processo
Unificado. Bookman. 2004. 351p.
FALBO, R. A.; Análise de Sistemas. UFES. 2012. 120p.
FOWLER, M,; SCOTT, K. UML essencial. Porto Alegre: Bookman, 2004.
LEITE, J. C.; Análise e Especificação de Requisitos. 2000b. Disponível em: <http://www.dimap.ufrn.
br/~jair/ES/c4.html>. Acesso em: 10 dez 2014.
MACHADO, I. M. R.; PEREIRA, L. M.; Processo de Desenvolvimento de Software Livre: Um
Estudo de Caso do Projeto EAD Livre. Simpósio Mineiro de Sistemas, 2006. Disponível em:
<http://homepages.dcc.ufmg.br/~ivre/Artigo1.pdf>. Acesso em 17 dez 2014.
MARTINS, V.; Processo Unificado. Disponível em: <http://www.batebyte.pr.gov.br/modules/
conteudo/conteudo.php?conteudo=1227>. Acesso em 15 dez 2014.
MELLO, J. A. B.; Uma Metodologia para Engenharia de Requisitos para Pequenas Equipes de
Desenvolvimento de Software. Rev. Ciên. Empresariais da UNIPAR, Toledo, v.6, n.1, 2005. 97-111p.
capítulo 5 • 143
RIBEIRO, C. F. Modelos de desenvolvimento de software. Revista .Net Magazine 101. Disponível
em: <http://www.devmedia.com.br/modelos-de-desenvolvimento-de-software-revista-net-
magazine-101/26747>. Acesso em: 15 dez 2014.
SOUZA, C. A. R.; SOUZA, V. E. S..; Modelagem de software com UML - Parte 1. Easy Java
Magazine 4. Disponível em: <http://www.devmedia.com.br/modelagem-de-software-com-uml-parte-1-
easy-java-magazine-4/20140>. Acesso em 12 dez 2014.
TACLA, C. A.; Análise e Projeto OO & UML 2.0. UTFPR. 2013. 97p. Disponível em: <http://www.
dainf.ct.utfpr.edu.br/~tacla/UML/Apostila.pdf>. Acesso em: 12 jan 2015.
GABARITO
Capítulo 1
01. Letra “a”.

02. As RTF tem como objetivos: (1) descobrir erros na função, lógica ou implementação
para qualquer representação do software; (2) verificar se o software que está sendo revisa-
do atende aos requisitos propostos; (3) garantir que o software foi representado de acordo
com padrões predefinidos; (4) obter software que seja desenvolvido de maneira uniforme; e
(5) tornar os projetos mais gerenciáveis. Um ponto interessante de se observar é que além
disso, a RTF também serve como base de treinamento, possibilitando que engenheiros mais
novos observem diferentes abordagens para análise, projeto e implementação de software,
contribuindo ainda mais para a qualidade.
03. Um processo de software sem controle resulta em processos improvisados pelos de-
senvolvedores e gerência. Não é rigorosamente seguido e o cumprimento das metas não
é controlado. O processo passa a ser altamente dependente da qualidade e experiência
dos profissionais envolvidos. E diminui a visão de progresso e qualidade do processo. A
qualidade do produto fica comprometida e os prazos dificilmente são cumpridos. Possui alto
risco quando é necessária a utilização de novas tecnologias, por depender diretamente da
experiência dos profissionais. Além de tornar muito difícil prever a qualidade final do produto.
O processo passa a ser constantemente reativo a situações inesperadas e problemas ao
invés de ser pró-ativas, não havendo tempo para melhorias. De forma geral, o “fogo” esta
144 • capítulo 5
sob controle, mas esta quase sempre “apagando incêndios”, fazendo com que os envolvidos
tenham “queimaduras” constantes. Com isso sempre sobram “cinzas” que podem facilmente
voltar a se incendiar mais tarde.
04. Para que um software seja considerado “de qualidade”, é necessário que este tenha
conformidade com alguns conceitos:
• Correção: deve funcionar de forma correta. Satisfazendo as suas especificações sem fa-
lhas ou erros;
• Integridade: suas especificações satisfazem os requisitos dos usuários e da organização;
• Flexibilidade: deve prever que o usuário pode agir de forma não esperada e deve ser
capaz de resistir a eventuais situações sem falhas;
• Confiabilidade: deve se comportar como esperado e não falhar em situações inesperadas;
• Eficiência: deve realizar suas tarefas em tempo adequado à complexidade de cada um
deles. E devem utilizar de modo eficiente os recursos de hardware disponíveis;
• Reusabilidade: os componentes do software devem permitir ser reutilizados em outras
aplicações;
• Usabilidade: deve ser fácil de aprender e de usar, permitindo maior produtividade do usu-
ário, flexibilidade de utilização e aplicação e proporcionar satisfação ao usuário;
• Manutenibilidade: deve permitir fácil manutenção para que correções ou atualizações
sejam realizadas de modo fácil e eficiente;
• Evolutibilidade: deve permitir expansão de suas funcionalidades para atender novos re-
quisitos ou incorporar novas tecnologias;
• Portabilidade: deve poder ser executado no maior número possível de equipamentos;
• Interoperabilidade: deve ser capaz de interagir com diferentes sistemas e plataformas.
05. Não é a mesma coisa. Qualidade e segurança são diferentes, dentro do contexto de
software. No entanto, a segurança pode ser um fator que determina a qualidade em um sof-
tware, se esta for um requisito desejado. Qualidade de software pode ser definida como um
conjunto de atributos de software que devem ser satisfeitos de modo que o software atenda
às necessidades dos usuários. A determinação dos atributos relevantes a cada sistema de-
pende do domínio da aplicação, das tecnologias utilizadas, das características específicas do
projeto e das necessidades do usuário e da organização.
capítulo 5 • 145
Capítulo 2
01. As principais dificuldades para uma empresa ou organização implantar uma norma de
qualidade de produtos de software estariam relacionadas à mudança ou readequação dos
processos da mesma, podendo causar grandes resistências entre os colaboradores, depen-
dendo da cultura organizacional ali existente, bem como exigir um nível de maturidade (quan-
to a processos) para que as normas sejam implantadas com sucesso. Ter o apoio da alta ge-
rência é essencial, bem como o apoio de todos os envolvidos neste processo de mudanças.
02. O impacto seria negativo, com softwares de baixa qualidade. Portanto, é praticamente
impossível desenvolver softwares de qualidade sem qualquer tipo de controle de processos,
uma vez que estes são essenciais para o êxito da qualidade do software. No entanto, caso
não seja considerado os aspectos de qualidade em um software, aí sim podemos considerar
que é possível desenvolver softwares sob estas condições, mas totalmente desprovidos de
qualidade.
03. Esta é uma pergunta que solicita sua opinião; pense e reflita sobre ela. Julgar que todas
as empresas devam implantar uma norma pode parecer utópico, mas seria o ideal, pois assim
as organizações estariam alcançando altos níveis de maturidade e estariam sempre buscan-
do a melhoria contínua.
04. A ISO publicou uma norma que representa uma padronização mundial para a qualidade
de produtos de software, trata-se da norma ISO/IEC 9126 e foi publicada em 1991. Esta
norma é uma das mais antigas da área de qualidade de software e possui uma tradução
para o Brasil, publicada em agosto de 1996 como NBR 13596. Esta norma apresenta um
conjunto de características que devem ser verificadas em um software para que ele seja
considerado um “software de qualidade”.
05. A qualidade de um software está diretamente relacionada à qualidade de seus proces-
sos, pois estes são determinantes para o resultado final do produto de software. O controle
dos processos e das atividades realizadas em todo o ciclo de desenvolvimento do software
irão ser determinando para o resultado da qualidade.
Capítulo 3
01. Diversos problemas podem ocorrer durante a atividade de levantamento de requisitos,

sendo que os principais identificados, de acordo com Santos (2004, p. 24), são:
• o conhecimento do domínio do negócio encontra-se espalhado por diversos meios, tais
como: livros, sistemas existentes, manuais de operação, envolvidos, etc.;
146 • capítulo 5
• o tempo escasso e a disponibilidade dos envolvidos;
• fatores políticos e organizacionais, podendo não ser muito clara sua existência aos envol-
vidos;
• os envolvidos não sabem exatamente o que fazem, o que precisam e o que querem que
seja desenvolvido.
02. Em algumas situações é mais fácil reunir analistas e usuários para simular situações
reais e necessárias no futuro sistema do que tentar estabelecer as necessidades por meio
de outros métodos mais abstratos. Para isto são usados os cenários. Os cenários servem
para revelar detalhes que não foram percebidos e adicioná-los aos esboços dos requisitos.
O estabelecimento dos cenários pode ser feito informalmente com os analistas trabalhando
com os usuários principais ou fomentadores do projeto a fim de identificar os usuários ope-
racionais e captar detalhes, ou outras formas. Os cenários são muito usados nos métodos
ágeis de desenvolvimento.
03. Requisitos não-funcionais: São restrições sobre os serviços ou as funções ofereci-
dos pelo Sistema. Entre ele: destacam-se restrições de tempo, restrições sobre o processo
de desenvolvimento, padrões, entre outros. Exemplos: Não poderão ocorrer perdas de in-
formações; O sistema deverá ter alta disponibilidade; O sistema deverá ser executado em
qualquer navegador; O sistema deverá comportar com velocidade satisfatória, com menos
de 3 segundos.
04. Letra “c”
05. Vamos deixar aqui a definição dada por Leite (2000b) para que você compare com a
sua resposta: Requisitos são objetivos ou restrições estabelecidas por clientes e usuários
do sistema que definem as diversas propriedades do sistema. Os requisitos de software são,
obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do
software. Sendo assim, um conjunto de requisitos pode ser definido como uma condição ou
capacidade necessária que o software deve possuir para que o usuário possa resolver um
problema ou atingir um objetivo ou para atender as necessidades ou restrições da organiza-
ção ou dos outros componentes do sistema
Capítulo 4
01. Alguns exemplos de softwares que trabalham com gerenciamento de requisitos são:
Jeremia, OSRMT, Tiger Pro e Xuse. Segue uma sugestão de artigo que faz um estudo com-
parativo entre ferramentas de Gerência de Requisitos: http://www.cin.ufpe.br/~tg/2009-2/
rrta.pdf
capítulo 5 • 147
02. O rastreamento pode ser realizado de diferentes formas, entre elas devemos destacar
as seguintes:
• Rastreamento de origem, em que é realizada a associação entre os requisitos e os stake-
holders que propuseram tal requisito.
• Rastreamento de requisitos, em que é identificada a associação de um determinado requi-
sito com a dependência existente com outros requisitos.
• Rastreamento de projeto, em que é identificada a associação de um requisito com o projeto
como um todo.
Para a melhor visualização do rastreamento o ideal é utilizar-se de uma representação
gráfica de referência cruzada ou matriz de rastreamento. Neste modelo os requisitos são
dispostos nas linhas e colunas de uma tabela e suas dependências são representadas por
letras ou símbolos
03. Sim, o fato de ter muitas mudanças de requisitos influencia a escolha dos métodos de
desenvolvimento de um software pois certas metodologias lidam melhor e outras não com
este tipo de situação. Um exemplo disto é o método cascata, ou clássico, que exige que todos
os requisitos sejam definidos desde o princípio para que o projeto siga o planejamento sem
contar com alterações, enquanto que os métodos ágeis, onde prevê iterações cíclicas, permi-
te que mudanças aconteçam e possuem técnicas adequadas para lidar com estas mudanças.
04. Buscando a qualidade é importante que a Especificação de Requisitos de Software
atenda a alguns preceitos de qualidade de software, conforme definidos por padrões interna-
cionais (como, por exemplo, o IEEE, o CMM e o SPICE). Para tanto a especificação deve ser:
ESPECIFICAÇÕES: DETALHAMENTO:
Tudo o que está sendo descrito sobre os requisitos deve realmente
CORRETA expressar sua realidade – ser o que realmente é
Os requisitos devem ter apenas uma interpretação, acordada entre
os usuários e os desenvolvedores. As dúvidas podem ser dirimidas
PRECISA com um dicionário de termos, que deve ser declarado para resolver
as dúvidas que surgirem
Deve refletir todas as decisões de especificação que foram tomadas
ao longo de sua discussão, envolvendo os usuários e os desenvol-
vedores. Deve trazer de forma bem clara e definida a sua funciona-
COMPLETA lidade, desempenho desejado, restrições de projeto (técnicas e não
técnicas), atributos necessários e, caso exista, relacionamento com
outras aplicações. Procurar contemplar todas as situações possíveis
CONSISTENTE Não ter nenhum conflito ou sobreposição a outros requisitos
148 • capítulo 5
Definir prioridades de acordo com a importância, estabilidade e com-
plexidade. Dentro destes critérios, os requisitos podem ser:
- essencial: requisito sem o qual o produto não atende às necessi-
dades do usuário;
- desejável: sua existência aumenta o valor do produto, mas se por
PRIORIZADA alguma necessidade não for contemplado não afeta de forma subs-
tancial a utilização do produto;
- opcional: requisito que poderá ser incluído caso haja disponi-
bilidade de prazo e orçamento, caracterizando-se como a última
prioridade a ser atendida;
A princípio todos os requisitos devem ser verificáveis. Ele será verifi-
cável se existir um processo finito que possa ser executado por uma
VERIFICÁVEL pessoa ou máquina e, principalmente, que mostre sua conformidade
com o solicitado
A mudança de todo e qualquer requisito pode ser realizada de forma
MODIFICÁVEL fácil, completa e consistente,
Permite que seja facilmente verificada sua consequência quando
ocorrer uma modificação. Há a necessidade de se fazer a rastre-
RASTREÁVEL abilidade nos dois sentidos, ou seja, verificar qual o impacto a ser
causado nos requisitos dependentes e dos quais depende
Que a especificação dos requisitos seja facilmente reutilizável, ou
REUTILIZÁVEL seja, se tivermos alguma funcionalidade a ser referenciada por um
outro requisito que não seja necessário descrevê-la novamente.
05. Durante o estágio de gerenciamento de requisitos, decide-se sobre:

• Identificação de requisitos - Cada requisito precisa ser identificado de modo único, para
que possa ser feita a referência cruzada deste com os outros requisitos e para que ele possa
ser utilizado nas avaliações de facilidade de rastreamento.
• Processo de gerenciamento de mudanças - Trata-se do conjunto de atividades que avalia
o impacto e o custo das mudanças.
• Políticas de facilidade de rastreamento - Essas políticas definem as relações entre os
requisitos e entre os requisitos e o projeto de sistema que devem ser registrados e também
como esses registros devem ser mantidos.
• Suporte de ferramentas CASE - O gerenciamento de requisitos envolve processar uma
grande quantidade de informações sobre os requisitos. As ferramentas que podem ser uti-
lizadas vão desde sistemas especializados de gerenciamento de requisitos até planilhas de
cálculo e sistemas simples de bancos de dados.
capítulo 5 • 149
Capítulo 5
01. Deixaremos aqui algumas ferramentas para modelagem de software como sugestão de
pesquisa:
• IBM Rational Requisite Pro: Um produto integrado poderoso de fácil utilização para ge-
renciamento de requisitos e de referência de utilização que promove melhor comunicação,
aprimora o trabalho em equipe e reduz o risco do projeto. Inclui ferramentas de gerenciamen-
to de requisitos, de modelagem dos negócios e de modelagem de dados.
• JUDE (Atual ASTAH) ou Java and UML Developer Environment: É uma das ferramen-
tas grátis para UML mais poderosas disponíveis atualmente. Com características que não
são encontradas nas outras ferramentas grátis, como adicionar métodos no diagrama de
sequência e a alteração se refletir no diagrama de classes.
• Umbrello UML: Umbrello UML é um programa de modelagem UML (LINUX). Permite
criar diagramas de software e outros sistemas em um formato padrão. É uma ferramenta
open-source.
• Poseidon para UML: É a ferramenta de modelagem de sistemas da empresa alemã
Gentleware AG. O Poseidon é uma evolução da ferramenta de código-aberto ArgoUML que
com mais de 350.000 instalações está entre as ferramentas de modelagem mais conhe-
cidas. Seu principal foco está na facilidade de uso que a torna simples de aprender e usar.
• DBDesigner: Editor visual para criação de banco de dados mySQL que integra criação,
modelagem, desenvolvimento e manutenção dos bancos em um ambiente simples e agradá-
vel. Comparável com produtos como Oracle’s Designer, IBM’s Relational Rose, CA Erwin. O
DBDesigner é OpenSource distribuído sobre a licença GPL.
• IBExpert: O IB Expert é um poderoso gerenciador de banco de dados que permite rea-
lizar todas as tarefas necessárias para o suporte e manutenção do banco tanto local como
remotamente. Com ele é possível administrar o banco criando tabelas, modificando campos,
índices, executando scripts SQL e outras funções. O IB Expert realiza a geração do modelo
de entidade relacionamento para bancos de dados Interbase e Firebird.
02. A UML é uma linguagem de modelagem e não um método de desenvolvimento, pois
muitas pessoas confundem isso. Não se encontra na UML a sequência de passos para se
desenvolver um software nem para se modelar. A “limitação” da UML é representar o sistema
por meio de diagramas comuns e integrados envolvendo as questões estáticas e dinâmicas
de um sistema de informação. A UML permite elaborar diversos diagramas para visualiza-
ção, especificação, construção e documentação de diversas partes do sistema em diversas
etapas do ciclo de vida. Existem vários tipos de diagramas que permitem modelar aspectos
dinâmicos do sistema através da UML.
150 • capítulo 5
03. Os atores representam usuários e outros sistemas que interagem com sistema mode-
lado. Eles são representados graficamente por um homem palito (boneco-de-palitos). Os
casos de uso mostram o comportamento do sistema, cenários que o sistema percorre em
resposta ao estímulo de um ator.
04. O diagrama de sequência normalmente está associado ao comportamento de um único
caso de uso e, também, podem representar um determinado cenário do sistema.
05. O diagrama de classes talvez seja o diagrama mais importante e usado na UML. É ele
quem modela a estrutura estática das classes de um sistema. No diagrama são mostradas
as associações entre as classes e seus tipos, a especificação das classes, especializações e
generalizações e os agrupamentos em pacotes. O interessante do diagrama de classes é que
ele pode ser implementado usando alguma linguagem de programação orientada a objetos.
Existem várias ferramentas CASE que após o desenho do diagrama de classes gera o código
em Java, C++, C#, etc.
capítulo 5 • 151
ANOTAÇÕES
152 • capítulo 5

2016 Livro Proprietario - Requisitos de Sistemas PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2016 Livro Proprietario - Requisitos de Sistemas PDF

Enviado por

Direitos autorais:

Formatos disponíveis

REQUISITOS DE

Autor do original saulo frança amui

Projeto editorial roberto paes

Coordenação de produção gladis linhares

Coordenação de produção EaD karen fernanda bortoloti

Projeto gráfico paulo vitor bastos

Diagramação bfs media

Revisão linguística amanda carla duarte aguiar

Imagem de capa alphaspirit | dreamstime.com

Dados Internacionais de Catalogação na Publicação (cip)

A529r Amui, Saulo

1. Requisitos de software. 2. Qualidade de software.

Diretoria de Ensino — Fábrica de Conhecimento

2. Processos de Ciclo de Vida e Qualidade 45

3. Análise e Especificação de Requisitos 69

5. Modelagem do Projeto - UML 119

Os requisitos de um sistema são as peças fundamentais para o desenvolvi-

• Aprender os principais conceitos de qualidade.

1.2 Conceitos de qualidade

Quando tratamos sobre qualidade, é necessário buscar os princípios que com-

• Projetos realizados acima do orçamento;

Comparando com a década de 70 percebemos que a Engenharia de Software

Qualidade de software pode ser definida como um conjunto de atributos de sof-

• Tamanho e complexidade do software;

• Correção: deve funcionar de forma correta. Satisfazendo as suas especifi-

1.2.3 Gestão da Qualidade

A gestão da qualidade de software visa assegurar o nível de qualidade que o sof-

Figura 1.1 – Processo de desenvolvimento de software.

A qualidade do software será proveniente do gerenciamento deste processo,

1.2.4 Processos de Software Sem Controle

Um processo de software sem controle resulta em processos improvisados pe-

1.2.5 Processos de Software Bem Controlados

Um processo de software bem controlado deve ser coerente com as linhas de

1.2.6 Implantação de um Programa de Qualidade

Na instalação de um programa de qualidade, é necessário que se estabeleça

• Preparação de uma política de qualidade: a iniciativa da elaboração de

O planejamento de um programa de qualidade tem as seguintes etapas:

• Estimativa da organização: medição da prática corrente, através de um

1.3 Processo de Qualidade de Software

Os modelos de qualidade normalmente são exemplificados tomando grandes empresas

O CMM é um modelo de qualidade de software bastante usado no mercado. Ele, assim

É usado para desenvolver

Figura 1.2 – ISO 9000 e o gerenciamento de qualidade.

1.4 Métricas de Qualidade de Software

• Operação do produto (usando-o): correção, confiabilidade, eficiência, in-

• Fatores (para especificar): descrevem a visão externa do software, como

Mas existem fatores subjetivos de qualidade que influenciam as notas, por-

Segundo McCall, as métricas podem estar na forma de uma lista de

• Auditabilidade: a facilidade com que se pode checar a conformidade aos

O peso dado a cada métrica de qualidade de software depende dos produtos

1.5 Garantia da qualidade de software (SQA)

• O software que foi entregue frequentemente apresenta falhas;

• A remoção de erros acontece no momento em que se é barato corrigir;

Elementos de Garantia da Qualidade de Software

(PRESSMAN, 2011, p. 389)

• American Society for Quality (ASQ) Software Division

1.6 Estatística da Garantia da Qualidade de

A garantia da qualidade de software também pode ter um componente esta-

1. Informações sobre erros e defeitos de software são coletadas e classificadas.

Estas etapas propostas e ações representam um passo importante para a

1.7 Revisões técnicas

Mesmo um pequeno subconjunto de métricas, reunidas para cada revisão

• Esforço de preparação, Ep - o esforço (em homens/hora) exigido para revisar um