CENTRO UNIVERSITRIO DA FUNDAO EDUCACIONAL GUAXUP

FBIO DA CUNHA DINIZ

LUCIENE DE FTIMA RESENDE CORREA

LEVANTAMENTO E ANLISE DE REQUISITOS PARA APLICAO WEB:

ASPECTOS TERICOS E A MODELAGEM

GUAXUP
2012

FBIO DA CUNHA DINIZ

LUCIENE DE FTIMA RESENDE CORREA

LEVANTAMENTO E ANLISE DE REQUISITOS PARA APLICAO WEB:

ASPECTOS TERICOS E A MODELAGEM

Trabalho de concluso de curso apresentado ao

Centro Universitrio da Fundao Educacional
Guaxup, como exigncia parcial para
obteno do Bacharelado em Cincia da
Computao.
Orientadora: Prof. Ms. Jaciara Silva Carosia

GUAXUP
2012

ATA DE APROVAO

ATA DE APROVAO 2

DEDICATRIA

Dedico este trabalho a todos os meus amigos,

familiares, os quais me ajudaram nesta
caminhada sempre apoiando as minhas
decises.
Dedico ao meu esposo Joo Batista Correa,
que foi a pessoa mais importante para que
chegasse ate aqui, sempre me ajudando e
apoiando nesta minha jornada, ao meu pai (in
memria) Pedro Candido Resende Neto, que
sempre me incentivou, a minha me Maria de
Ftima da Silva Resende e irms, pela fora
que me deram, ao meu grande amigo Fbio
Diniz, com quem desenvolvi o TCC.

AGRADECIMENTOS

professora Ms. Jaciara Silva Carosia, pela ateno e orientao imprescindveis realizao
desse trabalho.
biblioteca do Unifeg, pelos livros emprestados durante todo o ano.
Prefeitura Municipal de Bom Jesus da Penha, pelo transporte fornecido aos alunos.
todos colegas de trabalho, que me apoiaram e incentivaram nesta caminhada.
minha me e ao meu pai que me motivaram durante toda a minha vida e principalmente
quando decidi fazer faculdade.
todos os professores, que ao longo do curso nos transmitiram conhecimento.
Agradecimentos em especial professora Ms. Jaciara Silva Carosia, que nos apoiou , dando a
ateno em todos os momentos de dificuldades. Aos professores Ricardo Vicente Fvero e
Lucas Ximenes Boa Sorte, que nos avaliaram. professora Adriana Carvalho dos Santos, que
nos orientou tirando todas as nossas dvidas.

A vida sempre nos fornece oportunidades,

portanto, cabe a cada um de ns saber
identific-las e aproveit-las de maneira
coesa.
(Fbio Diniz)

Resumo
Os clientes e usurios da indstria de software esto cada vez mais exigentes em
relao qualidade das aplicaes entregues. Para auxiliar os desenvolvedores a criarem
produtos de software adequados ao uso, a engenharia de software prope vrios mtodos e
tcnicas que podem auxiliar na tarefa de levantamento e anlise de requisitos.
Alm da crescente demanda por aplicaes web, estas tm se tornando cada vez mais
complexas. Tendo em vista a constante busca pela qualidade destas aplicaes, o presente
trabalho enfatiza a importncia do levantamento e anlise de requisitos para aplicaes web.
Portanto, necessrio que a equipe tcnica envolvida no projeto utilize todos os recursos
disponveis na engenharia software para obter os requisitos do sistema de forma clara e
objetiva. Quando a anlise e levantamento de requisitos feita de forma organizada possvel
obter um ndice elevado da qualidade do produto final e consequentemente a satisfao do
cliente em relao organizao responsvel pela criao do sistema.
Palavras-chaves
Levantamento, Anlise, Requisitos, Modelagem.
Abstract
Customers and users of the software industry are increasingly demanding about the
quality of the delivered applications. To help developers create software products suitable for
use in software engineering proposes several methods and techniques that can assist in the
task of gathering and analyzing requirements.
Besides the growing demand for web applications, they are becoming increasingly
complex. Given the constant search for quality of these applications, this paper emphasizes
the importance of the survey and requirements analysis for web applications. Therefore, it is
necessary that the technical staff involved in the project use all available resources in
engineering software for system requirements clearly and objectively. When the analysis and
requirements gathering is done in an organized manner is possible to obtain a high rate of
end-product quality and hence customer satisfaction in relation to the organization responsible
for creating the system.
Keywords
Survey, Analysis, Requirements, Modeling

FIGURAS

Figura 1 - Fatores de qualidade de software McCall .......................................................... 20

Figura 2 - Modelo Cascata ..................................................................................................... 23
Figura 3 - Modelo Incremental.............................................................................................. 24
Figura 4 - Problemas enfrentados na construo de Sistemas .......................................... 25
Figura 5 - Erro de comunicao durante o processo de desenvolvimento de software.... 26
Figura 6 - Home ...................................................................................................................... 41
Figura 7 - Cardpio ................................................................................................................ 42
Figura 8 - Pedido de pizza via e-mail .................................................................................... 43
Figura 9 - Diagrama de caso de uso cliente .......................................................................... 46
Figura 10 - Diagrama de caso de uso usurio do sistema ................................................... 47
Figura 11 - Diagrama de contedo........................................................................................ 49

Sumrio
1. Introduo .......................................................................................................................... 12
2. Conceitos ............................................................................................................................. 13
2.1. Engenharia de Software .................................................................................................. 13
2.2. Requisito ........................................................................................................................ 14
2.2.1. Requisitos funcionais .................................................................................................... 15
2.2.2. Requisitos no-funcionais ............................................................................................. 15
2.2.3. Requisitos de domnio ................................................................................................... 16
2.2.4. Requisitos de usurio .................................................................................................... 17
2.2.5. Requisitos de sistema .................................................................................................... 18
2.3. Qualidade ......................................................................................................................... 19
2.4. Teste de validao ............................................................................................................ 21
2.5. Ciclo de vida de sistema .................................................................................................. 22
2.5.1. Modelo cascata .............................................................................................................. 22
2.5.2. Modelo incremental ...................................................................................................... 23
3. Engenharia de requisitos ................................................................................................... 25
3.1. Objetivo ............................................................................................................................ 25
3.2. Dificuldades ...................................................................................................................... 25
3.2.1. Entendimento ................................................................................................................ 27
3.2.2. Volatilidade .................................................................................................................... 27
3.2.3. Escopo ............................................................................................................................ 28
3.3. Atividades ......................................................................................................................... 28
3.3.1. Viabilidade ..................................................................................................................... 28
3.3.2. Levantamento de requisitos ......................................................................................... 29
3.4. Tcnicas de levantamento de requisitos ........................................................................ 30
3.4.1. Ponto de vista ................................................................................................................. 30
3.4.2. Entrevista ....................................................................................................................... 31
3.4.3. Cenrios ......................................................................................................................... 32
3.4.4. Etnografia ...................................................................................................................... 33
3.4.5. Validao........................................................................................................................ 34
3.5. Gerenciamento de requisitos .......................................................................................... 35
3.6. Modelagem grfica .......................................................................................................... 36
4. Aplicaes web ................................................................................................................... 37
5. Modelagem de Requisitos para web ................................................................................. 40
5.1. Prototipao ..................................................................................................................... 40

5.2. Processo de desenvolvimento de um prottipo ............................................................. 41

5.3. UML (Unified Modeling Languagem) ......................................................................... 44
5.4. A importncia da UML ................................................................................................... 45
5.5. Diagramas de Caso de Uso ............................................................................................. 45
5.7. Diagrama de Contedo ................................................................................................... 48
6. Concluso ............................................................................................................................ 49

12

1. Introduo
A anlise de requisitos de software a primeira fase de desenvolvimento de
software, tendo como objetivo a interao entre o analista, o cliente e futuros usurios do
sistema para determinar funcionalidades do software. Para se obter sucesso no
desenvolvimento do software necessrio um completo entendimento de seus requisitos,
evitando, assim, a frustrao do cliente futuramente. A anlise de requisitos um processo de
descoberta e entendimento das necessidades do cliente, modelagem do software e
especificao dos requisitos. Um requisito uma caracterstica apresentada pelo sistema ou
uma descrio do que capaz de realizar para atingir seus objetivos.
De acordo com Pressman (2011), a engenharia de requisitos tem como objetivo
fornecer o mecanismo apropriado para analisar, avaliar, negociar, especificar e validar as
necessidades de acordo com o sistema operacional que ser utilizado dentro da empresa ou de
acordo com a necessidade do cliente. importante lembrar tambm, que alguns destes
mecanismos citados podem ocorrer em paralelo.
A anlise de requisitos vai muito alm de somente registrar o que o cliente quer.
Segundo Pressman (2011) a engenharia de requisitos tem como objetivo estabelecer uma base
concreta para o projeto e para a construo. Sem ela, o software resultante tem grande
probabilidade de no atender as necessidades do cliente, importante poder identificar os
requisitos de forma clara, para que ambas as partes, isto , desenvolvedor e cliente, possam
concordar dando continuidade ao projeto. Feito este processo, faz-se necessrio verificar
realmente o que um requisito para o sistema, com o intuito de poder defini-los e documentlos.
O levantamento de requisitos uma das partes mais importantes no processo de
desenvolvimento de software, sendo determinante para analisar o que o cliente deseja para,
assim, poder definir as regras de negcios e os seus processos. Um levantamento de requisitos
aliado ao mapeamento de processo de suma importncia, pois estabelecem atividades,
metodologias, comunicao, planejamento, modelagem, construo e entrega. Alm disso,
necessrio contar com um conjunto de atividades de apoio que so aplicadas ao longo do
processo como acompanhamento e controle do projeto, administrao de riscos,
gerenciamento de configuraes, revises tcnicas entre outras. No decorrer do
desenvolvimento do projeto muitos sistemas so retardados em seu prazo, ou at mesmo
abandonados durante o percurso de construo, pois, a fase de levantamento de requisitos
simplesmente feita de forma equivocada.

13

Desta forma, o objetivo geral deste trabalho demonstrar a importncia do

levantamento e anlise de requisitos para as empresas desenvolvedoras de software, pois esta
atividade a base para desenvolvimento de sistemas de qualidade, sendo sistemas para web,
desktop, dispositivos mveis entre outros.
O objetivo especfico demonstrar o uso da modelagem como tcnica facilitadora
para o levantamento e anlise de requisitos de aplicaes web.
A metodologia seguida para o desenvolvimento deste trabalho foi uma pesquisa
bibliogrfica atravs da qual so demonstrados os aspectos tericos do levantamento e analise
de requisitos, bem como o uso da modelagem grfica e da prototipao nesta atividade.
O processo de construo de sites para web deve acontecer de forma rpida. Assim,
necessrio que os analistas organizem e estruturem os requisitos que foram obtidos juntos ao
cliente para que possam gerar rapidamente um prottipo do sistema. Este prottipo ser
mostrado ao cliente e este ir validar se as caractersticas presentes no prottipo so aquelas
que ele esperar encontrar no produto final e eventualmente sugerir melhorias no prottipo.
Segundo Freed Books apud Pressman (2011, pag. 127) a parte mais difcil ao
construir um sistema de software, decidir o que construir. Nem uma parte do trabalho afeta
tanto o sistema resultante se for feita a coisa errada. Nem uma parte mais difcil de consertar
depois.
A engenharia de requisitos de extrema importncia para a engenharia de software,
pois, atravs desta rea possvel obter os requisitos para a construo de sistemas tanto para
dispositivos mveis, desktops e quanto para a web. Quando este levantamento feito de
maneira consciente consegue-se desenvolver softwares com um grau extremamente alto de
qualidade, objetivo este que almejado por qualquer desenvolvedor, analista e principalmente
pelo cliente.

2. Conceitos
2.1. Engenharia de Software
De acordo com Pressman (2011), a engenharia de software uma tecnologia que se
baseia em camadas, e que esta fundamentada no objetivo de conseguir obter o maior
comprometimento com a qualidade dos sistemas a serem construdos, portanto, esta em uma
constante busca para aperfeioar os seus processos.

14

Para Pfleeger (2004), a engenharia de software uma rea que busca solucionar os
problemas relacionados a computadores ou a um determinado sistema computacional j
existente. Desta forma, necessrio entender a natureza do problema para que depois se possa
obter uma soluo plausvel.
Segundo Pressman (2011), a engenharia de software uma rea da computao cujo
objetivo principal a especificao, desenvolvimento e manuteno de sistemas de software,
utilizando-se de tecnologias e prticas as quais tem com funo fazer o gerenciamento dos
projetos visando organizao, produo e qualidade.
De acordo com Sommerville (2007), esta cincia baseia-se em modelos abstratos e
precisos os quais permitem ao engenheiro de software especificar, projetar, implementar e
manter sistemas de software, avaliando e garantindo a sua qualidade.
Segundo Sommerville (2007), a engenharia de software aborda trs definies
complementares que ajudam a entender melhor o seu funcionamento:
Est envolvida com a produo e manuteno de sistemas desenvolvidos com custos
e prazos estimados;
Apresenta muitas partes interconectadas e diferentes verses. As quais so
construdas por uma equipe de analistas, projetistas, programadores, gerentes,
testadores, etc;
O estabelecimento e uso de princpios de engenharia para a produo
economicamente vivel de software de qualidade que funcione em mquinas reais.
Portanto, o objetivo principal da engenharia de software organizar e estruturar o
processo de desenvolvimento de Software, tentando ao mximo evitar falhas.
A engenharia de software aborda todas as etapas do processo de desenvolvimento de
software. A engenharia de requisitos uma delas, a qual visa fazer o levantamento de
requisitos do sistema a ser desenvolvido, para que de tal forma possa garantir a qualidade do
produto.

2.2. Requisitos
Segundo Sommerville (2007), requisitos de um sistema so as descries fornecidas
pelo sistema e as suas restries operacionais. Estes apresentam as necessidades dos clientes
para solucionar um problema dentro da organizao tais como: controlar um dispositivo,
enviar um pedido ou encontrar informaes dentro de um banco de dados da empresa.

15

Segundo Pfleeger (2004), requisito uma caracterstica do sistema ou uma descrio

de algo que o sistema capaz de realizar, para atingir seus objetivos.
Assim, o entendimento dos requisitos de extrema importncia, pois atravs dele se
consegue identificar as possveis funes que o sistema ir desempenhar na empresa.
Os requisitos podem ser agrupados em vrias categorias, sendo elas: requisitos
funcionais, requisitos no-funcionais, requisitos de domnio, requisitos de usurio e requisitos
de sistema.

2.2.1. Requisitos funcionais

Para Sommerville (2007), os requisitos funcionais so caractersticas que o sistema
deve fornecer ao cliente para que possa desenvolver uma determinada funo. O levantamento
destes tipos de requisitos ira depender de alguns fatores que podem influenciar o desempenho
final do sistema, tais como: o software que est sendo desenvolvido, os usurios que utilizaro
o software e a abordagem geral considerada pela organizao.
Segundo Sommerville (2007), o levantamento de requisitos feito de forma
equivocada uma das maiores dificuldades enfrentadas pela engenharia de software, pois de
forma geral possvel que o desenvolvedor do sistema interprete um requisito de forma
ambgua, de tal forma, que este venha a simplificar sua implementao. Sendo assim, faz-se
necessrio definir novos requisitos e fazer algumas mudanas no sistema, atrasando sua
entrega e consequentemente aumentando seus custos.
De acordo com Pfleeger (2004), os requisitos funcionais tentam de alguma forma
descrever a interao do sistema com ambiente. Portanto, so utilizados para decidir os
estados que podem ser aceitos pelo sistema. Alm de que, tambm descrevem de alguma
forma como o sistema deve se comportar levando-se em considerao um estmulo do
ambiente.
Logo, os requisitos funcionais do sistema so todas as funes que o sistema deve
desempenhar dentro do ambiente organizacional da empresa quando recebe um determinado
estmulo.

2.2.2. Requisitos no-funcionais

Para Sommerville (2007), apresenta restries impostas sobre os servios ou funes

16

oferecidas pelo sistema. Estas restries referem-se a: restries de timing, restries sobre o
processo de desenvolvimento e padres.
Segundo Sommerville (2007), os requisitos no funcionais podem estar envolvidos
pelas propriedades emergentes do sistema, como confiabilidade, tempo de resposta e espao
de armazenamento. Estes tipos de requisitos podem restringir o processo que deve ser
utilizado para desenvolver o sistema. Alguns exemplos de requisitos de processo so:
Especificao dos padres de qualidade que devem ser usados pelo processo;
O projeto deve utilizar ferramentas CASES para auxiliar o desenvolvimento;
A descrio do processo deve ser seguida.
De acordo com Sommerville (2007), os requisitos no-funcionais surgem devido a:
necessidades do usurio, restries de oramento, polticas organizacionais, interoperabilidade
com outros sistemas de hardware ou software, segurana e privacidade.
Ainda de acordo com Sommerville (2007), os requisitos no-funcionais como um
todo so difceis de serem verificados durante o seu levantamento, pois os clientes definem
esses requisitos como metas gerais, usabilidade, capacidade do sistema de se recuperar de
falhas ou de respostas rpidas ao usurio. Estas metas causam um grande problema para os
desenvolvedores, pois, deixam o escopo sugerido para interpretao e discusses futuras com
cliente verificando o que ele realmente necessita.
Segundo Pfleeger (2004), os requisitos no-funcionais so restries impostas pelo
sistema, portanto, tem como funo limitar as aes. Por exemplo, um setor no pode acessar
as informaes e dados de outro setor a no ser que seja um gerente desta rea de atuao
organizacional.
As situaes que podem influenciar no projeto final do sistema so: as caractersticas
do software que est sendo desenvolvido, os usurios que utilizaro o software e a abordagem
geral considerada pela organizao.
Portanto, os requisitos no-funcionais so aqueles que apresentam determinadas
restries que devem ser consideradas durante o desenvolvimento do sistema ou durante sua
utilizao.

2.2.3. Requisitos de domnio

Segundo Sommerville (2007), so derivados do domnio de uma aplicao de
sistema, em vez de necessidades especificas dos usurios do sistema. Podem ser novos

17

requisitos funcionais, os quais iro restringir os requisitos j existentes ou estabelecer clculos

especficos dentro do sistema.
De acordo Sommerville (2007), um dos grandes problemas observados nos requisitos
de domnio o fato de que so redigidos na linguagem de domnio de aplicao. Assim, a
maioria dos engenheiros de software apresenta grande dificuldade em entend-los. Podendo,
de tal forma deixar de considerar informaes importantes pelo fato de as considerarem
relevantes.
Para Firesmith apud Pressman (2011), a anlise de domnio uma maneira de
identificar, analisar os requisitos comuns de um determinado campo de aplicao e que pode
ser reutilizado em outros projetos do mesmo campo.
Os requisitos de domnio apresentam como objetivo especificar o que necessrio no
sistema, por exemplo, funes ou clculos especficos que o software deva executar dentro da
empresa.

2.2.4. Requisitos de usurio

Segundo Sommerville (2007), os requisitos de usurio devem compreender tanto os
requisitos funcionais quanto os no-funcionais de forma que este seja entendido por quem ir
operar o sistema dentro da empresa, pois estes no detm um conhecimento tcnico detalhado.
De acordo com Sommerville (2007), estes requisitos possuem muitas informaes
restringindo de tal forma a liberdade que o desenvolvedor do sistema possui de apresentar
solues inovadoras para os problemas do usurio e so difceis de serem compreendidos.
Assim, devem-se focar somente os recursos principais a serem fornecidos.
Para Sommerville (2007), no levantamento de requisitos do usurio devem-se levar
em considerao algumas diretrizes, que tem como objetivo diminuir os mal-entendidos entre
o cliente e o desenvolvedor. Estas diretrizes podem ser:
Aderir a um formato padro que assegure que as definies dos requisitos aderiram a
este formato, tornando de tal forma as omisses menos provveis e os requisitos fceis
de serem entendidos;
Deve-se utilizar uma linguagem consistente, distinguindo requisitos obrigatrios e
desejveis;
Destacar o texto, ressaltando as partes principais dos requisitos;
Evitar usar os termos tcnicos presentes na informtica, pois isto dificultara o
entendimento do usurio.

18

Portanto, os requisitos de usurio compreendem tanto os requisitos funcionais quanto

os no-funcionais, e so difceis de serem compreendidos, pois, os usurios normalmente
escondem os seus verdadeiros atributos dentro da organizao.

2.2.5. Requisitos de sistema

Segundo Sommerville (2007), os requisitos de sistema so verses expandidas dos
requisitos de usurios e so usados como ponto de partida para o desenvolvimento do sistema,
adicionando detalhes e explicando como os requisitos de usurio devem ser fornecidos atravs
do sistema.
Para Sommerville (2007), os requisitos devem simplesmente distinguir o
comportamento externo do sistema determinando suas restries operacionais. Para se
detalhar um sistema complexo impossvel incluir todas as informaes de projeto, pelas
seguintes razoes:
Pode ser necessrio projetar uma arquitetura inicial do sistema que ajudar na
especificao dos requisitos;
O sistema deve operar com outros sistemas j existentes;
O uso de uma arquitetura especifica pode ser utilizada para satisfazer os requisitos
no funcionais.
Segundo Sommerville (2007), a linguagem natural normalmente utilizada para
redigir as especificaes de requisitos de sistema e de usurios. Como os requisitos de sistema
so mais detalhados que os de usurio, a linguagem natural pode ser mais confusa e difcil de
ser compreendida:
A compreenso da linguagem formal depende da utilizao das mesmas palavras
para os conceitos de leitores e elaboradores de especificao;
A especificao de requisitos em linguagem formal muito flexvel, pois possvel
dizer a mesma coisa de maneira diferente;
No possvel padronizar os requisitos em linguagem natural. Caso seja necessrio
efetuar alguma mudana necessrio verificar todos os requisitos em vez de apenas um
grupo.
A clara definio dos requisitos interfere diretamente na qualidade do produto final.
Um software de qualidade aquele que faz o que o cliente deseja e o que ele deseja
corresponde aos requisitos.

19

2.3. Qualidade
Segundo Darwin apud Pressman (2011) qualidade um conceito complexo e
multifacetado o qual pode ser descrito de cinco formas diferentes. A viso transcendental, a
qual sustenta que a qualidade algo que pode ser reconhecida imediatamente, mas no
explicita. A viso de usurio v a qualidade como metas que o usurio final deve atingir.
Viso do fabricante define-se atravs da especificao original do produto. A viso do
produto esta diretamente ligada s caractersticas do sistema. E, finalmente, viso baseada no
valor, que est diretamente ligada a quanto o cliente est disposto a desembolsar por um
sistema de qualidade.
Segundo Pressman (2011), em relao qualidade do projeto este se refere as
caractersticas que os projetistas especificam para um produto, tais como: a qualidade dos
materiais, as tolerncias e as especificaes de desempenho, so alguns dos fatores que
contribuem para qualidade do projeto.
Segundo Pressman (2011, p.360) a qualidade de software pode ser descrita como:
uma gesto de qualidade efetiva aplicada de modo a criar um produto til que fornea valor
mensurvel para aqueles que o produzem e para aqueles que o utilizam.
Ainda segundo Pressman (2011), alguns pontos importantes da qualidade de software
so as seguintes:
A gesto de qualidade especifica tem como objetivo estabelecer infraestrutura para
fornecer suporte a qualquer momento podendo gerar um produto de alta qualidade
dentro do mercado;
O produto til deve fornecer o contedo, funes e recursos que o usurio final
deseja, devendo fornecer confiabilidade e iseno de erros;
Ao agregar valor tanto para o fabricante quanto para usurio de um produto de
software, quando construdo um software de alta qualidade pela empresa tende a gerar
benefcios para a comunidade e usurios finais.
Segundo McCall apud Pressman (2011), os fatores que afetam a qualidade de
software esto focados em trs importantes aspectos: as caractersticas operacionais, a
habilidade de suportar mudanas e a adaptabilidade a novos ambientes.

20

Figura 1 - Fatores de qualidade de software McCall

REVISO DO PRODUTO

TRANSIO DO PRODUTO

Fonte: Imagem adaptada do livro de Engenharia de Software Pressman (2011)

Segundo McCall apud Pressman (2011), possvel observar de acordo com a Figura
1 as seguintes descries sobre qualidade:
Correo: o programa satisfaz a especificao atendendo os objetivos do cliente;
Confiabilidade: o programa consegue realizar as funes exigidas com uma preciso
alta;
Eficincia: quantidade de recursos computacionais e os cdigos exigidos para
desempenhar a funo desejada;
Integridade: em relao ao acesso pelos usurios no autorizados podem ser
controlados dentro do sistema;
Usabilidade: esforo necessrio para aprender, operar e fazer entrada de dados
interpretando de tal forma a sada que o sistema ira fornecer ao usurio;
Facilidade de manuteno: esforo para conseguir corrigir um erro no sistema;
Flexibilidade: esforo para se conseguir modificar o programa;
Testabilidade: deve garantir que o sistema desempenhe a funo desejada;
Portabilidade: o sistema pode interagir com diferentes plataformas de hardware ou
software;

21

Reusabilidade: o sistema pode ser reutilizado em outras aplicaes.

Portanto, todo processo de desenvolvimento de software tem com objetivo garantir a
qualidade do produto final, isto , atingir as caractersticas de qualidade descritas
anteriormente.
Segundo Pressman (2011), o custo de qualidade esta envolvido com todos os custos
necessrios para a busca da qualidade ou para execuo de atividades relacionadas
qualidade, como custos pela falta de qualidade. Assim, para compreender estes custos, uma
organizao deve reunir mtricas para propor uma base de custo corrente de qualidade,
identificando oportunidades para reduzi-los fornecendo uma base slida de comparao.
O controle da qualidade engloba um conjunto de metas na engenharia de software
com o objetivo de garantir a qualidade do produto entregue ao cliente. Os modelos devem ser
todos revisados para garantir que sejam completos e consistentes. O cdigo pode e deve ser
inspecionado de modo a garantir que no haja erros antes de o teste comear. Aplica-se uma
srie de testes para descobrir erros na lgica do processamento, na manipulao de dados, e na
comunicao da interface. Uma combinao de medies e realimentao permitindo a equipe
de software ajustar o processo quando um desses produtos deixe de atender as metas
estabelecidas para qualidade.
Segundo Pressman (2011), a garantia de qualidade estabelece a infraestrutura que
prope mtodos slidos dentro da engenharia de software, gerenciamento racional do projeto
e aes de controle de qualidade fundamentais para construo de software de alta qualidade.
Esta garantia de qualidade depende de uma srie de funes de auditoria de relatrios
possibilitando a avaliao de efetividade e completude das aes de controle de qualidade. O
objetivo fornecer ao pessoal tcnico e administrativo os dados necessrios para qualidade do
produto, ganhando assim, a confiana de que as aes para atingir a qualidade desejada do
produto estejam funcionando corretamente.

2.4. Teste de validao

Segundo Pressman (2011), este tipo de teste executado quando o software se
encontra em perfeito funcionamento, tendo em mente validar o sistema como um todo. A
validao do sistema tenta mostrar que os requisitos se encontram em conformidade com a
especificao feita durante a anlise de requisitos.
Em outras palavras, o teste de validao tem como objetivo principal verificar se as
especificaes dos requisitos condizem com o real funcionamento do sistema. Os testes

22

devem ser executados juntos com o usurio final em condies que se encontram no seu dia a
dia. Podendo, portanto, utilizar-se de condies ambientes, interfaces sistemticas e massas
de dados.
De acordo com Sommerville (2007), o teste de validao tem como objetivo verificar
se os requisitos esto de acordo com o que o cliente tinha pedido.
Enfim, estes testes so utilizados para obter de alguma forma a certeza de que o
levantamento de requisitos foi feito de maneira consciente, de tal forma, que o sistema
desenvolvido apresente a qualidade pretendida pelos clientes e pela equipe tcnica de
desenvolvimento de sistemas.

2.5. Ciclo de vida de sistema

Para um software bem sucedido, e para atender as necessidades do cliente, a
engenharia de software, ao longo dos anos, props vrios modelos de processo. importante
salientar que no h um modelo ideal, todos os modelos propostos devem ser adaptados
realidade de cada empresa, aplicao e cliente.
O que comum em todos os modelos de processo propostos que a fase de anlise
de requisitos sempre antecede a codificao estando sempre presente no ciclo de vida dos
sistemas, ou seja, pode-se dar maior ou menor nfase a esta etapa, mas jamais ignor-la. Isto
pode ser constatado tanto em modelos mais antigos, como o Modelo em Cascata, quanto em
modelos mais recentes, como o Modelo Incremental.

2.5.1. Modelo cascata

O Modelo em Cascata (ou Ciclo de Vida Clssico) apresenta uma abordagem
sequencial para o desenvolvimento do software, comeando pela pesquisa do que o cliente
necessita. Avanando de tal forma pelas fases seguintes as quais so: planejamento,
modelagem, construo, emprego, e terminando no suporte contnuo do software
desenvolvido (Pressman, 2011).
Conforme Sommervillle (2007), o modelo em cascata apresenta uma sequncia de
iteraes que envolvem as atividades de desenvolvimento, isto , para que se consiga
prosseguir para as fases subsequentes necessrio terminar todo o processo que envolve a
anterior, como pode ser observado na Figura 2.

23

Figura 2 - Modelo cascata

Fonte: Imagem adaptada do livro de Engenharia de Software Pressman (2011)

Como pode ser observado na Figura 2, o levantamento de necessidades e a anlise
esto explicitamente descritos neste modelo dentro das fases Comunicao e Modelagem,
respectivamente.
Segundo Pressman (2011), este modelo apresenta alguns problemas. Um deles que
o modelo prev que o cliente consiga definir todas as suas necessidades no incio do processo.
Muitas vezes nem todas as suas necessidades esto to claras neste momento, pois a
percepo do que realmente ser o sistema vai se consolidando a medida que o processo de
desenvolvimento avana.
O quando criado trouxe grandes contribuies engenharia de software, o modelo
mais antigo e serviu de base para todos os outros modelos de processo subsequentes.

2.5.2. Modelo incremental

De acordo Pressman (2011), o modelo incremental tenta combinar elementos dos
fluxos de processos lineares e paralelos, de forma escalonada, de acordo com o tempo.
Um incremento um componente de software compilado, no qual vrias fases do
sistema podem ser desenvolvidas em paralelo e integradas quando completadas. Assim, o
objetivo do desenvolvimento incremental criar o sistema atravs de integraes.
O modelo na engenharia de software tudo que serve de base para o
desenvolvimento, ou seja, um exemplo a ser seguido na construo de sistemas. Portanto,
os modelos apresentam de certa forma fornecer um roteiro eficaz para equipes durante a
construo do software, facilitando desta maneira o processo de levantamento de requisitos,
pois, apresentam um mtodo adequado para elaborao das funes, restries que o sistema
possa ter.

24

Figura 3 - Modelo incremental

Fonte: Imagem adaptada do livro de Engenharia de Software Pressman (2011)

Como pode ser visto na Figura 3, as fases de comunicao e modelagem tambm

esto explcitas. Porm, requerem menor esforo do que no Modelo em cascata, visto que so
feitas para pequenos incrementos do software (que representam poucos requisitos) e no para
todos os requisitos do sistema de uma s vez.
No modelo Incremental, o cliente no precisa decidir sobre todos os requisitos no
incio do processo, ele pode deixar os requisitos mais confusos para os incrementos
posteriores.
Pressman (2011) exemplifica a aplicao do Modelo Incremental na construo de
uma aplicao para processamento de texto. Neste caso, os incrementos poderiam ser
construdos e liberados na seguinte ordem: liberar funes bsicas de gerenciamento de
arquivos como: edio, produo de documentos no primeiro incremento; apresentar recursos
mais sofisticados de edio e produo de documentos no segundo; implementar reviso
ortogrfica e gramatical no terceiro; e no ltimo documento com recursos avanados de
formatao.
O modelo incremental o mais indicado para o desenvolvimento de aplicaes web,
pois, possvel coletar os requisitos de forma rpida gerando incrementos que sero
melhorados a cada reunio com o cliente.
Independente do modelo de processo a ser utilizado, o objetivo do levantamento e
anlise de requisitos sempre entender de forma clara e objetiva as reais necessidades do
cliente.

25

3. Engenharia de requisitos
3.1. Objetivo
Segundo Sommerville (2007), a Engenharia de Requisitos tem como objetivo manter
um documento de requisitos de sistema.

Este tipo de processo baseia-se em quatro

subprocessos de alto nvel os quais so: avaliar se o sistema de alguma forma til para
empresa, obteno de requisitos, converso dos requisitos em uma forma padro e verificar se
os requisitos realmente definem o sistema proposto ao cliente.

3.2. Dificuldades
Durante o levantamento de requisitos so vrias as dificuldades encontradas dentre as
quais possvel citar: o entendimento do problema, ou seja, a comunicao entre as pessoas
envolvidas na descrio do sistema, as mudanas constantes de requisitos e a complexidade
dos sistemas atuais, principalmente na rea de desenvolvimento para web.
A Figura 4 apresenta um grfico que demonstra os principais problemas enfrentados
no desenvolvimento de sistemas.
Figura 4 - Problemas enfrentados na construo de sistemas

Fonte: Gesto das comunicaes em projetos de tecnologia da informao Quartaroli et. al. (2010).

26

Conforme demonstra a Figura 4, dentre os problemas relacionados ao tema deste

trabalho destacam-se: mudanas de requisitos, dificuldade de comunicao e problemas na
definio do escopo.
A Figura 5 demonstra como os erros de comunicao podem acontecer durante o
processo de levantamento de requisitos e afetar negativamente a aceitao do produto por
parte do cliente.

Figura 5 - Erro de comunicao durante o processo de desenvolvimento de software

Fonte: http://www.slideshare.net/Ridlo/analise-de-requisitos-software

Analisando a Figura 5 possvel verificar que o cliente queria era muito simples de
ser implementado, mas existiram vrias falhas de comunicao durante o processo de
levantamento e anlise de requisitos, gerando uma distoro entre as necessidades do cliente e
o produto entregue. Uma alternativa para minimizar este problema a utilizao de
modelagem e o desenvolvimento de um prottipo para melhor compreenso do usurio das
funcionalidades que o sistema venha ter.

27

3.2.1. Entendimento
Segundo Quartaroli et. al. (2010), um ponto importante que deve ser considerado no
desenvolvimento de projetos que envolvem tecnologia da informao o fato de que estes
apresentam profissionais de reas diferentes, portanto, pode ocorrer grande frequncia de
falhas na comunicao, pois, a linguagem tcnica utilizada pode no ser entendida por uma
das partes envolvidas. Assim, as empresas esto percebendo que a comunicao interna
essencial para que se consiga obter maior motivao, produtividade, as quais so
importantssimas para a evoluo da empresa dentro do mercado.
Para Pressman (2011), os usurios no esto completamente cientes do que
necessrio que o sistema execute, pois, no tem um entendimento adequado de suas
capacidades e limitaes no ambiente computacional, no entendem o domnio do problema,
tendo, portanto, dificuldades em transmitir aos engenheiros de softwares as suas reais
necessidades dentro da organizao.
Entender o sistema que o cliente esta propondo extremamente difcil, pois, muitas
vezes, nem mesmo ele sabe o que realmente esta querendo.

3.2.2. Volatilidade
De acordo com Pressman (2011), os requisitos mudam constantemente ocasionando
grandes dificuldades em estabelec-los.
Segundo Santos (2004), a mudana de requisitos que podem ocorrer durante o ciclo
produtivo, deve ser gerenciados. O gerenciamento de mudanas de requisitos visa montar um
conjunto de tarefas que sero executadas para que se possa definir, validar, e manter o
documento de requisitos coerente com o sistema.
De acordo com Espindola et. al. s. d., a mudana de requisitos pode ser afetada pela
falta de uma documentao condizente com o sistema a ser desenvolvido, portanto, torna-se
invivel gerenciar mudanas em algo que se apresenta de certa forma desconhecida. Assim,
podem surgir outras dificuldades no gerenciamento de mudanas dos requisitos, como:
Anlise do problema: em certos casos torna-se quase impossvel verificar os
requisitos originais do sistema, pois, podem no estar disponveis para analise;
Anlise e oramento: para que se consiga fazer uma analise satisfatria necessrio
que as informaes estejam coerentes, para que ento possa realizar a mudana

28

requisitada. De tal forma, que o levantamento incoerentes dos requisitos pode acarretar
oramentos incorretos;
Implementao das modificaes no documento de requisitos: sem a
documentao de um determinado sistema no h o que ser modificado de forma que
este ficara restrito a somente descrever o possvel comportamento do sistema.
Para que se consiga estruturar de forma adequada a mudana de requisitos
importante organizar toda e qualquer mudana que seja necessria ao longo do ciclo de vida
do projeto.

3.2.3. Escopo
Segundo Santos (2009), o escopo do sistema a ser definido pelo analista, deve ser
refinado posteriormente, obtendo um maior detalhamento do software a ser construdo. Ento,
o cliente tenta definir as funes e o desempenho desejado do sistema, mas com detalhes que
no so concretos, apresentando grande dificuldade de entendimento do mesmo.
De acordo com Siqueira (2007), a definio de escopo esta relacionada s fronteiras
entre determinadas tarefas, ou seja, onde comea e termina o trabalho. Assim, o
gerenciamento de escopo tem como objetivo incluir todos os processos necessrios para
garantir que o projeto seja terminado com sucesso. Este visa ter o controle do que pode ser
includo no projeto ou no.
Para Pressman (2011), os requisitos definidos de forma precria ou os
cliente/usurios especificam os detalhes tcnicos de forma equivocada, os quais podem
confundir em vez de esclarecer os objetivos.
A anlise de requisitos pode apresentar elevado grau de complexidade, pois a
comunicao entre futuros usurio do sistema e analista torna-se complexa, sendo possvel a
apresentao de informaes falsas e dupla interpretao do que foi dito.

3.3. Atividades
3.3.1. Viabilidade
Segundo Sommerville (2007), todos os sistemas que sero desenvolvidos devem
passar por um estudo de viabilidade, processo no qual consiste em delimitar um conjunto de
requisitos de negcio, uma descrio do sistema e como o sistema pretende atender os seus

29

processos. Estes resultados devem ser descritos em um relatrio que ser analisado por grupo
de analista que verificaro se possvel prosseguir para as fases subsequentes ou no.
De acordo com Sommerville (2007), os objetivos apresentados no estudo de
viabilidade apresentam ou no valor significativo para a empresa. Apesar de este fato ser
bvio, muitas organizaes desenvolvem sistemas que no contribuem para os objetivos do
seu cliente, pois estes falham em definir os requisitos de negcios para o sistema, deve-se
tambm levar em considerao que outros fatores tais como polticos ou organizacionais
tambm podem influenciar.
Segundo Sommerville (2007), neste tipo de estudo, necessrio consultar fontes de
informaes como gerentes de departamentos onde o sistema ser utilizado, engenheiros de
software familiarizados com este tipo de sistema, especialistas em tecnologia e usurios finais
do sistema.
Segundo Zanlorenci et. al. s. d., o estudo de viabilidade apresenta como objetivo
descrever os requisitos a partir de determinada situao do problema, ou seja, do ponto de
vista dos stakeholders. Podendo ento, proceder com as funcionalidades e aplicaes dos
requisitos de acordo com a implementao.
O estudo de viabilidade tem como objetivo apresentar uma viso geral do sistema a
ser desenvolvido pela equipe tcnica.

3.3.2. Levantamento de requisitos

Segundo Sommerville (2007), o levantamento de requisitos o estagio no qual os
engenheiros de software trabalham com os clientes e usurios finais do sistema, com objetivo
de aprender sobre o domnio, servios, desempenho e restries de hardware.
Assim, o levantamento de requisitos pode envolver vrias pessoas dentro da empresa.
De forma que, utiliza-se o termo Stakeholders para definir qualquer pessoa ou grupo afetado
pelo sistema, direta ou indiretamente. Dentro deste grupo de Stakeholders podem ser
definidos: usurios que utilizam o sistema ou engenheiros que esto trabalhando no sistema
ou mantendo o mesmo.
Para Sommerville (2007), as atividades de processo de levantamento de requisitos
so as seguintes:
Obteno de requisitos: processo no qual os stakeholders devem coletar os
requisitos do sistema;

30

Classificao e organizao dos requisitos: atividade envolvendo a coleta de

requisitos no estruturados;
Priorizao e negociao de requisitos: quando vrios stakeholders participam do
processo, pois, os requisitos apresentam muitos conflitos;
Documentao de requisitos: os requisitos coletados so documentados e colocados
no modelo espiral.
Conforme Sommerville (2007), os stakeholders apresentam vises diferentes sobre a
importncia e prioridade de requisitos, havendo assim alguns conflitos. Durante todo o
processo de levantamento de requisitos faz-se necessrio negociar frequentemente com os
stakeholders de modo que os objetivos almejados possam ser alcanados. Sendo difcil
satisfazer todos os stakeholders, se algum deles perceber que suas vises no foram
consideradas pode at mesmo tentar interromper o projeto.
Para Pressman (2011), o levantamento de requisitos tenta combinar diversos
elementos para solucionar um determinado problema elaborando, negociando e especificando
os requisitos de forma estruturada.
O levantamento de requisitos deve ser feito de forma clara, pois, a base para a
construo de sistemas, e sucessivamente alcanar produtos com qualidade. Portanto,
apresenta processos que devem reunir informaes do sistema proposto ou do sistema que j
existe para que, ento, se possa conseguir os requisitos de usurio e de sistema. Para isto,
necessrio criar uma documentao de todos os requisitos obtidos fazendo comparaes com
sistemas similares. Esta ocorre de diversas formas tais como entrevistas, observaes,
cenrios e prottipos que sero utilizados para ajudar na especificao dos requisitos.

3.4.

Tcnicas de levantamento de requisitos

Para facilitar o levantamento de requisitos, a engenharia de software props tcnicas

para auxiliar os analistas a se comunicarem com o cliente, desta forma, possvel verificar
realmente as necessidades do cliente, isto , o que realmente deseja que seja implementado
em seu sistema.

3.4.1. Ponto de vista

Segundo Sommerville (2007), as abordagens que ocorrem atravs de ponto de vista

auxiliam a Engenharia de Requisitos a organizar o processo de levantamento de requisitos.

31

Um dos pontos fortes da anlise de ponto de vista o reconhecimento de diversas

perspectivas fornecendo um framework para verificar os possveis conflitos nos requisitos os
quais foram determinados pelos stakeholders. Estes pontos de vistas podem ser classificados
pelos stakeholders e outras fontes de requisitos da seguinte maneira:
Ponto de Vista de Interao: Tendem a representar as pessoas que iro interagir
diretamente com o sistema;
Ponto de Vista Indireto: so os stakeholders que no utilizam o sistema
diretamente, mas seus requisitos o influenciam de alguma forma;
Ponto de Vista de Domnio: Apresentam caractersticas e restries do domnio que
influenciam os requisitos do sistema.
De acordo com Sommerville (2007), para facilitar o processo de levantamento de
requisitos de ponto de vista necessrio identificar os mais especficos:
Fornecedores e receptores;
Sistemas que fazem interface diretamente com o sistema;
Regulamentos e padres;
Fonte requisitos de negcios e no funcionais;
Pontos de vista que refletem os requisitos das pessoas que desenvolveram o sistema;
Ponto de vista de marketing, caractersticas do produto e demonstrao da imagem
externa da organizao.
Conforme Souza (2007), a tcnica de ponto de vista apresenta as diferentes
perspectivas dos stakeholders propondo de tal forma um framework para o levantamento de
requisitos. Assim, possvel descobrir os conflitos dos requisitos propostos pelos
stakeholders.
A anlise de requisitos atravs de ponto de vista pode ser de certa forma interessante,
mas como existem diversos pontos de vistas dentro de uma organizao nem sempre fcil
determinar os seus requisitos.

3.4.2. Entrevista
Segundo Sommerville (2007), as entrevistas podem ser formais ou informais com os
stakeholders, e parte do processo da Engenharia de Requisitos. o momento no qual os
engenheiros tendem a formular perguntas aos stakeholders sobre o sistema que utilizam e o
qual ser desenvolvido. As entrevistas so feitas de duas formas:

32

Entrevistas fechadas, onde os stakeholders respondem a um grupo de perguntas

definidas;
Entrevistas Abertas, no h um roteiro a ser seguido. Os engenheiros tentam
explorar assuntos com os stakeholders desenvolvendo desta forma uma melhor
compreenso das necessidades da empresa.
Para Sommervillle (2007), o objetivo das entrevistas obter um melhor
entendimento dos stakeholders verificando como podem interagir com o sistema e os
problemas que enfrentam com o sistema que utilizam. Portanto, um pouco difcil ter
conhecimento e domnio durante as entrevistas por dois motivos:
Os especialistas utilizam uma terminologia especifica. quase impossvel determinar
os requisitos de domnio sem utilizar este tipo de terminologia;
Para os stakeholders alguns conhecimentos so to familiares que so difceis de
explic-los e, portanto fundamentais ao sistema, mas normalmente no so
mencionados.
De acordo com Carvalho (2009), a entrevista uma conversa direcionada com o
objetivo de extrair os requisitos da empresa, utiliza-se para isto o formato de perguntaresposta, e seus objetivos so:
Obter as opinies do entrevistado, o que ajuda na descoberta dos problemas-chave a
serem tratados;
Conhecer os sentimentos do entrevistado sobre o estado corrente do sistema;
Obter metas organizacionais e pessoais;
Levantar procedimentos informais.
A entrevista quando aplicada de forma equivocada, pode alterar gradativamente a
real funo que cada funcionrio exerce realmente dentro da organizao, dificultando desta
forma a coleta dos reais requisitos do sistema.

3.4.3. Cenrios
Segundo Pressman (2011), os cenrios descrevem como o sistema ser usado,
mostrando as caractersticas e as funes que sero usadas por diferentes tipos de classes de
usurios.
Conforme Sommerville (2007), os cenrios so de extrema importncia, pois, ajudam
a determinar maiores detalhes sobre os requisitos. Assim, os cenrios abrangem uma ou varias
interaes. De forma, que este fornecera diferentes informaes sobre o sistema em diversos

33

nveis de detalhamento. Assim, todo tipo de Cenrio deve apresentar as seguintes

informaes:
Descrio do que usurios esperam do sistema;
Descrio do Fluxo normal e eventos;
Descrio do que pode dar errado e como pode ser tratado;
Informaes sobre atividades que podem ocorrer ao mesmo tempo;
Descrio do estado do sistema no fim do cenrio.
Os cenrios podem ser descritos em forma de textos, diagramas para completar os
textos, imagens de computador, diagramas, etc. Os quais de alguma forma auxiliam na
compreenso das funes, mtodos que o sistema venha a desempenhar.

3.4.4. Etnografia
Segundo Sommerville (2007), geralmente, os sistemas baseados em software no
podem trabalhar isoladamente, pois, deve-se considerar o contexto social e organizacional da
empresa, podendo de tal forma influenciar os seus requisitos. Razo pela qual, muitos
sistemas entregues nunca foram utilizados dentro da empresa.
... etnografia uma tcnica de observao que pode ser usada para compreender os
requisitos sociais e organizacionais da corporao. (SOMMERVILLE, 2007, p. 104)
Conforme Sommerville (2007), as pessoas conseguem compreender muito bem o seu
trabalho, mas no conseguem compreender o relacionamento com os trabalhos de outros da
mesma empresa. De forma que, os fatores sociais e organizacionais s podem ser
compreendidos por um observador imparcial. Desta forma, a etnografia eficaz para
descobrir certos requisitos tais como:
Requisito que mostram realmente como a pessoa trabalha, e no as definies de
como esta deveriam trabalhar;
So requisitos derivados da cooperao e do conhecimento de atividades das outras
pessoas envolvidas.
De acordo com Sommerville (2007), a etnografia pode ser combinada com a
prototipao, de forma que este define em poucos ciclos o refinamento do prottipo. Alm de
que, identifica problemas e questes que podem ser discutidos com etngrafo. Assim, a
etnografia pode revelar aspectos importantes do processo que no podem ser levantados por
outras tcnicas de levantamento de requisitos, mas este tipo de abordagem no o ideal para
obter os requisitos organizacionais ou de domnio.

34

Para Souza (2007), a etnografia uma tcnica que observa os requisitos

organizacionais e sociais da empresa representando os processos reais das pessoas envolvidas
dentro da organizao.
Normalmente, neste caso, o usurio consegue entender muito bem o seu trabalho,
mas no consegue distinguir os dos seus colegas.

3.4.5. Validao
Para Sommerville (2007), a validao de requisitos tem como objetivo definir o que
o usurio espera do sistema. Esta uma fase que se sobrepe a analise, pois um
procedimento utilizado para descobrir falhas com os requisitos. A validao dos requisitos
de extrema importncia, pois, a manuteno destes pode gerar um custo excessivo a empresa
solicitante do servio. Portanto, durante a validao necessrio fazer verificaes nos
documentos de requisitos. importante incluir as seguintes verificaes:
Verificao de validade: normalmente o usurio pode pensar que o sistema ir
desenvolver uma nica funo especifica, mas no o que ocorre, pois, existem
diversos stakeholders dentro da organizao e cada exerce um tipo de trabalho
deferente;
Verificao de consistncia: os requisitos apresentados atravs do documento no
devem apresentar conflitos;
Verificao de completeza: o documento deve apresentar todas as funes exigidas
e as restries desejadas pelos usurios;
Verificao de realismo: os requisitos devem ser verificados, de tal forma que
possam ser implementados dentro da tecnologia desejada no extrapolando o oramento
e o prazo estipulado;
Facilidade de verificao: Diminuio das divergncias entre cliente e fornecedor,
escrevendo os requisitos deforma que sempre possam ser verificados.
Conforme Sommerville (2007), algumas tcnicas podem ser utilizadas para fazer a
validao dos requisitos:
Revises de requisitos: os requisitos devem ser analisados por uma equipe
especializada de revisores;
Prototipao: um modelo executvel do sistema apresentado ao cliente, o qual ser
testado para verificar se realmente atende suas necessidades reais;

35

Gerao de casos de teste: todos os requisitos devem passar por um teste, pois
assim, possvel verificar possveis problemas de requisitos.
De acordo com Spindola et. al. s. d., esta a etapa na qual se examina toda a
especificao do software, para que se possa verificar se os requisitos foram definidos sem
ambiguidades, inconsistncia ou omisses, e que os erros foram detectados e corrigidos.
Processo que determina se os requisitos esto de acordo com o sistema a ser
construdo.

3.5. Gerenciamento de requisitos

De acordo com Sommerville (2007), os requisitos de sistemas esto constante
mudana, tornando quase que impossvel definir totalmente o problema, assim os requisitos
de softwares ficam incompletos, pois durante o processo de desenvolvimento os requisitos
dos stakeholders apresentam constantes mudanas.
Para Sommerville (2007), quando o sistema estiver corretamente instalado na
organizao inevitvel surgir novos requisitos. Portanto, improvvel definir os efeitos que
o novo sistema apresentara sobre os usurrios e clientes da organizao. Com certeza
descobriro novas necessidades e prioridades:
Nos sistemas de grande porte h uma grande comunidade de usurios os quais
apresentam requisitos e prioridades diferentes. A empresa desenvolvedora do sistema
deve ter em mente que o suporte deve ser fornecido a cada setor especifico da empresa.
Quem paga pelo sistema e os usurio normalmente so pessoas diferentes. Os
clientes impem restries organizacionais e de oramento de tal forma que se consiga
obter as metas estimadas.
Pode ser necessrio adicionar um novo hardware, a interface pode ter que interagir
com outros sistemas, s prioridades de negcio podem mudar de acordo com as
necessidades da empresa.
O gerenciamento de requisitos um processo para compreender e controlar as
mudanas de requisitos de sistema. No qual se precisa manter o acompanhamento dos
requisitos dependentes, de modo que seja possvel avaliar o impacto das mudanas de
requisitos (SOMMERVILLE, 2007, p. 107).
O Gerenciamento de Requisitos auxilia os engenheiros de software a controlar o
problema da volatilidade dos requisitos.

36

Conforme Sommerville (2007), necessrio utilizar o gerenciamento de mudanas

de requisitos, pois, pode-se tratar estes de forma consistente, sendo, portanto as mudanas no
documento de requisitos feitas de forma controlada. Existindo trs formas de estgios para o
processo de gerenciamento de mudanas:
Anlise de problema e especificao da mudana: este processo se inicia com um
problema apresentado pelo requisito ou com uma proposta de mudana especifica;
Anlise de mudana e estimativa de custo: a mudana avaliada de acordo com a
rastreabilidade e o conhecimento especfico dos requisitos do sistema;
Implementao da mudana: quando os requisitos so modificados ou
acrescentados necessrio alterar o documento de requisitos, o projeto e sua
implementao.
Segundo Sommerville (2007), quando uma mudana de requisito solicitada,
primeiro muda-se este no sistema para que depois mude o documento de requisito, levando a
defasagem entre o documento de requisitos e a sua implementao.
De acordo com Souza (2007), o levantamento e estruturao dos requisitos devem
ser feitos de acordo com alguns aspectos bsicos que so:
Identificao de requisitos;
Gerenciamento das mudanas dos requisitos;
Polticas de rastreamento dos requisitos;
Suporte das ferramentas case.
As mudanas de requisitos devem ser feitas de maneira estruturada para que no
desestruture o documento de requisitos.

3.6. Modelagem grfica

A modelagem facilita o entendimento entre os envolvidos ao processo de
levantamento de requisitos. As formas de modelagem mais utilizadas so a prototipao e a
modelagem grfica.
A prototipao permite que o cliente tenha uma viso mais realstica do produto a ser
desenvolvido. Os modelos grficos em geral so de extrema importncia para o levantamento
de requisitos, pois, tentam eliminar a ambiguidade imposta pela linguagem natural.
A modelagem de software serve para construir modelos que expliquem as
caractersticas ou o comportamento do software. Os modelos so usados para identificar as

37

funcionalidades e caractersticas que o software possa apresentar ao decorrer de sua

construo.
Os modelos grficos simbolizam os artefatos dos possveis componentes do sistema,
de tal modo que, possa verificar os seus inter-relacionamentos. Para isto, pode-se utilizar os
diagramas UML que uma abordagem orientada ou fluxogramas que apresentam uma
abordagem no orientada a objeto.
A notao grfica utiliza ferramentas cases que apresentam como objetivo facilitar a
compreenso dos clientes sobre o futuro sistema a ser desenvolvido para a organizao.

4. Aplicaes para Web

As aplicaes web so sistemas de informtica desenvolvidos para serem utilizados

atravs de um navegador na internet ou por redes privadas. Assim, possvel dizer que estas
aplicaes so um conjunto de programas executados a partir de um servidor HTTP. O
surgimento destas aplicaes esta ligada aos seguintes fatores: facilidade de manuteno e
atualizao do cdigo fonte.
A internet nos dias atuais se tornou um meio de comunicao altamente requisitado
pelas empresas, pois a facilidade de divulgao de seus produtos e servios muito ampla,
alcanando diversas regies, expandindo desta forma o seu empreendimento. Assim, surge a
necessidade de criar novos sistemas de informaes, os quais devem permitir que
organizaes, clientes, fornecedores entre outros atores do mundo organizacional estabeleam
conexes seguras, divulgando seus negcios pela rede mundial de computadores.
Atualmente, a maioria dos processos e operaes que so realizadas por uma
empresa, seja ela comercial, industrial ou de servios em geral, podem ser apoiadas por
aplicaes web, as quais podem ser acessadas por diversos tipos de equipamentos, dentre eles
pode-se citar: celulares, computadores, etc.
Portanto, devido a grande facilidade de uso, as aplicaes web tm sido utilizadas
para alavancar os negcios da empresa, pois, oferecem produtos e servios de forma mais
rpida, barata e segura, viabilizando uma maior interao entre cliente e empresa. Para tanto,
durante o desenvolvimento destas aplicaes, importante o foco na confiabilidade e tambm
na facilidade de suas interfaces.
De acordo com Dzendzik (2004), a engenharia web no idntica engenharia de
software. Assim, os mtodos, as ferramentas e as tcnicas, geralmente, da engenharia de
software convencional no so adequados ao projeto de web sites, pois, estes produtos

38

apresentam requisitos prprios como, por exemplo: gerenciar um volume imenso de

informaes, combinar a navegao feita pelo leitor atravs das prprias informaes de
multimdia, atualizaes constantes, entre outros fatores. Assim, possvel identificar
algumas diferenas existentes entre engenharia de software convencional e engenharia web,
que so:
Diferentes propsitos: as aplicaes convencionais oferecem servios e solues
enquanto web sites oferecem contedos que so informaes, representando desta
forma, um meio de comunicao;
Apresentao e funcionalidade: aplicaes convencionais apresentam um foco
maior na funcionalidade e aplicabilidade, enquanto web sites apresentam um foco maior
na apresentao, aparncia, navegao entre outras qualidades estticas;
Tradio e experincia: a maioria dos desenvolvedores apresentam maior
experincia no desenvolvimento de software convencional, possibilitando planejamento
e gerncia mais realsticos em relao a processos de web sites;
Pblico alvo e audincia (classe de usurios): aplicao convencional tem classe de
usurios mais bem definida. J os web sites tm um pblico alvo diversificado com foco
maior na navegao e qualidades estticas;
Maturidade da tecnologia: aplicaes convencionais apresentam tecnologias mais
estveis e excelentes ferramentas disponveis, enquanto a engenharia web tem
tecnologias que esto em constante evoluo, existe vrias ferramentas para
implementao, mas possuem poucas para anlise, projeto, documentao e outras
atividades da engenharia de software.

Para Dzendzik (2004), os requisitos que servem de base para construo de um web site so:
Requisitos de contedo: so as informaes que devem ser estruturada dentro da
paginas;
Requisitos funcionais: so todas as ferramentas utilizadas para a construo do site;
Requisitos de navegao: fornece uma viso geral da interao do usurio com o
site;
Requisitos de projeto e de implementao: est relacionado ao custo, a
qualificao do pessoal envolvido e aos prazos de entrega.

39

De acordo com Filho (2011, p.23), sistemas e aplicaes baseados na web,

englobam desde uma simples pgina web com recursos de interao com o usurio, at um
abrangente site fornecedor de servios completos para toda uma comunidade especifica.
Segundo Powell apud Pressman (2011), as aplicaes e sistemas baseados na web
apresentam um mistura de publicao impressa, desenvolvimento de software, marketing e
computao, de comunicaes internas e relaes externas de arte e tecnologia. Portanto, a
maioria das aplicaes web apresenta as seguintes caractersticas:
Uso intensivo das redes: uma aplicao web reside em uma rede e deve atender as
necessidades de uma comunidade de clientes;
Simultaneidade: nestes tipos de aplicaes um numero enorme de usurios devem
acessar esta aplicao web ao mesmo tempo;
Carga no previsvel: o numero de acesso de usurios a aplicao pode variar de um
dia para o outro;
Desempenho: se o usurio de uma aplicao ter que esperar muito para acessa-la,
talvez possa procurar outra opo;
Disponibilidade: este tipo de aplicao deve estar disponvel 24 horas por dia, 7 dias
por semana, 365 dias por ano;
Orientada a dados: a funo principal da maioria destas aplicaes web usar
hipermdia para apresentar texto, grficos, udio, e vdeo ao usurio final;
Sensibilidade no contedo: a qualidade e a natureza esttica do contedo so fatores
de extrema importncia nas aplicaes web;
Evoluo continua: as informaes contidas nas aplicaes web esto em constante
evoluo as quais devem ser planejadas e seguir uma ordem cronolgica;

Imediatismo: Embora imediatismo a imperativa necessidade de colocar

rapidamente um software no mercado- seja uma caracterstica de diversos campos de

aplicao, as webapps normalmente apresentam um tempo de colocao no mercado
que pode consistir em poucos dias ou semanas; (Pressman, 2011, p.38)

Segurana: pelo fato de estarem disponveis na internet, torna-se impossvel limitar

o numero de usurios finais que podem acessar estas aplicaes. Desta forma,
necessrio implementar fortes estruturas de segurana para se transmitir dados via rede
de internet e proteger o contedo da aplicao;
Esttica: parte que consiste na aparncia e na impresso que desperta no usurio.

40

Estes atributos so apresentados na maioria das aplicaes web. Portanto, para poder
desenvolv-las necessrio a utilizao de algumas ferramentas que auxiliam no processo de
desenvolvimento de software.
As aplicaes web apresentam um grande volume de informaes e outros dados,
desta forma, estas caractersticas so apresentadas na maioria delas. Sendo, portanto,
primordiais na sua construo.
O desenvolvimento de aplicaes web apresentam caractersticas distintas das
aplicaes convencionais, e, portanto, as tcnicas de anlise de requisitos para este tipo de
aplicao precisam ser escolhidas considerando tais diferenas.

5. Modelagem de Requisitos para web

5.1. Prototipao
Segundo Pfleeger (2004), prototipao um esboo simplificado do produto a ser
atingido, em outras palavras, um rascunho do que o sistema. Muitas vezes o cliente no est
exatamente certo do que deseja e exige do analista coisas que s vezes no so realmente
necessrias.

Para facilitar o entendimento das necessidades do cliente e mostrar este

entendimento a ele, a prototipao pode ser utilizada. Assim, possvel fazer uma
investigao e ter uma noo melhorada do que se realmente o cliente deseja.
Segundo Pearson (2010), em um estudo realizado com 39 projetos envolvendo
prototipao, foi possvel verificar os seguintes benefcios:
Usabilidade aprimorada do sistema;
Adequao maior do sistema s necessidades do usurio;
Qualidade do projeto aprimorada;
Facilidade de manuteno aprimorada;
Esforo de desenvolvimento reduzido.
Este estudo apresentou como objetivo melhorar os requisitos do usurio, de forma a
adequ-los as necessidades do sistema. A prototipao pode at dar mais gastos no incio do
desenvolvimento do software, mas tem-se uma reduo desses gastos em fases mais avanada
no processo de desenvolvimento.
Existem 2 tipos de prottipos:
Evolucionrio: serve para levantar requisito e vai sendo melhorado at se tornar o
produto final;

41

Descartvel: s serve para levantar requisitos, ele explorativo e no tem pretenso

de uso, serve para se ter uma viso de possveis solues ou quando so desejveis.

5.2. Processo de desenvolvimento de um prottipo

A modelagem grfica e o uso de prottipos tentam de alguma forma eliminar a
ambiguidade demonstrando o real funcionamento do sistema ao cliente, que ter exatamente
uma noo das funes que este ir executar.
No presente trabalho, para ilustrar o uso da prototipao no levantamento de
requisitos, foi suposto o seguinte escopo do sistema:
A Pizzaria Royalit uma aplicao atravs da qual possvel fazer o seu pedido de
pizza atravs do e-mail. Alm disso, voc pode verificar todas as promoes fornecidas pelo
estabelecimento na pgina inicial (Home) e caso queira nos seguir nas redes sociais s
acessar os respectivos links.
O cardpio da pizzaria Royalit fornece uma imensa variedade de sabores e tamanhos
das pizzas. E ainda, se o cliente desejar possvel comprar refrigerantes, sobremesas ou at
mesmo aperitivos tambm atravs do e-mail. Estes so os principais servios oferecidos pela
Pizzaria Royalit.
As figuras 6, 7 e 8 demonstram os prottipos criados para o site da Pizzaria Royalit:
Figura 6 Home

A Figura 6 mostra a pgina inicial (Home) atravs da qual possvel acessar os

demais links do site da Pizzaria Royalit.

42

Figura 7 - Cardpio

A Figura 7 mostra o Cardpio com as pizzas que o cliente pode pedir atravs do e-mail.

43

Figura 8 - Pedido de pizza via e-mail

De acordo com a Figura 8 para fazer o seu pedido atravs do e-mail necessrio
preencher todos os campos obrigatrios.

44

Existem vrias ferramentas que auxiliam na construo de prottipos. No exemplo da

Pizzaria Royalit foi utilizado as seguintes ferramentas:
Joomla: um sistema gestor de contedo para web sites;
Php: linguagem de programao utilizada no desenvolvimento de aplicaes que so
acessadas atravs do browser;
Mysql: banco de dados utilizados para guardar informaes do web site;
Wamp: apresenta um conjunto de ferramentas. Estas ferramentas so as seguintes:
apache ( um servidor local atravs do qual posso rodar as aplicaes atravs do
browser), o Php e o Mysql.
Portanto, o prottipo uma das ferramentas mais poderosas na anlise de requisitos,
pois, atravs dele possvel esboar uma tela para o cliente em poucos minutos. Desta forma,
o seu objetivo aumentar a segurana quanto validao dos requisitos do sistema.
5.3. UML (Unified Modeling Languagem)
Alm da prototipao, a modelagem grfica bastante importante no levantamento e
anlise de requisitos para aplicaes web.
Segundo Guedes (2009) UML uma linguagem de modelagem padro para o
desenvolvimento de aplicao orientada a objetos, tendo como caractersticas fundamentais a
melhoria da compreenso, visualizao, especificao e construo de software.
A UML no uma linguagem de programao e sim uma linguagem de modelagem,
que auxilia engenheiros de software a definir os requisitos, a estrutura lgica, a testar, avaliar,
arquitetar, e alem disso ainda identifica todos os possveis comportamentos do sistema. A
linguagem de modelagem totalmente independente do processo de software, ou seja, pode
ser usada por vrios processos de desenvolvimento diferentes.
A premissa de UML que uma imagem vale por mil palavras. Porm, Melo (2004,
pag. 28) afirma que a imagem deve ser simples sem perder a expressividade. Portanto,
UML uma linguagem para especificao, visualizao, construo e documentao de
artefatos de sistemas de software.
Segundo Matos (2003, pag. 17) a UML no prescreve nenhum roteiro, apenas
permite que a criatividade e o bom senso permeiem um desenvolvimento com qualidade.
A UML tem como objetivo criar diagramas para melhor entendimento do cliente
sobre o sistema que est sendo desenvolvido para a empresa.

45

5.4. A importncia da UML

Segundo Booch, and Rumbaugh, and Jacobson (2005), os modelos fornecem uma
cpia do que pedido pelo usurio, tendo-se assim uma noo de como ficar o projeto do
sistema. Uma das principais caractersticas do UML que os modelos ajudam a ter uma
previa visualizao de como o sistema ir ficar. Deste modo, necessrio fazer uma
documentao condizente para que no haja futuras reclamaes dos clientes e de outras
pessoas envolvidas no desenvolvimento do sistema.
A modelagem pode ser utilizada no desenvolvimento de sistema mais simples at o
mais incrementado que seja, pois ela trs muitos benefcios, lembrando que quanto maior for
o sistema, maior a necessidade da modelagem, isto , Construmos modelos de sistema
complexos porque no possvel compreend-los em sua totalidade.
Frase dita por cliente annimo Sei que voc acredita que entendeu o que acha que
eu disse, mas no estou certo de que percebe que aquilo que ouviu no o que eu pretendia
dizer, atravs desta frase possvel evidenciar a importncia da modelagem grfica.
(Pressman, 2006, pg. 116).
A UML baseada em um conjunto de diagramas, sendo que cada diagrama enfoca
um aspecto distinto de problemas. Assim podemos citar algumas ferramentas atravs das
quais possvel gerar estes diagramas como exemplo pode-se citar: o Astah.

5.5. Diagramas de Caso de Uso

O Diagrama de Caso de Uso o diagrama mais completo e informal da UML.
utilizado nas fases de levantamento e anlise de requisitos do sistema. Porm, no se pode
descartar a possibilidade de ser usado tambm durante o todo processo de modelagem e como
base para todos os outros diagramas que eventualmente possam criados.
Um diagrama de caso de uso mostra um conjunto de casos de uso e atores (um tipo
especial de classe) e seus relacionamentos. Aplique esses diagramas pra ilustrar a
viso esttica do caso de uso de um sistema. Os diagramas de caso de uso so
importantes principalmente para a organizao e modelagem dos comportamentos
de um sistema (Booch et. al., 2005, p. 27).

46

O Diagrama de Caso de Uso apresenta uma linguagem para melhor compreenso e

d uma idia geral do sistema proposto, uma tcnica baseada em cenrios que constituem o
levantamento de requisitos. Desta forma, pode-se demonstrar ao usurio do sistema as
funcionalidades propostas.
Segundo Sommerville (2007) os casos de uso podem ser documentados atravs de
textos, links e outros diagramas de UML, que determinam que o cenrio seja mais detalhado.
Por exemplo, os Diagramas de Sequncia so utilizados para acrescentar detalhes aos casos de
uso, mostrando os agentes envolvidos, os objetos que estes interagem e suas operaes
associadas aos objetos.
Segundo Pressman (2011), o caso de uso descreve todo o comportamento do sistema
sobre diversas condies e medida que o sistema responde a uma determinada solicitao de
seu usurio.
Para mostrar a modelagem utilizando diagramas UML, foi utilizado o escopo da
Pizzaria Royalit, descrito na seo 5.2 do presente trabalho.
Como ilustrao, a Figura 9 e Figura 10 apresentam os Diagramas de Caso de Uso
criados para a Pizzaria Royalit.

Figura 9 - diagrama de caso de uso cliente

47

Como apresentado na Figura 10, o Cliente um ator, isto , uma entidade externa ou
usurio do sistema, que interage com o sistema atravs de casos de uso que so representados
como elipses.
Figura 10 - Caso de uso usurio do sistema

A Figura 10 mostra as interaes de outro ator, neste caso o Funcionrio da pizzaria,

com o sistema.
Estes modelos foram criados utilizando a ferramenta Astah.
A UML um padro que mostra realidade da modelagem orientada a objetos, e por
isto tem sido amplamente utilizado no levantamento de requisitos.

48

5.6. Astah

O Astah uma ferramenta CASE (Compuyer-Aided Software Engineering) a qual

visa auxiliar a criao de diagramas de UML, e que tambm pode ser utilizada para
construo de outros diagramas, tais como: Diagrama de Entidade- Relacionamento (DER),
Diagrama de fluxo de dados (DFD), e, alm disso, define funcionalidades teis a fase de
especificao e projeto do sistema.
A fase de projeto desenvolvimento de sistema parte onde se deve descrever o
software, ou seja, seu funcionamento. Portanto, necessrio definir claramente este modelo
de desenvolvimento.
Desta forma, pode-se dizer que o Astah utiliza-se da UML para padronizar a criao
dos diagramas permitindo, assim, uma melhor visualizao da comunicao entre os objetos.
Conforme dito, a UML possibilita esquematizar o sistema para verificar se este esta de acordo
com requisitos que foram levantados junto ao cliente.
O Astah uma ferramenta que possui verses free que pode ser baixada no seguinte
site: astah.net.

5.7. Diagrama de Contedo

Na realidade o Diagrama de Contedo no um diagrama especfico de UML, mas
uma recomendao de Pressman (2011) para representar a hierarquia de contedo de
aplicaes web. Assim, o Diagrama de Contedo tem como objetivo demonstrar o que deve
ser inserido em cada pgina da aplicao web.
Segundo Pressman (2011), o Diagrama de Contedo tem como objetivo mostrar uma
viso geral do contedo que deve ser inserido na aplicao web. Este contedo pode ser
desenvolvido antes ou depois da implementao da aplicao. Portanto, ela incorporada
atravs da referncia navegacional dentro de sua estrutura geral.
A Figura 11 mostra o Diagrama de Contedo para o site da Pizzaria Royalit,
representado atravs de uma rvore de dados.

49

Figura 11 - Diagrama de contedo

Assim, a Figura 11 mostra um mapa da navegabilidade do site da Pizzaria Royalit.

H vrios outros diagramas UML que podem ser usados em aplicaes web, tais como
o Diagrama de Classes, Diagrama de Estados, entre outros. A escolha dos diagramas a serem
utilizados depende da necessidade do desenvolvedor, que deve considerar a complexidade da
aplicao.

6. Concluso
Uma das atividades mais complicadas durante o desenvolvimento do software
entender o que o cliente necessita e realmente precisa demonstrar isso a ele, para assim chegar
a um consenso sobre as caractersticas e funcionalidades que a aplicao deve ter. Logo,
promover uma comunicao eficiente uma das formas de diminuir este problema. Problemas
de comunicao afetam diretamente a qualidade e aceitao do produto final.
Com a crescente procura dos clientes por aplicaes web, importante o foco na
qualidade destas aplicaes, que tem algumas caractersticas distintas das aplicaes
convencionais.
A Engenharia de Software prope diversas tcnicas que podem ser utilizadas para
um melhor relacionamento entre o analista e o cliente, que podem ser utilizadas no
desenvolvimento para web.

Entre essas tcnicas tem-se, por exemplo, entrevistas,

questionrios, exames de documentos, desenvolvimento de prottipos e modelos grficos. O

50

presente trabalho destacou especialmente a importncia da prototipao e da modelagem

grfica.
No desenvolvimento de aplicaes web, onde a atratividade e a usabilidade da
aplicao so caractersticas fundamentais, o uso de prottipos uma alternativa bastante
interessante. Assim, o cliente vendo o resultado final, ele tem a noo de como vai ficar a sua
aplicao web, ajudando assim o analista de sistema fazer o seu trabalho de maneira eficiente
e objetiva.
A modelagem grfica interessante, pois, apresenta como finalidade facilitar o
entendimento das funes, de forma que o cliente venha a compreender melhor o
funcionamento do sistema.
Os diagramas UML no devem ser usados para burocratizar o processo, mas como
aliados na busca da qualidade do produto final. O desenvolvedor deve escolher os diagramas
que mais atendam as suas necessidades.
Portanto, durante o levantamento e anlise de requisitos muito importante, escutar,
preparar-se antes de se comunicar, usar uma comunicao fcil, fazer anotaes, buscar
colaboraes, manter focado, se algo no est com clareza desenhe, bem mais fcil para o
entendimento do que se deseja.

O esforo gasto nesta fase, influenciar diretamente na

qualidade e aceitao do produto pelo cliente.

REFERNCIA BIBLIOGRFICA
ALVES, Pablo Rodrigo Campelo. Engenharia de requisitos para aplicaes web. 2009.
Monografia (Especializao em PS-GRADUAO EM CINCIAS DA COMPUTAO)
UNIFERSIDADE FEDERAL DE PERNAMBUCO. Recife. Disponvel em
<http://www.cin.ufpe.br/~in1020/arquivos/monografias/2009_1/pablo.pdf>. Acesso em: 20
junho 2012.
AMAZNIA,
Joomla.
O
que

Joomla?
Disponvel
<http://www.joomlamazonia.com.br/Joomla-Tutorial-e-Artigos/o-que-e-joomla.html>.
Acesso em: 12 junho 2012.

em:

CARVALHO, Pedro F.. Tcnicas de Levantamentos de Requisitos. Disponvel em:

<http://www.pedrofcarvalho.com.br/PDF/ENGENHARIA_ANALICSE_LEVANTAMENTO
_REQUISITOS_2.pdf>. Acesso em: 10 out. 2012.
CONFORTO, Dbora e SANTAROSA, Lucila M. C. Acessibilidade Web; Internet para
Todos. Revsita de Informtica na Educao: Teoria, Prtica PGIE/UFRGS. V.5 N 2p.87102.
Nov/2002.
Disponvel
em:
<http://edu3051.pbworks.com/f/ACESSIBILIDADE_WEB_revista_PGIE.pdf>. Acesso em:
09 out. 2012.
DZENDZIK, I.T. Processo de desenvolvimento de web sites com recursos da UML / I. T.
Dzendzik So Jose dos campos: INPE, 2004. 182p. (INPE-12450-TDI/997). Disponvel
em: <http://mtcm16.sid.inpe.br/col/sid.inpe.br/jeferson/2004/12.10.09.14/doc/pulicacao.pdf>.
Acesso em 10 out. 2012.
ESPINDOLA, Rodrigo Santos de; MAJDENBAUM, Azriel; AUDY, Jorge Luiz Nicolas.
Uma anlise crtica dos desafios para engenharia de requisitos em manuteno de software.
Uma anlise crticas de desafios para engenharia de requisitos em manuteno de software.
Faculdade de Informtica Pontifcia Universidade Catlica do Rio Grande do Sul. Disponvel
em: <http://wer.inf.pucrio.br/WER papers/artigos/artigos_WER04/Rodrigo_Espindola.pdf>.
Acesso em maio 2012.
GUEDES, Gilleanes T.A. UML 2: Uma abordagem prtica/Gilleanes T.A. Guedes So
Paulo:Novatec Editora, 2009.
JACYNTHO, Mark Douglas de Azevedo. Processos para Desenvolvimento de Aplicaes
Web. 23/09 Rio de Janeiro: Issn 0103-9741, 2012. Disponvel em: <ftp://ftp.inf.pucrio.br/pub/docs/techreports/09_23_jacyntho.pdf>. Acesso em: 10 out. 2012.

JEVEAUX, Paulo Csar M..Escopo, o inimigo do sucesso. Escopo, o inimigo do sucesso.

Imasters, 12 dez. 2011. Disponvel em: <http:/imaters.com.br/artigo/16224/gerencia-deti/escopo-o-inimigo-do-sucesso>. Acesso em: 12 abril 2012.
MARCONDES, Francisco Supino; MONTINI, Denis vila, VEGA, talo Santiago: DIAS,
Luiz Vieira. Elicitao da dificuldade de entendimento com base na teoria de Bergson. So
Paulo. Disponvel em: <http://www.centropaulasouza.sp.gov.br/pos-graduao/workshop-de-

graduao-e-pesquisa/anais/2009/trabalhos/gesto-e-desenvolvimento-de-tecnoligia-dainformaoaplicadas/comunicaes/MARCONDES,%20Francisco%20Supino.pdf>. Acesso
em: 11 agosto 2012.
MEDIA,
Dev.
Projeto
de
Software
com
Astah*.
Disponvel
em:
<http://www.devmedia.com.br/projeto-de-software-com-astah*-engenharia-de-software30/18442>. Acesso em: 12 junho 2012.
MELLO, Leandro Cicero da Silva, Levantamento de Requisitos. Faculdade Integradas Matogrossenses
De
Cincias
Sociais
e
Humanas.
Disponveis
em:
<http:
www.klebermota.eti.br/wp-content_leandro_cicero_levantamento_de_requisitos.pdf>.Acesso
em: 12 abril 2012.
PFLEGER, Shari Lawrence. Engenharia de Software: Teoria e Prtica. Segunda So Paulo:
Prentice Hall, 2004.
PRESSMAN, Roger. Engenharia de Software. 6 Edio. So Paulo: McGrawHill, 2006.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. Stima Porto
Alegre: Amgh 2011.
QUARTAROLI, Claudio; MARTINS, Leila Costa Silva. Gesto das comunicaes em
Projeto de Tecnologia da Informao: PM World Today, jan. 2012. Disponvel em: <http:
pmies.org.br/clickadmin/mdias/data/artigo-PMI_RIO.pdf>. Acesso em: 21 junho 2012.
RODRIGO, Mapeamento de Processos & levantamento de Requisitos. Faculdades Integradas
Mato-grossenses
De
Cincias
Sociais
e
Humanas.
Disponvel
em:
<http://www.klebermota.eti.br/wpcontent/aluno_leandro_cicero_levantamento_de_requisitos.Pdf>. Acesso em: 12 de abril
2012.
SANTOS, Jos Henrique Amaral Dos. Gerncia de mudanas de requisitos: uma proposta de
aplicao a um estudo de caso. 2004. Monografia (especializao em Ps Graduao em
Computao) Universidade federal do rio Grande do Sul. Porto alegre. Disponvel em:
<http://www.lume.ufrgs.br/bitstream/handle/10183/4118/000452937.pdf?sequence=1>.
Acesso em: 23 agosto 2012.
SANTOS, Rildo F. Anlise de Requisitos de Software. Disponvel em:
<http://www.slideshare.net/Ridlo/analise-de-requisitos-software>. Acesso em: 10 abril 2012.
SIQUEIRA, Rodrigo George Piubello. Planejamento de escopo de projetos: o caso de uma
consultoria. 2007. Monografia (Graduao em ENGENHARIA PRODUO)
UNIVERSIDADE FEDERAL DE JUIZ DE FORA. Juiz de fora. Disponvel em:
<http://www.ufjf.br/ep/files/2009/tcc_dez2007_rodrigopiubello.pdf>. Acesso em 22 maio
2012.
SOMMERVILLE, lan. Engenharia de Software. Oitava So Paulo: Pearson Addison-Wesley,
2007.
SOUZA, Maria Rosngela Oliveira Machado Rosa de. A ENGENHARIA DE REQUISITOS
NO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS. 50 ed. So Paulo: Uniesp,

2007.
Disponvel
em:
<http://www.uniesp.edu.br/tema/tema50/03Maria
RosangelaOliveira.pdf>. Acesso em: 09 out. 2012.
TECLUDI,
WAMP

O
que
e?
Disponvel
<http://tecludi.wordpress.com/2008/03/28/wamp-o-que-e/>. Acesso em: 12 junho 2012.

em:

TEIXEIRA, Damzio Pereira. Requisitos de Mtodos de Garantia de Qualidade no

Desenvolvimento de Software. Departamento de Cincias da Computao Universidade
Federal
de
Minas
Gerais,
Pampulha.
Disponvel
em:
<http://homepages.dcc.ufmg.br/~rodolfo/dcc823-2-07/Entrega4/Damzio4.pdf>. Acesso em:
12 junho 2012.
TRAVASSOS, Guilherme Horta GOROV, Dmytro; AMARAL, Edgar Augusto Gurgel do.
Introduo Engenharia de Software Experimental. Rio de Janeiro: Coppe?ufrj, 2002.
Disponvel
em:
<http://www2.ufpa.br/cdesouza/teaching/topes/4-ESExperimental.pdf>Acesso em 09 out. 2012.
ZANIRO, Dnis; FABRI, Sandra. Um processo Guiado pera levantamento de Requisitos de
Aplicaes Web Baseado em Objetivos e Casos de Uso. So Carlos. Disponvel em:
<http://wer.inf..puc-rio.br/WERpapers/artigos/artigos_WER08/zaniro.pdf>. Acesso em: 12
abril 2012.