Casos Notáveis Padrões de Interacção com o Cliente5-2).pdf · Engenharia de Requisitos 62 Casos...

Engenharia de Requisitos 62

Casos NotáveisPadrões de Interacção com o Cliente

Linda RisingCustomer Interaction PatternsIn Harrison2000. Capítulo 26.

Um Processo de Análise de Requisitos para Desenvolvimento com Objectos

Bruce WhitenackRAPPeL: A Requirements Analysis Process Pattern Language for Object Oriented Developmenthttp://www.bell-labs.com/people/cope/Patterns/Process/RAPPeL/rapel.html


Padrões de Interacção com o ClienteLinda Rising

Customer Interaction PatternsIn Harrison2000. Capítulo 26.


É uma Relação não é um NegócioProblema: 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 clienteQueremos satisfazer os clientes

Solução:Focar a relação com o cliente não apenas na venda do produtoConhecer o cliente e usar esse conhecimento no produto e como modo de ganhar a confiança do cliente

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


Conhecer o ClienteProblema: Qual a melhor forma de estabelecer uma relação com o cliente?Forças:

A equipa normalmente pensa que conhecer o produto é suficienteA equipa e o cliente querem resultados rápidos

Solução:Aprender com o clienteAprender a linguagem do clientePensar 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çaProblema: Como se solidifica a relação com o cliente?Forças:

Clientes querem contactar da equipa aqueles com que se sentem confortáveisAs pessoas são relutantes em gastar o seu tempo com quem não conhecem

Solução:Cada contacto deve servir para aumentar a confiançaTer 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ácilProcurar manter a relação, é mais fácil construir uma relação do que a reconstruir


Ouvir, Ouvir, OuvirProblema: 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ínoRecolher informação fazendo perguntasSer flexível e positivo

Contexto Resultante:O cliente vai sentir-se estimado e a sua confiança vai aumentar


Ser ReactivoProblema: Qual é a resposta aceitável aos pedidos do cliente?Forças:

Queremos ser atenciosos com os clientesNem sempre podemos dar uma resposta imediata

Solução:Responder ao telefonemas dos clientes no mesmo diaConfirmar 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 ClienteProblema: 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 produtoEstratégias de gestão de tempo desencorajam as reuniões

Solução:Chegar à reunião com antecedência para conhecer as pessoasApó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 IntegridadeProblema: O que se deve partilhar com o cliente?Forças:

Não se pode informar o cliente sobre todos os riscos possíveisOs clientes querem ser informados acerca de tudo

Solução:Identificar os N riscos do projecto e partilhar o impacto desses riscos com o clienteEvitar a honestidade que é destrutiva

Contexto Resultante:O cliente aprende a confiar na nossa palavraO cliente reage mais calmamente quando lhe anunciamos novos riscos para o projecto


Não AquecerProblema: Como lidar com um cliente zangado?Forças:

A resposta natural é ser defensivo mas isso vai aumentar a irritação do clienteA irritação estraga a relação com o clienteQueremos defender os nossos interesses

Solução:Não argumentar, um cliente irritado não é racional, ouvir, ouvirNão tentar acalmar o cliente fazendo promessas, fazer perguntasDescobrir 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 LimitesProblema: Quando se está em modo de solução é difícil pensar nas consequências de propor uma solução e de dar uma respostaForças:

Desejamos satisfazer os clientesOs clientes podem ter expectativas ou pedidos irrealistasNã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 papelTomar 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 ManeirasProblema: Quando se interage com os clientes nem sempre se pensa sobre etiqueta, vestir e comportamentoForças:

Algumas pessoas pensam que considerar etiqueta, vestir e comportamento são uma perda de tempoAs pessoas podem reagir pessoalmente a faltas de etiqueta, vestir ou comportamento descuidado

Solução:Vestir de acordo com as expectativas dos clientesMostrar respeito por todos inclusive a concorrênciaCuidado particular com as interacções com os da nossa companhia em frente dos clientes

Contexto Resultante:As expectativas do cliente são satisfeitas


Um Processo de Análise de Requisitos para

Desenvolvimento com Objectos

Bruce WhitenackRAPPeL:

A Requirements Analysis Process Pattern Language for Object Oriented Development

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


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


Construir o NecessárioProblema: 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ícilOs clientes não conseguem expressar convenientemente os seus requisitosA equipa de desenvolvimento tem dificuldade em entender o que é que o cliente pretende

Os requisitos alteram-se, são incompletos e incoerentesO espaço do problema é mal conhecido


Construir o NecessárioSolução:

Utilizar as seguintes técnicasGerir as expectativas do clienteManter uma relação com o cliente Capturar e validar os objectivos do responsável do negócioFazer uma análise de requisitos

Análise do domínio do problemaEspecificação de requisitosValidação de requisitos

Usar protótipos


Gerir as Expectativas do ClienteProblema: Como se gerem e satisfazem as expectativas do cliente acerca do produtoForças:

Um produto pode satisfazer tecnicamente a especificação de requisitos mas não satisfazer o clienteNão é possível assegurar que um produto vai 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ávelDesenvolver protótipos para validar que o comportamento do sistema vai satisfazer as expectativas do cliente


Relação com o ClienteProblema: 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çãoQuando 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 clientePrimeiro entendimento depois entender


Objectivos do NegócioProblema: Como se alinham os objectivos do negócio com o sistema que está a ser desenvolvidoForças:

Um sistema desenvolvido pode, de acordo com os requisitos, estar completo mas não satisfazer 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ócioNão se devem ter mais do que oito objectivos do negócio


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

Solução:Escrever cada processo de negócio Inicialmente escrever os processos de negócio principaisOs casos de uso devem ser derivados dos processos de negócioUsar protótipos de interface, em papel, para visualizar como é que o utilizador vai interagir com o sistema


Regras de NegócioProblema: 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 explícitasNormalmente 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


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 estadoRestriçã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-classeComputação – define resultados em termos de uma equação ou algoritmo

Regras de Negócio


Definição de RequisitosProblema: 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 termosElaborar:

Análise do domínioRequisitos de comportamentoAnálise do domínio do problema


Requisitos de ComportamentoProblema: Qual deve ser o comportamento do sistema?Forças: os requisitos de comportamento são geralmente muito vagosSolução:

Os comportamentos devem ser descritos em termos de casos de usoOs clientes do sistema devem ser identificados e definidos num diagrama de fronteira do sistemaAs entidades externas são classificadas como clientes e servidoresPara cada cliente listar todos os casos de uso numa Matriz de Casos de uso


Requisitos de ComportamentoDescrever cada caso de uso em detalheSempre que relevante associar a cada caso de uso:

Regras de negócioRelações entre objectosProtótiposDiagramas de fluxo de janelas

Se necessário usar uma tabela de decisão para identificar todos os estímulos que originam casos de usoSe houver sequências de estímulos usar diagramas de transiçãoSe houver muita sincronização usar diagramas de actividade


Análise do DomínioProblema: Como se define o domínio do problema no qual o sistema vai ser desenvolvidoForças:

O objectivo da análise do domínio do problema é fornecer um entendimento da área do problemaA análise do domínio não tem como objectivo a definição de requisitos

Solução:Define-se uma comunidade de objectos interrelacionadosProcede-se às seguintes actividades de identificação:

Informação NecessáriaIdentificar e Definir os Objectos do DomínioClassificação, Associação e Agrupamento de ObjectosRefinamento dos Objectos do DomínioCiclo de Vida do ObjectoEstereótipos de Objecto


Informação NecessáriaProblema: 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ócioMuitas 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çãoConstruir uma Matriz de Informação que identifica o objecto de informação, a sua fonte e a sua descrição


Identificar e Definir os ObjectosProblema: 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 objectoExistem objectos simples e objectos complexosExistem objectos que são visíveis pelos utilizadores finais enquanto que outros existem para suportar os primeirosOs objectos podem ser agrupados em papéis, o que ajuda a entender o essencial do domínio do problema


Identificar e Definir os ObjectosSolução:

Procurar os objectos em:Descrições de casos de usoGlossários de termosDescrições de processos de negócio

Definir as responsabilidades de cada objectoBaseado nas responsabilidades determinar o conjunto de papéis que o objecto possui


Classificação, Associação e AgrupamentoProblema: 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 comportamentoAnimar o cenário para determinar os colaboradores necessários para o objecto cumprir a responsabilidadeConsiderar todos os casos de uso e eventos que são desencadeados por clientes externos e desenvolver um cenário associado a cada um delesAnimar os cenáriosComo resultado das animações anteriores definir um diagrama de estrutura que defina os relacionamentos entre os objectos


Refinamento dos ObjectosProblema: Quais são os atributos dos objectos? Que regras restringem os objectos? Forças:

Alguns atributos dependem da implementaçãoExistem 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 fornecerCapturar as regras de negócio


Ciclo de Vida do ObjectoProblema: 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ócioAtribuir nomes de negócio aos estados identificadosConstruir diagramas de transição de estado


Estereótipos de ObjectoProblema: 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 standard:

Contentores de informaçãoControladoresCoordenadoresFornecedores de serviçoObjectos de interface

Definir estereótipos específicos do domínio


Para Além da FuncionalidadeProblema: 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 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 InterfaceProblema: Qual é a melhor forma de determinar os requisitos de interface utilizador?Forças:

80% da satisfação do utilizador vem da interfaceA interface utilizador deve transmitir a visão lógica que o utilizador tem do sistemaRequisitos 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 RequisitosProblema: Como especificar os requisitos de modo a satisfazer os diversos intervenientes?Forças:

Os requisitos podem ser descritos usando:Linguagem naturalLinguagens formaisProtótipos

Solução:Usar a matriz para a especificação de requisitos definida em http://www.atlsysguild.com/GuildSite/Robs/Template.htmlUsar casos de uso


Validação de RequisitosProblema: 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

Solução:Todos os intervenientes devem ler a especificação de requisitosConduzir reuniões de revisão dos requisitosRevisão dos protótipos com os utilizadoresRegistar todas as questões levantadas durante as revisõesContinuar a verificação dos requisitos durante todo o processo de desenvolvimentoSe necessário, escolher um grupo de arbitragem para reconciliar desacordos


Exemplo: Figura DensaObter informação

de qualidade sobre a disciplina

Alunos

Introd

uzem

Inform

ação

pesso

al

Obtêm

Inform

ação

discip

lina

Equipaalunos

Papéis

IST/CIIST

Desenvolvimento

Aprovação à disciplina

Fornecer melhoresserviços à escola

Vendemos um conjunto integrado

de aplicações

Empresa XPTO

Docentes de EP

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

IST

Integram

Gestão de EP

GesDis


Exemplo: Modelo de Domínio

Aluno

email : string

número : integernome : stringestado : undefinedpassword : string

Secção

nome : stringordem : integernome : string 1email : string 1

Item

nome : stringvalor : string

Grupo

horário : undefinednúmero : integersala : string

Tipo Grupo

máximo : integermínimo : integerideal : integer

número : integernome : stringestado : undefinedpassword : string

horário : undefinednúmero : integersala : string

0..1**

*

máximo : integermínimo : integerideal : integer

1

nome : stringvalor : string

1

*

Docente

nome : stringusername : stringpassword : stringemail : string

SubSecçãoSecçãoTopoPágina

departamento : stringlicenciatura : stringdisciplina : string

semestre : undefinedano : undefined

departamento : stringlicenciatura : stringdisciplina : string

semestre : undefinedano : undefined

nome : stringusername : stringpassword : stringemail : string

* *

* 1

ordem : integer

*

*1


Exemplo: Actores

Aluno Docente

Pessoa


Exemplo: Casos de Uso

GesDis

Aluno

Pessoa

Inscrição de Aluno

Inscrição em Grupo

Visualizar Secção

Visualizar Página

Docente

Registar AlunosSecretaria

Inserir Aluno

Editar Aluno

Apagar Aluno


Exemplo: Registar Alunos<<description>>

Registar alunos.

Pré-condiçãoA 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 alternativosNo 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 secretariaNo passo 2: O aluno já registado não surge na nova pauta; o seu registo passa a anulado.

Pós-condiçãoCaminho 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õesP8 – 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 delesRecompensar a equipa de acordo com as prioridades


P11 – Desenvolver o Tipo Adequado de Protótipo

Evolutivos quando os aspectos críticos estão dominadosDescartáveis quando os aspectos críticos não estão dominadasProtótipos descartáveis apenas devem incluir as características que não estão dominadas

P13 – Desenvolver Rapidamente Protótipos Descartáveis

Conclusões


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 na Selecção de Interfaces UtilizadorP43 – Registar a Razão para cada Requisito

Ulteriormente é possível verificar as consequências de alterar

Conclusões


P44 – Dividir para ConquistarIdentificar o conjunto mínimo de requisitos que pode ser útilIdentificar os incrementos mínimos que tornam o conjunto mínimo de requisitos mais útil

P45 – Fazer Revisão de RequisitosDe modo a envolver todos os intervenientes

P46 – Evitar Fazer Desenho nos Requisitos

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

Conclusões


ConclusõesP47 – 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

EstruturaComportamentoNegócio

P49 – Organizar os RequisitosDa forma mais útil categorizando por utilizador, estímulo, objecto...


P50 – Atribuir Prioridades aos Requisitos

Obrigatório, Desejável e Opcional

P51 – Escrever com ConcisãoP52 – Numerar cada RequisitoP53 – Reduzir a Ambiguidade dos Requisitos

Usar linguagem natural e linguagens formais

Conclusões


P54 – Aumentar, Nunca Substituir, a Linguagem Natural

Manter ambas as descrições

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

(1) escrever em linguagem natural(2) escrever o modelo formal(3) adaptar a linguagem natural para reduzir ambiguidades

Conclusões


ConclusõesP56 – Manter a Especificação de Requisitos LegívelP57 – Especificar a Fiabilidade Explicitamente

Percentagem de pedidos a cuja resposta o sistema falhaPercentagem de tempo em que um pedido pode falharPercentagem de tempo que o sistema pode não estar disponível


ReferênciasPfleeger98, Capítulo 4, excepto 4.5.David95, Alguns princípios dos Capítulos 2 e 3.Volere - Requirements Specification Templatehttp://www.atlsysguild.com/GuildSite/Robs/Template.html

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


ReferênciasRequirements: 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

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

Date post:	20-Mar-2018
Category:	Documents
Upload:	lamnguyet
View:	215 times
Download:	3 times

Casos Notáveis Padrões de Interacção com o Cliente5-2).pdf · Engenharia de Requisitos 62 Casos...

Documents