Post on 18-Sep-2015
description
Engenharia de Requisitos
Professor: Msc. Alexandre Rafael Lenz
1. Apresentao do Professor 2. Apresentao da Disciplina
Ementa Objetivo Bibliografia
3. Introduo Engenharia de Requisitos Requisitos Tipos de Requisitos Nveis de Requisitos
2
Agenda
4. Processo de Engenharia de Requisitos Viso Geral do Processo de Engenharia de Requisitos Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Qualidade dos Requisitos Atributos dos Requisitos Organizao dos Requisitos
Anlise de Requisitos UML Modelo Entidades e Relacionamentos
Documentao de Requisitos O Documento de Definio de Requisitos O Documento de Especificao de Requisitos
Verificao e Validao de Requisitos Gerncia de Requisitos
Mudanas de Requisitos Matriz de Rastreabilidade
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software CMMI MPS.BR
1. Apresentao do Professor
4
- DOUTORANDO EM CINCIA DA COMPUTAO Universidade Federal da Bahia, UFBA, Salvador, Brasil Ttulo: Uma Abordagem para Gerao de Contedos Complementares num Cenrio de Convergncia Digital Orientador: Celso Alberto Saibel Santos - MESTRADO EM INFORMTICA. Universidade Federal do Paran, UFPR, Brasil. Ttulo: Utilizando tcnicas de aprendizado de mquina para apoio ao teste de regresso, Ano de Obteno: 2009. Orientadora: Slvia Regina Vergilio.
- GRADUAO - BACHARELADO EM CINCIA DA COMPUTAO. Universidade Luterana do Brasil, ULBRA. Ttulo: Processo de Teste de Software Customizvel baseado em Modelos e Normas de Qualidade. Ano de Obteno: 2007. Orientador: Luis Fernando Fortes Garcia.
Apresentao do Professor
5
Apresentao do Professor
- PROFESSOR 4 ANOS DE EXPERINCIA - REA 1 - UNIJORGE - UNIME - UNEB Funcionrio Pblico, D.E., Concursado desde
2012 - Engenharia de Software - Gerncia de Projetos - Sistemas de Informao - Sistemas Multimdia - Interface Humano-Computador - Algoritmos
6
Apresentao do Professor
Mais de 7 anos de experincia profissional na rea de T.I.,
Atuando em multinacionais como HP, LG, Nokia, Siemens e
Bunge.
Palestrante nos Simpsios da Sociedade Brasileira de
Engenharia de Televiso (SET) em Belo Horizonte, Braslia,
Recife e Manaus.
Gerente de Projetos no Centro Internacional de Tecnologia
de Software, gerenciando os Laboratrios de Teste de Tv
Digital da LG Electronics em Porto Alegre, Curitiba, So Paulo,
Belo Horizonte, Salvador e Fortaleza.
7
Apresentao do Professor
Nome em citaes bibliogrficas: LENZ, A. R.;
Lenz, A. R.
reas de atuao: Engenharia de Software, Teste
de Software, Televiso Digital e Convergncia
Digital.
2. Apresentao da Disciplina
9
Apresentao da Disciplina
Engenharia de Requisitos: A engenharia de requisitos estabelece uma base slida para o projeto e para a construo. Sem ela, o software resultante tem grande probabilidade de no atender s necessidades do cliente.
10
Apresentao da Disciplina
EMENTA Introduo Engenharia de Requisitos Tipos de requisitos. O processo da Engenharia de Requisitos. Tcnicas de Levantamento de Requisitos. Anlise de Requisitos e Modelagem Conceitual. Mtodos e tcnicas para a modelagem de sistemas. Documentao de requisitos. Verificao e validao de requisitos. Gerncia de requisitos. Engenharia de Requisitos e Normas e Modelos de
Qualidade
11
Apresentao da Disciplina
BIBLIOGRAFIA BSICA Ian Sommerville. Engenharia de Software, 9 Edio. Pearson Education, 2011. Roger S. Pressman. Engenharia de Software - Uma Abordagem Profissional, 7 Edio, Bookman, 2011. BIBLIOGRAFIA COMPLEMENTAR Falbo, R.A., Engenharia de Requisitos de Software Notas de Aula, UFES, 2012.
Objetivo Geral: Estudar as caractersticas, abordagens e mtodos aplicveis ao processo de Engenharia de Requisitos, procurando capacitar os alunos a levantar, analisar, modelar conceitualmente, documentar, avaliar e gerenciar requisitos de sistemas de software.
Objetivos Especficos:
Estudar os principais aspectos a serem considerados na definio de requisitos de sistemas de software;
Capacitar o aluno a aplicar tcnicas de levantamento de requisitos e modelagem conceitual 12
Apresentao da Disciplina
3. Introduo
14
Mapa dos requisitos
[PRESSMAN, 2011]
Problema Clssico
15
Soluo: Comunicao
16 Cliente Engenheiro de
Requisitos
Um processo de software envolve diversas atividades que podem ser classificadas quanto ao seu propsito em:
Atividades de Desenvolvimento (ou Tcnicas) so as atividades diretamente relacionadas ao processo de desenvolvimento
do software (levantamento e anlise de requisitos, projeto, implementao)
Atividades de Gerncia envolvem atividades relacionadas ao gerenciamento do projeto de maneira
abrangente (gerncia de projetos, gerncia de configurao, reuso, etc.).
Atividades de Controle da Qualidade so aquelas relacionadas com a avaliao da qualidade do produto ou do
processo (verificao, validao, garantia da qualidade).
Processo de Software: Classificao de Atividades
17
Processo de Software: Classificao de Atividades
18
Processo de Software: Classificao de Atividades
19
Atividades de Desenvolvimento:
1 Atividade de Desenvolvimento Levantamento de Requisitos:
quando os requisitos do sistema a ser desenvolvido so preliminarmente capturados e organizados.
em seguida os requisitos devem ser modelados, avaliados e documentados.
Modelagem Conceitual: elaborao de modelos descrevendo o qu o software tem de fazer (e no como faz-lo).
Processo de Software: Classificao de Atividades
20
Note que muitas solues so possveis para o mesmo conjunto de requisitos
So ligadas uma dada plataforma de implementao
linguagem de programao, mecanismo de persistncia a ser adotado, etc.
Atividade de Projeto
Tem por objetivo definir e especificar uma soluo (como faz-lo) a ser implementada.
Importncia dos Requisitos
21
Requisitos tm um papel central no desenvolvimento de software, uma vez que uma das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e requisitos para os quais foi construdo.
Requisitos so a base para: Estimativas
Modelagem
Projeto
Implementao
Testes
Manuteno
Esto presentes ao longo de todo o ciclo de vida de um software.
Atividades Relacionadas aos Requisitos
22
Nos estgios iniciais de um projeto, requisitos tm de ser levantados, entendidos e documentados.
Atividades de:
Levantamento de Requisitos
Anlise de Requisitos
Documentao de Requisitos
Atividades Relacionadas aos Requisitos
23
Dada a importncia dos requisitos para o sucesso de um projeto, atividades de controle da qualidade devem ser realizadas para verificar, validar e garantir a qualidade dos requisitos
Atividades de:
Verificao de Requisitos
Validao de Requisitos
Garantia da Qualidade de Requisitos
Os custos sero bem maiores se defeitos em requisitos forem identificados tardiamente
Atividades Relacionadas aos Requisitos
24
Mesmo quando coletados de forma sistemtica, requisitos mudam. fundamental gerenciar a evoluo dos requisitos, bem como manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto.
Atividade de:
Gerncia de Requisitos
Processo de Software: Classificao de Atividades
25
Atividades Relacionadas aos Requisitos
26
Atividades de Desenvolvimento
Levantamento de Requisitos
Anlise de Requisitos
Documentao de Requisitos
Atividades de Gerncia
Gerncia de Requisitos
Atividades de Controle da Qualidade
Verificao de Requisitos
Validao de Requisitos
Garantia da Qualidade de Requisitos
Definio de Engenharia de Requisitos
27
A Engenharia de Requisitos o processo pelo qual os requisitos de um produto de software so coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software. (AURUM; WOHLIN, 2005)
Definio de Engenharia de Requisitos
28
Engenharia de Requisitos :
O processo de (em relao aos requisitos):
A Engenharia de Requisitos de Software o ramo da Engenharia de Software que envolve as atividades relacionadas com a definio dos requisitos de software de um sistema, desenvolvidas ao longo do ciclo de vida de
software [Sommerville, 2011]
Coletar Analisar Documentar
Verificar/ Validar
Gerenciar
Definio de Requisito
29
Existem diversas definies para requisito de software na literatura, dentre elas:
Requisitos de um sistema so descries dos servios que devem ser fornecidos por esse sistema e as suas restries operacionais (SOMMERVILLE, 2011).
Um requisito de um sistema uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir seus objetivos (PFLEEGER, 2004).
Um requisito alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).
Tipos de Requisitos
30
As vrias definies apresentadas apontam para a existncia de diferentes tipos de requisitos: Requisitos Funcionais
Requisitos No Funcionais
Requisitos de Domnio (Regras de Negcio)
Tipos de Requisitos
31
Requisitos Funcionais (RFs) So declaraes de servios que o sistema deve prover,
descrevendo o que o sistema deve fazer (SOMMERVILLE, 2011).
Um requisito funcional descreve uma interao entre o sistema e o seu ambiente (PFLEEGER, 2004).
Podendo descrever, ainda, como o sistema deve reagir a entradas especficas, como o sistema deve se comportar em situaes especficas e o que o sistema no deve fazer (SOMMERVILLE, 2011).
Tipos de Requisitos
32
Requisitos Funcionais (RFs) Exemplo:
RF1 (Fidelizao do Cliente) Para que o cliente possa efetuar o pedido o mesmo deve estar previamente cadastrado no site. Para a consulta no catlogo no necessrio que o usurio esteja autenticado. Deve-se permitir que o cliente seja bloqueado caso haja alguma situao de inadimplncia no pagamento.
Tipos de Requisitos
33
Requisitos No Funcionais (RNFs) Descrevem restries sobre os servios ou funes
oferecidos pelo sistema (SOMMERVILLE, 2011), as quais limitam as opes para criar uma soluo para o problema (PFLEEGER, 2004).
Neste sentido, os requisitos no funcionais so muito importantes para a fase de projeto (design), servindo como base para a tomada de decises nessa fase.
Tipos de Requisitos
34
Requisitos No Funcionais (RNFs) Os requisitos no funcionais tm origem nas
necessidades dos usurios:
em restries de oramento
em polticas organizacionais
em necessidades de interoperabilidade com outros sistemas de software ou hardware
em fatores externos como regulamentos e legislaes
(SOMMERVILLE, 2011)
Tipos de Requisitos
35
Classificao - RNFs (SOMMERVILLE, 2011): Requisitos de produto: comportamento do produto.
confiabilidade, usabilidade, eficincia, portabilidade, manutenibilidade e segurana.
Requisitos organizacionais: so derivados de metas, polticas e procedimentos das organizaes do cliente e do desenvolvedor. Time-to-market, linguagem, custo, plataforma, etc.
Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Interoperabilidade com outros sistemas, privacidade, etc.
Tipos de Requisitos
36
Classificao RNFs ISO 25000:
Tipos de Requisitos
37
Requisitos No Funcionais (RNFs) Exemplo:
RNF1 (Desempenho) O Site deve estar preparado para atender 20 requisies simultneas com respostas de no mximo 1 segundo de atraso.
Tipos de Requisitos
38
Ainda que a classificao em requisitos funcionais e no funcionais seja a mais amplamente aceita, h outras classificaes de requisitos.
Sommerville (2011) considera, alm de requisitos funcionais e no funcionais, requisitos de domnio.
Tipos de Requisitos
39
Requisitos de domnio na concepo de Sommerville so o que outros autores, tal como Wiegers (2003), chamam de Regras de Negcio.
Exemplo: Em um sistema de matrcula de uma universidade, uma regra de negcio diz que:
RN1 (pr-requisito) Um aluno s pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus pr-requisitos.
Tipos de Requisitos
40
Regras de Negcio
1. Fatos ou invariantes: declaraes que so verdade sobre o negcio. Geralmente
descrevem associaes ou relacionamentos entre importantes termos do negcio.
Ex.: Todo pedido tem uma taxa de remessa.
2. Restries: como o prprio nome indica, restringem as aes que o sistema ou
seus usurios podem realizar.
Algumas palavras ou frases sugerem a descrio de uma restrio, tais como deve, no deve, no pode e somente.
Ex.: Um aluno s pode tomar emprestado, concomitantemente, at trs livros.
Tipos de Requisitos
41
Regras de Negcio
3. Ativadores de Aes: so regras que disparam alguma ao sob condies especficas. Uma
declarao na forma Se , ento indicada para descrever ativadores de aes.
Ex.: Se a data para retirada do livro ultrapassada e o livro no retirado, ento a reserva cancelada.
4. Inferncias: so regras que derivam novos fatos a partir de outros fatos ou
clculos. So normalmente escritas no padro se / ento, mas a clusula ento implica um fato ou nova informao e no uma ao a ser tomada.
Ex.: Se o usurio no devolve um livro dentro do prazo estabelecido, ento ele torna-se um usurio inadimplente.
Tipos de Requisitos
42
Regras de Negcio
5. Computaes:
so regras de negcio que definem clculos a serem realizados usando algoritmos ou frmulas matemticas especficos.
Podem ser expressas como frmulas matemticas, descrio textual, tabelas etc. Ex.: Multa = Valor de Locao * Nmero de Dias de Atraso.
Nveis de Descrio de Requisitos
43
Os requisitos devem ser redigidos de modo a serem passveis de entendimento pelos diversos interessados (stakeholders).
Desenvolvedores tm interesse em detalhes tcnicos.
Requisitos de Sistema
Clientes requerem descries mais abstratas.
Requisitos de Usurio
Nveis de Descrio de Requisitos
44
Requisitos de Usurio: so declaraes em linguagem natural acompanhadas de diagramas intuitivos de quais servios so esperados do sistema e das restries sob as quais ele deve operar.
Nvel de abstrao mais alto para pessoas que no possuem conhecimento tcnico.
[Sommerville, 2011]
Nveis de Descrio de Requisitos
45
Requisitos de Sistema: definem detalhadamente as funes, servios e restries do sistema. So verses expandidas dos requisitos de usurio usados pelos desenvolvedores para projetar, implementar e testar o sistema.
Especificaes em linguagem natural so insuficientes e para especific-los, notaes mais especializadas devem ser utilizadas.
[Sommerville, 2011]
Nveis de Descrio de Requisitos
46
Esses nveis de descrio de requisitos so aplicados em momentos diferentes e com propsitos distintos.
Requisitos de usurio so elaborados nos estgios iniciais do desenvolvimento. Usados como base para a contratao e o planejamento do projeto
Requisitos de sistema so elaborados como parte dos esforos diretos para o desenvolvimento do sistema Capturam detalhes importantes para as fases tcnicas
Documentos de Requisitos
Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados:
Documento de Definio de Requisitos: deve ser escrito de maneira que o cliente possa entender. Usa uma listagem do qu o cliente espera que o sistema proposto faa. Representa um consenso entre o cliente e o desenvolvedor sobre o qu o cliente quer. Resultado do Levantamento de Requisitos
Documento de Especificao de Requisitos: redefine os requisitos de usurio em termos mais tcnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de requisitos. Resultado da Anlise de Requisitos 47
2. Processo de
Engenharia de Requisitos
Viso Geral do Processo de Engenharia de Requisitos
A Engenharia de Requisitos pode ser descrita como um processo:
Um conjunto organizado de atividades que deve ser seguido para derivar, avaliar e manter os requisitos e artefatos relacionados.
Deve incluir: A estrutura ou sequncia dessas atividades
Quem responsvel por cada atividade
Suas entradas e sadas
As ferramentas usadas para apoiar as atividades
Os mtodos, tcnicas e diretrizes a serem seguidos na sua realizao. 49
Viso Geral do Processo de Engenharia de Requisitos
Processos de engenharia de requisitos podem variar muito de uma organizao para outra.
A definio de um processo apropriado organizao traz muitos benefcios.
Deve atender s necessidades da organizao, ou at mesmo de um projeto especfico.
No faz sentido falar em processo ideal ou definir algum e imp-lo a uma organizao.
50
Viso Geral do Processo de Engenharia de Requisitos
Wiegers (2003) destaca alguns benefcios que um processo de Engenharia de Requisitos de alta qualidade pode trazer: menor quantidade de defeitos nos requisitos,
reduo de retrabalho,
desenvolvimento de menos caractersticas desnecessrias,
diminuio de custos,
desenvolvimento mais rpido,
menos problemas de comunicao,
alteraes de escopo reduzidas,
estimativas mais confiveis,
maior satisfao dos clientes e membros da equipe. 51
Viso Geral do Processo de Engenharia de Requisitos
52 (KOTONYA; SOMMERVILLE, 1998)
1 2 3 4
5
Viso Geral do Processo de Engenharia de Requisitos
Vale destacar que no h limites bem definidos entre as atividades do processo apresentado.
Na prtica, elas so intercaladas e existe um alto grau de iterao e feedback entre elas.
O processo executado at que todos os usurios estejam satisfeitos e concordem com os requisitos. 53
Viso Geral do Processo de Engenharia de Requisitos
Esse processo pode ser aplicado para diferentes ciclos de vida:
Ao se adotar um modelo de ciclo de vida iterativo, essas atividades podem ser realizadas muitas vezes.
54
Viso Geral do Processo de Engenharia de Requisitos
Atividades do Processo de Engenharia de Requisitos: 1. Levantamento de Requisitos
2. Anlise de Requisitos
3. Documentao de Requisitos
4. Verificao e Validao de Requisitos
5. Gerncia de Requisitos
55
1. Levantamento de Requisitos
Levantamento de Requisitos Nessa fase, um esforo conjunto de clientes, usurios e
especialistas de domnio necessrio
Objetiva entender a organizao, seus processos, necessidades, deficincias dos sistemas de software atuais, possibilidades de melhorias, bem como restries existentes.
No se resume somente a perguntar s pessoas o que elas desejam, mas sim analisar cuidadosamente a organizao, o domnio da aplicao e os processos de negcio no qual o sistema ser utilizado
56
Levantamento de Requisitos
Os requisitos podem ser obtidos de diferentes fontes:
Informaes dos interessados (stakeholders) Usurios, clientes e especialistas de domnio.
Consultar documentos
Sistemas e processos existentes
Obter conhecimentos do domnio
Estudar o negcio da organizao
etc. 57
1. Levantamento de Requisitos
Dimenses do levantamento de requisitos
58 (KOTONYA; SOMMERVILLE, 1998)
1. Levantamento de Requisitos
1 2
3 4
Dimenses do levantamento de requisitos 1. Entendimento do domnio da aplicao:
entendimento geral da rea na qual o sistema ser aplicado;
2. Entendimento do problema: entendimento dos detalhes do problema especfico a ser
resolvido com o auxlio do sistema a ser desenvolvido;
3. Entendimento do negcio: entender como o sistema ir afetar a organizao e como
contribuir para que os objetivos do negcio e os objetivos gerais da organizao sejam atingidos;
59
1. Levantamento de Requisitos
Dimenses do levantamento de requisitos 4. Entendimento das necessidades e das restries dos
interessados: Entender as demandas de apoio para a realizao do trabalho de
cada um dos interessados no sistema, entender os processos de trabalho a serem apoiados pelo sistema e o papel de eventuais sistemas existentes na execuo e conduo dos processos de trabalho.
Consideram-se interessados (stakeholders), todas as pessoas que so afetadas pelo sistema de alguma maneira, dentre elas clientes, usurios finais e gerentes de departamentos onde o sistema ser instalado.
60
1. Levantamento de Requisitos
Stakeholders Todas as pessoas que so afetadas pelo sistema de alguma maneira
Nem sempre o cliente o usurio final
Cliente Quem contrata e paga pelo servio (Administrador de um hospital)
Usurio final Quem usa o software no dia a dia (Mdicos e enfermeiros)
Importante Nunca deixe de levantar requisitos com os usurios finais pois sem a
colaborao deles, o software no ser usado 61
1. Levantamento de Requisitos
Alguns sistemas sero utilizados por milhares ou milhes de usurios
Escolha usurios fonte dos requisitos que sejam representativos
Lembre-se que a regra de Pareto (80-20) aparenta ser vlida 20% dos requisitos satisfazem a 80% dos usurios
Escolher um usurio muito especialista pode levar a implementao de requisitos que nunca sero utilizados
Requisitos funcionais: Descrevem as funcionalidades do sistema
Requisitos no funcionais: Descrevem a qualidade do sistema 62
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Dentre as vrias tcnicas, podem ser citadas (KENDALL;
KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998; AURUM; WOHLIN, 2005):
Entrevistas
Questionrios
Observao
Anlise de Documentos
Anlise de Sistemas Existentes
Cenrios
Prototipao
Dinmicas de Grupo 63
1. Levantamento de Requisitos
As tcnicas so complementares: til empregar vrias dessas
tcnicas concomitantemente, de modo a se ter um levantamento
de requisitos mais eficaz.
Tcnicas de Levantamento de Requisitos Entrevistas:
Tcnica amplamente utilizada, que consiste em conversas direcionadas com um propsito especfico e com formato pergunta-resposta.
Seu objetivo descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinio e as expectativas do entrevistado sobre o sistema.
64
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Entrevistas:
Entrevistas fechadas: nas quais o interessado responde a um conjunto de perguntas predefinidas.
Entrevistas abertas: nas quais no existe um roteiro predefinido. O analista explora vrios assuntos com o interessado e, assim, desenvolve uma maior compreenso de suas necessidades.
65
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Entrevistas: Planejamento da entrevista [Kendall e Kendall, 2010]:
1. Estudar material existente sobre o domnio e a organizao. linguagem usada , vocabulrio comum, otimizar o tempo despendido nas entrevistas.
2. Estabelecer objetivos. fontes de informao, formatos da informao, frequncia na tomada de deciso, estilo
da tomada de deciso etc.
3. Decidir quem entrevistar. pessoas chave das diversas classes de interessados
4. Preparar o entrevistado. agendamento para que o entrevistado tenha tempo para pensar sobre a entrevista.
5. Preparar a entrevista. tipos de questes e a estrutura da entrevista e o modo como a mesma ser registrada.
66
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Entrevistas:
67
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Questionrios:
O uso de questionrios possibilita ao analista obter informaes como postura, crenas, comportamentos e caractersticas de vrias pessoas que sero afetas pelo sistema.
68
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Observao:
Consiste em observar o comportamento e o ambiente dos indivduos de vrios nveis organizacionais.
Utilizando-se essa tcnica, possvel capturar o que realmente feito e qual tipo de suporte computacional realmente necessrio.
Ajuda a confirmar ou refutar informaes obtidas com outras tcnicas e ajuda a identificar tarefas que podem ser automatizadas e que no foram identificadas pelos interessados. 69
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Anlise de Documentos:
Pela anlise de documentos existentes na organizao, analistas capturam informaes e detalhes difceis de conseguir por entrevista e observao.
Documentos revelam um histrico da organizao e sua direo.
70
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Anlise de Software Existente:
Caso j exista um sistema em uso e o projeto trata da sua reconstruo, este pode ser utilizado como fonte para levantamento de requisitos.
A tarefa ser executada atravs da Engenharia Reversa no contexto de uma Reengenharia do software.
71
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Cenrios:
Um cenrio de interao entre o usurio final e o sistema montado e o usurio simula sua interao com o sistema nesse cenrio, explicando ao analista o que ele est fazendo e de quais informaes ele precisa para realizar a tarefa descrita no cenrio.
O uso de cenrios ajuda a entender requisitos, a expor o leque de possveis interaes e a revelar facilidades requeridas.
72
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Prototipao:
Um prottipo uma verso preliminar do sistema, muitas vezes no operacional e descartvel, que apresentada ao usurio para capturar informaes especficas sobre seus requisitos de informao, observar reaes iniciais e obter sugestes, inovaes e informaes para estabelecer prioridades e redirecionar planos.
73
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Prototipao:
Prototipao evolucionria Uma abordagem para o desenvolvimento do sistema onde um
prottipo inicial produzido e refinado atravs de vrios estgios at atingir o sistema final.
Prototipao descartvel Um prottipo o qual usualmente uma implementao prtica
do sistema produzida para ajudar a levantar os problemas com os requisitos e depois descartado. O sistema ento desenvolvido usando algum outro processo de desenvolvimento.
74
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Prototipao:
75
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Prototipao:
76
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Prototipao:
77
1. Levantamento de Requisitos
Tcnicas de Levantamento de Requisitos Dinmicas de Grupo:
H vrias tcnicas que procuram explorar dinmicas de grupo para a descoberta e o desenvolvimento de requisitos: Brainstorming: representantes de diferentes grupos de interessados
engajam-se em uma discusso informal para rapidamente gerarem o maior nmero possvel de ideias.
JAD (Joint Application Development): interessados e analistas se renem para discutir problemas a serem solucionados e solues possveis. Com as diversas partes envolvidas representadas, decises podem ser tomadas e questes podem ser resolvidas mais rapidamente.
JAD so normalmente bem estruturadas (passos, aes e papis). 78
1. Levantamento de Requisitos
Contextualizao: O contexto consiste em definir algumas caractersticas de cada Requisito Funcional, tais como: para quem til?, quando?, por que?, onde?, como?
79
1. Levantamento de Requisitos
Essas perguntas so fundamentais para
entendimento dos requisitos, auxiliando uma descrio detalhada e consistente.
Dimenses Contextuais [KNIGHT, 2004]
Contextualizao: Para cada requisito identificado, as seguintes questes devem ser feitas:
01) Por que o requisito deve ser considerado na Soluo? A resposta deve ser analisada e verificada com o problema que est sendo resolvido pela
soluo em questo. A resposta tem que manter o escopo do Problema e da Soluo. Caso a resposta indique que o requisito amplia a soluo do Problema, ento um estudo mais aprofundado deve ser feito em relao ao escopo do Problema e da Soluo.
02) Como o requisito deve ser considerada Soluo? Esta pergunta deve esclarecer, do ponto de vista do usurio, como o requisito deve ser
considerado na soluo. As respostas podem variar bastante e outros requisitos de diversos tipos podem ser identificados.
Alm disso, esse item responde em partes os critrios de aceitao do requisito, uma vez que aponta para a expectativa do cliente em relao funcionalidade. As outras perguntas que completam os critrios de aceitao do requisito so as perguntas Quando? e Onde?, pois nelas tambm so traduzidas as expectativas do cliente.
80
1. Levantamento de Requisitos
Contextualizao: Para cada requisito identificado, as seguintes questes devem ser feitas:
03) Quando o requisito deve ser processado ou executado na Soluo? A pergunta visa obter Requisitos que definam a frequncia de processamento, a
disponibilidade e alguns outros Requisitos para que a funcionalidade seja executada, depois de implementada na Soluo.
04) Onde o requisito ser implementado? Indica a localizao da funcionalidade (mdulos, ambientes, servidores especficos, etc.).
05) Quem utilizar o requisito? A pergunta definir os usurios autorizados a utilizar a funcionalidade, aps a implantao.
Cada usurio identificado com a pergunta dever ser questionado tambm sobre os seus Requisitos para a implementao da funcionalidade.
81
1. Levantamento de Requisitos
Aplicando as Tcnicas de Levantamento de Requisitos
Duas importantes questes que precisam ser abordadas em relao s tcnicas de levantamento de requisitos so (AURUM; WOHLIN, 2005): Que tcnica(s) aplicar durante uma atividade de levantamento de
requisitos?
Quais dessas tcnicas so complementares?
Em ltima instncia, cada situao , em alguma extenso, nica e, portanto, as respostas a essas perguntas so dependentes do contexto do projeto (AURUM; WOHLIN, 2005).
De maneira geral, as principais tcnicas discutidas so complementares.
82
1. Levantamento de Requisitos
Qualidade dos Requisitos: A especificao dos requisitos deve satisfazer a uma srie de critrios para ser considerada uma especificao que possui qualidade, entre eles:
1. Clareza A clareza de um requisito expressa atravs de sua preciso, corretude e capacidade de ser
compreendido por todos os envolvidos no projeto. Para isso todos os conceitos presentes na especificao devem ser representados pelo mesmo termo.
2. Completude Para determinado requisito, todas as necessidades a ele relacionado foram captadas do
cliente e registradas. (Aplicabilidade do roteiro de levantamento de requisitos)
3. Origem O requisito foi coletado de um fornecedor de requisito oficial?
83
1. Levantamento de Requisitos
Qualidade dos Requisitos: 4. Consistncia
Garantir que no existam conflitos entre os requisitos e entre os artefatos gerados durante o ciclo de vida do projeto.
5. Implementveis Garantir que determinado requisito no conflita com as tecnologias e arquiteturas
determinadas durante o ciclo de vida do projeto.
6. Testveis A verificao e validao do requisito ocorrem atravs de procedimentos de teste,
experimentos e provas ou atravs de acordos de aceitao previamente definidos.
Para garantir esse critrio, deve-se identificar as condies para a homologao do Requisito, ou seja, todas as condies que permitam verificar que esse Requisito foi atendido.
7. Rastreveis O requisito deve permitir a fcil determinao de seus antecedentes e precedentes.
84
1. Levantamento de Requisitos
Atributos dos Requisitos:
Identificador nico (RF-n, RNF-n, RN-n)
Descrio (Texto descritivo)
Prioridade (Baixa, Mdia, Alta)
Status (Identificado, Aprovado, Cancelado, Em Construo, Em Homologao, Finalizado)
Origem (Nome do usurio, Documento analisado, etc.)
Dependncias
Etc.
85
1. Levantamento de Requisitos
Organizao dos Requisitos:
Narrativa livre O sistema deve mostrar uma mensagem de status (finalizada, em
andamento, ...) para uma tarefa em intervalos no menores que 60 segundos (dificulta o entendimento - no a forma mais indicada)
Lista de Requisitos Funcionais (RFs) RF-1: Uma mensagem de status deve ser mostrada na rea inferior
da janela (desenho da Fig.1)
RF-2: A mensagem deve ser atualizada a cada 60 segundos, com tolerncia de 10 segundos para mais ou para menos
RF-3: A mensagem deve estar sempre visvel
86
1. Levantamento de Requisitos
Organizao dos Requisitos:
Lista de Requisitos No Funcionais (RNFs) Disponibilidade
RNF - DS-1: O sistema deve ficar disponvel por 99,5% do tempo nos dias teis, das 6h s 22h
Eficincia RNF - EF-1: Em condies de pico de uso, deve ter uma reserva de 25% de
capacidade de processamento e memria
RNF - EF-2: O clculo de interferncia deve ser finalizado com sucesso em menos de 5 minutos
Flexibilidade RNF - FL-1: Um novo tipo de sensor deve poder ser configurado no sistema em
menos de 3 horas
Integridade RNF - IN-1: Transaes histricas dos consumidores s podero ser vistas por
usurios com privilgios de auditor 87
1. Levantamento de Requisitos
Organizao dos Requisitos:
Lista de Requisitos No Funcionais (RNFs)
88
1. Levantamento de Requisitos
Organizao dos Requisitos:
Lista de Requisitos No Funcionais (RNFs)
89
1. Levantamento de Requisitos
Organizao dos Requisitos:
Exemplo de Requisito No Funcional (RNF)
90
1. Levantamento de Requisitos
Organizao dos Requisitos:
Lista de Regras de Negcio (RNs) RN-1: O valor total de um pedido igual soma dos totais dos itens do
pedido acrescido de 10% de taxa de entrega.
RN-2: Um cliente do banco no pode retirar mais de R$ 1.000 por dia de sua conta.
RN-3: Os pedidos para um cliente no especial devem ser pagos antecipadamente.
RN-4: A regra de consistncia de nmeros de CPF calculada como descrito abaixo...
RN-5: sobre instncias (integridade referencial); ex: se X est em projeto, ento X funcionrio;
RN-6: sobre comparaes; ex: salrio tem que ser maior que salrio mnimo;
RN-7: sobre tempo (cronolgico); ex: todo funcionrio deve ter sido candidato antes; 91
1. Levantamento de Requisitos
Alguns problemas que tornam o levantamento de requisitos uma tarefa difcil: fronteiras so mal definidas
clientes/usurios especificam detalhes tcnicos desnecessrios.
clientes/usurios no sabem muito bem o que querem
clientes/usurios tm pouca compreenso das capacidades e limitaes de um ambiente computacional
clientes/usurios no tm pleno entendimento do domnio do problema
clientes/usurios tm dificuldade de comunicar suas necessidades
clientes/usurios omitem informao que acreditam ser bvia
92
1. Levantamento de Requisitos
Alguns problemas que tornam o levantamento de requisitos uma tarefa difcil: clientes/usurios especificam requisitos que conflitam com as
necessidades de outros clientes/usurios
clientes/usurios especificam requisitos que so ambguos ou impossveis de testar
Pode ser difcil compreender e coletar informaes quando existem muitos termos desconhecidos
clientes/usurios que entendem o problema a ser resolvido podem ser muito ocupadas
Polticas organizacionais podem influenciar nos requisitos de um sistema.
93
1. Levantamento de Requisitos
Descreva os requisitos (RFs, RNFs e RNs) de um Gerenciador de Compromissos
Lista de requisitos funcionais
Devidamente contextualizados
Lista de requisitos no funcionais
Lista de regras de negcio
Entregveis
Os requisitos devem estar organizados em um documento de definio de requisitos (a forma de organizao faz parte da avaliao) e contendo os atributos como prioridade, status, origem, etc. 94
Avaliao Parte 1
Viso Geral do Processo de Engenharia de Requisitos
95 (KOTONYA; SOMMERVILLE, 1998)
1 2 3 4
5
Uma vez identificados os requisitos, possvel iniciar a atividade de anlise, quando os requisitos levantados so usados como base para a modelagem do sistema.
Requisitos de usurio so escritos tipicamente em linguagem natural, pois eles devem ser compreendidos por pessoas que no sejam especialistas tcnicos.
Contudo, til expressar requisitos mais detalhados do sistema de maneira mais tcnica. Para tal, diversos tipos de modelos podem ser utilizados (ex.: UML).
96
2. Anlise de Requisitos
A atividade de anlise uma atividade de modelagem conceitual, pois ela se preocupa com o domnio do problema e no com solues tcnicas para o mesmo. Duas principais perspectivas so consideradas nesta atividade:
Perspectiva estrutural: Busca modelar os conceitos, propriedades e relaes do domnio
que so relevantes para o sistema em desenvolvimento.
Diagramas de Classes e Modelo de Entidades e Relacionamentos so usados para modelar esta perspectiva.
Perspectiva comportamental: visa modelar o comportamento geral do sistema, de uma de suas
funcionalidades ou de uma entidade especfica ao longo do tempo.
Diagramas de casos de uso, diagramas de atividades, diagramas de estados e diagramas de interao so usados para esta perspectiva. 97
2. Anlise de Requisitos
Os modelos criados durante a atividade de anlise de requisitos cumprem os seguintes papis (PFLEEGER, 2004):
prover uma base para o entendimento e concordncia entre clientes e desenvolvedores sobre o que o sistema deve fazer; e
prover uma especificao que guie os desenvolvedores na demais etapas do desenvolvimento, sobretudo no projeto, implementao e testes do sistema.
98
2. Anlise de Requisitos
Descries de Casos de Uso
No h um padro definido para especificar casos de uso.
Diferentes autores propem diferentes estruturas, formatos e contedos para descries de casos de uso
Alguns mais indicados para casos de uso essenciais e mais complexos, outros para casos de uso cadastrais e mais simples.
Exemplos detalhados podem ser encontrados na Seo 5.3 [Falbo, 2012].
99
2. Anlise de Requisitos
Descries de Casos de Uso
100
2. Anlise de Requisitos
Linguagem de Modelagem Unificada (Unified Modeling Language UML)
uma linguagem grfica padro para especificar, visualizar, documentar e construir artefatos de sistemas de software
somente uma linguagem e, portanto, apenas parte de um mtodo de desenvolvimento de software.
Ela independente do processo de software a ser usado, ainda que seja mais adequada a processos de desenvolvimento orientados a objetos. 101
2. Anlise de Requisitos
UML
Diagramas de Classes: Um diagrama de classes exibe um conjunto de classes e seus relacionamentos. Proveem uma viso esttica da estrutura de um sistema.
102
2. Anlise de Requisitos
103
2. Anlise de Requisitos
UML: Diagramas de Classes
UML
Diagramas de Casos de Uso:
Um diagrama de casos de uso mostra um conjunto de casos de uso e atores e seus relacionamentos.
Os casos de uso descrevem a funcionalidade do sistema percebida pelos atores externos.
Um ator interage com o sistema, podendo ser um usurio humano, dispositivo de hardware ou outro sistema.
Diagramas de casos de uso proveem uma viso das funcionalidades do sistema, sendo importantes para a organiz-las e model-las.
104
2. Anlise de Requisitos
105
2. Anlise de Requisitos
UML: Diagramas de Casos de Uso
UML
Diagramas de Estados:
Mostram os estados pelos quais um objeto pode passar ao longo de sua vida, em resposta a estmulos recebidos, juntamente com suas aes.
Os diagramas de estados proveem uma viso dinmica de um objeto, sendo importantes para modelar o comportamento dos objetos de uma classe em resposta ocorrncia de eventos.
106
2. Anlise de Requisitos
107
2. Anlise de Requisitos
UML: Diagramas de Estados
UML
Diagramas de Atividades:
Mostram a estrutura de um processo.
Proveem uma viso dinmica do sistema (ou de uma poro do sistema) e podem ser usados tanto para modelar processos de negcio quanto para modelar funes do sistema.
Um diagrama de atividades d nfase ao fluxo de controle entre objetos
108
2. Anlise de Requisitos
109
2. Anlise de Requisitos
UML: Diagramas de Atividades
UML
Diagramas de Interao: Diagramas de Sequncia:
Mostra um conjunto de objetos ou papis interagindo, incluindo as mensagens que podem ser trocadas entre eles.
So um tipo de diagrama de interao cuja nfase est na ordenao temporal das mensagens.
110
2. Anlise de Requisitos
111
2. Anlise de Requisitos
UML: Diagramas de Sequncia
Fases de um projeto de BD
Coleta e Anlise de Requisitos
Projeto Conceitual
Projeto Lgico
Projeto Fsico
Mini-mundo
Requisitos de BD
Esquema conceitual
Esquema lgico
Esquema interno 112
Modelo de Entidades e Relacionamentos (MER)
Representao semntica das estruturas de dados mantidas num banco de dados
Foi proposto por Peter Chen em 1976
Possui vrias notaes: - Relacionamentos como objetos do Modelo (Chen)
- Relacionamentos apenas como simples ligaes (Codd, Martin)
113
Entidades
Uma entidade tudo aquilo sobre o qual se deseja manter informaes.
Podendo representar:
objetos concretos: pessoas, livros, carros,
conceitos abstratos: empresas, eventos, embarques,
114
Possui propriedades que a distingue de outras entidades.
um subconjunto de objetos (instncias) que:
desempenha o mesmo papel semntico
possui os mesmos tipos de propriedades (atributos)
115
Entidades
Ex.: Conjunto de todas as contas correntes de um banco
Conjunto de todos os empregados de uma empresa
Conjunto de todos os filmes de um produtor
Representao de entidades no diagrama E-R (entidades e relacionamentos):
Empregado Filme Emprstimo
116
Entidades
Entidades devem ser descritas num Dicionrio de Dados
Entidade: EMPREGADO
Descrio: Pessoa que mantm vnculo
empregatcio com a Empresa atravs de
um contrato de trabalho de acordo com a
legislao trabalhista
117
Entidades
118
Instncia: objeto de uma entidade com suas respectivas propriedades que distinguvel dos outros objetos. Ex.: A entidade Empregado poderia ter a seguinte instncia: Maria dos Anjos, 31 anos, Secretria, Solteira, R$ 800,00
Entidades
So as propriedades que caracterizam ou descrevem uma entidade ou um relacionamento.
Ex.: A entidade CARRO poderia ter os seguintes atributos:
Placa, fabricante, modelo, ano de fabricao, cor, preo
O relaciomento TRABALHA entre EMPREGADO e PROJETO pode ter o atributo: horasTrabalhadas.
119
Atributos
Cada atributo possui um domnio que identifica o conjunto de valores permitidos para aquele atributo.
Ex.: nome: domnio string(20) salrio: domnio numrico
120
Atributos
Entidade: EMPREGADO
Atributo: Data de Admisso
Descrio: data na qual foi assinado o
contrato de trabalho entre a empresa e o
empregado
Domnio: data posterior a 03/01/78 (data de
criao da empresa) e a data de nascimento
do empregado
Atributos devem tambm ser descritos no Dicionrio de Dados:
121
Atributos
Simples: atmico.
Ex. Idade: numrico Nome: cadeia de caracteres
Composto: contm sub-atributos que compem o atributo.
Ex.: Endereo (rua, nmero, bairro, CEP, cidade, etc.)
122
Atributos
Simplesmente valorados: tm um nico valor para uma instncia de uma entidade.
Ex.: PESSOA: Idade
Multivalorados: possuem vrios valores numa instncia de uma entidade.
Ex.: PESSOA:TitulaoSuperior(nenhum, Bel., MSc., PhD)
Atributos derivados: podem ser determinados a partir de outros atributos/entidades.
Ex. Idade e dataAniversrio
123
Atributos
Relacionamentos
So funes que mapeiam um conjunto de instncias de uma entidade em um outro conjunto de instncias de outra entidade (ou da mesma entidade: auto relacionamento).
Em outras palavras, so associaes entre diversas entidades.
Ex.:
Um empregado trabalha num projeto
Um cliente possui conta bancria
Um filme possui vrios atores 124
Empregado
Projeto trabalha
matricula nome salrio horas
1..N
1..N
125
Relacionamentos
Empregado supervisiona 0..N
0..1
126
Relacionamentos
Restries de Integridade
Caracterizam as restries nas quais os relacionamentos entre entidades esto submetidos (regras do negcio).
Ex.:
Todo empregado deve estar lotado num departamento
Existe Cliente que no foi recomendado por Cliente
Toda Nota Fiscal deve ter pelo menos um item discriminado
Toda multa deve estar associada a um carro
Existe carro sem multa associada 127
Podemos caracterizar um relacionamento em termos de:
1. Cardinalidade: quantidade de instncias que podem participar do relacionamento
2. Totalidade: obrigatoriedade da ocorrncia do relacionamento entre as entidades envolvidas.
128
Restries de Integridade
Tipos de Cardinalidade
Um_para_Um (1:1): uma instncia de uma entidade A est associada a no mximo a uma instncia de uma entidade B, e vice-versa.
Um_para_Muitos (1:N): uma instncia de uma entidade A est associada a qualquer nmero de instncias da entidade B. Porm, uma instncia da entidade B pode estar associada, no mximo, a uma instncia da entidade A.
129
Restries de Integridade
Tipos de Cardinalidade
Muitos_para_Um (N:1): uma instncia da entidade A est associada a uma instncia de B. Porm, uma instncia de B pode estar associada a qualquer nmero de instncias de A.
Muitos_para_Muitos(M:N): uma instncia da entidade A est associada a qualquer nmero de instncias da entidade B, e vice-versa.
OBS.: o uso de zero (0:1) ou (0:N) indica a totalidade do relaciomento.
130
Restries de Integridade
a1
a2
a3
a4
a5
b1
b2
b3
b4
b5
A B
1:1
b1
b2
b3
b4
b5
a1
a2
a3
B A
1:N
a1
a2
a3
a4
a5
b1
b2
b3
N:1
a1
a2
a3
a4
a5
b1
b2
b3
b4
b5
N:M
A A B B
131
Restries de Integridade
Representao clssica Chen
A B 1
1
A B 1
N
A B N
1
A B N
M
132
Chaves
Como distinguir as instncias de uma entidade? Num Banco de Dados, isto feito atravs dos atributos das entidades que formam as chamadas chaves de identificao.
Toda instncia de uma entidade deve ter uma chave de identificao, que deve ter algum valor no nulo.
133
Chave de identificao composta: uma chave formada por mais de um atributo.
Ex.: Cenrio: sistema de controle de multas de trnsito.
Premissas: toda multa est relacionada a um carro,
carros devem ser de propriedades de pessoas que tenham carteira de habilitao,
carteiras de habilitao so emitidas pelo DETRAN de cada estado.
134
Chaves
Entidade Chave
Estado Sigla do estado
Motorista Sigla do estado +
nmero da carteira de
habilitao
Carro Sigla do Estado
Nmero da carteira de motorista
Placa do Carro
Multa Sigla do Estado
Nmero da carteira de motorista
Placa do Carro
Nmero de sequncia da multa
135
Chaves
Obs.: Evitar usar chaves compostas sempre que possvel!
Chaves de identificao definidas pelo usurio concorrem entre si como chaves candidatas e so sujeitas mudanas.
Ex.: Entidade : Departamento
Chaves candidatas:
1. Sigla do Departamento
2. Cdigo do Centro de Custo
3. Cdigo da Diretoria + Cdigo da Superintendncia + Cdigo do Departamento
136
Chaves
O que fazer quando:
um departamento mudar de nome?
- for modificada a estrutura de codificao de Centros de Custos?
- um departamento mudar de diretoria?
Soluo: chave de identificao prpria: surrogate ou object identification (object id)
137
Chaves
Surrogates:
- criados para cada entidade (chave primria)
- identifica univocamente cada instncia da entidade
- no precisa ser percebido pelos usurios
- no controlado pelos usurios (gerado automaticamente pelo SGBD)
138
Chaves
MER Estendido
Superclasses e Subclasses
Vimos que uma entidade usada para representar um conjunto de instncias do mesmo tipo (Ex. Empregado).
Porm, muitas vezes uma entidade tem subentidades que necessitam ser representadas explicitamente.
Ex. Empregado pode ser agrupado em: Secretria, Engenheiro e Tcnico
139
Superclasses e Subclasses Estas subentidades so subconjuntos da entidade
Empregado, ou seja, cada instncia de uma subentidade tambm uma instncia da entidade Empregado. Ento dizemos que Secretria _uma Empregada, Engenheiro _um Empregado e Tcnico _um Empregado.
Este relacionamento _um caracteriza a herana. Ou seja, a subentidade (subclasse) herda todos os atributos e relacionamentos da superentidade (superclasse).
140
MER Estendido
Superclasses e Subclasses
importante notar, que nem toda instncia da superentidade membro de uma subentidade.
Ex.: podemos ter empregados que no so nem secretria, nem engenheiro, nem tcnico.
141
MER Estendido
Empregado
_um
Tcnico Engenheiro Secretria
142
MER Estendido
Especializao
o processo de definir um conjunto de subclasses de uma entidade (superentidade).
Podem-se ter vrias especializaes de uma mesma entidade, baseado em caractersticas distintas.
Ex.: A entidade Empregado pode tambm ser especializada nas subentidades Assalariado e Horista.
143
Existem pelo menos duas razes para usar especializao num modelo de dados:
Certos atributos podem ser aplicados somente a algumas instncias de uma entidade (subclasse), mas no a todas.
Ex.: Secretria: lnguas, velocidadeDigitao
Engenheiro: Especialidade, CREA
Motorista: nmero da carteira de habilitao, categoria
Alguns relacionamentos s se aplicam a algumas instncias que pertencem a uma subclasse. Ex.: Horistas pertencem_a Empreiteras
144
Especializao
o processo inverso Especializao, isto , um processo de sntese em que suprimimos as diferenas entre vrias entidades (subclasses), identificamos suas caractersticas comuns e as generalizamos numa superclasse.
145
Generalizao
MER Estendido - Restries
Cobertura Total: cada instncia da superentidade deve ser uma instncia de alguma subentidade.
Ex.: Todo Empregado deve ser Engenheiro, Secretria ou Motorista
Cobertura Parcial: uma instncia de uma superentidade pode no ser membro de nenhuma subclasse.
Ex.: Pode existir empregado que no seja Engenheiro, Secretria nem Motorista.
146
MER Estendido - Restries
Disjuno: uma dada instncia pode ser membro de no mximo uma subentidade.
Ex. Empregado ou secretria, engenheiro ou tcnico.
Sobreposio: uma mesma instncia pode ser membro de mais de uma subentidade.
Ex. Empregado pode ser engenheiro e tcnico.
147
DER - Exemplo
148
Mtodo de Anlise de Requisitos Funcionais
149
Execute a anlise dos requisitos do Gerenciador de Compromissos proposto na Parte 1 da Avaliao
Entregveis:
Documento de Especificao de Requisitos com:
Diagrama de Entidades e Relacionamentos
Descries de Casos de Uso
Opcionais: Diagrama de Classes
Diagrama de Casos de Uso
Outros Diagramas UML 150
Avaliao Parte 2
Viso Geral do Processo de Engenharia de Requisitos
151 (KOTONYA; SOMMERVILLE, 1998)
1 2 3 4
5
Basicamente so gerados dois documentos de requisitos durante o processo de Engenharia de Requisitos:
1. Documento de Definio de Requisitos
Resultado da atividade de Levantamento de Requisitos
2. Documento de Especificao de Requisitos
Resultado da atividade de Anlise de Requisitos
H muitos formatos distintos propostos na literatura.
152
3. Documentao de Requisitos
1. Documento de Definio de Requisitos Registro dos requisitos em um documento, de modo
que possam ser verificados, validados e utilizados como base para outras atividades do processo de software.
Para que sejam teis, os requisitos tm de ser escritos em um formato compreensvel por todos os interessados.
Combinao de linguagem natural, modelos, tabelas e outros elementos. Formas de documentao de requisitos na Seo 3.4 [Falbo, 2012].
153
3. Documentao de Requisitos
1. Documento de Definio de Requisitos Uma estrutura simples contendo apenas quatro sees:
1. Introduo Breve introduo ao documento, descrevendo seu propsito e
estrutura.
2. Descrio do Propsito do Sistema: Descreve o propsito geral do sistema.
3. Descrio do Minimundo: Apresenta uma viso geral do domnio, do problema a ser resolvido,
dos processos de negcio apoiados e das principais ideias do cliente sobre o sistema a ser desenvolvido.
4. Requisitos de Usurio: Requisitos funcionais, requisitos no funcionais e regras de negcio. 154
3. Documentao de Requisitos
2. Documento de Especificao de Requisitos
Tem como propsito registrar os requisitos escritos a partir da perspectiva do desenvolvedor
Deve incluir os vrios modelos conceituais desenvolvidos
Deve incluir a especificao dos requisitos no funcionais detalhados.
155
3. Documentao de Requisitos
2. Documento de Especificao de Requisitos 1. Introduo:
breve introduo ao documento, descrevendo seu propsito e estrutura.
2. Modelo de Casos de Uso:
diagramas de casos de uso e as descries de casos de uso associadas.
3. Modelo Estrutural:
diagramas de entidades e relacionamento e diagrama de classes do sistema.
4. Modelo Dinmico:
apresenta os modelos comportamentais dinmicos do sistema, incluindo os diagramas de estados, diagramas de interao e diagramas de atividades.
5. Dicionrio do Projeto:
apresenta as definies dos principais conceitos, servindo como um glossrio do projeto.
6. Especificao dos Requisitos No Funcionais:
apresenta os requisitos no funcionais descritos no nvel de sistema, o que inclui critrios de aceitao. 156
3. Documentao de Requisitos
Viso Geral do Processo de Engenharia de Requisitos
157 (KOTONYA; SOMMERVILLE, 1998)
1 2 3 4
5
As atividades de Verificao & Validao (V&V) devem ser iniciadas o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos so encontrados, maiores os custos associados sua correo.
V&V de requisitos deve assegurar que: 1. Todos os requisitos do sistema tenham sido declarados de
modo no-ambguo
2. As inconsistncias, conflitos, omisses e erros tenham sido detectados e corrigidos
3. Os documentos esto em conformidade com os padres estabelecidos
4. Os requisitos realmente satisfazem s necessidades dos clientes e usurios.
158
4. Verificao e Validao de Requisitos
As atividades de Verificao & Validao (V&V) devem ser iniciadas o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos so encontrados, maiores os custos associados sua correo.
Verificao x Validao
Verificao assegurar que o software esteja sendo construdo de forma correta Revises realizadas pela equipe do projeto (internamente).
Validao assegurar que o software que est sendo desenvolvido o software correto Revises realizadas pelos usurios ou clientes (externamente).
159
4. Verificao e Validao de Requisitos
Verificao x Validao
Verificao
realizada em relao consistncia entre requisitos e modelos e conformidade com padres organizacionais de documentao de requisitos.
Validao
Tem de envolver a participao de usurios e clientes, pois somente eles so capazes de dizer se os requisitos atendem aos propsitos do sistema.
160
4. Verificao e Validao de Requisitos
Tcnicas de Verificao e Validao
Revises Formais
Seguem um processo para realizao de revises (papis, atividades, ferramentas, monitoramento de defeitos).
Revises Informais
Podem ser conduzidas pelos prprios autores dos documentos, por clientes, usurios ou por qualquer envolvido.
No seguem regras pr-estabelecidas.
So baseadas em checklists, guias e templates garantindo padronizaes. 161
4. Verificao e Validao de Requisitos
Tcnicas de Verificao e Validao
Revises Formais X Revises Informais
As revises formais devem ser combinadas com revises informais para uma estratgia de qualidade efetiva e dentro de custos razoveis.
162
4. Verificao e Validao de Requisitos
Tcnicas de Verificao e Validao
Revises Formais
Reviso em Pares (Peer Review)
Inspeo Formal
Walkthrough Estruturado
163
4. Verificao e Validao de Requisitos
Tcnicas de Verificao e Validao
Revises Formais
Reviso em Pares (Peer Review)
Apenas uma pessoa, alm do autor, verifica o artefato.
Depende totalmente da experincia e conhecimento do revisor.
considerada formal, pois existem checklists, guias, templates, registro sistemtico de defeitos e procedimentos especficos de anlise.
164
4. Verificao e Validao de Requisitos
Tcnicas de Verificao e Validao
Revises Formais
Inspeo Formal A inspeo de um artefato deve ser solicitada quando ele chegar a um
ponto de completude razovel.
No devem ser realizadas inspees de artefatos que ainda esto mudando com frequncia.
165
4. Verificao e Validao de Requisitos
Papis Participantes: Autor Moderador Leitor Escriba Inspetor (Todos so inspetores) Verificador
Atividades: 1. Preparao para a reunio 2. Conduo (leitura do documento) 3. Resultados da reunio 4. Anlise causal (em caso de alto grau de
defeitos)
Tcnicas de Verificao e Validao
Revises Formais
Walkthrough Estruturado A diferena principal em relao s inspees que o autor descreve o
artefato para um grupo e solicita comentrios. (no tem o papel do leitor)
Em qualquer ponto do desenvolvimento de um artefato.
No deve durar mais de uma hora e mnimo de participantes trs
166
4. Verificao e Validao de Requisitos
Papis Participantes: Apresentador Moderador Escriba Especialista de manuteno Especialista de padres Outros Revisores
Atividades: 1. Preparao para a reunio 2. Conduo (rpida apresentao do artefato) 3. Resultados da reunio 4. Anlise causal (em caso de alto grau de
defeitos)
Tcnicas de Verificao e Validao
Revises Informais
Demonstrao Muito utilizada para demonstrao de artefatos ou prottipos para
clientes e usurios
Checklists de padres
Guias de padronizao
Comparao com Templates
167
4. Verificao e Validao de Requisitos
Verificao e Validao Questes:
Os requisitos esto claros?
A fonte dos requisitos est identificada?
Os requisitos foram mostrados para essa fonte?
Os requisitos esto descritos de forma quantitativa?
Os requisitos esto relacionados via referncia cruzada?
Os requisitos violam alguma restrio do domnio?
O requisito testvel? Os testes foram especificados?
Os requisitos so rastreveis para os modelos e o cdigo subsequente?
Existem requisitos implcitos? 168
4. Verificao e Validao de Requisitos
Exemplos de Ambiguidade:
A janela deve abrir rapidamente
O sistema deve ser flexvel
O clculo deve ser eficiente
A interface com o usurio deve ser melhor que a atual
No devem ser mostradas muitas mensagens de erro
A exibio do mapa de navegao deve ser amigvel
169
4. Verificao e Validao de Requisitos
Execute verificao dos artefatos gerados nas Partes 1 e 2 da Avaliao
Cada grupo ir verificar os artefatos de outro grupo.
Tcnica: Walkthrough Estruturado
Entregveis:
Lista de Defeitos categorizados por prioridade e tipo. Ambiguidade
Inconsistncia
Omisso
Erro 170
Avaliao Parte 3
Viso Geral do Processo de Engenharia de Requisitos
171 (KOTONYA; SOMMERVILLE, 1998)
1 2 3 4
5
172
5. Gerncia de Requisitos
Mudana de software inevitvel
Novos requisitos surgem quando o software usado;
O ambiente de negcio muda;
Erros devem ser reparados;
Novos computadores e equipamentos so adicionados ao sistema;
O desempenho ou a confiabilidade do sistema deve ser melhorada.
Um problema-chave para as organizaes a implementao e o gerenciamento de mudanas em seus sistemas e a rastreabilidade entre os artefatos.
173
5. Gerncia de Requisitos
Gerncia de Requisitos
Objetivo
Controlar as mudanas nos requisitos
Permitir a anlise de impacto das mudanas
174
5. Gerncia de Requisitos
Custo da evoluo
Distribuio de esforos de manuteno
175
(SOMMERVILLE, 2011)
5. Gerncia de Requisitos
Distribuio de esforos de manuteno
176
Percentuais de Esforo por
Tipo de Manuteno (PFLEEGER,
2007)
5. Gerncia de Requisitos
O processo de evoluo de sistema
177
(Sommerville, 2011)
5. Gerncia de Requisitos
Implementao de mudanas
178
(Sommerville, 2011)
5. Gerncia de Requisitos
Solicitaes de mudana urgentes
Mudanas urgentes podem ter de ser implementadas sem passar por todos os estgios do processo de desenvolvimento de software
Se um defeito crtico de sistema tem de ser reparado;
Se mudanas no ambiente do sistema (por exemplo, atualizao do OS) tm efeitos inesperados;
Se existem mudanas de negcio que necessitam de uma resposta muito rpida (por exemplo, o release de um produto concorrente)
179
5. Gerncia de Requisitos
Reparo de emergncia
180
(Sommerville, 2011)
5. Gerncia de Requisitos
Processo de Manuteno
181
Basili (1990) props trs paradigmas diferentes para tratar a manuteno de software:
(i) Conserto Rpido;
(ii) Melhoria Interativa;
(iii) Reuso Total
5. Gerncia de Requisitos
Conserto Rpido
182
Essa abordagem corresponde normalmente preferida pelo mantenedor, justificando a deciso pela urgncia da manuteno (Visaggio, 2001).
5. Gerncia de Requisitos
Melhoria Interativa
183
prope inicialmente adequar e atualizar a documentao de alto nvel que ser afetada, para ento propagar as mudanas at o nvel de cdigo-fonte.
5. Gerncia de Requisitos
Reuso Total
184
Reuso total, consiste em construir um novo software, utilizando componentes do software antigo e outros disponveis em um repositrio.
5. Gerncia de Requisitos
Matriz de Reastreabilidade
185
Matrizes de rastreabilidade so os principais artefatos produzidos na fase de gerncia de requisitos.
Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente
Permitem obter um entendimento de como uma modificao em um requisito vai afetar diferentes aspectos do sistema.
5. Gerncia de Requisitos
Matriz de Reastreabilidade
186
Matriz de rastreabilidade de dependncia: indica como os requisitos esto relacionados uns com os outros.
Matriz de rastreabilidade requisitos fontes: indica a fonte de cada requisito.
Matriz de rastreabilidade requisitos subsistemas: indica os subsistemas que tratam os requisitos.
Matriz de rastreabilidade requisitos de usurio casos de uso: indica os casos de uso que detalham um requisito funcional ou tratam um requisito no funcional ou regra de negcio.
5. Gerncia de Requisitos
Matriz de Reastreabilidade
187
5. Gerncia de Requisitos
Matriz de Reastreabilidade
188
5. Gerncia de Requisitos
Regressiva a partir dos requisitos relaciona requisitos com suas origens (outros documentos
ou pessoas); Progressiva a partir dos requisitos
relaciona requisitos aos artefatos do projeto (planos, modelos de anlise e projeto, cdigo etc.);
Regressiva em direo aos requisitos relaciona artefatos do projeto aos requisitos;
Progressiva em direo aos requisitos relaciona as fontes (p.ex., documentos que precederam o
documento de requisitos) aos requisitos relevantes.
Matriz de Reastreabilidade
189
5. Gerncia de Requisitos
CMMI
190
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software
O CMMI um modelo de qualidade de processo desenvolvido pelo (Software Engineering Institute SEI) da Universidade de Carnegie Mellon.
Tem como objetivo fornecer diretrizes para a definio e melhoria de processos de software de uma organizao
Cinco nveis de maturidade na representao em estgios: 1- Inicial 2- Gerenciado 3- Definido 4- Gerenciado Quantitativamente 5- Em Otimizao
191
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software
CMMI - Nvel 2- Gerenciado rea de processo: Gesto de Requisitos (REQM)
SG 1 Gerenciar Requisitos SP 1.1 Entender os requisitos. SP 1.2 Obter comprometimento com os requisitos. SP 1.3 Gerenciar mudanas de requisitos. SP 1.4 Manter rastreabilidade bidirecional dos requisitos. SP 1.5 Garantir alinhamento entre o trabalho de projeto
(planos de projeto e produtos de trabalho) e requisitos.
192
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software
CMMI - Nvel 3- Definido rea de Processo: Desenvolvimento de Requisitos (RD)
SG 1 Desenvolver Requisitos de Cliente SP 1.1 Levantar necessidades. SP 1.2 Transformar necessidades dos interessados em requisitos de cliente.
SG 2 Desenvolver Requisitos do Produto SP 2.1 Estabelecer os requisitos do produto e de componentes do produto. SP 2.2 Alocar requisitos de componentes do produto. SP 2.3 Identificar requisitos de interface.
SG 3 Analisar e Validar Requisitos SP 3.1 Estabelecer conceitos e cenrios operacionais. SP 3.2 Estabelecer uma definio da funcionalidade e dos atributos de
qualidade requeridos. SP 3.3 Analisar requisitos. SP 3.4 Analisar requisitos para balancear. SP 3.5 Validar requisitos.
MPS.BR
193
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software
O MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2011) um programa mobilizador, que tem como objetivo a melhoria de processo do software brasileiro.
Tem como objetivo definir e aprimorar um modelo de melhoria e avaliao de processo de software, visando preferencialmente s micro, pequenas e mdias empresas. Sete nveis de maturidade:
G- Parcialmente Gerenciado F- Gerenciado, E- Parcialmente Definido D- Largamente Definido C- Definido B- Gerenciado Quantitativamente A- Em Otimizao
194
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software
MPS.BR - Nvel G - Parcialmente Gerenciado rea de processo: Gerncia de Requisitos
GRE 1. O entendimento dos requisitos obtido junto aos fornecedores de requisitos;
GRE 2. Os requisitos so avaliados com base em critrios objetivos e um comprometimento da equipe tcnica com esses requisitos obtido;
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida;
GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir inconsistncias em relao aos requisitos;
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto.
195
Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software
MPS.BR - Nvel D - Parcialmente Gerenciado rea de processo: Desenvolvimento de Requisitos
DRE 1. As necessidades, expectativas e restries do cliente, tanto do produto quanto de suas interfaces, so identificadas;
DRE 2. Um conjunto definido de requisitos do cliente especificado e priorizado a partir das necessidades, expectativas e restries identificadas;
DRE 3. Um conjunto de requisitos funcionais e no-funcionais, do produto e dos componentes do produto que descrevem a soluo do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente;
DRE 4. Os requisitos funcionais e no-funcionais de cada componente do produto so refinados, elaborados e alocados;
DRE 5. Interfaces internas e externas do produto e de cada componente do produto so definidas;
DRE 6. Conceitos operacionais e cenrios so desenvolvidos; DRE 7. Os requisitos so analisados, usando critrios definidos, para balancear as
necessidades dos interessados com as restries existentes; DRE 8. Os requisitos so validados.