engenharia de requisitos parte escrita
TRANSCRIPT
-
8/2/2019 Engenharia de Requisitos Parte Escrita
1/57
CENTRO UNIVERSITRIO AUGUSTO MOTTAUNISUAM
ENGENHARIA DE PRODUO
Rio de JaneiroSetembro de 2010
-
8/2/2019 Engenharia de Requisitos Parte Escrita
2/57
Engenharia de Requisitos
Alunos:
Aguilar Junior
Bruno OliveiraCarlos Trindade
Leandro Amaral
Marcelo Abbadia
Thas Conde
Walter Machado
Rio de JaneiroSetembro de 2010
-
8/2/2019 Engenharia de Requisitos Parte Escrita
3/57
RESUMO
Esta pesquisa tem como objetivo principal demonstrar princpios bsicos da Engenharia de
Requisitos no Processo de Desenvolvimento do Produto. A pesquisa composta de dois materiais:
arquivo de texto descritivo contendo os temas propostos detalhadamente e arquivo para
apresentao contendo os temas propostos dispostos em tpicos e ilustraes. Ao concluir o estudo
do material, o aluno ter noes bsicas de requisitos, localizar facilmente a Engenharia de
Requisitos dentro do Processo de Desenvolvimento do Produto, entender a importncia da
Engenharia de Requisitos, conhecer os tipos e subtipos de requisitos e as normas internacionais que
regem tais divises, compreender o processo de Elicitao, Modelagem e Anlise e Gerenciamento
de Requisitos e ter domnio dos fatores crticos fundamentais no sucesso de uma Engenharia de
Requisitos bem sucedida. Em dois momentos do material para apresentao foi adicionado pausas
que tem por objetivo verificar a absoro do conhecimento apresentado. Na primeira pausa ser
proposto ao aluno a confeco de uma lista de requisitos aleatrios para um produto especfico,
neste momento o aluno ter conhecimento apenas do conceito de Requisitos e da importncia da
Engenharia de Requisitos no Processo de Desenvolvimento do Produto. Na segunda pausa, o aluno j
ter sido apresentado aos tipos e subtipos de requisitos e tambm ao processo de produo egerenciamento de requisitos e ser verificado a absoro destes temas.
Palavras-chave: Requisitos, Engenharia de Requisitos, Elicitao, Modelagem, Anlise
-
8/2/2019 Engenharia de Requisitos Parte Escrita
4/57
SUMRIO
Contedo
NOES DE REQUISITOS ......................................................................................................................... 5
REQUISITOS x ESPECIFICAO ............................................................................................................ 5
REQUISITOS x RESTRIO ................................................................................................................... 6
REQUISITOS x PREMISSAS ................................................................................................................... 7
A ENGENHARIA DE REQUISITOS .......................................................................................................... 8
PARA QUE SERVE A ENGENHARIA DE REQUISITO? ............................................................................. 8
A ENGENHARIA DE REQUISITOS NO CICLO DE VIDA DO PRODUTO ...................................................... 10
A IMPORTNCIA DOS REQUISITOS ........................................................................................................ 13
TIPOS DE REQUISITOS ........................................................................................................................... 20
REQUISITOS FUNCIONAIS .................................................................................................................. 20
REQUISITOS NO FUNCIONAIS ......................................................................................................... 20
CLASSIFICAO DE REQUISITOS ............................................................................................................ 21
CLASSIFICAO QUANTO A QUALIDADE INTERNA E EXTERNA ........................................................ 22
CLASSIFICAO QUANTO A QUALIDADE EM USO ............................................................................ 25
CLASSIFICAO QUANTO AO NVEL DE ABSTRAO ........................................................................ 26
O PROCESSO DA ENGENHARIA DE REQUISITOS .................................................................................... 27
PRODUO DE REQUISITOS .................................................................................................................. 33
ELICITAO ........................................................................................................................................ 33
MODELAGEM .................................................................................................................................... 40
ANLISE ............................................................................................................................................. 42
GERENCIAMENTO DE REQUISITOS ........................................................................................................ 45FATORES CRTICOS DE SUCESSO ........................................................................................................... 48
DEFINIO DE REQUISITOS ILUSTRAES ......................................................................................... 51
CONCLUSES ......................................................................................................................................... 56
BIBLIOGRAFIA ........................................................................................................................................ 57
-
8/2/2019 Engenharia de Requisitos Parte Escrita
5/57
NOES DE REQUISITOS
Podemos definir requisitos como sendo A exigncia imprescindvel para a consecuo de
certo fim, entretanto buscando outras fontes bibliogrficas podemos encontrar as definies abaixo
listadas:
1) Uma condies ou capacidade necessitada pelo cliente para resolver um problemaou atingir um objetivo;
2) Uma condio ou capacidade que deve ser satisfeita ou possuda por um produto oucomponente para satisfazer um contrato, padro, especificao ou outros
documentos formalmente impostos;3) Uma representao documentada de uma condio ou capacidade dispostas nos
itens (1) ou (2).
Antes de continuarmos com o desenvolvimento do tema, torna-se extremamente necessrio
a diferenciao de requisitos de outros conceitos normalmente confundidos com a definio de
requisitos de um projeto, sistema ou produto. Abaixo segue as comparaes entre os termos em que
normalmente h a confuso.
Existem diferentes definies em diversas literaturas tcnicas para cada conceito que ser
exibido, as citaes encontradas definem os mesmos conceitos sob diferentes perspectivas. Nesta
pesquisa iremos exibir os conceitos que julgamos ter melhor insero dentro do tema explorado. A
partir deste contexto toda a pesquisa ser desenvolvida.
REQUISITOS X ESPECIFICAO
RequisitoCondio necessria para a obteno de certo objetivo, ou para preenchimentode certo fim.
Especificao Descrio rigorosa e minuciosa das caractersticas que um produto, umaobra, ou um servio dever apresentar. Podemos dizer ainda que o processo de representao dos
requisitos de uma forma que leva a implementao bem-sucedida.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
6/57
Com base na conceituao acima, podemos entender que as especificaes de um produto
so conseqncia de um requisito. Assim sendo, podemos utilizar o exemplo abaixo para ratificar o
entendimento.
O desenvolvimento de um eletrodomstico deve prever a sua utilizao na rede domestica
brasileira.
O requisito da necessidade acima que o aparelho eletrodomstico funcione em uma
residncia no Brasil. Evidentemente de conhecimento que o fornecimento de energia eltrica no
Brasil se d atravs de concessionrias de energia que entregam nas tomadas residenciais
eletricidade na faixa de 127V a 220V com uma freqncia estvel de 60hz. Deste modo a
especificao do aparelho eletrodomstico ser de tenso de alimentao de 127V a 220V com
freqncia de 60Hz.
REQUISITOS X RESTRIO
RequisitoCondio necessria para a obteno de certo objetivo, ou para preenchimentode certo fim.
Restrio O estado, a qualidade ou o sentido de estar restrito a uma determinada ao ouinatividade. Uma restrio ou limitao aplicvel, interna ou externa ao projeto, que afetar o
desempenho do projeto ou de um processo. Exemplos de restrio restrio de tempo, qualidade,
custos, etc.
Figura 1
-
8/2/2019 Engenharia de Requisitos Parte Escrita
7/57
A figura 01 ilustra o relacionamento entre as trs restries bsicas de um projeto, verifica-se
que ao alterar um dos fatores os outros tambm so afetados. Este modelo chamado de Tripla
Restrio.
Com base na conceituao acima, podemos entender que as especificaes de um produto
so conseqncia de um requisito. Assim sendo, podemos utilizar o exemplo abaixo para ratificar o
entendimento.
Para o desenvolvimento do celular com tela touch screen ser disponibilizado R$ 100.000,00
para o desenvolvimento do produto e a equipe de desenvolvimento dever terminar o projeto em
at 180 dias.
O requisito da necessidade acima que o aparelho celular tenha tela touch screen e as
restries impostas a este projeto so de Tempo e de Custos. No caso do tempo, temos a restrio
de dias que o projeto no deve ultrapassar (no caso acima o limite de 180 dias) e para a restrio
de custo temos o limite oramentrio de R$ 100.000,00 que deve ser respeitado no desenvolvimento
do projeto.
REQUISITOS X PREMISSAS
Requisito Condio necessria para a obteno de certo objetivo, ou parapreenchimento de certo fim.
Especificao Basicamente premissas so hipteses e requisitos referem-se aosdeveres de funcionalidade do produto. Porm, essa definio no basta para apresentar claramente
a diferena entre os dois termos.
A chave da questo est na pergunta: Quem executa o trabalho est no ambiente externo
ou interno ao projeto?.
Premissas so suposies dadas como certas sobre o ambiente externo ao projeto. Sobre
elas baseado o plano e a promessa de tempo e custo.
Podemos resumir a afirmao acima na equao:
-
8/2/2019 Engenharia de Requisitos Parte Escrita
8/57
Premissas = Suposies + Ambiente externo ao Projeto
.Se houver a manuteno da estabilidade econmica aps as eleies presidenciais, ser
desenvolvido a televiso com conversor digital integrado.
O requisito da necessidade acima que a televiso tenha conversor digital embutido
(integrado), a premissa para que o desenvolvimento ocorra que aps as eleies a estabilidade
econmica se mantenha.
Em outras palavras podemos dizer que premissas so suposies externas ao projeto que
no so de domnio do desenvolvedor do projeto e se prev apenas o seu monitoramento atravs de
medies durante um perodo determinado.
A ENGENHARIA DE REQUISITOS
Mas o que Engenharia de Requisitos? Para responder a esta pergunta, vamos
buscar no dicionrio o significado de cada uma das palavras: a engenharia (Arte de aplicar os
conhecimentos cientficos inveno, aperfeioamento ou utilizao da tcnica industrial em todasas suas determinaes Dicionrio Michaelis) aplicada a obteno metdica de requisitos
(Requisitos: Condio necessria para a obteno de certo objetivo, ou para o preenchimento de
certo objetivo.) do produto, sejam estes Funcionais ou No-Funcionais, tratando os de maneira
sistemtica e padronizada como fim de se ter um reaproveitamento da anlise de requisitos feita,
para qualquer outro projeto semelhante ou mesmo para manuteno do mesmo.
PARA QUE SERVE A ENGENHARIA DE REQUISITO?
Todas as etapas que formam a base de desenvolvimento de um produto tm sua importncia
dentro do contexto geral, sempre com o objetivo principal de auxiliar, dentro de suas especificaes,
o andamento desse desenvolvimento. Com a engenharia de requisitos ocorre da mesma forma. Ela
possui uma tarefa inicial muito importante nesse processo, pois havendo procedimentos bem
definidos que ajudem na tarefa de elicitar os requisitos de um produto a ser desenvolvido, isso se
-
8/2/2019 Engenharia de Requisitos Parte Escrita
9/57
torna mais fcil e um pouco menos dependente do talento das pessoas e de suas experincias nesse
tipo de atividade, evitando boa parte do re-trabalho e de inconsistncias desses requisitos.
A Engenharia de Requisitos (ER) define um documento de requisitos funcionais e requisitos
no funcionais onde se deve ter a viso de todos os requisitos do problema a ser resolvido ou de sua
face inicial de acordo com o modelo de ciclo de vida usado na anlise.
A ER tambm tem a funo de diminuir custos de desenvolvimento atravs de um processo
de amadurecimento de idias a medida que novos requisitos so expostos, isso se deve a premissa
de que quanto mais cedo se identifique a mudana menos esforo ela resultar. Isso feito atravs,
principalmente da conscientizao de que os requisitos so mutveis e atravs da escolha de um
modelo de ciclo de vida adequado.
A ER pode fazer ainda o acompanhamento da resoluo dos requisitos e da mudana dos
mesmos, dando suporte avaliao de custos e riscos na mudana dos requisitos ao longo da anlise
ou projeto com a finalidade de avaliar a viabilidade da mudana dos mesmos no atual instante de
desenvolvimento.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
10/57
A ENGENHARIA DE REQUISITOS NO CICLO DE VIDA DO PRODUTO
Dentro do processo de desenvolvimento do produto, uma das atividades a Elaborao de
Requisitos, a figura abaixo mostra de forma linear onde a Engenharia de Requisitos se posiciona.
Entretanto, h diversos modelos de ciclos de desenvolvimento do produto que podem ser ilustrados
de diversas formas diferentes.
Figura 2
Os modelos existentes possuem diferentes graus de sofisticao e complexidade. Paraprojetos que envolvem uma equipe de desenvolvimento pouco numerosa e experiente, o mais
adequado ser provavelmente um processo simples. No entanto, para sistemas maiores queenvolvem equipes de dezenas ou centenas de elementos e milhares de utilizadores, um processosimples no suficiente para oferecer a estrutura de gesto e disciplina necessrias engenharia deum bom produto. Desta forma, necessrio algo mais formal e disciplinado. importante fazer notarque isto no significa que se perca em inovao ou que se pe entraves criatividade. Significaapenas que utilizado um processo bem estruturado para permitir a criao de uma base estvelpara a criatividade.
Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto, de fato, uma verso simplificada da realidade. suposto ser uma abstrao e, tal como todas asboas abstraes, apenas a quantidade de detalhe necessria ao trabalho em mos deve ser includa.
Qualquer organizao que deseje por um modelo de ciclo de vida em prtica ir necessitar deadicionar detalhes especficos para dadas circunstncias e diferentes culturas. Por exemplo, a
-
8/2/2019 Engenharia de Requisitos Parte Escrita
11/57
Microsoft quis manter uma cultura de pequena equipa e ao mesmo tempo tornar possvel odesenvolvimento de grandes e complexos produtos.
A seguir iremos dar uma introduo de uma interpretao do aspecto que um modelo de
ciclo de vida deve ter em termos de engenharia de requisitos para projetos de produtos.Dependendo do tipo de sistema em desenvolvimento pode no ser completamente possvel ou atapropriado seguir os modelos rigorosamente. de notar tambm que para por em prtica um destesmodelos e aplic-lo a um projeto real seria necessrio adicionar mais detalhes.
A engenharia de produto tem produzido inmeros modelos de ciclo de vida, incluindo osmodelos de cascata, espiral e desenvolvimento rpido de aplicaes (RAD). Antes do modelo decascata ser proposto em 1970, no havia concordncia em termos dos mtodos a levar a cabo nodesenvolvimento de software. Desde ento ao longo dos anos muitos modelos tm sido propostosrefletindo assim a grande variedade de interpretaes e caminhos que podem ser tomadas nodesenvolvimento de produtos. Nesta pesquisa foi decidida a incluso destes modelos por duas
razes: primeiro porque so representativos dos modelos utilizados na indstria e foi j provado oseu sucesso, e segundo porque mostram como a nfase no desenvolvimento de produto mudougradualmente de forma a incluir uma viso mais interativa e centrada no utilizador.
O modelo de ciclo de vida em cascata foi o primeiro modelo a ser conhecido em engenhariade produto e est na base de muitos ciclos de vida utilizados hoje em dia. Este consiste basicamentenum modelo linear em que cada passo deve ser completado antes que o prximo passo possa seriniciado. Por exemplo, a anlise de requisitos deve ser completada antes que o desenho do sistemapossa ser iniciado. Os nomes dados a cada passo variam, assim como varia a definio exata de cadaum deles, mas basicamente o ciclo de vida comea com a anlise de requisitos movendo-se deseguida para a fase de desenho, codificao, implementao, teste e finalmente manuteno do
sistema. Uma das grandes falhas deste modelo o fato de os requisitos estarem constantemente amudar j que os negcios e ambiente em que se inserem mudam rapidamente. Isto significa que nofaz sentido parar os requisitos durante muito tempo, enquanto o desenho e implementao dosistema so completados. Foi ento reconhecido que seria necessrio dar feedback s atividadesiniciais a partir do momento em que este modelo comeou a ser usado em grande escala. A idia deinterao no foi incorporada na filosofia do modelo de cascata. Neste momento, includo algumnvel de interao na maior parte das verses deste modelo e so comuns sesses de reviso entreos elementos responsveis pelo desenvolvimento do sistema. No entanto, a possibilidade de revisoe avaliao com os utilizadores do sistema no est contemplada neste modelo.
Durante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de
projetos de produto, mas em 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiralpara desenvolvimento de produto saltam a vista dois aspectos: a anlise de risco e prototipagem. Omodelo espiral incorpora-os de uma forma interativa permitindo que as idias e o progresso sejamverificados e avaliados constantemente. Cada interao volta da espiral pode ser baseada nummodelo diferente e pode ter diferentes atividades. No caso da espiral, no foi a necessidade doenvolvimento dos utilizadores que inspirou a introduo de interao, mas sim a necessidade deidentificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que asdiferentes atividades so repetidas at uma deciso ser tomada e o documento de especificao derequisitos ser aceito. Se forem encontrados problemas numa verso inicial do documento, reentram-se nas fases de levantamento, anlise, documentao e validao. Isto se repete at que sejaproduzido um documento aceitvel ou at que fatores externos, tais como prazos e falta de recursos
ditem o final do processo de engenharia de requisitos.
http://pt.wikipedia.org/wiki/Modelo_em_espiralhttp://pt.wikipedia.org/wiki/Modelo_em_espiral -
8/2/2019 Engenharia de Requisitos Parte Escrita
12/57
Ao nos aprofundarmos na Engenharia de requisitos iremos observar basicamente trs temas
principais e suas descries conforme abaixo:
Figura 3
-
8/2/2019 Engenharia de Requisitos Parte Escrita
13/57
A IMPORTNCIA DOS REQUISITOS
Para falarmos da importncia dos requisitos, precisamos definir projeto:
Projeto um empreendimento temporrio que cria um produto, servio ou resultado nico.
Os fatores crticos para o sucesso de um projeto esto listados abaixo, nota-se que o principal
fator crtico refere-se aos Requisitos.
Atendimento dos Requisitos Tcnicos e Funcionais Cumprimento do Oramento Cumprimento do Cronograma Satisfao dos Interessados Benefcios para o patrocinador
A passagem abaixo tambm retrata tal importncia:
A parte mais rdua na construo de um produto consiste exatamente em identificar o que
construir. Nenhuma outra parte do trabalho compromete tanto o resultado do projeto se elaborado
de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correes
posteriores. Fred Brook
Podemos notar tamanha importncia ao observar o grfico exibido na figura 04. Neste
grfico observamos que as falhas so causadas por vrios motivos, mas o principal relativo a
requisitos inadequados. Ou seja, mais da metade das falhas tem sua origem em requisitos realizados
inadequadamente.
Figura 4
-
8/2/2019 Engenharia de Requisitos Parte Escrita
14/57
Estas falhas geram custos uma vez que precisam ser reparadas. A manuteno destas falhas,provenientes de requisitos inadequados, deve ter ateno no processo de desenvolvimento doproduto. . Consideramos como manuteno (especificamente nesta pesquisa) como sendo qualquerretrabalho (em nvel de requisitos, projeto, codificao, teste) causado por uma definio do domnio
do problema mal elaborada nas fases iniciais do desenvolvimento.Neste ponto, importante analisamos os dados da tabela exibida na figura 05. Percebemosque o custo das atividades relacionadas anlise de requisitos baixo. Por outro lado, nesta faseque grande parte dos defeitos so inseridos. Podemos perceber ainda analisando a primeira linhaque o custo de correo destes problemas nesta fase baixo. Continuando a anlise, percebemosque estes defeitos no so tratados no momento devido, o que pode aumentar bastante o custo como projeto.
Embora simples, esta anlise nos permite concluir que importante que seja dada maiorimportncia s atividades relacionadas especificao dos requisitos do produto.
Figura 5
Reforando a importncia que as atividades relacionadas a requisitos devem possuir naindstria de desenvolvimento de produto, estudo realizado pelo Standish Group, considerando 350companhias e 8.000 projetos, em 1995 revelou que:
52.7% dos projetos so considerados problemticos, ou seja, no cobre todas asfuncionalidades exigidas, custo aumentado e est atrasado.
31,1% dos projetos fracassam, ou seja, o projeto cancelado durante o desenvolvimento.
16,2% dos projetos so finalizados com sucesso, ou seja, cobre todas as funcionalidades emtempo e dentro do custo previsto;
Na figura 06 verificamos a demonstrao grfica destes dados:
-
8/2/2019 Engenharia de Requisitos Parte Escrita
15/57
Figura 6
O Standish Group ainda fez uma anlise sobre os fatores crticos para sucesso dos projetos deprodutos. O resultado dos dez mais lembrados pode ser visto na Tabela da figura 07. Podemosperceber que trs dos principais fatores esto relacionados s atividades de requisitos: (1) RequisitosIncompletos; (2) Falta de Envolvimento do Usurio; (6) Mudana de Requisitos e Especificaes.
Figura 7
Ainda destacando a importncia dos requisitos e seus impactos financeiros, podemos
analisar a figura 08 e 09 que exibem sob diferentes pontos de vista os custos com requisitos
inadequados:
-
8/2/2019 Engenharia de Requisitos Parte Escrita
16/57
Figura 8
Figura 9
-
8/2/2019 Engenharia de Requisitos Parte Escrita
17/57
Os impactos de requisitos inadequados, no se restringem apenas a parte financeira. Na
figura 10 verificamos que diversas reas de uma empresa so afetadas por requisitos inadequados de
um produto. Os problemas refletem em praticamente toda a empresa.
Figura 10
Os resultados de requisitos inadequados podem ser desastrosos para empresa e tambm
para o que o cliente esperava. Na figura 11 so exibido alguns projetos de produtos que no
satisfizeram em nada seus clientes e so frutos de requisitos inadequadamente definidos.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
18/57
Figura 11
Podemos exibir graficamente o esforo desprendido em cada fase do desenvolvimento de
um produto. E assim podemos notar que os esforos desprendidos com definio de requisitos so
realizados praticamente durante todo o processo de desenvolvimento do produto com seu pice na
fase inicial. Na figura 12 exibida abaixo temos uma viso geral baseada na RUP (Rational Unified
Process Processo unificado Racional) que nada mais do que uma metodologia de engenharia e
um processo considerado pesado e preferencialmente aplicvel a grandes equipes de
desenvolvimento e a grandes projetos, porm o fato de ser amplamente customizvel torna possvel
que seja adaptado para projetos de qualquer escala. Para a gerncia do projeto, o RUP prov uma
soluo disciplinada de como assinalar tarefas e responsabilidades dentro de uma organizao de
desenvolvimento de produtos.
http://pt.wikipedia.org/wiki/Projetohttp://pt.wikipedia.org/wiki/Projeto -
8/2/2019 Engenharia de Requisitos Parte Escrita
19/57
Figura 12
-
8/2/2019 Engenharia de Requisitos Parte Escrita
20/57
TIPOS DE REQUISITOS
Os requisitos so, geralmente, categorizados como:
Requisitos Funcionais So aqueles que representam a funcionalidade do produto
implementaes);
Requisitos No Funcionais So aqueles que restringem os requisitos funcionais
(restries).
REQUISITOS FUNCIONAIS
So requisitos diretamente ligados a funcionalidade do produto, descrevem as funes que o
produto deve executar. Alguns exemplos so:
O celular deve efetuar ligaes telefnicas; O celular deve permitir o envio de mensagens de texto; O celular deve ter acesso a internet.
REQUISITOS NO FUNCIONAIS
So requisitos que expressam condies que o produto deve atender ou qualidades
especficas que o produto deve ter. Em vez de informar o que o produto far, os requisitos no-
funcionais colocam restries no produto. Alguns exemplos so:
O celular deve ser compatvel com as redes GSM com freqncias utilizadas noBrasil;
O celular deve garantir que o tempo de retorno das consultas sua agenda no sejamaior do que 1 segundo.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
21/57
CLASSIFICAO DE REQUISITOS
Antes de classificarmos os requisitos, precisamos tomar conhecimento dos sistemas de
padronizao internacionais que efetuam a regulamentao das normas que classificam os
requisitos. Estas formam o sistema especializado para padronizao mais conhecido. As mesmas so
mostradas abaixo:
ISO - The International Organization for Standardizatized IEC - The International Electrotechnical Commition
Para classificarmos os requisitos, iremos estrutura-los quanto a sua qualidade.A qualidade deum produto pode ser entendida de diversas formas e utilizando diferentes abordagens.
A Norma ISO/IEC 9126 trata deste tema estabelecendo um modelo de qualidade com os
componentes abaixo listados:
Qualidade do Produto Compreende os atributos de qualidade do produtodividindo-se entre atributos Internos & Externos, diferenciando-se entre si pela
forma que so aferidos (interna ou externamente);
Qualidade em Uso Consiste na aferio da qualidade em cada contextoespecifico de usurio, esta tambm a qualidade percebida pelo usurio.
Assim sendo podemos definir as caractersticas de qualidade como:
Qualidade Interna - a totalidade das caractersticas do produto a partir de uma viso
interna durante o seu desenvolvimento ou manuteno;
Qualidade Externa - a totalidade das caractersticas do produto a partir de uma viso
externa durante a sua execuo;
Qualidade em uso - a viso do usurio da qualidade do produto quando ele usado em um
ambiente especfico e de um contexto especfico de uso. Ele mede a extenso em que usurios
podem alcanar seus objetivos em um ambiente particular, ao invs de medir o prprio produto.
Na figura 13 podemos verificar a estrutura de relacionamento entre estas qualidades e suaimplicao no produto.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
22/57
Figura 13
CLASSIFICAO QUANTO A QUALIDADE INTERNA E EXTERNA
De acordo com a Norma ISO/IEC 9126-1:2001 podemos avaliar seis caractersticas de
qualidade definidas estruturadas conforme ilustrao abaixo (figura 14):
Figura 14
-
8/2/2019 Engenharia de Requisitos Parte Escrita
23/57
Iremos a partir de agora definir cada uma destas seis caractersticas e suas sub-
caracteristicas:
Funcionalidade A capacidade do produto de prover funes que satisfazem necessidades explcitas
e implcitas, quando o produto usado sob condies especificadas.
AdequaoA capacidade do produto de fornecer um conjunto apropriado de funes paratarefas especificas e objetivos do cliente.
Preciso - A capacidade do produto para prever o correto ou acordado resultados ou efeitoscom o grau de preciso necessrio.
Interoperabilidade - A capacidade do produto de interagir com um ou maisproduto/sistemas especificados.
Segurana A capacidade do produto de fornecer segurana ao cliente. Assegurando quesomente usurios autorizados tero acesso a informaes.
Conformidade Funcional A capacidade do produto de aderir as normas, convenes ouregulamentaes previstas em leis e similares relacionadas funcionalidade.
Confiabilidade A capacidade de um produto em manter um nvel de desempenho especificado,
quando usado sob condies especificadas.
Maturidade - A capacidade do produto para evitar o fracasso como resultado de falhas noproduto.
Freqncia de Falhas Tolerncia a falhas - A capacidade do produto para manter um nvel de desempenho
especificado em casos de falhas ou de violao de suas especificaes.
Recuperabilidade - A capacidade do produto de restabelecer um nvel de desempenhoespecificado e recuperar-se de falhas sem perdas.
Conformidade da Confiabilidade- A capacidade do produto a aderir a normas, convenesou regulamentaes relacionadas confiabilidade.
(A disponibilidade considerada uma combinao de maturidade, tolerncia a falhas e
recuperabilidade).
Usabilidade - A capacidade do produto de ser compreendido, aprendido, usado e atrativo para o
cliente, quando usado sob condies especificadas.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
24/57
Compreensibilidade - A capacidade do produto para permitir ao usurio compreender se oproduto adequado, e como ele pode ser usado para tarefas especficas e condies de uso.
Aprendizibilidade - A capacidade do produto para permitir ao usurio aprender suaaplicao.
Operacionalidade - A capacidade do produto para permitir o usurio para operar e controlar. AtratividadeA capacidade do produto em ser atraente para o cliente. Conformidade Usual - A capacidade do produto de aderir aos padres, convenes, guias de
estilo ou regulamentaes relacionadas usabilidade.
Eficincia - A capacidade do produto para oferecer um desempenho adequado, em relao
quantidade de recursos usados, sob condies estabelecidas.
Tempo de comportamento - A capacidade do produto em dar uma resposta adequada(tempo) ao executar sua funo, sob condies estabelecidas.
Utilizao dos recursos - A capacidade do produto em usar quantidades adequadas e tiposde recursos ao executar suas funes sob condies estabelecidas.
Conformidade da Eficincia - A capacidade do produto em aderir s normas e convenesrelacionadas eficincia.
Manutenibilidade - A capacidade do produto em ser modificado. As modificaes podem incluir
correes, melhorias ou adaptao do produto s mudanas no ambiente e nos requisitos e
especificaes funcionais.
Analisabilidade - A capacidade do produto em ser diagnosticado por deficincias ou causasde falhas no produto, ou para as peas a serem modificados para serem identificados.
Mutabilidade - A capacidade do produto em permitir que uma modificao especificada sejaimplementada.
Estabilidade - A capacidade do produto a fim de evitar efeitos inesperados de modificaesdo produto.
Testabilidade - A capacidade do produto em permitir que a modificao seja validada. Conformidade da Manutenibilidade - A capacidade do produto em aderir a normas ou
convenes relacionadas manutenibilidade
PortabilidadeA capacidade do produto de ser transferido de um ambiente para o outro.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
25/57
Adaptabilidade - A capacidade do produto de ser adaptado para diferentes ambientesespecificados, sem aplicao de aes ou outros meios que no os previstos para este efeito
o produto considerado.
Instalabilidade - A capacidade do produto em ser utilizado em um ambiente determinado. Co-existncia - A capacidade do produto de coexistir com outro produto independente em
um ambiente comum, compartilhando recursos comuns.
Substituibilidade - A capacidade do produto em ser usado no lugar de outro produtoespecificado para o mesmo efeito no mesmo ambiente.
Conformidade da Portabilidade - A capacidade do produto em aderir a normas ouconvenes relacionadas portabilidade.
CLASSIFICAO QUANTO A QUALIDADE EM USO
De acordo com a Norma ISO/IEC 9126-1:2001 podemos classificar os Requisitos No
Funcionais quanto a sua Qualidade em Uso estruturadas conforme ilustrao abaixo (figura 15):
Figura 15
Eficcia A capacidade do produto em permitir aos usurios atingir metas especificadas compreciso e plenitude em um contexto de uso especificado.
Produtividade A capacidade do produto em permitir que os clientes gastem uma quantidadeadequada de recursos em relao eficcia alcanada em um contexto de utilizao especificadas.
Segurana A capacidade do produto em atingir nveis aceitveis de risco de danos s pessoas,negcios, software, bens ou o ambiente em um contexto de uso especificado.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
26/57
SatisfaoA capacidade do produto em satisfazer o cliente em um contexto de uso especificado.
CLASSIFICAO QUANTO AO NVEL DE ABSTRAO
Podemos ainda classificar os requisitos quanto ao seu nvel de abstrao conforme abaixo:
Requisitos de Negcios Representam objetivos de alto nvel da organizao ou do cliente quesolicita ao cliente o produto.
Geralmente elicitado na viso e escopo documentados
Requisitos do ClienteDescreve os objetivos do usurio ou tarefas que o usurio deve ser capaz deexecutar com o produto.
Geralmente elicitado em modelos de casos de uso / documentos
Requisitos do Produto So os requisitos para o produto como um todo (que podem incluircomponentes fsicos e de inteligncia)
Elicitado em especificao de requisitos de produtoRequisitos LgicosSo derivados dos requisitos do produto (atravs da atribuio de requisitos deproduto para componentes de inteligncia e detalh-los)
Elicitado em especificao de requisitos de produto
-
8/2/2019 Engenharia de Requisitos Parte Escrita
27/57
O PROCESSO DA ENGENHARIA DE REQUISITOS
Para nos aprofundarmos nos processos da ER e entender como as atividades inseridas neste
processo se relacionam, devemos apreciar uma outra definio para Engenharia de Requisitos:
Atividades relacionadas produo (levantamento, registro, validao e verificao) e
gerncia (controle de mudanas, gerncia de configurao, rastreabilidade, gerncia de qualidade
dos requisitos) de requisitos.
A figura 16 representa esta definio graficamente.
Figura 16
O processo da Engenharia de requisitos refere-se atividade de definir e documentar as
funes e funcionalidades do projeto, e do produto, necessrias para atender s necessidades e
expectativas das partes interessadas (NBR ISO/IEC 12207).
O sucesso do projeto diretamente influenciado pela ateno na captura e gerenciamento
dos requisitos do projeto e do produto.
Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para
serem medidos na Execuo.
Escopo do produto. As caractersticas e funes do produto, servio ou resultado.
Escopo do projeto. O trabalho que precisa ser realizado para entregar um produto,
servio ou resultado com as caractersticas e funes especificadas.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
28/57
Os interessados no projeto e conseqentemente no produto so chamados de stakeholders que
pode ser definido conforme abaixo:
Interessados no produto Pessoas que sero afetadas pelo produto e que tem uma influncia direta ou indireta na
elaborao dos requisitos:
Utilizadores finais Gestores e outros envolvidos nos processos organizacionais que o produto influencia Responsveis pelo desenvolvimento e manuteno do produto Clientes da organizao que possam vir a usar o produto Organismos de regulao e certificao
Exemplo num sistema automtico de sinalizao ferroviria:
Operadores do sistema, condutores dos comboios, gestores, passageiros, engenheiros de
instalao e manuteno, autoridades de certificao e segurana.
Desta forma, os dois conceitos base (produo e gerncia) devem ser considerados em
conjunto ao se definir estratgias de trabalho com requisitos nas organizaes (ver Figura 17).
Figura 17
Neste ponto podemos citar alguns dos principais objetivos da engenharia de requisitos:
Estabelecer uma viso comum entre o cliente e a equipe de projeto em relao aosrequisitos que sero atendidos pelo projeto do produto;
-
8/2/2019 Engenharia de Requisitos Parte Escrita
29/57
Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento; Documentar e controlar os requisitos alocados para estabelecer um baseline para
uso gerencial e da engenharia de produto;
Manter planos, artefatos e atividades de produto consistentes com os requisitosalocados.
Para apoiar o alcance destes objetivos, importante que se tenha um processo de
engenharia de requisitos bem definido. Um processo de engenharia de requisitos um conjunto
estruturado de atividades a serem seguidas para criar, validar e manter um documento de requisitos.
Poucas organizaes tm um processo de ER explicitamente definido e padronizado. Entretanto,sugere-se que cada organizao deva desenvolver um processo adequado sua realidade. A figura
18 apresenta um modelo genrico de atividades que pode descrever a maioria dos processos de
engenharia de requisitos. Perceba que ele est concentrado nas atividades de produo dos
requisitos.
Figura 18
-
8/2/2019 Engenharia de Requisitos Parte Escrita
30/57
Apesar do aparente fluxo entre as atividades, no existe uma fronteira explcita elas. Na
prtica existe muita sobreposio e interao entre uma atividade e outra.
Como entradas para o processo so consideradas:
Descries do que os stakeholders necessitam para suportar suas atividades; Informaes a respeito do sistema que ser substitudo ou de qualquer sistema com
o qual o sistema sendo definido ter que interagir;
Padres vigentes na organizao a respeito de prticas de desenvolvimento desistemas, gerncia de qualidade, etc.;
Regulamentos externos, tais como leis, regulamentos de segurana ou sade; Informaes gerais sobre o domnio de aplicao.
Em paralelo execuo das atividades definidas no processo da Figura 18, est o processo de
gerncia dos requisitos, voltado ao endereamento de modificaes nos requisitos. Os aspectos
relacionados s atividades de gerncia podem ser vistos na Figura 16.
A Figura 19 ilustra o processo de captura das necessidades dos stakeholders e a partir delas oestabelecimento do conjunto de features e requisitos. Este modelo conhecido como Modelo
Espiral.
Figura 19
-
8/2/2019 Engenharia de Requisitos Parte Escrita
31/57
A volta mais interna da espiral representa a primeira compreenso do conjunto das
necessidades at a definio dos requisitos que as endeream. As demais voltas representam
aperfeioamentos sobre os resultados anteriores. Devido a um melhor entendimento do problema,
novos elementos podem surgir, alguns podem desaparecer ou serem modificados at que se chegue
a um resultado julgado necessrio e suficiente para iniciar o desenvolvimento propriamente dito.
Conforme sugere a figura o processo iterativo e constitudo por quatro fases, cada uma
representada por um quadrante.
No quadrante 1, LEVANTAMENTO DAS NECESSIDADES, parte-se do conjunto anterior de
necessidades e atravs de procedimentos e instrumentos especficos envolvendo especialistas de
requisitos e representantes dos slots vo sendo colhidas e incorporadas as necessidades. Quando
todos os slots forem considerados os especialistas estaro de posse de um conjunto de necessidades
dos slots e tal conjunto ter redundncias e incongruncias minimizadas.
O quadrante 2, NEGOCIAO, representa uma negociao em que as necessidades apuradasanteriormente so submetidas apreciao de uma plenria cujos participantes tm poder de
deciso. Tal plenria tem como objetivo a definio do escopo do projeto, ou seja, definir quais as
necessidades que devero ser atendidas por ele. Esse conjunto de necessidades servir como base
para a definio dos requisitos. As necessidades recusadas ser o mantidas no sistema a ttulo de
histrico no sendo mais objeto de anlise do projeto.
No quadrante 3, ESCOLHA DE FEATURES, cada necessidade constante do escopo do projeto
objeto de anlise com o objetivo de definir pelo menos uma feature do futuro sistema que a atenda.
Podem existir diversas features alocadas a uma necessidade mas nenhuma necessidade pode ficar
sem uma feature alocada. Essa parte do processo executada por especialistas que, com o auxliodos stakeholders que deram origem s necessidades, buscam uma soluo adequada ela. O
resultado um conjunto de features em que cada uma descrita na forma de caso de uso com um
nvel alto de abstrao.
No ltimo quadrante, DEFINIO DE REQUISITOS, as features so trabalhadas no sentido de
se chegar a um conjunto de recursos ou requisitos que as suporte. Tal tarefa deve ser comandada
pelos especialistas de requisitos auxiliados por stakeholders tcnicos e especialistas. O resultado
um conjunto dos requisitos do projeto descritos na forma de casos de uso com um nvel de detalhes
que permita o seu entendimento por qualquer interessado.
Note-se que o processo inicia-se com a proposta do problema pelos interessados no
desenvolvimento do sistema. Na primeira volta da espiral, a mais interna, obtida a maioria das
necessidades, features e requisitos. As voltas adicionais da espiral sugerem que os conjuntos de
necessidades, features e requisitos podem sempre ser alterados seja para modificao, incorporao
ou remoo de elementos.
Abaixo na figura 20 observamos a ilustrao do processo da engenharia de requisitos.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
32/57
Figura 20
-
8/2/2019 Engenharia de Requisitos Parte Escrita
33/57
PRODUO DE REQUISITOS
O processo de definio de requisitos pode ser definido, resumidamente, por trs atividades:
elicitao, modelagem e anlise (veja figura 21). Geralmente, estas atividades ocorrem simultnea e
incrementalmente, num processo evolutivo que dura todo o processo de desenvolvimento do
produto.
Figura 21
ELICITAO
Elicitar usualmente definido como a atividade voltada para descobrir (identificar, deduzir,
extrair, evocar, obter) os requisitos de um produto, atravs de entrevistas com os interessados no
produto, de documentos, da anlise do domnio do problema ou de estudo de mercado.
O engenheiro / analista de requisitos utiliza alguma ou um conjunto de tcnicas para
descobrir (elicitar) os requisitos do produto a ser desenvolvido.
Algumas das tcnicas mais conhecidas esto relacionadas a tcnicas de leitura dedocumentos, brainstorm, observao, entrevistas, reunies, questionrios, cenrio, antropologia,
participao ativa dos steakholders e engenharia reversa.
O termo elicitao de requisitos sugere que o processo uma simples transferncia de
conhecimento, onde os engenheiros de requisitos documentam os conhecimentos dos clientes. Na
verdade mais complexo: os clientes nem sempre tem uma ideia clara dos requisitos, existem
conflitos de requisitos dentro da organizao, geralmente ligadas a limitaes tecnolgicas. A
elicitao um processo complexo de negociao envolvendo todos os stakeholders do produto.
Existem quatro dimenses para a elicitao de requisitos:
Compreender o domnio da aplicao
-
8/2/2019 Engenharia de Requisitos Parte Escrita
34/57
Compreenso do problema
Compreenso da rea de negcio
Conhecer as necessidades dos stakeholders
O processo de elicitao conta basicamente com os seguintes papis:
Analista de Requisitos: Responsvel pela seleo da tcnica e pela conduo da elicitao de
requisitos;
Gerente de Projetos: Responsvel por prover informaes sobre o projeto para o Analista de
Requisitos e tambm aprovar a tcnica indicada pelo processo;
Cliente/Usurio: Responsvel por prover informaes para identificao dos requisitos.
Existem diversas tcnicas de elicitao e em seguida iremos exibir as normalmente utilizadas:
Entrevista:
Esta tcnica resume-se em conversas realizadas com o usurio (entrevistado) paralevantar os requisitos do produto a ser desenvolvido. Podemos decompor esta tcnica nas seguintes
atividades:
o Ler material de suporte;
o Estabelecer os objetivos da entrevista;
o Decidir quem entrevistar;
o Preparar o entrevistado;
o Decidir os tipos de questes e a sua estrutura.
Uma entrevista pode ser estruturada de trs diferentes formas:
o Estrutura em pirmide: iniciamos as entrevistas com perguntas mais especificas sobre o
produto e fechamos com perguntas mais genricas. Geralmente utilizadas com usurios mais
relutantes;
o Estrutura em funil: iniciamos as entrevistas com perguntas mais genricas sobre oproduto e fechamos com perguntas mais especificas. Geralmente utilizadas com usurios que tem
uma relao mais afetiva com o assunto;
-
8/2/2019 Engenharia de Requisitos Parte Escrita
35/57
o Estrutura em diamante: esta estrutura combina as duas estruturas anteriores e
utilizadas para manter a usurio entrevistado interessado no assunto e para isto se utiliza de
perguntas variadas.
Prototipao:
uma verso inicial de um produto para experimentao. Permite aos utilizadores identificar
os pontos fortes e fracos do produto por ser algo concreto que pode ser criticado.
Temos dois tipos de prottipos:
o Prottipos Throw-away: ajudam o levantamento e desenvolvimento dos requisitos esuportam os requisitos mais difceis de perceber;
o Prottipos Evolutivos: ajudam o desenvolvimento rpido de uma verso inicial do
produto e suportam os requisitos bem definidos e conhecidos.
Algumas das desvantagens da prototipao so os custos de aprendizagem e os custos de
desenvolvimento.
Os benefcios do uso da prototipao so listados abaixo:
O prottipo permite que os usurios experimentem e descubram o que eles realmentenecessitam para suportar o trabalho deles; Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido
realizados;
Essencial para desenvolvimento do aspecto look andfeel da interface do usurio; Pode ser usado para teste do produto e desenvolvimento da documentao; Fora um estudo detalhado dos requisitos que revela inconsistncias e omisses.
JAD
JAD (Joint Application Development): uma tcnica que permite a interao entre pessoas
que necessitam tomar decises que afetem mltiplas reas de uma organizao. Esta tcnica envolve
atividades de preparao para as reunies, sesses de workshop com os participantes, agenda para
as reunies, participantes assumindo papeis de facilitador / condutor e documentador alm de
facilidades visuais, como a utilizao de flipchart, quadro negro.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
36/57
Esta tcnica deve ser utilizada nos casos onde existe a necessidade de consenso entre
diversos usurios, pois possibilita a todos os envolvidos ter uma viso global do produto, ajudando a
consolidar interesses de diversos usurios quanto ao produto a ser desenvolvido.
O objetivo desta tcnica aumentar o comprometimento e participao do usurio e obtersubsdios para elaborar o documento de Especificao de Requisitos para o produto com consenso
de todos de forma a ser uma validao formal dos requisitos do produto.
Brainstorm
Em sesses de Brainstorming, um grupo de pessoas reunido, um cenrio simulado e um
assunto discutido para elicitar os requisitos. As pessoas participantes devem se sentir confortveis obastante para discutir o assunto sem se sentirem intimidadas. Nenhuma idia descartada. Todas as
idias so boas idias.
Cenrios
Tem como objetivo a obteno de entendimento das funes e caractersticas de uso de umproduto, alm de criar um conjunto de cenrios que identifiquem a linha de uso para o produto.
So teis para abstrair exemplos da vida real e adicionar detalhes ao esboo de requisitos.
O processo de elicitao pode ser ilustrado conforme figura 22, exibida abaixo:
Figura 22
Identificar o Contexto do Projeto
-
8/2/2019 Engenharia de Requisitos Parte Escrita
37/57
Esta atividade tem como propsito contextualizar o Analista de Requisitos sobre o Projeto
que ser desenvolvido. Atravs de uma reunio com o Gerente do Projeto, o Analista obtm
informaes relacionadas ao escopo, premissas, restries e informaes relacionadas ao domnio do
negcio do cliente antes de realizar um primeiro contato direto com o(s) usurio(s) do produto.
Baseado nas informaes obtidas nesta atividade, o Analista de Requisitos poder analisar o domnio
de negcio do cliente e os dados do projeto de uma forma mais contextualizada para prosseguir no
processo de elicitao.
Como resultado da atividade, elaborado um documento pelo Analista, que poder ser
atualizado durante a execuo do processo de elicitao. Neste documento, so registrados os
termos relevantes relacionados ao domnio de negcio do cliente visando facilitar a compreenso e
comunicao entre os envolvidos no processo de elicitao.
Realizar Apresentao inicial
Esta atividade tem como propsito realizar uma reunio para conscientizar os envolvidos
sobre a importncia da colaborao do(s) usurio(s) dentro do processo de elicitao de requisitos,
uma vez que esta colaborao estar associada ao sucesso do resultado final do produto que ser
desenvolvido.
Durante a reunio, o Analista de Requisitos tambm coleta informaes sobre os papis e
responsabilidades dos envolvidos no processo de elicitao. Estas informaes sero estruturadasem uma Matriz de Responsabilidades. A Matriz de Responsabilidades permite ao Analista de
Requisitos identificar o perfil de cada um dos usurios envolvidos, facilitando assim a conduo da
elicitao. Normalmente uma Ata de Reunio gerada para documentar os temas abordados e
repass-los a todos os envolvidos.
Selecionar a Tcnica de Elicitao
O propsito desta atividade auxiliar o Analista de Requisitos a escolher uma tcnica de
elicitao que melhor se adapte s caractersticas do projeto, da organizao e da equipe de
desenvolvimento. Esta atividade foca em orientar o Analista de Requisitos na escolha da tcnica a ser
utilizada com base em parmetros relacionados ao projeto.
Para fins de exemplos, selecionamos os que geralmente impactam nos projetos independente da
estrutura da Organizao. Os parmetros selecionados e suas definies so apresentados a seguir:
o Fonte de obteno dos requisitos: Indica se a tcnica aplicada em grupo ouindividualmente. Considerado uma restrio no processo de tomada de deciso;
-
8/2/2019 Engenharia de Requisitos Parte Escrita
38/57
o Qualidade: Indica se a tcnica permite um aprendizado mtuo, resoluo de conflito eidentificao dos requisitos;
o Tempo: Indica o tempo despendido para a elicitao de requisitos;o Custo: Indica o custo (relacionado a pessoas e capital) necessrio;o Confiabilidade: Indica se as informaes coletadas so confiveis para o desenvolvimento do
projeto;
o Contexto: Indica se a tcnica leva em conta o ambiente onde est se realizando a elicitao,ou seja, se a tcnica permite que o Analista de Requisitos considere efetivamente o domnio
do negcio sobre o qual o produto ser desenvolvido;
o Validao dos requisitos: Indica se a tcnica permite validao dos requisitos;o Necessidade de treinamento: Indica o nvel de necessidade de treinamento que o Analista
de Requisitos precisar para conhecer e aplicar a tcnica na elicitao.
O Analista define quais parmetros devem ser priorizados na escolha da tcnica que ser
utilizada para elicitao dos requisitos de acordo com caractersticas do projeto (levantadas nas
atividades anteriores). Esta definio realizada atravs da atribuio do grau de relevncia (nota)
para cada um dos parmetros. Este peso pode variar de 0 a 5 pontos. Os valores entre 0 e 2 indicamuma relevncia baixa do parmetro para o projeto. Os valores entre 3 e 5 indicam que o parmetro
apresenta alta relevncia. O Analista deve registrar uma justificativa para cada nota para anlises
futuras.
Os resultados da matriz so gerados atravs do somatrio das pontuaes intermedirias
obtidas para cada tcnica. Estas pontuaes so calculadas atravs da multiplicao do peso pela
nota, atribuda pelo Analista, para cada tcnica em relao a cada parmetro. A tcnica mais
adequada ser a que obtiver a maior pontuao total. Abaixo exemplo de uma matriz de deciso.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
39/57
Figura 23
Aplicar a Tcnica de Elicitao
Esta atividade tem como propsito coletar e listar os requisitos para desenvolvimento do produto. O
Analista de Requisitos utilizando a tcnica selecionada coleta os requisitos necessrios para
desenvolvimento do produto junto ao(s) cliente(s).
Como resultado desta atividade, gerado um documento, denominado neste processo como
Requisitos Identificados, contendo os requisitos elicitados durante a aplicao da tcnica. O Glossrio
tambm pode ser atualizado caso o Analista de Requisitos identifique alguma necessidade.
Elaborar Lista de Requisitos
Nesta atividade, o Analista de Requisitos elabora a Lista de Requisitos, baseado nos
Requisitos Identificados durante a elicitao aplicando a tcnica selecionada.
A Lista de Requisitos deve conter uma descrio do produto em desenvolvimento, a
descrio dos requisitos e o critrio de aceitao, que consiste nas condies necessrias para
verificar se o requisito foi implementado.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
40/57
Depois de finalizada a Lista de Requisitos, esta deve ser revisada, aprovada e assinada pelo
Gerente do Projeto e pelo representante do cliente ou dos usurios. Esta aprovao intermediria.
A atividade formal de verificao/validao dos requisitos no contemplada neste processo, porm
para que se possa dar prosseguimento nas demais atividades de Definio de Requisitos, que no
esto includas neste processo, necessria uma validao intermediria do Gerente e do Cliente.
MODELAGEM
As informaes obtidas durante a elicitao so registradas e organizadas em modelos de
requisitos tais como, casos de uso, cenrios e lxico, entidade relacionamento, dentre outros. A
construo destes modelos exige maior aprofundamento no conhecimento sobre as necessidades
dos usurios e tambm informaes tcnicas. Isto remete atividade de anlise, sendo necessrioanalisar as informaes registradas para descobrir erros e omisses, sendo muitas vezes necessrio
retornar elicitao para esclarecer, acrescentar ou corrigir o conhecimento adquirido.
Pela modelagem so atingidos quatro objetivos, no que se refere ao produto:
I. Modelos ajudam o desenvolvedor e o cliente a visualizarem um produtocomo ele ou deve ser
II. Modelos nos permitem especificar a estrutura ou o comportamento de umproduto
III. Modelos nos do um molde que nos guia na construo de um produto e,finalmente
IV. Modelos documentam as decises tomadas.
A modelagem de requisitos a atividade central no processo de engenharia de requisitos
porque dela resulta o produto principal deste processo: o documento de requisitos, o documento no
qual os desenvolvedores devem se basear para construir o produto.
Vrios modelos so necessrios para compor o documento de requisitos porque cada um
deles enfatiza apenas parte dos aspectos necessrios para que os desenvolvedores entendam o que
o produto sendo construdo deve prover e o seu contexto.
A partir de agora iremos exibir algumas das tcnicas de modelagem mais utilizadas.
Entrelaamento
Um requisito entrelaado ocorre quando em uma unidade de decomposio existe mais deuma descrio de requisitos diferentes. Uma unidade de decomposio de requisitos que contm
-
8/2/2019 Engenharia de Requisitos Parte Escrita
41/57
vrias propriedades diferentes pode ser difcil de entender. Esta situao oferece uma oportunidade
de refatorao.
Espalhamento
Um requisito espalhado uma situao que ocorre quando a especificao de uma
funcionalidade no est encapsulada em uma nica unidade de decomposio de requisitos.
Duplicao
A duplicao de requisitos caracteriza-se por: o mesmo requisito (ou informao) estar
duplicado em diferentes partes de um documento de requisitos, ou o mesmo requisito, pr ou pscondio aparecerem em diversas estruturas do documento de requisitos.
Modelos de Metas
Modelos de metas surgiram com o objetivo de modelar, tambm, a razo da existncia dos
requisitos. Desta maneira, o engenheiro consegue identificar a soluo mais adequada para o
problema em questo. Metas trazem tona requisitos e regras de negcio normalmente omitidos, e
que muitas vezes, levam ao fracasso do produto.
Modelos de metas representam explicitamente requisitos funcionais e no funcionais
atravs da decomposio de metas. Esta decomposio indica como satisfazer uma determinada
meta, indicando a razo pela qual as submetas so necessrias.
Casos de uso
Uma descrio de um conjunto de seqncias de aes, resultantes da interao do produto
com um cliente (um tipo de requerente). As aes produzem um resultado que pode ser observadopelo cliente.
Viewpoint
So mecanismos que permitem considerar aspectos do produto percebidos por diferentes
requerentes. Ao se analisar o produto por vrios aspectos obtm-se uma especificao mais
adequada. Os viewpoints permitem melhor entendimento das necessidades dos usurios mediante
cada uma das atividades do processo.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
42/57
A figura 24 mostra alguns exemplos de Templates (modelos de documentos) de Requisitos
normalmente utilizados.
Figura 24
ANLISE
Alm da anlise de erros e omisses o processo de definio de requisitos possibilita a
anlise sob diferentes perspectivas tais como, viabilidade, custo, tempo, prioridades, reuso,
completude, corretude, variabilidade, evoluo, dentre outras. Basicamente temos duas atividades
principais dentro da anlise:
Verificao
Validao
-
8/2/2019 Engenharia de Requisitos Parte Escrita
43/57
Verificao
Esta atividade examina a especificao do produto, de forma a assegurar que todos osrequisitos foram definidos sem ambigidades, inconsistncias ou omisses, detectando e corrigindo
possveis problemas ainda durante a fase de definio dos requisitos.
Neste contexto, sabe-se que o custo da correo de defeitos aumenta na medida em que o
processo de desenvolvimento progride. Revises de artefatos de produto tm se mostrado uma
abordagem eficiente e de baixo custo para encontrar defeitos logo aps terem sido introduzidos,
reduzindo o retrabalho e melhorando a qualidade dos produtos.
Um tipo particular de reviso de produto so as inspees. Inspees possuem um processo
de deteco de defeitos rigoroso e bem definido. Os benefcios de se aplicar inspees so maiores
para artefatos desenvolvidos no incio do processo, como o documento de requisitos.
Validao
A validao representa a atividade em que obtemos o aceite do cliente sob determinado
artefato. No cenrio de engenharia de requisitos, esta atividade significa aprovar junto ao cliente os
requisitos que foram especificados. Embora aparentemente simples, esta atividade pode serbastante dificultada pelo cliente ou mesmo por um processo de validao inadequado utilizado pela
empresa.
Abaixo listamos a lista de verificao que deve ser realizada para garantir o sucesso da
produo dos requisitos. Trata-se de um checklist que deve ser realizado.
Projeto Prematuro Os requisitos incluem informao prematura de projeto ou implementao?
Requisitos Combinados A descrio dos requisitos descreve um requisito nico ou este pode ser
descrito em vrios requisitos diferentes?
Requisitos Desnecessrios O requisito realmente necessrio, ou mera adio cosmtica ao
produto?
Uso de equipamentos no padronizados Os requisitos implicam na utilizao de equipamentos
no padronizados?
Est de acordo com os objetivos de Negcio O requisito consistente com os objetivos de
negcio definidos na introduo do documentos de requisitos?
Ambiguidade de Requisitos O requisito ambiguo, isto poder ser lido de forma diferente por
pessoas diferentes? Quais so as possibilidades de interpretacao dos requisitos?
-
8/2/2019 Engenharia de Requisitos Parte Escrita
44/57
Viabilidade dos Requisitos O requisito viavel em relacao a tecnologia usada para
implementacao do produto?
Teste dos Requisitos Podemos testar os requisitos, ou seja, eles foram escritos de tal forma que
um engenheiro/analista de teste poder derivar o teste que mostrar se o produto satisfaz osrequisitos?
A figura 25 ilustra graficamente todo o processo de produo de requisitos.
Figura 25
-
8/2/2019 Engenharia de Requisitos Parte Escrita
45/57
GERENCIAMENTO DE REQUISITOS
Gerenciamento de requisitos o processo de controlar as mudanas dos requisitos durante:
O Processo da Engenharia de Requisitos O Desenvolvimento do Produto
Requisitos so inevitavelmente incompletos e inconsistentes
Requisitos novos surgem durante o processo de acordo com mudanas nasnecessidades do negcio e um entendimento melhor do produto desenvolvido.
Diferentes pontos de vista tm diferentes requisitos e esses geralmente socontraditrios.
A reutilizao, evoluo e rastreabilidade de requisitos esto intimamente relacionados habilidade
de gerenciar interaes entre requisitos, que por sua vez, est relacionada habilidade de separar e
compor caractersticas, representando-as em modelos. Visto que, geralmente, um nico tipo de
modelo no suficiente para explicitar todas as caractersticas do produto, diferentes modelos so
utilizados, tornando as informaes espalhadas e entrelaadas, tambm, em diferentes vises.
Reuso
Reuso envolve considerar requisitos que foram desenvolvidos para um sistema eus-los em sistemas diferentes;
O reuso de requisitos economiza tempo e esforo, pois requisitos reutilizados jforam analisados e validados em outros sistemas;
Atualmente o reuso de requisitos um processo informal. Contudo, um reuso maissistemtico economizaria muito esforo;
Vantagens: produtividade e qualidade (componentes j validados); Desvantagens: dificuldade de se promover reutilizao sem modificao.
Evoluo
Devido natureza voltil dos requisitos, necessrio estar preparado para mudanas, ou evoluo. A
evoluo de requisitos ocorre em dois sentidos: no sentido do desenvolvimento de produto,
-
8/2/2019 Engenharia de Requisitos Parte Escrita
46/57
mudando do nvel alto de abstrao para a implementao, e de requisitos para cdigo; e no sentido
da melhoria contnua para atender as expectativas dos requisitantes, sofrendo alteraes
decorrentes de erros/omisses ou para atender novas necessidades.Em ambos os sentidos, conhecer
e gerenciar as interaes entre requisitos extremamente importante para:
A decomposio e modularizao das caractersticas do produto porque indica oacoplamento e coeso entre as partes envolvidas;
E para a anlise do impacto de mudanas, tanto entre requisitos no mesmo nvel deabstrao quanto entre requisitos e artefatos de produto em nveis de abstrao
diferentes.
Rastreamento
Responsvel por dependncias entre requisitos, suas origens e projeto do produto
Rastreamento de Origem (Pr-Rastreabilidade) Associao entre requisitos e stakeholders que propuseram tais requisitos
Rastreamento entre Requisitos Associao entre requisitos dependentes
Rastreamento de Projeto (Ps-Rastreabilidade) Associao dos requisitos com o projeto
Gerencia de Qualidade de Requisitos
Segundo o padro IEEE 830, devemos considerar alguns critrios de qualidade ao
trabalharmos com requisitos:
Correo: um documento de requisitos considerado correto se todos os requisitos
representam algo que deve estar presente no produto que est sendo desenvolvido, ou seja, os
requisitos reais do cliente devem coincidir com os requisitos identificados. Esta no uma tarefa
trivial e parte de seu sucesso est associada a uma boa atividade de validao dos requisitos.
No ambigidade: um conjunto de requisitos no ambguo quando somente pode ser
interpretado por todos os envolvidos em um projeto de uma nica maneira.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
47/57
Completude: um conjunto de requisitos dito completo quando descreve todas as
demandas de interesse dos clientes. Estas demandas incluem requisitos funcionais, de desempenho,
restries, atributos e interfaces externas.
Consistncia: um conjunto de requisitos dito consistente se nenhum subconjunto destesrequisitos entra em conflito com os demais requisitos do produto.
Verificabilidade: um requisito verificvel se existe uma forma efetiva, em termos de tempo
e custo, para que pessoas ou ferramentas indiquem se um produto cumpre o requisito (IEEE). Em
quase todas as situaes, difcil provar de forma conclusiva que um requisito cumprido por um
produto. Entretanto, escrever bem o requisito pode ajudar a aumentar a confiana na avaliao.
Modificabilidade: um conjunto de requisitos modificvel quando seu estilo e estrutura tal
que as alteraes podem ser realizadas de forma simples e consistente com os demais requisitos.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
48/57
FATORES CRTICOS DE SUCESSO
A seguir iremos apresentar diversos aspectos que devem ser observados quando
trabalhamos com Engenharia de Requisitos. Desprender ateno para estes aspectos com certeza
aumentar as chances de sucesso.
Dificuldade na Definio de Requisitos
Conforme declarao abaixo, a comunicao um dos fatores fundamentais para o sucesso do
projeto.
Sei que voc acredita que entendeu o que acha que eu disse, mas no estou certo de que percebe
que aquilo que ouviu no o que eu pretendia dizer ... - Declarao de um cliente annimo.
Alguns outros problemas tambm merecem ateno:
Problemas de escopo: os limites do produto so geralmente definidos de forma incompleta, ou os
clientes/usurios especificam detalhes tcnicos desnecessrios;
Problemas de compreenso: os clientes/usurios geralmente no esto completamente certos das
necessidades, tm uma compreenso pobre das capacidades e limitaes de seu ambientecomputacional ou do domnio do seu negcio, omitem informaes que julgam bvias e etc.
Problemas de volatilidade: os requisitos mudam o tempo todo.
Stakeholders em geral no sabem o que querem Stakeholders expressam requisitos em sua terminologia Stakeholders diferentes podem gerar requisitos conflitantes Fatores polticos e organizacionais podem influenciar os requisitos do produto Requisitos mudam durante o processo de anlise. Stakeholders novos podem surgir e o
ambiente de trabalho mudar
Requisitos Funcionais e No Funcionais tendem a ser misturados Vrios requisitos diferentes podem ser expressos juntos Uso de expressoes extremamente tcnicas Comunicao ineficiente
-
8/2/2019 Engenharia de Requisitos Parte Escrita
49/57
Tcnicas e ferramentas inadequadas (especificao inadequada e imprecisa) Tendncias de se eliminar a tarefa de Especificao dos Requisitos Falhas ao considerar alternativas antes que o produto seja especificado Ser que realmente entendi o que o cliente deseja? Devo me certificar de que no houve falha em nossa interao (comunicao) H diversas tcnicas de validao Demonstrar que os requisitos definem o produto que o cliente realmente deseja Custos com erros de requisitos so altos Consertar um erro de requisitos aps entrega do produto pode custar mais de 100 vezes o
custo de um erro de implementao
Aquisio da informao
Que informao deve ser coletada e como ela deve ser representada? Quem fornece as informaes? Que tcnicas e ferramentas esto disponveis para facilitar a coleta de informaes?
Tamanho do Projeto
Como eliminar inconsistncias na especificao de grandes projetos? possvel detectar omisses?
Pode um grande projeto ser efetivamente particionado para que se torneintelectualmente administrvel?
Alteraes
Como as alteraes efetuadas em outros elementos do produto so coordenadas com osrequisitos do produto?
Como se determina o impacto de uma alterao em outras partes do produtoaparentemente no relacionadas?
Como se corrige erros na especificao para que no se gere efeitos colaterais?
-
8/2/2019 Engenharia de Requisitos Parte Escrita
50/57
Atravs de ilustraes tambm podemos exemplificar outros problemas:
Figura 26
preciso tambm definir prioridades ao trabalharmos com requisitos. Alguns requisitos so
mais urgentes que outros. essencial determinar a prioridade dos requisitos junto ao cliente.
Requisitos de maior prioridade so considerados em primeiro lugar
Requisitos podem ser vistos em trs classes distintas:
Essenciais Importantes Desejveis
Em princpio, o desenvolvimento do produto deve resolver todos os requisitos de essenciais para
desejveis.
o Um celular deve ser capaz de efetuar Roaming Prioridade: Essencial
o A mudana de rede deve ser feita de forma automtica Prioridade: Importante
o Ao mudar de rede, o celular deve emitir um bip e mudar de cor Prioridade: Desejvel
-
8/2/2019 Engenharia de Requisitos Parte Escrita
51/57
DEFINIO DE REQUISITOS ILUSTRAES
Estaremos agora exibindo algumas ilustraes que vo nos ajudar a compreender melhor
todos os aspectos da Engenharia de Requisitos.
Figura 27
Figura 28
-
8/2/2019 Engenharia de Requisitos Parte Escrita
52/57
A definio de requisitos consiste, na verdade, na compreenso de um dado problema, e adefinio das caractersticas e restries para a soluo desse problema. A compreenso doproblema, ou seja, o negcio, os stakeholders e suas necessidades pertencem ao domnio doproblema e as caractersticas e restries do sistema pertencem ao domnio da soluo. Uma
dificuldade que se apresenta nesse processo que, para os stakeholders, a separao entre essesdois domnios no ntida. As pessoas tm a tendncia de elaborar caractersticas e definir restriesantes de compreender detalhadamente necessidades relativas a elas e isto natural, pois acompreenso de um problema s vezes demanda o esboo de elementos para a sua soluo.
O mtodo exibido nas figuras 27 e 28 concebido de forma tal que os elementos do domniodo problema so capturados e os do domnio da soluo so vislumbrados e definidos permitindoque a fronteira entre os domnios seja cruzada nos dois sentidos vrias vezes durante a elicitao.Desta forma as necessidades, caractersticas e restries so definidas num processo incremental eiterativo a partir de entrevistas com stakeholders e anlise e sntese de especialistas de requisitos.Alm disso, o mtodo registra o histrico de cada requisito, da necessidade que o gerou aos
artefatos utilizados na anlise. A definio de requisitos realizada em duas etapas sendo que ambasso conduzidas pelos especialistas de requisitos que devem ser direcionados por aspectosinstitucionais, ambientais e pelas fronteiras ou bordas do problema.
Na primeira etapa determinam-se quais so os grupos funcionais de stakeholders (gerentes,desenvolvedores, patrocinadores, agentes reguladores, usurios,...), definem-se a populao de cadagrupo e respectivos representantes. Na segunda etapa feita a captura das necessidades dosstakeholders e, para cada necessidade, determinado um conjunto de features e para cada featureos requisitos necessrios ao seu atendimento.
Figura 29
-
8/2/2019 Engenharia de Requisitos Parte Escrita
53/57
Na figura 29 podemos verificar a definio dos Stakeholders que como j foi definido sopessoas e organizaes, como clientes, patrocinadores, organizaes executoras e o pblico, queestejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positivaou negativa pela execuo ou trmino do projeto. Elas podem tambm exercer influncia sobre o
projeto e suas entregas (PMBoK 3 edio).
Figura 30
Na ilustrao da figura 30, verificamos o relacionamento entre requisitos e o papel dorastreamento de requisitos que utilizado para justamente prover relacionamentos entre requisitos,
e possibilitar uma adequada compreenso dos relacionamentos de dependncia entre requisitos eatravs dos artefatos de requisitos, de arquitetura e de implementao. A rastreabilidade pode serimplementada por um conjunto de elos ou ligaes entre requisitos inter-relacionados, entrerequisitos e suas fontes, e entre requisitos e os componentes que os implementam.
A rastreabilidade de requisitos tem sido identificada como fator de qualidade, caractersticaque um sistema pode possuir e incluir como requisito no funcional, alm de ser um dos maisimportantes pr- requisitos para desenvolvimento de produtos.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
54/57
Figura 31
Na figura 31, verificamos a relao entre necessidades e features, cada uma das necessidadesdo escopo considerada com o objetivo de se estabelecer um conjunto de features para atend-la.
Pelo menos uma feature precisa ser estabelecida para cada necessidade. Para auxiliar nessa tarefadevem-se considerar as features coletadas durante a captura das necessidades. Tais features podemser reutilizadas parcial ou integralmente se isso for julgado conveniente. No caso de necessidadesque no tenham features sugeridas ser necessrio que se criem novas ou se reutilize alguma que jtenha sido definida. Assim que forem definidas, todas as features devero ser registradas na formade casos de uso com nvel pequeno de detalhes bem como informaes sobre o seu estado e seusrelacionamentos com as necessidades de origem e com os requisitos a ela alocados.
A definio dos requisitos feita com um processo semelhante da features: para cadauma das features determinado o conjunto de requisitos funcionais e no funcionais necessrios sua realizao. O conjunto de requisitos coletados na captura das necessidades de grande valia
nessa tarefa, pois o reuso total ou parcial de requisitos sugeridos pode agilizar essa etapa. Osrequisitos que forem definidos sero registrados como casos de uso detalhados juntamente com asrespectivas informaes de estado e relacionamentos. O registro dos relacionamentos dos requisitospermitem o seu rastreamento, isto , determinar as suas origens e o que pode ser afetado em casode uma modificao futura.
As features e requisitos sugeridos durante a captura de necessidades devero ser mantidospelo sistema a ttulo de histrico, mesmo os que no foram reaproveitados.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
55/57
Figura 32
Na figura 32 podemos verificar que a elicitacao de requisitos se comporta de forma cclica eseqencial, demonstrando desta forma a extrema importncia do gerenciamento de requisitosgerindo cada mudana de etapa e alterao/incluso de requisitos durante o processo dedesenvolvimento do produto.
-
8/2/2019 Engenharia de Requisitos Parte Escrita
56/57
CONCLUSES
importante perceber que a engenharia de requisitos depende muito da interao entre o
cliente e desenvolvedor do projeto, de modo que seja minimizado qualquer problema na definio
de requisitos por parte do cliente. Por mais que no se deseje, os requisitos estaro sempre
mudando durante o desenvolvimento de um produto, e quo melhor for o processo de engenharia
de requisitos desenvolvido por todos na empresa, menores sero os problemas encontrados em
funo de toda a dificuldade que envolve esta importante parte da anlise.
Tambm notvel que o cenrio atual na engenharia de requisitos esta muito longe do ideal
tanto para os clientes como para os desenvolvedores de projetos, isto se deve a falta de
padronizao principalmente na engenharia de requisitos no funcionais, e a falta de uma real
conscientizao da importncia da engenharia de requisitos no contexto da engenharia de produto.
Tambm h uma carncia conceitual em relao aos profissionais da rea de engenharia de
produto relacionada a falta ou pouco entendimento do domnio do problema do problema a ser
analisado e documentado, sendo este causado pela transdisciplinalidade da aplicao de engenharia
de produto na resoluo de problemas
-
8/2/2019 Engenharia de Requisitos Parte Escrita
57/57
BIBLIOGRAFIA
Requirements Engineering Processes and Techniques, Gerald Kotonya, Ian Sommerville, Wiley,
1998
Information Systems: An introduction to informatics in organizations. P. Beynon-Davies, Palgrave,
2002
Software Testing, Ron Patton, SAMS, 2001
Planeamento de Sistemas de Informao, Lus Amaral, Joo Varajo, FCA Editora, 2000
Requirements Analysis and System Design: Developing Information Systems with UML, L. A.
Maciaszek, Addison-Wesley, 2001
IEEE Std 610.12: 1990 - Standard Glossary of Software Engineering Terminology
(http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf?arnumber=159342)
Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 edition, IEEE Computer
Society (http://www.swebok.org/)
ISO/IEC Std 12207:1995 - Information technology - Software life cycle processes
(http://www.iso.org/)
Tese sobre Requisitos No-Funcionais
http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf
Representing and Using Non-Functional Requirements
http://www-di.inf.puc-rio.br/~karin/pos/nonfunctional.pdf
Gerenciamento de Requisitos
http://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_
0003.2xt/-template_interna
Four Dark Corners of Requirements Engineeringhttp://www-di.inf.puc-rio.br/~karin/pos/corners.pdf
http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf?arnumber=159342http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf?arnumber=159342http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf?arnumber=159342http://www.swebok.org/http://www.swebok.org/http://www.swebok.org/http://www.iso.org/http://www.iso.org/http://www.iso.org/http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdfhttp://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdfhttp://www-di.inf.puc-rio.br/~karin/pos/nonfunctional.pdfhttp://www-di.inf.puc-rio.br/~karin/pos/nonfunctional.pdfhttp://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_0003.2xt/-template_internahttp://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_0003.2xt/-template_internahttp://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_0003.2xt/-template_internahttp://www-di.inf.puc-rio.br/~karin/pos/corners.pdfhttp://www-di.inf.puc-rio.br/~karin/pos/corners.pdfhttp://www-di.inf.puc-rio.br/~karin/pos/corners.pdfhttp://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_0003.2xt/-template_internahttp://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_0003.2xt/-template_internahttp://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003_10_10_0003.2xt/-template_internahttp://www-di.inf.puc-rio.br/~karin/pos/nonfunctional.pdfhttp://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdfhttp://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdfhttp://www.iso.org/http://www.swebok.org/http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf?arnumber=159342