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
Engenharia de Requisitos 63
Padrões de Interacção com o ClienteLinda Rising
Customer Interaction PatternsIn Harrison2000. Capítulo 26.
Engenharia de Requisitos 64
É 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
Engenharia de Requisitos 65
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
Engenharia de Requisitos 66
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
Engenharia de Requisitos 67
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
Engenharia de Requisitos 68
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
Engenharia de Requisitos 69
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
Engenharia de Requisitos 70
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
Engenharia de Requisitos 71
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
Engenharia de Requisitos 72
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
Engenharia de Requisitos 73
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
Engenharia de Requisitos 74
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
Engenharia de Requisitos 75
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
Engenharia de Requisitos 76
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
Engenharia de Requisitos 77
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
Engenharia de Requisitos 78
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
Engenharia de Requisitos 79
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
Engenharia de Requisitos 80
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
Engenharia de Requisitos 81
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
Engenharia de Requisitos 82
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
Engenharia de Requisitos 83
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
Engenharia de Requisitos 84
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
Engenharia de Requisitos 85
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
Engenharia de Requisitos 86
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
Engenharia de Requisitos 87
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
Engenharia de Requisitos 88
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
Engenharia de Requisitos 89
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
Engenharia de Requisitos 90
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
Engenharia de Requisitos 91
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
Engenharia de Requisitos 92
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
Engenharia de Requisitos 93
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
Engenharia de Requisitos 94
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
Engenharia de Requisitos 95
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
Engenharia de Requisitos 96
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
Engenharia de Requisitos 97
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
Engenharia de Requisitos 98
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
Engenharia de Requisitos 99
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
Engenharia de Requisitos 100
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
Engenharia de Requisitos 101
Exemplo: Actores
Aluno Docente
Pessoa
Engenharia de Requisitos 102
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
Engenharia de Requisitos 103
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.
Engenharia de Requisitos 104
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
Engenharia de Requisitos 105
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
Engenharia de Requisitos 106
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
Engenharia de Requisitos 107
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
Engenharia de Requisitos 108
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...
Engenharia de Requisitos 109
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
Engenharia de Requisitos 110
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
Engenharia de Requisitos 111
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
Engenharia de Requisitos 112
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
Engenharia de Requisitos 113
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
Top Related