Measuring Alignment of Stakeholder Goals and Requirements Karl Cox Karl.Cox@nicta.au

1. Measuring Alignment of Stakeholder Goals and RequirementsKarl CoxKarl.Cox@nicta.com.au

2. Agenda • The problem context • Some questions • Group brainstorming • Feedback • Where to go from here? *This is an open session for discussion - it is entirely exploratory.

3. The Problem Context Enterprise IT used for strategic purposes has a number of characteristics: • Multiple levels of stakeholders • Mid-management, Executive, End Users, Consumers, Customers (e.g. Franchisees), External Collaborative organizations (e.g. suppliers, logistics) • Depth of requirements analysis • Market space, competitor analysis, inter-organizational, intra-organizational: objectives, strategies, business processes, business models • Importance of Requirements Analysis • Getting the low-level requirements wrong can mean strategic failure, and this can cost a company millions, and even shut it down. • No absolute or provably correct answers for the requirements.

4. What, why and how - stakeholder viewpoints RA is DA’s what and why RB is DA’s how RB is DB’s what, RA is BD’s why RC is DB’s how RC is DC’s what, RB and RA are DC’s why… Adapted from Jackson, M. 2001, Problem Frames, Addison Wesley

6. Scale of the real problem • Real problems cross many organizational and social boundaries* • Real problems are multi-dimensional • Real industry problems involve large numbers of people for this kind of problem • And they all have their own interests to protect! • It is unlikely that viewpoint analysis will be sufficient • GQM will unlikely scale in its current format… and may not be applicable to this problem. • *S. Bleistein, K. Cox and J. Verner (2005), "Validating Strategic Alignment of Organisational IT Requirements using Goal Modelling and Problem Diagrams", Journal of Systems and Software (now available from JSS Articles in Press online).

7. What is already out there • Goal modelling in Requirements Engineering proposes pointlessly formal mathematics • to conduct simple trade off analysis • to reason about which goal is needed • Prioritization of requirements • Lots of approaches, all mostly a, b, c; 1, 2, 3; must have, should have, could have … lists. • Lack rationale for why • Not much measurement involved in this • Inter-rater reliability • Would this cope with such a complex problem? • Easy WinWin • This is about negotiation and only on one level (as far as I am aware) • Could it be applied to our problem?

8. Questions • How do we know when we are achieving consensus among stakeholders? • How do we know what consensus means? • How do we measure consensus among stakeholders at different levels in the problem? • What measurement tools exist already that might be applicable to this problem? • How do we trial such approaches empirically? • How do we validate our measurement choices? • Is measurement enough? What else do we need to think about?

9. Brainstorming • Divide into groups and discuss! • Make notes, please. • Then we will gather together and get some feedback.

10. Where do we go from here? • Worth pursuing at next ISERN or elsewhere? • How to continue this research? • How do we make this measurement problem relevant? • By relevant, I mean to industry (not just academia)

11. Thank you!