WWW.DOMINANDOT I .COM .BR

Engenharia de Software

Requisitos

Professor Marcio Victorino mcvictorino@uol.com.br

RequisitosOs requisitos de um sistema so descries dos servios fornecidos

pelo sistema e as suas restries operacionais. Esses requisitos refletem

as necessidades dos clientes de um sistema que ajuda a resolver algum

problema.

Um requisito uma condio ou uma capacidade com a qual osistema deve estar de acordo.

2

Levantamento de Requisitos Chegar a um acordo sobre o que o sistema deve fazer.

Prover um melhor entendimento dos requisitos do sistema.

Definir as fronteiras do sistema.

Prover uma base para o planejamento tcnico dos contedos das iteraes.

Prover uma base para a estimativa de custos.

Definir uma interface de usurio para o sistema.

3

Como o cliente explicou.

Como o lder de projeto entendeu.

Como o analista projetou.

Como o programador construiu.

Como o consultor de negcios descreveu.

Como o projeto foi documentado.

Que funcionalidades foram instaladas.

Como o cliente foi cobrado.

Como foi mantido. O que o cliente realmente queria.

4

FURPS: Funcionalidade. Usabilidade. Confiabilidade. Desempenho. Suportabilidade: Possibilidade de teste. Extensibilidade . Adaptabilidade. Manutenibilidade Compatibilidade Possibilidade de configurao Possibilidade de instalao

Requisitos (FURPS +) + : Restries de design. Requisitos de

implementao. Requisitos de interface. Requisitos fsicos.

5

Requisitos (Sommerville)Requisitos do Usurio: so declaraes em linguagem natural e em diagramas,

sobre as funes que o sistema deve fornecer e asrestries sob as quais deve operar.

Requisitos de Sistema: estabelecem detalhadamente as funes e as restries de

sistema. Deve ser preciso (especificao funcional) e servecomo base para o contrato.

Especificao de Projeto de software: uma descrio abstrata do projeto de software; que

uma base para o projeto e a implementao maisdetalhados. Essa especificao acrescenta mais detalhes especificao de requisitos do sistema.

6

Requisitos (Sommerville)Requisitos Funcionais: so declaraes de funes que o sistema deve fornecer,

como o sistema deve reagir a entradas especficas e comodeve se comportar em determinadas situaes.

Requisitos no Funcionais: so restries sobre os servios ou as funes oferecidas

pelo sistema (tempo,padro, etc).

Requisitos de Domnio: originam-se no domnio de aplicao do sistema e refletem

caractersticas desse domnio. Podem ser funcionais ouno funcionais.

7

Requisitos No Funcionais (Sommerville) Requisitos de Produto: especificam ou restringem o

comportamento do software. Ex: desempenho, memria requerida, taxa de falha, proteo e

usabilidade.

Requisitos Organizacionais: so derivados das polticas eprocedimentos da organizao do cliente e dodesenvolvedor.

Ex: requisitos dos processos operacionais (uso do sistema),requisitos do processo de desenvolvimento (escolha da linguagemde programao) e requisitos ambientais (ambiente operacional dosistema).

Requisitos Externos: derivam de fatores externos ao sistemae seu processo de desenvolvimento:

Ex: requisitos reguladores, requisitos legais e requisitos ticos.

8

Requisitos No Funcionais (Sommerville)

9

Requisitos Volteis (Sommerville) Classificao dos Requisitos volteis:

Requisitos mutveis: se modificam devido a mudanasdo ambiente no qual a organizao est operando.

Requisitos emergentes: surgem medida que acompreenso do cliente do sistema se desenvolvedurante o desenvolvimento do sistema.

Requisitos conseqentes: Requisitos que resultam daintroduo do sistema de computao.

Requisitos de compatibilidade: Requisitos que dependemde sistemas ou processos de negcios especficosdentro da organizao.

10

Modelagem de Requisitos FuncionaisO Modelo de Casos de Uso uma

representao das funcionalidadesexternamente observveis do sistema e doselementos externos ao sistema que interagemcom ele.

Este modelo parte integrante da especificaode requisitos. Na verdade, o modelo de casosde uso molda os requisitos funcionais dosistema.

O diagrama da UML utilizado na modelagem decasos de uso o diagrama de casos de uso.

Composto de Casos de Uso, de Atores e de11

Modelo de Casos de Uso

12

Modelagem de Casos de UsoUm meio de capturar o comportamento desejado

para o sistema em desenvolvimento.Um meio de comunicar o comportamento do

sistema. Identificar quem ou o que interage com o

sistema e o que o sistema deve fazer.Uma forma de se verificar se todos os requisitos

foram capturados.Um instrumento de Planejamento.

13

Diagrama de Casos de UsoUm caso de uso representa quem faz o que

(interage) com o sistema, sem considerar ocomportamento interno do sistema.

Casos de Uso descrevem o sistema, seuambiente e os relacionamentos entre o sistemae seu ambiente.

Casos de Uso capturam os comportamentos dosistema: Um comportamento de sistema como o sistema age e

reage, uma atividade visvel e testvel do sistema.

14

Estudante se conecta no sistema

Sistema aprova conexo

Estudante solicita Informaes sobre curso

Sistema transmite solicitao

Catlogo de Cursos retorna informao de curso

Sistema exibe lista de Cursos

Estudante seleciona Cursos

Sistema confirma disponibilidade de Cursos

Sistema exibe agenda aprovada

Estudante Sistema de Catlogo de Cursos

Matricular em Cursos

Diagrama de Casos de Uso

15

Especificao de Caso de Uso.

16

Cenrio

Geralmente um caso de uso tem diversas maneiras de ser realizado. Umcenrio a descrio de uma das maneiras pelas quais um caso de uso

pode ser realizado. Um cenrio tambm chamado de instncia de um

caso de uso. Normalmente h diversos cenrios para um mesmo caso de

uso.

17

Exemplo de Cenrios Um cliente pretende fazer uma retirada em um Banco 24 hs:

Cenrio 1:

O cliente digita sua senha corretamente;

O cliente solicita a retirada de um valor menor que o saldo de sua conta.

A mquina tem notas suficientes.

Cenrio 2:

O cliente digita sua senha corretamente;

O cliente solicita a retirada de um valor menor que o saldo de sua conta.

A mquina no tem notas suficientes.

Cenrio 3:

O cliente digita sua senha corretamente;

O cliente solicita a retirada de um valor maior que o saldo de sua conta.

A mquina tem notas suficientes.18

Cenrios

Podem ser utilizados na fase de testes dos sistemas.

Facilita o entendimento dos casos de uso.

Levanta os detalhes dos casos de uso.

Se o cliente digitar uma senha invlida?

Se o cliente solicitar um valor maior que seu saldo?

Se o cliente solicitar um valor menor que seu saldo, mas a mquina no possuir notassuficiente?

19

Diagrama de Casos de Uso

Um ator representa qualquercoisa que interage com o sistema.

Um modelo de caso de uso defineum conjunto de casos de uso,onde cada caso de uso umaseqncia de aes que umsistema executa que produz umresultado observvel de valor paraum ator em particular.

Caso de Uso

Ator

20

Ator

Um ator representa um papel que um ser humano, dispositivo dehardware ou outro sistema pode desempenhar.

Ator(stick man)

21

Um usurio pode ter diferentes papis

Charles

Charles comoEstudante Estudante

Charles comoProfessor

Professor

Nomes de atores devem claramente denotar o papel do ator.

22

Nomeando Casos de Uso O nome indica o que alcanado por suas interaes com o ator.

O nome pode ter vrias palavras.

Dois casos de uso no podem ter o mesmo nome.

Matricular em Disciplina LoginManter Informaes de Alunos

23

Fluxo de Eventos de Casos de Uso

Possui um fluxo normal, fluxo bsico.

Vrios fluxos alternativos:

Variantes regulares do fluxo bsico.

Caso esdrxulos.

Fluxos excepcionais tratando situaes de erro.

24

Relacionamentos

Comunicao (associao).

Incluso.

Extenso.

Generalizao.

25

Relacionamento: Comunicao Representa a informao de quais atores esto associados a que casos de

uso.

O fato de um ator estar associado a um caso de uso significa que esse atorinterage (troca informaes) com o sistema.

Um ator pode se relacionar com vrios casos de uso.

Estudante Sistema de Catlogo de Cursos

Matricular em Cursos

26

Relacionamento: Incluso Existe somente entre casos de uso.

Indica que um caso de uso ter seu procedimento copiado num localespecificado em outro caso de uso, identificado como base.

Ex: o caso de uso Validar Correntista em uma aplicao bancria pode serincludo em outros casos de uso: Obter Extrato, Realizar Saque, Realizar

Depsito, etc.

27

Diagrama de Casos de Uso: Incluso

Cliente

Obter Extrato

Realizar Saque

Realizar Depsito

Validar Correntista

Incluso

28

Relacionamento: Extenso

Existe somente entre casos de uso.

Utilizado para modelar situaes em que diferentes sequencias deinteraes podem ser inseridas em um caso de uso, chamado caso de uso

estendido.

Cada uma dessas diferentes sequencias representa um comportamento ques ocorre sob certas condies, ou cuja realizao depende de escolha de

um ator.

29

Diagrama de Casos de Uso: Extenso

Escritor

Substituir Texto

Editar Documento

Corrigir Ortografia

Extenso

30

Diagrama de Casos de Uso

Cliente

Mostrar Mapa do Salo

Reserva de

Restaurante

CadastrarCliente

Extenso e Incluso

31

Relacionamento: Generalizao

Existe entre casos de uso e atores.

Este relacionamento permite que um caso de uso (ou ator) herdecaractersticas de um outro caso (ator) de uso mais genrico,este

ltimo normalmente chamado de casos de uso (ator) base.

32

Diagrama de Casos de Uso: Generalizao

Aluno

Reservar Livro

Solicitar Compra de Ttulo

Devolver Livro

Herana

Professor

RealizarPagamento

Cliente

RealizarPagamento com Carto de Crdito

RealizarPagamentocom Cheque

33

Relacionamentos

Use incluso: quando o mesmo comportamento se repete em mais de um caso de uso.

Use extenso: quando um comportamento opcional de um caso de uso tiver de ser descrito.

Use herana: entre atores quando precisar definir um ator que possui o comportamento de umator preexistente, mas que possui comportamento particular.

Use herana: entre casos de uso quando identificar dois casos de uso com comportamentossemelhantes e um deles for uma forma especial do outro.

34

Diagrama de Casos de Uso

Corresponde a uma viso externa do sistema e representa graficamente osatores, casos de uso e relacionamentos entre esses elementos.

O diagrama de casos de uso tem o objetivo de ilustrar em um nvel alto deabstrao quais elementos externos interagem com as funcionalidades do

sistema.

35

Caso de Uso Concreto Um caso de uso concreto iniciado por um ator e constitui um fluxo

completo de eventos. "Completo" significa que uma instncia do casode uso executa a operao inteira chamada pelo ator.

Cliente

Realizar Saque

36

Caso de Uso Abstrato Um caso de uso abstrato propriamente nunca instanciado. Os casos de uso abstratos so

includos em, se estendem para ou generalizam outros casos de uso.

Quando um caso de uso concreto iniciado, uma instncia do caso de uso criada. Essainstncia tambm exibe o comportamento especificado por seus casos de uso abstratosassociados. Portanto, nenhuma instncia separada criada de casos de uso abstratos.

A distino entre os dois importante porque so os casos de uso concretos que os atores"vero" e iniciaro no sistema.

Um caso de uso abstrato tem seu nome escrito em itlico.

Cliente

Realizar Saque Validar Correntista

37

Modelo de Casos de Uso

Um modelo que descreve os requisitos funcionais de um sistema em termos de casos de uso.

Um modelo das funcionalidades desejadas do sistema (casos de uso) e seu ambiente (atores).

Especificao do Caso de Uso 2

Ator Caso de Uso 2

Sistema

Caso de Uso 3

Caso de Uso 1

Fronteirado

Sistema

38

Modelo de Casos de Uso

Modelo Investigativo de Casos de Uso:- Descrio da investigao - Lista de todos os atores- Lista de todos os casos de uso

Especificao.Caso de Uso 2- Breve descrio- Fluxo de eventos

Especificao. Caso de Uso 3- Breve descrio- Fluxo de eventos

Ator 1

Caso de Uso 2

Caso de Uso 3

Caso de Uso 1

Ator 2

Ator 3

Especificao Caso de Uso 1- Breve descrio - Fluxo de eventos

Sistema

39

Modelo de Casos de Uso

EspecificaesSuplementares

Glossrio

Especificaes de Casos de uso

...

Modelo de Casos de Uso

Atores

Casos de Uso

Listados

Requisitos

Regras do

Negcio

40

Pacotes Casos de uso semanticamente relacionados podem ser agrupados em Pacotes.

Objetivos:

Estruturar o modelo de casos de uso de uma maneira que reflita os tipos de usurios do sistema.

Definir a ordem que os casos de uso sero desenvolvidos.

Definir o grau de correlao entre os casos de uso

Pacote

41

Pacotes

Diagrama de Pacotes

Pedidos Entregas

Estoque

SecretariaSecretaria

ControleAcadmico

ControleAcadmic

o

Cadastrar Aluno

Matricular Aluno

Emitir Histrico

42

Benefcios dos Casos de Uso D contexto aos Requisitos.

So fceis de entender.

Facilitam o acordo com clientes.

Ilustram porque o sistema necessrio:

Casos de Uso: porque o sistema usado.

Atores: quem/o que deseja interagir com o sistema.

43

Utilizados para comunicar com os usurios e experts de domnio:

Provem uma viso do produto que vai ser desenvolvido numa fase precoce dodesenvolvimento.

Assegura um entendimento mtuo dos requisitos.

Utilizado para identificar:

Quem interage com o sistema e o que o sistema deve fazer.

As interfaces que o sistema deve possuir.

Utilizado para verificar:

Se todos os requisitos foram capturados.

Se a equipe de desenvolvimento entende os requisitos.

Benefcios dos Casos de Uso

44

Decomposio Funcional a diviso de um problema em pequenas partes isoladas.

As partes:

Trabalham juntas para prover a funcionalidade do sistema.

Frequentemente no fazem sentido isoladas.

Casos de Uso:

No so decomposio funcional.

Mantm agrupada uma funcionalidade para descrever um uso completo do sistema.

Fornecem um contexto.

45

Decomposio Funcional

Sintomas: Casos de uso muito pequenos.

Muitos casos de uso.

Casos de uso sem resultado ou valor.

Operaes de baixo nvel como nome:

Operao + objeto

Funo + dado

Exemplo: Insira Carto

Dificuldades no entendimento geral do

modelo.

Aes Corretivas: Procure por um contexto maior:

Por que voc est construindo este sistema?

Ponha-se no papel de um ator

O qu o ator deseja obter?

Objetivo de quem este caso de uso vai satisfazer?

Que valor este caso de uso adiciona?

Qual a histria por trs deste caso de uso?

46

Engenharia de RequisitosSommerville

47

Engenharia de RequisitosConsiste de um processo que envolve todas as

atividades exigidas para criar e manter odocumento de requisitos de sistema, compostapelas atividades: Estudo da viabilidade do sistema.

Elicitao e anlise de requisitos.

Especificao de Requisitos.

Validao de requisitos.

48

Processo de Engenharia de Requisitos

49

Modelo em espiral dos processos de engenharia de requisitos

50

Estudo de Viabilidade A entrada para o estudo de viabilidade uma descrio

geral do sistema e de como ele ser utilizado dentro de umaorganizao.

Os resultados devem ser um relatrio que recomenda sevale a pena ou no realizar o processo de engenharia derequisitos e o processo de desenvolvimento do sistema.

Deve responder as seguintes perguntas: O sistema contribui para os objetivos gerais da organizao?

O sistema pode ser implementado com a utilizao de tecnologia atualdentro das restries de custo e de prazo?

O sistema pode ser integrado com outros sistemas j em operao?

51

Levantamento e Anlise de RequisitosNessa atividade, os engenheiros de software

trabalham com os clientes e os usurios finaisdo sistema para aprender sobre o domnio daaplicao, quais servios o sistema devefornecer, o desempenho esperado do sistema,restries de hardware etc.

52

Levantamento e Anlise de Requisitos A elicitao e a compreenso dos requisitos dos

stakeholders so difceis devido a vrias razes:I. Os stakeholders frequentemente no sabem o que querem do sistema de

computador a no ser em termos gerais. Eles podem achar difcil articular o quedesejam que o sistema faa ou fazem pedidos no realistas.

2. Os stakeholders expressam os requisitos naturalmente em seus prprios termose com o conhecimento implcito de seu trabalho. Os engenheiros de requisitos,sem experincia no domnio do cliente, devem entender esses requisitos.

3. Diferentes stakeholders possuem diferentes requisitos, expressos de diferentesformas. Os engenheiros de requisitos precisam considerar todas as fontespotenciais de requisitos e descobrir pontos em comum e conflitos.

4. Fatores polticos podem influenciar os requisitos do sistema. Os gerentes podemsolicitar requisitos especficos que aumentaro sua influncia na organizao.

5. O ambiente econmico e de negcios sobre o qual a anlise realizada dinmico. Ele muda inevitavelmente durante o processo de anlise. Portanto, aimportncia de determinado requisito pode mudar. Novos requisitos podem surgirde novos stakeholders que no haviam sido consultados anteriormente.

53

Levantamento e Anlise de Requisitos

As atividades de processo so:I. Obteno de requisitos: o processo de interao com os stakeholders

no sistema para coletar seus requisitos. Os requisitos de domnio sotambm descobertos durante essa atividade, provenientes dosstakeholders e da documentao.

2. Classificao e organizao de requisitos: esta atividade envolve acoleo de requisitos no estruturados, agrupa os requisitosrelacionados e os organiza em conjuntos coerentes.

3. Priorizao e negociao de requisitos: quando vrios stakeholdersparticipam do processo, os requisitos sero conflitantes. Esta atividadeest relacionada priorizao de requisitos, procura e resoluo deconflitos de requisitos por meio da negociao.

4. Documentao de requisitos: os requisitos so documentados ecolocados na prxima volta da espiral. Podem ser produzidosdocumentos de requisitos formais ou informais.

54

Levantamento e Anlise de Requisitos

55

Levantamento e Anlise de Requisitos Tcnicas (Sommerville): Entrevistas. Levantamento Orientado a Ponto de Vista. Etnografia. Cenrios. Casos de Uso.

Outras: Leitura de documentos. Questionrios. Anlise de protocolos. Participao ativa dos usurios (Workshop). Reuso de requisitos. Prototipagem.

56

Entrevistas Entrevistas formais ou informais com os stakeholders no

sistema fazem parte da maioria os processos de engenhariade requisitos. Nessas entrevistas, a equipe de engenharia derequisitos formula questes para os stakeholders sobre osistema que eles usam e o sistema a ser desenvolvido. Osrequisitos so derivados das respostas a essas questes. Asentrevistas podem ser de dois tipos:

1. Entrevistas fechadas, nas quais o stakeholder responde a umconjunto de perguntas predefinidas.

2. Entrevistas abertas, nas quais no existe um roteiro predefinido. Aequipe de engenharia de requisitos explora vrios assuntos com osstakeholders no sistema e, assim, desenvolve uma compreensomaior de suas necessidades.

57

Entrevistas Na prtica, as entrevistas com os stakeholders so,

geralmente, uma combinao desses tipos(fechadas e abertas).

difcil elicitar o conhecimento de domnio duranteas entrevistas por dois motivos: os especialistas dedomnio usam terminologia e jarges especficos ealguns conhecimentos de domnio so to familiaresque so considerados difceis de explicar ouconsiderados to fundamentais que no vale a penamencion-los.

58

Levantamento Orientado a Pontos de Vista:

em um sistema existem vrios pontos de vista que precisam ser considerados.

Estgios:

Pontos de Vista

Identificao de Ponto de Vista

Estruturao de Ponto de Vista

Mapeamento de Sistema conforme Ponto de Vista

Documentao de Ponto de Vista

59

Etnografia:

tcnica de observao utilizada para compreender os requisitos organizacionais e sociais. Otrabalho dirio observado e so anotadas as tarefas reais em que os participantes esto

envolvidos. O valor da etnografia est na descoberta requisitos implcitos, que refletem os

processos reais.

Etnografia

60

Cenrios: A obteno de requisitos com base em cenrios pode ser realizadas informalmente, ou de forma um pouco

mais estruturada, com o uso de casos de uso.

De maneira geral, um cenrio deve incluir:l. Uma descrio do que os usurios esperam do sistema no incio do cenrio.

2. Uma descrio do fluxo normal de eventos no cenrio.

3. Uma descrio do que pode dar errado e como isso tratado.

4. Informaes sobre outras atividades que podem ocorrer simultaneamente.

5. Uma descrio do estado de sistema no fim do cenrio.

Cenrios

61

Os casos de uso constituem uma tcnica baseada em cenrios para elicitao derequisitos e foram introduzidos inicialmente no mtodo Objectory (Jacobsen, et

aI., 1993).

Eles se tomaram uma caracterstica fundamental da notao UML para descriode modelos de sistema orientado a objetos.

Em sua forma mais simples, um caso de uso identifica o tipo da interao e osagentes envolvidos.

Casos de Uso

62

Validao de Requisitos A validao de requisitos se ocupa de mostrar que os requisitos realmente

definem o sistema que o cliente deseja.

Enquanto a anlise trabalha com requisitos incompletos, a validaoelabora um esboo completo do documento de requisitos.

Tcnicas de validao de requisitos: Revises de requisitos.

Prototipao.

Gerao de casos de teste.

Anlise automatizada de consistncia (linguagem formal).

63

Validao de Requisitos Durante o processo de validao de requisitos, devem ser realizadas verificaes nos requisitos do documento de

requisitos:

1. Verificaes de validade: mais estudos e anlises podem identificar que funes adicionais e diferentes so

necessrias.

2. Verificaes de consistncia: os requisitos em um documento no devem ser conflitantes.

3. Verificaes de completeza: o documento de requisitos deve incluir requisitos que definam todas as funes e as

restries desejadas pelo usurio do sistema.

4. Verificaes de realismo: usando o conhecimento da tecnologia existente, os requisitos devem ser verificados

quanto a se realmente podem ser implementados.

5. Facilidade de verificao: deve ser possvel descrever um conjunto de testes que possa demonstrar que o sistema

entregue atende a cada requisito especificado.

64

Revises de Requisitos Em uma reviso formal de requisitos, a equipe de desenvolvimento deve 'conduzir' o cliente

pelos requisitos de sistema, explicando as implicaes de cada requisito. A equipe de reviso

deve verificar cada requisito em termos de consistncia, bem como verificar os requisitos

como um todo em termos de completeza. Os revisores podem tambm verificar:

1. Facilidade de verificao: o requisito, conforme estabelecido, testvel de forma realstica?

2. Facilidade de compreenso: os adquirentes e os usurios finais do sistema compreendem o requisito de forma apropriada?

3. Rastreabilidade: a origem do requisito est estabelecida claramente? Talvez seja necessrio retomar fonte do requisitopara avaliar o impacto de uma mudana.

4. Adaptabilidade. O requisito adaptvel? Isto , o requisito pode ser mudado sem efeitos em grande escala sobre os outrosrequisitos de sistema?

65

Revises de Requisitos Conflitos, contradies, erros e omisses nos requisitos devem ser apontados

pelos revisores e registrados formalmente no relatrio de reviso.

, portanto, de responsabilidade dos usurios, do adquirente de sistema e dodesenvolvedor de sistema negociar uma soluo para esses problemas

identificados.

66

Engenharia de RequisitosPressman

67

Engenharia de Requisitos Tem por objetivo ajudar os engenheiros de software a

compreender melhor o problema que eles vo trabalhar pararesolver.

Inclui um conjunto de tarefas que levam a um entendimentode qual ser o impacto do software sobre o negcio, do que ocliente quer e de como os usurios finais vo interagir com osoftware.

Como todas as outras atividades de engenharia de software,precisa ser adaptada s necessidades do processo desoftware.

uma ao de engenharia de software que comea durante aatividade de comunicao e continua durante a atividade demodelagem.

68

Engenharia de Requisitos Tarefas: Concepo;

Levantamento;

Elaborao;

Negociao;

Especificao;

Validao.

Gesto.

69

Engenharia de RequisitosConcepo: A maioria dos projetos comea quando uma

necessidade do negcio identificada ou ummercado ou um servio potencialmente novo descoberto.

Os engenheiros de software perguntam uma sriede questes livres de contexto. A inteno estabelecer um entendimento bsico do problema,o pessoal que quer uma soluo, a natureza dasoluo desejada e a efetividade da comunicao ecolaborao preliminares entre clientes edesenvolvedor.

70

Engenharia de Requisitos Levantamento: Ajuda o cliente a definir o que necessrio.

Problemas: problemas de escopo: limite mal definido;

problemas de entendimento: pleno entendimento dodomnio do problema;

problemas de requisitos: volatilidade.

71

Engenharia de Requisitos

Elaborao: As informaes obtidas do cliente durante a concepo e o

levantamento so expandidas e refinadas.

Enfoca o desenvolvimento de um modelo tcnico refinadodas funes, caractersticas e restries do software.

Consiste de uma ao de modelagem de anlise.

guiada pela criao e refinamento de cenrios dousurio.

O resultado final um modelo de anlise que define odomnio do problema informacional, funcional ecomportamental.

72

Engenharia de RequisitosNegociao: Tem por objetivo reconciliar conflitos ocasionados

por clientes e usurios, por intermdio de umprocesso de negociao.

Especificao: Pode ser um documento escrito, um modelo

grfico, um modelo matemtico formal, umacoleo de cenrios de uso, um prottipo, ouqualquer combinao desses elementos.

o produto de trabalho final produzido peloengenheiro de requisitos.

73

Engenharia de RequisitosValidao: Os produtos de trabalho resultantes da engenharia

de requisitos so avaliados quanto qualidade.

Gesto: A gesto de requisitos comea com a identificao.

A cada requisito atribudo um identificador. Umavez identificados os requisitos, tabelas derastreamento so desenvolvidas, cada tabela derastreamento relaciona os requisitos identificados aum ou mais aspactos do sistema ou de seuambiente.

74

Incio do Processo de Engenharia de Requisitos Identificao dos interessados.Reconhecimento dos diversos pontos de vista. Trabalho em busca da colaborao. Formulao das primeiras perguntas.

75

Levantamento de Requisitos Coleta colaborativa de requisitos; Cenrios de Uso; Implantao da Funo de Qualidade (IFQ): traduz as necessidades do cliente para requisitos tcnicos do

software. concentra-se em maximizar a satisfao do cliente a partir do

processo de engenharia de software. identifica trs tipos de requisitos: normais: refletem os objetivos e metas estabelecidos para um

sistema durante as reunies com o cliente; esperados: esto implcitos no produto, o cliente no se refere; excitantes: refletem as caractersticas que vo alm das

expectativas do cliente.

76

Gerenciamento de Requisitos

Sommerville

77

Gerenciamento de Requisitos Os requisitos de sistemas de software de grande porte esto

sempre mudando. O problema no pode ser totalmente definido, os requisitos

de software tendem a ser incompletos. Durante o processo de software, o entendimento dos

stakeholders sobre o problema muda constantemente. Esses requisitos devem ento evoluir para refletir essas

novas vises do problema. Depois que o sistema estiver instalado, inevitavelmente

surgiro novos requisitos. difcil para os usurios e os clientes do sistema

anteciparem quais efeitos o novo sistema causar naorganizao.

78

Gerenciamento de Requisitos Quando os usurios adquirirem experincia com o sistema,

novas necessidades e prioridades surgem:I. Sistemas de grande porte geralmente tm uma comunidade diversificada

de usurios. Os requisitos finais do sistema constituem inevitavelmenteum compromisso entre eles e, com a experincia, descobre-sefrequentemente que o equilbrio de apoio dado aos diferentes usuriostem de ser mudado.

2. As pessoas que pagam por um sistema e os usurios de um sistemararamente so as mesmas pessoas. Os clientes do sistema impemrequisitos devido a restries organizacionais e de oramento. Essasrestries podem ser conflitantes com os requisitos dos usurios finais e,aps a entrega, novas caractersticas podem ser includas para apoio dousurio, fazendo com que o sistema alcance suas metas.

3. O ambiente de negcios e tcnico do sistema muda aps a instalao, eessas mudanas devem se refletir no sistema.

79

Gerenciamento de Requisitos O gerenciamento de requisitos um processo para

compreender e controlar as mudanas dos requisitos desistema.

preciso manter o acompanhamento dos requisitosindividuais e manter as ligaes entre os requisitosdependentes, de modo que seja possvel avaliar o impactodas mudanas de requisitos.

preciso estabelecer um processo formal para fazerpropostas de mudana e lig-las aos requisitos de sistema.

O processo de gerenciamento de requisitos deve se iniciarassim que uma verso inicial do documento de requisitosesteja disponvel, mas deve-se iniciar o planejamento dasmudanas de requisitos durante o processo de elicitao derequisitos.

80

Gerenciamento de Requisitos (RUP)O gerenciamento de requisitos um modelo

sistemtico para encontrar, documentar,organizar e rastrear os requisitos variveis deum sistema.

Um requisito uma condio ou umacapacidade com a qual o sistema deve estarde acordo.

81

Planejamento do Gerenciamento de Requisitos o primeiro estgio essencial no processo

de gerenciamento de requisitos.O gerenciamento de requisitos muito

dispendioso.Para cada projeto, o estgio de planejamento

estabelece o nvel de detalhamentonecessrio para o gerenciamento derequisitos.

82

Planejamento do Gerenciamento de Requisitos Durante o estgio de gerenciamento de requisitos, deve-se

decidir sobre: 1. Identificao de requisitos. Cada requisito deve ser identificado

unicamente de modo que possa ser feita a referncia cruzada entre estee outros requisitos para que ele possa ser usado nas avaliaes derastreabilidade.

2. Processo de gerenciamento de mudanas. o conjunto de atividadesque avaliam o impacto e custo das mudanas.

3. Polticas de rastreabilidade. Essas polticas definem osrelacionamentos entre os requisitos e entre os requisitos e o projeto dosistema, que devem ser registrados, e como esses registros devem sermantidos.

4. Apoio de ferramentas CASE. O gerenciamento de requisitos envolve oprocessamento de grandes quantidades de informaes sobre osrequisitos. As ferramentas que podem ser usadas variam desde sistemasespecializados de gerenciamento de requisitos a planilhas e sistemassimples de banco de dados. 83

Planejamento do Gerenciamento de Requisitos O gerenciamento de requisitos precisa de apoio

automatizado; as ferramentas CASE para essa finalidadedevem ser selecionadas durante a fase de planejamento. Oapoio de ferramentas necessrio para:

I. Armazenamento de requisitos. Os requisitos devem ser mantidos emum repositrio de dados seguro e gerenciado acessvel a todos osenvolvidos no processo de engenharia de requisitos.

2. Gerenciamento de mudanas. O processo de gerenciamento demudanas simplificado se um apoio ativo de ferramentas estiverdisponvel.

3. Gerenciamento de rastreabilidade. O apoio de ferramentas pararastreabilidade permite que requisitos relacionados sejam obtidos.Algumas ferramentas usam tcnicas de processamento de linguagemnatural para auxiliar na descoberta de possveis relacionamentos entreos requisitos.

84

Gerenciamento de Mudanas de Requisitos Aps a aprovao do documento de

requisitos o gerenciamento de mudanas derequisitos deve ser aplicado a todas asmudanas propostas aos requisitos.

A vantagem de usar um processo formal paragerenciamento de mudanas que todas aspropostas de mudana so tratadasconsistentemente, e as mudanas nodocumento de requisitos so feitas demaneira controlada.

85

Gerenciamento de Mudanas de Requisitos Existem trs principais estgios para um processo

de gerenciamento de mudanas:1. Anlise do problema e especificao da mudana. O

processo se inicia com um problema de requisitosidentificado ou, s vezes, com uma proposta de mudanaespecfica. Durante esse estgio, o problema ou a propostade mudana analisada para verificar se vlida.

2. Anlise da mudana e estimativa de custo. O efeito damudana proposta avaliado usando as informaes derastreabilidade e o conhecimento geral sobre os requisitosdo sistema.

3. Implementao da mudana. O documento de requisitos e,quando necessrio, o projeto e a implementao de sistemaso modificados. 86

Gerenciamento de Mudanas de Requisitos Se uma mudana de requisitos do sistema

solicitada com urgncia, existe sempre umapropenso a realizar a mudana no sistema e,depois, retrospectivamente, modificar o documentode requisitos.

Isso leva quase inevitavelmente defasagem entreo documento de requisitos e a implementao dosistema.

Uma vez feitas as mudanas no sistema, asmudanas no documento de requisitos podem seresquecidas ou realizadas de maneira noconsistente com as mudanas no sistema.

87

Fim

Professor Marcio Victorino 88