Priorização e Negociação de Requisitos

Apresentação em tema: "Priorização e Negociação de Requisitos"— Transcrição da apresentação:

1 Priorização e Negociação de Requisitos
Equipe: David Cardoso Marconi Madruga Roberta Arcoverde Shirley Silva

2 Roteiro Motivação Definições Introdução Contexto de ER Priorização
Abordagens Negociação Ferramenta Discussão e Conclusão Referências

3 Motivação A prioridade dos requisitos é baseada em muitos fatores. A importância do requisito para o usuário é uma delas, mas não deve ser o único. Há uma dificuldade muito grande em definir quais fatores devem ser levados em conta. BASEADO NO QUADRO Q EU COLOQUEI NO MEU RESUMO!!!

4 Motivação

5 Priorização de Requisitos Definições
Although it is essential that people have a common understanding about the terms they use and activities they perform in product development, the terms “requirements prioritization” and “priority” have several different meanings in practice. This causes confusion and misunderstandings among product development personnel. The terms are not uniformly defined in organizations, so in spoken language different activities with different purposes are referred to by the same terms. This happens without the awareness of the practitioners.

6 Definições “Requirements prioritization is an ambiguous concept”
Requirements Prioritization Challenges in Practice Laura Lehtola, Marjo Kauppinen, and Sari Kujala

7 Definições “How do we decide which requirements are the most important ones for the company in the long run?” “How do we decide, which requirements we have to implement right away in the next product release?” Priorização de requisitos é um conceito ambiguo. Na prática, o termo “priorizacao de requisitos” tem vários significados nas empresas. O termo pode ser usado com os seguintes significados: -“How do we decide which requirements are the most important ones for the company in the long run?” - “How do we decide, which requirements we have to implement right away in the next product release?” - “How do we select the requirements that will be implemented first in this project?” - ”Which of the requirements describe the system in high-level terms?” Ou seja, diferentes atividades são propostas a partir de um mesmo termo. “How do we select the requirements that will be implemented first in this project?” ”Which of the requirements describe the system in high-level terms?”

8 Introdução Priorização de requisitos é uma área bastante desafiadora.
“Despite the recent rapid and welcome growth in requirements engineering (RE) research, managers still do not have simple, effective, and industrially proven techniques for prioritizing requirements.” [Karlsson, J., Ryan, K.: A cost-value approach for prioritizing requirements.1997] Priorização de requisitos é uma importante atividade no desenvolvimento de sw. Pois o sistema precisa conter as funcionalidades essenciais e o escopo de cada release deve ser limitado. Muitos projetos se deparam com o fato de que nem todos os requisitos podem ser implementados devido a limitação do tempo ou restriçoes de recursos, por exemplo. Isto significa que deve haver uma tomada de decisão a respeito de quais requisitos vão ser implementados no release e quais os requisitos que ficarão para os próximos releases. De acordo com Wiegers, a priorizaçao é necessária tanto para identificar os requisitos mais importantes quando para auxiliar o gerente a resolver conflitos (pq??), e a planejar o release. Harwel propõe outra coisa(ver). Priorização de requisitos é reconhecidamente uma área bastante desafiadora. Karlsson atribui o fato de que as empresas não sabem como atribuir e modificar prioridades, ao recente e rápido crescimento da ER. Ou seja, os gerentes ainda não têm uma maneira simples, efetiva e industrialmente comprovada de técnicas de priorização de requisitos. Neste artigo é descrito o estado da arte das práticas atuais de priorização de requisitos na indústria, trabalhando com duas empresas. A pesquisa foi feita da seguinte forma: Foi formado um grupo com participantes das duas empresas, em que o objetivo é encontrar como e em quais fases do desenvolvimento a priorizacao de requisitos é feita. E tb encontrar quais os fatores de prioridade se baseam para tomada de decisão.

9 Introdução Muitos projetos se deparam com o fato de que nem todos os requisitos podem ser implementados devido a limitação do tempo ou restrições de recursos. “Information about priorities is needed, not just so as to be able to ignore the least important requirements but also to help the project manager to resolve conflicts, plan for staged deliveries, and make the necessary trade-offs.” [Wiegers, K.E.: Software Requirements.1999]

10 Contexto em ER

11 Contexto em ER

12 Priorização de Requisitos
Decidir o que deve ser implementado Time-to-market x Funcionalidades Para cada requisito elicitado: Quão importante é o requisito para o cliente? Quanto irá custar? Quais os riscos envolvidos na sua implementação? Todos os stakeholders devem opinar... Mas a palavra final é da alta gerência

13 Priorização de Requisitos
As abordagens de priorização de requisitos podem ser divididas em 2 grandes áreas[Lehtola 2004]: Métodos baseados em valorar diferentes fatores de requisitos Abordagens de negociação

14 Comparando Requisitos
Um problema de Sorting Comparações 2 a 2 Construção de árvore binária ...entre outros Complicações Fácil dizer que x é mais importante que y Difícil dizer quão mais importante x é de y

15 Métodos de Priorização
VOP Numeral Assignment AHP Cost-Value Approach BST Outras

16 VOP Stakeholders estabelecem:
Valores que são importantes para eles; O quão importante é cada um desses valores; A nota de cada requisito para cada valor pré-estabelecido; Prioridade é calculada através de soma ponderada NotaReqFinal = NotaReqV1 * PesoV NotaReqVN * PesoVN

17 VOP Vantagens Desvantagens Resultados claros; Simplicidade;
Velocidade; Desvantagens Difícil estabelecer pesos; Poucas informações sobre a técnica;

18 Numeral Assignment Stakeholders dão uma nota de 1 a 5 para cada requisito Os números significam: 1 – não importa (o cliente não precisa disso) 2 – não muito importante (o cliente aceitaria a sua falta) 3 – importante (o cliente gostaria disso) 4 – muito importante (o cliente não quer ficar sem isso) 5 – obrigatório (sem isso, o cliente não aceita)

19 Numeral Assignment A média de notas de cada stakeholder para cada requisito é a nota final Vantagens Simplicidade; Clareza; Desvantagens Pouca Fidelidade; Considera apenas opinião dos stakeholders

20 Analytic Hierarchy Process (AHP)
Descrição Passo a passo Exemplos Críticas

21 AHP - Descrição AHP é método de tomada de decisão em situações com múltiplos objetivos[Saaty,1980] Usada pela primeira vez no contexto de ER por [Karlsson 1996] Usa matriz de comparação 2 a 2

22 AHP – Passo a passo Criar uma matriz n x n, para n requisitos
Para cada elemento (x,y) da matriz, atribuir um valor: 1  x e y têm prioridades equivalentes 3  x é levemente mais importante que y 5  x é moderadamente mais importante que y 7  x é muito mais importante que y 9  x é extremamente mais importante que y Podem ser usados valores intermediários... Para cada elemento (y,x), usar o valor recíproco Fonte: adaptado de Easterbrook, University of Toronto

23 AHP – Passo a passo Normalizar a tabela Obter valor de cada requisito
Para cada coluna, calcular seu somatório e dividir cada elemento por este valor Obter valor de cada requisito Média aritmética de cada linha Este processo pode ser repetido para estimar o custo de cada requisito em relação aos outros 

24 AHP – Exemplos No contexto de requisitos... Passo 3

25 AHP - Exemplos Passo 4 Valor médio de cada requisito ÷ 4 = 0.26
÷ 4 = 0.50 ÷ 4 = 0.09 ÷ 4 = 0.16 Valor médio de cada requisito

26 AHP – Exemplos Ranking obtido:
Req 1 contém 26% do valor total dos requisitos; Req 2 contém 50% do valor total dos requisitos; Req 3 contém 9% do valor total dos requisitos; Req 4 contém 16% do valor total dos requisitos; Desta forma, a prioridade de cada requisito fica assim estabelecida: Req 2 > Req 1 > Req 4 > Req 3

27 AHP – Consistency Ratio
Usada para assegurar a consistência dos resultados RI depende do número de requisitos CI depende da matriz de comparação e dos resultados O ratio ideal é < 0.10

28 AHP - Exemplos http://www.cci-icc.gc.ca/tools/ahp/index_e.asp
Site que constrói a matriz AHP, e calcula índice de consistência Exemplo de utilização de AHP em contexto diferente de ER (no caso, utilizando AHP para escolher entre ofertas de emprego)

29 AHP - Críticas Apesar de consolidada na literatura, AHP não é ainda muito utilizada Excesso de formalismo Dificuldade de compreensão Resultados ‘místicos’ (visualização difícil) Argumentar sobre os resultados é difícil – diferentemente de técnicas mais simples, como VOP

30 Abordagem Custo-Valor (Cost-Value)
Abordagem que utiliza o AHP Para calcular a importância do requisito: Avaliar a importância do requisito para o projeto Avaliar o custo da implementação Fonte: adaptado de Karlsson & Ryan, 1997

31 Abordagem Custo-Valor (Cost-Value)
Passo-a-passo 1. Revisão completa dos requisitos para eliminar ambigüidades e assegurar completude 2. Aplicação de AHP para avaliar o valor relativo dos requisitos por stakeholders 3. Aplicação de AHP para estimar o custo relativo da implementação de cada requisito por especialistas em ES 4. Valores são inseridos em um diagrama de custo-valor por um especialista 5. Stakeholders usam o diagrama como um mapa conceitual para discutir os requisitos

32 Abordagem Custo-Valor (Cost-Value)
Por ter base matemática, tem resultados mais concretos Pode ser usada como complemento do WinWin [Karlsson, 97]

33 BST (Binary Search Tree)
Algoritmo de ordenação básico Utiliza comparações 2 a 2

34 BST (Binary Search Tree)
Armazenamento de relatórios em arquivos .pdf Visualização de Balanço Mensal Impressão de Relatórios [RF 01] Gerenciamento de Clientes [RF 02] Armazenamento de relatórios em arquivos .pdf [RF 04] Visualização de Balanço Mensal [RF 03] Impressão de Relatórios

35 Outras Abordagens Planning Game 100-Point Method
O mesmo que Numeral Assignment, mas baseado em estórias 3 grupos: “aqueles sem os quais o sistema não funciona”, “aqueles que são menos essenciais mas que acrescentam valor de negócio” e “aqueles que seria legal ter” 100-Point Method Cada stakeholder tem 100 pontos e pode distribui-los entre os requisitos da forma que quiser Nota do requisito é a soma dos pontos 100 points -> só funciona 1 vez, se votar 2 vezes as pessoas tendem a mudar sua pontuação para fazer seus favoritos subirem

36 Negociação de Requisitos
The process of resolving conflicts among software quality requirements is complex and difficult because of incompatibilities among stakeholders’ interests and priorities, complex cost-quality requirements dependencies, and an exponentially increasing resolution option space for larger systems.

37 Theory W Make Everyone a Winner;
“Theory W characterizes a manager’s primary role as a negotiator between his various constituencies, and a packager of project solutions with win conditions for all parties. Beyond this, the manager is also a goal-setter, a monitor of progress towards goals, and an activist in seeking out day-to-day win-lose or lose-lose project conflicts, confronting them, and changing them into win-win situations.” Boehm, B. : shows how it would apply in avoiding the software project management problems encountered in a case study analyzed by the other author (Ross). Theory W’s fundamental principle is well-matched to the problems of software project management. It holds that software project managers will be fully successful if and only if they make winners of all the other participants in the software process: superiors, subordinates, customers, users, maintainers, etc. This principle is particularly relevant in the software field, which is a highly people-intensive area whose products are largely services or decision aids, and whose performers are often unfamiliar with user and management concerns. However, Theory W can be applied to other fields as well.

38 Win Win “The big Challenge is to determine the relationships among the various views and reconcile them.” The WinWin Requirements Negotiation System: a Model-Driven Approach (1996)   Mingjune Lee, Barry Boehm

39 Win Win :: Visão Geral

40 Win Win :: Negotiation Model
boehm_in_1999_sqp.pdf boehm95software.pdf Fonte: Boehm, B. :

41 Win Win :: Negotiation Model

42 Win Win :: Spiral Model Fonte: Boehm, B. :

43 Win Win :: Operações Fonte: Boehm, B. :

44 Win Win :: EasyWinWin Metodologia que usa ferramentas colaborativas

45 Win Win :: EasyWinWin Define um conjunto de atividades para guiar os stakeholders por um processo de: Reunir Requisitos Elaborar Requisitos Priorizar Requisitos Negociar Requisitos Utiliza técnicas de grupo que são providas por ferramentas colaborativas (brainstorming eletrônico, polling, etc.)

46 Win Win :: Conclusão “Usage experience also indicates that WinWin is not a panacea for all conflict situations, but generally increases stakeholders’ levels of cooperation and trust” Boehm, B.

47 Win Win :: Conclusão Capturar desejos dos stakeholders (win conditions) Expressar desentendimentos e aspectos que necessitem de resolução Oferecer opções como soluções potenciais Negociar acordos que resolvem conflitos Documentação Traçar as maneiras pelas quais as decisões foram tomadas Checar a completude e consistência dos requisitos horowitz99win.pdf

48 Ferramenta (Expert Choice)

49 Ferramenta(Expert Choice)
Ferramenta que abstrai bastante o problema de resultados complexos do AHP Fácil de usar Utiliza conceitos de objetivos e sub-objetivos Fornece alternativas para estabelecimento de pesos (Forma gráfica, textual ou numérica)

50 Discussão e Conclusão Numeral Assignment Theory-W AHP
Passo-a-passo claro 3 2 Medição Quantitativa 1 Maturidade Menor esforço Curva de Aprendizado Pontuação Total 12 8 16 clear-cut steps: There is clear definition between stages within the prioritization method for progress and implementation. quantitative measurement: The prioritization method's numerical output clearly displays the clients' priorities for all requirements. high maturity: The method has experienced considerable exposure and analysis in its vetting by the requirements engineering community. low labor-intensity: A reasonable number of hours are needed to properly execute the prioritization method. shallow learning curve: The requirements engineers and stakeholders can fully comprehend the method within a reasonable length of time.

51 Discussão e Conclusão Técnicas são adequadas a situações específicas
Nenhuma técnica é uma silver bullet Difícil comparar abordagens, pois não há estudos comparativos suficientes e por abordagens estarem em diferentes níveis de abstrações Lehtola propõe um framework para comparação e classificação de técnicas de priorização

52 Discussão e Conclusão Framework para comparação de requisitos[Lehtola, Berander, Ahmed Khan] Propõe uma classificação das técnicas segundo 3 variáveis: Variáveis Independentes (Objetivos da técnica, nível hierárquico, formato de entradas e saídas, ...) Variáveis Dependentes (Tempo, Precisão, Facilidade de Aprendizado, ...) Variáveis de Contexto(Tipo de mercado, Papel dos Envolvidos na empresa, ...)

53 Referências Karlsson, J. and Ryan, K. (1997) “A Cost-Value Approach for Prioritizing Requirements” Wiegers, K. (1999) “Software Requirements” EasyWinWin: Lehtola, Berander, Khan. “Towards a Research Framework on Requirements Prioritization” Azar, (2007) “Value-Oriented Requirements Prioritization in a Small Development Organization” Ramires (2004) “Negociação de Requisitos no Processo de Desenvolvimento de Software” AHP e outras técnicas: