ENGENHARIA DE REQUISITOS Análise e Modelação de Sistemas 2006

ENGENHARIA ENGENHARIA DE DE

REQUISITOSREQUISITOS

Análise e Modelação de Análise e Modelação de SistemasSistemas

20062006

Engenharia de RequisitosEngenharia de Requisitos

• A engenharia de requisitos (no A engenharia de requisitos (no contexto da engenharia de software) contexto da engenharia de software)

• É um processo que engloba todas as É um processo que engloba todas as actividadesactividades

• Que contribuem para a produção de Que contribuem para a produção de um documento de requisitosum documento de requisitos

• E sua manutenção ao longo do E sua manutenção ao longo do tempo.tempo.

Engenharia de RequisitosEngenharia de Requisitos

• Este processo deve ser precedido de Este processo deve ser precedido de estudos de viabilidade estudos de viabilidade

• Que a partir das restrições do Que a partir das restrições do projecto, determinam se este é ou não projecto, determinam se este é ou não viável viável

•E se se deve prosseguir para a E se se deve prosseguir para a identificação dos requisitos.identificação dos requisitos.

Conceito de RequisitosConceito de Requisitos

O que são O que são requisitosrequisitos de um sistema? de um sistema?

• descrições de como o sistema se descrições de como o sistema se deve comportardeve comportar

• descrições de propriedades do descrições de propriedades do sistemasistema

• descrições de restrições do sistema descrições de restrições do sistema ou condicionantes no seu ou condicionantes no seu desenvolvimentodesenvolvimento


• mais definições...mais definições...•uma capacidade de um sistema de uma capacidade de um sistema de software que um utilizador necessita para software que um utilizador necessita para resolver um problema ou atingir um resolver um problema ou atingir um objectivo objectivo

•uma capacidade que um sistema de uma capacidade que um sistema de software deve possuir para satisfazer um software deve possuir para satisfazer um contracto, especificação, norma, ou contracto, especificação, norma, ou qualquer outra documentação impostaqualquer outra documentação imposta

Conceito de RequisitosConceito de Requisitosrequisitos frequisitos funcionaisuncionais

descrevem o que o sistema deve fazerdescrevem o que o sistema deve fazer

exemplosexemplos

"o sistema deve possibilitar armazenar os pedidos de "o sistema deve possibilitar armazenar os pedidos de orçamento"orçamento"

"o sistema deve possibilitar a paragem de emergência do motor"o sistema deve possibilitar a paragem de emergência do motor

requisitos requisitos não-funcionaisnão-funcionais

descrevem as restrições na implementação dos requisitos descrevem as restrições na implementação dos requisitos funcionaisfuncionais

exemplosexemplos

"o sistema deve permitir armazenar pelo menos 500 pedidos de "o sistema deve permitir armazenar pelo menos 500 pedidos de orçamento por ano"orçamento por ano"

"o sistema operativo a usar deve ser linux""o sistema operativo a usar deve ser linux"

"a paragem de emergência deve ser realizada em menos de 3 "a paragem de emergência deve ser realizada em menos de 3 segundos"segundos"

Onde terminam os requisitos?Onde terminam os requisitos?

• "Os requisitos terminam onde começa a liberdade do "Os requisitos terminam onde começa a liberdade do implementador"implementador"

• Idealmente, todas as decisões que têm de ser validadas Idealmente, todas as decisões que têm de ser validadas pelo cliente (que o implementador não pode tomar pelo cliente (que o implementador não pode tomar isoladamente), devem estar contidas no documento de isoladamente), devem estar contidas no documento de requisitosrequisitos

• Na prática, não é possível ou economicamente viável prever Na prática, não é possível ou economicamente viável prever tudo à partida, e é necessário manter um diálogo constante tudo à partida, e é necessário manter um diálogo constante com o clientecom o cliente

• O nível de detalhe desejável varia de situação para situaçãoO nível de detalhe desejável varia de situação para situação


• níveis de requisitosníveis de requisitos•alto nível:alto nível: missões, objectivos, regras do missões, objectivos, regras do negócionegócio

•baixo nível:baixo nível: necessidades dos necessidades dos utilizadores, funcionalidades, restriçõesutilizadores, funcionalidades, restrições

O processo de O processo de Engenharia de Engenharia de RequisitosRequisitos• É constituído por quatro actividades É constituído por quatro actividades

de alto nível (Soares, 2005):de alto nível (Soares, 2005):

• Identificação. Identificação.

• Análise e negociação. Análise e negociação.

• Especificação e documentação. Especificação e documentação.

• Validação. Validação.

O processo de engenharia de O processo de engenharia de requisitos:requisitos:modelo de actividades de alto modelo de actividades de alto nívelnível

identificação, descoberta de requisitos

análise e negociação de requisitos

documentação, especificação de requisitos

validação de requisitos

documento de

requisitos

necessidades dos utilizadores, sistemas legados,informação do domínio, normas organizacionais, etc.

O processo de engenharia de O processo de engenharia de requisitos:requisitos: entradas e saídas entradas e saídas

processo de engenharia de

requisitosespecificação

dosistema

requisitos(acordados)

sistemas

legadosnecessidades

dos utilizadores

normasda

organização

regulamentos

informaçãodo

domínio (Kotonya e Sommerville, 1998)

O processo de engenharia de requisitosO processo de engenharia de requisitos*qualidade do processo de ER*qualidade do processo de ER

modelo de maturidademodelo de maturidade

nível 1. inicialPER adhoc

nível 2. repetívelPER obedecendo

a normas

nível 3. definidoPER baseado

em melhores práticas;melhoria contínua

O processo de engenharia de requisitosO processo de engenharia de requisitosactores no processoactores no processo

especialista do domínio

utilizador final engenheiro de software

responsável de projecto

engenheiro de requisitos / analista

processo deengenharia de requisitos

O processo de engenharia de requisitosO processo de engenharia de requisitosactores no processo: actores no processo: stakeholdersstakeholders

• Quem são os "interessados no Quem são os "interessados no sistema" (sistema" (stakeholdersstakeholders)?)?•São as pessoas que serão afectadas pelo São as pessoas que serão afectadas pelo sistema sistema

•E que têm uma influência directa ou E que têm uma influência directa ou indirecta na elaboração dos requisitos:indirecta na elaboração dos requisitos:

O O processo de engenharia de requisitosprocesso de engenharia de requisitosactores no processo: actores no processo: stakeholdersstakeholders

• Quem são os "interessados no Quem são os "interessados no sistema" (sistema" (stakeholdersstakeholders))

• Utilizadores finais, gestores e outros Utilizadores finais, gestores e outros envolvidos nos processos organizacionais que envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistemadesenvolvimento e manutenção do sistema

• Clientes da organização que possam vir a Clientes da organização que possam vir a usar o sistema, organismos de regulação e usar o sistema, organismos de regulação e certificação, etc.certificação, etc.

Processo de descoberta de requisitos Processo de descoberta de requisitos "orientado ao problema""orientado ao problema"

acordar na definição

do problema

entender as causas

do problema

identificar os

stakeholders

definir as fronteiras da solução

identificar as

restrições da solução

• análise de problemas - processo de compreender um problema análise de problemas - processo de compreender um problema e propor soluções para resolver esse problemae propor soluções para resolver esse problema

identificaridentificar os os stakeholdersstakeholders

• compreender as necessidades dos compreender as necessidades dos interessados no sistema é um factor interessados no sistema é um factor decisivo no desenvolvimento de uma decisivo no desenvolvimento de uma solução efectiva para um problemasolução efectiva para um problema

– quem são os utilizadores do sistema?quem são os utilizadores do sistema?– quem é o cliente (comprador) do sistema?quem é o cliente (comprador) do sistema?– quem será afectado pelas saídas que o sistema produz?quem será afectado pelas saídas que o sistema produz?– quem fará a manutenção do sistema?quem fará a manutenção do sistema?

Definir as fronteiras da Definir as fronteiras da soluçãosolução

– quem fornece, utiliza, remove informação do quem fornece, utiliza, remove informação do sistema? quem opera o sistema? quem faz sistema? quem opera o sistema? quem faz manutenção do sistema? onde é que o sistema é manutenção do sistema? onde é que o sistema é usado? como obtém o sistema a sua informação? usado? como obtém o sistema a sua informação? que outros sistema interactuam com o sistema?que outros sistema interactuam com o sistema?

outros sistemas

fronteira do sistema

solução

utilizadores

identificar as restrições da identificar as restrições da soluçãosolução

• restrições no grau de liberdade que temos restrições no grau de liberdade que temos para desenvolver o sistemapara desenvolver o sistema

– económicaseconómicas– políticaspolíticas– tecnológicastecnológicas– sistemas existentessistemas existentes– ambienteambiente– recursosrecursos

Acordar na definição do Acordar na definição do problemaproblema

•exemplo de formulação do problemaexemplo de formulação do problema

"o "o problemaproblema de se passar demasiado tempo a produzir de se passar demasiado tempo a produzir a documentação do projecto a documentação do projecto afectaafecta os parceiros do os parceiros do projecto e projecto e resultaresulta em atrasos significativos no em atrasos significativos no cumprimento dos prazos; cumprimento dos prazos;

os os benefíciosbenefícios do sistema que gerisse a documentação do sistema que gerisse a documentação à medida que é produzida residiriam numa menor à medida que é produzida residiriam numa menor percentagem de incumprimento de prazos e numa percentagem de incumprimento de prazos e numa melhor relação com os parceiros"melhor relação com os parceiros"

O processo de engenharia de O processo de engenharia de requisitosrequisitos

boas práticas boas práticas • algumas boas práticasalgumas boas práticas

• definir uma estrutura normalizada para o documento de definir uma estrutura normalizada para o documento de requisitosrequisitos

• identificar univocamente cada requisitoidentificar univocamente cada requisito

• definir políticas de gestão de requisitosdefinir políticas de gestão de requisitos

• usar usar checklistschecklists de problemas para a análise de requisitos de problemas para a análise de requisitos

• usar cenários para identificar os requisitosusar cenários para identificar os requisitos

• especificar os requisitos quantitativamenteespecificar os requisitos quantitativamente

• usar prototipagem para animar os requisitosusar prototipagem para animar os requisitos

• reutilizar requisitosreutilizar requisitos

• especificar sistemas formalmenteespecificar sistemas formalmente

• etc.,etc.,

http://pt.wikipedia.org/wiki/Imagem:Spiral.jpg

IDENTIFICACÃOIDENTIFICACÃODOSDOS

REQUISITOS REQUISITOS

Processo de engenharia de Processo de engenharia de requisitos: modelo de requisitos: modelo de actividades de alto nívelactividades de alto nível


análise e negociação de requisitos especificação

, documentação de requisitos validação de

requisitos

documento de

Requisitos


Processo de engenharia de Processo de engenharia de requisitos: modelo em espiralrequisitos: modelo em espiral

(Kotonya e Sommerville, 1998; SWEBOK)

Dimensões da descobertaDimensões da descoberta de requisitosde requisitos

compreender o domínio de

aplicaçãocompreender o problema aser resolvido

compreender o contexto de

negócio

compreender as

necessidades erestrições dosinteressados

Kotonya, 1998

como é que o sistema contribui para os objectivos do negócio?etc.

estende e especializa conhecimento geral do domínio

que actividades devem ser suportadas pelo sistema?qual o papel de sistemas existentes?etc.

conhecimento geral do domínio

Estágios do ProcessoEstágios do Processo

• Estabelecimento de objectivos Estabelecimento de objectivos – Objectivos gerais do negócio, descrição genérica do problema a Objectivos gerais do negócio, descrição genérica do problema a

resolver, necessidade do sistema e restrições sobre o sistema. resolver, necessidade do sistema e restrições sobre o sistema.

• Aquisição de conhecimento de Aquisição de conhecimento de backgroundbackground– informação sobre a organização em que o sistema vai ser instalado, o informação sobre a organização em que o sistema vai ser instalado, o

domínio de aplicação do sistema e informação sobre sistemas domínio de aplicação do sistema e informação sobre sistemas existentesexistentes

• Organização do conhecimentoOrganização do conhecimento– Organizar a grande quantidade de conhecimento (informação?) Organizar a grande quantidade de conhecimento (informação?)

recolhida no estágio anterior. recolhida no estágio anterior.

• Recolher requisitos dos Recolher requisitos dos stakeholdersstakeholders– Consultar os interessados no sistema para descobrir os seus requisitos.Consultar os interessados no sistema para descobrir os seus requisitos.

Fontes de requisitos (1)Fontes de requisitos (1)– objectivos gerais de alto nível do sistemaobjectivos gerais de alto nível do sistema

• objectivos gerais de alto nível do sistema, objectivos gerais de alto nível do sistema, problema que o sistema deve resolver, motivação problema que o sistema deve resolver, motivação para a implementação do sistema, factores para a implementação do sistema, factores críticos de sucesso, interesse para o negócio, ...críticos de sucesso, interesse para o negócio, ...

• necessário avaliar custos e benefícios de atingir os necessário avaliar custos e benefícios de atingir os objectivos, por exemplo com estudo de viabilidadeobjectivos, por exemplo com estudo de viabilidade

– conhecimento do domínio de aplicaçãoconhecimento do domínio de aplicação• necessário para inferir conhecimento tácito que os necessário para inferir conhecimento tácito que os

stakeholdersstakeholders não explicitam, avaliar não explicitam, avaliar trade-offs trade-offs entre requisitos conflituosos, etc.entre requisitos conflituosos, etc.

• pode ser obtido junto de especialistas do domínio, pode ser obtido junto de especialistas do domínio, documentos, etc.documentos, etc.

– stakeholders stakeholders do sistemado sistema• fundamental identificar, representar e gerir os fundamental identificar, representar e gerir os

pontos de vista, interesses e necessidades de pontos de vista, interesses e necessidades de todos os interessados no sistema (utilizadores, todos os interessados no sistema (utilizadores, clientes, etc.)clientes, etc.)

(fonte: SWEBOK)

Fontes de requisitos (2)Fontes de requisitos (2)– ambiente operacionalambiente operacional

• o ambiente operacional em que o sistema vai executar o ambiente operacional em que o sistema vai executar pode impor diversos requisitospode impor diversos requisitos

– aproveitamento de infra-estruturas físicas e lógicas existentesaproveitamento de infra-estruturas físicas e lógicas existentes

– interoperabilidade com sistemas existentes (internos ou interoperabilidade com sistemas existentes (internos ou externos)externos)

– etc.etc.

– ambiente organizacionalambiente organizacional• muitos sistemas destinam-se a suportar processos de muitos sistemas destinam-se a suportar processos de

negócio, devendo-se adequar à estrutura, cultura, negócio, devendo-se adequar à estrutura, cultura, políticas, regras e normas internas da organização políticas, regras e normas internas da organização (intra/inter)(intra/inter)

– ambiente externoambiente externo • normas, regulamentos, legislação, etc.normas, regulamentos, legislação, etc.• podem impor requisitospodem impor requisitos• exemplos: lei de protecção de dados pessoais, normas de exemplos: lei de protecção de dados pessoais, normas de

acessibilidade, POC, ...acessibilidade, POC, ...

(fonte: SWEBOK)

Técnicas de descoberta de Técnicas de descoberta de requisitosrequisitos

– análise de documentação análise de documentação – análise de sistemas existentesanálise de sistemas existentes– entrevistasentrevistas– encontros facilitadosencontros facilitados ( (workshopsworkshops, ,

brainstormingbrainstorming))– cenárioscenários– protótiposprotótipos– observação e análise social, estudos observação e análise social, estudos

etnográficosetnográficos– soft systems methodssoft systems methods– reutilização de requisitosreutilização de requisitos

ENTREVISTASENTREVISTAS

EntrevistasEntrevistas

•entrevistar os futuros utilizadores e entrevistar os futuros utilizadores e outros outros stakeholdersstakeholders é a técnica mais é a técnica mais vulgar e simples de obter informação vulgar e simples de obter informação para identificar requisitospara identificar requisitos


•a entrevista é uma técnica a entrevista é uma técnica simples, mas não é fácil de aplicar simples, mas não é fácil de aplicar


– Enviesamento de quem conduz a Enviesamento de quem conduz a entrevista: entrevista:

– Relação pessoal entre os Relação pessoal entre os intervenientes na entrevista:intervenientes na entrevista:

– predisposição do entrevistado:predisposição do entrevistado:– Capacidade de seguir um "plano" Capacidade de seguir um "plano"

para a entrevista:para a entrevista:


•tipos de entrevistastipos de entrevistas

– estruturadas vs. não estruturadasestruturadas vs. não estruturadas– descontextualizadas vs. descontextualizadas vs.

contextualizadas pela soluçãocontextualizadas pela solução


• Entrevistas e QuestionáriosEntrevistas e Questionários: esta é talvez a técnica mais : esta é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns factores: algumas dúvidas), está condicionada a alguns factores:

• Enviesamento de quem conduz a entrevistaEnviesamento de quem conduz a entrevista: convém : convém que o entrevistador dê margem ao entrevistado para expor que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida). as suas ideias sem as enviesar logo à partida).

• Relação pessoal entre os intervenientes na entrevistaRelação pessoal entre os intervenientes na entrevista . .

http://pt.wikipedia.org/wiki/Entrevistas_a_Stakeholders


• Predisposição do entrevistado:Predisposição do entrevistado: caso, por exemplo, o caso, por exemplo, o papel do entrevistado venha a ser afectado pela papel do entrevistado venha a ser afectado pela introdução de um sistema na organização, este pode introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação. propositadamente dificultar o acesso à informação.

• Capacidade de seguir um "plano" para a entrevista:Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).superficial (ou podem nem chegar a ser abordados).

Elaboração das perguntasElaboração das perguntas Perguntas de contexto livre Perguntas de contexto livre

• Como exemplo de perguntas deste género, Como exemplo de perguntas deste género, podemos ter:podemos ter:

• Quem são os utilizadores? Quem são os utilizadores? • Quem é o cliente? Quem é o cliente? • Têm necessidades diferentes? Têm necessidades diferentes? • Onde podem ser encontradas outras soluções Onde podem ser encontradas outras soluções

para este problema? para este problema?

Elaboração das perguntasElaboração das perguntas

Perguntas centradas na Perguntas centradas na soluçãosolução• Após terem sido feitas as perguntas Após terem sido feitas as perguntas

de contexto livre, pode começar-se a de contexto livre, pode começar-se a explorar as soluções propostas com explorar as soluções propostas com estas perguntas mais direccionadas:estas perguntas mais direccionadas:

• (Apresentar as capacidade gerais de uma (Apresentar as capacidade gerais de uma solução) E se pudesse fazer ... e ...? solução) E se pudesse fazer ... e ...?

• Como classificaria a importância de cada Como classificaria a importância de cada uma das funcionalidades apresentadas? uma das funcionalidades apresentadas?

Aqui ficam algumas dicas para Aqui ficam algumas dicas para uma entrevista de sucesso:uma entrevista de sucesso:

• Prepare uma entrevista de contexto livre apropriada, Prepare uma entrevista de contexto livre apropriada, e tome nota para que isso sirva como referência no e tome nota para que isso sirva como referência no decorrer da entrevista. Faça uma revisão às questões decorrer da entrevista. Faça uma revisão às questões a colocar nos momentos que antecedem a entrevista. a colocar nos momentos que antecedem a entrevista.

• Antes da entrevista faça uma pesquisa ao Antes da entrevista faça uma pesquisa ao backgroundbackground do do stakeholderstakeholder e da empresa a serem entrevistados. e da empresa a serem entrevistados. Não mace a pessoa a ser entrevistada com perguntas Não mace a pessoa a ser entrevistada com perguntas que poderia facilmente saber a resposta à priori. que poderia facilmente saber a resposta à priori. Ainda assim, pode confirmar brevemente essas Ainda assim, pode confirmar brevemente essas respostas dando a mostrar o seu interesse e respostas dando a mostrar o seu interesse e conhecimento da pessoa e empresa em questão. conhecimento da pessoa e empresa em questão.

Aqui ficam algumas dicas para Aqui ficam algumas dicas para uma entrevista de sucesso:uma entrevista de sucesso:• Anote as respostas no seu bloco de notas durante a Anote as respostas no seu bloco de notas durante a

entrevista. (Não tente capturar a informação de forma entrevista. (Não tente capturar a informação de forma electrónica nesta fase!) electrónica nesta fase!)

• Consulte as notas da estrutura da entrevista no decorrer da Consulte as notas da estrutura da entrevista no decorrer da mesma. Desta forma tem a certeza que está a fazer as mesma. Desta forma tem a certeza que está a fazer as perguntas correctas e que não se está a desviar dos perguntas correctas e que não se está a desviar dos objectivos definidos. objectivos definidos.

• Discuta os problemas com o utilizador. Esclareça situações Discuta os problemas com o utilizador. Esclareça situações que possa observar no ambiente. Faça sugestões e que possa observar no ambiente. Faça sugestões e observações baseadas em conhecimento teórico e observações baseadas em conhecimento teórico e familiarização com outros sistemas. familiarização com outros sistemas.

Entrevista e CompilaçãoEntrevista e Compilação

• O guião da entrevista não deve ser O guião da entrevista não deve ser demasiado restritivo. Depois de demasiado restritivo. Depois de estabelecida uma ligação positiva com o estabelecida uma ligação positiva com o entrevistado, é normal que a entrevista entrevistado, é normal que a entrevista acabe por entrar numa dinâmica própria.acabe por entrar numa dinâmica própria.

• Após a realização das entrevistas, o Após a realização das entrevistas, o analista já deve ter ficado com um leque analista já deve ter ficado com um leque de necessidades identificadas. Para de necessidades identificadas. Para compilar o conjunto de necessidades compilar o conjunto de necessidades gerais dos utilizadores entrevistados deve gerais dos utilizadores entrevistados deve ser usado um método que pode ser ser usado um método que pode ser denominado de "Resumo do Analista". denominado de "Resumo do Analista".

Vantagens Vantagens

• É a forma mais fácil de descobrir as necessidades de um sistema, É a forma mais fácil de descobrir as necessidades de um sistema, pois passa por perguntar directamente aos pois passa por perguntar directamente aos stakeholdersstakeholders. .

• Permite uma melhor compreensão do problema e seu domínio. Permite uma melhor compreensão do problema e seu domínio.

• Pode ser utilizada em praticamente qualquer situação. Pode ser utilizada em praticamente qualquer situação.

• É uma solução de baixo custo. É uma solução de baixo custo.

• Uma vez bem definidas as perguntas e estrutura da entrevista, é Uma vez bem definidas as perguntas e estrutura da entrevista, é possível encontrar requisitos reais, e não apenas necessidades de possível encontrar requisitos reais, e não apenas necessidades de alto nível. alto nível.

• É um método que aproxima as entidades envolvidas no projecto. É um método que aproxima as entidades envolvidas no projecto.

Desvantagens Desvantagens

• Consome bastante tempo. Consome bastante tempo.

• Utilizadores diferentes podem ter Utilizadores diferentes podem ter necessidades contraditórias. necessidades contraditórias.

• Pode originar grandes discrepâncias Pode originar grandes discrepâncias entre o funcionamento actual do entre o funcionamento actual do processo de negócio, e o plano para o processo de negócio, e o plano para o futuro. futuro.

Workshops Workshops dede

RequisitosRequisitos

WorkshopsWorkshops

•uma workshop de requisitos é uma uma workshop de requisitos é uma técnica de grupo para o debate e técnica de grupo para o debate e acordo das questões asociadas à acordo das questões asociadas à identificação dos requisitosidentificação dos requisitos

– levada a cabo através da formação de um levada a cabo através da formação de um grupo de representantes dos grupo de representantes dos stakeholdersstakeholders

– facilitada por alguém com competência facilitada por alguém com competência para conduzir o processo de identificação para conduzir o processo de identificação e análise de e análise de requisitosrequisitos

WorkshopsWorkshops

•preparaçãopreparação

– "vender" o conceito"vender" o conceito– assegurar a participação dos assegurar a participação dos

stakeholdersstakeholders adequados adequados– garantir os aspectos logísticosgarantir os aspectos logísticos– fornecer materiais para discussão fornecer materiais para discussão

antecipadamenteantecipadamente– escolher o facilitadorescolher o facilitador– estabelecer uma agendaestabelecer uma agenda

Note-se que uma workshop, Note-se que uma workshop, apesar de se assemelhar a uma apesar de se assemelhar a uma reunião, difere em alguns pontos:reunião, difere em alguns pontos:

• Reuniões são lideradas por um gestor (líder, que geralmente, faz Reuniões são lideradas por um gestor (líder, que geralmente, faz pouca preparação). As workshops são lideradas por um facilitador pouca preparação). As workshops são lideradas por um facilitador neutro que se prepara intensivamente; neutro que se prepara intensivamente;

• As reuniões não requerem trabalho prévio por parte da assistência. As reuniões não requerem trabalho prévio por parte da assistência. As workshops requerem muito trabalho prévio, incluíndo a criação As workshops requerem muito trabalho prévio, incluíndo a criação de produtos que servem de candidatos a inputs do workshop; de produtos que servem de candidatos a inputs do workshop;

• As decisões numa reunião são tomadas pelo gestor, e podem não As decisões numa reunião são tomadas pelo gestor, e podem não ser tópico de discussão. Numa workshop cada decisão está ser tópico de discussão. Numa workshop cada decisão está associada a uma regra. Existe um processo de decisão e a tomada associada a uma regra. Existe um processo de decisão e a tomada de decisão pode estar associada a uma ou mais pessoas (mas não de decisão pode estar associada a uma ou mais pessoas (mas não ao facilitador); ao facilitador);

• As reuniões prendem-se com troca de informação. Já ás workshops As reuniões prendem-se com troca de informação. Já ás workshops prendem-se com a descoberta e criação da informação; prendem-se com a descoberta e criação da informação;

Note-se que uma workshop, Note-se que uma workshop, apesar de se assemelhar a uma apesar de se assemelhar a uma reunião, difere em alguns pontos:reunião, difere em alguns pontos:

• Numa reunião existe pouca interacção entre os presentes. Nas Numa reunião existe pouca interacção entre os presentes. Nas workshops a participação é intensa e variada e os participantes workshops a participação é intensa e variada e os participantes realizam actividades individualmente, como membros de sub-realizam actividades individualmente, como membros de sub-grupos, ou colectivamente; grupos, ou colectivamente;

• Reuniões não permitem quase nenhuns momentos de Reuniões não permitem quase nenhuns momentos de descontracção. Já as workshops encorajam a descontracção como descontracção. Já as workshops encorajam a descontracção como forma de promoção da inovação e do trabalho de equipa. forma de promoção da inovação e do trabalho de equipa.

• As reuniões normalmente não envolvem a prodção de As reuniões normalmente não envolvem a prodção de documentação. Já nas workshops os participantes criam e documentação. Já nas workshops os participantes criam e verificam documentos como p.ex diagramas de casos de uso; verificam documentos como p.ex diagramas de casos de uso;

• As reuniões usam raramente meios visuais. Nas workshops sao As reuniões usam raramente meios visuais. Nas workshops sao fortemente utilizados meios visuais como posters, post-it, cartões fortemente utilizados meios visuais como posters, post-it, cartões diagramas. diagramas.

Planear uma workshopPlanear uma workshop

• Planear o horário da sessão: em que altura do dia se Planear o horário da sessão: em que altura do dia se realizará, quanto tempo durará, ... realizará, quanto tempo durará, ...

• Planear o local: a sessão deve decorrer num local Planear o local: a sessão deve decorrer num local arejado, com boa luz; as cadeiras devem estar dispostas arejado, com boa luz; as cadeiras devem estar dispostas de forma que todos os participantes se vejam de forma que todos os participantes se vejam

• Planear as regras básicas: Planear as regras básicas: – Todos os membros devem participar o máximo possível Todos os membros devem participar o máximo possível – Como a sessão é só uma, é importante que seja estabelecido Como a sessão é só uma, é importante que seja estabelecido

um conjunto de regras básicas que regulem a participação. um conjunto de regras básicas que regulem a participação. Ex: nunca se deve desviar do objectivo da sessão, nunca se Ex: nunca se deve desviar do objectivo da sessão, nunca se deve desviar da questão base do momento, não se deve deve desviar da questão base do momento, não se deve ultrapassar a vez dos outros, ... ultrapassar a vez dos outros, ...

Planear uma workshopPlanear uma workshop

• Planear a agenda a seguir: Planear a agenda a seguir: – Dar as boas-vindas Dar as boas-vindas – Rever a agenda Rever a agenda – Rever o objectivo da sessão Rever o objectivo da sessão – Rever as regras básicas de participação Rever as regras básicas de participação – Fazer uma introdução ao projecto Fazer uma introdução ao projecto – Lançar as questões e conduzir as respostas Lançar as questões e conduzir as respostas – Terminar agradecendo a participação Terminar agradecendo a participação

• Escolher os participantes (ver quadro abaixo) Escolher os participantes (ver quadro abaixo)

• Planear a gravação da sessão Planear a gravação da sessão – Deve estar presente um ajudante (co-facilitador) que vá tirando Deve estar presente um ajudante (co-facilitador) que vá tirando

notas ao longo da workshop notas ao longo da workshop – Para além disso, pode ser útil gravar a sessão em suporte áudio ou Para além disso, pode ser útil gravar a sessão em suporte áudio ou

video video

Conduzir uma workshopConduzir uma workshop

• De seguida será descrita uma De seguida será descrita uma possível abordagem ao modo como o possível abordagem ao modo como o mediador deverá conduzir a sessão:mediador deverá conduzir a sessão:


• FormingForming - Fase de orientação do grupo e introdução dos objectivos - Fase de orientação do grupo e introdução dos objectivos da sessão. Nesta fase o facilitador deve: da sessão. Nesta fase o facilitador deve: – Apresentar-se e apresentar o co-facilitador Apresentar-se e apresentar o co-facilitador – Agradecer a disponibilidade das pessoas Agradecer a disponibilidade das pessoas – Explicar os modos de gravação da sessão (só papel, gravador audio ou Explicar os modos de gravação da sessão (só papel, gravador audio ou

video) video) – Apresentar/relembrar a agenda Apresentar/relembrar a agenda

• StormingStorming - divulgação de todas as ideias que os intervenientes - divulgação de todas as ideias que os intervenientes possam ter, mesmo que estas sejam incompatíveis com outras áreas possam ter, mesmo que estas sejam incompatíveis com outras áreas de negócio ou mesmo com o sistema que foi inicialmente idealizado. de negócio ou mesmo com o sistema que foi inicialmente idealizado. O facilitador deve: O facilitador deve: – Introduzir todas as questões antes de se iniciar o debate. Dar algum Introduzir todas as questões antes de se iniciar o debate. Dar algum

tempo aos participantes para pensarem sobre cada uma (e registarem as tempo aos participantes para pensarem sobre cada uma (e registarem as suas respostas). De seguida conduzir a discussão à volta das respostas a suas respostas). De seguida conduzir a discussão à volta das respostas a cada questão, sendo tratada uma de cada vez cada questão, sendo tratada uma de cada vez

– Quando terminada uma questão, o facilitador deve fazer um breve Quando terminada uma questão, o facilitador deve fazer um breve resumo sobre as respostas dadas e a conclusão a que se chegou (pode resumo sobre as respostas dadas e a conclusão a que se chegou (pode ser o co-facilitador a fazer isto) ser o co-facilitador a fazer isto)


• NormingNorming - Promover a harmonia, a compreensão e o apoio das - Promover a harmonia, a compreensão e o apoio das ideias uns dos outros, aumentando a coesão dos grupos ideias uns dos outros, aumentando a coesão dos grupos intervenientes. O facilitador deve: intervenientes. O facilitador deve: – Garantir que as regras básicas de participação são respeitadas, dando Garantir que as regras básicas de participação são respeitadas, dando

voz a todos os participantes voz a todos os participantes – O facilitador não deve participar no debate/discussão (nunca justificar O facilitador não deve participar no debate/discussão (nunca justificar

a sua posição)... O seu papel fundamental é ouvir e coleccionar a sua posição)... O seu papel fundamental é ouvir e coleccionar informação informação

– Assegurar a participação uniforme - se 1/2 pessoas estão a liderar a Assegurar a participação uniforme - se 1/2 pessoas estão a liderar a discussão, o facilitador deve promover e incentivar os outros discussão, o facilitador deve promover e incentivar os outros intervenientes, chamando-os a responder. Uma boa abordagem é usar intervenientes, chamando-os a responder. Uma boa abordagem é usar uma mesa redonda, seguindo uma direcção, dando a cada participante uma mesa redonda, seguindo uma direcção, dando a cada participante 1 min para transmitir a sua opinião. 1 min para transmitir a sua opinião.

• PerformingPerforming - Nesta fase já deverá estar interiorizado no - Nesta fase já deverá estar interiorizado no pensamento dos stakeholders uma actuação como equipa. Aqui já pensamento dos stakeholders uma actuação como equipa. Aqui já deverão emergir soluções. Os requisitos já deverão ser tratados deverão emergir soluções. Os requisitos já deverão ser tratados com mais detalhe e ser prioritizados. com mais detalhe e ser prioritizados.


• AdjourningAdjourning - Deverá ser feita uma retrospectiva - Deverá ser feita uma retrospectiva do projecto, e das soluções encontradas. Esta fase do projecto, e das soluções encontradas. Esta fase não deverá ser descurada, já que é essencial para não deverá ser descurada, já que é essencial para que os intervenientes percebam que o papel que que os intervenientes percebam que o papel que desempenharam foi tomado em conta e é essencial desempenharam foi tomado em conta e é essencial para este e futuros projectos. O facilitador deve: para este e futuros projectos. O facilitador deve: – Notificar os participantes da breve recepção de uma cópia Notificar os participantes da breve recepção de uma cópia

do relatório resultante da sessão (contendo as principais do relatório resultante da sessão (contendo as principais propostas e conclusões) propostas e conclusões)

– Agradecer aos participantes a sua presença e participação Agradecer aos participantes a sua presença e participação – Terminar a sessão Terminar a sessão

Como tirar mais proveito Como tirar mais proveito dos Workshops?dos Workshops? • As tomadas de decisão devem seguir processos bem As tomadas de decisão devem seguir processos bem

definidos e devem resultar de um processo de definidos e devem resultar de um processo de negociação, mediado pelo facilitador.negociação, mediado pelo facilitador.

• Uma técnica que é também útil em workshops é o Uma técnica que é também útil em workshops é o uso de brainstorming como forma de gerar um uso de brainstorming como forma de gerar um elevado número de ideias numa pequena quantidade elevado número de ideias numa pequena quantidade de tempo. de tempo.

• Como resultado dos workshops deve ser produzida Como resultado dos workshops deve ser produzida documentação que reflicta os requisitos e decisões documentação que reflicta os requisitos e decisões tomadas sobre o sistema a implementar. tomadas sobre o sistema a implementar.

BrainstormingBrainstorming

•brainstorming é uma técnica para a brainstorming é uma técnica para a geração de novas ideias por um conjuto de geração de novas ideias por um conjuto de pessoaspessoas

– encoraja a participação de todosencoraja a participação de todos– permite o aproveitamento e refinamento de permite o aproveitamento e refinamento de

outras ideiasoutras ideias– pode ser bastante produtiva (nº de ideias/hora)pode ser bastante produtiva (nº de ideias/hora)– o resultado pode ser um conjunto de soluçõeso resultado pode ser um conjunto de soluções– encoraja o pensamento livre... (maluquices...)encoraja o pensamento livre... (maluquices...)

Brainstorming:Brainstorming: reduzir reduzir ideiasideias•"podar" ideias"podar" ideias

•agrupar ideiasagrupar ideias

•definir as características de cada ideiadefinir as características de cada ideia

•estabelecer prioridadesestabelecer prioridades

BrainstormingBrainstorming

• regras do brainstormingregras do brainstorming

– não permitir críticas ou debatenão permitir críticas ou debate– deixar a imaginação voar...deixar a imaginação voar...– gerar tantas ideias quanto for possívelgerar tantas ideias quanto for possível– mutar e combinar ideiasmutar e combinar ideias– Atraso do julgamentoAtraso do julgamento – Criatividade em quantidade e qualidadeCriatividade em quantidade e qualidade

Há 3 principais partes no Há 3 principais partes no brainstorming:brainstorming:

• Encontrar os factos, Encontrar os factos,

• Geração da ideia, Geração da ideia,

• Encontrar a solução.Encontrar a solução.


• Da busca dos factos na resolução de Da busca dos factos na resolução de um problema existem duas sub partes:um problema existem duas sub partes:

• Definição do problema, Definição do problema,

• Preparação.Preparação.


• Inicialmente, define-se o problema. Poderá ser necessário Inicialmente, define-se o problema. Poderá ser necessário subdividir o problema em várias partes. A técnica de subdividir o problema em várias partes. A técnica de Brainstorming funciona para problemas que têm muitas Brainstorming funciona para problemas que têm muitas soluções possíveis tal como a geração de ideias para o seu soluções possíveis tal como a geração de ideias para o seu desenho.desenho.

• Depois é necessário colher toda a informação que pode Depois é necessário colher toda a informação que pode relacionar-se com o problema.relacionar-se com o problema.

• Geração de idéias por brainstorming.Geração de idéias por brainstorming.

• Busca da solução. Avaliar e seleccionar as melhores idéias.Busca da solução. Avaliar e seleccionar as melhores idéias.

Brainstorming na Brainstorming na educaçãoeducação • A técnica de brainstorming não é uma actividade A técnica de brainstorming não é uma actividade

exclusiva de um ambiente empresarial: pelo exclusiva de um ambiente empresarial: pelo contrário, na escola esta, pode ser uma técnica muito contrário, na escola esta, pode ser uma técnica muito importante na educação dos estudantes. Este grande importante na educação dos estudantes. Este grande ou pequeno grupo de actividade encoraja os ou pequeno grupo de actividade encoraja os estudantes a manterem-se focados num tópico e estudantes a manterem-se focados num tópico e contribuir para uma fluidez de ideias em liberdade.contribuir para uma fluidez de ideias em liberdade.

• O professor pode começar por propôr uma questão O professor pode começar por propôr uma questão ou problema, ou introduzindo um tópico. Os ou problema, ou introduzindo um tópico. Os estudantes, depois expressam e divulgam as estudantes, depois expressam e divulgam as possíevis respostas e soluções, palavras, expressões possíevis respostas e soluções, palavras, expressões ou ideias relevantes.ou ideias relevantes.

CENÁRIOSCENÁRIOS

cenárioscenários

•abordagem para colocar os abordagem para colocar os interessados num sistema perante uma interessados num sistema perante uma situação realista em que simulam ou situação realista em que simulam ou apenas antevêem a sua interacção com apenas antevêem a sua interacção com o sistemao sistema

– materializam-se em materializam-se em históriashistórias que que explicam como é que o sistema poderá ser explicam como é que o sistema poderá ser usadousado

CenáriosCenários

• uma forma de levar as pessoas a imaginar uma forma de levar as pessoas a imaginar o comportamento de um sistema é o uso o comportamento de um sistema é o uso de cenários. Através de exemplos práticos de cenários. Através de exemplos práticos descritivos do comportamento de um descritivos do comportamento de um sistema, os seus utilizadores podem sistema, os seus utilizadores podem comentar acerca do seu comportamento e comentar acerca do seu comportamento e da interacção que esperam ter com ele. da interacção que esperam ter com ele.

• Trata-se de uma abordagem informal, Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários sistema. De um modo geral, os cenários devem incluir os seguintes elementos: devem incluir os seguintes elementos:

CenáriosCenários

• Estado do sistema no início do Estado do sistema no início do cenário. cenário.

• Sequência de eventos esperada (na Sequência de eventos esperada (na ausência de erros) no cenário. ausência de erros) no cenário.

• Listagem de erros que podem Listagem de erros que podem ocorrer no decorrer dos eventos do ocorrer no decorrer dos eventos do cenário e de como estes erros serão cenário e de como estes erros serão tratados.tratados.

CenáriosCenários

• Listagem de erros que podem Listagem de erros que podem ocorrer no decorrer dos eventos do ocorrer no decorrer dos eventos do cenário e de como estes erros serão cenário e de como estes erros serão tratados. tratados.

• Outras actividades que podem estar Outras actividades que podem estar a ser executadas ao mesmo tempo a ser executadas ao mesmo tempo que as deste cenário. que as deste cenário.

• Estado do sistema depois de o Estado do sistema depois de o cenário terminar. cenário terminar.

CenáriosCenários: : conteúdoconteúdodescrição do sistema antes de se entrar no cenário

fluxo normal de eventos

excepções ao fluxo normal de

eventos

info

rmaçã

o s

obre

ou

tras

act

ivid

ades

que

oco

rrem

ao m

esm

o

tem

po

descrição do estado do sistema depois de completado o cenário

CenáriosCenários: : definiçãodefinição

•mais definiçõesmais definições– uma história ou exemplo de eventos uma história ou exemplo de eventos

retirados da experiência do mundo real; retirados da experiência do mundo real; incluem detalhes do contexto do sistema incluem detalhes do contexto do sistema (cenas)(cenas)

– um caminho ou instância de um modelo um caminho ou instância de um modelo (normalmente de casos de utilização)(normalmente de casos de utilização)

– a visão futura de um sistema a ser a visão futura de um sistema a ser desenhado, com sequências de desenhado, com sequências de comportamento e descrições contextuaiscomportamento e descrições contextuais

Sutcliffe, 2002

CenáriosCenários: : objectivosobjectivos

•identificar e clarificar requisitosidentificar e clarificar requisitos– adicionar detalhe a requisitos mais geraisadicionar detalhe a requisitos mais gerais– compreender a relação entre requisitoscompreender a relação entre requisitos

•validar requisitosvalidar requisitos– compreender um requisito no seu contexto compreender um requisito no seu contexto

de utilizaçãode utilização– verificar se a sua relação com outros verificar se a sua relação com outros

requisitos faz sentidorequisitos faz sentido

Principais vantagens do uso de Principais vantagens do uso de cenários em Engenharia de cenários em Engenharia de

RequisitosRequisitos • Tem em conta o ponto de vista do utilizadorTem em conta o ponto de vista do utilizador

• Especificações parciaisEspecificações parciais

• Fácil de compreenderFácil de compreender

• Ciclos de feedback curtosCiclos de feedback curtos

• Servir de base para os testes do sistemaServir de base para os testes do sistema

CENÁRIOS: CENÁRIOS: conclusãoconclusão

• Engenharia de requisitos baseada Engenharia de requisitos baseada em cenários é definitavamente um em cenários é definitavamente um passo na direcção certa.passo na direcção certa.

• Em particular, cenários são uma Em particular, cenários são uma chave que permite um novo estilo de chave que permite um novo estilo de engenharia de requisitos engenharia de requisitos evolucionário e incremental.evolucionário e incremental.

CENÁRIOS: CENÁRIOS: conclusãoconclusão

• Os cenários focam-se nos utilizadores, em Os cenários focam-se nos utilizadores, em descrições concretas e instâncias específicas. descrições concretas e instâncias específicas.

• O desenho de sistemas baseado em cenários O desenho de sistemas baseado em cenários atribui um grande ênfase aos utilizadores; atribui um grande ênfase aos utilizadores; articula qual o seu papel, o que fazem, como articula qual o seu papel, o que fazem, como fazem, e sobre que circunstâncias o fazem. fazem, e sobre que circunstâncias o fazem.

• Um cenário é uma descrição concreta do Um cenário é uma descrição concreta do trabalho e actividades, descrevendo assim trabalho e actividades, descrevendo assim uma instância específica e um caso de uso.uma instância específica e um caso de uso.

CenáriosCenários versus versus casos de casos de usouso• Existem diferentes opiniões sobre a relação Existem diferentes opiniões sobre a relação

existente entre casos de uso e cenários:existente entre casos de uso e cenários:– Há quem os considere sinónimosHá quem os considere sinónimos– Há quem considere que um cenário corresponde Há quem considere que um cenário corresponde

a um conjunto de casos de uso (fluxo normal de a um conjunto de casos de uso (fluxo normal de eventos, e cada fluxo excepcional seriam casos eventos, e cada fluxo excepcional seriam casos de uso separados)de uso separados)

– Há quem considere que um caso de uso Há quem considere que um caso de uso corresponde a um conjunto de cenárioscorresponde a um conjunto de cenários• Em UML, um caso de uso admite variantes, podendo-se Em UML, um caso de uso admite variantes, podendo-se

considerar cada variante como um cenárioconsiderar cada variante como um cenário• Cada cenário pode ser representado por um diagrama Cada cenário pode ser representado por um diagrama

de interacção (normalmente um diagrama de de interacção (normalmente um diagrama de sequência)sequência)

cenários: exemplo – reservar livro cenários: exemplo – reservar livro através do através do sitesite da biblioteca da biblioteca

• Entrar no sistema (Entrar no sistema (log onlog on))

• Procurar o livro pretendido por autor, título Procurar o livro pretendido por autor, título ou ISBNou ISBN

• Seleccionar um dos exemplares disponíveisSeleccionar um dos exemplares disponíveis

• Dar ordem para reservar esse exemplarDar ordem para reservar esse exemplar

• Seleccionar o modo de entrega: Seleccionar o modo de entrega: levantamento na biblioteca, ou envio por levantamento na biblioteca, ou envio por funcionáriofuncionário

• Sair do sistema (Sair do sistema (logoutlogout))

PROTOTIPAGEMPROTOTIPAGEM

PrototipagemPrototipagem

•um protótipo é uma versão inicial de um protótipo é uma versão inicial de um sistema usado para apoiar um sistema usado para apoiar essencialmente as fases de essencialmente as fases de identificação, análise e validação de identificação, análise e validação de requisitosrequisitos

PrototipagemPrototipagem

•característicascaracterísticas– desenvolvimento rápidodesenvolvimento rápido– funcionalidades limitadasfuncionalidades limitadas– requisitos não funcionais pouco requisitos não funcionais pouco

consideradosconsiderados– várias tecnologiasvárias tecnologias– pode ir desde maquetas a protótipos pode ir desde maquetas a protótipos

evolutivosevolutivos

Prototipagem: Prototipagem: custoscustos

•a decisão de usar a prototipagem a decisão de usar a prototipagem deve ser tomada com recurso a uma deve ser tomada com recurso a uma análise custo-benefícioanálise custo-benefício

•custos envolvidos na prototipagemcustos envolvidos na prototipagem– formação, desenvolvimento, prazos mais formação, desenvolvimento, prazos mais

alargados, protótipos incompletosalargados, protótipos incompletos

Prototipagem:Prototipagem: benefíciosbenefícios

•benefício principalbenefício principal– os clientes e utilizadores finais têm os clientes e utilizadores finais têm

contacto com um sistema realista cedo o contacto com um sistema realista cedo o que lhes permite compreender melhor os que lhes permite compreender melhor os requisitos que pretendem identificar e requisitos que pretendem identificar e analisaranalisar

•outros benefíciosoutros benefícios– ajuda a estabelecer a viabilidade e utilidade ajuda a estabelecer a viabilidade e utilidade

do sistemado sistema– é a única forma efectiva de desenvolver IPCé a única forma efectiva de desenvolver IPC– pode ser usado na validaçãopode ser usado na validação– o estudo cuidadoso dos requisitos ajuda a o estudo cuidadoso dos requisitos ajuda a

revelar inconsistências e lacunasrevelar inconsistências e lacunas

Prototipagem:Prototipagem: tipostiposExistem 3 tipos de protótipos (Sommerville, Existem 3 tipos de protótipos (Sommerville,

Sawyer, 1997):Sawyer, 1997):

– Protótipo em papel:Protótipo em papel: é desenvolvido um conjunto é desenvolvido um conjunto de interfaces associadas a cenários de utilização que de interfaces associadas a cenários de utilização que são apresentados aos utilizadores. Este tipo de são apresentados aos utilizadores. Este tipo de prototipagem é barata e eficiente (Rogers, Sharp, prototipagem é barata e eficiente (Rogers, Sharp, Preece, 2002)(Kotonya, Sommerville 1998). È mais Preece, 2002)(Kotonya, Sommerville 1998). È mais indicada quando o sistema a desenvolver é indicada quando o sistema a desenvolver é software. Não é necessário desenvolver software software. Não é necessário desenvolver software executável. Os analistas e utilizadores percorrem executável. Os analistas e utilizadores percorrem estes cenários, simulando a utilização do sistema, estes cenários, simulando a utilização do sistema, sendo analisado as reacções dos utilizadores, a sendo analisado as reacções dos utilizadores, a informação requerida e a forma de interacção com o informação requerida e a forma de interacção com o sistema. Este método é muito eficiente para sistema. Este método é muito eficiente para sistemas interactivos. Este tipo de protótipo é de sistemas interactivos. Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, 2002). baixa fidelidade (Rogers, Sharp, Preece, 2002).

Prototipagem:Prototipagem: tipostipos– Protótipo “wizard of Oz”:Protótipo “wizard of Oz”: uma pessoa uma pessoa

simula as respostas dos sistemas em simula as respostas dos sistemas em resposta as acções dos utilizadores. Este resposta as acções dos utilizadores. Este tipo de prototipagem é relativamente tipo de prototipagem é relativamente barata visto apenas a interface do sistema barata visto apenas a interface do sistema ter de ser desenvolvida (Kotonya, ter de ser desenvolvida (Kotonya, Sommerville 1998). Os utilizadores Sommerville 1998). Os utilizadores interagem com o que parece ser o sistema interagem com o que parece ser o sistema em que as suas acções são analisadas por em que as suas acções são analisadas por um pessoa que simula a resposta do um pessoa que simula a resposta do sistema. É particularmente útil quando o sistema. É particularmente útil quando o sistema a desenvolver tem por base numa sistema a desenvolver tem por base numa interface existente. Este tipo de protótipo é interface existente. Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, de baixa fidelidade (Rogers, Sharp, Preece, 2002). 2002).

Prototipagem:Prototipagem: tipostipos

– Protótipo automático:Protótipo automático: é utilizado linguagens 4GL é utilizado linguagens 4GL ou outras linguagens que permitem um rápido ou outras linguagens que permitem um rápido desenvolvimento de protótipos executáveis. Este desenvolvimento de protótipos executáveis. Este tipo de prototipagem é a mais cara (Kotonya, tipo de prototipagem é a mais cara (Kotonya, Sommerville 1998). Envolve o desenvolvimento de Sommerville 1998). Envolve o desenvolvimento de software, recorrendo a linguagens de programação software, recorrendo a linguagens de programação de alto nível, que simule as funcionalidades do de alto nível, que simule as funcionalidades do sistema. O problema principal do desenvolvimento sistema. O problema principal do desenvolvimento de protótipos executáveis é de os Stakeholders não de protótipos executáveis é de os Stakeholders não simularem a real utilização do sistema final devido simularem a real utilização do sistema final devido ao facto de muitos dos requisitos não funcionais do ao facto de muitos dos requisitos não funcionais do sistema não estarem provavelmente implementados sistema não estarem provavelmente implementados em conjunção com falta de treino. Um outro em conjunção com falta de treino. Um outro problema poderá surgir se o desenvolvimento do problema poderá surgir se o desenvolvimento do sistema estiver atrasado. Nesta situação pode sistema estiver atrasado. Nesta situação pode ocorrer a tentação de prosseguir o desenvolvimento ocorrer a tentação de prosseguir o desenvolvimento do protótipo com todas as nefastas consequências do protótipo com todas as nefastas consequências anteriormente referidas. anteriormente referidas.

Prototipagem:Prototipagem: tipostipos

•prototipagem evolutivaprototipagem evolutiva– o objectivo é proporcionar um sistema o objectivo é proporcionar um sistema

"produtivo" o mais rápido possível ao "produtivo" o mais rápido possível ao clientecliente

– os requisitos objecto dos protótipos iniciais os requisitos objecto dos protótipos iniciais deverão ser aqueles mais facilmente deverão ser aqueles mais facilmente compreendidos e que podem dar compreendidos e que podem dar rapidamente um valor acrescentado útil ao rapidamente um valor acrescentado útil ao utilizadorutilizador

ESTUDOS ESTUDOS ETNOGRÁFICOSETNOGRÁFICOS

EtnografiaEtnografia

• Técnica onde o sociólogo gasta um Técnica onde o sociólogo gasta um tempo considerável no ambiente de tempo considerável no ambiente de trabalho a observar e a anotar como os trabalho a observar e a anotar como os participantes envolvidos trabalhamparticipantes envolvidos trabalham

• Interacções implícitas são reveladas. As Interacções implícitas são reveladas. As pessoas não têm que explicar o seu pessoas não têm que explicar o seu trabalhotrabalho

EstudosEstudos EtnográficosEtnográficos::

• Este tipo de estudos são uma análise da Este tipo de estudos são uma análise da componente social das tarefas componente social das tarefas desempenhadas numa dada organização. desempenhadas numa dada organização.

• Quando um dado conjunto de tarefas se Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em esperar que esta sinta dificuldade em articular todos os passos que segue ou articular todos os passos que segue ou todas as pessoas com as quais interage todas as pessoas com as quais interage para as levar a cabo.para as levar a cabo.

http://pt.wikipedia.org/wiki/Estudo_etnogr%C3%A1fico



EstudosEstudos EtnográficosEtnográficos::

• Através de uma observação directa das Através de uma observação directa das actividades realizadas durante um período de actividades realizadas durante um período de trabalho de um funcionário é possível encontrar trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando requisitos que não seriam observáveis usando técnicas convencionais.técnicas convencionais.

• Esta observação pode ser acompanhada de Esta observação pode ser acompanhada de registos áudio/vídeo, porém não convém usá-los registos áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os em demasia visto que o tempo necessário para os processar pode ser demasiado. processar pode ser demasiado.

• Nesta técnica assume-se que o Nesta técnica assume-se que o stakeholderstakeholder observado desempenha as suas funções observado desempenha as suas funções "correctamente", pelo que convém ter algum "correctamente", pelo que convém ter algum cuidado na escolha do(s) cuidado na escolha do(s) stakeholder(s)stakeholder(s) a a observar.observar.




ObservaçãoObservação e Análisee Análise SocialSocial•estudos etnográficos e identificação estudos etnográficos e identificação

de requisitosde requisitos– há requisitos que não se conseguem há requisitos que não se conseguem

identificar através das técnicas identificar através das técnicas convencionaisconvencionais

– os estudos etnográficos ajudam a fazer os estudos etnográficos ajudam a fazer emergir requisitos derivados de formas emergir requisitos derivados de formas rotineiras e tácitas de trabalharrotineiras e tácitas de trabalhar

Observação e Análise Observação e Análise SocialSocial•grande parte dos sistemas que grande parte dos sistemas que

desenvolvemos visam apoiar o desenvolvemos visam apoiar o trabalhotrabalho das pessoas das pessoas

•o trabalho é uma o trabalho é uma actividade socialactividade social que envolve grupos de pessoas que que envolve grupos de pessoas que cooperam para levar a cabo cooperam para levar a cabo diferentes tarefasdiferentes tarefas Kotonya, 1998

observação e análise socialobservação e análise social

•as pessoas encontram frequentemente as pessoas encontram frequentemente dificuldade em tornar dificuldade em tornar explícitaexplícita a forma como a forma como realizam tarefas e como trabalham em conjunto realizam tarefas e como trabalham em conjunto com outroscom outros

•quando as tarefas se tornam quando as tarefas se tornam rotinarotina e as e as pessoas tendem a não pensar nelas pessoas tendem a não pensar nelas conscientemente, torna-se difícil que articulem conscientemente, torna-se difícil que articulem como é que o trabalho é realizadocomo é que o trabalho é realizado

•as pessoas usam artefactos (ferramentas, as pessoas usam artefactos (ferramentas, documentos, etc.) de uma forma documentos, etc.) de uma forma intuitivaintuitiva

EstudosEstudos EtnográficosEtnográficos

•algumas directrizesalgumas directrizes– assumir que as pessoas que se estão a estudar são boas a assumir que as pessoas que se estão a estudar são boas a

realizar o seu trabalhorealizar o seu trabalho– estabelecer relações de confiança com as pessoas envolvidas estabelecer relações de confiança com as pessoas envolvidas

no estudo; os analistas devem ser externos à organizaçãono estudo; os analistas devem ser externos à organização– escrever notas detalhadas e regulares das práticas de escrever notas detalhadas e regulares das práticas de

trabalho estudadastrabalho estudadas– realizar entrevistas abertasrealizar entrevistas abertas– não recorrer demasiado às gravações vídeo e áudio, porque não recorrer demasiado às gravações vídeo e áudio, porque

são difíceis de tratar em tempo útilsão difíceis de tratar em tempo útil– realizar sessões de crítica por parte de elementos externos ao realizar sessões de crítica por parte de elementos externos ao

projectoprojecto

observação observação e análise sociale análise social

•estudos etnográficosestudos etnográficos– observação detalhada das práticas sociais de observação detalhada das práticas sociais de

uma sociedadeuma sociedade– uma compreensao total destas práticas só é uma compreensao total destas práticas só é

possível pela observação do detalhe e a partir possível pela observação do detalhe e a partir do interior da comunidadedo interior da comunidade

– um grupo de funcionários numa biblioteca, num um grupo de funcionários numa biblioteca, num banco, num laboratório têm características dos banco, num laboratório têm características dos elementos de uma sociedadeelementos de uma sociedade

Estudos EtnográficosEstudos Etnográficos

protótipo

prototipagem

experiências dos

utilizadores

etnografia focada

reuniões de

crítica

análise etnográfic

a

ANÁLISE ANÁLISE EE

NEGOCIAÇÃONEGOCIAÇÃO

O processo de engenharia de requisitosO processo de engenharia de requisitosmodelo de actividades de alto nívelmodelo de actividades de alto nível



documentação de requisitos


documento de requisitos


Processo de engenharia de Processo de engenharia de requisitos: modelo em espiralrequisitos: modelo em espiral


Análise e Negociação de RequisitosAnálise e Negociação de Requisitos

objectivosobjectivos

•análise e negociação de requisitos análise e negociação de requisitos – actividades que visam descobrir actividades que visam descobrir problemasproblemas com com

os requisitos e chegar a os requisitos e chegar a acordosacordos para a sua para a sua resolução de forma a satisfazer todos os resolução de forma a satisfazer todos os interessados no sistemainteressados no sistema

– na realidade, na fase de na realidade, na fase de identificaçãoidentificação de de requisitos já se desenrolam actividades de requisitos já se desenrolam actividades de análise e negociaçãoanálise e negociação

– análise e negociação de requisitos são análise e negociação de requisitos são actividades que incidem sobre conjuntos actividades que incidem sobre conjuntos incompletosincompletos de requisitos de requisitos

Análise e Negociação de RequisitosAnálise e Negociação de Requisitos

característicascaracterísticas•a análise e negociação de requisitos é a análise e negociação de requisitos é

normalmente um processo complexonormalmente um processo complexo– requer pessoas com requer pessoas com competênciascompetências

específicasespecíficas– baseia-se muito no baseia-se muito no julgamentojulgamento e e

experiênciaexperiência dos participantes dos participantes– não é possívelnão é possível transformar este processo transformar este processo

numa abordagem numa abordagem estruturadaestruturada e e sistemáticasistemática

– é custoso e morosoé custoso e moroso

Análise de RequisitosAnálise de Requisitos

necessidade, consistência e necessidade, consistência e completudecompletude

•no conjunto de requisitos no conjunto de requisitos identificados podeidentificados pode– haver requisitos que se sobrepõemhaver requisitos que se sobrepõem– haver requisitos que estão em conflito haver requisitos que estão em conflito

ou que são contraditóriosou que são contraditórios– faltar requisitos...faltar requisitos...


técnicas:técnicas: check-listscheck-lists

•listas de questões que um analista listas de questões que um analista usa para avaliar os requisitosusa para avaliar os requisitos– são um "lembrete" do que é importante são um "lembrete" do que é importante

considerar na análiseconsiderar na análise– não devem ter mais do que 10 itemsnão devem ter mais do que 10 items– evoluem com a experiência ganha no evoluem com a experiência ganha no

processo de análiseprocesso de análise


técnicas:técnicas: check-listscheck-lists

•exemploexemplo– o requisito inclui aspectos de desenho ou implementaçãoo requisito inclui aspectos de desenho ou implementação– o requisito poderia ser decomposto em sub-requisitos?o requisito poderia ser decomposto em sub-requisitos?– o requisito é mesmo necessário?...o requisito é mesmo necessário?...– o requisito implica a utilização de software não standard?o requisito implica a utilização de software não standard?– o requisito está de acordo com os objectivos do negócio?o requisito está de acordo com os objectivos do negócio?– o requisito é ambíguo?o requisito é ambíguo?– o requisito é realista?o requisito é realista?– o requisito é "testável"?o requisito é "testável"?

Sutcliffe, 2002


análise quanto ao âmbitoanálise quanto ao âmbito

definir asfronteiras do

sistema

analisar e decidir

se o requisito está

dentro ou fora

diagramas de contextodiagramas de casos de uso


análise de prioridadesanálise de prioridades

•definir prioridades na análise e definir prioridades na análise e implementação dos requisitosimplementação dos requisitos

•classificaçãoclassificação– alta, média, baixa, não/sabealta, média, baixa, não/sabe– essencial, útil, pouco interesse, a ser essencial, útil, pouco interesse, a ser

decididodecidido


organização dos requisitosorganização dos requisitos

•hierarquizaçãohierarquização– relações de composição ou "pai-> filhos" ou relações de composição ou "pai-> filhos" ou

"requisito-> sub-requisito""requisito-> sub-requisito"– os requisitos são definidos a vários níveis de os requisitos são definidos a vários níveis de

abstracçãoabstracção

•a organização em hierarquias é a organização em hierarquias é adequada a uma abordagem iterativa adequada a uma abordagem iterativa (espiral) ao processo de engenharia de (espiral) ao processo de engenharia de requisitosrequisitos


hierarquia de requisitos e casos de usohierarquia de requisitos e casos de uso

1.1. marcação de consulta marcação de consulta (caso de uso)(caso de uso)– 1.1 a consulta pode ser marcada pelo médico 1.1 a consulta pode ser marcada pelo médico

ou pela assistenteou pela assistente– 1.2 um médico pode marcar uma consulta para 1.2 um médico pode marcar uma consulta para

outro médicooutro médico– 1.3 não se podem marcar duas consultas para 1.3 não se podem marcar duas consultas para

a mesma data, hora e médico a mesma data, hora e médico (restrição)(restrição)– 1.4 o sistema deve alertar o utilizador no caso 1.4 o sistema deve alertar o utilizador no caso

do doente ter outras consultas marcadas do doente ter outras consultas marcadas (alerta)(alerta)

– 1.5 o sistema deve ajudar o utilizador a 1.5 o sistema deve ajudar o utilizador a encontrar vagas (encontrar vagas (ajudaajuda))

– (...)(...)

Negociação de RequisitosNegociação de Requisitos

aspectos geraisaspectos gerais

•negociação para quê?negociação para quê?– chegar a acordo em relação a opções chegar a acordo em relação a opções

mais adequadas aos interesses dos mais adequadas aos interesses dos stakeholdersstakeholders

– definir as prioridades a dar aos definir as prioridades a dar aos requisitos para novas iterações de requisitos para novas iterações de identificação e análise e para o identificação e análise e para o desenvolvimentodesenvolvimento

– chegar a acordo em relação a chegar a acordo em relação a compromissos entre requisitos que compromissos entre requisitos que entram em conflitoentram em conflito


tarefas na negociaçãotarefas na negociação

estruturar opções

e escolhas

estabelecer critérios de avaliação

explicar opções disponíveis e a escolha a fazer

chegar a umacordo

diagnosticar causas dedesacordo


intervenientes na negociaçãointervenientes na negociação

•stakeholders stakeholders primáriosprimários– os que operam o sistemaos que operam o sistema– preocupam-se com os requisitos preocupam-se com os requisitos

funcionais e questões de usabilidadefuncionais e questões de usabilidade– pretendem sistemas fáceis de usar e pretendem sistemas fáceis de usar e

aprenderaprender


intervenientes na negociaçãointervenientes na negociação

•stakeholders secundáriosstakeholders secundários– não operam o sistema mas consomem o não operam o sistema mas consomem o

que este produzque este produz– o sucesso das suas actividades depende o sucesso das suas actividades depende

da qualdade do sistemada qualdade do sistema– são tipicamente gestores que usam a são tipicamente gestores que usam a

informação do sistema para controlar, informação do sistema para controlar, monitorar e ajustar processos monitorar e ajustar processos organizacionaisorganizacionais


intervenientes na negociaçãointervenientes na negociação•stakeholders terciáriosstakeholders terciários

– gestores de topo que raramente consomem gestores de topo que raramente consomem as saídas do sistema (directamente) as saídas do sistema (directamente)

– usam-nas indirectamente para planear e usam-nas indirectamente para planear e controlar estrategicamente o negóciocontrolar estrategicamente o negócio

– interessam-se pelo papel que o sistema interessam-se pelo papel que o sistema desempenha na prossecução dos objectivos desempenha na prossecução dos objectivos estratégicos do negócio tais como aumentar a estratégicos do negócio tais como aumentar a vantagem competitiva ou melhorar o serviço vantagem competitiva ou melhorar o serviço ao clienteao cliente


gerir a negociaçãogerir a negociação

•problemas num processo de problemas num processo de negociaçãonegociação– separar os aspectos a debater das separar os aspectos a debater das

questões pessoaisquestões pessoais– falta de entendimento partilhado e de falta de entendimento partilhado e de

pontos de vista pessoaispontos de vista pessoais– atitudes interpessoaisatitudes interpessoais


técnicas para gerir a negociaçãotécnicas para gerir a negociação

•lidar com os ataques pessoaislidar com os ataques pessoais– evitá-los...evitá-los...– se acontecerem: mudar de assunto, fazer se acontecerem: mudar de assunto, fazer

um intervalo...um intervalo...– resolver o problema fora da reuniãoresolver o problema fora da reunião



•bloqueiobloqueio– reacções negativas sem justificação: reacções negativas sem justificação:

"isso não resulta", "não se pode fazer", "isso não resulta", "não se pode fazer", "dá muito trabalho“. "dá muito trabalho“.

– desafiar os participantes a justificarem a desafiar os participantes a justificarem a sua posição negativasua posição negativa



•conflitos entre gruposconflitos entre grupos– choque de pontos de vista entre gruposchoque de pontos de vista entre grupos– exemplos: qualidade vs. prazos, custos exemplos: qualidade vs. prazos, custos

vs. desenvolvimento, segurança vs. vs. desenvolvimento, segurança vs. acesso, complexidade funcional vs. acesso, complexidade funcional vs. usabilidade, etc.usabilidade, etc.

– deferir decisões, os ânimos arrefecem...deferir decisões, os ânimos arrefecem...



•outras técnicasoutras técnicas– testar e provar assunções (pressupostos)testar e provar assunções (pressupostos)– relaxar restriçõesrelaxar restrições– tentar encontrar potenciais benefícios tentar encontrar potenciais benefícios

para todos para todos – evitar tomar partidosevitar tomar partidos

ESPECIFICAÇÃOESPECIFICAÇÃOEE

DOCUMENTAÇÃODOCUMENTAÇÃO

O processo de engenharia de O processo de engenharia de requisitosrequisitosmodelo de actividades de alto nívelmodelo de actividades de alto nível







+ protótipo

+ modelo

Documento de RequisitosDocumento de Requisitos

•O que é um O que é um Documento de Documento de RequisitosRequisitos??– é uma é uma descriçãodescrição oficial dos requisitos de oficial dos requisitos de

um sistema para os um sistema para os clientes, utilizadores clientes, utilizadores e desenvolvedorese desenvolvedores

– outras designações: especificação funcional, outras designações: especificação funcional, definição de requisitos, especificação de definição de requisitos, especificação de requisitos, caderno de encargosrequisitos, caderno de encargos


•comocomo se escreve um Documento de se escreve um Documento de Requisitos?Requisitos?– depende de quem o escreve, para quem, onde, ...depende de quem o escreve, para quem, onde, ...– normalmente é escrito em normalmente é escrito em linguagem naturallinguagem natural e e

pode ser complementado com pode ser complementado com diagramas, diagramas, tabelas, fotografiastabelas, fotografias, , imagensimagens, etc., etc.

– existem existem directrizesdirectrizes e e recomendaçõesrecomendações para a para a escrita de documentos de requisitosescrita de documentos de requisitos

– o o grau de detalhegrau de detalhe depende de quem o escreve, depende de quem o escreve, da organização em que está inserido, do seu da organização em que está inserido, do seu propósito,propósito,


•Documento de RequisitosDocumento de Requisitos é usado para é usado para comunicar o que se pretende que um determinado comunicar o que se pretende que um determinado sistema faça sistema faça – destina-se aos destina-se aos clientes, utilizadores, gestores e clientes, utilizadores, gestores e

desenvolvedoresdesenvolvedores do eventual sistema do eventual sistema– especifica que especifica que serviçosserviços o sistema deve prestar, as o sistema deve prestar, as

propriedadespropriedades do sistema (fiabilidade, eficiência, etc.) do sistema (fiabilidade, eficiência, etc.) e e restriçõesrestrições impostas à operação e desenvolvimento impostas à operação e desenvolvimento do sistemado sistema

– tanto pode ser um documento muito sucinto e tanto pode ser um documento muito sucinto e genérico como um documento extenso e muito genérico como um documento extenso e muito detalhado.detalhado.


• O que é que normalmente se encontra num documento de O que é que normalmente se encontra num documento de requisitos?requisitos?

– uma uma visão geral do sistemavisão geral do sistema e dos benefícios e dos benefícios decorrentes do desenvolvimento do sistemadecorrentes do desenvolvimento do sistema

– um um glossárioglossário explicando os termos técnicos usados explicando os termos técnicos usados– uma definição dos serviços ou uma definição dos serviços ou requisitos funcionaisrequisitos funcionais do do

sistemasistema– uma definição das uma definição das propriedadespropriedades do sistema ( do sistema (requisitos requisitos

não-funcionaisnão-funcionais) tais como fiabilidade, segurança, etc.) tais como fiabilidade, segurança, etc.


• O que é que normalmente se encontra num documento de O que é que normalmente se encontra num documento de requisitos?requisitos?

– as as restriçõesrestrições à operação do sistema e ao processo de à operação do sistema e ao processo de desenvolvimentodesenvolvimento

– uma definição do uma definição do ambienteambiente em que o sistema vai operar em que o sistema vai operar e as mudanças previstas para esse ambientee as mudanças previstas para esse ambiente

– especificações detalhadasespecificações detalhadas recorrendo a recorrendo a modelosmodelos e e outras ferramentasoutras ferramentas


•Estrutura sugerida por Estrutura sugerida por IEEE/ANSI (830-IEEE/ANSI (830-1993)1993)

•1. Introdução1. Introdução– 1.1 Propósito do documento1.1 Propósito do documento– 1.2 Âmbito do sistema1.2 Âmbito do sistema– 1.3 Definições, acrónimos e abreviaturas1.3 Definições, acrónimos e abreviaturas– 1.4 Referências1.4 Referências– 1.5 Resenha do resto do documento1.5 Resenha do resto do documento


•Estrutura sugerida por Estrutura sugerida por IEEE/ANSI (830-IEEE/ANSI (830-1993)1993) (cont.) (cont.)

•2. Descrição geral2. Descrição geral– 2.1 Perspectiva do produto 2.1 Perspectiva do produto – 2.2 Funções do produto2.2 Funções do produto– 2.3 Características dos utilizadores2.3 Características dos utilizadores– 2.4 Restrições gerais2.4 Restrições gerais– 2.5 Assunções e dependências2.5 Assunções e dependências


• Estrutura sugerida por Estrutura sugerida por IEEE/ANSI (830-1993)IEEE/ANSI (830-1993) (cont.) (cont.)

•3. Requisitos específicos3. Requisitos específicos– requisitos funcionais, requisitos não funcionais, requisitos funcionais, requisitos não funcionais,

requisitos da interface com o utilizador: requisitos da interface com o utilizador:

•funcionalidade, interfaces externas, requisitos funcionalidade, interfaces externas, requisitos de desempenho, restrições de concepção, de desempenho, restrições de concepção, atributos do sistema, características de atributos do sistema, características de qualidade, ...qualidade, ...

•ApêndicesApêndices

• ÍndiceÍndice


•OrientaçõesOrientações– explicar como se usa o documentoexplicar como se usa o documento– descrever um ou mais cenários de utilizaçãodescrever um ou mais cenários de utilização– definir claramente os termos especializadosdefinir claramente os termos especializados– formatar o documento para uma boa formatar o documento para uma boa

legibilidadelegibilidade– ajudar os leitores a encontrar informaçãoajudar os leitores a encontrar informação– fazer o documento fácil de alterarfazer o documento fácil de alterar

Manual do Utilizador como Manual do Utilizador como Documento de RequisitosDocumento de Requisitos

• Steve McConnel, no seu livro "Software Steve McConnel, no seu livro "Software Project Survival Guide", defende que, na Project Survival Guide", defende que, na maioria dos situações, é mais vantajoso maioria dos situações, é mais vantajoso documentar os requisitos através de um documentar os requisitos através de um manual do utilizador e um protótipo da manual do utilizador e um protótipo da interface com o utilizador, facilmente interface com o utilizador, facilmente percebidos por todos, do que através de um percebidos por todos, do que através de um documento formal de requisitosdocumento formal de requisitos

• (documento formal deve ser apenas um (documento formal deve ser apenas um complemento)complemento)

VALIDAÇÃOVALIDAÇÃODEDE

REQUISITOSREQUISITOS

O processo de engenharia de requisitosO processo de engenharia de requisitosmodelo de actividades de alto nívelmodelo de actividades de alto nível







Processo de engenharia de Processo de engenharia de requisitos: modelo em requisitos: modelo em espiralespiral


Validação de RequisitosValidação de Requisitos

• Consiste em demonstrar que os Consiste em demonstrar que os requisitos definem o sistema que o requisitos definem o sistema que o cliente realmente quer.cliente realmente quer.

Revisões de RequisitosRevisões de Requisitos

• Revisões regulares devem ser Revisões regulares devem ser realizadas enquanto a definição dos realizadas enquanto a definição dos requisitos está sendo formulada requisitos está sendo formulada

• Ambos o cliente e o analista devem Ambos o cliente e o analista devem estar envolvidos nas revisões estar envolvidos nas revisões

O processo de Engenharia de O processo de Engenharia de RequisitosRequisitosvalidação de Requisitosvalidação de Requisitos

•validação de requisitos diz respeito à validação de requisitos diz respeito à verificação dos requisitos quanto à sua verificação dos requisitos quanto à sua consistência, completude e precisãoconsistência, completude e precisão

•envolveenvolve revisão de requisitosrevisão de requisitos prototipagemprototipagem validação de modelosvalidação de modelos teste de requisitosteste de requisitos

Validação de RequisitosValidação de Requisitosanálise vs. validaçãoanálise vs. validação


assegurar que os requisitos vão ao

encontro das necessidades dos

stakeholders

requisitos em "bruto",informais e pouco estruturados,

escritos numa mistura de notações stakeholders


draft final do documento de requisitos,

isento de inconsistência e incompletude,

segue normas de qualidade,

assegurar que os requisitos estão correctamente

descritos

temos os requisitos certos?

temos os requisitos correctamente?

Validação de RequisitosValidação de Requisitosanálise vs. validaçãoanálise vs. validação

•exemplos de problemas que aparecem exemplos de problemas que aparecem na fase de validaçãona fase de validação

não conformidade com normas de não conformidade com normas de qualidadequalidade

requisitos mal descritos, ambíguosrequisitos mal descritos, ambíguos erros na modelação do sistema ou erros na modelação do sistema ou

problema problema conflictos entre requisitos que não foram conflictos entre requisitos que não foram

detectados no processo de análisedetectados no processo de análise

Validação de RequisitosValidação de Requisitosprocesso de validaçãoprocesso de validação



conhecimento organizacional

normas da organização

lista de problemas

acções acordadas

Kotonya, 1998

Validação de RequisitosValidação de RequisitosRevisão de requisitosRevisão de requisitos

planearrevisão

distribuirdocument

os

preparar para

a revisão

reunião de revisão

acções decontinuida

de

rever odocument

o

Kotonya, 1998

Validação de RequisitosValidação de Requisitosrevisão de requisitosrevisão de requisitos

•reunião de revisão de requisitosreunião de revisão de requisitos a reunião de revisão é uma reunião a reunião de revisão é uma reunião formalformal deve ser conduzida por alguém que não deve ser conduzida por alguém que não

esteve envolvido na produção dos requisitosesteve envolvido na produção dos requisitos cada requisito deve ser apresentado à vez cada requisito deve ser apresentado à vez

para discussão pelo grupopara discussão pelo grupo os problemas identificados são registados os problemas identificados são registados

para posterior discussãopara posterior discussão

Validação de RequisitosValidação de Requisitosrevisão de requisitosrevisão de requisitos

requisitos mal escritos

falta de informação

conflictos

requisitos não realistas

clarificação, reescrita dos requisitos

descobrir a informação que falta no documento

os stakeholders devem negociar para resolver oconflicto

o requisito deve sermodificado ou removido

problemas

acções


revisão de requisitos:revisão de requisitos: equipaequipa

equipa derevisão derequisitos

utilizador-finalou representante

especialista dodomínio

representantedo cliente

responsáveis pelo desenho do

sistema

engenheiro derequisitos


revisão de requisitos:revisão de requisitos: checklistschecklists

•checklists de revisãochecklists de revisão devem ser genéricasdevem ser genéricas não devem incidir sobre requisitos não devem incidir sobre requisitos

individualmente mas com as individualmente mas com as propriedades de qualidade do documento propriedades de qualidade do documento como um todo e com as relações entre como um todo e com as relações entre requisitosrequisitos



questões atributo de qualidade

rastreabilidade, conformidade com normas,

compreensibilidade

compreensibilidade, completude

ambiguidade

consistência, redundância

completude

organização, rastreabilidade

cada requisito está identificado de forma única?os termos especializados aparecem no glossário?o requisito depende de outros para se compreender o seu significado?há requisitos que usam o mesmo termo com sentidos diferentes?o mesmo serviço é solicitado em vários requisitos? há contradições nestas solicitações?se os requisitos fazem referência a outras facilidade, isso está descrito algures no documento?os requisitos relacionados estão agrupados? se não como se referenciam mutuamente?



•atributos de qualidade dos requisitosatributos de qualidade dos requisitos compreensibilidadecompreensibilidade redundânciaredundância completudecompletude ambiguidadeambiguidade consistênciaconsistência organizaçãoorganização conformidade com as normasconformidade com as normas rastreabilidaderastreabilidade

Validação de RequisitosValidação de Requisitosprototipagemprototipagem

•se num projecto já foram usados se num projecto já foram usados protótipos para a identificação de protótipos para a identificação de requisitos, então faz sentido que o requisitos, então faz sentido que o sejam também na validação sejam também na validação


seleccionar os testadores

do protótipo

desenvolvercenários de

teste

executarcenários

documentar problemas

documentar e estender os protótipos

Kotonya, 1998


• a reescrita dos requisitos noutro formato pode a reescrita dos requisitos noutro formato pode ajudar a validá-los ajudar a validá-los – é necessário compreendê-los bem o que pode é necessário compreendê-los bem o que pode

revelar conflictos, omissões e inconsistênciasrevelar conflictos, omissões e inconsistências

• os manuais de utilização podem começar a os manuais de utilização podem começar a ser produzidos na fase de validação (manual ser produzidos na fase de validação (manual do protótipo)do protótipo)– descrição das funcionalidades implementadas e descrição das funcionalidades implementadas e

da forma de as aceder (interfaces)da forma de as aceder (interfaces)– menção às partes do sistema não menção às partes do sistema não

implementadasimplementadas– como recuperar de dificuldadescomo recuperar de dificuldades– como instalar o protótipocomo instalar o protótipo

Validação de RequisitosValidação de Requisitosvalidação de modelosvalidação de modelos

•parte da especificação de requisitos de um parte da especificação de requisitos de um sistema pode ser constituída por vários sistema pode ser constituída por vários modelosmodelos

•a validação de modelos tem como objectivosa validação de modelos tem como objectivos– 1. avaliar individualmente a consistência de cada 1. avaliar individualmente a consistência de cada

modelomodelo– 2. avaliar a consistência externa (entre modelos)2. avaliar a consistência externa (entre modelos)– 3. mostrar que os modelos reflectem os requisitos 3. mostrar que os modelos reflectem os requisitos

reais dos stakeholders reais dos stakeholders

Validação de RequisitosValidação de Requisitosteste de requisitosteste de requisitos

•um requisito "testável" significa que se um requisito "testável" significa que se pode definir um ou mais pode definir um ou mais testestestes a realizar a realizar no sistema final de forma a poder ser no sistema final de forma a poder ser verificado se o sistema verificado se o sistema cumpre o cumpre o requisitorequisito– cada requisito funcional no documento cada requisito funcional no documento

de requisitos deve ser analisado e um de requisitos deve ser analisado e um teste ser definido de forma a ser teste ser definido de forma a ser verificado objectivamente se o sistema verificado objectivamente se o sistema satisfaz o requisito satisfaz o requisito

Validação de RequisitosValidação de Requisitosteste de requisitosteste de requisitos

•registo de testeregisto de teste– 1. identificador do requisito1. identificador do requisito– 2. requisitos relacionados2. requisitos relacionados– 3. descrição do teste3. descrição do teste– 4. problemas na realização do teste4. problemas na realização do teste– 5. comentários e recomendações5. comentários e recomendações

Verificação Automatizada de Verificação Automatizada de

ConsistênciaConsistência

Requisitos em umalinguagem formal

Relatório dos proble-mas com os Requisitos

Processador de requisitos

Analisador de requisitos

Bases de dadosde requisitos


• Erros nos requisitos custam caro, portanto Erros nos requisitos custam caro, portanto a sua validação é importante a sua validação é importante – corrigir um erro de requisitos = 100 x corrigir corrigir um erro de requisitos = 100 x corrigir

erro de implementaçãoerro de implementação


• ““Checar” requisitosChecar” requisitos– ConsistênciaConsistência. Há conflitos de requisitos? . Há conflitos de requisitos? – ValidadeValidade. O sistema provê as funções que . O sistema provê as funções que

atendem as necessidades do cliente? atendem as necessidades do cliente? – CompletudeCompletude. Todas as funções requeridas . Todas as funções requeridas

pelo cliente estão incluídas? pelo cliente estão incluídas? – RealismoRealismo. Os requisitos podem ser . Os requisitos podem ser

implementados com o orçamento e tecnologia implementados com o orçamento e tecnologia disponíveis?disponíveis?

– VerificabilidadeVerificabilidade. Os requisitos podem ser . Os requisitos podem ser verificados?verificados?

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


• Revisões de requisitos Revisões de requisitos – Análise manual sistemática dos Análise manual sistemática dos

requisitos requisitos

• PrototipaçãoPrototipação– Utilização de um modelo executável do Utilização de um modelo executável do

sistema sistema

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


• Geração de casos de teste Geração de casos de teste – Desenvolver testes para verificar os Desenvolver testes para verificar os

requisitos requisitos

• Análise automatizada da consistência Análise automatizada da consistência – Verificar a consistência de uma Verificar a consistência de uma

descrição de requisitos estruturada descrição de requisitos estruturada

Revisões de RequisitosRevisões de Requisitos

• Revisões devem se preocupar com:Revisões devem se preocupar com:– Verificabilidade. O requisito é realisticamente Verificabilidade. O requisito é realisticamente

testável?testável?– Compreensibilidade. O requisito está bem Compreensibilidade. O requisito está bem

compreendido?compreendido?– Traço. A origem do requisito está claramente Traço. A origem do requisito está claramente

identificada? identificada? – Adaptabilidade. O requisito pode ser mudado Adaptabilidade. O requisito pode ser mudado

sem grande impacto noutros requisitos? sem grande impacto noutros requisitos?

Requisitos Voláteis e Requisitos Voláteis e

PermanentesPermanentes

• Requisitos VoláteisRequisitos Voláteis Mudança provável durante ou depois do Mudança provável durante ou depois do

desenvolvimentodesenvolvimento Ex: Requisitos dos serviços bancáriosEx: Requisitos dos serviços bancários

Tipos de requisitos voláteis:Tipos de requisitos voláteis: Mutáveis: mudanças no ambienteMutáveis: mudanças no ambiente Emergentes: durante o desenvolvimentoEmergentes: durante o desenvolvimento Consequentes: resulta da introdução do sistema de Consequentes: resulta da introdução do sistema de

computadorcomputador Compatibilidade: depende de sistemas ou processos Compatibilidade: depende de sistemas ou processos

particulares dentro da organizaçãoparticulares dentro da organização

GESTÃO GESTÃO DEDE

REQUISITOS REQUISITOS

Gestão de RequisitosGestão de Requisitos

• É o processo de gerir as mudanças É o processo de gerir as mudanças nos requisitos durante o processo de nos requisitos durante o processo de engenharia de requisitos e o engenharia de requisitos e o processo de desenvolvimento de processo de desenvolvimento de sistemassistemas


• Requisitos são inevitavelmente Requisitos são inevitavelmente incompletos e inconsistentes incompletos e inconsistentes – Novos requisitos emergem durante o Novos requisitos emergem durante o

processo, pois as necessidades do processo, pois as necessidades do negócio mudam e a compreensão dos negócio mudam e a compreensão dos requisitos melhorarequisitos melhora

– Pode haver contradição no requisitos de Pode haver contradição no requisitos de viewpoints diferentes viewpoints diferentes


• Mudança de requisitos Mudança de requisitos – A prioridade dos requisitos de A prioridade dos requisitos de

viewpoints diferentes pode mudar viewpoints diferentes pode mudar durante o processo de desenvolvimento durante o processo de desenvolvimento

– O negócio pode sofrer alterações O negócio pode sofrer alterações durante o desenvolvimentodurante o desenvolvimento

Evolução de RequisitosEvolução de Requisitos

Compreensão inicial do problema

Compreensão modificada do

problema

Requisitos iniciais

Requisitos modificados

Tempo

Plano de Gestão de RequisitosPlano de Gestão de Requisitos

• Durante o processo de engenharia de Durante o processo de engenharia de requisitos deve-se planear:requisitos deve-se planear:

– A identificação dos requisitos A identificação dos requisitos – Um processo de gestão de mudança Um processo de gestão de mudança – Políticas de traçoPolíticas de traço– Suporte de ferramentas CASESuporte de ferramentas CASE

referências e informação referências e informação adicionaladicional

• Gerald Kotonya, Ian Sommerville, Gerald Kotonya, Ian Sommerville, Requirements Requirements Engineering – Processes and Techniques,Engineering – Processes and Techniques, Wiley, Wiley, 1998 (capítulo 3)1998 (capítulo 3)

• User Centerd Requirements Engineering: Theory User Centerd Requirements Engineering: Theory and Practice. Alistair Stutcliffe. Springer. 2002.and Practice. Alistair Stutcliffe. Springer. 2002.

• Soares (2005). Soares (2005). Introdução, Identificação Introdução, Identificação e Análise em Engenharia de Requisitose Análise em Engenharia de Requisitos. . António Lucas Soares. 2005. António Lucas Soares. 2005. http://http://twiki.fe.up.pttwiki.fe.up.pt//twikitwiki//binbin//viewview/ERSS0506/ErssDocumentos0506/ERSS0506/ErssDocumentos0506

http://twiki.fe.up.pt/twiki/bin/view/ERSS0506/ErssDocumentos0506









Documents

ENGENHARIA DE REQUISITOS Análise e Modelação de Sistemas 2006