Engenharia de Requisitos Parte Escrita

8/2/2019 Engenharia de Requisitos Parte Escrita

1/57

CENTRO UNIVERSITRIO AUGUSTO MOTTAUNISUAM

ENGENHARIA DE PRODUO

Rio de JaneiroSetembro de 2010


2/57

Engenharia de Requisitos

Alunos:

Aguilar Junior

Bruno OliveiraCarlos Trindade

Leandro Amaral

Marcelo Abbadia

Thas Conde

Walter Machado

Rio de JaneiroSetembro de 2010


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


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


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.


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


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/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


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.


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


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


12/57

Ao nos aprofundarmos na Engenharia de requisitos iremos observar basicamente trs temas

principais e suas descries conforme abaixo:

Figura 3


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


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:


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:


16/57

Figura 8

Figura 9


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.


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


19/57

Figura 12


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.


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.


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


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.


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.


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.


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


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.


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;


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


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


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.


32/57

Figura 20


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


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;


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.


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


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;


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.


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.


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


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.


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


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?


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


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,


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.


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.


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


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?


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


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


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


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.


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.


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.


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


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

Engenharia de Requisitos Parte Escrita

Documents

Transcript of Engenharia de Requisitos Parte Escrita