Engenharia Requisitos

:
(
)
{
; =
=
E
n
c
o
d
i
n
g
c
a
p
t
i
o
n
C
o
n
t
e
n
T
y
p
e
End
inline
:
:
TEMA II
TPICOS EM ENGENHARIA
DE SOFTWARE
C
E
R
T
I
F
I
C
A
O

E
M

T
E
C
N
O
L
O
G
I
A

D
A

I
N
F
O
R
M
A
O
APRESENTAO GERAL
TEMA II - TPICOS EM ENGENHARIA DE SOFTWARE
Engenharia de software o estudo ou a aplicao de uma aborda-
gem sistemtica, disciplinada e baseada em mtodos quantitativos para
o desenvolvimento, manuteno e operao de sistemas de software
(http://www.swebok.org/ch1.html#Ref1). Engloba tcnicas e prticas de
gerncia de projetos, linguagens de programao, bases de dados, fer-
ramentas, plataformas, bibliotecas, padres e processos.
O termo foi criado na dcada de 1960 e utilizado ocialmente em 1968
na NATO Conference on Software Engineering (Conferncia sobre Enge-
nharia de Software da OTAN). Sua criao surgiu numa tentativa de
contornar a crise do software e dar um tratamento de engenharia (mais
sistemtico e controlado) ao desenvolvimento de sistemas de software
complexos.
Com as constantes e extraordinrias evolues no hardware ao longo
dos ltimos anos, pode-se notar que as mudanas nos softwares foram
igualmente signicativas. A capacidade e a necessidade de criar gran-
des e complexos sistemas aumentaram. Os servios e a infra-estrutura
nacionais energia, comunicaes e transporte contam amplamente
com sistemas de computadores muito complexos e conveis. (SOM-
MERVILLE,2007).
Para as atividades de modelagem podemos citar trs mtodos: Anlise
estruturada, criada por Gane & Searson; Anlise essencial, criada por
Palmer & McMenamin e Ed. Yourdon; Unified Modeling Language (UML)
criada por Grady Booch, Ivar Jacobson & Jaimes Rumbaugh.
Na Metodologia Estruturada, na qual existem vrios mtodos, como
Anlise Estruturada e Projeto Estruturado (muitas vezes denominados
SA/SD e Anlise Essencial). Tanto a Anlise Estruturada quanto a An-
lise Essencial utilizam a ferramenta Diagrama de Fluxos de Dados para
modelar o funcionamento do sistema e um Modelo de Entidades e Re-
lacionamentos (MER). Na Metodologia Orientada a Objetos destacamos
a Orientao a Objetos e Rational Unified Process (RUP).
Outro ponto importante abordado no material o uso de ferramentas
CASE (do ingls Computer-Aided Software Engineering), cuja classica-
o abrange toda ferramenta baseada em computadores que auxiliam
atividades de engenharia de software, desde a anlise de requisitos e
modelagem at programao e testes.
Atualmente, existem inmeras atividades cotidianas que envolvem al-
guma interao com banco de dados. Ao efetuarmos um depsito ou
uma retirada de dinheiro em um banco, provavelmente estaro envolvi-
dos um programa ou uma pessoa que acessa um banco de dados. Desta
forma, nalizando o material so introduzidos conceitos bsicos neces-
srios para projetar, implementar, manter e utilizar sistemas de banco
de dados, que podem ser criados e mantidos por programas aplicativos
e por um Sistema Gerenciador de Banco de Dados.
MDULO A - Engenharia de Requisitos
CERTIFICAO EM TECNOLOGIA DA INFORMAO
Braslia, dezembro de 2008.

LISTA DE FIGURAS
Figura 1 Atividades da Engenharia de Requisitos ..............................................................................................................................................................15A
Figura 2 Atividades da Elicitao de Requisitos ................................................................................................................................................................16A
Figura 3 Processos para a Elicitao de Requisitos ...........................................................................................................................................................20A
Figura 4 Processos de negociao e priorizao de requisitos ......................................................................................................................................... 21A
Figura 5 Processo de vericao de requisitos ...................................................................................................................................................................22A
Figura 6 Tipos de requisitos ................................................................................................................................................................................................23A
Figura 7 Requisitos no-funcionais ....................................................................................................................................................................................25A
Figura 8 Exemplo da relevncia de caractersticas de acordo com o tipo de software ..................................................................................................25A
Figura 9 Modelos utilizados na Anlise de Requisitos ......................................................................................................................................................27A
Figura 10 Processo de Validao de Requisitos .................................................................................................................................................................28A
Figura 11 Fluxo de Requisitos .............................................................................................................................................................................................30A

LISTA DE QUADROS
Quadro 1 - Estatsticas importantes sobre projetos de software ........................................................................................................................................30A
Quadro 2 - Fontes de informaes relacionadas Gesto de Requisitos ........................................................................................................................... 31A
LISTA DE SIGLAS
API - Application Programming Interface
CCB - Comit de Controle de Mudana
DRS - Documento de Requisitos de Sistema
IEC - International Electrotechnical Commission
IEEE - Institute of Electrical and Electronics Engineers
ISO - International Organization for Standardization
JAD - Joint Application Design
RUP - Rational Unied Process
SUMRIO
RESULTADOS ESPERADOS DO APRENDIZADO ..................................................................................................................................................................... 11A
APRESENTAO .......................................................................................................................................................................................................................13A
1 - Elicitao de Requisitos .....................................................................................................................................................................................................14A
1.1 - Conceitos .........................................................................................................................................................................................................................14A
1.2 - Atividades da elicitao de requisitos ...........................................................................................................................................................................16A
1.3 - Diculdades da elicitao ..............................................................................................................................................................................................17A
1.4 - Tcnicas de elicitao .....................................................................................................................................................................................................17A
1.5 - Processos para a elicitao de requisitos ......................................................................................................................................................................19A
2 - Anlise e Negociao de Requisitos .................................................................................................................................................................................20A
2.1 - Solicitaes x necessidades ............................................................................................................................................................................................22A
2.2 - Encontros de negociao ...............................................................................................................................................................................................23A
3 - Especicao de Requisitos ..............................................................................................................................................................................................23A
3.1 - Atividades da elicitao de requisitos ...........................................................................................................................................................................23A
3.2 - Requisitos no-funcionais .............................................................................................................................................................................................24A
3.3 - Classicao de Requisitos no-funcionais no Banco do Brasil .................................................................................................................................25A
4 - Modelagem do Sistema .....................................................................................................................................................................................................27A
5 - Validao de Requisitos .....................................................................................................................................................................................................28A
6 - Fluxo de Requisitos no RUP .............................................................................................................................................................................................29A
7 - Gesto de Requisitos .........................................................................................................................................................................................................29A
7.1 - Introduo .......................................................................................................................................................................................................................29A
7.2 - Informaes utilizadas (Entradas) e produzidas (Sadas) ............................................................................................................................................ 31A
REFERNCIAS BIBLIOGRFICAS ............................................................................................................................................................................................32A
11A
M
D
U
L
O

A
Identicar os conceitos que permitem levantar
requisitos de sistema e especic-los.
1
2
Identicar os elementos da anlise e da
negociao de requisitos.
RESULTADOS ESPERADOS DO APRENDIZADO
3
Identicar as principais caractersticas da
especicao de requisitos.
4
Descrever o processo de validao e gesto de
requisitos.
13A
M
D
U
L
O

A
APRESENTAO
A Engenharia de Requisitos tem sido reconhecida como uma das mais
importantes disciplinas em Engenharia de Software porque a maior
parte dos problemas de desenvolvimento de software so originados
por denies equivocadas de requisitos. As atividades de Engenharia
de Requisitos so executadas de forma mais intensa nas etapas iniciais
do desenvolvimento de software e direcionam fortemente o uso dos
recursos ao longo de todo o desenvolvimento e, depois, ao longo de
todo o ciclo de vida do produto. Por isso, problemas de correo mais
dispendiosa e de maior impacto negativo no projeto freqentemente
so decorrncia de falhas em Engenharia de Requisitos.
No processo de especicao de requisitos, as principais atividades po-
dem ser denidas como: elicitao, anlise, modelagem, validao e
gerenciamento de requisitos. Normalmente, falhas na realizao destas
atividades resultam em documentos de requisitos inconsistentes, in-
completos e conseqentemente produtos de software de baixa quali-
dade.
14A
1 - Elicitao de Requisitos
1.1 - Conceitos
Os requisitos de um projeto de software formam a base para o plane-
jamento, o acompanhamento do desenvolvimento, e a aceitao dos
resultados do projeto de software. Portanto, muito importante que
esses requisitos estejam bem denidos e acordados entre os envolvi-
dos. Se os requisitos so especicados de forma incompleta ou incon-
sistente, os artefatos resultantes das prximas etapas do processo de
software (por exemplo, projeto, implementao e testes) no tero a
qualidade desejada. Quanto mais tarde os problemas na especicao
de requisitos forem detectados no processo de desenvolvimento, maior
ser o custo de correo do software.
Com um processo bem denido pode-se obter (elicitar), entender e
validar as necessidades e expectativas do cliente e, posteriormente, do-
cument-las no Documento de Requisitos de Sistema (DRS). O docu-
mento de requisitos descreve os servios e funes que o sistema deve
prover, as limitaes sobre as quais o sistema deve operar, as proprieda-
des gerais do sistema, isto , limitaes nas propriedades emergentes,
as denies de outros sistemas com os quais o sistema deve integrar,
as limitaes no processo usado para desenvolver o sistema e as descri-
es sobre o hardware no qual o sistema ir executar.
O DRS constitui a base para as estimativas de tamanho, de esforo,
de cronograma, e de custo. Assim, quando as estimativas de tamanho,
prazo e custo so gerados a partir de requisitos incompletos, ambguos,
omissos ou inconsistentes, as estimativas no sero precisas resultando
em prejuzo e descumprimento dos prazos.
Segundo o IEEE Institute of Electrical and Electronics Engineers, Re-
quisito uma condio ou capacitao necessria a um usurio para
solucionar um problema ou encontrar um objetivo; (b) uma condi-
o ou capacitao que um sistema ou componente do sistema precisa
atender ou ter para satisfazer um contrato, padro, especicao, ou
outro documento formalmente estabelecido. O conjunto de todos os
requisitos forma a base para o posterior desenvolvimento do sistema ou
componente do sistema.
Os requisitos descrevem o que o sistema deve fazer e tambm o
que ele no deve fazer sem dizer (ou detalhar) o como fazer e de-
vem ter as seguintes caractersticas:
Vericveis: se no podemos vericar o atendimento de um dado
requisito, tanto faz se ele existir ou no. A vericao ocorre mediante
procedimentos de teste, experimentos e provas ou por meio de acordos
de aceitao previamente denidos;
Precisos: requisitos devem ser expressos precisamente, de outro modo
no se pode garantir que iro ser interpretados da mesma forma por
todas as pessoas envolvidas;
Corretos: requisitos devem expressar corretamente o que requerido;
Consistentes: requisitos no devem conter conitos;
Completos: tudo que requerido deve ser expresso;
Compreensveis: todas as pessoas envolvidas devem entender, no seu
nvel de participao, o que est expresso em um requisito;
Manutenveis: podemos alterar com facilidade um requisito quando
este muda ou evolui.
Para elaborar e manter uma especicao de requisitos necessrio que
os desenvolvedores executem um conjunto estruturado de atividades
15A
M
D
U
L
O

A
destinadas a elicitar, documentar, analisar e validar requisitos. Este con-
junto de atividades, iterativas por natureza, recebe o nome de Processo
de Engenharia de Requisitos.
Quando a organizao no dispe deste processo formalmente denido
e amplamente divulgado, os desenvolvedores elaboram as especica-
es de requisitos de uma forma emprica, executando atividades no
padronizadas e denidas individualmente. Se isto ocorre, a qualidade
da especicao depender exclusivamente da experincia e formao
das pessoas, havendo assim uma elevada probabilidade de ocorrerem
conitos, incoerncias e re-trabalho.
Conforme pode ser observado na Figura 1, as atividades que compem
o Processo de Engenharia de Requisitos e um conjunto de boas prticas
que apiam a sua execuo so: elicitao, modelagem, anlise, valida-
o/vericao e gerenciamento de requisitos.
Elicitao
G
e
r
n
c
i
a
Modelagem
Verificao Validao
Anlise
Figura 1 Atividades da Engenharia de Requisitos
A etapa de elicitao de requisitos corresponde fase de entendimento
do problema. Elicitao o processo responsvel por descobrir informa-
es, compreender os fatos descobertos e adquirir conhecimentos. Para
tanto, so utilizadas diversas tcnicas que sero vistas posteriormente,
como a anlise dos uxos de trabalho dos usurios, a denio dos
atributos de qualidade do sistema e o desenvolvimento de mecanismos
que possibilitem o reuso de requisitos.
Na elicitao de requisitos, a redao de uma declarao de viso e es-
copo do sistema, a denio dos procedimentos para desenvolvimento
dos requisitos, a identicao das classes de usurios e dos diferentes
grupos de interesse no sistema, a identicao dos casos de uso cons-
tituem boas prticas.
A etapa de modelagem corresponde construo de um modelo do
software o qual representa o que se pretende construir e mostra no
somente os requisitos do problema, mas tambm como sero atendidos
pelos elementos da soluo. Os modelos do sistema permitem uma
melhor compreenso do uxo de dados e de controle, o processamento
funcional e a operao comportamental, alm do contedo da infor-
mao. O modelo serve como fundamento para o projeto de software e
como base para a criao de sua especicao.
A etapa de anlise de requisitos corresponde modelagem lgica do
sistema. Nesta fase, os requisitos especicados so transformados em
modelos que representam o sistema em mbito conceitual. A documen-
tao resultante dessa fase servir como instrumento de comunicao
entre usurios e desenvolvedores e dever ser clara, precisa, completa,
consistente, sem ambigidade e de fcil modicao.
16A
As fases de validao e vericao dos requisitos correspondem con-
rmao dos conhecimentos adquiridos junto aos clientes/usurios e
vericao se os requisitos se encontram implementados corretamente
nos modelos do processo de desenvolvimento de software respectiva-
mente. Tudo isso feito sob uma gerncia responsvel pelo acompa-
nhamento das fases por meio de avaliao contnua dos resultados
obtidos.
So participantes do processo:
1. Clientes (Usurios) do Sistema: denem os requisitos e vericam se
eles satisfazem suas necessidades;
2. Lderes de Projeto: denem e usam os requisitos para planejarem
uma proposta e o processo de desenvolvimento do sistema;
3. Analistas e Analistas Desenvolvedores: usam os requisitos para en-
tender e especicar o sistema em construo;
4. Analistas de teste do sistema: usam os requisitos para desenvolver
testes de validao do sistema;
5. Analistas de manuteno do sistema: usam os requisitos para en-
tender o sistema.
6. Representantes da rea de Infra-estrutura: usam requisitos no
funcionais para a concepo do sistema.
7. Representantes da rea de Operao de Sistemas: usam requisitos
no funcionais para a implantao do sistema.
1.2 - Atividades da elicitao de requisitos
Conforme pode ser visto na Figura 2, os componentes da elicitao de
requisitos so: entendimento do domnio da aplicao, entendimento
do problema a ser resolvido, entendimento do contexto do negcio e
entendimento das necessidades das partes interessadas (stakeholders).
Problema
a ser
resolvido
Domnio
Contexto
do negcio
Necessidades
dos
stakeholders
da aplicao
Figura 2 Atividades da Elicitao de Requisitos
Entender o domnio da aplicao o ponto inicial de todo o processo
de anlise. Os usurios e desenvolvedores possuem vises diferentes e
fazem suposies diferentes sobre a natureza da soluo. Uma mesma
linguagem compartilhada tanto por desenvolvedor como por usurio
melhora a comunicao e o entendimento entre ambos. Em outras pa-
lavras, a anlise do domnio consiste em estudar o domnio de forma a
identicar, formalizar e classicar as caractersticas elementares (objeto,
regras e limitaes).
O entendimento do problema corresponde a compreenso detalhada da
situao/problema existente que demanda uma soluo que seja a mais
apropriada e otimizada possvel.
Grupo de pessoas interessadas ou que inuenciam nos processos.
17A
M
D
U
L
O

A
O entendimento do contexto do negcio corresponde a compreenso
de como os sistemas envolvidos interagem entre si e contribuem de
forma direta ou indireta com os objetivos do negcio em questo.
Por ltimo, imprescindvel entender detalhadamente as necessidades
especcas dos usurios e demais pessoas que requerem suporte do
sistema em seu trabalho.
1.3 - Diculdades da elicitao
As principais diculdades na atividade de elicitao de requisitos, em
geral, esto relacionadas postura dos usurios diante da situao
atual e do sistema proposto, so elas:
Os usurios podem no ter uma idia exata do sistema por eles reque-
rido ou mesmo das solues possveis a serem oferecidas pelo sistema.
Em geral, os usurios tm diculdades para descrever seus conheci-
mentos sobre o domnio do problema.
Usurios e analistas tm pontos de vista diferentes referente ao proble-
ma e a possveis solues devido s diferentes formaes prossionais.
Os usurios podem ter restries de uso em relao ao novo sistema
e, com isso, se recusarem a participar da elicitao de requisitos, ou
mesmo fornecer informaes erradas.
1.4 - Tcnicas de elicitao
As Tcnicas de Elicitao correspondem s tcnicas que podem ser
utilizadas para coletar conhecimento sobre os requisitos dos usurios.
O conhecimento deve ser estruturado segundo as tcnicas de parti-
cionamento (agregao dos conhecimentos relacionados), abstrao
(expresses de alto nvel de comportamento de sistema que permitem
identicar generalidades) e projeo (organizao das informaes de
acordo com futuras perspectivas).
Alguns problemas, no entanto, devem ser superados como, por exem-
plo, o tempo reduzido dedicado para a etapa de elicitao, a falta de
preparo dos engenheiros quanto s tcnicas de elicitao e a prpria
postura dos stakeholders que nem sempre se encontram totalmente
convencidos da necessidade de um novo sistema.
De forma prtica, o processo de elicitao de requisitos deve comear
pelas perguntas bvias do tipo: o que?, por qu?, por quem?,
como?, porm existem tcnicas que podem ser seguidas para obter as
informaes necessrias de forma precisa e completa.
As principais tcnicas de elicitao so:
Tcnicas tradicionais inclui o uso de questionrios, de entrevistas e
de anlise de documentao existente.
1 - Questionrios questes pr-estabelecidas so distribudas
para uma amostragem signicante e representativa de stakeholders e,
por m, os resultados so avaliados. So extremamente teis quando
a quantidade de stakeholders grande. Como as questes so prede-
terminadas, mais eciente na avaliao de tendncias de opinies a
respeito de requisitos especcos de bem denidos. Duas grandes van-
tagens da elicitao por questionrio a padronizao das perguntas
e o tratamento estatstico das respostas. Porm esta tcnica limita o
universo das respostas devido reduzida interao com o usurio.
18A
2 - Entrevistas o engenheiro de requisitos ou analista levanta
questes relacionadas aos stakeholders e/ou suas necessidades referen-
te ao problema a ser resolvido. O processo de entrevista bastante til
devido ao contato direto com o usurio e a validao imediata, princi-
palmente quando os usurios possuem conhecimentos subjetivos e es-
to dispostos a serem entrevistados. As entrevistas podem ser fechadas
(com um conjunto de questes previamente estabelecidas), abertas (as
questes so levantadas no momento da entrevista) e do tipo tutorial
(o usurio dene as necessidades e requisitos). importante que os
entrevistadores estejam abertos s questes dos usurios, ou seja, no
faam a entrevista com noes pr-concebidas sobre o que hipoteti-
camente necessrio.
3 - Anlise de documentao existente requer abstrao e co-
nhecimento do vocabulrio da aplicao para extrair as informaes
relevantes. A maior vantagem a facilidade de acesso grande quan-
tidade de informaes. Por outro lado, tem-se grande disperso das
informaes e volume de trabalho.
JAD (Joint Application Design) uma tcnica de reunies, usando-
se um lder neutro e um processo estruturado, buscando-se consenso
sobre um assunto predeterminado: uma denio de produto; uma
denio de processo; uma especicao de requisitos. A tcnica busca
reduzir os prazos de levantamento e anlise dos requisitos; eliminar
requisitos de valor questionvel; aumentar a qualidade dos requisitos;
resolver diferenas de demandas entre usurios; reduzir diferenas de
interpretao dos requisitos entre usurios e desenvolvedores; trazer
tona, o mais cedo possvel, problemas polticos que possam interferir
no projeto; aumentar a motivao de usurios e desenvolvedores. Em
projetos com um nmero razovel de intervenientes, a tcnica se mos-
tra altamente recomendvel.
Tcnicas de elicitao de grupo so tcnicas de dinmica de grupo
cujo objetivo entender de forma mais detalhada as necessidades dos
usurios, dentre elas, o brainstorming. No brainstorming, os stakehol-
ders so reunidos em ambiente apropriado, onde a participao enco-
rajada de forma que todas as idias possam ser declaradas em voz alta
(para que os demais sejam inuenciados) e escritas (para que no sejam
perdidas). Esta tcnica mais ecaz quando cada stakeholder possui
uma parte do conhecimento de algum aspecto do problema.
Prototipao corresponde implementao parcial e rpida de um
sistema enfatizando principalmente a interface visual de forma a co-
letar informaes para o processo de requisitos. O prottipo pode ser
descartado ou evoluir para o produto nal. Tal tcnica usada para
elicitar requisitos quando h um alto grau de incerteza ou quando
necessrio um rpido feedback dos usurios.
Tcnicas de modelagem tcnica que visa representar os requisitos
em modelos conceituais que descrevem as necessidades encontradas na
elicitao, ou seja, fornece um modelo especco das informaes que
sero adquiridas, e usa o modelo para orientar o processo de elicitao.
Uma tcnica bastante utilizada o uso de cenrios para representar as
tarefas que os usurios executam normalmente e aquelas que eles de-
sejam executar. Inclui mtodos baseados em metas e mtodos baseados
em cenrios.
Tcnicas cognitivas inclui uma srie de tcnicas originalmente de-
senvolvidas para aquisio de conhecimento para sistemas baseados
em conhecimento. Por exemplo, anlise de protocolo, laddering, card
sorting, repertory grids.
19A
M
D
U
L
O

A
Tcnicas contextuais surgiu como uma alternativa para as tcnicas
tradicionais e cognitivas incluindo tcnicas de etnograa e anlise social.
Etnograa tcnica que prima pela observao dos potenciais usu-
rios em seu ambiente natural. Resulta em uma percepo mais precisa
do problema do que simplesmente perguntar aos usurios o que eles
fazem. Essa tcnica bastante til para suporte automao de uma
funo pouco ou no automatizada, particularmente quando so dis-
ponveis a observadores treinados sem noes pr-concebidas do pro-
blema e de sua soluo.
1.5 - Processos para a elicitao de requisitos
Os processos para a Elicitao de Requisitos podem ser observados na
Figura 3. Em geral, o processo de Elicitao de requisitos de software
recebe novos requisitos por meio de uma Solicitao de servio ou Soli-
citao de alterao de requisitos entre outras fontes e, uma vez docu-
mentados e analisados, so elaboradas as Matrizes de rastreabilidade e
o Documento de requisitos de software (DRS) que, por sua vez, entram
em um processo para negociao de prioridades, conforme detalhado
a seguir.
Efetuar a reunio inicial com o cliente participam da reunio
inicial com o cliente todas as partes interessadas (stakeholders). Nessa
reunio devem ser obtidos os principais assuntos que devero estar
presentes no Documento de Viso.
Entender o domnio da aplicao a reunio inicial com o cliente
fornecer a base para determinar os principais domnios para proceder
o desenvolvimento do sistema. Uma das principais diculdades enfren-
tadas pelo desenvolvedor de software a complexidade do domnio do
problema, ou seja, estabelecer um entendimento do domnio da aplica-
o procurando descobrir o mximo de informaes sobre o ambiente
onde o sistema atuar;
Identicar as partes interessadas (stakeholders) ou seja, identi-
car as pessoas interessadas pelo produto, ou que participaro do seu
desenvolvimento. Para cada stakeholder importante identicar nome
e funo;
Escolher a tcnica de elicitao ao escolher a tcnica de elicitao,
devem ser consideradas quais as fontes dos requisitos, a disponibilidade
e nvel de cooperao das pessoas, alm dos tipos de requisitos a se-
rem elicitados. A escolha da tcnica apropriada para elicitar requisitos
depende do tempo e dos recursos disponveis, assim como do tipo de
informao necessria.
Elaborar a lista de Requisitos Candidatos o objetivo desta ativida-
de descrever os requisitos relevantes do sistema, ou seja, aqueles que
contribuem para atender os objetivos do projeto, de forma a representar
as principais necessidades e funcionalidades do sistema, devendo ser
includos no Documento de Viso.
Estudar os Requisitos candidatos, os sistemas similares e os docu-
mentos coletados com o cliente documentos, arquivos e sistemas si-
milares devem ser inspecionados e abstrados para melhor compreender
o contexto do sistema, alm de permitir uma avaliao da possibilidade
de re-usabilidade de requisitos e de solues.
Elaborar o glossrio a denio de um glossrio necessria para
evitar ambigidades e facilitar a leitura de documentos do sistema onde
20A
os principais termos utilizados no domnio da aplicao e pelos desen-
volvedores e usurios devem ser denidos.
Elaborar o documento de Viso deve-se avaliar o conjunto de re-
quisitos essenciais para a denio do Documento de viso do software
e este deve incluir o escopo do projeto e suas limitaes, bem como as
principais caractersticas do software a ser desenvolvido.
Efetuar a reunio inicial
com o cliente
Escolher e executar
Tcnicas de Elicitao
Identifcar os
stakeholders
Entender o domnio
da aplicao
Elaborar a lista de
Requisitos Candidatos
Estudar: os Requisitos candidatos sistemas
similares e os documentos do cliente
Elaborar o Glossrio Elaborar o documento de Viso
Fim
Incio
C1
C2
C3
C4
Figura 3 Processos para a Elicitao de Requisitos
2 - Anlise e Negociao de Requisitos
O objetivo da anlise descobrir problemas, incompletude e inconsis-
tncia nos requisitos elicitados. Neste caso, os requisitos normalmente
so retornados aos stakeholders para resoluo por meio de um proces-
so de negociao. Outro importante objetivo da anlise de requisitos
descobrir as interaes entre requisitos e informar os conitos e sobre-
posies de requisitos.
As atividades da anlise de requisitos comeam com o reconhecimento
do problema, a avaliao do problema e sntese da soluo (modela-
gem), a especicao dos requisitos do software e por m a reviso.
A anlise intercalada com elicitao, pois os problemas so levantados
quando os requisitos so elicitados. Alm disso, uma lista de vericao
de problemas poder ser utilizada para auxiliar o processo de anlise
onde cada requisito poder ser avaliado em contrapartida a esta lista.
A lista de vericao da anlise consta de basicamente oito itens que
conduzem s perguntas que devem ser respondidas na anlise dos re-
quisitos. Os itens so:
Projeto prematuro Os requisitos incluem informao prematura de
projeto ou de implementao?
Requisitos combinados A descrio dos requisitos especica um re-
quisito nico ou pode ser desmembrada em vrios requisitos diferentes?
Requisitos desnecessrios O requisito realmente imprescindvel ou
ser que uma mera adio suprua ao sistema?
Uso de hardware no padronizado Os requisitos implicam uso de
uma plataforma de hardware no padronizada? Para tomar esta deci-
so, necessrio conhecer os requisitos de plataforma do computador.
Est de acordo com os objetivos de negcio O requisito consisten-
te com os objetivos de negcio denidos na introduo do documento
de requisitos?
21A
M
D
U
L
O

A
Ambigidade de requisitos O requisito ambguo, ou seja, poder
ser interpretado de forma diferente por pessoas diferentes? Quais so
as possibilidades de interpretao dos requisitos?
Realismo dos requisitos O requisito real no que se refere tecno-
logia usada para a implementao do sistema?
Teste dos requisitos H possibilidade de teste para comprovar se o
sistema satisfaz os requisitos?
Durante a negociao e priorizao de requisitos (Figura 4), as seguin-
tes atividades so realizadas:
Escolher a tcnica de negociao o processo de negociao de
requisitos tenta solucionar conitos entre usurios sem comprometer
a satisfao dos objetivos de cada um. Em geral, os modelos de ne-
gociao identicam as principais necessidades de cada usurio, ou
seja, atribuem prioridades aos requisitos, em seguida analisam esses
resultados para tentar garantir que os requisitos mais crticos sejam
atendidos.
Priorizar os requisitos uma vez escolhida a tcnica de negociao,
a mesma deve ser utilizada no apenas para resolver conitos, mas
tambm para priorizar os requisitos. Na denio de prioridades para os
requisitos, importante que os riscos e a complexidade dos requisitos
sejam observados de forma a minimizar possveis atrasos nos milesto-
nes a estabelecidos. Milestones correspondem aos pontos de controle
em um cronograma os quais representam a concluso de um conjunto
de tarefas ou fase, passiva de aprovao e de formalizao por parte do
cliente. Os requisitos podem ter trs nveis de prioridade: alta, mdia e
baixa.
- Alta: requisitos obrigatrios, ou seja, requisitos que deixam o de-
senvolvedor sob fora de contrato perante o cliente ou entidades
externas equipe de desenvolvimento.
- Mdia: requisitos que possuem importncia signicativa para o
cliente, mas que podem ser negociados com a gerncia para serem
retirados do escopo, caso no seja vivel sua implementao.
- Baixa: requisitos de menor importncia para a realizao dos ob-
jetivos do software.
Denir os milestones e os pontos de reviso de acordo com a prio-
rizao, os requisitos so agrupados para estabelecer linhas de base de
implementao, facilitando a denio dos milestones e de pontos de
reviso.
Atualizar o Documento de Requisitos de Software o resultado
obtido a partir da tcnica de priorizao deve ser incorporado ao Docu-
mento de Requisitos de Software (DRS), enriquecendo a documentao
sobre os atributos dos requisitos.
Incio
Priorizar os Requisitos
Atualizar o DRS
Fim
Defnir os milestones e os
pontos de reviso
Escolher a Tcnica de
Negociao
Figura 4 Processos de negociao e priorizao de requisitos
22A
2.1 - Solicitaes x necessidades
O grupo de pessoas ou representantes de uma organizao que tem
interesse ou inuncia no projeto so chamados de interessados (na
literatura em ingls, utilizado o termo stakeholder). O interessado
mais bvio o usurio nal, mas devem ser levados em considerao
outros interessados importantes: um comprador, um contratante, um
desenvolvedor, um gerente de projeto ou qualquer outro que se preo-
cupe bastante ou que apresente necessidades que devem ser satisfeitas
pelo projeto.
importante que sejam agrupadas todos os tipos de solicitaes de
interessados ao longo do ciclo de vida do desenvolvimento. As solicita-
es correspondem aos dados de entrada brutos usados para levantar as
necessidades. No incio do projeto, so usadas tcnicas de entrevistas,
questionrios e seminrios. Em um estgio mais adiantado do desen-
volvimento, so feitas a coleta das solicitaes de mudanas, relatrios
de defeito e solicitaes de melhoria. comum que as solicitaes
sejam vagas e ambguas, declaradas at mesmo como necessidades.
As solicitaes dos interessados estabelecem um contexto importante
para entender as reais necessidades dos interessados e fornecem con-
tribuio crtica s exigncias dos produtos. Essa contribuio fornece
respostas cruciais que permitem determinar os porqus e os qus
do comportamento de sistema.
A partir das solicitaes, so realizadas algumas vericaes referentes
aos requisitos levantados (Figura 5):
Vericao da necessidade a necessidade dos requisitos analisada.
Em alguns casos, alguns requisitos propostos podem no ser relevantes,
pois no contribuem para os objetivos de negcio da organizao ou
para o problema especco tratado pelo sistema.
Vericao de consistncia e completude os requisitos so veri-
cados entre si para determinar consistncia e completude. Consistncia
signica que nenhum requisito deve ser contraditrio e completude
signica que nenhum servio (ou limitao) necessrio seja esquecido.
Vericao de viabilidade Os requisitos so vericados para garan-
tir que so viveis dentro do oramento e do prazo estabelecido para o
desenvolvimento do sistema.
Anlise de Requisies
Negociao de Requisio
Verifcao da
Necessidade
Requisies
Desnecessrias
Discusso sobre
as Requisies
Priorizao
das Requisies
Acordo sobre as
Requisies
Requisies
Inviveis
Requisies
Imcompletas
e confitantes
Verifcao
de viabilidade
Verifcao
de consistncia
e completude
Figura 5 Processo de vericao de requisitos
Sendo assim, ca explcito o fato de que imprescindvel que a equipe de desenvolvimento conhea as necessidades
especcas dos interessados fundamentais do sistema. Mas a questo como identicar essas necessidades?
23A
M
D
U
L
O

A
2.2 - Encontros de negociao
Problemas nos requisitos so inevitveis quando um sistema possui
muitos stakeholders. Os conitos no so necessariamente falhas, mas
reetem necessidades e prioridades diferentes entre as partes interessa-
das. A negociao de requisitos o processo de discusso dos conitos
de requisitos e a busca de um compromisso no qual, por meio de um
consenso, todas as partes interessadas concordem com as solues su-
geridas. Sendo assim, no planejamento do processo de engenharia de
requisitos, desejvel deixar um tempo considervel reservado para a
negociao. Alcanar o consenso aceitvel por todas as partes pode
tomar um tempo considervel.
Os encontros de negociao correspondem ao estgio de informao
no qual a natureza dos problemas associados com os requisitos ex-
plicada. A partir da, as partes interessadas discutem como o problema
poder ser resolvido.
Todas as partes interessadas no requisito devem ter a oportunidade de
participar com comentrios e opinies, devendo ser atribudas priori-
dades aos requisitos.
Como resultado deste processo, solues para os problemas dos requi-
sitos so identicadas e um conjunto de requisitos acordado. Ge-
ralmente, isso envolve mudanas, eliminao ou elicitao para obter
mais informaes sobre alguns dos requisitos.
3 - Especicao de Requisitos
Os requisitos podem ser classicados como:
Requisitos funcionais;
Requisitos no-funcionais.
Requisitos
Funcionais
Requisitos
No Funcionais
Descrevem as operaes
providas pelo sistema
Defnem a qualidade e
as restries do sistema
Figura 6 Tipos de requisitos
A diferena entre requisitos funcionais e no-funcionais est no fato de
os primeiros descreverem o qu o sistema deve fazer, enquanto que
os outros xam restries sobre como os requisitos funcionais devem
ser implementados.
Os requisitos funcionais tm efeito localizado, isto , afetam apenas
a parte do sistema onde as funcionalidades foram implementadas. Os
requisitos no-funcionais tm efeito global, pois satisfao afeta vrios
componentes do sistema.
3.1 - Atividades da elicitao de requisitos
Requisitos funcionais expressam o comportamento de um sistema es-
pecicando a contribuio e as condies esperadas de sada, ou seja,
correspondem descrio das diversas operaes que clientes e usurios
24A
solicitam para que possam ser implementadas e oferecidas pelo siste-
ma.
3.2 - Requisitos no-funcionais
Requisitos no-funcionais (Figura 7) correspondem aos atributos que
no so especicamente descritos pelos requisitos funcionais do sis-
tema, mas so imprescindveis para atingir a qualidade necessria do
software.
Requisitos no-funcionais so difceis de descrever, porm, trat-los
durante o processo de desenvolvimento pode ser vital para o sucesso de
sistemas. As principais caractersticas desses requisitos so:
Subjetivos - so interpretados e avaliados por diferentes pessoas
que tm diferentes perspectivas e necessidades, podendo ter diferentes
signicados para cada pessoa. Exemplo: a interpretao de Usabilidade
diferente para cada usurio, variando conforme sua percepo visual,
seu conhecimento tecnolgico, seu nvel cultural, sua idade etc.;
Relativos - sua interpretao e importncia dependem diretamente
de cada sistema e sua realizao relativa. Exemplo: usabilidade mais
importante para sistemas on-line, alto desempenho mais importante
para sistemas real-time;
Interativos - interagem entre si. Assim, a realizao de um requisi-
to no-funcional pode interferir positivamente ou negativamente nos
outros requisitos no-funcionais. Exemplo: Maior grau de segurana
implica em menor desempenho.
Alm disso, os requisitos no-funcionais so crticos para o sucesso de
sistemas de software e esto diretamente relacionados com a satisfao
dos usurios. Devido a essa importncia, alguns requisitos funcionais
podem ser sacricados para atender s restries impostas pelos requi-
sitos no-funcionais.
Necessidade do Cliente Preocupao do Cliente Requisitos No Funcionais
Funo
Facilidade de uso Usabilidade
Controle de acesso Segurana
Recuperao de falhas Conabilidade
Desempenho
Otimizao de Recursos Ecincia
Desempenho de vericao Vericabilidade
Facilidade de comunicao Interoperabilidade
Alterao
Facilidade de reparar Manutenibilidade
Facilidade de alterar Flexibilidade
Facilidade de transportar Portabilidade
Facilidade de expandir Expansibilidade
A lista seguinte resume as consideraes para denir a qualidade de
requisitos no-funcionais de um sistema.
Utilidade requisitos que endeream fatores humanos (esttica, fa-
cilidade de aprendizado e facilidade de uso) e consistncia na interface
do usurio, documentao de usurio e materiais de treinamento.
Conana requisitos que lidam com a freqncia e a severidade de
fracasso, recuperao, previsibilidade e preciso.
Desempenho requisitos que impem condies em requisitos fun-
cionais, por exemplo, um requisito que especica a taxa de transao,
velocidade, disponibilidade, preciso, tempo de resposta, tempo de re-
cuperao ou uso de memria com que uma determinada ao deve ser
executada.
25A
M
D
U
L
O

A
Suporte requisitos que focalizam a preservao, a capacidade de
testes e as outras qualidades exigidas para manter o sistema em dia
depois de seu lanamento.
Requisitos
no-funcionais
Requisitos
de produto
Requisitos
no-funcionais
Requsitos
externos
Requisitos
de efcincia
Requisitos de
facilidade de uso
Requisitos
de confabilidade
Requisitos
de portabilidade
Requisitos de
interoperabilidade
Requisitos
ticos
Requisitos
de desempenho
Requisitos
de espao
Requisitos de
implementao
Requisitos
de entrega
Requisitos
de padres
Requisitos
legais
Requisitos
de privacidade
Requisitos
de segurana
Figura 7 Requisitos no-funcionais
3.3 - Classicao de Requisitos no-funcionais no Banco do Brasil
Segundo a Norma ISO/IEC 9126, cada tipo de software tem seus pr-
prios fatores de qualidade. A importncia dos fatores de qualidade varia
dependendo da classe de software (Figura 8).
Classe Caracterstica
Sistema de misso crtica Conabilidade
Software de Sistema Tempo Real Ecincia
Software Interativo em Relao ao Usurio Final Usabilidade
Figura 8 Exemplo da relevncia de caractersticas
de acordo com o tipo de software
Fonte: Banco do Brasil, 2007, p. 8
Os requisitos no-funcionais utilizados no BB podem ser vistos como
categorias genricas que fazem o papel de fatores de qualidade a serem
atendidos no desenvolvimento dos produtos de software. Estas catego-
rias so:
Desempenho: requisitos de desempenho so aqueles que se referem
ecincia do sistema em explorar seus recursos. Os atributos de de-
sempenho devem ser denidos em faixa de valores. Podem ser de dois
tipos:
- Estticos: quando se referem capacidade em termos de: quanti-
dade de terminais na rede, nmero de acessos simultneos, volumes
de transaes e volume de dados (arquivos e tabelas);
- Dinmicos: quando se referem velocidade em termos de: tran-
saes por segundo, tempo de resposta em condies normais e de
pico e Intervalo de tempo limite para processamento. Ecincia pode
26A
ser descrita nas fases de especicao e de projeto, entretanto, s
pode ser medida na fase de implementao.
Conabilidade: os requisitos de conabilidade relacionam-se s fa-
lhas no sistema. Os atributos so: cpia de segurana (incluindo todos
os dados/informaes que devem ser copiados) e periodicidade (para
garantir a integridade do sistema e planos de contingncia);
Disponibilidade: dene o perodo em que o sistema deve estar ativo
em cada modalidade (on-line e batch);
Segurana: requisitos de segurana referem-se s necessidades de
proteo do sistema e aos dados que ele gerencia. Enquadram-se aqui
requisitos relativos violao de processos e informaes. So requi-
sitos de segurana: o controle de acesso a dados e transaes (classe
de usurios e tipos de controle de acesso), o sigilo e a integridade das
informaes, a identicao e autenticao dos usurios e as trilhas de
auditoria (movimento/transao e periodicidade que devem ser regis-
trados);
Outros atributos de qualidade necessrios ao sistema em desenvolvi-
mento e que no foram denidos nos itens acima, tais como:
Portabilidade: refere-se habilidade do sistema ser movido entre
ambientes (hardware ou software). Tem atributos dependentes da ha-
bilidade de adaptao, instalao, conformidade e substituio;
Facilidade de Manuteno (ou Manutenibilidade): refere-se ha-
bilidade de o sistema reagir execuo de alteraes para adaptao
do software ao ambiente ou modicao nos requisitos. Os atributos
desta categoria so: simplicidade de anlise, conciso, estabilidade e
modularizao;
Expansibilidade: a habilidade de o sistema reagir incluso de
novos componentes, causado pela requisio de novas funcionalidades
que o sistema deve possuir. Expansibilidade e manutenibilidade so
fatores de qualidade que so fortemente dependentes da arquitetura. E
ao mesmo tempo, so os objetivos da especicao arquitetural;
Facilidade de Uso (ou Usabilidade): refere-se capacidade de um
software ser compreendido, aprendido, utilizado e ser atrativo para o
usurio, em condies especcas de utilizao.
Requisitos operacionais: chamados requisitos de restrio do ambiente
ou da arquitetura. Estes requisitos so determinados pelas restries
e necessidades de hardware ou software. Por exemplo, um sistema de
tempo real a ser implementado sob um hardware preexistente. Enquan-
to os requisitos de qualidade determinam quo desejvel (ou quanto
de bom) ser uma determinada implementao, os requisitos de res-
trio determinam se a implementao aceitvel como um todo. Os
requisitos operacionais podem ser de quatro tipos:
- Requisitos de software - que descrevem o contexto e as restries de
software para o desenvolvimento, plataforma de execuo do sistema
(banco de dados: freqncia de uso, volume de dados armazenados,
restries de integridade, persistncia, etc), sistema operacional, e ou-
tros sistemas aplicativos;
- Requisitos de hardware - que descrevem a plataforma e as restries
de hardware para o desenvolvimento e plataforma de execuo do sis-
tema (dispositivos suportados, famlia de processador, etc.);
27A
M
D
U
L
O

A
- Requisitos de comunicao - que descrevem os APIs (Application
Programming Interface - bibliotecas de cdigo que podem ser incorpo-
rados a fontes de programas), protocolos de rede, software de suporte
distribuio, por exemplo, Corba;
- Requisitos externos - que descrevem pontos que no podem ser
modicados devido a padres, regras, normas, leis.
4 - Modelagem do Sistema
A Anlise de Requisitos leva geralmente a trs tipos de modelos: Mode-
lo de Caso de Uso, Modelo de Projeto e Modelo de Teste (Figura 9).
Inicialmente, a coleta de solicitaes dos interessados realizada abran-
gendo todas as solicitaes e listas desejadas obtidas dos usurios -
nais, dos clientes, do comrcio e de outros interessados do projeto.
Esse conjunto de solicitaes de interessados utilizado para desen-
volver um documento de viso que contm o conjunto fundamental
de necessidades dos interessados e dos usurios e as caractersticas
de alto-nvel do sistema. Essas caractersticas de sistema expressam o
comportamento do sistema implementado deve ter para que este aten-
da as necessidades do interessado. A relao entre os requisitos e os
componentes necessrios esta implementao conhecida como ras-
treamento de requisitos.
As caractersticas includas no documento de viso so baseadas na
anlise do custo de implementao de uma caracterstica desejada e na
determinao do retorno daquele investimento. Essa anlise encon-
trada no caso de negcio para o projeto.
Antes do incio da codicao, tais caractersticas devem ser traduzidas
em requisitos detalhados de software, em um nvel de detalhamento
que permita projetar e construir um sistema real, e que se possa iden-
ticar casos de teste para testar o comportamento do sistema. Esses
requisitos detalhados so captados no modelo de caso de uso e em
outras especicaes adicionais que captam os requisitos que no se
ajustam bem aos casos de uso.
Artefatos
Viso
SRS
Solicitaes do
interessado
Modelo de Projeto Modelo de Teste
Materiais de
documentao do
usurio fnal e materiais
de treinamento
Modelo de Caso
de Uso
Especifcao
suplementar
x
ok
x
ok
x
ok
x
ok
x
ok
Tipos de requisito
Necessidades do
interessado/usurio
Requisitos de
Software
Requisitos de Projeto/Teste
Documento
Figura 9 Modelos utilizados na Anlise de Requisitos
Fonte: KRUCHTEN, 2004, p.136
Os requisitos detalhados so sintetizados em um Modelo de Projeto e
na documentao de usurio nal. Eles podem ser vericados atravs
de um Modelo de Teste.
28A
5 - Validao de Requisitos
Aps a fase de anlise dos requisitos, necessrio que eles sejam cui-
dadosamente validados, principalmente no que se refere consistncia
e completude. A atividade de Validao tem por objetivo identicar
problemas nos requisitos, antes do incio da construo do sistema. A
importncia dessa atividade caracterizada pelo fato de que a corre-
o de um erro nesta fase acarretar um custo muito inferior do que
a correo nas fases mais adiantadas do processo de desenvolvimento,
minimizando este custo em at 200 vezes.
Para o gerente do projeto, indivduo responsvel por atender s ex-
pectativas dos diferentes interessados no sistema, recomenda-se, como
boas prticas, a seleo de um modelo de ciclo de vida apropriado, a
elaborao do plano do projeto com base nos requisitos do sistema, a
renegociao dos compromissos, assim que se perceba que no podem
ser cumpridos, o gerenciamento dos riscos associados a requisitos e a
criao de condies para que os requisitos possam ser rastreados ao
longo do projeto.
Conforme pode ser observado na Figura 10, durante um processo de
Validao, as seguintes atividades so executadas:
Usar Checklist de validao checklists estruturam o processo de va-
lidao de forma que aspectos importantes no sejam deixados de lado.
Embora sejam semelhantes aos checklists de anlise, os de validao de-
vem focalizar aspectos de qualidade do documento de requisito como
um todo, bem como os relacionamentos entre os requisitos. Algumas
questes podem ser relacionadas para vericar se a lista de requisitos
est completa, se os requisitos esto consistentes e no contraditrios,
se o documento est estruturado de forma a facilitar o entendimento,
se foi feito o rastreamento dos requisitos ou se o documento est de
acordo com os padres.
Incio
Usar os checklist
de validao
Executar a Inspeo Formal
para validao
Notifcar Gerente de
Projeto e envolvidos
Notifcar Gerente
Snior
Desvios resolvveis
internamente
Desvios no resolvveis
internamente
Defnir os casos de
teste dos requisitos
Final
C1
C2
D1
Figura 10 Processo de Validao de Requisitos
Denir os casos de teste dos requisitos denir um ou mais casos
de testes que posteriormente permitam vericar se o sistema satisfaz o
requisito de forma plena, alm de uma maneira de validar os requisitos,
pode servir como base para os testes nais do sistema. Ao escrever o
caso de teste, o requisito ser escrito por meio de uma viso diferente.
Cada caso de teste deve possuir, no mnimo, um identicador, os re-
quisitos a ele relacionados e a descrio do teste. Se utilizados em uma
ferramenta, os casos de testes podem estar diretamente associados aos
requisitos, alm de permitir que os testes sejam feitos automaticamente.
Executar as Inspees formais nas inspees formais, um grupo
deve validar os requisitos de forma sistemtica, descobrir os problemas
29A
M
D
U
L
O

A
relacionados a eles e entrar em um acordo a respeito de como solucio-
n-los.
6 - Fluxo de Requisitos no RUP
De acordo com a tecnologia desenvolvida no RUP (Rational Unied
Process), possvel observar o Fluxo de requisitos na Figura 11.
As atividades representadas no Fluxo de requisitos segundo o RUP so:
Analisar o problema abrange a identicao dos interessados e dos
limites e das restries do sistema.
Entender as necessidades do interessado por meio do uso das
tcnicas de extrao de informaes, as solicitaes do interessado so
reunidas e, a partir da, estabelecida uma compreenso clara das reais
necessidades dos usurios e dos outros interessados do sistema.
Denir o Sistema a partir da contribuio dos interessados, so es-
tabelecidos: o conjunto de caractersticas de sistema a ser considerado
para entrega, os critrios que sero usados para priorizao dos requi-
sitos, as expectativas sobre como as caractersticas sero entregues e os
atores e casos de uso necessrios para cada caracterstica fundamental
a serem identicados.
Administrar a extenso do sistema so coletadas informaes
relevantes de interessados no projeto e mantidas, junto aos requisitos,
como atributos de requisitos, para serem usadas na priorizao e alcan-
ce do conjunto estabelecido no acordo de requisitos. Dessa forma, o
sistema pode ser entregue a tempo e com um oramento que satisfaa
as expectativas dos clientes.
Renar a denio do sistema por meio de um modelo de caso de
uso, os requisitos de software do sistema so detalhados para obter um
acordo com o cliente sobre a funcionalidade do sistema e captao de
outros requisitos importantes, como requisitos no-funcionais, restri-
es de projeto, dentre outros.
Administrar mudana de requisitos uso dos atributos de requi-
sito e de rastreamento para avaliao do impacto das mudanas.
recomendvel o uso de uma autoridade de controle central, como um
Comit de Controle de Mudana ou Grupo de Controle de Mudana
(do ingls Change Control Board - CCB), para controlar mudanas nos
requisitos.
7 - Gesto de Requisitos
7.1 - Introduo
A Gesto de requisitos uma disciplina da engenharia de software que
procura manter sob controle o conjunto dos requisitos de um produto,
mesmo diante de alteraes inevitveis (requisitos normativos). Faz par-
te da Gesto de Requisitos lidar com as modicaes e instabilidades
dos requisitos.
Com relao ao desenvolvimento de software, uma maneira de reali-
zar um choque de gesto tratarmos as necessidades e os anseios do
cliente com a mxima ateno e controle possveis. Para sustentar isso,
possvel observar a seguir algumas estatsticas importantes sobre pro-
jetos de software mostradas no Quadro 1.
30A
Quadro 1 - Estatsticas importantes sobre projetos de software
Descrio Percentual
30%
54%
66%
90%
so cancelados
ultrapassam os oramentos estabelecidos
so considerados como insucesso
no cumprem os prazos de entrega
Fonte: Standish Group, 2004
(Sistema novo)
Analisar o
problema
(Problema
incorreto)
Defnir o
sistema
(Mais
iteraes)
Refnar a
defnio do
sistema
Administrar o
alcance do
sistema
(Enderear
Problema
correto)
(No pode fazer
todo o trabalho)
Trabalhar no
alcance
Administrar
mudana
de requisitos
(Nova
contribuio)
(Defnio de
requisitos
completa)
Entender necessidades
do interessado
(Sistema exixtente)
Figura 11 Fluxo de Requisitos
Fonte: KRUCHTEN, 2004, p.136
Alm disso, comprovado que a principal fonte de problemas e custos
adicionais est nos chamados requisitos conforme as estatsticas:
56% dos defeitos dos softwares tm origem nos requisitos (James
Martin).
82% do esforo de correo de defeitos esto relacionados com os
requisitos (Dean Lefngwell).
Existem muitas equipes que tratam as necessidades de maneira infor-
mal, em que o controle das informaes depende nica e exclusivamen-
te da experincia das pessoas envolvidas. O que na verdade no garante
a qualidade do software ao nal do projeto.
Dessa forma, padronizar processos e automatizar a denio e gesto
de requisitos algo extremamente fundamental para que tais estatsti-
cas possam ser revertidas, pois estabelecer o controle de cada necessi-
dade desde a sua descoberta, detalhamento, validao e, com certeza,
tambm em suas provveis mudanas.
O RUP um processo de engenharia de software desenvolvido e comer-
cializado pela Rational Software, bastante utilizado atualmente no de-
senvolvimento de software de alta qualidade e corresponde a um modo
disciplinado de ordenar e gerenciar tarefas e responsabilidades em uma
empresa de desenvolvimento. O objetivo desse processo produzir,
dentro de prazo e oramento previstos, software de alta qualidade que
satisfaa s necessidades de seus usurios nais.
31A
M
D
U
L
O

A
7.2 - Informaes utilizadas (Entradas) e produzidas (Sadas)
A seguir, esto descritos as principais fontes de informaes relacionadas Gesto de Requisitos.
Quadro 2 - Fontes de informaes relacionadas Gesto de Requisitos
Solicitao de servio Entrada
Entrada
Entrada e
sada
Refere-se ao documento formal por meio do qual o sistema solicitado pelo cliente.
SAR (Solicitao de
Alterao de Requisitos)
Documento que deve ser preenchido quando h necessidade de alterao ou incluso de requisitos. Especifca e documenta a alterao de requisitos solicitada pelo
stakeholder, estabelecendo as bases para sua execuo e condies de execuo (prioridades, recursos envolvidos, recursos afetados etc.).
Referem-se a informaes gerais sobre o sistema. Documento onde fornecido o objetivo do sistema a ser desenvolvido, as caractersticas principais, funcionalidades e
requisitos no-funcionais, a identifcao dos stakeholders. Fornece uma viso inicial do sistema, apresentando-o em linhas gerais. Documenta o ambiente geral de proces-
sos a ser desenvolvido, fornecendo a todos os envolvidos uma descrio compreensvel do sistema e suas funcionalidades abordadas em uma macro-viso. O objetivo do
documento Viso defnir as necessidades de alto nvel e caractersticas do sistema, focando nas potencialidades requeridas pelos stakeholders e como estes requisitos sero
abordados no sistema.
Sada
Sada
Sada
Viso
Glossrio
Rastreabilidade
O objetivo do glossrio fornecer uma terminologia comum sobre o projeto a todos os envolvidos. Este conjunto de termos e conceitos originais usado para defnir um
mapeamento especfco sobre o domnio do problema, explicando os itens mais importantes e as descries de outros componentes do projeto.
Alm de facilitar o entendimento da aplicao, o Glossrio evita ambigidades no entendimento das informaes, ao longo do processo.
Neste contexto, as Matrizes de Rastreabilidade mostram os relacionamentos entre os requisitos elicitados.
Entrada e
sada
Documento de Requisitos
de Software (DRS)
composto pelo detalhamento dos requisitos. A DRS guarda a especifcao dos requisitos de software, descritos em nvel de detalhe que possibilite o entendimento de
todos os envolvidos. Tambm serve como base de comunicao entre os stakeholders e ajuda a manter um foco integrado no desenvolvimento.
Requisitos impactados Referem-se aos requisitos que sero alterados em decorrncia da incluso ou alterao de requisitos.
Sada Baseline Baseline ou confgurao base um conjunto de requisitos aprovados e revisados que representa o embasamento de um acordo de evoluo e desenvolvimento.
atualizada por meio da incluso ou Alterao de requisitos.
Sada Notifcao das reas
envolvidas
Refere-se comunicao de todos os que sero impactados pela incluso ou alterao de requisitos.
Sada Mtricas Informaes coletadas ao longo do gerenciamento de requisitos.
Sada Casos de testes Devem estar includos no DRS (Documento de Requisitos de Software).
Sada Atas de verifcao Ser utilizada a Ata de Reunio para registrar as no-conformidades.
Sada Plano de reviso Ser utilizada a Ata de Reunio para registrar os compromissos de reviso.
Sada DRS atualizado Corresponde ao Documento de Requisitos de Software alterado em funo da incluso ou alterao de requisitos.
Descrio Tipo Entrada ou Sada
32A
TEMA II - TPICOS EM ENGENHARIA DE SOFTWARE REFERNCIAS BIBLIOGRFICAS
BANCO DO BRASIL Disciplina de Requisitos de Software: Processo de Desenvolvimento de Aplicativos do Banco do Brasil PDABB. Braslia:
Banco do Brasil, 2007.
KRUCHTEN, P. Introduo ao RUP: Rational Unied Process. Rio de Janeiro: Cincia Moderna, 2004.
LEFFINGWELL, D. Calculating the return on investment from more effective requirements management. EUA: American Programmer, 1997.
SOFTWARE Engineering Body of Knowledge. EUA: IEEE Computer Society, 2004. Disponvel em: <http://www.swebok.org>. Acesso em: 20 jan.
de 2008.
SOMERVILLE, I. Engenharia de Software. 8. ed. So Paulo: Pearson Addison-Wesley, 2007.
WEBER, K. Projeto melhoria de processo de software brasileiro. In: SIMPSIO BRASILEIRO DE QUALIDADE DE SOFTWARE (SBQS), 3., 2004,
Braslia. Anais... Braslia: SBQS, 2004.
WIEGERS, K. The seven deadly sins of software reviews: software development. EUA: Process impact, 1998. p.44-47. Disponvel em: <http://
www.processimpact.com/pr_goodies.shtml>. Acesso em: 25 jan. de 2008.

Engenharia Requisitos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

:

Você também pode gostar