Post on 19-Nov-2015
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