© Colin Potts C2-1 Goal-oriented approaches Colin Potts Georgia Tech

© Colin Potts C2-2 Goals & requirements l Systems exist to meet goals or objectives »Goals are not requirements –may be ambiguous and inconsistent –not absolute (some take priority) –idealized rather than implementable –not allocated to product »Goals are not business processes –processes are implementations of goals

© Colin Potts C2-3 Example of goal properties SATISFY patron’s info. requests MAINTAIN library budget MAKE books available to public inconsistent idealized high priority none allocated to Library IS

© Colin Potts C2-4 Goals, requirements and fitness for use Goals Sys reqts. that meet goals reqts. that don’t quite meet goals

© Colin Potts C2-5 Pre-requirements traceability l Pre-reqts. traceability shows where reqt. traces from thus, goals provide rationale for reqts. 1.1 The system shall blah, blah If the co-worker is blah, blah, the system shall inform the user Reqts. MAKE blah blah MAINTAIN user awareness of blah Goals

© Colin Potts C2-6 Types of goals l Achieve some desired state of affairs »MAKE »KNOW »SATISFY l Maintain some desired state of affairs »KEEP »AVOID l Improve along some trajectory »IMPROVE, etc.

© Colin Potts C2-7 Expansion of goals MAKE meeting scheduled KNOW meeting constraints KNOW meeting participants’ preferences KNOW meeting participants’ identities KNOW all feasible times depends on

© Colin Potts C2-8 Allocation of responsibilities to system & environment MAKE meeting scheduled KNOW meeting constraints KNOW meeting participants’ preferences KNOW meeting participants’ identities KNOW all feasible times System Envt

© Colin Potts C2-9 Realization of goals as requirements KNOW meeting constraints 1. When an initiator calls a meeting, he or she will define a set of meeting constraints The meeting scheduler shall display a form into which constraints may be entered If any constraints are unspecified, the meeting scheduler shall insert default values Meeting constraints include the following: - earliest meeting time - latest meeting time - names of invited participants allocations underlined

© Colin Potts C2-10 Identifying obstacles to goals l What can go wrong to thwart a goal? »The actor responsible for MAKE goals may fail –mechanical failure or human error »The infrastructure responsible for KNOW goals may garble or misremember relevant information –communications errors –human error (forgetting, confusion) »A SATISFY goal may be intrinsically unsatisfiable –resource contention l Is it worth worrying about? »If so, add secondary requirements to defend against it or mitigate its effects

© Colin Potts C2-11 Retracting idealized assumptions l Idealized goal & refinement l Realistic goal KNOW schedule preferences KNOW schedule preferences data entry requirements data entry requirements data modification requirements change notification reqts.

© Colin Potts C2-12 Team exercise: Goal refinement l As a class »Define some high-level goals for the system described in the example requirements »Expand them into more detailed goals »Choose one intermediate-level goal l In teams of 2-3 »Identify obstacles that could thwart that goal »Write a set of primary and secondary reqts. for the goal l As a class »Discuss insights achieved about the system

© Colin Potts C2-13 Methods for goal-oriented requirements definition l Make process concrete »Define, expand, realize and “de-idealize” goals by considering concrete scenarios l Use goals as a benchmark of consensus »If people can’t agree on goals, they won’t agree on product features –Modified JAD or CRC meetings useful

© Colin Potts C2-14 Goal-oriented approaches: how to find out more l Goal-oriented methods are just emerging from the research community »No textbooks or handbooks »Experience in telephony, electronic commerce, software reuse, BPR »Several recent action-research papers from GA Tech & Univ. Namur (Belgium)