cap07.pdf

Ian Sommerville 2006 Engenharia de Software, 8. edio. Captulo 7 Slide 1 2007 by Pearson Education

Processos de Engenharia deRequisitos


Objetivos

Descrever as principais atividades de engenharia de requisitose seus relacionamentos

Apresentar tcnicas para elicitao e anlise de requisitos Descrever validao de requisitos e o papel das revises de

requisitos Discutir o papel do gerenciamento de requisitos no apoio de

outros processos de engenharia de requisitos


Tpicos abordados

Estudos de viabilidade Elicitao e anlise de requisitos Validao de requisitos Gerenciamento de requisitos


Processos de engenharia de requisitos

Os processos usados nos requisitos de engenharia(doravante, RE) variam amplamente dependendo do domniode aplicao, das pessoas envolvidas e da organizao quedesenvolve os requisitos.

Contudo, existe uma srie de atividades genricas comuns atodos os processos Elicitao de requisitos; Anlise de requisitos; Validao de requisitos; Gerenciamento de requisitos.


O processo de engenharia de requisitos


Engenharia de requisitos


Estudos de viabilidade

Um estudo de viabilidade decide se vale a pena ou nogastar tempo e esforo com sistema proposto.

um estudo breve e focalizado que verifica Se o sistema contribui para os objetivos da

organizao; Se o sistema pode ser implementado usando

tecnologia atual e dentro do oramento; Se o sistema pode ser integrado a outros s.


Implementao do estudo deviabilidade

Baseado na avaliao de informao (o que requerido),coleta de informao e escrita de relatrio.

Questes para as pessoas da organizao O que faria se o sistema no fosse implementado? Quais so os problemas com processo atuais? Como o sistema proposto ajudar? Quais sero os problemas de integrao? Tecnologia nova necessria? Quais habilidades? Quais recursos devem ser apoiados pelo sistema

proposto?


Elicitao e anlise

Algumas vezes chamada de elicitao de requisitos ou dedescoberta de requisitos.

Envolve pessoal tcnico trabalhando com os clientes paradescobrir sobre o domnio de aplicao, os servios que osistema deve fornecer e sobre as restries operacionais.

Pode envolver usurios finais, gerentes, engenheirosenvolvidos na manuteno, especialistas de domnio,representantes de sindicato, etc. Estes so chamandosstakeholders.


Problemas de anlise de requisitos Stakeholders no sabem o que eles realmente querem. Stakeholders expressam requisitos em seus prprios termos. Diferentes stakeholders podem ter requisitos conflitantes. Fatores organizacionais e polticos podem influenciar os

requisitos de sistema. A mudana de requisitos durante o processo de anlise. Novos

stakeholders podem surgir e o ambiente de negcio muda.


A espiral de requisitos


Atividades de processo

Obteno de requisitos Interao com os stakeholders para coletar seus

requisitos. Os requisitos de domnio so tambmdescobertos neste estgio.

Classificao e organizao de requisitos Agrupa requisitos relacionados e organiza-os em

conjuntos coerentes. Priorizao e negociao de requisitos

Priorizao de requisitos e resoluo de conflitos derequisitos.

Documentao de requisitos Os requisitos so documentados e colocados na prxima

volta da espiral.


Descoberta de requisitos

o processo de reunir informaes sobre os sistemaspropostos e existentes, e obter requisitos de usurio e desistema a partir dessas informaes.

As fontes de informao incluem documentao,stakeholders e as especificaes de sistemas similares.


Stakeholders de caixa eletrnico

Clientes de banco Representantes de outros bancos Gerentes de bancos Pessoal de conta Administradores de banco de dados Gerentes de proteo Departamento de marketing Engenheiros de manuteno de hardware e de software Reguladores de banco


Pontos de vista

Pontos de vista so uma maneira de estruturar osrequisitos para representar as perspectivas destakeholders diferentes. Stakeholders podem serclassificados em diferentes pontos de vista.

Essa anlise de mltiplas perspectivas importante, poisno h uma maneira nica correta para analisarosrequisitos de sistema.


Tipos de pontos de vista

Pontos de vista de interao So as pessoas ou os outros sistemas que interagem

diretamente com o sistema. Em um sistema de caixaeletrnica bancrio, os clientes e o banco de dados decontas so pontos de vista de interao.

Pontos de vista indiretos So os stakeholders que no usam o sistema

diretamente, mas que influenciam os requisitos. Em umsistema de caixa eletrnico bancrio, gerncia e pessoalde proteo so pontos de vista indiretos.

Pontos de vista de domnio So as caractersticas e restries de domnio que

influenciam os requisitos. Em um sistema de caixaeletrnico bancrio, um exemplo seria os padres paracomunicaes entre bancos.


Identificao de pontos de vista

Identificar pontos de vista usando: Fornecedores e receptores de servios do sistema; Sistemas que devem interfacear diretamente com o

sistema que est sendo especificado; Regulamentos e padres; Fontes de requisitos de negcio e de requisitos no

funcionais; Engenheiros que tm de desenvolver e manter o sistema; Marketing e outros pontos de vista de negcio.


Hierarquia de pontos de vista doLIBSYS


Entrevista

Em entrevista formal ou informal, a equipe de RE formulaquestes para os stakeholders sobre o sistema que elesusam e o sistema a ser desenvolvido.

Existem dois tipos de entrevistas Entrevistas fechadas, onde um conjunto de

questes predefinidas so respondidas. Entrevistas abertas, onde no h um roteiro

predefinido e onde uma variedade de assuntos soexplorados com os stakeholders.


Entrevistas na prtica

Normalmente, uma mistura de entrevistas fechadas e abertas Entrevistas so boas para obteno de um entendimento geral

do que os stakeholders fazem e como eles podem interagircom o sistema.

Entrevistas no so boas para a compreenso de requisitos dedomnio Os engenheiros de requisitos no podem entender a

terminologia especfica de domnio; Alguns conhecimentos de domnio so to especificos

que as pessoas acham difcil explicar ou pensam queno valem a pena mencion-los


Entrevistas efetivas

Os entrevistadores devem ter mente aberta, desejaremouvir os stakeholders e no ter idias preconcebidassobre os requisitos.

Eles devem induzir os entrevistados com uma questoou uma proposta, e no simplesmente esperar que elesrespondam a uma questo tal como o que voc quer?.


Cenrios

Cenrios so exemplos reais de como um sistema podeser usado.

Eles devem incluir Uma descrio da situao inicial; Uma descrio do fluxo normal de eventos; Uma descrio do que pode dar errado; Informao sobre outras atividades concorrentes; Uma descrio do estado quando o cenrio termina.


Cenrio do LIBSYS


Casos de uso

Os casos de uso constituem uma tcnica baseada emcenrios UML que identificam os agentes em uma interao, eque descrevem a interao em si.

Um conjunto de casos de uso deve descrever todas aspossveis interaes com o sistema.

Diagramas de seqncia podem ser usadas para adicionardetalhes aos casos de uso, mostrando a seqncia deprocessamento de eventos no sistema.


Caso de uso de impresso de artigo


Casos de uso do LIBSYS


Impresso de artigo


Fatores sociais e organizacionais

Sistemas de software so usados em um contexto sociale organizacional. Isso pode influenciar, ou mesmodominar os requisitos de sistema.

Fatores sociais e organizacionais no so um ponto devista nico, mas so influncias sobre todos pontos devista.

Bons analistas devem ser sensveis a esses fatores, masatualmente no h uma maneira sistemtica paracontrapor suas anlises.


Etnografia

Um cientista social despende um tempo considervelobservando e analisando como as pessoas realmentetrabalham.

As pessoas no tm de explicar ou articular seu trabalho. Fatores sociais e organizacionais de importncia podem ser

observados. Estudos de etnografia tm mostrado que o trabalho ,

geralmente, mais rico e mais complexo do que o sugeridopelos modelos simples de sistema.


Etnografia focalizada

Desenvolvida em um projeto de estudo do processo decontrole de trfego areo.

Combina etnografia com prototipao. O desenvolvimento de prottipo resulta em questes no

respondidas que enfocam a anlise etnogrfica. O problema com a etnografia, que ela estuda prticas

existentes que podem ter alguma base histrica que no mais relevante.


Etnografia e prototipao


Escopo da etnografia

So requisitos originados a partir do modo como aspessoas realmente trabalham, e no como as definiesde processo sugerem que elas deveriam trabalhar.

So requisitos originados a partir da cooperao e daconscientizao das atividades de outras pessoas.


Validao de requisitos

Dedica-se a mostrar que os requisitos definem o sistemaque o cliente realmente deseja.

Custos de erros de requisitos so altos e, desse modo, avalidao muito importante A custo da reparao de um erro de requisitos

depois da entrega pode equivaler a 100 vezes ocusto de reparao de um erro de implementao.


Verificao de requisitos

Verificao de validade. O sistema fornece as funes quemelhor apiam as necessidades do cliente?

Verificao de consistncia. Existe algum tipo de conflito derequisitos?

Verificao de completeza. Todas as funes requisitadas pelocliente foram includas?

Verificao de realismo. Os requisitos podem serimplementados com o oramento e a tecnologia disponveis?

Facilidade de verificao. Os requisitos podem ser verificados?


Tcnicas de validao de requisitos Revises de requisitos

Anlise manual sistemtica dos requisitos. Prototipao

Uso de um modelo executvel do sistema paraverificar requisitos. Abordado no Captulo 17.

Gerao de casos de teste. Desenvolvimento de testes para requisitos a fim de

verificar a testabilidade.


Revises de requisitos

Revises regulares devem ser feitas enquanto adefinio de requisitos est sendo formulada.

Ambos, cliente e fornecedor, devem ser envolvidos nasrevises.

Revises podem ser formais (com documentoscompletos) ou informais. Uma boa comunicao entredesenvolvedores, clientes e usurios podem resolverproblemas nos estgios iniciais.


Verificao de requisitos

Facilidade de verificao. O requisito realisticamentetestvel?

Facilidade de compreenso. O requisito adequademente compreendido?

Rastreabilidade. A origem do requisito claramenteestabelecida?

Adaptabilidade. O requisito pode ser mudado sem umgrande impacto em outros requisitos?


Gerenciamento de requisitos

Gerenciamento de requisitos, o processo de gerenciamentode mudanas de requisitos durante o processo de engenhariade requisitos e o desenvolvimento de sistema.

Requisitos so, inevitavelmente, incompletos e inconsistentes Novos requisitos surgem durante o processo, medida

que as necessidades de negcio mudam e uma melhorcompreenso do sistema desenvolvida;

Os diferentes pontos de vista tm requisitos diferentes eestes so freqentemente contraditrios.


Mudana de requisitos

A priorizao dos requisitos em conseqncia dasmudanas de pontos de vista durante o processo dedesenvolvimento.

Os clientes do sistema podem especificar os requisitos apartir de uma perspectiva de negcio que conflitam comos requisitos do usurio final.

Os ambientes tcnico e de negcio do sistema mudamdurante seu desenvolvimento.


Evoluo de requisitos


Requisitos permanentes e volteis Requisitos permanentes. So requisitos estveis,

derivados da atividade central da organizao do cliente.Por exemplo, um hospital ter sempre mdicos,enfermeiros, etc. Podem ser derivados dos modelos dedomnio.

Requisitos volteis. So requisitos que mudam durante odesenvolvimento, ou quando o sistema estiver emoperao. Um exemplo seria, em um hospital, osrequisitos derivados da poltica de sade.


Classificao de requisitos volteis


Planejamento de gerenciamento derequisitos

Durante o processo de engenharia de requisitos, voc tem deplanejar: A Identificao de requisitos

Como os requisitos so identificados individualmente; O processo de gerenciamento de mudanas

o processo seguido quando da anlise de umamudana de requisitos;

Polticas de rastreabilidade a quantidade de informaes que mantida sobre

os relacionamentos de requisitos; Apoio de ferramenta CASE

O apoio de ferramenta requisitada para auxiliar nogerenciamento das mudanas requisitos.


Rastreabilidade

A rastreabilidade est relacionada aos relacionamentos entreos requisitos, suas fontes e o projeto de sistema.

Rastreabilidade da fonte Ligam os requisitos aos stakeholders que propuseram os

requisitos; Rastreabilidade de requisitos

a ligao dos requisitos dependentes; Rastreabilidade de projeto

Ligam os requisitos aos mdulos de projeto.


Uma matriz de rastreabiidade


Apoio de ferramenta CASE

Armazenamento de requisitos Os requisitos devem ser mantidos em um repositrio de

dados seguro e gerenciado. Gerenciamento de mudanas

O processo de gerenciamento de mudanas umprocesso de workflow cujos estgios podem serdefinidos, e o fluxo de informaes entre esses estgios,parcialmente automatizado.

Gerenciamento de rastreabilidade Recuperao automatizada das ligaes entre os

requisitos.


Gerenciamento de mudanas derequisitos

Deve ser aplicado todas as mudanas propostas aosrequisitos.

Estgios principais Anlise de problema: discutir problemas e mudanas de

requisitos; Anlise de mudana e estimativa de custo: avaliar os

efeitos das mudanas sobre outros requisitos; Implementao de mudana: Modificar documentos de

requisitos e outros documentos para refletir asmudanas.


Gerenciamento de mudanas derequisitos


Pontos-chave

O processo de engenharia de requisitos inclui um estudode viabilidade, elicitao e anlise de requisitos,validao de requisitos e gerenciamento de requisitos.

A elicitao e a anlise de requisitos constituem umprocesso iterativo, envolvendo entendimento de domnio,coleta, classificao, estruturao, priorizao evalidao de requisitos.

Os sistemas tm mltiplos stakeholders com diferentesrequisitos.


Pontos-chave

Fatores sociais e organizacionais influenciam os requisitos desistema.

A validao de requisitos est relacionado a verificaes devalidade, consistncia, completeza, realismo e facilidade deverificao.

Mudanas de negcio levam, inevitavelmente, s mudanasde requisitos.

O gerenciamento de requisitos inclui planejamento egerenciamento de mudanas.

cap07.pdf

Documents