Você está na página 1de 158

ENGENHARIA DE

REQUISITOS

Professora Me. Vanessa Ravazzi Perseguine

GRADUAO

Unicesumar
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pr-Reitor de Administrao
Wilson de Matos Silva Filho
Pr-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cludio Ferdinandi

NEAD - Ncleo de Educao a Distncia


Direo Operacional de Ensino
Ktia Coelho
Direo de Planejamento de Ensino
Fabrcio Lazilha
Direo de Operaes
Chrystiano Mincoff
Direo de Mercado
Hilton Pereira
Direo de Polos Prprios
James Prestes
Direo de Desenvolvimento
Dayane Almeida
Direo de Relacionamento
Alessandra Baron
Gerncia de Produo de Contedo
Juliano de Souza
Superviso do Ncleo de Produo de
Materiais
Ndila de Almeida Toledo
Coordenador de Contedo
Fabiana De Lima
Design Educacional
Yasminn Zagonel
Projeto Grfico
Jaime de Marchi Junior
Jos Jhonny Coelho
C397 CENTRO UNIVERSITRIO DE MARING. Ncleo de Educao a
Editorao
Distncia; PERSEGUINE, Vanessa Ravazzi
Humberto Garcia da silva
Engenharia de Requisitos. Vanessa Ravazzi Perseguine. Reviso Textual
(Reimpresso revista e atualizada) Viviane Favaro Notari/Yara Martins Dias
Maring-Pr.: UniCesumar, 2016.
158 p. Ilustrao
Graduao - EaD. Andr Lus Onishi

1. Engenharia. 2. Software. 3. Gesto EaD. I. Ttulo.

CDD - 22 ed. 620


CIP - NBR 12899 - AACR/2

Ficha catalogrfica elaborada pelo bibliotecrio


Joo Vivaldo de Souza - CRB-8 - 6828
Viver e trabalhar em uma sociedade global um
grande desafio para todos os cidados. A busca
por tecnologia, informao, conhecimento de
qualidade, novas habilidades para liderana e so-
luo de problemas com eficincia tornou-se uma
questo de sobrevivncia no mundo do trabalho.
Cada um de ns tem uma grande responsabilida-
de: as escolhas que fizermos por ns e pelos nos-
sos faro grande diferena no futuro.
Com essa viso, o Centro Universitrio Cesumar
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir
para o futuro dos brasileiros.
No cumprimento de sua misso promover a
educao de qualidade nas diferentes reas do
conhecimento, formando profissionais cidados
que contribuam para o desenvolvimento de uma
sociedade justa e solidria , o Centro Universi-
trio Cesumar busca a integrao do ensino-pes-
quisa-extenso com as demandas institucionais
e sociais; a realizao de uma prtica acadmica
que contribua para o desenvolvimento da consci-
ncia social e poltica e, por fim, a democratizao
do conhecimento acadmico com a articulao e
a integrao com a sociedade.
Diante disso, o Centro Universitrio Cesumar al-
meja ser reconhecido como uma instituio uni-
versitria de referncia regional e nacional pela
qualidade e compromisso do corpo docente;
aquisio de competncias institucionais para
o desenvolvimento de linhas de pesquisa; con-
solidao da extenso universitria; qualidade
da oferta dos ensinos presencial e a distncia;
bem-estar e satisfao da comunidade interna;
qualidade da gesto acadmica e administrati-
va; compromisso social de incluso; processos de
cooperao e parceria com o mundo do trabalho,
como tambm pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educao continuada.
Seja bem-vindo(a), caro(a) acadmico(a)! Voc est
iniciando um processo de transformao, pois quan-
do investimos em nossa formao, seja ela pessoal
ou profissional, nos transformamos e, consequente-
Diretoria de
mente, transformamos tambm a sociedade na qual
Planejamento de Ensino
estamos inseridos. De que forma o fazemos? Criando
oportunidades e/ou estabelecendo mudanas capa-
zes de alcanar um nvel de desenvolvimento compa-
tvel com os desafios que surgem no mundo contem-
porneo.
O Centro Universitrio Cesumar mediante o Ncleo de
Diretoria Operacional
Educao a Distncia, o(a) acompanhar durante todo
de Ensino
este processo, pois conforme Freire (1996): Os homens
se educam juntos, na transformao do mundo.
Os materiais produzidos oferecem linguagem dial-
gica e encontram-se integrados proposta pedag-
gica, contribuindo no processo educacional, comple-
mentando sua formao profissional, desenvolvendo
competncias e habilidades, e aplicando conceitos
tericos em situao de realidade, de maneira a inse-
ri-lo no mercado de trabalho. Ou seja, estes materiais
tm como principal objetivo provocar uma aproxi-
mao entre voc e o contedo, desta forma possi-
bilita o desenvolvimento da autonomia em busca dos
conhecimentos necessrios para a sua formao pes-
soal e profissional.
Portanto, nossa distncia nesse processo de cres-
cimento e construo do conhecimento deve ser
apenas geogrfica. Utilize os diversos recursos peda-
ggicos que o Centro Universitrio Cesumar lhe possi-
bilita. Ou seja, acesse regularmente o AVA Ambiente
Virtual de Aprendizagem, interaja nos fruns e en-
quetes, assista s aulas ao vivo e participe das discus-
ses. Alm disso, lembre-se que existe uma equipe de
professores e tutores que se encontra disponvel para
sanar suas dvidas e auxili-lo(a) em seu processo de
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurana sua trajetria acadmica.
AUTORES

Professora Me. Vanessa Ravazzi Perseguine


Mestre em Cincias da Computao. Especialista em Gesto e Coordenao
Escolar. Especialista em Gesto de Projetos. Graduada em Cincia da
Computao. Experiencia na Gesto de TI rgo Pblico, Coordenao de
cursos e projetos. Experincia na rea de Cincias da Computao, atuando
nas reas: engenharia de software, lgica e algoritmos e gerencia de projetos.
APRESENTAO

ENGENHARIA DE REQUISITOS

SEJA BEM-VINDO(A)!
Ol! Seja bem-vindo(a) disciplina Engenharia de Requisitos. Neste curso, iremos abor-
dar as atividades da engenharia de requisitos e sua importncia no processo de desen-
volvimento de software. Nesse contexto, gostaria que considerasse o seguinte: mesmo
para engenheiros de software experientes, complexo gerir todas as especialidades
envolvidas no processo de desenvolvimento de software.
Via de regra, os softwares so desenvolvidos para um conhecimento especfico, em que
se faz necessrio um entendimento prvio do modelo de negcio para o qual o software
ser desenvolvido. Por exemplo, se o software para o gerenciamento de uma locadora
de vdeos, o desenvolvedor dever entender sobre o negcio locar vdeos; se o software
tem a responsabilidade de emitir demonstrativos contbeis, o responsvel pelo seu de-
senvolvimento ter que conhecer todos os dados necessrios a serem levantados para
os clculos contbeis e posterior emisso desses relatrios; ou, ainda, se o software
responsvel pelo monitoramento dos dados que mantm atividades de sobrevivncia
que trar de volta terra o astronauta que foi a Marte, o profissional responsvel ter
que aprender todas as condies e exigncias que devero ser controladas. Para a entre-
ga de um produto de qualidade, que atenda s expectativas do cliente e que execute o
que se esperado, de extrema importncia que os responsveis pelo desenvolvimen-
to do software conheam o ambiente onde o software ser inserido.
Calma! No se assuste! No estou dizendo que ter que fazer uma faculdade sobre a es-
pecialidade de cada software que ir desenvolver, ou supervisionar o desenvolvimento,
o que eu pretendo deixar claro que to importante quanto desenvolver o software,
botar a mo na massa, o planejar o que ser desenvolvido. O tempo destinado ao
planejamento uma discusso antiga e a gesto de projetos est em evidncia mundial.
Casos de sucesso e a utilizao de tcnicas geis, modeladas para o desenvolvimento
de software, esto promovendo a desburocratizao do processo de software, princi-
palmente nas fases de planejamento e controle, o que tem impulsionado as empresas
para a sistematizao dos processos internos e a adoo de boas prticas de desenvolvi-
mento de software. Dentro da engenharia de software, podemos considerar como parte
do planejamento o estabelecimento de um processo de software, e a engenharia de re-
quisitos a atividade do processo de software responsvel por recolher as informaes
sobre o ambiente de negcio em que o software ser inserido, interpretar para os de-
senvolvedores o propsito do software e projetar as respostas esperadas pelos usurios.
Alm de entender como a engenharia de requisitos se situa nos processos de enge-
nharia de software, no decorrer desta disciplina, estudaremos os fundamentos da en-
genharia de requisitos, os processos, como gerenciar requisitos e controlar mudanas
e teremos um breve olhar sobre como as metodologias geis de desenvolvimento de
software tratam as atividades da engenharia de requisitos.
Vamos comear nossos estudos?
Boa leitura!
SUMRIO

UNIDADE I

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE


SOFTWARE

13 Introduo

14 Engenharia de Requisitos no Contexto da Engenharia de Software

16 Processo de Software 

20 Modelo de Processo de Software

21 Atividades Fundamentais do Processo de Software

23 Importncia da Engenharia de Requisitos no Processo de 


Desenvolvimento de Software

27 Consideraes Finais

UNIDADE II

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS

35 Introduo

36 Conceitos Fundamentais da Engenharia de Requisitos

37 Stakeholders

40 Classificao dos Requisitos

48 Documentao dos Requisitos de Software

53 Matriz de Rastreabilidade de Requisitos

54 Template da Matriz de Rastreabilidade de Requisitos

56 Consideraes Finais
09
SUMRIO

UNIDADE III

PROCESSOS DA ENGENHARIA DE REQUISITOS

67 Introduo

68 Processos da Engenharia de Requisitos

69 Levantamento e Anlise de Requisitos

88 Negociao

90 Validao dos Requisitos

94 Especificao de Requisitos

105 Consideraes Finais

UNIDADE IV

GESTO DE REQUISITOS

115 Introduo

116 Evoluo dos Requisitos

118 Rastreabilidade

123 Controle de Mudanas 

127 Consideraes Finais


SUMRIO

UNIDADE V

REQUISITOS NAS METODOLOGIAS GEIS

135 Introduo

136 Requisitos nas Metodologias geis

137 Manifesto gil 

140 SCRUM 

143 Especificao de Requisitos geis

146 Consideraes Finais

151 Concluso
153 Referncias
158 Gabarito
Professora Me. Vanessa Ravazzi Perseguine

I
ENGENHARIA DE REQUISITOS

UNIDADE
NO CONTEXTO DA
ENGENHARIA DE SOFTWARE

Objetivos de Aprendizagem
Apresentar conceitos bsicos da engenharia de software.
Contextualizar a engenharia de requisitos no processo de software.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Engenharia de requisitos no contexto da engenharia de software
Processo de software
Modelo de processo de software
Atividades fundamentais do processo de software
Importncia da engenharia de requisitos no processo de
desenvolvimento de software
13

INTRODUO

Ol, caro(a) aluno(a)! Comeamos nossos estudos apresentando a engenharia


de requisitos no contexto da engenharia de software. Nesta unidade, revisitare-
mos alguns conceitos importantes, necessrios para a compreenso dos objetivos
da engenharia de requisitos.
Passaremos pelo software que se tornou elemento fundamental no mer-
cado atual, a ponto de se tornar uma espcie de carteira de investimento para
os empresrios (Gesto de Ativos de Software) e finalizaremos com o entendi-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mento dos processos fundamentais envolvidos nas atividades de desenvolvimento


de software.
A Engenharia de Software envolve um conjunto de etapas que inclui mto-
dos, ferramentas e procedimentos que possibilitam o controle do processo de
desenvolvimento de software, ocupando-se de todos os aspectos, desde os estgios
iniciais de especificao do sistema at sua manuteno (evoluo). A Engenharia
de Requisitos uma espcie de subrea da Engenharia de Software, com o obje-
tivo principal de obter um Documento de Requisitos correto e completo.
Ouso afirmar, concordando com vrios estudiosos da rea, que engenha-
ria de requisitos a disciplina do ciclo de vida do desenvolvimento de software
que tem influncia direta, ou uma das mais diretas, sobre o sucesso ou fracasso
de qualquer projeto.
A incluso de tcnicas maduras e comprovadas de gesto de requisitos ofe-
rece, dentre outros benefcios, o aumento da satisfao do usurio, que o
principal indicador de qualidade do sistema, e, tambm, a reduo de custos na
construo e manuteno de um sistema. Se os requisitos forem bem definidos
e gerenciados, existe uma real garantia de que o sistema atingir seu objetivo em
uma primeira tentativa, o que garante uma reduo do custo total do sistema.
Assim, nosso objetivo nesta unidade entender a base da engenharia de
requisitos, conhecendo os processos que a sustentam. Vamos l!?

Introduo
14 UNIDADE I

ENGENHARIA DE REQUISITOS NO CONTEXTO DA


ENGENHARIA DE SOFTWARE

Para entendermos a importncia da engenharia de requisitos durante a


definio de um software, necessrio identificar onde ela se encaixa no
contexto da engenharia de software. Vamos refrescar a memria e contextu-
alizar a engenharia de requisitos, relembrando rapidamente alguns conceitos
fundamentais?
Primeiro, a partir da informtica bsica, o que software? Fcil! Imediatamente

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
nos vem memria: conjunto de instrues; parte lgica; programas para
computador; sistemas que controlam o funcionamento de um computador.
Perfeito! Mantenha isso em mente.
Agora, da base do nosso curso, como voc define engenharia de software?
Quando penso em engenharia de software, lembro-me de ferramentas; pro-
cesso; sistematizao; controle; metodologia. A IEEE Standard 24765-2010,
define engenharia de software como a aplicao de uma abordagem sistemtica,
disciplinada e quantificvel para o desenvolvimento, operao e manuteno de
software.
Correlacionando, temos, ento, que software um conjunto de instrues
a ser executado por um computador, e engenharia de software a abordagem
sistemtica que envolver todos os aspectos de desenvolvimento do software:
o projeto, a anlise e a construo do software para algum objetivo especfico.
Aprofundando um pouco, para Pressman (2010), essa abordagem sistem-
tica a que me referi acima pode ser vista como uma tecnologia em camadas,
conforme mostra a figura 1.

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


15

Foco na
Qualidade

Processos

Mtodos
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Ferramentas

Figura 1: Engenharia de software em camadas


Fonte: adaptada de Pressman (2010).

Podemos assumir que a busca pela qualidade deve ser a base para todas as fases
e atividades do processo de desenvolvimento do software, isto , devemos man-
ter Foco na Qualidade. Na camada Mtodos, Pressman (2010) explica que
esto os detalhes de como fazer para construir o software1 e, como est acima
do processo, pode ser interpretada como uma camada de suporte, pois apoia as
atividades de desenvolvimento, sistematizando-as e mensurando-as, de forma a
garantir a manuteno da qualidade. A ltima camada, Ferramentas, no topo,
garante apoio automatizado aos mtodos. So as ferramentas computacionais,
eletrnicas, ou outras que permitem automatizao das atividades previstas pelo
Processo e definidas no Mtodo.
No modelo de engenharia de software de Pressman (2010), apresentado

1 Neste ponto, importante observar que existem mtodos para as diferentes atividades do processo
de desenvolvimento de software, por exemplo, as atividades da fase da especificao de software tero
mtodos diferentes dos das atividades da fase de projeto de software, que sero ainda diferentes das
atividades dos mtodos da fase de validao de software e assim por diante, vocs estudaro cada fase do
processo de software como disciplinas do curso.

Engenharia de Requisitos no Contexto da Engenharia de Software


16 UNIDADE I

na Figura 2, o Processo se destaca como o elemento principal, responsvel por


definir a estrutura geral para o controle gerencial do desenvolvimento do sof-
tware. a camada processo que vai embasar e contextualizar quais mtodos e
ferramentas sero aplicados para o desenvolvimento de determinado produto
de software, isto , quais sero os produtos de trabalho, quais marcos sero
definidos, como gerir as modificaes propostas e se a qualidade est sendo
mantida. Na camada processo, estabelecido o Projeto de Desenvolvimento
do Software.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Ferramentas
Mtodos

Figura 2: Engenharia de Software em Camadas


Fonte: adaptada de Roger S. Pressman (2010).

PROCESSO DE SOFTWARE

Percebemos que, tanto para o IEEE quanto para Pressman (2010), to importante
quanto o produto de software que produzido a forma como ele produzido. A
proposta das disciplinas da engenharia de software nos habilitar para a criao
de softwares com qualidade e que sigam as especificaes de oramento e pra-
zos. Como? Por meio de processos adaptveis que tm como propsitos tornar
gil o desenvolvimento, atender s particularidades de cada projeto e, principal-
mente, alcanar a satisfao do cliente.

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


17

Por que, mesmo tendo disponveis tcnicas, metodologias testadas e ferra-


mentas automatizadas, ainda existem tantos projetos de desenvolvimento
de software fracassados?
Fonte: o autor.

Ento, a produo de um software bem-sucedido assumindo somente trs


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

critrios: 1. cumpriu oramento; 2. cumpriu prazo; 3. atendeu s expectativas do


cliente d-se por meio do estabelecimento bem definido do processo de software.
Agora, pergunto: o que voc entende por processo? Deixe de lado, por
enquanto, seu aspecto tcnico, vamos pensar na palavra processo de forma geral.
Se abrirmos um browser para Internet, digitarmos na caixa de pesquisa defina
processo, e, se voc optou pela ferramenta de pesquisa mais popular, sero apre-
sentadas duas definies antes mesmo da apresentao da lista de links com os
resultados encontrados2:

processo
substantivo masculino
1.
ao continuada, realizao contnua e prolongada de alguma atividade; segui-
mento, curso, decurso.
2.
sequncia contnua de fatos ou operaes que apresentam certa unidade ou
que se reproduzem com certa regularidade; andamento, desenvolvimento,
marcha.

Analisando essas definies, de forma geral, ambas nos remetem a uma atividade
continuada, concorda? Faz-nos pensar em algo desenvolvido passo a passo. A
seguir, vamos observar a definio que um dicionrio nos apresenta sobre o tema.

2 Resultado da busca pelo termo defina processo no Google.

Processo de Software
18 UNIDADE I

O Aurlio3 define:

Significado de Processo
1. Mtodo, sistema, modo de fazer uma coisa.
2. Conjunto de manipulaes para obter um resultado.
3. O conjunto dos papis relativos a um negcio.
4. Conjunto dos autos e mais documentos escritos numa causa cvel ou
criminal.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
5. Processamento.
6. Seguimento, decurso.
7. Marcha das fases normais ou mrbidas dos fenmenos orgnicos.
8. Demanda, ao.
9. Processo sumrio: aquele que, em ateno brevidade, dispensa certas
formalidades.

Deixando de lado os significados que fogem ao nosso contexto, como o ter-


ceiro e o quarto, o dicionrio nos apresenta processo como uma abordagem,
uma forma adotada para se desenvolver algo.
Vamos consolidar? Processo , ento, uma atividade organizada em etapas
especficas a serem desenvolvidas de forma contnua, que mantenha uma uni-
dade, a fim de alcanar um propsito final.
Considerando que o nosso propsito final o software (enquanto produto
a ser desenvolvido) e de posse da nossa prpria definio de processo, fica fcil
concordar com Pressman (2010, p. 16) quando nos apresenta o processo de sof-
tware como um arcabouo para as tarefas que so necessrias para construir
softwares de alta qualidade.

3 Dicionrio Aurlio (online).

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


19

O conceito de Engenharia de Software surgiu na conferncia da OTAN sobre


Engenharia de Software (NATO Software Engineering Conference), em Gar-
misch, Alemanha, organizada a fim de propor solues para o que ficou histo-
ricamente conhecido como Crise de Software no final da dcada de sessenta.
Hoje, mais de cinquenta anos depois da Crise do Software, percebemos que a
grande maioria das empresas e dos profissionais de desenvolvimento de sof-
tware ainda no consegue sucesso em seus projetos. Guinther de Bitencourt
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Pauli afirma em seu artigo que o problema que as abordagens tradicionais


de engenharia de software ainda se baseiam em outros ramos de engenharia,
como a civil e mecnica, onde os custos com planejamento so menores.
Aprofunde seu conhecimento lendo o artigo disponvel em:
<http://www.ancibe.com.br/artigos%20de%20si/artigo%20-%20Suces-
sos%20em%20projetos%20de%20informatica%C3%A7%C3%A3o.pdf>.
Acesso em: 29 abr. 2015.
Fonte: o autor.

timo! Vamos juntar tudo?


O processo de software um conjunto de atividades que nos orienta durante
o desenvolvimento do software. Um processo ir determinar as responsabilida-
des de cada um dos envolvidos, o prazo e quais ferramentas sero utilizadas.
Existem inmeras propostas e sugestes para modelos de processo de sof-
twares, todas baseadas em experincias bem ou malsucedidas. No existe um
processo ideal, o que a literatura prope so boas prticas que podem ser adap-
tadas para cada empresa ou profissional e, ainda assim, dentro da mesma empresa,
para cada projeto, deve ser estabelecido seu prprio processo, considerando suas
exigncias e realidade comercial. Essas propostas so conhecidas como modelo
de processo de software. Um processo de software pode ser visto como um con-
junto de atividades organizadas e utilizadas para definir, desenvolver, testar e
manter um software. Existem vrias propostas de modelos de processo de sof-
tware, as atividades bsicas comuns entre elas, em geral, so: levantamento de
requisitos; anlise de requisitos; projeto; implementao; testes; implantao.

Processo de Software
20 UNIDADE I

MODELO DE PROCESSO DE SOFTWARE

Um modelo de processo de software um conjunto de mtodos e ferramentas


orientados para auxiliar no planejamento, desenvolvimento, controle e manu-
teno de um software.
Os modelos de processos de software foram sendo desenvolvidos aos poucos,
conforme os especialistas esbarravam em um problema e analisavam a melhor
forma de resolv-lo, assim, tambm foram sendo desenvolvidas suas atualiza-
es, conforme a evoluo do mercado de desenvolvimento de software.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Se recorrermos a uma pesquisa bsica, na Internet mesmo, encontraremos
vrios modelos de processo de software propostos: linear (famoso cascata); incre-
mental; orientada a reuso; baseado em componentes, espiral, processo unificado
(quem nunca ouviu falar do RUP?); os, atualmente, mais explorados, os geis:
Scrum, TDD (Test Driven Development), ATDD (Acceptance test-driven develop-
ment), BDD (BDD Behavior driven development), XP (eXtreme Programming).
Enfim, so inmeras as propostas existentes de modelos de processos para desen-
volvimento de software. Qualquer modelo que voc decida estudar, ainda que
possua etapas e mtodos diferentes, perceber que apresenta os mesmos objeti-
vos finais: cumprir o prazo, cumprir o custo, entregar um produto de qualidade
e nico; e, tambm, exige as mesmas condies: pessoas treinadas e motivadas,
processos claros e definidos e ferramentas adequadas.
Na prtica, o que precisamos identificar o processo de software que melhor
se adapte realidade do nosso negcio e que atenda s necessidades de produ-
o do software a ser desenvolvido. Sommerville (2011, p. 19) me apoia nessa
afirmao quando diz que: no existe um processo ideal, a maioria das organi-
zaes desenvolve os prprios processos de desenvolvimento de software.
Importante registrar que existe uma pequena distino entre processo e
modelo de software: o processo de software intrnseco a qualquer novo pro-
jeto de software, pois trata da necessidade de um software ser desenvolvido
de forma completa e que atenda a todas as expectativas do cliente, enquanto o
modelo a forma onde sero trabalhados todos os passos para atingir os obje-
tivos de desenvolver software.

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


21

Uma linguagem de modelagem suficiente no processo de desenvolvimen-


to de um software?
Fonte: o autor.

ATIVIDADES FUNDAMENTAIS DO PROCESSO DE


SOFTWARE
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Todo processo de software deve cumprir todas as etapas que foram estabelecidas
para ele, ainda que voc desenvolva o seu prprio modelo. Voc deve estar se pergun-
tando: que etapas so essas? As etapas so as atividades estabelecidas em conjunto
com sua equipe de trabalho e que sero tratadas em cada uma das fases do processo.
Pressman (2010, p. 18) diz que
um arcabouo de processo estabelece o alicerce para um processo de
software completo pela identificao de um pequeno nmero de ativi-
dades aplicveis a todos os projetos de software, independentemente de
seu tamanho ou complexidade.

Sommerville (2011) considera as seguintes atividades como fundamentais para


a engenharia de software: especificao de software; projeto de software; valida-
o de software; e evoluo de software.
Especificao de software: define a funcionalidade do software e as res-
tries sobre sua operao.
Projeto de software: define as funcionalidades que devero ser desenvolvidas
para que se obtenha como produto final o software especificado pelo cliente.
Validao de software: o software deve ser validado para garantir que faa
o que o cliente deseja.
Evoluo de software: o software deve evoluir para atender aos novos
requisitos que, naturalmente, surgiro.
O software um produto resultante de uma atividade cognitiva. A cognio est
diretamente relacionada com fatores diversos, como o pensamento, a linguagem,

Atividades Fundamentais do Processo de Software


22 UNIDADE I

a percepo, a memria e o raciocnio, que fazem parte do desenvolvimento inte-


lectual. Considerando que a atividade de desenvolver um software intelectual,
ela, ento, tambm pode ser classificada como de natureza artstica, isto , depende
de pessoas para ser realizada. Portanto desenvolver um software um processo
complexo, intelectual e criativo que apresenta, para cada requisito, diferentes pro-
postas de soluo e que dependem de pessoas, com diferentes intelectos, para criar
e decidir a melhor soluo para os problemas apresentados. Nesse contexto, um
Processo de Software bem definido garante sistematizao, regras, prazos, ferra-
mentas e outros procedimentos padronizados que auxiliam as pessoas envolvidas

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
na aplicao do seu intelecto para a produo das aes desejadas para o produto.
Um processo de software deve estabelecer atividades que envolvam todos os
aspectos do desenvolvimento, desde a concepo do sistema, ou seja, sua ideia,
at suas excees, aquilo que no ser resolvido pelo software, suas funcionali-
dades, quais so as responsabilidades e objetivos do produto a ser desenvolvido.
Devem estar definidas as atividades de modelagem do software, em que ser
feita a interpretao dos requisitos para a produo de uma descrio de todos
os componentes que sero necessrios para a codificao do software. Acima,
denominamos essa fase de projeto de software, projeto aqui, nessa fase, pode ser
interpretado como arquitetural, em que tcnicas e/ou ferramentas de modela-
gem sero utilizadas para produzir a descrio da arquitetura do produto a ser
desenvolvido, definio dos mdulos e seus relacionamentos, definio da inter-
face, como ser a interao do produto com o usurio, e organizado, de forma
a ser entendvel tanto para o cliente quanto para a equipe de desenvolvimento.
Riscos, custos, prazos podem ser definidos nessa fase tambm.
As atividades de codificao so as prximas a serem contempladas no pro-
cesso de software em que sero estabelecidas as iteraes e interaes, se sero
feitos testes nessa fase, como sero tratados os impedimentos e como ser exe-
cutada a validao do software, por pacotes, ou depois de o produto pronto, ou,
ainda, como uma fase anterior codificao. O processo de software deve con-
siderar, tambm, manuteno do produto desenvolvido, em que, praticamente,
todas as fases anteriores so abrangidas quando determinado o ciclo de manu-
teno. Vale registrar aqui que todas essas informaes devem ser consideradas
pelo modelo de processo de software, e todas as atividades esto vinculadas ao

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


23

desenvolvimento do produto final, qual ordem execut-las e quais atividades


acrescentar variam para cada modelo de processo de software.
O objetivo desta disciplina aprofundar o conhecimento na atividade de
especificao de software, tambm conhecida como engenharia de requisitos,
as demais atividades do processo de software sero trabalhadas, em momento
oportuno, por outras disciplinas.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

IMPORTNCIA DA ENGENHARIA DE REQUISITOS NO


PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

A Figura 3 um clssico na
rea do desenvolvimento de
software. Ela demonstra exata-
mente o que acontece durante
o processo de levantamento
de informaes sobre um
produto a ser desenvolvido
e podemos abstra-la para a
engenharia de requisitos.
No tpico anterior, fala-
mos, brevemente, sobre a
conferncia organizada para Figura 3: Processo de comunicao durante o desenvolvimento de projeto.
Fonte: Corazzin (online).
tratar dos assuntos relaciona-
dos ao desenvolvimento de software, que ficou conhecida como Crise do Software.
A conferncia, que aconteceu em 1968, foi organizada para tratar de assuntos
como a complexidade dos problemas do desenvolvimento do software, a ausn-
cia de tcnicas bem estabelecidas e a crescente demanda por novas aplicaes e
teve como objetivo estabelecer prticas mais maduras para o processo de desen-
volvimento. As causas da crise do software esto ligadas complexidade do
processo de software e falta de metodologias para trat-las durante o processo
de desenvolvimento, o que promovia, principalmente, os seguintes problemas:

Importncia da Engenharia de Requisitos no Processo de Desenvolvimento de Software


24 UNIDADE I

Projetos estourando o oramento.


Projetos estourando o prazo.
Software de baixa qualidade.
Softwares, muitas vezes, no atingiam os requisitos.
Projetos no gerenciveis.
Cdigo difcil de manter.

Levanto novamente este assunto para propor uma analogia entre o cenrio de

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
desenvolvimento de software em 1968 e o atual. O que mudou?
Negativamente, percebemos que todas as conquistas citadas acima e mais cin-
quenta anos de experincia no desenvolvimento de software no bastaram para
melhorar efetivamente a qualidade do software. O pmsurvey.org publica, anual-
mente, uma pesquisa promovida e organizada pelo Project Management Institute,
que conta com a participao de centenas de organizaes no mundo. Os resultados
da pesquisa de 2012 mostram que cerca de 60% das organizaes tm cumprido
as metas dos fatores crticos de sucesso, conforme indicado na tabela a seguir.

FATORES CRTICOS DE SUCESSO EM PROJETOS


1. Problemas de comunicao. 10. Estimativas incorretas ou sem fundamento.
2. No cumprimento de prazos. 11. Problemas com fornecedores.
12. Retrabalho em funo da falta de qualidade do
3. Escopo no definido adequadamente.
produto.
4. Mudanas de escopo constantes. 13. Falta de definio de responsabilidades.
14. Falta de apoio na alta administrao/patrocina-
5. Recursos humanos insuficientes.
dor.
6. Riscos no avaliados corretamente. 15. Falta de competncia para gerenciar projetos
7. Concorrncias entre o dia a dia e o
16. Falta de uma metodologia de apoio.
projeto na utilizao dos recursos.
8. Mudanas de prioridade constantes
17. Falta de uma ferramenta de apoio.
ou falta de prioridade.
9. No cumprimento do oramento
18. Clientes no satisfeitos.
estabelecido.
Tabela 1: Fatores Crticos de Sucesso em Projetos
Fonte: Pmsurvey.org (2012).

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


25

O The Standish Group publica, a cada dois anos, uma pesquisa chamada
Chaos Report, que aponta o percentual de projetos, na rea de TI, que alcanam
sucesso, dficit (atraso/prejuzo) ou fracasso. O relatrio de 2013 aponta que ape-
nas 39% dos projetos de TI no mundo alcanam sucesso.
Positivamente, vrios modelos de processo de desenvolvimento de software
foram propostos, vrias ferramentas para automao das atividades do pro-
cesso foram criadas. Artefatos de gerenciamento de projeto de software foram
propostos. A gesto de projetos j h algum tempo vem conquistando espao
estratgico nas organizaes, como comprovado pelos estudos promovidos pelo
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Project Management Institute Brasil (PMI), entidade internacional que regula-


menta os profissionais do setor.
Temos, ainda, nesse intervalo, o manifesto gil, uma reunio de dezessete pes-
soas em 2001, no The Lodge at Snowbird Resort, que resultou no Manifesto para o
desenvolvimento gil de Software, o qual estudaremos mais a fundo na unidade V,
e, finalmente, o cenrio da crescente adoo de modelos de maturidade, como MPS.
BR (Melhoria do Processo de Software Brasileiro), da SOFTEX, e CMMI (Capability
Maturity Model Integration), da SEI, um indicador de que as empresas nacio-
nais esto se preocupando com a qualidade dos produtos e servios que oferecem.
Toda essa conversa foi necessria para dar suporte afirmao que farei a
seguir: o principal causador de falhas dos projetos de software so falhas no pro-
cesso de Engenharia de Requisitos.
Considere comigo: tudo especificao, projeto, modelagem, programao,
testes, implantao, manuteno - parte do entendimento e da determinao de
o que se pretende fazer. O descompromisso com essa determinao causa incre-
mentos no desejados, como: atrasos no cronograma, custos acima do previsto,
falta de recursos humanos, alterao dos requisitos, alterao das especificaes,
flexibilizao comprometedora do escopo, qualidade abaixo da esperada, frus-
trao do cliente e outros tantos problemas.
Outro recurso que utilizo para ilustrar a importncia da Engenharia de
Requisitos no processo de desenvolvimento de software so os estudos pro-
movidos pelo Standish Group. Eles mostram que o alto ndice de manuteno,
retrabalho em nvel de requisitos, projeto, codificao, testes causado por falhas
de definio nas fases iniciais do processo de desenvolvimento.

Importncia da Engenharia de Requisitos no Processo de Desenvolvimento de Software


26 UNIDADE I

% DO CUSTO DE % DOS ERROS % DOS ERROS CUSTO RELATIVO


DESENVOLVIMENTO INTRODUZIDOS ENCONTRADOS DE CORREO
Anlise de
5 55 18 1
Requisitos
Projeto 25 30 10 1 ~ 1,5
Codificao e
50
teste de unidade
Teste 10 10 50 1~5
Validao e do-
10
cumentao
manuteno 5 22 10 ~ 100

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Tabela 2: Levantamento de custos com erros nas fases de projetos de software
Fonte: Standish Group CHAOS Report 2013 on software project success and failure.

O que a Tabela 2 nos aponta , primeiramente, que os custos relacionados anlise


de requisitos so baixos, nessa fase, a maioria dos erros apresentada. Observe que,
se os erros apresentados fossem corrigidos nessa fase, os custos de correo ficariam
baixssimos, enquanto, se deixarmos para corrigi-los depois da validao, l na fase
da manuteno (ltima linha da tabela), os custos aumentariam exorbitantemente.
O mesmo estudo apresenta fatores crticos para o sucesso dos projetos de
software. Os dez mais lembrados esto relacionados na tabela a seguir. Observe
que trs principais fatores para o sucesso esto relacionados s atividades da
Engenharia de Requisitos: requisitos incompletos, falta de envolvimento do usu-
rio, mudana de requisitos e especificaes.

FATORES CRTICOS PARA O SUCESSO DE PROJETOS DE SOFTWARE


Fatores Porcentagem
Requisitos Incompletos 13,1
Falta de Envolvimento do Usurio 12,4
Falta de Recursos 10,6
Expectativas Irreais 9,9
Falta de apoio Executivo 9,3
Mudana de Requisitos e Especificaes 8,7
Falta de Planejamento 8,1
Sistema no mais necessrio 7,5
Tabela 3: Fatores Crticos para o Sucesso de Projetos de Software
Fonte: Standish Group CHAOS Report 2013 on software project success and failure.

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


27

Ser que alcancei meu objetivo de convenc-lo sobre a importncia da


Engenharia de Requisitos no processo de produo de um software? palpvel
que o trabalho mais criterioso na fase inicial do processo de software garante o
sucesso de todo o projeto.
Encerro o assunto citando Pressman (2010, p. 117): engenharia de requisi-
tos estabelece uma base slida para o projeto e a construo. Sem ela o software
resultante tem uma alta probabilidade de no satisfazer as necessidades do cliente.
Isto , o entendimento do o que fazer para sua catalogao e modelagem efi-
ciente representar a real necessidade do cliente, que se trata do ponto-chave
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

para a qualidade do software.

H mais de quarenta anos, a engenharia de software nos apresenta a im-


portncia da fase de levantamento e anlise dos requisitos, para o desen-
volvimento de software, pesquisas renomadas comprovam que um levan-
tamento mal executado a principal causa dos estouros nos projetos de
desenvolvimento de software, porque, ainda hoje, enfrentamos esses mes-
mos problemas?
Fonte: Galeote (online).

CONSIDERAES FINAIS

Nesta unidade, revisamos alguns conceitos bsicos que voc, talvez, j tenha
conhecido na sua formao. Este nivelamento foi necessrio para podermos situar
a engenharia de requisitos nas atividades da engenharia de software.
Definimos que a engenharia de software uma abordagem sistemtica que
envolver todos os aspectos de desenvolvimento do software: o projeto, a anlise
e a construo do software para algum objetivo especfico. Formulamos, juntos,
a definio de processo como uma atividade organizada em etapas especficas a
serem desenvolvidas de forma contnua, que mantenha uma unidade, a fim de
alcanar um propsito final, que um produto de software de qualidade. Sendo

Consideraes Finais
28 UNIDADE I

assim, o processo de software representa um conjunto de atividades que nos


orienta durante o desenvolvimento do software.
O CMMI (Capability Maturity Model Integration) um modelo de capa-
citao de processos de software, desenvolvido pelo SEI (Software Engineering
Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a
avaliao da capacidade das fbricas de software de repetir uma srie de resulta-
dos de uma maneira previsvel e com qualidade. Como profissionais da rea de
desenvolvimento de software, muito importante entender como os conceitos
se encaixam na prtica, o que o CMMI e outros modelos de maturidade bus-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
cam avaliar a qualidade de gesto de processos das empresas desenvolvedoras
de software, ento, percebemos que, para produzir um produto de qualidade,
dependemos da qualidade de seu processo de desenvolvimento, que est inti-
mamente ligado com o processo da engenharia de requisitos.
Lembre-se de que no existe um processo ideal, deve ser estabelecido um
conjunto de atividades especficas para cada projeto e, ainda que dentro de uma
mesma empresa, para cada projeto, deve ser estabelecido seu prprio processo,
considerando suas exigncias e realidade comercial.

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE


29

1. A definio a abordagem sistemtica que envolver todos os aspectos de de-


senvolvimento do software: o projeto, a anlise e a construo do software para
algum objetivo especfico diz respeito a:
a. Processo de software.
b. Engenharia de software.
c. Software.
d. Engenharia de requisitos.

2. Assinale a alternativa correta sobre Processo de Software:


I. Conjunto de atividades bem definidas, com responsveis, com artefatos de
entrada e sada, com dependncias entre elas e ordem de execuo, com mo-
delo de ciclo de vida.
II. Conjunto parcialmente ordenado de atividades (ou passos) para se atingir um
objetivo, definindo quem est fazendo o que, quando e como para atingir um
certo objetivo.
III. O processo de software um conjunto de atividades que nos orienta durante
o desenvolvimento do software. Um processo ir determinar as responsabili-
dades de cada um dos envolvidos, o prazo e quais ferramentas sero utiliza-
das.
a. Apenas I est correta.
b. Apenas II est correta.
c. Apenas III esto corretas.
d. I, II e III esto corretas.

3. Um modelo de processo de software um conjunto de mtodos e ferramentas


orientados para auxiliar no planejamento, desenvolvimento, controle e manu-
teno de um software. Sobre modelo de processo de software, analise as alter-
nativas abaixo:
I. No existe um processo ideal, a maioria das organizaes desenvolve os pr-
prios processos de desenvolvimento de software.
II. Um modelo de processo de software uma descrio simplificada do proces-
so de desenvolvimento de software.
III. Os modelos de processo de software incluem as atividades, que fazem parte
do processo de desenvolvimento de software.
a. Apenas I est correta.
b. Apenas I e III esto corretas.
c. Apenas II e III esto corretas.
d. I, II e III esto corretas

4. Um arcabouo de processo estabelece o alicerce para um processo de software


completo pela identificao de um pequeno nmero de atividades aplicveis a
todos os projetos de software, independentemente de seu tamanho ou com-
plexidade. Essa a definio de Pressman (2010) para Processo de Software. Em
relao a Processo de Software, qual alternativa abaixo est correta?
a. A atividade especificao de software: define as funcionalidades que devero
ser desenvolvidas para que se obtenha como produto final o software espe-
cificado pelo cliente.
b. A atividade de projeto de software: define a funcionalidade do software e as
restries sobre sua operao.
c. A atividade de validao de software: o software deve ser reescrito e mantido
para garantir que faa o que o cliente deseja.
d. Evoluo de software: o software deve evoluir para atender aos novos requi-
sitos que, naturalmente, surgiro.

5. Os estudos promovidos pelo Standish Group mostram que o alto ndice de ma-
nuteno, retrabalho em nvel de requisitos, projeto, codificao, testes cau-
sado por falhas de definio nas fases iniciais do processo de desenvolvimento.
Selecione a alternativa que relaciona uma atividade inicial, em um processo de
software:
a. Levantamento de requisitos.
b. Teste de software.
c. Programao.
d. Implantao.
31

DESENVOLVIMENTO DE SOFTWARE REQUER PROCESSO DE GESTAO.

Software, de modo genrico, uma enti- e aplicaes Web, dentre tantas. Paralela-
dade que se encontra em quase constante mente, observou-se o surgimento de vrias
estado de mudana. Essas mudanas ocor- tcnicas de modelagem e projeto bem
rem por necessidade de corrigir erros como de linguagens de programao. Per-
existentes no software e/ou de adicionar ceba que o cenrio existente, dcadas atrs,
novos recursos e funcionalidades. Igual- mudou completamente. Antigamente, os
mente, os sistemas computacionais (isto projetos de sistemas alocavam pequena
, aqueles que tm software como um de parcela ao software. Os componentes de
seus principais elementos) tambm sofrem hardware, diferentemente, eram analisa-
mudanas freqentemente. Essa necessi- dos e testados quase exaustivamente o
dade evolutiva do sistema de software o que permitia a produo rpida de grandes
torna predisposto a defeitos (isto no quantidades de subsistemas e implicava
confivel), podendo resultar em atraso na em raros erros de projetos. Entretanto, a
entrega e em custos acima do estimado. facilidade inicial de modificar o software,
Concomitante com esses fatos, o cresci- comparativamente ao hardware, motivou
mento em tamanho e complexidade dos seu uso. A intensificao do uso do software
sistemas de software exige que os pro- numa larga variedade de aplicaes o fez
fissionais da rea raciocinem, projetem, crescer em tamanho e complexidade. Isto
codifiquem e se comuniquem por meio de tornou proibitivo analisar e testar exaus-
componentes (de software) e qualquer con- tivamente, alm de impactar no custo de
cepo ou soluo de sistema passa ento manuteno.
para o nvel arquitetural. Nesse sentido, o
objetivo deste artigo discutir e explorar o Perceba que medida que tamanho e
fato de que software no construdo como complexidade dos sistemas de software
uma TV ou geladeira, mas desenvolvido. aumentam, o problema de projeto extra-
pola as estruturas de dados e algoritmos
Quase cinco dcadas atrs software consti- de computao. Ou seja, h necessidade
tua uma insignificante parte dos sistemas de considerar o projeto da arquitetura (ou
existentes e seu custo de desenvolvimento estrutura geral) do sistema, exigindo tam-
e manuteno eram desprezveis. Para per- bm um processo de desenvolvimento de
ceber isso, basta olharmos para histria da software. O ciclo de vida de um produto
indstria do software (www.softwarehis- compreende um conjunto de atividades
tory.org). Encontra-se o uso do software que vai desde sua concepo at a entrega
numa ampla variedade de aplicaes tais desse produto ao cliente, envolvendo ainda
como sistemas de manufatura, software sua evoluo e, eventualmente, retirada
cientfico, software embarcado, robtica desse produto.
Fonte: Filho (2011, online).
MATERIAL COMPLEMENTAR

Engenharia de Software - Uma Abordagem Profissional


Roger S. Pressman
Editora: Bookman
Sinopse: Verso concebida tanto para alunos de graduao quanto para
profissionais da rea. Oferece uma abordagem contempornea sobre
produo do software, gesto da qualidade, gerenciamento de projetos,
com didtica eficiente e exerccios de grande aplicao prtica.
Professora Me. Vanessa Ravazzi Perseguine

II
FUNDAMENTOS DA

UNIDADE
ENGENHARIA DE
REQUISITOS

Objetivos de Aprendizagem
Conhecer os fundamentos da engenharia de requisitos e definir seus
principais artefatos de sada.
Entender a importncia da engenharia de requisitos no contexto de
desenvolvimento de software.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Conceitos fundamentais da engenharia de requisitos
Stakeholders
Classificao dos requisitos
Documentao dos requisitos de software
Template documento de requisitos
Matriz de rastreabilidade de requisitos
Template matriz de rastreabilidade de requisitos
35

INTRODUO

Ol! Vamos para mais uma unidade de estudos? Avanando em nosso aprendi-
zado, estudaremos os conceitos fundamentais da engenharia de requisitos. No
possvel entender o propsito de uma atividade sem, primeiro, compreender
os elementos que a compem.
O primeiro elemento que devemos dominar seu significado requi-
sitos. Todo nosso curso baseia-se nele. Entender do que se trata e como
ele deve ser tratado crucial para o sucesso da engenharia de requisitos.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Observaremos, no decorrer da unidade, que os requisitos delimitam o sof-


tware, pois estabelecem as funcionalidades e as restries solicitadas por um
conjunto de stakeholders. O processo de especificao e documentao de
requisitos fundamental para o sucesso de um projeto de software e enten-
deremos que um bom documento de requisitos possibilita estimativas de
custos mais precisas, cronogramas mais ajustados e um produto final que
atende s expectativas do cliente.
Outro elemento importante na engenharia de requisitos o stakeholder.
Os requisitos de software so levantados e mapeados por meio da anlise dos
stakeholders. Como cada grupo de stakeholder tem interesses especficos e par-
ticulares, eles podem, ao invs de colaborar, atrapalhar o desenvolvimento do
software, se no forem bem gerenciados. Nesta unidade, conheceremos o que
significa stakeholders e entenderemos o tipo de influncia que eles podem cau-
sar ao projeto de desenvolvimento de software.
O objetivo desta unidade, alm de garantir o conhecimento sobre os prin-
cipais elementos da engenharia de requisitos, assimilar o que foi apresentado
na unidade anterior sobre a importncia da engenharia de requisitos enquanto
principal causadora de falhas dos projetos de software.
Boa leitura!

Introduo
36 UNIDADE II

CONCEITOS FUNDAMENTAIS DA ENGENHARIA DE


REQUISITOS

A engenharia de requisitos, segundo Sommerville (2008), envolve todas as ativida-


des de conceituao, documentao e manuteno de um conjunto de requisitos
para um sistema baseado em computador.
Vamos observar o significado das palavras em separado:
Engenharia1- substantivo feminino: aplicao de mtodos cientficos
ou empricos utilizao dos recursos da natureza em benefcio do ser

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
humano
Requisito2- adjetivo: 1. p.us. que foi requisitado, requerido; 2. substantivo
masculino: condio para se alcanar determinado fim

Juntado os conceitos: engenharia de requisitos pode ser definida, ento, como


conjunto de atividades sistemticas como condio para se alcanar determi-
nado fim, o que se foi requisitado. Nesse sentido, Sommerville (2003, p. 103)
nos positiva com sua definio: engenharia de requisitos um processo que
envolve todas as atividades exigidas para criar e manter o documento de requi-
sitos de sistema.
Conjunto de atividades pode ser entendido como processo, e sobre pro-
cesso, ns entendemos! Assim, o propsito da engenharia de requisitos est
relacionado com a identificao de metas a serem atingidas: qualidade de sof-
tware; produtividade no desenvolvimento, operao e manuteno de software;
permitir que profissionais tenham controle sobre o desenvolvimento de software
dentro de custos, prazos e nveis de qualidade desejados.

1 Resultado da busca pelo termo defina engenharia no Google.


2 Resultado da busca pelo termo defina requisito no Google.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


37

Qualidade de software definida pelo IEEE (The Institute of Electrical and Elec-
tronics Engineers) como o grau com que um sistema, componente ou pro-
cesso atende (1) aos requisitos especificados e (2) s expectativas ou neces-
sidades de clientes ou usurios. Enquanto profissionais de desenvolvimento
de software, carregamos nossos conhecimentos para a aplicao prtica?
Fonte: Sayo, Staa e Leite (2003, p. 9).
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

A ABES Software - Associao Brasileira das Empresas de Software publi-


ca, anualmente, o Estudo do Mercado Brasileiro de Software - Panorama e
Tendncias. Os dados levantados para as publicaes so consolidados por
cinquenta escritrios da IDC - International Data Corporation divididos em
seis regies mundiais.
O relatrio final apresenta com riqueza de detalhes dados sobre os merca-
dos brasileiro e mundial de software, uma ferramenta importante para os
profissionais da rea, uma ferramenta importante para anlise do setor.
O Relatrio disponibilizado sem custos pelo portal da ABES. Vale a pena
visitar e se manter atualizado sobre o seu setor de atuao profissional.
Para saber mais, acesse o link disponvel em: <http://www.abessoftware.
com.br/>. Acesso em: 27 mar. 2015.
Fonte: autor.

STAKEHOLDERS

Vimos que a qualidade de um produto de software est diretamente relacionada


ao atendimento das expectativas do cliente. Sabemos, tambm, que o sucesso de
um projeto est intimamente relacionado administrao de problemas ligados
especificao e gerenciamento dos requisitos do software. Voc percebe o ele-
mento comum nas duas exigncias? Exatamente! Tanto para qualidade quanto

Stakeholders
38 UNIDADE II

para o levantamento dos requisitos, ser necessria a participao do cliente, um


estranho a sua organizao e a voc que dever ser includo, ouvido e interpre-
tado, durante todo o processo de desenvolvimento de software e, principalmente,
na fase da Engenharia de Requisitos.
Esse estranho na rea de projetos reconhecido como Stakeholders. Para o
PMBOK (online), stakeholders so pessoas e organizaes, como clientes, patro-
cinadores, organizaes executoras e o pblico, que estejam ativamente envolvidas
no projeto ou cujos interesses possam ser afetados de forma positiva ou nega-
tiva pela execuo ou trmino do projeto. Podemos resumir stakeholders como

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
qualquer pessoa ou organizao que realiza ou sofre alguma ao do projeto.

A partir da sua terceira edio, o gerenciamento de stakeholders foi abor-


dado pelo Guia PMBOK (guia de prticas na gesto de projetos - Project
Management Body of Knowledge da PMI), por meio da rea de conheci-
mento Gerenciamento das Comunicaes do Projeto, processo Gerenciar
as Partes Interessadas. O enfoque do Guia PMBOK at sua ltima verso foi
a importncia da comunicao entre os envolvidos no projeto, tanto os do
ambiente interno quanto os externos, entretanto, com o desenvolvimento
da rea de projetos, percebeu-se que, para garantir o sucesso de um pro-
jeto, deveria ser definido um mtodo exclusivo para gerenciar os grupos e
relacionamentos que geram resultados estratgicos para os projetos, e o ge-
renciamento de stakeholders subiu de processo para rea de conhecimento.
Isso prova que a interferncia desse elemento influncia diretamente o re-
sultado do projeto.
Para saber mais, acesse os links disponveis em: <https://brasil.pmi.org/>
(PMI no Brasil); <http://www.pmi.org/> (Project Management Institute). Aces-
so em: 8 jul. 2015.
Fonte: o autor.

Enquanto estiver envolvido somente na engenharia de requisitos, voc no ter


que se preocupar com o gerenciamento e controle de todos os stakeholders envol-
vidos no projeto, mas de extrema importncia que execute o levantamento de,

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


39

no mnimo, aqueles que podem influenciar na definio e manuteno dos requi-


sitos que definiro o escopo final do produto. Dificilmente, o usurio final do
seu software ser o contratante ou o patrocinador, por isso sua ateno tem que
estar focada alm deles, para que o produto final atenda s necessidades geren-
ciais e operacionais para as quais foi contratado.
O gerenciamento de identificao dos interessados complexo e pos-
sui metodologias e ferramentas prprias, seria necessria uma disciplina s
para elas. Para garantir que o projeto tenha sucesso, sugiro que, no mnimo,
voc execute as cinco etapas a seguir, mantendo o foco nos interesses que
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

podem influenciar na definio e na manuteno dos requisitos e do escopo


final do produto:
1 Identificar os stakeholders: relacionar todas as pessoas que influenciam
o projeto ou so influenciadas por ele. Mesmo que seja uma organizao
ou grupo, importante identificar as pessoas que o representam.
2 Caracterizar os stakeholders quanto ao que tomam em relao ao
projeto: classificar os stakeholders em quatro grupos, de acordo com a
atitude que tomam em relao ao projeto:
Favorveis: contribuem para o sucesso do projeto. Demonstram inte-
resse e responsabilidade pelo projeto.
Neutros: no possuem influncia e no esto interessados nos resul-
tados do projeto.
Contrrios: acreditam que o projeto prejudica seus interesses. Criam
empecilhos para o andamento do projeto.
Sabotadores: de difcil identificao. Geralmente, espies e concorrentes.

3 Priorizar os Stakeholders: classificar os stakeholders quanto ao inte-


resse e poder (influncia) que eles podem ter sobre o projeto. A partir
dessa classificao, voc determinar como ser sua comunicao com
cada um deles. Essa priorizao pode ser feita construindo uma matriz
estratgica:

Stakeholders
40 UNIDADE II

Grade de poder e interesse


alto

Manter satisfeito Gerenciar de perto

Poder

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Monitorar
Manter informado
(esforo mnimo)

baixo
baixo Interesse positivo alto

Figura 5: Matriz estratgica dos stakholders


Fonte: PMKB (online).

4 Comunicar os stakeholders: importante manter um canal de comu-


nicao com os interessados eleitos. Esse canal pode ser estabelecido por
diversos meios: telefone, e-mail, comunicado, grupo de discusso, relat-
rios etc. Voc define o nvel e a periodicidade das informaes para cada
um. O Importante que, depois de planejado, seja cumprido.
5 Gerenciar os stakeholders: estar atento aos empecilhos que podem preju-
dicar o seu projeto e responder prontamente a cada problema identificado.

CLASSIFICAO DOS REQUISITOS

Vimos que o significado da palavra requisito condio para se alcanar deter-


minado fim, o que seria, ento, um requisito de software?
Sommerville (2008) diz que um requisito uma descrio detalhada de uma
funo do sistema. Requisitos de software j foram considerados sinnimos de fun-
es do sistema, ou seja, tudo que o software deveria fazer era considerado requisito.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


41

Com a evoluo dos softwares e do entendimento da engenharia de siste-


mas, percebeu-se que requisitos so, alm de funes, objetivos, propriedades e
restries que o software deve possuir para satisfazer contratos, padres ou especi-
ficaes. O importante ter em mente que os requisitos de software devem sempre
ser trabalhados para resolver os problemas do cliente e sob o ponto de vista dele.
Mantendo a linha de raciocnio, uma coleo de requisitos de software repre-
senta o produto final negociado entre as partes interessadas e o engenheiro de
requisitos. Concorda? Como montar esse documento ento? Primeiro passo,
temos que entender os tipos de requisitos de software que existem e como eles
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

se classificam.
Existe uma conveno, que vem da literatura clssica, definindo tipos de
requisitos no que diz respeito forma de registro, isto , a maneira como ele ser
escrito no documento e a quem se destina.

TIPO DE REQUISITO
Tipo Requisito Definio A quem se destina
Requisitos de Os requisitos so escritos com alto nvel Gerentes de clientes.
Usurio de abstrao, em linguagem natural, e Usurio final do sistema.
podem conter diagramas simples e re-
Engenheiro do cliente.
presentativos das funcionalidades que o
sistema deve apresentar e das restries Arquiteto do sistema.
que ele deve operar.
Requisitos de O nvel de detalhamento na descrio Usurio final do sistema.
Sistema dos requisitos aumentado. Requisitos Engenheiro do cliente.
do sistema informam, de maneira deta-
Arquiteto do sistema.
lhada, o que o produto final deve fazer.
Pode servir de contrato entre o compra- Desenvolvedor do sof-
dor do sistema e o desenvolvedor. Aqui, tware.
um nico requisito de usurio pode ser
dividido em vrios requisitos do sistema.
Requisitos de Ou especificao de projeto, a definio Engenheiro do cliente.
Projeto do projeto de software em nvel mais Arquiteto do sistema.
tcnico modelagem.
Desenvolvedor do sof-
tware.
Quadro 3: Tipo de Requisitos
Fonte: o autor adaptado de Sommerville (2008) e Pressman (2010).

Classificao dos Requisitos


42 UNIDADE II

Nessa abordagem, os autores orientam a escrita de documentos separados


para os usurios finais e para os desenvolvedores. Em qualquer prova de con-
curso, ou abordagem terica, exatamente isso que voc deve responder, mas,
na prtica, o desenvolvimento de um nico documento que seja claro, conciso
e que contenha as especificaes tanto para as necessidades dos usurios quanto
dos desenvolvedores o suficiente e mais eficiente.
Alm dos tipos, os requisitos so classificados em requisitos funcionais,
requisitos no funcionais e requisitos de domnio.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
CLASSIFICAO DE REQUISITOS
Classificao Definio Exemplos
Requisitos Fun- So os requisitos diretamente ligados Requisitos de entrada: o Sistema
cionais funcionalidade do software, descrevem deve cadastrar mdicos profissio-
as funes que o software deve execu- nais.
tar. Os requisitos funcionais podem ser Requisito de sada: o Sistema deve
interpretados como um conjunto de emitir um relatrio de clientes.
entradas, processamento e sada. Repre-
Requisito de mudana de estado:
sentam clculos, lgicas e as funciona-
O Sistema deve passar um cliente
lidades especficas que definem o que
da situao em consulta para
o software ir realizar. O implemento
consultado, quando o cliente
destes requisitos caracteriza um sistema.
terminar de ser atendido.
Requisitos no So os requisitos que expressam as con- Controle de acesso somente para
funcionais dies ou especialidades que o software pessoas autorizadas.
deve atender. So as restries a serem Tempo de resposta limitado em
impostas relacionadas a desempenho, vinte segundos.
segurana, usabilidade, portabilidade,
facilidade de uso, eficincia etc.
Requisito de So aqueles derivados do domnio da Clculo de impostos ou taxas
domnio aplicao, ou seja, da especialidade onde especficas:
o software ser implantado e, tambm, rea de RH possui incrementos
do prprio software, que refletem nele. e descontos especficos do seu
Podem ser novos requisitos funcionais, domnio frias, horas extras etc.
ou restries sobre requisitos existentes,
rea tributria, clculos e porcenta-
ou clculos especficos. Esses requisitos
gens especficas que so inerentes
so expressos com o uso de uma lingua-
a sua aplicao IPTU, ISS etc.
gem especfica do domnio da aplicao
e, geralmente, de difcil compreenso rea comercial,exige clculos
para os engenheiros de software. que s dizem respeito a sua es-
pecialidade PIS, COFINS etc.
Quadro 4: Classificao de requisitos
Fonte: adaptado de Sommerville (2008) e Pressman (2010).

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


43

Sommerville (2008) classifica os requisitos no funcionais em requisitos de


produto, requisitos organizacionais e requisitos externos. Os requisitos de pro-
duto especificam o comportamento do produto e podem ser subdivididos em
requisitos de usabilidade, de eficincia, de confiana e de proteo. Os requisitos
organizacionais so elaborados a partir das polticas e procedimentos da empresa,
do cliente e do desenvolvedor e so subdivididos em requisitos ambientais, ope-
racionais e de desenvolvimento. Por ltimo, os requisitos externos envolvem os
requisitos referentes aos fatores externos ao software e seu processo de desen-
volvimento, que seriam os requisitos reguladores, ticos e legais.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Requisitos
no funcionais

Requisitos Requisitos Requisitos


de produto organizacionais externos

Requisitos de Requisitos de Requisitos de


facilidade de uso entrega interoperabilidade

Requisitos de Requisitos de Requisitos


eficincia implementao legais

Requisitos de Requisitos de Requisitos


portabilidade padres ticos

Requisitos de
confiabilidade Requisitos de Requisitos de
desempenho privacidade

Requisitos de Requisitos de
espao segurana
Figura 6: Requisitos No Funcionais
Fonte: Engenharia de requisitos (online).

Para auxiliar a compreenso, alguns exemplos de requisitos no funcionais e as


classificaes que podem assumir:

Classificao dos Requisitos


44 UNIDADE II

Requisitos da organizao: padres, infraestrutura.


Requisitos externos: interoperabilidade, legislao, localizao
geogrfica.
Requisitos de facilidade de uso: usurios devero operar o sistema aps
um determinado tempo de treinamento.
Requisitos de eficincia: o software dever processar n requisies por
x tempo.
Requisitos de portabilidade: o software deve ser compatvel com qual-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
quer plataforma.
Requisitos de entrega: um relatrio de acompanhamento do desenvolvi-
mento dever ser fornecido toda segunda-feira.
Requisitos de implementao: o software ser programado na lingua-
gem Java.
Requisitos de padres: o software ser implementado com orientao ao
objeto plataforma Java.
Requisitos de interoperabilidade: o software deve estar integrado ao Banco
de dados SQL Server.
Requisitos ticos: o sistema no apresentar aos usurios com acesso nvel
B quaisquer dados do nvel A.
Requisitos legais: o software dever atender s normas legais, tais como
padres, leis etc.
Requisitos de integrao: o software deve ser integrado com outra apli-
cao j existente.

Higor Medeiros (online), em seu artigo Introduo a Requisito de Software,


disponibilizado pela Devmedia, afirma que: os requisitos no funcionais so
geralmente mensurveis e assim devemos preferencialmente associar uma medida
ou referncia para cada requisito no funcional e apresenta uma tabela para ilus-
trar os requisitos funcionais por outra tica.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


45

CLASSIFICAO DE REQUISITOS FUNCIONAIS


Requisito Mtrica
Velocidade Transaes processadas por segundo.
Tempo de resposta ao usurio/evento.
Tempo de atualizao da tela.
Facilidade de uso Tempo de treinamento.
Numero de telas de ajuda.
Confiabilidade Tempo mdio para falhar.
Probabilidade de indisponibilidade.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Taxa de ocorrncia de falhas.


Disponibilidade.
Robustez Tempo de reincio aps falha.
Porcentagem de eventos que causam falhas.
Probabilidade de que os dados sejam corrompi-
dos por falhas.
Portabilidade Porcentagem de declaraes dependentes de
sistema-alvo.
Nmero de sistemas-alvo.
Quadro 5: Classificao de Requisitos Funcionais
Fonte: Medeiros (online).

Perceba que os requisitos no funcionais descrevem as especialidades do


software (como ele ), enquanto os requisitos funcionais relacionam suas fun-
cionalidades (o que ele faz).
Sommerville (2008) classifica como requisitos de domnios aqueles requisitos
que expressam a regra de negcio a ser trabalhada e interpretada pelo software
a ser desenvolvido. Essa interpretao pode ser difcil para os engenheiros de
requisitos, uma vez que no conhecem o ambiente e as prticas envolvidas nos
processos internos do negcio que ir converter em software. Os especialis-
tas do domnio podem, por julgarem bvio, deixarem de fornecer informaes
importantes e como resultado o requisito pode no ser implementado de forma
satisfatria (SOMMERVILLE, 2004, p. 88).
Parece complicado, mas alguns exemplos simples podem ajudar a compre-
ender os requisitos de domnio:

Classificao dos Requisitos


46 UNIDADE II

O clculo da mdia final dado pela frmula: (Nota1 * 2 + Nota2 * 3)/5,


em que Nota1 e Nota2 so dados do prprio processo, no so entradas
para a frmula.
O pr-requisito para um aluno matricular-se em uma disciplina que
tenha sido aprovado nas disciplinas classificadas como pr-requisitos.
No desenvolvimento de um software para gesto de operadora de plano
de sade, os requisitos de domnio so conhecimentos especficos desta
rea de atuao.

Os requisitos de usurios descrevem os requisitos funcionais e no funcionais de

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
forma compreensvel pelos futuros usurios do sistema, devem ser relacionados
com uma linguagem simples e no tcnica. Especificam somente o comporta-
mento externo do sistema. Devido a problemas que podem surgir pelo uso da
linguagem natural, como falta de clareza, confuso ou fuso de requisitos, reco-
mendado que, na formalizao dos requisitos para a modelagem do sistema, essa
forma de descrio no seja utilizada.
A fim de minimizar divergncias na elaborao de requisitos de usurio,
Sommerville (2008) recomenda que, para a descrio dos requisitos de usurio,
sigam-se os seguintes critrios:
Crie um formato-padro e certifique que todas as definies de requisi-
tos estejam de acordo com ele.
Utilize a linguagem de forma consistente, distinguindo requisitos obri-
gatrios dos desejveis.
Ressalte partes importantes dos requisitos.
Evite o uso de jarges tcnicos.

Finalmente, os requisitos de sistema so descries mais detalhadas dos requisi-


tos de usurio, eles podem servir de base para um contrato de desenvolvimento
de software. Nesse nvel de descrio, os requisitos de sistema devem especificar
consistentemente todo o sistema a ser desenvolvido. Normalmente, so utiliza-
dos como documentao preliminar para o projeto de um novo software.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


47

Como comentei acima, as especificaes de requisitos escritas em lingua-


gem natural esto sujeitas a divergncias e essas divergncias, frequentemente,
s so descobertas em fases posteriores do processo de software, o que ocasiona
aumento de custo e de tempo no projeto. No caso da deciso por essa aborda-
gem para a documentao dos requisitos, cabe aqui a mesma orientao dada
por Sommerville (2008) para a descrio dos requisitos de usurio.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Na prtica, no fcil a distino dos requisitos para sua classificao. Bus-


cando uma maneira de facilitar a identificao e classificao dos requisi-
tos, a FURPS+ foi concebida pelo Processo Unificado UML. Eles utilizam o
acrnimo FURPS para descrever as principais categorias e sua subcategoria:
Functionality (Funcionalidade); Usability (Usabilidade); Reliability (Confiabili-
dade); Performance (Performace ou Desempenho); Supportability (Suporta-
bilidade); Plus (+), assim fica mais fcil relembrar cada um deles, no momen-
to da elicitao dos requisitos. Para saber mais, acesse o link disponvel em:
<http://ieeexplore.ieee.org/>. Acesso em: 8 jul. 2015.
Fonte: o autor.

REQUISITOS NO PROCESSO DE SOFTWARE

fcil interpretar que os requisitos sero utilizados e considerados somente na fase


inicial do processo de desenvolvimento de software, uma vez que a Engenharia
de Requisitos a primeira atividade do processo, mas isso no representa a rea-
lidade. Os requisitos participaro de forma direita ou indireta, durante todas as
fases do processo de desenvolvimento do software, observe como, de maneira
simplificada, relaciono funes para o documento de requisitos como base para
atividades em todas as fases do processo de:
Especificao de software:
Definio de critrios de aceitao e validao (pelos stakeholders).
Definio sobre o que o sistema deve fazer (especificao para a equipe).

Classificao dos Requisitos


48 UNIDADE II

Projeto de software:

Alocao de tarefas para a equipe.

Estimativa de custo/esforo/cronograma.

Acompanhamento e controle do andamento do projeto.

Validao de software: teste e verificao do sistema desenvolvido.

Evoluo de software: informaes para o gerenciamento de mudanas

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Por isso, o documento de requisitos deve ser bem elaborado e estar sempre
atualizado.

DOCUMENTAO DOS REQUISITOS DE SOFTWARE

DOCUMENTO DE REQUISITOS

Agora, sabemos que o principal objetivo do processo de definio de requisi-


tos obter um acordo entre quem solicita e quem desenvolve, estabelecendo, de
forma clara e rigorosa, o que dever ser produzido, isto , o conjunto de requisitos
levantados define o Escopo do produto que ser registrado nem um documento
oficial, o Documento de Requisitos.
O Documento de Requisitos deve ser um documento de consenso, como
dito anteriormente, um acordo entre a equipe de desenvolvimento e o cliente e,
tambm, um ponto de referncia para validaes futuras. Deve, ainda, garan-
tir uma rastreabilidade mnima, isto , a possibilidade de identificar, a partir de
um determinado requisito, todas as dependncias, diretas ou indiretas, quando,
por exemplo, surge a necessidade de uma mudana.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


49

Como documentar? Isso um desafio!


Na prtica, o que se percebe que os procedimentos utilizados para a
definio desse acordo so muito variveis, vo desde mtodos pouco estru-
turados at mtodos sistemticos e burocrticos. Percebe-se, tambm, que
so vrios os fatores que influenciam o nvel de estruturao do documento,
dentre eles, elejo trs, que, no meu ponto de vista, so os mais evidentes no
mercado: 1. Maturidade tcnica da empresa/equipe, 2. Disciplina e 3. Cultura
organizacional.
Existem vrios modelos sugeridos para documentao, o RUP sugere mode-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

los para documento de requisitos mais complexo com mais controles e mais
simples, dependendo do tamanho do projeto. O Guia PMBOK tem a sua suges-
to para a documentao de requisitos e, se fizer uma busca pela Internet usando
as palavras documento de requisitos, ir se deparar com inmeras formas de
apresentao. O desafio aqui decidir qual o modelo que melhor se adapta ao
seu projeto, a sua empresa, a sua equipe.
Independente da abordagem escolhida, de extrema importncia para
o projeto que ele exista e que seja til. No adianta desenvolver um artefato
com trezentas pginas de um nico requisito com prottipos, diagramas, des-
critivas detalhadas e tcnicas, wireframes que ningum vai ler ou seguir, ou,
no outro extremo, documentar em poucas linhas algo que no representa o
problema real.
Como chegar ao nvel certo de documentao? Na minha opinio, primeiro,
seu documento deve ser capaz de garantir o entendimento dos stakeholders. O
documento deve demonstrar tanto as funcionalidades do sistema, de forma
interpretvel por esse pblico, quanto deve deixar claro que ele quem garantir
que o que foi descrito ali ser contemplado no produto final. Segundo, a equipe
tcnica deve estar ciente de que esse documento a nica garantia de que est
atendendo, de forma completa, s solicitaes do cliente, que qualquer solicita-
o que no esteja documentada ali ser considerada mudana e que tero que
despender tempo extra para produzi-la.

Documentao dos Requisitos de Software


50 UNIDADE II

E agora? Como montar o documento de requisitos?


Vrias so as formas usadas para documentar requisitos. Por exemplo, nos
anos setenta, usava-se o DFD Diagrama de Fluxo de Dados - complementado
por material descritivo, tambm, documentavam-se requisitos usando fluxo-
gramas; at o final dos anos noventa, alguns ainda chamavam o documento de
requisito de especificao funcional. Depois, veio a linguagem UML - Unified
Modeling Language e, ento, as metodologias baseadas nela apresentaram seus
modelos de artefatos: UP Unified Process, RUP Rational Unified Process, para
eles, a descrio de requisitos feita pelos casos de uso. Temos, ainda, a verso de

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
boas prticas para a documentao e desenvolvimento de projetos da Microsoft
- Microsoft Solutions Framework (MSF).
No se aflija! O ponto aqui que todas oferecem modelos, e modelos so
adaptveis, portanto, voc pode definir junto com sua equipe qual o padro que
utilizaro para a documentao dos seus requisitos.
O Documento de Requisitos deve: 1. estabelecer o escopo do software - con-
junto de funcionalidades que ele dever oferecer - e tambm deve especificar os
atributos de qualidade suportados conjunto de caractersticas tcnicas - (fcil,
no ? Percebeu que estamos falando dos requisitos funcionais e no funcionais);
2. ser elaborado de maneira precisa, completa, consistente e, como j dito, deve ser
compreensvel aos stakeholders - todos eles: este documento ser lido por vrios
interessados no projeto, por exemplo, o cliente, o gerente de projeto, o engenheiro
de testes, os programadores etc.; 3. servir de referncia para testes, manuteno
e evoluo do sistema. Percebemos que alguns itens so imprescindveis:
Definio dos requisitos de usurio.
Stakeholders.
Especificao de requisitos de sistema.
Arquitetura do sistema.

Com base nessas premissas, definiremos um padro para o registro dos requisi-
tos para o nosso curso. Para isso, utilizaremos as sugestes do Guia PMBOK e
as recomendaes IEEE de documentao padro: IEEE-Std 830-1998. A Figura
7 traz um template desse documento.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


51

TEMPLATE DOCUMENTO DE REQUISITOS


DOCUMENTO DE REQUISITOS
Histrico de Revises

DATA VERSO DESCRIO RESPONSVEL


01/01/2015 1.0 Elaborao do documento Vanessa Chain
... ... ... ...
Modificao na seo Descrio
28/04/2015 3.1 da interface com o usurio e nos Rogrio Matos
casos de uso do sistema.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

1. OBJETIVOS
Descrio dos objetivos do documento e o pblico ao qual ele se destina.
2. ESCOPO GERAL DO PRODUTO
Definir, em linhas gerais, o propsito e escopo do produto a ser desenvolvido.

3. CONVENES, TERMOS E ABREVIAES


Relao dos termos e abreviaes usadas, tipos de prioridades atribudas aos requi-
sitos, alm de informar como o documento deve evoluir.
3.1 Identificao dos requisitos e casos de uso
3.2 Prioridades dos requisitos
4. REQUISITOS
Os requisitos podem ser registrados utilizando vrias tcnicas, de forma individual
ou agregada, para facilitar a compreenso da rotina a ser implementada. Neste
documento, sugiro uma planilha para o registro, com a opo de utilizao da re-
presentao grfica por meio de casos de uso. A coluna UC identifica o caso de uso
referente quele requisito.
4.1 Requisitos funcionais
Esta seo descreve, de maneira sumarizada, as funcionalidades do software. O
engenheiro de requisitos deve organizar o conjunto de funcionalidades, de modo a
torn-las compreensveis a todos os stakeholders envolvidos.

Descrio/ pr- ps-


RF UC PR Entrada Sada Stakeholder
Ao condio condio

Documentao dos Requisitos de Software


52 UNIDADE II

4.2 Requisitos no funcionais


Esta seo considera os requisitos do produto, do processo, da interface grfica e
da plataforma tecnolgica empregada e demais requisitos limitadores, isto , re-
quisitos de segurana, confiabilidade, timeout de sesso de usurio, usabilidade, e
outros a serem identificados.

Descrio/ pr- ps-


RF UC PR Entrada Sada Stakeholder
Ao condio condio

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
5. ESCOPO NO CONTEMPLADO
Contm descrio das funcionalidades que no sero desenvolvidas. Outra deno-
minao dada a esta seo escopo negativo. Isto garante aos stakehorders o que
no faz parte do conjunto a ser implementado.
6. APROVAO
Nesta sesso, registre o nome, funo na empresa e/ou no projeto, os envolvidos, a
data e a assinatura.

Figura 7: Template de Documento de Requisitos


Fonte: o autor.

Cabem, ainda, no documento de requisitos outras duas sesses, que so opcionais


e podem ficar a critrio do engenheiro de requisitos sua incluso no documento
formal:
a. Documentos Complementares, em que voc pode relacionar atas de reu-
nies nas quais ocorrero levantamento e validao de requisitos, o plano
de projeto, ou, ainda, a matriz de rastreabilidade dos requisitos.
b. Apndice, em que voc poder acrescentar documentos que no fazem
parte do documento de requisitos, mas podem colaborar com informaes
de apoio para os leitores; documentos, por exemplo, de levantamento de
perfil dos usurios do sistema a ser desenvolvido, descrio do problema a
ser automatizado pelo sistema de software, descrio da plataforma sobre
a qual o sistema ser desenvolvido etc.

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


53

MATRIZ DE RASTREABILIDADE DE REQUISITOS

Perfeito! Sabemos onde registrar nossos requisitos. Agora, falaremos um pouco


sobre como ligar os requisitos as suas origens e os rastrear durante todo o ciclo
de vida do projeto.
Uma das maiores dificuldades para a engenharia de requisitos o controle
e o registro de novos requisitos impostos ao projeto durante o seu desenvolvi-
mento que podem ser gerados por diversos motivos, por exemplo: demanda
de programao, por solicitao de stakeholders, por mudana de contexto, ou,
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

ainda, correo de erros detectados.


A Gerncia de Requisitos o processo da Engenharia de Requisitos que trata
esse problema por meio de um processo com trs fases: Identificao, Gesto de
Mudanas e Rastreabilidade, e tem como principais objetivos: o gerenciamento
das mudanas, o gerenciamento entre requisitos relacionados e o gerenciamento
das dependncias entre a documentao de requisitos e outros documentos ori-
ginados durante outros processos da engenharia de software.
Na unidade IV, trataremos a gesto de requisitos com mais propriedade e
detalhes, para o momento, o que importa como elaborar o documento para
registrar as mudanas e permitir o rastreamento dos requisitos do incio ao fim
do projeto.
De acordo com o guia Guia PMBOK, o uso da matriz de rastreabilidade
tem as seguintes funes: a) garante que cada requisito adiciona valor de neg-
cio por meio da sua ligao aos objetivos funcionais (da regra de negcio) e aos
objetivos do projeto de desenvolvimento; b) fornece um meio de rastreamento
do incio ao fim do ciclo de vida do projeto; c) garante que os requisitos valida-
dos no documento de requisitos sejam entregues no final do projeto; e d) fornece
uma estrutura de gerenciamento das mudanas do escopo do produto.
A matriz de rastreabilidade uma tabela que relaciona os atributos associados
a cada requisito e os liga a sua origem. Os atributos que devem ser registrados,
no mnimo, so:

Matriz de Rastreabilidade de Requisitos


54 UNIDADE II

Identificador de requisito.
Descrio do requisito conforme documento de requisitos.
Solicitante.
Prioridade.
Situao (aprovado, em desenvolvimento, entregue, entre outros).
Critrio de aceitao.

O modelo sugerido para o uso durante nosso curso foi elaborado com base no

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
proposto pelo Guia PMBOK para matriz de rastreabilidade de requisitos.

TEMPLATE DA MATRIZ DE RASTREABILIDADE DE


REQUISITOS
MATRIZ DE RASTREABILIDADADE DE REQUISITOS

Histrico de Revises

Data Verso Descrio Responsvel


01/01/2015 1.0 Elaborao do documento Vanessa Chain
... ... ... ...
09/04/2015 3.1 Inserido novo requisito (RF152-UC89) Rafaela Rodrigues

Legenda

Prioridade Tipo do Requisito Status Complexidade


Altssima Funcional Validado Alta
Alta Tcnico Em desenvolvimento Mdia
Mdia Qualidade Teste Baixa
Baixa Qualidade
Muito Baixa Concludo

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Critrios Mnimos
Id Req. Prioridade Descrio Complexidade Solicitante Data Validao Status
para Aceitao
Inserir identi- Estabelecer a Inserir descrio Estabelecer o Critrios/exigncias Registrar o Data da valida- Status.
ficao do Requi- prioridade de do Requisito nvel de comple- externas que devem stakeholder o do requisito,
sito conforme desenvolvimento conforme xidade para o estar concludos para solicitante. Por ou da assinatura
registrado no para os requisitos, registrado no desenvolvimento o aceite do requisito. exemplo: do documento
Documento de considerando Documento de (programao de requisito, ou
Por exemplo: Emisso Usurio; Ge-
requisitos. as abstraes e requisitos. da funo do documento
de NF Eletrnica. rente Projeto;
dependncias. estabelecida pelo de aceite de
Critrio mnimo: Qualidade.
requisito). incluso de re-
conjunto de Schemas
quisito (Registro
XML com as defini-
de Solicitao de
es das mensagens
Mudanas).
e regras de validao
dos Web.

Services (WS) da NF-e


disponvel.
...

Figura 8: Matriz de Rastreabilidade de Requisitos


Fonte: o autor.

Template da Matriz de Rastreabilidade de Requisitos


55
56 UNIDADE II

A Devmedia um site de contedo para rea de desenvolvimento de sof-


tware. Conta com vrios especialistas focados na melhoria dos processos de
desenvolvimento de software e disponibiliza artigos, cursos, links e opinies
sobre as vertentes da rea.
O link a seguir oferece um curso que objetiva introduzir os conceitos-base
da Engenharia de Requisitos.
Acesse e participe: <http://www.devmedia.com.br/curso/introducao-a-en-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
genharia-de-requisitos/132>. Acesso em: 22 jun. 2015
Fonte: o autor.

CONSIDERAES FINAIS

Nesta unidade, analisamos a importncia da engenharia de requisitos dentro


do processo de desenvolvimento de software. Percebemos que um documento
de requisito pode ser considerado o motivo do sucesso ou do fracasso do pro-
jeto, uma vez que nele que esto contidas as especificaes operacionais do
software a ser desenvolvido.
Aprendemos que o propsito da engenharia de requisitos est relacionado
com a identificao de metas a serem atingidas: qualidade de software; produti-
vidade no desenvolvimento, operao e manuteno de software; permitir que
profissionais tenham controle sobre o desenvolvimento de software dentro de
custos, prazos e nveis de qualidade desejados.
Estudamos ainda que, enquanto estiver envolvido somente na engenharia de
requisitos, voc no ter que se preocupar com o gerenciamento e controle de
todos os stakeholders envolvidos no projeto, mas de extrema importncia que
execute o levantamento, no mnimo, daqueles que podem influenciar na deli-
mitao e manuteno dos requisitos que definiro o escopo final do produto.
Nesta unidade, desenvolvemos um modelo de Documento de Requisitos e
entendemos que esse documento responsvel por delimitar o escopo do con-
junto de funcionalidades que um sistema deve prover, bem como descrever os

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS


57

atributos de qualidade que devem ser suportados pelo sistema a ser desenvol-
vido. Montamos, tambm, uma Matriz de Rastreabilidade de Requisitos que nos
apoiar na gerncia de requisito durante todo o ciclo de vida do projeto.
Percebemos que a engenharia de requisitos se relaciona com praticamente
todas as reas do processo de desenvolvimento de software: especificao, pro-
jeto, validao, testes e implementao e, como primeiro passo no processo de
desenvolvimento de software, tem um impacto significativo sobre o sucesso do
projeto. Ela delimita o escopo do projeto e estabelece uma base comum de comu-
nicao para todas as disciplinas envolvidas no projeto de desenvolvimento.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Consideraes Finais
1. So os requisitos que expressam as condies ou especialidades que o software
deve atender. So as restries a serem impostas relacionadas a desempenho,
segurana, usabilidade, portabilidade, facilidade de uso, eficincia etc. Com base
nessa afirmao, identifique a alternativa que apresenta a descrio de um
requisito no-funcional:
a. O software deve calcular os salrios dos diaristas e mensalistas.
b. Os relatrios onde constam os salrios dos funcionrios devem ser emitidos
quinzenalmente para considerar os adiantamentos e vales que recebem.
c. O tempo de resposta das consultas no deve superar quinze segundos.
d. O software deve apresentar uma tela informando ao usurio que seu acesso
no permitido.

2. Afirmativa 1: conjunto de atividades sistemticas como condio para se alcan-


ar determinado fim, o que se foi requisitado.
Afirmativa 2: conjunto estruturado de atividades para extrair, validar e manter
um documento de requisitos.
Sobre os requisitos de software, em relao s afirmaes acima:
a. Somente a afirmativa 1 verdadeira.
b. Somente a afirmativa 2 verdadeira.
c. Ambas as afirmativas so falsas.
d. Ambas as afirmativas so verdadeiras.

3. Dada a descrio abaixo, identifique a alternativa que relaciona os principais sta-


ckeholders:
A pizzaria Pizza a Pezzi funciona com entrega de pizzas in-loco, ou seja, no h
entrega em domiclio e o cliente deve vir buscar a pizza. uma empresa familiar com
atualmente 6 funcionrios, alm dos 2 proprietrios. A pizzaria gostaria de melhorar
sua organizao e tem como objetivo principal maximizar sua produo e, portan-
to, a entrada bruta e o lucro lquido. Deseja-se tambm melhorar o atual servio de
pedido e entrega das pizzas. O horrio de abertura da pizzaria ao pblico das 18:00
s 22:00. Os pedidos podem ser feitos por telefone ou pessoalmente na pizzaria. Os
pedidos feitos por telefone tem mais prioridade. As pizzas so enfornadas em grupos
de no mximo nove pizzas e cada fornada precisa de 5 minutos para um cozimento
apropriado das pizzas. O processo de preparao das pizzas consiste de seis fases:
(1) o cliente faz o pedido; (2) a pizza (base, molho, cobertura) preparada; (3) a pizza
enfornada; (4) se necessrio so colocados ingredientes crus depois do cozimento;
(5) a pizza preparada para entrega; (6) a pizza entregue ao cliente, que efetua o
pagamento. A pizzaria abre de tera a domingo. Durante final de semana e feria-
59

dos, a carga de trabalho maior do que nos dias teis. A organizao do trabalho
feita da seguinte maneira: os dois proprietrios trabalham todos os dias; dos outros
seis funcionrios, cinco trabalham somente durante o final de semana, enquanto o
sexto ajuda o proprietrio durante os dias teis e fica disposio dos proprietrios
tambm para ajudar nos feriados e eventualmente substituir algum outro funcio-
nrio que precisou faltar. Existem trs papis principais na gesto da pizzaria: quem
prepara a pizza, quem trabalha na cozinha preparando os ingredientes e quem ge-
rencia os pedidos, entregas e pagamentos. A gesto dos recursos necessrios para a
pizzaria efetuada inteiramente pelos dois proprietrios. Os ingredientes que faltam
(acabam) so comprados no supermercado. Outros recursos, como por exemplo as
caixas para entrega das pizzas, so pedidos ou comprados em lojas especializadas.
Fonte: Souza (online).
a. Os proprietrios da pizzaria; os funcionrios da pizzaria (o pizzaiolo, o cozi-
nheiro e o atendente); os clientes da pizzaria.
b. O Proprietrio do supermercado; os clientes da pizzaria; lojas especializadas.
c. O governo; os funcionrios da pizzaria (o pizzaiolo, o cozinheiro e o atenden-
te); o proprietrio do supermercado.
d. Os proprietrios da pizzaria; os funcionrios da pizzaria (o pizzaiolo, o cozi-
nheiro e o atendente); o proprietrio do supermercado.

4. Os requisitos de usurio so escritos com alto nvel de abstrao, em linguagem


natural, e podem conter diagramas simples e representativos das funcionalidades
que o sistema deve apresentar e das restries que ele deve operar. Assinale a al-
ternativa que contm a quem se destinam as informaes nesse nvel de abstrao:
a. Engenheiro do cliente; arquiteto do sistema.
b. Desenvolvedor do software; gerentes de clientes.
c. Gerentes de clientes; usurio final do sistema.
d. Engenheiro do cliente; desenvolvedor do software.

5. Os requisitos no funcionais so classificados em requisitos de produto, requisi-


tos organizacionais e requisitos externos, os requisitos de produto especificam o
comportamento do produto e podem ser subdivididos em:
a. Requisitos de usabilidade, de eficincia, de confiana e de proteo.
b. Ambientais, operacionais e de desenvolvimento.
c. Reguladores, ticos e legais.
d. Requisitos de usabilidade, reguladores, ticos e legais, ambientais.
6. Assinale a alternativa correta, marcando com (V) a assertiva verdadeira e com (F)
a assertiva falsa, sobre os tipos de requisitos de software:
( ) Requisitos de facilidade de uso: usurios devero operar o sistema aps um
determinado tempo de treinamento.
( ) Requisitos de eficincia: o software dever processar n requisies por x tem-
po.
( ) Requisitos de portabilidade: o software deve ser compatvel com qualquer
plataforma.
( ) Requisitos de domnio: um relatrio de acompanhamento do desenvolvimen-
to dever ser fornecido toda segunda-feira.
Assinale a opo com a sequncia CORRETA.
a. V, F, V, V.
b. F, V, V, F.
c. V, V, V, F
d. F, V, F, F.

7. A matriz de rastreabilidade uma tabela que relaciona os atributos associados


a cada requisito e os liga a sua origem. Assinale a alternativa que relaciona, de
acordo com o guia Guia PMBOK, o objetivo da utilizao da matriz de rastrea-
bilidade:
a. Garante que cada requisito adiciona valor de negcio por meio da sua ligao
aos objetivos no funcionais (da regra de negcio).
b. Fornece um meio de rastreamento do incio ao fim do ciclo de vida do projeto.
c. Garante que os requisitos no validados no documento de requisitos sejam
tratados no final do projeto.
d. Fornece uma estrutura de planejamento do escopo do produto.
61

DOCUMENTO DE REQUISITOS - ESSENCIAL AO DESENVOLVIMENTO DE


SOFTWARE

Um engenheiro de software um profissio- exemplo, inconsistncia e falta de clareza


nal que deve ter a habilidade de antecipar de suma importncia de modo a tor-
e gerenciar mudanas de requisitos de nar o processo mais efetivo sob o ponto
um produto de software. Alm disso, ele de vista de custo. Adicionalmente, envol-
precisa saber se expressar e comunicar-se ver o usurio no processo determinante
bem a fim de capturar e registrar adequa- para o sucesso do produto e do processo.
damente o documento de requisitos. Os Dentro deste contexto, entender adequa-
principais problemas no desenvolvimento damente o requisito essencial e essa
de um sistema de software decorrem do tarefa do engenheiro de software. Um
entendimento errado entre engenheiro de requisito compreende uma caracterstica
software (produtor), responsvel em apre- ou funcionalidade que o sistema deve pos-
sentar o documento de requisitos, e usurio suir ou uma restrio que deve satisfazer
(consumidor). Um documento de requisitos para atender uma necessidade do usurio.
de software precisa ser claro, consistente e Dessa forma, o engenheiro de software,
completo, porque esse documento servir desempenhando o papel de engenheiro de
de referncia aos desenvolvedores, geren- requisitos, deve executar duas atividades
tes de projeto, engenheiros de software essenciais para a elaborao do documento
(responsveis pelos testes e manuteno de requisitos: Elicitao de requisitos ati-
do sistema), alm de servir de base para vidade na qual os requisitos do sistema a
definir o escopo das funcionalidades a ser desenvolvido so levantados; Anlise
serem registradas num contrato. Perceba de requisitos atividade na qual os requi-
que os requisitos compreendem o cerne sitos so analisados e confirmados pelos
de qualquer produto e mudanas sobre principais interessados do projeto (isto , os
eles podem ocorrer ao longo do ciclo de stakeholders) que incluem cliente, usurio
vida de um software. final e gerente de projetos, dentre outros.

Desenvolver um sistema de software requer Considera-se ainda que a elicitao de


um processo, o qual informa um conjunto requisitos objetiva definir caractersticas
de atividades a serem realizadas, quem as do sistema sob a perspectiva do cliente,
executam, quais artefatos de entrada so enquanto que a anlise de requisitos visa
necessrios e quais artefatos de sada so obter a especificao de requisitos, do
produzidos. Nesse sentido, detectar erros ponto de vista tcnico, conforme entendi-
ou quaisquer outros problemas como, por mento dos desenvolvedores.
Durante a realizao destas atividades, o importante ressaltar a necessidade de
engenheiro de software est preocupado definir o limite, ou tambm denomi-
em levantar, entender, analisar e, por fim, nado escopo do sistema, a fim de tratar
documentar os requisitos. Para tanto, ele os requisitos funcionais e no funcionais
deve concentrar-se nas caractersticas do do sistema. Alm disso, quando da ela-
sistema e atributos de qualidade, e no em borao do documento de requisitos, o
como obt-los. Aqui, preciso identificar engenheiro de software deve levar em con-
quais requisitos fazem parte ou no do siderao os diferentes pontos de vistas dos
escopo do sistema a ser desenvolvido, ou stakeholders de modo que o documento
em outras palavras, entender a interface do resultante possa comunicar adequada-
sistema considerado e o ambiente externo. mente o conjunto de requisitos do sistema
a ser construdo.
Fonte: Filho (online).
MATERIAL COMPLEMENTAR

O vdeo a seguir apresenta, de forma simples, todas as reas de conhecimento do Guia PMBOK e
como se integram durante o gerenciamento de um projeto.
Disponvel em: <http://www.ricardo-vargas.com/pt/pmbok5-processes-flow/>. Acesso em: 01 jul.
2015.

Material Complementar
Professora Me. Vanessa Ravazzi Perseguine

III
PROCESSOS DA

UNIDADE
ENGENHARIA DE
REQUISITOS

Objetivos de Aprendizagem
Conhecer os processos da engenharia de requisitos.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Processos da engenharia de requisitos
Levantamento e anlise de requisitos
Tcnicas para coletar requisitos
Entrevistas
Brainstorming
Tcnica de grupo nominal (TGN)
Oficinas
Questionrios
Pesquisas
Etnografia
Negociao
Validao de requisitos
Especificao de requisitos
67

INTRODUO

Muito bem! J entendemos onde a engenharia de requisitos se encaixa nas ati-


vidades da engenharia de software, j observamos os principais fundamentos,
estudamos o que requisito e sua classificao e, ainda, modelamos os docu-
mentos que devero ser o produto final da engenharia de requisitos e a base
para todo o projeto de software de gerenciamento de requisitos. Agora, vamos
conhecer os processos e atividades que so responsveis por garantir a especifi-
cao de um bom requisito.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Comeo com uma pergunta: qual o objetivo da engenharia de requisitos?


A engenharia de requisitos tem o objetivo de fornecer a todos os envolvidos no
projeto de desenvolvimento de software um artefato escrito que promova o enten-
dimento do que se deseja produzir. Para ter certeza de que esse artefato reproduz,
de fato, o produto final desejado, ele deve ser revisado e validado com o cliente,
usurio, patrocinador, enfim, com todos os stakeholders que foram identifica-
dos no projeto e durante todo o processo de desenvolvimento. Nesta unidade,
estudaremos o conjunto de atividades que nos auxiliam na construo do docu-
mento que ser o ponto-chave, o produto final.
O primeiro passo, para o sucesso do projeto, o levantamento de requisitos,
ele deve ter caractersticas que o torne conciso, claro e completo em sua unidade.
Para que isso ocorra, vrias tcnicas de elicitao podem ser utilizadas. Nesta
unidade, sero apresentadas algumas, as mais populares e de aplicao prtica
no contexto do desenvolvimento de software.
Durante o processo de levantamento e mesmo depois de decidido todo o
conjunto de requisitos, necessrios para a composio do sistema que atender
necessidade do cliente, importante analisar o que foi especificado e, ento,
corrigir, caso no se tenha escrito exatamente o que era esperado. Esse processo
da engenharia de requisitos denominado anlise dos requisitos. Na sequncia,
vem a etapa da negociao de requisitos com stakeholders.
Perceberemos que os processos de levantamento, anlise e negociao devem
andar juntos e permanecer durante todo o ciclo de vida do projeto, o que ir dar
garantias da elaborao de um bom Documento de Requisitos.

Introduo
68 UNIDADE III

PROCESSOS DA ENGENHARIA DE REQUISITOS

Processos da engenharia de requisitos podem variar muito em funo das


caractersticas dos projetos e, at mesmo, das organizaes. Pressman (2010)
organiza as atividades de engenharia de requisitos montando o seguinte pro-
cesso: Levantamento, Elaborao, Negociao, Especificao, Validao e Gesto.
Sommerville (2008) nos apresenta: Levantamento, Anlise, Documentao,
Verificao/Validao e Gerncia, e ajusta em sua publicao de 2011, organi-
zando as atividades da seguinte forma: Estudo de Viabilidade, Levantamento e

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Anlise, Documentao, Validao e Gesto.
Tambm possvel encontrar, na literatura, as atividades organizadas como
elicitao, anlise, negociao, documentao, verificao e validao. Analisando
as propostas, podemos perceber que, apesar de estarem organizadas ou, at
mesmo, nomeadas de formas diferentes, elas apresentam em comum a necessi-
dade do levantamento e do registro dos requisitos.
Fato , como afirma Mrcio Andrade Silva em seu artigo: A importncia do
levantamento de requisitos no sucesso dos projetos de software, que toda meto-
dologia de desenvolvimento de software prope uma srie de fases e atividades
dentro do seu ciclo de vida, porm, independente do nome dado a cada fase,
extremamente recomendvel que o processo contemple, no mnimo, dois gru-
pos de atividades:
Especificao de requisitos: que representa todas as atividades realizadas para
identificar, analisar, especificar e definir as necessidades que o sistema dever
prover para soluo do problema levantado.
Gesto de requisitos: atividades responsveis pela documentao, versiona-
mento, controle de mudanas e qualidade dos requisitos levantados na fase de
especificao de requisitos.
Para o nosso estudo, organizei uma compilao dos principais autores e suas
representaes genricas e mesclei com as propostas prticas apresentadas no
mercado atual. Assim, seguiremos o seguinte processo: Levantamento e Anlise,
Negociao, Documentao, Validao e Gerenciamento de requisitos.

PROCESSOS DA ENGENHARIA DE REQUISITOS


69

Levantamento
e Anlise

Negociao

Documento Gerenciamento
de Requisitos de Requisitos
Documentao
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Validao
Figura 9: Processo da Engenharia de Requisitos
Fonte: o autor.

LEVANTAMENTO E ANLISE DE REQUISITOS

Esta etapa inicia o processo de engenharia de requisitos. Nesse ponto, voc j


deve ter identificado ou j foi disponibilizado para voc a relao dos stakehol-
ders, considerando seu grau de interesse, poder e influncia no seu produto,
bem como aqueles que conhecem a regra de negcio e sejam capazes de auxili-
-lo nas atividades de levantamento de requisitos. Essa fase tambm conhecida
como Elicitao de requisitos, elicitao quer dizer ato ou efeito de eliciar; con-
frontar; aliciar; conseguir obter resposta ou informao (PRIBERAM, online).
Summerville (2008) considera que a definio do escopo geral deve ser feita
em uma fase anterior de Levantamento e Anlise que ele intitula Estudo de
Viabilidade, e Pressman (2010) concorda com ele, adicionando uma fase anterior
no seu processo, a qual nomeia Concepo. Ambos afirmam que, nessa fase, o
engenheiro de requisitos ir reunir-se com os clientes e usurios patrocinadores
e usurios finais do sistema para obter a noo geral sobre as funcionalidades
do sistema a ser desenvolvido ou mantido e, a partir dessa noo, define-se o
escopo geral e se existe viabilidade para o desenvolvimento do software.

Levantamento e Anlise de Requisitos


70 UNIDADE III

Em uma abordagem mais prtica, considero que as etapas de concepo


ou estudo de viabilidade foram desenvolvidas em um momento anterior do
projeto, em que as partes se renem para decidir pelo desenvolvimento e con-
tratao dos servios, e que a fase de engenharia de requisitos j est dentro do
projeto de desenvolvimento de software acordado, ento, nesse momento do
Levantamento o engenheiro de requisito estar com a responsabilidade de
definir o escopo e os requisitos para o desenvolvimento do software, podendo,
assim, aproveitar a reunio tanto para o levantamento do escopo quanto para
levantamento dos requisitos.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
O levantamento de requisitos o incio da atividade de desenvolvimento
de software, o ir a campo e compreender o que o cliente deseja e como ser
desenhada sua proposta para atender s expectativas dele. Sommerville (2008)
prope um processo genrico de levantamento e anlise que contm as seguin-
tes atividades:
1. Compreenso do domnio: os engenheiros de requisitos devem desen-
volver sua compreenso do domnio da aplicao para que a transcrio
seja eficiente e clara para os demais profissionais envolvidos no processo
de desenvolvimento de software, principalmente em equipes em que
engenheiro de requisitos no necessariamente o programador. A com-
preenso do domnio ir se desenvolver mais conforme as atividades a
seguir forem sendo desenvolvidas.
2. Coleta de requisitos: o processo de interagir com os stakeholders do
sistema para descobrir seus requisitos.
3. Classificao: organizao dos requisitos em grupos coerentes.
4. Resoluo de conflitos: como existem muitos stakeholders diferentes
envolvidos, os requisitos sero apresentados a partir de pontos de vista
diferentes. Os requisitos podem conflitar uns com os outros, nessa fase, o
engenheiro de requisitos ir categorizar todas as informaes para, pos-
teriormente, decidir pelo conjunto de requisitos mais consistente.
5. Definio das prioridades: com o conjunto de requisitos em mos,
juntamente com os stakeholders tomadores de deciso, so definidos os
requisitos mais importantes.

PROCESSOS DA ENGENHARIA DE REQUISITOS


71

6. Verificao de requisitos: os requisitos so verificados para descobrir


se esto completos e consistentes e se esto em concordncia com o que
os stakeholders desejam do sistema.

A obteno de requisitos no um processo formal, por isso no permite sua


automatizao. O engenheiro de requisitos deve contar com tcnicas de entre-
vista, questionrio, mapeamento, entendimento do processo-alvo etc.

TCNICAS PARA COLETAR REQUISITOS


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

O objetivo reunir-se com os stakeholders e conquist-los, traz-los para o projeto


e faz-los entender que so coautores, e no meros participantes ou telespec-
tadores. As caractersticas do projeto e do cliente determinaro a tcnica mais
adequada para a coleta de requisitos.
Fornier (1994) apresenta alguns procedimentos a serem estabelecidos durante
o levantamento de requisitos que independem da tcnica adotada para a coleta
deles:
Antes:
I. Identificar as reas envolvidas, explicar a finalidade e obter aprovao das
gerncias apropriadas para o trabalho.
II. Obter nome e funo dos stakeholders chaves e que participaro da coleta.
Confirmar e solicitar concordncia quanto a papis, responsabilidades e
disponibilidades previstas.

Durante:
1. Familiarizar-se com o local de trabalho que est sendo estudado.
2. Coletar amostras de documentos e procedimentos escritos.
3. Acumular informaes estatsticas a respeito das tarefas: frequncia com
que ocorrem, estimativas de volume, tempo de durao para cada tarefa
e assim por diante.
4. Enquanto interage com as partes interessadas, tentar ser objetivo e no
comentar as formas de trabalho de maneira no construtiva.

Levantamento e Anlise de Requisitos


72 UNIDADE III

5. Alm das operaes normais de negcio, identificar, tambm, as excees.


6. To logo o levantamento tenha sido completado, agradecer s pessoas
pelo apoio.
Aps:
1. Documentar os requisitos e consolidar os resultados.
2. Caso seja necessrio, contatar os prprios informantes para esclarecer
dvidas.
3. Rever os resultados consolidados com os prprios informantes e/ou

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
superiores.
4. Atribuir uma prioridade para cada requisito identificado.

A coleta de requisitos um processo meticuloso que demanda recursos e


tempo. A EMC desenvolveu uma nova abordagem para a coleta de requisitos
que foca nos dados. Desenvolveram um mapa de percurso para a governan-
a e qualidade de dados empresariais que utiliza uma abordagem colabora-
tiva e consistente para definir a qualidade de dados.
Fonte: Karel (online).

Existem inmeras tcnicas para interagir com os stakeholders a fim de coletar


dados e informaes. Novamente, recomendo que decida qual metodologia utili-
zar em acordo com a necessidade do seu projeto. Isso significa que deve conhecer
sua organizao, seus colaboradores e seu cliente.
A seguir, analisaremos algumas tcnicas para coletar requisitos, que selecionei
tomando por base tanto a teoria quanto a minha experincia prtica: entrevis-
tas, brainstorming, tcnica de grupo nominal (TGN), tcnica Delphi, oficinas,
questionrios, pesquisas e etnografia.

PROCESSOS DA ENGENHARIA DE REQUISITOS


73

ENTREVISTAS

Sotille et al (2014) afirmam que a entrevista o mtodo mais utilizado para cole-
tar requisitos. As entrevistas acontecem em reunies para sanar dvidas, levantar
problemas e buscar solues. Essa tcnica, normalmente, utilizada quando a
equipe de desenvolvimento no conhece os problemas do cliente ou da orga-
nizao. necessrio que se faa uma preparao prvia para a realizao dela.
Antes da entrevista:
Algumas questes devem ser consideradas: o que se deseja saber? O que
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

se aceita saber? (Mnimo necessrio). Quem ser o entrevistado? Quais


perguntas sero feitas? Qual a sequncia de execuo das perguntas?
Quando finalizar?
Divulgue com antecedncia a agenda e pauta da entrevista (reunio).
Dessa forma, o entrevistado pode se preparar e buscar informaes/docu-
mentos necessrios.
Agendar a entrevista/reunio em um horrio conveniente para o entrevis-
tado e, sempre que possvel, em local sossegado, que elimine distraes.

Durante a entrevista:
Ter em mente que pode haver resistncia s mudanas e que seu traba-
lho pode ser considerado uma ameaa pelo entrevistado.
Fazer perguntas.
Ouvir e responder de forma cordial s perguntas do entrevistado.
Tomar notas.
No ser tendencioso.
Determinar quem ficar responsvel pelas atividades a serem realizadas
e o respectivo prazo de concluso.
Quanto ao tipo de perguntas, para elaborar o questionrio, voc pode compor
com duas categorias gerais: abertas (subjetivas) e objetivas. As perguntas aber-
tas permitem que o interlocutor d uma resposta descritiva. Por exemplo: como
o usurio se comporta nessa situao? As perguntas objetivas, por outro lado,

Levantamento e Anlise de Requisitos


74 UNIDADE III

apenas requerem um sim ou no como resposta, por exemplo: o usurio geral


ter acesso a esta rotina? Uma pergunta objetiva indicada quando uma res-
posta precisa necessria.
A estrutura da entrevista pode ser organizada das seguintes formas:
Estrutura Pirmide: comea com questes detalhadas (objetivas/finas) e
termina com questes mais gerais (subjetivas/largas).
Estrutura Funil: comea com questes mais gerais (subjetivas/largas) e
termina com questes mais detalhadas (objetivas/finas).

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Estrutura de Diamante: agrega a estrutura funil mais a estrutura pirmide.
Isto , comea com questes especficas, avana para questes mais gerais
e finaliza com questes especficas. Geralmente, a melhor forma de se
entrevistar, mas tende a ser mais longa.
No-Estruturada: no h uma sequncia de como as questes sero abor-
dadas, porm as questes so definidas com antecedncia.

A comunicao um processo que envolve a troca de informaes e utiliza


os sistemas simblicos como suporte para este fim. Por meio da internet,
novos meios de comunicao foram criados, e-mail, chat, fruns, comuni-
dades virtuais, webcam, entre outros, revolucionaram os relacionamentos
humanos. Voc considera que qualquer rotina que exija interao e troca de
informaes hoje em dia possvel ser realizada pelos meios virtuais?
Fonte: o autor.

BRAINSTORMING

Brainstorming significa tempestade cerebral ou tempestade de ideias. uma


expresso inglesa formada pela juno das palavras brain, que significa cre-
bro, intelecto, e storm, que significa tempestade (SIGNIFICADOS, online).

PROCESSOS DA ENGENHARIA DE REQUISITOS


75

O brainstorming uma dinmica de grupo que usada para desenvolver


novas ideias ou projetos, para juntar informao e para estimular o pensa-
mento criativo. Foi criado pelo publicitrio Alex Osborn para testar e explorar
a capacidade criativa de indivduos ou grupos. A tcnica de brainstorming pro-
pe que um grupo de pessoas se rena para expor seus pensamentos e ideias
sobre um determinado problema. intencionalmente no limitador e proje-
tado para deixar a mente criativa fluir livremente. O foco na quantidade de
ideias expostas.
Os procedimentos para a implantao do brainstorming composto pelas
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

seguintes etapas: definio do tema (defina claramente o problema, saiba


o que voc quer de resultado antes de iniciar o brainstorming), escolha
da equipe (recomenda-se at 12 participantes e o encorajamento para a
participao de representantes de vrias reas diferentes), definir o tipo
de brainstorming, gerao de ideias em reunio (encoraje a participao
voluntria e a gerao entusiasmada e divertida de muitas ideias, anote
todas as ideias em um flip-chart), seleo das ideias (elaborao de um
relato final sobre o tema que pode, inclusive, incluir oportunidades de
melhoria no processo de realizao de um brainstorming). A Figura 10
demonstra as etapas para a implantao do brainstorming:

Figura 10: Etapas do brainstorming


Fonte: o autor.

Levantamento e Anlise de Requisitos


76 UNIDADE III

Para uma sesso de brainstorming, devem ser seguidas algumas regras bsicas:
Garantir que todos compreendam o objetivo do brainstorming antes de
inici-lo.
Decidir que mtodo de brainstorming ir utilizar antes de iniciar a reu-
nio. Normalmente, comea de maneira estruturada e, ento, muda para
o no estruturado, quando a maioria dos integrantes no tem mais cola-
borao a fazer.
proibido debates e crticas s ideias apresentadas. O objetivo deixar a
criatividade fluir e alcanar o mximo possvel de ideias, crticas causam

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
inibies. A discusso deve comear depois que o brainstorming acabar.
Nenhuma ideia deve ser desprezada. Deve ser dada liberdade total para
que o grupo fale sobre o que quiser.
Modificao ou combinao de ideias. Prosseguir com base na ideia de
outros e tentar criar ideias mais livres, novas e desembaraadas.
Deve-se garantir igualdade de oportunidade. Todos os participantes devem
ter chance de expor suas ideias.

Escolha um lugar para a reunio que seja do tamanho exato para acomodar a
equipe e crie uma atmosfera relaxada, que promova segurana aos participan-
tes. Existem vrias formas de promover o brainstorming, pode ser estruturado
ou no estruturado, pode, ainda, utilizar anotaes annimas para a divulgao
de ideias, quando perceber que o grupo no comunicativo, ou no se sente a
vontade em expor suas opinies abertamente.
Lembra o que Fornier (1994) recomenda? Para qualquer tcnica utilizada,
antes de aplic-la, identifique os stakeholders, reconhea o ambiente. Observe
as pessoas, pois esse processo poder ser til para resolver impasses que podem
surgir durante o andamento do projeto.
No brainstorming estruturado, cada membro deve dar uma ideia sobre
o tema escolhido a cada rodada. O nmero de rodadas pode ser definido em
funo do tempo disponvel ou voc pode deixar que o brainstorming prossiga

PROCESSOS DA ENGENHARIA DE REQUISITOS


77

at que todos no tenham mais ideias para apresentar. Essa forma de condu-
o tem a vantagem de evitar que os indivduos mais falantes predominem
sobre os mais tmidos e, tambm, colabora no impedimento da inibio, em
que colaboradores de diferentes nveis hierrquicos da organizao partici-
pam juntos.
No brainstorming no estruturado, qualquer participante lana ideias
medida que vo surgindo, no existe vez, como no brainstorming estruturado.
A vantagem que se cria um ambiente mais relaxado e se torna mais fcil para
alguns integrantes aproveitar as ideias de outros para formular suas prprias.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

menos metdico e mais dinmico, ideal quando as pessoas do grupo so todas


comunicativas e pouco tmidas, mas h o risco de os integrantes mais falantes
dominarem o ambiente.

TCNICA DE GRUPO NOMINAL (TGN)

O brainstorming no utiliza, em sua estrutura, votao ou priorizao de ideias,


a tcnica de grupo nominal adiciona ao processo de brainstorming uma etapa
de votao para ordenar as melhores ideias e prioriz-las.
O site escritrio de projetos1 apresenta as seguintes etapas para a realizao
da tcnica de grupo nominal:
Gere ideias: cada participante escreve suas ideias em um papel.
Recolha o material escrito por cada participante e registre as ideias: pode-
-se usar um flip chart ou um quadro negro.
Reveja e discuta as ideias.
Vote as ideias: cada participante prioriza as ideias que so ordenadas con-
forme votao.

1 <http://escritoriodeprojetos.com.br/>.

Levantamento e Anlise de Requisitos


78 UNIDADE III

TCNICA DELPHI

O mtodo Delphi foi originalmente criado nos anos 50 do sc. XX. O mtodo
consiste em um inqurito efetuado a especialistas e realizado em dois ou mais
ciclos. Como em cada ciclo os participantes tm acesso aos resultados do ciclo
anterior, as suas respostas podem ser mantidas ou alteradas de forma a incor-
porar o conhecimento e as opinies expressas pelos demais.
Esse modelo no rene os participantes, uma tcnica no interativa e uti-
lizada como meio de alcanar um consenso quando h dificuldade em reunir

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
os participantes.
Sotille et al (2014) nos apresentam o seguinte processo que pode ser utilizado
para a organizao do levantamento de requisitos utilizando o mtodo Delphi:
1. Designa-se um facilitador e escolhem-se os participantes.
2. De acordo com o problema, um questionrio elaborado e distribudo
aos participantes. Apenas o facilitador tem acesso sobre os participan-
tes e suas respostas.
3. O facilitador distribui as informaes sobre o projeto e solicita aos parti-
cipantes que respondam ao questionrio e gerem uma lista de requisitos
e individual e anonimamente o encaminhe para ele.
4. O facilitador consolida as diversas listas em uma nica e redistribui para
os participantes revisarem/complementarem. Esse o momento em que
cada participante considera o que foi proposto pelos demais e mantm,
complementa ou acata outras ideias.
5. A nova lista devolvida ao facilitador que, novamente, a consolida.
Esse processo pode se repetir quantas vezes forem necessrias, at que o faci-
litador resolva o consenso e deciso final. A Figura 11 representa o processo.

PROCESSOS DA ENGENHARIA DE REQUISITOS


79

Respostas aos
questionrios

Compilao e distribuio
das respostas

Respostas aos
questionrios revisadas
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Consenso e
deicso final
Figura 11: Processo mtodo Delphi para coleta de requisitos
Fonte: o autor.

OFICINAS

As oficinas renem partes interessadas multifuncionais para definir os requisi-


tos do produto a ser desenvolvido ou melhorado. As oficinas tm como objetivo
acionar o trabalho em equipe. Deve existir sempre um facilitador cujo papel
conduzir a equipe e promover a discusso entre os vrios stakeholders. As toma-
das de deciso so baseadas em processos bem definidos e com o objetivo de
obter um processo de negociao, mediado pelo facilitador. Algumas aborda-
gens que podem ser utilizadas em oficinas so exemplificadas a seguir:
QFD quality function deployment. O mtodo desdobramento da
funo de qualidade foi criado na dcada de 60 pelo japons Yoji
Akao e tem como objetivo principal permitir que a equipe de desen-
volvimento do produto incorpore as reais necessidades do cliente.
A primeira indstria a aplic-lo foi a Mitsubishi Heavy em 1972.
A Ford e a Xerox tambm utilizam esse mtodo. O site Infoescola
afirma que o QFD uma ferramenta que possibilita ouvir a voz do
cliente e orden-la, de modo a facilitar a anlise de suas necessidades

Levantamento e Anlise de Requisitos


80 UNIDADE III

que so transformadas em requisitos. Em geral, o QFD obedece a qua-


tro fases: planejamento do produto, desenvolvimento dos componentes,
planejamento do processo e planejamento da produo. A tcnica ori-
ginal desenvolvida por Akao, Figura 12, sofreu algumas adaptaes ao
longo do tempo, havendo, portanto, algumas variaes da matriz original.

Matriz de correlao
entre as
especificaes
do produto.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Como?
(ou especificaes
do produto)
Ordem de Importncia dos
Requisitos para o Cliente
Requisitos do cliente
(ou O Qu?)

Concorrncia
Matriz de Relaes

Anlise da
(entre o Como?
e o O Qu?)

Avaliao Tcnica
(ou Quanto?)
Figura 12: Matriz QFD original
Fonte: Faria (online).

JAD - joint application design. uma metodologia para definio de


requisitos criada pela IBM do Canad em 1977 e adaptada para o Brasil
em 1982, por Hugo Gattoni. uma oficina que busca promover que todos
os participantes compartilhem uma mesma viso do produto. No JAD,
todos os participantes so coautores da soluo e devem deter o mesmo
sentimento de responsabilidade sobre o seu desenvolvimento. A tcnica
JAD pode ser utilizada em vrios momentos durante o ciclo de vida de
um projeto: no planejamento, na definio dos requisitos e do escopo e
na etapa de estimativas de esforo e horas para o desenvolvimento. A tc-
nica JAD se divide em duas etapas, representadas pela Figura 13: Dados
sobre o projeto e Resultados Revisados. Cada etapa possui trs fases: (1)
Adaptao - preparar o material que ser utilizado durante as reunies,

PROCESSOS DA ENGENHARIA DE REQUISITOS


81

alocar e convidar os participantes selecionados para as reunies, adap-


tar o processo JAD ao produto que ser desenvolvido; (2) Sesso - so as
reunies propriamente ditas. Nessa fase, os requisitos so desenvolvidos
e documentados; (3) Finalizao - converter os requisitos extrados em
um documento de especificao de requisitos.

Os quatro princpios do mtodo JAD so:


a. Dinmica de grupo - facilita o entendimento do problema e das neces-
sidades das reas envolvidas no projeto. Os participantes compartilham
ideias e exploram a criatividade na criao da soluo.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

b. Recursos visuais usar tcnicas visuais que facilitam a comunicao e o


entendimento, por exemplo, utilizar na sala de reunio painis contendo
referncias e conceitos do projeto, indicadores magnticos, prottipos e
transparncias que servem para melhor comunicar e validar ideias durante
a definio do projeto.
c. Processo organizado e racional o JAD emprega anlise top-down com
atividades bem definidas, a fim de atingir a definio de objetivos, espe-
cificaes e projetos externos.
d. Documentao padro cada sesso JAD possui um documento de sada
padro que tem como objetivo registrar formalmente os resultados do
processo para que todos os participantes entendam as decises tomadas.
Geralmente, utiliza-se para esse documento a abordagem WYSIWYG
(do ingls what you se is what you get ou, em portugus, o que voc v
o que voc obtm).

PROJETO JAD PROJETO

Dados sobre Resultados


o projeto revisados

Agendas
Objetivos Resultados
Preparao Sesso Reviso
Dados Avaliaes
Prvios

Figura 13: Viso geral do JAD


Fonte: Luiz David (2012).

Levantamento e Anlise de Requisitos


82 UNIDADE III

Histria de usurio (user stories) so descries textuais de uma fun-


cionalidade requerida escrita do ponto de vista do usurio. As user stories
possuem uma caracterstica que deriva da metodologia gil de desen-
volvimento de sistemas que focam mais na comunicao do que na
documentao. As metodologias geis fornecem uma abordagem itera-
tiva e incremental para desenvolver e implementar projetos, com entregas
contnuas, flexibilidade de escopo e participao da equipe. Na prtica, se
o seu projeto, por alguma razo, necessita de uma documentao formal
que contemple todas as informaes referentes aos requisitos, sozinha,
as user stories no traro o resultado esperado. O foco das user stories a
discusso em torno dos itens, e no na escrita dos cartes. So descries

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
curtas de uma funcionalidade de um sistema. Os requisitos aqui tratados
como Histrias devem ser pensados sempre em nvel de negcio, por isso,
devem ser escritas sempre com o cliente presente. O cliente deve focar nos
objetivos do negcio. Por que voc quer que seja realizada essa histria?
essa deve ser a pergunta da equipe ao tentar determinar o objetivo de
uma histria. Histrias, geralmente, so escritas como ndices ou ttulos
para blocos de atividades, elas, usualmente, so colocadas em quadros
para planejamento e discusso. recomendado que cada histria seja
composta, no mnimo, por um ator, uma ao e uma funcionalidade. A
Figura 14 ilustra a composio de uma user story.

Como um [ator] eu quero/preciso de


/devo/gostaria de [ao] para
[funcionalidade].

Figura 14: Exemplo de user story card padro


Fonte: Primo (online).

PROCESSOS DA ENGENHARIA DE REQUISITOS


83

a. Ator: o proprietrio da histria de usurio. o interessado naquela fun-


cionalidade. recomendado descrever de forma especfica quem o ator
para ser mais fcil identificar o contexto da histria dentro do sistema.
b. Ao: representa o que o ator quer fazer. Realizando aquela ao, ele espera
alcanar seu objetivo dentro do sistema.
c. Funcionalidade: o resultado esperado aps a execuo da ao pela pers-
pectiva do ator. Tambm pode ser visto como justificativa. A Figura 15
apresenta um exemplo de user story.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Como um vendedor responsvel pelo


setor de livros eu quero procurar por
livros filtrando por nome para que seja
possvel verificar se o livro X est
disponvel para pronta entrega.

Figura 15: Exemplo de user story card


Fonte: Primo (online).

QUESTIONRIOS

O uso de questionrio indicado, por exemplo, quando h diversos grupos de


usurios que podem estar em diversos locais diferentes. Nesse caso, elaboram-se
pesquisas especficas direcionadas aos stakeholders identificados previamente.
Vrios tipos de questionrios podem ser utilizados: mltipla escolha, lista de
verificao e questes abertas com espaos em branco para uma descrio mais
informal. Lembre-se de que ningum gosta de ficar respondendo question-
rios complexos e, o mais importante, ningum quer perder tempo respondendo

Levantamento e Anlise de Requisitos


84 UNIDADE III

perguntas, por isso, o questionrio deve ser construdo de forma a minimizar o


tempo gasto em sua resposta.
Na fase de preparao do questionrio, deve ser indicado o tipo de
informao que se deseja obter. Assim que os requisitos forem definidos, o
analista deve elaborar o questionrio com questes de forma simples, clara
e concisa, deixar espao suficiente para as repostas que forem descritivas e
agrupar as questes de tpicos especficos em um conjunto com um ttulo
especial. O questionrio deve ser acompanhado por uma carta explicativa,
redigida por um alto executivo, para enfatizar a importncia dessa pesquisa

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
para a organizao.
Deve ser desenvolvido um controle que identifique todas as pessoas que
recebero os questionrios. A distribuio deve ocorrer junto com instru-
es detalhadas sobre como preench-lo e ser indicado claramente o prazo
para devoluo do questionrio. Ao analisar as respostas dos participan-
tes, feita uma consolidao das informaes fornecidas no questionrio,
documentando as principais descobertas e enviando uma cpia com essas
informaes para o participante, como forma de considerao pelo tempo
dedicado pesquisa.
Sotille et al (2014) recomendam alguns procedimentos para garantir uma
aplicao eficiente do questionrio:
Antes:
Definir objetivos do questionrio.
Decidir o que preciso saber para atingir os objetivos.
Expor claramente os objetivos pretendidos e a importncia da contribui-
o de cada stakeholder.
Desenvolver perguntas representativas e objetivas. Evitar perguntas dis-
cursivas, mas permitir que os usurios deixem comentrios gerais sobre
o projeto no final do questionrio.
Definir mtodo de tabulao para respostas.
Validar o questionrio em piloto com usurio de fcil acesso. Essa valida-
o permite testar o questionrio e o mtodo de tabulao.

PROCESSOS DA ENGENHARIA DE REQUISITOS


85

Durante:
Distribuir o questionrio com prazo suficiente para que o usurio res-
ponda sem presso.
Estar disponvel para dirimir eventuais dvidas.
Monitorar o recebimento dos questionrios.
Aps:
Tabular os dados.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Analisar o resultado da tabulao.


Remeter os dados tabulados para cada participante que respondeu ao
questionrio.

PESQUISAS

Como vimos, elicitar uma expresso normalmente atribuda atividade de


descobrir, identificar, deduzir, extrair ou obter informaes. Pesquisas em docu-
mentos organizacionais podem ser uma maneira de se conseguir identificar os
requisitos necessrios para determinar as funcionalidades de um novo produto
de software. Exemplos de documentos que podem ser analisados incluem plano
de negcio, registro de marketing, acordos, requisies de propostas, fluxo de
negcio, modelos lgicos de dados, repositrio de regras de negcio, documen-
tao, processos de negcio, casos de uso, registro de questes pblicas, polticas,
procedimentos, leis, cdigos etc.

ETNOGRAFIA

Etnografia uma tcnica de observao usada para compreender os requisitos


sociais e organizacionais. O engenheiro de requisitos se insere no ambiente de
trabalho onde o sistema ser usado. Ele observa o trabalho do dia a dia e anota
as tarefas reais nas quais os participantes esto envolvidos. A Wikipedia afirma

Levantamento e Anlise de Requisitos


86 UNIDADE III

que, por meio de uma observao direta das atividades realizadas durante um
perodo de trabalho de um funcionrio, possvel encontrar requisitos que no
seriam observveis usando tcnicas convencionais. Nessa tcnica, assume-se que
o representante do cliente observado desempenha as suas funes corretamente.
Enfim, encontraremos diversas tcnicas, como j comentei: mtodos em
que o foco a conversao, por exemplo, grupo focal, mapas mentais, diagrama
de afinidade, anlise de deciso multicritrios; outras tcnicas em que o foco
a observao, etnografia, protocolo de anlise; ainda, temos os mtodos anal-
ticos, como: reuso de requisitos, estudo de documentao/anlise de contedo,

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
laddering, sorteio de cartes; tambm, existem as tcnicas sintticas, como: pro-
totipao, questionrio de ambiente, storyboards. Todas elas possuem vantagens
e desvantagens a serem consideradas em relao complexidade do ambiente
de negcio onde seu projeto estar inserido. O importante conhec-las e saber
seus pontos fortes e fracos para aplic-las adequadamente em cada situao.
Uma vez levantados os requisitos, passamos para a atividade de anlise.
Nessa etapa, os requisitos levantados so usados como base para a modelagem
do sistema. Conforme vimos anteriormente, os requisitos, quando levantados
diretamente dos usurios, so escritos tipicamente em linguagem natural, pois
eles so fornecidos e devem ser compreendidos por pessoas que no so espe-
cialistas tcnicos. Na atividade de anlise, os requisitos podem ser detalhados
de maneira mais tcnica, utilizando, para isso, diversos tipos de modelos que,
por utilizarem representaes grficas, so, geralmente, mais compreensveis
do que descries detalhadas em linguagem natural (SOMMERVILLE, 2008).
Em essncia, a fase de anlise uma atividade de modelagem. A modelagem
nessa fase, dita conceitual, pois se preocupa com o domnio do problema, e no
com solues tcnicas para ele. Esse o momento em que a equipe de desenvol-
vimento ir interpretar as necessidades do cliente e desenhar o sistema. Esses
modelos ajudam o analista a entender a informao, a funo e o comporta-
mento do sistema.
Parece confuso quando descritas linearmente todas as atividades do processo,
na prtica, as atividades da engenharia de requisitos ocorrem em paralelo. Como?
Explico: durante o levantamento, uma anlise e uma especificao j estaro sendo
executadas de maneira indireta e alguns problemas so identificados e tratados,

PROCESSOS DA ENGENHARIA DE REQUISITOS


87

entretanto outros somente sero identificados por meio de uma anlise mais
detalhada. A Figura 16 nos apresenta um modelo da espiral da interao entre
levantamento e anlise de requisitos, com o propsito de facilitar a compreenso.
O levantamento o ato de identificar as necessidades do usurio, isto , os
requisitos do sistema. A anlise trata da constante observao e dos elementos do
ambiente onde o software ser implantado, checando todas as atividades que sero
envolvidas no sistema: quem faz, por que faz e se existem outras formas de ser
feito, considerando os dados e informaes que so gerados por essas atividades.
A especificao a descrio sistemtica e abstrata do que o sistema deve
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

fazer a partir dos requisitos levantados. Ela apresenta a soluo de como os


problemas levantados na anlise devem ser resolvidos pelo software em desenvol-
vimento, fechando o primeiro ciclo da engenharia de requisitos com a produo
do Documento de Requisitos e da Matriz de Rastreabilidade de Requisitos.
Naturalmente, os requisitos passaro por uma negociao e uma prvia validao
tanto dos stakeholders do lado do cliente quanto da equipe de desenvolvimento.
Esse o processo de gerncia de requisitos! A gerncia de requisitos ser estu-
dada na unidade IV.

Declarao informal de requisitos

Elicitao Anlise

Problemas
dos requisitos
Documentos de
especificao
dos requisitos
Negociao
Figura 16: Modelo da espiral da interao entre levantamento e anlise de requisitos
Fonte: Kotonya (1998).

A seguir, vamos estudar as demais atividades da engenharia de requisitos!

Levantamento e Anlise de Requisitos


88 UNIDADE III

NEGOCIAO

Com a lista geral de requisitos em mos, vamos, agora, para a fase de negociao
e priorizao dos requisitos junto aos stakeholders do lado do cliente.
Pressman (2010) afirma, e concordo com ele, que muito comum que clientes
e usurios peam mais do que pode ser conseguido, e tambm muito comum
que diferentes clientes ou usurios proponham requisitos conflitantes e argu-
mentem que a sua verso a essencial para as necessidades do sistema.
Embora exista a mxima o cliente tem sempre razo, alguns pontos devem

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ser considerados e discutidos para garantir que o produto final atinja seu obje-
tivo, as restries de prazo, custos, recursos, quase sempre vm de encontro com
a realizao dos desejos do cliente, nesse ponto, a equipe de desenvolvimento
deve deixar as limitaes do projeto claras e iniciar um processo de negociao,
com o intuito de acordar entre as partes, quanto aos requisitos que sero consi-
derados prioritrios e quais participaro do escopo do projeto.
A priorizao dos requisitos pode determinar tanto o sucesso do projeto
como o seu fracasso e essas decises no so simples ou binrias. Pressman (2010)
sugere que clientes, usurios e demais interessados ordenem os requisitos e dis-
cutam os conflitos e prioridades at se chegar a um consenso geral e o escopo
geral do produto ser definido. Sylvia (2008) sugere que, dentre os principais pro-
blemas, os mais crticos so os relacionados a: negcio, clientes e implementao.
De forma geral, o que se sugere que os riscos associados a cada requisito
sejam identificados e analisados para, ento, elaborar estimativas de esforo de
desenvolvimento, de forma a avaliar o impacto de cada requisito no custo do
projeto e no prazo de entrega. Dessa forma, requisitos podem ser eliminados,
combinados ou modificados para se alcanar o consenso entre cliente e equipe
de desenvolvimento (PRESSMAN, 2010).
Existem vrias tcnicas para priorizao dos requisitos, por exemplo:
Atribuio numrica - prope a atribuio de uma escala de notas para
cada requisito. Os requisitos so agrupados em diferentes grupos, nos
quais os stakeholders podem relacionar uma classificao confivel.
rvores de Busca Binrias (BSTs) - um algoritmo comumente usado
em busca de informao e que pode ser facilmente adaptado para prio-
rizar uma grande quantidade de requisitos.
PROCESSOS DA ENGENHARIA DE REQUISITOS
89

Analytic Hierarchy Process (AHP) uma tcnica de tomada de decises em


situaes de mltiplos objetivos. A tcnica prov um ndice de consistncia
utilizado para verificar a fidelidade dos resultados. Esse ndice calcu-
lado de acordo com o nmero de requisitos e com os valores atribudos
em uma matriz. Por se tratar de uma tcnica complexa e de difcil ras-
treabilidade dos resultados, a AHP no bem aceita comercialmente.
Abordagem Custo-Valor (Cost-Value Approach) - proposta por Karlsson
(1997), ela prioriza os requisitos de acordo com seus custos e valores relativos.
Essa tcnica simplifica os resultados providos pela aplicao da tcnica AHP,
de forma clara e objetiva. Assim, ela une a preciso da AHP com resultados
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mais transparentes e visveis aos stakeholders. Tambm, no bem aceita


comercialmente, pois exige a aplicao de AHP em dois momentos, tornan-
do-se muito custosa na medida em que o nmero de requisitos aumenta.
Value-Oriented Prioritization (VOP) - avalia e ordena requisitos de acordo
com o impacto que eles tero em valores de negcios especficos da orga-
nizao e, a partir da, escolhem-se quais requisitos sero mais benficos
para a organizao como um todo, e no para um stakeholder em parti-
cular. Para a priorizao, so atribudos pesos a cada rea da organizao
de acordo com seu nvel de importncia, pode-se tambm atribuir pesos
para os riscos dos requisitos e consider-los no resultado final.

O levantamento, a anlise e a negociao de requisitos esto intimamente liga-


dos e fazem parte de um processo em espiral. Esse processo deve ser seguido
at a satisfao de todas as partes envolvidas, sendo um processo influenciado
no s pela lgica e argumentos tcnicos, mas tambm pela poltica da organi-
zao e pela personalidade dos stakeholders (SOMMERVILLE; SAWYER, 1997).

A mudana no vir se esperarmos por outra pessoa ou outros tempos. Ns


somos aqueles por quem estvamos esperando. Ns somos a mudana que
procuramos.
Fonte: Barack Obama.

Negociao
90 UNIDADE III

VALIDAO DOS REQUISITOS

Depois de levantados e negociados os requisitos, chegou o momento de revisar


tudo quanto ambiguidade, s omisses e s inconsistncias. A validao dos
requisitos, segundo Sommerville (2008), garante que a necessidade real do usu-
rio esteja descrita corretamente no Documento de Requisitos. Isso est parecendo
redundante para voc? Voc deve estar se perguntando: no foi exatamente isso
que fizemos durante a negociao? Vamos esclarecer.
Anlise e Negociao respondem pergunta: foram elicitados os requisitos

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
corretos? A Validao responde: os requisitos foram elicitados corretamente?
Isto , em um primeiro momento, voc ir certificar se todos os requisitos que
devem ser considerados foram realmente, eles garantem a completude do sis-
tema que ser desenvolvido, se no faltou nada a ser levantado. Na segunda,
validao, voc os corrige.
O objetivo da validao de requisitos descobrir erros nos requisitos docu-
mentados. Como j estudamos, o Documento de Requisitos referncia para
todas as demais atividades de desenvolvimento. Nesse sentido, a validao
extremamente importante, pois o custo para correo de um requisito nessa
fase bem inferior ao custo nas fases posteriores, implementao ou testes,
por exemplo.
Nessa fase, se uma divergncia for encontrada, levanta-se novamente o
requisito, sem parar o desenvolvimento ou os testes, o que comprometeria cus-
tos e prazos do projeto. Carla Oliveira (2014) sustenta essa teoria afirmando que
erros afetam negativamente todas as atividades posteriores de desenvolvimento.
Um erro de requisito descoberto quando o sistema j est em produo ou em
operao exige a reviso de todos os artefatos: cdigo fonte, artefatos de testes e
descries de arquitetura, o que implica custos significativos.
Para tal atividade, Sommerville (2008) prope algumas tcnicas de validao,
tais como revises tcnicas de requisitos, prototipao e gerao de casos de teste.

PROCESSOS DA ENGENHARIA DE REQUISITOS


91

A reviso tcnica de requisitos pode ser formal ou informal. A reviso tc-


nica formal o principal mecanismo para validao de requisitos, trata-se de
um processo no qual uma equipe formada por engenheiros de software, clien-
tes, usurios ou outros interessados examinam as especificaes, procurando por
erro de registro ou de interpretao, por requisitos que precisem de mais escla-
recimento, ou por aqueles em que faltam informaes. Nessa reunio, devem
tambm ser considerados os requisitos conflitantes e os intangveis. A reviso de
requisitos informal um debate que ocorre entre equipe tcnica e cliente com o
objetivo de identificar problemas e propor solues.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Na prototipao, os requisitos so apresentados de maneira mais ldica, por


exemplo, no formato de telas para o usurio, facilitando a interpretao das roti-
nas a serem desenvolvidas.
A tcnica de validao gerao de casos de testes verifica se o requisito
implementvel. Isto significa: fcil de ser interpretado e codificado. Caso con-
trrio, ele deve ser reconsiderado. Parece complicado testar um requisito antes
da codificao, mas no impossvel, considerando a prtica e experincia da
equipe de desenvolvimento.
Por exemplo, nas metodologias geis de desenvolvimento de software que
esto dominando as fbricas de software atuais , os requisitos so expressos em
cenrios, tambm conhecidos como users stories (histrias de usurios), conver-
samos um pouco sobre isso quando estudamos as tcnicas de levantamento de
requisitos. Partindo das informaes adquiridas, a equipe de desenvolvimento
estima o esforo e recursos necessrios para a implementao e o cliente atri-
bui uma prioridade para cada histria, tendo como referncia a importncia da
funcionalidade para o sistema.
Por fim, Oliveira (2014) prope um cheklist para a validao de requisitos.
A tcnica checklist deve ser usada durante a reviso tcnica formal de requisi-
tos e tem como objetivos:

Validao dos Requisitos


92 UNIDADE III

Descobrir erros de funo, de lgica ou de implementao para qualquer


representao do software.
Verificar que o software em questo atende aos requisitos especificados.
Garantir que o software foi representado de acordo com padres
pr-definidos.
Garantir que o software seja desenvolvido de maneira uniforme.
Desenvolver projetos mais gerenciveis.
Para isso, podemos considerar a lista de verificaes que Sommerville (2008)

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
prope:
1. Verificao de validade. Um sistema possui diversos usurios com necessi-
dades diferentes, nessa validao, a equipe ir identificar se certas funes
citadas como necessrias por um usurio so, realmente, indispensveis
para o todo.
2. Verificao de consistncia. Identificar se existem requisitos que dizem
a mesma coisa de uma forma diferente, se descrevem uma mesma fun-
o sob pontos de vista de usurios diferentes.
3. Verificao de completeza. O documento de requisito deve descrever
todas as funes e todas as restries exigidas pelos usurios do sistema.
4. Verificao de realismo. Validar se existe tecnologia para a implementao
dos requisitos. Nessa validao, deve-se, tambm, considerar os custos e
o prazo determinado para o desenvolvimento do sistema.
5. Facilidade de verificao. Observar se os requisitos esto escritos de forma
compreensvel para todas as partes envolvidas no processo de desenvol-
vimento do sistema, o que os torna verificveis.

Oliveira (2014) afirma que o checklist auxilia o analista de requisitos ou o repre-


sentante da equipe de desenvolvimento a coordenar a reunio de reviso formal de
requisitos, colaborando para o foco dos revisores nas caractersticas importantes.
Os checklists devem ser aplicados a documentos de anlise, projeto, codificao
e testes. Um exemplo de checklist apresentado na Figura 17.

PROCESSOS DA ENGENHARIA DE REQUISITOS


93

ITEM ITEM PARA VERIFICAO SIM NO

No ambguo: no ambguo se, e somente se, cada requisito declarado seja suscetvel a apenas
uma interpretao.
1 Cada requisito est descrito com clareza, conciso e sem ambiguidade?

Consistente: consistente se, e somente se, nenhum dos requisitos do documento, tomado
individualmente, est em conflito com qualquer outro requisito do mesmo documento.
2 Existem requisitos conflitantes?
Completo: completo se, e somente se, conter toda e apenas a informao necessria para que
o software correspondente seja produzido.

3 Existem requisitos implcitos?


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

4 Os requisitos exibem a distino clara entre funes, dados e restries?


5 As restries e dependncias foram claramente descritas?
6 Existem requisitos que contm algum nvel desnecessrio de detalhe do projeto?
7 Os requisitos definem todas as informaes a serem apresentadas aos usurios?
8 Os requisitos descrevem as respostas do sistema ao usurio devido s condies de erro?
9 Existem situaes no tratadas pelos requisitos que precisam ser consideradas?
10 O documento contm realmente toda a informao prometida em sua introduo?

Figura 17: Modelo Checklist de Validao de Requisitos


Fonte: Oliveira (online).

Para facilitar o entendimento, acompanhe o processo abaixo, representado pela


Figura 18, que demonstra o que seriam as possveis entradas e sadas da etapa
de validao.

1. Especificaes de
Requisitos
1. Lista de Problemas
2. Conhecimento Validao de
Organizao Requisitos 2. Lista de Aes

3. Padres
Organizao

Figura 18: Entradas e Sadas do Processo de Validao de Requisitos


Fonte: adaptada de Kotonya (1998).

A entrada 1 Especificao de Requisitos deve ser uma verso completa


do Documento de Requisitos, organizada de acordo com os padres da orga-
nizao, contemplando todos os requisitos que comporo o software a ser

Validao dos Requisitos


94 UNIDADE III

desenvolvido. O Conhecimento da Organizao (entrada 2 no processo) no


tangvel, mas, na prtica, muito importante ser considerado, uma vez que
as pessoas envolvidas na validao de requisitos devem participar por dete-
rem o conhecimento sobre as terminologias particulares, a execuo prtica
das rotinas que sero automatizadas pelo novo sistema e, principalmente, o
perfil dos usurios que ofereceram as informaes durante o levantamento de
requisitos e que iro utilizar o sistema depois de pronto. A entrada 3, Padres
Organizacionais, garante que a validao ir considerar que todos os padres
relevantes para o documento de requisitos devem ser entrada para o processo

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
de validao.
Como sadas do processo, teremos: 1. Lista de Problemas, recomendado
que seja organizada por tipo de problema (inconsistentes, incompletos, intan-
gveis etc.) para facilitar as solues e agilizar a reunio tcnica de reviso; e 2.
Lista de Aes, que representa a lista de atividades em resposta aos problemas
listados, acordada com os envolvidos no processo.
No final da validao, temos praticamente o documento de requisitos pronto,
que corresponde entrega final da engenharia de requisitos. No prximo item,
falaremos mais desse documento. Vamos l?

Um projeto uma verdadeira guerra de interesses. Descobrir, desde o come-


o, como gerenci-los a chave para o sucesso.
Fonte: Stakeholder (online).

ESPECIFICAO DE REQUISITOS

Quando conversamos sobre os conceitos fundamentais da engenharia de requisi-


tos, falamos sobre o Documento de Requisitos, l, tnhamos como foco a estrutura
de apresentao do documento, agora, estudaremos um pouco mais sobre como
escrever os requisitos para document-los.

PROCESSOS DA ENGENHARIA DE REQUISITOS


95

Vimos, na unidade dois, que essa documentao descreve os requisitos que


foram coletados e como eles permitiro atingir os objetivos do sistema a ser
desenvolvido. Aprendemos, tambm, que, inicialmente, os requisitos podem ser
descritos de um modo geral (alto nvel) para que sejam detalhados posteriormente.
Primeiro, vamos considerar o pblico-alvo dos requisitos, a quem se desti-
nam, quem sero os leitores e quais sero os propsitos da leitura:
Clientes: leem para validar.
Gerentes: utilizam para solicitar uma proposta e para planejar o processo
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

de desenvolvimento.
Programadores: utilizam para entender o que deve ser desenvolvido.
Testes: utilizam para planejar os testes de validao do sistema.
Manuteno: utiliza para compreender o sistema e suas relaes.

Agora, considere os parmetros sugeridos para o registro dos requisitos e os


definidos para a sua validao. Releia o requisito e aplique um teste rpido para
verificar se os critrios foram atingidos:
1. Necessidade. Depois de escrito, pergunte: qual ser a pior coisa que
poder acontecer se esse requisito no for includo? Se no encontrar-
mos qualquer problema, ento, porque, provavelmente, no precisamos
do requisito (esta funo necessria?).
2. Verificvel. Durante e aps a escrita, leia o que est produzindo e observe
se est entendvel para todos os leitores, como estudamos acima. Esse
aspecto importante porque ajudar a assegurar que o requisito veri-
ficvel (como posso testar essa funo?).
3. Realizvel. Em algumas literaturas, poder encontrar este parmetro
nomeado como atingvel. Observe se o requisito registrado pode ser
desenvolvido (programado) em relao tecnologia disponvel, ora-
mento e prazo. No caso de dvida, investigue, converse, se ainda assim
persistir a dvida, descreva junto com o requisito o objetivo que deseja
alcanar com a execuo da rotina ali descrita, porque, ainda que ele seja
exequvel tecnicamente, poder no ser atingvel devido a outros crit-
rios ( atingvel?).

Especificao de Requisitos
96 UNIDADE III

4. Claro: cada requisito deve expressar uma nica ideia, geralmente


frases simples especificam um bom requisito (est claro o que pre-
cisa ser feito?).

frequente a utilizao da linguagem natural para a descrio dos requisitos,


principalmente quando a especificao est relacionando os requisitos de usu-
rio. Para esse nvel de especificao, Summerville (2008) recomenda algumas
regras bsicas:
a. Crie um formato padro para sua escrita e garanta que todos os requisi-
tos sero escritos seguindo esse padro, assim, omisses se tornam menos

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
frequentes e facilita a verificao dos requisitos.
b. Utilize uma linguagem coerente, use variaes de tempo de verbos para
indicar o que obrigatrio ser feito e o que desejvel. Por exemplo, a
utilizao do verbo deve para requisitos obrigatrios, e sua variao deve-
ria para aqueles requisitos que so desejveis. Com isso estabelece-se
uma regra ou padro em que os requisitos obrigatrios so especificados
com o verbo deve frente, enquanto aqueles requisitos que, se no forem
implementados, no causaro impacto no objetivo do produto final, sero
especificados com o verbo deveria na sua descrio.
d. Destaque as partes mais importantes da descrio do requisito.
e. No utilize jarges de informtica ou da regra de negcio para a qual o
requisito ser desenvolvido, quando termos tcnicos inerentes ao domnio
da aplicao forem inevitveis, procure detalh-lo da forma mais com-
pleta possvel. Por exemplo:
RF001 O sistema deve validar os dados informados no campo desti-
nado ao nmero do CPF.
RF002 O sistema deve classificar a apresentao em tela da lista de clien-
tes pelo campo nome.
RF003 O sistema deveria classificar a apresentao em tela da lista de
clientes pelo campo sobrenome.
RF004 O sistema deve exibir a mensagem de alerta ATENO!
Quantidade em estoque insuficiente quando o campo quantidade con-
tiver valor mais alto que o campo quantidade de itens em estoque.

PROCESSOS DA ENGENHARIA DE REQUISITOS


97

Os exemplos nos mostram que os requisitos funcionais 001, 002 e 004 so obri-
gatrios, enquanto o 003 somente desejvel. Procure especificar as aes em
sua sequncia e registre, sempre que possvel, uma ao por requisito.
A descrio dos requisitos de sistema, em que o nvel de especificao mais
tcnico tambm pode ser feita utilizando linguagem natural, entretanto, quando
a especificao exige mais detalhamento, podem surgir problemas.
A linguagem natural possui uma ambiguidade intrnseca, a interpretao de
um conceito depende tanto do interlocutor quanto do receptor da mensagem.
Ela, tambm, muito flexvel, possvel dizer a mesma coisa de muitas manei-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

ras diferentes, alm de no possibilitar uma padronizao.


Sommerville (2008) sugere, para a especificao de requisitos de sistema,
algumas linguagens padronizadas:
Linguagem natural estruturada: os requisitos so escritos em linguagem
natural em um formulrio padro ou template. Cada campo fornece infor-
maes sobre um aspecto do requisito.
Linguagem de descrio de projeto: essa abordagem usa uma linguagem
como de programao, mas com caractersticas mais abstratas para espe-
cificar os requisitos, definindo um modelo operacional do sistema. Essa
abordagem pouco usada atualmente, embora possa ser til para as espe-
cificaes de interface.
Notaes grficas: para definio dos requisitos funcionais do sistema, so
usados modelos grficos, suplementados por anotaes de texto; diagra-
mas de caso de uso e sequncia da UML.
Especificaes matemticas: essas notaes so baseadas em conceitos
matemticos, como mquinas de estado finito ou conjuntos. Embora essas
especificaes possam reduzir a ambiguidade de um documento de requi-
sitos, a maioria dos clientes no entende uma especificao formal. Por
ser muito tcnica, no possvel que o cliente verifique o que as infor-
maes representam e automaticamente ficam relutantes em aceit-las.

Para nossos estudos, adotaremos a abordagem da Linguagem Natural Estruturada,


que, segundo Summerville (2008), mantm a facilidade de expresso da lingua-
gem natural, mas garante um nvel de padronizao. Na utilizao da linguagem
natural estruturada, podem-se estabelecer terminologias e utilizar template padro

Especificao de Requisitos
98 UNIDADE III

para a especificao dos requisitos do sistema, possibilitando um agrupamento


mais eficiente dos requisitos.
Essa abordagem elimina alguns problemas da linguagem natural, mas neces-
srio, ainda, um cuidado quanto ambiguidade no momento da descrio do
requisito. Deve-se criar um ou mais templates padro em funo do sistema que
ser desenvolvido e das necessidades, do detalhamento necessrio. Quando um
formulrio padro usado para especificar os requisitos funcionais, as seguin-
tes informaes devem ser consideradas:
Descrio da funo ou entidade.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Descrio de suas entradas e de onde elas vieram.
Descrio de suas sadas e para onde elas iro.
Informaes sobre os dados necessrios para o processamento e outras
entidades usadas.
Descrio da ao a ser tomada.
Condies pr e ps (se for o caso).
Os efeitos colaterais (se houver) da funo.

Para a atividade de levantamento de requisitos do nosso curso, foi definido o


seguinte formulrio-padro:

Funo RF UC PR
Descrio / Ao
Entrada
Sada
Pr-condio
Ps-condio
Stakeholder

Em que:
Funo: identifica a Funo do Requisito.

PROCESSOS DA ENGENHARIA DE REQUISITOS


99

RF: identificao do Requisito. Pode ser numrico, ou outro cdigo que


decida utilizar. Por exemplo: RF001, RF002, RNF003 etc.
UC: representa, o Caso de Uso, mtodo de especificao de requisito da
UML, uma representao grfica, que pode ser utilizada para auxiliar
na especificao de requisitos mais complexos e de difcil compreenso
somente descritiva. Tambm corresponde a um cdigo de identificao
do Use Case. Por exemplo: UC001, UC002 etc.
PR: representa a prioridade estipulada pelo stakeholder para o desenvol-
vimento do requisito.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Descrio/Ao: campo destinado especificao da funo do requi-


sito e da ao a ser tomada.
Entrada: entradas necessrias para o processamento da funo.
Sada: sadas/resultados produzidos com a realizao da funo do
requisito.
Pr-condies: o que j deve ter ocorrido ou estar disponvel antes da
execuo do requisito, por exemplo, <criar nota fiscal> deve preceder
<modificar nota fiscal>.
Ps-condies: que devem ser verdadeiras quando a execuo do requi-
sito se completar, por exemplo, <nota fiscal modificada e consistente>.
Stakeholder: identificar o tipo (grupo) ou nome do stakeholder solici-
tante desse requisito. Esse formulrio incorporado ao Documento de
Requisitos no formato de tabela.

A seguir, para ilustrar e auxiliar no aprendizado, apresento um exemplo do pro-


fessor Bruno Calegaro, da Universidade Federal de Santa Maria. Ele demonstra
a especificao de requisitos para um sistema de Bomba de Insulina, primeiro
na verso em linguagem natural e, na sequncia, na verso linguagem natural
padronizada:
Linguagem Natural:

Especificao de Requisitos
100 UNIDADE III

3.2 O sistema deve medir o acar no sangue e fornecer insulina, se necessrio,


a cada dez minutos. (Mudanas de acar no sangue no relativamente lentas,
portanto, medies mais frequentes so desnecessrias; medies menos fre-
quentes podem levar a nveis de acar desnecessariamente elevados.)
3.6 O sistema deve, a cada minuto, executar uma rotina de autoteste com as
condies a serem testadas e as aes associadas definidas no Quadro 4.3 ( A
rotina de autoteste pode descobrir problemas de hardware e software e pode
alertar o usurio para a impossibilidade de operar normalmente.)
Fonte: Calegaro (2013, p. 10).

Linguagem Natural Estruturada:

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
BOMBA DE INSULINA/SOFTWARE DE CONTROLE/SRS/3.3.2

Funo Calcular as doses de insulina: nvel seguro de acar


Descrio Calcula a dose de insulina a ser fornecida quando o nvel de
acar esta na zona de segurana entre trs e sete unidades
Entradas Leitura atual de acar(r2), duas leituras anteriores (r0 e r1)
Fontes Leitura atual da taxa de acar pelo sensor. Outras leituras
de memria
Sadas CompDose a dose de insulina a ser fornecida
Destino Loop principal de controle
Ao CompDose zero se o nvel de acar esta estvel ou
em queda ou se o nvel esta aumentando, mas a taxe de
aumento esta diminuindo. Se o nvel esta aumentando e a
taxa de aumento esta aumentando, ento CompDose cal-
culado dividindo-se a diferena entre o nvel atual de acar
e o nvel anterior por quatro e arredondando-se o resultado.
Se o resultado arredondado para zero, ento CompDose
definida como a dose mnima que pode ser fornecida
Requisitos Duas leituras anteriores, de modo que a taxa de variao do
nvel de acar pode ser calculada
Pr-Condies O reservatrio de insulina contem, no mnimo, o Maximo da
dose nica permitida de insulina
Ps-Condies R0 substituda por r1 e r1 substituda por r2
Efeitos colaterais Nenhum
Fonte: Calegaro (2013, p. 13).

PROCESSOS DA ENGENHARIA DE REQUISITOS


101

Quando se tem pouco acesso ou informao nenhuma sobre o que se deseja


desenvolver/produzir, inevitavelmente voc tender a produzir definies com
base em dedues sobre o assunto. Essas definies podem no representar o
que o cliente deseja para o seu produto.
Para o problema de insuficincia de informao, a soluo : busque-as.
Visite a organizao do cliente, converse com os usurios, levante documentos,
desenhe esquemas, pesquise atividades semelhantes ou, at mesmo, sistemas
concorrentes, fato , ser necessrio ir a campo e interagir. Para o caso de no
existir nenhuma informao, registre suas hipteses associadas a cada requisito,
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

isso ajudar nas etapas de negociao e validao.


Outra dica para escrever seus requisitos: separe funcionalidade de imple-
mentao. frequente a especificao ter a ver com a implementao e no com
a necessidade. As especificaes devem referir o que necessrio para o sistema
e no como vai ser disponibilizado ou programado. Para evitar a especificao de
implementaes, pergunte-se: por que precisamos deste requisito? Por exemplo:

Projeto: Desenvolver um sistema para gerenciamento de requisitos.


Requisito Funcional: RF001 Fornecimento de uma base de dados.
Pergunta:
Por que precisamos fornecer uma base de dados?
Respostas:
1. Disponibilizar capacidade para o acompanhamento dos requisitos.
2. Disponibilizar capacidade para adicionar atributos aos requisitos.
3. Disponibilizar a possibilidade de ordenar os requisitos.

Observe que as respostas so claramente os requisitos reais, isto , so as neces-


sidades, elas que deveriam representar o RF001. J a descrio: Fornecimento
de uma base de dados problema para a implementao.
Sempre pergunte ao seu requisito para que voc precisa dele e verifique se
a resposta te remete para uma ou mais necessidades. Se isso ocorrer, refine o
requisito, separando a necessidade da implementao, seno voc tem a garan-
tia de que definiu a funo da maneira correta.

Especificao de Requisitos
102 UNIDADE III

Por fim, lembre-se sempre: os requisitos no devem ser dbios, devem ser
mensurveis, devem possibilitar testes, devem ser investigveis, completos, con-
sistentes e aceitveis para todas as partes envolvidas.
Os atributos de qualidade aplicados nos requisitos so, basicamente, os mes-
mos aplicados na fase de Validao dos requisitos:
1. No Ambiguidade: cada requisito deve possuir, apenas, uma interpretao.
2. Completude: a capacidade de cada requisito especificar claramente seu
assunto, objetivo.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
3. Consistncia: a capacidade de cada requisito no ser contraditrio a outro.
4. Correo/Exatido: a capacidade do requisito de estar correto.

Escrevendo assim, parece uma tarefa fcil, no se engane, no subestime este tra-
balho. Pronto. Sabemos como ele tem que ser! Agora, s praticar!

ESPECIFICAO DE REQUISITO POR CASO DE USO

Caso de Uso um diagrama da UML, Figura 17, utilizado para elicitao de


requisitos. Por ser grfico, pode facilitar na compreenso de alguns requisitos.
Pode ser utilizado sozinho ou acompanhado de especificao detalhada dos casos
de uso em linguagem natural.
Para aprender de forma satisfatria como especificar um requisito utilizando
o diagrama de Caso de Uso, seria necessria uma disciplina especfica para isso,
o objetivo desta seo apresentar, de forma generalizada, o Caso de Uso e rela-
cionar uma tcnica de modelagem com o contedo apresentado.
Um modelo Caso de Uso descreve uma funo proposta para o sistema a ser
desenvolvido. Ele deve representar uma interao entre um utilizador (humano
ou mquina) e o sistema. Essa interao deve representar uma nica funciona-
lidade, por exemplo: faz pagamento ou ver detalhes do pagamento.
Cada Caso de Uso descreve a funcionalidade a ser construda no sistema
proposto; o que pode incluir a funcionalidade de outro Caso de Uso ou esten-
der outro Caso de Uso com seu prprio comportamento.

PROCESSOS DA ENGENHARIA DE REQUISITOS


103

Login

<<extend>>

CLIENTE
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Registrar
como cliente

Figura 18: Exemplo de Caso de Uso


Fonte: o autor.

Casos de Uso so tipicamente relacionados com atores, Figura 19, que so


entidades, pessoas ou no, que usam ou interagem com o sistema para realizar
alguma rotina.

ATOR
Figura 19: Representao da entidade Ator
Fonte: o autor.

Um Caso de Uso pode incluir a funcionalidade de outro como parte de seu


processamento. Geralmente, esse relacionamento denominado Include. O pro-
cesso Include chamado toda vez que o caminho bsico executado.
Como no exemplo da Figura 20, para executar a funo do requisito: o sis-
tema deve permitir ao usurio vendedor escolher na lista de pedidos de cliente a
ordem de classificao por cliente. Antes de alterar a ordem, o caso de uso <ordem
de classificao> ir incluir (Include) o caso de uso <alterar ordem de classifica-
o> toda vez que for executado.

Especificao de Requisitos
104 UNIDADE III

<<include>> Alterar
Ordem de ordem de
classificao classificao
VENDEDOR

Um caso de uso pode ser includo por um ou mais outros casos de uso. Esse
procedimento ajuda a reduzir redundncia, reutilizando um componente que
comum e que pode ser reutilizado. O Include denominado como um tipo de
relacionamento do diagrama de caso de uso.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Outro tipo de relacionamento o Extend. O Atributo Extend possibilita
que um caso de uso estenda o comportamento de outro, nesse caso, diferente
do Include, quando circunstncias excepcionais so encontradas. Por exem-
plo, o requisito: o sistema deve exigir a aprovao de usurio mster para alterar
dados do pedido de cliente. Para elicitar esse requisito, o caso de uso <obter a
aprovao> dever, quando necessrio, estender o comportamento normal do
caso de uso <alterar pedido de cliente>, permitindo o acesso. Como apresen-
tado na Figura 20.

Alterar <<extend>>
Pedido Obter
de cliente Aprovao

VENDEDOR
Figura 20: Diagrama de Caso de Uso: Alterar Pedido de Cliente
Fonte: o autor.

Include e Extend so relacionamentos que podem ocorrer somente entre


casos de uso. A modelagem por caso de uso permite, alm do relacionamento
entre casos de uso, relacionamento entre atores e entre atores e casos de uso.
Os relacionamentos entre atores so comunicao (ou associao), repre-
sentado por uma seta de base aberta, e a especializao (ou generalizao),
representado por uma seta de base fechada.
Um relacionamento de comunicao representa que os dois atores, de forma
uni ou bidirecional, realizam uma troca de informao ou de mensagem, que
tem significado formal para o sistema a ser desenvolvido.

PROCESSOS DA ENGENHARIA DE REQUISITOS


105

O relacionamento entre um ator e um caso de uso expressa sempre uma


comunicao. Um ator, enquanto entidade externa, no pode assumir nenhum
relacionamento estrutural com o sistema computacional.

O Documento de Requisitos a especificao das caractersticas operacio-


nais do sistema de software a ser produzido, permite construir modelos que
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

descrevem atividades funcionais, classes de dados, relacionamentos e flu-


xo de dados. Existem vrias tcnicas para a modelagem dos requisitos de
software, a UML (Unified Modeling Language ou Linguagem de Modelagem
Unificada) uma delas. A UML permite uma modelagem orientada a obje-
tos, que possibilita, por meio de diagramas, planejar e definir toda a estrutu-
ra de fluxo de dados do sistema a ser desenvolvido.
Aprenda mais sobre a UML acessando os links a seguir:
Devmedia - Introduo a UML Unified Modeling Language ou Lingua-
gem de Modelagem Unificada: <http://www.devmedia.com.br/introdu-
cao-a-uml-unified-modeling-language-ou-linguagem-de-modelagem-
-unificada/6928#ixzz3ZeYZMXWJ>. Acesso em: 24 jul. 2015.
OMG - The Object Management Group is an international,
open membership, not-for-profit technology standards consortium:
<http://www.uml.org/>. Acesso em: 24 jlu. 2015.
Fonte: o autor.

CONSIDERAES FINAIS

Estudamos, nesta unidade, o processo de engenharia de requisitos, nesse ponto,


entendemos por que considerado um dos mais importantes processos da enge-
nharia de software.
Requisitos bem especificados favorecem todas as outras atividades do pro-
cesso de desenvolvimento de software, garantindo, ainda, que seja realizado
dentro do custo e prazo estabelecido e, mais importante, que satisfaa a neces-
sidade do cliente.

Consideraes Finais
106 UNIDADE III

Estudamos que so quatro as principais atividades para realizao da enge-


nharia de requisitos. A primeira delas o levantamento de requisitos, o momento
em que o cliente vai declarar sua expectativa quanto ao sistema que ser desen-
volvido e a equipe de desenvolvimento levanta, em um primeiro momento, em
linguagem natural e no to formal, os requisitos funcionais e suas restries.
Aprendemos que existem vrias tcnicas para o levantamento de requisitos, por
exemplo, a entrevista uma tcnica na qual o engenheiro de requisito realiza
uma conversa com os diferentes stakeholders envolvidos no processo de desen-
volvimento, com o objetivo de definir quais so os requisitos necessrios para

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
a fabricao do software. Em seguida, as fases de negociao e validao dos
requisitos, o que garantir que sejam coesos, claros, no ambguos e rastreveis.
Na ltima etapa, verificamos formas de especificar os requisitos no Documento
de Requisitos. Os requisitos devem ser descritos de uma maneira que possibi-
lite que sejam verificados e em uma linguagem ou padronizao que possa ser
compreendida por leitores tcnicos e no tcnicos.
Depois de conhecer todos os processos e entender por que so necessrios,
no podemos mais subestimar a importncia do requisito no desenvolvimento
de software. Sabemos que, na prtica do desenvolvimento de software, temos a
tendncia de no nos prolongarmos na fase do levantamento e partir logo para
a implementao, mas, considerando tudo que foi apresentado at agora, voc
percebe quais seriam os impactos no projeto? Consegue perceber por que tantos
projetos de software no cumprem prazos, nem custos, muito menos atendem s
necessidades do cliente? Vai, agora, aplicar toda essa teoria na prtica?

PROCESSOS DA ENGENHARIA DE REQUISITOS


107

1. Processos da engenharia de requisitos podem variar muito em funo das carac-


tersticas dos projetos e, at mesmo, das organizaes. Pressman (2010) organiza
as atividades de engenharia de requisitos montando o processo representado
pelas atividades constantes em qual das alternativas abaixo?
a) Levantamento, Elaborao, Negociao, Especificao, Validao e Gesto.
b) Levantamento, Anlise, Documentao, Verificao/Validao e Gerncia.
c) Anlise, Levantamento, Documentao e Gerncia.
d) Levantamento, Elaborao, Negociao, Especificao e Gesto.

2. A Elicitao de requisitos, fase na engenharia de requisitos, envolve tcnicas de


coleta de informaes. Uma delas ocorre em ambiente informal, onde toda ideia
considerada como uma possvel soluo de um problema, nessa tcnica, cr-
ticas so proibidas e todas as sugestes apresentadas so encorajadas, mesmo
que paream, em um primeiro momento, estranhas e fora de contexto. Assinale
a alternativa que contenha a tcnica com essas caractersticas:
a) Prototipao.
b) Entrevista.
c) Questionrio.
d) Brainstorming.
e) Anlise de protocolos.

3. So tcnicas para a elicitao de requisitos de um software:


I. Joint Application Development (JAD).
II. Questionrio.
III. Entrevista.
Quais esto corretas?
a) Apenas I est correta.
b) Apenas III est correta.
c) Apenas I e II esto corretas.
d) I, II e III esto corretas.
4. Qual ou quais alternativas representam a etapa que inicia o processo de enge-
nharia de requisitos:
I. O levantamento de requisitos o incio da atividade de desenvolvimento de
software.
II. Esta fase tambm conhecida como Elicitao de requisitos, em que elici-
tao quer dizer ato ou efeito de eliciar; confrontar; aliciar; conseguir obter
resposta ou informao.
III. o ir a campo e compreender o que o cliente deseja e como ser desenhada
sua proposta para atender s expectativas dele.
a) Apenas I est correta.
b) Apenas III est correta.
c) Apenas I e II esto corretas.
d) I, II e III esto corretas.

5. A obteno de requisitos no um processo formal, por isso, no permite sua


automatizao. O engenheiro de requisitos deve contar com tcnicas de entre-
vista, questionrio, mapeamento, entendimento do processo-alvo. So tcnicas
de elicitao de requisitos.
a) Questionrio, Entrevista, .
b) Questionrio, Scrum, Oficinas.
c) Negociao, Questionrio, Brainstorming.
d) Scrum, Questionrio, Entrevista.

6. De forma geral o que se sugere que os riscos associados a cada requisito se-
jam identificados e analisados para ento elaborar estimativas de esforo de de-
senvolvimento de forma a avaliar o impacto de cada requisito no custo do pro-
jeto e no prazo de entrega. Essa afirmao diz respeito a qual fase do processo
de engenharia de requisito.
a) Elicitao de requisitos
b) Validao de requisitos.
c) Negociao de requisitos.
d) Especificao de requisitos.

7. Sobre a validao de requisitos, analise as afirmaes e indique a alternativa correta:


I. O objetivo da validao de requisitos descobrir erros nos requisitos docu-
mentados.
II. Nessa fase, se uma divergncia for encontrada, feita uma pausa no desen-
volvimento e nos testes e se levanta, novamente, o requisito.
109

III. Nesse sentido, a validao extremamente importante, pois o custo para cor-
reo de um requisito nessa fase bem inferior ao custo nas fases posteriores,
implementao ou testes, por exemplo.
a) Apenas I est correta.
b) Apenas II e III esto corretas.
c) Apenas I e III esto corretas.
d) I, II e III esto corretas.

8. Qual das alternativas melhor representada pela figura a seguir:

Entregar <<extend>> Segurar


CLIENTE SEGURADORA
volumes volumes

a. O cliente tem autorizao para solicitar entrega de volumes. Alguns volumes


de maior valor podem ser assegurados, os clientes podem solicitar isso do
sistema e uma companhia de seguro foi contratada para segurar os volumes
de maiores valores.
b. O relacionamento extend usado em casos em que comportamento opcional
ou excepcional inserido em um caso de uso existente.
c. O cliente deve solicitar autorizao para um usurio mster para solicitar en-
trega de volumes. Alguns volumes de maior valor podem ser assegurados,
os clientes podem solicitar isso do sistema e uma companhia de seguro foi
contratada para segurar os volumes de maiores valores.
d. A seguradora pode informar ao cliente que ele deve contrat-la para assegu-
rar cargas de maiores volumes.
A IMPORTNCIA DA ENGENHARIA DE REQUISITOS PARA O CICLO DE
DESENVOLVIMENTO DE SOFTWARE DE TEMPO REAL

A anlise e a especificao de requisitos A crescente complexidade dos sistemas de


so atividades fundamentais no pro- software tornam as atividades de Engenha-
cesso de desenvolvimento de software, ria de Requisitos tanto mais importantes
influindo diretamente no desenvolvimento quanto difceis. Para minimizar a comple-
satisfatrio de sistemas. Por se tratarem xidade dos sistemas de tempo-real (STR)
de atividades de grande importncia no (Real-Time Systems), que so encontrados
ciclo de vida do software, e que se rela- em muitos setores, como plantas indus-
cionam diretamente com a qualidade do triais, telecomunicaes, transporte, militar
produto a ser desenvolvido, a Engenha- e de sade, so utilizados modelos que de
ria de Requisitos precisa ser devidamente forma grfica ou textual auxiliam na com-
planejada. Sendo assim, deve ser aplicada preenso e representao desses sistemas.
de forma abrangente para assegurar que Por sua prpria natureza, projetar softwares
um conjunto completo das necessidades e de tempo-real traz exigncias especficas
requisitos dos usurios sejam capturados, de anlise, projeto e teste, exigindo assim
e posteriormente, transformados em um habilidades/metodologias especiais para
conjunto validado de requisitos em todo seu projeto e desenvolvimento. Com isso,
o ciclo de vida. A Engenharia de Requisi- a anlise de STR requer modelos de sof-
tos (RE) uma abordagem disciplinada e tware que possibilitem avaliar questes de
sistemtica para elicitar, especificar, anali- tempo, sincronizao e dimensionamento
sar, confirmar, validar e gerenciar requisitos destes softwares. A modelagem de apli-
enquanto considera usurios, objetivos e caes de tempo-real no um processo
necessidades tcnicas, econmicas e de trivial, pois o projeto das mesmas dever
negcio. Ela abrange todo o processo de conter, na maioria dos casos, uma anlise
desenvolvimento do software e caracte- distribuda em rede do comportamento
rizada, em diferentes bibliografias, como o e disposio dos diversos componen-
processo mais crtico e complexo do ciclo tes do sistema, como por exemplo, os
de desenvolvimento de software. A princi- sensores e atuadores, que esto aptos, res-
pal razo que o processo de engenharia pectivamente, a captar estmulos gerados
de requisitos tem impacto dominante sobre externamente e a responder a tais estmu-
as capacidades do produto resultante. los dentro de um intervalo de tempo finito
111

e especificvel. Dada a grande quantidade tempo-real possuem requisitos especficos,


de problemas j relatados na literatura em e dada a grande importncia deste tipo
relao ao desenvolvimento de software, de sistema, devem ser claramente expres-
torna-se necessrio aplicar metodologias sados. Por esta razo, e para minimizar as
que possibilitem tratar e manipular coe- dificuldades para a modelagem de requisi-
rentemente as caractersticas inerentes aos tos de sistemas de tempo-real, propem-se,
softwares em geral, como por exemplo, a neste trabalho, utilizar o profile SysML, que
intangibilidade e o alto grau de abstrao. estende a UML, em conjunto com estere-
A complexidade de softwares de tempo- tipos do profile MARTE para representar
-real demonstra-se crescente quando de requisitos no-funcionais de sistemas de
sua especificao e anlise. Os sistemas de tempo-real.
Fonte: Ribeiro e Souza (2012).
MATERIAL COMPLEMENTAR

Para entender um pouco mais sobre a necessidade de se especificar de forma clara e objetiva os
requisitos, assista ao vdeo disponvel em: <https://www.youtube.com/watch?v=fHjc3cJ6m00>.
Acesso em: 06 jul. 2015.

Engenharia de Software - Qualidade e Produtividade


com Tecnologia
Kechi Hirama
Editora: Elsevier
Sinopse: Neste livro, o professor Kechi Hirama, da Escola
Politcnica da USP, apresenta uma viso moderna e inovadora
do conceito de Engenharia de Software. Em vez de explorar
exausto tpicos tradicionais da disciplina, como fazem os
ttulos considerados clssicos da rea, d nfase aos conceitos
requisitados pelos entrantes nesse universo, tais como
documentao de processos, novas formas de padres arquiteturais, gerncia de projetos
OO, gerncia de requisitos e, por fim, o novssimo manifesto gil (Scrum) e os projetos e
implementao de servios SOA. A importncia do livro se concretiza pelo fato de apresentar
todos os temas de maneira direta e totalmente voltada para a realidade dos estudantes e
professores brasileiros.
Professora Me. Vanessa Ravazzi Perseguine

IV
UNIDADE
GESTO DE REQUISITOS

Objetivos de Aprendizagem
Entender como gerenciar mudanas em requisitos j definidos.
Verificar como gerenciar os relacionamentos entre requisitos e entre
o Documento de Requisitos e demais documentos produzidos
durante o desenvolvimento.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Evoluo dos requisitos
Rastreabilidade
Controle de mudanas
Planejamento do gerenciamento
Gerenciamento de mudana de requisitos
Ferramentas para o gerenciamento de requisitos
115

INTRODUO

Quando comeamos nossos estudos na unidade I, conversamos sobre o quo


complexo o processo de desenvolvimento de um software. A construo de um
sistema no algo fsico, no palpvel, no como construir uma casa, ou um
computador, exige interpretao, envolve deduo. Vrias pesquisas e estudos,
como os executados pelo Pulse of the Profession do PMI, apontam como prin-
cipal fator pelas falhas em Projetos o inadequado Gerenciamento de Requisitos.
Isso porque os programadores devem seguir especificaes para o desenvolvi-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mento de um produto de software, quando nem sempre eles participam da fase


em que elas so elicitadas.
O gerenciamento de requisitos deve iniciar nessa fase, durante o levanta-
mento dos requisitos, ali, as polticas de gesto dos requisitos devem ser definidas
considerando as caractersticas e necessidades do software a ser desenvolvido.
Ter incio efetivo, a partir da liberao da primeira verso do Documento de
Requisitos, e permanece ativo durante todo o ciclo de desenvolvimento do pro-
duto de software. A gesto de requisitos ultrapassa o ponto de entrega do produto
ao cliente, por se manter necessrio o controle de mudanas quando o produto
desenvolvido entra na fase de manuteno.
Uma gesto de requisitos mal planejada e mal executada provoca impactos
e, como j foi dito, tem relao direta com o sucesso ou com o fracasso do pro-
jeto. O PMI apresenta pesquisas demonstrando que, dos projetos que fracassam,
47% deles tm como causa base uma gesto de requisitos mal feita.
Nesta unidade, estudaremos a gesto de requisitos e sero apresentadas formas
de lidar com a volatilidade dos requisitos, o que nos possibilitar entender que
a evoluo uma caracterstica inerente aos sistemas computacionais e deve ser
levada em conta durante todas as fases do projeto de desenvolvimento do software.
Para entender do que se trata a gesto de requisitos, vamos retomar nossa
abordagem de relacionar o significado das palavras com a atividade que elas
nomeiam. Vamos l! Busque no seu navegador ou no seu dicionrio o significado
da palavra gesto. O Michaelis (online) define: ges.to sf(lat gestione)1Ato de
gerir.2Administrao, direo.G. de negcio: administrao oficiosa de neg-
cio alheio, feita sem procurao.

Introduo
116 UNIDADE IV

Se gesto significa administrar, ento, o primeiro passo definir quais so


os objetivos e criar polticas de identificao, controle e rastreamento das infor-
maes necessrias para atingi-los.
Assim, a gesto de requisitos comea com a identificao. Cada requisito deve
receber um atributo responsvel por identific-lo e torn-lo nico em um pro-
cesso de busca. Pense nessa identificao como o nmero do seu RG (Registro
Geral). Depois de identificados, segundo Pressman (2010), tabelas de rastrea-
mento podem ser desenvolvidas os relacionando com um ou mais aspectos do
sistema ou seu ambiente.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Cada vez mais fbricas de software buscam pela maturidade nos seus pro-
cessos de desenvolvimento, a fim de finalizarem seus projetos dentro do prazo
e com os menores custos. Sayo e Koogan, em artigo publicado pela PUC-RIO,
relatam que a gerncia de requisitos vista como um dos principais problemas
a serem superados para que as organizaes cheguem ao nvel 2 de maturidade
do modelo CMMI (Capability Maturity Model Integration) do SEI (Software
Engineering Institute). O propsito do processo Gerncia de Requisitos, segundo
o Programa MPS.BR nvel G (Parcialmente Gerenciado), gerenciar os requisitos
do produto e dos componentes do produto do projeto e identificar inconsistn-
cias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
Pronto, essa a viso geral da gesto de requisitos, agora, vamos estudar
com um pouco mais de detalhes o contedo envolvido na gesto de requisitos.

EVOLUO DOS REQUISITOS

Requisitos mudam, essa uma certeza no desenvolvimento de software, Pressman


(2010) complementa afirmando que o desejo de mudar dos requisitos persiste ao
longo da vida do sistema. A evoluo uma caracterstica inerente aos sistemas
computacionais. O surgimento de novos requisitos ou a necessidade de alterar
um j existente acontece durante o processo de desenvolvimento e, at mesmo,
depois que o sistema tiver em operao, isso se chama evoluo de sistemas.

GESTO DE REQUISITOS
117

Voc j deve ter ouvido falar sobre o bug do milnio, ou ento sobre o fre-
nesi que o lanamento do sistema operacional Windows provocou no mercado
de desenvolvimento de software para interface grfica, quando lanado. Esses
so exemplos clssicos de que simples alteraes no macrosistema afetam os sis-
temas de software, que ou evoluem para se adaptarem ou se tornaro inteis.
Outros fatores de mudanas nos requisitos so: especificao mal descrita ou
errada de requisito (inconsistncias, conflitos); mais conhecimento adquirido pelo
cliente ou usurio com o decorrer do projeto (mudam de ideia, quando enten-
dem o que realmente querem do sistema); mudana de prioridade do cliente;
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mudana de tecnologia; mudana de leis, polticas e processos internos ou exter-


nos organizao vinculada ao projeto.
A literatura nos apresenta duas classificaes de requisitos a partir da pers-
pectiva de evoluo do requisito. Sommerville (2008) apresenta os requisitos
Permanentes e os Requisitos Volteis:
Requisitos Permanentes: so os requisitos criados a partir do domnio
da aplicao, so relativamente estveis, mudam mais lentamente que os
requisitos volteis. Por exemplo, em um sistema de recursos humanos,
sempre existiro os requisitos relacionados documentao dos funcio-
nrios, ou referncias da organizao, ou, ainda, referentes ao calendrio
bsico. padro os sistemas informatizados disponibilizarem uma aba/
janela/menu referente aos Cadastros Bsicos.
Requisitos Volteis: so requisitos que iro mudar durante o tempo de
desenvolvimento do sistema, provavelmente, depois, quando j estive-
rem em operao. Por exemplo, as regras de pagamento do funcionrio
podem sofrer alteraes por imposio de leis ou por mudana na pol-
tica da empresa.

Sommerville (2010) divide os requisitos volteis em quatro classes:


Mutveis: so os requisitos que se modificam devido s mudanas no
ambiente em que a organizao est inserida.
Emergentes: so os requisitos que surgem conforme a compreenso do
cliente referente ao sistema. Dessa compreenso, novos requisitos podem
surgir. So emergentes, tambm, aqueles requisitos que o processo do
projeto revela.

Evoluo dos Requisitos


118 UNIDADE IV

Consequentes: so os requisitos que surgem aps a insero do sistema


na organizao. So as solicitaes de adaptaes ou criao de novas
rotinas desencadeadas pelo uso do sistema at sua perfeita adaptao s
rotinas da organizao.
Compatibilidade: so os requisitos que dependem de outro sistema, equi-
pamento ou processo. Conforme esse sistema, equipamento ou processo
os requisitos tambm mudam.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
RASTREABILIDADE

No tpico para os nossos estudos, mas o quesito qualidade de software deve


ser mencionado quando falamos em gerenciamento de requisitos. Analise o
seguinte: uma denominao simplista do objetivo da qualidade de software
entregar o que o cliente espera receber.
Qualidade para o CMMI medida por nveis de maturidade nos processos
de desenvolvimento de software. Se observar as exigncias, ir encontrar que o
conjunto de atividades que compe o processo de desenvolvimento de requi-
sitos exigido no nvel 3 de maturidade, j as atividades de Gerenciamento de
Requisitos esto no nvel 2 de maturidade. Percebe o que isso quer dizer? Isso
significa que uma organizao que busque certificao de qualidade pelo CMMI
deve, primeiro, focar sua ateno nos processos de Gerenciamento de Requisitos.
Gerir requisitos, ento, o primeiro passo para um processo de desenvolvimento
de software maduro e que garanta um produto final com qualidade.
O que garante um gerenciamento de requisitos bem executado? Um pro-
cesso de controle de mudanas conciso e um atributo de rastreabilidade bem
definido. A rastreabilidade de requisitos uma das atividades aconselhadas por
vrios modelos de qualidade, por exemplo, o CMMI, MPS-BR e ISO 9001.

GESTO DE REQUISITOS
119

Rastreabilidade pode ser definida como o conjunto de ligaes entre


os requisitos, com as fontes dos requisitos, com eles mesmos e com outros
artefatos. A rastreabilidade pode ser conseguida vinculando o requisito ao
stakeholder que trouxe a informao, ou vinculando o requisito aos requi-
sitos relacionados, ou ainda vinculando o requisito aos padres do projeto.
A condio de rastreamento deve ser atribuda ao requisito no momento do
seu levantamento e ela dever refletir a facilidade de se encontrar os requisi-
tos relacionados. Sommerville (2008) relaciona trs tipos de rastreabilidade
de requisitos:
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

1. Por stakeholders: vincula o requisito ao stakeholder que o props. Essa


informao utilizada, quando uma mudana proposta, para desco-
brir os stakeholders, para que possam ser consultados.
2. Requisitos dependentes: quando o requisito vinculado a outro requi-
sito na sua concepo, essa informao pode ser utilizada para avaliar
quantos requisitos sero afetados pela mudana proposta e a extenso
das mudanas consequentes dela que sero necessrias.
3. Modelos de projeto: vincula o requisito ao modelo de projeto onde foi
implementado. Essa informao utilizada para avaliar o impacto das
mudanas para o projeto e implementao.

preciso decidir qual critrio de rastreabilidade ser utilizado para atribuir ao


requisito j no momento da sua especificao.
Para deter a habilidade de acompanhar e descrever a vida de um sistema, tanto
fazendo o caminho da concepo do requisito at sua implementao quanto
voltando da funo em execuo at seu requisito gerador, as matrizes de ras-
treabilidade podem ser implementadas por meio de uma ferramenta simples,
como um editor de textos ou uma planilha eletrnica (muitas das ferramentas
comercialmente disponveis para a fase de requisitos utilizam alguma forma de
matriz de rastreabilidade).

Rastreabilidade
120 UNIDADE IV

MATRIZ DE RASTREABILIDADE
Identificao do Projeto Nome do projeto Data: Data de criao da matriz
Gerente do Projeto Responsvel pelo Projeto
Resumo do Projeto Descrio resumida do produto final

Id. Requisito Doc. Fonte Arquitetura Componente Caso de teste

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Figura 22: Exemplo de Matriz de Rastreabilidade por Requisito e Caso de teste
Fonte: o autor.

A matriz dever ser preenchida com os requisitos, expressos em linguagem


natural e numerados sequencialmente. As colunas subsequentes representam
os documentos gerados durante o desenvolvimento do software. Nesse formato,
a correspondncia nem sempre da ordem de um para um, isto , um mesmo
requisito pode ser verificado por vrios casos de teste e, por outro lado, vrios
casos de teste podem estar verificando um nico requisito. A Figura 22 representa
uma matriz de rastreabilidade por requisito e caso de teste. A Figura 23 repre-
senta uma matriz de rastreabilidade por requisitos funcionais e no funcionais.

MATRIZ DE RASTREABILIDADE
Identificao do Projeto Nome do projeto Data: Data de criao da matriz
Gerente do Projeto Responsvel pelo Projeto
Resumo do Projeto Descrio resumida do produto final

Requisitos
Requisitos no funcionais
Funcionais
RF01 RNF01 RNF02 RNF03 RNF04 RNF05 RNF06
RF02
RF03
RF04
RF05
Figura 23: Exemplo de Matriz de Rastreabilidade por Requisitos Funcionais e Requisitos No funcionais
Fonte: o autor.

GESTO DE REQUISITOS
121

Nossa Matriz de Rastreabilidade desenvolvida na unidade II representa um


modelo simples de uma ferramenta de rastreabilidade de requisitos. A seguir,
relaciono alguns exemplos de matriz de rastreabilidade:
Rastreamento das fontes de requisitos (relaciona o requisito, stakeholders
e documento de requisitos).
Rastreamento da razo dos requisitos (relaciona o requisito com a des-
crio do porqu o requisito foi especificado).
Rastreamento requisitos-requisitos (relaciona requisitos com outros requi-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

sitos que so dependentes uns dos outros).


Rastreamento requisitos-arquitetura (relaciona os requisitos com os sub-
sistemas onde foram implementados).
Rastreamento requisitos-projeto (relaciona os requisitos com o har-
dware especfico ou componentes de software que so usados para
implement-los).
Rastreamento requisitos-interface (relaciona os requisitos com a inter-
face externa do sistema que ser usada para apresentar os requisitos).

Vrios caminhos de rastreamento so possveis:


Rastreamento Backward-from: vincula requisitos a suas fontes em outros
documentos ou stakeholders.
Rastreamento Forward-from: vincula requisitos ao projeto e componen-
tes de implementao.
Rastreamento Backward-to: vincula o projeto e os componentes de imple-
mentao aos requisitos.
Rastreamento Forward-to: vincula outros documentos (que possam ter
precedido o documento de requisitos) aos requisitos relevantes.
Existem, no mercado, vrias ferramentas para o gerenciamento de requisitos, pro-
prietrias e livres. Por exemplo: IBM Rational da IBM; EasyRM Version 1.06 da
Cybernetic Intelligence GmbH; Borland Caliber Analyst da Borland; Caliber da
Microfocus, OSRMT (Open Source Requirements Management Tool) ferramenta livre,
DotProject, distribudo sob a licena GNU-GPL (GNU General Public License) e outros.

Rastreabilidade
122 UNIDADE IV

Para sistemas de pequeno porte, geralmente, o rastreamento suportado por


ferramentas simples, como processadores de texto e planilhas de clculo. Nos
sistemas de grande porte, a utilizao dessas ferramentas fica comprometida
devido quantidade de informao gerada. Nesse caso, a utilizao de ferramen-
tas automatizadas de gerenciamento de requisitos recomendada.
Temo me considerar repetitiva, mas, novamente, a definio dos elementos
que comporo seu processo de rastreabilidade deve ser adaptada s necessida-
des especficas do seu projeto, ou melhor, de cada projeto a ser desenvolvido.
No adianta rastrear uma quantidade excessiva de informaes se no for vivel

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
a sua manuteno e utilizao. A definio dos elementos a serem relacionados
para o rastreamento deve considerar prazos e custos do projeto, alm dos pro-
cessos e dos padres em uso na organizao.

O site IBM Developer Works postou uma notcia falando sobre a importncia
de se capturar e gerenciar requisitos.
A notcia retrata como uma falha clssica, para conceituar uma arquitetu-
ra fsica de um produto, resultou em problemas de integrao no tempo
de execuo, gerando um diagnstico inicial que designava o software
como culpado do mau funcionamento, j que era difcil para os mecni-
cos testar o componente fisicamente. A falta de critrio na especificao,
no momento do levantamento, provocou custos adicionais e sobrecar-
regou a fbrica, devido a necessidade da correo da operao que j
estava em execuo.
Para saber mais, acesse: <https://www.ibm.com/developerworks/commu-
nity/blogs/academia/entry/a_import_c3_a2ncia_de_levantar_e_geren-
ciar_requisitos_sensor_de_chuva_de_autom_c3_b3veis23?lang=en>.
Acesso em: 05 maio 2015.
Fonte: o autor.

GESTO DE REQUISITOS
123

CONTROLE DE MUDANAS

Assumindo que os requisitos mudam, o gerenciamento de requisitos deve,


ento, se ocupar de controlar essas mudanas de forma sistemtica e eficiente.
Sommerville (2008) afirma que 65% da manuteno de um sistema esto relacio-
nados implementao de novos requisitos, 18% modificao de requisitos j
existentes e 17% correo de defeitos de um sistema. Podemos, ento, com base
nessas informaes, considerar que a manuteno dos sistemas uma extenso
do desenvolvimento de software, com atividades associadas s de especificao,
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

projeto, implementao e testes.


Percebemos que parte do processo de gesto de requisitos controlar mudan-
as. O CMMI afirma que fundamental que as alteraes dos requisitos sejam:
Identificadas e avaliadas.
Avaliadas sob o ponto de vista de risco.
Documentadas.
Planejadas.
Comunicadas aos grupos e indivduos envolvidos.
Acompanhadas at a finalizao.

O processo de controle de mudanas permite que todas as mudanas sejam


rastreadas e garante que nenhuma solicitao seja perdida ou deixada de lado.
Summerville (2008) recomenda que o planejamento desse processo deve come-
ar junto com o levantamento inicial do requisito, e o gerenciamento ativo
das mudanas deve comear assim que a primeira verso do Documento de
Requisitos for liberada.

PLANEJAMENTO DO GERENCIAMENTO

Um requisito somente ser rastrevel se for possvel identificar sua concepo,


porque ele existe, quais os requisitos relacionados a ele e qual o seu relacionamento

Controle de Mudanas
124 UNIDADE IV

com outras informaes, tais como: projeto do sistema, testes, implementaes


e documentao do usurio. Para isso, Summerville (2008) recomenda que, na
fase de planejamento do gerenciamento do requisito, sejam considerados os
seguintes aspectos:
Identificao nica para os requisitos: definio da forma de identifica-
o do requisito. Para ser rastrevel, o requisito deve ser nico.
Processo de gerenciamento de mudana: definio das atividades do
processo. Seja estabelecido um conjunto de atividades que ir avaliar o
impacto e o custo da mudana.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Polticas de rastreamento: definio dos elementos de rastreamento.
necessrio decidir como ser o relacionamento entre os requisitos e entre
os requisitos e o projeto de software, bem como decidir como sero man-
tidos esses relacionamentos.
Suporte de ferramenta CASE: definio de uma ferramenta automati-
zada para gerenciar o processo. O gerenciamento de requisitos envolve
uma grande quantidade de informaes que deve ser mantida, essa ferra-
menta pode ser um sistema especializado em gesto de requisitos como,
tambm, uma planilha eletrnica. Essa ferramenta dar apoio para as ati-
vidades de armazenar requisitos, gerenciar mudanas e rastreabilidade.

Se voc deseja reduzir a deteriorizao do software, ter de melhorar o pro-


jeto de software.
Fonte: Roger S. Pressman (2010 p. 5).

GERENCIAMENTO DE MUDANA DE REQUISITOS

Quando so propostas mudanas, preciso verificar o impacto que elas pro-


vocaro sobre o requisito, nos outros requisitos relacionados e, tambm, no
projeto de software. O processo definido no planejamento do gerenciamento de

GESTO DE REQUISITOS
125

mudanas deve ser aplicado a todas as mudanas propostas de forma consistente


e controlada. Para o processo de gerenciamento de mudanas, trs atividades so
propostas por Sommerville (2008):
I. Anlise do problema e especificao da mudana: essa fase se inicia
quando detectado um problema no requisito que precisa ser remode-
lado, ou quando uma proposta/solicitao de mudana apresentada. O
problema ou a proposta deve ser analisado e validado, isso porque uma
mudana pode ser solicitada simplesmente pela falta de entendimento
do solicitante da especificao do requisito. Como resultado dessa fase,
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

uma melhor especificao da mudana deve ser definida.


II. Anlise de custo: a segunda etapa do processo de gerenciamento de
mudanas de requisito analisa o efeito que a mudana proposta provoca
no sistema. Utilizando a rastreabilidade, o custo da mudana estimado
considerando a proporo de alteraes que sero necessrias no docu-
mento de requisitos e no projeto. No final dessa etapa, decide-se pela
aceitao ou no da mudana proposta.
III. Implementao de Mudana: uma vez aprovada a mudana, o docu-
mento de requisitos e o projeto so alterados.

A Figura 24 representa o processo de gerenciamento de mudana de requisi-


tos proposto.

Identificao de problema Documento de Requisito;


direto no requisito; Projeto
Proposta/solicitao de Implementao
mudana.
Anlise do Problema Implementao
e especificao da Anlise do Custo
da Mudana
mudana
Alterao do documento
de Requisito;
Alterao do Projeto;
Alterao na
Implementao.

Figura 24: Processo de gerenciamento de mudana de requisitos


Fonte: adaptada de Sommerville (2008).

Controle de Mudanas
126 UNIDADE IV

Plano de gerenciamento dos requisitos


Segundo o Guia PMBOK, o Plano de Gerenciamento dos Requisitos docu-
menta como eles sero analisados, documentados e gerenciados do incio
ao fim do projeto. Este Plano faz parte ou um plano auxiliar do plano de
gerenciamento do projeto. Trata-se de uma baseline que funciona como
guia para todos os projetos de uma empresa/equipe, assim, todos os pro-
jetos seguiro um padro pr-definido, garantindo um repositrio nico e

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
uma fonte de pesquisa para os gerentes de projeto e desenvolvedores. O
site Escritrio de Projetos1 oferece templates dos principais documentos uti-
lizados para a gesto de projetos.
Visite tambm a pgina oficial do PMI e aprenda mais sobre o guia de prti-
cas de gerenciamento de projetos: <http://www.pmi.org/PMBOK-Guide-an-
d-Standards.aspx>. Acesso em: 8 jul. 2015.
Fonte: o autor.

O processo de gerenciamento de mudanas poder incluir as seguintes ativi-


dades:
Solicitao de mudanas: executado a partir de formulrio prprio que
deve ser aceito pela equipe de desenvolvimento e cliente.
Anlise do impacto e custo da mudana: estudo efetuado a partir do
levantamento de complexidade, conforme informaes de rastreamento,
tempo de execuo, influencia no prazo final, custo de implementao,
custo de teste.
Responsabilidades: levantamento das responsabilidades pela solicitao
de mudana.
Registros: ferramenta CASE para o gerenciamento do projeto.

GESTO DE REQUISITOS
127

Na academia, um processo de desenvolvimento de software dividido em


vrias disciplinas especficas, isso para facilitar a didtica e a organizao dos
assuntos. Voc consegue estabelecer as relaes entre elas quando carrega-
mos nossos conhecimentos para a aplicao prtica?
Fonte: o autor.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

CONSIDERAES FINAIS

Voc pode considerar clich ou, at mesmo, jargo da rea, e sei que j deve ter
ouvido essa afirmao inmeras vezes durante sua formao, mas, depois de tudo
que estudamos at agora, o momento de, realmente, entender o que ela quer
dizer: os requisitos esto para o desenvolvimento de software como os alicerces
esto para uma construo civil. Ficou claro que requisitos devem ser levan-
tados com critrio e documentados com maestria, mais que isso, devem estar
acessveis a todos os envolvidos no processo de desenvolvimento do software.
Aprendemos que os requisitos mudam, isso inerente necessidade de evo-
luo dos sistemas computacionais, para que se mantenham atualizados e teis,
por isso, o gerenciamento de requisitos deve se ocupar de controlar essas mudan-
as de forma sistemtica e eficiente. Com isso, possvel perceber que conversar
com os stakeholders, ouvir as suas expectativas e necessidades em relao ao sis-
tema, e mais, mant-los envolvidos, prximos do processo de gesto de requisitos
fundamental para o sucesso de um projeto de desenvolvimento de software.
Mudanas, se no partem de problemas encontrados durante a implementa-
o, surgem de novos entendimentos ou novas necessidades. Em ambos os casos,
so os stakeholders a chave para o levantamento do impacto que a mudana ir
causar no projeto e para a validao da mudana no requisito. Buscando aprovei-
tar esse recurso, as metodologias geis baseiam-se no princpio que os requisitos
do software sero elaborados ao longo do seu desenvolvimento, e no em uma
etapa especfica, para os agilistas, os requisitos no precisam ter toda a informa-
o neles desde o comeo, apenas informao o suficiente. Assim, inerente a

Consideraes Finais
128 UNIDADE IV

essa abordagem que os requisitos iro evoluir, mudar e at falhar. Dessa forma,
sua elaborao contnua est diretamente integrada ao gerenciamento e controle
de mudanas, apoiando diretamente o desenvolvimento.
Finalizando a unidade, foi observado que ferramentas CASE podem faci-
litar a alcanar os resultados esperados no processo de gerncia de requisitos,
auxiliando na automatizao do planejamento e no registro e controle dos rela-
cionamentos dos requisitos.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

GESTO DE REQUISITOS
129

1. O surgimento de novos requisitos ou a necessidade de alterar um j existente


acontece durante o processo de desenvolvimento e, at mesmo, depois que o
sistema tiver em operao, isso se chama evoluo de sistemas. Sobre a gesto
de controle de mudanas de requisitos, assinale a alternativa correta:
a. So rotinas para identificar, controlar e rastrear requisitos e modificaes de
requisitos em qualquer poca, medida que o projeto prossegue.
b. Gesto de mudanas consiste em construir um modelo tcnico refinado de
funes, caractersticas e restries do software.
c. Para o controle de mudanas, basta negociar com os clientes os conflitos de prio-
ridade de requisitos e identificar e analisar os riscos associados a cada requisito.
d. O controle de mudanas tem como prioridade avaliar os requisitos quanto
qualidade, garantindo que ambiguidades, inconsistncias, omisses e erros
sejam detectados e corrigidos.

2. Rastreabilidade pode ser definida como o conjunto de ligaes entre os requi-


sitos, com as fontes dos requisitos, com eles mesmos e com outros artefatos. A
condio de rastreamento deve ser atribuda ao requisito no momento do seu
levantamento e ela dever refletir a facilidade de se encontrar os requisitos rela-
cionados. Indique a alternativa que identifica os trs tipos de rastreabilidade de
requisitos propostos por Sommerville (2008):
a. Por modelo de projeto, por prototipao, por stakeholders.
b. Por stakeholders, por entrevistas e por modelo de projetos.
c. Por stakeholders, por requisitos dependentes e por modelos de projeto.
d. Por modelo de projeto, por requisitos dependentes, por questionrios.

3. Analise as alternativas sobre o gerenciamento de mudanas de requisitos e indi-


que a alternativa correta:
I. O problema ou a proposta deve ser analisado e validado, isso porque uma
mudana pode ser solicitada simplesmente pela falta de entendimento do
solicitante da especificao do requisito.
II. No final da anlise de custo, a mudana sempre aceita.
III. Uma vez aprovada a mudana, o documento de requisitos e o projeto no
necessitam ser alterados.
a. Apenas I est correta.
b. Apenas II e III esto corretas.
c. Apenas I e III esto corretas.
d. I, II e III esto corretas.
4. Analise as afirmativas referentes gesto de mudanas de requisitos e, na sequ-
ncia, assinale a alternativa correta:
I. A rastreabilidade de requisitos ocorre, apenas, na relao entre os requisitos
propriamente ditos e os artefatos ou subprodutos de desenvolvimento gera-
dos.
II. O levantamento do impacto de mudana de um requisito faz com que seja
necessrio retornar a sua fonte. Na validao dos requisitos, a equipe deve
estar sempre atenta rastreabilidade do requisito.
III. O gerenciamento de mudanas nos requisitos mantm informaes de ras-
treabilidade a serem usadas para avaliar quais outros requisitos seriam afe-
tados por uma mudana, bem como o impacto da mudana de requisitos no
projeto e na implementao do sistema.
a. I est correta.
b. II e III esto corretas.
c. I e III esto corretas.
d. I, II, III esto corretas.
131

DESENVOLVIMENTO DE SOFTWARE REQUER PROCESSO E GESTO

Software, de modo genrico, uma enti- requer processo (de desenvolvimento) e


dade que se encontra em quase constante gesto (do projeto de desenvolvimento).
estado de mudana. Essas mudanas ocor-
rem por necessidade de corrigir erros Dentro do contexto discutido acima, um
existentes no software e/ou de adicionar aspecto importante no desenvolvimento
novos recursos e funcionalidades. Igual- de um sistema de software o contnuo fee-
mente, os sistemas computacionais (isto dback durante o processo. A importncia de
, aqueles que tm software como um de ter um feedback (resposta e comentrios)
seus principais elementos) tambm sofrem do cliente mais cedo no desenvolvimento
mudanas frequentemente. Essa necessi- implica na necessidade de fazer um prot-
dade evolutiva do sistema de software o tipo. Alm disso, a necessidade de melhor
torna predisposto a defeitos (isto no planejar o desenvolvimento, fazendo um
confivel), podendo resultar em atraso na balanceamento entre custos e benefcios.
entrega e em custos acima do estimado. Isto requer uma avaliao preliminar se
Concomitante com esses fatos, o cresci- vivel ou no desenvolver o software dese-
mento em tamanho e complexidade dos jado pelo cliente. Como conseqncia,
sistemas de software exige que os pro- voc pode perceber que duas atividades
fissionais da rea raciocinem, projetem, importantes so planejamento e an-
codifiquem e se comuniquem por meio de lise de riscos, que procuram exatamente
componentes (de software) e qualquer con- responder a questo: vivel desenvol-
cepo ou soluo de sistema passa ento ver esse software? Note que tudo isso
para o nvel arquitetural. Nesse sentido, o visa minimizar custos e assegurar que o
objetivo deste artigo discutir e explorar desenvolvimento ir ocorrer da forma como
o fato de que software no construdo planejada e dentro dos prazos propostos.
como uma TV ou geladeira, mas desen- Agora, voc poderia ainda questionar: Por
volvido. E, o desenvolvimento de software que tudo isso?
Fonte: Filho (2011, online).
MATERIAL COMPLEMENTAR

Anlise e Gesto de Requisitos de Software: Onde


Nascem os Sistemas
Felipe Nery Machado
Editora: Erica
Sinopse: Apresenta os conceitos da anlise e gesto de
requisitos, com exemplos sobre variaes e tcnicas de
levantamento e anlise. Descreve os Modelos de Capacidade
e Maturidade (CMMI), Processo Unificado da Rational (RUP),
mtodos geis, o funcionamento do SCRUM, detalha a
engenharia de requisitos e a gerncia de escopo de projetos.
Aborda as mais diversas tcnicas que podem ser utilizadas, com
destaques para estudo etnogrfico, entrevistas, associao entre requisitos e modelo de negcios,
especificao de requisitos com casos de uso e user stories como elemento de levantamento de
requisitos.
Professora Me. Vanessa Ravazzi Perseguine

REQUISITOS NAS

V
UNIDADE
METODOLOGIAS GEIS

Objetivos de Aprendizagem
Oferecer, ao aluno, um panorama geral das metodologias geis.
Apresentar como as metodologias geis tratam os requisitos de
software.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Requisitos nas metodologias geis
Manifesto gil
Scrum
Especificao de requisitos geis
135

INTRODUO

Ol, aluno(a)! Esta a ltima unidade de estudos, encerraremos nossa disci-


plina falando sobre a especificao de requisitos geis. Para isso, abordaremos,
rapidamente, os princpios do manifesto gil de desenvolvimento de software e
analisaremos o framework Scrum, e como fica a especificao de requisitos em
um processo gil.
A gerncia de requisitos envolve todos os processos que cooperam para a
gerao de um Documento de Requisitos e para a sua manuteno durante todo
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

ciclo de vida do projeto de desenvolvimento de software. A evoluo conside-


rada uma das questes mais crticas no desenvolvimento de sistemas tradicionais,
pois provoca mudanas, e o controle dessas complexo.
Por outro lado, temos os mtodos geis inseridos em ambientes dinmicos,
em que os requisitos esto em constante modificao e so construdos durante o
desenvolvimento do software. Esta unidade apresenta o manifesto gil de desen-
volvimento de software, um documento divulgado em 2001, que declarou uma
nova filosofia para os projetos de desenvolvimento de software.
Desse manifesto, vrias metodologias e novos processos de desenvolvi-
mento de software foram organizados para atender aos seus doze princpios.
Os processos geis no desaprovam e no revogam a utilizao de ferramentas
e documentao, mas declaram que mais importantes do que isso so os valores
geis: os indivduos e interaes entre eles, software em funcionamento, colabo-
rao com o cliente e responder a mudanas.
Vimos que a especificao de um requisito est diretamente ligada quali-
dade de software. Nos processos geis, temos uma viso diferente de requisitos,
aqui, ele um objetivo, no lugar de uma solicitao sobre o que deve ser feito, e
sua especificao ocorre durante todo o ciclo de vida do processo de desenvol-
vimento do software. Vamos l!

Introduo
136 UNIDADE V

REQUISITOS NAS METODOLOGIAS GEIS

Sistemas computacionais cada vez mais complexos e abrangentes dificultam ou,


at mesmo arrisco dizer, impossibilitam a definio completa dos requisitos antes
do incio do projeto. A evoluo da tecnologia tanto de software quanto de har-
dware est muito rpida, o que obriga os engenheiros de software a serem geis
na tomada de decises.
Os agilistas, como so chamados os profissionais que apoiam os proces-
sos geis, praticam desenvolvimento incremental, ou seja, pacotes de trabalhos

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
so entregues em pequenos perodos de tempo. No processo gil, no se faz um
plano completo com tudo que se deve desenvolver antes do incio da implemen-
tao, so desenvolvidos incrementos, pedaos do produto que so produzidos
aos poucos e entregues constantemente.
fcil encaixar essa abordagem quando se observa os sistemas j implanta-
dos e em fase de manuteno, em que as solicitaes de mudanas passam a ser
o carro chefe da equipe de desenvolvimento, mas como isso funcionaria para
um novo produto de software? Sommerville (2008) explica que, no momento da
elaborao do projeto, devem se estabelecer os requisitos para que os incremen-
tos iniciais do sistema considerem as funcionalidades de alta prioridade. Com a
entrega dessas funes, o cliente pode observar o requisito na prtica e especifi-
car as mudanas para serem consideradas e incorporadas nas prximas entregas.
Um estudo comparando equipes geis e equipes tradicionais, desenvolvido
por Crispin & Gregory (2009), apresentou como resultado:
Times geis:
H um entendimento detalhado dos requisitos devido proximidade do
cliente e especialistas no negcio.
O foco est no valor a ser entregue - equipe gil focada em entregar um
produto de alta qualidade que fornea valor de negcio.

Times tradicionais:
H uma iluso de controle, no sabem como o cdigo escrito, nem se
os programadores executam testes.

REQUISITOS NAS METODOLOGIAS GEIS


137

Entrega-se o que foi acordado nos requisitos.

No afirmo aqui que uma metodologia melhor que outra, a deciso pela tradi-
cional ou gil deve ser feita pela organizao, considerando suas caractersticas
(perfil organizacional e cultura) e suas necessidades.
Muitos benefcios podem ser trazidos para uma organizao, j em operao
nos moldes tradicionais, que decide adotar uma metodologia gil, mas, para isso,
em um primeiro momento, ela ir evidenciar as fraquezas de equipe e da prpria
organizao, para que se possa atuar sobre elas, esse um momento de estresse.
Deve-se estar preparado para uma mudana de paradigmas e de comportamento.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

MANIFESTO GIL

Qual o propsito do manifesto gil? Pressman (2010, p. 58) nos apresenta uma
discusso til:
Mtodos geis foram desenvolvidos em um esforo para vencer as fra-
quezas percebidas e reais da engenharia de software convencional. O de-
senvolvimento gil pode fornecer importantes benefcios, mas ele no
aplicvel a todos os projetos, produtos, pessoas e situaes. Ele tambm
no contrrio slida prtica de engenharia de software e pode ser
aplicado como uma filosofia prevalecente a todo trabalho de software.

Em 2001, um grupo de dezessete profissionais, entre eles, desenvolvedores, pro-


dutores e consultores de software, assinaram o Manifesto para o Desenvolvimento
gil de Software. Nesse ataque construtivo velha guarda, declararam:
Estamos descobrindo melhores modos de desenvolvimento de softwa-
re fazendo-o e ajudando outros a faz-lo. Por meio desse trabalho pas-
samos a valorizar:

Indivduos e interaes em vez de processos e ferramentas.


Softwares funcionando em vez de documentao abrangente.
Colaborao do cliente em vez de negociao de contratos.
Respostas a modificaes em vez de seguir um plano (O MANIFESTO...,
online).

Manifesto gil
138 UNIDADE V

Pressman (2010) nos ajuda a compreender os propsitos da Aliana gil com


seu manifesto dizendo que, se os modelos de processo devem funcionar, devem,
ento, ser caracterizados de uma forma mais realstica, com mecanismos que
mostrem tolerncia com as pessoas envolvidas.
O principal foco da agilidade o controle efetivo das mudanas, mas
o manifesto tambm prope uma nova filosofia de trabalho: que encoraja
a comunicao, no s entre os membros da equipe, mas, principalmente,
entre a equipe de desenvolvimento e os stakeholders envolvidos, que enfatiza
a entrega rpida do produto de software e que o plano de projeto deve ser fle-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
xvel. Pressman (2010) afirma que a agilidade pode ser aplicada em qualquer
processo de software.

A agilidade dinmica, especfica em contedo, agressiva no acolhimento


de modificaes e orientada ao crescimento.
Fonte: Pressman (2010).

Os 12 princpios do desenvolvimento gil de software:


1. Nossa maior prioridade satisfazer o cliente por meio da entrega cont-
nua e adiantada de software com valor agregado.
2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desen-
volvimento. Processos geis tiram vantagem das mudanas visando
vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a
poucos meses, com preferncia menor escala de tempo.
4. Pessoas de negcio e desenvolvedores devem trabalhar, diariamente, em
conjunto por todo o projeto.
5. Construa projetos em torno de indivduos motivados. D a eles o ambiente
e o suporte necessrio e confie neles para fazer o trabalho.

REQUISITOS NAS METODOLOGIAS GEIS


139

6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre


uma equipe de desenvolvimento por meio de conversa face a face.
7. Software funcionando a medida primria de progresso.
8. Os processos geis promovem desenvolvimento sustentvel. Os patro-
cinadores, desenvolvedores e usurios devem ser capazes de manter um
ritmo constante indefinidamente.
9. Contnua ateno excelncia tcnica e bom design aumentam a agilidade.
10. Simplicidade - a arte de maximizar a quantidade de trabalho no reali-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

zada - essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-
-organizveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais efi-
caz e, ento, refina e ajusta seu comportamento de acordo.

Os modelos geis esto cada vez mais presentes no processo de desenvol-


vimento de softwares, o manifesto gil uma declarao de princpios que
fundamentam o desenvolvimento gil de software. Como vimos, possui
princpios claros. Saiba mais sobre os membros que formam a Aliana gil
e como se desenvolveu a concepo do Manifesto para o Desenvolvimen-
to gil de Software, acessando o link disponvel em: <http://www.drdobbs.
com/open-source/the-agile-manifesto/184414755?queryText=the+agi-
le+manifesto>. Acesso em: 05 maio 2015.
Fonte: o autor.

Existem, no mercado, vrias metodologias geis, as mais conhecidas e aplica-


das so: Extreme Programming (XP), Scrum, Lean Development, Feature-Driven
Development (FDD), Kanban, RUP e OpenUP. Para os nossos estudos, utiliza-
remos o framework Scrum.

Manifesto gil
140 UNIDADE V

SCRUM

A gerncia de projetos uma rea chave no desenvolvimento de software. Os


processos de desenvolvimento de software que subsidiam a gerncia de proje-
tos podem dar mais garantias de que o produto a ser desenvolvido ser entregue
dentro do prazo, do custo e com qualidade. Por isso, no momento de se definir
um processo de software, questes como essa devem ser consideradas. O Scrum
um processo emprico que oferece uma estrutura para gerncia de projeto. A
Figura 25 apresenta o processo do Scrum:

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Reunio Produto ou
diria Funcionalidade
1 dia Concluda
Product Sprint
Backlog Backlog 2a4
semanas

Sprint
Figura 25: Processo do Scrum
Fonte: Vieira (2014, online).

O Scrum estipula papis bem definidos e diversas etapas que devem ser cum-
pridas em prazos estipulados, visando entregar o produto de forma rpida e que,
ao mesmo tempo, atenda s expectativas do cliente. O Product Owner representa
os stakeholders e o negcio, o Team formado por poucas pessoas (recomenda-se
sete, no mximo, e nunca menos de trs) e multidisciplinares uma das prin-
cipais caractersticas do Scrum. O ScrumMaster atua como um lder de equipe,
coordenando a equipe para que as metas sejam alcanadas.
Metodologias geis de desenvolvimento de software so iterativas, ou seja,
o trabalho dividido em iteraes, que, no Scrum, so chamadas de Sprints e,
geralmente, duram de 2 a 4 semanas.
A seguir, veremos as etapas do processo:
O Sprint representa um tempo definido dentro do qual um conjunto de
atividades deve ser executado. No incio de cada Sprint, faz-se um Sprint
Planning Meeting (reunio de planejamento), em que o Product Owner

REQUISITOS NAS METODOLOGIAS GEIS


141

(geralmente, o representante do stakeholder - cliente) prioriza todos os


itens do Product Backlog para que a equipe selecione as funcionalidades
que ser capaz de implementar durante o Sprint que se inicia.
Product Sprint Backlog (Backlog do Produto). As funcionalidades a serem
implementadas no projeto so mantidas em uma lista que conhecida
como Product Backlog. As funcionalidades alocadas em um Sprint so
transferidas do Product Backlog para o Sprint Backlog.
Kanban (Quadro de Trabalho). O time mantm um quadro de trabalho,
em que organiza as atividades dos itens de Backlog da Sprint, classifican-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

do-as, geralmente, com os seguintes status: a fazer, em andamento, Em


testes e concludo. A Figura 26 demonstra um quadro de atividades:

Backlog Fila Fazendo Concludo

Validar Captcha Exibir Exibir


Cadastrar CPF user formulrio
resultado
Users

Confirmar Campos
senha Obrigatrios

Figura 26: Modelo de organizao do quadro de atividades no Scrum


Fonte: Metodologias geis (online).

Daily Scrum: com o objetivo de manter a equipe focada e dirimir impedi-


mentos mais rapidamente, diariamente, a equipe faz uma breve reunio
de, no mximo, 15 minutos com todos os participantes em p, chamada
Daily Scrum. Na Daily, cada integrante diz o que fez no dia anterior, o
que pretende fazer no dia que se inicia e se existe algum impedimento
que est atrapalhando o seu trabalho.
Sprint Review Meeting: reunio para apresentao do que foi implemen-
tado durante o Sprint e para a realizao de uma Sprint Retrospective para
identificar o que funcionou bem e o que pode ser melhorado para o pr-
ximo Sprint. Essa mesma reunio pode ser utilizada para o planejamento
do prximo Sprint.
Burn Down Chart. O Burndown um simples grfico, com dois eixos X e
Y, em que o eixo X representa o nmero de tarefas existentes no Sprint e

SCRUM
142 UNIDADE V

o eixo Y os dias que representam o tamanho do Sprint. A Figura 27 mos-


tra um grfico BurnDown.

% que Falta
para Fazer Burn Down Chart
100%

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Projeto atrasado

50%
Projeto adiantado
(entregando mais
que o esperado Recuperou, e
para a data) entregou adiantado

0%
Dia 1 Dia n Dia Final Tempo
Figura 27: Exemplo de grfico BurnDown para o acompanhamento das tarefas do Sprint
Fonte: Metodologias geis (online).

A escolha de uma metodologia de desenvolvimento uma das etapas no


incio do desenvolvimento de um novo software, assim como a escolha da
linguagem de programao e o banco de dados que ser utilizado. Saber
identificar a melhor metodologia a ser utilizada para o software em questo
repercute, sem dvida, em benefcios ao longo de todo o processo de fabri-
cao de um software. Vrias questes devem ser analisadas e levantadas
no momento da escolha, como: a quantidade de integrantes da equipe de
desenvolvimento, o tamanho do software que ser desenvolvido, o conhe-
cimento da metodologia por parte dos integrantes e o prazo de entrega.
Aprofunde seus conhecimentos estudando a implantao de um modelo
gil, o Scrum, no desenvolvimento de um software.
Fonte: Zenaro (2012, online).

REQUISITOS NAS METODOLOGIAS GEIS


143

Alguns estudos apontam fragilidades no Scrum, como a dificuldade em se captu-


rar requisitos, gerenci-los e de tratar as dependncias. Uma maneira de superar
essas fragilidades utilizar o Scrum em conjunto com alguma ferramenta CASE
para gesto de projetos, que possibilite o registro e a rastreabilidade dos user stories.

ESPECIFICAO DE REQUISITOS GEIS


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Em processos geis, a especificao dos requisitos se d por meio dos user sto-
ries. Como estudamos na unidade II, trata-se de uma tcnica de especificao
de requisitos.
O objetivo do user stories garantir equipe capacidade de responder rapi-
damente s necessidades do usurio. O user stories cria menos sobrecarga de
documentao e mostra, de forma rpida, a evoluo das necessidades do cliente
ou a descoberta de novos requisitos no decorrer do desenvolvimento.
O levantamento e gerenciamento dos requisitos nos processos geis
acontece durante todo o ciclo de vida de desenvolvimento, e conta com a
participao efetiva do Stakeholder, promovendo esclarecimentos imediatos
no caso de dvidas.
Relembrando o estudado na unidade II, os user stories so comumente escri-
tos em cartes utilizados. Segundo Longo e Silva (2014), o carto a parte visvel
dos user stories, mas no a mais importante. Ali, fica registrado o texto de um
requisito, mas os seus detalhes so discutidos nas reunies entre a equipe e o stake-
holder para, em seguida, o requisito, aqui chamado de histria, ser registrado e
verificado por meio da confirmao. Voc pode rever a forma recomendada de
escrever um user stories registrada na unidade II.
Longo & Silva (2014) dizem que uma das principais diferenas das histrias
de usurio para as declaraes tradicionais de requisitos est na comunica-
o verbal. A linguagem escrita , muitas vezes, imprecisa e no garante que
um cliente e/ou desenvolvedor ir interpretar uma declarao da mesma
forma. A garantia da compreenso est na conversa com o cliente. Algumas

Especificao de Requisitos geis


144 UNIDADE V

vantagens dos user stories foram levantadas por Longo e Silva (2014) e so
relacionadas a seguir:
Podem ser utilizadas prontamente no planejamento do projeto.
So escritas de modo a permitir que estimativas de complexidade, custo
e prazo sejam especificadas a partir delas.
So implementadas por completo em determinada iterao de um pro-
jeto gil.
Incentivam a equipe a adiar detalhes de coleta. Uma histria inicial pode

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ser escrita e, quando necessrios mais detalhes, podem ser substitudas
com histrias mais detalhadas.
Iniciar a codificao muito mais cedo. Uma equipe pode muito rapida-
mente, escrever algumas histrias para dar-lhes uma sensao geral do
sistema.
Facilita a priorizao dos requisitos. Se considerar milhares ou dezenas
de milhares de declaraes do tipo o sistema deve... em uma especifica-
o de requisitos de software (e as relaes entre eles), pode-se encontrar
dificuldades em prioriz-los.

importante registrar que um user story no um requisito. Segundo


Longo & Silva (2014), enquanto os requisitos sugerem o que deve ser feito,
user stories focam nos objetivos, e isso torna a viso do produto completa-
mente diferente.
A diferena final entre as histrias de usurio e o padro IEEE 830 de requi-
sitos, como afirma Longo & Silva (2014), em relao ao custo do requisito que
no visvel at que todos os requisitos sejam escritos. O cenrio tpico que
um ou mais analistas passam dois ou trs meses escrevendo um documento de
requisitos. Esse documento , ento, entregue aos programadores, que detectam
que o projeto levar 24 meses, ao invs dos seis meses previstos.
A especificao de um requisito em um user stories deve seguir as mesmas

REQUISITOS NAS METODOLOGIAS GEIS


145

As exigncias do mercado mudaram e, com isso, a engenharia de requisi-


tos teve que se adequar a elas. Os mtodos geis alteraram processos da
engenharia de requisitos tradicional e os adaptaram para seus interesses.
Tradicionalmente, engenharia de requisitos fortemente baseada em do-
cumentao para compartilhar conhecimento, enquanto nas metodologias
geis so focados em colaborao entre desenvolvedores e clientes para
garantir objetivos similares.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Leia mais em: Desenvolvimento gil: anlise sobre requisitos tradicionais,


disponvel em: <http://www.devmedia.com.br/desenvolvimento-agil-ana-
lise-sobre-requisitos-tradicionais/30202#ixzz3ZIm1vbYk>. Acesso em: 8 jul.
2015.
Fonte: o autor.

recomendaes de especificao das metodologias tradicionais. Para auxiliar essa


atividade, uma vez que o prprio cliente pode ser designado para descrever os
user stories, a IBM desenvolveu uma tcnica chamada INVEST: Independente,
Negocivel, Valiosa, Estimvel, Pequena (Small) e Testvel.
Independente: um user story deve ser nico, tudo o que necessita ser
escrito deve estar contido ali, no havendo a necessidade de outros itens
para complementar o seu significado.
Negocivel: o user story nunca deve ser fechado, dessa forma, na neces-
sidade de acrescentar ou retirar alguma informao, o seu autor pode
intervir sem maiores problemas.
Valiosa: no colocar informaes desnecessrias para no poluir o carto.
Ao realizar essa seleo, user stories se tornam mais eficazes.
Estimvel: descrever o item de forma a possibilitar estimativas de comple-
xidade, a fim de determinar o tempo necessrio para seu desenvolvimento.
S dessa forma que a equipe poder decidir quantos user stories sero
assumidos para a implementao no tempo determidado para a iterao.
Small (pequeno): a descrio no user story deve ser breve.

Especificao de Requisitos geis


146 UNIDADE V

Testvel: os itens que compem aquele user story devem sempre possi-
bilitar testes.

Os requisitos geis so testados a cada iterao dentro do processo gil de desen-


volvimento. Testes de aceitao so criados a partir de critrios de aceitao.
Segundo Longo & Silva (2014), os critrios de aceitao definem os limites de
user stories e so usados para confirmar quando uma histria concluda e se
est funcionando conforme o esperado.
Os critrios devem ser escritos em linguagem simples, assim como o user
story. Quando a equipe de desenvolvimento concluir o user story, dever demons-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
trar a funcionalidade para o cliente, mostrando como cada critrio solicitado foi
satisfeito. Um user story no considerado completo at que seu teste de acei-
tao tenha sido aprovado.

CONSIDERAES FINAIS

Enfim, chegamos ao final de nossa disciplina, nesta ltima unidade, vimos


que a adoo dos processos na engenharia de requisitos fundamental para
sucesso de qualquer tipo de projeto, os processos tradicionais exigem mais
tempo nas etapas iniciais de planejamento e levantamento de requisitos. Os
mtodos geis foram propostos para solucionar a burocracia imposta pelos
modelos tradicionais, mas no extinguem por completo os documentos a
serem gerados na fase de planejamento e elicitao dos requisitos, a proposta
reduzi-los e torn-los mais prticos, a fim de diminuir o esforo empregado
nessas etapas e impulsionar a equipe de desenvolvimento para a implemen-
tao em menos tempo.
A entrega de valor objetivo nos mtodos geis e se inicia na definio dos
requisitos. Os stakeholders participam ativamente durante todo o ciclo de vida
do projeto e os requisitos so implementados conforme a prioridade estipulada
por eles.

REQUISITOS NAS METODOLOGIAS GEIS


147

A documentao do processo tradicional no produzida da mesma maneira


na metodologia gil, ela apresenta os requisitos de maneira executvel e imple-
mentvel, priorizando uma documentao enxuta e eficaz.
O engenheiro de requisitos na metodologia gil pode assumir o papel de pro-
duct owner e tem como objetivo escrever somente o suficiente. Foi apresentada
uma tcnica para garantir que a descrio registrada no user stories seja curta,
clara e objetiva. O que foi especificado no user stories deve ser uma unidade de
desenvolvimento nica e passvel de teste, porque um user stories somente con-
siderado finalizado depois de ter seu teste validado.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Finalmente, percebemos que a engenharia de requisitos deve se fazer presente


nos processos geis, para garantir aos requisitos a capacidade de relacionamento
e de rastreamento.

Consideraes Finais
1. O termo Sprint aplica-se ao modelo gil do processo de engenharia de software
denominado:
a. XP.
b. DAS.
c. DSDM.
d. Scrum.
e. Crystal.

2. Um dos principais conceitos do Scrum a implantao de um controle descen-


tralizado, capaz de lidar de forma mais eficiente em ambientes pouco previsveis.
Quais so os papis definidos pelo framework para gerenciar essas questes?
a. Product Owner, Product Backlog e Planning Meeting.
b. Product Owner, Scrum Master e Team.
c. Product Owner, Scrum Team e Scrum Master.
d. Sprint, Scrum Master e Planning Meeting

3. Sobre os user stories, correto afirmar que:


a. O user story tem a intenso real de fornecer equipe uma capacidade para
responder rapidamente o que o usurio quer e precisa.
b. O user story cria sobrecarga de documentao e mostra a evoluo das neces-
sidades do cliente.
c. Com os user stories, o levantamento e gerenciamento dos requisitos nos pro-
cessos geis acontecem durante toda a fase de elicitao de requisitos.
d. Os user stories so comumente escritos em planilhas utilizadas para detalhar
em uma linguagem tcnica os requisitos.
149

A HISTRIA DA TAHINI-TAHINI: MELHORIA DE PROCESSOS DE


SOFTWARE COM MTODOS GEIS E MODELO MPS

A discusso sobre a possibilidade ou no da sucesso, nesta excelente iniciativa do MCTI.


utilizao de mtodos geis em conjunto
com modelos de maturidades em proces- Nelson Franco, gerente de Qualidade da
sos de software frequente e atual. Alguns Softex, espera que esta publicao motive
consideram que as exigncias dos modelos as empresas a investirem na melhoria con-
de maturidade no podem ser implementa- tnua de seus processos de software e de
das em organizaes com desenvolvimento sua competitividade tanto no mercado
gil. Outros consideram que a implemen- brasileiro como no exterior. Kival Weber,
tao destes modelos ir ferir a agilidade coordenador executivo do programa MPS.
do desenvolvimento. Esta incompatibili- BR, lembra que o modelo MPS-SW (Sof-
dade discutida, portanto, por defensores tware) est sendo implementado desde
do uso de mtodos geis e por defensores 2004 no Brasil e, de maro de 2010 a maro
dos modelos de maturidade. de 2014, na Colmbia, Peru e Mxico no
mbito do Projeto BID/FUMIN Rede
Neste contexto se situa o livro A Histria da Latino Americana da Indstria de Sof-
Tahini-Tahini: Melhoria de Processos de Sof- tware (RELAIS). Este ano, nossa meta
tware com Mtodos geis e Modelo MPS superar a marca das 500 avaliaes MPS,
de Jorge Boria, Viviana Rubinstein e Andrs dando tambm sequncia ao processo
Rubinstein. de internacionalizao do modelo MPS,
complementa. Coordenado pela Softex, o
O livro teve origem em uma chamada programa mobilizador MPS.BR Melhoria
realizada em dezembro de 2011 pela Secre- de Processo do Software Brasileiro j totali-
taria de Poltica de Informtica SEPIN, do zou 491 Avaliaes MPS-SW (Software) em
Ministrio de Cincia, Tecnologia e Inova- empresas de todas as regies do pas, mui-
o MCTI, responsvel pela conduo do tas das quais utilizam mtodos geis, em
Programa Brasileiro de Qualidade e Produti- um intervalo de tempo justo e a um custo
vidade em Software PBQP Software, para mdico. Desse total, 70% so empresas de
o Ciclo 2012 do Programa Srie de Livros micro, pequeno e mdio porte e 30% so
do PBQP Software. Entre vrios concorren- grandes organizaes pblicas e privadas.
tes foi o texto selecionado para publicao. A iniciativa conta com investimentos das
empresas e apoio do Ministrio da Cincia,
um livro tcnico, mas fascinante e de Tecnologia e Inovao (MCTI), da Finan-
leitura muito agradvel. Por vezes nos leva ciadora de Estudos e Projetos (FINEP), do
a rir, tamanho o bom humor dos autores ao Banco Interamericano de Desenvolvimento
tratar o tema. Certamente ser um caso de (BID/FUMIN) e do SEBRAE.
Fonte: Modelo MPS (2013, online).
MATERIAL COMPLEMENTAR

Metodologias geis: Engenharia de Software Sob


Medida
Paulo Cesar de Macedo, Jos Henrique Teixeira de Carvalho Shrocco
Editora: Erica
Sinopse: Tendo em vista o crescente interesse pelo uso das
metodologias geis, esta obra apresenta, de maneira comparativa
e completa, as caractersticas, aplicaes e exemplos de seus
principais paradigmas, tais como Iconix, SCRUM, XP, FDD, DSDM,
ASD e famlia de metodologias Crystal. Contempla tambm
um captulo sobre uma nova proposta de metodologia gil,
desenvolvida para ser utilizada em projetos acadmicos. Destinada a estudantes e pesquisadores
da rea de computao e de gesto de projetos, mostra-se alinhada com as novas tendncias
mundiais, necessrias para atender aos requisitos da atual realidade de mercado de projetos de
software.
151
CONCLUSO

Chegamos ao final de mais uma etapa! Juntamente com esta unidade, encerramos a
disciplina de Engenharia de Requisitos. Espero que voc tenha aprendido um pouco
mais com os temas abordados neste material.
Tentamos estabelecer elementos prticos versus tericos que contribuam com a
sua formao. A engenharia de software exige que tenha um entendimento global
de todos os seus processos, o que, didaticamente, no possvel e, por isso, seus
processos so divididos em disciplinas especficas. No decorrer do seu curso, faa
um esforo para compreender o funcionamento dos processos na prtica, a fim de
estabelecer um paralelo.
Definimos, durante nossos estudos, que engenharia de requisito pode ser definida
como um conjunto das atividades envolvidas no levantamento, documentao e
manuteno de um conjunto de requisitos para um sistema baseado em compu-
tador e que o processo de engenharia de requisitos apresenta dois tipos bsicos
de atividades: primeiro, a anlise do problema, em que so aplicadas as tcnicas
brainstorming, entrevistas, etnografia, a fim de identificar as funes e as poss-
veis restries sobre a soluo do problema; segundo, a especificao do produto,
escrever, negociar, validar e preparar o Documento de Requisitos que representa o
comportamento esperado do produto.
Finalizamos falando sobre as metodologias geis de desenvolvimento de software,
manifesto de profissionais da rea contra prazos e a complexidade dos mtodos
tradicionais da engenharia de software. Nessa metodologia, a engenharia de requi-
sitos fica em plano de fundo, uma vez que os requisitos so desenvolvidos medida
que o software desenvolvido.
Esperamos ter alcanado o objetivo inicial, que era mostrar a importncia da en-
genharia de requisitos. Desejamos que a utilizao do que foi aqui apresentado te
garanta sucesso e realizao profissional. Se, de alguma forma, pudemos ajudar, es-
tamos disposio! Muito obrigada pela ateno! At uma prxima!
153
REFERNCIAS

CALEGARO, B. Aula 9. Universidade Federal de Santa Catarina. Centro de Tecno-


logia. Disponvel em: <http://www-usr.inf.ufsm.br/~calegaro/ELC1069/Aula%2009.
pdf>. Acesso em: 8 jul. 2015.
CSAR, A. C. F. Qualidade de documento de requisitos, visando alguns padres,
normas e modelo. Monografia Curso de ps-graduao em Cincia da Computa-
o, Centro de Informtica, Universidade Federal de Pernambuco, 2008. Disponvel
em: <www.cin.ufpe.br/.../monografica_ER_ANA_CRISTINA_MESTRADO.doc>. Aces-
so em: 25 abr. 2015.
CORAZZIN, E. Escopo do Projeto X Escopo do Produto. Auctus Qualidade e Gesto.
Disponvel em: <http://www.auctus.com.br/escopo-do-projeto-x-escopo-do-pro-
duto/>. Acesso em: 30 jun. 2015.
CRISPIN, L.; GREGORY, J. Agile Testing: A practical guide for testers and agile teams.
Addison Wesley, 2009.
DAVID, L. Tcnicas para reunies em JAD (Joint Application Design). Disponvel
em: <http://engenhariadesoftware.info/downloads/JAD.ppt>. Acesso em: 03 set.
2012.
DEVMEDIA. Introduo a Requisito de Software. Disponvel em: <http://www.
devmedia.com.br/introducao-a-requisitos-de-software/29580>. Acesso em: 23 mar.
2015.
DICIONRIO do Aurlio. Significado de Processo. Disponvel em: <http://www.di-
cionariodoaurelio.com/processo>. Acesso em: 30 jun. 2015.
ENGENHARIA de requisitos: requisitos funcionais e no funcionais. Concurso de TI:
dicas e materiais para concursos. Disponvel em: <http://concursosdeti.net/engenha-
ria-de-requisitos-requisitos-funcionais-e-nao-funcionais/>. Acesso em: 06 jul. 2015.
FAGUNDES, R. M. Engenharia de requisitos: Do perfil do analista de requi-
sitos ao desenvolvimento de requisitos com UML e RUP. Salvador: E-book,
2011. Disponvel em: <https://books.google.com.br/books?id=i2pIBQAAQBA-
J&pg=PA23&lpg=PA23&dq=na+pratica+como+documentar+requisitos&-
source=bl&ots=hV_Na4Fthg&sig=_wp2TErMZ-1FCqVa9_HrVDph22c&hl=p-
t-BR&sa=X&ei=QfEhVd2xFsK0sAS1_4CwCQ&ved=0CE4Q6AEwCQ#v=onepage&-
q=na%20pratica%20como%20documentar%20requisitos&f=false>. Acesso em: 21
mar. 2015.
FARIA, C. Desdobramento da funo qualidade (QFD). Infoescola. Disponvel em:
<http://www.infoescola.com/administracao_/desdobramento-da-funcao-qualida-
de-qfd/>. Acesso em: 02 jul. 2015.
FILHO, A. M. da S. Desenvolvimento de Software requer Processo e Gesto. Revista
Espao Acadmico, n. 23, ago. 2011. Disponvel em: <http://www.periodicos.uem.
br/ojs/index.php/EspacoAcademico/article/viewFile/14312/7593>. Acesso em: 01
maio 2015.
REFERNCIAS

FILHO, A. M. da S. Documento de requisitos. Engenharia de Software Magazine, a.


1, 10. ed. Disponvel em: <http://academico.ifrr.edu.br/uploads/MATERIAIS_AULAS/
7243-DOCUMENTO_DE_REQUISITOS.pdf>. Acesso em: 22 jun. 2015.
FOURNIER, R. Guia prtico para o desenvolvimento e manuteno de sistemas
estruturados. So Paulo: Makron Books, 1994.
GALEOTE, S. Levantamento e anlise de requisitos: uma viso pragmtica sobre fer-
ramentas. Qualidade de Software. Disponvel em: <http://www.galeote.com.br/
blog/2012/05/levantamento-e-anlise-de-requisitos-uma-viso-pragmtica-sobre-fer-
rametas/>. Acesso em: 6 jul. 2015.
GENVIGIR, E. C. Um modelo para rastreabilidade de Requisitos de software ba-
seado em Generalizao de elos e atributos. 2001. 202f. Tese (Doutorado) Ps-
Graduao em Computao Aplicada, INPE, So Jos dos Campos. 2009. Disponvel
em: <http://mtc-m18.sid.inpe.br/col/sid.inpe.br/mtc-m18@80/2009/03.02.14.17/
doc/publicacao.pdf?languagebutton=pt-BR>. Acesso em: 01 maio. 2015.
GUIA PMBOK - Project Management Body of Knowledge Experincia e Co-
nhecimento em Gerenciamento de Projetos. Disponvel em <http://pmkb.com.br/
artigo/analise-e-classificacao-dos-stakeholders-para-gestao-de-projetos/>. Acesso
em: 25 mar. 2015.
IBM Rational Software. Disponvel em: <http://www.ibm.com/software/rational>.
Acesso em: 01 maio 2015.
IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610 12-1990,
december, 1990, p. 67.
INSTITUTE of Electrical and Electronics Engineers. Recommended practice for sof-
tware requirements specifications. Revision 830. New York: IEEE: 1998.
KAREL, R. Menos coleta de requisitos, mais explorao de dados. Informatica. Dis-
ponvel em: <http://international.informatica.com/br/potential-at-work/informa-
tion-leaders/less-requirements-gathering-more-data-exploration.aspx>. Acesso
em: 22 jun. 2015.
KARLSSON, J.; RYAN, K. A Cost-Value Approach for Prioritizing Requirements,
IEEE Software, Sept./Oct. 1997, p. 67-74.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Process and Techni-
ques. John Wiley and Sons: 1998.
LONGO, H. E. R.; SILVA, M. P. da. A Utilizao de Histrias de Usurios no Levantamen-
to de Requisitos geis. Int. J. Knowl. Eng. Manag, Florianpolis, v.3, n.6, p. 1-30, jul/
nov, 2014.
MEDEIROS, H. Princpios da Engenharia de Software. Devmedia. Disponvel em
<http://www.devmedia.com.br/principios-da-engenharia-de-software/29630>.
Acesso em: 29 mar. 2015.
155
REFERNCIAS

METODOLOGIAS geis SCRUM. BRQ. Disponvel em: <http://www.brq.com/meto-


dologias-ageis/>. Acesso em: 06 jul. 2015.
MICHAELIS. Dicionrio online. Disponvel em: < http://michaelis.uol.com.br/>. Aces-
so em: 8 jul. 2015.
MODELO MPS e Mtodos geis tema de livro. Acate. Disponvel em: <https://www.
acate.com.br/node/45474>. Acesso em: 24 jun. 2015.
O MANIFESTO GIL. Agile Alliance. Disponvel em: < http://www.agilealliance.org/
pt/o-manifesto/>. Acesso em: 8 jul. 2015.
OLIVEIRA, C. Utilizao de checklist para validao de requisitos de software. iMas-
ter.com, 2014. Disponvel em: <http://imasters.com.br/desenvolvimento/software/
utilizacao-de-checklist-para-validacao-de-requisitos-de-software/>. Acesso em: 01
maio. 2015.
PMKB. Anlise e Classificao dos stakholders para gesto de projetos. Dispon-
vel em: <http://pmkb.com.br/artigo/analise-e-classificacao-dos-stakeholders-para-
-gestao-de-projetos/>. Acesso em: 30 jun. 2015.
PMSURVEY.ORG. A global intiative of PMI chapters. Disponvel em: <http://pmsur-
vey.org/>. Acesso em: 8 jul. 2015.
PRESMAN, R. S. Engenharia de Software. 6. ed. Porto Alegre: McGrawHill, 2010.
PRIBERAM, Dicionrio da Lngua Portuguesa. Eliciar. Disponvel em: <http://www.
priberam.pt/dlpo/eliciar>. Acesso em: 05 maio. 2015.
PRIMO, G. User Storie o que so? Como usar? Blog ScrumHalf. Disponvel em:
<http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/>.
Acesso em: 02 jul. 2015.
RAMIRES, J. J. da C. V. Negociao de requisitos no processo de desenvolvimen-
to de software. Dissertao (Mestrado em informtica) Faculdade de Cincias,
Universidade de Lisboa, 2004. Disponvel em: <http://www.di.fc.ul.pt/~paa/reports/
T13.pdf>. Acesso em: 28 abr. 2015.
RIBEIRO, F.G.; SOUZA, R. L. da S. A importncia da engenharia de requisitos para
o ciclo de desenvolvimento de software de tempo real. In: MOSTRA CIENTFICA
DO CENTRO DE ENSINO SUPERIOR DE CATALO, 10., 2012, Catalo. Resumo...
Catalo, 2012. Disponvel em: <http://www.cesuc.br/_xmostracientifica/artigos/ar-
tigo_5.pdf>. Acesso em: 05 maio 2015.
SAYO, M.; BREITMAN, K. K. Gerncia de Requisitos. Faculdade de Informtica da
PUC-RS e DI/PUC-Rio. Disponvel em: <http://www-di.inf.puc-rio.br/~karin/TELE-
COM/index_files/gerencia_req.pdf>. Acesso em: 07 maio. 2015.
SAYO, S.; STAA, A. v.; LEITE, J. C. S. do P. Qualidade em requisito. Monografia em
Cincia da Computao Departamento de Informtica Pontifcia Universidade
REFERNCIAS

Catlica, Rio de Janeiro. Disponvel em: <http://www.dbd.puc-rio.br/depto_infor-


matica/03_47_sayao.pdf>. Acesso em: 8 jul. 2015.
SIGNIFICADOS.com.br. Significado de Brainstorming. Disponvel em: <http://
www.significados.com.br/brainstorming/>. Acesso em: 06 jul. 2015.
SILVA, M. A. A importncia do levantamento de requisitos no sucesso dos projetos
de software. Linha de Cdigo. Disponvel em: <http://www.linhadecodigo.com.br/
artigo/1685/a-importancia-do-levantamento-de-requisitos-no-sucesso-dos-proje-
tos-de-software.aspx#ixzz3ZIgykkYG>. Acesso em: 02 maio 2015.
SILVA, S. C. da L. e. Priorizao e negociao de requisitos. Monografia Ps-gra-
duao em cincias da computao, Universidade Federal de Pernambuco, 2008.
Disponvel em: <http://www.cin.ufpe.br/~in1020/arquivos/monografias/2008-1/
Monografica_SCLS.pdf>. Acesso em: 28 abr. 2015.
SILVA, S. F. B. Engenharia de Requisitos: Uma anlise das tcnicas de levantamento
de requisitos. Monografia Curso de Cincia da Computao, Universidade FUMEC,
Belo Horizonte. 2012. Disponvel em: <http://www.ricardoterra.com.br/publica-
tions_files/students/2012_fumec_silva.pdf>. Acesso em: 01 maio. 2015.
SOMMERVILLE, I. Engenharia de Software. So Paulo: Pearson Prentice hall, 2008.
SOTILLE, M. A. Gerenciamento do escopo em projetos. Rio de janeiro: Editora FGV,
2014.
SOUZA, V. E. S. Exerccios Pizzaria Anlise de Objetivos. UFES. Disponvel em:
<http://www.inf.ufes.br/~vitorsouza/wp-content/uploads/academia-br-requisitos-
-exercicio-pizzaria-01-resolucao.pdf>. Acesso em: 01 jul. 2015.
STAKEHOLDERS: da identificao ao Plano de Gerenciamento de Comunicaes.
InovaGP. Disponvel em: <http://www.inovagp.com/2012/03/stakeholders-da-i-
dentificacao-ao-plano-de-gerenciamento-de-comunicacoes/>. Acesso em: 23 jun.
2015.
STANDISH Group. Chao Report. 2014. Disponvel em: <http://www.projectsmart.
co.uk/docs/chaos-report.pdf>. Acesso em: 04 maio 2015.
VIEIRA, D. Scrum: A Metodologia gil Explicada de forma Definitiva. MindMaster
Educao Profissional. Disponvel em: <http://www.mindmaster.com.br/scrum/>.
Acesso em: 04 jul. 2015.
ZENARO, F. dos S. A utilizao do Scrum em um sistema web: um estudo de caso.
T.I.S. Disponvel em: <revistatis.dc.ufscar.br/index.php/revista/article/downlo-
ad/16/20>. 05 maio 2015.
157
GABARITO

UNIDADE I

1. B.
2. D.
3. B.
4. D.
5. A.

UNIDADE II

1. C.
2. D.
3. A.
4. C.
5. A.
6. C.
7. B.

UNIDADE III

1. A.
2. D.
3. D.
4. D.
5. A.
6. C.
7. C.
8. A.
GABARITO

UNIDADE IV

1. A.
2. C.
3. A.
4. B.

UNIDADE V

1. D.
2. B.
3. A.

Você também pode gostar