Padrões de Interacção com o Cliente

(1)

Engenharia de Requisitos 60

Padrões de Interacção com o

Cliente

Linda Rising

Customer Interaction Patterns

In Harrison2000. Capítulo 26.

(2)

É uma Relação não é um Negócio

3UREOHPD

: Como devemos tratar os clientes de

modo a ficarem contentes com os nossos produtos?

)RUoDV

:

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

Queremos satisfazer os clientes

6ROXomR

:

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

produto

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

&RQWH[WR5HVXOWDQWH

:

Uma relação continuada significa continuação do negócio

Conhecer o Cliente

3UREOHPD

: Qual a melhor forma de estabelecer uma

relação com o cliente?

)RUoDV

:

A equipa normalmente pensa que conhecer o produto é

suficiente

A equipa e o cliente querem resultados rápidos

6ROXomR

:

Aprender com o cliente

Aprender a linguagem do cliente

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

sucesso

&RQWH[WR5HVXOWDQWH

:

Quando conhecemos os valores do cliente tornamos-nos

(3)

Construir Confiança

3UREOHPD

: Como se solidifica a relação com o

cliente?

)RUoDV

:

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

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

6ROXomR

:

Cada contacto deve servir para aumentar a confiança Ter encontros pessoais e não apenas por correio electrónico

&RQWH[WR5HVXOWDQWH

:

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

3UREOHPD

: Qual é a forma mais eficaz de

desenvolver a relação com o cliente?

)RUoDV

:

Muitos clientes pedem o nosso tempo

É difícil estar sempre a 100%

6ROXomR

:

Ouvir o cliente e mostrar interesse genuíno

Recolher informação fazendo perguntas

Ser flexível e positivo

&RQWH[WR5HVXOWDQWH

:

O cliente vai sentir-se estimado e a sua confiança

(4)

Ser Reactivo

3UREOHPD

: Qual é a resposta aceitável aos pedidos

do cliente?

)RUoDV

:

Queremos ser atenciosos com os clientes

Nem sempre podemos dar uma resposta imediata

6ROXomR

:

Responder ao telefonemas dos clientes no mesmo dia

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

&RQWH[WR5HVXOWDQWH

:

Os clientes estão informados no nosso progresso na

resolução dos seus pedidos

Reuniões com o Cliente

3UREOHPD

: Tem que se ir a reuniões com os clientes

mas parecem ser uma perda de tempo.

)RUoDV

:

Desejamos que os clientes estejam a par do estado actual

do produto

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

6ROXomR

:

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

&RQWH[WR5HVXOWDQWH

:

(5)

Mostrar Integridade

3UREOHPD

: O que se deve partilhar com o cliente?

)RUoDV

:

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

Os clientes querem ser informados acerca de tudo

6ROXomR

:

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

Evitar a honestidade que é destrutiva

&RQWH[WR5HVXOWDQWH

:

O cliente aprende a confiar na nossa palavra

O cliente reage mais calmamente quando lhe anunciamos

novos riscos para o projecto

Não Aquecer

3UREOHPD

: Como lidar com um cliente zangado?

)RUoDV

:

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

6ROXomR

:

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

&RQWH[WR5HVXOWDQWH

:

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

(6)

Ter a Noção dos Limites

3UREOHPD

: Quando se está em modo de solução é

difícil pensar nas consequências de propor uma

solução e de dar uma resposta

)RUoDV

:

Desejamos satisfazer os clientes

Os clientes podem ter expectativas ou pedidos irrealistas Não queremos fazer promessas que não possamos manter

6ROXomR

:

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

&RQWH[WR5HVXOWDQWH

:

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

protegidos

Ter Boas Maneiras

3UREOHPD

: Quando se interage com os clientes nem

sempre se pensa sobre etiqueta, vestir e

comportamento

)RUoDV

:

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

6ROXomR

:

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

&RQWH[WR5HVXOWDQWH

:

(7)

Um Processo de Análise de

Requisitos 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

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

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

(8)

Construir o Necessário

3UREOHPD

: Como se captura, comunica e

valida requisitos de modo a que o sistema

resultante vai de facto fazer o que é

necessário?

)RUoDV

:

A captura e comunicação de requisitos é difícil

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

6ROXomR

:

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

(9)

Gerir as Expectativas do Cliente

3UREOHPD

: Como se gerem e satisfazem as

expectativas do cliente acerca do produto

)RUoDV

:

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 uma simples tentativa de especificar completamente os requisitos

6ROXomR

:

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

3UREOHPD

: Como se constrói uma boa

relação com o cliente?

)RUoDV

:

O principal problema do desenvolvimento de

software é as pessoas não trabalharem em

cooperação

Quando o cliente não comunica a equipa retira-se

para a segurança dos seus gabinetes

6ROXomR

:

Primeiro estabelecer uma relação com o cliente

(10)

Objectivos do Negócio

3UREOHPD

: Como se alinham os objectivos do

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

)RUoDV

:

Um sistema desenvolvido pode, de acordo com os

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

6ROXomR

:

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

3UREOHPD

: Como se contextualiza um sistema que

suporta um processo de negócio?

)RUoDV

:

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

6ROXomR

:

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

(11)

Regras de Negócio

3UREOHPD

: Qual é a melhor forma de definir

regras de negócio de modo a estas poderem

ser usadas e verificadas?

)RUoDV

:

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

6ROXomR

:

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

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

Computação – define resultados em termos de uma

equação ou algoritmo

(12)

Definição de Requisitos

3UREOHPD

: Quais são os métodos e

técnicas que melhor permitem definir

os requisitos do sistema? Como e

quando devem ser aplicados?

6ROXomR

:

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

3UREOHPD

: Qual deve ser o comportamento

do sistema?

)RUoDV

: os requisitos de comportamento são

geralmente muito vagos

6ROXomR

:

Os comportamentos devem ser descritos em

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

(13)

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 de

actividade

Análise do Domínio

3UREOHPD

: Como se define o domínio do problema

no qual o sistema vai ser desenvolvido

)RUoDV

:

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

6ROXomR

:

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

(14)

Informação Necessária

3UREOHPD

: Como se captura a informação

necessária aos clientes e se reflecte essa informação

como um conjunto de objectos?

)RUoDV

:

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

6ROXomR

:

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

3UREOHPD

: Como se determina quais os

objectos do domínio do problema? E como se

definem os seus papéis?

)RUoDV

:

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

(15)

Identificar e Definir os Objectos

6ROXomR

:

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

objecto

Baseado nas responsabilidades determinar

o conjunto de papéis que o objecto possui

Classificação, Associação e Agrupamento

3UREOHPD

: Quais são os relacionamentos entre os

objectos? Que objectos são parte de outros?

6ROXomR

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

(16)

Refinamento dos Objectos

3UREOHPD

: Quais são os atributos dos

objectos? Que regras restringem os

objectos?

)RUoDV

:

Alguns atributos dependem da implementação

Existem regras de negócio que têm impacto na

definição dos atributos dos objectos

6ROXomR

:

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

3UREOHPD

: Como e quando se deve definir o

ciclo de vida do objecto?

)RUoDV

:

Alguns objectos têm um grande conjunto de

estados

6ROXomR

:

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

(17)

Estereótipos de Objecto

3UREOHPD

: Como se determina a natureza

dos papéis dos objectos no domínio do

problema?

6ROXomR

:

Pensar nos objectos em termos de estereótipos

de comportamento standard:

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

3UREOHPD

: Quais são as outras

restrições para além das funcionais?

)RUoDV

:

Algumas são de comportamento, como é o

suporte a várias línguas, enquanto que

outras são organizacionais, como a

utilização de uma base de dados relacional

6ROXomR

:

Usar uma Lista de Tipos de Requisitos

para assegurar que a maior parte destes

requisitos são capturados

(18)

Requisitos de Interface

3UREOHPD

: Qual é a melhor forma de

determinar os requisitos de interface

utilizador?

)RUoDV

:

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 cedo

6ROXomR

:

Para cada caso de uso especificar as vistas que o

utilizador tem do sistema

Especificação de Requisitos

3UREOHPD

: Como especificar os requisitos

de modo a satisfazer os diversos

intervenientes?

)RUoDV

:

Os requisitos podem ser descritos usando:

Linguagem natural Linguagens formais Protótipos

6ROXomR

:

Usar a matriz para a especificação de requisitos

definida em

http://www.atlsysguild.com/GuildSite/Robs/Templ

ate.html

(19)

Validação de Requisitos

3UREOHPD

: Como verificar que os requisitos estão

correctos e são completos?

)RUoDV

:

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

É difícil validar sistemas definidos manualmente

6ROXomR

:

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 arbitragem para reconciliar desacordos

Exemplo: Figura Densa

Obter informação de qualidade sobre a disciplina Alunos Introd uzem Inform ação pesso al Obtêm Inform ação discip lina Equipa alunos Papéis IST/CIIST Desenvolvimento Aprovação à disciplina Fornecer melhores serviços à escola

Docentes de ES

1-Exemplo pedagógico 2-Criar uma prática de

desenvolvimento no IST Integram

Gestão de ES GesDis

(20)

Exemplo: Modelo de Domínio

email : string número : integer nome : string estado : undefined password : string nome : string ordem : integer nome : string 1 email : string 1 !"# nome : string valor : string $&%' horário : undefined número : integer sala : string ()'&$&%' 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 * * " nome : string username : string password : string email : string +, , (' -./)0 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

Aluno Docente Pessoa

(21)

Exemplo: Casos de Uso

GesDis Aluno Pessoa Inscrição de Aluno Inscrição em Grupo Visualizar Secção Visualizar Página Docente Registar Alunos Secretaria Inserir Aluno 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 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.

(22)

Casos de Uso - Cenários

Uma sequência de passos que descreve

uma interacção entre um utilizador e

um sistema

1

O utilizador acede a “Agrupamento”, onde

Agrupamento é o nome do agrupamento.

O sistema mostra no ecrã os turnos do

agrupamento seleccionado. Para cada

turno, são visualizados:

2

O nome do turno;

2

As aulas a ele associadas (dia da semana, hora

de início e de fim e sala);

2

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

1

Caso de Uso: Visualizar Turnos do

Agrupamento

1

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.

1

Cenário 1: Existem turnos

1

(23)

Actores

3

Um actor é um papel que um utilizador toma

em relação com um sistema

Humanos

Outros sistemas

3

Um utilizador pode ter vários papéis

3

Os actores levam a cabo casos de uso

3

Os actores podem ser facilmente

identificados antes da identificação dos casos

de uso

3

Os eventos externos facilitam a identificação

dos actores

Formato Caso de Uso

O formato deve ser ajustado às

necessidades.

Um exemplo de formato:

1

Nome

1

Objectivo

1

Actores

1

Pré-condições

1

Cenário Principal

1

Cenários Alternativos

1

Pós-condições

(24)

Visualizar Turnos do Agrupamento

Objectivo:

1

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:

1

Qualquer utilizador do sistema Fénix

Pré-Condições:

1

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.

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

(25)

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

Pós-Condições:

1

O estado do sistema permanece inalterado

Diagramas de Casos de Uso

Diagrama Casos de Uso - Estudante

Estudante

Visualizar Agrupamentos da Disciplina

Visualizar Turnos do Agrupamento Visualizar Grupo do Turno

Criar Grupo Inscrever em Grupo Alterar Turno Remover Inscrição <<include>> <<include>> <<include>> <<include>> <<include>> <<include>>

(26)

Relações entre Casos de Uso

Inclusão – quando nos estamos a

repetir em dois os mais casos de uso

Generalização – uma variação

(alternativa) de um comportamento

que se pretende representar fora do

caso de uso

Extensão - uma variação de um

comportamento que se pretende

representar fora do caso de uso 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:

1

Delimitam o sistema

1

Cada caso de uso pode ser isolado dos

restantes pelo que facilita a decomposição

do espaço do problema

1

Podem ser usados para estimar o tempo e

o esforço necessário ao desenho e

codificação do sistema

1

O desenvolvimento do sistema pode ser

(27)

Conclusões

P8 – Comunicar com os Clientes e

Utilizadores

1

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

1

Procurar criar sinergias entre as tarefas e

resultados de cada um deles

1

Recompensar a equipa de acordo com as

prioridades

P11 – Desenvolver o Tipo Adequado de

Protótipo

1

Evolutivos quando os aspectos críticos

estão dominados

1

Descartáveis quando os aspectos críticos

não estão dominadas

1

Protótipos descartáveis apenas devem

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

dominadas

P13 – Desenvolver Rapidamente

Protótipos Descartáveis

Conclusões

(28)

P39 – Determinar o Problema antes de

Escrever a Solução

1

Existem sempre várias soluções e a sua

escolha depende de qual é e quem tem o

problema

P42 – Protótipos Reduzem o Risco na

Selecção de Interfaces Utilizador

P43 – Registar a Razão para cada

Requisito

1

Ulteriormente é possível verificar as

consequências de alterar

Conclusões

P44 – Dividir para Conquistar

1

Identificar o conjunto mínimo de requisitos

que pode ser útil

1

Identificar os incrementos mínimos que

tornam o conjunto mínimo de requisitos

mais útil

P45 – Fazer Revisão de Requisitos

1

De modo a envolver todos os

intervenientes

P46 – Evitar Fazer Desenho nos

Requisitos

Não enviesar o espaço da solução

(29)

Conclusões

P47 – Usar as Técnicas Adequadas

4

Se o problema é muito complexo usar

várias técnicas

P48 – Ver os Requisitos de Acordo com

Várias Perspectivas

4

Estrutura

4

Comportamento

4

Negócio

P49 – Organizar os Requisitos

4

Da forma mais útil categorizando por

utilizador, estímulo, objecto...

P50 – Atribuir Prioridades aos

Requisitos

4

Obrigatório, Desejável e Opcional

P51 – Escrever com Concisão

P52 – Numerar cada Requisito

P53 – Reduzir a Ambiguidade dos

Requisitos

4

Usar linguagem natural e linguagens

formais

(30)

P54 – Aumentar, Nunca Substituir, a

Linguagem Natural

4

Manter ambas as descrições

P55 – Escrever em Linguagem Natural

antes de usar um Modelo Formal

4

(1) escrever em linguagem natural

4

(2) escrever o modelo formal

4

(3) adaptar a linguagem natural para

reduzir ambiguidades

Conclusões

P56 – Manter a Especificação de

Requisitos Legível

P57 – Especificar a Fiabilidade

Explicitamente

4

Percentagem de pedidos a cuja resposta o

sistema falha

4

Percentagem de tempo em que um pedido

pode falhar

4

Percentagem de tempo que o sistema

(31)

Referências

Pfleeger98, Capítulo 4, excepto 4.5.

David95, Alguns princípios dos

Capítulos 2 e 3.

Volere - Requirements Specification

Template

http://www.atlsysguild.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/P1 1.htm