António Rito Silva Rito.Silva@inesc-id - Autenticação · António Rito Silva [email protected]. Sumário Caracterização Objectivos Problemas Qualidades Factores Não-Técnicos

Engenharia de Requisitos

António Rito [email protected]

Sumário

� Caracterização� Objectivos� Problemas� Qualidades

� Factores Não-Técnicos� Técnicas

Engenharia de Requisitos 2

� Técnicas� Avaliação e Validação� Casos Notáveis� Exemplo� Conclusões

Objectivos

� Identificação de quais são as características do sistema a desenvolver

� Assegurar que essas características correspondem aos objectivos do


correspondem aos objectivos do negócio

� Verificar se o sistema desenvolvido satisfaz ou não as características identificadas

Definição de Requisito

� Um requisito é 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


� Em princípio os requisitos devem versar sobre o espaço do problema, o quê, e não sobre o espaço da solução, o como, contudo pode acontecer que os requisitos coloquem restrições ao espaço da solução

Tipos de Requisitos

� Os requisitos funcionais descrevem uma interacção entre o sistema e o seu ambiente

� Os requisitos não-funcionaisdescrevem restrições ao sistema que limitam as possibilidades de


limitam as possibilidades de implementação

� Os requisitos do desenvolvimentodescrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores

Requisitos Funcionais

� Contexto do sistema� Reacção a estímulos externos� Estados do sistema� Informação manipulada pelo sistema� ...


� ...

Requisitos Não-Funcionais

� Usabilidade� Desempenho� Fiabilidade� Disponibilidade� Segurança


� Segurança� Portabilidade� Tecnologia de implementação� Ambiente físico da instalação� ...

Requisitos de Desenvolvimento� Manutenção� Evolução� Documentação� Processo� Orçamento


� Orçamento� Recursos humanos� Recursos computacionais� ...

Actividades

1. 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


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

Análise de Requisitos

� Fontes dos Requisitos� Clientes e utilizadores� Organização e outros sistemas existentes� Documentação existente� Matriz de tipos de requisitos


� Matriz de tipos de requisitos� Reutilização de requisitos� Modelos do domínio� Modelo do sistema actual

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


� Separar os requisitos em três categorias:� Têm que ser satisfeitos� É desejável que sejam satisfeitos� Podem ser satisfeitos mas é possível

eliminar

Documentos de Requisitos� Definição de Requisitos 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.


e os analistas de requisitos.� Especificação de Requisitos 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.

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


� 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

Qualidades dos Requisitos

� Coerência – não devem ser ambíguos ou incoerentes

� Completude – todos os estados possíveis, alterações de estados, entradas, etc, devem ser descritos� Externamente Completos – todas as ligações


� 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

� Realismo – o que é pedido pelo cliente deve ser realizável

Qualidades dos Requisitos

� Clareza – a descrição dos requisitos deve ser simples e clara para os utilizadores

� Validade – o requisito deve descrever algo que é de facto relativo ao problema

� Certificação – deve ser possível escrever testes que demonstram que o requisito foi


testes que demonstram que o requisito foi satisfeito

� Rastreabilidade – deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito

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


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

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


� 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

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


� 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

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� ...

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� ...

Técnicas

� Representação de Requisitos� Prototipagem� Matriz Volere� Casos de Uso� Figuras Densas (Rich Pictures)


� Figuras Densas (Rich Pictures)

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


construção da solução

Representações

� Axiomática� Linguagem� Dados Abstractos� Diagramas de Fluxo de Dados� Tabelas de Decisão


� Tabelas de Decisão� Diagramas de Transição� Baseado em Objectos

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


� Exige que o conjunto de axiomas seja completo e coerente

� Particularmente útil para sistemas peritos

Linguagem

� Descreve requisitos como cadeias de caracteres de uma linguagem

� Permite automatizar a verificação da completude e da coerência dos requisitos


requisitos� Particularmente útil no

desenvolvimento de compiladores

Dados Abstractos

� Descreve o sistema baseado nos dados

� Permite ignorar como os dados estão implementados e são manipulados

� Particularmente útil quando o


� Particularmente útil quando o problema não está baseado em funções

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

Tabelas de Decisão

� Representam regras estímulo/resposta quando um conjunto de condições se verifica


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


execução associada a cada interacção e, desta forma, o comportamento global do sistema

Diagramas de Transição


Baseado em Objectos

� Estende a abordagem estática dos dados abstractos com os conceitos de:� Encapsulação� Hierarquia de classes


� Herança � Polimorfismo

� Facilita a classificação de entidades

Baseado em Objectos

1Unidade

Pessoa

Orgão

Vínculo

1 *

*

*

1 *

1

*

Função

FunçãoPrimaria FunçãoInerente

*

1 *


Pessoa

Discente Funcionario

Cargo

Docente

FunçãoPrimaria FunçãoInerente

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


� 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?

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 e este é

eficiente?� Suporte Computacional: Possui suporte


� 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?

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


� Validar requisitos não funcionais como o desempenho

� Mostrar, à gestão, da viabilidade da aplicação

� Desenho� ...

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 evolutivo – adicionalmente ao protótipo descartável também tem como objectivo o desenvolvimento incremental do sistema final

Técnicas para Prototipagem

� Linguagens de especificação executáveis – linguagens formais, e.g. B

� Linguagens de alto nível – linguagens dinâmicas, e.g. Smalltalk

� Geradores de aplicações – geração de


� 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

Matriz Volere

� Estrutura a linguagem natural� Enumera requisitos não funcionais

tipo� Look and feel

� Usabilidade� Desempenho


� Desempenho� Operacionais� Manutenção e portabilidade� Segurança� Culturais e políticos� Legais

Matriz Volere


Matriz Volere

� Exemplos de medidas para verificação 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


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

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


� 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

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


problema� O desenvolvimento do sistema pode ser seguido

em termos dos seus casos de uso� Podem ser usados para estimar o tempo e o

esforço necessário ao desenho e codificação do sistema

Cenários� Uma sequência de passos que

descreve uma interacção entre um utilizador e um sistema� O utilizador acede a “Agrupamento”,

onde Agrupamento é o nome do agrupamento. O sistema mostra no ecrã os turnos do agrupamento seleccionado.


os turnos do agrupamento seleccionado. Para cada turno, são visualizados:� O nome do turno;� As aulas a ele associadas (dia da semana,

hora de início e de fim e sala);� O número dos grupos inscritos no turno

(quando não tem grupos aparece a mensagem “Sem Grupos”).

Caso de Uso

� É um conjunto de cenários agrupados de acordo com um objectivo do utilizador� Caso de Uso: Visualizar Turnos do

Agrupamento� Objectivo: Esta funcionalidade permite


� Objectivo: Esta funcionalidade permite ao utilizador visualizar, caso existam, os turnos associados ao agrupamento seleccionado e para cada turno o número dos grupos nele inscritos.

� Cenário 1: Existem turnos� Cenário 2: Não existem turnos

Actores

� Um actor é um papel que um utilizador toma em relação com um sistema� Humanos� Outros sistemas

� Um utilizador pode ter vários papéis� Os actores levam a cabo casos de uso


� Os actores levam a cabo casos de uso� Os actores podem ser facilmente

identificados antes da identificação dos casos de uso

� Os eventos externos facilitam a identificação dos actores

Formato Caso de Uso

� O formato deve ser ajustado às necessidades

� Um exemplo de formato:� Nome� Objectivo� Actores


� Actores� Pré-condições� Cenário Principal� Cenários Alternativos� Pós-condições

Visualizar Turnos do Agrupamento� Objectivo:

� Esta funcionalidade permite ao utilizador visualizar, caso existam, os turnos associados ao agrupamento seleccionado e para cada turno o número dos grupos nele inscritos.

Actores:


� Actores: � Qualquer utilizador do sistema Fénix

� Pré-Condições: � A disciplina seleccionada tem que ter

pelo menos um agrupamento.

Visualizar Turnos do Agrupamento� Cenário Principal:

1. O utilizador acede a “Agrupamento”, onde Agrupamento é o nome do agrupamento.

2. O sistema mostra no ecrã os turnos do agrupamento seleccionado.


agrupamento seleccionado.3. Para cada turno, são visualizados:

1. O nome do turno;2. As aulas a ele associadas (dia da semana,

hora de início e de fim e sala);3. O número dos grupos inscritos no turno

(quando não tem grupos aparece a mensagem “Sem Grupos”).

Visualizar Turnos do Agrupamento� Cenário Alternativo:

1. Passo 1 do Cenário Principal.2. Como não existem turnos do

agrupamento seleccionado, o sistema mostra no ecrã a mensagem “Não existem turnos”.


existem turnos”.

� Pós-Condições:� O estado do sistema permanece

inalterado

Diagramas de Casos de Uso

Diagrama Casos de Uso - Estudante

Visualizar Grupo do Turno

Inscrever em Grupo

Alterar Turno

Remover Inscrição

<<include>>

<<include>>

<<include>>

<<include>>


Estudante

Visualizar Agrupamentos da Disciplina

Visualizar Turnos do Agrupamento

Criar Grupo <<include>>

<<include>>

Relações entre Casos de Uso

� Inclusão – quando nos estamos a repetir em dois ou mais casos de uso

� Extensão – um caso de uso especial estende um outro caso de uso, uma variação de um comportamento que


variação de um comportamento que se representa fora do caso de uso original de forma controlada, indicando os pontos de extensão

Casos de Uso Revisitados

� 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


problema� O desenvolvimento do sistema pode ser seguido

em termos dos seus casos de uso� Podem ser usados para estimar o tempo e o

esforço necessário ao desenho e codificação do sistema

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


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

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


ocorrem no processo de trabalho� Objectivos – refere as motivações de

cada um dos intervenientes

� Devem-se captar as tensões entre os intervenientes

Figuras Densas


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:


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

Técnicas de Validação� Técnicas manuais

� Leitura� Cruzamento de informação� Entrevistas� Revisões

Listas de verificação


� Listas de verificação� Cenários� Modelos pré-definidos� Demonstração matemática

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� Modelos pré-definidos� Prototipagem� Simulação� Demonstração matemática

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

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


menus de ajuda� 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

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:


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

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


para Desenvolvimento com Objectos� Bruce Whitenack� RAPPeL: A Requirements Analysis

Process Pattern Language for Object Oriented Development

� http://www.bell-labs.com/people/cope/Patterns/Process/RAPPeL/rapel.html

� Padrões de Interacção com o Cliente� É uma Relação não é um Negócio� Conhecer o Cliente� Construir Confiança� Ouvir, Ouvir, Ouvir� Ser Reactivo

Casos Notáveis


� Ser Reactivo� Reuniões com o Cliente� Mostrar Integridade� Não Aquecer� Ter a Noção dos Limites� Ter Boas Maneiras

É uma Relação não é um Negócio� Problema: Como devemos tratar os clientes de

modo a ficarem contentes com os nossos produtos?� Forças:

� A equipa costuma dar ênfase ao produto e não ao cliente

� Queremos satisfazer os clientes� Solução:


� Focar a relação com o cliente não apenas na venda do produto

� Conhecer o cliente e usar esse conhecimento no produto de modo a ganhar a confiança do cliente

� Contexto Resultante:� Uma relação continuada significa continuação do

negócio

Conhecer o Cliente� Problema: Qual a melhor forma de estabelecer

uma relação com o cliente?� Forças:

� A equipa normalmente pensa que conhecer o produto é suficiente

� A equipa e o cliente querem resultados rápidos� Solução:

� Aprender com o cliente


� Aprender com o cliente� Aprender a linguagem do cliente� Pensar nas necessidades dos clientes e ajudá-los a

ter sucesso� Contexto Resultante:

� Quando conhecemos os valores do cliente tornamos-nos numa extensão da sua empresa

Construir Confiança� Problema: Como se solidifica a relação com o

cliente?� Forças:

� Clientes querem contactar da equipa aqueles com que se sentem confortáveis

� As pessoas são relutantes em gastar o seu tempo com quem não conhecem

� Solução:


� Solução:� Cada contacto deve servir para aumentar a

confiança� Ter encontros pessoais e não apenas por correio

electrónico� Contexto Resultante:

� Numa relação baseada na confiança a interacção torna-se mais fácil

� Procurar manter a relação, é mais fácil construir uma relação do que a reconstruir

Ouvir, Ouvir, Ouvir� Problema: Qual é a forma mais eficaz de

desenvolver a relação com o cliente?� Forças:

� Muitos clientes pedem o nosso tempo� É difícil estar sempre a 100%

� Solução:� Ouvir o cliente e mostrar interesse genuíno


� Ouvir o cliente e mostrar interesse genuíno� Recolher informação fazendo perguntas� Ser flexível e positivo

� Contexto Resultante:� O cliente vai sentir-se estimado e a sua

confiança vai aumentar

Ser Reactivo� Problema: Qual é a resposta aceitável aos pedidos

do cliente?� Forças:

� Queremos ser atenciosos com os clientes� Nem sempre podemos dar uma resposta imediata

� Solução:� Responder ao telefonemas dos clientes no mesmo


� Responder ao telefonemas dos clientes no mesmo dia

� Confirmar todos os pedidos que o cliente faça por correio electrónico

� Contexto Resultante:� Os clientes estão informados no nosso progresso na

resolução dos seus pedidos

Reuniões com o Cliente� Problema: Tem que se ir a reuniões com os

clientes mas parecem ser uma perda de tempo.� Forças:

� Desejamos que os clientes estejam a par do estado actual do produto

� Estratégias de gestão de tempo desencorajam as reuniões

� Solução:


� Solução:� Chegar à reunião com antecedência para conhecer

as pessoas� Após a reunião dispor de algum tempo para falar

acerca de interesses comuns do negócio� Contexto Resultante:

� As reuniões transformam-se numa experiência mais positiva

Mostrar Integridade� Problema: O que se deve partilhar com o cliente?� Forças:

� Não se pode informar o cliente sobre todos os riscos possíveis

� Os clientes querem ser informados acerca de tudo� Solução:

� Identificar os N riscos do projecto e partilhar o


� Identificar os N riscos do projecto e partilhar o impacto desses riscos com o cliente

� Evitar a honestidade que é destrutiva� Contexto Resultante:

� O cliente aprende a confiar na nossa palavra� O cliente reage mais calmamente quando lhe

anunciamos novos riscos para o projecto

Não Aquecer� Problema: Como lidar com um cliente zangado?� Forças:

� A resposta natural é ser defensivo mas isso vai aumentar a irritação do cliente

� A irritação estraga a relação com o cliente� Queremos defender os nossos interesses

� Solução:� Não argumentar, um cliente irritado não é racional,


� Não argumentar, um cliente irritado não é racional, ouvir, ouvir

� Não tentar acalmar o cliente fazendo promessas, fazer perguntas

� Descobrir as verdadeiras preocupações do cliente� Contexto Resultante:

� O cliente vai-se acalmar, e quando se acalmar o problema vai poder ser resolvido num contexto mais comunicativo

Ter a Noção dos Limites� Problema: Quando se está em modo de solução é

difícil pensar nas consequências de propor uma solução e de dar uma resposta

� Forças:� Desejamos satisfazer os clientes� Os clientes podem ter expectativas ou pedidos

irrealistas� Não queremos fazer promessas que não possamos


� Não queremos fazer promessas que não possamos manter

� Solução:� Os limites são diferentes para os membros da equipa,

cada membro da equipa deve ter a noção de qual é o seu papel

� Tomar notas sobre as questões fora na nossa área e encontrar a pessoa responsável por dar a resposta

� Contexto Resultante:� Os interesses da equipa, da empresa e do cliente

serão protegidos

Ter Boas Maneiras� Problema: Quando se interage com os clientes nem

sempre se pensa sobre etiqueta, vestir e comportamento

� Forças:� Algumas pessoas pensam que considerar etiqueta,

vestir e comportamento são uma perda de tempo� As pessoas podem reagir pessoalmente a faltas de

etiqueta, vestir ou comportamento descuidado


etiqueta, vestir ou comportamento descuidado� Solução:

� Vestir de acordo com as expectativas dos clientes� Mostrar respeito por todos inclusive a concorrência� Cuidado particular com as interacções com os da

nossa companhia em frente dos clientes� Contexto Resultante:

� As expectativas do cliente são satisfeitas

Casos Notáveis� Um Processo de Análise de Requisitos para

Desenvolvimento com Objectos� Objectivos

1. Orientar analistas e arquitectos para aplicarem um conjunto de técnicas de modo a produzir uma análise mais profunda e um melhor conhecimento do espaço do problema

2. Fornecer um enquadramento para definir e


2. Fornecer um enquadramento para definir e capturar requisitos antes, e durante, o desenvolvimento com objectos, e com o qual o software pode ser avaliado, desenhado e testado

3. Possibilitar a rastreabilidade desde o desenho aos objectivos do negócio e ao sistema

Construir o Necessário� Problema: Como se captura, comunica e

valida requisitos de modo a que o sistema resultante vai de facto fazer o que é necessário?

� Forças:� A captura e comunicação de requisitos é difícil

� Os clientes não conseguem expressar


� Os clientes não conseguem expressar convenientemente os seus requisitos

� A equipa de desenvolvimento tem dificuldade em entender o que é que o cliente pretende

� Os requisitos alteram-se, são incompletos e incoerentes

� O espaço do problema é mal conhecido

Construir o Necessário

� Solução: � Utilizar as seguintes técnicas

� Gerir as expectativas do cliente� Manter uma relação com o cliente � Capturar e validar os objectivos do

responsável do negócio


responsável do negócio� Fazer uma análise de requisitos

� Análise do domínio do problema� Especificação de requisitos� Validação de requisitos

� Usar protótipos

Gerir as Expectativas do Cliente� Problema: Como se gerem e satisfazem as

expectativas do cliente acerca do produto� Forças:

� Um produto pode satisfazer tecnicamente a especificação de requisitos mas não satisfazer o cliente

� Não é possível assegurar que um produto vai satisfazer as expectativas do cliente através de


satisfazer as expectativas do cliente através de uma simples tentativa de especificar completamente os requisitos

� Solução: � Produzir uma lista das expectativas do cliente e

classificar cada uma como real ou desejável� Desenvolver protótipos para validar que o

comportamento do sistema vai satisfazer as expectativas do cliente

Relação com o Cliente

� Problema: Como se constrói uma boa relação com o cliente?

� Forças: � O principal problema do desenvolvimento de

software é as pessoas não trabalharem em cooperação


cooperação� Quando o cliente não comunica a equipa retira-

se para a segurança dos seus gabinetes

� Solução:� Primeiro estabelecer uma relação com o cliente� Primeiro entendimento depois entender

Objectivos do Negócio� Problema: Como se alinham os objectivos

do negócio com o sistema que está a ser desenvolvido

� Forças:� Um sistema desenvolvido pode, de acordo com

os requisitos, estar completo mas não satisfazer as necessidades reais do negócio


as necessidades reais do negócio

� Solução:� Fazer a pergunta Se o sistema não satisfizer este objectivo é razão suficiente para parar o desenvolvimento? Se a resposta for sim então estamos perante um objectivo do negócio

� Não se devem ter mais do que oito objectivos do negócio

Contextualizar� Problema: Como se contextualiza um sistema que

suporta um processo de negócio?� Forças:

� A razão do sistema é o negócio, a sua automatização, o aumento de produtividade, a reengenharia, ...

� É difícil perspectivar como vai ser o novo negócio após a instalação do sistema tendo como base apenas os casos de uso


apenas os casos de uso� Solução:

� Escrever cada processo de negócio � Inicialmente escrever os processos de negócio

principais� Os casos de uso devem ser derivados dos processos

de negócio� Usar protótipos de interface, em papel, para

visualizar como é que o utilizador vai interagir com o sistema

Regras de Negócio

� Problema: Qual é a melhor forma de definir regras de negócio de modo a estas poderem ser usadas e verificadas?

� Forças:� Raramente as regras de negócio são


� Raramente as regras de negócio são explícitas

� Normalmente as regras de negócio apenas surgem na base de dados como stored procedures ou no código de interface

� Solução:� Regras que restringem casos de uso

� Estímulo/Resposta – restringem o comportamento no contexto de um caso de uso ou de um evento que pode desencadear um caso de uso. WHEN ... IF ... THEN

Regras de Negócio


� Pré-condição – especificam as condições que devem-se verificar antes de uma operação ou caso de uso ocorrer correctamente ... ONLY IF ...

� Pós-condição – garantem o resultado de um caso de uso ou condição ... CORRECTELY COMPLETED ONLY IF ...

Regras de Negócio

� Regras que restringem objectos e o seu estado� Restrição de Objecto – define condições e

políticas para os objectos e suas associações ...ALWAYS HOLD THAT...

� Inferência – define que se uma condição


� Inferência – define que se uma condição se verifica então outra condição pode ser inferida, e.g., uma relação de sub-classe

� Computação – define resultados em termos de uma equação ou algoritmo

Definição de Requisitos

� Problema: Quais são os métodos e técnicas que melhor permitem definir os requisitos do sistema? Como e quando devem ser aplicados?

� Solução:


� Solução:� Definir um glossário de termos� Elaborar:

� Análise do domínio� Requisitos de comportamento� Análise do domínio do problema

Requisitos de Comportamento� Problema: Qual deve ser o

comportamento do sistema?� Forças: Os requisitos de comportamento

são geralmente muito vagos� Solução:

� Os comportamentos devem ser descritos em termos de casos de uso


termos de casos de uso� Os clientes do sistema devem ser identificados e

definidos num diagrama de fronteira do sistema� As entidades externas são classificadas como

clientes e servidores� Para cada cliente listar todos os casos de uso

numa Matriz de Casos de uso

Requisitos de Comportamento� Descrever cada caso de uso em detalhe� Sempre que relevante associar a cada caso de

uso:� Regras de negócio� Relações entre objectos� Protótipos� Diagramas de fluxo de janelas


� Diagramas de fluxo de janelas� Se necessário usar uma tabela de decisão para

identificar todos os estímulos que originam casos de uso

� Se houver sequências de estímulos usar diagramas de transição

� Se houver muita sincronização usar diagramas de actividade

Análise do Domínio� Problema: Como se define o domínio

do problema no qual o sistema vai ser desenvolvido

� Forças:� O objectivo da análise do domínio do

problema é fornecer um


problema é fornecer um entendimento da área do problema

� A análise do domínio não tem como objectivo a definição de requisitos

Análise do Domínio

� Solução:� Define-se uma comunidade de objectos

interrelacionados� Procede-se às seguintes actividades de

identificação:� Informação Necessária


� Informação Necessária� Identificar e Definir os Objectos do Domínio� Classificação, Associação e Agrupamento de

Objectos� Refinamento dos Objectos do Domínio� Ciclo de Vida do Objecto� Estereótipos de Objecto

Informação Necessária� Problema: Como se captura a informação necessária

aos clientes e se reflecte essa informação como um conjunto de objectos?

� Forças:� A necessidade de informação é de importância

primordial para muitos dos utilizadores dos sistemas de negócio


� Muitas vezes existe pouco comportamento associado a essa informação

� Solução:� Usar casos de uso e protótipos de interface em papel

para determinar as diferentes vistas da informação� Construir uma Matriz de Informação que identifica o

objecto de informação, a sua fonte e a sua descrição

Identificar e Definir os Objectos� Problema: Como se determina quais os

objectos do domínio do problema? E como se definem os seus papéis?

� Forças:� Cada processo, cada transacção, cada entidade

pode ser vista como um objecto� Existem objectos simples e objectos complexos


� Existem objectos simples e objectos complexos� Existem objectos que são visíveis pelos

utilizadores finais enquanto que outros existem para suportar os primeiros

� Os objectos podem ser agrupados em papéis, o que ajuda a entender o essencial do domínio do problema

Identificar e Definir os Objectos� Solução:

� Procurar os objectos em:� Descrições de casos de uso� Glossários de termos� Descrições de processos de negócio

� Definir as responsabilidades de cada


� Definir as responsabilidades de cada objecto

� Baseado nas responsabilidades determinar o conjunto de papéis que o objecto possui

Classificação, Associação e Agrupamento� Problema: Quais são os relacionamentos entre os

objectos? Que objectos são parte de outros? � Solução: Para cada responsabilidade de cada

objecto:� Desenvolver um cenário onde o objecto necessita

desse comportamento� Animar o cenário para determinar os colaboradores

necessários para o objecto cumprir a


necessários para o objecto cumprir a responsabilidade

� Considerar todos os casos de uso e eventos que são desencadeados por clientes externos e desenvolver um cenário associado a cada um deles

� Animar os cenários� Como resultado das animações anteriores definir um

diagrama de estrutura que defina os relacionamentos entre os objectos

Refinamento dos Objectos� Problema: Quais são os atributos dos

objectos? Que regras restringem os objectos?

� Forças:� Alguns atributos dependem da implementação� Existem regras de negócio que têm impacto na


� Existem regras de negócio que têm impacto na definição dos atributos dos objectos

� Solução:� Em vez de definir atributos nos objectos define-

se qual é a informação que devem fornecer� Capturar as regras de negócio

Ciclo de Vida do Objecto� Problema: Como e quando se deve definir

o ciclo de vida do objecto?� Forças:

� Alguns objectos têm um grande conjunto de estados

� Solução:� Iterar sobre todos os objectos do domínio e


� Iterar sobre todos os objectos do domínio e avaliar se existem variações de estado a eles associados nos casos de uso e nos processos de negócio

� Atribuir nomes de negócio aos estados identificados

� Construir diagramas de transição de estado

Estereótipos de Objecto

� Problema: Como se determina a natureza dos papéis dos objectos no domínio do problema?

� Solução: � Pensar nos objectos em termos de estereótipos

de comportamento normalizado:


de comportamento normalizado:� Contentores de informação� Controladores� Coordenadores� Fornecedores de serviço� Objectos de interface

� Definir estereótipos específicos do domínio

Para Além da Funcionalidade� Problema: Quais são as outras

restrições para além das funcionais?� Forças:

� Algumas são de comportamento, como é o suporte a várias línguas, enquanto que outras são organizacionais, como a


outras são organizacionais, como a utilização de uma base de dados relacional

� Solução:� Usar uma Lista de Tipos de Requisitos

para assegurar que a maior parte destes requisitos são capturados

Requisitos de Interface

� Problema: Qual é a melhor forma de determinar os requisitos de interface utilizador?

� Forças:� 80% da satisfação do utilizador vem da interface� A interface utilizador deve transmitir a visão


� A interface utilizador deve transmitir a visão lógica que o utilizador tem do sistema

� Requisitos de interface devem ser adquiridos cedo

� Solução:� Para cada caso de uso especificar as vistas que

o utilizador tem do sistema

Especificação de Requisitos� Problema: Como especificar os requisitos

de modo a satisfazer os diversos intervenientes?

� Forças:� Os requisitos podem ser descritos usando:

� Linguagem natural� Linguagens formais


� Linguagens formais� Protótipos

� Solução:� Usar a matriz para a especificação de requisitos

definida em http://systemsguild.com/GuildSite/Robs/Template.html

� Usar casos de uso

Validação de Requisitos� Problema: Como verificar que os requisitos

estão correctos e são completos?� Forças:

� É necessária a aprovação dos clientes e utilizadores

� É difícil validar sistemas definidos manualmente pois não permitem verificação


manualmente pois não permitem verificação automática

Validação de Requisitos

� Solução:� Todos os intervenientes devem ler a

especificação de requisitos� Conduzir reuniões de revisão dos requisitos� Revisão dos protótipos com os utilizadores� Registar todas as questões levantadas


� Registar todas as questões levantadas durante as revisões

� Continuar a verificação dos requisitos durante todo o processo de desenvolvimento

� Se necessário, escolher um grupo de arbitragem para reconciliar desacordos

Exemplo: Figura DensaObter informação de qualidade sobre

a disciplina

AlunosIST/CIIST

Fornecer melhoresserviços à escola

1-Exemplo pedagógico

IntegramGesDis


Equipaalunos

Papéis

Desenvolvimento

Aprovação à disciplina

Vendemos um conjunto integrado

de aplicações

Empresa XPTO

Docentes de EP

1-Exemplo pedagógico2-Criar uma prática de desenvolvimento no

ISTGestão de EP

Exemplo: Modelo de Domínio

Aluno

número : integer

nome : string

estado : undefined

password : stringSecção

1

Item

nome : string

valor : string

Grupo

horário : undefined

número : integer

sala : string

Tipo Grupo

máximo : integer

mínimo : integer

ideal : integer

número : integer

nome : string

estado : undefined

password : string

horário : undefined

número : integer

sala : string

0..1**

*

máximo : integer

mínimo : integer

ideal : integer

1

nome : string

valor : string

1

*


email : string nome : string

ordem : integer

nome : string 1email : string 1

Docente

nome : string

username : string

password : string

email : string

SubSecçãoSecçãoTopoPágina

departamento : string

licenciatura : string

disciplina : string

semestre : undefined

ano : undefined

departamento : string

licenciatura : string

disciplina : string

semestre : undefined

ano : undefined

nome : string

username : string

password : string

email : string

* *

* 1

ordem : integer

*

*1

Exemplo: Actores

Pessoa


Aluno Docente

Exemplo: Casos de Uso

GesDis

Pessoa Visualizar Secção

Visualizar Página Registar AlunosSecretaria

Inserir Aluno


Aluno

Inscrição de Aluno

Inscrição em Grupo

Docente

Editar Aluno

Apagar Aluno

Exemplo: Registar Alunos<<description>>

Registar alunos.

Pré-condição

A pauta da secretaria está definida.

Caminho principal

1.O docente fornece a pauta da secretaria ao sistema.

2.O sistema regista os alunos não registados e actualiza a informação.

Caminhos alternativos

No passo 1: A pauta não está no formato correcto; o docente é avisado.


No passo 1: A pauta não está no formato correcto; o docente é avisado.

No passo 2: O aluno já está registado; se já esta inscrito na secretaria nada é

feito, se apenas está inscrito na cadeira passa a inscrito na secretaria

No passo 2: O aluno já registado não surge na nova pauta; o seu registo passa

a anulado.

Pós-condição

Caminho principal - A base de dados é actualizada de acordo com as regras

descritas acima.

Caminhos alternativos - As acções a tomar para cada caso particular de aluno

estão de acordo com as regras descritas nos caminhos alternativos. Em caso

de erro da pauta, a informação não é alterada.

Conclusões

� P8 – Comunicar com os Clientes e Utilizadores� O cliente e os utilizadores são as pessoas

mais importante envolvidas no projecto

� P9 – Alinhar os Incentivos para a Equipa com os Incentivos para o


Equipa com os Incentivos para o Cliente� Procurar criar sinergias entre as tarefas e

resultados de cada um deles� Recompensar a equipa de acordo com as

prioridades

� P11 – Desenvolver o Tipo Adequado de Protótipo� Evolutivos quando os aspectos críticos

estão dominados� Descartáveis quando os aspectos

críticos não estão dominadas

Conclusões


críticos não estão dominadas� Protótipos descartáveis apenas devem

incluir as características que não estão dominadas

� P13 – Desenvolver Rapidamente Protótipos Descartáveis

� P39 – Determinar o Problema antes de Escrever a Solução� Existem sempre várias soluções e a sua

escolha depende de qual é e quem tem o problema

� P42 – Protótipos Reduzem o Risco

Conclusões


� P42 – Protótipos Reduzem o Risco na Selecção de Interfaces Utilizador

� P43 – Registar a Razão para cada Requisito� Ulteriormente é possível verificar as

consequências de alterar

� P44 – Dividir para Conquistar� Identificar o conjunto mínimo de

requisitos que pode ser útil� Identificar os incrementos mínimos que

tornam o conjunto mínimo de requisitos mais útil

Conclusões


mais útil� P45 – Fazer Revisão de Requisitos

� De modo a envolver todos os intervenientes

� P46 – Evitar Fazer Desenho nos Requisitos� Não enviesar o espaço da solução

Conclusões

� P47 – Usar as Técnicas Adequadas� Se o problema é muito complexo usar

várias técnicas � P48 – Ver os Requisitos de Acordo

com Várias Perspectivas� Estrutura


� Estrutura� Comportamento� Negócio

� P49 – Organizar os Requisitos� Da forma mais útil categorizando por

utilizador, estímulo, objecto...

� P50 – Atribuir Prioridades aos Requisitos� Obrigatório, Desejável e Opcional

� P51 – Escrever com Concisão� P52 – Numerar cada Requisito

Conclusões


� P52 – Numerar cada Requisito� P53 – Reduzir a Ambiguidade dos

Requisitos� Usar linguagem natural e linguagens

formais

� P54 – Aumentar, Nunca Substituir, a Linguagem Natural� Manter ambas as descrições

� P55 – Escrever em Linguagem Natural antes de usar um Modelo Formal

Conclusões


Formal � (1) escrever em linguagem natural� (2) escrever o modelo formal� (3) adaptar a linguagem natural para

reduzir ambiguidades

Conclusões

� P56 – Manter a Especificação de Requisitos Legível

� P57 – Especificar a Fiabilidade Explicitamente� Percentagem de pedidos a cuja resposta


� Percentagem de pedidos a cuja resposta o sistema falha

� Percentagem de tempo que o sistema pode não estar disponível

Referências

� Pfleeger98, Capítulo 4, excepto 4.5.� David95, Alguns princípios dos Capítulos 2

e 3.� Volere - Requirements Specification

Templatehttp://systemsguild.com/GuildSite/Robs/Template.html


http://systemsguild.com/GuildSite/Robs/Template.html

� The Rich Picture: A Tool for Reasoning about Work Context. Andrew Monk and Steve Howard. Interactions March/April 98. http://www.ics.uci.edu/~wscacchi/Software-Process/Readings/RichPicture.pdf

Referências

� Requirements: Made to Measure http://www.atlsysguild.com/GuildSite/Robs/apmeas.html

� Linda Rising. Customer Interaction Patterns. In Harrison2000. Capítulo 26. http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/P11/P11.htm


1/P11.htm

� Bruce Whitenack. RAPPeL: A Requirements Analysis Process Pattern Language for Object Oriented Development.http://www2.umassd.edu/SWPI/ATT/pattern/rapel.html

Documents

António Rito Silva Rito.Silva@inesc-id - Autenticação · António Rito Silva [email protected]. Sumário Caracterização Objectivos Problemas Qualidades Factores Não-Técnicos