This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
� Assegurar que essas características correspondem aos objectivos do negócio
� Verificar se o sistema desenvolvido satisfaz ou não as características identificadas
Engenharia de Requisitos 4
Definição de Requisito� Um UHTXLVLWR é uma característica do
sistema, ou a descrição de algo que o sistema é capaz de fazer para satisfazer os seus objectivos
� Em princípio os requisitos devem versar sobre o espaço do problema, R�TXr, e não sobre o espaço da solução, R�FRPR, contudo pode acontecer que os requisitos coloquem restrições ao espaço da solução
3
Engenharia de Requisitos 5
Tipos de Requisitos� Os UHTXLVLWRV�IXQFLRQDLV descrevem uma
interacção entre o sistema e o seu ambiente� Os UHTXLVLWRV�QmR�IXQFLRQDLV descrevem
restrições ao sistema que limitam as possibilidades de implementação. Têm impacto no desenho
� Os UHTXLVLWRV�GR�GHVHQYROYLPHQWRdescrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores
Engenharia de Requisitos 6
Requisitos Funcionais� Contexto do sistema� Reacção a estímulos externos� Estados do sistema� Informação manipulada pelo sistema� ...
4
Engenharia de Requisitos 7
Requisitos Não-Funcionais� Usabilidade� Desempenho� Segurança� Robustez� Fiabilidade� Disponibilidade� Portabilidade� Tecnologia de implementação� Ambiente físico da instalação� ...
Actividades1. Estudo de viabilidade – o sistema faz
sentido do ponto de vista do negócio e é realizável com o orçamento disponível
2. Análise de requisitos – entender como vai ser o sistema analisando diversas fontes
3. Definição de requisitos – descrever os requisitos de modo a serem entendido pelos utilizadores e clientes
4. Especificação de requisitos – descrever detalhadamente os requisitos de modo a permitir fazer a ponte com a solução
Engenharia de Requisitos 10
Análise de Requisitos� Fontes dos Requisitos
� Clientes e utilizadores� Organização e outros sistemas existentes� Documentação existente� Matriz de tipos de requisitos� Reutilização de requisitos� Modelos do domínio� Modelo do sistema actual
6
Engenharia de Requisitos 11
Análise de Requisitos� Identificar as pessoas, os processos e
os recursos envolvidos no problema e documentar as suas relações
� Identificar a fronteira do sistema� Separar os requisitos em três
categorias:� Têm que ser satisfeitos� É desejável que sejam satisfeitos� Podem ser satisfeitos mas é possível
eliminar
Engenharia de Requisitos 12
Documentos de Requisitos� 'HILQLomR�GH�5HTXLVLWRV contém uma lista
de tudo o que o cliente espera que o sistema faça. Define um entendimento entre o cliente e a equipa de desenvolvimento sobre o que é que o sistema deve fazer. É escrito pelos clientes e os analistas de requisitos.
� (VSHFLILFDomR�GH�5HTXLVLWRV rescreve o documento de definição de requisitos em termos técnicos mais apropriados à equipa de desenvolvimento e às actividades de desenho. É escrito pelos analistas de requisitos.
7
Engenharia de Requisitos 13
Problemas dos Requisitos� Linguagem natural é inevitável no
levantamento de requisitos� Dificuldades comunicação entre os utilizadores e a
equipa de desenvolvimento� Os utilizadores não concordam sobre os requisitos
� Por vezes não é possível definir completamente o problema
� Os requisitos evoluem durante o processo desenvolvimento
� O levantamento de requisitos origina problemas de equilíbrio de poder
� A descrição do problema é influenciada pela solução
Engenharia de Requisitos 14
Qualidades dos Requisitos� &RHUrQFLD – não devem ser ambíguos ou
incoerentes� &RPSOHWXGH – todos os estados possíveis,
alterações de estados, entradas, etc, devem ser descritos� Externamente Completos – todas as ligações com
o ambiente desejadas pelo cliente estão descritas� Internamente Completos – não existem
referências indefinidas entre requisitos� 5HDOLVPR – o que é pedido pelo cliente deve
ser realizável
8
Engenharia de Requisitos 15
Qualidades dos Requisitos� &ODUH]D�– a descrição dos requisitos deve
ser simples e clara para os utilizadores� 9DOLGDGH – o requisito deve descrever algo
que é de facto relativo ao problema� &HUWLILFDomR – deve ser possível escrever
testes que demonstram que o requisito foi satisfeito
� 5DVWUHDELOLGDGH – deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito
Engenharia de Requisitos 16
Certificação de Requisitos� Os requisitos devem ser escritos de uma
forma que permita a sua verificação objectiva. Para isso devem seguir-se as seguintes regras:� Escrever uma quantidade para cada advérbio e
adjectivo de modo a que o significado dos qualificadores seja claro e não ambíguo
� Substituir pronomes por nomes de entidades� Assegurar que cada substantivo é definido
exactamente uma única vez nos documentos de requisitos
9
Engenharia de Requisitos 17
Factores Sociais e Organizacionais� O sistema vai levar à redução de
gestores intermédios� Contudo, os gestores intermédios são uma
importante fonte de informação sobre os requisitos do sistema
� Os utilizadores e a equipa de desenvolvimento não constituem um todo partilhando os mesmos objectivos pelo que vão surgir preconceitos entre os intervenientes
Engenharia de Requisitos 18
Intervenientes� Existem diferentes intervenientes:
� Gestores de Processo, definem a calendarização� Clientes e Utilizadores, entendem os requisitos� Gestores do Negócio, entendem o impacto do
sistema no negócio� Arquitectos do Sistema, usam os requisitos para a
definição da arquitectura� Avaliadores do Sistema, recolhem dados para os
testes e desenvolvem grupos de testes� Os diferentes intervenientes podem ter
visões conflituosas sobre os requisitos, e.g., entre o cliente e o utilizador
10
Engenharia de Requisitos 19
Equipa -> Utilizadores� Não sabem o que querem� Não são capazes de exprimir o que
querem� As suas necessidades são políticas� Querem as coisas já� Não conseguem atribuir prioridades às
necessidades� Não assumem responsabilidades� Não aceitam compromissos� ...
Engenharia de Requisitos 20
Utilizadores -> Equipa� Não entendem as necessidades operacionais� Dão demasiada importância aos aspectos
técnicos� Tentam dizer-nos qual deve ser o nosso
trabalho� Não conseguem implementar requisitos
muito claros� Estão sempre fora do orçamento� Estão sempre atrasados� Pedem tarefas aos utilizadores que os
desviam da sua tarefa principal� ...
11
Engenharia de Requisitos 21
Técnicas� Representação de Requisitos� Prototipagem� Matriz Volere� Casos de Uso� Figuras Densas (Rich Pictures)
Engenharia de Requisitos 22
Representação de Requisitos� O objectivo das representações de
requisitos é:� Reduzir a imprecisão associada à
linguagem natural� Separar a descrição do problema da
construção da solução
12
Engenharia de Requisitos 23
Representações� Axiomática� Linguagem� Dados Abstractos� Diagramas de Fluxo de Dados� Tabelas de Decisão� Diagramas de Transição� Baseado em Objectos
Engenharia de Requisitos 24
Axiomática� Especifica as propriedades básicas do
sistema, como axiomas, e como o comportamento gera novas propriedades, os teoremas
� Exige que o conjunto de axiomas seja completo e coerente
� Particularmente útil para sistemas peritos
13
Engenharia de Requisitos 25
Axiomática – Exemplo (1)
Engenharia de Requisitos 26
Axiomática – Exemplo (2)
14
Engenharia de Requisitos 27
Linguagem� Descreve requisitos como cadeias de
caracteres de uma linguagem� Permite automatizar a verificação da
completude e da coerência dos requisitos
� Particularmente útil no desenvolvimento de compiladores
Engenharia de Requisitos 28
Dados Abstractos� Descreve o sistema baseado nos dados� Permite ignorar como os dados estão
implementados e são manipulados� Particularmente útil quando o problema
não está baseado em funções
15
Engenharia de Requisitos 29
Diagramas de Fluxo de Dados� Representa
� Processamento de dados� Relações de produção e consumo de
dados� Repositórios de dados
� Permite ignorar o fluxo de execução
Engenharia de Requisitos 30
DFDs - Exemplo
Libraryuser
Checkuser
Item database
Checkitem
Librarycard
User status
requesteditem
Issueitem
Itemstatus
issueditem
updateuser
details
UserID
ItemID
Update detailsitem details
Libraryassistant
return date
User database
update detailsuser details
16
Engenharia de Requisitos 31
Tabelas de Decisão� Representam regras estímulo/resposta
quando um conjunto de condições se verifica
Engenharia de Requisitos 32
Diagramas de Transição� Representam o sistema em termos da
sua reacção a eventos internos e externos
� Permite ignorar a sequência total de execução associada a cada interacção e, desta forma, o comportamento global do sistema
17
Engenharia de Requisitos 33
Diagramas de Transição
Engenharia de Requisitos 34
Baseado em Objectos� Estende a abordagem estática dos
dados abstractos com os conceitos de:� Encapsulação� Hierarquia de classes� Herança � Polimorfismo
Escolher uma Representação& É necessário analisar as diferentes técnicas
de representação de acordo com os seguintes itens:' Implementação: Ajuda na implementação?' Testes: Ajuda nos testes?' Legibilidade: A especificação é legível para os
peritos do domínio?' Manutenção: A especificação pode ser útil
durante a manutenção?' Modularidade: Permite decomposição?' Expressividade: Com que facilidade representa as
abstracções do problema?
Engenharia de Requisitos 38
Escolher uma Representação' Correcção: Permite a detecção de incorrecções ou
incoerências?' Verificação: A especificação é verificável
formalmente?' Geração: Se possui geração de código este é
eficiente?' Suporte Computacional: Possui suporte
computacional?' Incompleta: Suporta informação incompleta?' Aprendizagem: Qual é a curva de aprendizagem?' Disciplina: Conduz a uma disciplina de escrita de
requisitos?
20
Engenharia de Requisitos 39
Protótipos para Requisitos� Os protótipos permitem detalhar e
completar a lista de requisitos � A prototipagem pode ser aplicada a:
� Interfaces� Validar requisitos funcionais� Validar requisitos não funcionais como o
desempenho� Mostrar, à gestão, da viabilidade da
aplicação� Desenho� ...
Engenharia de Requisitos 40
Tipos de Protótipos� Consideram-se dois tipos de protótipos:
� Protótipo descartável – o principal objectivo é validar ou clarificar os requisitos
� Protótipo evolutivo – adicionalmente ao protótipo descartável também tem como objectivo o desenvolvimento incremental do sistema final
21
Engenharia de Requisitos 41
Técnicas para Prototipagem� Linguagens de especificação
executáveis – linguagens formais, e.g. Z
� Linguagens de alto nível – linguagens dinâmicas, e.g. Smalltalk
� Geradores de aplicações – geração de código, e.g. SQL
� Composição de componentes reutilizáveis – composição de componentes independentes, e.g. UNIX Shells
Engenharia de Requisitos 42
Matriz Volere� Estrutura a linguagem natural� Enumera requisitos não funcionais tipo
� Look and feel� Usabilidade� Desempenho� Operacionais� Manutenção e portabilidade� Segurança� Culturais e políticos� Legais
22
Engenharia de Requisitos 43
Matriz Volere
Engenharia de Requisitos 44
Matriz Volere� Exemplos de medidas para verificação
da conformância de requisitos� Requisito funcional – o resultado de um
cálculo é o esperado� Desempenho – 98% das transacções têm
um tempo de resposta inferior a 1,5 segundos
� Operacionais – 90% de um painel de trabalhadores conseguem utilizar o produto numa simulação das condições operacionais
23
Engenharia de Requisitos 45
Matriz Volere� Manutenção – cada 10 alterações ao
código devem estar operacionais em 3 semanas
� Segurança – o produto deve estar conforme uma determinada norma
� Legal – o departamento jurídico deve certificar que o produto está de acordo com a legislação
� Look and feel – está de acordo com uma norma
Engenharia de Requisitos 46
Casos de Uso� Os casos de uso descrevem o sistema
do ponto de vista do utilizador. As vantagens são:� Delimitam o sistema� Cada caso de uso pode ser isolado dos
restantes pelo que facilita a decomposição do espaço do problema
� Podem ser usados para estimar o tempo e o esforço necessário ao desenho e codificação do sistema
� O desenvolvimento do sistema pode ser seguido em termos dos seus casos de uso
24
Engenharia de Requisitos 47
Casos de Uso
BANCO
Cliente do Banco
Levantar Dinheiro
Depositar Dinheiro
Transferir Dinheiro entre Contas
Autenticação
<<include>>
<<include>>
<<include>>
Engenharia de Requisitos 48
Figuras Densas� Permitem fazer uma análise do negócio
ao nível de abstracção dos clientes e utilizadores� Registar e raciocinar sobre o contexto do
trabalho e a forma como este influência o desenho
� Início da ponte entre o negócio e os requisitos
� Técnica que facilita a interacção e a comunicação entre os clientes e a equipa
25
Engenharia de Requisitos 49
Figuras Densas� Consideram os seguintes elementos
� Estrutura – refere os aspectos do contexto do trabalho que vão ser alterados
� Processo – refere as transformações que ocorrem no processo de trabalho
� Objectivos – refere as motivações de cada um dos intervenientes
� Devem-se captar as tensões entre os intervenientes
Engenharia de Requisitos 50
Figuras Densas
26
Engenharia de Requisitos 51
Validação de Requisitos
List of problems
Agreed actions
Requirementsdocument
Organisationalstandards
Organisationalknowledge
Requirementsvalidation
Engenharia de Requisitos 52
Validação de Requisitos� A validação de requisitos é o processo
que determina se a especificação de requisitos é coerente com a definição de requisitos, ou seja, se os requisitos satisfazem as necessidades dos clientes:( Cada especificação está relacionada com
um requisito no documento de definição de requisitos
( Cada requisito está tratado no documento de especificação de requisitos
27
Engenharia de Requisitos 53
Técnicas de Validação� Técnicas manuais
( Leitura( Cruzamento de informação( Entrevistas( Revisões( Listas de verificação( Cenários( Demonstração matemática
Engenharia de Requisitos 54
Técnicas de Validação� Técnicas automáticas são possíveis se
os requisitos estiverem representados de modo a poderem ser tratados computacionalmente – bases de dados, linguagens formais, protótipos( Cruzamento de informação( Prototipagem( Simulação( Demonstração matemática
28
Engenharia de Requisitos 55
Revisão de Requisitos
Plan review Distributedocuments
Prepare forreview
Hold reviewmeeting
Follow-upactions
Revisedocument
Engenharia de Requisitos 56
Revisão de Requisitos& Juntar representantes da equipa de
desenvolvimento, do cliente e dos utilizadores para:' Rever objectivos do sistema' Comparar os requisitos com os objectivos para
confirmar se são todos necessários' Verificar a completude e correcção dos requisitos' Se foram identificados riscos avaliar com o cliente
se a abordagem de solução proposta é a melhor' Definir como é que a satisfação de requisitos vai
ser verificada durante o desenvolvimento
29
Engenharia de Requisitos 57
Métricas para Requisitos& Desempenho – transacções processadas por
segundo, tempo de resposta a um pedido do utilizador, tempo de refrescar o ecrã
) Usabilidade – tempo de treino, número de menus de ajuda
) Robustez – tempo de recomeçar após faltas) Portabilidade – número de sistemas alvo,
número de comandos dependentes do alvo) Tempo de desenvolvimento – uma função do
número de requisitos dá uma estimativa do esforço de desenvolvimento, e.g., COCOMO
Engenharia de Requisitos 58
Métricas para Requisitos) Impacto – qual o impacto que a alteração de
um particular tipo de requisitos tem no sistema
) Complexidade – qual a complexidade associada à implementação dos requisitos. Para isso pode-se perguntar aos arquitectos e avaliadores sobre cada requisito:* Conhecido* Novo mas parecido* Novo mas será possível encontrar uma solução* Não se entende e não se sabe se será possível
encontrar uma solução* Não se entende e não é possível encontrar uma
solução
30
Engenharia de Requisitos 59
Casos Notáveis� Padrões de Interacção com o Cliente
( Linda Rising( Customer Interaction Patterns( In Harrison2000. Capítulo 26.
� Um Processo de Análise de Requisitos para Desenvolvimento com Objectos( Bruce Whitenack( RAPPeL: A Requirements Analysis Process