Escolar Documentos
Profissional Documentos
Cultura Documentos
Uma Estratégia para Análise de Requisitos PDF
Uma Estratégia para Análise de Requisitos PDF
Ana Elizabete Souza de Carvalho, Helena Cristina Tavares, Jaelson Brelaz Castro
Centro de Informtica, Univesidade Federal de Pernanbuco
{ana-elizabete.carvalho, helena-cristina.tavares}@serpro.gov.ar, jbc@cin.ufpe.br
1. Introduo
Ultimamente tem havido um grande interesse na comunidade de engenharia de
software na melhoria do processo. As empresas precisam medir a sua capacidade de
desenvolver software com qualidade. Para isto, esto utilizando o modelo CMM
(Capability Maturity Model), que um modelo gerencial que organiza as melhores
prticas existentes, embora os padres e as prticas que so aplicveis no sejam
completamente definidos.
Em geral, o desenvolvimento de software comercial responde rapidamente s
mudanas tecnolgicas [1]. Por isso, importante investir no processo de melhoria
contnua para o aumento da qualidade focalizando a engenharia de requisitos.
Encontram-se algumas tentativas de uso de requisitos nas organizaes mas,
infelizmente, as tentativas comeam pela fase do gerenciamento do ciclo de vida e
rastreabilidade dos requisitos, iniciada por um processo de avaliao de maturidade
do nvel organizacional SEI-CMM [2], sem antes ter o domnio da importante fase de
descobrimento de requisitos, a partir do descobrimento dos fatos e fenmenos do
32
ambiente ou domnio da aplicao [3]. Por isso, importante que a empresa tambm
possua seus processos para o desenvolvimento de requisitos definidos.
Na prxima Seo, descrita a importncia da Qualidade de Software e o contexto
do SERPRO. Na Seo 3, os processos a serem executados para a implantao da
Gerncia de Requisitos que foram definidos pelo SERPRO so descritos. Na Seo 4,
as fases utilizadas para a implantao dos processos para a gerncia de requisitos
definidos so descritas. Na seo 5 feito um mapeamento entre a proposta
apresentada e as prticas do CMM para a Gerncia de Requisitos. Uma descrio
breve do estudo de caso apresentada na Seo 6 e, a Seo 7 composta das
concluses e trabalhos futuros.
33
A primeira ACP do CMM para atingir o Nvel 2 (figura 3) a Gerncia de
Requisitos, a qual estabelece as diretrizes para um comum entendimento entre o
cliente e os requisitos de seu projeto de software, que sero conduzidos pela equipe do
desenvolvimento. Este acordo com o cliente a base para planejar e administrar o
projeto de software. O controle das relaes com o cliente depende de um efetivo
controle do processo da mudana. Mas, para que a Gerncia de Requisitos seja
implantada na organizao necessrio que um processo de Engenharia de Requisitos
esteja implantado.
Como Empresa de Tecnologia da Informao, o SERPRO atua num mercado em
permanente ebulio, por isso iniciou um processo para identificao e implantao
das melhores prticas para elevar o estgio de maturidade do processo de
desenvolvimento de software.
Impulsionando este processo est a meta de atingir o nvel 2 de maturidade
segundo o modelo CMM (Capability Maturity Model) do SEI at o final de 2002. E,
os trabalhos iniciais verificaram que a falta de uma efetiva gerncia de requisitos um
dos principais problemas a serem superados.
Dando incio estruturao interna de uma gerncia de requisitos, o SERPRO
participou do projeto Plataforma Tecnolgica em Engenharia de Requisitos -
Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas [8], o
qual teve como objetivo estabelecer bases para o aumento da qualidade dos processos
de produo de software, por meio da cooperao entre universidades e
empresas, com nfase na utilizao da Engenharia de Requisitos.
A plataforma foi extremamente importante para um melhor conhecimento dos
problemas enfrentados pelas organizaes que participaram do projeto e da
possibilidade da cooperao com as instituies de pesquisa para minorar esses
problemas.
Identificados os problemas, os processos a serem executados para a implantao
da Gerncia de Requisitos foram definidos pelo SERPRO e so descritos na prxima
Seo.
34
Software. Os desvios e as solicitaes de alterao de requisitos so revistos antes de
serem incorporados, seus impactos so avaliados, e os compromissos assumidos so
renegociados com as partes interessadas (stakeholders).
Usar os Requisitos
Rever os Requisitos
para planejar os
antes de serem
Artefatos e
incorporados ao projeto Requisito de Atvidades(At2)
(At1) Software
Requisitos
Validados PDS - Plano de
Desenvolvimento
Baselinede Requisitos: de Software
Contrato Tcnico (Hb2)
Grupo de Eng.
de Software
Novas Baselines
Avaliar impactos e
renegociar
Habilidade Hb
( ) compromissos
35
As figuras 2 e 3 so apresentadas apenas com as entradas e sadas da tcnica
IDEF0. A Tabela 1 descreve as principais entradas e sadas dos processos descritos
anteriormente.
Solicitaa Vis
de Plano de
Defini
Glossri
SAR' Matrize
1
DR Requisito
A
Impactado
Gerenciament Nova
e
DRS
Mtrica
2
A Notificao para
reas
SAR'
Valida
Casos de
Notificao para
4 reas
SAR'
Verifica
Atas de
Artefato
3 Notificao para
A reas
36
ENTRADA TIPO DESCRIO
OU SADA
Solicitao entrada Refere-se ao documento formal por meio do qual o sistema
de Servio solicitado pelo cliente.
SAR (Solici- entrada Documento que deve ser preenchido quando h necessidade de
tao de alterao ou incluso de requisitos. Especifica e documenta a
Alterao de alterao de requisitos solicitada pelo stakeholder, estabelecendo as
Requisitos) bases para sua execuo, e condies de execuo (prioridades,
recursos envolvidos, recursos afetados, etc).
Viso sada Referem-se a informaes gerais sobre o sistema. Documento onde
fornecido o objetivo do sistema a ser desenvolvido; suas principais
caractersticas, funcionalidades e no-funcionalidades; os
stakeholders. Seu objetivo apresentar o sistema em linhas gerais,
fornecendo uma viso inicial. Documenta o ambiente geral de
processos a ser desen-volvido, fornecendo a todos os envolvidos uma
descrio compreensvel do sistema e suas macro-funcionalidades. O
objetivo do documento Viso definir as necessidades de alto-nvel e
caractersticas do sistema, focando nas potencialidades requeridas
pelos stakeholders e como estes requisitos sero abordados no
sistema.
Glossrio entrada O objetivo do glossrio fornecer uma terminologia comum sobre o
e sada projeto a todos os envolvidos. Este conjunto de termos e conceitos
originais usado para definir um mapeamento especfico sobre o
domnio do problema, explicando os itens mais relevantes 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.
Rastreabilida entrada Neste contexto, as Matrizes de Rastreabilidade mostram os
de e sada relacionamentos entre os requisitos elicitados.
DRS (Docu- entrada composto pelo detalhamento dos requisitos. A DRS guarda a
mento de e sada especificao dos requisitos de software, descritos num nvel de
Requisitos detalhe que possibilite o entendimento de todos os envolvidos. A DRS
de serve como base de comunicao entre os stakeholders, e ajuda a
Software) manter um foco integrado no desenvolvimento.
Requisitos sada Referem-se aos requisitos que sero alterados em decorrncia da
Impactados incluso ou alterao de requisitos.
Nova sada Baseline ou configurao base um conjunto de requisitos aprovados
Baseline e revisados que representa o embasamento de um acordo de
evoluo e desenvolvimento; atualizada por meio da incluso ou
alterao de requisitos.
DRS sada Corresponde ao Documento de Requisitos de Software alterado em
atualizado funo da incluso ou alterao de requisitos.
Notificao sada Refere-se comunicao a todos os que sero impactados pela
as reas incluso ou alterao de requisitos.
envolvidas
Mtricas sada Informaes coletadas ao longo do gerenciamento de requisitos.
Casos de sada Devem estar includos no DRS (Documento de Requisitos de
Testes Software).
Atas de sada Ser utilizada a Ata de Reunio para registrar as no-conformidades.
Verificao
Plano de sada Ser utilizado a Ata de Reunio para registrar os compromissos de
Reviso reviso.
Solicitao DRS
Elicitao Documentao Negociao
DRS
de Sistemas dos & Anlise &
Requisitos de Priorizao
SAR's
Software
1 2 3
Plano de Reviso
A11 A12 A1
Viso Matrize 3
s
(Acompanhamento
e rastreabilidade)
38
escutar suas respostas [15]. So teis quando stakeholders
possuem muitos conhecimentos subjetivos e esto dispostos a
serem entrevistados. Para ser mais eficiente, o entrevistador
deve ser experiente.
o Tcnicas de elicitao de grupo so tcnicas de dinmica de grupo
com o objetivo de entender de forma mais detalhada as
necessidades dos usurios, esto includas: brainstorming, sesses
JAD e RAD [16];
Brainstorming: stakeholders so reunidos em um local, num
ambiente que encoraje a participao, permitindo que todas as
idias sejam declaradas em voz alta (para que os demais
sejam influenciados) e escritas (para que no sejam perdidas)
[17]. mais eficaz quando cada stakeholder possui uma parte
do conhecimento de algum aspecto do problema.
o Prototipao implementao parcial de um sistema de forma
rpida para obter feedback para o processo de requisitos. O
prottipo descartado. utilizada para elicitar requisitos quando h
um alto grau de incerteza ou quando necessrio um rpido
feedback dos usurios;
o Tcnicas de modelagem fornece um modelo especfico das
informaes que sero adquiridas, e usa esse 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 desejam executar [18]. Inclui
mtodos baseados em metas, tais como: KAOS [19] e I* [20] e
mtodos baseados em cenrios como CREWS [21].
o Tcnicas cognitivas inclui uma srie de tcnicas originalmente
desenvolvidas para aquisio de conhecimento para sistemas
baseados em conhecimento, alguns exemplos so: Anlise de
protocolo, laddering, card sorting, repertory grids [22];
o Tcnicas contextuais surgiu como uma alternativa para as tcnicas
tradicionais e cognitivas, inclui tcnicas de etnografia e anlise
social [23];
o Etnografia: observar potenciais usurios em seu ambiente natural.
Resulta em uma percepo mais precisa do problema do que
perguntar aos usurios o que eles fazem [24]. So teis para suporte
automao de uma funo pouco ou no automatizada,
particularmente quando so disponveis a observadores treinados
sem noes preconcebidas do problema e de sua soluo.
39
documentos. Um cuidado, porm, deve ser tomado para a tendncia da no
utilizao dos processos para alterao de requisitos.
Incio
. .
Escolher e executar Identificar os Entender o domnio
Tcnicas de Elicitao stakeholders da aplicao
.
C2 .
Elaborar a lista de
Requisitos Candidatos
Fim
40
Descrever os requisitos e os seus atributos: depois que os requisitos do
sistema so elicitados, eles devem ser documentados com um nvel
apropriado de detalhes. Na maior parte das organizaes os requisitos so
escritos em linguagem natural, pois uma notao que de fcil
entendimento para uma grande variedade de stakeholders. Entretanto, o nvel
de abstrao dos requisitos varia de acordo com a organizao e deve ser
definido de acordo com o projeto ou at mesmo com o tipo de requisito. O
principal foco da pesquisa em documentao de requisitos prover notaes
e linguagens de especificao. Desde linguagem natural [26] lgica [27],
diferentes linguagens tm sido propostas para expressar e descrever
requisitos. Pesquisas atuais tm reconhecido que o gerenciamento de
requisitos uma atividade crucial no processo de engenharia de requisitos,
ou seja, necessrio no somente escrever os requisitos de forma entendvel
mas tambm permitir que eles possam ser rastreados e gerenciados ao longo
da evoluo do sistema [28].
Incio
C2
Classificar os Requisitos
C3
FIm
In c io
E s co lh e r a T c n ic a d e
N e g o c ia o
D e fin ir o s m ile s to n e s e o s
p o n to s d e re v is o
A tu a liz a r o D R S
F im
43
por formulrio padronizado ou por meio de sistema de solicitao de
demandas.
Registrar novos requisitos: Os novos requisitos tambm devem ser recebidos
formalmente ou por formulrio padronizado ou por meio de sistema de
solicitao de demandas.
Verificar requisitos relacionados: uma vez preenchidas as matrizes de
rastreabilidade, de forma que tenham sido estabelecidos relacionamentos de
rastreamento entre os requisitos, necessrio verificar os requisitos
relacionados para que seja avaliado o impacto desta incluso ou alterao
posteriormente.
Incio
C1
Avaliar Impacto
C3
Coletar Mtricas
Fim
44
volatilidade dos requisitos. A equipe de gerncia de requisitos deve definir
quais mtricas sero utilizadas no projeto, de acordo com suas caractersticas
peculiares.
Durante processo de Validao (figura 10) as seguintes atividades so executadas:
Usar Checklist de Validao: checklists estruturam o processo de validao
de forma que aspectos importantes no sejam esquecidos. Embora sejam
semelhantes aos checklists de anlise, os checklists de validao devem
focalizar aspectos de qualidade do documento de requisito como um todo,
bem como os relacionamentos entre os requisitos. Algumas questes podem
ser relacionadas para checar se algum requisito est ausente; 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.
Definir os casos de teste dos requisitos: definir um ou mais casos de testes
que posteriormente permitam verificar se o sistema satisfaz o requisito, alm
de uma forma de validar os requisitos, pode servir como base para os testes
finais do sistema. Ao escrever o caso de teste, o requisito estar sendo escrito
de um ngulo diferente. Cada caso de teste deve possuir, no mnimo, um
identificador, os requisitos 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 possam ser feitos
automaticamente.
Incio
C1
C2
Final
Incio
Verificar os Requisitos
Avaliar os Desvios
Final
46
4. As Fases para Implantao
47
organizao podem ser definidos subgrupos de trabalho, onde o coordenador
deve ser um membro do GT-Requisitos. O grupo de trabalho GT-Pessoas-
chave deve ser composto por pessoas que detm o conhecimento de como
o processo de desenvolvimento e manuteno de software na empresa.
Devem ser entrevistadas e treinadas primeiro de acordo com a necessidade e
a disponibilidade. Este grupo pode mudar medida que aumenta a
compreenso dos processos de software. importante que nesta fase esteja
circulando na empresa informaes a respeito do trabalho sendo
desenvolvido, o que pode ser feito por meio de jornais internos, circulares, e-
mail ou circulao de revistas e livros que tratem sobre o tema. Pode-se
tambm disponibilizar informaes na Intranet da empresa.
Fase 8 - Implantao
Fase 1 - Conscientizao
48
Fase 4 - Levantamento de Processos Engenharia de Requisitos existentes: o
primeiro passo para a melhoria o conhecimento de como est o seu
processo de desenvolvimento. Uma empresa pode ter vrias maneiras de
executar uma mesma tarefa como desenvolver e manter software.
importante que o GT-Requisitos tome conhecimento de todos os processos
de Engenharia de Requisitos existentes na empresa. Este conhecimento
dever ser provido por reunies, entrevistas e coletas de documentos com o
GT-Pessoas-chave. Deve-se avaliar as polticas, padres e processos atuais
de Engenharia de Requisitos existentes na organizao, identificando os
pontos fortes e fracos.
Fase 5 - Elaborao do Plano de Melhoria: o Plano de Melhoria do
Processo de Engenharia de Requisitos a base para o futuro esforo de
melhoria e deve estar de acordo com o cronograma definido anteriormente.
O GT-Requisitos deve preparar o Plano de Melhoria contendo os processos
e documentos existentes de modo que fique claro os pontos em que h
necessidade de melhoria e o impacto benfico que pode causar ao processo.
Pode recomendar aes para solucionar as carncias identificadas e at
estimar o tempo e recursos necessrios para cada atividade de melhoria.
Fase 6 - Definio dos Processos: a definio dos Processos a serem
implantados deve ser elaborada tendo como base com as boas prticas
existentes na empresa, o Plano de Melhoria definido, o tipo, as restries e a
cultura da organizao. So importantes pesquisas em bibliografia existente,
instituies de pesquisa e, se possvel, a utilizao de benchmarking.
Fase 7 - Definio de Papis e Responsabilidades: nesta fase devem ser
especificados os papis e as responsabilidades das pessoas que executaro as
atividades de desenvolvimento e gerenciamento de requisitos. Deve-se
definir um mapeamento para as funes existentes na Empresa.
Fase 8 - Implantao: a fase de Implantao deve possuir o planejamento e
a execuo, inicialmente para o projeto-piloto e posteriormente, para os
demais projetos. Para iniciar a implantao importante que o GT-
Requisitos defina um Plano para Projeto-piloto, onde seja especificado o
projeto escolhido, as pessoas envolvidas, os treinamentos necessrios, alm
os prazos esperados. A implantao do projeto-piloto deve ser acompanhada
pelo GT-Requisitos e as dificuldades encontradas devem ser documentadas
para posterior anlise e avaliao dos Processos definidos.
Fase 9 Acompanhamento e Ajustes: esta fase deve acompanhar a aplicao
das prticas de Gerncia de Requisitos implantadas, avaliando-as e
promovendo os refinamentos necessrios. Nesta fase, devero ser executadas
aes para atender a prtica de Verificao definida pelo CMM para a
Gerncia de Requisitos.
5. Estratgia x CMM
A tabela 2 descreve as prticas-chave para Gerncia de Requisitos do CMM
relacionando em que parte desta proposta as principais aes a serem executadas so
definidas.
49
Prticas do CMM Estratgia
O projeto segue uma poltica organizacional
Co 1 Fase 6 - Definio dos Processos
para gerenciar os requisitos de software.
Para cada projeto, est estabelecida a
responsabilidade para analisar os requisitos
Fase 7 - Definio de Papis e
Hb 1 de sistema e aloc-los ao hardware,
Responsabilidades
software ou outros componentes do
sistema.
Os requisitos de software esto
2 Processo de Definio
documentados
Fase 1 - Conscientizao
Esto disponveis os recursos e fundos
Fase 2 - Preparao
3 necessrios para gerenciar os requisitos de
Processo de Definio
software. Processo de Elicitao de Requisitos
Os membros do grupo de engenharia de
software e de outros grupos relacionados a
4 Fase 3 - Treinamento
software esto treinados para realizar suas
atividades de gerncia de requisitos.
Processo de Gerenciamento & Mtricas
O grupo de engenharia de software revisa Processo de Documentao & Anlise
At 1 os requisitos de software, antes de serem Processo de Negociao & Priorizao
incorporados ao projeto. Processo de Validao
Processo de Verificao
O grupo de engenharia de software utiliza
os requisitos de software como base para
2 confeccionar os planos de Processo de Verificao
desenvolvimento do software, desenvolver
produtos de trabalho e realizar atividades.
Revisar as alteraes nos requisitos de
3 software e incorpor-las ao projeto de Processo de Gerenciamento & Mtricas
software.
A gerncia snior revisa, periodicamente,
Ve 1 todas as atividades de gerncia dos Fase 9 - Acompanhamento e Ajustes
requisitos de software.
O gerente de projeto revisa periodicamente
2 ou por evento, todas as atividades de Fase 9 - Acompanhamento e Ajustes
gerncia dos requisitos de software.
O grupo de garantia de qualidade de
software revisa e/ou audita as atividades e
3 produtos de trabalho utilizados para Processo de Validao
gerenciar os requisitos de software,
reportando seus resultados.
Bibliografia
52
[2] SEI-Software Engineering Institute, "Capability Model for Software", 1a ed. USA:
Carnegie Mellon University, Pittsburgh, Pennsylvania, 1997.
[6] Paulk M. C. et all., "The Capability Maturity Model", version 1.1 (CMU/SEI-93-TR-
24), Software Engineering Institute, Carnegie Mellon University, Pittsburgh,
PA(USA),1993.
[7] Fiorini, S. T., Staa A., Baptista R. M. ,"Engenharia de Software com CMM", Brasport,
1998.
[8] Leite, J., Castro, J., Pinheiro, F.,"Plataforma Tecnolgica em Engenharia de Requisitos
Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas",
http://www.cic.unb.br/~facp/per/perhome.html
[9] Booch, G., Rumbaugh, J E, Jacobson, I., "The Unified Modeling Language User
Guide", Addison Wesley, 1999.
[10] Booch, G., "Object Oriented Design with Applications", The Benjamin/Cumming
Publishing Company, Inc., Redwood City, 1991.
[11] Gil, G., Figueroa, D., Oliveros, A., "Produccin Del LEL em um Dominio Tcnico.
Informe de um caso", III Workshop de Engenharia de Requisitos. Rio de Janeiro-
Brasil, 2000.
[20] Yu, E., "Modeling Strategic Relationship for Process Reengineering", PhD thesis,
Computer Science Department, University of Toronto, Toronto, Canada, 1995.
53
[21] Maiden, N., "CREWS-SAVRE: Scenarios for Acquiring and Validating
Requirements", Automated Software Engineering, 1998.
[22] Shaw, M. E, Gaines, B., "Requirements Acquisition", Software Engineering Journal,
vol 11, 1995.
[23] Viller, S. E., Sommerville, I., "Social Analysis in the Requirements Engineering
Process: from ethnography to method", 4th International Symposium on Requirements
Engineering, Limerick, Ireland, Jun, 1999.
[25] Davis, A. M., "Achieving Quality in Software Requirements" SQP 1, NO. 3. 1999.
[26] Ambriola, V. E., Gervasi, V., "Processing Natural Language Requirements", 12th
International Conference on Automated Software Engineering. Lake Tahoe, EUA.
Nov. 1997.
[28] Gotel, O. E., Finkelnstein, A., "An Analysis of the Requirements Traceability
Problem", 1st International Conference on Requirements Engineering, Colorado
Springs, EUA. Apr. 1994.
[29] Wiegers K. E. ,"When Telepathy Won't Do: Requirements Engineering Key Practices",
Cutter IT Journal, May, 2000.
[31] Karlsson, K. E., Ryan, K., "Software Requirements Prioritizing", 2nd International
Conference on Requirements Engineering. Apr. 1996. pp. 110 116.
[32] Saaty, T., "The Analytic Hierarchy Process", New York: McGraw-Hill, 1990.
[33] Hauser, J. E., Clausing, D., "The House of Quality", The Harvard Business Review, vol
3. 1988.
[35] Codd, E. F., Codd, F. B., Salley, C. T., "Providing OLAP (Online Analytical
Processing) to User Analyst: an IT Mandate", Arbor Software White Paper,
http://www.arborsoft.com/OLAP.htm, 1993.
[36] Carvalho, A. E., "Uma Estratgia para Implantao de uma Gerncia de Requisitos
visando a Melhoria dos Processos de Software", Dissertao de Mestrado, UFPE,
Brasil, 2001.
54