Engenharia de Requisitos. António Rito Silva

(1)

Engenharia de Requisitos

António Rito Silva

(2)

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

(3)

Objectivos

Identificação de quais são as

características do sistema a

desenvolver

Assegurar que essas características

correspondem aos objectivos do

negócio

Verificar se o sistema desenvolvido

(4)

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

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

(5)

Tipos de Requisitos

Os requisitos funcionais descrevem

uma interacção entre o sistema e o

seu ambiente

Os requisitos não-funcionais

descrevem restrições ao sistema que

limitam as possibilidades de

implementação

Os requisitos do desenvolvimento

(6)

Requisitos Funcionais

Contexto do sistema

Reacção a estímulos externos

Estados do sistema

Informação manipulada pelo sistema

...

(7)

Requisitos Não-Funcionais

Usabilidade

Desempenho

Fiabilidade

Disponibilidade

Segurança

Portabilidade

Tecnologia de implementação

(8)

Requisitos de Desenvolvimento

Manutenção

Evolução

Documentação

Processo

Orçamento

Recursos humanos

Recursos computacionais

...

(9)

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

(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

(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

(12)

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.

(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

(14)

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

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

(15)

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

(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

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

(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

(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

(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

(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

(21)

Técnicas

Representação de Requisitos

Prototipagem

Matriz Volere

Casos de Uso

Figuras Densas (Rich Pictures)

(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

(23)

Representações

Axiomática

Linguagem

Dados Abstractos

Diagramas de Fluxo de Dados

Tabelas de Decisão

Diagramas de Transição

(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

(25)

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

(26)

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

(27)

Diagramas de Fluxo de Dados

Representa

Processamento de dados

Relações de produção e consumo de dados

Repositórios de dados

(28)

Tabelas de Decisão

Representam regras

estímulo/resposta quando um

conjunto de condições se verifica

(29)

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

(30)

Diagramas de Transição

(31)

Baseado em Objectos

Estende a abordagem estática dos

dados abstractos com os conceitos

de:

Encapsulação

Hierarquia de classes

Herança

Polimorfismo

(32)

Baseado em Objectos

1 Unidade Pessoa Orgão Vínculo 1 * * * 1 * 1 * Função FunçãoPrimaria FunçãoInerente * 1 * Engenharia de Requisitos 32 Pessoa Discente Funcionario Cargo Docente FunçãoPrimaria FunçãoInerente

(33)

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?

(34)

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

computacional?

Incompleta: Suporta informação incompleta?

Aprendizagem: Qual é a curva de

aprendizagem?

Disciplina: Conduz a uma disciplina de escrita de

(35)

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

(36)

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

(37)

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

código, e.g. SQL

Composição de componentes

(38)

Matriz Volere

Estrutura a linguagem natural

Enumera requisitos não funcionais

tipo

Look and feel

Usabilidade Desempenho Engenharia de Requisitos 38 Desempenho Operacionais Manutenção e portabilidade Segurança Culturais e políticos Legais

(39)

(40)

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

(41)

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

(42)

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

(43)

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;

(44)

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

(45)

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 podem ser facilmente

identificados antes da identificação dos casos de uso

(46)

Formato Caso de Uso

O formato deve ser ajustado às

necessidades

Um exemplo de formato:

Nome Objectivo Actores Engenharia de Requisitos 46 Actores Pré-condições Cenário Principal Cenários Alternativos Pós-condições

(47)

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:

Qualquer utilizador do sistema Fénix

(48)

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”).

(49)

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:

(50)

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>> Engenharia de Requisitos 50 Estudante

Visualizar Agrupamentos da Disciplina

Visualizar Turnos do Agrupamento

Criar Grupo <<include>> <<include>>

(51)

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

se representa fora do caso de uso

original de forma controlada,

(52)

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

(53)

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

(54)

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

(55)

(56)

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

(57)

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

(58)

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

Engenharia de Requisitos 58 Cruzamento de informação Modelos pré-definidos Prototipagem Simulação Demonstração matemática

(59)

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

(60)

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

(61)

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

(62)

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 Pattern Language for Object Oriented Development

(63)

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

(64)

É 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

(65)

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 a linguagem do cliente

Pensar nas necessidades dos clientes e ajudá-los a ter sucesso

(66)

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:

Cada contacto deve servir para aumentar a confiança

Ter encontros pessoais e não apenas por correio electrónico

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

(67)

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

Recolher informação fazendo perguntas

Ser flexível e positivo

(68)

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

Os clientes estão informados no nosso progresso na resolução dos seus pedidos

(69)

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:

Chegar à reunião com antecedência para conhecer as pessoas

(70)

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

O cliente aprende a confiar na nossa palavra

O cliente reage mais calmamente quando lhe anunciamos novos riscos para o projecto

(71)

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

(72)

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

Os interesses da equipa, da empresa e do cliente serão protegidos

(73)

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

(74)

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

(75)

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

(76)

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

Fazer uma análise de requisitos

Análise do domínio do problema

Especificação de requisitos

Validação de requisitos

(77)

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

(78)

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 retira-segurança dos retira-seus gabinetes

Solução:

Primeiro estabelecer uma relação com o cliente

(79)

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

(80)

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

(81)

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

(82)

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

(83)

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

se verifica então outra condição pode ser inferida, e.g., uma relação de sub-classe

(84)

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:

Definir um glossário de termos

Elaborar:

Análise do domínio

Requisitos de comportamento

(85)

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

(86)

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

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

(87)

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

entendimento da área do problema

A análise do domínio não tem como

objectivo a definição de requisitos

(88)

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

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

(89)

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:

(90)

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

(91)

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

(92)

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

(93)

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

definição dos atributos dos objectos

Solução:

(94)

define-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

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

(95)

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

(96)

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

(97)

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

lógica que o utilizador tem do sistema

Requisitos de interface devem ser adquiridos

(98)

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 Engenharia de Requisitos 98 Linguagens formais Protótipos Solução:

Usar a matriz para a especificação de requisitos

definida em

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

(99)

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

(100)

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

durante as revisões

Continuar a verificação dos requisitos

durante todo o processo de desenvolvimento

Se necessário, escolher um grupo de

(101)

Exemplo: Figura Densa

Obter informação de qualidade sobre a disciplina Alunos IST/CIIST Fornecer melhores serviços à escola 1-Exemplo pedagógico Integram GesDis Equipa alunos Papéis Desenvolvimento Vendemos um _{Docentes de EP} 1-Exemplo pedagógico 2-Criar uma prática de

desenvolvimento no IST

(102)

Exemplo: Modelo de Domínio

Aluno número : integer nome : string estado : undefined password : string S ecçã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 * Engenharia de Requisitos 102

email : string nome : string

ordem : integer nome : string 1 email : string 1 Docente nome : string username : string password : string email : string S ubS ecção S ecçãoTopo Pá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

(103)

Exemplo: Actores

Pessoa

(104)

Exemplo: Casos de Uso

GesDis

Pessoa _{Visualizar Secção}

Visualizar Página _{Registar Alunos}

Secretaria Inserir Aluno Engenharia de Requisitos 104 Aluno Inscrição de Aluno Inscrição em Grupo Docente Editar Aluno Apagar Aluno

(105)

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.

(106)

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

Cliente

Procurar criar sinergias entre as tarefas e

resultados de cada um deles

Recompensar a equipa de acordo com as

(107)

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

(108)

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

(109)

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

(110)

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 Engenharia de Requisitos 110 Estrutura Comportamento Negócio

P49 – Organizar os Requisitos

Da forma mais útil categorizando por utilizador, estímulo, objecto...

(111)

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

(112)

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

(113)

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

(114)

Referências

Pfleeger98, Capítulo 4, excepto 4.5.

David95, Alguns princípios dos Capítulos 2 e 3.

Volere - Requirements Specification Template

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

(115)

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/P1 1/P11.htm

1/P11.htm