ERS - NA10 - Modelagem - P12 - 2-3

CI-UFPB Engenharia de Requisitos
A10 Especificao e modelagem Parte I

2012.2 Danielle Rousy drousy.ufpb@gmail.com
O que veremos hoje?

Papel da modelagem em ER
Por que importante modelar? Limitaes da modelagem
2012.2 UFPB - Especificao de Requisitos
Breve viso das linguagens de modelagem Modelo de anlise
Vamos relembrar um pouco...

Domnio da aplicao Domnio da mquina
Especificao de Requisitos Propriedades do domnio Computadores Requisitos Programas
Alguns comentrios
Propriedades do domnio aspectos referente ao domnio da aplicao que so verdades se ou no desenvolvemos o sistema proposto Requisitos aspectos referente ao domnio da aplicao que desejamos fazer verdade aps a entrega do sistema proposto Especificao descrio do comportamento do programa de forma a manter os requisitos da aplicao
Especificao dos requisitos

Deve incluir:
(1) Ambiente fsico
Onde o equipamento funcionar? Esse funcionamento se dar em um ou vrios locais? Existe alguma restrio ambiental, tal como temperatura, umidade ou interferncia magntica?
(2) Interfaces
A entrada tem origem em outro ou outros sistemas? A sada vai para outro ou outros sistemas? Existe uma maneira preestabelecida pela qual os dados devem ser formatados? Existe alguma mdia definida, que os dados devem utilizar?

(3) Os usurios e fatores humanos
Quem utilizar o sistema? Haver diversos tipos de usurios? Qual o nvel de habilidade de cada tipo de usurio? Que tipo de treinamento ser necessrio para cada tipo de usurio? Que facilidade o usurio ter para entender e utilizar o sistema? Qual ser a dificuldade para que o usurio utilize inadequadamente o sistema? O que o sistema realizar? Quando o sistema far? Existem diversos modos de operao? Como e quando o sistema pode ser modificado ou aprimorado? Existem limitaes quanto velocidade de execuo, ao tempo de resposta, ou sada?
(4) Funcionalidade


(5) Documentao
Que documentao necessria? Essa documentao deve ser on-line, no formato de livro, ou ambos? A que pblico se destina cada tipo de documentao?
(6) Dados
Qual dever ser o formato dos dados de entrada e sada? Com que frequncia eles sero enviados ou recebidos? Quem preciso devem ter? Com que grau de preciso os clculos devem ser feitos? Qual ser o fluxo de dados do sistema? Existem dados que devem ser mantidos por algum tempo?
Recursos, segurana e garantia de qualidade...
O processo de Engenharia de Requisitos
UFPB - Especificao de Requisitos
2012.2
Estudo de Viabilidade
Qual o problema? H uma soluo vivel para o problema? Vale a pena resolver o problema? A administrao est vitalmente vinculada aos resultados; Definio do problema mais ntida; So fixados objetivos especficos; Os problemas que sero excludos so claramente identificados; Calcula-se o custo/benefcio com mais exatido.
2012.2
O processo de Engenharia de Requisitos
2012.2
Elicitao e Anlise de requisitos

Processo interativo com realimentao contnua (cclico) Atividades:
Obteno de requisitos (coleta de dados) Classificao e organizao de requisitos Priorizao e negociao de requisitos Documentao de requisitos
2012.2
10
Classificao dos Requisitos

Consiste basicamente em agrupar os diversos requisitos coletados em categorias bem-definidas Classificao:
Funcional
Ex.: Deve ser possvel consultar o preo de uma mercadoria
No Funcional
Ex.: A consulta deve retornar uma resposta em no mximo 5s
Inversos
Ex.: O sistema no far controle de estoque.
11
2012.2
Resoluo de Conflitos
normal que ocorram requisitos conflitantes Por exemplo
R-23: O sistema deve ... R-45: O sistema no deve ...
2012.2
Cliente o responsvel por resolver conflitos e ambigidades
12
Atribuio de Prioridade
Alguns requisitos so mais urgentes que outros essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade so considerados em primeiro lugar
13
2012.2
Prioridade
Requisitos podem ser agrupados em classes, por exemplo:
Essenciais Importantes Desejveis
2012.2
Em princpio, o sistema deve abranger todos os requisitos de essenciais para desejveis
14
Outras escalas de priorizao de requisitos: [Wiegers]

IEEE 1998
essencial
software no aceitvel a no ser que estes requisitos sejam implementados
Kovitz 1999
condicional
melhoraria produto, mas no o tornaria inaceitvel se ausente
opcional
classe de funcionalidade que pode ou no valer a pena
15
3 - dever ser implementado de modo perfeito 2 - precisa funcionar, mas no de modo espetacular 1 - pode conter bugs
2012.2
Exemplo de Prioridade
[RF001] Consulta X ao B.D. deve retornar dados A, B, C
[RNF001] Consulta X ao B.D. deve visualizar dados segundo padro Y

Prioridade: Importante
[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados

Prioridade: Desejvel
16
2012.2
Prioridade: Essencial
Validao e Verificao de Requisitos

2012.2
Demonstrar que os requisitos definem o sistema que o cliente realmente deseja Custos com erros de requisitos so altos
Consertar um erro de requisitos aps entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementao
17
Validao e Verificao de Requisitos

Ser que realmente entendi o que o cliente deseja? Devo me certificar de que no houve falha em nossa interao (comunicao) H diversas tcnicas de validao
2012.2
18
Tcnicas de Validao e Verificao de Requisitos

Revises de Requisitos
Anlise manual sistemtica dos requisitos
UFPB - Especificao de Requisitos 2012.2
Prototipao
Uso de modelo executvel do sistema para avaliar requisitos
Gerao de Casos de Teste

Desenvolver testes especficos para os requisitos para avali-los
Anlise de Consistncia Automtica

Avaliar uma especificao dos requisitos
19
Verificao X Validao
Verificao Validao
entre modelos
20
estamos construindo o produto de maneira certa? (em relao a outros produtos)
estamos construindo o produto certo? (em relao a inteno dos fregueses)
2012.2
Revises de requisitos
Revises regulares devem ser feitas enquanto a definio de requisitos est sendo formulada. Ambos, cliente e fornecedor, devem ser envolvidos nas revises. Revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre desenvolvedores, clientes e usurios pode resolver problemas nos estgios iniciais.
2012.2
21
Inspees
criadas em 1972 por Fagan, na IBM, para melhoria da qualidade de cdigo hoje so utilizadas em qualquer tipo de artefato gerado pelo processo de desenvolvimento inspeo pode detectar de 30% a 90% dos erros existentes tcnica de leitura aplicvel a um artefato, buscando a localizao de erros ou defeitos no mesmo, segundo um critrio pr-estabelecido
22
2012.2
Inspees em Requisitos
Planejamento
Viso geral
Detec o
Coleo
Correo
Acompanhamento
Organizador Moderador Inspetor
Processo Papis Inspeo Artefatos

a serem inspecionados para conduzir a inspeo
Autor
Secretrio Relator
Tcnicas de leitura
Ad hoc Check lists Abstrao de erros baseada em Pontos de Funo Baseada em Perspectivas
23
Laitenberger01
2012.2
Inspees em Requisitos
Inspees baseadas em check lists:
Inspetores utilizam uma lista com os itens a serem verificados cada artefato tem uma lista especfica (Documento de Requisitos, Casos de Uso, Glossrios, Lxico Ampliado da Linguagem...) os defeitos so anotados no artefato sendo analisado aps a reviso, realizada uma reunio onde os problemas encontrados so relatados aos desenvolvedores
24
2012.2
Checklist
Pontos a serem avaliados/observados durante o processo de inspeo Depende do material a ser inspecionado (casos de uso, cenrios, DFDs, JSD...) Depende do enfoque da inspeo Taxonomia dos defeitos - o que procurar
25
2012.2
Exemplo OO
Checklist OO:
Todas as classes so representadas por retngulos com 1,2 ou 3 compartimentos? As classes possuem nomes diferentes? Existem classes sem relacionamentos definidos? Os atributos e os mtodos de cada classe so adequados aquela classe? Todo comportamento especificado possvel de ser contemplado atravs das associaes do modelo?
2012.2
26
Gerenciamento de Requisitos
Gerenciamento de requisitos o processo de controlar as mudanas dos requisitos durante
O processo da engenharia de requisitos E desenvolvimento do sistema
27
2012.2
Gerenciamento de Requisitos
Requisitos so inevitavelmente incompletos e inconsistentes
Requisitos novos surgem durante o processo de acordo com mudanas nas necessidades do negcio e um entendimento melhor do sistema desenvolvido Diferentes pontos de vista tm diferentes requisitos e esses geralmente so contraditrios
28
2012.2
Rastreamento
Responsvel por dependncias entre requisitos, suas origens e projeto do sistema Rastreamento de Origem
Associao entre requisitos e stakeholders que propuseram tais requisitos
29
2012.2
Rastreamento
Rastreamento de Requisitos Rastreamento de Projeto
Associao dos requisitos com o projeto
2012.2
Associao entre requisitos dependentes
Usar hipertexto ou referncia cruzada

Ou matriz de rastreamento
30
Rastreamento
1.Rastrear requisitos do usurio
Requisitos Produto (Caracter.)
Req A 1
Requisitos Detalhados (Casos de Uso)
Req B
procedimentos de teste 4.Rastrear requisitos do usurio no plano
2
Projeto
Modelos
3
Teste
Sutes Teste
4
Doc. Usurio
Plano
31
3.Rastrear requisitos nos
2012.2
nos do sistema 2.Rastrear requisitos no projeto
Rastreamento: Anlise de Impacto

Req A antes
ifreturnvalue>$5
Req A depois
ifreturnvalue>$2
2012.2
Req B
Req C
Req B Req C
Links dos requisitos devem ser marcados como revisar Linksrevisardevemseranalisados
32
Uma matriz de rastreabiidade
D= requisito da linha depende do requisito da coluna R= existe algum relacionamento entre os requisitos
UFPB - Especificao de Requisitos 33
2012.2
Estrutura de um Documento de Requisitos

1. Introduo 2. Definio dos Requisitos do Usurio 3. Especificao dos Requisitos do Sistema 4. Arquitetura do Sistema 5. Modelos do Sistema 6. Evoluo do Sistema 7. Apndices 8. ndice
2012.2
34
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
1. Introduo
1.1 Propsito do documento 1.2 Escopo do sistema 1.3 Glossrio, acrnimos e abreviaturas 1.4 Referncias 1.5 Descrio do resto do documento
35
2012.2
2. Descrio geral
2.1 Perspectiva do produto 2.2 Funes do produto 2.3 Caractersticas dos usurios 2.4 Restries gerais 2.5 Assertivas e dependncias
36
2012.2
3. Requisitos especficos
requisitos funcionais, no-funcionais, GUI com o usurio:
funcionalidade, interfaces externas, desempenho, restries, atributos do sistema, caract. qualidade, ...
37
2012.2
4. Arquitetura do Sistema 5. Modelos do Sistema
Diagrama de Atores Modelo de Caso de Uso Modelo de Anlise Modelo de Projeto Diagrama de Pacotes
6. Evoluo do Sistema (Futuro) 7. Apndices 8. ndice
38
2012.2
39
Vamos voltar a falar de modelos...

2012.2
Vamos relembrar um pouco....

Necessita de informao de Sistema
Mantem informao sobre

2012.2
Usa Usurios do sistema
Sistema de informao
Contrata
Constroem Desenvolvedores de Sistema
40
Pensando os sistemas
Observa o problema/contexto/domnio
41
2012.2
Faz comparaes
Modelagem
Pode guiar a elicitao de REQ
Pode auxiliar a representar as questes a responder Pode auxiliar a identificar requisitos ocultos
2012.2
Pode fornecer uma medida de progresso

Completeza do modelo -> completeza da elicitao
Pode auxiliar a descobrir problemas

Requisitos conflitantes Terminologia confusa ou escopo confuso Desacordo entre stakeholders
Pode auxiliar verificar nosso entendimento

Raciocinar sobre o modelo para entender suas consequncias
42
Auxilia visualizar o sistema e validar os requisitos
ER envolve modelagem...
Um modelo mais do que uma descrio
Esse modelo s til se o fenmeno modelado corresponde de forma sistemtica ao fenmeno do domnio sendo modelado
Livro Termos do modelo L: entidade P: entidade Autor: relao (1,n) autor (0,n) Pessoa
2012.2
Domnio da modelagem
Domnio da aplicao
Termos da aplicao L: livro P: pessoa E: escreve
43
Relembrando.. Notaes para a modelagem

Linguagem natural
Extremamente expressiva e flexvel til para elicitao Pobre na captura de relacionamentos chaves
2012.2
Captura estruturas e alguma semntica

Ex.: diagramas, tabelas etc
So visuais torna mais rpida a comunicao com os stakeholders
Notao formal
Semntica precisa, extensvel e possibilita raciocnio automtico Modelos matemticos (ex.: teoria de conjuntos, mquina de estado etc) Modelos muito detalhados
44
Notao semi-formal
Modelo de anlise
Fornece uma descrio dos domnios informacional, funcional e comportamental necessrios a um sistema baseado em computador (Pressman, 2010) medida que o modelo de anlise evolui, certos elementos tornam-se relativamente estveis, fornecendo uma base slida para as tarefas posteriores de projeto.
45
2012.2
Modelo de anlise Utilidade

Focalizar a ateno nas caractersticas importantes do sistema, dando menos ateno s menos importantes Discutir modificaes e correes nos requisitos do usurio com baixo custo e mnimo risco Verificar se o analista conhece, corretamente, o ambiente do usurio e o documentou de uma tal maneira que os projetistas e programadores possam construir o sistema
2012.2
46
Modelo de anlise Elementos constituintes

Elementos baseado em cenrios
O sistema descrito do ponto de vista do usurio (ex.: casos de uso) Cada cenrio de uso implica em um conjunto de objetos que so manipulados medida que um ator interage com o sistema Esses objetos so designados de classes (uma coleo de coisas que tem atributos similares e comportamentos comuns)
2012.2
Elementos baseado em classe
Elementos comportamentais
O comportamento de um sistema baseado em computador pode ter um profundo efeito sobre o projeto O modelo de anlise deve fornecer elementos que descrevem o comportamento
Elementos orientados a fluxo

A informao transformada medida que ela flui por um sistema baseado em computador
47
Modelo de contexto
Normalmente, realizado no estgio inicial da especificao e anlise de requisitos Principal objetivo definir os limites do sistema
O que o sistema e o que o ambiente do sistema?
Sistema de contabilidade da agncia
Banco de dados de contas
Sistema de operao
Sistema de caixa eletrnico Sistema de atendimento da agncia
Sistema de manuteno
Banco de dados de operao
48
2012.2
O modelo de contexto do projeto j foi realizado?

Esboce em 5min o modelo de contexto do seu projeto.
UFPB - Especificao de Requisitos 2012.2
49
Modelos de comportamento
So usados para descrever o comportamento geral do sistema
Modelos de fluxos de dados modelam o processamento de dados no sistema
Modelos de mquina de estados modelam como o sistema reage aos eventos
2012.2
50
Modelo de fluxo de dados
51
2012.2
Diagrama de fluxo de dados (DFD)

Consiste em:
2012.2
processos, depsito de dados, fluxos e terminais (ou entidade externa).
52
Diagrama de fluxo de dados (DFD)

Processos: so representados como crculos ou bolhas no diagrama. Representam vrias funes individuais que o sistema executa. Funes transformam entradas em sadas. Fluxos: so representados por setas direcionadas curvas. Elas so as conexes entre os processos e representam a informao que os processos exigem como entrada e/ou as informaes que eles geram como sada. Depsitos de dados: so representados por duas linhas paralelas ou por uma elipse. Eles mostram colees de dados que o sistema deve manter na memria por um perodo de tempo. Terminadores: representam as entidades externas com as quais o sistema se comunica.
2012.2
53
Diagrama de Fluxo de Dados

Que funes deve o sistema executar? Quais so as interaes entre as funes? Que transformaes deve executar o sistema? Que entradas so transformadas em que sadas? Que espcie de trabalho faz o sistema? Onde ele obtm a informao para faz-lo? Para onde ele remete os resultados do trabalho?
54
2012.2
Forma de Representao
simbolizado por meio de uma seta, com a ponta indicando a direo do fluxo. [ CHRIS GANE / SARSON]. J DeMarco, diz que os fluxos de dados um tubo, atravs do qual fluem pacotes de informaes. A maior parte dos fluxos de dados movimentaram-se entre processos, mas eles podem tambm fluir para dentro ou para fora de arquivos, indo para caixas-destino e vindo de caixas-fonte. simbolizado por meio de vetores.
55
2012.2
Notao
Notao bsica utilizada no DFD:
2012.2
Entidade Externa
Envia ou recebe informaes do sistema. Fora dos limites do sistema
Processo
Transformador de informaes interno aos limites do sistema.
Depsito de Dados Fluxo de dado Armazenamento de dados no sistema.
56
Algumas convenes
Nomes em maiscula e ligadas por hfen; Dois fluxos de dados diferentes no podem ter o mesmo nome; Os nomes so escolhidos para representarem no apenas o dado que flui sobre o tubo, mas tambm o que sabemos sobre o dado Evite nomes vagos como dados e informao
57
2012.2
Exemplo 1
Eventos:
2012.2
Aluno solicita matrcula.
dados_matrcula
Aluno comprovante Matricular Aluno
Cursos
Matrculas
58
Exemplo 2
Eventos:
2012.2
hora de gerar a Folha de Pagamentos.
Recursos Humanos
folha_pagto
Emitir Folha de Pagamento
Funcionrios Descontos Abonos
59
Abordagem top-down
Abordagem top-down:
2012.2
Exploso de Processo
60
Exemplo 3 Diagrama de contexto

Paciente
dados_pessoais
marcaoconsulta
Paciente
nota_ consultas
dados_mdico
Mdico
escala info_pagto valor_consulta
ficha_paciente
61
Sistema de Controle de Atendimento Mdico
2012.2
Figura 0 - Controle de Atendimento Mdico

especialidade
Paciente
dados_pessoais marcaoconsulta
Paciente
nota_ consultas
horrios
dados_mdico Mdico
info_pagto
Controlar Pagamentos 2
pagto
Gerenciar Mdicos 3
escala valor_consulta ficha_paciente
valor
total_ Consultas paciente
horrio_semana
62
2012.2
Controlar Consultas 1
disponibilidade
Consultas Mdicos
nome
Pacientes
Um fluxo que parte de um depsito normalmente interpretado como uma leitura ou um acesso feito s informaes desse depsito.
Pode significar que:
Um pacote isolado de dados foi recuperado do depsito: por exemplo, um depsito chamado CLIENTES, de onde cada pacote contm informaes de nome, endereo e telefone de clientes. Um fluxo tpico que sasse desse depsito envolveria a recuperao de um pacote completo de informaes sobre um cliente. Mais de um pacote foi recuperado do depsito: Por exemplo o fluxo poderia recuperar pacotes de informaes sobre todos os clientes da cidade de So Paulo a partir do depsito CLIENTES. Apenas uma parte do pacote foi recuperada do depsito: apenas a parte do n do telefone de um cliente foi recuperada do depsito CLIENTES. Parte de mais de um pacote foram recuperados do depsito: um fluxo pode recuperar do depsito CLIENTES o cdigo postal de todos os clientes do estado de So Paulo.
2012.2
63
Importante
Na maioria dos casos os fluxos so rotulados, entretanto no necessitamos rotular um fluxo se todo um grupo de um pacote entra ou sai do depsito. Um fluxo que parte de um depsito normalmente interpretado como uma leitura ou um acesso feito s informaes desse depsito.
64
2012.2
Exerccio
Indicar o fluxos existentes no DFD o processo de compras de em um supermercado. Considerar apenas as etapas de passagem do produto pelo caixa, pagamento e empacotamento das mercadorias.
Processos: passar produtos no balco, registrar produtos, pagamento, empacotamento, colocar produtos no carrinho Entidades: cliente, caixa, empacotador Depsitos: carrinho, pacote, caixa registradora.
65
2012.2
Referncia
DEMARCO, Tom Anlise Estruturada e Especificao De Sistema Editora Campus; GANE, Chris, SARSON, Trish: Anlise Estruturada de Sistemas Livros Tcnicos e Cientficos Editora Ltda. SOMMERVILLE, Ian. Engenharia de Software, 8 ed. So Paulo: Pearson Addison-Wesley, 2007.
Captulo 6 - Requisitos de Software. Captulo 7 Processos de Engenharia de Requisitos
66
2012.2

ERS - NA10 - Modelagem - P12 - 2-3

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ERS - NA10 - Modelagem - P12 - 2-3

Enviado por

Direitos autorais:

Formatos disponíveis

CI-UFPB Engenharia de Requisitos

A10 Especificao e modelagem Parte I

O que veremos hoje?

Breve viso das linguagens de modelagem Modelo de anlise

Vamos relembrar um pouco...

Especificao de Requisitos Propriedades do domnio Computadores Requisitos Programas

Especificao dos requisitos

Especificao dos requisitos

Especificao dos requisitos

Recursos, segurana e garantia de qualidade...

O processo de Engenharia de Requisitos

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

O processo de Engenharia de Requisitos

UFPB - Especificao de Requisitos

Elicitao e Anlise de requisitos

UFPB - Especificao de Requisitos

Classificao dos Requisitos

UFPB - Especificao de Requisitos

Cliente o responsvel por resolver conflitos e ambigidades

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

Em princpio, o sistema deve abranger todos os requisitos de essenciais para desejveis

UFPB - Especificao de Requisitos

Outras escalas de priorizao de requisitos: [Wiegers]

UFPB - Especificao de Requisitos

[RNF001] Consulta X ao B.D. deve visualizar dados segundo padro Y

[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados

Validao e Verificao de Requisitos

UFPB - Especificao de Requisitos

Validao e Verificao de Requisitos

UFPB - Especificao de Requisitos

Tcnicas de Validao e Verificao de Requisitos

Gerao de Casos de Teste

Anlise de Consistncia Automtica

UFPB - Especificao de Requisitos

estamos construindo o produto de maneira certa? (em relao a outros produtos)

estamos construindo o produto certo? (em relao a inteno dos fregueses)

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

Organizador Moderador Inspetor

Processo Papis Inspeo Artefatos

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

UFPB - Especificao de Requisitos

Associao entre requisitos dependentes

Usar hipertexto ou referncia cruzada

UFPB - Especificao de Requisitos

Requisitos Detalhados (Casos de Uso)

procedimentos de teste 4.Rastrear requisitos do usurio no plano

UFPB - Especificao de Requisitos

3.Rastrear requisitos nos

nos do sistema 2.Rastrear requisitos no projeto

Rastreamento: Anlise de Impacto

Links dos requisitos devem ser marcados como revisar Linksrevisardevemseranalisados

UFPB - Especificao de Requisitos

Uma matriz de rastreabiidade

UFPB - Especificao de Requisitos 33

Estrutura de um Documento de Requisitos

UFPB - Especificao de Requisitos

6. Evoluo do Sistema (Futuro) 7. Apndices 8. ndice