-
UNIVERSIDADE DO VALE DO ITAJA PR-REITORIA DE PS-GRADUAO,
PESQUISA, EXTENSO E CULTURA
PROGRAMA DE MESTRADO ACADMICO EM COMPUTAO APLICADA
INTRODUO ENGENHARIA DE REQUISITOS
Relatrio Tcnico RT-ES-0001/11
por
Rodrigo Cezario da Silva [email protected]
Fabiane Barreto Vavassori Benitti, Dra.
[email protected]
So Jos (SC), agosto de 2011
-
ii
SUMRIO
RESUMO
.................................................................................................
iii ABSTRACT
.............................................................................................
iv 1 INTRODUO
................................................................................................
5 2 ENGENHARIA DE REQUISITOS
................................................................. 5
3 PROCESSO DE ENGENHARIA DE REQUISITOS
..................................... 8 3.1 ELICITAO DE REQUISITOS
.................................................................
12 4 RASTREABILIDADE DE REQUISITOS
.................................................... 20 5 DOCUMENTO
DE ESPECIFICAO DE REQUISITOS ........................ 24 6 CONCLUSO
................................................................................................
30 REFERNCIAS BIBLIOGRFICAS
.................................................. 31
-
iii
RESUMO
SILVA, Rodrigo Cezario. Introduo Engenharia de Software. So Jos,
2011. 43 f. Relatrio de Tcnico (Mestrado em Computao
Aplicada)Programa de Mestrado Acadmico em Computao Aplicada,
Universidade do Vale do Itaja, So Jos, 2011. A Engenharia de
Requisitos, uma subrea da Engenharia de Software, a etapa onde so
criados e refinados os requisitos de software. Atravs da aplicao de
tcnicas e abordagens de elicitao de requisitos, os requisitos so
capturados, analisados e validados com seus interessados. Por sua
vez, a definio correta dos requisitos um fator crucial para reduzir
custos e riscos no projeto de software. No entanto, entende-se que
a falta de um bom trabalho nesta etapa pode levar ao insucesso ou
abandono do projeto. Neste sentido, este relatrio tcnico tem o
papel de apresentar os conceitos bsicos, o processo e atividades
envolvidas na Engenharia de Requisitos. Palavras-chave: Engenharia
de Requisitos. Elicitao de requisitos. Tcnicas de elicitao.
-
iv
ABSTRACT
The Requirements engineering, a sub-area of Software
Engineering, is the stage where they are created and refined the
software requirements. Through the application of techniques and
approaches to requirements elicitation, requirements are captured,
analyzed and validated with its stakeholders. In turn, the correct
definition of the requirements is a crucial factor in reducing
costs and risks in software design. However, it is understood that
the lack of a good job at this stage can lead to failure or
abandonment of the project. Thus, this technical report is the role
of presenting the basic concepts, process and activities involved
in requirements engineering. Keywords: Requirements Engineering.
Requirements elicitation. Requirements elicitation techniques.
-
1 INTRODUO
Nos ltimos anos, as organizaes voltadas ao desenvolvimento de
software tm procurado por
melhores prticas em engenharia de requisitos (YOUNG, 2004;
WIEGERS, 2006; ROBERTSON;
ROBERTSON, 2006; DAVEY; COPE, 2008; TAMAI; KAMATA, 2009; LIU et
al., 2010). Essa
busca por novas prticas ocorreram porque as organizaes
perceberam que o xito no projeto est
cada vez mais relacionado a um melhor entendimento dos
requisitos (WIEGERS, 2006;
ROBERTSON; ROBERTSON, 2006).
Neste sentido, a definio correta dos requisitos um fator crucial
para reduzir custos e riscos
no projeto de software (GOTTESDIENER, 2008), pois a falta de um
bom trabalho na atividade de
elicitao de requisitos leva ao insucesso ou abandono de projetos
(DAVEY; COPE, 2008).
Problemas na elicitao de requisitos esto relacionados a escopo,
compreenso e volatilidade
(CHISTEL; KANG, 1992), esses problemas so decorrentes da
dificuldade em se extrair ou
identificar as necessidades de seus usurios (HOOD et al.,
2008).
O objetivo principal deste estudo definir uma introduo bsica de
Engenharia de Requisitos
oferecendo as competncias bsicas necessrias para o entendimento
de suas etapas e de suas
atividades.
2 ENGENHARIA DE REQUISITOS
Devido necessidade de qualidade na produo de um produto de
software, o processo de
desenvolvimento de software vem sendo aperfeioado ao longo dos
anos (GENVIGIR, 2009). Essa
busca por aperfeioamento est ocorrendo porque organizaes
perceberam que o xito na execuo
dos projetos est cada vez mais relacionado a um melhor
entendimento dos requisitos (WIEGERS,
2006; ROBERTSON; ROBERTSON, 2006).
Diversos autores destacam a importncia da engenharia de
requisitos e seus impactos,
principalmente em relao aos custos do projeto e qualidade,
ressaltando que os defeitos de
software na fase de projetos so muito mais caros e difceis de
serem resolvidos do que na fase de
definio de requisitos (PRESSMAN, 2002; BOEHM e BASILI, 2001;
ROBERTSON;
ROBERTSON, 2006; YOUNG, 2004). Segundo Wiegers (2006), a
engenharia de requisitos trata os
aspectos mais desafiadores no desenvolvimento de software, pois
esta estabelece as bases para todo
o projeto posterior. Conforme Kotonya e Sommerville (1998), os
problemas de escrever requisitos
-
6
so universais e nunca haver uma soluo completa para resolver
estes problemas. Porm, o
resultado do impacto no sistema desses problemas pode ser
reduzido utilizando-se de boas
prticas de engenharia de requisitos.
Neste sentido, a engenharia de requisitos trabalha de forma a
sistematizar o tratamento dos
requisitos (SWEBOK, 2004). Uma definio para engenharia de
requisitos feita por Cheng e Atlee
(2007), como um processo pelo qual requisitos so determinados. o
processo pelo qual se
descobre os propsitos do sistema, faz-se a identificao dos
stakeholders e de suas necessidades,
documenta-se essas necessidades de forma que seja passvel de
anlise, comunicao e que,
posteriormente, possa-se implement-las (NUSEIBEH; EASTERBROOK,
2000).
No entanto, antes de aprofundar no processo de engenharia de
requisitos, faz-se importante
compreender o que so requisitos. Requisito, por sua vez, tem o
papel de descrever como o sistema
dever se comportar, alm de prestar informao sobre o domnio da
aplicao ou restries na
operao do sistema (KOTONYA; SOMMERVILLE, 1998), a fim de
resolver um problema no
mundo real (SWEBOK, 2004). Os requisitos servem de base para
elaborao de cada projeto
(HULL et al., 2005; YOUNG; 2004, p.2) e o sucesso do projeto
depende do entendimento desses
requisitos (CHENG; ATLEE, 2007). Uma separao por tipos de
requisitos pode ser feita de modo
a evitar problemas no processo de engenharia de requisitos
(KOTONYA; SOMMERVILLE, 1998).
Os requisitos podem ser divididos em trs tipos: requisitos de
negcio, que dirigido por metas ou
objetivos e tambm descrevem vises estratgicas de negcio,
requisitos do usurio, que descrevem
o que o usurio espera do sistema, e requisitos do sistema, que
descrevem o que o sistema deve
fazer (GOTTESDIENER, 2008). Essa separao entre diferentes nveis
de descrio deve ser feita
para facilitar a comunicao entre os diferentes tipos de leitores
(KOTONYA; SOMMERVILLE,
1998).
Os requisitos de sistema so classificados frequentemente em trs
tipos: requisitos
funcionais, requisitos no funcionais e requisitos de domnio
(KOTONYA; SOMMERVILLE,
1998), definidos da seguinte forma:
Requisitos funcionais: so descries de funes que o sistema ir
fazer; deve ser til
ao usurio para ajudar na execuo de seu trabalho. Qualquer ao ou
verbo ativo
so considerados requisitos funcionais, como por exemplo,
calcular, inspecionar,
publicar, processar, imprimir, listar e etc. (ROBERTSON;
ROBERTSON, 2006)
-
7
Requisitos no funcionais: expressam condies de comportamento
e/ou restries
que o software deve satisfazer (CYSNEIROS; LEITE, 1998), ou
seja, so descries
ou atribuies de qualidade que o sistema deve possuir
(ROBERTSON;
ROBERTSON, 2006). So exemplos requisitos ligados segurana,
desempenho,
usabilidade, acurcia, portabilidade e etc.
Requisitos do domnio: derivam do domnio da aplicao e refletem
caractersticas
desse domnio. Podem ser enquadrados como requisitos funcionais
ou como
requisitos no funcionais (SOMMERVILLE, 2007). A diferena entre
esse tipo de
requisito e os requisitos funcionais e os no funcionais, que
requisitos de domnio
normalmente tm uma existncia fora dos limites de qualquer
sistema de software
(WIEGERS, 2006). Isso quer dizer que, uma regra de negcio no
propriamente
um requisito de domnio, ela existe independentemente de um
sistema
computacional, e muitas vezes ela ser aplicada para garantir que
o sistema imponha
esta regra. Cabe ressaltar aqui que nem todos os autores citam
este tipo de requisito.
Outra distino referente a requisitos sugerida por Leffingwell e
Widrig (2003), propondo
a classificao dos requisitos em nveis que podem ser observados
sob o ngulo de uma pirmide
conforme ilustrada na Figura 1. No topo da pirmide, localizam-se
as necessidades (needs) dos
stakeholders, ao centro esto s caractersticas (features) e na
base os requisitos de sistema. Para
Leffingwell e Widrig (2003), as necessidades (needs) e
caractersticas (features) esto intimamente
relacionadas e devem estar bem definidos para que ambos no
entrem em conflito. Esse conflito
ocorre porque os stakeholders normalmente especificam uma
caracterstica do sistema e no uma
necessidade ou requisitos de sistema. Cabe ento ao analista
fazer essa identificao, para obter a
real necessidade dos stakeholders.
-
8
Figura 1 - Viso de requisitos em nveis. Fonte: adaptado de
Leffingwell e Widrig (2003).
3 PROCESSO DE ENGENHARIA DE REQUISITOS
Conforme Nuseibeh e Easterbrook (2000), o sucesso de um sistema
de software decorrente
do cumprimento das finalidades para o qual o sistema foi
desenvolvido. De um modo amplo, pode-
se dizer que o processo de engenharia de requisitos objetiva a
criao e manuteno do documento
de especificao de requisitos (SOMMERVILLE, 2007, p.143). Esse
processo ou domnio da
engenharia de requisitos pode ser divido em desenvolvimento de
requisitos, que centra as atividades
de identificar e acordar um conjunto de requisitos; e
gerenciamento de requisitos, parte responsvel
por gerir as alteraes do conjunto de requisitos gerado pelas
atividades de desenvolvimento de
requisitos (WIEGERS, 2006). Segundo Sommerville (2007, p.143), a
engenharia de requisitos pode
ser divido em desenvolvimento de requisitos e gerenciamento de
requisitos. O desenvolvimento de
requisitos dividido em quatro atividades: elicitao1, anlise,
especificao e validao. E o
gerenciamento de requisitos composto de trs atividades:
identificao de requisitos (a
identificao de requisitos aqui no se refere atividade de
elicitao de requisitos, mas sim a
atividade de organizar, como por exemplo: fazer atribuio de
identificador nico, adequaes de
1Optou-se por utilizar o termo elicitao para a traduo da palavra
elicitation da lngua inglesa. Pode-se afirmar que elicitar e
elicitao so simples adaptaes de palavras inglesas: o verbo (to)
elicit pode ser traduzido como: eliciar, fazer sair, trazer tona,
deduzir, concluir, induzir, evocar; e o substantivo elicitation tm
como significado: ao de extrair ou fazer surgir; (MICHAELIS, 1998).
O termo elicitation de uso corrente na literatura inglesa sobre o
tema de engenharia de requisitos. O vocbulo elicitao est sendo
usado com freqncia nas publicaes de lngua portuguesa na rea de
engenharia de requisitos (CYSNEIROS, 2001; FREITAS et al.,
2007).
-
9
atributos como status, prioridade e urgncia), gerenciamento de
mudanas de requisitos e
rastreabilidade de requisitos. Para um melhor entendimento, a
Figura 2 ilustra a diviso das
atividades do processo de engenharia de requisitos.
Figura 2 - Processo de engenharia de requisitos.
Fonte: adaptado de Wiegers (2006) adicionando a viso de Vliet
(2007).
No contexto deste trabalho, adotado o termo atividade para
referir-se s subreas do
desenvolvimento de requisitos. As atividades do processo de
engenharia de requisitos so descritas
como:
Elicitao - a elicitao de requisitos compreende as atividades que
envolvem o
entendimento ou descoberta das necessidades dos stakeholders
(WIEGERS, 2006),
com isso pretende-se entender as metas, objetivos e motivos que
levam ao
desenvolvimento de um sistema computacional. Diversos autores
relatam problemas
nessa atividade do processo de desenvolvimento de requisitos
(FREITA et al., 2007;
HOOD et al., 2008; PRESMANN, 2002; YOUNG, 2004). Em trabalhos
como o de
Gottesdiener (2008) e Freitas et al. (2007), ainda observado que
a definio correta
dos requisitos no incio do desenvolvimento uma fator crucial
para reduo de risco
de falhas e custos com defeitos.
Anlise depois de extrado os requisitos a anlise de requisitos
utiliza-se destes
para derivao e para que se possa chegar a um nvel de maior
detalhamento, alm
de resolver conflitos de interesses dos stakeholders, verificar
pontos vagos e fazer
-
10
priorizao dos requisitos (GOTTESDIENER, 2008; WIEGERS, 2006). A
anlise d
subsdios para que o analista possa aprimorar o entendimento
durante uma atividade
de elicitao (WIEGERS, 2006).
Especificao a atividade de especificao de requisito procede de
forma a
documentar os requisitos em um nvel apropriado de detalhes
(WIEGERS, 2006).
Normalmente, essa documentao realizada em linguagem natural.
Outros aspectos
sobre especificao incluem a diferenciao dos requisitos entre
requisitos funcionais
e no funcionais, visando documentar requisitos de forma
inequvoca e completa
(GOTTESDIENER, 2008). Para Vliet (2007, p.202), a especificao de
requisitos
reflete no entendimento mtuo do problema entre os stakeholders e
o documento
gerado serve de base para um contrato e tambm para testes de
conformidade com a
especificao de requisitos.
Validao a validao de requisitos tem a preocupao de demonstrar
que os
requisitos definidos realmente refletem as necessidades do
cliente
(SOMMERVILLE, 2007, p. 158). Conforme Nuseibeh e Easterbrook
(2000), a
validao de requisitos uma tarefa nada fcil de realizar, isso
devido a razes de
natureza filosfica, no que diz respeito a questes do que verdade
e do que
conhecido, e razes sociais, nas quais diz respeito dificuldade
de entrar em
consenso nos pontos conflitantes. Segundo Vliet (2007, p.242),
uma forma de
contornar essas dificuldades envolve a participao do cliente na
validao dos
requisitos, segundo o autor, o cliente quem realmente conhece o
problema e ele
quem deve decidir se a especificao do requisito foi escrita de
forma adequada e
que esta realmente descreva o seu problema.
Em paralelo a atividade de desenvolvimento de requisitos,
encontra-se o gerenciamento de
requisitos, este voltado a entender e controlar as mudanas dos
requisitos de sistema
(SOMMERVILLE, 2007, p. 161). Segundo Wiegers (2006), esta
atitude tem seu incio aps os
stakeholders terem acordado que os requisitos esto bons o
suficiente para servir de base para a
construo de uma parte do produto (software).
Conforme Hood et al. (2008, p.35), o gerenciamento de requisitos
uma interface da
engenharia de requisitos com todos os outros processos. Sendo
assim, todas as alteraes no projeto
-
11
devem estar em conformidade com a documentao de requisitos, alm
de ser possvel de filtrar ou
selecionar um conjunto de requisitos s diversas verses de
produto.
Para isso, o gerenciamento de requisitos envolve trs atividades
(VLIET, 2007, p.236):
Identificao de requisitos nessa atividade os requisitos so
identificados atravs de
um identificador nico para que possa ser referenciado por outros
requisitos em uma
matriz de rastreabilidade (SOMMERVILLE, 2007, p.162). Como
sugerido por Vliet
(2007, p.237), conveniente incluir tambm informaes sobre os
requisitos como,
por exemplo: status, prioridade, stakeholders envolvidos e
verso. A verso
necessria, j que os requisitos podem por diversas vezes serem
alterados e
atualizados.
Gerenciamento de mudanas de requisitos Essa atividade conduzida
de forma a
visualizar cada requisito como um item de configurao em um
procedimento de
gerncia de configurao2 (VLIET, 2007, p.237), o seu objetivo de
avaliar o
impacto e custos das mudanas (SOMMERVILLE, 2007, p.163).
Rastreabilidade de requisitos essa atividade objetiva relacionar
requisitos com
artefatos ou elementos da soluo. A rastreabilidade permite
rastrear artefatos onde
os requisitos so realizados (rastreabilidade para frente), e
tambm permite rastrear
artefatos que j foram escolhidos na soluo (rastreabilidade para
trs). A
rastreabilidade est ligada intimamente a melhorar a qualidade
dos sistemas de
software (SPANOUDAKIS e ZISMAN, 2005; DICK, 2002).
Segundo Wiegers (2006), o processo de engenharia de requisitos
deve ser realizado de
forma iterativa, deve ser planejado em vrios ciclos, com o
intuito de refinar os requisitos para se
obter um nvel de detalhamento mais adequado. A realizao das
atividades de levantamento,
anlise, especificao e validao podem ser feitas em paralelo (HOOD
et al., 2008, p.44;
WIEGERS, 2006).
2 A gerncia de configurao conforme o modelo CMMI-DEV (SEI,
2010a, p.114), tem o objetivo de estabelecer e manter a integridade
dos produtos de trabalho usando a identificao da configurao,
controle de configurao, representando status de configurao e
configurao de auditorias. Modelos importantes de maturidade como
CMMI-DEV (SEI, 2010a), MPS.BR (SOFTEX, 2009) e norma ISO/IEC 15504
(ISO/IEC Std. 15504, 2005, p.55) tambm conhecida como SPICE, exigem
o gerenciamento de configurao em um processo de gesto de
requisitos.
-
12
Como mencionado na literatura, o processo de engenharia de
requisito visa a criao e
manuteno do documento de especificao de requisitos (SOMMERVILLE,
2007, p.143). Ento,
no fim de um ciclo de uma iterao, gerado um documento de
especificao de requisitos, esse
documento reflete o entendimento mtuo do problema entre os
stakeholders e serve de base para
um contrato e tambm para testes de conformidade com a
especificao de requisitos (VLIET, 2007
p.202).
3.1 Elicitao de Requisitos
A elicitao de requisitos compreende atividades nas quais
objetivam o descobrimento
preciso do problema a ser resolvido e, portanto, identificao das
necessidades dos stakeholders e
suas restries ou limites (NUSEIBEH; EASTERBROOK, 2000; WIEGERS,
2006; AOUAD;
ARAYICI, 2010). Deve envolver atividades que permitam a
comunicao, a definio de
prioridade, a negociao e a colaborao com os stakeholders
relevantes (ZOWGHI; COULIN,
2005, p.21).
Na literatura, no existe consenso sobre as atividades realizadas
durante a elicitao de
requisitos. Contudo, consenso que a elicitao de requisitos uma
atividade realizada no incio do
processo de Engenharia de Requisitos e deve ser conduzida de
forma iterativa e integrada
(SOMMERVILLE, 2007, p. 148; ZOWGHI; COULIN, 2005, p.21). Uma
diviso da atividade de
elicitao feita por Zowghi e Coulin (2005, p.21-23), definindo a
elicitao de requisitos como um
processo que se divide em cinco tipos fundamentais: (i)
entendimento do domnio da aplicao; (ii)
identificar as fontes de requisitos; (iii) anlise dos
stakeholders; (iv) seleo de tcnicas, abordagens
e instrumentos que sero usados; e (v) elicitar os requisitos das
partes interessadas e de outras
fontes. A definio de um processo para a elicitao de requisitos
visa melhorar a colaborao entre
os envolvidos (BARBOSA et al., 2009). Porm, o processo pode
variar muito, este delineado
dependendo das pessoas que o envolvem (ZHANG, 2007).
A elicitao de requisitos uma tarefa difcil de ser realizada
(AOUAD; ARAYICI, 2010;
HOOD et al., 2008) e tambm dita como crucial para o sucesso de
um projeto de software
(GOTTESDIENER, 2008; FREITA et al., 2007; ZHANG, 2007).
Pesquisas relatam que problemas
na atividade de elicitao de requisitos podem levar ao insucesso
ou abandono de projetos
(DAVEY; COPE, 2008) e que erros cometidos nesse ponto podem ser
muito mais custosos de
serem resolvidos (BOEHM; BASILI, 2001; PRESSMAN, 2002) e, em
complemento, Robertson e
-
13
Robertson (2006) afirmam que 60% dos erros em produtos de
software so decorrentes de
requisitos incorretos ou incompletos.
Conforme relatado na literatura, os problemas ocorridos na
elicitao de requisitos so
decorrentes de problemas de comunicao humana; mudanas das
necessidades das organizaes e
limitao da viso de oportunidades (DAVEY; COPE, 2008; CHRISTEL;
KANG, 1992). Na
literatura, pode-se encontrar outros autores que reforam
problemas na atividade de elicitao de
requisitos e atribui que o maior peso de dificuldade incide na
compreenso dos requisitos (HOOD et
al., 2008; PRESMANN, 2002; YOUNG, 2004; SOMMERVILLE, 2007,
p.146). Neste sentido,
Zhang (2007) afirma que os requisitos devem ser analisados e
identificados proativamente, e deve-
se selecionar um mtodo adequado para diminuir os problemas na
elicitao.
As tcnicas para elicitao de requisitos so mtodos que os
analistas utilizam para
determinar as necessidades dos clientes e usurios, de modo que
os sistemas construdos possam ter
uma alta probabilidade de resolver de forma satisfatria essas
necessidades (HICKEY; DAVIS,
2003).
Segundo Leffingwell e Widrig (2003), a escolha de uma tcnica
(mtodo) para elicitao ir
variar dependendo de alguns pontos: tipo de aplicao, habilidade
da equipe de desenvolvimento,
habilidades e sofisticao do cliente, dimenso do problema,
criticidade3 da aplicao, tecnologia
utilizada e singularidade da aplicao. E o conhecimento dos
engenheiros de software sobre os
mtodos de desenvolvimento de requisitos deve ser pleno, o que
contribuir para prever as
necessidades do desenvolvimento e selecionar o mtodo mais
apropriado para cada projeto
(ZHANG, 2007).
Diversas tcnicas so mencionadas na literatura, cada uma dessas
tcnicas possui um objeto
diferente de observao ou investigao, e cada uma delas tem um
foco especfico em um
determinado tipo de requisitos. Segundo Zhang (2007), por se
tratar de um processo iterativo, e de
acordo com os meios em que se procede a comunicao entre
analistas e stakeholders, as tcnicas
3 Optou-se por utilizar o termo criticidade para a traduo do da
palavra criticality da lngua inglesa, que possui como significado:
criticidade (Google tradutor, 2010). O termo criticality de uso
corrente na literatura inglesa sobre assuntos que abordam
problemticas. No contexto deste trabalho o termo criticidade ser
utilizado para determinar quo crtica uma determinada situao.
-
14
de elicitao de requisitos podem ser distinguidas em quatro
tipos: estudo observacional, de
conversao, analticos e sintticos.
A classificao dos mtodos por tipos serve como um guia para os
engenheiros na escolha
do mtodo mais apropriado ou adequado para o levantamento, alm de
fornece base para evoluo
dos mtodos de levantamento de requisitos (ZHANG, 2007). Os tipos
de mtodos de elicitao de
requisitos so descritos a seguir, conforme Zhang (2007):
1. Mtodos observacionais: mtodo utilizado para compreenso do
domnio da
aplicao. Esse mtodo constitui na observao das atividades humanas
para
obteno de requisitos no tcitos e de difcil verbalizao. Incluem
nesse grupo as
seguintes tcnicas de elicitao:
a. Estudo etnogrfico Tcnica utilizada para estudar as pessoas em
seus
ambientes naturais. Com uso de mtodos etnogrficos, mais fcil
o
descobrimento de conhecimento tcito, o que no ocorre na maioria
das
outras tcnicas de elicitao (VLIET, 2007, p. 218). Segundo Zowghi
e
Coulin (2005, p. 29), um estudo etnogrfico eficaz quando a
necessidade de
um novo sistema decorrente de problemas existentes com o
processo e
procedimentos e padres complexos de relacionamento entre os
stakeholders.
b. Anlise social Consiste em colocar um observador em uma
sociedade ou
cultura por um determinado tempo com a preocupao de observar
detalhadamente todas as prticas realizadas pelo grupo (ZHANG,
2007).
c. Observao Nesta tcnica, o observador inserido em um grupo
para
observao de um determinado processo ou atividade. Durante a
observao,
o observador deve compreender as atividades que esto sendo
realizadas pelo
grupo sem exercer interferncia direta sobre estas (ZOWGHI;
COULIN,
2005, p.29). Ainda segundo Zowghi e Coulin (2005, p. 29),
tcnicas de
observao so custosas e exigem habilidade e esforo significativo
para
compreenso das aes que esto sendo realizadas. Outra questo
quanto
eficcia, nesta o indivduo que est sendo observado tem a tendncia
de
mudar o seu comportamento na execuo da tarefa quando consciente
que
est sendo vigiado.
-
15
d. Anlise de protocolo Em uma anlise de protocolo, os usurios
so
submetidos execuo de uma tarefa na qual sero observados por
um
analista, de forma simultnea a sua execuo, os participantes
falam em voz
alta o que esto fazendo e tambm sobre o seu pensamento sob o
processo
(GOGUEN; LINDE, 1993). Segundo Zowghi e Coulin (2005, p. 29), um
vis
pode ser introduzido pelo uso dessa tcnica. Na maioria dos
casos, pequenos
passos realizados no processo do usurio acabam ficando fora do
processo,
por serem tomados como abreviados ou esquecidos pelos usurios,
os quais
no podem ser explicados, que consequentemente ficam fora do
registro do
processo, assim, registrados de forma incompleta ou
incorreta.
2. Mtodos de conversao: so mtodos de obteno de requisitos no
qual se utiliza
comunicao verbal entre duas ou mais pessoas. A conversa um meio
natural de
expressar necessidade e ideias. considerada muito eficaz para
desenvolver e
compreender problemas. Algumas tcnicas de levantamento que se
utiliza deste
mtodo so:
a. Entrevista A tcnica mais comum na elicitao de requisitos
(ZHANG,
2007). Alguns pontos chaves referente entrevista so definidos
por
Leffingwell e Widrig (2003). Eles contribuem em afirmar que
entrevista
uma tcnica simples e que pode ser usada na maioria das
circunstncias. E a
sua conduo em um contexto de perguntas livres pode ajudar a
obter
entrevistas sem vis. Tambm pode ser apropriada para descoberta
de
requisitos e explorao de solues possveis. Conforme Alexander e
Stevens
(2002, p.22), a entrevista pode ser conduzida de forma
estruturada ou de
discusso livre. Nas entrevistas estruturadas, um roteiro de
perguntas
formulado de forma a fazer perguntas em pontos especficos. J as
entrevistas
de discusso livre ajudam a levantar novos requisitos ainda em
aberto ou
desconhecido. Alguns cuidados na escolha do tipo de entrevista
podem ser
tomados, as entrevistas estruturadas tendem a limitar o que os
stakeholders
poderiam dizer sobre o problema, ocultando coisas que podem ser
de
interesse no sistema. Sugesto para conduo de uma entrevista
feita em
Alexander e Stevens (2002, p.23).
-
16
b. Workshop uma forma poderosa e muito utilizada para fazer
os
stakeholders pensarem alm da forma atual de como realizam suas
tarefas.
(ROBERTSON; ROBERTSON, 2006; LEFFINGWELL; WIDRIG, 2003). A
tcnica consiste em uma reunio realizada de forma estruturada,
dinamizada e
intensiva, na qual esto presentes os stakeholders chaves do
projeto e
concentra-se na criao ou reviso das caractersticas de alto nvel
do projeto.
Sua conduo elaborada de forma a se obter mais rapidamente o
consenso e
acordo dos stakeholders sob os requisitos (LEFFINGWELL;
WIDRIG,
2003). Normalmente, realizada em conjunto com as tcnicas de
entrevistas
(ALEXANDER; STEVENS, 2002, p. 27), e de brainstorming
(LEFFINGWELL; WIDRIG, 2003).
c. Brainstorming A tcnica de brainstorming envolve a gerao e
reduo de
idias (ZHANG, 2007; LEFFINGWELL; WIDRIG, 2003). Uma sesso de
brainstorming amplamente utilizada no incio do projeto, ela
objetiva
coletar idias ou caracterstica inovadoras de um produto em um
curto espao
de tempo (AOUAD; ARAYICI, 2010, p.55).
3. Mtodos Analticos: As tcnicas classificadas no mtodo analtico
so aquelas que
exploram documentao existente, ou que utiliza deduo para
adquirir
conhecimentos e requisitos. As tcnicas que se enquadram no mtodo
analtico so:
a. Reuso de requisitos Consiste em tcnicas nas quais se
procura
especificaes de requisitos em projetos anteriores que tenha
potencial
reutilizvel. Muitas das especificaes de requisitos utilizadas em
projetos
anteriores podem ser reutilizadas sem nenhum tipo de alterao, e
muitas
podem ser reutilizadas para um novo projeto com pequenas
adequaes
(ROBERTSON; ROBERTSON, 2006). Segundo Cybulski e Reed (2000),
a
reutilizao de requisitos fornece importantes ganhos tanto na
produtividade
quanto na qualidade no processo de desenvolvimento. As prximas
sees
abordaro mais detalhadamente sobre tcnicas de reuso por se
tratar de um
dos focos deste trabalho.
b. Estudo e anlise de documentos Nessa tcnica, os requisitos so
extrados
de documentos informais. Os requisitos escondidos que possam
estar
-
17
contidos nos documentos so extrados e registrados. No entanto,
para os
requisitos obtidos por esta tcnica devem estar relacionados com
algum
stakeholder que justifique a existncia desses requisitos (HULL
et al., 2005,
p. 100).
c. Laddering (escada) Se trata de uma tcnica de questionamento
estruturado
que possibilita uma hierarquia de conceitos a ser
estabelecidos
(CORBRIDGE et al., 1994). Laddering utiliza da tcnica de
entrevista para
obter uma compreenso de como os stakeholders percebem os
atributos de
produtos em associaes significativas com relao a si mesmo. A
entrevista
realizada de forma dirigida, as perguntas so do tipo "Por que
isso
importante para voc?". As questes realizadas na entrevista
objetivam
expressar um conjunto de ligaes entre os principais elementos de
percepo
em toda gama de atributos, consequncias e valores. Esse conjunto
de
ligaes, ou escada, referido como orientaes de percepo. As
orientaes de percepo por sua vez, representam combinaes de
elementos que servem de base para distino entre produtos e
classes de um
determinado produto (REYNOLDS; GUTMAN, 1988). Essa tcnica
usada
principalmente para esclarecer requisitos e categorizar
entidades de domnio
(ZOWGHI; COULIN, 2005, p.28).
d. Carto de triagem (card sorting) uma tcnica usada para
descobrir como
os stakeholders classificam determinada informao em sua mente de
acordo
com seu prprio entendimento (ZOWGHI; COULIN, 2005, p.27). A
tcnica
consiste na utilizao de cartes, os quais so escritos termos os
quais se
pretende analisar como os stakeholders os entendem. Os
participantes
agrupam esses cartes da forma que for mais lgica para ele e
depois rotula
cada grupo de cartes. A tcnica aplicada individualmente, e no
final os
agrupamentos comuns geram o conceito que se buscava com a
tcnica
(LEITE, 2007). Segundo Wang et. al. (2006), carto de triagem um
meio
eficaz para suscitar ideias sobre a estrutura do conhecimento e
muito til
para ajudar os entrevistados a recordar conceitos do domnio. A
tcnica de
card sorting tambm muito utilizada por design para identificar
a
navegao em um sistema interativo (ZILSE, 2007; VAN AMSTEL,
2005).
-
18
e. Grade de repertrio uma tcnica derivada da Psicologia dos
Construtos4
Pessoais (KELLY, 1955 apud FERNANDES, 2002). Nela o analista
faz
observaes de uma forma no intrusiva da percepo do mundo
pelos
stakeholders. As observaes so anotadas em uma matriz na qual
existe uma
relao estabelecida entre os construtos e elementos. Um sistema
de
pontuao responsvel por estabelecer a relao entre construtos,
entre os
elementos e entre construtos e elementos (FERNANDES, 2002).
Conforme
Steed e Macdonnell (2003), uma grade repertrio deve de expressar
algo
sobre a maneira como uma pessoa olha para as coisas. O apelo
para
Psicologia uma forma de se obter algo que difcil de expressar
por outros
meios.
4. Mtodos Sintticos: so mtodos nos quais se combina diferentes
meios de
comunicaes para demonstrar funcionalidade e interaes do sistema.
Destacam-se
como exemplo de tcnicas do mtodo sinttico as seguintes
tcnicas:
a. Cenrios uma tcnica muito utilizada para compreenso e validao
de
requisitos e desenvolvimento de casos de teste (ZOWGHI; COULIN,
2005,
p. 31). uma narrativa que descreve uma viso geral de uma interao
por
parte dos stakeholders com o sistema. A narrativa representa
normalmente
um passo-a-passo do objetivo que se pretende alcanar (POTTS,
1995;
ALEXANDER; STEVENS, 2002, p. 45). Segundo Sommerville (2007,
p.153), os cenrios ajudam particularmente a adicionar um maior
grau de
detalhamento na descrio de requisitos.
b. Storyboards Segundo Zowghi e Coulin (2005), storyboard uma
tcnica
utilizada para obter uma reao inicial dos stakeholders sobre
um
determinado conceito proposto para a aplicao. empregada no incio
do
ciclo de desenvolvimento, mesmo antes do desenvolvimento dos
requisitos.
Destaca-se como fatores positivos sobre os storyboarding, o fato
de se tratar
4 Construtos definido uma unidade bsica de construo de
significado, consistindo essencialmente em uma discriminao entre
elementos, sendo que a construo de uma experincia ou acontecimento
tem subjacente uma afirmao e uma negao simultneas (FERNANDES, 2002,
p.82).
-
19
de uma tcnica extremamente barata, amigvel, informal e
interativa
(LEFFINGWELL; WIDRIG, 2003).
c. Prototipao A prototipao uma tcnica indicada quando houver
a
criao de um sistema sem precedentes. Geralmente utilizada para
dar uma
ideia aos stakeholders do que pode ser possvel no projeto,
proporcionando
um maior entendimento de suas necessidades (HULL et al., 2005,
p. 103).
Ainda segundo Hull et al., (2005, p.103), existem alguns
problema em se usar
prottipos: (i) esforo considervel para construo de prottipos,
(ii)
prottipos tendem a fazer os stakeholders a mudarem facilmente de
ideia, e
(iii) prottipos tendem a impulsionar os stakeholders a utiliz-lo
de forma
operacional.
d. Joint Application Development - JAD uma tcnica de reunio que
visa
acelerar o processo de desenvolvimento de software. utilizada
como meio
de se obter um senso comum entre os stakeholders. O JAD
conduzido em
quatro sesses:
i. primeira reunio: as atividades dessa sesso so: (i) abertura
pelo
patrocinador; (ii) definio do escopo do projeto; (iii) definio
dos
objetivos especficos; (iv) descrio dos problemas com a
abordagem
atual, referente ao que o novo sistema ir resolver; (v)
identificao
dos stakeholders que sero entrevistados na atividade de elicitao
de
requisitos; (vi) definio da data da sesso de design5.
ii. levantamento de dados e anlise.
iii. planejamento para a sesso de design.
5 Sesso de Design uma reunio em que o Analista de Sistemas
apresenta ao Condutor a proposta do sistema, para que o Condutor
possa apresentar suas crticas e sugestes para uma melhor apresentao
da proposta a ser debatida na reunio de design (PALUDO et al.,
2009).
-
20
iv. reunio de design6: considera a sesso principal da tcnica do
JAD,
nesta etapa que feita a definio de objetivos, levantamento
de
problemas e limites do sistema, anlise dos processos, dados
e
interfaces do sistema, anlise do novo fluxo e necessidades
administravas, apresentao do cronograma, aprovao do novo
fluxo
e avaliao da reunio. No final desta sesso elaborado o
documento
final, no qual consiste de todas as anotaes de todas as
sesses
realizadas e representa a concluso do grupo (JUDY, 1993 apud
PALUDO et al., 2009).
e. Inqurito contextual uma adaptao de tcnicas de etnografia, no
qual se
combina tcnicas de entrevistas, de observao do local de trabalho
e
prototipagem. essencialmente usado para design de sistemas
interativos,
nos quais o design interface do usurio crtica (HOLTZBLATT;
BEYER,
1993; ZHANG, 2007).
4 RASTREABILIDADE DE REQUISITOS
A rastreabilidade uma das atividades da gerncia de requisitos
(VLIET, 2007, p.236), mas
tambm uma atividade que apoia vrias atividades no processo de
desenvolvimento de software.
Seu emprego visa a melhoria de qualidade na obteno de sistemas
de software (SPANOUDAKIS;
ZISMAN, 2005; GENVIGIR, 2009).
Utilizando-se do entendimento de Gotel e Finkelstein (1994),
rastreabilidade de requisitos
refere-se capacidade de descrever e acompanhar a vida de um
requisito no ciclo de
desenvolvimento, tanto para frente quanto para traz deste ciclo,
e atravs de todas as variaes entre
o modelo de desenvolvimento em um estgio do ciclo de vida de
desenvolvimento de sistemas.
Conforme Kulak e Guiney (2003), os requisitos devem ser
identificados durante todo o ciclo de
desenvolvimento do sistema. A rastreabilidade fornece suporte
para auditoria de cada atividade no
6 A reunio de design uma reunio onde os atores envolvidos no
projeto iro debater sobre a proposta. Neste sentido, esta reunio
dividida da seguinte forma: i) apresentao, definio de objetivos,
levantamento de problemas e limites do sistema; ii) anlise dos
processos, dados e interfaces do sistema; iii) anlise do novo fluxo
e necessidades administrativas surgidas; iv) cronograma, aprovao do
novo fluxo e avaliao da reunio; e v) elaborao do documento final
(PALUDO et al., 2009).
-
21
desenvolvimento e manuteno. O emprego correto de rastreabilidade
no projeto descreve o porqu
da atividade estar sendo realizada.
A rastreabilidade pode ser enquadrada em duas classificaes
gerais: i) rastreabilidade
horizontal e vertical, e ii) pr-rastreabilidade e
ps-rastreabilidade (GENVIGIR, 2009, p.39).
Segundo Lindvall e Sandahl (1996), a rastreabilidade horizontal
a classificao referente s
diferentes verses ou variaes de requisitos ou artefatos. E
rastreabilidade vertical refere-se a que
realizada entre requisitos e artefatos produzidos ao longo do
processo de software.
A segunda classificao de rastreabilidade trata da
pr-rastreabilidade e ps-rastreabilidade.
Ambas se referem aos aspectos do ciclo de vida dos requisitos,
porm a pr-rastreabilidade se
concentra antes de serem includos na especificao dos requisitos
e a ps-rastreabilidade se
concentra aps a sua incluso na especificao de requisitos (GOTEL;
FINKELSTEIN, 1994). Isso
quer dizer que pr-rastreabilidade se preocupa com a produo dos
requisitos e a ps-rastreabilidade
no desenvolvimento dos requisitos. A Figura 3 ilustra o conceito
de pr e a ps-rastreabilidade
sugerido por Gotel e Finkelstein (1994).
Figura 3 - Pr e ps-rastreabilidade.
Fonte: Adaptado de Gotel e Finkelstein (1994).
Para Gotel e Finkelstein (1994), problemas na prtica de
rastreabilidade foram encontrados
pela falta da sua distino, e crucial o entendimento da diferena
entre as duas classificaes.
destacada como principal diferena a forma de lidar com as
informaes e os problemas que a
rastreabilidade pode ajudar. A pr-rastreabilidade depende da
capacidade de rastreabilidade de
requisitos para frente ou para trs, de volta a sua origem ou
fontes (clientes, usurios, normas e
etc.), atravs dos artefatos gerados ao longo do processo de
engenharia de requisitos. Mudanas no
-
22
processo precisam ser refeitas na especificao de requisitos e
devem ser propagadas a partir de sua
fonte.
A ps-rastreabilidade depende da capacidade de rastrear os
requisitos para frente ou para
trs de uma base de referncia. Neste caso, o documento de
especificao de requisitos a base de
referncia (baseline) e seu rastreabilidade realizada atravs dos
artefatos que esto relacionados
com os requisitos. Mudanas realizadas na baseline devem ser
propagadas a todos os artefatos
relacionados (GOTEL; FINKELSTEIN, 1994).
Em relao rastreabilidade, existem tambm diversos tipos de
relacionamentos, esses
relacionamentos esto dispostos na literatura em oito grupos:
i. Dependncia: neste tipo de relao, um elemento e1 depende de um
elemento e2, se
a existncia do elemento de e1 depende da existncia do elemento
e2, ou se os
impactos ocorridos em e2 tm que ser refletidos em e1; O seu
papel de ajudar a
gerencia dependncias entre objetos (este normalmente no mesmo
estgio de
desenvolvimento), que por muitas vezes impostas por uma restrio
(recurso,
competncia, compatibilidade). Esse relacionamento utilizado para
registrar a
composio e hierarquia dos objetos e para gerir as repercusses
das mudanas em
um objeto sobre outro que dele dependa (RAMESH; JARKE,
2001).
ii. Generalizao/Refinamento: este relacionamento objetiva
identificar como os
elementos de um sistema complexo podem ser divididos em
componentes, como os
elementos podem ser combinados para originar outros elementos, e
como um
elemento pode ser refinado por outro elemento;
iii. Evoluo: este relacionamento especifica a evoluo dos
elementos, consiste em um
elemento e1 evolves_to um elemento e2, se e1 for substitudo por
e2 durante o
processo de desenvolvimento. Seu propsito de permitir a
identificao das origens
dos objetos para melhor compreenso dos requisitos e outros
objetos e para registrar
informaes quanto s modificaes e histricos de refinamentos dos
vrios objetos
(SAYO; LEITE, 2005);
iv. Satisfao: a relao em que um elemento e1 satisfaz um elemento
e2, se em e1
corresponde s expectativas, necessidades e desejos para e2, ou
se e1 corresponde as
condies representadas por e2. Este relacionamento visa garantir
que os requisitos
-
23
foram satisfeitos pelo sistema, registrando os desenhos criados
para satisfazer
requisitos e os componentes para os quais requisitos so alocados
(SAYO; LEITE,
2005). Alguns exemplos de propsitos para sua utilizao seriam:
assegurar a
coerncia entre as sadas das diferentes fases do ciclo de vida,
acompanhamento dos
projetos criados para satisfazer os requisitos, e identificar o
sistema/subsistema/
componentes que satisfaam requisitos e que cada componente
satisfaa algum
requisito;
v. Sobreposio: esta relao corresponde a um elemento e1 que
coincide com um
elemento e2, e ambos se referem a uma caracterstica comum de um
sistema ou ao
seu domnio. O trabalho de Spanoudakis (2002) apresenta uma
proposta para
utilizao deste tipo de relacionamento, o estudo descreve regras
que expressam
heursticas para gerao dos relacionamentos de sobreposio
baseando-se em
padres sintticos especficos;
vi. Conflitantes: neste tipo de relao existem conflitos entre os
dois elementos e1 e e2.
Este tipo de relaciona auxilia na indicao de conflitos
relacionados entre requisitos,
componentes, e elementos de projeto, para que se possa definir
questes relacionadas
a esses elementos, e para fornecer informaes que possam ajudar
na soluo dos
conflitos e problemas (SPANOUDAKIS; ZISMAN, 2005);
vii. Racionalizao: esta relao usada para representa e manter a
lgica por trs da
criao e evoluo dos elementos, e as decises sobre o sistema em
diferentes nveis
de detalhe. Nesta relao o objetivo identificar as razes por trs
da criao de
vrios objetos, para isso so identificadas as seguintes razes:
justificativa para
criao/modificao dos objetos, decises importantes e as suposies
feitas,
identificao do contexto no qual o objeto foi criado, assegurar a
transparncia no
processo de deciso, incluindo alternativas descartadas (RAMESH;
JARKE, 2001); e
viii. Contribuio: este tipo de relacionamento visa representar
as associaes entre os
artefatos de requisitos e os stakeholders que tem contribudo
para a gerao dos
requisitos (SPANOUDAKIS; ZISMAN, 2005, p.5-8).
Segundo Dick (2002), a atividade de rastreabilidade tornou-se
uma prtica fundamental na
engenharia de sistemas e a relao de ligao dos requisitos em um
documento com os outros
-
24
artefatos do processo de software pode ser usada para vrios
tipos de anlise, tais como: anlise de
impacto, anlise de derivao, anlise de cobertura de impacto e
anlise de cobertura de derivao.
A capacidade para realizao dessas anlises proporciona um salto
qualitativo no processo de
engenharia de requisitos.
Conforme Spanoudakis e Zisman (2005), alm de servir de base nas
anlises relatadas por
Dick (2002), a rastreabilidade tambm pode ser usada para anlise
em processo de reutilizao dos
componentes de sistema de software e na identificao e comparao
das necessidades de sistemas
novos com sistemas j existentes. Outro aspecto relatado pelos
autores, a possibilidade de utilizar
a rastreabilidade para permitir que os usurios tenham uma melhor
compreenso das
funcionalidades do sistema.
Segundo Spanoudakis e Zisman (2005), a gerao de rastreabilidade
pode ser feita de forma
manual, automtica ou semi-automtica. A maioria dos instrumentos
para o emprego de
rastreabilidade limita o seu suporte para a criao das relaes de
rastreabilidade manualmente.
Porm, esse tipo de abordagem para gerao das relaes de
rastreabilidade difcil de ser
realizada, envolve maior complexidade, necessita de mais tempo
para ser realizada e mais
propensa a erros. Para aliviar estes problemas citados, faz-se
necessrio a aplicao de alguma
abordagem que d suporte a gerao automtica ou semi-automtica das
relaes de rastreabilidade
(SPANOUDAKIS; ZISMAN, 2005).
5 DOCUMENTO DE ESPECIFICAO DE REQUISITOS
O documento de especificao de requisitos o documento que dispe
das declaraes
oficiais as quais os desenvolvedores devem implementar
(SOMMERVILLE, 2007, p. 136). A
especificao dos requisitos do sistema a atividade auge da
anlise. neste ponto em que todas as
descries das funes do sistema, restries do projeto, validaes
apropriadas e outros dados
pertinentes aos requisitos so documentados (PRESSMAN, 2002, p.
267). Sua utilizao tambm
essencial para a elaborao de um contrato de desenvolvimento do
software (SOMMERVILLE,
2007, p. 138). A concluso da sua reviso um marco final do
processo de engenharia de
requisitos, nas quais todas as atividades do processo de
engenharia de requisitos foram concludas
(VLIET, 2007 p.12).
Segundo Smith (2006), a elicitao de requisitos, anlise e
documentao so atividades
importantes no processo de software, mas muitas vezes so
realizadas de forma negligente e trazem
-
25
problemas nesta etapa do processo de desenvolvimento. Sem uma
descrio precisa dos requisitos
do produto muito improvvel que um desenvolvedor consiga entregar
um produto que atenda as
necessidades do seu cliente. Entretanto, se o desenvolver j tem
uma boa compreenso do problema
pode ser que se aproxime do produto esperado sem utilizar-se de
uma documentao dos requisitos,
mas dificilmente isso ocorrer porque normalmente as potenciais
divergncias fazem produzir um
documento de especificaes de requisitos (PARNAS, 2000).
Conforme Smith (2006), a documentao dos requisitos importante
porque os problemas
que envolvem a computao so complexos, com muitas fontes
potenciais para ambiguidade no
entendimento de terminologias e notaes. Parnas (2000) ressalta a
importncia do documento de
especificao de requisitos afirmando que a sua concluso dada de
forma incompleta ou
inconsistente pode levar ao fracasso ou abandono do projeto ou
implementaes de necessidades
equivocadas pelos desenvolvedores.
Porm, ressalta-se que a documentao precisa propicia muitos
benefcios no processo de
desenvolvimento. Segundo Van Schouwen et al. (1993), esses
benefcios so:
1) os profissionais que trabalham no projeto do software tm uma
melhor viso do que
esto construindo, antes de prosseguir o seu trabalho;
2) a reviso das especificaes com os stakeholders pode ser feita
de forma a verificar
se suas necessidades esto sendo satisfeitas;
3) os profissionais responsveis pela garantia da qualidade podem
verificar uma
implementao contra uma declarao de comportamento exigido e pode
formular
testes de validao sem olhar o cdigo fonte;
4) a equipe de manuteno pode se familiarizar mais facilmente com
o sistema,
podendo manter o design original quando houver intenes de fazer
alteraes.
Smith (2006) refora alguns desses benefcios e contribui em
destacar mais alguns como:
1) nica maneira de julgar a exatido e confiabilidade do software
por comparao
com as especificaes dos requisitos;
2) possibilidade de documentar claramente as especificaes das
premissas e restries
de dados.
-
26
Segundo Pressman (2002, p.259), o modo de realizar a especificao
se reflete na qualidade
da soluo. Neste sentido, como caractersticas de uma boa
especificao de requisitos, a norma Std
830-1998 (1998, p.4) contribui em destacar que a especificao de
requisitos deve ser:
a) Correta: considerada correta quando todos os requisitos
registrados nele sero
correspondidos pelo software.
b) No ambgua: quando o requisito expresso tem uma nica
interpretao.
c) Completa: refere-se a que todos os requisitos significantes
estejam reconhecidos e
tratados, e que todas as respostas do software estejam
definidas, que todas as figuras,
tabelas e diagramas estejam com suas respectivas legendas e
referncias completas,
bem como a definio de todos os termos e unidades de medidas
utilizadas no
documento.
d) Consistente: nenhum subconjunto individual de requisitos
descrito entra em conflito
com outro requisito.
e) Classificado por importncia e/ou estabilidade: refere-se
associao de um
requisito expresso no documento a um identificador de importncia
e/ou
estabilidade.
f) Verificvel: a verificao de um requisito pode ser feita por um
processo finito, no
qual uma mquina ou uma pessoa possa fazer a sua verificao quanto
a sua
implementao no produto de software.
g) Modificvel: esta caracterstica implica quanto estrutura e
estilo aos quais
mudanas a requisitos possam ser efetuados de forma fcil,
completa e consistente, e
ainda preservando a estrutura e estilo.
h) Rastrevel: refere-se quanto facilidade a qual um requisito
consiga identificar a
sua origem e suas verses futuras no processo de
desenvolvimento.
Alm dessas caractersticas, Young (2006) complementa como
caractersticas desejveis:
a) Necessrio: quanto o requisito atende as necessidades reais do
sistema.
-
27
b) Possvel: refere-se a quanto um requisito factvel e pode ser
realizado dentro do
oramento e cronograma.
c) Conciso: o requisito deve ter uma declarao breve, resumida e
exata.
d) Usar construtor padro: o requisito deve ser declarado no
imperativo, utilizando-se
da palavra dever.
e) Implementvel: possvel de traduzir para o projeto.
f) Clusulas evasivas: recomenda-se a no utilizao de palavras que
implicam
excees ou termos especulativos. Como por exemplo: se, quando,
mas, exceto, a
menos que, embora, geralmente, frequentemente e tipicamente.
Conforme Sommerville (2007, p. 137), o documento de especificao
de requisitos visa
atender diferentes stakeholders. Alguns destes possveis
stakeholders so apresentados na Figura 4.
Para esses stakeholders, o documento de especificao de
requisitos tem que ser um compromisso
de comunicao, definindo em detalhes as informaes sobre as
necessidades dos clientes, como
tambm informaes de possvel evoluo do sistema.
Figura 4 - Usurios de um documento de especificao de requisitos
de software. Fonte: Sommerville (2007, p. 137).
Gerentes Utilizam o documento de especificao de requisitos para
planejar um pedido de proposta para o software e para planejar o
processo de desenvolvimento.
Clientes Especificam os requisitos e os lem para verificar se
eles atendem a suas necessidades. Especificam as mudanas nos
requisitos.
Engenheiros de software
Utilizam os requisitos para compreender o sistema que deve ser
desenvolvido.
Engenheiros de testes
Utilizam os requisitos para desenvolver testes de software.
Engenheiros de manuteno
Utilizam os requisitos para ajudar a compreender o software e as
relaes entre as suas partes.
-
28
Pressman (2002, p. 271) colabora em afirmar que uma reviso do
documento de
especificaes de requisitos fundamental para garantir que os
stakeholders tenham a mesma
percepo do sistema. Essa reviso deve ser conduzida de forma a
descobrir problemas que possam
estar ocultos no contedo do documento.
De um modo geral, um documento de especificao de requisitos deve
sempre descrever as
seguintes questes (IEEE Std 830-1998, 1998, p.3):
Funcionalidades: Refere-se ao que o software deve fazer.
Interfaces externas: descreve questes relacionadas com a interao
do software
com as pessoas.
Performance ou Desempenho: Referente a questes de velocidade,
disponibilidade,
tempo de resposta, tempo de recuperao, entre outras.
Atributos: Refere-se s questes de portabilidade, correo,
manuteno, segurana,
etc.
Restries: Preocupa-se com as questes quanto as restries impostas
a
implementao do projeto.
Outra orientao feita pela norma IEEE Std 830-1998 (1998), diz
respeito estrutura do
documento de especificao de requisitos. A Figura 5 ilustra um
esboo da estrutura de um
documento de especificao de requisitos obtido na norma IEEE Std
830-1998 (1998, p.11). Em
nada implica a mudana dos nomes dos dados, porm todas essas
informaes devem ser includas
para obter-se um bom documento de especificao de requisitos.
-
29
1. Introduo 1.1. Propsito 1.2. mbito 1.3. Definies, acrnimos e
abreviaturas 1.4. Referncias 1.5. Organizao
2. Descrio geral 2.1. Perspectiva do produto 2.2.
Funcionalidades do produto 2.3. Caracterstica do utilizador 2.4.
Restries 2.5. Assunes e dependncias
3. Requisitos Apndices ndice
Figura 5 - Esboo de um documento de especificao de
requisitos.
Fonte: IEEE Std 830-1998 (1998, p.11).
Segundo as orientaes da Std 830-1998 (1998, p.11-15), a Seo 1
disposta na Figura 5,
refere-se introduo do documento de especificao de requisitos,
devendo fornecer informaes
de uma viso geral de todo documento. A Seo 2 para um documento
de especificao de
requisitos deve descrever os fatores gerais que afetam o produto
e seus requisitos, contribuindo para
um melhor entendimento dos requisitos que so apresentados
detalhadamente na Seo 3. A Seo
3 deve conter todos os requisitos de software, esses requisitos
devem ser detalhados a um nvel que
permita que os projetistas e equipe de testes possam projetar e
testar um sistema visando satisfazer
esses requisitos. Ressalta-se em Std 830-1998 (1998, p.15), que
os requisitos declarados na Seo 3,
devem incluir, no mnimo, um estmulo como descrio de cada entrada
no sistema, cada resposta
de sada do sistema, bem como todas as funes desempenhadas pelo
sistema ao responder uma
entrada ou apoiar uma sada.
Conforme Hull et al. (2005, p.75), a organizao dos requisitos em
uma estrutura correta
pode beneficiar nos seguintes pontos:
minimizar o nmero de requisitos;
compreender grandes quantidades de informao;
encontrar conjuntos de requisitos relativos a temas
especficos;
deteco de omisses e duplicaes de requisitos;
eliminar os conflitos entre os requisitos;
-
30
gerir iterao (por exemplo, requisitos em atraso);
rejeitar requisitos pobres;
avaliar os requisitos;
reuso de requisitos de outros projetos.
Segundo Wiegers (2006), requisitos nunca so acabados ou
completos. Alguns cuidados
devem ser tomados para no chegar a uma paralisia da anlise, pois
o sucesso do negcio no
est na escrita perfeita de um documento de especificao de
requisitos. Esta etapa deve ser
concluda quando se obteve requisitos de sistemas bons o
suficiente para que a equipe possa
prosseguir com o projeto.
6 CONCLUSO
Este relatrio tcnico oferece discusso sobre os conceitos bsicos
sob os aspectos gerais de
Engenharia de Requisitos, bem como seu processo e atividades.
Foram abordados tambm os
principais aspectos sobre a prtica da atividade de
rastreabilidade e a descrio dos aspectos que
envolvem o documento de especificao de requisitos. A Engenharia
de Requisitos oferece
atividades, no qual se pode coletar, especificar,
analisar/verificar e gerenciar os requisitos. A
preocupao da engenharia de requisito est em entender as
necessidades reais do sistema, e
document-la.
-
31
REFERNCIAS BIBLIOGRFICAS
ALEXANDER, I. F., STEVENS, R. Writing Better Requirements,
Pearson Education: Great Britain, 2002
AOUAD G., ARAYICI, Y. Requirements Engineering for Computer
Integrated Environments in Construction, Wiley-Blackwell: United
Kingdom, 2010
BARBOSA, B., WERNECK, M., ASSIS, H., FERNANDES, U., SILVA, I. Um
processo de elicitao de requisitos com foco na seleo da tcnica de
elicitao, SBQS 2009 - VIII Simpsio Brasileiro de Qualidade de
Software, 2009
BOEHM, B., BASILI, V. R.. Software Defect Reduction Top 10 List,
IEEE Computer. 34(1); Los Alamitos, CA: IEEE Computer Society;
2001, doi:10.1109/2.962984
CHENG, B. H. C., ATLEE, J. M. Research Directions in
Requirements Engineering, International Conference on Software
Engineering 2007 Future of Software Engineering, IEEE Computer
Society Washington, DC, USA, 2007, ISBN:0-7695-2829-5
CHRISTEL, M. G., KANG, K. C. Issues in Requirements Elicitation,
Technical Report Software Engineering Institute CMU/SEI-92-TR-12.7,
September 1992. Disponvel
em:http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf.
Acessado outubro de 2009.
CORBRIDGE, C., RUGG, G., MAJOR, N. P., SHADBOLT, N. R., BURTON,
A.M. Laddering: technique and tool use in knowledge acquisition,
Knowledge acquisition, 6, pp. 315-341, 1994.
CYBULSKI, J. L., REED, K. Requirements Classification and Reuse:
Crossing Domain Boundaries. In Conference on Software Reuse,
ICSR'2000, (Vienna, Austria, 2000), 190-210, 2000
CYSNEIROS, L. M. Requisitos No Funcionais: Da Elicitao ao Modelo
Conceitual, PUC-Rio, Tese de Doutorado e Cincias da Computao,
2001
CYSNEIROS, L. M., LEITE, J. C. S. P. Utilizando Requisitos No
Funcionais para Anlise de Modelos Orientados a Dados, Anais do
WER98 - Workshop em Engenharia de Requisitos, Maring-PR, Brasil,
Outubro 12, 1998, pp 149-158. Disponvel em: . Acessado junho de
2010
DAVEY, B; COPE, C. Requirements Elicitation Whats Missing?,
Issues in Informing Science and Information Technology, vol.5,
2008
DICK, J. Rich Traceability, Proceedings of the 1st International
Workshop on Traceability in Emerging Forms of Software Engineering,
Edinburgh, Scotland, 2002
FERNANDES, E. M. Grelha de Repertrio, Universidade do Minho.
Centro de Estudos em Educao e Psicologia, 2002. Disponvel em
http://repositorium.sdum.uminho.pt/bitstream/1822/4210/1/Grelha%20de%20Repert%C3%B3rio.pdf.
Acessado em junho de 2010
-
32
FREITAS, D. P.; BORGES, M. R. S., ARAJO, R. M. Colaborao e
Negociao na Elicitao de Requisitos, In IDEAS - Workshop
Iberoamericano de Ingenieria de Requisitos y Ambientes de software,
Venezuela - Maio 2007, Disponvel em:
http://kuainasi.ciens.ucv.ve/ideas07/documentos/articulos_ideas/Articulo74.pdf,
Acessado outubro de 2009
GENVIGIR, E. C. Um modelo para rastreabilidade de requisitos de
software baseado em generalizao de elos e atributos, So Jose dos
Campos - SP, INPE, Tese de dourado em computao aplicada, 2009
GOTEL, O. C. Z., FINKELSTEIN, C. W. An Analysis of the
Requirements Traceability Problem, Proceedings of the First
International Conference on (22 April 1994), pp. 94-101, 1994
GOTTESDIENER, E. Good Practices for Developing User
Requirements, Crosstalk - The Journal of Defense Software
Engineering, March, 2008
HICKEY A. M., DAVIS, A. M. Elicitation technique selection: How
do experts do it? In Proceedings of the 11th IEEE International
requirements engineering conference, Monterey Bay, CA, pp. 169-178,
2003
HOLTZBLATT, K., BAYER, H. Making customer-centered design work
for teams. Comm. ACM, Volume 36, Issue 10, 1993
HOOD, C., WIEDEMANN, S., FICHTINGER, S., PAUTZ, U. Requirements
Management: The Interface Between Requirements Development and All
Other Systems Engineering Processes. Springer-Verlag Berlin
Heidelberg, 2008. ISBN 978-3-540-47689-4
HULL, E., JACKSON, K., DICK, J. Requirements Engineering, Second
Edition, Springer London Berlin Heidelberg, 2005
IEEE Std 830-1998, IEEE Recommended Practice for Software
Requirements Specifications, Nova Iorque: IEEE, 1998. ISBN
0-7381-0332-2
ISO/IEC Std. 15504. Information Tecnology - Process Assessment -
Part 5, International Organization for Standardization, 2005
JUDY, A. H. Joint Application Design. So Paulo: Markron Books,
1993
KELLY, G. The psychology of personal constructs. New York:
Norton, 1955
KOTONYA, G., SOMMERVILLE, I. Requirements Engineering: Process
and Techniques. Editora John Wiley and Sons. 1998.
KULAK, D., GUINEY, E. Use Cases: Requirements in Context, Second
Edition, Addison Wesley, 2003
LEFFINGWELL, D., WIDRIG, D. Managing Software Requirements: A
Use Case Approach, Second Edition, Addison Wesley, 2003
LEITE, J. C. S. P. Tcnicas de Coleta de Fatos (Elicitao),
setembro de 2007, em Livro Vivo: Engenharia de Requisitos,
http://livrodeengenhariaderequisitos.blogspot.com/, 2007.
Disponvel
-
33
em: . Acessado em maro de 2010.
LINDVALL M., SANDAHL, K., Practical Implications of
Traceability, Software Practice and Experience, v. 26, n. 10, pp.
1161-1180, 1996
LIU, L., LI, T., PENG, F. Why Requirements Engineering Fails: A
Survey Report from China, Requirements Engineering Conference (RE),
2010 18th IEEE International, 2010
MICHAELIS, Dicionrio Michaelis: Moderno dicionrio da lngua
portuguesa, So Paulo, Companhia Melhoramentos, 1998 (Dicionrios
Michaelis)
NUSEIBEH, B., EASTERBROOK, S. Requirements Engineering: A
Roadmap, Proceedings of International Conference on Software
Engineering (ICSE-2000), Limerick, Ireland : ACM Press, 2000
PALUDO, M.A.; BURNETT, R.C.; LOCH, J.M.; REIS, D.
Desenvolvimento de Software Aplicando a Tcnica Joint Application
Design, 2009. Disponvel em:
http://www.pg.utfpr.edu.br/ppgep/Ebook/ARTIGOS/56.pdf. Acessado em
junho de 2010
PARNAS, D. L. Requirements Documentation: Why a Formal Basis is
Essential, Proceedings. 4th International Conference on
Requirements Engineering, 2000, pp. 81-82
POTTS, C. Using Schematic Scenarios to Understand User Needs,
Proc. DIS95 - ACM Symposium on Designing interactive Systems:
Processes, Practices and Techniques, University of Michigan,
1995
PRESSMAN, Roger S. Engenharia de software, 5 edio. MacGraw-Hill,
2002.
RAMESH, B., JARKE, M. Towards Reference Models For Requirements
Traceability, IEEE Transactions in Software Engineering, 27(1),
58-93, 2001
REYNOLDS, T. J., GUTMAN, J. Laddering Theory, Method, Analysis,
and Interpretation, Journal of Advertising Research, Vol. 28, No.
1. pp. 11-31, 1988
ROBERTSON, S. ROBERTSON, J. Mastering the Requirements Process,
Second Edition. Addision Wesley Professional, Maro 17, 2006
SAYO, M., LEITE, J. C. S. P. Rastreabilidade de Requisitos, RITA
Vol. XII N1, 2005
SEI, Software Engineering Institute. CMMI for Development,
Version 1.3 (CMMI-Dev V1.3). Novembro, 2010a. Disponvel em <
http://www.sei.cmu.edu/reports/10tr033.pdf > acessado em janeiro
de 2011
SMITH, S. Systematic Development of Requirements Documentation
for General Purpose Scientific Computing Software, Proceedings of
the 14th IEEE International Requirements Engineering Conference, RE
2006, pages 209-218, Minneapolis/St. Paul, Minnesota, 2006
SOFTEX, Sociedade para Promoo da Excelncia do Software
Brasileiro. MPS.BR - Melhoria de Processo do Software Brasileiro,
V2009, Atualizado em Setembro de 2009, Disponvel em
-
34
http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf,
acessado em junho de 2010
SOMMERVILLE, Ian. Engenharia de software, 8 edio. So Paulo:
Pearson Addison Wesley, 2007.
SPANOUDAKIS, G., Plausible and Adaptive Requirement Traceability
Structures, in Proc. 14th International Conference Software Eng.
and Knowledge Eng, 2002.
SPANOUDAKIS, G., ZISMAN, A., Software Traceability: A Roadmap.
Advances in Software Engineering and Knowdledge Engineering, Vol.
3: Recent Advances,(ed) S.K Chang, World Scientific Publishing,
ISBN:981-256-273-7, Agosto de 2005
STEED, A., MACDONNELL, J. Experiences with repertory grid
analysis for investigating effectiveness of virtual environments.
Proceedings of the 6th International Workshop on Presence, Denmark,
2003
SWEBOK. Guide to the Software Engineering Body of Knowlegment,
IEEE Computer Society, 2004. Disponvel em
http://www.computer.org/portal/web/swebok/htmlformat. Acesso em
outubro de 2009.
TAMAI, T., KAMATA, M. L. Impact of Requirements Quality on
Project Success or Failure, Design Requirements Engineering: A
Ten-Year Perspective, Lecture Notes in Business Information
Processing, 14, 258-275, 2009
VAN AMSTEL, F. Card-sorting melhor que buraco, 2005. Disponvel
em:
http://usabilidoido.com.br/cardsorting_e_melhor_que_buraco.html.
Acessado em julho de 2010
VAN SCHOUWEN, A.J., PARNAS, D.L., and MADEY, J. Documentation of
Requirements for Computer Systems. Proceedings of the Requirements
Engineering Symposium - RE 93, San Diego, CA, 1993, Janeiro 1993,
pp. 198-207.
VLIET, H. V. Software Engineering: Principles and Practice,
Wiley, 2007
WANG, Y., SURE, Y., STEVENS, R., RECTOR, A. Knowledge
Elicitation Plug-in for Protg: Card Sorting and Laddering, Asian
Semantic Web Conference (ASWC'06), Beijing, China, 2006
WIEGERS, K. E. More About Software Requirements: Thorny Issues
and Practical Advice, Microsoft Press, ISBN:0735622671, 2006
YOUNG, R. R. The Requirements Engineering Handbook. Artech
House, 2004
ZHANG, Z; Effective Requirements Development - A Comparison of
Requirements Elicitation techniques, SQM2007 conference, 2007
ZILSE, R. Card sorting no tudo, 2007. Disponvel em:
http://webinsider.uol.com.br/2007/08/29/card-sorting-nao-e-tudo.
Acessado em julho de 2010.
ZOWGHI, D., COULIN, C. Requirements Elicitation: A Survey of
Techniques, Approaches, and Tools. In AURUM, A., WOHLIN, C.
Engineering and Managing Software Requirements, Springer: Germany,
2005, p.19-46.
-
35
