DANIELE ERICA DAMKE

PATRCIA FREITAS DE MORAES

APLICAO DA ABORDAGEM GQM
PARA A DEFINIO DE UM PROCESSO DE
ENGENHARIA DE REQUISITOS DE
SOFTWARE EMBARCADO
PROGRAMA DE PS-GRADUAO LATO SENSU
ENGENHARIA DE
SOFTWARE
APLICAO DA ABORDAGEM GQM PARA A DEFINIO DE UM
PROCESSO DE ENGENHARIA DE REQUISITOS DE SOFTWARE
EMBARCADO
Autores: Daniele Erica Damke
Patrcia Freitas de Moraes
Orientadora: Prof MSc. Claudia de Oliveira Melo
2008
DANIELE ERICA DAMKE
PATRCIA FREITAS DE MORAES







Trabalho apresentado ao Programa de Ps-
Graduao Latu Sensu em Engenharia de
Software da Universidade Catlica de
Braslia, como requisito para obteno do
Ttulo de Especialista em Engenharia de
Software.
Orientadora: MSc. Claudia de Oliveira Melo.








BRASLIA
2008






















Este trabalho dedicado a todas as pessoas que nos acompanharam na
elaborao deste trabalho contribuindo para seu xito.

AGRADECIMENTOS



Agradecemos s empresas participantes da pesquisa e ao Prof Dr. Joo Alberto
Fabro pela colaborao e apoio na pesquisa.

nossa orientadora Prof MSc. Claudia de Oliveira Melo e a todos os professores
que nos orientaram nessa jornada.

Aos nossos amigos que incentivaram nossa caminhada.

Aos nossos companheiros pela compreenso dos momentos de ausncia durante a
elaborao do trabalho.

A nossa famlia pelo incentivo e pelo crdito depositado em ns.

A todos que de alguma forma colaboram com as pesquisas e com o crescimento de
um mercado de software de maior qualidade.

A Deus por sempre nos direcionar e iluminar, permitindo a concluso deste projeto.























Tudo d certo no final.
Se no deu certo porque ainda no chegou o fim.
RESUMO



O mercado de software embarcado vem crescendo exponencialmente nos
ltimos anos. Apesar disso, o desenvolvimento deste tipo de software ainda uma
rea que merece ateno dos pesquisadores devido a sua complexidade e a falta de
tcnicas e ferramentas especficas para esse domnio de sistemas.
Aliada a todas as dificuldades do desenvolvimento de sistemas embarcados o
mercado nacional de desenvolvimento desse segmento de software composto em
sua maioria por Micro e Pequenas Empresas (MPEs). O que de certa forma agrava o
problema devido fato desse tipo de empresas possuir pouca informalidade em seus
processos.
Este trabalho realizou uma avaliao do processo de desenvolvimento de
micro e pequenas empresas desenvolvedoras de software embarcado com o
objetivo de definir um processo de engenharia de requisitos para sistemas
embarcados.

Palavras-chave: Sistemas Embarcados, Micro e Pequenas Empresas, Processo de
Requisitos.
LISTA DE ILUSTRAES
Figura 1 - Onde esto os processadores? (Tennenhouse 2000) ............................................... 19
Figura 2 Modelo de Processo ISO/IEC 12207 (Calsalvara, et al. 2000).................................. 31
Figura 3 - Inter-relao entre os elementos de um modelo de processo de software (Weber
2002) ................................................................................................................................... 33
Figura 4 - Grfico das Baleias do RUP (Kruchten 2003)............................................................ 37
Figura 5 - Grfico das Baleias do IPProcess (Barros, Bione, et al. 2005) .................................. 39
Figura 6 - Grfico Y do Modelo UPES ....................................................................................... 41
Figura 7 - Causas de Retrabalho (Gastaldo 2003)..................................................................... 43
Figura 8 Classificao de Requisitos No-Funcionais (Sommerville 1998)............................. 46
Figura 9 - Balanceamento da Equipe de ER (Hofmann 2001) ................................................... 50
Figura 10 - Fluxo de Trabalho da Disciplina de Requisitos (RUP 2001)..................................... 52
Figura 11 - Decomposio do processo de desenvolvimento de sistemas embarcados (Graaf
2003) ................................................................................................................................... 59
Figura 12 - Processo de Especificao de Requisitos (Lattemann 1997) .................................. 60
Figura 13 - Interao indireta entre o piloto e um caso de uso do TRCS (Nars 2002) ............... 61
Figura 14 - Os principais construtores da tcnica de caso de uso (Nars 2002).......................... 63
Figura 15 - Interao indireta entre o piloto e um caso de uso do TRCS (Nars 2002) ............... 64
Figura 16 - Envolvidos do desenvolvimento de sistemas embarcados (Graaf 2003) ................. 64
Figura 17 - Fases da Abordagem GQM (Berghout e Solligen 1999) ......................................... 70
Figura 18 Modelo de Avaliao GQM (Laboratory s.d.) .......................................................... 74
Figura 19 - Relao entre os Elementos do Modelo GQM......................................................... 96
Figura 20 - Tela Inicial do ProReqSE....................................................................................... 106
Figura 21 Fluxo da Atividade Definir Viso ........................................................................... 109
Figura 22 Fluxo da Atividade Encontrar e Resumir Requisitos ............................................. 113
Figura 23 Fluxo da Atividade Detalhar Requisitos ................................................................ 115
Figura 24 Fluxo da Atividade Revisar Requisitos................................................................. 117
LISTA DE TABELAS
Tabela 1 - Componentes do SPEM........................................................................................... 32
Tabela 2 - Comparativo das Caractersticas de ER em Processos de....................................... 42
Tabela 3 - Melhores Prticas da ER (Hofmann 2001)................................................................ 48
Tabela 4 Definio das palavras-chave da linguagem de especificao PLanguage (Gastaldo
2003) ................................................................................................................................... 55
Tabela 5 Questes de Definio dos Objetivos da Medio (Laboratory s.d.) ........................ 72
Tabela 6 - Abstract Sheets (Berghout e Solligen 1999) ............................................................. 73
Tabela 7 - Questes Iniciais da Fase de Planejamento............................................................. 78
Tabela 8 - Equipe GQM............................................................................................................. 78
Tabela 9 Modelo de Definio dos Objetivos da Medio (Laboratory s.d.)............................ 80
Tabela 10 - Objetivo do Negcio ............................................................................................... 80
Tabela 11 - Pontos de Verificao............................................................................................. 81
Tabela 12 - Contextualizao da Empresa................................................................................ 83
Tabela 13 - Contextualizao do Software ................................................................................ 84
Tabela 14 - Contextualizao da Equipe de Requisitos............................................................. 85
Tabela 15 - Entendimento dos Requisitos Funcionais e No-Funcionais................................... 87
Tabela 16 Identificao e Registro das Necessidades, Expectativas e Restries do Cliente 89
Tabela 17 - Modo de Especificao dos Requisitos................................................................... 91
Tabela 18 Definio e Manuteno dos Requisitos Funcionais e No Funcionais............... 91
Tabela 19 - Rastreabilidade dos Requisitos............................................................................... 92
Tabela 20 Anlise dos Requisitos........................................................................................... 93
Tabela 21 Reviso dos Planos e Produtos de Trabalho ......................................................... 94
Tabela 22 - Identificao das Interfaces do Sistema.................................................................. 95
Tabela 23 - ndices dos Pontos de Verificao.......................................................................... 99
Tabela 24 - Comparativo das Caractersticas de ER em Processos de................................... 120

LISTA DE ABREVIAES
CI Circuitos Integrados
DBL Desenvolvimento Baseado em Componentes
EPF Eclipse Process Framework Composer
ER Engenharia de Requisitos
EUA Estados Unidos da Amrica
GQM Goal /Question / Metric
Intel Corp. Intel Corporation
IpProcess Processo de Desenvolvimento de Soft-Ip
ISO/IEC International Organization for Standardization / International
Electrotechnical Commission
JAD Joint Application Development/Design
MDA Model Driven Architecture
MPE Micro e Pequena Empresa
MPS.BR Programa de Melhoria de Software Brasileiro
NASA National Aeronautics and Space Administration
OMG Object Management Group
PLanguage Planning Language
PU Processo Unificado
RUP Rational Unified Process
RUPSE Rational Unified Process for Sytem Engineering
SE Sistemas Embarcados
SPEM Software Process Engineering Metamodel
UC Caso de Uso
UML Unified Model Language
UPES Unified Process for Embedded System
SUMRIO
AGRADECIMENTOS .................................................................................................................. 4
RESUMO..................................................................................................................................... 6
LISTA DE ILUSTRAES .......................................................................................................... 7
LISTA DE TABELAS ................................................................................................................... 8
LISTA DE TABELAS ................................................................................................................... 8
LISTA DE ABREVIAES.......................................................................................................... 9
SUMRIO.................................................................................................................................. 10
1. INTRODUO ...................................................................................................................... 14
1.1 Motivao e Contexto ...................................................................................................... 14
1.2 Objetivos.......................................................................................................................... 15
1.3 Resultados Esperados..................................................................................................... 16
1.4 Metodologia ..................................................................................................................... 16
1.5 Organizao do Trabalho................................................................................................. 17
2. SISTEMAS EMBARCADOS.................................................................................................. 18
2.1 Definio.......................................................................................................................... 19
2.1.1 Caractersticas de Sistemas Embarcados ............................................................. 20
2.2 Dificuldades na Evoluo dos Sistemas Embarcados...................................................... 23
2.2.1 Dificuldades Acadmicas....................................................................................... 23
2.2.2 Dificuldades no Projeto.......................................................................................... 24
2.3 Consideraes Finais ...................................................................................................... 27
3. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE................................................... 29
3.1 Processo.......................................................................................................................... 29
3.2 Modelo de Processo de Software .................................................................................... 30
3.2.1 Elementos do Modelo de Processo deSoftware..................................................... 31
3.3 Modelagem de Processo ................................................................................................. 33
3.4 Modelos de Processos de Desenvolvimento de Software................................................ 35
3.4.1 Processo Unificado................................................................................................ 35
3.4.2 Rational Unified Process........................................................................................ 36
3.5 Modelos de Processo de Desenvolvimento de Software Embarcado............................... 37
3.5.1 RUPSE.................................................................................................................. 37
3.5.2 IPProcess.............................................................................................................. 38
3.5.3 Processo Unificado para Sistemas Embarcados (UPES)....................................... 40
3.6 Consideraes Finais do Captulo ................................................................................... 41
4. REQUISITOS ........................................................................................................................ 43
4.1 Conceitos Bsicos ........................................................................................................... 44
4.1.1 Requisitos.............................................................................................................. 44
4.1.2 Requisitos Funcionais x Requisitos No-Funcionais.............................................. 45
4.1.3 Engenharia de Requisitos...................................................................................... 46
4.1.4 Processo de ER Tradicional .................................................................................. 50
4.1.5 Gerncia de Requisitos ......................................................................................... 52
4.1.6 Envolvidos no Processo de Engenharia de Requisitos .......................................... 53
4.1.7 Revises de Requisitos ......................................................................................... 53
4.2 Requisitos em Sistemas Embarcados.............................................................................. 53
4.2.1 Requisitos No Funcionais .................................................................................... 53
4.2.2 Requisitos de Hardware x Requisitos de Software................................................. 56
4.2.3 Inveno de Requisitos ......................................................................................... 56
4.3 Processo de ER para Sistemas Embarcados................................................................... 57
4.3.1 Contexto das Empresas Desenvolvedoras de SE.................................................. 57
4.3.2 Processos de Desenvolvimento de SE Sob o Ponto de Vista da ER..................... 58
4.3.3 Metodologias para Especificao dos Requisitos em SE....................................... 61
4.3.4 Envolvidos no Processo de ER para SE................................................................ 64
4.3.5 Modelos de Documentos para Especificao dos Requisitos em SE..................... 65
4.3.6 Gerenciamento de Requisitos em SE.................................................................... 66
4.3.7 Outros Aspectos Importantes no Processo de ER para SE ................................... 66
4.4 Consideraes Finais ...................................................................................................... 67
5. ABORDAGEM GQM.............................................................................................................. 68
5.1 O Mtodo Goal Question Metric (GQM) ........................................................................... 68
5.1.1 Planejamento......................................................................................................... 70
5.1.2 Definio ............................................................................................................... 71
5.1.3 Coleta.................................................................................................................... 74
5.1.4 Interpretao ......................................................................................................... 75
5.1.5 Captura de Experincias........................................................................................ 76
5.2 Consideraes Finais do Captulo ................................................................................... 76
6. AVALIAO DO PROCESSO DE ENGENHARIA DE REQUISITOS PARA O
DESENVOLVIMENTO DE SISTEMAS EMBARCADOS ...................................................... 77
6.1 Aplicao do GQM........................................................................................................... 77
6.1.1 Planejamento......................................................................................................... 78
6.1.2 Definio ............................................................................................................... 79
6.1.3 Elaborao das Questes e Mtricas .................................................................... 82
6.1.4 Coleta.................................................................................................................... 97
6.1.5 Interpretao ......................................................................................................... 97
6.1.6 Captura de Experincias...................................................................................... 102
6.2 Consideraes Finais .................................................................................................... 102
7. DEFINIO DO PROCESSO DE ENGENHARIA DE REQUISITOS PARA O
DESENVOLVIMENTO DE SISTEMAS EMBARCADOS .................................................... 104
7.1 Processo de Engenharia de Requisitos para Sistemas Embarcados ProReqSE......... 104
7.1.1 Papis ................................................................................................................. 107
7.1.2 Atividades............................................................................................................ 108
7.1.3 Produtos de Trabalho .......................................................................................... 117
7.1.4 Diretrizes ............................................................................................................. 119
7.1.5 Listas de Verificao............................................................................................ 119
7.1.6 Conceitos ............................................................................................................ 120
7.2 Comparao do ProReqSE com Outros Processos....................................................... 120
7.3 Consideraes Finais .................................................................................................... 121
8. CONSIDERAES FINAIS DO TRABALHO ...................................................................... 122
8.1 Concluso...................................................................................................................... 122
8.2 Trabalhos Futuros.......................................................................................................... 123
REFERNCIAS....................................................................................................................... 124
APNDICE A RESPOSTA DO QUESTIONRIO DE AVALIAO DOS PROCESSOS DE
DESENVOLVIMENTO DE SISTEMAS EMBARCADOS .................................................... 128
APNDICE B LISTA DE VERIFICAO I ............................................................................ 134
APNDICE C LISTA DE VERIFICAO II ........................................................................... 138
APNDICE D LISTA DE VERIFICAO III .......................................................................... 142
APNDICE E LISTA DE PRIORIZAO.............................................................................. 146
APNDICE F DOCUMENTO DE REFERNCIA CRUZADA................................................ 148
APNDICE G DOCUMENTO DE ESPECIFICAO SUPLEMENTAR ................................ 152


Pgina 14
1. INTRODUO
1.1 Motivao e Contexto
Aplicaes de software embarcado esto cada vez mais presentes em nosso
cotidiano. Em geral so sistemas extremamente crticos para o sucesso do negcio e muitas
vezes para a segurana e bem-estar humanos, como as aplicaes de medicina,
telecomunicaes e aviao. O projeto deste tipo de sistemas complexo, pois apresenta
restries severas em relao s funcionalidades e implementao, dentre elas:
a reao a eventos externos em tempo real;
adaptao a limites de tamanho e peso;
gerenciamento de consumo de potncia sem perda de desempenho;
baixa disponibilidade de memria;
satisfao a requisitos de confiabilidade e segurana e ;
adequao a restries de oramento.
Alm disso, o projeto de sistemas embarcados bastante caro para as empresas por
envolver equipes especializadas e multidisciplinares (hardware digital, hardware analgico,
software, teste), e abordar conceitos pouco estudados pela computao de propsitos
gerais.
A diminuio dos custos de produo, o avano da fabricao de hardware e
software e a necessidade crescente do mercado possibilitaram o desenvolvimento de
complexas aplicaes de software embarcado ad hoc. Por outro lado, o aumento de
complexidade e criticidade destas aplicaes refletiram-se no processo de desenvolvimento
destes sistemas, sendo necessria uma maior nfase na verificao e validao de suas
atividades.
A evoluo das ferramentas especficas para desenvolvimento de softwares
embarcados auxilia o processo, entretanto, as estratgias de desenvolvimento adotadas
nem sempre resultam em uma soluo de qualidade satisfatria. Estudos com mais de 450
desenvolvedores de sistemas embarcados identificaram alguns fatores que contribuem para
o aumento do nmero de projetos fracassados (atrasados ou cancelados): mudana na
especificao, especificao incompleta, complexidade da aplicao e quantidade
insuficiente de desenvolvedores (Carro 2002). A avaliao e identificao das deficincias
de estratgias que auxiliam o desenvolvimento de requisitos no-funcionais como
previsibilidade, confiabilidade, desempenho, tamanho reduzido, criticidade e suporte a
tempo real tornam-se objeto de estudo para melhoria da qualidade das solues.
Pgina 15
Outro ponto que deve ser ressaltado o crescimento e sucesso da indstria
brasileira de desenvolvimento de software. Para que o setor torne-se realmente competitivo
nacional e internacionalmente necessrio que haja um incentivo as empresas para a que
os produtos e servios oferecidos atendam aos padres de qualidade internacionalmente
exigidos (Softex s.d.). No entanto, o setor de desenvolvimento de software brasileiro
composto em sua grande maioria por micro e pequenas empresas (MPEs) (MCT 2002).
Devido a restries de custos e investimentos a principal caracterstica dessa parcela do
mercado brasileiro a informalidade das prprias empresas e de seus processos (J. C.
Hauck 2004).
Assim, de vital importncia a pesquisa e o incentivo para que esse tipo de
empresas possa melhorar seus processos com o intuito de adequar-se s normas nacionais
e internacionais de desenvolvimento de software e melhorar a qualidade dos produtos e
servios oferecidos no mercado (Softex s.d.). Para que isso acontea, necessrio que os
processos da empresa estejam corretamente definidos, documentados e institucionalizados
com cada uma das atividades da organizao representadas em um modelo (J. C. Hauck
2004). Segundo Hauck, A institucionalizao do processo de desenvolvimento proporciona
s organizaes um desenvolvimento estruturado de seus projetos de forma que diversas
pessoas possam desempenhar mais de uma funo e o resultado final do produto atinja os
mesmo nveis de qualidade independente de quem o desenvolveu.
1.2 Objetivos
Este projeto baseia-se em estudos das reas de sistemas embarcados, processos de
desenvolvimento e de engenharia de requisitos para sistemas embarcados e GQM
Neste contexto, esta proposta de pesquisa tem como objetivo definir e aplicar uma
avaliao do processo de engenharia de requisitos de MPEs desenvolvedoras de Sistemas
Embarcados (SE). Com base nessa avaliao e nas caractersticas especficas deste tipo de
software, o trabalho pretende sugerir um processo de engenharia de requisitos mais efetivo
e aderente realidade das MPEs desenvolvedoras de software embarcado. Logo, o
desenvolvimento de cada atividade caracterizado por meio dos seguintes objetivos
especficos:
Elaborar reviso bibliogrfica: consiste na pesquisa, seleo e estruturao de
informaes para construo do referencial terico da monografia.
Definir o Programa de Medies (GQM): planejar (definir a equipe GQM, escolher
a rea de melhoria e preparar os envolvidos), definir (documentar os objetivos,
questes e mtricas), coletar os dados e interpret-los em relao s mtricas
definidas, gerando os resultados da medio.
Pgina 16
Propor e documentar ajustes em um processo de engenharia de requisitos:
tomando como base na disciplina de Requisitos do OpenUP, os resultados do
GQM e as definies do programa de melhoria de software brasileiro (MPS.Br).
Para a definio da avaliao foi selecionada a metodologia Goal/Question/Metrics (GQM)
(Basili e Rombach 1994), que tem se apresentado um mecanismo eficiente no planejamento
e definio de objetivos de medio e avaliao. Utilizada em diversos objetos de pesquisa
na rea de Engenharia de Software e adotada como uma importante ferramenta de
avaliao de qualidade de software, a principal caracterstica de GQM a adaptabilidade
para avaliao de qualquer tipo de problema. Logo, o mtodo ser aplicado nas MPEs
participantes da avaliao.

1.3 Resultados Esperados
So esperado os seguintes resultados do trabalho:
Identificar as principais limitaes dos atuais processos de engenharia de
requisitos de software embarcado com base na aplicao do mtodo GQM em
MPEs nacionais.
Proposio de um processo de engenharia de requisitos que visa diminuio da
complexidade e dos custos, alm do aumento da efetividade no desenvolvimento
de sistemas embarcados, com base na pesquisa realizada. Este processo levar
em considerao as caractersticas prprias deste tipo de sistema como:
o Resposta em tempo real, resposta a eventos sncronos, tamanho e custo
reduzidos, segurana e confiabilidade, ambientes inspitos,
previsibilidade, portabilidade, limites de tamanho e peso, gerenciamento
de consumo de potncia sem perda de desempenho, baixa
disponibilidade de memria.
1.4 Metodologia
Este projeto classificado como pesquisa aplicada e qualitativa por gerar
conhecimentos para aplicao prtica dirigida soluo de problemas do desenvolvimento
de um tipo especfico de software (Oliveira s.d.). A pesquisa ser avaliada em um conjunto
exclusivo de empresas cujos dados sero analisados indutivamente pelos pesquisadores e
de acordo com a abordagem de estudo. Quanto aos fins, esse trabalho uma pesquisa
metodolgica por elaborar um instrumento de captao da realidade, definindo formas para
atingir o objetivo de estudo. Quanto aos meios, essa pesquisa ser bibliogrfica - baseada
em livros, artigos cientficos, redes eletrnicas e documental.
Pgina 17
1.5 Organizao do Trabalho
Este trabalho composto de sete captulos organizados da seguinte forma:
O captulo 2 descreve conceitos relacionados a sistemas embarcados, alm
da exposio de suas caracterticas e dos problemas de seu
desenvolvimento.
O captulo 3 discorre sobre a elaborao de processos de desenvolvimento
de software e sobre os elementos que os compem. So descritos ainda os
principais processos de desenvolvimento de software tradicionais e
especficos para sistemas embarcados.
O captulo 4 apresenta os principais processos de engenharia de requisitos
tradicionais e especificos para sistemas embarcados.
O captulo 5 descreve o mtodo GQM, suas fases e os produtos gerados.
O captulo 6 apresenta todo o processo de elaborao e aplicao do
programa de medies.
O captulo 7 descreve a adaptao do processo de engenharia de requisitos
do processo unificado as caractersticas dos sistemas embarcados.
O captulo 8 apresenta as concluses desta monografia, destacando as
contribuies desta pesquisa e os trabalhos futuros.
Pgina 18

2. SISTEMAS EMBARCADOS
A tecnologia da computao tem se tornado onipresente no dia-a-dia da populao.
Softwares embarcados hoje controlam a comunicao, os transportes, os sistemas mdicos,
entre outros (Henzinger 2007). Embora apenas recentemente os sistemas embarcados
tenham se mostrado extremamente populares no cotidiano das pessoas, esta categoria de
sistemas surgiu e foi reconhecida nos Estados Unidos no incio da dcada de 60 em um
computador-guia do projeto Apollo denominao do conjunto de misses espaciais
coordenadas pela NASA (National Aeronautics and Space Administration) com o objetivo
de levar o primeiro homem lua (Wolf 2001).
Com a evoluo dos microprocessadores e a diminuio de seus custos de
produo, os sistemas embarcados tornaram-se universais, pois esto presentes em muitos
dispositivos, desde os mais simples, como eletrodomsticos, at dispositivos complexos
como os de naves espaciais. Entretanto, a maioria desses sistemas no percebida pelas
pessoas, pois como o prprio nome insinua, esto embutidos dentro de outros sistemas
utilizados no dia-a-dia (Barreto 2006).
Em 2000 Tennenhouse (Tennenhouse 2000), na ocasio vice-presidente e diretor de
pesquisas da Intel Corporation (Intel Corp) , publicou um artigo no qual mostrava que 80%
de todos os processadores fabricados no mundo eram usados em sistemas embarcados
(Figura 1). Os 20% restantes eram divididos em aplicaes desktop (2%), aplicaes
robticas (6%) e sistemas automotivos (12%). Neste contexto, no resta outra sada para as
pesquisas em Cincia da Computao seno seguir a mesma direo dos processadores e
investir uma boa parcela de seu capital intelectual neste novo espao de pesquisa.
Pgina 19

Figura 1 - Onde esto os processadores? (Tennenhouse 2000)
As aplicaes mais comuns do mercado de processadores embarcados so
telefones celulares, brinquedos, eletrodomsticos e outros equipamentos eletrnicos. Estes
produtos so projetados sob restries de recursos tais como energia consumida, utilizao
de memria, tamanho do circuito integrado, desempenho, resposta em tempo real, e,
principalmente, custo. No custo deve ser includo, alm dos componentes de hardware, o
desenvolvimento do hardware e de software aplicativo (Barbiero 2006).
Contudo, medida que aumenta a quantidade e variedade de tais produtos, h um
acrscimo em sua complexidade, devido integrao de mais componentes de software e
hardware ao sistema. E, aliado a isso, ainda existe uma srie de restries como aquelas
citadas no pargrafo anterior. A unio destes aspectos torna o projeto de sistemas
embarcados um desafio constante, visto que todas estas caractersticas devem ser levadas
em considerao durante o desenvolvimento (Graaf 2003).
Este captulo abordar, na seo 2.1, a definio e as caractersticas de sistemas
embarcados. J a seo 2.2 apresentar as dificuldades na evoluo deste tipo de sistema.
Por fim, a seo 2.3 descreve as consideraes finais do captulo.
2.1 Definio
Definir sistemas embarcados no uma tarefa trivial. Segundo (Marwedel 2003),
sistemas embarcados podem ser definidos como sistemas eletrnicos de processamento de
informao embutidos em um produto de forma transparente para o usurio. Como j foi
Pgina 20
descrito anteriormente, este tipo de sistema composto de sistemas micro processados que
no aparecem como funcionalidade final de um produto, ou seja, esto completamente
encapsulados ou dedicados ao dispositivo ou sistema que ele controla, portanto, so
invisveis do ponto de vista do usurio (Wolf 2001).
Lee (E. Lee, Embedded Software 2002) ressalta, no entanto, que sistemas
embarcados no se resumem a software em um pequeno dispositivo. Ao contrrio da
computao tradicional, sua principal caracterstica no a transformao de dados, mas
preferencialmente a interao com o mundo fsico. Um software cuja principal caracterstica
a interao com o mundo real deve, por necessidade, adquirir algumas propriedades de tal
mundo. Ou seja, ele gasta tempo, consome energia e no finaliza nunca (a menos que
falhe). Alm disso, so softwares que implementam um conjunto de tarefas pr-definidas,
geralmente com requisitos especficos que so utilizados para acrescer ou otimizar
funcionalidades (Barreto 2006).
Em linhas gerais, os processos e componentes que compem os sistemas
embarcados so muito parecidos com a computao de propsito geral. No entanto, na
computao tradicional, o objetivo principal atender a funcionalidades com desempenho
cada vez maior. J na computao embarcada o interesse est voltado para interfaces com
o ambiente, como sensores e atuadores, e algoritmos de controle, de modo a satisfazer
severas restries, como, requisitos temporais, de consumo de energia e memria,
mobilidade, tamanho, peso, segurana, confiabilidade, tempo de entrega dentre outras
(Barreto 2006).
2.1.1 Caractersticas de Sistemas Embarcados
A seguir so apresentadas algumas caractersticas comuns em sistemas
embarcados, segundo (Marwedel 2003). Vale lembrar que os sistemas no
necessariamente possuem todas estas caractersticas, mas devem ter muitas delas para
serem considerados embarcados.
2.1.1.1 Acoplado ao ambiente fsico
Freqentemente, sistemas embarcados so conectados ao ambiente fsico atravs
de sensores que coletam informaes sobre este espao e atuadores que controlam este
ambiente.
2.1.1.2 Confivel
Sistemas embarcados tm que ser confiveis. Muitos sistemas embarcados so de
segurana crtica, ou seja, so sistemas cujas falhas podem gerar conseqncias
catastrficas, colocando em risco at mesmo vidas humanas. Sistemas de controle de
Pgina 21
estaes de energia nuclear so exemplos de sistemas de extrema segurana crtica que
so, ao menos em parte, controlados por software. Confiabilidade , entretanto, importante
tambm em outros sistemas como carros, trens, avies etc. Uma razo chave para ser de
segurana crtica que estes sistemas so diretamente conectados ao ambiente e tm um
impacto imediato neste ambiente.
Um sistema considerado confivel deve abranger os seguintes aspectos (Pradhan
1996):
Confiabilidade: probabilidade de que um sistema no v falhar;
Manutenibilidade: a probabilidade de que uma falha no sistema possa ser
reparada dentro de uma certa janela de tempo;
Disponibilidade: probabilidade de que o sistema esteja disponvel. Os dois
aspectos anteriores (confiabilidade e manutenibilidade) devem ser altos para
garantir a alta disponibilidade;
Segurana no funcionamento (safety): probabilidade de que uma falha no
sistema no cause nenhum dano;
Segurana no uso (security): propriedade de que dados confidenciais
continuem confidenciais e que comunicaes autnticas estejam garantidas.
2.1.1.3 Eficiente
Sistemas embarcados devem ser eficientes. Para garantir esta eficincia, algumas
caractersticas devem ser levadas em considerao:
Energia: muitos sistemas embarcados so mveis, ou seja, obtm energia de
baterias. Se por um lado os requisitos computacionais esto evoluindo
rapidamente (especialmente para aplicaes multimdia) e os usurios esto
esperando que suas baterias durem cada vez mais. Por outro, a tecnologia das
baterias no tem acompanhado a mesma velocidade de evoluo. Sendo assim,
a energia eltrica disponvel para os sistemas embarcados deve ser usada com
muita eficincia;
Tamanho do cdigo: todo o cdigo que rodar em um sistema embarcado deve
ser armazenado com o sistema. Normalmente, no h discos rgidos onde o
cdigo pode ser armazenado. Portanto, o tamanho do cdigo deve ser o mnimo
possvel;
Eficincia em tempo de execuo: o mnimo de recursos deve ser usado para
implementar as funcionalidades requeridas. A fim de reduzir o consumo de
Pgina 22
energia, freqncia de clock e voltagens preciso ser o menor possvel. Ou seja,
apenas os componentes necessrios devem estar presentes;
Peso: todos os sistemas portveis devem ter baixo peso;
Custo: para a produo de sistemas em massa, principalmente os eletrnicos
destinados ao consumo, competitividade no mercado uma caracterstica
essencial.
2.1.1.4 Dedicado aplicao
Estes sistemas so dedicados a uma determinada aplicao. Por exemplo, um
processador que rode um software de controle de carro, sempre rodar este software. No
deve haver a possibilidade de executar um jogo ou um programa de planilhas no mesmo
processador. Isto no indicado devido a duas razes: aplicaes adicionais diminuiriam a
segurana do sistema e execut-las s seria vivel caso os recursos (como memria)
estivessem sem uso.
2.1.1.5 Interface dedicada
A maioria dos sistemas embarcados no usa teclados, mouses e monitores grandes
de computadores para sua interface com o usurio. Ao invs disso, existem interfaces com o
usurio dedicadas que consistem de botes de presso, volantes, pedais, etc. Ademais,
muitas das atividades executadas por estes sistemas so autnomas e grande parte de
suas interaes so com outros sistemas, ao invs de humanos. Por isso, o usurio
dificilmente nota que o processamento de informaes envolvido. Por este motivo, a nova
era da computao tambm foi caracterizada como disappearing computer.
2.1.1.6 Restrio de Tempo Real
Muitos sistemas embarcados devem suportar restries de tempo real. Neste caso,
no completar um processamento dentro da janela de tempo esperada pode resultar em
uma perda significativa na qualidade provida pelo sistema (por exemplo, se a qualidade de
udio ou vdeo for afetada) ou em uma ameaa ao usurio (por exemplo, se carros, trens ou
avies no operarem da maneira prevista).
2.1.1.7 Hbrido
Muitos sistemas embarcados so sistemas hbridos no sentido de inclurem partes
analgicas e digitais. As partes analgicas usam valores contnuos de sinal em tempos
contnuos, ao passo que partes digitais usam valores discretos de sinais em tempos
discretos.
Pgina 23
2.1.1.8 Reativo
Tipicamente, sistemas embarcados so sistemas reativos, ou seja, esto em
interao contnua com seu ambiente e executam em um ritmo determinado por este
ambiente (Berg, 1995, apud Marwedel, 2003, p.4). Os sistemas reativos so aqueles que
permanecem em um determinado estado, esperando uma entrada. Para cada entrada, eles
efetuam alguns processamentos e geram uma sada e um novo estado. Portanto, autmatos
so modelos muito bons para tais sistemas. Funes matemticas, as quais descrevem os
problemas resolvidos pela maioria dos algoritmos, podem ser um modelo inapropriado.
2.2 Dificuldades na Evoluo dos Sistemas Embarcados
Ainda que as oportunidades paream ilimitadas, a evoluo dos softwares
embarcados no tem conseguido acompanhar o potencial oferecido pelas tecnologias
emergentes de hardware e de comunicao (Henzinger 2007). Nas subsees seguintes
so apresentadas algumas das dificuldades encontradas no estudo e no projeto de sistemas
embarcados.
2.2.1 Dificuldades Acadmicas
Apesar de se mostrar um assunto extremamente interessante e com grandes
possibilidades de estudo, os sistemas embarcados so pouco representados
academicamente e em discusses pblicas (Ryan, 1995, apud Marwedel, 2003, p.4). Na
academia, um dos problemas de ensinar a projetar sistemas embarcados o equipamento
necessrio para tornar o tpico interessante e prtico. Alm disso, sistemas embarcados
reais so muito complexos e, portanto, difceis de ensinar (Marwedel 2003).
Por outro lado, sistemas embarcados no aparecem como uma disciplina central no
currculo de Cincia da Computao e nem no de Engenharia Eltrica. Na prtica,
engenheiros eltricos freqentemente elaboram arquiteturas de softwares e cientistas da
computao tm que lidar com restries fsicas. Ou seja, o projeto de sistemas
embarcados est relacionado aos dois currculos. No entanto, existe uma barreira, iniciada
na ainda academia, que separa estes dois mundos. E a indstria busca desesperadamente
por engenheiros que possuam conhecimentos suficientes nos dois campos (Henzinger
2007).
Se em um extremo tem-se o fato de que as pesquisas em cincia da computao
ignoraram por muito tempo os sistemas embarcados, pois utilizavam abstraes que de
certa forma no levavam em conta as caractersticas fsicas. No outro, tem-se a
comprovao de que o projeto de sistemas embarcados vai alm do conhecimento
Pgina 24
tradicional dos engenheiros eltricos, uma vez que o clculo e o software so partes
integrantes dos sistemas embarcados (Henzinger 2007).
Segundo Lee (E. Lee, Embedded Software 2002), do ponto de vista do software,
sistemas embarcados eram muito pequenos e retrgrados com uso de suas tcnicas
peculiares como programao em linguagem assembly, e muito limitado pelos custos de
hardware. Conseqentemente, o projeto destes sistemas no foi beneficiado pela valiosa
abstrao do desenvolvimento do sculo XX. Tais sistemas no utilizam recursos como
modelagem orientada a objetos, polimorfismo e gerenciamento automtico de memria (E.
Lee, Embedded Software 2002). As melhores tecnologias com seu uso desregrado de
memria, camadas de abstrao, algoritmos elaborados e otimizaes estatsticas no
pareciam aplicveis. E como os resultados das pesquisas no resolviam os problemas dos
sistemas embarcados, o problema no era, portanto, interessante aos olhos dos
pesquisadores (E. Lee, Whats Ahead for Embedded Software? 2000).
No entanto, estas deficincias tm se transformando em oportunidades. Os
pesquisadores esto comeando a reconstruir suas pesquisas de maneira que possam
adequ-las aos problemas reais e diferenciados expostos pelos sistemas embarcados. E o
problema mais urgente , justamente, como adaptar as tcnicas de software existentes para
enfrentar os desafios do mundo fsico (E. Lee, Whats Ahead for Embedded Software?
2000).
2.2.2 Dificuldades no Projeto
2.2.2.1 Dificuldades Tecnolgicas
O nmero crescente de aplicaes resultou na necessidade de se construir
tecnologias que suportem o projeto de sistemas embarcados. As tecnologias e ferramentas
disponveis atualmente ainda possuem limitaes significativas, dentre elas a demanda por
melhores linguagens de especificao, ferramentas de gerao de cdigo a partir das
especificaes, verificadores de tempo, sistemas operacionais de tempo real, tecnologias de
baixo custo de energia e tcnicas de projeto para sistemas confiveis (Marwedel 2003).
Estas vises distintas entre as tcnicas modernas de software e as necessidades
dos sistemas embarcados no uma novidade. Remontando-se s razes da computao
nota-se que as interfaces com o mundo real somente comearam a se estender
recentemente, depois dos teclados e monitores. A computao tem suas origens na
transformao de dados, no na interao com sensores, atuadores ou mesmo humanos.
Entretanto, softwares em uma rede de sistemas embarcados sero formados, certamente,
por componentes que operaro de maneira concorrente e em tempo real, com grande
freqncia interagindo remotamente (E. Lee, Whats Ahead for Embedded Software? 2000).
Pgina 25
Ademais, o projeto de sistemas embarcados extremamente complexo, por envolver
conceitos at agora pouco analisados pela computao de propsitos gerais. Questes
como portabilidade e limite de consumo de potncia sem perda de desempenho, baixa
disponibilidade de memria, necessidade de segurana e confiabilidade, possibilidade de
funcionamento em uma rede maior, interao constante com o mundo real e o curto tempo
de projeto tornam o desenvolvimento de sistemas computacionais embarcados uma rea
em si (Wolf 2001). Portanto, os desafios da pesquisa so enormes, uma vez que os prazos
de entrega dos sistemas cada vez menor, o custo e a complexidade desse tipo de
sistemas extremamente alta, no sendo confivel a utilizao de metodologias de
desenvolvimento com solues ad hoc. Paradoxalmente, as tecnologias de engenharia de
software no possuem caractersticas especficas para lidar com requisitos de memria,
energia ou tempo real.
Uma das principais caractersticas dos sistemas embarcados, no entanto, o fato de
interagirem com o mundo real e, deste modo, no operarem em um ambiente estritamente
controlado. Em conseqncia, este tipo de sistema apresenta caractersticas extremamente
complexas, como:
reao a eventos externos em tempo real;
concorrncia sistemas embarcados raramente interagem com um nico
processo fsico. Eles devem reagir, simultaneamente, a estmulos provenientes
da rede e de uma variedade de sensores e, ao mesmo tempo, reter controle
temporrio sobre os atuadores;
vivacidade (liveness) esta uma caracterstica crtica, pois os programas no
podem terminar ou ficar bloqueado enquanto esperam a ocorrncia de eventos
que nunca acontecero;
heterogeneidade uma caracterstica intrnseca dos sistemas embarcados.
Eles misturam estilos de computao e tecnologias de implementao. Primeiro
porque tais sistemas so, freqentemente, uma mistura de hardware e software,
por isso, softwares embarcados interagem com hardwares projetados
especificamente para interagir com eles. Sistemas embarcados tambm so
heterogneos no estilo de manipulao. Eles interagem com eventos ocorrendo
irregularmente no tempo (alarmes, comandos do usurio, gatilhos de sensores,
etc.) e regularmente no tempo (amostras de sensores de dados e sinais de
controle de atuadores);
reatividade reagem continuamente com o ambiente na velocidade do ambiente.
Sistemas reativos tm restries de tempo-real e so freqentemente de
Pgina 26
segurana crtica, no sentido que falhas podem resultar na perda de vidas
humanas. E eles nunca terminam e devem ser capazes de se adaptarem s
mudanas. Tais sistemas esto sempre sendo redesenhados enquanto operam e
no podem falhar;
dentre outros j citados adaptao a limites de tamanho e peso; gerenciamento
de consumo de potncia sem perda de desempenho; baixa disponibilidade de
memria; satisfao a requisitos de confiabilidade e segurana e adequao a
restries de oramento.
A partir do exposto, nota-se que outro grande desafio no desenvolvimento de
sistemas embarcados o atendimento de seus requisitos no-funcionais, ou seja, aqueles
cuja preocupao no com a funcionalidade do sistema. Independente do tipo de software,
a especificao dos requisitos no-funcionais j prejudicada pelo fato das tcnicas
adequadas para sua identificao e classificao no serem amplamente difundidas. Em
sistemas embarcados este complicador ainda maior, dada a imensa quantidade de
requisitos no-funcionais a serem analisados.
2.2.2.2 Dificuldades do Negcio
Alm das dificuldades tcnicas, algumas dificuldades advindas do negcio tambm
surgiram recentemente no projeto de sistemas embarcados, as quais os novos processos de
desenvolvimento devem considerar (Sangiovanni-Vincentelli 2004): crescimento dos custos
de engenharia no recorrente, elevando os custos da produo de um circuito integrado
(CI); simultnea presso para a reduo do tempo de entrega (time-to-market) de um
produto, e sua crescente complexidade; alterao de um modelo de negcio vertical para
um modelo horizontal, onde a responsabilidade da produo de um novo projeto
distribuda entre companhias distintas.
Dado o exposto, nota-se que projetar um sistema embarcado uma tarefa rdua. E o
aumento das conexes, com a internet e entre os prprios dispositivos, introduz
complicaes significativas como a possibilidade de baixar mdulos que reconfiguram
dinamicamente o sistema. Alm disso, os consumidores demandam funcionalidades cada
dia mais elaboradas, que aumentam muito a complexidade do software. O fato que tais
sistemas no podem mais ser projetados por um nico engenheiro dedicado a construir
dezenas de quilobytes de cdigo assembly (E. Lee, Whats Ahead for Embedded Software?
2000).
Por outro lado, softwares embarcados freqentemente encapsulam o conhecimento
do domnio, especialmente quando necessrio processar dados de sensores ou controlar
atuadores. At mesmo programas muito pequenos podem conter algoritmos altamente
Pgina 27
sofisticados, o que requer um profundo conhecimento do domnio e das tecnologias de
suporte, como as de processamento de sinal.
2.2.2.3 Fracasso nos projetos
Um estudo realizado por (Carro 2002) com mais de 450 desenvolvedores de
sistemas embarcados identificaram alguns fatores que contribuem para o aumento do
nmero de projetos fracassados (atrasados ou cancelados):
mudana na especificao;
especificao incompleta;
complexidade da aplicao;
quantidade insuficiente de desenvolvedores, e
tecnologias especficas para a aplicao de softwares embarcados.
Para resolver todas estas questes, as tcnicas de projeto de software existentes
no so apropriadas. Em parte porque so recentes, em outra, porque no levam em
considerao as caractersticas especficas de sistemas embarcados. As tecnologias de
desenvolvimento existentes no avaliam adequadamente o impacto em sistemas
embarcados e nem so customizveis a ponto de servirem a tais propsitos (Graaf 2003).
Por fim, em decorrncia do conhecimento do domnio requerido: sistemas
embarcados so projetados, freqentemente, por engenheiros treinados classicamente no
domnio em que trabalham. Os engenheiros de tais sistemas raramente so cientistas da
computao, possuindo, portanto, pouco conhecimento de teoria da computao,
concorrncia, projeto orientado a objetos, sistemas operacionais e semntica (E. Lee,
Whats Ahead for Embedded Software? 2000). Na realidade, segundo (E. Lee, Whats
Ahead for Embedded Software? 2000) discutvel se outras disciplinas da engenharia
teriam muito pouco a oferecer ao projeto de sistemas embarcados atualmente, devido a sua
viso diferenciada a respeito da questo temporal e do uso desregrado de recursos de
hardware. Mas estas disciplinas sero essenciais na medida em que os softwares
embarcados forem se tornando cada vez mais complexos, modulares, adaptativos e
conectveis.
2.3 Consideraes Finais
Apesar de serem muitas so as dificuldades enfrentadas no desenvolvimento de
sistemas embarcados, este trabalho limitar-se- a entender e avaliar os processos atuais de
Engenharia de Requisitos deste tipo de sistema. O produto final deste estudo consistir na
Pgina 28
elaborao de um processo que se adapte de maneira adequada a este domnio de
software.
Sendo assim, o captulo seguinte abordar conceitos de processo de
desenvolvimento de software, tanto para sistemas tradicionais quanto para sistemas
embarcados, bem como tcnicas para a modelagem de processos.

Pgina 29
3. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
O desenvolvimento de software de alta qualidade no uma tarefa trivial desde o
surgimento da indstria de software. No incio os sistemas eram desenvolvidos sem a
utilizao de mtodos sistemticos e praticamente sem nenhuma documentao (ad hoc). O
sucesso e a qualidade dos softwares dependiam diretamente dos profissionais envolvidos
em seu desenvolvimento (Farias 2006).
Com o passar dos anos e com o aumento da complexidade dos sistemas, esse
cenrio comeou a se modificar. Tornou-se evidente a necessidade de definir e utilizar
mtodos sistemticos e ferramentas que guiassem o desenvolvimento de software, o que
levou ao surgimento da engenharia de software (Pimentel 2007).
Os processos de desenvolvimento surgiram como parte da engenharia de software.
Seu principal objetivo assegurar a qualidade no desenvolvimento de sistemas em todas as
suas etapas, para isso eles servem de guia para a execuo de atividades, definem quais
produtos sero desenvolvidos e quando, coordenam as mudanas necessrias, e auxiliam o
acompanhamento do progresso do desenvolvimento do software (Pimentel 2007).
Este captulo aborda conceitos relacionados aos processos de desenvolvimento de
software. Sua organizao do realizada da seguinte forma: na seo 3.1 ser apresentada
uma breve descrio de processos de desenvolvimento de software. A seo 3.2 evidencia
alguns modelos de processos e os itens que os compem. A seo 3.3 apresenta as fases e
o fluxo de modelagem de um processo . Nas sees 3.4 e 3.5 so relatados processos de
desenvolvimento de software tradicionais e especficos para o desenvolvimento de sistemas
embarcados. Finalmente, a seo 3.6 descreve as consideraes finais do captulo.
3.1 Processo
Diversas etapas so executadas durante o processo de desenvolvimento de
software. As atividades que as compem iniciam com a identificao das necessidades do
usurio, prosseguem com seu refinamento e finalizam com a disponibilizao do software
para sua utilizao pelo usurio final. Esse conjunto de atividades que recebe dados de
entrada realiza um processamento que adiciona valor a esses dados e produz uma sada de
valor a um cliente especifico chamado de processo (Gonalvez 2000).
Pressman (Pressman 2006) afirma que um processo de software caracterizado por
um pequeno nmero de atividades que so aplicadas a qualquer tipo de projeto
independente de seu tamanho e custo, e por um conjunto de tarefas. Este conjunto de
tarefas composto de colees de atividades de engenharia de software; que podem ser
adaptadas s necessidades da equipe e s caractersticas do projeto de software; marcos
Pgina 30
de projeto, produtos de trabalho e pontos de garantia da qualidade. Suas atividades podem
ser adaptadas s necessidades da equipe e s caractersticas do projeto de software.
Segundo Weber (Weber 2002), os processos de software tm o seu principal
enfoque nos processos tcnicos e gerenciais relacionados ao desenvolvimento de software
cujo objetivo : planejar, monitorar, gerenciar, executar, controlar e melhorar atividades
relacionadas a software. Dessa forma, a correta definio do conjunto de processos das
atividades da empresas, agrupados, documentados e institucionalizados subsidiam a
gerao de produtos com altos nveis de qualidade (J. C. Hauck 2004).
3.2 Modelo de Processo de Software
Conforme Feiler (Feiler e Humphrey 1993), o modelo de processo uma
representao abstrata da arquitetura, projeto ou definio do processo de software, que
descreve, em diferentes nveis de detalhes, uma organizao dos elementos de um
processo e prov definies da maneira como devem ser realizadas a avaliao e a
melhoria de processo.
Um modelo de processo composto de grupos de processos e de sub-modelos que
variam de acordo com as abordagens de diferentes autores. Acua em (Acua, et al. 2000)
define que um processo composto basicamente de dois sub-processos inter-relacionados
e dois sub-modelos: o processo de produo, que consiste na construo e na manuteno
do software; e o gerenciamento do processo, que responsvel por estimar, planejar e
controlar os recursos necessrio para executar o processo de produo, alm dos sub-
modelos de gerenciamento do processo e do prprio modelo de processo.
A ISO/IEC 12207 (International Organization for Standardization / International
Electrotechnical Commission) uma norma que define e classifica com maior nvel de
detalhe o grupo de processos que compem um modelo de processo de software,
abrangendo todo o ciclo de vida do software desde a concepo at sua descontinuidade
(Calsalvara, et al. 2000). Os processos da ISO/IEC 12207 so agrupados de acordo com
seu principal objetivo no ciclo de vida do projeto de forma que sua estrutura seja flexvel,
modular e adaptvel conforme as necessidades de cada organizao (Calsalvara, et al.
2000). A Figura 2 ilustra o modelo de processos da norma ISO/IEC 12207.
Pgina 31

Figura 2 Modelo de Processo ISO/IEC 12207 (Calsalvara, et al. 2000)
O modelo de processo da norma ISO/IEC 12207 composto de trs tipos de
processos:
Processos Fundamentais: So processos diretamente relacionados produo
do software em si.
Processos de Apoio: servem como ferramenta de auxlio aos processos
fundamentais. Os processos de apoio so de fundamental importncia para o
suporte a continuidade e a qualidade dos processos fundamentais.
Processos Organizacionais: Viabilizam a manuteno dos demais processos da
organizao e sub-existem dentro das organizaes independente de projetos
especficos.
O objetivo do modelo de processo apresentado pela ISO/IEC 12207, e tambm por
outros modelos de processo e de melhoria de processo, que seja fornecida uma estrutura
para que todos os envolvidos com o desenvolvimento do software utilizem uma linguagem
comum na definio dos processos da organizao (Calsalvara, et al. 2000).
3.2.1 Elementos do Modelo de Processo deSoftware
Os elementos que compem o modelo de processo de software oferecem aos seus
envolvidos um melhor entendimento de seu papel na organizao, das funes
desempenhadas no processo de desenvolvimento da empresa e de suas atividades ao
Pgina 32
longo de todo o ciclo de desenvolvimento (Weber 2002). Visando representar de forma
grfica as caractersticas e os componentes de modelagem de um processo de
desenvolvimento a OMG criou o SPEM Metamodel (OMG 2005).
O SPEM um profile da notao UML que foi proposto pela OMG (Object
Management Group) para a descrio de processos de desenvolvimento de software e de
seus componentes. A proposta inicial da OMG limita-se a definir o conjunto mnimo de
processo que modela os elementos necessrios para descrever qualquer processo de
desenvolvimento de software, sem adicionar modelos especficos ou condies para
qualquer rea especfica ou disciplina, como gerenciamento de projeto ou anlise.
Segundo o SPEM, um modelo de processos inclui os elementos de processo definido
na Tabela 1 (OMG 2005):
Tabela 1 - Componentes do SPEM
Esteretipo/Conceito Descrio (Adicionar a
descrio das figurinhas)
Notao (colocar as
figurinhas)
Fase tempo entre os maiores
milestones do projeto. Entre a
execuo das fases objetivos e
metas so definidos, artefatos
so criados ou
complementados e decises
so tomadas para a mudana
de fase.

Disciplina uma coleo de atividades na
qual est relacionada uma
maior rea de conhecimento.

Atividade Etapa de um processo que
produz alteraes de estado
externamente visveis no
produto de software. Uma
atividade pode ser
representada por uma entrada,
uma sada e um ou mais
artefatos.

Papel uma funo dentro do
processo, ou seja, um grupo
de responsabilidades,

Pgina 33
privilgios e habilidades que
so requeridas para a
execuo de terminada
atividade;
Produto de Trabalho um artefato consumido,
produzido ou alterado durante a
execuo de uma atividade.
So os subprodutos do
processo, as entradas e sadas
de uma atividade durante o
processo;

Orientaes So documentos que provem
um maior detalhe de
informaes sobre os diversos
detalhes do processo.

Documento um tipo de produto de
trabalho que representa um
arquivo texto.

Modelo UML um tipo de produto de
trabalho que representa um
arquivo texto.

A Figura 3 demonstra como os elementos de um modelo se inter-relacionam para formar
um processo de desenvolvimento de software (J. C. Hauck 2004):

Figura 3 - Inter-relao entre os elementos de um modelo de processo de software (Weber 2002)
3.3 Modelagem de Processo
Pgina 34
A modelagem de um processo uma estrutura que descreve como identificar,
documentar e institucionalizar as atividades envolvidas na construo de produtos de
software. As pesquisas na rea de modelagem de processos propem diversos paradigmas
para sua execuo, no entanto, duas formas de modelagem de processos so amplamente
utilizadas atualmente: a modelagem descritiva, que basicamente descreve o processo que
est sendo analisado e a modelagem prescritiva, que propem um modelo de processos
ideal para a organizao que est sendo analisada (J. C. Hauck 2002) (Mcchesney 1995).
Para que seja possvel documentar, institucionalizar ou at mesmo propor melhorias
em um processo necessrio que haja o entendimento das atividades, papis envolvidos e
de todos os artefatos produzidos na execuo do processo. A modelagem descritiva uma
ferramenta utilizada para identificar como as atividades de desenvolvimento so executadas
e quais as caractersticas envolvidas nos processos de desenvolvimento da organizao
levando em conta o contexto na qual ela est inserida (Weber 2002). A obteno do modelo
descritivo detalha formalmente como as atividades so realizadas no momento em que a
avaliao do processo est sendo executada sem interferncia direta na forma como elas
so ou devem ser feitas. Possibilitando uma viso real do processo atual que permite uma
futura anlise para identificao de erros ou proposio de melhorias (Mcchesney 1995).
Aps a avaliao dos processos das organizaes em muitos casos so constatadas
identificaes de erros e proposio de melhorias, pois o processo modelado no atende a
recomendao de normas de padronizao e melhoria de processos. Nesse caso
necessrio reformular ou readequar suas atividade e papis. A modelagem prescritiva
contempla os modelos prescritos aps a avaliao dos processos institucionalizados nas
organizaes, pois descrevem como o software deveria ser desenvolvido (J. C. Hauck
2002). A modelagem de processos prescritiva pode ser executada de forma manual
baseadas em normas, padres, melhores prticas ou metodologias, ou de forma automtica
apoiada por ferramentas com modelos de processos automticos (Mcchesney 1995).
Diversas so as classificaes de modelagem de processos de software que so
propostas na literatura, no entanto, as etapas da modelagem de processos so
customizadas de acordo com a realidade vivenciada pelas empresas desenvolvedoras de
software.
No caso das MPEs, que so o foco deste trabalho, na maioria dos casos os
processos de desenvolvimento no so documentados e nem conhecidos pelos
participantes da equipe. Dessa forma, necessrio que seja realizada uma avaliao inicial
da cultura e do processo existente na organizao seguida da etapa de elicitao (J. C.
Hauck 2002). Aps essas fases modelos prescritos so sugeridos tomando como base os
Pgina 35
processos avaliados e a literatura que trata a padronizao de processos. Aps a prescrio
do modelo, a documentao e a disseminao do processo devem ser realizadas (J. C.
Hauck 2004). Essa mesclagem das caractersticas da modelagem descritiva e prescritiva
gera um modelo de processo hbrido que utiliza as melhores caractersticas dos dois
modelos com o objetivo de definir um processo de desenvolvimento otimizado que atinja
altos nveis de qualidade levando em conta o contexto no qual a organizao est inserida
(J. C. Hauck 2002).
3.4 Modelos de Processos de Desenvolvimento de Software
3.4.1 Processo Unificado
O processo unificado (PU) o produto final de trs dcadas de trabalho. Seu
desenvolvimento partiu do Objectory Process (1987), via Rational Objectory Process (1997)
at o Rational Unified Process (RUP)(1998). Neste percurso o processo sofreu as mais
diversas influncias, sendo as abordagens de maior impacto as adotadas pela Ericsson e
Rational.
O PU surgiu com o objetivo de definir um processo de desenvolvimento de software
visando construo de sistemas orientados e a objetos (Larman 2004). Ele combina as
melhores prticas estudadas por Booch, Jacobson e Rumbaugh e tem como base a Unified
Modeling Language (UML). Entretanto, as caractersticas que o torna realmente nico
podem ser resumidas em trs aspectos: dirigido a caso de uso, centrado na arquitetura e
iterativo e incremental (Jacobson, Boock e Rumbaugh 1999).
No PU o caso de uso (UC) o ponto central do desenvolvimento.Ele captura os
requisitos funcionais do sistema e fora os engenheiros de software a pensarem em termo
do valor para o usurio e no apenas nas funcionalidades que o sistema deve possuir. Alm
disso, os UCs dirigem todo o projeto de desenvolvimento de software desde seu projeto, at
sua implementao e testes (Jacobson, Boock e Rumbaugh 1999).
A arquitetura de software no PU descreve as diferentes vises do sistema que est
sendo construdo. Ela incorpora os aspectos estticos e dinmicos mais significantes para o
sistema e reflete alm dos casos de uso, as necessidades da empresa e do cliente. A
arquitetura tambm influenciada por fatores como a plataforma de software em que o
sistema executar, os blocos reusveis disponveis, consideraes de implantao,
sistemas legados e requisitos no-funcionais (Jacobson, Boock e Rumbaugh 1999).
Os casos de uso e a arquitetura devem ser desenvolvidos em paralelo e so
interligados na medida em que o produto deva possuir funo e estrutura. A funo
corresponde ao UC e a estrutura arquitetura. Se por um lado os casos de uso, quando
Pgina 36
realizados, devem estar de acordo com arquitetura definida. Por outro, a arquitetura deve
permitir a realizao de todos os casos de uso (Jacobson, Boock e Rumbaugh 1999).
Alm de usar a UML e ser baseado em casos de uso, arquitetura e desenvolvimento
iterativo e incremental, o PU baseado em componentes. E para que esta abordagem
funcione necessrio um processo que leve em considerao ciclos, fases, fluxos de
trabalho, mitigao de riscos, controle de qualidade, gerenciamento de projetos e controle
de configurao. O PU estabelece uma framework que integra todas estas diferentes
caractersticas em um nico modelo de processos customizvel (Jacobson, Boock e
Rumbaugh 1999).
3.4.2 Rational Unified Process
Construdo com base no PU o RUP um processo de engenharia de software
lanado no mercado em 1996 para dar suporte s atividades relacionadas ao ciclo de vida
do processo de desenvolvimento (Barros, Esmeraldo e Silva, Uma Metodologia de
Desenvolvimento Baseada em Componentes Aplicada Modelagem de Sistemas
Embarcados 2006) (Kruchten 2003). Ele descreve todos os artefatos, atividades e papis,
fornece diretrizes e inclui modelos para a maioria dos artefatos (Larman 2004).
O principal objetivo do RUP garantir a produo de softwares de alta qualidade que
atenda s necessidades dos usurios dentro de um oramento e de um cronograma previsto
(Kruchten 2003).
Assim como estabelecido no PU, trs princpios bsicos fundamentam o RUP:
orientao a casos de uso, arquitetura e iterao. O RUP utiliza uma abordagem baseada
em fases e disciplinas e atribui tarefas e responsabilidades dentro de uma organizao
desenvolvedora de software (Kruchten 2003). A Figura 4 ilustra as duas dimenses
abordadas pelo RUP:
Pgina 37

Figura 4 - Grfico das Baleias do RUP (Kruchten 2003)
O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do
processo medida que se desenvolve. Representa os aspectos dinmicos do processo e
descrito por meio de fases, iteraes e marcos. O eixo vertical representa as disciplinas, que
agrupam as atividades de maneira lgica, por natureza, representa os aspectos estticos do
processo e descrito por meio de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papis. Segundo Kruchten (Kruchten 2003), o RUP pode ser utilizado em
diversos tipos de projetos e em empresas de pequeno, mdio e grande porte, devido a sua
flexibilidade e facilidade de configurao.
3.5 Modelos de Processo de Desenvolvimento de Software Embarcado
Conforme descrito no Captulo 02 (Sistemas Embarcados), os problemas do
desenvolvimento de software tradicional so diferentes dos problemas de desenvolvimento
de sistemas embarcados no qual um conjunto mais amplo de requisitos compe o produto
final (Barros, et al. 2005). O ponto crucial do desenvolvimento de sistemas embarcados a
determinao dos muitos desafios da integrao entre software e hardware. Para isso,
diversos modelos de processos para sistemas embarcados foram propostos na literatura. A
sees seguintes apresentam alguns desses modelos.
3.5.1 RUPSE
Lanado no mercado em 2001, o Rational Unified Process for Systems Engineering
(RUPSE) uma ferramenta que oferece s organizaes desenvolvedoras de software uma
estrutura de suporte para facilitar a definio do ciclo de vida de engenharia de sistemas (M.
Cantor 2003) (Cantor, Rational Unified Process for Sytem Enginerring - Anlise e Design de
Pgina 38
Requisitos 2003). Diferente do RUP, que foca no suporte ao desenvolvimento de software, o
RUPSE foca no suporte Engenharia de Sistemas (M. Cantor 2003).
O RUPSE oferece suporte ao desenvolvimento de sistemas em grande escala,
compostos de software, hardware, trabalhadores e componentes de informaes (M. Cantor
2003). Ele fornece solues que inclui um modelo de arquitetura que permite a abordagem
de um conjunto diferente de perspectivas (lgicas, fsicas, informao etc.) (M. Cantor 2003)
Segundo Cantor (M. Cantor 2003), o RUPSE determina projetos que:
1. Necessitem de diversas equipes com desenvolvimento simultneo devido a seu
tamanho.
2. Desenvolvam simultaneamente hardware e software.
3. Sejam complexos o suficiente para possurem problemas de implementao
arquiteturalmente significativos.
Tanto no RUP como no RUPSE, diversos papis so envolvidos no processo de
desenvolvimento, esses papis so desenvolvidos por pessoas que compem a equipe de
desenvolvimento como analistas de requisitos, arquitetos, projetistas, desenvolvedores entre
outros. Alm disso, o ciclo de vida, as iteraes e as disciplinas do RUPE so herdadas do
RUP. No entanto, para suportar a especificao de novas vises da engenharia de
sistemas, o RUPSE inclui novos artefatos, atividades e funes, altera a estrutura de
desenvolvimento do RUP (estrutura 4+1) e utiliza no s a UML 2.0, mas tambm seus
esteretipos (Cantor, Rational Unified Process for Sytem Enginerring - Anlise e Design de
Requisitos 2003).
A especificao do sistema no RUPSE estuda como se espera que o sistema
execute em um determinado contexto. Ou seja, so analisadas caractersticas como as
funcionalidades do sistema que so externamente visveis, os servios fornecidos e as
medidas de eficcia que devem ser atendidas. Dessa forma, realizada uma anlise da
viso e da misso da empresa e da funo do sistema nesse contexto (M. Cantor 2003).
A anlise do ambiente no qual o sistema est envolvido modelada em diagramas
de contexto que estabelecem seu escopo, limites, servios, atributos e comunicaes com
outras entidades. Esses diagramas utilizam esteretipos da linguagem UML para sua
representao grfica (M. Cantor 2003).
3.5.2 IPProcess
O Processo de Desenvolvimento de Soft-Ip (IPProcess) surgiu da necessidade de
criao de uma metodologia que resolvesse os problemas especficos do desenvolvimento
Pgina 39
de software embarcado (Barros, Esmeraldo e Silva, Uma Metodologia de Desenvolvimento
Baseada em Componentes Aplicada Modelagem de Sistemas Embarcados 2006). Para
isso, a abordagem de desenvolvimento baseados em componente (DBC) e a utilizao de
disciplinas na atribuio de tarefas e responsabilidade dentro de uma organizao foram
unificadas em um modelo de desenvolvimento de sistemas embarcados embarcado (Barros,
et al. 2005).
Dessa forma, o IPProcess prope a utilizao de tcnicas da Engenharia de
Software na modelagem de sistemas de software iniciando em uma descrio de hardware
em alto nvel que permite a deteco de erros na fase de Projeto enfocando a qualidade no
final da implementao (Barros, et al. 2005).
A Figura 5 ilustra a arquitetura do IPProcess sob a perspectiva de fases e disciplinas
(Barros, et al. 2005):

Figura 5 - Grfico das Baleias do IPProcess (Barros, Bione, et al. 2005)
As fases do processo so representadas no eixo horizontal e so decompostas
seqencialmente ao longo do tempo: especificao funcional, arquitetura, projeto RTL e
prototipao fsica (Barros, et al. 2005). As duas fases iniciais descrevem o entendimento do
problema (o que deve ser feito) e sua modelagem (como deve ser feito) utilizando a notao
UML e a UML Real Time. O processo de implementao efetivamente iniciado na fase de
Projeto RTL, pelo fato de que necessrio um perodo de tempo para a discusso exaustiva
das funcionalidades, dos requisitos e das possveis arquiteturas que sero utilizadas. A
seguir ser descrito um breve resumo de cada uma das fases do IPProcess (Barros,
Esmeraldo e Silva, Uma Metodologia de Desenvolvimento Baseada em Componentes
Aplicada Modelagem de Sistemas Embarcados 2006):
4. Concepo: Tem como objetivo definir o escopo do sistema (ou componente)
encontrando, entendendo e definindo seus requisitos funcionais e no-funcionais.
Pgina 40
5. Arquitetura: Nesta fase so definidos os componentes da arquitetura e suas
interfaces e construda um prova arquitetural que demonstra que a arquitetura
est estvel e suporta os requisitos identificados na fase de concepo.
6. Projeto : O propsito dessa fase o desenvolvimento de um modelo de
simulao baseado na arquitetura do sistema que utilizado para realizar a
verificar dos componentes da arquitetura.
7. Prototipao Fsica: Nesta fase so construdos os prottipos fsicos que
garantam que o sistema pode ser disponibilizado para seus usurios finais.
O IPProcess composto pelas seguintes disciplinas (Barros, et al. 2005):
8. Requisitos: A disciplina de requisitos possui um maior esforo de execuo na
fase de concepo, com isso, as principais atividades da disciplina so a anlise
do problema, o entendimento das necessidades dos usurios e a definio de
interfaces externas levando em conta os objetivos e as necessidades dos
usurios. Os artefatos produzidos na disciplina de requisitos so o Documento de
Viso, o Glossrio, o Documentos de Requisitos do Usurio, o Modelo de Caso
de Uso e o Documento de Especificao de Requisitos
9. Anlise e Projeto: O principal objetivo da disciplina de anlise e projeto a
elaborao do projeto da arquitetura do sistema e associao de funcionalidades
aos seus componentes, portanto, grande parte do esforo dessa disciplina se
concentra na fase de arquitetura do sistema.
10. Verificao Funcional: Esta disciplina do IPProcess visa validar se os requisitos
foram implementados de forma correta e encontrar defeitos no modelo de
simulao, para isso, um plano de verificao elaborado juntamente com a
execuo dos testes.
11. Prototipao FPGA: O principal propsito desta disciplina transformar o modelo
de simulao em um prottipo fsico e validar se os requisitos foram corretamente
implementados nesse prottipo.
3.5.3 Processo Unificado para Sistemas Embarcados (UPES)
Outro modelo de processos que leva em considerao as caractersticas especficas
dos sistemas embarcados o Processo Unificado para Sistemas Embarcados (UPES). O
UPES norteia o desenvolvimento de sistemas embarcados desde a concepo dos
requisitos at a efetiva implementao do sistema (Riccobene, et al. 2007).
Pgina 41
O UPES baseia-se na abordagem MDA (Model Driven Architecture), onde a
aplicao gerada automaticamente por meio de modelos UML (Unified Model Language).
Seu ciclo de desenvolvimento em Y ilustrado na Figura 6 (Riccobene, et al. 2007). Em um
lado o processo PU tradicional utilizado na definio de um modelo executvel da
aplicao, em outro lado disponibilizada a plataforma de hardware modelada em uma
linguagem prpria para sistema embarcados (UML 2.0 e suas extenses) (Riccobene, et al.
2007). A interseco entre os dois lados une o mapeamento do modelo da aplicao
considerando o modelo da plataforma (Riccobene, et al. 2007). Essa juno realizada por
meio da elaborao de um modelo de mapeamento que refina os requisitos de entrada em
termos de diagramas de componentes e de construo (Riccobene, et al. 2007).
Application Model
Platform Model
Mapping Model
Embedded System
Platform Model

Figura 6 - Grfico Y do Modelo UPES
Os componentes de hardware so mapeados diretamente no modelo de plataforma e
os componentes de software implementados como tarefas que usam servios providos pelo
modelo de aplicao (Riccobene, et al. 2007).
O Processo de Engenharia de Requisitos deste modelo foca especificamente no
Processo Unificado Tradicional, dessa forma, no foi includo nesse modelo nenhuma
adaptao para o contexto de sistemas embarcados.
3.6 Consideraes Finais do Captulo
Este captulo aborda, conceitos relacionados a processos de desenvolvimento de
software e seus modelos apresentados na literatura, alm de tcnicas de modelagem de
processos, suas fases e componentes. Para finalizar, so descritos alguns processos de
desenvolvimento de software tradicionais e especficos para sistemas embarcados.
Pgina 42
A Tabela 2 apresenta uma anlise comparativa dos processos de desenvolvimento
de sistemas embarcados que visa avaliar a efetiva abrangncia das caractersticas
desejadas em um processo de engenharia de requisitos (ER).
Tabela 2 - Comparativo das Caractersticas de ER em Processos de
Desenvolvimento de Sistemas Embarcados
Caracterstica do Processo de ER RUP SE IPProcess UPES
1. H um processo de Engenharia de
Requisitos definido?
S
1
S S
2. A atividade de levantamento de requisitos
realizada?
S S S
3. A atividade de especificao se preocupa
somente com o que ser desenvolvido?
S S S
4. A atividade de design tratada separada da
especificao?
N
2
S S
5. O processo de engenharia de requisitos
possui caractersticas especificas do
desenvolvimento de sistemas embarcados
S N N
6. O processo de engenharia de requisitos
possui a mesma estrutura dos processos
tradicionais?
N S S

Conforme foi observado na descrio do captulo e no comparativo da Tabela 2, os
processos de desenvolvimento de software embarcado se assemelham aos processos
tradicionais. Em muitos deles, o maior enfoque dado no projeto software ficando a
engenharia de requisitos sem adequaes necessrias ao desenvolvimento desse tipo de
sistemas. Dessa forma, identificado como oportunidade de pesquisa, o estudo das
adaptaes necessrias aos processos existentes para que o processo de engenharia de
requisitos possa atender as caractersticas especficas do software embarcado.
O captulo seguinte ir apresentar um detalhamento dos processos de requisitos dos
processos de desenvolvimento propostos na literatura. Sero abordados conceitos
relacionados aos processos de requisitos tradicionais e especficos para o desenvolvimento
de sistemas embarcados
Pgina 43
4. REQUISITOS
Um dos maiores desafios no processo de desenvolvimento de software ainda
atender as expectativas dos usurios. Entender os requisitos de um problema est entre as
tarefas mais difceis enfrentadas por um Engenheiro de Software (Pressman 2006). Por
mais bem definido e otimizado que seja o sistema necessrio esforo, ateno e
experincia por parte da equipe de projeto para entregar ao cliente o que ele deseja e,
realmente, precisa.
O ponto de partida na concepo de sistemas, sejam eles embarcados ou no, a
definio de seus requisitos funcionais e no-funcionais. De acordo com (Hofmann 2001),
requisitos deficientes ainda so a maior causa de falhas nos projetos de software. Capers
Jones descobriu, por meio de pesquisas realizadas com centenas de organizaes, que a
engenharia de requisitos deficiente em mais de 75% das empresas (Jones, 1996, apud
Hofmann, 2001, p. 58.Um estudo realizado por (Gastaldo 2003) demonstrou que cerca de
50% do retrabalho referente ao processo de desenvolvimento de software ocorre nas fases
iniciais de elicitao, anlise e documentao de requisitos, conforme Figura 7.

Causas de Retrabalho
Entendimento do Requisito Projeto Detalhado Interno
Codificao Especificao dos Requisitos do Cliente
Falta de Especif icao Especificao dos Requisitos Internos
Garantia Verif icao de Documento
Antecipao de Projeto Teste Integrado
Produto/Servio de Terceiros Procedimento de Testes Cliente

Figura 7 - Causas de Retrabalho (Gastaldo 2003)
Segundo Gastaldo (Gastaldo 2003), grande parte das causas do retrabalho
relacionada aos requisitos no-funcionais de desempenho. Sua pesquisa revelou que por
no serem levados em considerao desde o incio do projeto, estes requisitos acabam no
Pgina 44
sendo atendidos. Em conseqncia de mudanas de estratgia a fim de inserir um requisito
no-funcional no projetado, h aumento de custo e prazo de entrega.
Em sistemas embarcados a situao no tem se mostrado diferente. Conforme
citado no captulo 2 mudanas na especificao do software e especificaes incompletas
esto entre as maiores causas de fracasso nos projetos. Diante deste contexto, a
Engenharia de Requisitos tem se tornado cada vez mais necessria para resolver os
problemas encontrados nas organizaes com relao definio de sistemas. Elaborar um
processo que preencha as lacunas existentes nas fases de elicitao, anlise,
documentao e validao de requisitos, especialmente os no-funcionais, uma tarefa de
grande importncia para o sucesso dos projetos de sistemas embarcados.
Na seo 4.1 sero apresentados os conceitos bsicos relacionados a requisitos de
software. A seo 4.1.3 descrever os aspectos de requisitos para sistemas embarcados.
Na seo 4.3 podem ser encontradas algumas caractersticas importantes no processo de
Engenharia de Requisitos para sistemas embarcados. J a seo 4.4 abordar as
consideraes finais do captulo.
4.1 Conceitos Bsicos
Nas sees seguintes so apresentados alguns conceitos julgados importantes no
contexto este estudo. Vale destacar que no foram descritos todos os conceitos
relacionados Engenharia de Requisitos, mas apenas aqueles considerados fundamentais
para o bom entendimento da pesquisa.
4.1.1 Requisitos
Um requisito definido como uma propriedade que o sistema deve apresentar a fim
de resolver algum problema do mundo real (IEEE 2001). J Sommerville (Sommerville 1998)
entende requisitos como sendo descries de como os sistemas devem se comportar,
informaes sobre o domnio de aplicaes, restries sobre o funcionamento do sistema,
ou especificaes de propriedades ou atributos do sistema. Ainda segundo ele, os requisitos
so definidos durante os primeiros estgios do desenvolvimento de sistemas como uma
especificao do que deve ser implementado.
Conforme (Sommerville 1998) um requisito pode descrever:
1. Uma funcionalidade em nvel de usurio (ex.: o processador de texto Word
deve incluir um revisor de escrita);
Pgina 45
2. Uma propriedade bem geral (ex.: o sistema deve garantir que nenhuma
informao pessoal estar disponvel sem autorizao);
3. Uma restrio especfica no sistema (ex.: o sistema deve checar a chegada
de mensagens 10 vezes por hora);
4. Como realizar algum clculo (ex.: o clculo do salrio deve ser feito de acordo
com a frmula = (remunerao + comisso) descontos);
5. Uma restrio no desenvolvimento do sistema (ex.: o sistema deve ser
desenvolvido em C++).
Sendo assim, requisitos invariavelmente contm uma mistura de informaes de
problemas, declaraes de comportamento e propriedades do sistema e restries de
projeto e construo. Isto pode causar dificuldades porque as restries de projeto e
construo podem conflitar com outros requisitos. Contudo, esta uma realidade da
Engenharia de Requisitos, ento, o Processo de Engenharia de requisitos deve incluir
atividades para encontrar e resolver os problemas encontrados (Sommerville 1998).
4.1.2 Requisitos Funcionais x Requisitos No-Funcionais
Segundo (IEEE 2001), os requisitos podem variar em seu objetivo e no tipo de
propriedades que representam, podendo, desta forma, ser classificados em:
Requisitos Funcionais: so aqueles que expressam funes ou servios que
um software deve ou pode ser capaz de executar ou fornecer. As funes ou
servios so, em geral, processos que utilizam entradas para produzir sadas
(Cysneiros 2001).
Requisitos No-Funcionais: so requisitos que colocam restries sobre o
produto em desenvolvimento, sobre o processo de desenvolvimento, e
tambm, especificam restries externas ao produto (Figura 8). Normalmente
so determinados pela natureza e tamanho do sistema no qual o software
est inserido.
Pgina 46

Figura 8 Classificao de Requisitos No-Funcionais (Sommerville 1998)
A distino entre este dois tipos de requisitos nem sempre muito clara. Parte da
razo advm para o fato de que os requisitos no-funcionais esto sempre relacionados a
um requisito funcional (Chung 1999). De uma maneira geral, pode-se dizer que um requisito
funcional expressa algum tipo de transformao que tem lugar no software, enquanto um
requisito no-funcional expressa como essa transformao ir se comportar ou que
qualidades especficas ela dever possuir (Cysneiros 2001).
4.1.3 Engenharia de Requisitos
A Engenharia de Requisitos (ER), uma subrea da Engenharia de Software, estuda o
processo de definio dos requisitos que o software dever atender. O processo de
definio de requisitos uma interface entre os desejos e necessidades dos clientes e a
posterior implementao desses requisitos em forma de software (Silva, Implantao de
Melhoria no Processo Engenharia de Requisitos na Empresa Frmula Informtica 2004).
Segundo (Sommerville 1998), a ER um termo relativamente novo que foi inventado
para cobrir todas as atividades envolvidas no descobrimento, documentao e construo
de uma srie de requisitos para um sistema baseado em computao. O uso do termo
Engenharia implica que tcnicas sistemticas e repetidas devem ser usadas para
assegurar que os requisitos do sistema so completos, consistentes, relevantes etc.
Pgina 47
A ER a primeira e mais importante atividade de cunho tcnico no desenvolvimento
de um software (Kondo, Estudo de Requisitos do Software Embarcado no Segmento da
Telemedicina 2006). No entanto, ela trata de conhecimentos no apenas tcnicos, mas
tambm gerenciais, organizacionais, econmicos e sociais (Silva, Implantao de Melhoria
no Processo Engenharia de Requisitos na Empresa Frmula Informtica 2004). A ER
ajuda os engenheiros de software a compreenderem melhor o problema que trabalharo
para resolver, ou seja, o que o cliente quer, como os usurios finais vo interagir com o
software e qual o impacto do software sobre o negcio (Pressman 2006).
As atividades da ER so realizadas no apenas pelos engenheiros de software,
conhecidos tambm como engenheiros de sistema ou analistas, mas tambm por outros
interessados (gerentes, clientes e usurios finais). Todos podem e devem participar da ER
para garantir que o sistema a ser construdo refletir o desejo dos interessados. Afinal de
contas, projetar e construir um software elegante que resolva o problema errado no serve
s necessidades de ningum. Essa a razo pela qual importante entender o que o
cliente deseja antes de comear a projetar e construir um sistema baseado em computador
(Pressman 2006).
Pesquisas realizadas at o momento sugerem que para grandes sistemas de
hardware/software, aproximadamente 15% do oramento total gasto em atividades de ER
(Sommerville 1998). Para sistemas pequenos, que normalmente so apenas software, o
custo com requisitos normalmente menor, cerca de 10% do total do oramento
(Sommerville 1998). O custo com requisitos no baixo, no entanto, as conseqncias de
requisitos errados so ainda maiores:
1. O sistema pode ser entregue fora do prazo e com custo superior ao estimado
inicialmente;
2. O cliente e os usurios finais podem no ficar satisfeitos com o sistema.
Podendo no utilizar algumas funcionalidades ou mesmo decidirem deixar o
sistema de lado por completo;
3. O sistema pode ser de uso no confivel, com erros regulares e com
desastres interrompendo a operao normal;
4. Se o sistema continuar em uso, o custo de evoluo e manuteno
normalmente so altos.
Pgina 48
Vale destacar, ainda, que o custo para consertar erros de requisitos , normalmente,
muito menor do que consertar erros em estgios posteriores do processo de
desenvolvimento. Corrigir problemas de requisitos podem demandar um retrabalho no
projeto, implementao e teste do sistema. Conseqentemente, os custos sero altos.
Estima-se que o custo para corrigir erros de requisitos pode ser 100 vezes maior do que
corrigir um simples erro de programa (Sommerville 1998).
1.1.1.1 Melhores Prticas na ER
De acordo com os estudos de Hofmann (Hofmann 2001), projetos de sucesso tm
uma correta combinao de conhecimento, recursos e processos. A Tabela 3 resume a
relao entre estes trs elementos. Esta tabela apresenta as sugestes de melhores
prticas, de acordo com cada uma das reas foco (conhecimento, recursos ou processo), o
custo de execuo desta prtica (em termos de introduo da prtica e de sua aplicao) e
os benefcios esperados da realizao de tais prticas.
Tabela 3 - Melhores Prticas da ER (Hofmann 2001)
rea Foco Melhores Prticas
Custo de
Introduo
Custo de
Aplicao
Benefcios Chaves
Envolver clientes e
usurios durante a ER
Baixo Moderado
Melhor entendimento
das reais necessidades
Identificar e consultar
todas as origens de
requisitos
Baixo a
Moderado
Moderado
Aprimoramento da
cobertura dos requisitos
Conhecimento
Atribuir as atividades de
ER a gerentes de
projetos e membros da
equipe habilidosos
Moderado
a Alto
Moderado
Performance mais
previsvel
Alocar de 15 a 30% do
total de esforo do
projeto para as atividades
de ER
Baixo
Moderado
a Alto
Manter uma alta
qualidade de
especificao do incio
ao fim do projeto
Prover modelos e
exemplos de
especificao
Baixo a
Moderado
Baixo
Aperfeioar a qualidade
da especificao
Recursos
Manter um bom
relacionamento com os
envolvidos
Baixo
Baio a
Moderado
Satisfazer melhor as
necessidades dos
clientes
Processos Priorizar requisitos Baixo
Baixo a
Moderado
Foco da ateno nas
necessidades mais
importantes dos clientes
Pgina 49
Desenvolver modelos
complementares
juntamente com os
prottipos
Baixo a
Moderado
Moderado
Eliminar inconsistncias
e ambigidades na
especificao
Manter a matriz de
rastreabilidade
Moderado Moderado
Explicitar a ligao entre
requisitos e produtos de
trabalho

Usar reviso por pares,
cenrios e walkthroughs
para validar e verificar os
requisitos
Baixo Moderado
Especificao mais
acurada e alta
satisfao do cliente
Segundo o estudo realizado por Hofmann (Hofmann 2001), a interao com os
envolvidos tem um papel decisivo do incio ao fim dos projetos de sucesso em ER. Os times
de mais sucesso sempre abarcam seus clientes e usurios no processo de ER e, alm
disso, mantm um excelente relacionamento com todos os envolvidos. Ainda de acordo com
as pesquisas de Hofmann (Hofmann 2001), a participao dos usurios o fator mais
importante para o sucesso da ER.
Alm disso, boas equipes de ER tambm identificam as fronteiras do domnio da
aplicao e dos principais envolvidos. E para validar seu entendimento do domnio da
aplicao eles identificam e consultam todo tipo de fonte de requisitos: examinam artefatos
de sistemas, materiais do sistema atual e dos anteriores etc.
Outro fator de grande importncia, segundo (Hofmann 2001), a escolha da equipe
de requisitos. necessrio escolher membros com habilidades no domnio da aplicao, na
tecnologia a ser utilizada e no processo de ER. Tambm indispensvel a escolha de
gerentes de projetos capacitados para a ER. E, quando julgarem necessrio, consultar
especialistas do domnio e envolvidos, a fim de aumentarem o conhecimento da equipe.
Projetos considerados de sucesso tambm alocam uma significativa parcela de
recursos para a ER. Conforme apresentado na Figura 9, Hofmann estima que 28% do total
de recursos do projeto alocado para as atividades de ER. Alm disso, a equipe costuma
ser distribuda de maneira balanceada: 11% do esforo de projeto para elicitao, 10% para
modelagem e 7% para validao e verificao. Para facilitar seu trabalho, normalmente as
equipes utilizam modelos e exemplos de documentos de especificao elaborados em
projetos anteriores (Hofmann 2001).
Pgina 50
Balanceamento da Equipe de ER
72%
11%
7%
10%
28%
Outras atividades Elicitao
Modelagem Validao e Verificao

Figura 9 - Balanceamento da Equipe de ER (Hofmann 2001)
Por fim, Hofmman (Hofmann 2001) destaca que a orientao dos projetos de
sucesso so dadas por requisitos priorizados pelos envolvidos. Isto permite que a equipe
decida quais requisitos devem ser investigados, quando e com que nvel de detalhe. Alm
disso, indispensvel manter a matriz de rastreabilidade dos requisitos. Este artefato
permite o rastreamento de um requisito de sua origem at sua implementao. Ademais,
equipes de sucesso validam e verificam, repetidamente, seus requisitos com mltiplos
envolvidos, utilizando tcnicas como reviso por pares, cenrios e walkthroughs (Hofmann
2001).
4.1.4 Processo de ER Tradicional
No existe um processo nico que seja bom para todas as organizaes. Cada
organizao deve desenvolver o seu prprio processo, que deve ser apropriado para o tipo
de sistema que desenvolve, sua cultura organizacional, o nvel de experincia e habilidade
das pessoas envolvidas na ER. Existem vrias formas de se organizar o processo de ER e
eles no podem ser transferidos de uma empresa para outra. Para definir um bom processo
de ER as organizaes precisam abarcar pessoas que estejam realmente envolvidas na ER,
e, caso julguem necessrios, podem solicitar ajuda de consultores externos a fim de
obterem uma perspectiva mais objetiva do que aquela dos envolvidos no processo
(Sommerville 1998).
Poucas organizaes tm um processo de requisitos explicitamente definido e
padronizado. Muitos dos padres de ER desenvolvidos at o momento envolvem apenas
Pgina 51
sadas de processo, como estrutura de documentos de requisitos. Uma descrio do
processo completo deve incluir quais atividades so realizadas, a estrutura ou agendamento
destas atividades, quem responsvel por atividade, as entradas e sadas destas atividades
e as ferramentas utilizadas para suportar a ER (Sommerville 1998).
De maneira geral, o processo de ER realizado por meio da execuo de sete
funes distintas: concepo, levantamento, elaborao, negociao, especificao,
validao e gesto. importante notar que algumas dessas funes de ER ocorrem em
paralelo e que todas so adaptadas s necessidades do projeto. Todas tentam definir o que
o cliente deseja e servem para estabelecer uma fundao slida para o projeto e a
construo do produto que o cliente receber (Pressman 2006).
No RUP a disciplina que descreve o processo de ER designada apenas como
Requisitos. O fluxo de trabalho desta disciplina (Figura 10) exibe as chamadas habilidades-
chaves necessrias para a execuo eficiente do gerenciamento de requisito, sendo elas:
Analisar o Problema, Compreender as Necessidades do Envolvidos, Definir o Sistema,
Gerenciar o Escopo do Sistema, Refinar a Definio do Sistema e Gerenciar Requisitos
Mutveis. O fluxo de trabalho exibido em ordem lgica e seqencial, embora seja aplicado
em ordem diferente, conforme a necessidade no decorrer do projeto.
Pgina 52

Figura 10 - Fluxo de Trabalho da Disciplina de Requisitos (RUP 2001)
4.1.5 Gerncia de Requisitos
A Gerncia de Requisitos consiste no processo de gerenciar mudanas nos
requisitos do sistema. Afinal, os requisitos de um sistema sempre mudam para refletir as
necessidades de mudanas solicitadas pelos envolvidos, as mudanas do negcio no qual o
sistema dever ser instalado, mudanas nas leis e regulamentaes, etc (Sommerville
1998). Estas mudanas devem ser gerenciadas para garantir que estejam dentro do
oramento e do prazo estipulados.
As principais atividades da gerncia de requisitos so o controle da mudana e a
avaliao do impacto da mudana. Neste sentido, a gerncia de requisitos exige que a
rastreabilidade dos requisitos seja armazenada (Sommerville 1998). Ou seja, ligaes entre
os requisitos, as fontes de requisitos e o projeto do sistema devem ser rastreadas e
guardadas, de maneira que estejam disponveis no momento de avaliar o impacto e
controlar as mudanas do sistema.
Pgina 53
4.1.6 Envolvidos no Processo de Engenharia de Requisitos
Os envolvidos no processo de ER so as pessoas ou organizaes afetadas pelo
sistema e que tm uma influncia direta ou indireta nos requisitos deste sistema
(Sommerville 1998). Os envolvidos incluem usurios finais do sistema, gerentes e outros
envolvidos no processo organizacional influenciados pelo sistema, engenheiros
responsveis pelo desenvolvimento e manuteno do sistema, clientes, etc.
4.1.7 Revises de Requisitos
Revises dos requisitos configuram-se como a tcnica mais utilizada na validao de
requisitos (Sommerville 1998). Elas incluem um grupo de pessoas que lem e analisam os
requisitos em busca de possveis problemas. Algumas das tcnicas utilizadas para este fim
so: a inspeo, o walkthrough e a reviso por pares.
A inspeo consiste na leitura passo a passo do documento, a reviso feita
confrontando-o com uma lista de itens que define o escopo da reviso (lista de verificao).
A equipe de inspeo do projeto geralmente composta de quatro pessoas sendo que uma
delas atua no papel de moderador. J o walkthrough consiste na leitura passo a passo do
documento revisado em uma reunio formal na qual o profissional que elaborou o
documento participa. A principal diferena dos dois mtodos a maneira como a reviso
conduzida, enquanto a inspeo baseada em uma lista de verificao o walkthrough
simula a execuo do programa (Drias 2001).
Outra tcnica de reviso a reviso por pares. Neste mtodo duas pessoas revisam
o produto com o objetivo de discutir pontos crticos a fim de obter benefcios dos pontos de
vista divergentes (Drias 2001).

4.2 Requisitos em Sistemas Embarcados
Sistemas embarcados possuem caractersticas bem especficas no que diz respeito
a seus requisitos. Nas sees seguintes so abordados alguns destes aspectos.
4.2.1 Requisitos No Funcionais
Conforme j foi citado no captulo 2, este tipo de sistema deve obedecer a restries
severas no que diz respeito a requisitos temporais, de peso, tamanho, mobilidade,
segurana, confiabilidade, consumo de energia e memria. Nota-se, portanto, que um dos
maiores desafios no desenvolvimento de sistemas embarcados o atendimento de seus
Pgina 54
requisitos no-funcionais, ou seja, aqueles cuja preocupao no especificamente com a
funcionalidade do sistema (Sommerville 1998).
No entanto, os requisitos no funcionais citados anteriormente no se configuram
como os nicos complicadores do domnio de sistemas embarcados. Um estudo publicado
por (Nars 2002) destaca, ainda, que softwares embarcados possuem propriedades como:
1. Estarem, com freqncia, embutidos em sistemas muito maiores e complexos;
2. Estarem acoplados a um hardware, de maneira que sensores e atuadores so os
responsveis por controlar as atividades;
3. Normalmente, a parte fsica do sistema j est estabelecida, devendo-se adaptar
o software ao hardware existente;
Existe, ainda, a demanda do mercado por produtos de baixo custo e curto prazo de
desenvolvimento (Yamaura 2003). Ou seja, estes softwares, alm de possurem
caractersticas extremamente complexas, devem garantir uma rpida entrega e produtos de
altssima qualidade (S. K. Lee 2007). Ademais, muitos destes produtos so dirigidos
inovao, como no caso de celulares, carros e avies. E neste caso, ser o primeiro a lanar
um produto no mercado garante um lucro superior. Mas isto somente possvel caso o
retorno do investimento exceda os custos de desenvolvimento e produo (Puschnig 2004).
Aliado a estas caractersticas tm-se o fato de que os requisitos no funcionais so
geralmente subjetivos, uma vez que podem ser vistos, interpretados e conceituados de
forma diferente por diferentes pessoas. Apesar dos requisitos funcionais tambm serem
afetados por pontos de vista variados, nos no funcionais este problema potencializado.
Isto ocorre devido ao fato dos requisitos no funcionais serem, por natureza, mais abstratos,
alm de normalmente serem especificados de maneira mais breve e vaga (Cysneiros 2001).
Ademais, requisitos no funcionais freqentemente interagem entre si, j que na tentativa de
satisfazer um requisito pode-se prejudicar ou ajudar a satisfazer outros. Lidar com os
requisitos no-funcionais no uma tarefa fcil, mas seu tratamento vital para a
construo de sistemas embarcados.
Outro aspecto importante no que diz respeito a requisitos no funcionais o fato de
serem descobertos ou tratados tardiamente no projeto. E um dos motivos dos requisitos
no-funcionais no serem definidos e analisados logo no incio do projeto o fato de no
serem cobertos pela maioria dos mtodos de Engenharia de Requisitos (Sommerville 1998).
Pgina 55
A explicao para isto a dificuldade para definir tal tipo de requisitos, e Sommerville
(Sommerville 1998) apontou algumas destas causas:
1. Algumas restries somente so descobertas na fase de projeto;
2. Certas restries so altamente subjetivas, sendo determinadas, apenas, por
avaliaes empricas;
3. Os requisitos no-funcionais tendem a estar relacionados com mais de um
requisito funcional, dificultando a explicitao desta dependncia;
4. Os requisitos no-funcionais tendem a conflitar e contradizer uns aos outros;
5. De uma maneira geral, no existem regras definidas para expressar os requisitos
no-funcionais.
Buscando resolver estes problemas, Gilb (Gilb 1989) sugere a utilizao de um
mtodo para especificao de requisitos no-funcionais denominado PLanguage. A
PLanguage ou Planning Language (Gilb 1989)permite a medio e o teste da qualidade
dos requisitos no-funcionais especificados e possui benefcios como facilidade de
aprendizado e flexibilidade, alm de ser compacta e prevenir omisses atravs de um
conjunto consistente de parmetros de qualidade que podem ser utilizados nas
especificaes (Gastaldo 2003). Sua forma de apresentao composta por um conjunto de
palavras-chave nas quais os requisitos devem ser especificados. Seu formato, atributos e
conceitos so apresentados na Tabela 4 (Gastaldo 2003).
Tabela 4 Definio das palavras-chave da linguagem de especificao PLanguage (Gastaldo 2003)
Palavras-Chave Descrio
Tipo Etiqueta, rtulo, identificador persistente e nico do requisito
Descrio
Descrio simples e breve do conceito principal ou significado
geral do requisito
Stakeholder Envolvidos/Afetados pelo requisito
Escala Escala usada para quantificar o requisito
Mtrica Processo ou mtodo para medir escalas dos requisitos
Mtodo Mtodo para medir a escala
Freqncia Freqncia para medio
Responsvel Pessoas/Departamento responsvel por fazer as medies
Pgina 56
Registro Onde/Quando as medidas devem ser reportadas
Nvel Mnimo O nvel mnimo requerido para evitar falhas
Plano Nvel para obter sucesso exigido
Nvel Sucesso Como prolongar, aumentar, alongar o sucesso
Nvel Desejado
Nvel desejvel de sucesso que no pode ser atingido atravs
dos mtodos atuais
Histrico Resultados anteriores para comparao (histrico)
Tendncia Tendncia histrica
Histrico de Sucesso O melhor resultado obtido
Definio Definio oficial do termo
Autoridade Pessoa, grupo ou nvel de autorizao
Como pode ser visto na Tabela 4, o formato da PLanguage claro para qualquer
integrante do projeto. A utilizao deste mtodo tem como objetivo resolver os problemas de
falta de tcnicas para o levantamento de requisitos, falta de detalhamento e clareza nas
especificaes, confuso entre requisitos funcionais e no-funcionais e a falta de formatao
e apresentao. Alm disso, o PLanguage ainda tem a vantagem de os testes poderem ser
feitos com base na prpria especificao, eliminando o trabalho da elaborao de um
documento de especificao e outro de testes (Gastaldo 2003).
4.2.2 Requisitos de Hardware x Requisitos de Software
Outro ponto importante, no que se refere aos requisitos em sistemas embarcados,
a difcil separao, durante a modelagem de requisitos, entre o hardware e o software, uma
vez que esto profundamente acoplados e so altamente interativos (Nars 2002). Os
softwares de sistemas embarcados normalmente controlam componentes de hardware que
esto dentro dos limites do prprio sistema em desenvolvimento (Nars 2002).
4.2.3 Inveno de Requisitos
comum, na Engenharia de Software, a assertiva de que os fornecedores de
requisitos muitas vezes no sabem ou no conseguem expressar o que esperam do
sistema. Em sistemas embarcados esta uma realidade com a qual os engenheiros de
software devem lidar com freqncia ainda maior, visto que so responsveis pela
construo de celulares, eletrodomsticos, carros e avies de ltima gerao. E criar novos
Pgina 57
produtos requer a inveno de novos requisitos, requisitos estes que nem mesmo os
envolvidos sabem ainda quais so. E papel dos engenheiros de requisitos inventar
alguma coisa melhor (Robertson, Eureka! Why Analysts Should Invent Requirements 2002).
Isto exige, alm de criatividade, um profundo conhecimento, por parte da equipe, a cerca do
domnio do negcio (Puschnig 2004).

4.3 Processo de ER para Sistemas Embarcados
Se, conforme apontado por (Sommerville 1998) poucas organizaes tm um
processo de requisitos explicitamente definido e padronizado, processos de ER especficos
para sistemas embarcados so ainda mais difceis de encontrar. A literatura sobre o assunto
restrita, de maneira que no foi possvel encontrar sequer uma fonte que definisse um
processo completo de ER para sistemas embarcados. O nico estudo que se aproximou do
procurado foi um inventrio publicado por (Graaf 2003).
Diante desta dificuldade a presente seo foi dividida de acordo com os assuntos
abordados nas diversas fontes consultadas. Tendo sido descritas, em cada tpico, as
prticas mais comuns utilizadas durante o processo de ER para softwares embarcados.
4.3.1 Contexto das Empresas Desenvolvedoras de SE
Um estudo bastante abrangente em relao ao desenvolvimento de softwares
embarcados foi publicado por Graaf (Graaf 2003). De acordo com este inventrio realizado
em trs pases europeus, envolvendo sete companhias e um instituto de pesquisa, a maioria
das companhias que desenvolve softwares embarcados no os vende. Eles vendem, na
realidade, telefones celulares, CD players e outros produtos. O software nestes produtos
constitui apenas uma parte, certamente importante, do produto como um todo. No entanto,
quanto mais transparente e acoplado ao hardware ele for, mais invisvel ele ser do ponto
de vista do produto (Henzinger 2007). Na realidade, os softwares somente so visveis
atravs dos aprimoramentos nas funes e na performance dos produtos (Henzinger 2007).
Alm disso, grande parte das empresas possui um desenvolvimento dirigido ao
hardware, ou seja, apenas quando o hardware j est em um estgio avanado de
desenvolvimento que o software comea a ser desenvolvido (Graaf 2003). Isto significa
que o software deve, necessariamente, adaptar-se ao hardware construdo. Este aspecto
revelou-se um problema, na medida em que muitas dificuldades que poderiam ser
resolvidas no domnio do hardware acabam solucionadas pelo software (Graaf 2003). E esta
Pgina 58
situao pode ser agravada com a freqncia cada vez maior do modelo de negcios
horizontal, onde a responsabilidade da produo de um novo projeto distribuda entre
companhias distintas (Sangiovanni-Vincentelli 2004). O software assume, assim, o papel de
integrador dos diversos componentes.
Outra conseqncia, observada por (Graaf 2003), deste desenvolvimento orientado
ao hardware que em algumas companhias os arquitetos de software no eram sequer
envolvidos nas decises de projeto em nvel de sistema. Os desenvolvedores de softwares
embarcados sentiram que isto estava se tornando um problema srio e, em funo disto,
muitas companhias esto mudando, de maneira que os arquitetos de software esto cada
dia mais envolvidos nas decises em nvel de sistema.
Dado o contexto em os softwares embarcados esto inseridos, no de se
surpreender que o ele seja, hoje, a parte mais cara e menos confivel das aplicaes de
sistemas embarcados (Henzinger 2007).
4.3.2 Processos de Desenvolvimento de SE Sob o Ponto de Vista da ER
De acordo com as pesquisas de (Graaf 2003), o modelo mais comum de processo de
desenvolvimento de sistemas embarcados utiliza uma abordagem top-down. Ou seja, nestes
modelos as refinaes de requisitos e arquitetura so realizadas em vrias iteraes
subseqentes, partindo do nvel de sistemas at chegar ao nvel de componente. A Figura
11 apresenta este modelo.
Pgina 59
Requisitos
Arquitetura
Requisitos
Arquitetura
Requisitos
Arquitetura
Requisitos
Arquitetura
Requisitos
Arquitetura
Requisitos
Arquitetura
Requisitos
Arquitetura
...
...
Projeto de Arquitetura
Sistema
Subsistema
Componente
Anlise de Requisitos
Requisitos
Arquitetura

Figura 11 - Decomposio do processo de desenvolvimento de sistemas embarcados (Graaf 2003)
J a metodologia de especificao de requisitos elaborada por (Lattemann 1997)
consiste de cinco passos. Em cada passo as caractersticas relevantes do sistema para
aquele passo so adicionadas especificao de requisitos, conforme representado na
Figura 12.
Pgina 60
Requisitos
Requisitos
Projeto
(Refinado)
Sistema
Controlador
Requisitos
Projeto
(Alto Nvel)
Componente
Requisitos
Componente
Requisitos
...
Especificao de Requisitos
...
Componente
Especificao de Requisitos
Realizao e
Implementao
Software de Controle

Figura 12 - Processo de Especificao de Requisitos (Lattemann 1997)
Neste processo (Lattemann 1997) defende que primeiro devem ser descritos os
requisitos do sistema como um todo, sem considerar os possveis erros e falhas. Para
facilitar esta etapa (Lattemann 1997) sugere que o sistema seja dividido em componentes e
que sejam criadas conexes entre estes. A prxima etapa a especificao dos requisitos
do controlador, definindo-se as interfaces entre hardware e software. Depois construdo o
projeto em alto nvel e, por fim, este projeto refinado, podendo-se partir para a realizao e
implementao.
Neste ponto, a abordagem de especificao de requisitos elaborada por (Lattemann
1997) no se distancia muito do processo genrico desenhado por (Graaf 2003). Pois,
apesar de no utilizarem os mesmos termos, em ambos o sistema divido em sistemas
menores e a especificao refinada em etapas.
Pgina 61
Por outro lado o processo de elicitao e especificao de requisitos utilizado por
(Nars 2002) toma como base a tcnica de caso de uso e possui 7 etapas principais,
conforme ilustrado na Figura 13.
Definir Sistema
Elaborar
Documentos
Descrever os
Casos de Uso
Criar Modelo de
Casos Uso
Encontrar Atores
Sistema
Definir
Requisitos de
Qualidade
Encontrar Casos
de Uso

Figura 13 - Interao indireta entre o piloto e um caso de uso do TRCS (Nars 2002)
O primeiro passo desta abordagem a definio do sistema, que tem por objetivo
restringir o escopo e entender o sistema a ser construdo. A segunda etapa consiste na
especificao dos requisitos de qualidade, onde devem ser definidas explicitamente as
restries do sistema. Daqui em diante o processo de (Nars 2002) muito se assemelha aos
processos tradicionais de ER: so encontrados os atores, os casos de uso, construdo o
modelo de caso de uso e so elaborados os documentos do sistema.
O diferencial desta abordagem o fato de (Nars 2002) defender para encontrar os
casos de uso o adequado trabalhar baseado em funes e no em atores. Alm de
proporcionar maior flexibilidade, esta tcnica permite que se encontre com maior habilidade
todos os casos de uso funcionais do sistema. Nars (Nars 2002) ressalta ainda que muito
cuidado deve ser tomado a fim de identificar apenas o que necessrio para o sistema em
especificao, pois, no domnio de softwares de controle de sistemas embarcados um
grande desafio levantar apenas as funcionalidades do sistema a ser construdo, dada a alta
interatividade entre ele e os demais sistemas envolvidos. Alm disso, (Nars 2002) aconselha
que seja utilizado um processo iterativo e progressivo de refinamento.
Como pode ser visto, diferentemente das abordagens de (Lattemann 1997) e (Graaf
2003), Nars (Nars 2002) no divide a especificao de requisitos em subsistemas ou separa
as especificaes de hardware e software. Pelo contrrio, Nars defende a especificao do
sistema como todo, dada a difcil separao de hardware e software no contexto de
sistemas embarcados (Nars 2002).
4.3.3 Metodologias para Especificao dos Requisitos em SE
Pgina 62
De acordo com (Graaf 2003) a UML ainda no uma prtica comum, mas muitas
empresas j tm considerado sua possibilidade de aplicao na ER. Mesmo no tendo
adotado a UML como padro, muitos projetos utilizaram diagramas para representar
requisitos cujas formas, em sua maioria, lembravam o estilo de diagrama da UML ou outras
notaes.
Ainda segundo (Graaf 2003), as construes mais utilizadas pelas companhias foram
os casos de uso. No entanto, alguns projetos chegaram a usar diagramas de seqncia
para realizar os casos de uso, outros aplicaram diagrama de classes para modelar o
domnio. Mas em muitos casos a interpretao das notaes UML no estava muito clara.
Neste aspecto, (Puschnig 2004) defendem a utilizao da tcnica de caso de uso,
pois de acordo com suas pesquisas, a modelagem por casos de uso foi de grande valia para
o entendimento inicial do sistema, por parte dos especialistas, mesmo quando estes
modelos ainda eram incompletos ou incorretos, uma vez que serviam como base para as
discusses.
Apesar dos inmeros benefcios apontados pela literatura em relao utilizao de
casos de uso, (Nars 2002) ressalta que a aplicao desta tcnica em um caso real da
indstria de sistemas embarcados revelou certa confuso pelas seguintes razes: a tcnica
de caso de uso carente de definies apropriadas para a adaptao a sistemas
embarcados, falta uma clara definio do processo de aplicao prtica da tcnica de caso
de uso e as relaes entre requisitos e casos de uso no claras o suficiente.
Buscando resolver estas questes, (Nars 2002) no apenas props, mas aplicou em
um sistema do ramo avinico, algumas adaptaes na tcnica de caso de uso a fim de
adequ-la ao universo de sistemas embarcados, conforme descrito na seo 2.2.2
No entanto, antes de definir o processo de elicitao e especificao de requisitos
baseado em casos de uso, (Nars 2002) esclarece como so interpretados os principais
construtores da tcnica de caso de uso ao adaptar esta tcnica ao domnio de sistemas
embarcados. Tomando como base os principais construtores da tcnica de caso de uso
Figura 14 o autor destaca que:
Pgina 63

Figura 14 - Os principais construtores da tcnica de caso de uso (Nars 2002)
mais apropriado considerar como sistema a composio de ambos,
hardware e software, visto que muito difcil separ-los durante a modelagem
de requisitos;
Um ator representa o papel de uma entidade externa e no a prpria entidade
externa, ressaltando-se que uma entidade pode ser qualquer coisa, humana
ou no (outros sistemas, software ou hardware, uma tempestade, um
pssaro, etc.);
Um ator est situado fora da fronteira do sistema a ser modelado;
Um ator deve interagir diretamente com o sistema a ser modelado;
Um caso de uso pode ser iniciado internamente pelo sistema, no sendo
necessria a interveno de um ator. Esta adaptao visa atender
peculiaridade de que em softwares de controle de sistemas embarcados a
maioria das funes de controle realizada sem que haja uma entrada
externa;
Um caso de uso pode descrever funcionalidades internas de um sistema e
no apenas seu comportamento externo;
Muitas vezes durante a elicitao de requisitos os autores sentiram a
necessidade de modelar uma interao temporria entre uma ator e um caso
de uso. Em um avio, por exemplo, o piloto o ator responsvel por controlar
todo o hardware do avio, no entanto, caso se esteja modelando apenas o
sistema de controle do reverso (designado TRCS) do avio, o piloto realizar
a interao atravs de outros sistemas do avio. Para resolver esta questo
foi criada a ligao indireta entre caso de uso e ator, conforme pode ser
observado na Figura 15.
Pgina 64

Figura 15 - Interao indireta entre o piloto e um caso de uso do TRCS (Nars 2002)
4.3.4 Envolvidos no Processo de ER para SE
Outro complicador comum no desenvolvimento de sistemas embarcados a participao de muitos
envolvidos, e isto ainda mais notrio durante a ER. A
Figura 16 apresenta os envolvidos encontrados com mais freqncia no processo de
ER de acordo com o inventrio de Graaf (Graaf 2003). Segundo (Graaf 2003), na primeira
fase da ER o cliente determina os requisitos funcionais e no funcionais, e, dependendo do
domnio do produto, estes requisitos so negociados entre o cliente e as reas de marketing
e venda ou mesmo diretamente com os desenvolvedores. Ou seja, o Engenheiro de
Requisitos no aparece no momento da negociao.
Requisitos dos
Envolvidos
Envolvidos
Fornecedores
Engenharia de Requisitos
Sistemas Legados
Reguladores
Padres
Contexto
Clientes/Usurios
Marketing Fabricao Manuteno

Figura 16 - Envolvidos do desenvolvimento de sistemas embarcados (Graaf 2003)
Um estudo realizado por (Puschnig 2004) identificou que, para o sucesso da ER do
domnio de SEs, alm do ncleo da equipe de desenvolvimento formada por engenheiros de
requisitos, analista de processo, programadores, etc., necessrio o envolvimento de
Pgina 65
especialistas de diferentes domnios. Isto se faz necessrio em virtude do pouco
conhecimento que os envolvidos muitas vezes possuem acerca do sistema a ser
desenvolvido. A soluo encontrada, portanto, foi o envolvimento de especialistas nas mais
diversas reas.
Em sua maioria, os especialistas requisitados estavam associados a uma rea
especfica de conhecimento: desenvolvedores, professores, gerentes, engenheiros de
produo, consultores e fornecedores. Os engenheiros de software e os especialistas
trabalhavam em conjunto, de maneira que os primeiros possuam uma concepo do
sistema como um todo, ao passo que os segundos tinham o conhecimento detalhado de um
ou mais aspectos tcnicos. No entanto para definir qual especialista ser necessrio e em
que momento dever ser requisitado necessrio, em primeiro lugar, estabelecer as
fronteiras do sistema.
Com tantas pessoas envolvidas no projeto fica complicado gerenciar os diferentes
requisitos provenientes de todas estas fontes. Esta caracterstica marcante,
especialmente, em projetos grandes (Graaf 2003). Ademais, normalmente muitos dos
especialistas requisitados no esto situados em um mesmo local e nem esto disponveis a
todo o momento, visto que podem estar alocados em mais de um projeto. Portanto, papel
do gerente de projeto prover os arranjos necessrios para garantir o efetivo e eficiente
envolvimento dos membros do projeto (Puschnig 2004).
4.3.5 Modelos de Documentos para Especificao dos Requisitos em SE
Segundo (Graaf 2003), as companhias estudadas normalmente especificavam seus
requisitos em linguagem natural, registrando as informaes em processadores de texto.
Normalmente utilizam modelos para estruturar os documentos, assim teriam um guia do que
devia ser levantado. No entanto, nem todos os projetos de uma mesma companhia
utilizavam os modelos, de maneira que podiam ser encontrados diferentes modelos de
documentos dentro de um mesmo projeto.
Como nos softwares embarcados as propriedades no funcionais so, geralmente,
de grande importncia, a expectativa era de que os modelos desenvolvidos pelas empresas
estudadas por (Graaf 2003) reservassem uma seo apenas para requisitos no funcionais,
mas no foi o que se observou. Alguns projetos ainda chegaram a especificar
caractersticas como restries de tempo-real em documentos separados, mas de maneira
geral, estes e outros requisitos como consumo de energia e memria no eram
explicitamente especificados e projetados.
Pgina 66
4.3.6 Gerenciamento de Requisitos em SE
Outro complicador destacado por (Graaf 2003) o fato de muitas companhias
construrem projetos em cima de projetos anteriores. Ou seja, estes projetos reutilizavam as
especificaes de requisitos, mesmo para o desenvolvimento de uma nova linha de produto.
Conseqentemente, deixar a documentao de requisitos consistente uma tarefa rdua,
pois para deixar todos os produtos e documentos do desenvolvimento consistentes,
preciso analisar precisamente o impacto de novas caractersticas. No entanto, os projetos
estudados freqentemente no explicitavam as relaes entre requisitos, ento a anlise de
impactos era muito difcil. Rastrear os requisitos era difcil por que as relaes (por exemplo,
entre requisitos e componentes arquiteturais) eram muito complexas para serem
especificadas manualmente e as ferramentas de gerenciamento de requisitos disponveis
no pareciam resolver este problema, apesar de algumas verses customizadas
funcionarem em alguns casos.
Esta rastreabilidade um aspecto essencial do gerenciamento de requisitos, visto
que entender os riscos associados ao impacto do software em seu ambiente fundamental
para assegurar a dependabilidade e a segurana no funcionamento de sistemas
embarcados. Infelizmente, a anlise de risco de sistemas embarcados tem sido
negligenciada e apenas recentemente tem recebido ateno da comunidade de engenharia
de software (Hewett 2005).
4.3.7 Outros Aspectos Importantes no Processo de ER para SE
O estudo realizado por (Puschnig 2004) em dois projetos da Daimler Chrysler revelou
outros dois aspectos, ainda no abordados at o momento, que se mostraram de grande
importncia para o sucesso da ER no domnio de sistemas embarcados:
Orientao a objetivos: abordagens orientadas a objetivos so comuns na
literatura, mas em sistemas altamente inovadores como os embarcados esta
abordagem essencial para descrever apropriadamente o sistema. To
importante quanto a orientao a objetivos a utilizao de camadas de
abstrao, visto que muito difcil solicitar aos especialistas que discorram
sobre suas ideais de maneira mais abstrata.
Revises: as revises revelaram-se uma maneira de completar a
especificao de requisitos e de elevar os requisitos a um nvel confivel e
maduro. Uma conseqncia das revises, no entanto, a quantidade de
Pgina 67
tempo gasta em cada uma, visto que segundo suas pesquisas, os autores
chegaram a despender um dia inteiro ou at mais em cada reviso.
Entretanto, as revises aparecem como uma oportunidade para capturar e
consolidar os requisitos com a ajuda dos especialistas, ou seja, mais uma
chance de realizar um trabalho efetivo e de exercitar a sinergia.
(Puschnig 2004) sugerem que durante as revises sejam executadas as
seguintes tarefas: coleta dos comentrios gerais sobre a compreenso,
estruturao e apresentao do documento de especificao inspecionado.
Estes comentrios devem ser consolidados e de acordo com a relevncia
deve ser feito um ranking, de maneira que possam ser negociados e
documentados. Como sada desta etapa deve ser gerado um relatrio de
reviso com os comentrios e a concordncia de todos os envolvidos.
4.4 Consideraes Finais
Conforme exposto neste captulo, sistemas embarcados no possuem processos
definidos e institucionalizados para ER. Alm disso, as abordagens para a levantamento e
especificao de requisitos apresentadas mostraram-se inadequadas para o contexto deste
tipo de sistema. De maneira que estes processos no conseguiram resolver ou minimizar as
dificuldades no desenvolvimento de softwares embarcados.
O captulo a seguir apresentar a abordagem GQM. Este mtodo ser utilizado na
elaborao dos objetivos, questes e mtricas da avaliao a ser submetida s empresas
participantes do programa de medies. A gerao dos indicadores a partir das informaes
coletadas nesta pesquisa permitir a criao de um processo que melhor se adapte
realidade das MPEs desenvolvedoras de softwares embarcados.
Pgina 68
5. ABORDAGEM GQM
Conforme descrito no Captulo 03, o aumento dos custos e da complexidade de
desenvolvimento de sistemas aliados a necessidade de ampliao da competitividade das
organizaes, tem levado a uma exigncia cada vez maior pela qualidade dos softwares
produzidos (Farias 2006)
Alm da dificuldade de se desenvolver software com qualidade a identificao dos
problemas que ocorrem durante o desenvolvimento do produto de baixa qualidade um
ponto extremamente custoso para as empresas. Para melhorar a qualidade dos sistemas
desenvolvidos necessrio entender os recursos, processos e os produtos e seus impactos
na organizao. Isso requer que a empresa capture conhecimento do desenvolvimento de
software (por meio da aplicao de programas de medies ou utilizao de bases de
conhecimento) e o aplique no planejamento,. controle e melhoramento de seus processos e
de seus projetos (Wangenheim e Ruhe 1999).
A abordagem GQM um mtodo de especificao de programas de medio de
software que permite que as informaes obtidas sejam utilizadas para acompanhamento do
alcance dos objetivos traados para o programa (Goethert e Fischer 2003).
Este captulo aborda conceitos relacionados ao mtodo GQM. A seo 5.1 descreve
o modelo GQM e seus nveis, e identifica suas fases. As sees 5.1.1, 5.1.2, 5.1.3, 5.1.4,
5.1.5 descrevem em detalhes as fases do modelo GQM, suas atividades e os produtos
gerados. Por fim, a seo 5.2 descreve as consideraes finais do captulo.
5.1 O Mtodo Goal Question Metric (GQM)
A metodologia GQM foi originalmente concebida durante as dcadas de 70 e 80 por
Victor Basili e David M. Weiss, posteriormente foi estendida e formalizada por Rombach e
sua equipe (Basili e Rombach 1994). Proposta com o objetivo de avaliar defeitos em
projetos no Centro Espacial da NASA, a metodologia GQM tem expandido sua utilizao
para um grande contexto de aplicaes na rea de Engenharia de Software, principalmente
por se adaptar facilmente para a avaliao de qualquer tipo de problema (Basili e Rombach
1994) (Kopanas, Sylaidis e Nakakis 1997). Andrade e Souza , por exemplo, propem a
definio de um modelo de mtricas que avalie processos de software (Anquetil, Oliveira e
Souza 2005). Soligen e Bergouth (Berghout e Solligen 1999), apresentam estudos para
utilizao do GQM na definio de um modelo de mtricas, alm de vrias outras propostas
de utilizao da metodologia (Anquetil, Oliveira e Souza 2005) (Basili e Rombach 1994).
Pgina 69
O principal objetivo da metodologia GQM fornecer e caracterizar um melhor
entendimento dos processos, produtos, recursos e ambiente para estabelecer bases para
comparaes com trabalhos futuros ou at mesmo com metas (ndices) de mercado
(Anquetil, Oliveira e Souza 2005). Portanto, podemos defini-la como uma abordagem
sistemtica que define e integra objetivos a modelos de processo, produtos e servios sob a
perspectiva de qualidade baseada em necessidades especficas dos projetos e das
organizaes atravs de um programa de medies (Gladcheff, Sanches e da Silva 2001).
O GQM amplamente citado na literatura como um mecanismo eficiente utilizado
para planejar e definir objetivos da medio e avaliar produtos e processos de software, pois
uma abordagem de mensurao que orientada pela avaliao orientada a objetivos
(Gladcheff, Sanches e da Silva 2001) (Ramos 2004).O princpio da metodologia GQM a
definio de um ou mais objetivos que servem de rota para a definio de questes que
orientam a elaborao de mtricas para avaliao dos objetivos especificados (Anquetil,
Oliveira e Souza 2005). O modelo GQM parte do princpio que a implementao de metas
operacionais e mensurveis para melhoria de software deve seguir uma abordagem top-
down, no entanto a interpretao dos dados coletados durante a avaliao deve seguir a
abordagem bottom-up (Wangenheim e Ruhe 1999). Portanto, a abordagem estabelece que
primeiramente os objetivos devem ser traados para que posteriormente sejam definidas
suas questes e mtricas para avaliao. Sendo assim, pode-se subdividir o processo em
trs nveis distintos (Basili e Rombach 1994):
Conceitual (Goal): Definio do objetivo (produto, processo ou servio) para
uma variedade de questes, propsito da aplicao do GQM (ex.: melhorar,
caracterizar ou controlar), foco de qualidade (caractersticas de qualidade), ponto
de vista (interessados na aplicao do GQM) e ambiente (contexto para
aplicao do resultado).
Operacional (Question): Definio do conjunto de questes em linguagem
natural propostas para caracterizar a forma de avaliao para um objetivo
especfico definido no nvel conceitual.
Quantitativo (Metric): Definio do conjunto de mtricas associadas a cada
questo que especificam em termos quantitativos e avaliveis as informaes
que se deseja obter durante a avaliao.
Pgina 70
Segundo (Anquetil, Oliveira e Souza 2005) apud (Berghout e Solligen 1999), a
implantao do modelo GQM realizada em quatro fases, que sero descritas nas sees a
seguir. A Figura 17 ilustra as os dados produzidos em cada uma das fases do modelo GQM:
Figura 17 - Fases da Abordagem GQM (Berghout e Solligen 1999)

5.1.1 Planejamento
Nesta fase so realizados estudos e definies iniciais para introduo do programa
de avaliao. Suas principais atividades so a coleta de todas as informaes necessrias
para o incio da avaliao, a designao, o treinamento e a motivao da equipe que ir
participar do GQM, a seleo da rea a ser melhorada, a identificao dos projetos que iro
participar da aplicao do mtodo, a identificao de quando e como os dados sero
coletados e a criao do Plano de Projeto. A fase de planejamento pode ser subdividida em
quatro sub-fases (Laboratory s.d.):
4. Definio da equipe GQM: Alguns pontos devem ser levados em considerao
quando a equipe definida: a equipe deve ser capaz de definir objetivos e
melhorias orientada pelo planejamento do projeto, o planejamento da coleta de
dados deve ser elaborada e a equipe deve ser treinada para a interpretao dos
dados.
5. Seleo da rea de melhoria: Nessa fase diversas reas processos ou produtos
de software devem ser selecionadas. A escolha da rea de melhoria deve ser
realizada levando em considerao o negcio, os objetivos, os custos, o tempo
os riscos e a qualidade da avaliao. Outros detalhes como problemas que
podem ocorrer durante o processo de avaliao, influncias externas, pessoas,
processos e produtos envolvidos e conhecimento prvio das pessoas que esto
Pgina 71
envolvidas no projeto sobre o processo de medio devem ser levados em conta
na elaborao da lista de seleo.
6. Seleo do projeto e definio da equipe de projeto: A equipe GQM deve alinhar
a equipe de projetos selecionada para a medio, com o objetivo de mant-los
cientes dos princpios do GQM enfatizando suas principais caractersticas.
7. Elaborao do Plano de Projeto: o Plano de Projeto elaborado por meio de
informaes da equipe de projeto, o documento deve possuir:
o Programa de Medies: Breve descrio do Plano de Projetos.
o Introduo: Apresenta uma viso geral do programa de medies e
contm uma descrio de como os objetivos de melhoria so traduzidos
em objetivos de projetos de desenvolvimento de software.
o Programao (cronograma): Descrio completa das tarefas planejadas,
quais formulrios sero utilizados e que momento sero aplicados,
resultados que devem ser obtidos e os custos e benefcios esperados.
o Organizao: Define os objetivos da organizao que so relevantes no
programa de medies.
o Gerenciamento dos Processos: Contm os procedimentos de
comunicao, as prioridades e descries das atividades de controle de
riscos.
o Treinamento e Promoo: Define como ser o processo de treinamento e
de divulgao do programa de medies.
5.1.2 Definio
Nesta etapa so definidos e documentados os objetivos, questes, mtricas e
hipteses. A definio do programa de medies composta das seguintes dimenses
(Gladcheff, Sanches e da Silva 2001):
Objeto de Estudo: O que ser analisado.
Objetivo: Envolve quatro aspectos o propsito da anlise (determinar,
caracterizar, melhorar ou controlar alguma caracterstica do objeto de medida),
foco de qualidade (qual atributo do objeto ser avaliado), ponto de vista (identifica
Pgina 72
quais os interessados pelo resultado da pesquisa), e contexto (em qual ambiente
est localizado).
Questes: Conjunto de perguntas que expressam a forma de se obter
informaes em uma linguagem natural cujas respostas devem estar de acordo
com os objetivos.
Mtricas: Conjunto de medidas que especificam em termos quantitativos e
avaliveis, as informaes que se deseja obter durante as avaliaes.
A fase de definio pode ser subdividida em nove sub-fases (Laboratory s.d.):
8. Definio dos Objetivos da Medio: Nesta fase os objetivos da medio devem
ser formalmente definidos e estruturados. A Tabela 5 define algumas questes
relevantes na definio dos objetivos de medio:
Tabela 5 Questes de Definio dos Objetivos da Medio (Laboratory s.d.)
Qual? o objeto que ser avaliado.
Por qu? entender, controlar e melhorar o objeto de
medio.
Qual aspecto? qual o foco da qualidade ser avaliado no
objeto de medio.
Quem? as pessoas que avaliam o objeto de
medio.
Contexto. o ambiente no qual o objeto de medio
ser avaliado.
9. Definio do Modelo de Processos de Software: Nesta etapa podem ser
utilizados modelos de processos de software existentes ou podem ser criados
novos modelos. O modelo proposto deve ser completo e consistente de acordo
com as definies do processo de medies.
10. Entrevistas GQM: A comunicao entre os perfis interessados na medio
essencial para o sucesso do programa. A extrao de informao dos membros
do projeto comumente realizada, por meio de entrevistas individuais que podem
ser guiadas por diagramas chamados abstract sheets que estruturam as
informaes a serem coletadas de forma que a equipe possua um ponto inicial
para o refinamento das questes e mtricas conforme descrito a seguir (Berghout
e Solligen 1999) (Ramos 2004) e ilustrado na Tabela 6:
Pgina 73
o Foco da qualidade: coleta e formalizao das possveis mtricas a serem
utilizadas na medio do objeto selecionado.
o Linhas de base das hipteses: coleta e formalizao dos envolvidos no
programa mtricas da sua opinio sobre os possveis resultados de cada
uma da mtricas registradas (nesse caso comum utilizar percentuais).
o Fatores de variao: coleta e formalizao dos fatores que podem
influenciar os resultados da medio.
o Impacto nas linhas de base das hipteses: formalizao do impacto e
influncia dos fatores de variao nos resultados das mtricas
registradas. Definio da dependncia entre os fatores de variao e as
mtricas.
Tabela 6 - Abstract Sheets (Berghout e Solligen 1999)
Objeto Propsito Foco da
qualidad
e
Ponto de
vista
Foco da qualidade Fatores de variao
Linha de base Impacto nas linhas de base
11. Definio de Questes e Hipteses: As questes a serem definidas devem prover
a correta interpretao dos objetivos relacionados. Para isso as questes devem
ser definidas em um nvel intermedirio, no extremamente abstrato e nem
extremamente detalhado. As hipteses de reposta devem ser determinadas
durante essa fase. Tanto as questes como as hipteses de respostas devem ser
examinadas e se necessrio reformuladas para refletir os objetivos propostos.
12. Definio de Mtricas: Nesta fase necessrio encontrar uma forma quantitativa
de responder as questes e representar os objetivos definidos. Para a completa
diminuio de erros as mtricas elaboradas devem ser revisadas em relao a
sua completude e consistncia em relao do modelo da avaliao conforme
exemplificado na Figura 18:
Pgina 74

Figura 18 Modelo de Avaliao GQM (Laboratory s.d.)
13. Elaborao do Plano GQM: Nesse documento so formalizados os objetivos, as
mtricas e as hipteses do programa de medies definidos nas fases anteriores.
O Plano GQM deve conter todas as informaes necessrias para coleta e
interpretao de dados.
14. Elaborao do Plano de Medies: Este documento mais especifico e refinado
que o Plano GQM, ele deve conter definies formais e textuais das medies
que sero efetuadas, como, por exemplo, quais as pessoas que iro realizar a
coleta dos dados, ferramentas utilizadas e a data de realizao das coletas. O
Plano GQM tambm deve conter possveis resultados da avaliao.
15. Elaborao do Plano de Anlise: Este documento deve simular uma interpretao
dos dados antes do incio da medio. O Plano de Anlise deve conter valores de
mtricas, grficos e fluxogramas que esto de acordo com o Plano QGM.
16. Reviso: Nessa fase todos os documentos de aplicao do GQM devem ser
revisados por todos os membros da equipe, e todos devem concordar com as
definies e deliberaes. Aps essa fase a aplicao do GQM deve ser iniciada.
5.1.3 Coleta
Nesta fase so coletados os dados de avaliao, por meio do preenchimento dos
questionrios elaborados pela equipe GQM. Os dados da pesquisa so validados atravs da
Pgina 75
verificao de no ocorrncia de erros, consistncia e completude dos questionrios
preenchidos. A fase de coleta pode ser subdividida em trs sub-fases (Laboratory s.d.):
Aguardar o Perodo de Prova: Antes da efetiva aplicao questionrios, dos
procedimentos e ferramentas de coleta de dados um perodo de proposio da
medio deve ser executado. Para isso uma sesso de abertura de coleta de
dados deve ser organizada, na qual os participantes da reunio (equipe de
projeto) devem avaliar a aprovar formalmente os planos de medio, os
formulrios, as ferramentas e os procedimentos de coleta.
Base de Mtricas: Nessa fase os formulrios de coleta de dados devem ser
preenchidos pelos participantes da avaliao. A equipe GQM responsvel por
acompanhar a coleta dos dados, agrupar e verificar a corretude dos dados
coletados.
Armazenamento dos dados coletados: Alm das repostas coletadas nas
avaliao, devem ser armazenadas as datas e atividades executadas por cada
membro da equipe e o intervalo de tempo gasto para a sua execuo.
5.1.4 Interpretao
Os dados obtidos na fase de coleta so analisados quantitativamente ou
qualitativamente e concluses so extradas pela equipe de avaliao atravs da anlise
destes dados. Nesta fase as questes a serem avaliadas so respondidas com base na
anlise dos dados obtidos utilizando a abordagem bottom-up. Os pontos de melhoria so
identificados a aes para melhoria so determinadas. A fase de interpretao pode ser
subdividida em trs sub-fases (Laboratory s.d.):
Preparao das Sesses de Feedback: O Plano GQM contm todas as
informaes necessrias para a elaborao das sesses de feedback. A equipe
GQM deve preparar todo o material da sesso de feedback que deve ser capaz
de apoiar a anlise e interpretao de dados, a definio da concluso e a sua
traduo em aes corretivas.
Resultados das Medies: Aps a sesso de feedback a equipe GQM deve
elaborar um relatrio da reunio contendo suas observaes relevantes,
concluses e aes corretivas que foram formuladas durante as sesses de
feedback.
Pgina 76
Anlise de Custo e Benefcio do Programa de Medies: A obteno dos
objetivos do GQM um fator essencial para o programa de medies. Entretanto,
avaliar os custos/benefcios estimados importante do ponto de vista econmico
e deve ser executado ao final da fase de interpretao.
5.1.5 Captura de Experincias
Os resultados da interpretao dos dados e as informaes do prprio programa de
medies so organizados em modelos e so armazenados em bases de experincia para
sua disponibilizao em projetos futuros.
5.2 Consideraes Finais do Captulo
Este captulo apresentou conceitos relacionados ao mtodo GQM. Foram detalhadas
as fases de planejamento, descrio, coleta, interpretao e captura de experincias. Em
cada uma das fases descritas foram identificadas as atividades executadas e os produtos
gerados.
Como podemos perceber na descrio do captulo, o modelo GQM uma ferramenta
que propicia a construo de programas que visam realizar a medio de qualquer objeto de
interesse. Dessa forma o modelo ser utilizado na avaliao das caractersticas do
desenvolvimento de sistemas embarcados.
O captulo 6 descrever em detalhes a elaborao do programa de medies dos
processos de desenvolvimento de sistemas embarcados de MPEs.
Pgina 77
6. AVALIAO DO PROCESSO DE ENGENHARIA DE REQUISITOS PARA O
DESENVOLVIMENTO DE SISTEMAS EMBARCADOS
Nos captulos 02, 03 e 04 foram expostas as principais caractersticas dos sistemas
embarcados, dos processos de desenvolvimento tradicionais e dos processos de
desenvolvimento especficos para sistemas embarcados, alm de processos de engenharia
de requisitos para sistemas embarcados. O captulo 5 apresentou a importncia da
utilizao das mtricas para a avaliao de produtos, processos e servios de software, bem
como a descrio de modelos de avaliao que podem ser usadas para melhorar e entender
um software a ser avaliado.
Neste captulo ser apresentado o modelo de avaliao do processo de engenharia
de requisitos baseado na abordagem Goal-Question-Metric (GQM). O objetivo da
elaborao desse modelo permitir o melhor entendimento do processo de engenharia de
requisitos de sistemas embarcados (SE) em MPEs brasileiras, de forma a gerar indicadores
que alimentem uma nova proposta de processo de Engenharia de requisitos para SE.
A organizao do captulo realizada da seguinte forma: na seo 6.1.1 so
apresentados o planejamento realizado para a seleo da metodologia de avaliao, a
definio das equipes avaliadora e avaliadas, alm da descrio do processo de
comunicao e treinamento dos participantes. A seo 6.1.2 descreve a o modelo de
avaliao GQM do processo de engenharia de requisitos do desenvolvimento de SEs. A
seo 6.1.4 descreve os procedimentos de medio, assim como a coleta dos questionrios
respondidos pelos participantes. As sees 6.1.5 e 6.1.6 apresenta a interpretao das
informaes coletadas e a captura de experincias do programa de medies. Finalmente, a
seo 6.2 descreve as consideraes finais do captulo.
6.1 Aplicao do GQM
Apesar de existirem muitos paradigmas para a definio de objetivos e escopo de
avaliaes de software, optou-se pela utilizao do GQM por ter se apresentado como um
excelente mecanismo para o planejamento e definio de avaliaes (Ramos 2004).
De acordo com o mtodo GQM, para que algo possa ser medido de maneira eficaz
necessrio, em primeiro lugar, traar os objetivos da medio a fim de que sirvam como um
guia para a criao das questes e, posteriormente, das mtricas. Sendo assim, tomando-se
como base a metodologia GQM, a avaliao foi dividida em quatro etapas planejamento,
definio, coleta e interpretao.
Pgina 78
6.1.1 Planejamento
Na fase de planejamento so realizados estudos e definies iniciais para introduo
do programa de avaliao. nessa fase que se determina os objetivos de negcio de alto
nvel de interesse.
Com base nas definies do captulo 5, a fase de planejamento do programa de
medies foi iniciada com a realizao de reunies para discusso de questionamentos
relacionados ao objetivo e ao foco da avaliao. Duas questes iniciais foram levantadas
durante as discusses, conforme descrito na Tabela 7.
Tabela 7 - Questes Iniciais da Fase de Planejamento
Questes Iniciais Respostas
Qual ser o objetivo principal da avaliao? Anlise dos problemas que ocorrem no
processo de engenharia de requisitos de
sistemas embarcados.
Quem ser o pblico alvo da avaliao? MPEs brasileiras que atuam no setor de
desenvolvimento de sistemas embarcados.
O primeiro questionamento foi respondido por meio da anlise do foco da pesquisa
realizada na rea de sistemas embarcados, na qual um dos principais desafios o
atendimento a rgidas restries de tempo, peso, tamanho, mobilidade, segurana,
confiabilidade, consumo de energia e memria (Sommerville 1998). Outro grande obstculo
a ser ultrapasso a adaptao do software ao hardware e sua separao na modelagem de
seus requisitos (Nars 2002).
No que diz respeito segunda questo, as MPEs foram selecionadas como pblico
alvo da avaliao devido sua efetiva participao no crescimento do mercado brasileiro de
desenvolvimento de software e a falta de formalizao de seus processos. Segundo
pesquisas realizadas pelo Ministrio da Cincia e Tecnologia em 2001 (MCT 2002), as
MPEs destacam-se no cenrio nacional com a participao de 60% da mo de obra efetiva
do setor de desenvolvimento de software, onde aproximadamente 70% conhecem algum
modelo de qualidade (ISO/IEC122007, ISO 9000 ou CMMI), mas apenas 20% delas utilizam
algum desses modelos.
Aps a definio do objetivo e do pblico alvo, o prximo passo foi a seleo das
equipes participantes do programa de medies. A Tabela 8 apresenta as equipes
avaliadora e avaliadas:
Tabela 8 - Equipe GQM
Pgina 79
Equipe de Definio e Coordenao
Papel rea de Atuao
Orientadora Definio de Processos
Pesquisadora Requisitos
Pesquisadora Requisitos
Equipes Avaliada
Papel rea de Atuao
Respondente Desenvolvimento de Sistemas de
Segurana
Respondente Desenvolvimento de Sistemas
Agrrios
Os participantes das equipes avaliadas so funcionrios de empresas
desenvolvedoras de sistemas embarcados para os mais diversos fins, como
desenvolvimento de sistemas agrrios e sistemas de segurana. A diversidade dos objetivos
do produto final foi propositalmente considerada, pois desta forma a avaliao poder
comparar os resultados e at mesmo as dificuldades encontradas em cada um dos
segmentos das organizaes participantes do programa. Desta forma, a avaliao torna-se
mais isenta e imparcial, sem desvios causados pelo domnio de negcio de uma
determinada empresa.
Levando em considerao a distribuio geogrfica das MPEs avaliadas, foi
acordado que a iterao entre as equipes avaliadora e avaliada seria realizada por e-mail.
Devido a essa caracterstica, foi necessria a elaborao da avaliao em um formato que
proporcionasse ao usurio facilidade na seleo das respostas de cada questo. Alm
disso, uma seo de ajuda foi elaborada com o objetivo de melhorar a compreenso do
questionrio.
Visto que a pesquisa proposta um programa de medies que no possui o
objetivo de melhoria de processo de determinada empresa, no foram avaliados projetos
especficos e nenhum dos Planos do modelo GQM foi elaborado. Diante desse contexto, a
prxima atividade realizada no programa de medies a definio do objetivos de negcio
e de seus sub-objetivos.
6.1.2 Definio
Pgina 80
Conforme exposto no captulo 5, a definio dos objetivos e sub-objetivos do
programa de avaliao deve ser executado etapas. Nessa pesquisa dividimos a fase de
definio em trs macro-atividades:
identificar os objetivos da avaliao,
identificar sub-objetivos;
identificar entidades e atributos relacionados aos sub-objetivos (questes e
mtricas).
Na primeiro passo, os objetivos da medio devem ser formalmente definidos e
estruturados. Conforme descrito no prembulo da seo, o objetivo da avaliao foi um
ponto extremante discutido no incio do programa. Logo, nessa fase da avaliao a
formalizao deste objetivo foi realizada. A Tabela 9 foi utilizada como ferramenta de apoio
na formalizao do objetivo da pesquisa.
Tabela 9 Modelo de Definio dos Objetivos da Medio (Laboratory s.d.)
Diretrizes Descries Respostas
Analisar: o objeto sob medio processo de engenharia de requisitos
Com o propsito de: entender, controlar e melhorar o
objeto de medio.
adequar
Com respeito a: foco da qualidade do objeto de
medio.
aplicabilidade
Do ponto de vista de: as pessoas que medem o objeto Equipe de desenvolvimento
No contexto: o ambiente que as medies
acontecero.
Das MPEs desenvolvedoras de
sistemas embarcados.
A Tabela 10 descreve o objetivo do negcio definido com base nas caractersticas
identificadas na tabela acima.
Tabela 10 - Objetivo do Negcio
Adequar a aplicabilidade do processo de gerenciamento de requisitos de MPEs
desenvolvedoras de sistemas embarcados sob o ponto de vista da equipe de
desenvolvimento.
Uma vez definido o objetivo do programa de medies, o prximo passo a
identificao detalhada do que se quer saber ou aprender (sub-objetivos). Ao responder o
que necessrio e o que se quer saber, os pontos influenciados ou gerenciados pelo
objetivo de avaliao sero identificados.
Pgina 81
Para facilitar o entendimento e a elaborao da avaliao os sub-objetivos
identificados no programa de medies no seguiram o padro estipulado pelo mtodo
GQM descrito no captulo 5. Ou seja, os sub-objetivos foram convertidos para pontos de
verificao (classificaes) que classificam as questes e mtricas elaboradas na pesquisa.
Os pontos identificados no programa de medies so relacionados as principais
caractersticas e dificuldades relatadas na literatura sobre o processo de engenharia de
requisitos de sistemas embarcados e at mesmo dos sistemas tradicionais, conforme
relatado nos captulos 2 e 3. Logo, eles possuem seu foco em todas as atividades que so
executadas durante o processo de engenharia de requisitos considerando que os requisitos
funcionais e no-funcionais devem ser levantados e analisados nesse processo.
Outros aspectos analisados na identificao dos pontos de verificao foram os
resultados esperados do processo de Gerncia de Requisitos do nvel G do programa de
Melhoria de Processo do Software Brasileiro MPS.BR. Eles estabelecem os resultados a
serem obtidos com a efetiva implementao do processo de Gerncia de Requisitos.
A Tabela 11 apresenta todos os pontos de verificao identificados no programa de
medies.
Tabela 11 - Pontos de Verificao
Pontos de Verificao
1. Contextualizao da empresa.
2. Contextualizao do software.
3. Contextualizao da equipe de requisitos.
4. O entendimento dos requisitos (funcionais e no-funcionais) obtido junto aos
fornecedores de requisitos?
5. As necessidades, expectativas e restries do cliente, tanto do produto quanto de suas
interfaces, so identificadas e registradas?
6. Os requisitos de software so aprovados?
7. Um conjunto definido de requisitos do cliente especificado a partir das necessidades,
expectativas e restries identificadas?
8. Um conjunto de requisitos funcionais e no-funcionais do produto e dos componentes do
produto que descrevem a soluo do problema a ser resolvido, definido e mantido a partir
dos requisitos do cliente?
9. utilizado algum mtodo, modelo ou linguagem para especificao dos requisitos
(funcionais e no-funcionais)?
10. estabelecida a rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho? Em caso positivo, esta rastreabilidade mantida?
Pgina 82
11. Interfaces internas e externas do produto e de cada componente do produto so
definidas?
12. Os requisitos so analisados para assegurar que sejam necessrios, corretos, testveis
e suficientes para balancear as necessidades dos interessados com as restries
existentes?
13. considerada e avaliada a dependncia entre os requisitos?
14. considerada e validada a viabilidade dos itens de software atenderem seus requisitos
alocados?
15. So feitas revises nos planos e produtos de trabalho do projeto visando identificar e
corrigir inconsistncias em relao aos requisitos?
16. As mudanas nos requisitos so gerenciadas ao longo do tempo?
Cada um dos pontos descritos na Tabela 11 foram detalhados na etapa de
planejamento, por meio da elaborao de questes que provem a correta interpretao dos
pontos de verificao e dos objetivos relacionados.
6.1.3 Elaborao das Questes e Mtricas
A prxima etapa do modelo GQM a definio das questes e mtricas relacionadas
aos pontos de verificao. Seguindo as definies do captulo 5, as questes foram
elaboradas em um nvel intermedirio de abstrao, pois elas serviro como guia para a
elaborao de suas mtricas. Para isso, cada questo foi definida com opes de respostas
numeradas que permitem a interpretao quantitativa de suas respectivas mtricas. As
sees seguintes apresentaro as questes mtricas definidas neste programa de
medies.
6.1.3.1 Ponto de Verificao 1
A contextualizao da empresa um aspecto de vital importncia para a avaliao,
visto que necessrio conhecer o ambiente no qual as equipes avaliadas esto inseridas.
Para isso, foram definidas trs questes cujas respostas so descritivas e no possuem
mtricas correlacionadas, portanto, no esto de acordo com as definies do modelo GQM
e no geram respostas quantitativas.
De acordo com a Tabela 12, o objetivo das questes definidas para o primeiro ponto
de verificao conhecer o ramo de atuao das empresas avaliadas, seu tempo de
experincia no mercado e sua quantidade de funcionrios. Essa informaes foram
contempladas a fim de garantir que todos os participantes da avaliao possuem um de
seus segmentos de atuao na rea de desenvolvimento de sistemas embarcados. Alm
disso, o ramo de atuao e o tempo de experincia das empresas auxiliam tambm na
Pgina 83
identificao da criticidade dos sistemas desenvolvidos, o que pode impactar na
necessidade de um maior enfoque na definio dos requisitos funcionais e no-funcionais
dentro do processo de engenharia de requisitos. Por fim, a quantidade de funcionrios da
empresa visa identificar seu enquadramento como MPE.
Tabela 12 - Contextualizao da Empresa
Ponto de Verificao (PVn) Questo (QTn)
QT01. Qual o domnio de negcio da empresa?
QT02. H quanto tempo a empresa atua neste domnio de
negcio?
PV01. Contextualizao - A
empresa
QT03. Qual o nmero de funcionrios da empresa?
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 84
6.1.3.2 Ponto de Verificao 2
Este ponto de verificao visa esclarecer o contexto do software desenvolvido pelas
empresas que participam da avaliao. Suas questes identificam de onde vm os
requisitos do software (cliente interno ou externo) e caractersticas de portabilidade e
integrao. Os indicadores gerados a partir destas questes permitiro reflexes acerca das
restries s quais o software pode estar submetido como plataforma, interface com outros
sistemas, padres e linguagens de desenvolvimento. A Tabela 13 descreve as questes,
suas opes de resposta e as mtricas associadas contextualizao do software.
Tabela 13 - Contextualizao do Software
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
(0) Componente de um
produto especfico da
prpria empresa (cliente
interno).
(1) Componente de um
produto especfico de outra
empresa (cliente externo).
(2) Um produto da empresa
(cliente interno).
QT04. O
software
embarcado
desenvolvido
pela empresa
...
(3) Um produto da empresa
desenvolvido sob
encomenda (cliente
externo).
ndice de
caracteriza
o do software

Frmula:
M4 = x, onde
x E A / A= {0,
1, 2, 3}
(0) No possui integrao
com outros sistemas.
(1) Possui integrao com
outros sistemas da prpria
empresa.
(2) Possui integrao
apenas com sistemas de
outros fabricantes.
QT05. O
software
embarcado
desenvolvido
pela empresa
possui
integrao
com outros
sistemas?
(3) Possui integrao com
sistemas da prpria
empresa e de outros
fabricantes.
Nvel de
integrao
exigido pelo
software

Frmula:
M5 = x, onde
x E A / A= {0,
1, 2, 3}
(0) O software dedicado a
uma plataforma especfica
da empresa.
PV02.
Contextualiza
o O software
QT06. O
software
embarcado
desenvolvido
pela empresa
deve
executar em
(0) O software dedicado a
uma plataforma especfica
de outro fabricante.
Nvel de
portabilidade
exigido pelo
software

ndice de
contextualizao
do software

Frmula
1
:
MT2 = M4 + M5
+ M6

1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 85
(1) O software executa em
diferentes plataformas da
prpria empresa.
(2) O software executa em
diferentes plataformas de
outro fabricante.
(3) O software executa em
diferentes plataformas da
prpria empresa e de outro
fabricante.

executar em
diferentes
plataformas?
(4) O software executa em
plataformas de diferentes
fabricantes.
Frmula:
M6 = x, onde
x E A / A =
{0, 1, 2, 3, 4}

6.1.3.3 Ponto de Verificao 3
A contextualizao da equipe de requisitos avalia a existncia, tamanho,
conhecimento, nvel de dedicao e formao acadmica da equipe responsvel pelo
levantamento de requisitos. O entendimento destas caractersticas auxiliar na modelagem
do processo de engenharia de requisitos, de maneira que se possa definir o nvel de
detalhamento, a quantidade e a designao dos papis, artefatos e atividades adequados
ao desenvolvimento de softwares embarcados em MPEs.
A Tabela 14 descreve as questes, as opes de resposta e as mtricas associadas
ao ponto de verificao descrito nesta seo.
Tabela 14 - Contextualizao da Equipe de Requisitos
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
(0) O software no um
componente do produto.
Ele o prprio produto da
empresa.
(1) No existe separao
entre as equipes do
produto e do software. O
levantamento realizado
em conjunto, no mesmo
processo.
PV03.
Contextualiza
o A Equipe de
Requisitos
QT07. No
caso do
software ser
um
componente
de um
produto da
prpria
empresa ou
de outro
fabricante,
existe uma
equipe
separada
para o
levantamento
dos
requisitos do
(2) No existe separao
entre as equipes. Mas os
levantamentos do produto e
do software so realizados
em momentos distintos e
por processos distintos.
Nvel de
especializa
o da equipe e
do processo
de
levantamento
de requisitos.

Frmula:
M7 = x, onde
x E A / A= {0,
1, 2, 3, 4}
ndice de
contextualizao
da equipe de
requisitos.

Frmula
1
:
MT3 = M7 + M8 +
M9 + M10 + M11
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 86
(3) Existe uma equipe
separada, responsvel pelo
levantamento dos
requisitos do software. O
processo de levantamento
o mesmo do produto.
requisitos do
software?
(4) Existe uma equipe
separada para o
levantamento dos
requisitos do software. O
processo de levantamento
distinto daquele utilizado
para o produto.

(0) No existe uma equipe
separada.
(1) At 20% da equipe de
projeto.
(2) De 20 a 30% da equipe
de projeto.
(3) De 30 a 40% da equipe
de projeto.
QT08. Caso
exista uma
equipe
separada
para os
requisitos do
software,
qual o seu
tamanho, em
relao ao
tamanho total
da equipe
responsvel
pelo projeto?
(4) Acima de 40% da
equipe de projeto.
Tamanho da
equipe de
requisitos em
relao
equipe de
projeto.

Frmula:
M8 = x, onde
x E A / A= {0,
1, 2, 3, 4}
(0) No existe uma equipe
separada.
(1) Os membros da equipe
de requisitos tambm
desempenham outros
papis ao longo do projeto.
QT09. Caso
exista uma
equipe
separada
para os
requisitos do
software,
seus
membros so
dedicados a
esta
atividade?
(2) Os membros da equipe
de requisitos so dedicados
a esta atividade.
Nvel de
dedicao da
equipe de
requisitos.

Frmula:
M9 = x, onde
x E A / A= {0,
1, 2}
(0) Os membros da equipe
no possuem formao em
Cincia da Computao (ou
reas afins) e nem
conhecimento da
Engenharia de Requisitos.

QT10. Qual a
formao
acadmica
dos membros
da equipe de
requisitos
(mesmo que
no exista
uma equipe
separada
para tal)?
(1) Os membros da equipe
no possuem formao em
Cincia da Computao (ou
reas afins), mas possuem
conhecimento da
Engenharia de Requisitos.
Nvel de
formao da
equipe de
requisitos
(Nvel de
conheciment
o da
Engenharia
de requisitos
e rea de
formao da
equipe).

1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 87
(2) Os membros da equipe
possuem formao em
Cincia da Computao (ou
reas afins), mas no tm
conhecimento da
Engenharia de Requisitos.
(3) Os membros da equipe
possuem formao em
Cincia da Computao (ou
reas afins), e possuem
conhecimento superficial da
Engenharia de Requisitos.

(4) Os membros da equipe
possuem formao em
Cincia da Computao (ou
reas afins), e possuem
conhecimentos profundos
da Engenharia de
Requisitos.

Frmula:
M10 = x,
onde x E A /
A= {0, 1, 2, 3,
4}
(0) A equipe de requisitos
no possui conhecimento
do negcio.
(1) A equipe de requisitos
tem conhecimento
superficial do negcio.

QT11. Qual o
nvel de
conheciment
o da equipe
de requisitos
no que diz
respeito ao
negcio do
software a
ser
desenvolvido
?
(2) A equipe de requisitos
tem conhecimentos
aprofundados do negcio.
Nvel de
conheciment
o da equipe
no negcio
do software a
ser
desenvolvido.

Frmula:
M11 = x,
onde x E A /
A= {0, 1, 2}

6.1.3.4 Pontos de Verificao 4 e 9
O modo como os requisitos so levantados, os nveis de detalhe e de especializao
do responsvel pelo levantamento de requisitos so aspectos que avaliam se o
entendimento dos requisitos funcionais e no-funcionais obtido juntos aos fornecedores de
requisitos, conforme descrito na Tabela 15. A resposta dessas questes gera indicadores
que auxiliam na definio dos papis, do nvel de detalhamento dos artefatos e das tcnicas
de levantamento de requisitos que melhor se adaptem as caractersticas dos tipos de
empresa e sistemas definidos nesse estudo.
Tabela 15 - Entendimento dos Requisitos Funcionais e No-Funcionais
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
PV04. O
entendimento
QT12. Nvel
de
(0) Os requisitos no so
levantados
Nvel de
entendimento
Nvel de
entendimento
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 88
(1) Os requisitos so
levantados informalmente
(conversa informal).
(2) Os requisitos so
recebidos j levantados.
entendimento
dos
requisitos.
(3) Os requisitos so
levantados por meio de
reunies formais.
dos
requisitos.

Frmula:
M12 = x,
onde x E A /
A= {0, 1, 2, 3}
(0) Os requisitos no so
levantados.
(1) Os requisitos so
levantados pela equipe de
implementao.
(1) Os requisitos so
levantados pelo gerente de
projetos.
(2) Os requisitos so
levantados pelos arquitetos
ou projetistas.
QT13. Nvel
de
especializa
o da equipe
de
levantamento
de requisitos
nesta
atividade.
(3) Os requisitos so
levantados pela equipe de
requisitos.
Nvel de
especializa
o da equipe
de
levantamento
de requisitos
nesta
atividade.

Frmula:
M13 = x,
onde x E A /
A= {0, 1, 2, 3}
(0) As necessidades do
cliente no so
identificadas.
(1) As necessidades do
cliente so identificadas.
(2) As necessidades do
cliente e as restries do
sistema so identificadas.
dos requisitos
(funcionais e
no-funcionais)
obtido junto
aos
fornecedores de
requisitos?
QT14. Nvel
de detalhe do
levantamento
de requisitos.
(3) As necessidades do
cliente, as restries do
sistema e as integraes
com outros
sistemas/dispositivos so
identificadas.
Nvel de
detalhe do
levantamento
de requisitos.

Frmula:
M14 = x,
onde x E A /
A= {0, 1, 2, 3}
dos requisitos
funcionais e no-
funcionais

Frmula
1
:
MT4 = M12 +
M13 + M14
(0) Os requisitos funcionais
e no-funcionais no so
especificados.
PV09.
utilizado algum
mtodo, modelo
ou linguagem
para
especificao
dos requisitos
(funcionais e
no-funcionais)?
QT20. Qual o
nvel de
utilizao de
mtodos/mod
elos no
levantamento
/especifica
o dos
requisitos
(1) Os requisitos funcionais
e no-funcionais so
levantados/ especificados
sem utilizao de tcnicas
auxiliares.
Nvel de
utilizao de
mtodos/mod
elos no
levantamento
/especifica
o dos
requisitos
(funcionais e
ndice de
utilizao de
ferramentas de
apoio.

Frmula
1
:
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 89
no-funcionais)? requisitos
(funcionais e
no-
funcionais)?
(2) Os requisitos funcionais
e no-funcionais so
levantados/especificados
formalmente com o auxlio
de tcnicas auxiliares
(checklist, brainstorm e
etc.).
(funcionais e
no-
funcionais).

Frmula:
M20 = x,
onde x E A /
A= {0, 1, 2}
MT9 = M20
6.1.3.5 Pontos de Verificao 5 e 6
A compreenso de como realizada a aprovao dos requisitos, a identificao e o
registro das necessidades, expectativas e restries do cliente necessria para a correta
definio dos artefatos a serem gerados no processo de engenharia de requisitos e dos
elementos que o comporo. Alm disso, o registro e aprovao apropriada das informaes
levantadas assegura que nenhum requisito seja ignorado ou entendido de forma
inadequada. A Tabela 16 apresenta as questes e mtricas relacionadas a este ponto de
verificao.
Tabela 16 Identificao e Registro das Necessidades, Expectativas e Restries do Cliente
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
(0) Os requisitos no so
levantados.
(1) Os requisitos so
acordados informalmente
(verbalmente, telefone)
mas no so registrados.
(2) Os requisitos so
acordados e registrados
informalmente (ex: e-mail,
documento
desestruturado).
(3) Os requisitos so
acordados e registrados em
documentos estruturados
(ex: atas de reunio).
QT15. Qual o
nvel de
formalizao
dos
requisitos?
(4) Os requisitos so
acordados e registrados
formalmente (ex:
documento de
especificao de
requisitos).
Nvel de
formalizao
dos
requisitos.

Frmula:
M15 = x,
onde x E A /
A= {0, 1, 2, 3,
4}
PV05. As
necessidades,
expectativas e
restries do
cliente, tanto do
produto quanto
de suas
interfaces, so
identificadas e
registradas?
QT16. Qual o
nvel de
formalizao
(0) As necessidades,
expectativas e restries do
cliente no so levantadas.
Nvel de
formalizao
do
Nvel de
identificao e
registro das
necessidades,
expectativas e
restries do
cliente.

Frmula
1
:
MT5 = M15 +
M16
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 90
(1) As necessidades,
expectativas e restries do
cliente so levantadas
informalmente e no so
registradas.
(2) As necessidades,
expectativas e restries do
cliente so levantadas e
registradas em documentos
informais (e-mail).
(3) As necessidades,
expectativas e restries do
cliente so levantadas e
registradas em atas de
reunio.

do
detalhamento
do
levantamento
/especifica
o de
requisitos?
(4) As necessidades,
expectativas e restries do
cliente so levantadas e
registradas em documentos
formais do processo (Ex.
Documento de Viso).
detalhamento
da
levantamento
/especifica
o de
requisitos.

Frmula:
M16 = x,
onde x E A /
A= {0, 1, 2, 3,
4}

(0) Os requisitos no so
levantados.
(1) Os requisitos so
acordados informalmente
(verbalmente, telefone)
mas no so registrados.
(2) Os requisitos so
acordados e registrados
informalmente (ex: e-mail,
documento
desestruturado).
(3) Os requisitos so
acordados e registrados em
documentos estruturados
(ex: atas de reunio).
PV06. Os
requisitos de
software so
aprovados?
QT17. Qual o
nvel de
formalizao
dos
requisitos?
(4) Os requisitos so
acordados e registrados
formalmente (ex:
documento de
especificao de
requisitos).
Nvel de
aprovao
dos
requisitos.

Frmula:
M17 = x,
onde x E A /
A= {0, 1, 2, 3,
4}
Nvel de
aprovao dos
requisitos.

Frmula
1
:
MT6 = M17
6.1.3.6 Ponto de Verificao 7
Outro assunto que foi ressaltado na avaliao o modo como os requisitos so
especificados, uma vez que uma das principais causas de falha do desenvolvimento de
software o levantamento deficiente de seus requisitos (Hofmann 2001).
Conseqentemente, necessrio que os mesmos sejam identificados a partir das
necessidades do cliente, que so refinadas em caractersticas e posteriormente em
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 91
requisitos do sistema. A Tabela 17 apresenta as questes e mtricas definidas para este
ponto de verificao.
Tabela 17 - Modo de Especificao dos Requisitos
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
(0) Os requisitos so
diretamente
levantados/definidos.
(1) As necessidades so
refinadas somente em nvel
de caractersticas.
(2) As necessidades so
refinadas diretamente em
nvel de requisitos.
(2) As caractersticas so
diretamente levantadas e
refinadas em nvel de
requisitos.
PV07. Um
conjunto
definido de
requisitos do
cliente
especificado a
partir das
necessidades,
expectativas e
restries
identificadas?
QT18. Qual o
nvel de
refinamento
dos
requisitos
funcionais?
(3) As necessidades so
refinadas em nvel de
caractersticas e
posteriormente de
requisitos.
Nvel de
refinamento
dos
requisitos
funcionais.

Frmula:
M18 = x,
onde x E A /
A= {0, 1, 2, 3}
Nvel de
refinamento dos
requisitos
funcionais.

Frmula
1
:
MT7 = M18
6.1.3.7 Pontos de Verificao 8 e 14
Para garantir que o sistema atenda a todos os seus requisitos necessrio que haja
um mapeamento (ligao, dependncia) entre os requisitos funcionais e no funcionais, de
maneira que no sejam definidos requisitos inviveis para a estrutura fsica do sistema.
Alm disso, as restries referentes aos requisitos no-funcionais e sua relao com os
requisitos funcionais so caractersticas marcantes no desenvolvimento de sistemas
embarcados. Dessa forma a Tabela 18 define questes, suas opes de resposta e mtricas
que avaliam o relacionamento entre os requisitos funcionais e no-funcionais tanto na sua
identificao como manuteno, bem como, a sua viabilidade de implement-los.
Tabela 18 Definio e Manuteno dos Requisitos Funcionais e No Funcionais
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
PV08. Um
conjunto de
requisitos
QT19. Qual o
nvel de
entendimento
(0) Os requisitos no-
funcionais no so
identificados.
Nvel de
definio e
manuteno
Nvel de
definio e
manuteno dos
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 92
(1) Os requisitos no-
funcionais so
identificados, mas no so
definidos e mantidos a
partir dos requisitos
funcionais identificados.
(2) Os requisitos no-
funcionais so identificados
e so definidos a partir dos
requisitos funcionais
identificados.
(3) Os requisitos no-
funcionais so identificados
e so definidos e mantidos
a partir dos requisitos
funcionais identificados.
funcionais e
no-funcionais
do produto e dos
componentes do
produto que
descrevem a
soluo do
problema a ser
resolvido,
definido e
mantido a partir
dos requisitos
do cliente?
dos
requisitos
no-
funcionais?
(4) Os requisitos no-
funcionais so identificados
e so definidos e mantidos
a partir dos requisitos
funcionais identificados e
comparados aos prprios
requisitos funcionais
levantados.
dos
requisitos
funcionais e
no-
funcionais.

Frmula:
M19 = x,
onde x E A /
A= {0, 1, 2, 3,
4}
requisitos
funcionais e no-
funcionais.

Frmula
1
:
MT8 = M19
(0) A viabilidade dos
requisitos funcionais e no-
funcionais no avaliada.
(1) A viabilidade dos
requisitos funcionais
avaliada.
(1) A viabilidade dos
requisitos no-funcionais
avaliada.
PV14.
considerada e
validada a
viabilidade dos
itens de software
atenderem seus
requisitos
alocados?
QT26. Qual o
nvel de
anlise da
viabilidade
dos
requisitos?
(2) A viabilidade dos
requisitos funcionais e no-
funcionais avaliada.
Nvel de
anlise da
viabilidade
dos
requisitos.

Frmula:
M26 = x,
onde x E A /
A= {0, 1, 2}
Nvel de anlise
da viabilidade
dos requisitos.

Frmula
1
:
MT14 = M26
6.1.3.8 Pontos de Verificao 10 e 13
A rastreabilidade um mecanismo que facilita a avaliao dos impactos de
mudanas nos sistemas, por meio do mapeamento da dependncia entre seus requisitos,
planos de projeto e produtos de trabalho. A rastreabilidade horizontal estabelece a
dependncia entre os requisitos e a rastreabilidade vertical permite o mapeamento das
necessidades, caractersticas e requisitos levantados at o nvel de decomposio mais
baixo do produto (Softex s.d.). Dessa forma, os pontos de verificao descritos na Tabela 19
visam determinar como as empresas participantes da avaliao tratam a rastreabilidade e a
dependncia de seus requisitos.
Tabela 19 - Rastreabilidade dos Requisitos
Ponto de Questo Opes de Resposta (A) Mtrica da Mtrica do
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 93
Verificao
(PVn)
(QTn) Questo
(Mn)
Ponto de
Verificao
(MTn)
(0) A rastreabilidade entre
os requisitos e os produtos
de trabalhos no
elaborada.
(1) A rastreabilidade entre
os requisitos de trabalho
elaborada.
PV10.
estabelecida a
rastreabilidade
bidirecional
entre os
requisitos e os
produtos de
trabalho? Em
caso positivo,
esta
rastreabilidade
mantida?
QT21. Qual o
nvel de
rastreabilidad
e dos
requisitos?
(2) A rastreabilidade entre
os requisitos e os produtos
de trabalhos elaborada e
mantida conforme o
andamento do projeto.
Nvel de
rastreabilidad
e dos
requisitos.

Frmula:
M21 = x,
onde x E A /
A= {0, 1, 2}
Nvel de
rastreabilidade
dos requisitos.

Frmula
1
:
MT10 = M21
(0) A dependncia entre os
requisitos no avaliada.
(1) A dependncia entre os
requisitos funcionais
avaliada.
(1) A dependncia entre os
requisitos no-funcionais
avaliada.
PV13.
considerada e
avaliada a
dependncia
entre os
requisitos?
QT25. Qual o
nvel de
anlise da
dependncia
entre os
requisitos?
(2) A dependncia entre os
requisitos funcionais e no-
funcionais avaliada.
Nvel de
anlise da
dependncia
entre os
requisitos.

Frmula:
M25 = x,
onde x E A /
A= {0, 1, 2}
Nvel de anlise
da dependncia
entre os
requisitos.

Frmula
1
:
MT13 = M25
6.1.3.9 Ponto de Verificao 12
As questes e mtricas relacionadas este ponto de verificao so descritas na
Tabela 20, elas tm como objetivo analisar quais so os papis envolvidos na realizao
dos testes e como so executadas as validaes dos requisitos. Dessa forma ser possvel
adaptar as estratgias de teste ao contexto das empresas avaliadas, sem perder o foco da
integridade do sistema.
Tabela 20 Anlise dos Requisitos
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
(0) Os requisitos no so
testados pela equipe de
desenvolvimento nem
validados pelo cliente?
PV12. Os
requisitos so
analisados para
assegurar que
sejam
necessrios,
corretos,
testveis e
suficientes para
QT23. Qual o
nvel de
anlise de
erros nos
requisitos?
(1) Os requisitos so
testados pela equipe de
desenvolvimento e no so
validados pelo cliente.
Nvel de
anlise de
erros nos
requisitos.

Frmula:
ndice de
corretude dos
requisitos.

Frmula
1
:
MT12 = M23 +
M24
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 94
(1) Os requisitos so
validados pelo cliente e no
so testados pela equipe
de desenvolvimento.

(2) Os requisitos so
testados pela equipe de
desenvolvimento e
validados pelo cliente.
M23 = x,
onde x E A /
A= {0, 1, 2}
(0) Os requisitos no so
testados.
(1) Os requisitos so
testados unitariamente e/ou
integralmente pela equipe
de desenvolvimento sem a
utilizao de casos de
testes.
(2) Os requisitos so
testados unitariamente pela
equipe de desenvolvimento
com a utilizao de casos
de testes.
(2) Os requisitos so
testados integralmente pela
equipe de desenvolvimento
com a utilizao de casos
de testes.
suficientes para
balancear as
necessidades
dos
interessados
com as
restries
existentes?
QT24. Qual o
nvel de
corretude dos
testes de
requisitos?
(3) Os requisitos so
testados unitariamente e
integralmente pela equipe
de desenvolvimento com a
utilizao de casos de
testes.
Nvel de
corretude dos
testes de
requisitos.

Frmula:
M24 = x,
onde x E A /
A= {0, 1, 2, 3}
M24
6.1.3.10 Pontos de Verificao 15 e 16
Outro ponto que merece ateno o acompanhamento das mudanas nos requisitos
do projeto. Alteraes nos requisitos esto entre os pontos que mais acarretam falhas nos
projetos de desenvolvimento de sistemas embarcados (Carro 2002), portanto, eles devem
ser gerenciados ao longo do processo. Neste sentindo, fundamental garantir que os
planos e produtos de trabalho .do projeto estejam sendo revisados, a fim de que reflitam os
requisitos definidos. Estes artefatos sero importantes para a tomada de decises em
relao ao projeto e para futuras manutenes no sistema. Tais aspectos so facilmente
atendidos quando se realiza a rastreabilidade dos requisitos e produtos de trabalho. Sendo
assim, os indicadores gerados a partir das mtricas apresentadas na Tabela 21 permitem
analisar estes aspectos nas empresas avaliadas.
Tabela 21 Reviso dos Planos e Produtos de Trabalho
Ponto de
Verificao
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
Mtrica do
Ponto de
1
:Interpretao - Quanto maior o valor de MTn, melhor o ndice/nvel.
Pgina 95
(PVn) (Mn) Verificao
(MTn)
(0) No so realizadas
revises dos planos e
produtos de trabalho.
(1) So realizadas revises
e correes dos planos e
produtos de trabalho
durante o processo de
desenvolvimento do
sistema.
(1) So realizadas revises
e correes dos planos e
produtos de trabalho
durante o processo de
manuteno do sistema.
PV15. So feitas
revises nos
planos e
produtos de
trabalho do
projeto visando
identificar e
corrigir
inconsistncias
em relao aos
requisitos?
QT27. Qual o
nvel de
anlise de
revises e
correes
dos produtos
de trabalho?
(2) So realizadas revises
e correes dos planos e
produtos de trabalho
durante o processo de
desenvolvimento e
manuteno do sistema.
Nvel de
anlise de
revises e
correes
dos produtos
de trabalho.

Frmula:
M27 = x,
onde x E A /
A= {0, 1, 2}
Nvel de anlise
de revises e
correes dos
produtos de
trabalho.

Frmula
1
:
MT15 = M27
(0) Os requisitos funcionais
e no-funcionais no so
mantidos.
(1) Os requisitos funcionais
so mantidos ao longo do
tempo
(1) Os requisitos no-
funcionais so mantidos ao
longo do tempo.
PV16. As
mudanas nos
requisitos so
gerenciadas ao
longo do tempo?
QT28. Qual o
nvel de
anlise de
manutenes
nos
requisitos
funcionais e
no-
funcionais?
(2) Os requisitos funcionais
e no-funcionais so
mantidos ao longo do
tempo.
Nvel de
anlise de
manutenes
nos
requisitos
funcionais e
no-
funcionais.

Frmula:
M28 = x,
onde x E A /
A= {0, 1, 2}
Nvel de anlise
de manutenes
nos requisitos
funcionais e no-
funcionais.

Frmula:
MT16 = M28

6.1.3.11 Ponto de Verificao 11
A identificao e o registro dos usurios e dos sistemas que interagem com o
software em desenvolvimento auxilia na definio da sua arquitetura e de seus protocolos
de comunicao, alm de facilitar a obteno de requisitos ainda no levantados A Tabela
22 apresenta as questes, opes de respostas e mtricas relacionadas a esse ponto de
verificao.
Tabela 22 - Identificao das Interfaces do Sistema
Ponto de
Verificao
(PVn)
Questo
(QTn)
Opes de Resposta (A)
Mtrica da
Questo
(Mn)
Mtrica do
Ponto de
Verificao
(MTn)
PV11. Interfaces
internas e
QT22. Qual o
nvel de
(0) Os atores do sistema
no so definidos.
Nvel de
identificao
Nvel de
identificao de
Pgina 96
(1) Os atores do sistema
so definidos, mas no so
registrados.
(2) Os atores do sistema
so definidos e registrados
em documentos informais
(Ex.: e-mail).
(3) Os atores do sistema
so definidos e registrados
em documentos
estruturados (Ex. Ata de
reunio).
externas do
produto e de
cada
componente do
produto so
definidas?
identificao
de
interfaces?
(4) Os atores do sistema
so definidos e registrados
em documentos formais
(ex: documento de viso).
de interfaces.

Frmula:
M22 = x,
onde x E A /
A= {0, 1, 2, 3,
4}
interfaces.

Frmula
1
:
MT11 = M22
Outros aspectos foram avaliados para este objetivo de medio, como, o modo de
elaborao dos cenrios operacionais e a anlise de viabilidade de operao e manuteno
dos softwares embarcados. No entanto, ao realizar a interpretao dessas questes,
considerou-se que esses pontos no fazem parte do processo de engenharia de requisitos,
e conseqentemente no so relacionados ao objetivo da medio.
A Figura 19 apresenta a relao entre o objetivo de medio, os itens de verificao,
e suas questes.

Figura 19 - Relao entre os Elementos do Modelo GQM
Pgina 97
Por fim foi realizada a reviso do questionrio que a ltima atividade prevista na
fase de definio do modelo GQM. Aps finalizar sua elaborao, os pesquisadores e a
orientadora efetuaram uma reviso formal que apontou melhorias no questionrio. Alm
disso, a avaliao foi submetida a anlise de todos os participantes, que puderam sugerir
novas modificaes.
6.1.4 Coleta
Conforme descrito no captulo 5, a fase de coleta do modelo GQM caracterizada
pela obteno das respostas do questionrio de avaliao. O procedimento de coleta de
dados foi definido considerando o contexto das equipes respondentes, com o objetivo de
maximizar a eficincia e eficcia da avaliao. Sendo assim, a obteno das respostas foi
realizada manualmente, por meio do preenchimento de planilhas Excel.
A primeira atividade dessa fase a validao dos procedimentos e das ferramentas
de coleta. Dada a distncia entre os participantes do programa de medies no foi
realizada uma reunio formal para sua validao. No entanto, como descrito na seo
anterior, o questionrio foi submetido a toda equipe para sugestes de melhorias que foram
incorporadas.
Aps as correes para aprimoramento do questionrio, assumiu-se que o mesmo
atendia aos objetivos do programa de medies. Por conseguinte, foi iniciada a segunda
atividade desta fase que consiste na distribuio do questionrio a fim de coletar as
respostas para formao da base de mtricas.
Durante a fase de coleta ocorreram alguns problemas de comunicao com os
participantes da avaliao no envio e recebimento dos questionrio. Como o prazo para
finalizar o programa de medies era exguo no foi possvel extend-lo, de maneira que a
interpretao foi realizada com a resposta de apenas um questionrio.
Os dados coletados foram conferidos em relao a sua completude e armazenados
para posterior interpretao. A planilha com as respostas do participante da avaliao est
disponvel no APNDICE A.
6.1.5 Interpretao
Conforme definido no captulo 5, a fase que sucede a coleta dos dados do programa
de medies a interpretao das informaes obtidas. Para execuo desta etapa o
trabalho foi dividido em trs atividades: anlise das informaes coletadas, clculo dos
dados quantitativos e interpretao dos ndices calculados.
Pgina 98
6.1.5.1 Anlise das Informaes
Dessa forma, aps o recebimento do questionrio respondido pelo participante da
avaliao foi realizada uma anlise para verificar a coerncia entre as respostas.
Outro aspecto identificado na anlise das respostas foi a inexatido do questionrio.
Uma das preocupaes no momento de elabor-lo foi mant-lo o mais legvel possvel
devido ao fato de profissionais de diversas reas participarem da pesquisa. Dessa forma, foi
excluda a utilizao de termos tcnicos da rea de informtica e foi elaborada uma seo
de ajuda para cada uma das questes. No entanto, pde-se perceber na anlise que as
respostas de determinadas questes poderiam ser interpretadas de uma maneira por
profissionais de engenharia de software e de outra por outros tipos de profissionais. Por
exemplo:
Na segunda questo do primeiro ponto de verificao especificado na Tabela 16
verificado o nvel de formalizao do levantamento/especificao de requisitos Quando
questionados se a especificao de requisitos era registrada em documentos formais, no
foi levado em considerao o nvel detalhe dos requisitos neste documento. Desta forma, a
partir da resposta informada, no se consegue obter o grau de entendimento desejado sob o
ponto de vista da Engenharia de Requisitos. Visto que o documento utilizado pelo
participante formal, mas pode no conter o nvel de detalhe exigido para um documento de
especificao de requisitos.
Devido escassez de tempo para finalizao deste estudo optou-se em continuar a
interpretao dos dados obtidos. Visto que a elaborao do processo de engenharia de
requisitos para MPEs desenvolvedoras de softwares embarcados utilizar, alm das
mtricas obtidas no programa de medies, o embasamento terico encontrado na
literatura.
1
: ndice do Ponto de Verificao (Mn).
2
: ndice da Questo (MTn).
Pgina 99
6.1.5.2 Clculo dos Dados Quantitativos
Em conformidade com as definies do captulo 5, a interpretao dos dados
coletados foi realizada na direo bottom-up. Ou seja, a partir dos ndices coletados em
cada questo foram calculados os dados quantitativos por ponto de verificao. A Tabela 23
apresenta cada um desses ndices.
Tabela 23 - ndices dos Pontos de Verificao
Mtrica da Questo (Mn) ndice
1

Mtrica do Ponto de
Verificao (MTn)
ndice
2

M04. ndice de caracterizao do
software.
M04 = 2
M05. Nvel de integrao exigido
pelo software.
M05 = 3
M06. Nvel de portabilidade
exigido pelo software.
M06 = 0
M2. ndice de criticidade do
contexto do software.
MT2 = 5
M07. Nvel de especializao da
equipe e do processo de
levantamento de requisitos.
M07 = 2
M08. Tamanho da equipe de
requisitos em relao equipe
de projeto.
M08 = 0
M09. Nvel de dedicao da
equipe de requisitos.
M09 = 0
M10. Nvel de formao da
equipe de requisitos (Nvel de
conhecimento da Engenharia de
requisitos e rea de formao da
equipe).
M10 = 3
M11. Nvel de conhecimento da
equipe no negcio do software a
ser desenvolvido.
M11 = 2
MT3. ndice de
contextualizao da equipe
de requisitos.
MT3 = 7
M12. Nvel de entendimento dos
requisitos.
M12 = 2
M13. Nvel de especializao da
equipe de levantamento de
requisitos nesta atividade.
M13 = 3
M14. Nvel de detalhe do
levantamento de requisitos.
M14 = 3
MT4. Nvel de entendimento
dos requisitos funcionais e
no-funcionais.
MT4 = 8
M20. Nvel de utilizao de
mtodos/modelos no
levantamento/especificao dos
requisitos (funcionais e no-
funcionais).
M20 =
MT9. ndice de utilizao de
ferramentas de apoio.
MT9 = 1
M15. Nvel de formalizao dos
requisitos.
M15 = 3
MT5. Nvel de identificao e
registro das necessidades,
MT5 = 6
Pgina 100
M16. Nvel de formalizao do
detalhamento da
levantamento/especificao de
requisitos.
M16 = 3
expectativas e restries do
cliente.

M17. Nvel de aprovao dos
requisitos .
M17 = 4
MT6. Nvel de aprovao dos
requisitos.
MT6 = 4
M18. Nvel de refinamento dos
requisitos funcionais.
M18 = 2
MT7. Nvel de refinamento
dos requisitos funcionais.
MT7 = 2
M19. Nvel de Definio e
Manuteno dos Requisitos
Funcionais e No-Funcionais.
M19 = 2
MT8. Nvel de definio e
manuteno dos requisitos
funcionais e no-funcionais.
MT8 = 2
M26. Nvel de anlise da
viabilidade dos requisitos.
M26 = 1
MT14. Nvel de anlise da
viabilidade dos requisitos.
MT14 = 1
M21. Nvel de rastreabilidade
dos requisitos.
M21 = 1
MT10. Nvel de
rastreabilidade dos requisitos.
MT10 = 1
M25. Nvel de anlise da
dependncia entre os requisitos.
M25 = 1
MT13. Nvel de anlise da
dependncia entre os
requisitos.
MT13 = 1
M23. Nvel de anlise de erros
nos requisitos.
M23 = 1
M24. Nvel de corretude dos
testes de requisitos.
M24 = 1
MT12. ndice de corretude
dos requisitos.
MT12 = 2
M27. Nvel de anlise de
revises e correes dos
produtos de trabalho.
M27 =1
MT15. Nvel de anlise de
revises e correes dos
produtos de trabalho.
MT15 = 1
M28. Nvel de anlise de
manutenes nos requisitos
funcionais e no-funcionais.
M28 = 2
MT16. Nvel de anlise de
manutenes nos requisitos
funcionais e no-funcionais.
MT16 = 2
M22. Nvel de identificao de
interfaces.
M22 = 3
MT11. Nvel de identificao
de interfaces.
MT11 = 3
6.1.5.3 Interpretao dos ndices Calculados
A empresa participante da avaliao uma MPE com 6 funcionrios que atua no
desenvolvimento de hardware criptogrfico h 3 anos. Os softwares embarcados
desenvolvidos so dedicados a uma plataforma prpria e compem um produto da empresa.
No entanto, possuem integraes no somente com sistemas da empresa, mas tambm
com sistemas de outros fabricantes. Como o software desenvolvido parte de um produto
da empresa avaliada, os requisitos do software so levantamentos/criados internamente.
As mtricas obtidas no ponto de verificao que avalia a contextualizao do
software (Tabela 23, item 0) revelaram que seu nvel de portabilidade no alto, no entanto
seu ndice de integrao com outros sistemas, inclusive de outros fabricantes, critico.
Logo, o contexto no qual o software est inserido de mdia criticidade.
J os ndices de contextualizao da equipe de requisitos mostraram que no exista
na empresa uma equipe especfica para o levantamento de requisitos. No entanto, apesar
Pgina 101
do software ser apenas um componente de um produto, seu levantamento de requisitos
realizado por um processo a parte. Embora a formao dos responsveis pelo levantamento
seja em computao ou reas afins, estes no possuem conhecimentos aprofundados sobre
a Engenharia de Requisitos. Em compensao, possuem conhecimentos arraigados acerca
do negcio para o qual o software est sendo desenvolvido. O ndice final do ponto de
verificao descrito no item 0 da Tabela 23 posiciona a equipe em um nvel intermedirio de
contextualizao.
A empresa apresentou um excelente nvel de entendimento dos requisitos funcionais
e no funcionais (Tabela 23, item 0). No entanto, o estudo revelou que o levantamento dos
requisitos realizado pelos arquitetos e projetistas do sistema, de maneira que a equipe de
desenvolvimento recebe os requisitos prontos para implementao. E este levantamento
realizado sem a utilizao de nenhum mtodo, modelo ou linguagem especfica (Tabela 23,
item 0).
Apesar de terem mostrado um bom ndice na identificao e registro das
necessidades, expectativas e restries do cliente (Tabela 23, item 0), a pesquisa exps que
o registro destas informaes no realizado em um documento especfico para esse fim.
No entanto, essas informaes so acordadas e registradas em documentos estruturados,
por exemplo, atas de reunio. J o ndice de aprovao dos requisitos propriamente ditos
revelou que os mesmos so acordados e registrados formalmente em documentos como o
de especificao de requisitos (Tabela 23, item 0).
Com relao ao item 0 da Tabela 23, que analisa o nvel de refinamento dos
requisitos funcionais, o ndice encontrado revelou que as necessidades do cliente no so
refinadas gradualmente. Dessa maneira, as necessidades do cliente so levantadas e
refinadas no nvel de requisitos sem a preocupao de identificar as caractersticas do
sistema.
No item 0 da Tabela 23 o clculo dos dados quantitativos revelou que os requisitos
no-funcionais so identificados a partir dos requisitos-funcionais, no entanto, no so
mantidos ao longo do tempo. Alm disso, so realizados somente estudos de viabilidade
dos requisitos funcionais (item 0 da Tabela 23).
O ndice que mede a dependncia entre os requisitos mostrou que esta avaliada
somente entre os requisitos funcionais, desconsiderando os no-funcionais (item 0 da
Tabela 23). J a rastreabilidade dos requisitos apesar de ser elaborada, no mantida ao
longo do projeto (item 0 da Tabela 23).
Pgina 102
No que diz respeito corretude dos requisitos foi identificado que estes so testados
pela equipe de desenvolvimento sem a utilizao de roteiros de testes mas no so
validados pelo cliente (item 0 da Tabela 23).
J os dados quantitativos referentes ao as revises dos produtos de trabalho
denunciaram que a sua reviso e correo realizada durante o processo de
desenvolvimento do software mas no durante sua manuteno (item 0 da Tabela 23). Por
outro lado, as mudanas dos requisitos funcionais e no funcionais so mantidas ao longo
do tempo (item 0 da Tabela 23). importante ressaltar que essa manuteno dos requisitos
no-funcionais no leva em considerao os requisitos funcionais relacionados, conforme
interpretao do item 0 da Tabela 23. Vale destacar tambm que as manutenes mais
freqentes na empresa consistem na gerao de verses especializadas do produto que
no substituem os requisitos originais.
Por fim, podemos identificar por meio dos valores calculados que as interfaces do
sistema so representadas com a utilizao de atores, no entanto, isto registrado em
documentos sem uma estrutura especfica para tal, como atas de reunies (item 0 da Tabela
23).
6.1.6 Captura de Experincias
Como o estudo realizado possui apenas cunho cientfico e foco do trabalho limita-se
a propor adequaes no processo de engenharia de requisitos do OpenUP, a captura de
experincias no foi realizada.
6.2 Consideraes Finais
Apesar do estudo no ter sido realizado conforme o planejamento inicial, a avaliao
da organizao participante comprovou que muitas das dificuldades no desenvolvimento de
sistemas embarcados encontradas na literatura realmente ocorrem no cotidiano das MPEs
que desenvolvem este tipo de software.
Como verificado na interpretao do programa de medies os requisitos no-
funcionais no recebem o tratamento adequado s caractersticas dos softwares
embarcados. Uma vez que no realizada a anlise de viabilidade nem identificada a
dependncia e rastreabilidade destes requisitos. Em conseqncia disso, quando realizada
a manuteno dos requisitos no possvel analisar a coerncia entre eles.
Outro fato comprovado que os profissionais que realizam o
levantamento/especificao dos requisitos no possui conhecimento especializado, alm de
no serem dedicados exclusivamente a estas tarefas. E talvez, por esse motivo no sejam
elaborados documentos adequados ao levantamento/especificao de requisitos, no sejam
Pgina 103
utilizadas tcnicas ou ferramentas de apoio a estas atividades e o refinamento dos requisitos
nveis de no seja executado respeitando os nveis de necessidade, caracterstica e
requisitos.
Embora no identificado na literatura pesquisada, outros aspectos como a no
utilizao de roteiros na execuo dos testes do software e a falta de revises dos produtos
de trabalho na fase de manuteno foram encontrados durante a avaliao.
Aps a execuo do programa de medies, todas as deficincias identificadas
serviro de base para proposio de adequaes no processo de engenharia de requisitos
do PU a fim de adapt-lo ao contexto das MPEs desenvolveras de software embarcado.
Esta atividade ser descrita em detalhes no captulo 7.

Pgina 104

7. DEFINIO DO PROCESSO DE ENGENHARIA DE REQUISITOS PARA O
DESENVOLVIMENTO DE SISTEMAS EMBARCADOS
Este captulo apresentar a elaborao do processo de engenharia de requisitos
para o desenvolvimento de sistemas embarcados. Para isso foram utilizadas as informaes
levantadas nos captulos 02, 03 e 04, os indicadores gerados no programa e medies
descrito no captulo 06 e o contexto das MPEs brasileiras que constroem esse tipo de
software.
A organizao do captulo realizada da seguinte forma: a seo 7.1 apresenta a
elaborao do Processo de Engenharia de Requisitos para Sistemas Embarcados detalhada
em termo dos elementos do processo (Papis, Tarefas, Produtos de Trabalho, Diretrizes,
Listas de Verificaes e Conceitos). Na seo 7.2 apresentada uma comparao do
ProReqSE com outros processos para sistemas embarcados. A seo 7.3 descreve as
consideraes finais do captulo.
7.1 Processo de Engenharia de Requisitos para Sistemas Embarcados
ProReqSE
O Processo de Engenharia de Requisitos para Sistemas Embarcados (ProReqSE) foi
modelado por meio da ferramenta Eclipse Process Framework Composer (EPF) (Foudation
2008). O EPF uma ferramenta visual de modelagem de processos que utiliza como base o
Software Process Engineering Metamodel (SPEM) e possibilita a importao de bibliotecas
de processos a fim de personaliz-las de acordo com o domnio da aplicao. O ProReqSE
utilizou como base a biblioteca do Open UP. O Basic Unified Process foi criado pela IBM e
rebatizado de Open Unified Process (OpenUP) em maro de 2006. O OpenUp uma
simplificao do RUP que se adapta realidade de pequenas equipes.
O fato de o EPF ser uma ferramenta freeware e o OpenUP uma biblioteca aberta
foram aspectos fortemente considerados no momento de escolha da ferramenta e do
modelo de processo a ser utilizado na elaborao do ProReqSE. A meta era melhorar a
qualidade dos processos atuais sem onerar os custos para sua adoo. Afinal, quanto
menores as dificuldades para implementao do ProReqSE, maiores sero suas chances de
aceitao.
Da mesma maneira que o OpenUP, o ProReqSE um processo elaborado para
aplicao em equipes pequenas e co-localizadas que buscam uma abordagem simplificada
para a especificao de seus produtos. Esta abordagem foi mantida devido ao curto prazo
normalmente exigido para o desenvolvimento de sistemas embarcados, conforme descrito
no captulo 02, e ao contexto das MPEs. Este tipo de empresa possui equipes bastante
Pgina 105
reduzidas, de maneira que um membro, normalmente, assume mais de um papel dentro do
processo, o que demanda, portanto, um processo leve, gil e eficiente.
Outros dois pontos foram considerados na definio das principais caractersticas do
ProReqSE: a informalidade dos processos de desenvolvimento das micro e pequenas
empresas brasileiras e a formao multi - disciplinar das equipes de desenvolvimento de
sistemas embarcados. Dessa forma, o ProREqSE :
Personalizvel: de maneira que as empresas possam adequ-lo s suas
necessidades de acordo com sua cultura e nvel de formalizao;
Completo: permite que o processo de engenharia de requisitos seja efetivamente
utilizado para atingir seus objetivos sem a necessidade de complementaes;
Mnimo: de forma que seu foco atingido com a utilizao de poucos elementos.
Conforme os processos de requisitos tradicionais citados nos captulos 3 e 4, o
ProReqSE define um conjunto de atividades cujo objetivo a compreenso, o refinamento,
a documentao e a verificao das necessidades do cliente de forma a construir um
software embarcado adequado. Para, isso foram definidas as seguintes atividades: definir
viso, encontrar e resumir requisitos e detalhar requisitos.
As atividades devero ser executadas na seqncia em que foram citadas acima, ou
seja, primeiro deve ser definida a viso do sistema e posteriormente os requisitos devem ser
resumidos e finalmente detalhados.
Estas atividades possuem artefatos de entrada e sada os quais foram denominados
produtos de trabalho. Alm disso, elas devem ser executadas pelos papis definidos no
processo.
Embora os papis do ProReqSE exijam conhecimento especfico de Engenharia de
Requisitos e grande parte das empresas avaliadas no captulo 06 no possuam equipes
com este conhecimento, tal aspecto no ser de grande relevncia, visto que o ProReqSE
foi elaborado de forma a apoiar todo o processo de engenharia de requisitos. Para isso
foram definidos modelos de documentos (templates), diretrizes de trabalho, listas de
verificaes e conceitos especficos da engenharia de requisitos.
O primeiro ponto a ser destacado em relao ao processo definido a abrangncia
de sua aplicao. Apesar da dificuldade na separao dos requisitos de hardware e software
no domnio de sistemas embarcados, descritas na seo 4.4.3, o ProReqSE optou por
manter a distino entre estes dois componentes do sistema. Dessa forma, o ProReqSE
abordar o processo de engenharia de requisitos de sistemas embarcados visando a
construo de seu software. Dois so os motivos que levaram a esta deciso: a falta de
Pgina 106
conhecimento, por parte da equipe desenvolvedora do processo, em relao engenharia
de hardware; as diferentes necessidades demandadas pelos dois processos de
desenvolvimento dificilmente uma tcnica ou modelo para levantamento e especificao
de requisitos de software seria aplicvel ao hardware. No entanto, o ProReqSE no deixou
de levar em considerao esta intrnseca ligao entre os dois componentes do sistema ao
definir os elementos do processo.
A ferramenta EPF permite a publicao de um guia eletrnico do processo criado.
Este guia visa facilitar de maneira significativa o entendimento e a institucionalizao do
processo nas empresas, visto que pode ser publicado em uma rea pblica, permitindo o
acesso de todos os envolvidos. A Figura 20 ilustra a pgina inicial do Guia Eletrnico de
Processos do ProReqSE:

Figura 20 - Tela Inicial do ProReqSE
Pgina 107
As sees a seguir apresentaro em detalhes os elementos que compem o
ProReqSE, bem como, as justificativas de sua utilizao no domnio de sistemas
embarcados e MPEs.
7.1.1 Papis
Segundo as melhores prticas da ER descritas na seo 1.1.1.1 do captulo 4,
atribuir as atividades de ER a membros habilidosos melhora a performance do
desenvolvimento tornando-o mais previsvel. Dessa forma, os papis definidos no o
ProReqSE levam em considerao as habilidades dos profissionais que devem assumi-los,
alm destas habilidades estarem diretamente relacionadas as atividades que cada papel
executa. Os papis definidos no ProReqSE so:
Analista: representa os interesses dos clientes e dos usurios finais cujo objetivo
recolher as informaes dos envolvidos para entender o problema a ser
resolvido, capturar seus requisitos e definir suas prioridades.
O analista o papel principal da ER, ele executa todas as atividades do processo
e o responsvel pela elaborao da maioria dos produtos de trabalho. Dada
sua importncia no processo, foram listadas, a seguir, as habilidades e os
conhecimentos exigidos do profissional que pretenda assumir este papel:
o Habilidade em identificar e entender os problemas e oportunidades;
o Habilidade de articular as necessidades que esto associadas com os
principais problemas a serem resolvidos ou com a oportunidade de ser
realizada;
o Habilidade de colaborar efetivamente com toda a equipe em sesses
colaborativas de trabalho (como workshops, sesses de JAD e outras
tcnicas);
o Boa capacidade de comunicao verbal e escrita;
o Conhecimento dos domnios de negcio e de tecnologia ou a capacidade
de absorver e compreender rapidamente tal informao.
Arquiteto: responsvel por fornecer apoio tomada de decises, balancear os
interesses dos envolvidos, os riscos tcnicos e assegurar que as decises sejam
comunicadas, validadas e seguidas de forma eficaz.
Visto que o arquiteto possui um papel secundrio no processo, ele no
responsvel pela execuo de nenhuma atividade e nem pela elaborao dos
produtos de trabalho.
Pgina 108
Desenvolvedor: responsvel por fornecer apoio tomada de decises
relacionadas implementao. Assim como o arquiteto, no responsvel pela
realizao de nenhuma atividade e nem pela confeco de produtos de trabalho.
Envolvidos: representam os grupos de envolvidos que precisam ser satisfeitos
pelo projeto. um papel que pode ser assumido por qualquer pessoal
materialmente afetada pelo resultado do projeto. Da mesma maneira que o
desenvolvedor e arquiteto no executa atividades especficas dentro do processo
e nem elabora produtos de trabalho.
Gerente de Projetos: conduz o planejamento do projeto, coordena as interaes
com os envolvidos e mantm a equipe de projeto focada em alcanar os objetivos
do projeto.
7.1.2 Atividades
Conforme citado anteriormente, o ProReqSE foi dividido em quatro atividades, onde
cada uma delas possui uma seqncia de tarefas a serem seguidas para atingir o objetivo
da atividade.
Os itens seguintes detalham as atividades e suas respectivas tarefas:
Definir Viso: definir a viso para o futuro sistema, ou seja, descrever o
problema a ser resolvido e as caractersticas do sistema de acordo com as
solicitaes dos interessados. Vale ressaltar que neste momento no h
separao entre hardware e software. A viso deve ser elaborada para o sistema
como um todo.
O fluxo de execuo da atividade Definir Viso ilustrado na Figura 21.
Pgina 109

Figura 21 Fluxo da Atividade Definir Viso
Conforme apresentado na Figura 21 esta atividade subdividida nas seguintes
tarefas:
o Identificar os Envolvidos: devem ser identificados todos os envolvidos
com o desenvolvimento do sistema, como tomadores de deciso, clientes,
usurios em potencial, parceiros, especialistas de domnio, analistas de
mercado e outras partes interessadas. Devem ser determinados os perfis
dos potenciais ou atuais usurios do sistema que se encaixem no papel
de ator. Alm disso, importante que informaes iniciais sobre os
usurios-chave e seu ambiente sejam registradas no documento de viso.
Esta tarefa foi definida observando as caractersticas dos sistemas
embarcados definida na seo 4.3.4 de que esse tipo de sistemas
normalmente possui muitos envolvidos em seu desenvolvimento e que
estes so os responsveis por criar os requisitos do software. Para que o
processo de requisitos atinja seu objetivo no desenvolvimento de software
necessrio que estes profissionais estejam envolvidos no projeto desde a
sua concepo.
Pgina 110
o Obter Acordo em Relao ao Problema a ser Resolvido: para evitar
qualquer mal-entendido durante o processo de desenvolvimento do
software importante que todos os envolvidos estejam de acordo com a
definio do problema a ser resolvido, bem como com a terminologia a ser
utilizada durante o projeto.
Aps formular o problema esta informao deve ser registrada na seo
correspondente do Documento de Viso, j a terminologia adotada deve
ser documentada em um Glossrio.
Esta uma tarefa fundamental no processo de sistemas embarcados dada
quantidade de interessados envolvidos no desenvolvimento e a
complexidade do sistema a ser desenvolvido.
Tcnicas sugeridas para executar esta etapa: brainstorm, workshops,
entrevistas e sesses de JAD.
o Capturar o Vocabulrio Comum: de grande importncia que se
trabalhe junto aos interessados para criar um glossrio que defina
acrnimos, abreviaes e termos tcnicos e negociais relevantes. Afinal,
cada projeto tem sua terminologia especfica e todos na equipe devem
entend-la bem, a fim de que a comunicao entre os envolvidos seja
realizada de maneira efetiva. Vale ressaltar que este glossrio deve ser
continuamente refinado e expandido ao longo do projeto.
No domnio de sistemas embarcados muito comum a presena de
equipes multidisciplinares, portanto, primar por uma comunicao efetiva
de fundamental importncia para o sucesso do projeto. Quanto maior a
equipe e sua diversidade, maior ser a necessidade de se manter um
glossrio atualizado do sistema.
o Obter Solicitaes dos Interessados: deve ser utilizado o mtodo mais
apropriado para capturar informaes. Foi desenvolvida uma diretriz para
guiar esta tarefa, nesta diretriz so descritas vrias tcnicas, sendo que
cada uma aplicvel a uma situao em particular ou a um certo tipo de
interessado.
Dado o contexto de sistemas embarcados, o ideal, o encontro
presencial com todos os envolvidos, visto que isso reduz as chances da
equipe de projeto entender as necessidades de maneira inadequada.
Qualquer requisito capturado durante esta tarefa deve ser registrado na
Lista de Priorizao das Necessidades.
Pgina 111
No contexto de sistemas embarcados nem sempre existe um cliente final
participando do desenvolvimento do sistema, alm do que muitas vezes
os envolvidos possuem pouco conhecimento acerca do sistema
desenvolvido. Para suprimir essas dificuldades, o ProReqSE utiliza a
soluo proposta por Puschnig, descrita na seo 4.3.4, que sugere o
envolvimento de especialistas de domnio. Associado a isso o ProReqSE
sugere o uso de sees de JAD na execuo dessa tarefa.
o Definir as Fronteiras do Sistema: Encontrar e definir a linha que divide a
soluo e o mundo real que a cerca. Essa tarefa consiste em identificar as
interfaces bem como as informaes de entrada e sada compartilhadas
entre os usurios, sistemas, mquinas (ex: sensores, atuadores e
hardware) e qualquer elementos do ambiente que interagem com o
sistema (ex: pssaros e tempestades).
Esta uma tarefa importante na definio dos requisitos de sistemas
embarcados visto que este tipo de software normalmente possui um
grande nmero de integraes. Alm disso, a definio das fronteiras do
sistema impacta diretamente na sua arquitetura.
Outra caracterstica que deve ser considerada na execuo desta tarefa
que os sistemas embarcados possuem tipos de interfaces diferentes dos
sistemas tradicionais. A diretriz Encontrar e Resumir Atores e Caso de
Uso auxilia a identificao das interfaces do sistema que so registradas
nos modelos de caso de uso.
o Identificar as Restries do Sistema: o objetivo desta tarefa identificar
todas as restries que possam impactar no projeto. Os principais tipos de
restries dos sistemas embarcados so: polticas (normas,
regulamentos, restries de regulamentao e padres legais),
econmicas (oramento, licenas), ambientais (execuo em ambientes
inspitos), fsicas (tamanho e peso), tcnicas (plataformas, tecnologias
processador, memria), viabilidade (prazo, alocao de recursos) e
sistema (compatibilidade de solues, suporte a sistemas operacionais,
ambientes, restries de tempo real e gerenciamento de consumo de
potncia sem perda de desempenho).
fundamental importncia que essas restries sejam identificadas de
forma adequada, pois em tarefas posteriores elas sero refinadas em
requisitos no-funcionais. Este aspecto extremamente crtico em
Pgina 112
sistemas embarcados dado que os requisitos no-funcionais so tratados
tardiamente gerando impactos no produto final.
o Identificar os requisitos de qualidade: o objetivo desta tarefa
identificar todos os requisitos de qualidade que possam impactar no
projeto. Aqui devem ser considerados aspectos como performance,
usabilidade, confiabilidade, portabilidade, escalabilidade,
manutenibilidade, reusabilidade, interoperabilidade, testabilidade,
correo, consistncia, compatibilidade, complexidade, i
internacionalizao (Fernandes 2005).
fundamental importncia que esses requisitos sejam identificados de
forma adequada, pois em tarefas posteriores sero refinados em
requisitos no-funcionais. Este aspecto extremamente crtico em
sistemas embarcados dado que os requisitos no-funcionais so tratados
tardiamente gerando impactos no produto final.
o Definir as Caractersticas do Sistema: refinar as necessidades do
envolvidos, indicando os recursos e as capacidades que o sistema deve
possuir para atend-las. Nessa tarefa as caractersticas so registradas
no documento de viso.
o Obter Concordncia: nesta tarefa os envolvidos devem revisar a viso
do projeto a fim de garantir consentimento, determinar qualidade e
identificar as mudanas requisitadas.
Como o desenvolvimento de sistemas embarcados normalmente muito
complexo e conta com a participao de diversos envolvidos, importante
que a viso do projeto seja revisada e acordada. Esta tarefa apoiada
pela Lista de Verificao de Viso.
Encontrar e Resumir Requisitos: O propsito desta atividade identificar e
capturar requisitos funcionais e no-funcionais para o sistema. Estes requisitos
formam a base da comunicao e concordncia, entre os interessados e a equipe
de desenvolvimento, a respeito do que o sistema deve fazer para atender as
necessidades dos envolvidos. O seu objetivo entender os requisitos em um alto
nvel de abstrao para que seja possvel determinar o escopo do sistema. Esta
atividade pode ser realizada dividindo-se o sistema em componentes menores e
construindo-se conexes entre eles. Posteriormente sero realizadas analises
para detalhar os requisitos prioritrios para implementao.
Pgina 113
As tarefas da atividade Encontrar e Resumir Requisitos so ilustradas na Figura
22:

Figura 22 Fluxo da Atividade Encontrar e Resumir Requisitos
Esta atividade subdividida nas seguintes tarefas:
o Obter Informaes: esta tarefa executada com o apoio de diversas
tcnicas de obteno de requisitos, como: brainstorming, JAD,
questionrios, wokshops dentre outras. Outra alternativa a utilizao de
documentaes de outros sistemas com caractersticas semelhantes ao
que est sendo desenvolvido.
No desenvolvimento de sistemas embarcados, a participao de
especialistas de domnio de vital importncia para definio de seus
requisitos, uma vez que esse tipo de sistemas possui caractersticas
especficas.
Conforme descrito do captulo 4, a identificao e consulta de todas as
origens dos requisitos e o envolvimento de clientes, usurios e
especialistas durante a Engenharia de Requisitos melhoram
respectivamente a cobertura dos requisitos e o entendimento das reais
necessidades.
A partir deste momento interessante que se comece a separar,
explicitamente, o hardware do software. As atividades e tarefas seguintes
Pgina 114
devem ser aplicadas apenas aos requisitos de software, ou seja, aqueles
diretamente ligados ao aplicativo a ser desenvolvido.
o Encontrar os Casos de Uso: tomando como base as tcnicas
elaboradas por (Nars 2002), a principal estratgia para descobrir os casos
de uso o fato de se trabalhar baseado em funes e no em atores.
Alm de proporcionar maior flexibilidade, esta tcnica permite que se
encontre com maior habilidade todos os casos de uso funcionais do
sistema. Para executar esta tarefa so sugeridos trs passos: identificar
as maiores funcionalidades do sistema, nomear cada caso de uso e
descrev-los brevemente.
No domnio de sistemas embarcados os tipos de funcionalidades mais
comumente encontradas so: as de inicializao do sistema, monitorao
de sensores e reporte de informaes de status (Nars 2002). Muito
cuidado deve ser tomado durante esta tarefa a fim de identificar apenas o
que necessrio para o sistema em especificao. No domnio de
sistemas embarcados um grande desafio levantar apenas as
funcionalidades do sistema a ser construdo, dada a alta interatividade
entre ele e os demais sistemas envolvidos.
o Identificar e Capturar os Termos do Domnio: o propsito desta tarefa
assegurar que os termos ambguos ou especficos do domnio esto
claramente definidos no glossrio e que esto sendo utilizados de forma
consistente.
o Identificar e Capturar os Requisitos Suplementares: o objetivo desta
tarefa obter os requisitos no-funcionais relevantes para o sistema, por
meio da interao com os envolvidos. Outro instrumento de apoio so as
restries identificadas na atividade anterior, que so refinadas em
requisitos suplementares.
o Identificar as Dependncias entre os Requisitos: esta tarefa foi
definida especificamente para o domnio de sistemas embarcados, onde
os requisitos no-funcionais tendem a estar relacionados com mais de um
requisito funcional. Esta relao pode ser de dependncia, colaborao
ou prejuzo. Buscando apoiar a especificao deste relacionamento, o
ProReqSE sugere a utilizao de um documento denominado Documento
de Referncia Cruzada. Alm disso este produto de trabalho ser
extremamente til na anlise de impacto das mudanas no sistema. Esta
Pgina 115
tarefa baseia-se nas melhores prticas da ER definidas na seo 1.1.1.1 e
nos conceitos de rastreabilidade definidos no item 4.3.6.
o Obter Concordncia: Esta tarefa visa conduzir revises nos requisitos
junto aos envolvidos para garantir consistncia dos requisitos (funcionais
e no-funcionais) com o documento de viso, determinar qualidade e
identificar solicitaes de mudanas. Essa tarefa apoiada pelas listas de
verificao modelo de caso de uso e de viso.
o Atualizar a Lista Priorizao de Necessidades: Revisar os requisitos de
acordo com as necessidades dos envolvidos para que os mesmos sejam
priorizados na Lista de Priorizao de Necessidades, conforme descrito
na seo 1.1.1.1 do captulo 04.
Detalhar Requisitos: Esta atividade visa descrever os requisitos em detalhes, de
acordo com sua priorizao, para permitir a iniciao do desenvolvimento.
O fluxo da atividade Detalhar Requisitos ilustrado na Figura 23:

Figura 23 Fluxo da Atividade Detalhar Requisitos

o Detalhar os Casos de Uso: para executar esta tarefa sugere-se a
utilizao de um processo iterativo e progressivo de refinamento. O
primeiro passo consiste em elaborar uma descrio breve do caso de uso,
depois devem ser definidos e numerados os fluxos de eventos e, por fim,
identificar as os requisitos no resolvidos, com o objetivo de esclarec-los.
No item 7.1.3 foi definido um modelo para a especificao de caso de uso
a fim de apoiar a execuo desta tarefa. No entanto, caso se deseje
elaborar um documento prprio, o detalhamento de caso de uso deve
possuir no mnimo: o fluxo principal; como e quando o caso de uso
comea e termina; quando o caso de uso ir interagir com os atores e o
que ser trocado entre eles; o que o sistema precisa fazer para executar o
caso de uso; quando e como o caso de uso precisar de dados
armazenados no sistema ou necessitar armazenar dados no sistema;
eventos excepcionais; pr-condies e ps-condies.
Pgina 116
As especificaes de caso de uso devem ser detalhadas de acordo com
sua priorizao, a Diretriz Detalhar Caso de Uso apia este trabalho. O
nvel de detalhe varia de acordo com as necessidades do projeto e a
complexidade do caso de uso. A diretriz Nvel de Abstrao dos Casos
de Uso auxilia a discusso sobre diferentes nveis de detalhe que podem
ser aplicados aos casos de uso. As particularidades dos casos de uso so
definidas na Especificao de Caso de Uso e nos Diagramas de
Seqncia de Cenrios Operacionais.
o Detalhar Requisitos Suplementares: Os requisitos no-funcionais
devem ser detalhados no documento Especificao Suplementar de
Requisitos, de acordo com a diretriz Requisitos Suplementares.
Conforme descrito no captulo 4, requisitos no-funcionais so crticos
para o desenvolvimento de sistemas embarcados. O ProReqSE, portanto,
sugere a utilizao de um mtodo denominado PLanguage (Gilb 1989).
Este mtodo auxilia o levantamento de requisitos no-funcionais, evita a
ocorrncia de problemas como a falta de clareza e detalhamento de sua
especificao e a confuso entre os requisitos funcionais e no-
funcionais. Alm disso, com a utilizao da PLanguage os testes de
requisitos no-funcionais podem ser executados com base na prpria
especificao, eliminando a necessidade de elaborao de um documento
de testes. O documento de especificao suplementar ir agregar a tabela
de especificao da PLanguage.
o Detalhar Termos do Glossrio: Nesta tarefa todos os termos ambguos
ou especficos do domnio, utilizados nas especificaes de caso de uso e
no documento de especificao suplementar de requisitos, devem ser
revisados e refinados conforme a necessidade.
Revisar Requisitos: Esta atividade visa revisar todos os produtos de trabalho
elaborados nas atividades e tarefas anteriores com o objetivo de validar o
entendimento dos requisitos e garantir sua concordncia com as expectativas dos
envolvidos.
As tarefas da atividade Revisar Requisitos so ilustrados na Figura 24:

Pgina 117
Figura 24 Fluxo da Atividade Revisar Requisitos
o Revisar Documentos: Aps a elaborao da viso do sistema e do
detalhamento dos requisitos funcionais e no funcionais o ProReqSE
sugere a execuo de uma reviso em todos os produtos de trabalho
gerados, como, Documento de Viso, Glossrio, Especificao de Caso
de Uso, Especificao Suplementar, Documento de Referncia Cruzada
dentre outros. Essas verificaes podero ser executados, por meio de
um dos trs mtodos de reviso descritos no captulo 04: inspeo,
walkthrough ou reviso por pares.
As listas de verificao iro guiar a execuo das revises. Os resultados
dessa atividade devem ser registradas nestes documentos de forma que
se possa construir uma base histrica dos erros cometidos em projetos
passados.
o Obter Concordncia: Conduzir uma reviso nos requisitos, especificao
de caso de uso e especificao suplementar de requisitos, com os
envolvidos relevantes a fim de garantir sua qualidade e consistncia com
o documento de viso e identificar solicitaes de mudana.
7.1.3 Produtos de Trabalho
Conforme definido nos captulos 03 e 04, os Produtos de Trabalho so informaes
produzidas, modificados ou utilizados pelas atividades do processo. Para facilitar o
entendimento, a elaborao dos produtos de trabalho e a melhoria da qualidade da
especificao foram definidos modelos (templates) destes documentos.
O ProReqSE sugere a utilizao de poucos artefatos devido a seu direcionamento s
MPEs e a cultura das equipes de desenvolvedoras de software embarcado. No entanto,
estes artefatos podem ser acrescidos, suprimidos ou customizados de acordo com a
necessidade de cada projeto.
Os modelos de documentos dos produtos de trabalho definidos ou customizados
pelo ProReqSE, para o domnio especifico de sistemas embarcados, so disponibilizados
nos APNDICES E,F e G.
O ProReqSE fornece os seguintes produtos de trabalho:
Documento de Viso: Este artefato fornece uma base de alto nvel, s vezes
contratual, para os requisitos tcnicos mais detalhados que so visveis para os
envolvidos. Captura a essncia do sistema descrevendo as restries do projeto
Pgina 118
e os requisitos de alto nvel que do ao leitor uma viso geral do sistema de uma
perspectiva dos requisitos comportamentais.
Especificao de Caso de Uso: Este artefato captura a seqncia das aes
executadas por um sistema que tenham um resultado de valor observvel para
aqueles que interagem com o sistema. O principal diferencial da especificao de
caso de uso utilizada pelo ProReqSE a definio de tipos de atores especficos
do domnio de sistemas embarcados, descritos na tarefa Definir as Fronteiras do
Sistema.
Especificao Suplementar: Este artefato captura e detalha todos os requisitos
do sistema que no so especificados nos casos de uso, incluindo requisitos de
atributos de qualidade e requisitos funcionais globais. O maior diferencial da
Especificao Suplementar do ProReqSE a utilizao da tabela de
especificao da PLanguage.
Glossrio: O objetivo do glossrio fornecer um vocabulrio comum acordado
por todos os envolvidos. Ajuda pessoas de diferentes grupos funcionais a
alcanar uma compreenso mtua do sistema. O objetivo no registrar todos os
termos possveis, mas somente aqueles que no esto claros, so ambguos ou
pertencem a domnios especficos.
Lista de Priorizao das Necessidades: O objetivo deste artefato priorizar as
necessidades dos envolvidos a fim de guiar a seqncia do detalhamento, projeto
e implementao do sistema.
Modelo de Caso de Uso: Este artefato captura um modelo das funes
desejadas do sistema e de seu ambiente, e serve como um contrato entre o
cliente e os desenvolvedores. O principal diferencial do modelo de caso de uso
utilizado pelo ProReqSE a definio de tipos de atores especficos do domnio
de sistemas embarcados.
Documento de Referncia Cruzada: A finalidade deste documento manter a
rastreabilidade e a concorrncia (dependncia, prejuzo ou colaborao) entre os
elementos do projeto. O ProReqSE sugere que seja feita a rastreabilidade entre
necessidades, caractersticas, requisitos funcionais, requisitos no-funcionais.
Contudo, outros elementos do projeto podem ser rastreados.
Diagrama de Seqncia de Cenrios Operacionais: Este documento visa
representar a seqncia temporal da execuo de cada um dos cenrios dos
casos de uso. De maneira que a concorrncia entre os fluxos possa ser tratada a
Pgina 119
fim de definir a correta seqncia a ser obedecida durante a execuo. Por
exemplo: identificar qual exceo deve ser priorizada caso duas excees sejam
lanadas no mesmo momento.
7.1.4 Diretrizes
As diretrizes so guias que buscam facilitar a execuo das tarefas que compe as
atividades definidas do ProReqSE e conseqente a elaborao de seus produtos de
trabalho. Estes itens so de vital importncia para o processo dado o contexto das equipes
desenvolvedoras de sistemas embarcados.
As diretrizes disponibilizadas no ProReqSE so:
o Armadilhas de Requisitos;
o Detalhar Casos de Uso;
o Encontrar Caso de Uso;
o Encontrar e Resumir Atores e Caso de Uso;
o Escrever Requisitos Adequadamente;
o Formato dos Casos de Uso;
o Modelo de Caso de Uso;
o Realizar a Reviso dos Requisitos;
o Requisitos Suplementares;
o Tcnicas para Obteno de Requisitos.
7.1.5 Listas de Verificao
Conforme definido no captulo 04, as listas de verificao visam garantir a qualidade
e a completude dos produtos gerados em cada uma das atividades do processo de
engenharia de requisitos para sistemas embarcados, bem como, a alta satisfao do cliente.
O ProReqSE utiliza as Listas de Verificao definidas a seguir na atividade Revisar
Requisitos:
o Lista de Verificao de Ator;
o Lista de Verificao de Bons Requisitos;
o Lista de Verificao de Casos de Uso;
o Lista de Verificao de Modelos de Caso de Uso Disponvel no
APNDICE C;
Pgina 120
o Lista de Verificao de Requisitos Suplementares Disponvel no
APNDICE D;
o Lista de Verificao de Viso Disponvel no APNDICE B;
7.1.6 Conceitos
O objetivo dos conceitos definir de forma detalhada termos e tcnicas
freqentemente utilizados na Engenharia de Requisitos. Da mesma forma que as diretrizes,
este elemento do processo auxilia as equipes de desenvolvimento de sistemas embarcados,
uma vez que estas no possuem conhecimentos especficos de Engenharia de Requisitos.
Os conceitos fornecidos pelo ProReqSE so:
o Ator;
o Atributos de Requisitos;
o PLanguage;
o Caracterstica;
o Caso de Uso;
o Modelo de Caso de Uso;
o Rastreabilidade;
o Requisitos;
o Requisitos Arquiteturalmente Significantes;
o Requisitos Suplementares.
7.2 Comparao do ProReqSE com Outros Processos
Conforme foi observado nos captulos 03, os processos de desenvolvimento de
software embarcado se assemelham muito aos processos tradicionais. Apesar destes
processos serem especficos para o domnio de sistemas embarcados eles do maior
enfoque ao projeto do software. A Tabela 24 descreve as diferenas bsicas entre os
processos de sistemas embarcados apresentados na literatura e o ProReqSE.
Tabela 24 - Comparativo das Caractersticas de ER em Processos de
Desenvolvimento de Sistemas Embarcados
Caracterstica do Processo de ER RUP SE IPProcess UPES ProReqSE
1. H um processo de Engenharia de
Requisitos definido?
S S S S
2. A atividade de levantamento de requisitos
realizada?
S S S S
Pgina 121
3. A atividade de especificao se preocupa
somente com o que ser desenvolvido?
S S S S
4. A atividade de design tratada separada da
especificao?
N S S S
5. O processo de engenharia de requisitos
possui caractersticas especificas do
desenvolvimento de sistemas embarcados
S N N S
6. O processo de engenharia de requisitos
possui a mesma estrutura dos processos
tradicionais?
N S S S
O comparativo do ProReqSE com outros processos de desenvolvimento de sistemas
embarcados evidencia os valores que foram agregados no processo elaborado. A
separao do tratamento dos requisitos e do projeto de software e a insero de tarefas,
atividades, papis, conceitos, diretrizes e listas de verificao especificas para este domnio
so caractersticas que reforam essa afirmao.
7.3 Consideraes Finais
As atividades do processo proposto devem ser executadas durante as fases do
desenvolvimento do software, no entanto, nada impede que alguma atividade ou tarefa seja
executada mais de uma vez ou seja quebrada com o intuito de adequar os artefatos
gerados. importante que os produtos gerados a partir do processo de engenharia de
requisitos dem subsdios execuo dos processos subseqentes, de forma que o produto
final atinja seus objetivos.
Neste captulo foi descrito o processo de engenharia de requisitos para sistemas
embarcados (ProReqSE) criado a partir da avaliao, detalhada no captulo 06, do
referencial terico, exposto nos captulos 02, 03 e 04 e do conhecimento prtico na rea de
Engenharia de Requisitos.
O captulo seguinte apresenta as concluses e trabalhos futuros relativos ao estudo
desenvolvido.
Pgina 122

8. CONSIDERAES FINAIS DO TRABALHO
8.1 Concluso
No presente trabalho foi apresentada uma proposta de processo de engenharia de
requisitos para sistemas embarcados. Esta proposta foi elaborada com base nos resultados
de uma avaliao do processo de desenvolvimento de micro e pequenas empresas
desenvolvedoras de sistemas embarcados e estudos sobre processos de desenvolvimento,
processo de requisitos, software embarcado e GQM.
A linha de pesquisas de sistemas embarcados que vem crescendo muito nos ltimos
anos devido evoluo, no apenas dos microprocessadores, mas tambm de outros
componentes de hardware. Conseqentemente, a quantidade de produtos no mercado
compostos de sistemas embarcados aumentou de forma significativa. No entanto, o
software utilizado nesses produtos no tem conseguido acompanhar essa evoluo.
Inmeras dificuldades foram encontradas durante o desenvolvimento do trabalho,
dentre elas a escassez no s de profissionais da rea de cincia da computao com
conhecimento em software embarcado, mas tambm de material de apoio pesquisa sobre
processos de desenvolvimento e processos de requisitos para esse domnio de sistemas.
Contudo, esses obstculos tornaram-se incentivos realizao do trabalho.
Outro empecilho encontrado foi a carncia de micro e pequenas empresas
desenvolvedoras de software embarcado que estivessem dispostas a participar da pesquisa.
Alm disso, o fato dos pesquisadores envolvidos neste estudo no vivenciarem o contexto
do desenvolvimento de sistemas embarcados dificultou a elaborao do programa de
medies utilizado na avaliao. O nvel de detalhe das questes, os termos a serem
utilizados no questionrio e a definio das mtricas de cada ponto de verificao
possivelmente no tenham sido definidos de forma que pudessem avaliar precisamente as
deficincias e os pontos fortes do processo de requisitos das empresas participantes.
Mesmo tendo contatado trs empresas que confirmaram a sua participao na
pesquisa, apenas uma delas respondeu ao questionrio. Isso prejudicou a pesquisa pela
falta amostras mas serviu como prova de conceito inicial para o GQM idealizado. Apesar
disso, a juno dos resultados obtidos na avaliao com as caractersticas do
desenvolvimento de software embarcado identificadas nas pesquisa serviram como subsidio
elaborao do ProReqSE.
O perfil dos profissionais envolvidos no desenvolvimento de software embarcado
geralmente voltado para a rea de engenharia, esta uma caracterstica que dificultou a
Pgina 123
elaborao dos papis do ProReqSE, pois as habilidades dos envolvidos no condizem com
as habilidades requeridas. Esse problema foi solucionado com a elaborao de diretrizes e a
definio dos conceitos que do suporte a execuo das atividades do ProReqSE.
Por fim, a combinao do uso do GQM na avaliao do processo de requisitos
existente nas MPEs desenvolvedoras de software e a utilizao de conceitos da literatura de
sistemas embarcados demonstrou uma boa aplicabilidade na definio do ProReqSE.
8.2 Trabalhos Futuros
Este projeto foi pioneiro na Universidade Catlica de Braslia na rea de sistemas
embarcados. Como o trabalho abordou apenas o processo de Engenharia de Requisitos de
Micro e Pequenas Empresas desenvolvedoras de software, existem diversas oportunidades
para dar continuidade a essa linha de pesquisa:
Ampliar a pesquisa abordando outros processos do desenvolvimento de
software.
Refinar a avaliao elaborando outras questes, pontos de verificao e
mtricas.
Aplicar a avaliao coletando informaes em uma maior quantidade de
empresas com mais respondentes.
Refinar o ProReqSE com a sugesto de novas adequaes.
Elaborar um processo completo de desenvolvimento de software embarcado.
Implantar o processo em uma ou mais MPEs.
Obter e armazenar indicadores que avaliem a eficincia do ProReqSE e
sugira melhorias.
Conseguir parceria de empresas ou instituies que trabalhem com o
desenvolvimento de software embarcado.
Adequar o ProReqSE de maneira que possa estar aderente a modelos de
melhoria de processo de software.
Pgina 124
REFERNCIAS

Acua, A., M. Ferre, M. Lpes, e L. Mate. The Software Process: Modeling, Evaluatio and
Improvement. World Scientific Publishing Company, 2000.
Anquetil, N., K. M. Oliveira, e K. D. Souza. Uso do GQM para avaliar implantao de
processo de manuteno de software. IV Simpsio Brasileiro de Qualidade de Software,
2005.
Barbiero, A. A. Ambiente de Suporte ao Projeto de Sistemas Embarcados. Curitiba:
Universidade Federal do Paran, 2006.
Barreto, R.S. Sistemas Embarcados: o novo boom da Informtica? Sociedade Brasileira de
Computao, 2006.
Barros, E., G. Esmeraldo, e A. L. M. Silva. Uma Metodologia de Desenvolvimento Baseada
em Componentes Aplicada Modelagem de Sistemas Embarcados. Workshop de
Desenvolvimento Baseado em Componentes (WDBC), 2006.
Barros, E., J. Bione, M. Lima, e F. Santos. IpProcess: A Development Process for Soft Ip-
Core with Prototiping in FPGA. Forum on Specification & Design Language, 2005.
Basili, V., e H. Rombach. Goal Question Metric Paradim. Encyclopedia of Software
Engineering. New York: John Riley and Sons, 1994.
Berghout, E., e R. Solligen. The Goal Question Metric Method: A practical Guide for Quality
Improvement of Software Development. London: MCGraw Hill, 1999.
Calsalvara, A., C. A. F. Machado, S. S. Reinehr, e R. C. Burnett. Norma NBR ISO/IEC
12207. 2000.
Cantor, M. Rational Unified Process for System Engineering - Introduo RUPSE. The
Rational Edge, 2003.
Cantor, M. Rational Unified Process for Sytem Enginerring - Anlise e Design de
Requisitos. The Rational Edge, 2003.
Carro, L. and Wagner, F.R. Sistemas Computacionais Embarcados. Vol. 56. Academic
Press, 2002.
Chung, L., Nixon, B., Yu, E. and Mylopoulos,J. Non-Functional Requirements in Software
Engineering. Kluwer Academic Publishers, 1999.
Cysneiros, L. M. Requisitos No Funcionais: Da Elicitao ao Modelo Conceitual. PUC/RJ,
2001.
Drias, E. S. Replicao de Estudos Empricos em Engenharia de Software. Edio:
Matemticas e Computao Instituto de Cincias. ICMC - USP, 2001.
Farias, T. M.M. Aplicao de Padres ao Processo de Desenvolvimento de Software RUP.
Trabalho de Concluso de Curso - Universidade de Pernambuco, 2006.
Pgina 125
Feiler, P. H., e W. S. Humphrey. Software process development and enactment: concepts
anddefinitions. Second International Conference on the Continuous Software Process
Improvement (IEEE Computer Society), 1993: 28 - 40.
Fernandes, D. B. Anlise de Sistemas Orientada ao Sucesso: Por que os projetos atrasam?
Cincia Moderna, 2005.
Foudation, Eclipse. Eclipse Process Framework. http://www.eclipse.org/epf (acesso em 01
de 05 de 2008).
Gastaldo, D.L. e Midorikawa, E.T. Processo de Engenharia de Requisitos Aplicado a
Requisitos No-Funcionais de Desempenho Um Estudo de Caso. 2003.
Gilb, T. A Planning Language. Edio: ACM Press. International Conference on APL. 1989.
169-177.
Gladcheff, A. P., R. Sanches, e D. M. da Silva. Um Instrumento de Avaliao de Qualidade
de Software Educacional: como elabor-lo. Simpsio Brasileiro de Engenharia de Software
- VIII Workshop de Qualidade de Software, 2001.
Goethert, W., e M. Fischer. Deriving Enterprise-BasedMeasure Using the Balanced
Scorecard and Goal-Driven Measurement Techniques. Software Engineering Institute,
2003.
Gonalvez, J. E. L. As empresas so grandes colees de processos. Revista de
Administrao de Empresas, Jan/Mar 2000: 6-19.
Graaf, B. and Lormans, M. and Toetenel, H. Embedded Software Engeneering: The State of
the Practice. IEEE Software, 2003: 61-69.
Hauck, J. C. Modelagem e Aplicao de um Processo de Software em uma Microempresa.
Relatrio Tcnico, UNIVALI, So Jos, 2002.
Hauck, J. C. R. Desenvolvimento de um Sistema de Software para Gerncia de Manuais de
Processos de Software em Micro e Pequenas Empresas. Trabalho de Concluso de Curso,
2004.
Henzinger, T. e Sifakis, J. The Discipline Of Embedded Systems Design. IEEE Computer
Magazine 40 (2007): 32-40.
Hewett, R. e Seker, R. A Risk Assessment Model of Embedded Software Systems. IEEE
International Conference on Man and Cybernetics Systems 4 (2005): 3238- 3243.
Hofmann, H.F. e Lehner, F. Requirements Engineering as a Success Factor in Software
Projects. Vol. 18. 4 vols. 2001.
IEEE. SWEBOK - A Project of the Software Engineering Coordinating Committee. 2001.
Jacobson, I., G. Boock, e J. Rumbaugh. The Unified Software Development Process.
Addison - Wesley, 1999.
Kondo, M.N.S., Silva, J.R., Hira, A.Y. e Zuffo, M.K. Estudo de Requisitos do Software
Embarcado no Segmento da Telemedicina. Escola Politcnica da USP, 2006.
Pgina 126
Kopanas, V., V. Sylaidis, e I. Nakakis. GQM-based improvement of embedded, real-time
software development practices. Eighth IEEE International Workshop on incorporating
Computer Aided Software Engineering, 1997: 105-115.
Kruchten, P. Introduo ao RUP - Rational Unified Process. Rio de Janeiro: Cincia
Moderna, 2003.
Laboratory, Software Measurement. GQM Method. http://ivs.cs.uni-magderburg.de/sw-
eng/us/java/GQM/link2.shtml (acesso em 10 de 2007).
Larman, C. Utilizando UML e Padres. So Paulo: Bookman, 2004.
Lattemann, F. e Lehmann, E. A. Methodological Approach to the Requirement Specification
of Embedded Systems. Proceedings of the 1st International Conference on Formal
Engineering Methods (ICFEM97), 1997: 183.
Lee, E.A. Embedded Software. Vol. Vol 56. Academic Press, 2002.
Lee, E.A. Whats Ahead for Embedded Software? IEEE Computer, 2000: 19-26.
Lee, S., Ko, H., Jo, D., Jeong, J., Kim, K. Reusable SW Requirements Development
Process: Embedded SW Industry Experiences. Proceedings of the 2007 Australian Software
Engineering Conference (ASWEC07), 2007: 147-158.
Marwedel, P. Embedded System Design. Springer, 2003.
Mcchesney, R. T. Toward a Classification Scheme for Software Process Modelling
Aproaches. Information and Software Technology, 1995.
MCT, Ministrio da Cincia e Tecnologia. Qualidade e Produtividade no Setor de Software
Brasileiro. Comunicao Pessoal, 2002.
Nars, E., McDermid, J. e Bernat, G. Eliciting and Specifying with Use Cases for Embedded
Systems. Proceedings of the Seventh International Workshop on Object-Oriented Real-Time
Dependable Systems (WORDS 2002), 2002: 350-357.
Oliveira, M. S. Orientaes Metodolgicas para Monografia Latu Sensu.
OMG, Object Management Group. Software Process Engineering Metamodel Specification.
2005.
Pimentel, A. R. Uma Abordagem para Projeto de Software Orientado a Objetos Baseado na
Teoria de Axiomtico. Tese de Doutorado - Universidade Tecnolgica Federal do Paran,
Maio 2007.
Pradhan, D. K. Fault-Tolerant System Design. New Jersey: Prentice Hall, 1996.
Pressman, R. S. Engenharia de Software. 5 edio. Mc Graw Hill, 2006.
Puschnig, A. e Kolagari, R.T. Requirements Engineering in the Development of Innovative
Automotive Embedded Systems. Proceedings of the 12th International Requirements
Engineering Conference (RE04), 2004: 328-333.
Ramos, C. Avaliao de Sistemas Legados. Dissertao de Mestrado - Universidade
Catlica de Braslia - UCB, 2004.
Pgina 127
Riccobene, E., P. Scandurra, A. Rosti, e S. Bocchio. Designing a Unified Process for
Embedded Systems. Edio: IEEE Computer Society. Fourth International Workshop on
Model-Based Methodologies for Pervasive and Embedded Software MOMPES07, Maro
2007: 77 - 90.
Robertson, J. Eureka! Why Analysts Should Invent Requirements. IEEE Software, 2002:
20-22.
RUP. Site RUP. Wthreex. 2001.
http://www.wthreex.com/rup/process/workflow/requirem/co_req.htm (acesso em 02 de 02 de
2008).
Sangiovanni-Vincentelli, A., Carloni, L., De Bernardinis, F., and Sgroi, M. Benefits and
challenges for platform-based design. 2004.
Silva, C.A.L.B., Silva, M.A.L.R. e Costa, O.L.P. Implantao de Melhoria no Processo
Engenharia de Requisitos na Empresa Frmula Informtica. VI Simpsio Internacional de
Melhoria de Processos de Software (SIMPROS 04), 2004.
Softex. Melhoria de Processo de Software Brasileiro - Guia Geral Verso 1.2.
http://www.softex.br/mpsbr/ (in portuguese) (acesso em 15 de 11 de 2007).
Sommerville, I. e Kotonya, G. Requirements Engineering. Wiley, 1998.
Tennenhouse, D. Proactive Computing. 5 edio. Vol. 3. 2000.
Wangenheim, C. G. V., e G. Ruhe. Anlise de Custo Benefcio de Mensurao Baseada em
GQM Um Estudo de Caso Replicado. Procedigs of X Conferncia Internacional de
Qualidade de Software, 1999.
Weber, S. Um Estudo de Caso em uma Microempresa de Software para o Desenvolvimento
de um Modelo de Processo de Software. Universidade Federal de Florianpolis - UFSC,
2002.
Wolf, W. Computers as Components: Principles of Embedded Computing System Design.
McGraw-Hill, 2001.
Yamaura, T., Miyazaki, H. e Onoma, A.K. A New Defining Approach for Software
Requirement Specifications. Proceedings of the IEEE Workshop on Software Technologies
for Future Embedded Systems (WSTFES03), 2003: 13-16.
Pgina 128
APNDICE A RESPOSTA DO QUESTIONRIO DE AVALIAO DOS
PROCESSOS DE DESENVOLVIMENTO DE SISTEMAS EMBARCADOS

Questionrio de Avaliao dos Processos de
Desenvolvimento de Sistemas Embarcados

Equipe Responsvel pela Avaliao:
Cludia de Oliveira Melo
Daniele Erica Damke
Patrcia Freitas de Moraes

Equipe Avaliada:
Latenter Criptografia e Segurana Digital
Thiago de Castro Martins
Engenheiro de Desenvolvimento

1. Contextualizao - A empresa
Questes Respostas
1.1 Qual o domnio de negcio da empresa?
Desenvolvimento de hardware
criptogrfico
1.2 H quanto tempo a empresa atua neste domnio de negcio? 3 anos
1.3 Qual o nmero de funcionrios da empresa? 6
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]


2. Contextualizao - O software
Questes Respostas
2.1 O software embarcado desenvolvido pela empresa ...
(2) Um produto da empresa
(cliente interno).
2.2
O software embarcado desenvolvido pela empresa possui
integrao com outros sistemas?
(3) Possui integrao com
sistemas da prpria empresa e de
Pgina 129
outros fabricantes.
2.3
O software embarcado desenvolvido pela empresa deve
executar em diferentes plataformas?
(0) O software dedicado a uma
plataforma especfica da empresa.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

3. Contextualizao - A Equipe de Requisitos
Questes Respostas
3.1
No caso do software ser um componente de um produto da
prpria empresa ou de outro fabricante, existe uma equipe
separada para o levantamento dos requisitos do software?
(2) No existe separao entre as
equipes. Mas os levantamentos do
produto e do software so
realizados em momentos distintos
e por processos distintos.
3.2
Caso exista uma equipe separada para os requisitos do
software, qual o seu tamanho, em relao ao tamanho total
da equipe responsvel pelo projeto?
(0) No existe uma equipe
separada.
3.2
Caso exista uma equipe separada para os requisitos do
software, seus membros so dedicados a esta atividade?
(0) No existe uma equipe
separada.
3.4
Qual a formao acadmica dos membros da equipe de
requisitos (mesmo que no exista uma equipe separada para
tal)?
(3) Os membros da equipe
possuem formao em Cincia da
Computao (ou reas afins), e
possuem conhecimento superficial
da Engenharia de Requisitos.
3.5
Qual o nvel de conhecimento da equipe de requisitos no que
diz respeito ao negcio do software a ser desenvolvido?
(2) A equipe de requisitos tem
conhecimentos aprofundados do
negcio.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

4. O entendimento dos requisitos (funcionais e no-funcionais) obtido junto aos fornecedores de
requisitos?
Questes Respostas
4.1 Qual o nvel de entendimento dos requisitos?
(2) Os requisitos so recebidos j
levantados.
4.2
Qual o nvel de especializao da equipe de levantamento
de requisitos nesta atividade?
(3) Os requisitos so levantados
pelos arquitetos ou projetistas.
4.3 Qual o nvel de detalhe do levantamento de requisitos?
(3) As necessidades do cliente, as
restries do sistema e as
Pgina 130
integraes com outros
sistemas/dispositivos so
identificadas.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

5. As necessidades, expectativas e restries do cliente, tanto do produto quanto de suas interfaces, so
identificadas e registradas?
Questes Respostas
5.1 Qual o nvel de formalizao dos requisitos?
(3) Os requisitos so acordados e
registrados em documentos
estruturados (ex: atas de reunio).
5.2
Qual o nvel de formalizao do detalhamento do
levantamento/especificao de requisitos?
(3) As necessidades, expectativas
e restries do cliente so
levantadas e registradas em atas
de reunio.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

6. Os requisitos de software so aprovados?
Questes Respostas
6.1 Qual o nvel de formalizao dos requisitos?
(4) Os requisitos so acordados e
registrados formalmente (ex:
documento de especificao de
requisitos).
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

7. Um conjunto definido de requisitos do cliente especificado a partir das necessidades, expectativas e
restries identificadas?
Questes Respostas
7.1 Qual o nvel de refinamento dos requisitos funcionais?
(2) As caractersticas so
diretamente levantadas e refinadas
em nvel de requisitos.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

8. Um conjunto de requisitos funcionais e no-funcionais do produto e dos componentes do produto que
descrevem a soluo do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente?
Pgina 131
Questes Respostas
8.1 Qual o nvel de entendimento dos requisitos no-funcionais?
(2) Os requisitos no-funcionais
so identificados e so definidos a
partir dos requisitos funcionais
identificados.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

9. utilizado algum mtodo, modelo ou linguagem para especificao dos requisitos (funcionais e no-
funcionais)?
Questes Respostas
9.1
Qual o nvel de utilizao de mtodos/modelos no
levantamento/especificao dos requisitos (funcionais e no-
funcionais)?
(1) Os requisitos funcionais e no-
funcionais so levantados/
especificados sem utilizao de
tcnicas auxiliares.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

10. estabelecida a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho? Em caso
positivo, esta rastreabilidade mantida?
Questes Respostas
10.1 Qual o nvel de rastreabilidade dos requisitos?
(1) A rastreabilidade entre os
requisitos de trabalho elaborada.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

11. Interfaces internas e externas do produto e de cada componente do produto so definidas?
Questes Respostas
11.1 Qual o nvel de identificao de interfaces?
(3) Os atores do sistema so
definidos e registrados em
documentos estruturados (Ex. Ata
de reunio).
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

12. Os requisitos so analisados para assegurar que sejam necessrios, corretos, testveis e
suficientes para balancear as necessidades dos interessados com as restries existentes?
Questes Respostas
Pgina 132
12.1 Qual o nvel de anlise de erros nos requisitos?
(1) Os requisitos so testados pela
equipe de desenvolvimento e no
so validados pelo cliente.
12.2 Qual o nvel de corretude dos testes de requisitos?
[Favor informar a opo que mais
se aplica sua realidade]
Dvidas Acredito que haja algum erro nas alternativas de resposta da questo 13.2

13. considerada e avaliada a dependncia entre os requisitos?
Questes Respostas
13.1 Qual o nvel de anlise da dependncia entre os requisitos?
(1) A dependncia entre os
requisitos funcionais avaliada.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo]

14. considerada e validada a viabilidade dos itens de software atenderem seus requisitos alocados?
Questes Respostas
14.1 Qual o nvel de anlise da viabilidade dos requisitos?
(1) A viabilidade dos requisitos
funcionais avaliada.
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

15. considerada e avaliada a viabilidade da operao e da manuteno do sistema?
Questes Respostas
15.1
Qual o nvel de anlise da viabilidade de operao e
manuteno dos sistemas?
(1) A viabilidade de operao do
sistema avaliada.
Dvidas
Por "manuteno" deve-se entender a manuteno do produto final (hardware + software) ou a
atualizao do software embarcado?

16. So feitas revises nos planos e produtos de trabalho do projeto visando identificar e corrigir
inconsistncias em relao aos requisitos?
Questes Respostas
16.1
Qual o nvel de anlise de revises e correes dos produtos
de trabalho?
(1) So realizadas revises e
correes dos planos e produtos
de trabalho durante o processo de
desenvolvimento do sistema.
Pgina 133
Dvidas [Favor digitar aqui suas dvidas e comentrios em relao a questo, caso existam]

17. As mudanas nos requisitos so gerenciadas ao longo do tempo?
Questes Respostas
17.1
Qual o nvel de anlise de manutenes nos requisitos
funcionais e no-funcionais?
(2) Os requisitos funcionais e no-
funcionais so mantidos ao longo
do tempo.
Dvidas
As manutenes mais freqentes no meu negcio consistem na gerao de verses
especializadas do produto. Neste caso, evidentemente os requisitos so passveis de sofrerem
alteraes. No entanto, estes novos requisitos NO substituem os originais. Em termos de um
sistema de controle de revises, isso seria o equivalente a um "branch".

Comentrios
[Favor digitar aqui seus comentrios, crticas e sugestes em relao ao questionrio]

Pgina 134

APNDICE B LISTA DE VERIFICAO I
PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
EMBARCADOS
Logotipo da Empresa
Lista de Verificao do
Documento de Viso
<Sigla do Projeto> - <Nome do Projeto>
Lista de Verificao do Documento de Viso: <Nome do
Documento>
Verso <X> Data: 18/3/2008
1. IDENTIFICAO
[Descrever informaes gerais sobre a reviso tcnica sendo realizada:
Projeto: Sigla e nome do projeto ao qual o(s) produto(s) sendo revisados pertencem;
Nome do Revisor: Nome da pessoa responsvel pela reviso;
Data da Reviso: Data da realizao da reviso;
Tempo de durao da reviso: Tempo gasto, em horas e minutos, com a atividade de reviso
tcnica do produto.]

Projeto <Sigla do Projeto> - <Nome do Projeto>
Nome do
Revisor

Data da Reviso <dd/MM/AAAA>
Tempo de Durao da
Reviso
<X> horas e <X>
minutos
2. OBJETIVO
[Descrever o objetivo da reviso e listar os produtos a serem revisados.]

Propsito da Reviso
Revisar o documento Viso identificando desvios relativos aos requisitos de alto nvel que
representam o escopo do sistema e a rastreabilidade entre esses requisitos.
Produtos a serem revisados Verso
<Viso> <X>

Pgina 135

3. ITENS DE VERIFICAO
[Listar os critrios para reviso dos produtos, enfatizando:
o Fatores crticos para a qualidade do produto(s);
o Principais defeitos historicamente identificados no(s) produto(s);
o Fatores do(s) produto(s) que so base para realizao de outras atividades.

Criar uma seo e tabela de reviso para cada produto a ser revisado.]
3.1. VISO - <VERSO DO PRODUTO>
[A lista de itens de verificao descreve:
No: Nmero seqencial do item de reviso;
Descrio do Item: Descrio do que deve ser revisado;
Situao: situao do produto revisado em relao ao item a ser revisado:
o OK: Produto(s) em conformidade com o item.
o NOK: Produto(s) no conforme com a descrio do item. Ou seja, produto com defeito em relao ao item;
o NA: Item no aplicvel para o produto em reviso.
Observaes e Defeitos:
o Quando situao OK: Campo deve permanecer em branco;
o Quando situao NOK: Campo deve descrever o defeito encontrado, relatando inclusive a localizao do defeito no produto (nmero de
pgina, seo, etc);
o Quando situao NA: Campo deve descrever o motivo pelo qual o item de reviso no se aplica ao produto sendo de revisado.
Gravidade: Gravidade dos defeitos encontrados;
o Alta: Defeitos que inviabilizem a compreenso do produto ou que caracterizam o produto como no aderente aos seus objetivos, como:
Produto no atende aos requisitos, idias impossveis de serem realizadas, produto que cause impacto em outro produto j homologado,
ausncia de informaes importantes no documento, etc.
o Mdia: Defeitos que dificultam a compreenso do produto, porm este permanece adequado ao seu objetivo, como: erros de ortografia e
gramtica, poluio visual, mau encadeamento de idias, etc.
o Baixa: Defeitos relevantes que no afetam a compreenso ou adequao do produto aos seus objetivos, como: Detalhes de apresentao,
cores, tamanhos de fontes, etc.



Pgina 136


Situao
No Descrio do Item
OK NOK NA
Observaes e
Defeitos
Gravidade
Geral
1 O documento foi elaborado com base na ltima verso do modelo disponvel?
2 As informaes do documento (nome, verso, autor, sigla e nome do projeto, etc) foram devidamente
registradas nas propriedades deste?

3 A verso do documento foi incrementada e a descrio da elaborao ou alterao foi registrada no
histrico de revises do documento?

4 A capa do documento foi atualizada com o nome e verso do documento, sigla e nome do projeto e
marca do cliente?

5 O cabealho do documento foi atualizado com o nome do documento e marca do cliente?
6 O rodap do documento foi atualizado com a sigla e o nome do projeto?
7 O sumrio do documento foi atualizado?
Requisitos
8 O Problema est identificado e registrado de maneira clara?
9 Os usurios do sistema esto identificados?
10 As necessidades dos interessados esto identificadas? As colunas esto preenchidas corretamente? O
nvel de prioridade est definido para cada necessidade?

11 As sentenas que nomeiam as Caractersticas esto descritas de acordo com o padro indicado no
documento Viso e no Processo de Gerenciamento e Engenharia de Requisitos?

12 A descrio de cada Caracterstica est clara? Basicamente, deve-se descrever como o recurso ser
percebido pelo usurio externamente, em alto nvel. O pblico alvo deste texto so pessoas com
formaes heterogneas e o objetivo que todas entendam o sistema.

13 Existem restries impostas? Caso afirmativo, o entendimento est claro o suficiente?
14 Os requisitos de documentao esto registrados?
(1) Gravidade: Alta, Mdia, Baixa.
[Descrever todos defeitos de ortografia e gramtica encontrados em qualquer seo do produto. Os defeitos de ortografia e gramtica no so classificados
quanto gravidade, pois todos devem obrigatoriamente ser corrigidos.
N
o
: Nmero seqencial do defeito
Localizao do Defeito: Nmero de pgina, pargrafo ou seo do produto na qual localizado o defeito.
Descrio do Defeito: Descrio do defeito de ortografia e gramtica, sugere-se copiar o trecho de texto e destacar o defeito com cor de fonte
diferente ou negrito.
]


Pgina 137

Defeitos de Ortografia e Gramtica
No Localizao do Defeito Descrio do Defeito




[Identificar sugestes de melhoria no produto revisado. No h necessidade de implementao de todas as sugestes, ficando a cargo do Autor do produto
decidir quanto sua implementao.
N
o
: Nmero seqencial da Sugesto
Descrio da Sugesto: Descrio da sugesto de melhoria no produto revisado
]

Sugestes de Melhoria
No Descrio da Sugesto






Pgina 138

APNDICE C LISTA DE VERIFICAO II

PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
EMBARCADOS
Logotipo da Empresa
Lista de Verificao de Especificao
de Caso de Uso
<Sigla do Projeto> - <Nome do Projeto>
Lista de Verificao de Especificao de Caso de Uso:
<Nome do Documento>
Verso <X> Data: 18/3/2008
1. IDENTIFICAO
[Descrever informaes gerais sobre a reviso tcnica sendo realizada:
Projeto: Sigla e nome do projeto ao qual o(s) produto(s) sendo revisados pertencem;
Nome do Revisor: Nome da pessoa responsvel pela reviso;
Data da Reviso: Data da realizao da reviso;
Tempo de durao da reviso: Tempo gasto, em horas e minutos, com a atividade de reviso
tcnica do produto.]

Projeto <Sigla do Projeto> - <Nome do Projeto>
Nome do
Revisor

Data da Reviso <dd/MM/AAAA>
Tempo de Durao da
Reviso
<X> horas e <X>
minutos
2. OBJETIVO
[Descrever o objetivo da reviso e listar os produtos a serem revisados.]

Propsito da Reviso
Revisar o Caso de Uso identificando desvios relativos ao detalhamento de requisitos funcionais e
rastreabilidade.
Produtos a serem revisados Verso
<Nome da Especificao> <X>

Pgina 139

3. ITENS DE VERIFICAO
[Listar os critrios para reviso dos produtos, enfatizando:
o Fatores crticos para a qualidade do produto(s);
o Principais defeitos historicamente identificados no(s) produto(s);
o Fatores do(s) produto(s) que so base para realizao de outras atividades.

Criar uma seo e tabela de reviso para cada produto a ser revisado.]
3.1. CASO DE USO <NOME DO CASO DE USO> - <VERSO DO PRODUTO>
[A lista de itens de verificao descreve:
No: Nmero seqencial do item de reviso;
Descrio do Item: Descrio do que deve ser revisado;
Situao: situao do produto revisado em relao ao item a ser revisado:
o OK: Produto(s) em conformidade com o item.
o NOK: Produto(s) no conforme com a descrio do item. Ou seja, produto com defeito em relao ao item;
o NA: Item no aplicvel para o produto em reviso.
Observaes e Defeitos:
o Quando situao OK: Campo deve permanecer em branco;
o Quando situao NOK: Campo deve descrever o defeito encontrado, relatando inclusive a localizao do defeito no produto (nmero de
pgina, seo, etc);
o Quando situao NA: Campo deve descrever o motivo pelo qual o item de reviso no se aplica ao produto sendo de revisado.
Gravidade: Gravidade dos defeitos encontrados;
o Alta: Defeitos que inviabilizem a compreenso do produto ou que caracterizam o produto como no aderente aos seus objetivos, como:
Produto no atende aos requisitos, idias impossveis de serem realizadas, produto que cause impacto em outro produto j homologado,
ausncia de informaes importantes no documento, etc.
o Mdia: Defeitos que dificultam a compreenso do produto, porm este permanece adequado ao seu objetivo, como: erros de ortografia e
gramtica, poluio visual, mau encadeamento de idias, etc.
o Baixa: Defeitos relevantes que no afetam a compreenso ou adequao do produto aos seus objetivos, como: Detalhes de apresentao,
cores, tamanhos de fontes, etc.

Situao
No Descrio do Item
OK NOK NA
Observaes e
Defeitos
Gravidade
Geral

Pgina 140

1 O documento foi elaborado com base na ltima verso do modelo disponvel?
2 As informaes do documento (nome, verso, autor, sigla e nome do projeto, etc) foram devidamente
registradas nas propriedades deste?

3 A verso do documento foi incrementada e a descrio da elaborao ou alterao foi registrada no
histrico de revises do documento?

4 A capa do documento foi atualizada com o nome e verso do documento, sigla e nome do projeto e
marca do cliente?

5 O cabealho do documento foi atualizado com o nome do documento e marca do cliente?
6 O rodap do documento foi atualizado com a sigla e o nome do projeto?
Requisitos
7 A descrio do DEC est clara e completa? Relata em poucas palavras o objetivo de negcio do
Documento de Especificao de Caso de Uso e cita suas funcionalidades? Voc entendeu o objetivo do
DEC sem precisar ler os seus fluxos de eventos?

8 Verifique se o Caso de Uso se encontra na lista ou Modelo de Casos de Uso existente no DRS.
9 Procure termos vagos e pea esclarecimento (algum, s vezes, usualmente, freqentemente).
10 Todos os atores que interagem com o DEC foram relacionados?
11 Verificar, para cada um dos passos do DEC, onde pode ocorrer uma validao de Regra de Negcio.
Se ocorrer isso, incluir no final do passo a indicao para a Regra que est no documento de Regras de
Negcio.

12 Todos os atributos de entrada e de sada e regras relacionadas esto especificados?
Exemplos:
1. Campos que devero ser apresentados para o usurio.
2. Campos que devero ser informados pelo usurio.
3. Regras de negcio que estabeleam atributos de entrada ou sada.

13 A obrigatoriedade dos atributos de entrada est especificada?
14 Os atributos que sero selecionados a partir de uma lista de valores esto evidenciados? (Ex: O Ator
seleciona a UF a partir de uma lista)

15 Os valores das listas ou domnios especficos do sistema esto documentados no DEC?
16 Conferir se o texto das mensagens referenciadas no DEC est apropriado para o negcio. Evitar
mensagens longas demais ou mensagens curtas que no dizem nada.

17 Se o DEC possui integraes, os requisitos destas (parmetros, regras) esto documentados?
Padres e Formas
18 O nome do DEC deve estar no infinitivo do verbo Rejeitar..., Receber....
19 Todos os documentos de referncias foram listados no item referncia. (Outros Casos de Uso,
Glossrio, Viso, etc.)

20 Se algum dos itens do template do Documento de Especificao de Casos de Uso no tiver informao,
esses itens no podem ser removidos. Informar para o item referente a seguinte frase: No se aplica.


Pgina 141

(1) Gravidade: Alta, Mdia, Baixa.

[Descrever todos defeitos de ortografia e gramtica encontrados em qualquer seo do produto. Os defeitos de ortografia e gramtica no so classificados
quanto gravidade, pois todos devem obrigatoriamente ser corrigidos.
N
o
: Nmero seqencial do defeito
Localizao do Defeito: Nmero de pgina, pargrafo ou seo do produto na qual localizado o defeito.
Descrio do Defeito: Descrio do defeito de ortografia e gramtica, sugere-se copiar o trecho de texto e destacar o defeito com cor de fonte
diferente ou negrito.
]

Defeitos de Ortografia e Gramtica
No Localizao do Defeito Descrio do Defeito




[Identificar sugestes de melhoria no produto revisado. No h necessidade de implementao de todas as sugestes, ficando a cargo do Autor do produto
decidir quanto sua implementao.
N
o
: Nmero seqencial da Sugesto
Descrio da Sugesto: Descrio da sugesto de melhoria no produto revisado
]

Sugestes de Melhoria
No Descrio da Sugesto





Pgina 142

APNDICE D LISTA DE VERIFICAO III
PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
EMBARCADOS
Logotipo da Empresa
Lista de Verificao de Especificao
Suplementar
<Sigla do Projeto> - <Nome do Projeto>
Lista de Verificao de Especificao Suplementar:
<Nome do Documento>
Verso <X> Data: 18/3/2008
1. IDENTIFICAO
[Descrever informaes gerais sobre a reviso tcnica sendo realizada:
Projeto: Sigla e nome do projeto ao qual o(s) produto(s) sendo revisados pertencem;
Nome do Revisor: Nome da pessoa responsvel pela reviso;
Data da Reviso: Data da realizao da reviso;
Tempo de durao da reviso: Tempo gasto, em horas e minutos, com a atividade de reviso
tcnica do produto.]

Projeto <Sigla do Projeto> - <Nome do Projeto>
Nome do
Revisor

Data da Reviso <dd/MM/AAAA>
Tempo de Durao da
Reviso
<X> horas e <X>
minutos
2. OBJETIVO
[Descrever o objetivo da reviso e listar os produtos a serem revisados.]

Propsito da Reviso
Revisar a Especificao de Requisitos no Funcionais identificando desvios relativos ao
detalhamento do requisito e rastreabilidade.
Produtos a serem revisados Verso
<Nome da Especificao> <X>

Pgina 143

3. ITENS DE VERIFICAO
[Listar os critrios para reviso dos produtos, enfatizando:
o Fatores crticos para a qualidade do produto(s);
o Principais defeitos historicamente identificados no(s) produto(s);
o Fatores do(s) produto(s) que so base para realizao de outras atividades.

Criar uma seo e tabela de reviso para cada produto a ser revisado.]
3.1. REQUISITO NO FUNCIONAL <NOME DO REQUISITO NO FUNCIONAL> - <VERSO DO PRODUTO>
[A lista de itens de verificao descreve:
No: Nmero seqencial do item de reviso;
Descrio do Item: Descrio do que deve ser revisado;
Situao: situao do produto revisado em relao ao item a ser revisado:
o OK: Produto(s) em conformidade com o item.
o NOK: Produto(s) no conforme com a descrio do item. Ou seja, produto com defeito em relao ao item;
o NA: Item no aplicvel para o produto em reviso.
Observaes e Defeitos:
o Quando situao OK: Campo deve permanecer em branco;
o Quando situao NOK: Campo deve descrever o defeito encontrado, relatando inclusive a localizao do defeito no produto (nmero de
pgina, seo, etc);
o Quando situao NA: Campo deve descrever o motivo pelo qual o item de reviso no se aplica ao produto sendo de revisado.
Gravidade: Gravidade dos defeitos encontrados;
o Alta: Defeitos que inviabilizem a compreenso do produto ou que caracterizam o produto como no aderente aos seus objetivos, como:
Produto no atende aos requisitos, idias impossveis de serem realizadas, produto que cause impacto em outro produto j homologado,
ausncia de informaes importantes no documento, etc.
o Mdia: Defeitos que dificultam a compreenso do produto, porm este permanece adequado ao seu objetivo, como: erros de ortografia e
gramtica, poluio visual, mau encadeamento de idias, etc.
o Baixa: Defeitos relevantes que no afetam a compreenso ou adequao do produto aos seus objetivos, como: Detalhes de apresentao,
cores, tamanhos de fontes, etc.

Situao
No Descrio do Item
OK NOK NA
Observaes e
Defeitos
Gravidade
Geral

Pgina 144

1 O documento foi elaborado com base na ltima verso do modelo disponvel?
2 As informaes do documento (nome, verso, autor, sigla e nome do projeto, etc) foram
devidamente registradas nas propriedades deste?

3 A verso do documento foi incrementada e a descrio da elaborao ou alterao foi registrada no
histrico de revises do documento?

4 A capa do documento foi atualizada com o nome e verso do documento, sigla e nome do projeto e
marca do cliente?

5 O cabealho do documento foi atualizado com o nome do documento e marca do cliente?
6 O rodap do documento foi atualizado com a sigla e o nome do projeto?
Requisitos
7 Existem requisitos de Usabilidade? Esto claramente especificados?
8 Existem requisitos de Confiabilidade? Esto claramente especificados?
9 Existem requisitos de Desempenho? Esto claramente especificados?
10 Existem requisitos de Suportabilidade? Esto claramente especificados?
11 Existem Restries de Projeto? Esto claramente especificados?
12 Existem outros Requisitos de Produto? Esto claramente especificados?
13 Os requisitos suplementares foram detalhados por meio do preenchimento da tabela da Planguage?
(1) Gravidade: Alta, Mdia, Baixa.
[Descrever todos defeitos de ortografia e gramtica encontrados em qualquer seo do produto. Os defeitos de ortografia e gramtica no so classificados
quanto gravidade, pois todos devem obrigatoriamente ser corrigidos.
N
o
: Nmero seqencial do defeito
Localizao do Defeito: Nmero de pgina, pargrafo ou seo do produto na qual localizado o defeito.
Descrio do Defeito: Descrio do defeito de ortografia e gramtica, sugere-se copiar o trecho de texto e destacar o defeito com cor de fonte
diferente ou negrito.
]

Defeitos de Ortografia e Gramtica
No Localizao do Defeito Descrio do Defeito




[Identificar sugestes de melhoria no produto revisado. No h necessidade de implementao de todas as sugestes, ficando a cargo do Autor do produto
decidir quanto sua implementao.
N
o
: Nmero seqencial da Sugesto

Pgina 145

Descrio da Sugesto: Descrio da sugesto de melhoria no produto revisado
]

Sugestes de Melhoria
No Descrio da Sugesto






Pgina 146
APNDICE E LISTA DE PRIORIZAO

PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
EMBARCADOS
Logotipo da Empresa
Lista de Priorizao
<Sigla do Projeto> - <Nome do Projeto>
Lista de Priorizao: <Nome do Documento> Verso <X> Data: 18/3/2008


Lista de Priorizao: <Nome do Documento>


Histrico da Reviso
Data Verso Descrio Autor
<dd/mmm/aa> <x.x> <detalhes> <nome>




ndice Analtico
1. Introduo 147
1.1. Priorizao das Necessidades do Cliente 147

Pgina 147
Lista de Priorizao: <Nome do Documento>

1. INTRODUO
[A introduo da lista de priorizao fornece uma viso da priorizao que deve ser seguida no
desenvolvimento nas necessudades do sistema. Ela deve incluir as necessidades do cliente e o seu
respectivo nvel de prioriza].
1.1. PRIORIZAO DAS NECESSIDADES DO CLIENTE
[Esta subseo fornece a priorizao de cada uma das necessidades do cliente. Para cada
necessidade identificar sua priorizao na tabela a seguir]
Necessidade Prioridade
[Necessidade 1]. [Nvel de Prioridade da
Necessidade Listada, pode
ser:

1: Prioridade Baixa
2: Prioridade Mdia
3:Prioridade Alta
[Necessidade 2]. [Nvel de Prioridade da
Necessidade Listada, pode
ser:

1: Prioridade Baixa
2: Prioridade Mdia
3:Prioridade Alta
[Necessidade 3]. [Nvel de Prioridade da
Necessidade Listada, pode
ser:

1: Prioridade Baixa
2: Prioridade Mdia
3:Prioridade Alta


Pgina 148
APNDICE F DOCUMENTO DE REFERNCIA CRUZADA
PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
EMBARCADOS
Logotipo da Empresa
Referncia Cruzada
<Sigla do Projeto> - <Nome do Projeto>
Lista de Priorizao: <Nome do Documento> Verso <X> Data: 18/3/2008

Documento de Referncia Cruzada: <Nome do
Documento>

Histrico da Reviso
Data Verso Descrio Autor
<dd/mmm/aa> <x.x> <detalhes> <nome>




ndice Analtico
1. Introduo Erro! Indicador no definido.
2. Referncia Cruzada Erro! Indicador no definido.
2.1. Necessidades X Caractersticas Erro! Indicador no definido.
2.2. Caractersticas X Requisitos Funcionais Erro! Indicador no definido.
2.3. Requisitos Funcionais X Requisitos Funcionais Erro! Indicador no definido.
2.4. Requisitos Funcionais X Requisitos No Funcionais Erro! Indicador no definido.
2.5. Requisitos No - Funcionais X Requisitos No - Funcionais Erro! Indicador no definido.
2.6. Outros X Outros Erro! Indicador no definido.
3. Glossrio Erro! Indicador no definido.


Pgina 149
Documento de Referncia Cruzada: <Nome do
Documento>

1. INTRODUO
[Descrever os objetivos do documento e outras informaes relevantes para o entendimento do seu
contedo.]
1.1. REFERNCIA CRUZADA
[Descrever tantas referncias cruzadas quantas forem necessrias. As referncias cruzadas
sugeridas so de Necessidades X Caractersticas, Caractersticas X Requisitos Funcionais,
Requisitos Funcionais X Requisitos Funcionais, Requisitos Funcionais X Requisitos No-Funcionais e
Requisitos No Funcionais X Requisitos No - Funcionais].
1.1.1. NECESSIDADES X CARACTERSTICAS
Caractersticas Os relacionamentos permitidos
so:
D Dependncia
C Colaborao
P - Prejudica
C
R
T
0
0
1

C
R
T
0
0
2

.
.
.

C
R
T
N
N
N

Necessidades
NCD001
NCD002
...
NCDNNN

1.1.2. CARACTERSTICAS X REQUISITOS FUNCIONAIS
Requisitos Funcionais Os relacionamentos permitidos
so:
D Dependncia
C Colaborao
P - Prejudica
R
F
C
0
0
1

R
F
C
0
0
2

.
.
.

R
F
C
N
N
N

Caractersticas
CRT001
CRT002
...
CRTNNN

1.1.3. REQUISITOS FUNCIONAIS X REQUISITOS FUNCIONAIS
Os relacionamentos permitidos
so:
Requisitos Funcionais

Pgina 150
so:
D Dependncia
C Colaborao
P - Prejudica
R
F
C
0
0
1

R
F
C
0
0
2

.
.
.

R
F
C
N
N
N

Requisitos Funcionais
RFC001
RFC002
...
RFCNNN

1.1.4. REQUISITOS FUNCIONAIS X REQUISITOS NO FUNCIONAIS
Requisitos No-
Funcionais
Os relacionamentos permitidos
so:
D Dependncia
C Colaborao
P - Prejudica
R
N
F
0
0
1

R
N
F
0
0
2

.
.
.

R
N
F
N
N
N

Requisitos Funcionais
RFC001
RFC002
...
RFCNNN

1.1.5. REQUISITOS NO - FUNCIONAIS X REQUISITOS NO - FUNCIONAIS
Requisitos No-
Funcionais
Os relacionamentos permitidos
so:
D Dependncia
C Colaborao
P - Prejudica
R
N
F
0
0
1

R
N
F
0
0
2

.
.
.

R
N
F
N
N
N

Requisitos No-Funcionais
RNF001
RNF002
...
RNFNNN

1.1.6. OUTROS X OUTROS
Outros Os relacionamentos permitidos
so:
D Dependncia
C Colaborao
P - Prejudica
O
T
R
0
0
1

O
T
R
0
0
2

.
.
.

O
T
R
N
N
N

Outros

Pgina 151
OTR001
OTR002
...
OTRNNN

1.2. GLOSSRIO
[Descrever os termos e siglas usados no documento.]

Pgina 152
APNDICE G DOCUMENTO DE ESPECIFICAO SUPLEMENTAR

PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
EMBARCADOS
Logotipo da Empresa
Documento de Especificao
Suplementar
<Sigla do Projeto> - <Nome do Projeto>
Documento de Especificao Suplementar: <Nome do
Documento>
Verso <X> Data: 18/3/2008

Documento de Especificao Suplementar: <Nome
do Documento>

Histrico da Reviso
Data Verso Descrio Autor
<dd/mmm/aa> <x.x> <detalhes> <nome>




ndice Analtico

1. Introduo 154
1.1. Definies, Acrnimos e Abreviaes 154
1.2. Referncias 154
2. Funcionalidade 154
2.1. <Requisito Funcional Um> 154
3. Usabilidade 154
3.1. <Requisito de Usabilidade Um> 154
4. Confiabilidade 155
4.1. <Requisito de Confiabilidade Um> 155
5. Desempenho 155
5.1. <Requisito de Desempenho Um> 155
6. Suportabilidade 155

Pgina 153
6.1. <Requisito de Suportabilidade Um> 155
7. Restries de Projeto 155
7.1. <Restrio de Projeto Um> 156
8. Outros Requisitos do produto 156
8.1. Padres Aplicveis 156
8.2. Requisitos do Sistema 156
8.3. Requisitos Ambientais 156
9. Componentes Comprados 156
10. Interfaces 156
10.1. Interfaces de Usurio 156
10.2. Interfaces de Hardware 156
10.3. Interfaces de Software 156
10.4. Interfaces de Comunicaes 157
11. Requisitos de Licenciamento 157

Pgina 154
Documento de Especificao Suplementar: <Nome
do Documento>
1. INTRODUO
[A introduo da Especificao Suplementar deve fornecer uma viso geral de todo o documento. Ela
deve incluir a finalidade, o escopo, as definies, os acrnimos, as abreviaes, as referncias e a
viso geral desta Especificao Suplementar.]
A Especificao Suplementar captura os requisitos de sistema que no so capturados
imediatamente nos Casos de Uso do Modelo de Casos de Uso. Entre os requisitos esto includos:
Requisitos legais e reguladores, incluindo padres de aplicativo.
Atributos de qualidade do Sistema a ser criado, incluindo requisitos de usabilidade,
confiabilidade, desempenho e suportabilidade.
Outros requisitos, como Sistemas operacionais e ambientes, requisitos de compatibilidade e
restries de design.
]
1.1. DEFINIES, ACRNIMOS E ABREVIAES
[Esta subseo deve fornecer as definies de todos os termos, acrnimos e abreviaes
necessrias adequada interpretao da Especificao Suplementar. Essas informaes podem ser
fornecidas mediante referncia ao Glossrio do projeto.]
1.2. REFERNCIAS
[Esta subseo deve fornecer uma lista completa de todos os documentos mencionados em qualquer
outra parte da Especificao Suplementar. Cada documento deve ser identificado por ttulo, nmero
do relatrio (se aplicvel), data e organizao de publicao. Especifique as fontes a partir das quais
as referncias podem ser obtidas. Essas informaes podem ser fornecidas por um anexo ou outro
documento.]
1.3. FUNCIONALIDADE
[Esta seo descreve os requisitos funcionais do sistema que so expressos no estilo de linguagem
natural. Normalmente, ela organizada por recurso, mas mtodos de organizao alternativos como,
por exemplo, organizao por usurio ou organizao por subsistema, tambm podem ser
apropriados. Entre os requisitos funcionais podem estar includos conjuntos de recursos, capacidades
e segurana].
1.3.1. <REQUISITO FUNCIONAL UM>
[A descrio do requisito deve ser feita aqui.]
1.4. USABILIDADE
[Esta seo deve incluir todos os requisitos que afetam a usabilidade. Estes so alguns exemplos]:
especifique o tempo de treinamento necessrio para que usurios normais e usurios com
conhecimentos avanados se tornem produtivos em operaes especficas
especifique perodos de tempo mensurveis para tarefas tpicas ou
especifique requisitos que estejam em conformidade com os padres comuns de usabilidade.
]
1.4.1. <REQUISITO DE USABILIDADE UM>
[A descrio do requisito.]

Pgina 155
1.5. CONFIABILIDADE
[Os requisitos de confiabilidade do sistema devem ser especificados aqui. Abaixo, algumas
sugestes]:
Disponibilidade - especifique a porcentagem de tempo disponvel (xx.xx%), as horas de uso,
o acesso manuteno, as operaes de modo degradado etc.
Tempo Mdio entre Falhas (MTBF) - normalmente especificado em horas, mas tambm
poder ser especificado em termos de dias, meses ou anos.
Tempo Mdio para Reparo (MTTR) - quanto tempo o sistema poder ficar sem funcionar
aps uma falha?
Exatido - especifique a preciso (resoluo) e exatido (atravs de algum padro conhecido)
necessrias na sada dos sistemas.
Taxa mxima de erros ou defeitos - geralmente expressa em termos de erros/KLOC
(thousands of lines of code, milhares de linhas de cdigo) ou de erros/ponto de funo.
Taxa de erros ou defeitos - categorizados em termos de erros pouco importantes, importantes
e crticos: o(s) requisito(s) deve definir o que se entende por um erro "crtico" (ex: perda total
de dados ou total incapacidade de usar determinadas partes da funcionalidade do sistema).
]
1.5.1. <REQUISITO DE CONFIABILIDADE UM>
[A descrio do requisito.]
1.6. DESEMPENHO
[As caractersticas de desempenho do sistema devem ser descritas nesta seo. Inclua tempos de
resposta especficos. Quando aplicvel, faa referncia, por nome, aos Casos de Uso relacionados].
Tempo de resposta de uma transao (mdio, mximo)
Taxa de transferncia (ex: transaes por segundo)
Capacidade (ex: o nmero de clientes ou de transaes que podem ser acomodados pelo
sistema)
Modos de degradao (o modo aceitvel de operao quando o sistema tiver sido degradado
de alguma maneira)
Utilizao de recursos: memria, disco, comunicaes etc.]
1.6.1. <REQUISITO DE DESEMPENHO UM>
[A descrio do requisito.]
1.7. SUPORTABILIDADE
[Esta seo indica todos os requisitos que aprimoraro a suportabilidade ou manutenibilidade do
sistema que est sendo criado, incluindo padres de codificao, convenes de nomeao,
bibliotecas de classes, acesso manuteno e utilitrios de manuteno.]
1.7.1. <REQUISITO DE SUPORTABILIDADE UM>
[A descrio do requisito.]
1.8. RESTRIES DE PROJETO
[Esta seo deve indicar todas as restries de design referentes ao sistema que est sendo criado.
As restries de design representam decises de design que foram impostas e devem ser
obedecidas. Entre os exemplos desse tipo de restrio esto linguagens de software, requisitos de
processo de software, uso prescrito de ferramentas de desenvolvimento, restries de design e de
arquitetura, componentes comprados, bibliotecas de classes etc.]

Pgina 156
1.8.1. <RESTRIO DE PROJETO UM>
[A descrio do requisito deve ser feita aqui.]
1.9. OUTROS REQUISITOS DO PRODUTO
[Em um nvel superior, liste padres aplicveis, requisitos de hardware ou de plataforma, requisitos de
desempenho e requisitos ambientais.]
1.9.1. PADRES APLICVEIS
[Liste todos os padres com os quais o produto dever estar em conformidade. Entre eles, podero
estar includos padres legais e reguladores, padres de comunicaes (TCP/IP, ISDN), padres de
conformidade com plataformas (Windows, UNIX etc) e padres de qualidade e de segurana (ISO,
CMMI).]
1.9.2. REQUISITOS DO SISTEMA
[Defina todos os requisitos do sistema necessrios para suportar o aplicativo. Entre eles, podero
estar includos os sistemas operacionais de host e as plataformas de rede suportadas, configuraes,
memria, perifricos e software fornecido.]
1.9.3. REQUISITOS AMBIENTAIS
[Descreva os requisitos ambientais quando necessrio. Para sistemas baseados em hardware, as
questes ambientais podero incluir temperatura, choques, umidade, radiao etc. Para aplicativos
de software, os fatores ambientais podem incluir condies de uso, ambiente do usurio,
disponibilidade de recursos, problemas de manuteno, e recuperao e tratamento de erros.]
2. COMPONENTES COMPRADOS
[Esta seo descreve todos os documentos comprados a serem usados no sistema, quaisquer
restries de utilizao ou de licenciamento aplicveis e quaisquer padres associados de
compatibilidade/interoperabilidade ou de interface.]
3. INTERFACES
[Esta seo define as interfaces que devem ser suportadas pelo aplicativo. Ela deve conter
especificidades, protocolos, portas e endereos lgicos adequados, entre outros, para que o software
possa ser desenvolvido e verificado em relao aos requisitos de interface.]
3.1. INTERFACES DE USURIO
[Descreva as interfaces de usurio que devero ser implementadas pelo software.]
3.2. INTERFACES DE HARDWARE
[Esta seo define todas as interfaces de hardware que devem ser suportadas pelo software,
incluindo a estrutura lgica, os endereos fsicos, o comportamento esperado, etc.]
3.3. INTERFACES DE SOFTWARE
[Esta seo descreve as interfaces de software com outros componentes do sistema de software.
Podero ser componentes comprados, componentes reutilizados de outro aplicativo ou componentes
que esto sendo desenvolvidos para subsistemas fora do escopo desta SRS, mas com os quais esse
aplicativo de software deve interagir.]

Pgina 157
3.4. INTERFACES DE COMUNICAES
[Descreva todas as interfaces de comunicaes com outros sistemas ou dispositivos como, por
exemplo, redes locais, dispositivos seriais remotos etc.]
4. REQUISITOS DE LICENCIAMENTO
[Esta seo define todos os requisitos de imposio de licenciamento ou outros requisitos de restrio
de utilizao que devem ser exibidos pelo software.]
5. DETALHAMENTO DOS REQUISITOS NO-FUNCIONAIS
[Esta seo define os atributos de qualidade de todos os requisitos no-funcionais. O objetivo da
seo gerar uma especificao completa de todos os requisitos no-funcionais do sistema. Cada
um dos requisito no-funcionais identificados deve ser especificado em uma tabela.]
5.1. <REQUISITO NO-FUNCIONAL UM>
Palavras-Chave Descrio
Tipo [Etiqueta, rtulo, identificador persistente e nico do requisito].
Descrio
[Descrio simples e breve do conceito principal ou significado
geral do requisito].
Stakeholder [Envolvidos/Afetados pelo requisito].
Escala [Escala usada para quantificar o requisito].
Mtrica [Processo ou mtodo para medir escalas dos requisitos].
Mtodo [Mtodo para medir a escala].
Freqncia [Freqncia para medio].
Responsvel [Pessoas/Departamento responsvel por fazer as medies].
Registro [Onde/Quando as medidas devem ser reportadas].
Nvel Mnimo [O nvel mnimo requerido para evitar falhas].
Plano [Nvel para obter sucesso exigido].
Nvel Sucesso [Como prolongar, aumentar, alongar o sucesso].
Nvel Desejado
[Nvel desejvel de sucesso que no pode ser atingido atravs
dos mtodos atuais].
Histrico [Resultados anteriores para comparao (histrico)].
Tendncia [Tendncia histrica].
Histrico de Sucesso [O melhor resultado obtido].
Definio [Definio oficial do termo].
Autoridade [Pessoa, grupo ou nvel de autorizao].