Um Estudo sobre a Atividade de Elicitao de Requisitos em Projetos de

Software da rea Espacial

Carlos Lahoz
1, 2
e Joo Batista Camargo Jr.
2

1
Instituto de Aeronutica e Espao, Praa Mal. Eduardo Gomes, 50,
12228-904 So Jos dos Campos, Brasil
lahoz@iae.cta.br
2
Escola Politcnica da Universidade de So Paulo, Av. Prof. Luciano Gualberto, 158
05508-900 So Paulo, Brasil
joao.camargo@poli.usp.br



Resumo

Dentro do enfoque de que o software comea a
atender cada vez mais um nmero crescente de
funcionalidades de sistemas, fundamental que a
atividade de elicitao de requisitos assuma um papel
decisivo no esforo de se alcanar um resultado
satisfatrio e seguro no projeto de um sistema. No que
diz respeito a sistemas aeroespaciais crticos, onde a
ambigidade, a no completeza e a falta de requisitos
podem provocar acidentes graves, envolvendo
prejuzos econmicos, materiais e humanos, obriga a
um tratamento mais cuidadoso sobre este assunto. Este
artigo apresenta os resultados preliminares de um
estudo sobre quais so os principais problemas que a
atividade de elicitao de requisitos enfrenta
atualmente em projetos espaciais no Brasil, segundo a
viso dos autores. O foco principal do trabalho est na
identificao dos requisitos de segurana em projetos
de desenvolvimento de software.

1. Introduo

Segundo Kotonya e Sommerville [8] o termo
engenharia de requisitos foi criado para cobrir todas as
atividades envolvidas na descoberta, documentao, e
manuteno de um conjunto de requisitos para um
sistema baseado em computador. Para Laplante [10], a
disciplina de engenharia de requisitos de software
compete determinao dos objetivos, funes, e
restries de um sistema de software e a representao
dos seus aspectos de forma acessvel para modelagem e
anlise. Obviamente que esta disciplina tem tambm
como objetivo identificar requisitos que sejam corretos,
completos e entendveis para clientes e
desenvolvedores. Pode-se dizer ento, que o termo
engenharia de requisitos, abrange tanto os assuntos
relativos anlise e especificao de sistemas de
informao (negcios) como o de anlise e
especificao de sistemas de engenharia. Sistemas
espaciais so classificados em sistemas de engenharia,
onde os requisitos envolvem hardware, software,
procedimentos operacionais e processos: os chamados
sistemas embarcados e sistemas de comando e controle
[10].

O processo de engenharia de requisitos, ou seu nvel
de detalhamento, pode variar de uma organizao para
outra. Uma organizao de desenvolvimento de
projetos de software da rea espacial pode no usar os
mesmos processos de uma organizao de tecnologia da
informao. Mas de modo geral o processo de
engenharia de requisitos, em qualquer tipo de sistema,
abrange as atividades de elicitao, anlise,
documentao, validao e gerenciamento de requisitos.

O foco desta pesquisa est na atividade de elicitao
de requisitos, que conforme proposto por Kotonya e
Sommerville [8] e Sawyer e Kotonya [19], o nome
usual dado s atividades envolvidas na descoberta dos
requisitos de um sistema. Para a realizao desta
atividade so utilizadas tcnicas como, por exemplo,
entrevistas, observao, anlise de cenrios,
prototipao. Seu principal objetivo extrair
informaes sobre o problema a ser resolvido, o servio
que o sistema proposto deve disponibilizar, os
requisitos de desempenho, as restries de hardware,
entre outros.

Quando falamos de elicitao de requisitos e,
especificamente de requisitos de segurana,
primeiramente pensamos sobre requisitos funcionais
que apresentam ramificaes de segurana crtica [2].
Enquanto normalmente os requisitos especificam o que
o sistema deve fazer ou espera-se que faa, os requisitos
de segurana especificam o que o sistema no deve
fazer, ou deve se prevenir para que acontea [16]. Em
sistemas onde a questo da segurana crtica,
requisitos funcionais so tanto aqueles que podem
causar acidentes se no forem implementados ou se o
forem incorretamente. J os requisitos no funcionais
so aqueles que no so especificamente requeridos

como funcionalidades do sistema. Eles apresentam
restries ao produto a ser construdo e ao processo de
seu desenvolvimento, e suas especificaes de restrio
externa ao qual o produto deve atender [10].

Este trabalho introduz primeiramente alguns estudos
e relatrios sobre problemas envolvendo software e
requisitos em organizaes da rea espacial, como o do
acidente com o foguete Ariane 5, da agncia espacial
francesa e o estudo do acidente que ocorreu com a
sonda Mars Climate Orbiter (MCO), da agncia
espacial americana. Em seguida apresentado, sob o
ponto de vista dos autores, quais so os principais
obstculos que as atividades da engenharia de requisitos
enfrentam nesta rea, especificamente na atividade de
elicitao. Depois, so feitos comentrios sobre os
envolvidos no processo de elicitao de requisitos
dentro deste contexto. Tambm apresentada uma
primeira forma de abordar o problema de segurana
atravs de uma classificao dos requisitos. Estudos
futuros sobre possveis formas de abordar a atividades
de elicitao de requisitos e segurana so apresentados
em seguida. Finalmente, algumas consideraes sobre
como superar obstculos, segundo a estratgia dos
autores, mostrado.

2. Requisitos e Projetos Espaciais

Existe atualmente, na literatura tcnica
especializada, um farto material tratando sobre as
disciplinas da engenharia de software e seus problemas
de projeto. Na rea espacial trabalhos recentes se
destacam sobre este tipo de estudo: as investigaes da
professora do Departamento de Aeronutica e
Astronutica e de Engenharia de Sistemas do
Massachusetts Institute of Technology (MIT), Nancy
Leveson, bem como o relato do pesquisador Kjeld
Hjortnaes, do European Space and Technology Centre
(ESTEC), e chefe do On-board Software Systems
Section (TOS-SEM). Tanto nas investigaes de
acidentes espaciais envolvendo software, bem como a
anlise de Hjortnaes de mais de 18 revises tcnicas
dos projetos de desenvolvimento de software da
European Space Agency (ESA), foram levantadas
questes de problemas envolvendo requisitos,
engenharia de sistemas e de software.

De um modo geral, foram observados nestes
estudos, dentre outros problemas, prticas inadequadas
de especificaes de requisitos ou um conhecimento
insuficiente do sistema, levando a um entendimento
pobre sobre seu contexto e seus requisitos operacionais.

No relatrio da investigao do acidente do foguete
Ariane 501 [12], estudado por Leveson, foi apontado
prticas pobres de especificao de requisitos. No da
investigao do acidente da nave Mars Climate Orbiter
(MCO) e da Mars Polar Lander (MPL) [14] [15]
recomendou-se treinamento mais adequado das equipes
de desenvolvimento devido a problemas na
especificao dos requisitos do sistema. Hjortnaes
observa, na sua anlise dos projetos da ESA, uma falta
de maturidade e estabilidade da baseline de requisitos
de software quando o processo de desenvolvimento se
inicia. Ele cita ainda que, em muitos dos relatrios
analisados, o desenvolvimento dos requisitos no foi
conduzido de forma adequada ou no existia um
entendimento correto dos mesmos. Ambos autores so
unnimes em dizer que a Engenharia de Software deve
ter uma participao mais efetiva no time de Engenharia
de Sistemas.

Um ponto importante que deve ser salientado em
projetos desta natureza a questo da segurana. No
caso especfico do acidente do terceiro prottipo do
Veculo Lanador de Satlites (VLS-1 V03) [20], um
estudo independente proposto por Almeida e Johnson
[1] refora que no relatrio oficial da investigao
citado a pouca ateno ao desenvolvimento de uma
cultura de segurana apropriada ao projeto. Faltaram
revises, auditorias externas e validao por
especialistas de avaliao de risco durante o
desenvolvimento do projeto. Almeida e Johnson
argumentam ainda que em algumas reas do programa
espacial brasileiro no h o reconhecimento da
importncia do gerenciamento de segurana de
sistemas, como recomendado nas indstrias da rea de
espao da Amrica do Norte e Europa.

Levando em considerao estes estudos, observou-se
que em diversos projetos, mesmo de agncias espaciais
com um alto nvel de maturidade em termos de
profissionais e infra-estrutura, existem ainda diversos
problemas de ordem operacional (processos), tcnica
(tecnologia) e humana (pessoas) [9]. Seguindo esta
abordagem, sob o ponto de vista de tecnologia,
processos e pessoas, possvel mapear as principais
barreiras enfrentadas no levantamento de requisitos em
projetos espaciais, e em seguida buscar os caminhos
para superar estes obstculos.

3. Tecnologia, Processos e Pessoas

Na viso de tecnologia observado o uso
inadequado, ou mesmo inexistente de uma tcnica de
elicitao e de representao de requisitos. Tcnicas
como entrevista, prototipao ou mesmo o estudo de
documentao, muitas vezes so mal empregadas,
apresentando resultados no muito confiveis.

Tambm, o uso inapropriado de modelos de
representao dos componentes do sistema e suas
interaes podem no destacar adequadamente as
dependncias comportamentais advindas da
especificao destes componentes, gerando problemas
que podem ser descobertos (quando descobertos)
somente em fases muito avanadas do desenvolvimento
de um sistema. Caso tpico de perdas financeiras, de

atraso no cronograma de projeto e perda total do crdito
da equipe.

A falta de uma abordagem sistmica de segurana
em sistemas de software, principalmente em ambientes
de pouca maturidade em cultura de segurana, pode no
ser percebido em um primeiro momento nas atividades
de elicitao, mas fatalmente afetar os estgios mais
avanados do desenvolvimento, ou, pior ainda, somente
quando o sistema estiver em operao.

A falta ou o uso inapropriado de ferramentas de
engenharia de software e de engenharia de requisitos,
como disponvel em ferramentas CASE, nos
verificadores de modelos e em outros recursos de apoio
identificao, representao e consistncia de
requisitos, geram erros e mal entendidos em projeto que
conduzem a ignorncia, desconfiana, constrangimento
e at descrdito da equipe e do projeto.

Na viso de processo, a indefinio ou pobreza de
modelos de processo, assim como uma abordagem
precria de segurana, est fortemente relacionada a
pouca maturidade da equipe e da organizao ao qual
pertence. Muitas vezes, por razes externas ao projeto,
como pessoal sem a qualificao necessria, estrutura
organizacional ineficiente ou mesmo presses de tempo
e de recursos, as atividades do processo de elicitao de
requisitos so menosprezadas em detrimento de outras
atividades, como por exemplo, as relacionadas
diretamente ao desenvolvimento de cdigo.

Mesmo com um processo de elicitao estabelecido,
sem um monitoramento ou seu uso de forma parcial,
no possibilitar o acompanhamento das alteraes
surgidas durante a vida de um requisito desde sua fase
de elicitao e ao longo do ciclo de vida do
desenvolvimento do sistema.

Outro obstculo presente em projetos, no s da rea
espacial, a comunicao inadequada entre os
envolvidos. Sem o auxilio de algum tipo de mecanismo
ou de uma ferramenta automatizada, o processo de
comunicao ser ineficiente, no permitindo que
durante a fase de elicitao, os requisitos extrados
pelos envolvidos sejam avaliados de forma abrangente,
de maneira a permanecerem estveis durante a vida do
projeto.

Na viso de pessoas, diferentes enfoques de ordem
cultural entre os participantes, sejam engenheiros de
sistema como de software, podem criar um obstculo
quase intransponvel. Software uma disciplina
relativamente nova, segundo a viso dos engenheiros de
sistema, e muitas vezes, a participao da equipe de
software nas atividades de elicitao dos requisitos de
sistema, no so consideradas to importantes.

Outro ponto crtico o entendimento limitado do
domnio do problema, que aliado a uma viso parcial
dos envolvidos, prejudica qualquer tcnica de
elicitao. Sem o entendimento claro e preciso do
domnio do problema, difcil interagir com os
participantes e ser capaz de ir alm da viso particular
de como cada um enxerga o sistema.

Ainda mais grave um gerenciamento de projeto
que no considera a importncia das atividades de
elicitao. A gerncia de um projeto tem que equilibrar
os interesses dos participantes no processo de
elicitao, definir as prioridades dos usurios e
promover o consenso entre os envolvidos. Sem este
equilbrio, foras antagnicas de interesse
aparentemente comuns, podem gerar, como uma
conseqncia extrema, a morte lenta e gradual de um
projeto.

4. Envolvidos no Processo

Segundo Gonzles [5] existem basicamente duas
comunidades que estabeleceram mtodos para capturar,
especificar e gerenciar requisitos: a engenharia de
sistemas e a engenharia de software. Apesar de
abordagens tcnicas e culturais diferentes, estas
comunidades possuem muitos elementos em comum e
podem aprender uma com a outra. Tambm no se pode
excluir do processo de elicitao de requisitos de
sistemas espaciais outros envolvidos que representam
papis importantes: o prprio cliente, o engenheiro de
segurana, o gerente de projeto e o usurio do sistema.

Cliente: quem define o sistema no seu nvel mais
abrangente. Geralmente em projetos espaciais so
representados pelas agncias governamentais ou pelos
dirigentes de alto nvel de um programa desta natureza.
O papel desempenhado pelo cliente de observar o
sistema dentro de um contexto estratgico-poltico
diferente do observado pelos outros envolvidos e pode
no ter muita influencia nos rumos tomados por um
projeto no seu nvel mais prtico de desenvolvimento e
acompanhamento.

Engenheiro de Sistema: representa o papel de quem
promove o consenso entre as pessoas envolvidas no
sistema e desenvolve um entendimento mais global da
soluo do problema. avesso aos riscos de projeto.
Usa linguagem natural para prospectar solues e
procura balancear os mtodos de engenharia e
gerenciamento para alcanar seus objetivos. Entende a
disciplina de requisitos como necessria, mas carece de
uma viso metodolgica da disciplina.

Engenheiro de Requisitos: neste caso especfico, ele
oriundo do time de engenharia de software e quem
modela o problema atravs de um conjunto de
formalismos e geralmente imagina o software como
todo o sistema. Faz especificao e aplica mtodos que

produziro resultado independente das pessoas
envolvidas. Apesar de possuir uma abordagem mais
metdica da disciplina de requisitos, ainda falta uma
viso mais abrangente do contexto do sistema e do
software como um todo. Pode, muitas vezes, nem
existir seu papel em uma organizao, sendo assumido
por algum outro tipo de engenheiro.

Engenheiro de Software: toda a equipe de projeto de
software envolvida com os requisitos, como
modeladores, programadores, testadores, equipe da
qualidade, etc. Possuem papel importante na
manipulao dos requisitos, podendo em muitos casos,
devido a uma interpretao errnea ou parcial de sua
funcionalidade, comprometer todo o projeto.

Engenheiro de Segurana: o papel do engenheiro de
segurana, tanto na engenharia de sistemas como na de
software, ou no existe ou recurso raro no mercado.
Este profissional geralmente tem (alguma) experincia
com implementao de polticas de segurana, com
adoo e documentao de padres, monitorao dos
procedimentos de segurana, anlise de risco, de
segurana e investigao de acidentes. Pode no ter um
bom conhecimento do hardware e do software utilizado
em um projeto, e nem fora suficiente para influenciar
nos rumos tomados pelo gerenciamento do projeto.

Gerente de Projeto: possui viso mais pragmtica de
um projeto, voltando sua preocupao muitas vezes
somente para o gerenciamento dos recursos e do tempo.
Sofre vrios tipos de presses durante suas atividades,
desde a exercida pelo alto escalo da organizao at a
do pessoal de desenvolvimento e produo. levado
muitas vezes a adotar medidas impopulares e de
impacto apenas imediato no projeto.

Usurio do sistema: so os clientes diretos do
sistema, cujo papel pode ser exercido por diversos
atores, como operadores (tcnicos e engenheiros),
equipe de software, e outros participantes que tambm
so os interessados pelos requisitos do projeto.
Interagem diretamente com os produtos espaciais e tem
a percepo das caractersticas ambientais, funcionais e
no funcionais dos requisitos. So capazes de
identificar problemas e apresentar solues com uma
rapidez muito maior que os projetistas, podendo adotar
posturas contraditrias para com a utilizao do
sistema. So muitas vezes os responsveis por criar e
validar os requisitos de um sistema e so capazes de
comprometer a integridade do sistema ou de sua
operao.

5. Requisitos e Segurana

Uma forma de solucionar a falta de uma abordagem
sistmica de segurana em sistemas de software,
obstculo relacionado viso de tecnologia,
apresentado anteriormente, pode ser atravs da adoo
de uma abordagem disciplinada de segurana dentro da
atividade de elicitao. desejvel que, nesta fase,
sejam realizadas atividades de extrao de requisitos e
anlise de segurana de forma concorrente e
complementar.

Segundo Kotonya e Sommerville [8], o processo de
requisitos pode ser estendido para incorporar uma
anlise de segurana, cujo resultado ser usado para
alterar (quando necessrio) os requisitos sugeridos para
o sistema. Isto significa integrar as duas atividades,
anlise de requisitos e anlise de segurana de forma
iterativa, refinando os requisitos em cada ciclo.

No caso especfico da atividade de elicitao de
requisitos, a extrao dos requisitos normais consiste na
identificao das entidades relevantes , seu
comportamento, especificao de entradas e sadas,
restries e interaes com outras entidades. J no caso
particular da extrao de requisitos de segurana, deve-
se avaliar em todos os requisitos extrados, potenciais
perigos e riscos, e se preocupar com que a especificao
no viole o comportamento seguro do sistema:
considerando que requisitos normalmente especificam o
que o sistema deve fazer ou espera que acontea.

Acredita-se que uma maneira de extrair
objetivamente requisitos de segurana primeiramente
classific-los atravs de fatores. A proposta tratar o
assunto segurana de uma maneira mais ampla, como o
enfoque do conceito de confiana no funcionamento, ou
dependabilidade (dependability) [11] [22].

Seguindo a classificao de Firesmith [4],
dependabilidade, o grau com que os vrios tipos de
usurios, podem depender de um produto de trabalho.
O autor classifica dependabilidade nos seguintes
subfatores: disponibilidade operacional (operational
availability), confiabilidade (reliability), robusteza
(robustness) e defensabilidade (defensibility).

Disponibilidade Operacional: o grau com que o
produto do trabalho est operacional e disponvel para
uso num determinado instante de tempo.

Confiabilidade: o grau com que o produto do
trabalho opera sem falha sob dadas condies normais,
durante um certo perodo de tempo.

Robusteza: o grau com que um produto do trabalho
executvel continue a funcionar apropriadamente sob
uma dada condio ou circunstncia anormal.

Defensabilidade: o grau com que o sistema ou
componente se defende de acidentes e ataques.
classificada em Segurana contra falhas acidentais
(Safety), Segurana contra falhas maliciosas/
intencionais (Security) e Capacidade de sobrevivncia
(Survivability).


Segurana contra falhas acidentais inclui preveno
de acidentes contra danos a sade, propriedade e
ambiente. Segurana contra falhas maliciosas/
intencionais inclui preveno contra danos maliciosos e
intencionais. Capacidade de sobrevivncia: inclui
prover servios essenciais de misso crtica a despeito
de danos maliciosos ou acidentais.

Segundo De Lemos [2] os requisitos devem
demonstrar uma consistncia entre as restries de
segurana do software e sua especificao, bem como
sua completeza com respeito s propriedades de
segurana. Isto significa que a tcnica de extrao deve
ser capaz de produzir requisitos que mantenham o
comportamento seguro do sistema em operao na
presena de qualquer evento, condio ou
circunstncia. Neste sentido, aps classificar os
requisitos de um sistema dentro de (sub) fatores, alguns
critrios podem (e devem) ser utilizados para auxiliar
no detalhamento de cada requisito. Uma lista de
critrios (checklist), independentemente de uma tcnica
especifica de elicitao, ser capaz de ajudar na
investigao das caractersticas e da natureza de cada
requisito previamente extrado, de modo a produzir
especificaes mais completas, consistentes e
confiveis, principalmente com relao segurana.
Deve-se levar em considerao, por exemplo, estados,
eventos, entradas e sadas, e a relao entre os disparos
destes eventos e suas sadas.

6. Estudos futuros

So apresentadas nesta seo algumas abordagens e
tcnicas, que fazem uso tanto da engenharia de
requisitos como da engenharia de projeto e que podem
vir a auxiliar na soluo dos problemas apresentados. A
idia aplicar algumas destas tcnicas na estratgia de
elicitao de requisitos de segurana em projetos de
software da rea espacial.

Acredita-se que mtodos como o do Volere, o do uso
de alternativas de projeto (rationales) e a de
organizao da informao atravs da ontologia,
possam auxiliar tanto na definio da estratgia de
elicitao, bem como no prprio processo de descoberta
dos requisitos de segurana de um projeto.

6.1. O Mtodo Volere

Uma abordagem sistemtica de produzir requisitos
que seja capaz de conciliar as diferentes opinies dos
envolvidos e seu entendimento sobre o sistema constitui
um desafio para qualquer projeto. O processo de
especificao de requisitos chamado Volere [17]
fornece uma estrutura e guias bem definidos sobre qual
deve ser o contedo necessrio para a identificao dos
requisitos de um projeto [7].

O processo baseado em experincia de vrios
projetos de anlise de negcios, e est em continua
melhoria. Desde sua introduo em 1995, o mtodo
Volere foi adotado por milhares de organizaes em
torno do mundo. O modelo proposto pelo mtodo
composto de um guia para o conhecimento dos itens
necessrios a fim de se especificar os requisitos para um
produto. O produto freqentemente parte de software,
mas ele pode tambm ser uma parte de hardware, um
produto de consumidor, um conjunto de procedimentos
ou qualquer outra coisa desde que seja com o enfoque
de um projeto.

O modelo conta com um checklist baseado na rea
de conhecimento de requisitos e de informaes desta
competncia. O mtodo fornece uma lista de questes
que devem ser detalhadas para o levantamento dos
requisitos do sistema, envolvidos no ambiente, usurios
finais do produto, restries da soluo, escopo do
trabalho e da estratgia, requisitos funcionais e de
dados, e no funcionais, como aparncia, usabilidade,
desempenho, operacionais, manuteno, segurana,
culturais, tarefas, custos, riscos, documentao entre
outros que auxiliam no detalhamento do sistema.

Devido a diferentes culturas de engenharia, a
utilizao sistemtica deste recurso em uma abordagem
de elicitao de requisitos de segurana de software
facilitar a identificao dos mesmos por parte dos
diferentes tipos de participantes, podendo capturar e
agrupar as diferentes vises dos envolvidos atravs de
seu modelo de categoria dos requisitos.

A idia poder observar os requisitos de segurana
atravs de uma mesma tcnica, de forma organizada e
categorizada, sob diferentes perspectivas dos usurios.

6.2. A Tcnica Baseada em Alternativas
(Rationales)

A tcnica de uso de alternativas (rationales),
proposta inicialmente por Maclean [13], capaz de
capturar requisitos e expor os usurios a escolhas de
alternativas de projeto, estimulando a utilidade e a
usabilidade das escolhas. Outro benefcio a
possibilidade de melhorar a comunicao de opes e
encorajar um projeto mais participativo [21]. A
possibilidade de solues mltiplas, baseada em
critrios de escolha, e com um enfoque na
documentao do histrico das decises e sua
comunicao entre os participantes, permite explorar
exponencialmente a versatilidade de um projeto.

No caso especifico de requisitos de segurana de um
projeto de software para aplicao espacial, onde se
trabalha com projetos de longo prazo, com repetidos
ciclos de manutenes e de verses, a incluso de uma
abordagem capaz de identificar e registrar as diversas
alternativas possveis de soluo, de extrema valia.

A memria de projeto e as razes de escolha muitas
vezes so perdidas no tempo e podem gerar erros
sistmicos de grandes propores ou at mesmo
catastrficos, como o do Ariane 5. Acredita-se que
erros como o deste acidente espacial poderia at ser
evitado se os rationales fossem revisados e discutidos
em cada edio do foguete.

Outra forte contribuio do uso desta tcnica seu
emprego em ambientes organizacionais heterognicos e
no muito estveis como de uma organizao militar.
possvel observar a despeito do que popularmente se
acredita que institutos governamentais de pesquisa
perdem seu corpo de conhecimento com o passar dos
anos. Presses econmicas, falta de estmulos
profissionais, polticas governamentais equivocadas na
rea tecnolgica podem levar a perdas irreparveis de
conhecimento e de experincia do uso deste tipo de
aplicao. Muitos pesquisadores trocam sua posio
funcional estvel para os desafios da iniciativa privada,
ficando muitos projetos sem reter devidamente o
conhecimento adquirido ao longo de sua vida. A perda
dos argumentos que levaram a uma determinada
escolha, ou no, a forma e os critrios definidos para
captura dos requisitos so informaes que podem levar
at anos para serem recuperadas.

6.3. O Uso de Ontologia

A Ontologia sob a perspectiva da computao um
assunto que tem sido discutido com bastante
importncia na rea de organizao da informao,
principalmente pela comunidade de pesquisa em
inteligncia artificial.

Como uma disciplina de filosofia, a construo de
uma ontologia deve prover uma categorizao de um
sistema que permita construir uma certa viso de
mundo em particular. O termo ontologia foi definido
por Gruber [6] como sendo uma perspectiva formal e
explicita de um conceito compartilhado. Ela pode ser
til para ajudar os envolvidos a compreender melhor
uma rea de conhecimento, dando apoio busca de
consenso no entendimento sobre um assunto especfico.

Basicamente consiste de um conjunto de conceitos,
relaes, definies, propriedades e restries descritas
na forma de axiomas [3]. A primeira atividade a ser
realizada na construo de uma ontologia identificar
claramente seu objetivo e os usos esperados para ela,
isto o domnio de interesse. Em seguida, os conceitos
e as relaes devem ser identificados e organizados
num modelo utilizando uma linguagem grfica.
Finalmente, a Ontologia deve ser avaliada para verificar
se satisfaz os requisitos estabelecidos na especificao.
Esta avaliao pode ser realizada em paralelo com a
captura e formalizao destas propriedades, onde
devem ser observados critrios como clareza, coerncia,
extensibilidade e compromissos ontolgicos mnimos
[18].

Todo o processo deve ser documentado a fim de
incluir os objetivos, motivaes, as descries textuais
da conceituao, formalismos e critrios de projeto.

Especificamente na atividade de elicitao de
requisitos de segurana, o uso de uma ontologia para
representar o domnio de conhecimento relacionado a
requisitos de sistemas espaciais que contm software,
acredita-se possibilitar uma descrio exata do
conhecimento envolvido na rea de software e sistemas
espaciais, no permitindo que os requisitos elicitados
tenham uma interpretao diferente do que se pretende,
o que muito comum quando do uso de linguagem
natural, onde as palavras podem ter semntica diferente
do contexto proposto.

Outro benefcio o compartilhamento do
conhecimento e das informaes do domnio da
engenharia de software para aplicaes espaciais, com o
mnimo de interpretaes dbias, entre os diferentes
envolvidos no processo. Consultas, comparaes e
verificaes podero ser efetuadas baseados nas
aplicaes de software a serem desenvolvidas.

A reutilizao do conhecimento, extremamente
benfico para projetos espaciais, onde uma srie de
prottipos muito semelhantes pode vir a ser
desenvolvido, facilitar a criao de mecanismos de
inferncia para criar novo conhecimento a partir do
existente.

7. Consideraes

Este estudo apresenta, segundo o entendimento dos
autores, uma viso sobre os principais aspectos que
influenciam as atividades de elicitao de requisitos em
aplicaes de desenvolvimento de software da rea
espacial.

Foram tecidos alguns comentrios sobre a viso de
tecnologia, pessoas e processos, os participantes no
processo de elicitao e sobre como classificar a
questo da segurana neste contexto. Tambm foram
abordadas algumas tcnicas que devero ser
empregadas em trabalhos futuros deste estudo.

Entende-se que uma boa prtica na atividade de
elicitao de requisitos significa integrar nesta
disciplina diferentes aspectos como o de pessoas,
processos e tecnologia. Em sistemas crticos, como o de
projetos espaciais, extremamente importante que estas
vises sejam inter-relacionas de maneira a se obter uma
consistncia maior dos requisitos extrados.

Na viso de tecnologia foi destacado como deve ser
a conduo inicial das atividades de elicitao relativa

questo da segurana em projetos de sistemas crticos.
Classificar os requisitos de acordo com fatores bem
estabelecidos o primeiro passo para desenvolver
modelos consistentes e seguros. O segundo passo seria
realizar uma anlise de segurana em conjunto com a
anlise dos requisitos para a avaliao do quanto os
riscos associados com a especificao so aceitveis.
importante criar uma estratgia que combine e
complemente fatores e subfatores de dependabilidade,
de modo a propor solues capazes de atender a uma
especificao o mais completa e abrangente possvel.

Outro aspecto importante a ressaltar, que
atualmente existem iniciativas que procuram criar novas
abordagens que sejam capazes de integrar a engenharia
de sistemas e a de software, como a System Modelling
Language (SysML), criado pela Object Management
Group (OMG), que se prope a dar suporte a
especificao, anlise, projeto, verificao e validao
de sistemas complexos que podem incluir hardware,
software, dados, pessoas, procedimentos e facilidades.
O grande benefcio criar uma linguagem comum entre
times heterogneos, como engenheiros de sistema e de
software, que desenvolvem solues de hardware e de
software melhorando a comunicao entre os
envolvidos.

Na viso de pessoas, os engenheiros de requisitos
tm de ser integrados tanto s equipes de sistema, de
software, bem como ao gerenciamento de projeto, de
forma a poder obter uma viso mais abrangente e
completa do problema. Esta integrao deve permitir
compartilhar as especialidades e os valores de cada
perfil de engenharia e ainda criar uma cultura de
segurana nica. Deve-se alcanar um meio termo entre
a averso ao risco da engenharia de sistema versus a
tendncia a modismos da engenharia de software. A
implantao da cultura de segurana deve propiciar um
reconhecimento claro de seu valor pelos participantes,
estar integrada a todas as atividades de engenharia,
capaz de ser contabilizada e ter uma situao de
liderana (relativamente) independente.

Na viso de processos, vrios padres se propem a
criar modelos e frameworks de desenvolvimento e
avaliao de processo que esto convergindo para a
integrao da engenharia de sistemas e de software.
Tanto o Capability Maturity Model Integration
(CMMI), como as normas da European Cooperation for
Space Standartization (ECSS) da ESA se preocupam
com conceitos combinados de engenharia de sistemas e
de software. esperado de uma organizao que
desenvolve solues para sistemas espaciais implante
processos de desenvolvimento e gerenciamento
compatveis com os requisitos de qualidade espacial, e
que mantenha ao longo da vida de um projeto
compromisso com a melhoria constante.

importante frisar que a estratgia de elicitao de
requisitos em projetos, seja de software ou de sistema,
rea espacial ou no, devem empregar tcnicas que
visem aumentar o grau de confiana de que estes so os
requisitos corretos, completos e adequados para a
soluo da solicitao proposta.

O enfoque foi direcionado para a fase de requisitos
de um sistema que contm software, mas
especificamente as atividades de elicitao.
Ferramentas, tcnicas e abordagem, tanto formais,
como no formais devem ser estudadas e criticadas a
fim de se certificar qual melhor se encaixa no domnio
do problema, da soluo e da equipe escolhida para
desenvolver tal projeto. Podemos observar que as
abordagens Volere, de alternativas e de ontologicas, em
uma primeira aproximao, contribuiro
extensivamente para a definio do escopo do projeto e
de sua soluo.
Concluindo, em sistemas espaciais, especialmente
aqueles que possuem software como elemento crtico,
precisam adotar uma nova estratgia para superar as
dificuldades relacionadas a problemas com requisitos e
projeto.

Os obstculos relacionados tecnologia e processos
no mbito do programa espacial brasileiro, devem ser
focados principalmente na mudana de cultura das
pessoas envolvidas. Em qualquer que seja a fase do
projeto ou a disciplina envolvida, esta mudana deve
ser calcada na qualidade, e mais especificamente no
fator de segurana.

12. Referncias

[1] I M. Almeida, C. W. Johnson: Extending the Borders of
Accident Investigation: Applying Novel Analysis Techniques
to the Loss of the Brazilian Space Programmes Launch
Vehicle VLS-1 V03, 2005,
http://www.dcs.gla.ac.uk/~johnson/papers/papers.html.
[2] R. De Lemos: Requirements Engineering for Embedded
Systems, tutorial, Centro Tcnico Aeroespacial. So Jos dos
Campos, 1998.
[3] K. Duarte; R. A. Falbo, Uma Ontologia de Qualidade de
Software, Anais do VII Workshop de Qualidade de Software,
XIV Simpsio Brasileiro de Engenharia de Software, Joo
Pessoa; 2000.
[4] D. G. Firesmith, Engineering Safety Requirements, Safety
Constraints, and Safety-Critical Requirements, Journal of
Object Technology, Zurich, Switzerland, March/April, 2004,
pp 27-42.
[5] R. Gonzales, Developing the Requirements Discipline:
Software vs. Systems, IEEE Software, March/April, 2005, pp
59-61.
[6] T. Gruber, A translation Approach to Portable Ontology
Specification, 1993.
[7] D.T. Haley, B. Nuseibeh, H. C. Sharp, J. Taylor, The
Condrum of Categorizing Requirements: Managing

Requirements for Learning on the Move, 12th IEEE
International Requirements Engineering Conference, 2004.
[8] G. Kotonya, I. Sommerville, Requirements Engineering,
John Wiley & Son Ltd (2000).
[9] C. H. N. Lahoz, J. B. Camargo Jr., M. A D. Abdala, L. A.
Burgareli, A Software Safety Requirements Elicitationn Study
on Critical Computer Systems. 1st IET International
Conference on System Safety, London, UK, 2006.
[10] P. A Laplante, Real Time Systems Design and Analysis,
IEEE Press Wiley- Interscience, John Wiley & Sons, 2004.
[11] J.-C. Laprie, Dependable Computing: Concepts, Limits,
Challenges, Special Issue of the 25th International
Symposium on Fault-Tolerant Computing, Pasadena, USA.
IEEE Computer Society Press. Los Alamitos, CA., 1995, pp
42-54.
[12] J.L. Lyons, Report of the inquiry board into the failure of
Flight 501 of the Ariane 5 rocket.Technical report, European
Space Agency, Paris, France, 1996.
[13] A. Maclean, R. M. Yong, V Belloti, T. Moran,
Questions, Options, and Criteria: Elements of Design Space
Analysis, Human-Computer Interaction 6(3&4), 1991.
[14] NASA, Mars Climate Orbiter: Mishap Investigation
Board, Phase I Report, Technical report, Mars Climate
Orbiter, Mishap Investigation Board, NASA Headquarters,
Washington DC, USA, 1999,
ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO report.pdf.
[15] NASA/JPL, Report on the loss of the Mars Polar Lander
and Deep Space 2 Missions, Technical Report JPL D-18709,
NASA/Jet Propulsion Laboratory, California Institute of
Technology, 2000,
http://www.jpl.nasa.gov/marsreports/marsreports.html.
[16] A. Saeed, R. De Lemos, T. Anderson, The Role of
Formal Methods in the Requirements Analysis of Safety-
Critical Systems: a Train Set Example, Proceeding of the 21st
Symposium on Fault Tolerant Computing, Montreal, Canada,
1991, pp 478-485.
[17] S. Robertson and J. Robertson, Mastering the
Requirements Process, Harlow, England: Addison-Wesley,
1999.
[18] A. I. S.C.C. Santos, F. Hustinx, N. A Rosrio, P. F. M.
Pinto, Ontologia, Seminrio, Faculdade de Engenharia da
Universidade do Porto, 2005.
[19] P. Sayer, G. Kotonya, SWEBOK, Software
Requirements Engineering Knowledge Area Description,
Technical Version 5,
1999,http://www.swebok.org/stoneman/version_0.5/KA_Desc
ription_for_Software_Requirements_Analysis(Version_0_5).
pdf.
[20] Servio Pblico Federal. Ministrio da Defesa, Comando
da Aeronutica, Departamento de Pesquisas e
Desenvolvimento, Relatrio da Investigao do acidente
ocorrido com o VLS1-V03, em 22 de agosto de 2003, em
Alcntara, Maranho, So Jos dos Campos, Brasil, 2004,
http://www.aeb.gov.br.
[21] A. Sutcliffe, Requirements Rationales: Integrating
Approaches to Requirements Analysis, ACM, 1995.
[22] P. Verssimo, R. De Lemos, Confiana no
Funcionamento: Proposta para uma Terminologia em
Portugus. Publicao conjunta INESC e LCMI/UFSC, 1989,
http://www.cs.kent.ac.uk/people/staff/rdl/CoF/.