Requisitos de Sistemas - Amui S.F.

Author: Amui S.F.

Tags: software requisitos de sistema tecnologia de computador

ISBN: 978-85-5548-031-7

Year: 2015

Similar

Sem Coração

Bonecas e Vestidos

Breve Manual de Lingua Russa

Moda croche 053

Text

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

1. Conceitos Gerais

Objetivos
1.1 Introdução
1.2 Conceitos de qualidade
1.2.1 Histórico
1.2.2 Conceitos
1.2.3 Gestão da Qualidade
1.2.4 Processos de Software Sem Controle
1.2.5 Processos de Software Bem Controlados
1.2.6 Implantação de um Programa de Qualidade
1.3 Processo de Qualidade de Software
1.4 Métricas de Qualidade de Software
1.5 Garantia da Qualidade de Software (SQA)
1.6 Estatística da Garantia da Qualidade de Software
1.7 Revisões técnicas
1.8 Revisões informais
1.9 Revisões Técnicas Formais

10
11
11
12
14
16
17
17
18
19
22
25
30
31
34
35

1.9.1 Diretrizes de revisão
1.10 Confiabilidade de software
Atividades
Reflexão
Referências bibliográficas

35
37
40
41
42

2. Processos de Ciclo de Vida e Qualidade
Objetivos
2.1 Introdução
2.2 Normas de qualidade de produtos de software
2.2.1 Qualidade de Produtos de Software - ISO 9126

45
46
47
48
48

2.2.2 Guias para a Avaliação da Qualidade - ISO 14598
2.2.3 Qualidade de Pacotes de Software - ISO 12119
2.2.4 A Série ISO 9000
2.3 Processos Fundamentais
2.4 Processos de apoio
2.5 Processos organizacionais
2.6 Processos de Adaptação
Atividades
Reflexão
Referências bibliográficas

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

50
52
53
60
62
63
65
66
66
67

Objetivos
3.1 Introdução
3.2 Descrição do projeto do software
3.2.1 Plano de Projeto
3.3 O entendimento das necessidades do projeto
3.4 Levantamento de Requisitos
3.4.1 Levantamento orientado a ponto de vista
3.4.2 Cenários
3.4.3 Etnografia
3.5 A especificação dos requisitos

70
71
71
75
76
78
80
84
86
87

3.5.1 Requisitos funcionais e não funcionais
3.5.1.1 Requisitos funcionais
3.5.1.2 Requisitos não-funcionais
3.6 A definição do software
Atividades
Reflexão
Referências bibliográficas

90
90
91
92
93
94
95

4. Gerenciamento de Requisitos
Objetivos
4.1 Introdução

97
98
99

4.2 Gerenciamento de Requisitos
4.3 Gerenciamento de mudanças
4.4 Rastreabilidade de requisitos
4.5 Gerência da qualidade de requisitos
4.6 Validação de requisitos
Atividades
Reflexão
Referências bibliográficas

5. Modelagem do Projeto - UML

99
103
108
110
114
115
116
117

119

Objetivos
5.1 Introdução
5.2 A modelagem do software
5.2.1 Modelagem ágil
5.3 UML (Unified Modeling Language)
5.3.1 Aplicação
5.4 Casos de Uso
5.4.1 Diagramas de Caso de Uso
5.4.2 Descrição de Casos de Uso
5.5 Diagramas de Classes
5.6 Diagrama de Objetos
5.7 Diagramas de estados

120
121
121
124
128
130
130
132
135
135
136
137

5.8 Diagramas de sequência
5.9 Diagrama de Colaboração
5.10 Diagrama de Atividade
5.11 Diagrama de Componentes
5.12 Diagrama de Execução
Atividades
Reflexão
Referências bibliográficas

137
139
139
140
141
142
142
143

Gabarito

144

Prefácio
Prezados(as) alunos(as),
Os requisitos de um sistema são as peças fundamentais para o desenvolvimento 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 gerenciamento e saber analisá-los é de extrema importância em todo o processo de
desenvolvimento de software e há uma grande necessidade das pessoas envolvidas conhecê-los muito bem.
Inicialmente, discutiremos os principais conceitos de requisitos, relacionando-os com a qualidade de software e observando suas relações com a garantia 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 relacionadas à 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 requisitos 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á associado à 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 necessidades do projeto. Com isto, o uso adequado e eficaz nos métodos de levantamento 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 gerenciar mudanças, efetuar rastreabilidade de requisitos e validação dos mesmos.

Por fim, uma vez que estes requisitos de sistemas foram devidamente levantados, 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 contribuir 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 aprendidos 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 propostos 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 desenvolvimento e a qualidade de seus requisitos são fundamentais para que isto aconteça.
Compreender bem as necessidades do cliente, suas funcionalidades, suas limitaçõ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 trataremos 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 fases inciais de um projeto e tem a utilidade de especificar o que deverá ser implementado 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 software. Deste modo, vamos estudar melhor os conceitos de qualidade para compreendermos 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 “qualidade é 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 engenharia tradicional logo, os conceitos que existem na administração e engenharia 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 empresa conseguir vender e lucrar mais, é um pré-requisito que a empresa deve conquistar para conseguir colocar o produto no Mercado Global.

1.2.1 Histórico
Quando tratamos sobre qualidade, é necessário buscar os princípios que compõ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 é multidisciplinar, 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 mundial, 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 qualidade de software provém destes estudos também.

12 •

capítulo 1

Na verdade a qualidade de software praticamente nasceu junto com a engenharia de software pois foi um momento em que era necessário estabelecer regras, 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 denominada 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 qualidade do software através da definição e normatização de processos de desenvolvimento. Por este motivo, os modelos aplicados na garantia da qualidade de
software focam no processo de desenvolvimento como forma de garantir a qualidade final do produto.
Saber os conceitos, técnicas, abordagens e demais conceitos sobre qualidade de software é um fator fundamental para saber como consegui-la.
Comparando com a administração, que toma como base as normas de qualidade da ISO, segundo a norma ISO 9000, a qualidade é o grau em que um conjunto 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 melhorada. Estas normas estabelecem requisitos para a melhoria dos processos internos,
maior capacitação dos colaboradores, monitoramento do ambiente de trabalho, verificaçã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 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 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 ponto de vista do usuário, que busca a facilidade de uso, desempenho, confiabilidade 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 qualidade do processo de desenvolvimento, mesmo que esta não garanta a qualidade 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 complementares e interdependentes. Espera-se que a qualidade do processo e fabricaçã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 processos, 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 produto 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 especificaçõ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 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;
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 software exige. A gestão da qualidade de software esta calcada na gestão do processo 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.
Definição

Análise de sistema
Análise de requisitos

Construção

Projeto
Codificação
Teste

Manutenção

Entendimento
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 pelos 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 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 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.

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, documentado 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 outras 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 produto e do processo. Além disso, é necessário que o processo seja institucionalizado, tornando-se parte da infraestrutura da organização, pois processos

capítulo 1

• 17

institucionalizados permanecem, mesmo depois que as pessoas que originalmente 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 dinamicamente 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 padrõ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 qualidade 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 entendida 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ê direciona 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 qualidade. 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 organizaçã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 versão do manual de qualidade, a equipe de melhoria da qualidade pode determinar o montante de trabalho necessário para a implementação do sistema de
qualidade e, convenientemente, elaborar cronogramas e atividades, estabelecer marcos e alocar recursos para este fim.
• Implementação de um programa cultural: para um programa de qualidade 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, procedimentos e padrões, métodos, ferramentas e recursos devem ser revistos regularmente 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 maneira 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 organizadamente 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 comum 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 suficientemente abrangentes. Interpretações e adaptações dos modelos a situações particulares devem ser ajustadas aos objetivos do negócio e serem realizadas 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 utilizados 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
ISO 9126
NBR 13596
ISO 14598
ISO 12119
IEEE P1061
ISO 12207
NBR ISO 9001

20 •

COMENTÁRIOS
Características da qualidade de produtosde software.
Versão brasileira da ISO 9126.
Guias para a avaliação de produtos de software, baseados na utilização prática
da norma ISO 9126.
Características da qualidade de pacotes de software (software de prateleira, vendido com um produto embalado).
Standard for Software Quality Metrics Methodology (produto de software).
Software Life Cycle Process. Norma para a qualidade do processo de desenvolvimento de software.
Sistemas de qualidade – Modelo para garantia de qualidade em projeto, desenvolvimento, instalação e assistência técnica (processo).

capítulo 1

NORMA
NBR ISO 9000-3
CMM
SPICE ISO 15504

COMENTÁRIOS
Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para
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
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.
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 equipe 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: Inicial, 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 especificamente 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 definição do processo deve incluir descrições da documentação necessária para
demonstrar que os processos definidos foram seguidos durante o desenvolvimento 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
qualidade da
organização

Documentos

É usado para desenvolver
Plano de qualidade Plano de qualidade Plano de qualidade
Projeto 1
Projeto 2
Projeto 3

Processo de qualidade
da organização
Conhecido
como
Gerenciamento de
qualidade do projeto

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 atributos 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 software. 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, integrabilidade 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, portanto é difícil ou até mesmo impossível desenvolver medidas diretas dos fatores de qualidade.
Sendo assim, é definido um conjunto de métricas para desenvolver expressõ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 hardware 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 é independente 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 colegas 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 qualidade 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 diversas 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 qualidade 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 verifica 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, executando monitorações e melhorias de processos de acordo com a necessidade.
Isto faz com que os padrões e procedimentos acordados estejam sendo seguidos 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 requisitos 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 quantificam a qualidade do software que está sendo entregue. Assim, a SQA não é
somente uma atividade associada de forma exclusiva às atividades de desenvolvimento 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;

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;

Controle de todos os artefatos de software e as mudanças feitas nesses produtos;

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 implementados 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 resultantes 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 seguidas 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 planejados 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 compreender 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 negativos 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 engenharia 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 fornecedores 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 software 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 software 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 automotiva 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 preocupaç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 relacionados a riscos tenham sido estabelecidos.
Além de cada uma dessas preocupações e atividades, a SQA trabalha para garantir 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 estatí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, algumas 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.

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 desenvolvimento 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 trabalho 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 importante 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 possam 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 exemplo, 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 nessa 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 relaçã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, discutir, 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 alguns aspectos orientados a revisões da programação em pares.
Devido a falta de planejamento ou preparação para estas reuniões informais, sua eficácia pode ser muito inferior em relação às reuniões com abordagens 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 estrutura adequada para condução e anotação de uma pauta, podem comprometem 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 simples para cada artefato produzido pela equipe de software. As questões levantadas na lista de verificação são genéricas, mas servirão como guia para os revisores 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 controle da qualidade de software realizada por engenheiros de software (e outros
profissionais). Neste tipo de revisão a abordagem é mais formal e exige uma estrutura em termos de planejamento e organização para que ela ocorra. Segundo 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 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.
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 planejada 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) apresenta 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

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 debatendo 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 (fornecendo 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 qualidade . 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

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 conjunto 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 software 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 estimar, diferentemente de outros fatores de qualidade. Pressman (2011, p. 395)
define a confiabilidade de software em termos estatísticos como “a probabilidade de operação sem falhas de um programa de computador em um dado ambiente 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 definição existem algumas variações, podendo ser apenas problemáticas ou catastró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 introdução de outros erros que resultarão em outras falhas.
Silva Filho (2014) ressalta um importante ponto, dizendo que a confiabilidade de software acaba se tornando uma propriedade determinante para o
produto, pois ela é observável pelos usuários, mostrando a necessidade de assegurar 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, constituem a base da Engenharia de Confiabilidade de Software (ECS), a qual é definida “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 desenvolvimento 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, arquitetura de sistema, ambiente operacional do software e suas implicações sobre a confiabilidade.
• 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 coletados 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 instante 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 diferentes técnicas como (SILVA FILHO, 2014):
• Quando os dados de falhas estão disponíveis – Por exemplo, o software encontra-se em testes ou no estágio operacional. Neste caso, as técnicas de estimação podem 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 software 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 relacionadas, 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 segundo 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

Deve realizar suas tarefas em tempo adequado à complexidade de cada um deles. E
devem utilizar de modo eficiente os recursos de hardware disponíveis.

Deve permitir expansão de suas funcionalidades para atender novos requisitos ou incorporar novas tecnologias.

Deve funcionar de forma correta. Satisfazendo as suas especificações sem falhas ou
erros.

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.

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 padrõ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á relacionada com a adoção da empresa como um todo a assumir compromissos de melhoria da qualidade 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 fornecedores 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 processos 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 nacional 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 Software 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 Magazine. Ed. 8. Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software8-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 aplicados ao software. Veremos que existem muito mais detalhes do que simplesmente documentar o sistema por meio de manuais técnicos.
Vimos no capítulo 1 o conceito de qualidade aplicada ao processo de software. 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 abordagem sobre as normas de qualidade de produtos de software e os processos fundamentais, de apoio, organizacionais e de adaptação.
Bons estudos!

OBJETIVOS
Neste capítulo teremos como objetivo:
• 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 definidos 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 algum 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 mundo 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 empresa 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 obté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 qualidade, aumentar a produtividade e diminuir os custos. Diferentes modelos são utilizados 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 conhecidos 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 implantado.
O certificado obtido normalmente tem validade por 3 anos a contar da data de auditoria 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 credenciamento 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 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”. 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.
Adeq
uaç
Acurácia ão
Interoperabilidade
Segurança
e
idad
cional
n
u
f
a
Conformidade com

Conformidade

Inteligibil
idad
e
Apreensibilid
ade
Operabilidade
Atratividade
de
bilida
com a usa

l
a bi

de
i da

Po
rt

Confi
ab
ilid
ade

abi
lida
de

Fu
a de
alid
ion
nc

Maturida
de
Tolerância e falh
as
Recuperabilidade
ilidade
Conformidade com a confiab

de
abilida
apt
Ad
e de instalação
uldad
Fac
Coexistência
Capacidade para substituir
Con
form
idade co
m a portabilidade

ute
Man

ISO 9126-1

Ef
ici
ê

ade
nibilid

bilidade
alisa
An
ificabilidade
Mod
Estabilidade
Testabilidade
Con
formi
dade co
m a manutenibilidade

m relação ao tempo
ento e
rtam
mpo
Co
lação aos recursos
Comportamento em re
Confo
rmidade com
a eficiência

Figura 2.1 – Norma ISO 9126-1. Fonte: Elaborado pelo autor.

CARACTERÍSTICA

SUBCARACTERÍSTICA
Adequação
Acurácia

Funcionalidade
(satisfaz as necessidades?)

Interoperabilidade
Conformidade
Segurança de acesso
Maturidade

Confiabilidade
(é imune a falhas?)

Tolerância a falhas
Recuperabilidade
Inteligibilidade

Usabilidade
(é fácil de usar?)

PERGUNTA CHAVE
Propõe-se a fazer o que é
apropriado?
Faz o que foi proposto de forma
correta?
Interage com os sistemas especificados?
Está de acordo com as normas,
leis, etc.?
Evita acesso não autorizado aos
dados?
Com que frequência apresenta
falhas?
Ocorrendo falhas, como ele
reage?
É capaz de recuperar dados em
caso de falha?
É fácil entender o conceito e a
aplicação?

Apreensibilidade

É fácil aprender a usar?

Operacionabilidade

É fácil de operar e controlar?

capítulo 2

• 49

Eficiência
(é rápido e enxuto?)

Tempo
Recursos
Analisabilidade

Manutenibilidade
(é fácil de modificar?)

Modificabilidade
Estabilidade
Testabilidade
Adaptabilidade

Portabilidade
(é fácil de usar em outro
ambiente?)

Capacidade de ser instalado
Conformidade
Capacidade. de substituir

Qual é o tempo de execução?
Quanto recurso usa? Durante
quanto tempo?
É fácil de encontrar uma falha,
quando ocorre?
É fácil modificar e adaptar?
Há grande risco quando se faz
alterações?
É fácil testar quando se faz
alterações?
É fácil adaptar a outros ambientes?
É fácil instalar em outros ambientes?
Está de acordo com padrões de
portabilidade?
É fácil usar para 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 subcaracterísticas de um software, ela ainda não define como dar uma nota a um software 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 valores (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 conjunto 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ásicos de certificação conforme mostra a tabela 2.2 (BARRETO JÚNIOR, 2014, p. 8):
CERTIFICAÇÃO

QUEM REALIZA?

FINALIDADE

De 1ª parte

Empresas que desenvolvem
software

Melhorar a qualidade de seu próprio
produto

De 2ª parte

Empresas que adquirem software

Determinar a qualidade do produto que
irão adquirir

De 3ª parte

Empresas que fazem certificação

Emitir documento oficial sobre a qualidade
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, relacionados 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

14598-3

Guia para Desenvolvedores

14598-4

Guia para Aquisição

14598-5

Guia para Avaliação

14598-6

Módulos de Avaliação

Como avaliar sob o ponto de vista de quem desenvolve
Como avaliar sob o ponto de vista de quem vai
adquirir
Como avaliar sob o ponto de vista de quem certifica
Detalhamento sobre como avaliar cada caracterí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ísticas, 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 requisitos de qualidade para este tipo de software, ela também destaca a necessidade 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

Definições

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, usabilidade, 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, eficiência, manutenibilidade e portabilidade.
4.

Instruções para teste
a) Pré-requisitos de teste: Lista de itens necessários ao teste, incluindo documentos incluídos no pacote, componentes do sistema e material de treinamento.
b) Atividades de teste: Instruções detalhadas sobre os procedimentos de teste, 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 especificados
• 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

ISO 9001

Modelo para garantia da qualidade em projeto, desenvolvimento, produção,
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 manutençã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 infraestrutura. 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 requisitos 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 organizaç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 “situaçã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 definidos na ISO 9000-3 (BARRETO JÚNIOR, 2014, p. 12):
GRUPO
ESTRUTURA DO SISTEMA DE QUALIDADE

ATIVIDADES DO CICLO DE VIDA

ATIVIDADES DE APOIO

ATIVIDADE
Responsabilidade do fornecedor
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
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
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 normas 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.

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

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.

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 encontra 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 conjunto 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 fornecimento 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 desenvolvimento na empresa.
Além das normas relacionadas à qualidade, existem outras normas e modelos 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 envolvem 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
Verificação

Operação

Validação

Desenvolvimento

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

Adapatação

Aquisição

PROCESSOS FUNDAMENTAIS DO CICLO DE VIDA

Fornecimento

Desenvolvimento

Operação

Manutenção

Iniciação
Preparação de pedido de proposta
Preparação e atualização do contrato
Monitoração do fornecedor
Aceitação e conclusão
Iniciação
Preparação de resposta
Contrato
Planejamento
Revisão e avaliação
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
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
Implementação do processo
Teste operacional
Operação do sistema
Suporte ao usuário
Implementação do processo
Análise do problema e da modificação
Implementação da modificação
Revisão/aceitação da manutenção
Migração
Descontinuação do software

capítulo 2

• 59

Documentação

PROCESSOS DE APOIO

Gerência de
configuração

Garantia da qualidade
Verificação
Validação
Revisão conjunta
Auditoria

PROCESSOS ORGANIZACIONAIS

Resolução de
problema

Gerência

Melhoria

Infra-estrutura

Treinamento

Implementação do processo
Projeto e desenvolvimento
Produção
Manutenção
Implementação do processo
Identificação da configuração
Controle da configuração
Relato da situação da configuração
Avaliação da configuração
Gerência da liberação e distribuição
Implementação do processo
Garantia do produto
Garantia do processo
Sistemas de garantia da qualidade
Implementação do processo
Verificação
Implementação do processo
Validação
Implementação do processo
Revisões de gerenciamento do projeto
Revisões técnicas
Implementação do processo
Auditoria
Implementação do processo
Resolução de problema
Iniciação e definição do escopo
Planejamento
Execução e controle
Revisão e avaliação
Conclusão
Estabelecimento do processo
Avaliação do processo
Melhoria do processo
Implementação do processo
Estabelecimento da infra-estrutura
Manutenção da infra-estrutura
Implementação do processo
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 qualidade 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 definidos, e assim proporcionar às organizações que a utilizam um melhor entendimento 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 adquirente e o fornecedor (aquisição e fornecimento) e a execução do desenvolvimento, 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 desenvolvimento 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 planejamento 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 execuç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́tica que satisfaça as necessidades da empresa. Define as atividades do adquirente, 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 conjunto de requisitos em um produto executável, definindo as atividades do desenvolvedor 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 atividades do operador, como a operação do produto de software e o suporte operacional 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, tratando 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 contribuem 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 documentaçã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 propriamente dito, a fim de ser possível acompanhar se os requisitos do projeto foram atendidos 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 atendimento 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̂ncia 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 serviç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 executadas 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 levantados 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 envolvido 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 contribuem 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́ fundamental a figura de gerência que exercerá acompanhamento das necessidades do projeto 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 implementam uma estrutura constituída de processo de ciclo de vida e pessoal associados, 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 gerente é 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 adequado para qualquer outro processo, incluindo hardware, software, ferramentas, um conjunto de técnicas, padrões e recursos. São utilizados no desenvolvimento, operação e manutenção do software.
• Melhoria: visa permitir que os processos sejam continuamente adaptados, 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 humanos capacitados para o melhor desempenho possível de suas funções. considerando 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 acordo 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, caracterí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 desenvolvimento 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 conhecida como SPICE, é considerada uma evolução da ISO/IEC 12207 (WAZLAWICK,
2013, p. 41).

ATIVIDADES
Vamos praticar um pouco os conceitos aprendidos. Responda às seguintes questões:
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 qualidade a ser seguida? Qual sua opinião sobre este ponto? Justifique.
04. Quais as principais normas de qualidade associadas à software utilizadas no Brasil. Explique.
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 qualidade 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 empresa para que estas normas e padrões sejam efetivadas dentro da organização, sendo necessá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 Engenharia 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

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.
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 importâ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álise 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 conceitos de requisitos de sistema e conseguiremos cada vez mais ampliar o nosso entendimento acerca da importância e de suas aplicações em projetos de
software.
Bons estudos!

OBJETIVOS
Neste capítulo teremos como objetivo:
• 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, independente da precisão com a qual um software venha a ser projetado e implementado (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, modelagem 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 cliente como o desenvolvedor, que desempenharão um papel de grande importância, 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 desenvolvimento de um software, principalmente porque ela faz a associação entre os elementos que irão constituir o software e o projeto deste. Assim, ela permite que o engenheiro de sistemas especifique as necessidades do software em
termos de funcionalidades e de desempenho, estabeleça as interfaces do software 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 engenheiros de software, analistas ou modeladores elaborem mais as necessidades básicas 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 processos de software utilizado. O projeto é iniciado assim que os requisitos de software 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 proposta para a obtenção de um contrato a fim da realização do trabalho, incluindo 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 verificar 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 previsto, 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 software. 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 traduzir 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 sistema 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́stica) 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 representaçã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 desenvolvimento 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 projeto, 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 software é fundamental na Engenharia de Software e que quando o gerenciamento é 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 desenvolvimento profissional de software e a programação em nível amador. De
acordo com Sommerville (2006, p. 60), “o gerenciamento de projetos de software é 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 imprevistos no prazo e no orçamento do projeto.
Os gerentes de software executam o mesmo tipo de trabalho que outros gerentes 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

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 projeto 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 compreendido. Nossa compreensão do processo ele software se desenvolveu significativamente
nos últimos anos. Contudo, ainda não podemos prever com certeza quando um processo 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 trabalho-padrão de um gerente de software, pois o trabalho varia muito, dependendo 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 executadas, 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 organizar, 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 produzidos 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 tomar ações corretivas visando alcançar o conjunto de metas planejadas em concordâ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 importante, 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.

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 fundamentais 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 maneira 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 sistema 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 podem 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 software. O processo de engenharia de requisitos pode ser descrito como um processo 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 desenvolvimento 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) envolve uma das principais partes do processo que terá como resultado o desenvolvimento de um software, pois é esta a atividade responsável por entender
aquilo que o cliente deseja ou necessita, ou ainda, aquilo que o cliente consegue 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, elaboração, negociação e especificação. Para estimular e encorajar uma abordagem colaborativa e orientada às equipes em relação ao levantamento de requisitos, 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, sistemas já existentes na organização, regulamentos vigentes, leis, etc, com o objetivo de entender a organização como um todo, seus processos, necessidades,
possibilidades de melhorias e as restrições existentes, preocupando-se na descoberta dos requisitos.
Existem diversas técnicas que podem ser utilizadas para o levantamento de
requisitos, como por exemplo: entrevistas; questionários; observação do ambiente 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 explicando 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 capturar 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 requisitos 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 stakeholders realmente desejam do sistema.

Especificações
dos requisitos

Validação dos
requisitos

Início do
processo

Compreensão
do domínio

Priorização

Coleta de
requisitos

Resolução de
conflitos

Documento de
requisitos

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 freqü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 sociais 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 é importante, 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, podemos 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 oferecimento 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 fontes 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 dados dizemos que eles são fontes ou drenos de dados. Neste caso a análise envolve 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 sistema são conhecidos como Frameworks de Representação. Eles podem ser comparados entre si para saber quais são os requisitos existentes usando uma única 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
Documentação dos
vista
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 recebem 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 herdados 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 consideraçã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.

EVENTOS

Referência para um conjunto de cenários de eventos descrevendo
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.

ESPECIFICAÇÃO

Referência para uma lista de especificações de serviço, que podem
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.

FORNECEDOR

Referência a uma lista de objetos do sistema que fornecem os
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 - tempestade 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 hierarquia 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 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 operacionais e captar 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, criticar e fazer sugestões tendo como consequência a reorganização dos componentes e tarefas do sistema. O interessante é que os participantes podem ter conhecimentos 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 processos 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 responde à ocorrência de um algum evento específico, tal como “iniciar uma transaçã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 é representado pela caixa com borda espessa. Assim mostra a figura 3.4.

84 •

capítulo 3

Cartão
Presente

Cartão
PIN

Cartão
Válido

Número da
conta
Número da
conta
Tempo esgotado
Devolver cartão
Cartão inválido
Devolver cartão
Cartão roubado

Validar
usuário
PIN incorreto

Usuário OK

Número da
conta
Selecionar
serviço

Informar PIN
PIN incorreto
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 exemplo acima as exceções são: tempo-esgotado, cliente não fornece PIN, cartão invá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 quando 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 independente 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 administrar 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 cadastrar novos livros no catálogo de livros.

Usuário da
biblioteca

Serviços de empréstimo

Administração de usuário

Fornecedor

Pessoal da
biblioteca

Serviços de catálogo

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, tornandose 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 tanto 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 software. Tem como objetivo descrever de maneira sistemática quais as propriedades 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 estará 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 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 (LEITE,
2000b).

capítulo 3

• 87

Sommerville (2006, p. 82) traz ainda algumas outras definições sobre requisitos, 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 ilustra 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 fornecedores 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 requisitos 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 ofertado, 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.

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).

Requisitos
do usuário

Gerentes de clientes
Usuários finais de sistemas
Engenheiros do cliente
Gerentes do fornecedor
Arquitetos de sistemas

Requisitos
do sistema

Usuários finais de sistemas
Engenheiros do cliente
Gerentes do fornecedor
Arquitetos de sistemas
Desenvolvedores de software

Especificação
de projeto
de software

Usuários finais de sistemas
Engenheiros do cliente
Gerentes do fornecedor
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 requisitos 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 explicitamente 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 oferecidos 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. 83)

Sommerville (2006, p. 84) ainda afirma que a distinção entre esses diferentes 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 sistema 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 desenvolvido. 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, trimestral, 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 formato 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 funcionais 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
RNF01
RNF02
RNF03
RNF04
RNF05
RNF06

REQUISITOS NÃO-FUNCIONAIS

TIPO

Não poderão ocorrer perdas de informações

Segurança

Visitantes anônimos não poderão ter acesso à Extranet

Segurança

Um perfil de usuários pode ter mais de um tipo de permissão

Segurança

O sistema deverá comportar com velocidade satisfatória

Desempenho

O sistema deverá ter alta disponibilidade

Confiabilidade

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 satisfeito, 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á inserido, 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 vezes é 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 modelos 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 estimativas de prazos e custos (cronograma e orçamento). Outro ponto apontado 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 software 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 completamente concluída.

ATIVIDADES
Vamos praticar um pouco os conceitos aprendidos. Responda às seguintes questões:
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 investimento 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 operacionalizado 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 gerenciamento de risco, prazo e custo.

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.

calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente.

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.

é fundamental que o software seja operacionalizado usando código aberto e emita relató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. Compreender 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 consequentemente 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 desenvolvimento 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 qualidade e o andamento do projeto, juntamente com os seus processos. O levantamento de requisitos é 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 sistemas. 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.

REFERÊNCIAS BIBLIOGRÁFICAS
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.
PRESSMAN, R. S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill, 2011. 780p.
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 totalmente 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 parte 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 requisitos, é 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 criado, 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 ambas as partes do projeto envolvendo a validação destes requisitos.
Vamos lá?!

OBJETIVOS
Neste capítulo teremos como objetivo:
• 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 baseline 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 implementaçõ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 controle 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 requisito durante o processo de levantamento de requisitos e desenvolvimento de
sistemas. É um conjunto de atividades que ajuda a equipe do projeto a identificar, 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 necessidade 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 requisitos 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 mudanças organizacionais (MEDEIROS, 2015).
Há, durante o processo de desenvolvimento e operação de software, o possí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 ocasionados 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 processo. 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 durante 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 reduzindo a probabilidade de erros e esquecimentos. “Adaptar um processo para as
necessidades internas é sempre a melhor escolha ao invés de impor um processo à organização” (MEDEIROS, 2015).
O planejamento é o primeiro estágio do processo de gerenciamento de requisitos. É um estágio dispendioso, sendo que para cada projeto há o estabelecimento 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 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 utilizadas vão desde sistemas especializados de gerenciamento de requisitos
até planilhas de cálculo e sistemas simples de bancos de dados.
(SOMMERVILLE, 2006, p. 119)

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́sito 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 ferramentas 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 relacionados. 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.
(SOMMERVILLE, 2006, p. 121)

Requisitos segundo Agilistas
[...] “a corrente agilista defende a simplificação dos requisitos, legando todo detalhamento 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 Orientada 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 liberdade é a abertura a ambiguidades, indefinições e até mesmo histórias descritas exaustivamente. 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 necessidades 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 gerenciamento de requisitos:
• http://migre.me/oIEKM
Neste outro artigo, além de abordar as normas de qualidade utilizadas em desenvolvimento 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 parte 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 requisitos tem como parte das suas atividades controlar mudanças. O CMM define mudanças como: As alterações que precisam ser feitas nos requisitos e artefatos 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 processo formalizado para gerir as mudanças é que, desta forma, todas as propostas 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 requisitos do sistema. O custo da mudança é estimado de acordo com as modificaç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 requisitos ou não.
8. Implementação de mudanças - O documento de requisitos e, se necessário, o projeto de sistema e a implementação são modificados. De modo a facilitar, 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 modulares quanto possível.

104 •

capítulo 4

Problema identificado

Análise do
problema e
especificação
da mudança

Análise e custo
da mudança

O processo de gerenciamento demanda um conjunto de tarefas que proporcionem o gerenciamento
e mapeamento entre as dependências dos requisitos e as solicitações de modificações e/ou inclusões
(SANTOS, 2004, p. 18).
Em função de possíveis divergências na percepção do projeto, podem ocorrer problemas na dificuldade, 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
solução (FAGUNDES, 2011, p. 206).

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 desenvolvedores 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 fatores 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́ suscitada 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 estar acertado e definido com os membros da equipe de desenvolvimento e usuá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, determinando quem será responsável pela sua execução e o formato em que os resultados 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 requisitos, proposto por Karl Wiegers.

Solicitante submete
solicitação de mudança

Submetida

Avaliador realiza
análise de impacto

Avaliada

Gerente decide NÃO
realizar a mudança

Rejeitada

Gerente decide
realizar mudança.
Aponta reponsável
para execução
Aprovada

Verificação
falhou

Mudança Cancelada

Responsável fez
a mudança e
pesquisa verificação
Mudança
Realizada

Mudança Cancelada

Cancelada

Verificador
confirma
mudança
Verificação não
foi necessária.
Modificador
instala produto

Verificada

Mudança Cancelada

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 dependê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 organizaç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 requisitos, 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 requisitos 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 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

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

1.2

1.3

2.1

2.2

U
R

2.3

3.1

3.2
U

R
R

U
U

U
R
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́ importante, 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 respectivos 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, classes, 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 Software 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:
CORRETA

PRECISA

COMPLETA

110 •

capítulo 4

DETALHAMENTO
Tudo o que está sendo descrito sobre os requisitos deve
realmente 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 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
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.

ESPECIFICAÇÕES:
CONSISTENTE

DETALHAMENTO
Não ter nenhum conflito ou sobreposição a outros requisitos.
Definir prioridades de acordo com a importância, estabilidade e complexidade. Dentro destes critérios, os
requisitos podem ser:

essencial: requisito sem o qual o produto não

atende às necessidades do usuário;
b)

PRIORIZADA

desejável: sua existência aumenta o valor do

produto, mas se por alguma necessidade não for
contemplado não afeta de forma substancial a utilização do produto;
c)

opcional: requisito que poderá ser incluído caso

haja disponibilidade de prazo e orçamento, caracterizando-se como a última prioridade a ser atendida;

VERIFICÁVEL
MODIFICÁVEL

RASTREÁVEL

REUTILIZÁVEL

A princípio todos os requisitos devem ser verificáveis. Ele
será verificável se existir um processo finito que possa ser
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 realizada 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
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
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 manutençã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 definidos (Á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 qualquer tenta- tiva 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 implementados, 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 problemas mais comuns são:
PROBLEMAS

Ambiguidade

Requisitos incompletos

112 •

capítulo 4

DESCRIÇÃO

EXEMPLO

Falta de clareza ou duplo sentido de frases ou expressões.
Este tipo de requisito leva a
interpretações erradas ou inconsistentes das necessidades
reais dos usuários.
Requisitos que deixam de fora
parte da informação necessária
à sua compreensão.

“O sistema deve enviar relatórios
de produtividade dos programadores, analistas ou desenvolvedores do projeto mensalmente
ou quando requisitado.”
Curva S (Planejado X Realizado)
de um projeto
Cadastro de iniciativas estratégicas

PROBLEMAS

Requisitos múltiplos

Requisitos com alternativas

DESCRIÇÃO

EXEMPLO

Estes são requisitos que concatenam vários requisitos em um
só. Estes requisitos devem ser
separados para facilitar a tarefa
de priorização e gerência de
mudanças.
São aqueles requisitos que não
estabelecem claramente qual
deve ser a ação do sistema
frente a uma dada situação. De
modo geral contém frases do
tipo mas, com exceção, apesar,
e quando.
São requisitos mal redigidos que
podem causar confusão e mal
entendidos. Um erro muito comum é o excesso de informação

No evento de falha da rede
elétrica, o sistema deve enviar
mensagem de erro ao usuário,
salvar a configuração atual do
sistema e os dados entrados,
até então.
O sistema deve mostrar o total
do pedido à medida que os
códigos dos produtos vão sendo
entrados no pedido, a não ser
que se trate de um produto
promocional.
Na improvável eventualidade de
falha no sistema de refrigeração,
o sistema deve mandar mensagem para a chave admin.

Requisitos mal escritos
Identificar e associar as intervenções que são complementares às outras

Requisitos inverificáveis

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
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 rastreá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 sistema 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 requisitos. 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ência de uma descrição de requisitos estruturada utilizando ferramentas automatizadas, entretanto poucas vezes isso é possível.
Além de realizar a validação dos requisitos é necessário revisar os requisitos. Estas revisões devem ser realizadas regularmente enquanto a definição dos
requisitos está sendo formulada. Esta tarefa deve envolver tanto o cliente quando os analistas do sistema.
Revisões podem ser feitas de forma formal ou informal e para isso é importante uma boa comunicação logo nos estágios iniciais. As revisões devem verificar 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 expectativas 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 (SOMMERVILLE, 2006, p. 50).

A não ser que sejam pequenos programas, os sistemas não devem ser testados como uma unidade isolada, ‘monolítica’. Os grandes sistemas são formados 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 incrementalmente, ou seja, o processo de teste deve evoluir em estágios, em conjunto com a implementação do sistema (SOMMERVILLE, 2006, p. 50).

ATIVIDADES
Vamos praticar um pouco os conceitos aprendidos. Responda às seguintes questões:
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 escolha 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 gerenciamentos de requisitos? Explique.

capítulo 4

• 115

REFLEXÃO
Podemos considerar que se os requisitos forem bem levantados, bem descritos e especificados, não teremos problemas quanto à mudanças futuras? Será que temos condições de desenvolver 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

REFERÊNCIAS BIBLIOGRÁFICAS
Á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-aengenharia-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-mpsbr/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.
PRESSMAN, R. S. Engenharia de Software, 7ª edição. São Paulo: McGraw-Hill, 2011. 780p.
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.
SOMMERVILLE, I. Engenharia de Software, 6ª edição. Editora Pearson do Brasil, 2003. 292p.
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 previamente 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 desenvolvimento, é de extrema importância para o sucesso do projeto.
Como modelar envolve notações gráficas, é desejável que se faça estas notaçõ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 notações e sua padronização, existem modelos que podem ser utilizados como
é o caso da UML (Unified Modeling Language), que é uma linguagem de modelagem 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 programaçã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
Neste capítulo teremos como objetivo:
• 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í durante 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 arquitetura 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 desenvolvimento 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 é ilustrada graficamente em um modelo de arquitetura de sistema, que permite ao leitor 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, mostrando 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
movimento

Sensores de
janela

Controlador
de alarme

Sintetizador
de voz

Alarme

Discador
de telefone

Figura 5.1 – Um sistema simples de alarme antifurto. Fonte: adaptado de Sommerville (2006,
p. 22).

SUBSISTEMAS

DESCRIÇÃO

Sensor de movimento
Sensor de janela
Controlador de alarme
Alarme
Sintetizador de voz
Discador de telefone

Detecta movimento nos cômodos monitorados pelo sistema.
Detecta a abertura de janelas externas do edifício.
Controla a operação do sistema.
Emite um aviso sonoro quando um intruso é detectado.
Sintetiza uma mensagem de voz dando a localização do possível intruso.
Faz as chamadas para avisar a segurança, a polícia, etc.

Tabela 5.1 – Funcionalidade de subsistemas no sistema de alarme antifurtos. Fonte: adaptado de Sommerville (2006, p. 22)

A implementação de um bom software está diretamente relacionada às atividades de modelagem, pois por meio dela constrói-se modelos para comunicar a estrutura e o comportamento desejados do sistema, visualizar e controlar
a arquitetura do mesmo e compreender melhor o sistema que está sendo elaborado (SOUZA e SOUZA, 2014).
Um sistema pode ser projetado a partir de diferentes modelos para desenvolver 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 modelos diversos, onde cada modelo será, portanto, uma abstração específica do
sistema. Os modelos podem ser voltados para a estrutura, dando ênfase à organizaçã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, particionando a complexidade do sistema para facilitar sua compreensão, e atuando 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 modelos (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 documento, está realizando uma troca importante- você está renunciando a novas funcionalidades 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 artefatos 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 metodologia 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 clientes 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 negó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́ trabalhando. 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 abordagem iterativa para a especificação, desenvolvimento e entrega de software. Esta
abordagem foi criada com o intuito de dar suporte ao desenvolvimento de aplicaçõ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;

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 envolvidos 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, organizase 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 princípios e valores de muitos desenvolvedores de software mais vividos. A pergunta 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 diferenç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 documentaç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, facilitando 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 objetivos 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 modelagem 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 popularidade 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 utilizada 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 objetos. 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 modelagem 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 necessá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ísticas 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 modelados, 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ência 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 partes do sistema em diversas etapas do ciclo de vida. São vários os tipos de diagramas 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
COMPORTAMENTO EXTERNO
DIAGRAMAS DE
COMPORTAMENTO INTERNO

Diagrama de casos de uso

Diagrama de classes

Diagrama de objetos

Diagrama de sequência

Diagrama de colaboração

DIAGRAMAS ESTRUTURAIS
Diagrama de estados

Diagrama de atividades

DIAGRAMAS DE
IMPLEMENTAÇÃO

Diagrama de componentes

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 praticamente 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 termos de diagramas orientados a objetos. Ela pode ser inclusive usada para modelar 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 modelagem, sem contribuir para a qualidade do produto final (MELLO, 2005, p. 107).
Há diversas maneiras de descrever casos de uso. Pode ser desde uma descriç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 projetos, pois nestes o trabalho tende a ser dividido em diversas equipes e a comunicaç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 linguagem 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 desenvolvido. Porém não especifica como este comportamento será implementado. “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. Baseandose no modelo de casos de uso os desenvolvedores elaboram os modelos de projeto e implementacão.
São os responsáveis pelos testes que têm o objetivo de garantir que os componentes 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 executa uma seqüência de tarefas derivadas dos casos de uso. Eles são especificados, projetados e servem de base para a construção dos casos de teste”(MARTINS, 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

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, pode-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 projetos 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 modelagem 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 distingue-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 sistema 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 relacionamentos 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 especificado pelo caso de uso destino.

Estabelecer limites

Atualizar contas

Gerente comercial

Sistema de contabilidade
Analisar riscos

<<uses>>
Avaliar negócio

<<uses>>
Fechar preços
Ator

Analista comercial
Registrar negócios
Generalização

Vendedor
<<extends>>
Negócios com
limites excedidos

Caso de uso

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 sistema (LEITE, 2000b):
• Estabeleça o contexto do sistema identificando os atores (usuários e sistemas externos) 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 dependê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 comportamento 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 requisitos. 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 escrever 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 alternativos. É 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 (computador, carro) ou abstrato (transação bancária, histórico, taxa de juros)” (TACLA, 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 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

• 135

Veja um exemplo de um diagrama de classes na figura 5.3.
Cliente
1
0..*

Possui

Contrato de
aluguel
0..*
1

Refere a
0..1

Veículo alugado
Tipo de veículo

Possui
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 nomes 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
Num_contrato: 2678
Veículo: “BMW 914”

Figura 5.4 – Diagrama de objetos.

136 •

capítulo 5

2679: contrato de aluguel
Num_contrato: 2679
Veículo: “Audi V8”

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 mostram 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 nodos 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.
No térreo

Subir (andar)

Subindo

Chegar no térreo
Chegar no andar

Indo para
o térreo
Descendo

Chegar no andar

Subir (andar)

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 representar a interação e relacionamento entre os objetos possibilitando assim visualizar 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 vertical, de cima para baixo. As mensagens enviadas por cada objeto são representadas 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.
Computador

Servidor de
impressão

Impressora

Fila

(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 utilizar uma técnica que consiste em colocar descrições de texto dos acontecimentos 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 diagrama 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 relacionamentos. 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)
1.2: Armazenar (arquivo)

Fila

1: Imprimir (arquivo)

Servidor de
impressão

(Impressora livre)
1.1: Imprimir (arquivo)

Impressora

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 informações de atividades sequenciais e ações nestas atividades. O diagrama suporta 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 diagrama 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.
(Disco cheio)
Imprimir arquivo ( )

(Espaço em disco)

Remover caixa
de mensagem

Impressora
imprimir (arquivo)

Mostrar caixa de
mensagem
“Disco cheio”
Mostrar caixa de
mensagem
“Imprimindo”

Criar arquivo
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 existem 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 pacote 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 tracejadas, 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
comunicação

Gráficos

Comm.dll

Graficos.dll

Gerenciador de
banco de
dados
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 roteador, etc., e conexões entre estes nodes e componentes que juntos compõem
toda a arquitetura física do sistema.
Cliente A:
Pentium 200
MMX

Cliente B:
Pentium 200
MMX

<<TCP/IP>>
Servidor de
aplicação:
HP/UX

SQL<<TCP/IP>>

Servidor de
banco de
dados:
ORACLE

<<TCP/IP>>

Figura 5.10 – Diagrama de execução.

capítulo 5

• 141

ATIVIDADES
Vamos praticar um pouco os conceitos aprendidos. Responda às seguintes questões:
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 software 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 projetos 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, proporcionando 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 trabalhos 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 aprendizagem.
• 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.

REFERÊNCIAS BIBLIOGRÁFICAS
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-netmagazine-101/26747>. Acesso em: 15 dez 2014.
SOMMERVILLE, I. Engenharia de Software, 6ª edição. Editora Pearson do Brasil, 2003. 292p.
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-1easy-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 revisado 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 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 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 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 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 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.
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 software, 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 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.

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, dependendo da cultura organizacional ali existente, bem como exigir um nível de maturidade (quanto a processos) para que as normas sejam implantadas com sucesso. Ter o apoio da alta gerê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 buscando 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 processos, 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 envolvidos;
• 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 operacionais 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 oferecidos 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 informaç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 comparativo 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 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 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, permite 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 internacionais (como, por exemplo, o IEEE, o CMM e o SPICE). Para tanto a especificação deve ser:

ESPECIFICAÇÕES:
CORRETA
PRECISA

COMPLETA

CONSISTENTE

148 •

capítulo 5

DETALHAMENTO:
Tudo o que está sendo descrito sobre os requisitos deve realmente
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
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 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
Não ter nenhum conflito ou sobreposição a outros requisitos

PRIORIZADA

VERIFICÁVEL
MODIFICÁVEL
RASTREÁVEL

REUTILIZÁVEL

Definir prioridades de acordo com a importância, estabilidade e complexidade. Dentro destes critérios, os requisitos podem ser:
- essencial: requisito sem o qual o produto não atende às necessidades do usuário;
- desejável: sua existência aumenta o valor do produto, mas se por
alguma necessidade não for contemplado não afeta de forma substancial a utilização do produto;
- opcional: requisito que poderá ser incluído caso haja disponibilidade 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́ verificável se existir um processo finito que possa ser 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 realizada 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 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 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 utilizadas 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 gerenciamento 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 gerenciamento de requisitos, de modelagem dos negócios e de modelagem de dados.
• JUDE (Atual ASTAH) ou Java and UML Developer Environment: É uma das ferramentas 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 conhecidas. 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 realizar 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 modelado. 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