UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
A IMPORTÂNCIA DO LEVANTAMENTO DE REQUISITOS NO
DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO NO
ÂMBITO DO PODER JUDICIÁRIO ESTADUAL
Por: Fabiano Teixeira da Silva
Orientador
Prof. Nelsom Magalhães
Rio de Janeiro
2012
DOCU
MENTO
PRO
TEGID
O PEL
A LE
I DE D
IREIT
O AUTO
RAL
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
A IMPORTÂNCIA DO LEVANTAMENTO DE REQUISITOS NO
DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO NO
ÂMBITO DO PODER JUDICIÁRIO ESTADUAL
Apresentação de monografia à AVM Faculdade
Integrada como requisito parcial para obtenção do
grau de especialista em Gestão de Projetos
Por: Fabiano Teixeira da Silva
3
AGRADECIMENTOS
Agradeço primeiramente a Deus pelas
oportunidades que Ele me proporciona.
A família, pelo companheirismo e
compreensão.
Aos colegas do curso de pós-
graduação pela parceria e
compartilhamento de ideias e
informações.
4
DEDICATÓRIA
Dedico à minha esposa, aos meus filhos e
aos meus pais, que me apoiam
incondicionalmente e a quem amo muito.
5
RESUMO
O presente trabalho tem por propósito abordar a importância do
levantamento de requisitos em projetos na área de Tecnologia da Informação,
em especial, nos projetos de desenvolvimento de sistemas de informação
(softwares).
Com o apoio do PMBOK e das técnicas de levantamento de requisitos,
este trabalho pretende apresentar algumas ferramentas que tem por objetivo
propiciar uma melhor compreensão desses requisitos no processo de
construção de sistemas de informação, entendendo e definindo claramente os
requerimentos do projeto e do negócio.
.
6
METODOLOGIA
A metodologia usada na elaboração deste trabalho foi pesquisa
bibliográfica, complementada com pesquisa de internet. As principais fontes
foram:
• GUIA PMBOK - 4ª Edição – 2008
• Livros sobre Engenharia de Software
• Material didático da AVM – Faculdade Integrada
7
SUMÁRIO
INTRODUÇÃO 08
CAPÍTULO I - O Cenário Atual 09
CAPÍTULO II - Engenharia de Requisitos 11
CAPÍTULO III – Guia PMBOK 21
CAPÍTULO IV – Ferramentas e Técnicas 34
CONCLUSÃO 43
BIBLIOGRAFIA 45
WEBGRAFIA 46
ÍNDICE 48
ÍNDICE DE FIGURAS 50
8
INTRODUÇÃO
De acordo com Ferreira (2010), o dicionário define a palavra requisito
como uma condição necessária para a obtenção de certo objetivo, ou para o
preenchimento de certo fim; quesito (p.1824).
Dentro do contexto de projetos de desenvolvimento de software,
requisito é um elemento essencial para o sucesso de um projeto. Os requisitos
são quem definem o que deverá ser feito no projeto. Sem os mesmos,
diminuem-se e muito as chances de êxito nos projetos mencionados.
Atualmente, os Tribunais de Justiça tem buscado um aumento da
eficiência de seus processos de trabalho, com o intuito de dar celeridade ao
julgamento de seus processos judiciais, objetivando uma melhor prestação
jurisdicional. Com isso, diversas solicitações têm sido demandadas para a área
de Tecnologia da Informação com o intuito de melhorar e automatizar os seus
processos internos. Com a área de informática abarrotada de solicitações e
com prazos exíguos para o atendimento das mesmas, ocorre que
determinadas atividades no desenvolvimento de software ficam prejudicadas,
incluindo a etapa de levantamento de requisitos.
Através do estudo de como efetuar levantamento de requisitos
abordados pela engenharia de software e também pelas boas práticas
consagradas e consolidadas no Guia PMBOK, este trabalho pretende
apresentar algumas ferramentas e técnicas que auxiliam nesta etapa da
construção do software, trazendo maior qualidade na coleta dos requisitos.
9
CAPÍTULO I
CENÁRIO ATUAL
Atualmente a área de Tecnologia da Informação (TI) vem sendo cada
vez mais requisitada para o desenvolvimento de sistemas de informação que
possam atender as necessidades de negócio da organização a qual
pertence.
No âmbito do Poder Judiciário, além das demandas relacionadas às
atividades do Tribunal de Justiça, o Conselho Nacional de Justiça (CNJ) vem
requerendo dos Tribunais de Justiça estaduais diversas solicitações que
necessitam do apoio da sua área de informática para o atendimento dessas
solicitações.
De fato, o número de solicitações que são feitas é em grande
quantidade. Para dar conta desta alta demanda de projetos, é necessário que
os profissionais da área de tecnologia da informação utilizem de ferramentas e
técnicas que possam aumentar a sua produtividade e a qualidade de seus
serviços.
Dentro deste contexto, observamos que a fase de planejamento tem
papel fundamental nos projetos da área de TI; e dentro desta fase, pode-se
afirmar que o bom levantamento dos requisitos do projeto é condição sine qua
non para o sucesso dos mesmos.
A figura abaixo apresenta o resultado de uma pesquisa sobre fatores
de fracasso de projetos de TI, realizada pela Standish Group:
10
Project Impaired Factors % of Responses
Incomplete Requirements 13.1%
Lack of User Involvement 12.4%
Lack of Resources 10.6%
Unrealistic Expectations 9.9%
Lack of Executive Support 9.3%
Changing Requirements & Specifications 8.7%
Lack of Planning 8.1%
Didn't Need It Any Longer 6
Lack of IT Management 6.2%
Tecnology Illiteracy 4.3%
Others 9.9%
Figura 1 - Causas de fracasso em projetos de sistemas de informação (Fonte: STANDISH GROUP, 1995, pag. 5)
11
CAPÍTULO II
ENGENHARIA DE REQUISITOS
Aquele que pergunta é tolo por 5 minutos; aquele que não faz é tolo
para sempre. (PROVÉRBIO CHINÊS citado por PRESSMAN, 2011, p.133)
A engenharia de requisitos tem se mostrado uma das mais importantes
fases do processo de desenvolvimento de software. Atualmente, observa-se
que a maior parte dos problemas no desenvolvimento dos sistemas é originada
nas etapas iniciais da construção do mesmo, onde identificar os objetivos do
sistema pretendido é essencial.
De acordo com a IEEE1 Standard 830-1984, engenharia de requisitos é
um processo de aquisição, refinamento e verificação das necessidades do
cliente para um sistema de informação, objetivando-se ter uma especificação
completa e correta dos requisitos de software.
Segundo Roger S. Pressman (2011, p. 127), “um amplo aspecto de
tarefas e técnicas que levam a um entendimento dos requisitos” é a definição
para engenharia de requisitos. A ideia é que ela forneça um mecanismo
adequado para se entender aquilo que o cliente deseja, analisando as
necessidades, avaliando a viabilidade, negociando uma solução razoável,
validando esses requisitos e gerenciando as necessidades à medida que são
incorporadas em um sistema de informação.
Ainda de acordo com Pressman, a Engenharia de Requisitos abrange
sete tarefas distintas (2011, p. 127-130):
1 Institute of Electrical and Electronic Engineers. Organização professional sem fins lucrativos, fundada nos Estados Unidos. Estabelece atividades de padrões baseadas em consenso. Fonte: http://www.ieee.org - Acessadas em 06/09/2012.
12
Ø Concepção - Em alguns casos seria a conversa inicial informal
com o cliente sobre o trabalho a ser feito. Quando é identificada a necessidade
do negócio.
Ø Levantamento - Basicamente é perguntar ao cliente e/ou aos
demais interessados os objetivos a serem alcançados de forma a atender as
necessidades da organização e como o mesmo deve ser utilizado no dia a dia.
Ø Elaboração - As informações obtidas nas tarefas anteriores são
expandidas e refinadas nesta tarefa. O objetivo é identificar os diversos
aspectos das funções, do comportamento e das informações do sistema.
Ø Negociação - É comum diferentes clientes ou interessados
proporem necessidades conflitantes. Nesta tarefa, conciliamos estes conflitos
através de um processo de negociação.
Ø Especificação - Nesta tarefa, começa o processo de
documentação dos requisitos. Um documento por escrito, um modelo
matemático formal, conjunto de cenários de uso, protótipos ou qualquer
combinação dos elementos citados.
Ø Validação - Os artefatos produzidos na etapa de especificação
são avaliados. A validação dos requisitos examina a especificação para
garantir que todos os requisitos do software tenham sido declarados de forma
não ambígua, que as inconsistências, omissões e erros tenham sido
detectados e corrigidos e que os artefatos estejam de acordo com os padrões
estabelecidos para o processo, projeto e produto.
Ø Gestão - Os requisitos mudam. E o desejo de mudar os
requisitos persiste ao longo da vida de um sistema. Gestão de requisitos é um
conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e
acompanhar as necessidades e suas mudanças ao longo do projeto.
13
Em outra perspectiva, segundo Summerville (2003), as atividades da
engenharia de requisitos são as seguintes (p. 103):
• Estudo de viabilidade;
• Obtenção e análise de requisitos;
• Validação de requisitos e
• Gerenciamento de requisitos.
A figura abaixo mostra o fluxo de atividades da Engenharia de
Requisitos:
Figura 2 - Fluxo de atividades do processo de Engenharia de Requisitos.
Adaptado. (Fonte: SUMMERVILLE, 2003, p. 103)
14
A figura abaixo mostra as entradas e saídas do processo de
engenharia de requisitos:
Figura 3 - Entradas e Saídas do Processo de Engenharia de Requisitos
(Fonte: MATUS, em http://ing.utalca.cl/~freyes/site/?q=system/files/Proyecto_de_ Programaci%C3%B3n_%28ICC%29./Material_de_Apoyo/ConceptosRequisitos.pdf.
Acessado em 12/10/2012.)
2.1. – Identificação dos Interessados
Etapa importante dentro da tarefa de concepção dos requisitos. De
acordo com Pressman (2011), interessado é qualquer um que se beneficia de
forma direta ou indireta do sistema que está sendo desenvolvido. Gerentes,
consultores, usuários finais, clientes internos e externos e outros (p. 131).
2.2 – Levantamento de Requisitos
O levantamento de requisitos é também chamado de elicitação de
requisitos, que significa definir, tornar explícito, obter o máximo de informação
sobre o objeto em questão. Combina elementos de resolução de problemas,
elaboração, negociação e especificação.
15
Quando desejamos solucionar um problema, agregando valor ao
negócio através de um sistema de informação, o primeiro passo é descobrir
quais são os requisitos desejáveis em relação a esse projeto. Neste processo
de descoberta, o elemento essencial e mais importante é o cliente que
requisita do sistema. As maiores dificuldades que surgem não são técnicos,
mas de comunicação, pois o objetivo é obter do cliente o que ele espera do
software a ser desenvolvido.
De acordo com Summerville (2003), as principais atividades do
processo de levantamento de requisitos são descritos na figura abaixo (p. 105):
ATIVIDADE DESCRIÇÃO
Compreensão do Domínio
Os analistas devem desenvolver sua compreensão do domínio da aplicação. Por exemplo, se exigido um sistema para supermercado, o analista deverá descobrir com operam os supermercados.
Coleta de requisitos
É o processo.de interagir com os interessados do sistema para descobrir os requisitos. A compreensão do domínio se desenvolve mais durante essa atividade.
Classificação Essa atividade considera o conjunto não estruturado de requisitos e os organiza em grupos coerentes.
Resolução de Conflitos
Quando múltiplos interessados estão envolvidos, os requisitos apresentação conflitos. Essa atividade se ocupa de encontrar e solucionar esses requisitos.
Definição das Prioridades
Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve a interação com os interessados para descobrir os requisitos mais importantes.
Verificação de Requisitos
Os requisitos são verificados, a fim de se descobrir se eles são completos e consistentes e se estão em concordância com o que os interessados realmente desejam do sistema.
Figura 4 – Quadro de atividades relacionadas ao processo de levantamento de requisitos. Adaptado. (Fonte: SUMMERVILLE, 2003, p. 105)
16
Segundo Summerville(2003), o levantamento e a análise de requisitos
é processo iterativo, com feedback contínuo de cada atividade para as outras.
O ciclo começa com a compreensão do domínio e termina com a verificação
dos requisitos. A compreensão dos requisitos melhora a cada fase do ciclo (p.
105), conforme demonstra a figura abaixo:
Figura 5 - Iteração entre as atividades do processo de Levantamento e Análise de
Requisitos (Fonte: SUMMERVILLE, 2003, p. 106)
2.2.1 – Tipos de Requisitos
Durante o processo de levantamento de requisitos, necessitamos
definir o tipo de requisito do qual estamos tratando, com o objetivo de melhor
compreender as necessidades do cliente.
Segundo Summerville (2003), os requisitos para o desenvolvimento de
sistemas de informação podem ser classificados em três categorias (p. 85):
Ø Requisitos Funcionais: São os requisitos que indicam as
funcionalidades que o sistema de informação deverá fornecer e como ele
17
deverá se comportar. Descreve as transformações a serem realizadas nas
entradas de um sistema ou em um de seus componentes, produzindo as
saídas esperadas.
Ø Requisitos Não Funcionais: Descrevem as restrições sobre as
funções oferecidas, como por exemplo as restrições de tempo, restrições de
uso de recursos, aspectos de desempenho, interfaces com o usuário,
confiabilidade, segurança portabilidade e outras propriedades que o software
deve possuir. Podem dizer respeito ao sistema como um todo e não a uma
funcionalidade específica.
Ø Requisitos de Domínio: São requisitos que se originam do
domínio da aplicação do sistema e que refletem características desse domínio.
podem ser requisitos funcionais ou não funcionais.
A figura abaixo mostra os níveis de abstração dos requisitos
supramencionados:
2.2.2 – Disponibilização da Função de Qualidade
A disponibilização da função de qualidade (quality function deployment, QFD) surgiu na década de 70 no Japão, nos estaleiros da Mitsubishi, em Kobe, e começou a ser propagado no Ocidente no final da década de 80. Tem como objetivo garantir a qualidade dos produtos e serviços de acordo com os desejos dos consumidores. (MARTINS, em http://www.blogdaqualidade.com.br/desdobramento-da-funcao-qualidade-qfd/, acessado em 11/10/2012)
Segundo Pressman (2011), a disponibilização da função de qualidade é
uma técnica de gestão de qualidade que traduz as necessidades do cliente
para requisitos técnicos do software. “O QFD concentra-se em maximizar a
satisfação do cliente por meio do processo de engenharia de
software”.(ZULTNER citado por PRESSMAN, 2011, p.136).
18
O QFD identifica três tipos de necessidades:
Ø Requisitos Normais: São os requisitos que refletem os objetivos
e metas estabelecidos para um produto ou sistema durante reuniões com o
cliente. Se eles estiverem presentes, o cliente fica satisfeito. Exemplo:
Funcionalidades específicas do sistema, níveis de desempenho definidos, etc.
Ø Requisitos Esperados: São requisitos que estão implícitos no
produto ou sistema e podem ser tão fundamentais que o cliente não os declara
explicitamente. Exemplo: Interface com o usuário intuitiva, confiabilidade,
facilidade na instalação, etc.
Ø Requisitos fascinantes: Recursos que vão além da expectativa
dos clientes e demonstram ser muito satisfatórios quando presentes. Exemplo:
Um novo celular vem com recursos padrão, mas junto vem um conjunto de
capacidades não esperadas como tela capacitiva multitoque com resistência a
arranhões.
19
Figura 6 – Planilha de Desdobramento/Disponibilização da Função de Qualidade (Fonte: MARTINS, http://www.blogdaqualidade.com.br/desdobramento-da-funcao-
qualidade-qfd/. Acessado em 11/10/2012)
20
2.2.3 – Documento de Requisitos
De acordo com Barcelos (2011), O Documento de Definição de
Requisitos (ou simplesmente Documento de Requisitos) tem como propósito
descrever os requisitos de usuário, tendo como público alvo clientes, usuários,
gerentes (de cliente e de fornecedor) e desenvolvedores (p. 16).
Há muitos formatos distintos propostos na literatura para documentos
de requisitos. Abaixo, é demonstrada uma estrutura simples para esse tipo de
documento, contendo apenas quatro seções:
Ø Introdução: breve introdução ao documento, descrevendo seu
propósito e estrutura.
Ø Descrição do Propósito do Sistema: descreve o propósito
geral do sistema.
Ø Descrição do Minimundo: apresenta, em um texto corrido, uma
visão geral do domínio, do problema a ser resolvido e dos processos de
negócio apoiados, bem como as principais ideias do cliente sobre o sistema a
ser desenvolvido.
Ø Requisitos de Usuário: apresenta os requisitos de usuário em
linguagem natural. Três conjuntos de requisitos devem ser descritos nesta
seção: requisitos funcionais, requisitos não funcionais e regras de negócio.
Identificador Descrição Origem Priorida-
de Responsável Interessados Dependências Conflitos
Figura 7 – Tabela de Requisitos (Fonte: BARCELOS, 2011, p.17)
21
CAPÍTULO III
GUIA PMBOK
O PMBOK (Project Management Body of Knowledge) ou Guia do
Conhecimento em Gerenciamento de Projetos é um conjunto de
conhecimentos amplamente reconhecido como boa prática em gestão de
projetos. Ele é elaborado e publicado pelo PMI (Project Manegement Institute),
servindo de base para este instituto.
De acordo com o próprio Guia PMBOK(2008), ele também fornece e
promove um vocabulário comum dentro da profissão de gerenciamento de
projetos para se discutir, escrever e aplicar conceitos de gerenciamento de
projetos, possibilitando a troca de informações entre os profissionais que
atuam na área de gerenciamento de projetos, tornando-se uma referência
básica para gerenciamento de projetos (p.11).
Este capítulo abordará a parte conceitual do PMBOK, bem como a
área de conhecimento e os processos relacionados ao levantamento de
requisitos de um projeto.
3.1. – Definição
Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. A sua natureza indica um início e um término definidos. O término é alcançado quando os objetivos tiverem sido atingidos ou quando concluir que esses objetivos não serão ou não poderão ser atingidos e o projeto for encerrado, ou quando o mesmo não for mais necessário. (PMBOK, 2008, p. 11).
Este guia é baseado em processos e subprocessos para descrever de
forma organizada o trabalho a ser realizado durante o projeto.
22
Segundo o PMBOK (2008), o gerenciamento de projetos é realizado
através da aplicação e integração apropriadas de 42 processos. Este
processos estão divididos em 5 grupos, chamados grupos de processos. Os
grupos de Processo são:
• Iniciação;
• Planejamento;
• Execução;
• Monitoramento e controle e
• Encerramento.
Os processos são gerenciados por nove (9) áreas de conhecimento:
• Integração;
• Escopo;
• Tempo;
• Custo;
• Qualidade;
• Recursos Humanos;
• Comunicações;
• Riscos e
• Aquisições.
Na figura abaixo, é demonstrada a distribuição dos processos pelas
áreas de conhecimento e também pelos grupos de processo:
Áreas de Conhecimento
Iniciação Planejamento Execução Monitoramento e controle
Encerramento
Integração
1. Desenvolver o termo de abertura do projeto
2. Desenvolver o plano de gerenciamento do projeto
3. Orientar e gerenciar a execução do projeto
4. Monitorar e controlar o trabalho do projeto 5. Realizar o controle integrado de mudanças
6. Encerrar o projeto ou fase
23
Escopo
1. Coletar os requisitos 2. Definir o escopo 3. Criar a EAP
4. Verificar o escopo 5. Controlar o escopo
Tempo
1. Definir as atividades 2. Sequenciar as atividades 3. Estimar os recursos das atividades 4. Estimar as durações das atividades 5. Desenvolver o cronograma
6. Controlar o cronograma
Custos
1. Estimar os custos 2. Determinar o orçamento
3. Controlar os custos
Qualidade 1. Planejar a qualidade
2. Realizar a garantia de qualidade
3. Realizar o controle da qualidade
Recursos Humanos
1. Desenvolver o plano de recursos humanos
2. Mobilizar a equipe do projeto 3. Desenvolver a equipe de projeto 4. Gerenciar a equipe do projeto
Comunicação 1. Identificar as partes interessadas
2. Planejar as comunicações
3. Distribuir as informações 4. Gerenciar as expectativas das partes interessadas
5. Reportar o desempenho
Riscos
1. Planejar o gerenciamento dos riscos 2. Identificar os riscos 3. Realizar a análise qualitativa dos riscos 4. Realizar a análise quantitativa dos riscos 5. Planejar as respostas aos riscos
6. Monitorar e controlar os riscos
Aquisição 1. Planejar as aquisições
2. Conduzir as aquisições
3. Administrar as aquisições
4. Encerrar as aquisições
Figura 8 – Mapeamento de grupos de processos de gerenciamento de projetos e áreas de conhecimento. Adaptado. (Fonte: PMBOK, 2008, p. 43)
24
3.2. – Gerenciamento de Escopo do Projeto
O gerenciamento do escopo do projeto é a área de conhecimento
responsável pelo levantamento dos requisitos do projeto.
O guia PMBOK (2008) diz que: “O gerenciamento do escopo do projeto
inclui os processos necessários para assegurar que o projeto inclui todo o
trabalho necessário, e apenas o necessário, para terminar o projeto com
sucesso. Esse gerenciamento está relacionado principalmente com a definição
e controle do que está e do que não está incluso no projeto“ (p. 92).
Os processos que pertencem a está área de conhecimento são:
• Coletar os requisitos;
• Definir o escopo;
• Criar a Estrutura Analítica do Projeto (EAP);
• Verificar o escopo e
• Controlar o escopo.
25
Figura 9 – Resumo do gerenciamento de escopo do projeto (Fonte: PMBOK, 2008,
p.93)
3.2.1 – Coletar os requisitos
De acordo com o PMBOK (2008), este processo é o responsável pela
definição e documentação das necessidades das partes interessadas, a fim de
se alcançar os objetivos do projeto (p.92).
26
É fundamental que os requisitos do projeto estejam bem descritos e
possam ser medidos, a fim de que possam ser verificados e validados
posteriormente.
As entradas deste processo são:
• Termo de Abertura do Projeto e
• Registro das Partes Interessadas.
As ferramentas e técnicas deste processo são:
• Entrevista;
• Dinâmica de Grupo;
• Oficinas;
• Técnicas de Criatividade em Grupo;
• Técnicas de Tomada de Decisão em Grupo;
• Questionários e pesquisas;
• Observações e
• Protótipos;
As saídas deste processo são:
• Documentação dos requisitos;
• Plano de Gerenciamento dos Requisitos e
• Matriz de Rastreabilidade de Requisitos.
A figura abaixo mostra as entradas, as ferramentas e as saídas do
processo de coleta de requisitos:
27
Figura 10 – Entrada, ferramentas e saídas do processo Coletar Requisitos. (Fonte: JENNY, em http://julianakolb.com/2011/01/19/5-1-coletar-requisitos/, acessado em
08/10/2012)
3.2.2 – Definir o Escopo
Segundo o PMBOK (2008), neste processo é feito o desenvolvimento
de uma descrição detalhada do projeto e do produto. A preparação da
declaração de escopo de forma detalhada é um fator crítico para o sucesso do
projeto. Baseia-se nas entregas principais, nas premissas e nas restrições que
são documentadas durante a iniciação do projeto.
As entradas deste processo são:
• Termo de Abertura do Projeto;
• Documentação dos requisitos e
• Ativos de Processos Organizacionais.
28
As ferramentas e técnicas deste processo são:
• Opinião Especializada;
• Análise do Produto;
• Identificação de Alternativas e
• Oficinas.
As saídas deste processo são:
• Declaração do Escopo do Projeto e
• Atualizações dos documentos do projeto.
A figura abaixo mostra as entradas, as ferramentas e as saídas do
processo de definir o escopo:
Figura 11 – Entrada, ferramentas e saídas do processo Definir o Escopo. (Fonte: JENNY, em http://julianakolb.com/2011/01/24/5-2-definir-o-escopo/, acessado em
08/10/2012)
29
3.2.3 – Criar a EAP
O PMBOK (2008) diz: “A estrutura analítica do projeto (EAP) é uma
decomposição hierárquica orientada às entregas do trabalho a ser executado
pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas,
sendo que cada nível descendente da EAP representa uma definição
gradualmente mais detalhada da definição do trabalho do projeto” (p.101).
A ideia é decompor as entregas de trabalho do projeto em
componentes ainda menores, facilitando o gerenciamento dos projetos. A EAP
é também conhecida como Work Breakdown Structure (WBS).
As entradas deste processo são:
• Declaração do Escopo do Projeto;
• Documentação dos requisitos e
• Ativos de Processos Organizacionais.
As ferramentas e técnicas deste processo são:
• Decomposição.
As saídas deste processo são:
• Estrutura Analítica do Projeto (EAP);
• Dicionário da EAP;
• Linha de Base do Escopo e
• Atualizações dos documentos do projeto.
A figura abaixo mostra as entradas, as ferramentas e as saídas do
processo de definir o escopo:
30
Figura 12 – Entrada, ferramentas e saídas do processo Criar a EAP. (Fonte: JENNY, em http://julianakolb.com/2011/01/21/5-3-criar-a-eap/, acessado em 08/10/2012)
3.2.4 – Verificar Escopo
De acordo com o PMBOK (2008), Neste processo é realizada a
formalização da aceitação das entregas concluídas do projeto. É efetuada a
revisão das entregas com o cliente para assegurar que foram concluídas
satisfatoriamente, obtendo o aceite formal dos mesmos.
As entradas deste processo são:
• Plano de Gerenciamento do Projeto;
• Documentação dos requisitos;
• Matriz de Rastreabilidade de Requisitos e
• Entregas validadas.
31
As ferramentas e técnicas deste processo são:
• Inspeção.
As saídas deste processo são:
• Entregas aceitas;
• Solicitações de Mudanças e
• Atualizações dos documentos do Projeto.
A figura abaixo mostra as entradas, as ferramentas e as saídas do
processo verificar escopo:
Figura 13 – Entrada, ferramentas e saídas do processo Verificar Escopo. (Fonte: JENNY, em http://julianakolb.com/2011/01/26/5-4-verificar-o-escopo/, acessado em
08/10/2012)
32
3.2.5 – Controlar Escopo
Neste processo é realizado o monitoramento do andamento do escopo
do projeto e do produto e gerenciamento das mudanças feitas na linha de base
do escopo, assegurando que todas as mudanças solicitadas são processadas.
As entradas deste processo são:
• Plano de Gerenciamento do Projeto;
• Documentação dos requisitos;
• Matriz de Rastreabilidade de Requisitos;
• Informações sobre o Desempenho do Trabalho;
• Ativos de Processos organizacionais.
As ferramentas e técnicas deste processo são:
• Análise de Variação.
As saídas deste processo são:
• Medição do Desempenho do Trabalho;
• Atualizações de Ativos de Processos Organizacionais;
• Solicitações de Mudanças;
• Atualizações no Plano de Gerenciamento do Projeto e
• Atualizações dos Documentos do Projeto.
33
Figura 14 – Entrada, ferramentas e saídas do processo Controlar o Escopo. (Fonte: JENNY, emhttp://julianakolb.com/2011/01/26/5-5-controlar-o-escopo/,
acessado em 08/10/2012)
34
CAPÍTULO IV
FERRAMENTAS E TÉCNICAS
A fase de levantamento de requisitos é essencial para o pleno
entendimento do que deve ser feito dentro do contexto de projetos. A utilização
de ferramentas e técnicas para obtenção desses requisitos tem por objetivo
auxiliar o profissional a superar as dificuldades associadas a esta fase do
projeto.
Este capítulo abordará algumas técnicas e ferramentas utilizadas tanto
pela engenharia de requisitos como pelo Guia PMBOK para o levantamento de
requisitos.
O conjunto de ferramentas e técnicas que serão alvo deste estudo são:
• Entrevistas;
• Joint Application Design (JAD);
• Questionários;
• Brainstorming;
• Delphi;
• Cenários;
• Prototipagem;
• Etnografia.
4.1. – Entrevistas
Uma entrevista é um meio formal ou informal de se descobrir informações das partes interessadas através de conversas diretas com as mesmas. Normalmente é feita através de perguntas preparadas ou espontâneas e do registro das respostas. São freqüentemente conduzidas individualmente,
35
mas podem envolver múltiplos entrevistadores e/ou entrevistados. Entrevistar participantes experientes, partes interessadas e especialistas no assunto do projeto pode auxiliar na identificação e definição das características e funções das entregas desejadas. (PMBOK, 2008, p. 95).
Segundo Moraes (2009) , a entrevista é uma das técnicas tradicionais
mais simples de utilizar e que produz bons resultados na fase inicial de
obtenção de dados. Convém que o entrevistador dê margem ao entrevistado
para expor as suas idéias. É necessário ter um plano de entrevista para que
não haja dispersão do assunto principal e a entrevista fique longa, deixando o
entrevistado cansado e não produzindo bons resultados. (p.56)
Alguns itens importantes devem ser observados pelo entrevistador:
• desenvolver um plano geral de entrevistas;
• planejar a entrevista para fazer uso eficiente do tempo;
• coletar e estudar todos as informações pertinentes a entrevista;
• determinar o escopo da entrevista, de modo que a mesma não
tenha longa duração, pois a dificuldade de se concentrar
aumenta com o passar do tempo.
4.2. – Joint Application Design (JAD)
(...)oficinas chamadas de sessões de Joint Application Design (JAD) são usadas na indústria de desenvolvimento de software. Essas são focadas em unir os usuários e a equipe de desenvolvimento para aperfeiçoar o processo de desenvolvimento do software. (PMBOK, 2008, p. 95).
De acordo com Moraes (2009), O JAD facilita a criação de uma visão
compartilhada do que o produto de software deve ser. Através da sua
utilização, os desenvolvedores ajudam os usuários a formular problemas e
36
explorar soluções. Dessa forma, os usuários ganham um sentimento de
envolvimento, posse e responsabilidade com o sucesso do produto (p. 57).
Ainda segundo Moraes (2009), a técnica JAD tem quatro princípios
básicos:
• Dinâmica de grupo: São realizadas reuniões com um líder
experiente, analista, usuários e gerentes, para despertar a força
e criatividade dos participantes. O resultado final será a
determinação dos objetivos e requisitos do sistema;.
• Uso de técnicas visuais: Objetiva aumentar a comunicação e o
entendimento.
• Manutenção do processo organizado e racional: A técnica
JAD faz uso da análise Top Down e atividades bem definidas,
possibilitando assim a garantia de uma análise completa,
reduzindo as chances de falhas ou lacunas no projeto;
• Utilização de documentação padrão: A documentação deve
ser preenchida e assinada por todos os participantes. Este
documento visa garantir a qualidade esperada do projeto e
promove a confiança dos participantes.
37
4.3. – Questionários
Questionários e pesquisas são conjuntos escritos de questões projetadas para acumular rapidamente informações a partir de um amplo número de entrevistados. Questionários e/ou pesquisas são mais apropriados para grandes audiências, quando uma resposta rápida é necessária e quando uma análise estatística é apropriada. (PMBOK, 2008, p. 95).
Diferente da entrevista, o questionário é uma técnica indicada quando
temos uma grande quantidade de pessoas para extrair as mesmas
informações ou grupo de entrevistados em locais diferentes e distantes.
Segundo Moraes (2009), na fase de preparação do questionário deve
ser indicado o tipo de informação que se deseja obter. O questionário deve ser
elaborado com questões de forma simples, clara e concisa, deixar espaço
suficiente para as repostas que forem descritivas e agrupar as questões de
tópicos específicos em um conjunto com um título especial. O questionário
deve ser acompanhado por uma carta explicativa, enfatizando a importância
dessa pesquisa para a organização (p. 57).
4.4. – Brainstorming
Segundo o PMBOK (2008, p.95), o Brainstorming é: "Uma técnica
usada para gerar e coletar múltiplas idéias relacionadas aos requisitos do
projeto e do produto".
Brainstorming significa tempestade de idéias. Ou seja, gerar idéias é o
foco desta técnica. De acordo com Moraes (2009), ela consiste em uma ou
várias reuniões onde é permitido aos participantes sugerirem e explorarem
idéias. As idéias que a princípio pareçam não convencionais são encorajadas
pois elas freqüentemente estimulam os participantes, o que pode levar a
38
soluções criativas para o problema. O número de idéias geradas deve ser
grande, pois quanto mais idéias forem propostas, maior será a chance de boas
idéias.Combinar e enriquecer as idéias de outros participantes deve ser
encorajado.
Ainda segundo Moraes (2009), as principais etapas para conduzir uma
reunião de brainstorming são (p.57):
• Seleção dos participantes: Os participantes devem ser
selecionados em função das contribuições diretas que possam
dar durante a sessão. A presença de pessoas bem informadas,
vindas de diferentes grupos garantirá uma boa representação.
• Explicar a técnica e as regras a serem seguidas: O líder da
reunião explica os conceitos básicos de brainstorming e as
regras a serem seguidas durante a reunião.
• Produzir uma boa quantidade de idéias: Os participantes
geram tantas idéias quantas forem exigidas pelos tópicos que
estão sendo o objeto do brainstorming. Os participantes são
convidados, um por vez, a dar uma única idéia. Se alguém tiver
problema, passa a vez e espera a próxima rodada.
Ao final do brainstorming. deve ser feita uma análise e revisão das
idéias. As mais relevantes são mantidas e classificadas e ordem de prioridade.
39
4.5. – Delphi
Um seleto grupo de especialistas responde questionários e fornece comentários a respeito das respostas de cada rodada de coleta de requisitos. Para manter o anonimato, as respostas só ficam disponíveis ao facilitador. (PMBOK, 2008, p. 95).
Segundo Wright (1986), a técnica Delphi passou a ser disseminada no
começo dos anos 60, com base em trabalhos desenvolvidos por Olaf Helmer e
Norman Dalker, pesquisadores da Rand Corporation. O objetivo original era
desenvolver uma técnica para aprimorar o uso da opinião de especialistas na
previsão tecnológica. Na metodologia desenvolvida, isto era feito
estabelecendo-se três condições básicas: o anonimato dos respondentes, a
representação estatística da distribuição dos resultados, e o feedback de
respostas do grupo para reavaliação nas rodadas subseqüentes.
As vantagens da técnica delphi são:
• Técnica adequada para obter consenso entre especialistas;
• Processo pode ser feito virtualmente;
• Pode focar em detalhes do projeto ou no projeto como um todo.
As principais desvantagens são:
• O processo é demorado.
• Requer habilidade para interpretar as opiniões dos especialistas.
40
4.6. – Cenários
Os cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções. Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais e as possibilidades que podem surgir. (LEITE, 2007, em http://engenhariadesoftware.blogspot.com.br/2007/05/usando-cenrios-para-descobrir.html. Acessado em 13/10/2012.)
Segundo Leite (2007), não é objetivo da técnica de cenários oferecer
uma descrição precisa, mas provocar discussões e estimular novos
questionamentos.
De acordo com Summerville (2003), os cenários podem acrescentar
detalhes a um esboço de requisitos. O cenário começa com um esboço da
interação e, durante o levantamento de requisitos, são acrescentados mais
detalhes (p.111).
Ainda segundo Summerville (2003), o cenário pode incluir:
• Uma descrição do estado do sistema no início do cenário.
• Uma descrição do fluxo normal de eventos no cenário.
• Uma descrição do que pode sair errado e de como lidar com
isso.
• Informações sobre outras atividades que possam estar em
andamento ao mesmo tempo.
• Uma descrição do estado do sistema no final do cenário.
41
4.7. – Prototipagem
Esta técnica costuma ser bastante utilizada na fase de levantamento
de requisitos. Segundo Moraes (2009), o protótipo tem por objetivo explorar
aspectos críticos dos requisitos de um produto, implementando de forma
rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo
é indicado para estudar as alternativas de interface do usuário; problemas de
comunicação com outros produtos; e a viabilidade de atendimento dos
requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo
são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre
outras (p.56).
Esta técnica é muito utilizada quando os usuários não conseguem
expressar os requisitos.
Um dos principais benefícios do protótipo é a redução dos riscos na
construção do sistema, pois o usuário consegue observar o que o analista
captou nos requisitos do produto.
4.8. – Etnografia
Segundo Moraes (2009), A etnografia é uma técnica de observação
que pode ser utilizada para compreender os requisitos sociais e
organizacionais, ou seja, entender a política organizacional bem como a cultura
de trabalho com objetivo de familiarizar-se com o sistema e sua história. Os
cientistas sociais e antropólogos usam técnicas de observação para
desenvolver um entendimento completo e detalhado de culturas particulares.
42
Ainda de acordo com Moraes (2009), nesta técnica, o analista se
insere no ambiente de trabalho em que o sistema será utilizado. O trabalho
diário é observado e são anotadas as tarefas reais em que o sistema será
utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir
requisitos de sistema implícitos, que refletem os processos reais, em vez de os
processos formais, onde as pessoas estão envolvidas.
Segundo Summerville (2003), a Etnografia é particularmente eficaz na
descoberta de dois tipos de requisitos (p.114):
• Os requisitos derivados da maneira como as pessoas realmente
trabalham, em vez da maneira pela qual as definições de
processo dizem como elas deveriam trabalhar;
• Os requisitos derivados da cooperação e conscientização das
atividades de outras pessoas.
Ainda de acordo com Summervile (2003), a etnografia pode ser
combinada com a prototipação. A etnografia informa o desenvolvimento do
protótipo, de modo que um número menor de ciclos de refinamento do
protótipo seja necessário (p.115).
Figura 15 – Etnografia e prototipação. (Fonte: SUMMERVILLE, 2003, p. 115)
43
CONCLUSÃO
É fundamental compreender a natureza e a complexidade do problema
a ser solucionado através da construção de um software. De acordo com
Summerville (2003), é difícil estabelecer com exatidão o que o sistema de
informação deve fazer. As descrições das funções e das restrições são os
requisitos para o sistema; é necessário descobrir, analisar, documentar e
verificar essas funções e restrições através da engenharia de requisitos.
O guia PMBOK (2008), que é um guia de boas práticas para
gerenciamento de projetos, na área de conhecimento "gerenciamento de
escopo do projeto", esclarece a importância de assegurar que o projeto inclua
todo o trabalho necessário, e apenas o necessário para terminar o projeto com
êxito. Para alcançar o propósito acima, ele fornece um processo específico
dentro do seu corpo de conhecimento: "Coletar os Requisitos". Com isso,
obtemos a definição e a documentação das necessidades das partes
interessadas.
O levantamento de requisitos no âmbito dos projetos de
desenvolvimento de sistemas de informação é um fator crítico de sucesso. Ao
invés de prejudicarmos esta etapa do projeto para cumprirmos cronogramas
muito reduzidos, devemos negociar com as partes interessadas um tempo
adequado para que sejam realizadas todas as etapas do projeto com exação,
principalmente a etapa em epígrafe. Com isso aumentamos as chances de
sucesso do projeto, conseguindo a satisfação dos clientes, aumentando o
44
retorno sobre o investimento. As organizações que negligenciam esta etapa do
projeto acabam tendo que empreender esforços a posteriori do projeto, tendo
muitas vezes que refazer trabalho.
45
BIBLIOGRAFIA
IEEE Std 830-1984 Standard Guide for Software Requirements
Specifications. IEEE, 1984.
FERREIRA, Aurélio Buarque de Holanda. Dicionário Aurélio da Língua
Portuguesa. 5ª Edição. Curitiba: Positivo, 2010.
MORAES, Janaína Bedani Dixon. REVISTA ENGENHARIA DE SOFTWARE
MAGAZINE. Rio de Janeiro; DevMedia, 2009. Mensal. Ano 01 - Edição nº 2.
Introdução a Abordagens de Identificação de Requisitos. p. 54-58.
PRESSMAN, Roger S. Engenharia de Software: Uma abordagem
Profissional. 7ª Edição. Porto Alegre: AMGH, 2011.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em
Gerenciamento de Projetos (Guia PMBOK). 4ª Edição. Pennsylvania: PMI,
2008.
SOMMERVILLE, Ian. Engenharia de Software. 6ª Edição. EDITORA
ADDISON-WESLEY, 2003.
46
WEBGRAFIA
BARCELOS, Monalessa Perini. Engenharia de Software – Notas de Aula II.
UFES, 2011. http://www.inf.ufes.br/~monalessa/PaginaMonalessa-
NEMO/ES/NotasDeAula-EngSoftware-EngComp-Parte-II.pdf. Acessado em
08/10/2012.
JENNY, Juliana. Sumario – Gerenciamento de Projetos.
http://julianakolb.com/2011/08/30/sumario/. Acessado em 08/10/2012.
LEITE, Jair C. Engenharia de Software. Usando cenários para descobrir
requisitos. 2007. http://engenhariadesoftware.blogspot.com.br/2007/05/usando-
cenrios-para-descobrir.html. Acessado em 13/10/2012.
MARTINS, Rosemary. Desdobramento Da Função Qualidade (QFD). http://www.blogdaqualidade.com.br/desdobramento-da-funcao-qualidade-qfd/. Acessado em 13/10/2012
MATUS, Francisco Reyes. Texto de Apoyo - Conceptos Básicos de Requisitos.
http://ing.utalca.cl/~freyes/site/?q=system/files/Proyecto_de_Programaci%C3%
B3n_%28ICC%29./Material_de_Apoyo/ConceptosRequisitos.pdf. Acessado em
12/10/2012.
REBELO, Irla. Apostila IHC - Interação Homem -Computador.
http://irlabr.wordpress.com/apostila-de-ihc/parte-1-ihc-na-pratica/projetando-
interacoes/. Acessado em 12/10/2012)
STANDISH GROUP. Chaos Report. 1995.
http://www.projectsmart.co.uk/docs/chaos-report.pdf. Acessado em 02/10/2012.
47
WRIGHT, James Terence Coulter e GIOVINAZZO, Renata Alves. DELPHI –
Uma ferramenta de apoio ao planejamento prospectivo
http://www.fundacaofia.com.br/profuturo/Uploads/Documents/Artigos/art50.htm.
Acessado em 12/10/2012.
48
ÍNDICE
FOLHA DE ROSTO 2
AGRADECIMENTO 3
DEDICATÓRIA 4
RESUMO 5
METODOLOGIA 6
SUMÁRIO 7
INTRODUÇÃO 8
CAPÍTULO I
CENÁRIO ATUAL 9
CAPÍTULO II
ENGENHARIA DE REQUISITOS 11
2.1. Identificação dos Interessados 14
2.2. Levantamento de Requisitos 14
2.2.1. Tipos de Requisitos 16
2.2.2. Disponibilização da Função de Qualidade 17
2.2.3. Documento de Requisitos 20
CAPÍTULO III
PMBOK 21
3.1. Definição 21
3.2. Gerenciamento de Escopo do Projeto 24
3.2.1. Coletar os requisitos 25
3.2.2. Definir o Escopo 27
3.2.3. Criar a EAP 29
3.2.4. Verificar Escopo 30
3.2.5. Controlar Escopo 32
49
CAPÍTULO IV
FERRAMENTAS E TÉCNICAS 34
4.1. – Entrevistas 34
4.2. – Joint Application Design (JAD) 35
4.3. – Questionários 37
4.4. – Brainstorming 37
4.5. – Delphi 39
4.6. – Cenários 40
4.7. – Prototipagem 41
4.8. – Etnografia 41
CONCLUSÃO 43
BIBLIOGRAFIA 45
WEBGRAFIA 46
ÍNDICE 48
ÍNDICE DE FIGURAS 50
50
ÍNDICE DE FIGURAS
Figura 1 - Causas de fracasso em projetos de sistemas de informação 10
Figura 2 - Fluxo de atividades do processo de Engenharia de Requisitos 13
Figura 3 - Entradas e Saídas do Processo de Engenharia de Requisitos 14
Figura 4 - Quadro de atividades relacionadas ao processo de
Levantamento de Requisitos 15
Figura 5 - Iteração entre as atividades do processo de Levantamento
e Análise de Requisitos 16
Figura 6 - Planilha de Desdobramento/Disponibilização da Função
de Qualidade 19
Figura 7 - Tabela de Requisitos 20
Figura 8 – Mapeamento de grupos de processos de gerenciamento
de projetos e áreas de conhecimento 23
Figura 9 – Resumo do gerenciamento de escopo do projeto 25
Figura 10 – Entrada, ferramentas e saídas do processo Coletar Requisitos 27
Figura 11 – Entrada, ferramentas e saídas do processo Definir o Escopo 28
Figura 12 – Entrada, ferramentas e saídas do processo Criar a EAP 30
Figura 13 – Entrada, ferramentas e saídas do processo Verificar Escopo 31
Figura 14 – Entrada, ferramentas e saídas do processo Controlar o Escopo 33
Figura 15 – Etnografia e prototipação 42
Recommended
