A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "ENGENHARIA DE REQUISITOS Análise e Modelação de Sistemas 2006."— Transcrição da apresentação:

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

2 Engenharia de Requisitos A engenharia de requisitos (no contexto da engenharia de software) A engenharia de requisitos (no contexto da engenharia de software) É um processo que engloba todas as actividades É um processo que engloba todas as actividades Que contribuem para a produção de um documento de requisitos Que contribuem para a produção de um documento de requisitos E sua manutenção ao longo do tempo. E sua manutenção ao longo do tempo.

3 Engenharia de Requisitos Este processo deve ser precedido de estudos de viabilidade Este processo deve ser precedido de estudos de viabilidade Que a partir das restrições do projecto, determinam se este é ou não viável Que a partir das restrições do projecto, determinam se este é ou não viável E se se deve prosseguir para a identificação dos requisitos. E se se deve prosseguir para a identificação dos requisitos.

4 Conceito de Requisitos O que são requisitos de um sistema? O que são requisitos de um sistema? descrições de como o sistema se deve comportardescrições de como o sistema se deve comportar descrições de propriedades do sistemadescrições de propriedades do sistema descrições de restrições do sistema ou condicionantes no seu desenvolvimentodescrições de restrições do sistema ou condicionantes no seu desenvolvimento

5 Conceito de Requisitos mais definições... mais definições... uma capacidade de um sistema de software que um utilizador necessita para resolver um problema ou atingir um objectivouma capacidade de um sistema de software que um utilizador necessita para resolver um problema ou atingir um objectivo uma capacidade que um sistema de software deve possuir para satisfazer um contracto, especificação, norma, ou qualquer outra documentação impostauma capacidade que um sistema de software deve possuir para satisfazer um contracto, especificação, norma, ou qualquer outra documentação imposta

6 Conceito de Requisitos requisitos funcionais descrevem o que o sistema deve fazer exemplos "o sistema deve possibilitar armazenar os pedidos de orçamento" "o sistema deve possibilitar a paragem de emergência do motor requisitos não-funcionais descrevem as restrições na implementação dos requisitos funcionais exemplos "o sistema deve permitir armazenar pelo menos 500 pedidos de orçamento por ano" "o sistema operativo a usar deve ser linux" "a paragem de emergência deve ser realizada em menos de 3 segundos"

7 Onde terminam os requisitos? "Os requisitos terminam onde começa a liberdade do implementador" "Os requisitos terminam onde começa a liberdade do implementador" Idealmente, todas as decisões que têm de ser validadas pelo cliente (que o implementador não pode tomar isoladamente), devem estar contidas no documento de requisitos Idealmente, todas as decisões que têm de ser validadas pelo cliente (que o implementador não pode tomar isoladamente), devem estar contidas no documento de requisitos Na prática, não é possível ou economicamente viável prever tudo à partida, e é necessário manter um diálogo constante com o cliente Na prática, não é possível ou economicamente viável prever tudo à partida, e é necessário manter um diálogo constante com o cliente O nível de detalhe desejável varia de situação para situação O nível de detalhe desejável varia de situação para situação

8 Conceito de Requisitos níveis de requisitos níveis de requisitos alto nível: missões, objectivos, regras do negócioalto nível: missões, objectivos, regras do negócio baixo nível: necessidades dos utilizadores, funcionalidades, restriçõesbaixo nível: necessidades dos utilizadores, funcionalidades, restrições

9 O processo de Engenharia de Requisitos É constituído por quatro actividades de alto nível (Soares, 2005): É constituído por quatro actividades 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.

10 O processo de engenharia de requisitos: modelo de actividades de alto ní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.

11 O processo de engenharia de requisitos: entradas e saídas processo de engenharia de requisitos especificação do sistema requisitos (acordados) sistemas legados necessidades dos utilizadores normas da organização regulamentos informação do domínio (Kotonya e Sommerville, 1998)

12 O processo de engenharia de requisitos *qualidade do processo de ER modelo de maturidade nível 1. inicial PER adhoc nível 2. repetível PER obedecendo a normas nível 3. definido PER baseado em melhores práticas; melhoria contínua

13 O processo de engenharia de requisitos actores no processo especialista do domínio utilizador finalengenheiro de software responsável de projecto engenheiro de requisitos / analista processo de engenharia de requisitos

14 O processo de engenharia de requisitos actores no processo: stakeholders Quem são os "interessados no sistema" (stakeholders)? Quem são os "interessados no sistema" (stakeholders)? São as pessoas que serão afectadas pelo sistemaSão as pessoas que serão afectadas pelo sistema E que têm uma influência directa ou indirecta na elaboração dos requisitos:E que têm uma influência directa ou indirecta na elaboração dos requisitos:

15 O processo de engenharia de requisitos actores no processo: stakeholders Quem são os "interessados no sistema" (stakeholders) Quem são os "interessados no sistema" (stakeholders) Utilizadores finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema Utilizadores finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema Clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc. Clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc.

16 Processo de descoberta de requisitos "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 e propor soluções para resolver esse problema análise de problemas - processo de compreender um problema e propor soluções para resolver esse problema

17 identificar os stakeholders compreender as necessidades dos interessados no sistema é um factor decisivo no desenvolvimento de uma solução efectiva para um problema compreender as necessidades dos interessados no sistema é um factor decisivo no desenvolvimento de uma solução efectiva para um problema –quem são os utilizadores do sistema? –quem é o cliente (comprador) do sistema? –quem será afectado pelas saídas que o sistema produz? –quem fará a manutenção do sistema?

18 Definir as fronteiras da solução –quem fornece, utiliza, remove informação do sistema? quem opera o sistema? quem faz manutenção do sistema? onde é que o sistema é usado? como obtém o sistema a sua informação? que outros sistema interactuam com o sistema? outros sistemas fronteira do sistema solução utilizadores

19 identificar as restrições da solução restrições no grau de liberdade que temos para desenvolver o sistema restrições no grau de liberdade que temos para desenvolver o sistema –económicas –políticas –tecnológicas –sistemas existentes –ambiente –recursos

20 Acordar na definição do problema exemplo de formulação do problema exemplo de formulação do problema "o problema de se passar demasiado tempo a produzir a documentação do projecto afecta os parceiros do projecto e resulta em atrasos significativos no cumprimento dos prazos; os benefícios do sistema que gerisse a documentação à medida que é produzida residiriam numa menor percentagem de incumprimento de prazos e numa melhor relação com os parceiros"

21 O processo de engenharia de requisitos boas práticas algumas boas práticas algumas boas práticas definir uma estrutura normalizada para o documento de requisitosdefinir uma estrutura normalizada para o documento de requisitos identificar univocamente cada requisitoidentificar univocamente cada requisito definir políticas de gestão de requisitosdefinir políticas de gestão de requisitos usar checklists de problemas para a análise de requisitosusar checklists 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.,

22

23

24

25 IDENTIFICACÃO DOS REQUISITOS

26 Processo de engenharia de requisitos: modelo de actividades de alto nível Processo de engenharia de requisitos: modelo de actividades de alto nível identificação, descoberta de requisitos análise e negociação de requisitos especificação, documentação de requisitos validação de requisitos documento de Requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc.

27 Processo de engenharia de requisitos: modelo em espiral Processo de engenharia de requisitos: modelo em espiral (Kotonya e Sommerville, 1998; SWEBOK)

28 Dimensões da descoberta de requisitos compreender o domínio de aplicação compreender o problema a ser resolvido compreender o contexto de negócio compreender as necessidades e restrições dos interessados 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

29 Estágios do Processo Estabelecimento de objectivos Estabelecimento de objectivos –Objectivos gerais do negócio, descrição genérica do problema a resolver, necessidade do sistema e restrições sobre o sistema. Aquisição de conhecimento de background Aquisição de conhecimento de background –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 existentes Organização do conhecimento Organização do conhecimento –Organizar a grande quantidade de conhecimento (informação?) recolhida no estágio anterior. Recolher requisitos dos stakeholders Recolher requisitos dos stakeholders –Consultar os interessados no sistema para descobrir os seus requisitos.

30 Fontes de requisitos (1) –objectivos gerais de alto nível do sistema objectivos gerais de alto nível do sistema, problema que o sistema deve resolver, motivação para a implementação do sistema, factores críticos de sucesso, interesse para o negócio,... objectivos gerais de alto nível do sistema, problema que o sistema deve resolver, motivação para a implementação do sistema, factores críticos de sucesso, interesse para o negócio,... necessário avaliar custos e benefícios de atingir os objectivos, por exemplo com estudo de viabilidade necessário avaliar custos e benefícios de atingir os objectivos, por exemplo com estudo de viabilidade –conhecimento do domínio de aplicação necessário para inferir conhecimento tácito que os stakeholders não explicitam, avaliar trade-offs entre requisitos conflituosos, etc. necessário para inferir conhecimento tácito que os stakeholders não explicitam, avaliar trade-offs entre requisitos conflituosos, etc. pode ser obtido junto de especialistas do domínio, documentos, etc. pode ser obtido junto de especialistas do domínio, documentos, etc. –stakeholders do sistema fundamental identificar, representar e gerir os pontos de vista, interesses e necessidades de todos os interessados no sistema (utilizadores, clientes, etc.) fundamental identificar, representar e gerir os pontos de vista, interesses e necessidades de todos os interessados no sistema (utilizadores, clientes, etc.) (fonte: SWEBOK)

31 Fontes de requisitos (2) –ambiente operacional o ambiente operacional em que o sistema vai executar pode impor diversos requisitos o ambiente operacional em que o sistema vai executar pode impor diversos requisitos – aproveitamento de infra-estruturas físicas e lógicas existentes – interoperabilidade com sistemas existentes (internos ou externos) – etc. –ambiente organizacional muitos sistemas destinam-se a suportar processos de negócio, devendo-se adequar à estrutura, cultura, políticas, regras e normas internas da organização (intra/inter) muitos sistemas destinam-se a suportar processos de negócio, devendo-se adequar à estrutura, cultura, políticas, regras e normas internas da organização (intra/inter) –ambiente externo normas, regulamentos, legislação, etc. normas, regulamentos, legislação, etc. podem impor requisitos podem impor requisitos exemplos: lei de protecção de dados pessoais, normas de acessibilidade, POC,... exemplos: lei de protecção de dados pessoais, normas de acessibilidade, POC,... (fonte: SWEBOK)

32 Técnicas de descoberta de requisitos –análise de documentação –análise de sistemas existentes –entrevistas –encontros facilitados (workshops, brainstorming) –cenários –protótipos –observação e análise social, estudos etnográficos –soft systems methods –reutilização de requisitos

33 ENTREVISTAS

34 Entrevistas entrevistar os futuros utilizadores e outros stakeholders é a técnica mais vulgar e simples de obter informação para identificar requisitos entrevistar os futuros utilizadores e outros stakeholders é a técnica mais vulgar e simples de obter informação para identificar requisitos

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

36 Entrevistas –Enviesamento de quem conduz a entrevista: –Relação pessoal entre os intervenientes na entrevista: –predisposição do entrevistado: –Capacidade de seguir um "plano" para a entrevista:

37 Entrevistas tipos de entrevistas tipos de entrevistas –estruturadas vs. não estruturadas –descontextualizadas vs. contextualizadas pela solução

38 Entrevistas Entrevistas e Questionários: esta é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns factores: Entrevistas e Questionários: esta é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns factores: Entrevistas e Questionários Entrevistas e Questionários Enviesamento de quem conduz a entrevista: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida). Enviesamento de quem conduz a entrevista: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida). Relação pessoal entre os intervenientes na entrevista. Relação pessoal entre os intervenientes na entrevista.

39 Entrevistas Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afectado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação. Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afectado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação. Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados). Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).

40 Elaboração das perguntas Perguntas de contexto livre Como exemplo de perguntas deste género, podemos ter: Como exemplo de perguntas deste género, 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 para este problema? Onde podem ser encontradas outras soluções para este problema?

41 Elaboração das perguntas Perguntas centradas na solução Após terem sido feitas as perguntas de contexto livre, pode começar-se a explorar as soluções propostas com estas perguntas mais direccionadas: Após terem sido feitas as perguntas de contexto livre, pode começar-se a explorar as soluções propostas com estas perguntas mais direccionadas: (Apresentar as capacidade gerais de uma solução) E se pudesse fazer... e...? (Apresentar as capacidade gerais de uma solução) E se pudesse fazer... e...? Como classificaria a importância de cada uma das funcionalidades apresentadas? Como classificaria a importância de cada uma das funcionalidades apresentadas?

42 Aqui ficam algumas dicas para uma entrevista de sucesso: Prepare uma entrevista de contexto livre apropriada, e tome nota para que isso sirva como referência no decorrer da entrevista. Faça uma revisão às questões a colocar nos momentos que antecedem a entrevista. Prepare uma entrevista de contexto livre apropriada, e tome nota para que isso sirva como referência no decorrer da entrevista. Faça uma revisão às questões a colocar nos momentos que antecedem a entrevista. Antes da entrevista faça uma pesquisa ao background do stakeholder e da empresa a serem entrevistados. Não mace a pessoa a ser entrevistada com perguntas que poderia facilmente saber a resposta à priori. Ainda assim, pode confirmar brevemente essas respostas dando a mostrar o seu interesse e conhecimento da pessoa e empresa em questão. Antes da entrevista faça uma pesquisa ao background do stakeholder e da empresa a serem entrevistados. Não mace a pessoa a ser entrevistada com perguntas que poderia facilmente saber a resposta à priori. Ainda assim, pode confirmar brevemente essas respostas dando a mostrar o seu interesse e conhecimento da pessoa e empresa em questão.

43 Aqui ficam algumas dicas para uma entrevista de sucesso: Anote as respostas no seu bloco de notas durante a entrevista. (Não tente capturar a informação de forma electrónica nesta fase!) Anote as respostas no seu bloco de notas durante a entrevista. (Não tente capturar a informação de forma electrónica nesta fase!) Consulte as notas da estrutura da entrevista no decorrer da mesma. Desta forma tem a certeza que está a fazer as perguntas correctas e que não se está a desviar dos objectivos definidos. Consulte as notas da estrutura da entrevista no decorrer da mesma. Desta forma tem a certeza que está a fazer as perguntas correctas e que não se está a desviar dos objectivos definidos. Discuta os problemas com o utilizador. Esclareça situações que possa observar no ambiente. Faça sugestões e observações baseadas em conhecimento teórico e familiarização com outros sistemas. Discuta os problemas com o utilizador. Esclareça situações que possa observar no ambiente. Faça sugestões e observações baseadas em conhecimento teórico e familiarização com outros sistemas.

44 Entrevista e Compilação O guião da entrevista não deve ser demasiado restritivo. Depois de estabelecida uma ligação positiva com o entrevistado, é normal que a entrevista acabe por entrar numa dinâmica própria. O guião da entrevista não deve ser demasiado restritivo. Depois de estabelecida uma ligação positiva com o entrevistado, é normal que a entrevista acabe por entrar numa dinâmica própria. Após a realização das entrevistas, o analista já deve ter ficado com um leque de necessidades identificadas. Para compilar o conjunto de necessidades gerais dos utilizadores entrevistados deve ser usado um método que pode ser denominado de "Resumo do Analista". Após a realização das entrevistas, o analista já deve ter ficado com um leque de necessidades identificadas. Para compilar o conjunto de necessidades gerais dos utilizadores entrevistados deve ser usado um método que pode ser denominado de "Resumo do Analista".

45 Vantagens É a forma mais fácil de descobrir as necessidades de um sistema, pois passa por perguntar directamente aos stakeholders. É a forma mais fácil de descobrir as necessidades de um sistema, pois passa por perguntar directamente aos stakeholders. 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, é possível encontrar requisitos reais, e não apenas necessidades de alto nível. Uma vez bem definidas as perguntas e estrutura da entrevista, é possível encontrar requisitos reais, e não apenas necessidades de alto nível. É um método que aproxima as entidades envolvidas no projecto. É um método que aproxima as entidades envolvidas no projecto.

46 Desvantagens Consome bastante tempo. Consome bastante tempo. Utilizadores diferentes podem ter necessidades contraditórias. Utilizadores diferentes podem ter necessidades contraditórias. Pode originar grandes discrepâncias entre o funcionamento actual do processo de negócio, e o plano para o futuro. Pode originar grandes discrepâncias entre o funcionamento actual do processo de negócio, e o plano para o futuro.

47 Workshops de Requisitos

48 Workshops uma workshop de requisitos é uma técnica de grupo para o debate e acordo das questões asociadas à identificação dos requisitos uma workshop de requisitos é uma técnica de grupo para o debate e acordo das questões asociadas à identificação dos requisitos –levada a cabo através da formação de um grupo de representantes dos stakeholders –facilitada por alguém com competência para conduzir o processo de identificação e análise de requisitos

49 Workshops preparação preparação –"vender" o conceito –assegurar a participação dos stakeholders adequados –garantir os aspectos logísticos –fornecer materiais para discussão antecipadamente –escolher o facilitador –estabelecer uma agenda

50 Note-se que uma workshop, apesar de se assemelhar a uma reunião, difere em alguns pontos: Reuniões são lideradas por um gestor (líder, que geralmente, faz pouca preparação). As workshops são lideradas por um facilitador neutro que se prepara intensivamente; Reuniões são lideradas por um gestor (líder, que geralmente, faz pouca preparação). As workshops são lideradas por um facilitador neutro que se prepara intensivamente; 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 de produtos que servem de candidatos a inputs do workshop; 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 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 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 de decisão pode estar associada a uma ou mais pessoas (mas não ao facilitador); 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á 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 ao facilitador); As reuniões prendem-se com troca de informação. Já ás workshops prendem-se com a descoberta e criação da informação; As reuniões prendem-se com troca de informação. Já ás workshops prendem-se com a descoberta e criação da informação;

51 Note-se que uma workshop, apesar de se assemelhar a uma reunião, difere em alguns pontos: Numa reunião existe pouca interacção entre os presentes. Nas workshops a participação é intensa e variada e os participantes realizam actividades individualmente, como membros de sub-grupos, ou colectivamente; Numa reunião existe pouca interacção entre os presentes. Nas workshops a participação é intensa e variada e os participantes realizam actividades individualmente, como membros de sub-grupos, ou colectivamente; Reuniões não permitem quase nenhuns momentos de descontracção. Já as workshops encorajam a descontracção como forma de promoção da inovação e do trabalho de equipa. Reuniões não permitem quase nenhuns momentos de descontracção. Já as workshops encorajam a descontracção como forma de promoção da inovação e do trabalho de equipa. As reuniões normalmente não envolvem a prodção de documentação. Já nas workshops os participantes criam e verificam documentos como p.ex diagramas de casos de uso; As reuniões normalmente não envolvem a prodção de documentação. Já nas workshops os participantes criam e verificam documentos como p.ex diagramas de casos de uso; As reuniões usam raramente meios visuais. Nas workshops sao fortemente utilizados meios visuais como posters, post-it, cartões diagramas. As reuniões usam raramente meios visuais. Nas workshops sao fortemente utilizados meios visuais como posters, post-it, cartões diagramas.

52 Planear uma workshop Planear o horário da sessão: em que altura do dia se realizará, quanto tempo durará,... Planear o horário da sessão: em que altura do dia se realizará, quanto tempo durará,... Planear o local: a sessão deve decorrer num local arejado, com boa luz; as cadeiras devem estar dispostas de forma que todos os participantes se vejam Planear o local: a sessão deve decorrer num local arejado, com boa luz; as cadeiras devem estar dispostas 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 –Como a sessão é só uma, é importante que seja estabelecido um conjunto de regras básicas que regulem a participação. Ex: nunca se deve desviar do objectivo da sessão, nunca se deve desviar da questão base do momento, não se deve ultrapassar a vez dos outros,...

53 Planear uma workshop Planear a agenda a seguir: Planear a agenda a seguir: –Dar as boas-vindas –Rever a agenda –Rever o objectivo da sessão –Rever as regras básicas de participação –Fazer uma introdução ao projecto –Lançar as questões e conduzir as respostas –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 notas ao longo da workshop –Para além disso, pode ser útil gravar a sessão em suporte áudio ou video

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

55 Conduzir uma workshop Forming - Fase de orientação do grupo e introdução dos objectivos da sessão. Nesta fase o facilitador deve: Forming - Fase de orientação do grupo e introdução dos objectivos da sessão. Nesta fase o facilitador deve: –Apresentar-se e apresentar o co-facilitador –Agradecer a disponibilidade das pessoas –Explicar os modos de gravação da sessão (só papel, gravador audio ou video) –Apresentar/relembrar a agenda Storming - divulgação de todas as ideias que os intervenientes possam ter, mesmo que estas sejam incompatíveis com outras áreas de negócio ou mesmo com o sistema que foi inicialmente idealizado. O facilitador deve: Storming - divulgação de todas as ideias que os intervenientes possam ter, mesmo que estas sejam incompatíveis com outras áreas de negócio ou mesmo com o sistema que foi inicialmente idealizado. O facilitador deve: –Introduzir todas as questões antes de se iniciar o debate. Dar algum tempo aos participantes para pensarem sobre cada uma (e registarem as suas respostas). De seguida conduzir a discussão à volta das respostas a cada questão, sendo tratada uma de cada vez –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 ser o co-facilitador a fazer isto)

56 Conduzir uma workshop Norming - Promover a harmonia, a compreensão e o apoio das ideias uns dos outros, aumentando a coesão dos grupos intervenientes. O facilitador deve: Norming - Promover a harmonia, a compreensão e o apoio das ideias uns dos outros, aumentando a coesão dos grupos intervenientes. O facilitador deve: –Garantir que as regras básicas de participação são respeitadas, dando voz a todos os participantes –O facilitador não deve participar no debate/discussão (nunca justificar a sua posição)... O seu papel fundamental é ouvir e coleccionar informação –Assegurar a participação uniforme - se 1/2 pessoas estão a liderar a discussão, o facilitador deve promover e incentivar os outros intervenientes, chamando-os a responder. Uma boa abordagem é usar uma mesa redonda, seguindo uma direcção, dando a cada participante 1 min para transmitir a sua opinião. Performing - Nesta fase já deverá estar interiorizado no pensamento dos stakeholders uma actuação como equipa. Aqui já deverão emergir soluções. Os requisitos já deverão ser tratados com mais detalhe e ser prioritizados. Performing - Nesta fase já deverá estar interiorizado no pensamento dos stakeholders uma actuação como equipa. Aqui já deverão emergir soluções. Os requisitos já deverão ser tratados com mais detalhe e ser prioritizados.

57 Conduzir uma workshop Adjourning - Deverá ser feita uma retrospectiva do projecto, e das soluções encontradas. Esta fase não deverá ser descurada, já que é essencial para que os intervenientes percebam que o papel que desempenharam foi tomado em conta e é essencial para este e futuros projectos. O facilitador deve: Adjourning - Deverá ser feita uma retrospectiva do projecto, e das soluções encontradas. Esta fase não deverá ser descurada, já que é essencial para que os intervenientes percebam que o papel que desempenharam foi tomado em conta e é essencial para este e futuros projectos. O facilitador deve: –Notificar os participantes da breve recepção de uma cópia do relatório resultante da sessão (contendo as principais propostas e conclusões) –Agradecer aos participantes a sua presença e participação –Terminar a sessão

58 Como tirar mais proveito dos Workshops? As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. Uma técnica que é também útil em workshops é o uso de brainstorming como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflicta os requisitos e decisões tomadas sobre o sistema a implementar. Como resultado dos workshops deve ser produzida documentação que reflicta os requisitos e decisões tomadas sobre o sistema a implementar.

59 Brainstorming brainstorming é uma técnica para a geração de novas ideias por um conjuto de pessoas brainstorming é uma técnica para a geração de novas ideias por um conjuto de pessoas –encoraja a participação de todos –permite o aproveitamento e refinamento de outras ideias –pode ser bastante produtiva (nº de ideias/hora) –o resultado pode ser um conjunto de soluções –encoraja o pensamento livre... (maluquices...)

60 Brainstorming: reduzir ideias "podar" ideias "podar" ideias agrupar ideias agrupar ideias definir as características de cada ideia definir as características de cada ideia estabelecer prioridades estabelecer prioridades

61 Brainstorming regras do brainstorming regras do brainstorming –não permitir críticas ou debate –deixar a imaginação voar... –gerar tantas ideias quanto for possível –mutar e combinar ideias –Atraso do julgamento –Criatividade em quantidade e qualidade

62 Há 3 principais partes no brainstorming: Encontrar os factos, Encontrar os factos, Geração da ideia, Geração da ideia, Encontrar a solução. Encontrar a solução.

63 Há 3 principais partes no brainstorming: Da busca dos factos na resolução de um problema existem duas sub partes: Da busca dos factos na resolução de um problema existem duas sub partes: Definição do problema, Definição do problema, Preparação. Preparação.

64 Há 3 principais partes no brainstorming: Inicialmente, define-se o problema. Poderá ser necessário subdividir o problema em várias partes. A técnica de Brainstorming funciona para problemas que têm muitas soluções possíveis tal como a geração de ideias para o seu desenho. Inicialmente, define-se o problema. Poderá ser necessário subdividir o problema em várias partes. A técnica de Brainstorming funciona para problemas que têm muitas soluções possíveis tal como a geração de ideias para o seu desenho. Depois é necessário colher toda a informação que pode relacionar- se com o problema. Depois é necessário colher toda a informação que pode 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.

65 Brainstorming na educação A técnica de brainstorming não é uma actividade exclusiva de um ambiente empresarial: pelo contrário, na escola esta, pode ser uma técnica muito importante na educação dos estudantes. Este grande ou pequeno grupo de actividade encoraja os estudantes a manterem- se focados num tópico e contribuir para uma fluidez de ideias em liberdade. A técnica de brainstorming não é uma actividade exclusiva de um ambiente empresarial: pelo contrário, na escola esta, pode ser uma técnica muito importante na educação dos estudantes. Este grande ou pequeno grupo de actividade encoraja os estudantes a manterem- se focados num tópico e contribuir para uma fluidez de ideias em liberdade. O professor pode começar por propôr uma questão ou problema, ou introduzindo um tópico. Os estudantes, depois expressam e divulgam as possíevis respostas e soluções, palavras, expressões ou ideias relevantes. O professor pode começar por propôr uma questão ou problema, ou introduzindo um tópico. Os estudantes, depois expressam e divulgam as possíevis respostas e soluções, palavras, expressões ou ideias relevantes.

66 CENÁRIOS

67 cenários abordagem para colocar os interessados num sistema perante uma situação realista em que simulam ou apenas antevêem a sua interacção com o sistema abordagem para colocar os interessados num sistema perante uma situação realista em que simulam ou apenas antevêem a sua interacção com o sistema –materializam-se em histórias que explicam como é que o sistema poderá ser usado

68 Cenários uma forma de levar as pessoas a imaginar o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interacção que esperam ter com ele. uma forma de levar as pessoas a imaginar o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interacção que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos: Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:

69 Cenários Estado do sistema no início do cenário. Estado do sistema no início do cenário. Sequência de eventos esperada (na ausência de erros) no cenário. Sequência de eventos esperada (na ausência de erros) no cenário. Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados. Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados.

70 Cenários Outras actividades que podem estar a ser executadas ao mesmo tempo que as deste cenário. Outras actividades que podem estar a ser executadas ao mesmo tempo que as deste cenário. Estado do sistema depois de o cenário terminar. Estado do sistema depois de o cenário terminar.

71 Cenários: conteúdo descrição do sistema antes de se entrar no cenário fluxo normal de eventos excepções ao fluxo normal de eventos informação sobre outras actividades que ocorrem ao mesmo tempo descrição do estado do sistema depois de completado o cenário

72 Cenários: definição mais definições mais definições –uma história ou exemplo de eventos retirados da experiência do mundo real; incluem detalhes do contexto do sistema (cenas) –um caminho ou instância de um modelo (normalmente de casos de utilização) –a visão futura de um sistema a ser desenhado, com sequências de comportamento e descrições contextuais Sutcliffe, 2002

73 Cenários: objectivos identificar e clarificar requisitos identificar e clarificar requisitos –adicionar detalhe a requisitos mais gerais –compreender a relação entre requisitos validar requisitos validar requisitos –compreender um requisito no seu contexto de utilização –verificar se a sua relação com outros requisitos faz sentido

74 Principais vantagens do uso de cenários em Engenharia de Requisitos Tem em conta o ponto de vista do utilizador Tem em conta o ponto de vista do utilizador Especificações parciais Especificações parciais Fácil de compreender Fácil de compreender Ciclos de feedback curtos Ciclos de feedback curtos Servir de base para os testes do sistema Servir de base para os testes do sistema

75 CENÁRIOS: conclusão Engenharia de requisitos baseada em cenários é definitavamente um passo na direcção certa. Engenharia de requisitos baseada em cenários é definitavamente um passo na direcção certa. Em particular, cenários são uma chave que permite um novo estilo de engenharia de requisitos evolucionário e incremental. Em particular, cenários são uma chave que permite um novo estilo de engenharia de requisitos evolucionário e incremental.

76 CENÁRIOS: conclusão Os cenários focam-se nos utilizadores, em descrições concretas e instâncias específicas. Os cenários focam-se nos utilizadores, em descrições concretas e instâncias específicas. O desenho de sistemas baseado em cenários atribui um grande ênfase aos utilizadores; articula qual o seu papel, o que fazem, como fazem, e sobre que circunstâncias o fazem. O desenho de sistemas baseado em cenários atribui um grande ênfase aos utilizadores; articula qual o seu papel, o que fazem, como fazem, e sobre que circunstâncias o fazem. Um cenário é uma descrição concreta do trabalho e actividades, descrevendo assim uma instância específica e um caso de uso. Um cenário é uma descrição concreta do trabalho e actividades, descrevendo assim uma instância específica e um caso de uso.

77 Cenários versus casos de uso Existem diferentes opiniões sobre a relação existente entre casos de uso e cenários: Existem diferentes opiniões sobre a relação existente entre casos de uso e cenários: –Há quem os considere sinónimos –Há quem considere que um cenário corresponde a um conjunto de casos de uso (fluxo normal de eventos, e cada fluxo excepcional seriam casos de uso separados) –Há quem considere que um caso de uso corresponde a um conjunto de cenários Em UML, um caso de uso admite variantes, podendo-se considerar cada variante como um cenário Em UML, um caso de uso admite variantes, podendo-se considerar cada variante como um cenário Cada cenário pode ser representado por um diagrama de interacção (normalmente um diagrama de sequência) Cada cenário pode ser representado por um diagrama de interacção (normalmente um diagrama de sequência)

78 cenários: exemplo – reservar livro através do site da biblioteca Entrar no sistema (log on) Entrar no sistema (log on) Procurar o livro pretendido por autor, título ou ISBN Procurar o livro pretendido por autor, título ou ISBN Seleccionar um dos exemplares disponíveis Seleccionar um dos exemplares disponíveis Dar ordem para reservar esse exemplar Dar ordem para reservar esse exemplar Seleccionar o modo de entrega: levantamento na biblioteca, ou envio por funcionário Seleccionar o modo de entrega: levantamento na biblioteca, ou envio por funcionário Sair do sistema (logout) Sair do sistema (logout)

79 PROTOTIPAGEM

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

81 Prototipagem características características –desenvolvimento rápido –funcionalidades limitadas –requisitos não funcionais pouco considerados –várias tecnologias –pode ir desde maquetas a protótipos evolutivos

82 Prototipagem: custos a decisão de usar a prototipagem deve ser tomada com recurso a uma análise custo- benefício a decisão de usar a prototipagem deve ser tomada com recurso a uma análise custo- benefício custos envolvidos na prototipagem custos envolvidos na prototipagem –formação, desenvolvimento, prazos mais alargados, protótipos incompletos

83 Prototipagem: benefícios Prototipagem: benefícios benefício principal benefício principal –os clientes e utilizadores finais têm contacto com um sistema realista cedo o que lhes permite compreender melhor os requisitos que pretendem identificar e analisar outros benefícios outros benefícios –ajuda a estabelecer a viabilidade e utilidade do sistema –é a única forma efectiva de desenvolver IPC –pode ser usado na validação –o estudo cuidadoso dos requisitos ajuda a revelar inconsistências e lacunas

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

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

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

87 Prototipagem: tipos Prototipagem: tipos prototipagem evolutiva prototipagem evolutiva –o objectivo é proporcionar um sistema "produtivo" o mais rápido possível ao cliente –os requisitos objecto dos protótipos iniciais deverão ser aqueles mais facilmente compreendidos e que podem dar rapidamente um valor acrescentado útil ao utilizador

88 ESTUDOS ETNOGRÁFICOS

89 Etnografia Etnografia Técnica onde o sociólogo gasta um tempo considerável no ambiente de trabalho a observar e a anotar como os participantes envolvidos trabalham Técnica onde o sociólogo gasta um tempo considerável no ambiente de trabalho a observar e a anotar como os participantes envolvidos trabalham Interacções implícitas são reveladas. As pessoas não têm que explicar o seu trabalho Interacções implícitas são reveladas. As pessoas não têm que explicar o seu trabalho

90 Estudos EtnográficosEstudos Etnográficos: Estudos Etnográficos Este tipo de estudos são uma análise da componente social das tarefas desempenhadas numa dada organização. Este tipo de estudos são uma análise da componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo.

91 Estudos EtnográficosEstudos Etnográficos: Estudos Etnográficos Através de uma observação directa das actividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Através de uma observação directa das actividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registos áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Esta observação pode ser acompanhada de registos áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o stakeholder observado desempenha as suas funções "correctamente", pelo que convém ter algum cuidado na escolha do(s) stakeholder(s) a observar. Nesta técnica assume-se que o stakeholder observado desempenha as suas funções "correctamente", pelo que convém ter algum cuidado na escolha do(s) stakeholder(s) a observar.

92 Observação e Análise Social estudos etnográficos e identificação de requisitos estudos etnográficos e identificação de requisitos –há requisitos que não se conseguem identificar através das técnicas convencionais –os estudos etnográficos ajudam a fazer emergir requisitos derivados de formas rotineiras e tácitas de trabalhar

93 Observação e Análise Social grande parte dos sistemas que desenvolvemos visam apoiar o trabalho das pessoas grande parte dos sistemas que desenvolvemos visam apoiar o trabalho das pessoas o trabalho é uma actividade social que envolve grupos de pessoas que cooperam para levar a cabo diferentes tarefas o trabalho é uma actividade social que envolve grupos de pessoas que cooperam para levar a cabo diferentes tarefas Kotonya, 1998

94 observação e análise social as pessoas encontram frequentemente dificuldade em tornar explícita a forma como realizam tarefas e como trabalham em conjunto com outros as pessoas encontram frequentemente dificuldade em tornar explícita a forma como realizam tarefas e como trabalham em conjunto com outros quando as tarefas se tornam rotina e as pessoas tendem a não pensar nelas conscientemente, torna-se difícil que articulem como é que o trabalho é realizado quando as tarefas se tornam rotina e as pessoas tendem a não pensar nelas conscientemente, torna-se difícil que articulem como é que o trabalho é realizado as pessoas usam artefactos (ferramentas, documentos, etc.) de uma forma intuitiva as pessoas usam artefactos (ferramentas, documentos, etc.) de uma forma intuitiva

95 Estudos Etnográficos algumas directrizes algumas directrizes –assumir que as pessoas que se estão a estudar são boas a realizar o seu trabalho –estabelecer relações de confiança com as pessoas envolvidas no estudo; os analistas devem ser externos à organização –escrever notas detalhadas e regulares das práticas de trabalho estudadas –realizar entrevistas abertas –não recorrer demasiado às gravações vídeo e áudio, porque são difíceis de tratar em tempo útil –realizar sessões de crítica por parte de elementos externos ao projecto

96 observação e análise social estudos etnográficos estudos etnográficos –observação detalhada das práticas sociais de uma sociedade –uma compreensao total destas práticas só é possível pela observação do detalhe e a partir do interior da comunidade –um grupo de funcionários numa biblioteca, num banco, num laboratório têm características dos elementos de uma sociedade

97 Estudos Etnográficos Estudos Etnográficos protótipo prototipage m experiências dos utilizadores etnografia focada reuniões de crítica análise etnográfica

98 ANÁLISE E NEGOCIAÇÃO ANÁLISE E NEGOCIAÇÃO

99 O processo de engenharia de requisitos modelo de actividades de alto nível identificação, descoberta de requisitos análise e negociação de requisitos documentaçã o de requisitos validação de requisitos documento de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc.

100 Processo de engenharia de requisitos: modelo em espiral (Kotonya e Sommerville, 1998; SWEBOK)

101 Análise e Negociação de Requisitos objectivos análise e negociação de requisitos análise e negociação de requisitos –actividades que visam descobrir problemas com os requisitos e chegar a acordos para a sua resolução de forma a satisfazer todos os interessados no sistema –na realidade, na fase de identificação de requisitos já se desenrolam actividades de análise e negociação –análise e negociação de requisitos são actividades que incidem sobre conjuntos incompletos de requisitos

102 Análise e Negociação de Requisitos características a análise e negociação de requisitos é normalmente um processo complexo a análise e negociação de requisitos é normalmente um processo complexo –requer pessoas com competências específicas –baseia-se muito no julgamento e experiência dos participantes –não é possível transformar este processo numa abordagem estruturada e sistemática –é custoso e moroso

103 Análise de Requisitos necessidade, consistência e completude no conjunto de requisitos identificados pode no conjunto de requisitos identificados pode –haver requisitos que se sobrepõem –haver requisitos que estão em conflito ou que são contraditórios –faltar requisitos...

104 Análise de Requisitos técnicas: check-lists listas de questões que um analista usa para avaliar os requisitos listas de questões que um analista usa para avaliar os requisitos –são um "lembrete" do que é importante considerar na análise –não devem ter mais do que 10 items –evoluem com a experiência ganha no processo de análise

105 Análise de Requisitos técnicas: check-lists exemplo exemplo –o requisito inclui aspectos de desenho ou implementação –o requisito poderia ser decomposto em sub-requisitos? –o requisito é mesmo necessário?... –o requisito implica a utilização de software não standard? –o requisito está de acordo com os objectivos do negócio? –o requisito é ambíguo? –o requisito é realista? –o requisito é "testável"? Sutcliffe, 2002

106 Análise de Requisitos análise quanto ao âmbito definir as fronteiras do sistema analisar e decidir se o requisito está dentro ou fora diagramas de contexto diagramas de casos de uso

107 Análise de Requisitos análise de prioridades definir prioridades na análise e implementação dos requisitos definir prioridades na análise e implementação dos requisitos classificação classificação –alta, média, baixa, não/sabe –essencial, útil, pouco interesse, a ser decidido

108 Análise de Requisitos organização dos requisitos hierarquização hierarquização –relações de composição ou "pai-> filhos" ou "requisito-> sub-requisito" –os requisitos são definidos a vários níveis de abstracção a organização em hierarquias é adequada a uma abordagem iterativa (espiral) ao processo de engenharia de requisitos a organização em hierarquias é adequada a uma abordagem iterativa (espiral) ao processo de engenharia de requisitos

109 Análise de Requisitos hierarquia de requisitos e casos de uso 1. marcação de consulta (caso de uso) –1.1 a consulta pode ser marcada pelo médico ou pela assistente –1.2 um médico pode marcar uma consulta para outro médico –1.3 não se podem marcar duas consultas para a mesma data, hora e médico (restrição) –1.4 o sistema deve alertar o utilizador no caso do doente ter outras consultas marcadas (alerta) –1.5 o sistema deve ajudar o utilizador a encontrar vagas (ajuda) –(...)

110 Negociação de Requisitos aspectos gerais negociação para quê? negociação para quê? –chegar a acordo em relação a opções mais adequadas aos interesses dos stakeholders –definir as prioridades a dar aos requisitos para novas iterações de identificação e análise e para o desenvolvimento –chegar a acordo em relação a compromissos entre requisitos que entram em conflito

111 Negociação de Requisitos tarefas 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 um acordo diagnosticar causas de desacordo

112 Negociação de Requisitos intervenientes na negociação stakeholders primários stakeholders primários –os que operam o sistema –preocupam-se com os requisitos funcionais e questões de usabilidade –pretendem sistemas fáceis de usar e aprender

113 Negociação de Requisitos intervenientes na negociação stakeholders secundários stakeholders secundários –não operam o sistema mas consomem o que este produz –o sucesso das suas actividades depende da qualdade do sistema –são tipicamente gestores que usam a informação do sistema para controlar, monitorar e ajustar processos organizacionais

114 Negociação de Requisitos intervenientes na negociação stakeholders terciários stakeholders terciários –gestores de topo que raramente consomem as saídas do sistema (directamente) –usam-nas indirectamente para planear e controlar estrategicamente o negócio –interessam-se pelo papel que o sistema desempenha na prossecução dos objectivos estratégicos do negócio tais como aumentar a vantagem competitiva ou melhorar o serviço ao cliente

115 Negociação de Requisitos gerir a negociação problemas num processo de negociação problemas num processo de negociação –separar os aspectos a debater das questões pessoais –falta de entendimento partilhado e de pontos de vista pessoais –atitudes interpessoais

116 Negociação de Requisitos técnicas para gerir a negociação lidar com os ataques pessoais lidar com os ataques pessoais –evitá-los... –se acontecerem: mudar de assunto, fazer um intervalo... –resolver o problema fora da reunião

117 Negociação de Requisitos técnicas para gerir a negociação bloqueio bloqueio –reacções negativas sem justificação: "isso não resulta", "não se pode fazer", "dá muito trabalho“. –desafiar os participantes a justificarem a sua posição negativa

118 Negociação de Requisitos técnicas para gerir a negociação conflitos entre grupos conflitos entre grupos –choque de pontos de vista entre grupos –exemplos: qualidade vs. prazos, custos vs. desenvolvimento, segurança vs. acesso, complexidade funcional vs. usabilidade, etc. –deferir decisões, os ânimos arrefecem...

119 Negociação de Requisitos técnicas para gerir a negociação outras técnicas outras técnicas –testar e provar assunções (pressupostos) –relaxar restrições –tentar encontrar potenciais benefícios para todos –evitar tomar partidos

120 ESPECIFICAÇÃO E DOCUMENTAÇÃO

121 O processo de engenharia de requisitos modelo de actividades de alto nível O processo de engenharia de requisitos modelo de actividades de alto nível identificação, descoberta de requisitos análise e negociação de requisitos documentação de requisitos validação de requisitos documento de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. + protótipo + modelo

122 Documento de Requisitos O que é um Documento de Requisitos? O que é um Documento de Requisitos? –é uma descrição oficial dos requisitos de um sistema para os clientes, utilizadores e desenvolvedores –outras designações: especificação funcional, definição de requisitos, especificação de requisitos, caderno de encargos

123 Documento de Requisitos como se escreve um Documento de Requisitos? como se escreve um Documento de Requisitos? –depende de quem o escreve, para quem, onde,... –normalmente é escrito em linguagem natural e pode ser complementado com diagramas, tabelas, fotografias, imagens, etc. –existem directrizes e recomendações para a escrita de documentos de requisitos –o grau de detalhe depende de quem o escreve, da organização em que está inserido, do seu propósito,

124 Documento de Requisitos Documento de Requisitos é usado para comunicar o que se pretende que um determinado sistema faça Documento de Requisitos é usado para comunicar o que se pretende que um determinado sistema faça –destina-se aos clientes, utilizadores, gestores e desenvolvedores do eventual sistema –especifica que serviços o sistema deve prestar, as propriedades do sistema (fiabilidade, eficiência, etc.) e restrições impostas à operação e desenvolvimento do sistema –tanto pode ser um documento muito sucinto e genérico como um documento extenso e muito detalhado.

125 Documento de Requisitos O que é que normalmente se encontra num documento de requisitos? O que é que normalmente se encontra num documento de requisitos? –uma visão geral do sistema e dos benefícios decorrentes do desenvolvimento do sistema –um glossário explicando os termos técnicos usados –uma definição dos serviços ou requisitos funcionais do sistema –uma definição das propriedades do sistema (requisitos não- funcionais) tais como fiabilidade, segurança, etc.

126 Documento de Requisitos O que é que normalmente se encontra num documento de requisitos? O que é que normalmente se encontra num documento de requisitos? –as restrições à operação do sistema e ao processo de desenvolvimento –uma definição do ambiente em que o sistema vai operar e as mudanças previstas para esse ambiente –especificações detalhadas recorrendo a modelos e outras ferramentas

127 Documento de Requisitos Estrutura sugerida por IEEE/ANSI ( ) Estrutura sugerida por IEEE/ANSI ( ) 1. Introdução 1. Introdução –1.1 Propósito do documento –1.2 Âmbito do sistema –1.3 Definições, acrónimos e abreviaturas –1.4 Referências –1.5 Resenha do resto do documento

128 Documento de Requisitos Estrutura sugerida por IEEE/ANSI ( ) (cont.) Estrutura sugerida por IEEE/ANSI ( ) (cont.) 2. Descrição geral 2. Descrição geral –2.1 Perspectiva do produto –2.2 Funções do produto –2.3 Características dos utilizadores –2.4 Restrições gerais –2.5 Assunções e dependências

129 Documento de Requisitos Estrutura sugerida por IEEE/ANSI ( ) (cont.) Estrutura sugerida por IEEE/ANSI ( ) (cont.) 3. Requisitos específicos 3. Requisitos específicos –requisitos funcionais, requisitos não funcionais, requisitos da interface com o utilizador: funcionalidade, interfaces externas, requisitos de desempenho, restrições de concepção, atributos do sistema, características de qualidade,... funcionalidade, interfaces externas, requisitos de desempenho, restrições de concepção, atributos do sistema, características de qualidade,... Apêndices Apêndices Índice Índice

130 Documento de Requisitos Orientações Orientações –explicar como se usa o documento –descrever um ou mais cenários de utilização –definir claramente os termos especializados –formatar o documento para uma boa legibilidade –ajudar os leitores a encontrar informação –fazer o documento fácil de alterar

131 Manual do Utilizador como Documento de Requisitos Steve McConnel, no seu livro "Software Project Survival Guide", defende que, na maioria dos situações, é mais vantajoso documentar os requisitos através de um manual do utilizador e um protótipo da interface com o utilizador, facilmente percebidos por todos, do que através de um documento formal de requisitos Steve McConnel, no seu livro "Software Project Survival Guide", defende que, na maioria dos situações, é mais vantajoso documentar os requisitos através de um manual do utilizador e um protótipo da interface com o utilizador, facilmente percebidos por todos, do que através de um documento formal de requisitos (documento formal deve ser apenas um complemento) (documento formal deve ser apenas um complemento)

132 VALIDAÇÃO DE REQUISITOS

133 O processo de engenharia de requisitos modelo de actividades de alto nível identificação, descoberta de requisitos análise e negociação de requisitos documentaçã o de requisitos validação de requisitos documento de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc.

134 Processo de engenharia de requisitos: modelo em espiral Processo de engenharia de requisitos: modelo em espiral (Kotonya e Sommerville, 1998; SWEBOK)

135 Validação de Requisitos Consiste em demonstrar que os requisitos definem o sistema que o cliente realmente quer. Consiste em demonstrar que os requisitos definem o sistema que o cliente realmente quer.

136 Revisões de Requisitos Revisões regulares devem ser realizadas enquanto a definição dos requisitos está sendo formulada Revisões regulares devem ser realizadas enquanto a definição dos requisitos está sendo formulada Ambos o cliente e o analista devem estar envolvidos nas revisões Ambos o cliente e o analista devem estar envolvidos nas revisões

137 O processo de Engenharia de Requisitos validação de Requisitos validação de requisitos diz respeito à verificação dos requisitos quanto à sua consistência, completude e precisão validação de requisitos diz respeito à verificação dos requisitos quanto à sua consistência, completude e precisão envolve envolve  revisão de requisitos  prototipagem  validação de modelos  teste de requisitos

138 Validação de Requisitos análise vs. validação análise e negociação de requisitos 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 validação de requisitos 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?

139 Validação de Requisitos análise vs. validação exemplos de problemas que aparecem na fase de validação exemplos de problemas que aparecem na fase de validação  não conformidade com normas de qualidade  requisitos mal descritos, ambíguos  erros na modelação do sistema ou problema  conflictos entre requisitos que não foram detectados no processo de análise

140 Validação de Requisitos processo de validação validação de requisitos documento de requisitos conhecimento organizacional normas da organização lista de problemas acções acordadas Kotonya, 1998

141 Validação de Requisitos Revisão de requisitos planear revisão distribuir documentos preparar para a revisão reunião de revisão acções de continuidad e rever o documento Kotonya, 1998

142 Validação de Requisitos revisão de requisitos reunião de revisão de requisitos reunião de revisão de requisitos  a reunião de revisão é uma reunião formal  deve ser conduzida por alguém que não esteve envolvido na produção dos requisitos  cada requisito deve ser apresentado à vez para discussão pelo grupo  os problemas identificados são registados para posterior discussão

143 Validação de Requisitos revisã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 o conflicto o requisito deve ser modificado ou removido problemas acções

144 Validação de Requisitos revisão de requisitos: equipa equipa de revisão de requisitos utilizador-final ou representante especialista do domínio representante do cliente responsáveis pelo desenho do sistema engenheiro de requisitos

145 Validação de Requisitos revisão de requisitos: checklists checklists de revisão checklists de revisão  devem ser genéricas  não devem incidir sobre requisitos individualmente mas com as propriedades de qualidade do documento como um todo e com as relações entre requisitos

146 Validação de Requisitos revisão de requisitos: checklists

147 atributos de qualidade dos requisitos atributos de qualidade dos requisitos  compreensibilidade  redundância  completude  ambiguidade  consistência  organização  conformidade com as normas  rastreabilidade

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

149 Validação de Requisitos prototipagem seleccionar os testadores do protótipo desenvolver cenários de teste executar cenários documentar problemas documentar e estender os protótipos Kotonya, 1998

150 Validação de Requisitos prototipagem a reescrita dos requisitos noutro formato pode ajudar a validá-los a reescrita dos requisitos noutro formato pode ajudar a validá-los –é necessário compreendê-los bem o que pode revelar conflictos, omissões e inconsistências os manuais de utilização podem começar a ser produzidos na fase de validação (manual do protótipo) os manuais de utilização podem começar a ser produzidos na fase de validação (manual do protótipo) –descrição das funcionalidades implementadas e da forma de as aceder (interfaces) –menção às partes do sistema não implementadas –como recuperar de dificuldades –como instalar o protótipo

151 Validação de Requisitos validação de modelos parte da especificação de requisitos de um sistema pode ser constituída por vários modelos parte da especificação de requisitos de um sistema pode ser constituída por vários modelos a validação de modelos tem como objectivos a validação de modelos tem como objectivos –1. avaliar individualmente a consistência de cada modelo –2. avaliar a consistência externa (entre modelos) –3. mostrar que os modelos reflectem os requisitos reais dos stakeholders

152 Validação de Requisitos teste de requisitos um requisito "testável" significa que se pode definir um ou mais testes a realizar no sistema final de forma a poder ser verificado se o sistema cumpre o requisito um requisito "testável" significa que se pode definir um ou mais testes a realizar no sistema final de forma a poder ser verificado se o sistema cumpre o requisito –cada requisito funcional no documento de requisitos deve ser analisado e um teste ser definido de forma a ser verificado objectivamente se o sistema satisfaz o requisito

153 Validação de Requisitos teste de requisitos registo de teste registo de teste –1. identificador do requisito –2. requisitos relacionados –3. descrição do teste –4. problemas na realização do teste –5. comentários e recomendações

154 Verificação Automatizada de Consistência Requisitos em uma linguagem formal Relatório dos proble- mas com os Requisitos Processador de requisitos Analisador de requisitos Bases de dados de requisitos

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

156 Validação de Requisitos “ Checar” requisitos “ Checar” requisitos –Consistência. Há conflitos de requisitos? –Validade. O sistema provê as funções que atendem as necessidades do cliente? –Completude. Todas as funções requeridas pelo cliente estão incluídas? –Realismo. Os requisitos podem ser implementados com o orçamento e tecnologia disponíveis? –Verificabilidade. Os requisitos podem ser verificados?

157 Técnicas de Validação de Requisitos Revisões de requisitos Revisões de requisitos –Análise manual sistemática dos requisitos Prototipação Prototipação –Utilização de um modelo executável do sistema

158 Técnicas de Validação de Requisitos Geração de casos de teste Geração de casos de teste –Desenvolver testes para verificar os requisitos Análise automatizada da consistência Análise automatizada da consistência –Verificar a consistência de uma descrição de requisitos estruturada

159 Revisões de Requisitos Revisões devem se preocupar com: Revisões devem se preocupar com: –Verificabilidade. O requisito é realisticamente testável? –Compreensibilidade. O requisito está bem compreendido? –Traço. A origem do requisito está claramente identificada? –Adaptabilidade. O requisito pode ser mudado sem grande impacto noutros requisitos?

160 Requisitos Voláteis e Permanentes Requisitos Voláteis Requisitos Voláteis  Mudança provável durante ou depois do desenvolvimento  Ex: Requisitos dos serviços bancários  Tipos de requisitos voláteis:  Mutáveis: mudanças no ambiente  Emergentes: durante o desenvolvimento  Consequentes: resulta da introdução do sistema de computador  Compatibilidade: depende de sistemas ou processos particulares dentro da organização

161 GESTÃO DE REQUISITOS

162 Gestão de Requisitos É o processo de gerir as mudanças nos requisitos durante o processo de engenharia de requisitos e o processo de desenvolvimento de sistemas É o processo de gerir as mudanças nos requisitos durante o processo de engenharia de requisitos e o processo de desenvolvimento de sistemas

163 Gestão de Requisitos Requisitos são inevitavelmente incompletos e inconsistentes Requisitos são inevitavelmente incompletos e inconsistentes –Novos requisitos emergem durante o processo, pois as necessidades do negócio mudam e a compreensão dos requisitos melhora –Pode haver contradição no requisitos de viewpoints diferentes

164 Gestão de Requisitos Mudança de requisitos Mudança de requisitos –A prioridade dos requisitos de viewpoints diferentes pode mudar durante o processo de desenvolvimento –O negócio pode sofrer alterações durante o desenvolvimento

165 Evolução de Requisitos Compreensão inicial do problema Compreensão modificada do problema Requisitos iniciais Requisitos modificados Tempo

166 Plano de Gestão de Requisitos Durante o processo de engenharia de requisitos deve-se planear: Durante o processo de engenharia de requisitos deve-se planear: –A identificação dos requisitos –Um processo de gestão de mudança –Políticas de traço –Suporte de ferramentas CASE

167 referências e informação adicional Gerald Kotonya, Ian Sommerville, Requirements Engineering – Processes and Techniques, Wiley, 1998 (capítulo 3) Gerald Kotonya, Ian Sommerville, Requirements Engineering – Processes and Techniques, Wiley, 1998 (capítulo 3) User Centerd Requirements Engineering: Theory and Practice. Alistair Stutcliffe. Springer User Centerd Requirements Engineering: Theory and Practice. Alistair Stutcliffe. Springer Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares ssDocumentos0506 Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares ssDocumentos0506 ssDocumentos0506 ssDocumentos0506


Carregar ppt "ENGENHARIA DE REQUISITOS Análise e Modelação de Sistemas 2006."

Apresentações semelhantes


Anúncios Google