Livro Proprietario - Requisitos de Sistemas

REQUISITOS DE
SISTEMA
autor
SAULO FRANA AMUI
1 edio
SESES
rio de janeiro 2015
Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza.
Autor do original saulo frana amui
Projeto editorial roberto paes
Coordenao de produo gladis linhares
Coordenao de produo EaD karen fernanda bortoloti
Projeto grfico paulo vitor bastos
Diagramao bfs media
Reviso lingustica 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 (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2015.
Dados Internacionais de Catalogao na Publicao (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. Gesto de requisitos. I. SESES. II. Estcio.

cdd 005.1
Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio
Prefcio 7
1. Conceitos Gerais
Objetivos 10
1.1Introduo
11
1.2 Conceitos de qualidade
11
1.2.1Histrico
12
1.2.2Conceitos
14
1.2.3 Gesto da Qualidade
16
1.2.4 Processos de Software Sem Controle
17
1.2.5 Processos de Software Bem Controlados
17
1.2.6 Implantao de um Programa de Qualidade
18
1.3 Processo de Qualidade de Software
19
1.4 Mtricas de Qualidade de Software
22
1.5 Garantia da Qualidade de Software (SQA)
25
1.6 Estatstica da Garantia da Qualidade de Software
30
1.7 Revises tcnicas
31
1.8 Revises informais
34
1.9 Revises Tcnicas Formais
35
1.9.1 Diretrizes de reviso
35
1.10 Confiabilidade de software
37
Atividades 40
Reflexo 41
Referncias bibliogrficas
42
2. Processos de Ciclo de Vida e Qualidade
45
Objetivos 46
2.1Introduo
47
2.2 Normas de qualidade de produtos de software
48
2.2.1 Qualidade de Produtos de Software - ISO 9126
48
2.2.2 Guias para a Avaliao da Qualidade - ISO 14598

50
2.2.3 Qualidade de Pacotes de Software - ISO 12119
52
2.2.4 A Srie ISO 9000
53
2.3 Processos Fundamentais
60
2.4 Processos de apoio
62
2.5 Processos organizacionais
63
2.6 Processos de Adaptao
65
Atividades 66
Reflexo 66
67
3. Anlise e Especificao de Requisitos
69
Objetivos 70
3.1Introduo
71
3.2 Descrio do projeto do software
71
3.2.1 Plano de Projeto
75
3.3 O entendimento das necessidades do projeto
76
3.4 Levantamento de Requisitos
78
3.4.1 Levantamento orientado a ponto de vista
80
3.4.2Cenrios
84
3.4.3Etnografia
86
3.5 A especificao dos requisitos
87
3.5.1 Requisitos funcionais e no funcionais
90
3.5.1.1 Requisitos funcionais
90
3.5.1.2 Requisitos no-funcionais
91
3.6 A definio do software
92
Atividades 93
Reflexo 94
95
4. Gerenciamento de Requisitos
97
Objetivos 98
4.1Introduo
99
4.2 Gerenciamento de Requisitos

99
4.3 Gerenciamento de mudanas
103
4.4 Rastreabilidade de requisitos
108
4.5 Gerncia da qualidade de requisitos
110
4.6 Validao de requisitos
114
Atividades 115
Reflexo 116
117
5. Modelagem do Projeto - UML
119
Objetivos 120
5.1Introduo
121
5.2 A modelagem do software
121
5.2.1 Modelagem gil
124
5.3 UML (Unified Modeling Language)
128
5.3.1Aplicao
130
5.4 Casos de Uso
130
5.4.1 Diagramas de Caso de Uso
132
5.4.2 Descrio de Casos de Uso
135
5.5 Diagramas de Classes
135
5.6 Diagrama de Objetos
136
5.7 Diagramas de estados
137
5.8 Diagramas de sequncia
137
5.9 Diagrama de Colaborao
139
5.10 Diagrama de Atividade
139
5.11 Diagrama de Componentes
140
5.12 Diagrama de Execuo
141
Atividades 142
Reflexo 142
143
Gabarito 144
Prefcio
Prezados(as) alunos(as),
Os requisitos de um sistema so as peas 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, padres, aspectos de seu gerenciamento e saber analis-los de extrema importncia 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 relaes com a garantia da qualidade, bem como a importncia das revises tcnicas, tanto formais
quanto s informais. Veremos como que este conjunto de associaes esto relacionadas confiabilidade do software.
O uso de normas de qualidade, por meio de institutos e rgos responsveis
por normatizar certos processos e itens de verificao, muito contribuem para
o avano da maturidade das empresas, devido busca constante de melhorias
e por atenderem a padres internacionais que visam a qualidade. Alm destes
pontos, algumas normas ainda trazem uma relao direta com os processos da
organizao, separando-as em nveis de maturidade, o que favorece a atuao
ou o foco em reas chaves para irem sendo incorporadas a cada estgio. Os requisitos de sistemas vo sendo cada vez mais bem estruturados por meio de
documentos adequados e completos para a organizao.
Um dos principais pontos para o desenvolvimento de um software est associado anlise e especificao de requisitos, alm de uma completa descrio
do projeto do software que est sendo proposta, compreendendo bem as necessidades do projeto. Com isto, o uso adequado e eficaz nos mtodos de levantamento de requisitos bem como sua especificao, tornam-se fatores essenciais
para um bom desenvolvimento.
Veremos ainda que os requisitos de sistemas sofrem mudanas e por isto
necessrio o uso de um gerenciamento de requisitos, para que seja capaz de gerenciar mudanas, efetuar rastreabilidade de requisitos e validao 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 tcnicas e ferramentas que iro contribuir para o desenho do software, modelando-o e expressando algumas situaes funcionais, comportamentais por meio de diagramase outras formas de
notao visual.
Aproveite a leitura e os estudos para tentar transportar os conceitos aprendidos em sua vida prtica, ou tentando observ-los em uso em empresas e nos
ambientes adequados.
Bons estudos!
1
Conceitos Gerais
Neste primeiro captulo comearemos tratando de um assunto de extrema

importncia 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, revises
tcnicas e confiabilidade.
Requisitos de software eram conhecidos antigamente como as funes que
um sistema oferecia. Atualmente, requisitos de software tratado com maior
abrangncia do que simplesmente suas funes, envolvendo pontos como os
objetivos, propriedades, padres, restries, especificaes e tudo aquilo que
for necessrio 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 restrio em seu desenvolvimento.
Para se ter um software de qualidade, os seus processos de desenvolvimento e a qualidade de seus requisitos so fundamentais para que isto acontea.
Compreender bem as necessidades do cliente, suas funcionalidades, suas limitaes e todos os aspectos associados estes requisitos, tambm contribuem
fortemente para um produto final de qualidade.
Veremos a importncia das revises tcnicas neste processo e tambm 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 captulo teremos como objetivo:
Aprender os principais conceitos de qualidade.
Conhecer a garantia da qualidade de software
Aprender sobre revises tcnicas.
Discutir sobre os aspectos relacionados confiabilidade de software.
10
captulo 1
1.1 Introduo
Requisitos so fundamentais para projetos de desenvolvimento de software,
uma vez que documenta as definio de uma propriedade ou comportamento
esperado de um produto ou servio.
De acordo com Dorfman e Thayer, requisitos podem ser definidos como
uma capacidade de software que o usurio necessita de modo a resolver um
problema ou alcanar um objetivo. Uma outra definio tambm 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, padro, especificao ou outra formalidade imposta.
Os requisitos definem caractersticas, atributos, qualidade ou habilidades
que um sistema, ou parte deste, deve constar para atender as necessidades dos
usurios.
Segundo Ian Sommerville, os requisitos so geralmente definidos nas fases inciais de um projeto e tem a utilidade de especificar o que dever ser implementado na fase de codificao ou desenvolvimento, propriamente dita,
podendo descrever uma facilidade encontrada do ponto de vista do usurio,
qualquer propriedade ou restrio geral do sistema ou ainda uma restrio ao
desenvolvimento do sistema (SAYO e BREITMAN, 2014).
Um ponto bem importante de ser observado relao 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 relaes com os processos de desenvolvimento de software
e a importncia dos requisitos neste contexto.
1.2 Conceitos de qualidade

Qualidade uma palavra muito difcil de ser definida, no ?
O que bom para um pode ser ruim para outros, o bonito para uma pessoa
pode ser feio ou no to bonito para outros e enfim, chega a ser uma questo
pessoal sobre o que ter qualidade.
Se perguntarmos para um empresrio que trabalha na administrao de
uma manufatura ele ter uma definio na ponta da lngua a qual diz que qualidade estar em conformidade com as exigncias dos clientes. Esta uma
captulo 1
11
definio muito usada na rea da administrao e baseada na viso da operao, na rea de engenharia de produo.
Segundo Slack et al. (1996), a definio de Qualidade bem mais ampla
e obedece a cinco categorias ou abordagens: Abordagem Transcendental,
Baseada em Manufatura, Baseada no Usurio, Baseada em Produto e Baseada
em Valor. Como percebemos, um assunto bastante vasto!
Mas a engenharia de software, lembrando, uma rea que provm da engenharia tradicional logo, os conceitos que existem na administrao e engenharia de produo sero aplicados tambm 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
usurios. Como podemos ver, o conceito aplicado ao software parecido com o
encontrado na administrao e engenharia tradicional.
Portanto, qualidade no 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 Histrico
Quando tratamos sobre qualidade, necessrio buscar os princpios que compem esta rea de estudo.
Nas empresas em geral, a palavra qualidade est relacionada com uma
tcnica de administrao chamada Qualidade Total. Esta tcnica multidisciplinar, ou seja, envolve vrias reas administrativas simultaneamente e em
conjunto com o objetivo de obter melhores bens e servios 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 aps o fim da segunda guerra mundial, momento no qual as indstrias precisavam repor as baixas em vrias reas.
Estes estudos buscavam conceber um modelo para aumentar a eficincia,
racionalizar os mtodos de trabalho, a crena no homem econmico, a diviso
e a hierarquizao do trabalho, a relevncia da organizao formal.
Baseado nestes objetivos, podemos notar que so os mesmos que qualquer
empresa de software ou relacionada com software deseja. Sendo assim, a qualidade de software provm destes estudos tambm.
12
captulo 1
Na verdade a qualidade de software praticamente nasceu junto com a engenharia de software pois foi um momento em que era necessrio estabelecer regras, prticas e processos para o desenvolvimento de melhores softwares. Logo,
um conceito contemporneo engenharia de software.
A Engenharia de Software, iniciou-se na dcada de 70 quando especialistas
em computao de vrios pases se reuniram para discutir os problemas de
desenvolvimento de software da poca. Durante esta conferncia 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 conferncia estavam:
Projetos realizados acima do oramento;
Projetos finalizados acima do tempo esperado;
Produtos de software de baixa qualidade;
Produtos de software sem atender aos requisitos do cliente;
Projetos ingerenciveis e com cdigo difcil de se manter.
Comparando com a dcada de 70 percebemos que a Engenharia de Software
evoluiu bastante. Muitos mtodos, tcnicas e teorias com o objetivo de resolver
(ou tentar) os problemas tratados na conferncia foram desenvolvidos.
A maioria destas evolues 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 histria uma subrea que tem ganhado foras 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 includa nas preocupaes das demais subreas.
Esta rea de conhecimento tem como objetivo principal garantir a qualidade do software atravs da definio e normatizao 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, tcnicas, abordagens e demais conceitos sobre qualidade de software um fator fundamental para saber como consegui-la.
Comparando com a administrao, que toma como base as normas de qualidade da ISO, segundo a norma ISO 9000, a qualidade o grau em que um conjunto de caractersticas inerentes a um produto, processo ou sistema cumpre
os requisitos inicialmente estipulados para estes.
captulo 1
13
A ISO (International Organization for Standardization Organizao Internacional para

Padronizao) 9000 na verdade um grupo de normas tcnicas que estabelecem
um modelo de gesto da qualidade para qualquer tipo de organizao, de qualquer
tamanho. A ISSO foi fundada em 1947 e possui como funo a promoo de normas
de produtos e servios, para que a qualidade dos mesmos seja permanentemente melhorada. Estas normas estabelecem requisitos para a melhoria dos processos internos,
maior capacitao dos colaboradores, monitoramento do ambiente de trabalho, verificao da satisfao dos clientes, colaboradores e fornecedores, num processo contnuo de melhoria do sistema de gesto da qualidade. O uso das normas ISO vantajosa
para as organizaes uma vez que lhes confere maior organizao, 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 usurios. A determinao dos atributos relevantes a cada sistema depende
do domnio da aplicao, das tecnologias utilizadas, das caractersticas especficas do projeto e das necessidades do usurio e da organizao.
Vrios fatores afetam a percepo da qualidade do desenvolvimento e do
software, entre eles podemos destacar:
Tamanho e complexidade do software;
Numero de pessoas envolvidas;
Mtodos tcnicas e ferramentas utilizadas;
Custo x Benefcio do sistema;
Custo associado aos erros;
A qualidade pode ser vista por vrios pontos de vista diferentes, como o ponto de vista do usurio, que busca a facilidade de uso, desempenho, confiabilidade e preo, entre outros. Ponto de vista do desenvolvedor que espera que
software tenha baixa taxa de erros, facilidade de manuteno e conformidade
com os requisitos, entre outros. E da organizao que deseja que o software seja
desenvolvido dentro dos prazos propostos e viveis para ela, que tenha uma boa
previso de custos e boa produtividade depois de implantado.
14
captulo 1
Para que tenhamos a qualidade total do software precisamos garantir a qualidade do processo de desenvolvimento, mesmo que esta no garanta a qualidade do produto final, mas um indicativo que a organizao capaz de produzir
bons produtos.
As duas vertentes - qualidade de produto e qualidade de processo - so complementares e interdependentes. Espera-se que a qualidade do processo e fabricao tenha um impacto positivo sobre o software obtido. Entretanto, tal
objetivo ser atingido se houver uma compreenso clara de que os processos
devem fornecer todos os mecanismos necessrios para especificar o produto e
controlar a fabricao.
Sendo assim, para alcanar a qualidade, utiliza-se de melhoria de processos, implementada atravs de modelos abstratos ou formais que permitem aos
engenheiros especificar, projetar, implementar e manter sistemas de software,
avaliando e garantindo suas qualidades. Alm disto, deve oferecer mecanismos
para se planejar e gerenciar o processo de desenvolvimento.
A implantao 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 satisfao dos clientes e da prpria empresa.
Para que um software seja considerado de qualidade, necessrio que
este tenha conformidade com alguns conceitos:
Correo: deve funcionar de forma correta. Satisfazendo as suas especificaes sem falhas ou erros;
Integridade: suas especificaes satisfazem os requisitos dos usurios e
da organizao;
Flexibilidade: deve prever que o usurio pode agir de forma no esperada
e deve ser capaz de resistir a eventuais situaes sem falhas;
Confiabilidade: deve se comportar como esperado e no falhar em situaes inesperadas;
Eficincia: deve realizar suas tarefas em tempo adequado complexidade
de cada um deles. E devem utilizar de modo eficiente os recursos de hardware
disponveis;
Reusabilidade: os componentes do software devem permitir ser reutilizados em outras aplicaes;
Usabilidade: deve ser fcil de aprender e de usar, permitindo maior produtividade do usurio, flexibilidade de utilizao e aplicao e proporcionar
satisfao ao usurio;
captulo 1
15
Manutenibilidade: deve permitir fcil manuteno para que correes ou

atualizaes sejam realizadas de modo fcil e eficiente;
Evolutibilidade: deve permitir expanso de suas funcionalidades para
atender novos requisitos ou incorporar novas tecnologias;
Portabilidade: deve poder ser executado no maior nmero possvel de
equipamentos;
Interoperabilidade: deve ser capaz de interagir com diferentes sistemas
e plataformas.
1.2.3 Gesto da Qualidade

A gesto da qualidade de software visa assegurar o nvel de qualidade que o software exige. A gesto da qualidade de software esta calcada na gesto do processo de desenvolvimento de software.
O processo de desenvolvimento de software composto basicamente de
trs etapas bsicas de acordo com a figura 1.1.
Definio
Anlise de sistema
Anlise de requisitos
Construo
Projeto
Codificao
Teste
Manuteno
Entendimento
Modificao
Revalidao
Figura 1.1 Processo de desenvolvimento de software.
A qualidade do software ser proveniente do gerenciamento deste processo,

atravs do controle eficaz de suas atividades. Inclui-se tambm no processo de
gerenciamento o controle e treinamento de pessoal, procedimentos e utilizao de ferramentas, obtendo desta forma um processo de software muito bem
definido.
16
captulo 1
O controle do processo consiste na competncia em controlar o processo de

software e influencia na capacidade da organizao 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 gerncia. No rigorosamente seguido e o cumprimento
das metas no controlado. O processo passa a ser altamente dependente da
qualidade e experincia dos profissionais envolvidos.
E diminui a viso de progresso e qualidade do processo.
A qualidade do produto fica comprometida e os prazos dificilmente so
cumpridos. Possui alto risco quando necessria a utilizao de novas tecnologias, por depender diretamente da experincia dos profissionais. Alm de tornar muito difcil prever a qualidade final do produto.
O processo passa a ser constantemente reativo a situaes inesperadas e
problemas ao invs de ser pr-ativas, no havendo tempo para melhorias. De
forma geral, o fogo esta sob controle, mas esta quase sempre apagando incndios, 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
ao para que o trabalho seja efetivamente concludo. 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 situaes mais complicadas em que aparentemente possam
tornar as atividades mais complexas.
Desta forma ser visvel o apoio da alta administrao e at mesmo de outras gerncias.
Um processo bem controlado precisa de fidelidade ao processo e deve
ser objeto de auditoria constante. Para tal so utilizadas medies do produto e do processo. Alm disso, necessrio que o processo seja institucionalizado, tornando-se parte da infraestrutura da organizao, pois processos
captulo 1
17
institucionalizados permanecem, mesmo depois que as pessoas que originalmente os definiram deixam a organizao ou o processo. Ficando a cargo da
cultura organizacional transmitir o processo adiante.
1.2.6 Implantao de um Programa de Qualidade

Na instalao de um programa de qualidade, necessrio que se estabelea
uma anistia geral, ou seja, o que aconteceu at aquele momento, no culpa de
ningum. A principal meta enfrentar os problemas existentes, em benefcio
de todos. Contudo, os seguintes aspectos devem ser contnua e dinamicamente avaliados e melhorados: a estratgia geral da empresa, o planejamento, e os
meios disponveis com vistas ao estabelecimento de condies favorveis, para
se alcanar os objetivos almejados.
Um programa de melhoria da qualidade leva ao estabelecimento de um
sistema de qualidade, que deve envolver aspectos tcnicos e culturais, que so
igualmente importantes. O aspecto tcnico envolve o desenvolvimento de padres e procedimentos para implementar a qualidade em todas as atividades.
O aspecto cultural est diretamente relacionado com a aceitao da qualidade
por todos os indivduos da organizao. Para se iniciar um programa de qualidade pode-se seguir as seguintes etapas:
Preparao de uma poltica de qualidade: a iniciativa da elaborao de
um programa de qualidade deve advir do topo da gerncia, formulando uma
poltica de qualidade, a ser publicada e comunicada de tal forma que seja entendida e implementada em todos os nveis da organizao.
Estabelecimento de um suporte qualidade: criao de um comit de
conduo da qualidade e uma equipe de melhoria da qualidade. O comit direciona as estratgias, estabelece a equipe de melhoria da qualidade, autoriza e
aprova o oramento, e fornece suporte de alto nvel para o programa de qualidade. A equipe de melhoria da qualidade estima as necessidades da organizao,
e projeta, planeja e monitora o sistema de qualidade.
O planejamento de um programa de qualidade tem as seguintes etapas:
Estimativa da organizao: medio da prtica corrente, atravs de um
padro apropriado, onde a organizao seleciona o ndice que melhor lhe
satisfaa.
18
captulo 1
Projeto do sistema de qualidade: os resultados da estimativa da organizao so analisados, os objetivos de seu sistema de qualidade so definidos e,
ento, a equipe de melhoria da qualidade projeta-o, gerando a primeira verso
do manual de qualidade.
Plano de implementao do programa de qualidade: com a primeira verso do manual de qualidade, a equipe de melhoria da qualidade pode determinar o montante de trabalho necessrio para a implementao do sistema de
qualidade e, convenientemente, elaborar cronogramas e atividades, estabelecer marcos e alocar recursos para este fim.
Implementao de um programa cultural: para um programa de qualidade ter sucesso necessrio o suporte de toda a organizao e, para isto, um
programa cultural deve ser cuidadosamente planejado e implementado desde
cedo, para a formao de conscincias voltadas para a qualidade, e encorajar a
participao de todos.
Implementao do programa tcnico: envolve a adoo de um ciclo de
vida, o desenvolvimento de procedimentos e padres, a seleo e implementao de mtodos e ferramentas, a definio e implementao de um programa
de medio, e o treinamento.
Reviso e avaliao: componentes do sistema de qualidade, procedimentos e padres, mtodos, ferramentas e recursos devem ser revistos regularmente e devem ser tomadas aes para assegurar sua contnua efetividade.
1.3 Processo de Qualidade de Software

Um processo de software consiste de uma srie de atividades que garantem,
tcnica e administrativamente, que o software pode ser desenvolvido de maneira organizada, disciplinada e previsvel.
Uma das maiores dificuldades encontradas pelas empresas de software o
gerenciamento de seus processos de software, para tal so 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 obteno segura de
um produto de software.
A escolha de um modelo apropriado importante para poder ir de encontro
s metas da organizao e saber o grau em que esse modelo ser implementado.
captulo 1
19
Um modelo de processo ao ser usado, estabelecida uma linguagem comum a todos a qual facilita a comunicao e o entendimento entre todos. Uma
estrutura oferecida para se priorizar as aes e auxilia-se nas comparaes
com diversas comunidades diferentes.
Por outro lado os modelos so simplificaes do mundo real no sendo suficientemente abrangentes. Interpretaes e adaptaes dos modelos a situaes particulares devem ser ajustadas aos objetivos do negcio e serem realizadas com muito cuidado e estudo. E necessrio muito bom senso para se
utilizar modelos corretamente e com viso de negcio.
Existem diversos modelos de qualidade de software que podem ser utilizados de acordo com os objetivos e organizao da empresa. Estes modelos sero
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 so exemplificados tomando grandes empresas
como clientes. Porm existem alguns modelos especficos 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 introdutrio ao PSP. Em ingls
http://campus.fortunecity.com/princeton/117/psp/psp.htm. Este artigo traz alguns
dos principais conceitos e tcnicas 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
COMENTRIOS
Caractersticas da qualidade de produtosde software.
Verso brasileira da ISO 9126.
Guias para a avaliao de produtos de software, baseados na utilizao prtica
da norma ISO 9126.
Caractersticas 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, instalao e assistncia tcnica (processo).
captulo 1
NORMA
NBR ISO 9000-3
CMM
SPICE ISO 15504
COMENTRIOS
Gesto de qualidade e garantia de qualidade. Aplicao 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 avaliao da qualidade do processo
de desenvolvimento de software. No uma norma ISO, mas muito bem aceita
no mercado.
Projeto da ISO/IEC para avaliao de processo de desenvolvimento de software.
Ainda no uma norma oficial ISO, mas o processo est em andamento.
Tabela 1.1 Modelos de qualidade. Fonte: adaptado de BARRETO JNIOR (2014, p. 1).
O CMM um modelo de qualidade de software bastante usado no mercado. Ele, assim

como outros modelos, quantifica o nvel de maturidade na qual uma determinada equipe ou organizao possui em relao ao desenvolvimento de software.
O CMM em especial divide as organizaes em cinco nveis de maturidade: Inicial, Repetvel, Definido, Gerenciado e Otimizado. O objetivo do CMM fazer com que
a organizao atinja nveis de excelncia na produo de software. Alm disso, por
meio desta classificao de maturidade, muitos clientes usam estes nveis como forma
de pr-requisito para que um determinado fornecedor de software possua para poder
prestar o servio.
Como mostrado na tabela 1.1, no existe uma norma ISO 9000 especificamente para o software porm ela estabelece princpios gerais que podem ser
aplicados ao software.
A ISO 9000 descreve vrios aspectos do processo de qualidade e exibe os
padres e procedimentos organizacionais que a empresa deve definir. Eles
devem ser documentados em um manual de qualidade da organizao. A definio do processo deve incluir descries da documentao necessria para
demonstrar que os processos definidos foram seguidos durante o desenvolvimento do produto.
Porm, 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.
captulo 1
21
Modelos de
Qualidade ISO 9000
usado para desenvolver
Manual de
qualidade da
organizao
Documentos
usado para desenvolver

Plano de qualidade Plano de qualidade Plano de qualidade
Projeto 1
Projeto 2
Projeto 3
Processo de qualidade
da organizao
Conhecido
como
Gerenciamento de
qualidade do projeto
Figura 1.2 ISO 9000 e o gerenciamento de qualidade.
1.4 Mtricas de Qualidade de Software

Um projeto de software um processo de tomada de deciso, onde mtricas
podem ser usadas para fornecer uma base de identificao de procedimentos,
que no estejam em conformidade com os alvos pretendidos, e medidas de atributos de projeto, alm de auxiliar na elaborao de novas solues, que levem
melhoria da qualidade.
Em 1977, McCall props um modelo para avaliao da qualidade de software. Esse modelo envolve um conjunto de fatores que avalia o software de trs
pontos de vista distintos, que englobam todos os conceitos de qualidade.
Operao do produto (usando-o): correo, confiabilidade, eficincia, integrabilidade e usabilidade.
Reviso do produto (mudando-o): manutenibilidade, flexibilidade e
evolutibilidade
Transio do produto (mudando-o para que funcione em um ambiente
diferente): portabilidade, reusabilidade e interoperabilidade.
22
captulo 1
O modelo de McCall esta organizado em trs nveis:

Fatores (para especificar): descrevem a viso externa do software, como
visto pelo usurio.
Critrios (para construir): descrevem a viso interna do software, ou seja,
como vista por quem est desenvolvendo.
Mtricas (para controlar): composta por escalas e medidas para avaliar
(com notas de 0 a 10, sim/no, Proporo)
Mas existem fatores subjetivos de qualidade que influenciam as notas, portanto difcil ou at mesmo impossvel desenvolver medidas diretas dos fatores de qualidade.
Sendo assim, definido um conjunto de mtricas para desenvolver expresses que podero 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 mtrica m
mn: mtricas que afetam o fator de qualidade
Segundo McCall, as mtricas podem estar na forma de uma lista de
conferncia (checklist), que usada para graduar atributos especficos
do software. O esquema de graduao proposto por McCall uma escala
de 0 (baixo) a 10 (elevado). As seguintes mtricas so usadas no esquema de
graduao.
Auditabilidade: a facilidade com que se pode checar a conformidade aos
padres.
Acurcia: a preciso das computaes e do controle.
Comunidade de comunicao (Communication Commonality): o grau
em que interfaces padres, protocolos e larguras de banda (bandwidths) so
usados.
Inteireza: o quanto a implementao total da funo requerida foi
conseguida.
captulo 1
23
Conciso: a compactao do programa em termos de linhas de cdigo.

Consistncia: o uso de tcnicas de projeto e documentao uniformes ao
longo do projeto de desenvolvimento de software.
Comunidade de dados (Data Commonality): o uso de estruturas e tipos
de dados padres ao longo do programa.
Tolerncia a erros: o dano que ocorre quando o programa encontra um erro.
Eficincia de execuo: 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 aplicao em potencial de componentes do
programa.
Independncia de hardware: o quanto o software desvinculado do hardware em que opera.
Instrumentao: o quanto o programa monitora sua prpria operao e
identifica erros que venham a ocorrer.
Modularidade: a independncia funcional dos componentes do
programa.
Operabilidade: a facilidade de operao de um programa.
Segurana: a disponibilidade de mecanismos que controlem ou protejam
programas e dados.
Auto-documentao: o quanto o cdigo-fonte apresenta documentao
significativa.
Simplicidade: o quanto um programa pode ser entendido sem dificuldade.
Independncia do software bsico: o quanto um programa independente de particularidades no-padronizadas de linguagens de programao
no padro, das caractersticas de sistemas operacionais e de outras situaes
ambientais.
Rastreabilidade: a capacidade de rastrear uma representao de projeto
ou componente de programa at os requisitos.
Treinamento: o quanto o software auxilia no sentido de ajudar novos usurios a aplicarem o sistema.
O peso dado a cada mtrica de qualidade de software depende dos produtos
e preocupaes locais. Os fatores de qualidade descritos por McCall e seus colegas representam uma dentre uma srie de listas de conferncia sugeridas
para a qualidade de software.
24
captulo 1
Existem algumas ferramentas que podem auxiliar uma equipe nas questes 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 pgina contm 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 propsito de gerar confiana para o cliente e para a
administrao da organizao de que os requisitos da qualidade especificados
sero atingidos, e de acordo com a ISO 8402, como o conjunto de atividades
planejadas e sistemticas, implementadas no sistema da qualidade e
demonstradas como necessrias, para prover confiana adequada de que uma
entidade atender os requisitos para a qualidade (RAPCHAN, 2011, p. 5).
As normas bsicas para Garantia da Qualidade so: 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 medies de controle da qualidade para garantir
que sejam usados os padres de qualidade e definies operacionais (mtricas)
apropriados. (MARSHALL, 2006, p.175). Este processo proporciona a melhoria
contnua de todos os processos da qualidade, com o propsito de reduzir os
desperdcios e as atividades sem valores agregados, o que contribui para que
os processos sejam operados com mais eficincia e eficcia. A auditoria verifica se todas as atividades esto de acordo com a poltica, os processos e os
procedimentos (PMBOK, 2004, p.189) que foram previamente estabelecidas
pela organizao, objetivando registrar as conformidades e no conformidades
e recomendar as aes corretivas e/ou preventivas que forem necessrias.
captulo 1
25
Desta forma, todo o esforo a ser empregado para efetuar correes do

problema deve ter como resultado uma reduo no custo da qualidade e uma
maior aceitao 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 monitoraes e melhorias de processos de acordo com a necessidade.
Isto faz com que os padres e procedimentos acordados estejam sendo seguidos e garantindo que problemas sejam encontrados e que as aes corretivas
tambm sejam aplicadas adequadamente. Esse tipo de ao tem uma orientao preventiva. O IEEE 610.12-1990 cita qualidade de software como (1) Um
padro planejado e sistemtico de todas as aes necessrias para fornecer
confiana adequada que um item ou produto est em conformidade com os requisitos tcnicos estabelecidos. (2) Um conjunto de atividades projetadas para
avaliar o processo pelo qual produtos so desenvolvidos ou manufaturados
(MARTINHO, 2008).
Segundo Martinho (2008), a SQA pode tambm ser entendida e formada por
um grupo de pessoas que esto relacionadas e empregadas atravs 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 no
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;
2.
Tarefas especificas de garantia da qualidade e controle da qualidade (inclusive
revisoes tecnicas e uma estrategia de testes multiescalonados);

3.
Pratica efetiva de engenharia de software (metodos e ferramentas;
4.
Controle de todos os artefatos de software e as mudancas feitas nesses produtos;
5.
Um procedimento para garantir a conformidade com os padroes de desenvolvi-
mento de software (quando aplicaveis) e;

6.
Mecanismos de medicao e de relatorios.

(PRESSMAN, 2011, p. 388)
26
captulo 1
No entanto, empresas que no possuem o grupo ou processos de SQA tem

uma tendncia a apresentar os seguintes indicadores de falta de qualidade,
conforme Lewis (2004) (MARTINHO, 2008):
O software que foi entregue frequentemente apresenta falhas;
Inaceitveis consequncias de falhas de sistemas, desde financeiras at cenrios
reais de aplicao;
Sistemas no esto frequentemente disponveis para uso pretendido;
Sistemas so frequentemente muito caros;
Custo de detectar e remover defeitos so excessivos.
Por outro lado, empresas que possuem o grupo ou processo de SQA implementados e a sua aplicao de maneira adequada e correta, apresenta que
(MARTINHO, 2008):
A remoo 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 mtricas 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 preocupacoes e
atividades que se concentram na gestao da qualidade de software e que podem ser
sintetizadas da seguinte maneira:
Padroes: o IEEE, a ISO e outras organizacoes de padronizacoes produziram uma
ampla gama de padroes para engenharia de software e os respectivos documentos. Os
padroes podem ser adotados voluntariamente por uma organizacao de engenharia de
software ou impostos pelo cliente ou outros interessados. O papel da SQA e garantir
que padroes que tenham sido adotados sejam seguidos e que todos os produtos resultantes estejam em conformidade com eles.
captulo 1
27
Revisoes e auditorias: As revisoes tecnicas sao uma atividade de controle de

qualidade realizada por engenheiros de software para engenheiros de software. Seu
intuito e o de revelar erros. Auditorias sao um tipo de revisao 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 revisao pode ser realizada para garantir que as revisoes estejam sendo realizadas de
maneira que conduza a maior probabilidade de descoberta de erros.
Testes: Os testes de software sao uma funcao 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 possivel de alcancar seu objetivo primario.
Coleta e analise de erros/defeitos: A unica forma de melhorar e medir o nosso
desempenho. A SQA reune e analisa dados de erros e defeitos para melhor compreender como os erros sao introduzidos e quais atividades de engenharia de software
melhor se adequam para sua eliminacao.
Gerenciamento de mudancas: As mudancas sao um dos aspectos mais negativos de qualquer projeto de software. Se nao forem administradas apropriadamente,
podem gerar confusao, e confusao quase sempre leva a uma qualidade inadequada.
A SQA garante que praticas adequadas de gerenciamento de mudancas tenham sido
instituidas.
Educacao: Toda organizacao de software quer melhorar suas praticas de engenharia de software. Um fator fundamental para o aperfeicoamento e a educacao dos
engenheiros de software, seus gerentes e outros interessados. A organizacao de SQA
assume a lideranca no processo de aperfeicoamento do software e e um proponente
fundamental e patrocinador de programas educacionais.
Gerencia dos fornecedores: Adquirem-se tres categorias de software de fornecedores externos de software - pacotes prontos, comerciais (por exemplo, Microsoft
Office, oferecidos ao usuario em embalagens), um shell personalizado que fornece um
esqueleto basico, personalizado de acordo com as necessidades do comprador e software sob encomenda que e projetado e construido de forma personalizada a partir de
especificacoes fornecidas pela empresa-cliente. O papel do grupo de SQA e garantir
software de alta qualidade por meio da sugestao de praticas especificas de garantia da
qualidade que o fornecedor deve (sempre que possivel) seguir, e incorporar exigencias
de qualidade como parte de qualquer contrato com um fornecedor externo.
28
captulo 1
Administracao da seguranca: Com o aumento dos crimes ciberneticos e novas

regulamentacoes governamentais referentes a privacidade, toda organizacao de software deve instituir politicas que protejam os dados em todos os niveis, estabelecer
protecao atraves de firewalls para as aplicacoes da Internet (WebApps) e garantir que
o software nao tenha sido alterado internamente, sem autorizacao. A SQA garante o
emprego de processos e tecnologias apropriadas para ter a seguranca de software
desejada.
Protecao: O fato de o software ser quase sempre um componente fundamental
de sistemas que envolvem vidas humanas (por exemplo, aplicacoes na industria automotiva ou aeronautica), o impacto de defeitos ocultos pode ser catastrofico. A SQA
pode ser responsavel por avaliar o impacto de falhas de software e por iniciar as etapas
necessarias para reducao de riscos.
Administracao de riscos: Embora a analise e a reducao de riscos seja preocupacao dos engenheiros de software, o grupo de SQA garante que as atividades de gestao
de riscos sejam conduzidas apropriadamente e que planos de contingencia relacionados a riscos tenham sido estabelecidos.
Alm de cada uma dessas preocupaes e atividades, a SQA trabalha para garantir que atividades de suporte ao software (por exemplo, manuteno, suporte on-line,
documentao e manuais) sejam realizadas ou produzidas tendo a qualidade como
preocupao dominante."
(PRESSMAN, 2011, p. 389)
CONEXO
Recursos para a Gesto da Qualidade
(PRESSMAN, 2011, p. 390) relaciona em seu livro dezenas de recursos para a gesto
da qualidade disponveis na internet, incluindo associaes de profissionais, organizaes de
padres e fontes de informao genricas. Veja a relao:
American Society for Quality (ASQ) Software Division
www.migre.me/oIuNQ
Association for Computer Machinery
www.acm.org
captulo 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: Tpicos sobre certificacao em qualidade
www.tickit.org/international.htm
1.6 Estatstica da Garantia da Qualidade de

Software
A garantia da qualidade de software tambm pode ter um componente estatstico, por meio de uso de tcnicas estatsticas para estimar a qualidade de
software. Ao executar o cdigo com um pequeno conjunto de casos de testes
aleatrios pode gerar resultados teis para estimar a qualidade. Este processo
tambm chamado pode prova do software.
A mdia dos erros encontrados pode ser usada como estimativa para a mdia de erros no projeto final.
Se a porcentagem de execues corretas alta, obviamente um sinal que
o desenvolvimento est seguindo na direo correta, caso contrrio, algumas aes de correo devem ser tomadas para poder alterar o processo de
desenvolvimento.
30
captulo 1
Pressman (2011, p. 393) prope as seguintes etapas para a estatstica da

qualidade de software:
1.
Informacoes sobre erros e defeitos de software sao coletadas e classificadas.
2.
E feita uma tentativa de associar cada erro e defeito a sua causa subjacente (por
exemplo, a nao adequacao as especificacoes, erros de projeto, violacao de padroes,

comunicacao inadequada com o cliente).
3.
Usando o principio de Pareto (80% dos defeitos podem ser associados a 20% de
todas as possiveis causas), sao isoladas os 20% (as poucas causas vitais) .
4.
Assim que as poucas causas vitais tiverem sido identificadas, prossegue-se para
a correcao dos problemas que provocaram os erros e defeitos.
Estas etapas propostas e aes representam um passo importante para a

adoo de uma gesto de qualidade relacionada s mudanas e adaptaes aos
processos de acordo com os erros encontrados.
1.7 Revises tcnicas

As revises tcnicas (RT) de software tem um papel muito valioso para a gesto
da qualidade, j que elas funcionam como uma espcie de filtro e podem ser
aplicadas em diferentes momentos ao longo do processo de desenvolvimento de software, contribuindo para a revelao de erros, falhas ou defeitos que
podem ser sanados e eliminados. Assim, as revises tcnicas 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
cdigo-fonte.
De acordo com Pressman (2011, p. 376), as revisoes tecnicas fazem parte das
muitas acoes exigidas como parte de boas praticas da engenharia de software.
requerido muita dedicao de nossa parte, em cada ao realizada para este
fim. Definir um conjunto de mtricas para poder avaliar a eficcia muito importante para a organizao, j que o esforco disponivel para o projeto e finito.
captulo 1
31
Freedman e Weinberg discutem a necessidade de revisoes da seguinte maneira:

O trabalho tecnico precisa de revisao pela mesma razao que o lapis precisa de
borracha: Errar e humano. A segunda razao para precisarmos de revisoes tecnicas e
que embora as pessoas sejam boas para descobrir alguns de seus proprios erros,
varios tipos de erros escapam mais facilmente daquele que os cometeu do que de
outras pessoas externas. O processo de revisao e, portanto, a resposta para a oracao
de Robert Burns:
Oh! que uma forca conceda poder para nos vermos como os outros nos veem.
Uma revisao - qualquer revisao - e uma forma de usar a diversidade de um grupo
de pessoas para :
1.
Apontar aperfeicoamentos necessarios no produto de uma unica pessoa ou de
uma equipe.
2.
Confirmar aquelas partes de um produto em que aperfeicoamentos sao indeseja-
veis ou desnecessarios.
3.
Obter trabalho tecnico de qualidade mais uniforme, ou pelo menos mais previsivel;
qualidade que possa ser alcancada sem revisoes, de modo a tornar o trabalho tecnico
mais gerenciavel.
Mesmo um pequeno subconjunto de mtricas, reunidas para cada reviso

a ser realizada, podem oferecer uma boa viso da situao, muito embora possam ser difinidas muitas outras mtricas para as RTs. Pressman (2011, p. 376)
relaciona alguma destas mtricas:
Esforco de preparacao, Ep - o esforco (em homens/hora) exigido para revisar um
produto resultante antes da reuniao de revisao.
Esforco de avaliacao, Ea - o esforco (em homens/hora) que e despendido durante
a revisao em si.
Reformulacao esforco, Re - o esforco (em homens/hora) dedicado a correcao dos
erros revelados durante a revisao.
Tamanho do artefato de software, TPS - uma medida do tamanho do artefato
de software que foi revisto (por exemplo, o numero de modelos UML ou o numero de
paginas de documento ou entao o numero de linhas de codigo).
32
captulo 1
Erros secundarios encontrados, Errsec - o numero de erros encontrados que

podem ser classificados como secundarios (exigindo menos para ser corrigidos do que
algum esforco pre-especificado).
Erros graves encontrados, Errgraves - o numero de erros encontrados que podem
ser classificados como graves (exigindo mais para ser corrigidos do que algum esforco
pre-especificado).
Vale ainda ressaltar que essas metricas podem ser ainda mais refinadas se
associar o tipo de artefato de software que foi revisto para as metricas.
Bugs, erros e defeitos

O objetivo do controle da qualidade de software e da gestao da qualidade em geral e,
em sentido mais amplo, eliminar problemas de qualidade no software. Tais problemas
sao conhecidos por diversos nomes - bugs, falhas, erros ou defeitos, apenas para citar
alguns. Esses termos sao sinonimos ou existem diferencas sutis entre eles?
Existe uma distincao clara entre erro (um problema de qualidade encontrado antes
de o software ser liberado aos usuarios finais) e defeito (um problema de qualidade
encontrado apenas depois de o software ter sido liberado aos usuarios finais). Essa
distincao e feita porque os erros e os defeitos podem acarretar impactos economicos,
comerciais, psicologicos e humanos muito diferentes. Os engenheiros de software tem
a missao de encontrar e corrigir o maior numero possivel de erros antes dos clientes
e/ ou usuarios finais. Devem-se evitar defeitos - pois (de modo justificavel) criam uma
imagem negativa do pessoal de software.
E importante notar, entretanto, que a distincao temporal entre erros e defeitos feita
neste livro nao e um pensamento dominante. O consenso geral na comunidade de
engenharia de software e que defeitos e erros, falhas e bugs sao sinonimos. Ou seja,
o momento em que o problema foi encontrado nao tem nenhuma influencia no termo
usado para descreve-lo. Parte do argumento a favor desta visao e que, muitas vezes,
fica dificil fazer uma distincao clara entre pre e pos-entrega (consideremos, por exemplo, um processo incrementai usado no desenvolvimento agil).
captulo 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 esforcar - muitissimo - para encontrar problemas
antes que seus clientes e usuarios finais os facam. Caso tenha maior interesse nessa questao, uma discussao razoavelmente completa sobre a terminologia envolvendo
bugs pode ser encontrada em www.softwaredevelopment.ca/bugs.shtml.
(PRESSMAN, 2011, p. 374)
As revises tcnicas tambm podem possuir diferentes abordagens em relao ao seu nvel de formalidade. Elas podem ser categorizadas em revises
informais ou em revises tcnicas mais formais, sendo que cada uma possui
suas formas de abordagem.
1.8 Revises informais

As revises informais podem ser constitudas de aes que visam revisar, discutir, mas de modo informal, como o prprio nome sugere. Teste de mesa de
um artefato de engenharia de software, juntamente com um colega, bem como
reunies informais (com pelo menos mais de duas pessoas), so exemplos de
reunies informais e estas visam geralmente, revisar um artefato ou ainda alguns aspectos orientados a revisoes da programacao em pares.
Devido a falta de planejamento ou preparao para estas reunies informais, sua eficcia pode ser muito inferior em relao s reunies com abordagens mais formais, pois so desprovidas de uma srie de pontos importantes
para dar continuidade ou atender os pontos que so discutidos ou que foram
tratados nesta reunio. O fato de no ter um follow-up, uma agenda e uma estrutura adequada para conduo e anotao de uma pauta, podem comprometem sua eficcia. No entanto, um simples teste pode revelar erros que, de outra
forma, poderiam propagar ainda mais na gesto da qualidade.
Uma maneira de tentar aumentar esta eficcia, nas reunies informais do
tipo teste de mesa, seria desenvolver um conjunto de listas de verificacao simples para cada artefato produzido pela equipe de software. As questoes levantadas na lista de verificacao sao genericas, mas servirao como guia para os revisores verificarem o produto resultante (PRESSMAN, 2011, p. 380).
34
captulo 1
1.9 Revises Tcnicas Formais

A revisao tecnica 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 reviso a abordagem mais formal e exige uma estrutura em termos de planejamento e organizao para que ela ocorra. Segundo Pressman (2011, p. 381), as RTF tem como objetivos: (1) descobrir erros na
funcao, logica ou implementacao para qualquer representacao 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 padroes predefinidos; (4) obter software que seja desenvolvido de maneira uniforme; e (5) tornar
os projetos mais gerenciaveis. Um ponto interessante de se observar que alem
disso, a RTF tambm serve como base de treinamento, possibilitando que engenheiros mais novos observem diferentes abordagens para analise, projeto e
implementacao de software, contribuindo ainda mais para a qualidade.
Para ter sucesso e ser bem-sucedida, em cada reunio formal tcnica,
imprescindvel a participao 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 reviso

Para a realizao de uma RTF, devem-se estabelecer previamente diretrizes, e
estas serem distribuidas a todos os revisores, contar com a anuencia de todos
e, entao, segui-las a risca. Em algumas situaes uma revisao nao controlada
pode ser pior do que nao fazer nenhuma revisao. Pressman (2011, p. 383) apresenta um conjunto minimo de diretrizes para revisoes tecnicas formais:
1.
Revisar o produto, nao o produtor. Uma RTF envolve pessoas e egos. Con-
duzida de forma apropriada, a RTF deve deixar todos os seus participantes com uma
agradavel sensacao de dever cumprido. Conduzido de forma impropria, a RTF pode
assumir a aura de uma inquisicao. Os erros devem ser apontados gentilmente; o clima
da reuniao deve ser descontraido e construtivo; o intuito nao deve ser o de causar
embaracos ou menosprezo. O lider da revisao deve conduzir a reuniao de revisao de tal
forma a garantir que o clima seja mantido e as atitudes sejam apropriadas; alem disso,
deve interromper imediatamente uma revisao que comecou a sair do controle.
captulo 1
35
Estabelecer uma agenda e mante-la. Um dos principais males de reunioes
2.
de todos os tipos e desviar do foco. Uma RTF deve ser mantida em seu rumo e prazo
estabelecidos. O lider da revisao tem a responsabilidade de manter o cronograma da
reuniao e nao devera ficar receoso em alertar as pessoas quando ela estiver saindo do
foco.
3.
Limitar debates e refutacao. Quando uma questao e levantada por um revisor,
talvez nao haja um acordo universal sobre seu impacto. Em vez de perder tempo debatendo a questao, o problema deve ser registrado para posterior discussao, fora da
reuniao.
4.
Enunciar as areas do problema mas nao tentar resolver todo o problema
registrado. Uma visao nao e uma sessao para resolucao de problemas. A solucao de
um problema pode, muitas vezes, ser realizada pelo proprio produtor ou com a ajuda de
apenas outro colega. A resolucao de problemas deve ser adiada para depois da reuniao
de revisao.
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 informacoes sao registradas. Alternativamente, as
anotacoes podem ser introduzidas diretamente em um notebook.
6.
Limitar o numero de participantes e insistir na preparacao antecipada.
Duas cabecas funcionam melhor do que uma, mas catorze cabecas nao funcionam,
necessariamente, melhor do que quatro. Mantenha o numero de pessoas envolvidas
no minimo necessario. Entretanto, todos os membros da equipe de revisao devem se
preparar com antecedencia. O lider da revisao deve solicitar comentarios escritos (fornecendo uma indicacao de que o revisor reviu o material).
7.
Desenvolver uma lista de verificacao para cada artefato que provavelmen-
te sera revisado. A lista de verificacao ajuda o lider da revisao a estruturar a RTF e

auxilia cada revisor a se concentrar nas questoes importantes. As listas de verificacao
devem ser desenvolvidas para analise, projeto, codigo e ate mesmo para o teste dos
artefatos.
8.
Alocar os recursos e programar o tempo para as RTFs. Para as revisoes
serem eficazes, elas devem ser programadas como tarefas durante a gestao de qualidade . Alem disso, deve-se programar o tempo para as inevitaveis modificacoes que
ocorrerao como resultado de uma RTF.
36
captulo 1
9.
Realizar treinamento significativo para todos os revisores. Para serem efica-
zes, todos os participantes de uma revisao deveriam receber algum treinamento formal.
O treinamento deve enfatizar tanto questoes relacionadas a processos, como o lado
psicologico das revisoes.
10. Revisar revisoes iniciais. Um interrogatorio pode ser benefico na descoberta de
problemas com o proprio processo de revisao. Os primeiros artefatos a serem revisados
devem ser as proprias diretrizes de revisao.
Devido s diversas variveis envolvidas, como por exemplo o nmero de

participantes, o tipo de artefatos resultantes, o momento, o tempo adequado,
a durao e a abordagem que ser feita, importante notar que estes fatores
podem causar impactos significativos na reviso. Assim, em funo deste conjunto de fatores, recomendado que a organizao avalie as melhores prticas
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 frequncia e de modo repetitivo, pouco
importar se outros fatores de qualidade de software esto de acordo. O software em questo estar com a confiana e credibilidade comprometida, com sua
qualidade final afetada.
O uso de dados histricos e de desenvolvimento permitem mensurar e estimar, diferentemente de outros fatores de qualidade. Pressman (2011, p. 395)
define a confiabilidade de software em termos estatisticos como a probabilidade de operacao 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 execucao), e provavel que ele opere corretamente
(sem falhas) 999 vezes (PRESSMAN, 2011, p. 395).
captulo 1
37
Uma questo 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 definicao existem algumas variacoes, podendo ser apenas problematicas ou catastroficas. 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 situaes, complicando ainda
mais o problema, a correcao de uma falha pode, na realidade, resultar na introducao de outros erros que resultarao 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 observvel pelos usurios, mostrando a necessidade de assegurar a qualidade e sua capacidade de no apresentar falhas quando est em
produo (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 satisfatrio num determinado ambiente.
Ou seja, a probabilidade de um sistema estar disponvel quando necessrio. A
disponibilidade pode ser determinada pela relao (SILVA FILHO, 2014):
Disponibilidade = ((MTTF) / (MTTF + MTTR)) x 100%
onde:
MTTF (Mean Time to Failure) o tempo mdio at a ocorrncia de falha.
MTTR (Mean Time to Repair) o tempo mdio 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 usurios relativo confiabilidade (SILVA
FILHO, 2014).
A Engenharia de Confiabilidade de Software ou ECS, abrange tcnicas de
engenharia para desenvolver e oferecer manuteno 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
captulo 1
De acordo com Silva Filho (2004), a ECS inclui:

Medio de confiabilidade de software, a qual inclui estimativa e previso com o uso
de modelos de confiabilidade de software.
Atributos e mtricas de projeto de produtos, processo de desenvolvimento, arquitetura de sistema, ambiente operacional do software e suas implicaes sobre a confiabilidade.
Aplicao deste conhecimento na especificao e projeto da arquitetura de software
do sistema, desenvolvimento, testes, uso e manuteno.
Para tanto, torna-se necessria a coleta de dados de falhas. Esses dados so coletados para se fazer a medio 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 mdio entre falhas esse tipo de dado faz o rastreamento dos intervalos entre
falhas consecutivas.
Alm destes pontos, a ECS tambm requer a medio de confiabilidade de

software que envolve duas atividades: estimao e previso de confiabilidade. A
atividade de estimao determina a confiabilidade de software atual aplicando
tcnicas estatsticas de inferncia aos dados de falhas obtidos durante o teste
do sistema ou durante a operao 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 previso determina a confiabilidade de software em uma
perspectiva futura baseada em mtricas de software e medidas disponveis.
Dependendo do estgio de desenvolvimento, a previso pode envolver diferentes tcnicas como (SILVA FILHO, 2014):
Quando os dados de falhas esto disponveis Por exemplo, o software encontra-se em testes ou no estgio operacional. Neste caso, as tcnicas de estimao podem ser usadas para parametrizar e verificar os modelos de confiabilidade de software,
os quais realizam previso de confiabilidade de software futura.
captulo 1
39
Quando os dados de falhas no esto disponveis Por exemplo, quando o software ainda encontra-se na fase de projeto ou implementao. Neste caso, as mtricas
obtidas do processo de desenvolvimento de software e as caractersticas do produto
resultante podem ser utilizadas para determinar a confiabilidade de software durante
a fase de testes.
Segurana e Confiabilidade
Nao obstante, a confiabilidade e a seguranca de software estejam estreitamente relacionadas, e importante compreender a sutil diferenca entre elas. A confiabilidade de
software usa a analise estatistica para determinar a probabilidade de que uma falha de
software venha a ocorrer. Entretanto, a ocorrencia de uma falha nao necessariamente
resulta num risco ou deformacao. A seguranca de software examina as maneiras segundo as quais as falhas resultam em condicoes que podem levar a uma deformacao.
Ou seja, as falhas nao sao consideradas no vazio, mas sao avaliadas no contexto de um
sistema inteiro computadorizado
Seguranca de software e um atividade de garantia de qualidade de software que
se concentra na identificacao e avaliacao 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 nivel de sistema sao identificadas, tecnicas de analise
sao usadas para definir a gravidade e a probabilidade de ocorrencia, tais como, analise
em arvore, logica de tempo real ou modelos de rede de Petri. Apos as casualidades
serem identificadas e analisadas, os requisitos relacionados a seguranca podem ser
especificados para o software.
(BUENO e CAMPELO, 2014, p. 16)
ATIVIDADES
Vamos praticar um pouco os conceitos aprendidos. Responda s seguintes questes:
01. A qualidade de software uma rea de conhecimento da engenharia de software que
objetiva garantir a qualidade do software atravs da definio e normatizao de processos
de desenvolvimento. Para que um software seja considerado de qualidade, necessrio
que este tenha conformidade com alguns conceitos. Marque a alternativa que representa o
conceito de Eficincia:
40
captulo 1
a) Deve realizar suas tarefas em tempo adequado complexidade de cada um deles. E

devem utilizar de modo eficiente os recursos de hardware disponveis.
b) Deve permitir expanso de suas funcionalidades para atender novos requisitos ou incorporar novas tecnologias.
c) Deve funcionar de forma correta. Satisfazendo as suas especificaes sem falhas ou
erros.
d) Deve ser fcil de aprender e de usar, permitindo maior produtividade do usurio, flexibilidade de utilizao e aplicao e proporcionar satisfao ao usurio.
e) Suas especificaes satisfazem os requisitos dos usurios e da organizao.
02. Quais so os principais objetivos da revises tcnicas fomais (RTF)?
03. Usando a definio de qualidade de software proposta neste captulo, voc acredita que
seja possvel criar um produto til que gere valor mensurvel sem usar um processo eficaz?
Justifique sua resposta.
04. Na sua avaliao, o que pode ser considerado um software de boa qualidade? Justifique.
05. Qualidade e segurana so a mesma coisa? Explique.
REFLEXO
A rea de qualidade, tanto na engenharia tradicional, quanto na engenharia de software
sem dvida bastante polmica e discutida. Porm, aps termos estudado os tpicos deste
captulo, podemos perceber que o comprometimento da organizao em adotar esses padres muito importante.
No adiantaria um esforo somente da equipe de software de uma organizao para a
equipe atingir padres de excelncia no desenvolvimento de software.
Normalmente, a adoo de um programa de qualidade aplicado ao software est relacionada com a adoo da empresa como um todo a assumir compromissos de melhoria da qualidade de seus produtos e servios. Porm, isso um pouco difcil de encontrar no mercado,
mas felizmente tem mudado, pois as empresas esto sentindo a necessidade de mudana
em busca de melhores padres e prticas, pois os seus clientes comearam a exigi-los e
cobram as empresas de software por eles.
captulo 1
41
Portanto, trata-se de um fator de vantagem competitiva para as empresas de software. O

gestor de TI tambm tem que se preocupar com estas questes 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 confiveis. So
Paulo: rica, 2006.
Rocha, A.R.C.; Maldonado, J. C.; Weber, K. C. Qualidade de Software: teoria e prtica. So
Paulo: Prentice Hall, 2001.
Anualmente, a Sociedade Brasileira de Computao (SBC) promove um simpsio nacional na rea de qualidade de software. Os anais destes eventos so grandes referncias e
recomendaes de ampliao dos horizontes nesta rea.
REFERNCIAS BIBLIOGRFICAS
BARRETO JNIOR, J.; Qualidade de Software. Disponvel 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. Disponvel em: <http://
sistemas.riopomba.ifsudestemg.edu.br/dcc/materiais/1022789570_Qualidade%20
de%20Software.pdf>. Acesso em: 17 dez 2014.
BUENO, L. C.; Gesto da Qualidade Como um Desafio Manuteno de Software.
Monografia. Instituto Superior de Administrao 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. So Paulo: Novatec, 2007.
MARTINHO, F.; Qualidade, Qualidade de Software e Garantia da Qualidade de Software so
as mesmas coisas?. 2008. Disponvel em: <http://www.testexpert.com.br/?q=node/669>.
Acesso em: 17 jan 2015.
42
captulo 1
PRESSMAN, R. S. Engenharia de Software, 7 edicao. Sao Paulo: McGraw-Hill, 2011.

780p.
RAPCHAN, F.; A Norma ISO 9000-3. UFES. 2011. Disponvel em: <http://www.geocities.
ws/chicorapchan/artigos/9000-3.pdf>. Acesso em: 17 jan 2015.
SAYAO, M; BREITMAN, K K. Gerencia de Requisitos. Disponivel 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. Disponvel em: <http://www.devmedia.com.br/artigo-engenharia-de-software8-confiabilidade-de-software/11312>. Acesso em: 11 dez 2014.
SLACK, N. et al. Administrao da produo. So Paulo: Atlas, 1996.
captulo 1
43
44
captulo 1
2
Processos de Ciclo
de Vida e Qualidade
Neste captulo vamos estudar alguns modelos ou padres de qualidade aplicados ao software. Veremos que existem muito mais detalhes do que simplesmente documentar o sistema por meio de manuais tcnicos.
Vimos no captulo 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 conhea esses modelos e os
avalie a fim de aplic-los em possveis 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 adaptao.
Bons estudos!
OBJETIVOS
Conhecer algumas das principais normas de qualidade de produtos de software.
Abordar sobre os processos fundamentais.
Abordar sobre os processos de apoio.
Abordar sobre os processos organizacionais.
46
captulo 2
2.1 Introduo
Para que a organizacao que produz software tenha sua qualidade reconhecida
em todo o mundo, seus processos devem respeitar padroes de qualidade definidos pela comunidade de software (SILVA, 2006, p. 9).
Um aspecto interessante da qualidade que no basta que ela exista. Ela
deve ser reconhecida pelo cliente. Por causa disso, necessrio que exista algum tipo de certificao oficial, emitida com base em um padro ou modelo
de qualidade. Alguns tipos de certificados so bastante conhecidos, como por
exemplo os certificados de qualidade da srie ISO-9000 (BARRETO JNIOR,
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 padro nico mundial,
uma empresa do Brasil, mesmo no tendo nenhum contato com uma outra empresa na Europa, pode garantir a ela a qualidade de seu trabalho (BARRETO
JNIOR, 2014, p. 1).
A certificao em uma norma ou padro ocorre quando uma empresa obtm um certificado oficial (documento) o qual indica que a empresa possui
conformidade com uma determinada norma ou padro.
Segundo Silva (2006, p. 9), desde a dcada de 1980, iniciaram-se esforos
para melhoria de processos de software, com o objetivo de melhorar a qualidade, aumentar a produtividade e diminuir os custos. Diferentes modelos so utilizados dependendo do mercado alvo das organizaes de software (ROCHA et
al., 2001). As principais normas e modelos de qualidade difundidos atualmente
so: 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 captulo iremos abordar alguns dos modelos ou padres mais conhecidos e utilizados, relacionados qualidade de software.
A ISO uma entidade internacional criada com o objetivo de padronizar normas, testes
e certificaes entre os pases.
Para se obter um certificado da ISO 9000 so necessrios alguns passos:
11. Adquirir e estudar as normas pretendidas
captulo 2
47
12. Implementar um sistema de gesto da qualidade segundo os requisitos da norma

pretendida, inclusive para software
13. Solicitar que um rgo certificador credenciado faa a avaliao do sistema implantado.
O certificado obtido normalmente tem validade por 3 anos a contar da data de auditoria de certificao. A empresa passa por avaliaes peridicas durante esse perodo
de 3 anos. No Brasil, o INMETRO o rgo do governo responsvel pelo credenciamento das instituies avaliadora que realizam a certificao de sistemas de qualidade.
2.2 Normas de qualidade de produtos de

software
Quando pensamos em qualidade, normalmente pensamos em parmetros de
comparao do tipo fsicos como forma, tamanho, conforto, velocidade e etc.
Mas e no caso de software? Como estabelecer estes padres de comparao?
Nas prximas sees vamos estudar alguns deles.
2.2.1 Qualidade de Produtos de Software - ISO 9126

A ISO publicou uma norma que representa uma padronizao 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 traduo para o Brasil, publicada em agosto de 1996 como NBR 13596.
Esta norma apresenta um conjunto de caractersticas 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
JNIOR, 2014, p. 5).
48
captulo 2
A figura 2.1 e a tabela 2.1 mostram o conjunto desta norma.

Adeq
ua
Acurcia o
Interoperabilidade
Segurana
e
idad
cional
n
u
f
a
Conformidade com
Conformidade
Inteligibil
idad
e
Apreensibilid
ade
Operabilidade
Atratividade
de
bilida
com a usa
Us
l
a bi
de
i da
Po
rt
Confi
ab
ilid
ade
abi
lida
de
Fu
a de
alid
ion
nc
Maturida
de
Tolerncia e falh
as
Recuperabilidade
ilidade
Conformidade com a confiab
de
abilida
apt
Ad
e de instalao
uldad
Fac
Coexistncia
Capacidade para substituir
Con
form
idade co
m a portabilidade
ute
Man
ISO 9126-1
Ef
ici
nc
ade
nibilid
ia
bilidade
alisa
An
ificabilidade
Mod
Estabilidade
Testabilidade
Con
formi
dade co
m a manutenibilidade
m relao ao tempo
ento e
rtam
mpo
Co
lao aos recursos
Comportamento em re
Confo
rmidade com
a eficincia
Figura 2.1 Norma ISO 9126-1. Fonte: Elaborado pelo autor.
CARACTERSTICA
SUBCARACTERSTICA
Adequao
Acurcia
Funcionalidade
(satisfaz as necessidades?)
Interoperabilidade
Conformidade
Segurana de acesso
Maturidade
Confiabilidade
( imune a falhas?)
Tolerncia a falhas
Recuperabilidade
Inteligibilidade
Usabilidade
( fcil de usar?)
PERGUNTA CHAVE
Prope-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 no autorizado aos
dados?
Com que frequncia apresenta
falhas?
Ocorrendo falhas, como ele
reage?
capaz de recuperar dados em
caso de falha?
fcil entender o conceito e a
aplicao?
Apreensibilidade
fcil aprender a usar?
Operacionabilidade
fcil de operar e controlar?
captulo 2
49
Eficincia
( rpido e enxuto?)
Tempo
Recursos
Analisabilidade
Manutenibilidade
( fcil de modificar?)
Modificabilidade
Estabilidade
Testabilidade
Adaptabilidade
Portabilidade
( fcil de usar em outro
ambiente?)
Capacidade de ser instalado

Conformidade
Capacidade. de substituir
Qual o tempo de execuo?

Quanto recurso usa? Durante
quanto tempo?
fcil de encontrar uma falha,
quando ocorre?
fcil modificar e adaptar?
H grande risco quando se faz
alteraes?
fcil testar quando se faz
alteraes?
fcil adaptar a outros ambientes?
fcil instalar em outros ambientes?
Est de acordo com padres de
portabilidade?
fcil usar para substituir
outro?
Tabela 2.1 Norma ISO 9126. Fonte: BARRETO JNIOR (2014, p. 5).
Essa norma no muito extensa porm define detalhadamente o que se

pretende avaliar em cada grupo e subgrupo.
Embora a norma ISO 9126/NBR 13596 enumere as caractersticas e subcaractersticas de um software, ela ainda no define como dar uma nota a um software em cada um destes itens. Se voc no est familiarizado com o processo
de avaliao 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 subcaractersticas.
2.2.2 Guias para a Avaliao da Qualidade - ISO 14598

fcil perceber a necessidade de mais detalhes sobre como avaliar a qualidade de
um software. As caractersticas e subcaractersticas da norma ISO/IEC 9126 apenas
comearam o trabalho. Faltava definir, em detalhes, como atribuir um conceito
para cada item. Afinal, sem uma padronizao, que valor teria uma avaliao?
A ISO, consciente deste problema, est finalizando o trabalho em um conjunto de Guias para a Avaliao da Qualidade segundo a norma ISO/IEC 9126.
Estes guias descrevem, detalhadamente, todos os passos para que se avalie um
software (BARRETO JNIOR, 2014, p. 8).
50
captulo 2
Esta nova norma traz muitos recursos interessantes aos avaliadores, j que
trata o processo de avaliao em grande detalhe. Ela leva em conta a existncia de
trs grupos interessados em avaliar um software, o que define os trs tipos bsicos de certificao conforme mostra a tabela 2.2 (BARRETO JNIOR, 2014, p. 8):
CERTIFICAO
QUEM REALIZA?
FINALIDADE
De 1 parte
Empresas que desenvolvem

software
Melhorar a qualidade de seu prprio

produto
De 2 parte
Empresas que adquirem software
Determinar a qualidade do produto que

iro adquirir
De 3 parte
Empresas que fazem certificao
Emitir documento oficial sobre a qualidade

de um software
Tabela 2.2 Certificaes da ISO14598. Fonte: BARRETO JNIOR (2014, p. 8).
Esta norma constituda, na verdade, de seis documentos distintos, relacionados entre si mostrados na tabela 2.3:
NORMA
NOME
FINALIDADE
14598-1
Viso Geral
Ensinar a utilizar as outras normas do grupo
14598-2
Planejamento e Gerenciamento
Sobre como fazer uma avaliao, de forma geral
14598-3
Guia para Desenvolvedores
14598-4
Guia para Aquisio
14598-5
Guia para Avaliao
14598-6
Mdulos de Avaliao
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 caracterstica
Tabela 2.3 Documentos da ISO14598. Fonte: adaptado de BARRETO JNIOR (2014, p. 8).
Resumidamente, esta nova norma complementa a ISO/IEC 9126 e permite

uma avaliao padronizada das caractersticas de qualidade de um software.
importante notar que esta norma entra em detalhes mnimos, incluindo
modelos para relatrios de avaliao, tcnicas para medio das caractersticas, documentos necessrios para avaliao e fases da avaliao, o que no
ocorre na norma ISO 9126.
captulo 2
51
2.2.3 Qualidade de Pacotes de Software - ISO 12119

Esta norma foi publicada em 1994 e trata da avaliao de pacotes de software,
tambm conhecidos como software de prateleira. Alm de estabelecer os requisitos de qualidade para este tipo de software, ela tambm destaca a necessidade de instrues para teste deste pacote, considerando estes requisitos. A
norma divide-se em itens, da seguinte forma (BARRETO JNIOR, 2014, p. 9):
1.
Escopo
2.
Definies
3.
Requisitos de qualidade
a) Descrio do Produto: descreve o produto, de forma a ajudar o comprador
em potencial, servindo como base para testes. Cada declarao deve ser correta
e testvel. Deve incluir declaraes sobre funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade.
b) Documentao do usurio: deve ser completa, correta, consistente, fcil de
entender e capaz de dar uma viso geral do produto.
c) Programas e dados: descreve em detalhes cada uma das funes do software, incluindo declaraes sobre funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade.
4.
Instrues para teste

a) Pr-requisitos de teste: Lista de itens necessrios ao teste, incluindo documentos includos no pacote, componentes do sistema e material de treinamento.
b) Atividades de teste: Instrues detalhadas sobre os procedimentos de teste, inclusive instalao e execuo de cada uma das funes descritas.
c) Registro de teste: Informaes sobre como os testes foram realizados, de tal
forma a permitir uma reproduo destes testes. Deve incluir parmetros utilizados,
resultados associados, falhas ocorridas e at a identidade do pessoal envolvido.
d) Relatrio de teste: Relatrio incluindo: identificao do produto, hardware
e software utilizado, documentos utilizados, resultados dos testes, lista de no
conformidade com os requisitos, lista de no conformidade com as recomendaes, datas, etc.
Tabela 2.4 Diviso da norma ISO 12119.
Um dos grandes mritos desta norma est na profundidade com que so

descritas cada uma das caractersticas e subcaractersticas mencionadas na
52
captulo 2
norma 9126. A norma inclui detalhes que devem estar presentes no produto,
tais como (BARRETO JNIOR, 2014, p. 10):
Documentao do usurio de fcil compreenso
Um sumrio e um ndice remissivo na documentao do usurio
Presena de um Manual de instalao com instrues detalhadas
Possibilidade de verificar se uma instalao foi bem sucedida
Especificao de valores limites para todos os dados de entrada, que devero ser
testados
Operao normal mesmo quando os dados informados esto fora dos limites especificados
Consistncia de vocabulrio entre as mensagens e a documentao
Funo de auxlio (help) com recursos de hipertexto
Mensagens de erro com informaes necessrias para a soluo da situao de erro
Diferenciao dos tipos de mensagem: confirmao, consulta, advertncia e erro
Clareza nos formatos das telas de entrada e relatrios
Capacidade de reverter funes de efeito drstico
Alertas claros para as consequncias de uma determinada confirmao
Identificao dos arquivos utilizados pelo programa
Identificao da funo do programa que est sendo executada no momento
Capacidade de interromper um processamento demorado
Outras caractersticas importantes so a nfase nos testes e os modelos de relatrios includos. Tudo isso facilita grandemente o trabalho do avaliador.
2.2.4 A Srie ISO 9000

Esta srie um conjunto de normas da ISO que define padres 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, produo,

instalao e assistncia tcnica
ISO 9002
Modelo para garantia da qualidade em produo e instalao
captulo 2
53
NORMA
TRATA DE
ISO 9003
Modelo para garantia da qualidade em inspeo e ensaios finais
ISO 9000-1
Diretrizes para a escolha entre as normas ISO 9001, 9002 e 9003
ISO 9000-3
Orientao para a aplicao da ISO 9001 em Software
Tabela 2.5 Normas da ISO 9000. Fonte: BARRETO JNIOR (2014, p. 11).
De acordo com Barreto Jnior (2014, p. 11), entre as normas 9001, 9002 e
9003, a primeira a que mais possui aderncia ao desenvolvimento e manuteno de software. Como toda norma deste grupo, ela usada para garantir
que um fornecedor atende aos requisitos especificados nos diversos estados do
desenvolvimento. Estes estgios incluem projeto, desenvolvimento, produo,
instalao e suporte.
O Padro ISO 9001:2000

A descricao a seguir define os elementos basicos do padrao ISO 9001:2000.
Informacoes completas sobre o padrao 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 gestao da qualidade.
Desenvolver, implementar e aperfeicoar o sistema.
Definir uma politica que enfatize a importancia do sistema.
Documentar o sistema de qualidade.
Descrever o processo.
Produzir um manual operacional.
Desenvolver metodos para controlar (atualizar) documentos. Estabelecer metodos
para manutencao de registros.
Dar suporte ao controle e a garantia da qualidade.
Promover a importancia da qualidade entre todos os interessados.
Focar na satisfacao do cliente.
Definir um plano de qualidade que atenda aos objetivos, as responsabilidades e a
autoridade.
Definir mecanismos de comunicacao entre os interessados. Estabelecer mecanismos
de revisao para um sistema de gestao da qualidade.
54
captulo 2
Identificar metodos de revisao 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 tecnicas (por exemplo, analise, projeto, testes).
Para monitoramento e gerenciamento de projetos. Definir metodos para reparacao.
Avaliar dados e metricas de qualidade.
Definir a abordagem para processos e aperfeicoamento continuos da qualidade.
(PRESSMAN, 2011, p. 398)
A ISO 9000:2000 e baseada em um conjunto de principios de gerenciamento de
qualidade, definidos a partir da experiencia de varias organizacoes (ISO, 2000):
Principio 1 - Foco no cliente: Dado que as organizacoes dependem de seus clientes,
e recomendavel que atendam as suas necessidade atuais e futuras e aos seus requisitos e procurem exceder as suas expectativas.
Principio 2 - Lideranca: Lideres estabelecem a unidade de proposito e o rumo da
organizacao. Convem que criem e mantenham um ambiente onde as pessoas estejam
totalmente envolvidas no proposito de atingir os objetivos da organizacao.
Principio 3 - Envolvimento de pessoas: Pessoas de todos os niveis sao a essencia de
uma organizacao. Seu envolvimento possibilita o aproveitamento de suas habilidades
por toda a organizacao.
Principio 4 - Abordagem de processo: Um resultado desejado e alcancado mais
eficientemente quando suas atividades e recursos sao gerenciados como um processo.
Principio 5 - Abordagem sistemica para a gestao: Identificar, entender e gerenciar
os processos inter-relacionados como um sistema contribui para a eficacia e eficiencia
da organizacao no sentido desta atingir os seus objetivos.
Principio 6 - Melhoria continua: Convem que a melhoria continua do desempenho
global da organizacao seja seu objetivo permanente.
Principio 7 - Abordagem factual para tomada de decisao: Decisoes eficazes sao
baseadas na analise de dados e informacoes.
Principio 8 - Beneficios mutuos nas relacoes com os fornecedores: Pelo fato de organizacao e fornecedores serem interdependentes, uma relacao de beneficios mutuos
aumenta a capacidade de ambos em agregar valor.
(SILVA, 2006, p. 10)
captulo 2
55
A norma ISO 9000-3 (no confundir com ISO 9003!) traz os roteiros para
aplicar a ISO 9001 especificamente na rea de desenvolvimento, fornecimento
e manuteno de software. Todas as orientaes giram em torno de uma situao contratual, onde uma outra empresa contrata a empresa em questo para
desenvolver um produto de software. Veja na tabela 2.6 abaixo os processos definidos na ISO 9000-3 (BARRETO JNIOR, 2014, p. 12):
GRUPO
ESTRUTURA DO SISTEMA DE QUALIDADE
ATIVIDADES DO CICLO DE VIDA
ATIVIDADES DE APOIO
ATIVIDADE
Responsabilidade do fornecedor
Responsabilidade do comprador
Anlise crtica conjunta
Anlise crtica do contrato
Especificao dos requisitos do comprador
Planejamento do desenvolvimento
Projeto e implementao
Testes e validao
Aceitao
Cpia, entrega e instalao
Manuteno
Gerenciamento de configurao
Controle de documentos
Registros da qualidade
Medio
Regras, convenes
Aquisio
Produto de software includo
Treinamento
Tabela 2.6 Processos definidos na ISO 9000-3. Fonte: BARRETO JNIOR (2014, p. 10).
O processo de certificao de uma empresa de software segundo as normas ISO 9001 / 9000-3 segue um conjunto de passos bem definidos (BARRETO
JNIOR, 2014, p. 10):
1.
A empresa estabelece o seu sistema de qualidade.
2.
A empresa faz uma solicitao formal a um rgo certificador, incluindo detalhes do
negcio da empresa, escopo da certificao solicitada e cpia do manual de qualidade.

3.
O rgo certificador faz uma visita empresa, colhe mais dados e explica o pro-
cesso de certificao.
4.
O rgo certificador verifica se a documentao do sistema de qualidade est de
acordo com a norma ISO.
56
captulo 2
5.
O rgo 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 rgo certificador emite o certificado de qualidade.
7.
O rgo certificador realiza visitas peridicas empresa para assegurar que o
sistema continua sendo efetivo.
CONEXO
No site http://www.12207.com h uma pgina que lista os padres de processo de software.
Por meio desta pgina voc consegue maiores informaes sobre o cada norma e encontra os links que lhe direcionar diretamente pgina de cada norma. Vale a pena conferir:
http://migre.me/oIBCn
De acordo com Wazlawick (2013, p. 363), a serie 9000 e conhecida como um conjunto de normas que enfatiza a documentacao de processos e procedimentos. Ela
estabelece quatro niveis de documentacao cada vez mais detalhados e complexos:
a)
Nivel 1: neste nivel generico e exigido basicamente um manual geral de qualida-
de explicando a politica e o sistema de qualidade, bem como a estrutura organizacional

da empresa e os papeis ou responsabilidades.
b)
Nivel 2: neste nivel, os processos sao 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 dependencias e quais os perfis
de responsaveis (Capitulo 2).
c)
Nivel 3: neste nivel devem ser detalhadas as instrucoes sobre como proceder
para o eficaz funcionamento do sistema de qualidade, abrangendo as atividades de

teste, inspecao, especificacoes, modelo e requisitos de qualidade etc. (Zahran, 1997).
d)
Nivel 4: neste nivel devem ser mantidos os registros de qualidade, ou seja, resul-
tados de testes e inspecoes que comprovam que as atividades do sistema de qualidade

documentado no nivel 3 sao efetivamente executadas.
(WAZLAWICK, 2013, p. 363)
captulo 2
57
A documentacao relacionada ao sistema de qualidade tambem pode ser

classificada segundo outros criterios, de acordo com Wazlawick (2013, p. 363):
Documentacao da qualidade: todos os documentos que estabelecem processos,
politicas e regras sobre como executar as atividades relacionadas a qualidade.
Registros da qualidade: resultados dos processos de avaliacao da qualidade que
indicam que os documentos da qualidade nao sao apenas letra morta, mas que sao
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 sao criados diariamente para cada projeto em desenvolvimento na empresa.
Alm 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 vrias outras normas, pois trata de assuntos que envolvem desde a concepo do software at a sua descontinuidade. Esta norma,
apresenta uma diviso de processos que podem ser assim divididas: Processos
Fundamentais, Processos de Apoio, Processos Organizacionais e ainda os
Processos de Adaptao (figura 2.2 e tabela 2.7).
Processos Fundamentais
Processos de Apoio
Aquisio
Documentao
Fornecimento
Gerencia de Configurao
Garantia de Qualidade
Verificao
Operao
Validao
Desenvolvimento
Reviso Conjunta
Manuteno
Auditoria
Resoluo de Problemas
Processos Organizacionais
Gerncia
Infra-estrutura
Melhoria
Treinamento
Figura 2.2 Estrutura de processos da ISO/IEC 12207.
58
captulo 2
Adapatao
Aquisio
PROCESSOS FUNDAMENTAIS DO CICLO DE VIDA
Fornecimento
Desenvolvimento
Operao
Manuteno
Iniciao
Preparao de pedido de proposta
Preparao e atualizao do contrato
Monitorao do fornecedor
Aceitao e concluso
Iniciao
Preparao de resposta
Contrato
Planejamento
Reviso e avaliao
Entrega e concluso
Implementao do processo
Anlise dos requisitos do sistema
Projeto da arquitetura do sistema
Anlise dos requisitos do software
Projeto da arquitetura do software
Projeto detalhado do software
Codificao e teste do software
Integrao do software
Teste de qualificao do software
Integrao do sistema
teste de qualificao do sistema
Apoio aceitao do software
Teste operacional
Operao do sistema
Suporte ao usurio
Anlise do problema e da modificao
Implementao da modificao
Reviso/aceitao da manuteno
Migrao
Descontinuao do software
captulo 2
59
Documentao
PROCESSOS DE APOIO
Gerncia de
configurao
Garantia da qualidade
Verificao
Validao
Reviso conjunta
Auditoria
PROCESSOS ORGANIZACIONAIS
Resoluo de
problema
Gerncia
Melhoria
Infra-estrutura
Treinamento
Projeto e desenvolvimento
Produo
Manuteno
Identificao da configurao
Controle da configurao
Relato da situao da configurao
Avaliao da configurao
Gerncia da liberao e distribuio
Garantia do produto
Garantia do processo
Sistemas de garantia da qualidade
Verificao
Validao
Revises de gerenciamento do projeto
Revises tcnicas
Auditoria
Resoluo de problema
Iniciao e definio do escopo
Planejamento
Execuo e controle
Reviso e avaliao
Concluso
Estabelecimento do processo
Avaliao do processo
Melhoria do processo
Estabelecimento da infra-estrutura
Manuteno da infra-estrutura
Desenvolvimento do material de treinamento
Implementao 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 alcanar diferencial competitivo, muitas empresas de todo o mundo,
inclusive do Brasil, vem usando a norma ISO/IEC 12207 como referncia em re-
60
captulo 2
lao aos seus processos, j que a globalizao da economia tem influenciado

as empresas produtoras e prestadoras de servios a atingirem nveis 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 producao de software a definir seus papeis, por meio de processos bem definidos, e assim proporcionar as organizacoes que a utilizam um melhor entendimento das atividades a serem executadas nas operacoes que envolvem, de
alguma forma, o software.
Os processos fundamentais inicialmente atendem a contratacao entre o adquirente e o fornecedor (aquisio e fornecimento) e a execucao do desenvolvimento, da operacao ou manutencao de produtos de software durante o ciclo de
vida do software (NOGUEIRA, 2003, p. 7).
O planejamento realizado de modo precrio nas empresas de desenvolvimento devido a ausencia constante de documentacao entre o desenvolvedor e
o adquirente, que est realizando a aquisio do produto ou do servio. A iluso
de pensarem que estas aes de planejamento, com especificaes adequadas
de requisitos, poderiam ser perda de tempo, traz uma resistencia em ambas
as partes interessadas em gerar documentacao, afetando todo o planejamento do projeto. Isto faz com que muitos desenvolvedores iniciem diretamente o
desenvolvimento (codificacao) e como consequncia, depois sao levados a um
processo interminvel de correcao e manutencao, causando um significativo
desgaste da relacao comercial entre as partes, alm do nao cumprimento dos
prazos de entrega e do custo do projeto que acumula prejuizos intangiveis, a
partir de estimativas aleatrias e inadequadas.
De maneira sinttica, os processos fundamentais envolvem o incio e execucao do desenvolvimento, operacao ou manutencao do software durante o seu
ciclo de vida (BARRETO JNIOR, 2014, p. 13). Para efeito de organizao, a 12207
divide os processos em quatro grandes famlias (WAZLAWICK, 2013, p. 40):
Aquisicao: visa a obtencao do produto ou servico relacionado a informatica que satisfaca as necessidades da empresa. Define as atividades do adquirente, bem como as necessidades de adquirir um produto, sistema ou servio de
software. Trata tambm da seleo do fornecedor.
Fornecimento: seu objetivo e fornecer um produto ou servico a terceiros.
Aqui definido as atividades do fornecedor e determina os procedimentos e
recursos necessrios.
captulo 2
61
Desenvolvimento: e definido como o processo de transformar um conjunto de requisitos em um produto executavel, definindo as atividades do desenvolvedor em anlise de requisitos, projeto, codificao, integrao, testes,
instalao e aceitao.
Operacao: tem como objetivo iniciar e manter o produto operando em
seu local definitivo, bem como prestar servicos aos usuarios. definido as atividades do operador, como a operao do produto de software e o suporte operacional aos usurios.
Manutencao: seu proposito 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 adaptao.
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 necessario para documentacao, gerencia de configurao,
garantia da qualidade, processo de verificacao, processo de validacao, revisao
conjunta, auditoria e resolucao de problemas.
Nogueira (2003, p. 9) ainda faz uma observao importante sobre a documentao do software e os processos de verificao e validao, relacionados
aos processos de apoio:
A documentacao do software sera a ultima tarefa que o desenvolvedor ira se preocupar,
sendo tratado como se nao tivesse que acontecer antes do desenvolvimento propriamente dito, a fim de ser possivel acompanhar se os requisitos do projeto foram atendidos ou se nem foram especificados no momento oportuno. Os processos de verificacao
e validacao ocorrem unilateralmente, ou seja, este requisito era obvio, nem precisava
mencionar, e para atender as necessidades do adquirente, este processo sera repetido
por inumeras vezes, alongando a manutencao e atrasando o funcionamento e atendimento as necessidades do negocio (NOGUEIRA, 2003, p. 9).
importante ressaltar que embora o objetivo dos processos de apoio seja

apoiar os processos fundamentais, nao sao eles que compoem as atividades
62
captulo 2
de desenvolvimento propriamente ditas. Os processos de apoio envolvidos sao

(WAZLAWICK, 2013, p. 40):
Documentacao: tem como proposito criar e manter informacoes sobre o
produto e o processo de desenvolvimento. Envolvem os registros de informaes do processo e atividade do ciclo de vida, de forma que estes documentos
possam ser distribudos a todos os envolvidos.
Gerencia de configuracao: seu objetivo e gerenciar e manter a consistencia entre todas as versoes dos produtos do trabalho, de forma a manter tambem
sua integridade. Para isto, necessrio realizar a identificao e definio dos
itens que iro compor o software, gerenciar e controlar as modificaes, alm
de garantir a integridade.
Garantia de qualidade: tem como objetivo garantir que os produtos e servicos estejam em conformidade com normas e padroes predefinidos, sendo
consistentes em relacao aos requisitos.
Verificacao: tem como proposito garantir ou confirmar que os produtos
refletem e atendem completamente os requisitos especificados.
Validacao: objetiva garantir ou confirmar que os requisitos especificados
sao os realmente desejados pelo cliente, validando o produto de software.
Revisao conjunta: tem como objetivo manter um entendimento comum
entre os diversos interessados a respeito do produto, do processo ou do servico.
As revises so realizadas nos nveis de gerenciamento e tcnico e so executadas durante toda a vigncia do contrato.
Auditoria: tem o propsito de prover uma avaliacao, independentemente
dos produtos e processos, determinando ainda uma adequao do produto aos
requisitos, planos e contrato.
Resolucao de problemas: objetiva assegurar que todos os problemas levantados sejam resolvidos, definindo um processo para analis-los e resolv
-los, bem como identificar tendncias de novas ocorrncias.
2.5 Processos organizacionais

Os processos organizacionais tem como propsito estabelecer e implementar
uma estrutura constituda pelos processos de ciclo de vida e pelo pessoal envolvido no desenvolvimento do software. Estes processos geralmente so em-
captulo 2
63
pregados fora do domnio de projetos e contratos especficos, no entanto, o

aprendizado a partir dos ensinamentos destes projetos e contratos muito contribuem para a melhoria da organizao, por meio dos processos de Gerncia,
Infra-estrutura, Melhoria e Treinamento (NOGUEIRA, 2003, p. 10).
O porte da empresa influencia no processo de gerncia, sendo que existem
casos em que poder existir uma pessoa responsvel e em outras situaes, o
prprio desenvolvedor pode assumir este papel de gerente. Note que, assumir
o papel no o mesmo que ter a funo. Assim, uma pessoa com a funo de
desenvolvedor poder assumir um papel de gerente, com responsabilidades
sobre o projeto, diferentemente de ser o gerente de projetos e executar prticas
pertinentes esta funo.
Sobre este assunto, Nogueira (2003, p. 10) comenta sobre a importncia da
figura do gerente:
Para implementar os processos de infra-estrutura, melhoria e treinamento, e fundamental a figura de gerencia que exercera acompanhamento das necessidades do projeto e seus devidos ajustes quanto a estrutura necessaria para um desenvolvimento
dentro dos requisitos do projeto, do dinamismo necessario para melhoria continua do
processo e os devidos treinamentos para adequacao das tecnologias especificadas
nos requisitos (NOGUEIRA, 2003, p. 10).
Segundo Barreto Jnior (2014, p. 14), os processos organizacionais implementam uma estrutura constituda de processo de ciclo de vida e pessoal associados, o que faz melhorar de forma contnua a estrutura da organizao e os
seus processos.
Desta forma, os processos organizacionais garantem o funcionamento da
organizacao. Sao eles (WAZLAWICK, 2013, p. 40):
Gerencia: visa organizar e controlar a realizacao dos projetos, bem como
seu desempenho, abrangendo as atividades genricas de gerenciamento. O gerente o responsvel pelo gerenciamento do produto, do projeto, das tarefas
de aquisio, fornecimento, desenvolvimento, operao, manuteno e apoio
e outras atividades relacionadas.
64
captulo 2
Infraestrutura: tem como objetivo manter um ambiente de trabalho adequado para qualquer outro processo, incluindo hardware, software, ferramentas, um conjunto de tcnicas, padres e recursos. So utilizados no desenvolvimento, operao e manuteno do software.
Melhoria: visa permitir que os processos sejam continuamente adaptados, visando a otimizacao do trabalho, por meio de atividades de medio,
avaliao, controle e melhoria de processos do ciclo de vida de software. Estes
processos so 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 possivel de suas funcoes. considerando ainda que outros processos so dependentes de pessoal qualificado.
2.6 Processos de Adaptao

Os processos de adaptacao definem as atividades necessarias para adaptar a
norma ISO/IEC 12207 para ser aplicada na organizacao ou em projetos. De acordo com Nogueira (2003, p. 10), a adaptacao deve ser executada com base em
alguns fatores que diferenciam uma organizacao ou projeto de outros, dentre
os quais a estrategia de aquisicao, modelos de ciclo de vida de projeto, caracteristicas de sistemas e software e cultura organizacional. Com a existencia dos
processos de adaptao, a organizao consegue adaptar a norma a qualquer
projeto desta ou em at mesmo ao modelo de ciclo de vida, cultura e tecnica de
desenvolvimento nela empregada.
Ainda, segundo Nogueira (2003, p. 10), tem-se notado um movimento das
empresas para adocao de normas e modelos de maturidade do processo de desenvolvimento de software, buscando melhor produtividade e com enfase em
promover uma reengenharia nos processos de desenvolvimento de software,
que ate entao eram basicamente vindos da experiencia dos desenvolvedores
de codigo e nao de gestores de projetos de grande expressao, e que assumem
papel de alta relevancia nas empresas para se obter vantagens competitivas
num mercado global que busca a informacao certa no momento certo.
Cada organizao possui seus fatores que a fazes diferenciar das outras,
abrangendo diferentes estratgias de aquisio, modelos de ciclo de vida de
projeto, caractersticas de sistemas e a cultura organizacional. Neste contexto,
captulo 2
65
pode-se mencionar ainda a norma ISO/IEC 15504, por tratar de qualidade e niveis de capacidade em processo de software. A norma 15504, tambem conhecida como SPICE, e considerada uma evolucao da ISO/IEC 12207 (WAZLAWICK,
2013, p. 41).
ATIVIDADES
01. Na sua opinio, quais seriam as principais dificuldades para uma empresa ou organizao implantar uma norma de qualidade de produtos de software? Justifique.
02. possvel 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 opinio 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.
REFLEXO
Vimos neste captulo que existem algumas normas de qualidade de produtos de software
que so fundamentais para as empresas seguirem padres e oferecerem produtos de qualidade com vantagem competitiva.
Ser que todas as empresas de desenvolvimento de software esto preparadas para
aplicarem normas de qualidade ou ainda aplicarem processos estruturados de acordo com
certos padres? Podemos notar que h a necessidade de um envolvimento de toda a empresa para que estas normas e padres sejam efetivadas dentro da organizao, sendo necessrio principalmente o apoio da alta gerncia e das diferentes reas funcionais.
Os processos fundamentais, de apoio, organizacionais e adaptativos so importantes
para que a empresa tenha uma estrutura slida e madura em relao aos seus processos, e
se isto ocorrer, ela est garantindo o resultado final principal que a produo de softwares
como produtos finais de qualidade.
66
captulo 2
LEITURA
Alm dos materiais e documentos das prprias normas de qualidade, h umam infinidade de
materiais e artigos relacionados elas, bem como captulos exclusivos em livros de Engenharia de Software em partes que tratam de qualidade de software e, naturalmente, nos livros
especficos deste assunto (Qualidade de Software).
Kiscianski, A.; Soares, M. S. Qualidade de Software. So Paulo: Novatec, 2007.
PRESSMAN, Roger S. Engenharia de Software, 7 edio. So Paulo: McGraw-Hill, 2011.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Prticas, 1a Edio, Elsevier, 2013.
Qualidade de Software - artigo de Jos Barreto Jnior 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 tcnica e
comparativa, de autoria de Bueno, C. F. S. e Campelo, G. B., ambos da UFPE.
http://migre.me/oKTyu
BARRETO JNIOR, J.; Qualidade de Software. Disponvel 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 gestao da qualidade Fundamentos e vocabulario, 2000.
NOGUEIRA, M. Qual a Importncia da Adoo da Norma ISO 12207 Nas Empresas de
Desenvolvimento de Software?. X SIMPEP. 2003. Disponvel em: <http://www2.dem.inpe.br/ijar/
ISO%2012207%20Artigo.pdf>. Acesso em: 18 dez 2014.
PRESSMAN, R. S. Engenharia de Software, 7 edicao. Sao Paulo: McGraw-Hill, 2011. 780p.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER K. C. Qualidade de Software: Teoria e Pratica. 1a.
Edicao. Editora Prentice Hall. Sao 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.
captulo 2
67
SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro: Guia Geral, Versao 1.0, 2005b.
Disponivel em: <www.softex.br/mpsbr>. Acesso em: 12 jan 2015.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Praticas, 1 Edicao, Elsevier, 2013. 506p.
68
captulo 2
3
Anlise e
Especificao de
Requisitos
A anlise e especificao de requisitos compem uma etapa de grande importncia e impacto no projeto de software. Veremos neste captulo sobre alguns
pontos que envolvem as etapas de projeto, partindo desde a sua descrio, o
entendimento das necessidades envolvidas, levantamento e especificao de
requisitos at a definio do software propriamente dito.
Muitos projetos se iniciam sem a devida clareza de seus requisitos e muitas
vezes estes so levantados a partir das necessidades dos clientes. Estes clientes,
por sua vez, tambm nem sempre esto 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 anlise prvia, bem estruturada, o uso de tcnicas adequadas para levantamento de
requisitos e a sua especificao, contribuem para o sucesso do projeto.
A especificao de requisitos determina e limita com maior segurana as
atividades que devero 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 captulo, poderemos aprofundar um pouco mais nos conceitos de requisitos de sistema e conseguiremos cada vez mais ampliar o nosso entendimento acerca da importncia e de suas aplicaes em projetos de
software.
Bons estudos!
OBJETIVOS
Abordar sobre a descrio do projeto do software.
Discutir a importncia e o entendimento das necessidades do projeto.
Aprender sobre levantamento de requisitos.
Aprender sobre a especificao dos requisitos.
Discutir a definio do software.
70
captulo 3
3.1 Introduo
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/usuario se a sua analise de requisitos tiver sido mal realizada, independente da precisao com a qual um software venha a ser projetado e implementado (MAZZOLA, 2010, p. 63).
De acordo com Mazzola (2010, p. 63), a Analise de Requisitos e uma tarefa
que envolve, antes de mais nada um trabalho de descoberta, refinamento, modelagem e especificacao das necessidades e desejos relativos ao software que
devera ser desenvolvido. A tarefa de anlise de requisitos envolve tanto o cliente como o desenvolvedor, que desempenharo um papel de grande importancia, cabendo ao cliente a formulacao (de modo concreto) das necessidades em
termos de funcoes e desempenho, enquanto que o desenvolvedor atua como
questionador, consultor e busca solucionar os problemas levantados.
A Anlise de requisitos uma etapa muito significativa no processo de desenvolvimento de um software, principalmente porque ela faz a associao entre os elementos que iro 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, estabeleca as interfaces do software com os outros elementos do sistema e tambm especificar as restricoes
de projeto (MAZZOLA, 2010, p. 63). Alm disto, ela ainda permite que engenheiros de software, analistas ou modeladores elaborem mais as necessidades basicas estabelecidas durante as tarefas de concepcao, levantamento e negociacao,
que fazem parte da engenharia de requisitos (PRESSMAN, 2011, p. 151).
3.2 Descrio do projeto do software

De acordo com Pressman (2011, p. 207), o projeto de software reside no nucleo
tecnico 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
avanar para a fase de construcao (geracao de codigo e testes).
Primeiramente, um projeto de software consiste na elaborao de uma proposta para a obteno de um contrato a fim da realizao do trabalho, incluindo a estimativa de custos e de cronograma (ZAMPAR e SOUZA, 2014).
captulo 3
71
O projeto e o incio de qualquer coisa ligada a engenharia, por exemplo, um engenheiro

civil nao manda construir um predio sem antes elaborar um planta, verificar o terreno
e outras coisas que denominamos de projeto, assim tambem e no desenvolvimento de
software voce nao 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 viavel, cria-se tambem 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 Gerencia de Projeto que e o primeiro
aspecto do projeto de software (FORCHESATTO, 2012, p. 12).
Qualidade a palavra que define a importancia do projeto de software, e

na etapa de Projeto em que a qualidade e incorporada na engenharia de software. O projeto nos fornece representacoes de software que podem ser avaliadas
e analisadas em termos de qualidade. A unica 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 existncia de projeto, aumenta-se o risco de construir um sistema instavel - um sistema que apresentar falhas quando forem feitas pequenas
alteracoes; um sistema com grande possibilidade de ser dificil de ser testado;
um sistema em que a qualidade qualidade nao pode ser avaliada ate uma fase
mais avancada 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
atraves do qual os requisitos sao traduzidos em uma espcie de planta para
construir o software. Inicialmente, a planta representa uma visao geral (holistica) do software. O projeto e representado em um alto nivel de abstracao - um
nivel que pode ser associado diretamente ao objetivo especifico do sistema e
aos requisitos mais detalhados de dados, funcionalidade e comportamento
(PRESSMAN, 2011, p. 209). medida em que as iteraes ocorrem, esta representao vai mudando mais para o baixo nvel, tornando-se cada vez mais prximo de especificaes que permitiro sua execuo, do ponto de vista do desenvolvimento das atividades.
72
captulo 3
Vale a pena salientar que o planejamento e o gerenciamento de projetos de

software abrangem produto, processo e pessoas que vo estar envolvidas no
projeto (ZAMPAR e SOUZA, 2014). As pessoas envolvidas e interessadas no projeto, como um todo, tambm so chamadas de stakeholders.
Stakeholder: uma palavra muito usada em vrias reas como administrao, 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 realizao.
A necessidade de gerenciamento um fator claro na distincao entre o desenvolvimento profissional de software e a programacao em nivel amador. De
acordo com Sommerville (2006, p. 60), o gerenciamento de projetos de software necessrio porque a engenharia de software profissional esta sempre
sujeita a restricoes de orcamento e de prazo. A organizao que desenvolve o
software que estabelece estas restries e o trabalho do gerente de projeto
de software deve garantir e assegurar que o projeto de software cumpra todas
essas restricoes e entregar um produto de software que contribua para as metas
da empresa. Segundo Zampar e Souza (2004), o gerente de software tem a funo de administrar os cronogramas e planos, para que no ocorram imprevistos no prazo e no oramento 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 srie de pontos e modos que podem tomar
o gerenciamento de software particularmente dificil. Sommerville (2006, p. 60)
cita algumas dessas diferencas:
captulo 3
73
1.
O produto e intangivel - O gerente do projeto de construo de um navio ou de
um projeto de engenharia civil pode ver o produto sendo desenvolvido. Se ha um atraso

na programacao, o efeito no produto e visivel. Partes da estrutura estao obviamente
inacabadas. O software e intangivel; nao pode ser visto ou tocado. Os gerentes de projeto de software nao podem ver o progresso, eles dependem de outras pessoas para
produzir a documentacao necessaria, a fim de examinar o progresso.
2.
No ha processo de software-padrao - Nao temos uma compreensao clara
das relacoes entre o processo de software e os tipos de produto. Nas disciplinas de

engenharia com longo historico, o processo e experimentado e testado. O processo de
engenharia para determinados tipos de sistema, como uma ponte, e bem compreendido. Nossa compreensao do processo ele software se desenvolveu significativamente
nos ultimos anos. Contudo, ainda nao podemos prever com certeza quando um processo de software especifico podera causar problemas de desenvolvimento.
3.
Grandes projetos de software sao, frequentemente, projetos nicos - Os
grandes projetos de software sao normalmente diferentes de projetos anteriores. Os

gerentes, portanto, na verdade, tem ampla experiencia anterior, que pode ser utilizada
para reduzir a incerteza nos planos. Consequentemente, e mais dificil prever problemas.
Alem disso, as rapidas mudancas tecnologicas em computadores e nas comunicacoes
desatualizam as experincias previas. As licoes aprendidas com essas experiencias
podem nao ser transferiveis para novos projetos.
Segundo Sommerville (2006, p. 61), impossvel dar uma descrio do trabalho-padro de um gerente de software, pois o trabalho varia muito, dependendo da organizao e do produto a ser desenvolvido. No entanto, a maioria
dos gerentes assume a responsabilidade, em algum estgio, por algumas das
seguintes atividades ou por todas elas, como:
elaboracao de propostas
planejamento e programacao de projetos
custo do projeto
monitoramento e revisoes de projetos selecao e avaliacao de pessoal
elaboracao de relatorios e apresentacoes
No planejamento de projeto so descritos as atividades que vo ser executadas, os marcos de referncias a serem atingidos e os produtos gerados por
um projeto. elaborado um plano para controlar o desenvolvimento e nele so
colocados os objetivos do projeto (ZAMPAR e SOUZA, 2014).
74
captulo 3
A gesto 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 gesto 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;
Documentao de papis e responsabilidades dos participantes;
Uma linguagem comum para comunicao das atividades do projeto,
bem como a rastreabilidade e relatrios dessas atividades;
Mecanismos de resoluo de conflitos e mitigao ou atenuao de riscos.
3.2.1 Plano de Projeto

De acordo com Silva Filho (2015), o plano de projeto um dos documentos produzidos na conduo de um projeto, funcionando como :
Um integrador entre diversas aes do projeto;
Mecanismo de comunicao para os stakeholders;
Captura e documenta a evoluo do projeto medida que ele vai sendo
executado e novas informaes vo sendo disponibilizadas.
O gerenciamento da execuo do plano de projeto tem o objetivo de realizar
o trabalho definido na descrio do escopo do projeto. Durante toda a execuo
do plano de projeto, o gerente de projeto se baseia nesse documento para tomar aes corretivas visando alcanar o conjunto de metas planejadas em concordncia com o que foi definido no plano. Nesse sentido, o plano de projeto
deve conter (SILVA FILHO, 2015):
Como os processos de gerncia sero utilizados;
Como as mudanas sero monitoradas e controladas;
Milestones com datas de pontos estratgicos para avaliao do projeto;
Baselines para cronograma, custo e qualidade;
Calendrio para recursos utilizados;
captulo 3
75
Mecanismos de comunicao para os stakeholders;

Definio de revises para resoluo de pontos em aberto e/ou pendentes;
Planos de outras reas de conhecimento (como, comunicao e qualidade).
O plano de projeto determinante para o sucesso de um projeto, pois ele
identifica os artefatos que devero ser entregues e quando e, igualmente importante, informa os recursos necessrios para realizar as entregas (de artefatos)
indicando as dependncias existentes para essas entregas (SILVA FILHO, 2015).
Conjunto de tarefas genericas para projeto

1.
Examinar o modelo do dominio de informacao e projetar estruturas de dados
apropriadas para objetos de dados e seus atributos.

2.
Usar o modelo de anlise, selecionar um estilo de arquitetura apropriada ao sof-
tware.
3.
Dividir o modelo de analise 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 funcoes de analise para cada subsistema.
4.
Criar um conjunto de classes ou componentes de projeto:

Traduzir a descricao de classes de analise em uma classe de projeto.
Verificar cada classe de projeto em relacao aos criterios de projeto; considerar
questoes de heranca.
Definir metodos e mensagens associadas a cada classe de projeto.
Avaliar e selecionar padroes 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 considerao, segundo Medeiros (2015):
76
captulo 3
1. Entendimento do Domnio da Aplicao 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
especfico a ser resolvido com o auxlio do sistema a ser desenvolvido;
3. Entendimento do Negcio onde busca o entendimento de como o sistema afetar a organizao e como contribuir para que os objetivos do negcio e
os objetivos gerais da organizao sejam atingidos; e por fim o
4. Entendimento das Necessidades e das Restries dos Interessados
onde entende-se as demandas de apoio para a realizao 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 execuo e
conduo 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 solucao possivel, descrever os requisitos de forma clara e
concisa e gerenciar as mudancas 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 usuario
e traducao destas necessidades em um futuro produto de software. De acordo
com Mello (2005), este processo pode ser dividido em cinco atividades:
1.
Levantamento (ou elicitao) de requisitos, que envolve a coleta organizada
dos requisitos de negcio;

2.
Anlise e negociao de requisitos, que procura catalogar e classificar os re-
quisitos em subconjuntos, negociar prazos de liberaes de acordo com a importncia

dos requisitos para o cliente;
3.
Especificao de requisitos, que documenta a funcionalidade do software, me-
tas de qualidade e restries que iro servir de base para o processo de desenvolvimento de software;
4.
Validao de requisitos, que verifica se todos os requisitos do sistema foram
declarados de forma no ambgua e em sintonia com as necessidades do cliente; e,

5.
Gesto de requisitos, que procura identificar, controlar e rastrear requisitos e
modificaes 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 especificao destes.
captulo 3
77
3.4 Levantamento de Requisitos

O levantamento de requisitos (tambm chamado elicitao de requisitos) envolve uma das principais partes do processo que ter como resultado o desenvolvimento de um software, pois esta a atividade responsvel por entender
aquilo que o cliente deseja ou necessita, ou ainda, aquilo que o cliente consegue enxergar como necessidade para o seu negcio.
De acordo com Pressman (2011, p. 133), no levantamento de requisitos h
uma combinao de elementos que abrangem a resolucao de problemas, elaboracao, negociacao e especificacao. Para estimular e encorajar uma abordagem colaborativa e orientada as equipes em relacao ao levantamento de requisitos, os interessados trabalham juntos para identificar o problema, propondo
elementos da solucao, negociando diferentes abordagens e especificando um
conjunto preliminar de requisitos da solucao.
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 usurios e clientes, informaes de domnio, sistemas j existentes na organizao, regulamentos vigentes, leis, etc, com o objetivo de entender a organizao como um todo, seus processos, necessidades,
possibilidades de melhorias e as restries existentes, preocupando-se na descoberta dos requisitos.
Existem diversas tcnicas que podem ser utilizadas para o levantamento de
requisitos, como por exemplo: entrevistas; questionrios; observao do ambiente e dos indivduos nas suas tarefas cotidianas na organizao; anlise de
documentos existentes na organizao; cenrio de interao entre o usurio
final e o sistema onde o usurio pode simular a sua interao com o sistema explicando para o analista o que ele est fazendo e de que informaes ele precisa
para realizar a tarefa; prototipagem onde uma verso preliminar do sistema,
muitas vezes no operacional e descartvel, apresentada ao usurio para capturar informaes especficas sobre seus requisitos de informao, observao
reaes; dinmica de grupo; e diversas outras tcnicas que tambm podem ser
empregadas (MEDEIROS, 2015).
A figura 3.1 apresenta um modelo generico do processo de levantamento e
analise. importante ressaltar que cada organizacao tera sua propria versao ou
uma versao mais definida desse modelo geral, dependendo de fatores locais,
como a pericia da equipe, o tipo de sistema em desenvolvimento, os padroes
utilizados, entre outros (SOMMERVILLE, 2006, 105).
78
captulo 3
As atividades do processo de levantamento de requisitos, segundo

Sommerville (2006, p. 105) sao:
Compreensao do dominio - Os analistas devem desenvolver sua compreensao do
dominio da aplicacao. 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 compreensao do dominio se desenvolve
mais durante essa atividade.
Classificacao - Essa atividade considera o conjunto nao estruturado dos requisitos
e os organiza em grupos coerentes.
Resolucao de conflitos - Quando multiplos stakeholders estao envolvidos, os requisitos apresentarao conflitos. Essa atividade se ocupa de encontrar e solucionar esses
conflitos.
Definicao das prioridades - Em qualquer conjunto de requisitos, alguns serao mais
importantes do que outros. Esse estagio envolve a interacao com os stakeholders, para
descobrir os requisitos mais importantes.
Verificacao de requisitos - Os requisitos sao verificados, a fim de se descobrir se
eles sao completos e consistentes e se estao em concordancia com o que os stakeholders realmente desejam do sistema.
Especificaes
dos requisitos
Validao dos
requisitos
Incio do
processo
Compreenso
do domnio
Priorizao
Coleta de
requisitos
Resoluo de
conflitos
Documento de
requisitos
Classficao
Figura 3.1 Processo de levantamento e anlise de requisitos. Fonte: Sommerville (2006

p. 106).
captulo 3
79
O levantamento e a analise de requisitos e um processo iterativo, com

feedback continuo de cada atividade para as outras, como pode ser observado
na figura X. O ciclo comeca com a compreensao do dominio e termina com a
verificacao dos requisitos. Com sito, a compreensao 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), sao:
O conhecimento do dominio do negocio encontra-se espalhado por diversos meios,
tais como: livros, sistemas existentes, manuais de operacao, envolvidos, etc.;
O tempo escasso e a disponibilidade dos envolvidos;
Fatores politicos e organizacionais, podendo nao ser muito clara sua existencia aos
envolvidos;
Os envolvidos nao 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), alem
dos itens dos principais problemas, citados acima, ha, principalmente no
Brasil, a instabilidade politica e social que faz com que os requisitos sejam frequentemente alterados, de forma muito dinamica.
Como vimos, existem vrias tcnicas para realizar o levantamento e anlise
dos requisitos, como entrevistas, leitura de documentos, questionrios, anlise
de protocolos, participao dos usurios, reuso de requisitos, prototipagem,
levantamento orientado a ponto de vista, cenrios, observao e anlises sociais ou etnografia. Veremos trs tcnicas relevantes e eficientes:
3.4.1 Levantamento orientado a ponto de vista

A concepo e utilizao de um sistema composto por vrios stakeholders,
sendo que cada um tem uma viso do sistema. A viso de um conjunto comum
de stakeholders chamada de ponto de vista.
Esta abordagem conhecida como anlise de multiperspectivas, e importante, pois no h uma nica maneira ou perspectiva de analisar um sistema e
80
captulo 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 servios
prestados pela biblioteca e seu impacto nos resultados;
2. Ponto de vista do atendente: preocupado na maneira de utilizao do
sistema para atender os clientes
3. Ponto de vista do usurio: preocupado em buscas eficientes e acesso ao
sistema via Internet;
4. Ponto de vista do Sindicato: preocupado nos efeitos da implantao do
sistema sobre a alterao no nvel de ocupao 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 reproduo, digitalizao e disponibilizao do contedo dos livros pelo sistema.
Os pontos de vista podem ser encarados de trs formas diferentes, como fontes ou drenos de dados, frameworks de representao e receptores de servios.
Quando os pontos de vista so responsveis por produzir ou consumir dados dizemos que eles so fontes ou drenos de dados. Neste caso a anlise envolve verificar quais dados so produzidos e consumidos e que suposies sobre
as fontes de dados so vlidas.
Os pontos de vista que representam tipos especficos de modelos de sistema so conhecidos como Frameworks de Representao. Eles podem ser comparados entre si para saber quais so os requisitos existentes usando uma nica representao.
Os pontos de vistas que so externos ao sistema e recebem seus servios so
conhecidos como receptores de servios.
Nesta tcnica utilizamos o mtodo VORD (Viewpoint Oriented Requisites
Definition) para obteno e anlise, a Figura 3.2 representa um esquema deste
mtodo.
captulo 3
81
Identificao dos
pontos de
Estruturao dos
vista
pontos de
Documentao dos
vista
pontos de
Mapeamento dos
vista
PV para o
sistema
Figura 3.2 Mtodo VORD.
O processo comea com a Identificao dos pontos de vista, os quais recebem servios do sistema, assim so identificados os servios fornecidos a cada
um.
Aps isso, inicia-se a estruturao dos pontos de vista agrupando-os
hierarquicamente.
Servios comuns so fornecidos em nveis mais altos na hierarquia e herdados por ponto de vista de nvel inferior. Feita a estruturao necessrio
revisar a documentao, refinando a descrio dos pontos de vista e servios
identificados.
Finalizada a documentao, deve-se transformar a anlise em um projeto
orientado a objetos, mapeando os pontos de vista no sistema planejado.
Durante a identificao do ponto de vista utilizam-se formulrios padres
para o ponto de vista para o servio, nas tabelas 3.3 e 3.4 so apresentados no
modelo.
Projeto orientado a objetos (POO) um tipo de projeto de sistema que leva em considerao a tecnologia de orientao a objetos.
Por ora, a orientao a objetos um paradigma de anlise, projeto e programao
de sistemas de software baseado na composio e interao entre diversas unidades
de software chamadas de objetos.
82
captulo 3
MODELO DE PONTO DE VISTA

REFERNCIA
Nome do ponto de vista.
ATRIBUTOS
Atributos que fornecem informaes sobre o ponto de vista.
EVENTOS
Referncia para um conjunto de cenrios de eventos descrevendo

como o sistema reage a eventos do ponto de vista.
SERVIOS
Referncia a um conjunto de descries de servio.
SUB_PVS
Nomes dos sub-pontos de vista.
MODELO DE SERVIO
REFERNCIA
Nome do servio.
RAZES
Razes pelas quais o servio fornecido.
ESPECIFICAO
Referncia para uma lista de especificaes de servio, que podem

ser expressas em diversas notaes.
PVS
Nomes de pontos de vista que recebem o servio.
REQUISITOS
Requisitos no funcionais que restringem o servio.
FORNECEDOR
Referncia a uma lista de objetos do sistema que fornecem os

servios.
Tabelas 3.3 e 3.4 Modelo de formulrios.
A identificao dos pontos de vista provavelmente o estgio mais difcil.

Aqui devem ser identificados todos os servios e ponto de vista do sistema. Uma
boa abordagem para isto realizao de um brainstorming (do ingls - tempestade de ideias). Um brainstorming nada mais do que uma reunio 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 ento responsvel por anotar os servios e pontos de vista,
referenciando as cores, por exemplo, preto para servio precisa parar. De vista,
Picada servio deve ser alocado um ponto de vista.
Com todos os servios e pontos de vista identificados e separados, deve-se
ento agrup-los e definir as entradas de cada um, organizando-os em hierarquia de herana. Depois de organizados detalham-se cada um utilizando-se as
tabelas apresentadas anteriormente.
captulo 3
83
3.4.2 Cenrios
Em algumas situaes mais fcil reunir analistas e usurios para simular situaes reais e necessrias no futuro sistema do que tentar estabelecer as necessidades por meio de outros mtodos mais abstratos. Para isto so usados os
cenrios.
Os cenrios servem para revelar detalhes que no foram percebidos e adicion-los aos esboos dos requisitos. O estabelecimento dos cenrios pode ser
feito informalmente com os analistas trabalhando com os usurios principais
ou fomentadores do projeto a fim de identificar os usurios operacionais e captar detalhes, ou outras formas.
Os cenrios so muito usados nos mtodos geis de desenvolvimento. Por
permitir um ambiente de simulao e ser simples, os envolvidos compreendem
facilmente o objetivo das sesses e atividades e conseguem assim avaliar, criticar e fazer sugestes tendo como consequncia a reorganizao dos componentes e tarefas do sistema. O interessante que os participantes podem ter conhecimentos e formaes heterogneas contribuindo assim para um ambiente
propcio de elicitao dos requisitos.
Desta forma, o cenrio permite que situao futuras possam ser previstas
pelos analistas e usurios levando a aes para trat-las no sistema e nos processos envolvidos.
Cenrios podem ser descritos de duas formas, como Cenrios de Eventos e
como Casos de Usos.
Cenrios de eventos podem ser usados para descrever como um sistema responde ocorrncia de um algum evento especfico, tal como iniciar uma transao. Cada evento distinto mostrado em um cenrio de evento separado.
Segundo Vord, h uma conveno diagramtica para cenrios de eventos.
Os cenrios de eventos devem conter os dados fornecidos e sadas, as informaes de controle, o processamento das excees e o prximo evento esperado.
Nele os dados de entrada so representados por Elipses. As informaes de
controle so setas que entram no topo da caixa, os dados saem pelo lado direito
da caixa. Excees so mostradas na base da caixa e o nome do prximo representado pela caixa com borda espessa. Assim mostra a figura 3.4.
84
captulo 3
Carto
Presente
Carto
PIN
Carto
Vlido
Nmero da
conta
Nmero da
conta
Tempo esgotado
Devolver carto
Carto invlido
Devolver carto
Carto roubado
Validar
usurio
PIN incorreto
Usurio OK
Nmero da
conta
Selecionar
servio
Informar PIN
PIN incorreto
Devolver carto
Reter carto
Figura 3.4 Diagrama de cenrio de eventos.
A maioria dos mtodos no inclui formas para descrever excees. No exemplo acima as excees so: tempo-esgotado, cliente no fornece PIN, carto invlido e carto roubado.
Casos de uso uma alternativa mais estruturada do uso de cenrios. Um
caso de uso representa uma unidade discreta da interao entre um usurio
(humano ou mquina) e o sistema. importante notar que no descreve como
o software dever ser construdo, mas sim como ele dever se comportar quando estiver pronto.
Casos de uso uma tcnica do padro UML que ser estudado no captulo
5, ele baseia-se em cenrios, identifica os atores em interao e descreve como
a interao ocorrer. Um conjunto de casos de uso deveria descrever todas as
possveis interaes com o sistema.
A UML (Unified Modeling Language) no uma metodologia de desenvolvimento e
est bastante relacionada com o paradigma de orientao a objetos que ser visto nas
prximas unidades tambm.
A UML permite que desenvolvedores visualizem os produtos de seus trabalhos em
diagramas padronizados por meio de uma notao grfica. uma notao independente de processos de software.
captulo 3
85
A figura 3.5 apresenta um diagrama com um caso de uso de um sistema de

biblioteca onde o usurio da biblioteca pode fazer o emprstimo do livro e administrar sua conta. O pessoal da biblioteca pode alterar cadastro e cadastrar
usurio e administrar o catlogo de livros. E o Fornecedor pode fornecer e cadastrar novos livros no catlogo de livros.
Usurio da
biblioteca
Servios de emprstimo
Administrao de usurio
Fornecedor
Pessoal da
biblioteca
Servios de catlogo
Figura 3.5 Casos de uso.
3.4.3 Etnografia
Etnografia consiste no estudo por vivncia 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 prtica um cientista social, externo organizao, passa algum tempo
analisando as atividades das pessoas e os processos da organizao, sem que
estas necessitem lhe explicar o seu trabalho. Este estudo geralmente mostra
com mais riqueza de detalhes o trabalho e os processos, em comparao com
as descries e modelos de sistema que por ventura possam existir.
O estudo etnogrfico mostra os requisitos derivados da maneira como as
pessoas realmente trabalham em vez da maneira como as definies sugerem
que elas deveriam trabalhar. Mostra tambm requisitos que so derivados da
cooperao e conhecimento das atividades de outras pessoas.
86
captulo 3
Entretanto ele no uma tcnica completa, e sempre deve ser usada com
outra tcnica de elicitao.
3.5 A especificao dos requisitos

A especificao , tambm outra fase importante, pois por meio dela que tanto o desenvolvedor quanto o cliente tero uma forma de documentar o que foi
acordado nas fases anteriores.
De modo objetivo, a especificao a descrio sistemtica e abstrata do
que o software deve fazer, a partir daquilo que foi analisado. Ela apresenta a
soluo de como os problemas levantados na anlise sero resolvidos pelo software. Tem como objetivo descrever de maneira sistemtica quais as propriedades funcionais so necessrias para resolver o problema do domnio. Alm dela
servir para este detalhamento da funcionalidade que dever ser implementada,
a especificao tambm a forma de comunicao sistemtica entre analistas
e projetistas do software (LEITE, 2000b).
Os softwares e sistemas computacionais, em sua maioria, so desenvolvidos
para sanarem uma necessidade existente no mundo real, levantadas e trazidas
pelo cliente ou por aqueles que compreendem o domnio do negcio em que
o problema a ser solucionado est inserido. Desta forma, modelar uma parte
do mundo real, bem como o domnio de aplicao em que este software estar inserido, uma atividade extremamente importante para se compreender a
necessidade e a importncia do sistema a ser construdo e definir os requisitos
que tornam o sistema til.
Neste contexto, imprescindvel conhecermos o significado de requisitos.
De acordo com Leite (2000b), requisitos so objetivos ou restries estabelecidas por clientes e usurios do sistema que definem as diversas propriedades do sistema. Os requisitos de software so, 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 condio ou
capacidade necessria que o software deve possuir para que o usurio possa
resolver um problema ou atingir um objetivo ou para atender as necessidades
ou restries da organizao ou dos outros componentes do sistema (LEITE,
2000b).
captulo 3
87
Sommerville (2006, p. 82) traz ainda algumas outras definies sobre requisitos, como os requisitos do usurio e requisitos de sistema, alm de apresentar sua
definio sobre especificao de projeto de software, como pode ser visto abaixo:
1.
Requisitos do usurio so declaraes, em linguagem natural e tambm em
diagramas, sobre as funes que o sistema deve fornecer e as restries sob as quais
deve operar.
2.
Requisitos de sistema estabelecem detalhadamente as funes e as restri-
es de sistema. O documento de requisitos de sistema, algumas vezes chamado de

especificao funcional, deve ser preciso. Ele pode servir como um contrato entre o
comprador do sistema e o desenvolvedor do software.
3.
Especificao de projeto de software uma descrio abstrata do projeto
de software que uma base para o projeto e a implementao mais detalhados. Essa
especificao acrescenta mais detalhes especificao de requisitos do sistema.
(SOMMERVILLE, 2006, p. 82)
Estes dois tipos de requisitos apresentam diferentes nveis de especificao

de sistema. Isto muito til porque comunicam informaes sobre o sistema
para diferentes tipos de leitores (usurios e desenvolvedores). A Tabela 3.5 ilustra a diferena entre os requisitos de usurios e os de sistemas, mostrando como
um requisito de usurio pode ser expandido em diversos requisitos de sistema,
j que estes trazem um maior detalhamento das funes e restries de sistema.
Os requisitos do usurio so escritos para gerentes do cliente e dos fornecedores que, geralmente, no possuem um conhecimento tcnico detalhado do
sistema, como pode ser visto na figura 7. Por outro lado, a especificao de requisitos de sistema deve ser destinada aos profissionais tcnicos de nvel snior e
os gerentes de projeto envolvidos. Novamente, ela ser utilizada pelo gerente do
cliente e do fornecedor. Nada impede que os usurios finais de sistemas possam
ler ambos os documentos. Assim, a especificao de projeto de software um
documento orientado implementao. Ele deve ser escrito para os engenheiros
de software que desenvolvero 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
identificacao do tipo de requisito auxilia no tratamento especifico a ele ofertado, de forma a garantir coesao e agilidade na traducao tanto para quando da
88
captulo 3
especificacao de requisitos (FAGUNDES,2011, p. 9). Estes requisitos podem ser

divididos em requisitos funcionais e requisitos no funcionais.
Definio dos requisitos do usurio
1.
O software deve permitir acesso a arquivos remotamente pela internet.
Especificao dos requisitos de sistema

1.
O usurio deve ter a possibilidade de definir o tipo dos arquivos que sero 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 especfico para cada tipo de arquivo.
4.
Devem ser fornecidos recursos para o cone que representa um arquivo, a ser
definido pelo usurio.

5.
Quando um usurio seleciona um cone que representa um arquivo, o efeito dessa
seleo aplicar a ferramenta associada com o tipo de arquivo ao arquivo representado

pelo cone selecionado.
Tabela 3.5 Requisitos do usurio e do Sistema. Fonte: Adaptado de Sommerville (2006, p. 83).
Requisitos
do usurio
Gerentes de clientes
Usurios finais de sistemas
Engenheiros do cliente
Gerentes do fornecedor
Arquitetos de sistemas
Requisitos
do sistema

Desenvolvedores de software
Especificao
de projeto
de software

Desenvolvedores de software
Figura 3.6 Leitores de diferentes tipos de especificaes. Fonte: SOMMERVILLE (2006,

p. 83).
captulo 3
89
3.5.1 Requisitos funcionais e no funcionais

Segundo Sommerville (2006, p. 83), os requisitos de sistema de software so,
freqentemente, classificados como funcionais ou no-funcionais ou como requisitos de domnio:
Requisitos funcionais: So declaraes de funes que o sistema deve fornecer,
como o sistema deve reagir a entradas especficas e como deve se comportar em
determinadas situaes. Em alguns casos, os requisitos funcionais podem tambm explicitamente declarar o que o sistema no deve fazer.
Requisitos no-funcionais: So restries sobre os servios ou as funes oferecidos pelo Sistema. Entre ele: destacam-se restries de tempo, restries sobre o
processo de desenvolvimento, padres, entre outros.
Requisitos de domnio: So requisitos que se originam do domnio de aplicao do
sistema e que refletem caractersticas desse domnio. Podem ser requisitos funcionais
ou no funcionais.
Sommerville (2006, p. 84) ainda afirma que a distino entre esses diferentes tipos de requisitos no to clara como sugerem essas definies simples.
Para exemplificar, pode-se imaginar um requisito de usurio relacionado
proteo. Inicialmente, parece ser um requisito no funcional. No entanto,
quando desenvolvido com mais detalhes, pode levar a outros requisitos que
so claramente funcionais, como a necessidade de incluir recursos de autorizao de usurios no sistema. Assim, embora seja til classificar os requisitos de
maneira quando os discutimos, devemos lembrar que essa , na verdade, uma
distino artificial.
3.5.1.1 Requisitos funcionais
Os requisitos funcionais definem uma funo que dever existir no sistema,
descrevendo a funcionalidade desejada ou os servios que se espera que o sistema fornea. O termo funo usado no sentido genrico de operao que
pode ser realizada pelo sistema, seja por meio de comandos dos usurios ou
seja pela ocorrncia de eventos internos ou externos ao sistema (LEITE, 2000b).
90
captulo 3
Eles dependem do tipo de software que est sendo desenvolvido, dos usurios
de software que se espera verificar e do tipo de sistema que est sendo desenvolvido. Quando expressos como requisitos de usurio, eles so normalmente
descritos de um modo bastante geral, mas os requisitos funcionais de sistema
descrevem a funo de sistema detalhadamente, suas entradas e sadas, excees etc (SOMMERVILLE, 2006, p. 84).
Aqui podemos citar alguns exemplos de requisitos funcionais:
o sistema deve permitir calcular a receita diria, semanal, mensal, trimestral, semestral e anual das compras efetuadas durante estes perodos.
o software dever realizar notificaes por email a cada compra efetuada.
os participantes do curso podero emitir seus certificados online em formato PDF.
dever existir um bloco no alto e direta da tela para o usurio efetuar
login no sistema.
importante salientar que o a especificao de um requisito funcional tem
como objetivo determinar o que se espera que o software ou sistema faa, sem
se preocupar neste momento em como ele ir fazer esta ao ou solicitao. De
acordo com Leite (2000b), importante diferenciar a atividade de especificar
requisitos da atividade de especificao que ocorre durante a fase de desenho
(design) do software, pois nesta fase deve-se tomar a deciso de quais sero as
funes que o sistema efetivamente ter para satisfazer quilo que os usurios
desejam. Outro ponto que merece ser lembrado que estes requisitos funcionais tero diferentes nveis de detalhamento, de acordo com a sua destinao,
como descritos no documento de especificao entre requisitos de usurios e
requisitos de sistema.
3.5.1.2 Requisitos no-funcionais
Requisitos no-funcionais esto relacionados ao uso do sistema e quanto s
qualidades globais de um software, como manutenibilidade, confiabilidade,
usabilidade, desempenho, segurana, disponibilidade, custos e vrias outras
como tambm as tecnologias envolvidas. Normalmente estes requisitos so
descritos de maneira informal, podendo ainda ser controversos (por exemplo,
o gerente quer segurana mas os usurios querem facilidade de uso) e difceis
de validar (LEITE, 2000b).
captulo 3
91
Alguns exemplos de requisitos no-funcionais podem ser vistos na tabela 3.6:

ID
RNF01
RNF02
RNF03
RNF04
RNF05
RNF06
REQUISITOS NO-FUNCIONAIS
TIPO
Nao poderao ocorrer perdas de informacoes
Segurana
Visitantes annimos no podero ter acesso Extranet
Segurana
Um perfil de usurios pode ter mais de um tipo de permissao
Segurana
O sistema dever comportar com velocidade satisfatria
Desempenho
O sistema dever ter alta disponibilidade
Confiabilidade
O sistema dever ser executado em qualquer navegador
Usabilidade
Tabela 3.6 Requisitos no-funcionais.
Leite (2000b) faz uma importante observao ao tratar que a necessidade de

se estabelecer os requisitos de forma precisa crtica na medida que o tamanho
e a complexidade do software aumentam, pois os requisitos exercem influncia
uns sobre os outros. Para ilustrar esta situao, 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 no seja satisfeito, pois programas em Java so, em geral, mais lentos.
3.6 A definio do software

A definio do software representa a definio de todos os seus componentes.
Uma vez estabelecido seus requisitos, suas funcionalidades e todos os seus
componentes, alm dos domnios da regra de negcio de onde ele estar inserido, o software tem a sua definio e quanto mais claro isto for, melhor para o
negcio e para todos os envolvidos.
A fase de definio do software ocorre em conjunto com outras atividades
como a modelagem de processos de negcios e anlise de sistemas, mais no
incio dos processos de desenvolvimento de software. Nesta atividade, diversos
profissionais buscam conhecer a situao atual e a identificar os problemas
para que possam elaborar propostas de soluo de sistemas computacionais
que resolvam tais problemas levantados ou conhecidos. Dentre as propostas
apresentadas, deve-se fazer um estudo de viabilidade, incluindo anlise custo
-benefcio, para que seja decidido qual soluo ser a escolhida (LEITE, 2007).
O resultado desta atividade deve incluir a deciso realizada entre a aquisio ou desenvolvimento do sistema, devendo ainda indicar informaes sobre
92
captulo 3
hardware, software, pessoal, procedimentos, informao e documentao.

Desta forma, a deciso tenha sido tomada pelo desenvolvimento do sistema,
no escopo da engenharia de software, necessrio 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 definio do software conta tambm com os profissionais
de engenharia de software, visando identificar os requisitos de software e modelos de domnio que sero utilizados na fase de desenvolvimento (codificao).
Leite (2007) ressalta que, alm destes pontos, o engenheiro pode vir a elaborar
um plano de desenvolvimento de software, a partir dos requisitos, indicando
em detalhes os recursos necessrios (humanos e materiais), bem como as estimativas de prazos e custos (cronograma e oramento). Outro ponto apontado pelo autor que no existe um consenso sobre o que caracteriza o final da
fase de definio do software, de forma clara. Isto pode variar de acordo com
o modelo de processo de desenvolvimento adotado. Em algumas propostas, a
fase de definio considerada concluda com a apresentao da proposta de
desenvolvimento apenas. Em outros modelos de processo, considera que o software apenas est completamente definido com a especificao de requisitos e
com a elaborao 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 definio no esteja ainda completamente concluda.
ATIVIDADES
01. Cite pelo menos 3 problemas que podem ocorrer durante a atividade de levantamento
de requisitos.
02. Explique a tcnica de levantamento de requisitos baseada em cenrios e d um exemplo.
03. Cite um exemplo de requisito no-funcional e explique o seu conceito.
04. A elicitao dos requisitos a tarefa de comunicar-se com os usurios e clientes para
determinar quais so os requisitos de sistema. Analise a frase abaixo, referente requisitos
de software especificados para um sistema de gesto de pessoal, expresso por um cliente:
captulo 3
93
necessrio que o software calcule os salrios dos diaristas e mensalistas e emita

relatrios mensais sumarizados por tipo de salrio. Entretanto, a base de dados deve estar
protegida e com acesso restrito aos usurios autorizados. De qualquer forma, o tempo de
resposta das consultas no deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatrios individuais dos departamentos,
nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente em
razo dos adiantamentos e vales que recebem. fundamental que o software seja operacionalizado usando cdigo aberto. Necessito, ainda, forte gerenciamento de risco, prazo e
custo, porque a entrega do produto final no pode ultrapassar o prazo de oito meses a contar
da data de incio do projeto.
Assinale a alternativa que contm apenas requisitos funcionais:
a) emita relatrios mensais sumariados por tipo de salrio e necessito, ainda, forte gerenciamento de risco, prazo e custo.
b) necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de dados deve
estar protegida e com acesso restrito aos usurios autorizados.
c) calcule os salrios dos diaristas e mensalistas e os relatrios individuais dos departamentos, nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente.
d) a base de dados deve estar protegida e com acesso restrito aos usurios autorizados e
entrega do produto final no pode ultrapassar o prazo de oito meses.
e) fundamental que o software seja operacionalizado usando cdigo aberto e emita relatrios mensais sumariados por tipo de salrio.
05. Defina o que so requisitos, com suas palavras.
REFLEXO
Um projeto de software pode ser mais complexo do que aparenta. Definir o software tambm
pode ser uma tarefa rdua e no to simples como inicialmente pode parecer ser. Compreender bem as necessidades do projeto, levantar com preciso os requisitos e ter certeza que
todos os requisitos foram levantados, lembrados, considerados e bem descritos, por meio de
sua especificao, pode ser algo que nem sempre seja possvel de se realizar. Em muitos
projetos, nem mesmo o cliente sabe ao certo o que ele quer e mesmo que saiba, lidamos
com requisitos volteis, sujeitos a alteraes no decorrer do projeto e desdobramentos de
situaes inesperadas ou no previstas.
94
captulo 3
O levantamento e a especificao de requisitos so fundamentais para o sucesso de

um projeto de software, afinal, por meio deles que os requisitos sero definidos e consequentemente as atividades sero distribudas 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 mtodo escolhido, com tcnicas
de levantamento de requisitos, documentao 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 negociaes com o cliente antes
e durante todo o processo.
Assim, podemos considerar que a anlise e especificao de requisitos so 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 vrios retrabalhos.
LEITURA
Em geral, a maioria dos livros de engenharia de software so excelentes fontes de estudo na
rea da engenharia de requisitos, envolvendo suas tcnicas de levantamento, especificao
e tudo o que necessrio para a definio do software.
PRESSMAN, Roger S. Engenharia de Software, 7 edio. So Paulo: McGraw-Hill,
2011.
MACHADO, F. N. Anlise e gesto de requisitos de software: onde nascem os sistemas. So Paulo: rica, 2011.
LIMA, A. S. UML 2.0: do requisito soluo. So Paulo: rica, 2009.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Prticas, 1a Edio, Elsevier,
2013.
FAGUNDES, R. M., Engenharia de Requisitos - Do perfil do analista de requisitos ao
desenvolvimento de requisitos com UML e RUP. Salvador, 2011. 216p.
captulo 3
95
FORCHESATTO, A. L.; Apostila Engenharia de Software. UNOESC. 2012. 43p.

LEITE, J. C.; Anlise e Especificao de Requisitos. 2000b. Disponvel 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. Disponvel 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. Disponvel em: <http://www.
dimap.ufrn.br/~jair/ES/c2.html>. Acesso em: 10 dez 2014.
MAZZOLA, V. B. Engenharia de Software - Conceitos Bsicos, Apostila, 2010. Disponvel em:
<https://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf>. Acesso em: 17
dez 2014.
MEDEIROS, H.; Introduo a Engenharia de Requisitos. Disponvel 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. Cin. Empresariais da UNIPAR, Toledo, v.6, n.1, 2005. 97-111p.
SANTOS, J. H. A.; Gerncia de Mudanas de Requisitos: uma proposta de aplicao a um
estudo de caso. Mestrado. UFRGS. 2004. 107p. Disponvel 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. Disponvel
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 edicao. Editora Pearson do Brasil, 2003. 292p.
ZAMPAR, F.; SOUZA, K.; Gesto de projeto e a metodologia ITIL. Disponvel em: <http://www.
devmedia.com.br/gestao-de-projeto-e-a-metodologia-itil/25617>. Acesso em: 08 dez 2014.
96
captulo 3
4
Gerenciamento de
Requisitos
Neste captulo estudaremos sobre o gerenciamento de requisitos, envolvendo

suas mudanas, a rastreabilidade destes requisitos, bem como a gerncia da
qualidade de requisitos e validao.
Como discutimos no captulo anterior, alguns requisitos no so totalmente estveis e estes so passveis de mudanas ou alteraes ao longo do ciclo
de desenvolvimento do software. Existem muitas causas para estas mudanas
ou alteraes nos requisitos, podendo envolver falta de clareza inicial por parte do cliente, falta de clareza das regras de negcio de onde o software estar
inserido, mudanas de leis ou fatores externos e ainda a descoberta de novas
funcionalidades no previstas inicialmente ou ajustes requisitos que foram
definidos inicialmente.
Para estas mudanas, alteraes, adies e at mesmo excluso de requisitos, necessrio que haja uma eficiente gesto destes requisitos, bem como o
controle das mudanas, sabendo e sendo possvel 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.
Aps todo o processo de gerenciamento de requisitos e gerenciamento das
mudanas, necessrio ainda que se tenha um bom controle da gerncia da
qualidade destes requisitos, bem como um processo seguro e que atendas ambas as partes do projeto envolvendo a validao destes requisitos.
Vamos l?!
OBJETIVOS
Aprender sobre o gerenciamento de requisitos.
Compreender o gerenciamento de mudanas.
Conhecer sobre rastreabilidade de requisitos.
Aprender sobre gerncia da qualidade de requisitos.
Conhecer a validao de requisitos.
98
captulo 4
4.1 Introduo
Uma das atividades fundamentais no desenvolvimento de software a etapa de
Gerenciamento de Requisitos. Os Requisitos so essenciais para a definio da
arquitetura do sistema, para a implementao e validao do sistema final.
um processo de controle do desenvolvimento, tendo como referncia a baseline de requisitos. Assim, durante este processo so mantidos planos, artefatos e
atividades de desenvolvimento consistentes com os requisitos definidos para o
software (SAYO e BREITMAN, 2014 , p. 1).
O gerenciamento de requisitos deve manter um controle padro sobre implementaes e manutenes, de forma que as demandas dos clientes e usurios possam ser atendidas em todas as fases do projeto, garantindo a excelncia
do produto (De BONA e SANTOS, 2012)..
Na Gerencia de Requisitos os requisitos necessarios para a construcao do
produto devem ser entendidos, documentados, revisados e controlados, tanto
quanto a sua inclusao, mas, principalmente, quanto as modificacoes. O controle possibilita trabalhar com estimativas de realizacao 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 alteraes 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 modificaes em qualquer poca do
desenvolvimento.
O Gerenciamento de Requisitos e uma area 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 solicitacao (SANTOS, 2004, p. 29).
No processo de desenvolvimento de software as modificaes nos requisitos ocorrem sistematicamente, desde o levantamento de requisitos at durante
a operao do sistema em produo. Isso se justifica pois h o aparecimento de
erros, conflitos, inconsistncia nos requisitos, novas demandas e prioridades
captulo 4
99
dos clientes, problemas tcnicos, mudanas no negcio, concorrentes, mudanas no ambiente externo e no ambiente de software, bem como possveis mudanas organizacionais (MEDEIROS, 2015).
H, durante o processo de desenvolvimento e operacao de software, o possvel e provvel surgimento de novos requisitos e a necessidade de mudancas
nos requisitos existentes. Este processo, tambem conhecido como evolucao
de sistemas, acontece como resultado de mudancas no meio ambiente onde o
proprio sistema de software esta inserido. Se o macrosistema muda os sistemas
de software devem acompanhar esta mudanca ou ficarao cada vez menos uteis
(SAYO e BREITMAN, 2014 , p. 5).
O gerenciamento dos requisitos visa, justamente, dirimir problemas ocasionados por estas mudanas. O Processo de Gerencia de Requisitos envolve
atividades que ajudam a equipe a identificar, controlar e rastrear requisitos e
gerenciar mudanas de requisitos em qualquer momento ao longo do ciclo de
vida do software (MEDEIROS, 2015).
A primeira etapa a identificao de novo requisito, com o uso de tabelas
de rastreamento, que identificam como os requisitos novos interagem com os
requisitos ou funes j existentes.
Devido a novas necessidades do negcio ou melhora na compreenso do
sistema e dos requisitos, usual que surjam novos requisitos durante o processo. Alm de alteraes nos requisitos podem ocorrer mudanas nas prioridades
dos requisitos, devido a mudanas nos pontos de vista e alteraes no negcio
durante o desenvolvimento.
Os requisitos podem ser divididos em dois grupos:
Requisitos permanentes: so requisitos estveis. Derivam da atividade
principal e por isso no sofrem alteraes durante o processo. Ex: requisitos do
sistema hospitalar - mdico, pacientes, etc.
Requisitos volteis: so requisitos que podem mudar durante ou depois
do desenvolvimento. Ex: Polticas governamentais sobre assistncia mdica.
Para Sommerville (2007), os requisitos volteis podem ser cartacterizados
como mutveis, emergentes, consequentes e de compatibilidade.
Mutveis: se modificam por causa das mudanas, do ambiente no qual a
empresa est operando.
100
captulo 4
Emergentes: surgem medida que a compreenso do sistema evolui durante o desenvolvimento.

Consequentes: resultam da introduo do sistema computacional.
Compatibilidade: dependem de sistemas ou processos especficos das
organizao.
No h um processo ideal para as organizaes, mas processos adaptados e
apropriadas para cada realidade, permitindo orientaes mais precisas e reduzindo a probabilidade de erros e esquecimentos. Adaptar um processo para as
necessidades internas sempre a melhor escolha ao invs de impor um processo organizao (MEDEIROS, 2015).
O planejamento o primeiro estgio do processo de gerenciamento de requisitos. um estgio dispendioso, sendo que para cada projeto h o estabelecimento do nvel de detalhes exigidos para o gerenciamento de requisitos.
Durante o estagio de gerenciamento de requisitos, decide-se sobre:
Identificacao de requisitos - Cada requisito precisa ser identificado de modo unico,
para que possa ser feita a referencia cruzada deste com os outros requisitos e para que
ele possa ser utilizado nas avaliacoes de facilidade de rastreamento.
Processo de gerenciamento de mudancas - Trata-se do conjunto de atividades
que avalia o impacto e o custo das mudancas.
Polticas de facilidade de rastreamento - Essas politicas definem as relaes entre os requisitos e entre os requisitos e o projeto de sistema que devem ser registrados
e tambm como esses registros devem ser mantidos.
Suporte de ferramentas CASE - O gerenciamento de requisitos envolve processar
uma grande quantidade de informaes sobre os requisitos. As ferramentas que podem ser utilizadas vo desde sistemas especializados de gerenciamento de requisitos
ate planilhas de clculo e sistemas simples de bancos de dados.
O gerenciamento de requisitos demanda um apoio automatizado e na fase

de planejamento que as ferramentas CASE utilizadas devem ser escolhidas. O
apoio de ferramentas e necessario para:
captulo 4
101
Armazenamento de requisitos - Os requisitos devem ser mantidos em um deposito de dados seguro, gerenciado, que seja acessivel por todos os envolvidos no processo
ele engenharia de requisitos.
Gerenciamento de mudancas - Esse processo e simplificado se o apoio de ferramentas ativas estiver disponivel.
Gerenciamento de facilidade de rastreamento - Como foi discutido antes, o apoio
de ferramentas para a rastreabilidade permite que so descobertos requisitos relacionados. Estao disponiveis algumas ferramentas que utilizam tecnicas de processamento
de linguagem natural, para ajudar a descobrir as possiveis relacoes entre os requisitos.
Requisitos segundo Agilistas

[...] a corrente agilista defende a simplificacao dos requisitos, legando todo detalhamento a acordos tacitos firmados com o cliente, que deve ter presenca constante. Essa
escola defende a definicao simplificada das funcionalidades pelo uso de Historias de
Usuario.
A forma dada a essas historias assemelham-se muito a maneira como os Casos
de Uso eram descritos em seu principio, numa fase pre-UML que costumo chamar de
gestacional (dos Casos de Uso), quando surgiram estudos propondo a Analise Orientada a Objetos. Consiste na identificacao do ator seguido da acao que ele deseja realizar,
seguido das regras de negocio vigentes sobre aquele uso.
Essa e uma forma simplificada e mais livre de redigir. Porem, o preco dessa liberdade e a abertura a ambiguidades, indefinicoes e ate mesmo historias descritas exaustivamente. Esta ultima tendo sido a maior queixa sobre Casos de Uso, abrindo espaco
para o surgimento da tecnica de Historias de Usuario.
Todavia, num cenario em que os problemas nao se apresentem e a descricao seja
realmente resumida, esse conjunto de historias sao, em verdade, uma lista das necessidades do cliente, aproximando-se da visao do sistema. Isso exatamente porque nao se
deseja, com as historias, obter uma descricao detalhadas de todos os usos.
Por ser representada mais por uma corrente do que por um processo definido, nao
ha declaracao formal sobre como obter as informacoes, embora seja mais difundido o
uso de mapas mentais para orientar as partes interessadas nessa atividade.
(FAGUNDES, 2011, p. 22 )
102
captulo 4
Neste artigo voc pode encontrar ferramentas que auxiliam no controle do gerenciamento de requisitos:
http://migre.me/oIEKM
Neste outro artigo, alm de abordar as normas de qualidade utilizadas em desenvolvimento de softwares, no final h tambm uma anlise de ferramentas para a gesto
de requisitos e mudanas:
http://migre.me/oIEZg
4.3 Gerenciamento de mudanas

As mudanas em um ambiente de desenvolvimento so inevitveis. Quando o
sistema ainda est sendo desenvolvido os requisitos continuam mudando. As
razoes para mudancas sao de varios tipos, entre outras (SAYO e BREITMAN,
2014 , p. 6):
Os sistemas so complexos e isso impe mudanas
Requisitos equivocados ou mal definidos devem sofrer ajustes ao longo
do processo de desenvolvimento,
Mudancas no ambiente: regras de negocios, leis, politicas internas,
Adio de novas funcionalidades mais avancadas com o intuito de criar
vantagens,
Mudanas tecnolgicas,
Mudanas no comportamento dos clientes.
O fato que os sistemas de informao devem evoluir constantemente,
de maneira que atenda s necessidades de seus usurios no atual ambiente
corporativo.
Este fenomeno e particular a sistemas de informacao e foi destacado por
Manny Lehman. Este tipo de sistema, tambem conhecido como sistema
do tipo E (evolutionary) se caracteriza por, uma vez instalado, tornar-se parte do meio ambiente e acabar alterando seus proprios requisitos (SAYO e
BREITMAN, 2014 , p. 6).
captulo 4
103
A mudanca nos requisitos e denominada de volatilidade; a gerncia de requisitos tem como parte das suas atividades controlar mudancas. O CMM define mudancas como: As alteracoes que precisam ser feitas nos requisitos e artefatos de software.
E necessrio que as alteracoes dos requisitos sejam:
Identificadas e avaliadas
Avaliadas considerando o risco
Documentadas
Planejadas
Comunicadas aos grupos e individuos envolvidos
Acompanhadas ate a finalizacao
O gerenciamento de mudancas de requisitos (figura 4.1) deve ser aplicado a
todas as mudancas propostas para os requisitos. O benefcio de se ter um processo formalizado para gerir as mudanas que, desta forma, todas as propostas de mudanas so tratadas de maneira consistente e de forma controlada.
Ha tres estagios principais em um processo de gerenciamento de mudancas
(SOMMERVILLE, 2006, p. 121):
6. Analise do problema e especificacao da mudanca - O processo comeca
com uma proposta de mudana ou com a identificacao de um problema com os
requisitos. Nesse estagio, e realizada a anlise do problema ou da proposta de
mudanca, a fim de verificar sua validade.
7. Analise e custo da mudanca - O efeito da mudanca proposta e avaliado,
de acordo com a facilidade de rastreamento e o conhecimento geral dos requisitos do sistema. O custo da mudanca e estimado de acordo com as modificacoes no documento de requisitos, no projeto de sistemas e na implementacao.
Concluindo essa etapa, decide-se sobre prosseguir com a alteracao de requisitos ou nao.
8. Implementao de mudanas - O documento de requisitos e, se necessario, o projeto de sistema e a implementacao sao modificados. De modo a facilitar, o documento de requisitos deve ser organizado, bem como os programas,
minimizando referencias externas e tornando as secoes do documento tao modulares quanto possivel.
104
captulo 4
Problema identificado
Anlise do
problema e
especificao
da mudana
Anlise e custo
da mudana
O processo de gerenciamento demanda um conjunto de tarefas que proporcionem o gerenciamento

e mapeamento entre as dependncias dos requisitos e as solicitaes de modificaes e/ou incluses
(SANTOS, 2004, p. 18).
Em funo de possveis divergncias na percepo do projeto, podem ocorrer problemas na dificuldade, por parte de analistas de requisitos e de
negcios, de se estabelecer o entendimento com as
partes interessadas sobre o tratamento de definies
posteriores de requisitos ou alterao de escopo da
soluo (FAGUNDES, 2011, p. 206).
Implementao de
mudanas
Figura 4.1 Gerenciamento de mudanas de requisitos.

Requisitos revisados
Fonte: (SOMMERVILLE, 2006, p. 122).
Na viso do cliente, qualquer resoluo sobre o projeto que facilite que este
cumpra sua misso bem vinda, incluindo alteraes. Porm para os desenvolvedores no assim:
j para a equipe de desenvolvimento, o objeto e tudo aquilo que foi definido no projeto
e alteracoes de escopo demandam necessariamente renegociacao de prazo e custo modificacoes que nao impliquem mudanca do escopo sao toleraveis, mas podem ser
sujeitas, sob a otica do desenvolvedor, a mudancas no cronograma em funcao de fatores como criticidade, proximidade com o prazo, dimensao da mudanca (FAGUNDES,
2011, p. 206).
captulo 4
105
Uma forma de resolver ou gerir estas discrepncias e a separacao precisa

entre o escopo do produto, como definido na disciplina de Gerenciamento de
Projetos, e a especificacao de requisitos, elaborada durante a Engenharia de
Requisitos (FAGUNDES, 2011, p. 206).
Desta forma, toda mudana que resulte na modificacao do Documento de
Visao deve passar por uma negociao. Sendo assim, determinadas inclusoes
ou exclusoes no projeto devem passar por um ajuste no acordo, por modificar o
escopo do produto (FAGUNDES, 2011, p. 206).
Alteraes que no modificam a viso e o escopo do projeto no demandam
tantos ajustes, mas tambm no so nulas do ponto de vista de negociao. O
esforo de modificacao e variavel de acordo com o momento em que ela e suscitada e de acordo com a analise de impacto fundamentada na rastreabilidade
dos requisitos (FAGUNDES, 2011, p. 206).
Assim, muito importante firmar previamente com o cliente uma viso
compartilhada de como se dar o processo de solicitaes de mudana, bem
como as revises do planejamento decorrentes destas mudanas. uma forma
de evitar surpresas e fortalecer os laos de confiana 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 pratica
consistente para a mudanca dos requisitos. fundamental o estabelecimento
de um processo claro para o tratamento de mudanas. Este processo precisa estar acertado e definido com os membros da equipe de desenvolvimento e usuarios (SAYO e BREITMAN, 2014 , p. 8). Os pontos que devem ser observados
com relao a possveis mudanas, dentro do processo de gerenciamento de
requisitos podem ser divididos em:
Entradas - quais condicoes devem ser satisfeitas antes de iniciar o
processo
Tarefas - detalhar quais sao as tarefas envolvidas neste processo, determinando quem sera responsavel pela sua execucao e o formato em que os resultados devem ser comunicados
Verificacao - definir etapas onde os resultados obtidos sao verificados de
modo a garantir consistencia e qualidade
Saidas - definir um criterio claro que indique que o processo chegou ao fim.
106
captulo 4
Na figura 4.2 apresentamos um exemplo de processo de mudanca de requisitos, proposto por Karl Wiegers.
Solicitante submete
solicitao de mudana
Submetida
Avaliador realiza
anlise de impacto
Avaliada
Gerente decide NO
realizar a mudana
Rejeitada
Gerente decide
realizar mudana.
Aponta reponsvel
para execuo
Aprovada
Verificao
falhou
Mudana Cancelada
Responsvel fez
a mudana e
pesquisa verificao
Mudana
Realizada
Mudana Cancelada
Cancelada
Verificador
confirma
mudana
Verificao no
foi necessria.
Modificador
instala produto
Verificada
Mudana Cancelada
Modificador
instala
produto
Final
Figura 4.2 processo de requisio de mudanca em requisito, proposto por Karl Wiegers.
Fonte: Sayo e Breitman (2014 , p. 8).
captulo 4
107
4.4 Rastreabilidade de requisitos

A rastreabilidade no algo fsico ou garantido simplesmente pelo registro dos
requisitos, mas a possibilidade de se identificar, a partir certo requisito, as dependncias diretas e indiretas. Esta e uma qualidade do registro de requisitos,
que auxilia a avaliar o impacto de uma mudana nos requisitos de uma soluo
(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 ligacoes 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 usuario que trouxe uma necessidade, como documentos da organizacao, padroes a serem seguidos e tambem legislacao pertinente (SAYO e
BREITMAN, 2014 , p. 12).
Para que seja possvel realizar de modo eficiente o gerenciamento de requisitos, principalmente quanto a modificao de requisitos necessrio que
cada requisito seja identificado de modo nico, para que seja possvel realizar
a transferncia cruzada com os outros requisitos, possibilitando, deste modo,
utiliz-lo nas avaliaes de rastreamento em possveis alteraes de requisitos.
Cada alterao deve ter seu impacto e custos avaliados, para tal, utilizam-se
polticas de rastreamento que define as relaes 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 associao entre os requisitos e os stakeholders que propuseram tal requisito.
Rastreamento de requisitos, em que identificada a associao de um
determinado requisito com a dependncia existente com outros requisitos.
Rastreamento de projeto, em que identificada a associao de um requisito com o projeto como um todo.
Para a melhor visualizao do rastreamento o ideal utilizar-se de uma
representao grfica de referncia cruzada ou matriz de rastreamento.
Neste modelo os requisitos so dispostos nas linhas e colunas de uma tabela e
108
captulo 4
suas dependncias so representadas por letras ou smbolos, 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 = relao 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 princpios da Engenharia de
Software cuja implementacao ainda implica significativa dificuldade.
Manter um controle de rastros entre modulos de codigo nao e dificil, porque as
dependencias entre os modulos costuma ser indicada de forma sintatica pelos proprios
comandos da linguagem (importou uses, por exemplo). Contudo, manter controle de
rastros entre artefatos de analise e design nao e tao simples. A rastreabilidade e importante, porque, quando sao feitas alteracoes em artefatos de analise, design ou codigo, e
necessario manter a consistencia com outros artefatos, caso contrario a documentacao
fica rapidamente desatualizada e inutil.
A tecnica 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 sequncia ou classes e mdulos de programa. Porm, esse tipo
de visualizacao matricial torna-se impraticavel a medida que a quantidade de elementos
cresce, especialmente se o controle das relacoes entre os elementos precisar ser feito
manualmente (Cleland-Huang, Zemont & Lukasik, 2004).
Tambem sao reportadas pesquisas que procuram automatizar a recuperacao de
relacoes de rastreabilidade entre artefatos a partir de evidencias sintaticas. Porem, em
razao das escolhas arbitrarias dos nomes de artefatos (falta de padrao), esses sistemas
captulo 4
109
de recuperacao 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 sao criados nos editores
de diagramas das ferramentas CASE, de forma que, com excecao dos requisitos que
sao produzidos externamente, outros elementos quaisquer (como casos de uso, classes, codigo, diagramas etc.) so podem ser criados como uma derivacao de algum outro
elemento que ja exista.
Dessa forma, sempre que um item e criado no repositorio do projeto, um rastro e
automaticamente criado entre ele e o elemento que lhe deu origem. Apenas itens que
representam requisitos (que vem do cliente, ou seja, sao externos ao projeto) podem
ser adicionados ao repositorio sem que isso ocorra por derivacao de outros itens."
(WAZLAWICK, 2013, p. 320)
4.5 Gerncia da qualidade de requisitos

Buscando a qualidade importante que a Especificacao de Requisitos de Software atenda a alguns preceitos de qualidade de software, conforme definidos
por padroes internacionais (como, por exemplo, o IEEE, o CMM e o SPICE).
Para tanto a especificacao deve ser (SANTOS, 2004, p. 22):
ESPECIFICAES:
CORRETA
PRECISA
COMPLETA
110
captulo 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 interpretacao, acordada entre os usuarios e os desenvolvedores. As dvidas
podem ser dirimidas com um dicionrio de termos, que
deve ser declarado para resolver as dvidas que surgirem.
Deve refletir todas as decisoes de especificacao que
foram tomadas ao longo de sua discussao, envolvendo
os usuarios e os desenvolvedores. Deve trazer de forma
bem clara e definida a sua funcionalidade, desempenho
desejado, restricoes de projeto (tecnicas e nao tecnicas),
atributos necessarios e, caso exista, relacionamento com
outras aplicacoes. Procurar contemplar todas as situacoes
possiveis.
ESPECIFICAES:
CONSISTENTE
DETALHAMENTO
Nao ter nenhum conflito ou sobreposicao a outros requisitos.
Definir prioridades de acordo com a importncia, estabilidade e complexidade. Dentro destes critrios, os
requisitos podem ser:
a)
essencial: requisito sem o qual o produto nao
atende as necessidades do usuario;

b)
PRIORIZADA
desejavel: sua existencia aumenta o valor do
produto, mas se por alguma necessidade nao for

contemplado nao afeta de forma substancial a utilizacao do produto;
c)
opcional: requisito que podera ser incluido caso
haja disponibilidade de prazo e orcamento, caracterizando-se como a ultima prioridade a ser atendida;
VERIFICVEL
MODIFICVEL
RASTREVEL
REUTILIZVEL
A principio todos os requisitos devem ser verificaveis. Ele

sera verificavel se existir um processo finito que possa ser
executado por uma pessoa ou maquina e, principalmente,
que mostre sua conformidade com o solicitado.
A mudanca de todo e qualquer requisito pode ser realizada de forma facil, completa e consistente.
Permite que seja facilmente verificada sua consequncia
quando ocorrer uma modificacao. 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 especificacao dos requisitos seja facilmente
reutilizavel, ou seja, se tivermos alguma funcionalidade
a ser referenciada por um outro requisito que nao seja
necessario descrev-la novamente.
Tabela 4.4 Qualidade de requisitos. Fonte: Adaptado de VILA e SPNOLA (2014).
A gerncia precisa, neste sentido, se responsabilizar pela criao e manuteno de uma infra-estrutura necessria para atividades de verificao que
tornem possvel a investigao da qualidade dos requisitos que esto sendo definidos (VILA e SPNOLA, 2014).
captulo 4
111
Gesto de Qualidade efetiva

Uma gesto de qualidade efetiva estabelece a infraestrutura que da suporte a qualquer tentativa de construir um produto de software de alta qualidade. Os aspectos
administrativos do processo criam mecanismos de controle e equilibrio de poderes que
ajudam a evitar o caos no projeto - um fator-chave para uma qualidade inadequada. As
praticas de engenharia de software permitem ao desenvolvedor analisar o problema e
elaborar uma solucao consistente , aspectos criticos na construcao de software de alta
qualidade. Finalmente, as atividades de apoio como o gerenciamento de mudancas e
as revisoes tecnicas tem muito a ver com a qualidade, assim como qualquer outra parte
da pratica de engenharia de software (PRESSMAN, 2011, p. 360).
Segundo o CMM a gerencia de requisitos e a revisao dos requisitos antes de

serem incorporados ao projeto. E necessario (SAYO e BREITMAN, 2014, p. 19):
Identificar requisitos incompletos ou ausentes
Determinar a clareza dos requisitos e se so possiveis de serem implementados, consistentes e verificaveis
Revisar requisitos com problemas potenciais
Negociar compromissos com os grupos envolvidos
A maior parte dos requisitos de software para sistemas de informacao sao
escritos utilizando-se linguagem natural. Uma srie de potenciais problemas
podem surgir por esta falta de formalidade na captura dos requisitos. Os problemas mais comuns sao:
PROBLEMAS
Ambiguidade
Requisitos incompletos
112
captulo 4
DESCRIO
EXEMPLO
Falta de clareza ou duplo sentido de frases ou expressoes.

Este tipo de requisito leva a
interpretacoes erradas ou inconsistentes das necessidades
reais dos usuarios.
Requisitos que deixam de fora
parte da informacao necessaria
a sua compreensao.
O sistema deve enviar relatorios

de produtividade dos programadores, analistas ou desenvolvedores do projeto mensalmente
ou quando requisitado.
Curva S (Planejado X Realizado)
de um projeto
Cadastro de iniciativas estrategicas
PROBLEMAS
Requisitos mltiplos
Requisitos com alternativas
DESCRIO
EXEMPLO
Estes sao requisitos que concatenam varios requisitos em um

so. Estes requisitos devem ser
separados para facilitar a tarefa
de priorizacao e gerencia de
mudancas.
Sao aqueles requisitos que nao
estabelecem claramente qual
deve ser a acao do sistema
frente a uma dada situacao. De
modo geral contem frases do
tipo mas, com excecao, apesar,
e quando.
Sao requisitos mal redigidos que
podem causar confusao e mal
entendidos. Um erro muito comum e o excesso de informacao
No evento de falha da rede

eletrica, o sistema deve enviar
mensagem de erro ao usuario,
salvar a configuracao atual do
sistema e os dados entrados,
ate entao.
O sistema deve mostrar o total
do pedido a medida que os
codigos dos produtos vao sendo
entrados no pedido, a nao ser
que se trate de um produto
promocional.
Na improvavel eventualidade de
falha no sistema de refrigeracao,
o sistema deve mandar mensagem para a chave admin.
Requisitos mal escritos

Identificar e associar as intervencoes que sao complementares as outras
Requisitos inverificveis
E de conhecimento comum a
O sistema X deve ser seguro
gerentes de projeto a maxima
"voce nao pode gerenciar o que O sistema C deve processar
nao pode medir". Um requisito
depositos rapidamente
inverificavel e escrito de modo
que fica impossivel de assegurar
que o sistema e capaz de
atende-lo.
Tabela 4.5 Problemas nos requisitos. Fonte: Adapatdo de SAYO e BREITMAN (2014 ,
p. 19).
Desta forma, fundamental que os requisitos sejam completos, corretos,

consistentes, realistas, necessrio, passvel de ser priorizado, verificvel e rastrevel (MEDEIROS, 2015).
4.6 Validao de requisitos

A validao de requisitos consiste em demonstrar que os requisitos levantados
definem o sistema que o cliente realmente quer. O custo de correo de um sistema com erro de requisitos pode chegar a cem vezes o custo de simples erros
de implementao, da a importncia de sua validao.
captulo 4
113
Validar ou checar os requisitos consiste em verificar se o sistema prov as

funes que atendem as necessidades do cliente. Verificar a consistncia dos
requisitos, se no conflitos entre eles.
Verificar a completude, se todas as funes requeridas pelo cliente esto
includas na descrio do sistema. O Realismo, se os requisitos podem ser
implementados dentro dos prazos e recursos financeiros, tecnolgicos e de
pessoal disponvel para tal. E finalmente verificar de os requisitos podem ser
verificados.
Para realizar a validao de forma eficiente utilizamos algumas tcnicas
como reviso de requisitos, prototipao, gerao de casos de teste e anlise
automatizada da consistncia.
Reviso de requisitos: consiste da anlise manual sistemtica dos requisitos. Deve ser realizada por uma equipe de engenheiros de software.
Prototipao: realiza-se a criao de prottipos executveis do sistema
como forma de verificar e testar a viabilidade e a consistncia dos requisitos
levantados.
Gerao de casos de teste: consiste em desenvolver testes que verifiquem
os requisitos levantados.
Anlise automatizada da consistncia: consiste em verificar a consistncia de uma descrio de requisitos estruturada utilizando ferramentas automatizadas, entretanto poucas vezes isso possvel.
Alm de realizar a validao dos requisitos necessrio revisar os requisitos. Estas revises devem ser realizadas regularmente enquanto a definio dos
requisitos est sendo formulada. Esta tarefa deve envolver tanto o cliente quando os analistas do sistema.
Revises podem ser feitas de forma formal ou informal e para isso importante uma boa comunicao logo nos estgios iniciais. As revises devem verificar os seguintes itens:
Verificabilidade: se o requisito pode ser testado de forma realstica.
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 no, qual impacto causar.
114
captulo 4
A verificao e validao (V & V) de software, tem como objetivo mostrar que

um sistema est de acordo com suas especificaes e que ele atende s expectativas do cliente comprador do sistema.
Esse processo envolve verificar processos, como por meio de inspees e revises, em
cada estgio do processo de software, desde a definio elos requisitos dos usurios
at o desenvolvimento elo programa. A maior parte dos custos de validao, contudo,
observada depois da implementao, quando o sistema operacional testado (SOMMERVILLE, 2006, p. 50).
A no ser que sejam pequenos programas, os sistemas no devem ser testados como uma unidade isolada, monoltica. Os grandes sistemas so formados por subsistemas, que so construdos a partir de mdulos, que so
compostos por procedimentos e funes. Os testes devem ser realizados incrementalmente, ou seja, o processo de teste deve evoluir em estgios, em conjunto com a implementao do sistema (SOMMERVILLE, 2006, p. 50).
ATIVIDADES
01. Existe algum software que gerencia os requisitos de um sistema? Voc conhece? Se
conhecer, explique basicamente o seu funcionamento. Se no conhece, pesquise na internet
algum software voltado para a gerncia de requisitos e o seu funcionamento.
02. Quais tcnicas voc utilizaria para rastrear requisitos de software? Explique.
03. Na sua opinio, o fato de haver muitas mudanas de requisitos pode influenciar na escolha do mtodos de desenvolvimento do software? Por que?
04. Quais critrios voc utilizaria para avaliar se os requisitos so de qualidade? Justifique.
05. Quais so os principais pontos que devem ser decididos durante o estgio de gerenciamentos de requisitos? Explique.
captulo 4
115
REFLEXO
Podemos considerar que se os requisitos forem bem levantados, bem descritos e especificados, no teremos problemas quanto mudanas futuras? Ser que temos condies 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 conseguiramos 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? So perguntas relativamente simples e comuns que poderamos
fazer a todo o momento, mas com uma certa complexidade em responder ou principalmente,
em gerenciar na prtica. A engenharia de software nos mostra processos, ferramentas, mtodos e tcnicas para respond-las e como lidar com estas situaes comuns e srias em
um projeto de desenvolvimento de software. Mudar requisitos pode ser um grave problema,
chegando at mesmo a limitar algumas aes, enquanto que em outras metodologias ou em
outras abordagens, pode ser tratado como algo previsvel e esperado, tendo condies de
agir e trabalhar com esta situao de mudanas.
LEITURA
Como comentamos no captulo anterior, os livros de engenharia de software so excelentes
fontes de leitura na rea da engenharia de requisitos e neles h uma abordagem com mais
profundidade acerca dos assuntos tratados neste captulo.
PRESSMAN, Roger S. Engenharia de Software, 7 edio. So Paulo: McGraw-Hill, 2011.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Prticas, 1a Edio, Elsevier,
2013.
SOMMERVILLE, Ian. Engenharia de Software, 9 edio. Editora Pearson do Brasil, 2011.
A revista Engenharia de Software, na sua edio 13 trouxe um excelente artigo sobre
Rastreabilidade que merece ser lido.
http://migre.me/oKWiW
116
captulo 4
VILA, A. L.; SPNOLA, R. O.; Introduo Engeharia de Requisitos. Revista Engenharia de
Software. Disponvel 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. Disponvel 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.; Introduo a Engenharia de Requisitos. Disponvel em: <http://www.devmedia.
com.br/introducao-a-engenharia-de-requisitos/29454>. Acesso em: 11 jan 2015.
SANTOS, J. H. A.; Gerncia de Mudanas de Requisitos: uma proposta de aplicao a um
estudo de caso. Mestrado. UFRGS. 2004. 107p. Disponvel 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.
SAYAO, M; BREITMAN, K K. Gerencia de Requisitos. Disponivel em <http://www-di.inf.puc-rio.
br/~karin/TELECOM/index_files/gerencia_req.pdf>. Acesso em: 24 nov de 2014.
SETTIMI, R., CLELAND-HUANG, J., KHADRA, O. B., MODY, J., LUKASIK,
W. & De PALMA, C. Supporting Software Evolution through Dynarnically Retrieving Traces to
UML Artifacts. Proceedings of the Principies of Software Evolution, 2004.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Prticas, 1 Edio, Elsevier, 2013. 506p.
captulo 4
117
118
captulo 4
5
Modelagem do
Projeto - UML
A modelagem do projeto de software envolve atividades fundamentais que iro

contribuir diretamente no desenvolvimento ou codificao de um sistema. Ela
trata do desenho do software, a sua modelagem, podendo explorar previamente vrios recursos e simular por meio de modelagens o seu funcionamento.
Usar um ambiente de modelagem que permita analisar, identificar possveis falhas ou melhorias antes de aplicar diretamente em um ambiente de desenvolvimento, de extrema importncia para o sucesso do projeto.
Como modelar envolve notaes grficas, desejvel que se faa estas notaes, desenhos e smbolos dentro de padres que sejam internacionalmente
conhecidos e que estes funcionem adequadamente dentro das regras de negcio que os softwares a serem desenvolvidos estejam inseridos. Para estas notaes e sua padronizao, existem modelos que podem ser utilizados como
o caso da UML (Unified Modeling Language), que uma linguagem de modelagem unificada, representada por alguns diagramas especficos, como por
exemplo os de casos de uso e diagramas de sequncia e de classes.
A UML muito utilizada em projetos que envolvem o paradigma de programao orientado a objetos. Esta tcnica usada largamente em vrios tipos de
aplicaes e mostra-se como uma tendncia que vai ser usada ainda mais.
Muitas tcnicas encontradas na rea de engenharia de software dependem
dos conceitos apresentados neste captulo e espero que isto sirva tambm para
a sua carreira.
OBJETIVOS
Aprender sobre a modelagem do software.
Conhecer os conceitos de casos de uso.
Aprender sobre diagramas de sequncias.
Aprender sobre diagramas de classes.
120
captulo 5
5.1 Introduo
A modelagem de software traz alguns benefcios importantes, melhorando
a comunicao entre os envolvidos no projeto, melhorando o planejamento
e tambm reduzindo riscos e custos. No entanto, muitos desenvolvedores e
gerentes no compreendem ou no usam adequadamente os recursos que a
modelagem pode oferecer. Em outras situaes, necessrio ter um esforo
de convencimento gerncia superior, mesmo a modelagem estando a durante muitos anos contribuindo para visualizao daquilo que ser desenvolvido
e permitindo adoo de padres visuais que muito facilitam a integrao da
equipe e o entendimento daquilo que est sendo proposto, justificando alguns
dos benefcios apontados.
Por meio da modelagem, possvel utilizar recursos visuais para representar
tipos de informaes distintas, como por exemplo usar diagramas para a arquitetura geral do sistema, dependncias do sistema, complexidade, fluxo de informaes atravs de sistemas, requerimentos do negcio, organizao e estrutura do
banco de dados, cdigo fonte - incluindo quase todos os aspectos do desenvolvimento orientado a objetos, configuraes da instalao, entre outros.
5.2 A modelagem do software

Um sistema ao ser desenvolvido precisa ser modelado como um conjunto de
componentes e de relaes entre esses componentes e esta ao 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 viso geral da organizao 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 interconexes entre esses subsistemas. Cada
subsistema sentado por um retngulo, no diagrama de blocos, e a existncia de uma
relao entre os subsistemas indicada por flechas que ligam esses retngulos. Os
relacionamentos indicados podem incluir fluxo de dados, uma relao de usa/usado
por ou algum outro tipo de relao de dependncia (SOMMERVILLE, 2006, p. 22).
captulo 5
121
Esse esquema grfico est ilustrado na figura 5.1, que exibe a decomposio
de um sistema de alarme antifurtos em seus componentes principais. Observe
que os diagramas de blocos devem ser complementados por breves descricoes
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
DESCRIO
Sensor de movimento
Sensor de janela
Controlador de alarme
Alarme
Sintetizador de voz
Discador de telefone
Detecta movimento nos cmodos monitorados pelo sistema.

Detecta a abertura de janelas externas do edifcio.
Controla a operao do sistema.
Emite um aviso sonoro quando um intruso detectado.
Sintetiza uma mensagem de voz dando a localizao do possvel intruso.
Faz as chamadas para avisar a segurana, a polcia, etc.
Tabela 5.1 Funcionalidade de subsistemas no sistema de alarme antifurtos. Fonte: adaptado de Sommerville (2006, p. 22)
A implementao de um bom software est diretamente relacionada s atividades de modelagem, pois por meio dela constri-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
captulo 5
simplificao da realidade, criado para facilitar o entendimento de sistemas

complexos, estes modelos podem abranger planos detalhados, assim como
planos mais gerais com uma viso panormica do sistema. Assim, todos os
sistemas podem ser descritos sob diferentes aspectos, com a utilizao de modelos diversos, onde cada modelo ser, portanto, uma abstrao especfica do
sistema. Os modelos podem ser voltados para a estrutura, dando nfase organizao do sistema, ou podem ser voltados ao comportamento, dando nfase
dinmica 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 construo do sistema;
Eles documentam as decises tomadas no projeto.
Por meio dos modelos, consegue-se obter mltiplas vises do sistema, particionando a complexidade do sistema para facilitar sua compreenso, e atuando como meio de comunicao entre os participantes do projeto. Portanto, uma
linguagem de modelagem padronizada, tal como a UML (Unified Modeling
Language), fundamental para a construo e o entendimento de bons modelos (SOUZA e SOUZA, 2014).
Dica: A documentao de sistema uma deciso de negcio, no uma deciso
tcnica.
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 documentacao. Quando voce para e pensa a respeito disso,
essa troca e uma decisao de negocio, nao tecnica. Voce esta trocando funcionalidade
de negocio por um possivel risco de diminuicao de beneficios que e gerar apenas artefatos permanentes que descrevem o sistema. Portanto, voce deve ir ate seus clientes e
pedir permissao para investir os recursos deles desta forma, mostrando as vantagens e
desvantagens de faze- lo. Algumas vezes, eles escolherao manter os artefatos que voce
sugeriu e outras vezes aceitarao o risco de nao te-los e diminuir a carga do trabalho. E
uma decisao deles, nao sua.
Fonte: Ambler (2004, p. 50)
captulo 5
123
5.2.1 Modelagem gil

Com um conjunto de prticas formadas por princpios e valores para serem
aplicados nos projetos de softwares, a Modelagem gil (MA) uma metodologia baseada na prtica para a modelagem e desenvolvimento eficaz de sistemas.
Apesar dela no definir procedimentos detalhados de como desenvolver um
tipo de modelo, ela oferece prticas simples de modelagem (RIBEIRO, 2014).
Ha dois motivos fundamentais para modelar: para compreender o que se
esta construindo ou para melhorar a comunicacao na equipe ou com os clientes do projeto. possvel escolher modelar os requisitos do sistema com um
diagrama de casos de uso ou com um conjunto de definicoes de regras de negocio. Tambm, existe a opo de desenvolver modelos para analisar aqueles
requisitos ou formular uma arquitetura de alto nivel 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. Alem disso, tambm possvel utilizar modelos para a comunicacao entre
membros da equipe ou com agentes externos (AMBLER, 2004, p. 26).
O desenvolvimento de software por meio da utilizao de modelagem gil
no significa o desenvolvimento com pouca modelagem, mas o uso de tcnicas
em consonncia com os requisitos do projeto. Usualmente utiliza-se a abordagem iterativa para a especificao, desenvolvimento e entrega de software. Esta
abordagem foi criada com o intuito de dar suporte ao desenvolvimento de aplicaes de negcios nas quais os requisitos de sistema mudam constantemente
durante o desenvolvimento (RIBEIRO, 2014).
A Modelagem gil tem trs objetivos (RIBEIRO, 2014):
1.
Definir e mostrar a forma de colocar em prtica valores, princpios e prticas rela-
tivas a uma modelagem simples e eficaz;

2.
Lidar com a questo de como aplicar as tcnicas geis nos projetos de software;
3.
Discutir como se podem melhorar as atividades de modelagem adotando os m-
todos geis.
124
captulo 5
E tem como princpios (RIBEIRO, 2014):

Satisfazer o cliente atravs da entrega adiantada e contnua de software de valor;
Aceitar mudanas de requisitos, mesmo que seja no final do desenvolvimento;
Entregar software funcionando com frequncia, com preferncia aos perodos mais
curtos;
As pessoas relacionadas a negcios e a equipe de desenvolvedores devem trabalhar
em conjunto durante o desenvolvimento do projeto;
preciso construir projetos ao lado de pessoas motivadas;
O mtodo mais eficaz e eficiente de transmitir informaes atravs da conversa
pessoal;
Software funcional a medida primria de progresso;
Processos de desenvolvimento gil promovem um ambiente sustentvel. Os envolvidos no projeto precisam ser capazes de manter indefinidamente passos constantes;
Contnua ateno a excelncia tcnica e ao bom design, tende a aumentar a agilidade;
Simplicidade;
As melhores arquiteturas, requisitos e designs emergem de times auto-organizveis;
Em intervalos regulares a equipe reflete em como ficar mais efetiva, ento, organizase e otimiza seu comportamento de acordo .
Atualmente, existem vrios mtodos geis como exemplo a Extreme

Programming (XP), Scrum e Crystal (RIBEIRO, 2014).
Na realidade, a MA apenas um conjunto de tcnicas que refletem os princpios e valores de muitos desenvolvedores de software mais vividos. A pergunta poderia ser colocada: se existe algo como modelagem gil, possvel dizer
que existem modelos geis? A resposta sim (AMBLER, 2004, p. 28).
Para melhor compreender a Modelagem gil, necessrio entender a diferenca entre modelo e modelo agil. Um modelo e uma abstracao que descreve
um ou mais aspectos de um problema ou uma solucao possivel para ele. Os
modelos sao pensados tradicionalmente como diagramas e sua respectiva documentacao(AMBLER, 2004, p. 30).
captulo 5
125
O modelo gil um modelo que cumpre seu proposito, sendo compreensivel para seu publico; simples, preciso, suficiente, consistente e detalhado; e o
investimento realizado na sua criacao e manutencao agrega valor positivo ao
projeto (AMBLER, 2004, p. 31).
Os modelos geis cumprem seu propsito;
Os modelo ageis sao compreensiveis;
Os modelos ageis sao suficientemente precisos;
Os modelos ageis sao suficientemente consistente;
Os modelos ageis sao suficientemente detalhados;
Os modelos ageis proporcionam valor positivo;
Os modelos ageis sao os mais simples possiveis.
(AMBLER, 2004, p. 32)
Seguem abaixo pontos que descrevem o escopo da Modelagem gil, facilitando o seu entendimento:
A MA e uma atitude, nao um processo prescritivo;
A MA e um suplemento dos metodos preexistentes; nao uma metodologia completa;
A MA e complementar aos processos de modelagem;
A MA e uma maneira de trabalhar em conjunto de modo eficaz para alcancar os objetivos dos clientes do projeto;
A MA e eficaz e trata de eficacia;
A MA e algo que funciona na pratica; nao uma teoria academica;
A MA nao e uma bala de prata (silver bullet*);
A MA foi feita para o desenvolvedor medio, mas nao e uma substituicao de pessoas
competentes;
A MA nao e um ataque a documentacao;
A MA nao e um ataque as ferramentas CASE.
(AMBLER, 2004, p. 32)
126
captulo 5
Fazendo a UML Funcionar na Prtica

As seguintes estratgias devem ajud-lo a fazer a UML trabalhar para voc na
prtica:
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 bsico de tcnicas de modelagem que ento suplementado com outras tcnicas para
satisfazer s suas necessidades especficas. Alm disso, eu no substituiria a UML por
outros artefatos. Embora esteja convencido de que minha prpria notao para modelagem de classes (Ambler, 1995) seja superior da UML, na realidade, ela no de
uso comum e, portanto, se voc utiliz-la dificultar a compreenso dos diagramas para
outras pessoas, o que reduzir a comunicao na equipe de projeto.
Adote um subconjunto bsico da notao. Se voc precisar de apenas 20%
da notao da UML para realizar 80% do trabalho de modelagem, comece com esses
20% bsicos.
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 tcnica, como a XP, lanada, 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
opinio, em vez de fazer a pergunta "Como aplicamos a UML com a [Nova Palavra da
moda]?", eles deveriam perguntar "Como modelamos uma aplicao baseada em [Nova
Palavra da moda]?".
Fonte: AMBLER (2004, p. 169)
captulo 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 notacao utilizada na representacao dos sistemas. A UML, apresentada por Booch, Jacobson e
Rumbaugh (2000), foi criada a partir dos principais metodos orientados a objetos. A UML pode ser utilizada em sua notacao, independente do processo de
software adotado (MACHADO e PEREIRA, 2006). Cada um dos autores possua
sua prpria forma de criar modelos e a UML a unio dessas trs abordagens,
adicionando novos conceitos e vises 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 padres para se criar modelos de software, o que dificultava o
trabalho pela falta de padronizao (SOUZA e SOUZA, 2014).
A UML uma linguagem muito expressiva, abrangendo todas as vises necessrias ao desenvolvimento e implantao de sistemas de software em geral
(SOUZA e SOUZA, 2014).
UML pode ser empregada para visualizao, especificao, construo e
documentao de artefatos de software, sendo uma linguagem padro para a
elaborao da arquitetura de projetos de software que aborda o carter esttico
e dinmico do sistema a ser analisado (SOUZA e SOUZA, 2014).
J no perodo de modelagem a UML considera todas as futuras caractersticas do sistema, relacionadas a trocas de mensagens entre as diversas partes
do sistema, o padro arquitetural adotado e os padres 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 comrcio eletrnico para
uma livraria, a sistemas de grande porte, como um sistema de transaes bancrias. Ela
pode abranger vrias caractersticas de um sistema em um de seus diagramas, sendo
aplicada nas diferentes atividades do desenvolvimento de software, desde a especificao de requisitos at a implementao e os testes (SOUZA e SOUZA, 2014).
A UML imprime a necessidade de que o analista modele o sistema como

estado da arte da orientao a objetos. Como dito anteriormente, o fato dela
contemplar o estado esttico, bem como o dinmico dos objetos e classes modelados, faz com que ela seja bastante interessante.
128
captulo 5
H uma confuso conceitual com relao a UML. Ela uma linguagem de

modelagem e no um mtodo de desenvolvimento. Na UML no h a sequncia 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 questes estticas e dinmicas de um sistema de informao.
A UML permite elaborar diversos diagramas. Estes diagramas podem ser
para visualizao, especificao, construo e documentao de diversas partes do sistema em diversas etapas do ciclo de vida. So vrios os tipos de diagramas que permitem modelar aspectos dinmicos do sistema por meio da UML
(LEITE, 2000b). Os diagramas da UML so 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 sequncia
Diagrama de colaborao
DIAGRAMAS ESTRUTURAIS
Diagrama de estados
Diagrama de atividades
DIAGRAMAS DE
IMPLEMENTAO
Diagrama de componentes
Diagramas de execuo
Tabela 5.2 Diagramas da UML.
captulo 5
129
5.3.1 Aplicao
Devido a quantidade de diagramas presentes na UML, possvel us-las praticamente em qualquer tipo de sistema mesmo os que no 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 especificao da
anlise at o final do projeto nas fases de testes.
A aplicao principal da UML descrever qualquer tipo de sistema em termos de diagramas orientados a objetos. Ela pode ser inclusive usada para modelar sistemas mecnicos, sem uso de software.
A maioria dos sistemas existentes possuem caractersticas de tempo real,
banco de dados, interao com o usurio por meio de telas e outras. A UML
suporta modelagens para todos estes tipos.
Os seguintes links mostram exemplos de aplicao da modelagem UML:
http://migre.me/oDEbg
Contm um exemplo completo com vrios diagramas sobre um mesmo sistema.
http://migre.me/oDEeG
Possui vrios 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 interacao completa entre um
ator e o sistema. Geralmente, cada requisito funcional gera pelo menos um
caso de uso. importante ter cuidado para nao 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 descricao de alto nivel, com poucas sentencas at uma descricao expandida, com
maior detalhamento do dialogo entre ator e sistema (MELLO, 2005, p. 108).
130
captulo 5
As descricoes expandidas sao importantes em casos de uso em grandes projetos, pois nestes o trabalho tende a ser dividido em diversas equipes e a comunicacao e executada por escrito. J em equipes menores, o natural que a
mesma equipe seja responsvel por todo o trabalho de desenvolvimento, desde
os requisitos ate a implantacao 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 notaes para a representao de casos
de uso (LEITE, 2000b).
Um caso de uso capaz de especificar o comportamento do sistema a ser desenvolvido. Porm no especifica como este comportamento ser implementado. Os comportamentos descrevem as funes da aplicao que caracterizam
a funcionalidade do sistema. Um caso de uso representa o que o sistema faz e
no como o sistema faz, proporcionando uma viso externa e no 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 implementaco.
So os responsveis pelos testes que tm o objetivo de garantir que os componentes do modelo de implementao cumpram corretamente os objetivos
estabelecidos nos casos de uso. Assim, percebe-se que os casos de uso, alm
de iniciarem o processo de desenvolvimento, tambm o mantm em coeso.
Direcionado a casos de uso significa que o processo de desenvolvimento executa uma seqncia de tarefas derivadas dos casos de uso. Eles so especificados, projetados e servem de base para a construo dos casos de teste(MARTINS, 2014).
De acordo com Falbo (2002), os casos de uso tem dois importantes papeis:
1.
Eles capturam os requisitos funcionais de um sistema. Um modelo de caso
de uso define o comportamento de um sistema (e a informacao associada) atraves de

um conjunto de casos de uso. O ambiente do sistema e definido pela descricao dos
diferentes usuarios. Estes usuarios utilizam o sistema atraves de um numero de casos
de uso.
captulo 5
131
2.
Eles oferecem uma abordagem para a modelagem de sistemas. Para ge-
renciar a complexidade de sistemas reais, e comum apresentar os modelos do sistema

em um numero de diferentes visoes. Em uma abordagem guiada por casos de uso, pode-se construir uma visao para cada caso de uso, isto e, em cada visao sao modelados
apenas aqueles elementos que participam de um caso de uso especifico. Um particular
elemento pode, e claro, participar de varios casos de uso. Isto significa que um modelo
do sistema completo so e visto atraves de um conjunto de visoes - 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 so 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 nao e capturado, nao e possivel planejar como trata-lo (FALBO, 2002).
Geralmente, em primeiro lugar, casos de uso sao listados e discutidos, para
so entao, 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, so
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 usurio, um hardware ou outro sistema que interage com
sistema modelado. O diagrama representa uma sequncia de aes 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
captulo 5
Os casos de uso mostram o comportamento do sistema, cenrios que o sistema percorre em resposta ao estmulo de um ator.
Os atores so conectados a casos de uso por uma associao representadas por uma
linha. O comportamento associado a cada caso de uso pode ser descrito como um
cenrio. Cada cenrio descreve textualmente o fluxo de eventos ou seqncia que
caracteriza o comportamento do ator e as respostas do sistema. Um cenrio uma
instncia do caso de uso (LEITE, 2000b).
O relacionamento entre um ator e um caso de uso representa a participao

deste ator no caso de uso. Existem, tambm, dois outros tipos de relacionamentos entre casos de uso:
Relacionamento estender - representado graficamente por uma seta
com um o esteretipo <<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 esteretipo
<<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 negcio
<<uses>>
Fechar preos
Ator
Analista comercial
Registrar negcios
Generalizao
Vendedor
<<extends>>
Negcios com
limites excedidos
Caso de uso
Figura 5.2 Diagrama de casos de uso. Fonte: Fowler e Scott (2004).
captulo 5
133
Pode-se dizer que um diagrama de casos de uso formado por (LEITE,

2000b):
Casos de uso
Atores
Relacionamentos de dependncia, generalizaes e associaes
Seguem abaixo as regras para modelar os requisitos de software de um sistema (LEITE, 2000b):
Estabelea o contexto do sistema identificando os atores (usurios 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 genrico, estabelecendo um
relacionamento de generalizao. Tente identificar outros relacionamentos, como a dependncia 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 no-funcionais.
Alm das regras acima, h algumas informaes importantes que auxiliam

na construo de diagramas mais claros (LEITE, 2000b).
D nomes que comuniquem o seu propsito.
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 prximos.
Use notas para chamar a ateno de caractersticas importantes - as notas no so
apenas para os requisitos no funcionais.
No 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
captulo 5
5.4.2 Descrio de Casos de Uso

Um caso de uso deve descrever o que um sistema faz. Apenas o diagrama de
caso de uso no 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 sao as informacoes transferidas e o fluxo basico e fluxos alternativos do
comportamento (FALBO, 2002, p. 26).
Aps 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 (bsico). Variantes do curso basico de
eventos e erros que possam vir a ocorrer devem ser descritos em cursos alternativos. usual que um caso de uso tenha apenas um unico curso basico, porm
inmeros cursos alternativos (FALBO, 2002, p. 26).
5.5 Diagramas de Classes

Ao conjunto de objetos com propriedades, comportamento, relacionamentos
e semntica comuns, d-se o nome de Classe. Uma classe pode ser entendida
como um esqueleto ou modelo para se criar objetos. Objeto uma abstrao
que representa uma entidade do mundo real, podendo ser algo concreto (computador, carro) ou abstrato (transao bancria, histrico, 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 esttica das classes de um sistema. No
diagrama so mostradas as associaes entre as classes e seus tipos, a especificao das classes, especializaes e generalizaes e os agrupamentos em
pacotes.
O interessante do diagrama de classes que ele pode ser implementado
usando alguma linguagem de programao orientada a objetos. Existem vrias
ferramentas CASE que aps o desenho do diagrama de classes gera o cdigo em
Java, C++, C#, etc.
captulo 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
Veculo alugado
Tipo de veculo
Possui
Caminho
Carro sport
Carro de passeio
Companhia de
aluguel de veculos
Figura 5.3 Diagrama de classes. Fonte: Fowler e Scott (2004).
5.6 Diagrama de Objetos

uma variao do diagrama de classes e possui praticamente a mesma notao. A diferena que este mostra objetos que foram instanciados das classes.
Ele mostra o sistema em um determinado momento. Usa a mesma notao do
diagrama de classes, mas com duas excees: os objetos so escritos com os nomes sublinhados e todas as instncias em um relacionamento so mostradas.
Os diagramas de objetos so teis para exemplificar diagramas de objetos
muito complexos, ajudando em sua compreenso. So tambm usados para
mostrar a colaborao dinmica dos objetos.
Pablo: cliente
Nome: Pablo F. Barros
Idade: 20
CPF: 94168912-15
2678: contrato de aluguel

Num_contrato: 2678
Veculo: BMW 914
Figura 5.4 Diagrama de objetos.
136
captulo 5
2679: contrato de aluguel

Num_contrato: 2679
Veculo: Audi V8
5.7 Diagramas de estados

Mostra todos os estados possveis dos objetos de uma classe, bem como os
eventos que devem ocorrer que provocam a tais mudanas de estado. Eles mostram o comportamento dinmico de um sistema, mostrando o ciclo de vida de
um objeto.
A UML utiliza como notao para diagramas de estados a notao proposta
por Harel. Nesta notao, um diagrama de estados um grafo dirigido cujos nodos representam estados e cujos arcos representam transies entre estados.
Estados so representados graficamente por elipses ou retngulos com bordas
arredondadas e transies so representadas por segmento de retas dirigidas.
O estado inicial representado por um ponto de incio e podem existir vrios
pontos de finalizao.
No trreo
Subir (andar)
Subindo
Chegar no trreo
Chegar no andar
Indo para
o trreo
Descendo
Chegar no andar
Subir (andar)
Parado
Descer (andar)
Tempo de espera
Figura 5.5 Diagrama de estados.
5.8 Diagramas de sequncia

Em um diagrama de sequencia, um objeto e mostrado como um retangulo com uma
linha vertical pontilhada anexada. Esta linha e chamada de linha de vida do objeto e
representa a vida do objeto durante a interacao. 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 pagina. Cada mensagem e rotulada com pelo
menos o nome da mensagem. Adicionalmente, pode incluir tambem seus argumentos
e alguma informacao de controle (FALBO, 2002, p. 71).
captulo 5
137
O diagrama de sequncia, mostrado na figura 5.6, tem como objetivo representar a interao e relacionamento entre os objetos possibilitando assim visualizar a sequncia de mensagens trocadas entre eles.
Os objetos so mostrados em linhas verticais. No caso da figura 6, os objetos
so: computador, servidor de impresso, impressora e fila.
A sensao temporal do diagrama percebido analisando-o no sentido vertical, de cima para baixo. As mensagens enviadas por cada objeto so representadas por setas entre os objetos relacionados.
No diagrama do exemplo, as mensagens so:
imprimir (arquivo);
impressora livre;
impressora ocupada.
Como podemos perceber, existem dois eixos no diagrama de sequncia: 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 sequncia normalmente est associado ao comportamento
de um nico caso de uso e, tambm, podem representar um determinado cenrio do sistema.
Computador
Servidor de
impresso
Impressora
Fila
(Impressora livre)
Imprimir (arquivo) Imprimir (arquivo)
(Impressora ocupada)
Imprimir (arquivo)
Figura 5.6 Diagrama de sequncia.
Para facilitar a compreenso de um diagrama de sequncia, possvel utilizar uma tcnica que consiste em colocar descries de texto dos acontecimentos do lado esquerdo do diagrama de sequncia (FALBO, 2002).
138
captulo 5
5.9 Diagrama de Colaborao

Mostra a colaborao dinmica entre os objetos, porm mostra a sequncia
cronolgica do cenrio que esta sendo modelado.
Se a nfase do diagrama for o decorrer do tempo, melhor escolher o diagrama de sequncia, mas se a nfase for o contexto do sistema, melhor dar
prioridade ao diagrama de colaborao.
O diagrama de colaborao desenhado como um diagrama de objeto,
onde os diversos objetos so mostrados juntamente com seus relacionamentos. As setas de mensagens so desenhadas entre os objetos para mostrar o
fluxo de mensagens entre eles. As mensagens so nomeadas, que entre outras
coisas mostram a ordem em que as mensagens so enviadas. O diagrama de
colaborao tambm pode conter objetos ativos, que executam paralelamente
com outros.
Computador
(Impressora ocupada)
1.2: Armazenar (arquivo)
Fila
1: Imprimir (arquivo)
Servidor de
impresso
(Impressora livre)
1.1: Imprimir (arquivo)
Impressora
Figura 5.7 Diagrama de colaborao.
5.10 Diagrama de Atividade

A figura 5.8 mostra um tpico diagrama de atividades.
Os diagramas de atividade so representaes grficas de fluxos de informaes de atividades sequenciais e aes nestas atividades. O diagrama suporta escolhas, iteraes e concorrncia (paralelismo).
Os diagramas podem ser usados basicamente para descrever os fluxos de
negcio e operacionais passo a passo dentro de um sistema. Em resumo, o diagrama de atividades mostra o fluxo de controle geral do sistema.
captulo 5
139
Na Figura 8 possvel perceber o fluxo de informaes de uma determinada

atividade do sistema. No caso a atividade a Imprimir arquivo(). Perceba que
este diagrama pode mostrar como dever ser a implementao deste mtodo
de uma classe de impresso, por exemplo.
(Disco cheio)
Imprimir arquivo ( )
(Espao 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, possvel perceber que o diagrama de componentes mostra
os vrios componentes em um sistema e suas dependncias. um diagrama
fsico.
Um componente pode ser um mdulo fsico do sistema. Pode ser um pacote de software, uma biblioteca (dll por exemplo), enfim, os componentes so
a implementao na arquitetura fsica do que foi especificado na arquitetura
lgica do sistema.
As dependncias entre os componentes, representadas pelas linhas tracejadas, mostram como mudanas em um componente podem causar mudanas em outros componentes. Existem vrios tipos de dependncia porm o uso
mais comum na representao a comunicao entre os componentes.
140
captulo 5
Gerenciador de
comunicao
Grficos
Comm.dll
Graficos.dll
Gerenciador de
banco de
dados
Db.dll
Aplicao
App.exel
Figura 5.9 Diagrama de componente. Fonte: Fowler e Scott (2004).
5.12 Diagrama de Execuo

Mostra a arquitetura fsica do sistema (hardware e software), juntamente com
as conexes entre si. Pode-se tambm mostrar os tipos de conexo entre eles.
a ltima descrio fsica da topologia do sistema, descrevendo a estrutura de
hardware e software que executam em cada sistema.
O diagrama de execuo composto por componentes, que possuem a
mesma simbologia dos componentes do diagrama de componentes, nodes,
que significam objetos fsicos que fazem parte do sistema, podendo ser uma
mquina cliente numa LAN, uma mquina servidora, uma impressora, um roteador, etc., e conexes entre estes nodes e componentes que juntos compem
toda a arquitetura fsica do sistema.
Cliente A:
Pentium 200
MMX
Cliente B:
Pentium 200
MMX
<<TCP/IP>>
Servidor de
aplicao:
HP/UX
SQL<<TCP/IP>>
Servidor de
banco de
dados:
ORACLE
<<TCP/IP>>
Figura 5.10 Diagrama de execuo.
captulo 5
141
ATIVIDADES
01. Voc conhece algum software que trabalha com modelagem? Se sim, cite e comente
sobre ele. Caso no conhea, pesquise alguns dos mais utilizados na internet e comente suas
principais caractersticas.
02. A UML pode ser considerada uma metodologia de desenvolvimento de sistemas. Esta
afirmao 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 situaes recomendvel utilizar diagramas de sequncia? Justifique.
05. Em quais situaes recomendvel utilizar diagramas de classes? Justifique.
REFLEXO
Modelar para construir. Isto no lhe parece bvio? Evidentemente que para a rea de software isto no seria diferente e assim como ocorre em outras reas da engenharia, a engenharia
de software tambm possui suas formas de notaes, mtodos e tcnicas para efetuar projetos de sistema. O paradigma de orientao a objetos uma forma de fundamentar outras
reas do conhecimento na engenharia de software.
Imagine se todos no mundo, em diferentes pases, adotassem seu modo os seus critrios e padres de desenhos ao modelar algo. Como seria? Consegue imaginar a dificuldade
que seria se cada pas, ou ainda em diferentes regies de um mesmo pas tivessem vrias
formas de anotar um determinado procedimento, uma ao, um processo, uma classe, um
objeto e assim por diante?
A UML traz esta possibilidade junto necessidade de se padronizar notaes por meio
de uma linguagem unificada de modelagem. Ela permite que diagramas sejam utilizados e
interpretados por pessoas com conhecimento tcnico de todas as partes do mundo, proporcionando um ganho nas anotaes, esquemas e diagramas dando sentido modelagem de
sistemas de todo os tipos, com diferentes focos, por meio de seus diagramas.
142
captulo 5
Enfim, atualmente temos disponveis vrios mtodos, tcnicas, ferramentas e modelos

a serem seguidos e aperfeioados 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
Alm de livros e guias que so fundamentais para complementar o estudo sobre modelagem
e UML, na internet existem vrios tutoriais a materiais que muito contribuem para a aprendizagem.
http://migre.me/oKWVm - Este link leva um site (Case-Tools) contm vrias ferramentas
UML gratuitas e proprietrias. necessrio realizar um cadastro.
UML.org - O site da principal referncia da UML, onde os novos padres so estabelecidos
e divulgados.
http://migre.me/oKXbj - Link para um excelente site sobre introduo a UML, em ingls.
Booch, G.; Rumbaugh, J.; Jacobson, I. UML: guia do usurio. So Paulo: Campus, 2006.
Excelente livro com uma boa viso sobre UML.
AMBLER, S. W.; Modelagem gil - Prticas eficazes para a Programao Extrema e o Processo
Unificado. Bookman. 2004. 351p.
FALBO, R. A.; Anlise de Sistemas. UFES. 2012. 120p.
FOWLER, M,; SCOTT, K. UML essencial. Porto Alegre: Bookman, 2004.
LEITE, J. C.; Anlise e Especificao de Requisitos. 2000b. Disponvel 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. Simpsio Mineiro de Sistemas, 2006. Disponvel em:
<http://homepages.dcc.ufmg.br/~ivre/Artigo1.pdf>. Acesso em 17 dez 2014.
MARTINS, V.; Processo Unificado. Disponvel 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. Cin. Empresariais da UNIPAR, Toledo, v.6, n.1, 2005. 97-111p.
captulo 5
143
RIBEIRO, C. F. Modelos de desenvolvimento de software. Revista .Net Magazine 101. Disponvel

em: <http://www.devmedia.com.br/modelos-de-desenvolvimento-de-software-revista-netmagazine-101/26747>. Acesso em: 15 dez 2014.
SOUZA, C. A. R.; SOUZA, V. E. S..; Modelagem de software com UML - Parte 1. Easy Java
Magazine 4. Disponvel 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.; Anlise e Projeto OO & UML 2.0. UTFPR. 2013. 97p. Disponvel em: <http://www.
dainf.ct.utfpr.edu.br/~tacla/UML/Apostila.pdf>. Acesso em: 12 jan 2015.
GABARITO
Captulo1
01. Letra a.
02. As RTF tem como objetivos: (1) descobrir erros na funcao, logica ou implementacao
para qualquer representacao 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 padroes predefinidos; (4) obter software que seja desenvolvido de maneira uniforme; e
(5) tornar os projetos mais gerenciaveis. Um ponto interessante de se observar que alem
disso, a RTF tambm serve como base de treinamento, possibilitando que engenheiros mais
novos observem diferentes abordagens para analise, projeto e implementacao de software,
contribuindo ainda mais para a qualidade.
03. Um processo de software sem controle resulta em processos improvisados pelos desenvolvedores e gerncia. No rigorosamente seguido e o cumprimento das metas no
controlado. O processo passa a ser altamente dependente da qualidade e experincia
dos profissionais envolvidos. E diminui a viso de progresso e qualidade do processo. A
qualidade do produto fica comprometida e os prazos dificilmente so cumpridos. Possui alto
risco quando necessria a utilizao de novas tecnologias, por depender diretamente da
experincia dos profissionais. Alm de tornar muito difcil prever a qualidade final do produto.
O processo passa a ser constantemente reativo a situaes inesperadas e problemas ao
invs de ser pr-ativas, no havendo tempo para melhorias. De forma geral, o fogo esta
144
captulo 5
sob controle, mas esta quase sempre apagando incndios, 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, necessrio que este tenha
conformidade com alguns conceitos:
Correo: deve funcionar de forma correta. Satisfazendo as suas especificaes sem falhas ou erros;
Integridade: suas especificaes satisfazem os requisitos dos usurios e da organizao;
Flexibilidade: deve prever que o usurio pode agir de forma no esperada e deve ser
capaz de resistir a eventuais situaes sem falhas;
Confiabilidade: deve se comportar como esperado e no falhar em situaes inesperadas;
Eficincia: deve realizar suas tarefas em tempo adequado complexidade de cada um
deles. E devem utilizar de modo eficiente os recursos de hardware disponveis;
Reusabilidade: os componentes do software devem permitir ser reutilizados em outras
aplicaes;
Usabilidade: deve ser fcil de aprender e de usar, permitindo maior produtividade do usurio, flexibilidade de utilizao e aplicao e proporcionar satisfao ao usurio;
Manutenibilidade: deve permitir fcil manuteno para que correes ou atualizaes
sejam realizadas de modo fcil e eficiente;
Evolutibilidade: deve permitir expanso de suas funcionalidades para atender novos requisitos ou incorporar novas tecnologias;
Portabilidade: deve poder ser executado no maior nmero possvel de equipamentos;
Interoperabilidade: deve ser capaz de interagir com diferentes sistemas e plataformas.
05. No a mesma coisa. Qualidade e segurana so diferentes, dentro do contexto de
software. No entanto, a segurana 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 usurios. A determinao dos atributos relevantes a cada sistema depende do domnio da aplicao, das tecnologias utilizadas, das caractersticas especficas do
projeto e das necessidades do usurio e da organizao.
captulo 5
145
Captulo2
01. As principais dificuldades para uma empresa ou organizao implantar uma norma de
qualidade de produtos de software estariam relacionadas mudana ou readequao dos
processos da mesma, podendo causar grandes resistncias entre os colaboradores, dependendo da cultura organizacional ali existente, bem como exigir um nvel de maturidade (quanto a processos) para que as normas sejam implantadas com sucesso. Ter o apoio da alta gerncia essencial, bem como o apoio de todos os envolvidos neste processo de mudanas.
02. O impacto seria negativo, com softwares de baixa qualidade. Portanto, praticamente
impossvel desenvolver softwares de qualidade sem qualquer tipo de controle de processos,
uma vez que estes so essenciais para o xito da qualidade do software. No entanto, caso
no seja considerado os aspectos de qualidade em um software, a sim podemos considerar
que possvel desenvolver softwares sob estas condies, mas totalmente desprovidos de
qualidade.
03. Esta uma pergunta que solicita sua opinio; pense e reflita sobre ela. Julgar que todas
as empresas devam implantar uma norma pode parecer utpico, mas seria o ideal, pois assim
as organizaes estariam alcanando altos nveis de maturidade e estariam sempre buscando a melhoria contnua.
04. A ISO publicou uma norma que representa uma padronizao 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 traduo
para o Brasil, publicada em agosto de 1996 como NBR 13596. Esta norma apresenta um
conjunto de caractersticas 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 so 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
iro ser determinando para o resultado da qualidade.
Captulo3
01. Diversos problemas podem ocorrer durante a atividade de levantamento de requisitos,
sendo que os principais identificados, de acordo com Santos (2004, p. 24), sao:
o conhecimento do dominio do negocio encontra-se espalhado por diversos meios, tais
como: livros, sistemas existentes, manuais de operacao, envolvidos, etc.;
146
captulo 5
o tempo escasso e a disponibilidade dos envolvidos;

fatores politicos e organizacionais, podendo nao ser muito clara sua existencia aos envolvidos;
os envolvidos nao sabem exatamente o que fazem, o que precisam e o que querem que
seja desenvolvido.
02. Em algumas situaes mais fcil reunir analistas e usurios para simular situaes
reais e necessrias no futuro sistema do que tentar estabelecer as necessidades por meio
de outros mtodos mais abstratos. Para isto so usados os cenrios. Os cenrios servem
para revelar detalhes que no foram percebidos e adicion-los aos esboos dos requisitos.
O estabelecimento dos cenrios pode ser feito informalmente com os analistas trabalhando
com os usurios principais ou fomentadores do projeto a fim de identificar os usurios operacionais e captar detalhes, ou outras formas. Os cenrios so muito usados nos mtodos
geis de desenvolvimento.
03. Requisitos no-funcionais: So restries sobre os servios ou as funes oferecidos pelo Sistema. Entre ele: destacam-se restries de tempo, restries sobre o processo
de desenvolvimento, padres, entre outros. Exemplos: Nao poderao ocorrer perdas de informacoes; O sistema dever ter alta disponibilidade; O sistema dever ser executado em
qualquer navegador; O sistema dever comportar com velocidade satisfatria, com menos
de 3 segundos.
04. Letra c
05. Vamos deixar aqui a definio dada por Leite (2000b) para que voc compare com a
sua resposta: Requisitos so objetivos ou restries estabelecidas por clientes e usurios
do sistema que definem as diversas propriedades do sistema. Os requisitos de software so,
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 condio ou
capacidade necessria que o software deve possuir para que o usurio possa resolver um
problema ou atingir um objetivo ou para atender as necessidades ou restries da organizao ou dos outros componentes do sistema
Captulo4
01. Alguns exemplos de softwares que trabalham com gerenciamento de requisitos so:
Jeremia, OSRMT, Tiger Pro e Xuse. Segue uma sugesto de artigo que faz um estudo comparativo entre ferramentas de Gerncia de Requisitos: http://www.cin.ufpe.br/~tg/2009-2/
rrta.pdf
captulo 5
147
02. O rastreamento pode ser realizado de diferentes formas, entre elas devemos destacar
as seguintes:
Rastreamento de origem, em que realizada a associao entre os requisitos e os stakeholders que propuseram tal requisito.
Rastreamento de requisitos, em que identificada a associao de um determinado requisito com a dependncia existente com outros requisitos.
Rastreamento de projeto, em que identificada a associao de um requisito com o projeto
como um todo.
Para a melhor visualizao do rastreamento o ideal utilizar-se de uma representao
grfica de referncia cruzada ou matriz de rastreamento. Neste modelo os requisitos so
dispostos nas linhas e colunas de uma tabela e suas dependncias so representadas por
letras ou smbolos
03. Sim, o fato de ter muitas mudanas de requisitos influencia a escolha dos mtodos de
desenvolvimento de um software pois certas metodologias lidam melhor e outras no com
este tipo de situao. Um exemplo disto o mtodo cascata, ou clssico, que exige que todos
os requisitos sejam definidos desde o princpio para que o projeto siga o planejamento sem
contar com alteraes, enquanto que os mtodos geis, onde prev iteraes cclicas, permite que mudanas aconteam e possuem tcnicas adequadas para lidar com estas mudanas.
04. Buscando a qualidade importante que a Especificacao de Requisitos de Software
atenda a alguns preceitos de qualidade de software, conforme definidos por padroes internacionais (como, por exemplo, o IEEE, o CMM e o SPICE). Para tanto a especificacao deve ser:
ESPECIFICAES:
CORRETA
PRECISA
COMPLETA
CONSISTENTE
148
captulo 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 interpretacao, acordada entre
os usuarios e os desenvolvedores. As dvidas podem ser dirimidas
com um dicionrio de termos, que deve ser declarado para resolver
as dvidas que surgirem
Deve refletir todas as decisoes de especificacao que foram tomadas
ao longo de sua discussao, envolvendo os usuarios e os desenvolvedores. Deve trazer de forma bem clara e definida a sua funcionalidade, desempenho desejado, restricoes de projeto (tecnicas e nao
tecnicas), atributos necessarios e, caso exista, relacionamento com
outras aplicacoes. Procurar contemplar todas as situacoes possiveis
Nao ter nenhum conflito ou sobreposicao a outros requisitos
PRIORIZADA
VERIFICVEL
MODIFICVEL
RASTREVEL
REUTILIZVEL
Definir prioridades de acordo com a importncia, estabilidade e complexidade. Dentro destes critrios, os requisitos podem ser:
- essencial: requisito sem o qual o produto nao atende as necessidades do usuario;
- desejavel: sua existencia aumenta o valor do produto, mas se por
alguma necessidade nao for contemplado nao afeta de forma substancial a utilizacao do produto;
- opcional: requisito que podera ser incluido caso haja disponibilidade de prazo e orcamento, caracterizando-se como a ultima
prioridade a ser atendida;
A principio todos os requisitos devem ser verificaveis. Ele sera verificavel se existir um processo finito que possa ser executado por uma
pessoa ou maquina e, principalmente, que mostre sua conformidade
com o solicitado
A mudanca de todo e qualquer requisito pode ser realizada de forma
facil, completa e consistente,
Permite que seja facilmente verificada sua consequncia quando
ocorrer uma modificacao. 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 especificacao dos requisitos seja facilmente reutilizavel, ou
seja, se tivermos alguma funcionalidade a ser referenciada por um
outro requisito que nao seja necessario descrev-la novamente.
05. Durante o estagio de gerenciamento de requisitos, decide-se sobre:

Identificacao de requisitos - Cada requisito precisa ser identificado de modo unico, para
que possa ser feita a referencia cruzada deste com os outros requisitos e para que ele possa
ser utilizado nas avaliacoes de facilidade de rastreamento.
Processo de gerenciamento de mudancas - Trata-se do conjunto de atividades que avalia
o impacto e o custo das mudancas.
Polticas de facilidade de rastreamento - Essas politicas definem as relaes entre os
requisitos e entre os requisitos e o projeto de sistema que devem ser registrados e tambm
como esses registros devem ser mantidos.
Suporte de ferramentas CASE - O gerenciamento de requisitos envolve processar uma
grande quantidade de informaes sobre os requisitos. As ferramentas que podem ser utilizadas vo desde sistemas especializados de gerenciamento de requisitos ate planilhas de
clculo e sistemas simples de bancos de dados.
captulo 5
149
Captulo5
01. Deixaremos aqui algumas ferramentas para modelagem de software como sugesto de
pesquisa:
IBM Rational Requisite Pro: Um produto integrado poderoso de fcil utilizao para gerenciamento de requisitos e de referncia de utilizao que promove melhor comunicao,
aprimora o trabalho em equipe e reduz o risco do projeto. Inclui ferramentas de gerenciamento de requisitos, de modelagem dos negcios e de modelagem de dados.
JUDE (Atual ASTAH) ou Java and UML Developer Environment: uma das ferramentas grtis para UML mais poderosas disponveis atualmente. Com caractersticas que no
so encontradas nas outras ferramentas grtis, como adicionar mtodos no diagrama de
sequncia e a alterao 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 padro. uma ferramenta
open-source.
Poseidon para UML: a ferramenta de modelagem de sistemas da empresa alem
Gentleware AG. O Poseidon uma evoluo da ferramenta de cdigo-aberto ArgoUML que
com mais de 350.000 instalaes 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 criao de banco de dados mySQL que integra criao,
modelagem, desenvolvimento e manuteno dos bancos em um ambiente simples e agradvel. Comparvel com produtos como Oracles Designer, IBMs Relational Rose, CA Erwin. O
DBDesigner OpenSource distribudo sobre a licena GPL.
IBExpert: O IB Expert um poderoso gerenciador de banco de dados que permite realizar todas as tarefas necessrias para o suporte e manuteno do banco tanto local como
remotamente. Com ele possvel administrar o banco criando tabelas, modificando campos,
ndices, executando scripts SQL e outras funes. O IB Expert realiza a gerao do modelo
de entidade relacionamento para bancos de dados Interbase e Firebird.
02. A UML uma linguagem de modelagem e no um mtodo de desenvolvimento, pois
muitas pessoas confundem isso. No se encontra na UML a sequncia de passos para se
desenvolver um software nem para se modelar. A limitao da UML representar o sistema
por meio de diagramas comuns e integrados envolvendo as questes estticas e dinmicas
de um sistema de informao. A UML permite elaborar diversos diagramas para visualizao, especificao, construo e documentao de diversas partes do sistema em diversas
etapas do ciclo de vida. Existem vrios tipos de diagramas que permitem modelar aspectos
dinmicos do sistema atravs da UML.
150
captulo 5
03. Os atores representam usurios e outros sistemas que interagem com sistema modelado. Eles so representados graficamente por um homem palito (boneco-de-palitos). Os
casos de uso mostram o comportamento do sistema, cenrios que o sistema percorre em
resposta ao estmulo de um ator.
04. O diagrama de sequncia normalmente est associado ao comportamento de um nico
caso de uso e, tambm, podem representar um determinado cenrio do sistema.
05. O diagrama de classes talvez seja o diagrama mais importante e usado na UML. ele
quem modela a estrutura esttica das classes de um sistema. No diagrama so mostradas
as associaes entre as classes e seus tipos, a especificao das classes, especializaes e
generalizaes e os agrupamentos em pacotes. O interessante do diagrama de classes que
ele pode ser implementado usando alguma linguagem de programao orientada a objetos.
Existem vrias ferramentas CASE que aps o desenho do diagrama de classes gera o cdigo
em Java, C++, C#, etc.
captulo 5
151
ANOTAES
152
captulo 5

Livro Proprietario - Requisitos de Sistemas

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Livro Proprietario - Requisitos de Sistemas

Загружено:

Авторское право:

Доступные форматы

REQUISITOS DE

SAULO FRANA AMUI

Dados Internacionais de Catalogao na Publicao (cip)

Requisitos de sistemas / Saulo Amui.

Rio de Janeiro : SESES, 2015.

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

3. Processos de software. 4. Gesto de requisitos. I. SESES. II. Estcio.

Diretoria de Ensino Fbrica de Conhecimento

2. Processos de Ciclo de Vida e Qualidade

2.2.2 Guias para a Avaliao da Qualidade - ISO 14598

3. Anlise e Especificao de Requisitos

4.2 Gerenciamento de Requisitos

5. Modelagem do Projeto - UML

Neste primeiro captulo comearemos tratando de um assunto de extrema

1.2 Conceitos de qualidade

A ISO (International Organization for Standardization Organizao Internacional para

Manutenibilidade: deve permitir fcil manuteno para que correes ou

1.2.3 Gesto da Qualidade

Figura 1.1 Processo de desenvolvimento de software.

A qualidade do software ser proveniente do gerenciamento deste processo,

O controle do processo consiste na competncia em controlar o processo de

1.2.4 Processos de Software Sem Controle

1.2.5 Processos de Software Bem Controlados

1.2.6 Implantao de um Programa de Qualidade

1.3 Processo de Qualidade de Software

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

usado para desenvolver

Figura 1.2 ISO 9000 e o gerenciamento de qualidade.

1.4 Mtricas de Qualidade de Software

O modelo de McCall esta organizado em trs nveis:

Conciso: a compactao do programa em termos de linhas de cdigo.

1.5 Garantia da qualidade de software (SQA)

Desta forma, todo o esforo a ser empregado para efetuar correes do

Tarefas especificas de garantia da qualidade e controle da qualidade (inclusive

revisoes tecnicas e uma estrategia de testes multiescalonados);

Pratica efetiva de engenharia de software (metodos e ferramentas;

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

Um procedimento para garantir a conformidade com os padroes de desenvolvi-

mento de software (quando aplicaveis) e;

Mecanismos de medicao e de relatorios.

No entanto, empresas que no possuem o grupo ou processos de SQA tem

Elementos de Garantia da Qualidade de Software

Revisoes e auditorias: As revisoes tecnicas sao uma atividade de controle de

Administracao da seguranca: Com o aumento dos crimes ciberneticos e novas

Data and Analysis Center for Software (DACS)

1.6 Estatstica da Garantia da Qualidade de

Pressman (2011, p. 393) prope as seguintes etapas para a estatstica da

Informacoes sobre erros e defeitos de software sao coletadas e classificadas.

exemplo, a nao adequacao as especificacoes, erros de projeto, violacao de padroes,

a correcao dos problemas que provocaram os erros e defeitos.

Estas etapas propostas e aes representam um passo importante para a

1.7 Revises tcnicas

Freedman e Weinberg discutem a necessidade de revisoes da seguinte maneira:

Apontar aperfeicoamentos necessarios no produto de uma unica pessoa ou de

Confirmar aquelas partes de um produto em que aperfeicoamentos sao indeseja-

Mesmo um pequeno subconjunto de mtricas, reunidas para cada reviso

Erros secundarios encontrados, Errsec - o numero de erros encontrados que

Bugs, erros e defeitos

Independentemente da maneira escolhida para interpretar esses termos ou do

1.8 Revises informais

1.9 Revises Tcnicas Formais

1.9.1 Diretrizes de reviso

Estabelecer uma agenda e mante-la. Um dos principais males de reunioes

Limitar debates e refutacao. Quando uma questao e levantada por um revisor,