1. Eliciting Stakeholders’ Knowledge of Goals and Processes to derive IT Support Stewart Green The University of the West of England

2. 17th June, 2003REBPS '032 Presentation Structure Problems Deriving requirements from goals and processes Four knowledge elicitation techniques Summary

3. 17th June, 2003REBPS '033 Problems What is the most effective way of using business goals and processes to derive requirements for computer-based systems (CBSs) that will support the processes and thus meet the goals? How can we elicit from business experts their knowledge of processes and goals needed to derive CBS requirements?

4. 17th June, 2003REBPS '034 Deriving Requirements: Principles In order to improve some part of a business, that part must first be understood and conceptualised “A system which serves another cannot be defined and modelled until a definition and model of the served system are available” (Winter, Brown and Check land, EJIS, 4, 95,136-142)

5. 17th June, 2003REBPS '035 Deriving Requirements: Overview Diagram Conceptualise the current served system in terms of goals, processes and logical structure Conceptualise the new served system in terms of goal, processes and logical structure Derive requirements for new serving system CBSs DERIVE REQUIREMENTS FOR NEW SERVING SYSTEM CBSsCONCEPTUALISE CURRENT SERVED SYSTEM Requirements for new serving system CBSs Conceptualisation of new served system Conceptualisation of current served system

6. 17th June, 2003REBPS '036 Deriving Requirements: Justification for Characterisation Goals Goals define the purpose of a business system; its most fundamental feature. Processes Process define the mechanisms through which goals are achieved. Logical structure Logical structure defines the organisational structure in which the processes are enacted in terms of organisational subsystems and roles.

7. 17th June, 2003REBPS '037 Knowledge Elicitation: Four Techniques Questionnaire (explicit knowledge) Interview (explicit knowledge) Contextual Design (implicit knowledge) Self-observation and measurement (new knowledge).

8. 17th June, 2003REBPS '038 Knowledge Elicitation: Questionnaire Generic Client Questionnaire e-mailed to client Questions elicit client’s view of business area Goals Processes Problems Suggested Improvements Logical structure Client Questionnaire may be reused on new projects A completed questionnaire should be tabulated and re-expressed in a number of different diagrams The tables and diagrams should be validated by the client

9. 17th June, 2003REBPS '039 Knowledge Elicitation: Case Study Questionnaire Client returned the questionnaire within one week Tabulating and diagramming the questionnaire data took 3 hours Validating the tables and diagrams with the client took 2 hours Utility: This proved to be a fast and effective way of obtaining a detailed characterisation of the client’s perspective of the current served system And thus for narrowing down the project to one or two problem areas (focused served system) BUT the client was very motivated and bright (degree-level education)

10. 17th June, 2003REBPS '0310 Knowledge Elicitation: Interview Subsystem Owner Questionnaire Generic reusable part Non-reusable part based on focused served system Open and closed questions Questions intended to elicit subsystem owner's view of: Subsystem goals Focused served system (processes, structure, problems, etc.) Many of the interview questions would need to be created for each new project Interview data should be written up, tabulated, diagrammed and validated Subsystem owner’s goals should be cross-referenced with client's goals

11. 17th June, 2003REBPS '0311 Knowledge Elicitation: Case Study Interviews Time to create customised focused served system questions: 2 hours Time to interview: 1 hour/stakeholder Time to write up interview: 1 hour/stakeholder Time to tabulate and diagram interview data: 0.5 hours/ stakeholder Time to validate tables and diagrams: 0.25 hours/stakeholder Utility: Interviews proved to be an effective way of eliciting subsystem owner’s goals and processes, e.g. the current user problem management process The open questions were particularly useful for eliciting ideas for improving the focused served system

12. 17th June, 2003REBPS '0312 Knowledge Elicitation: Contextual Design Observe stakeholder performing served system work Note down time each action is performed Ask question to clarify nature of work and to elicit full range of work Write up observation session notes Analyse session transcript Current processes Possible, feasible, and desirable process changes Implications for requirements for computer-based systems

13. 17th June, 2003REBPS '0313 Knowledge Elicitation: Case Study Contextual Design Time for observation session: 2 hours/ stakeholder Time to write up session: 1 hour/ stakeholder Time to analyse session: 0.5 hours/ stakeholder

14. 17th June, 2003REBPS '0314 Knowledge Elicitation: Case Study Contextual Design Utility: Observation enables the RE to ascertain the processes actually being performed Stake holders’ answers to questions help the RE to ascertain the feasibility of possible changes For example, I asked a Helpdesk stakeholder how feasible it would be for her to type in details of user problems if a computer-based problem management system were used on the helpdesk She replied that she would find typing in a lot of details to be too time-consuming. Later she indicated that pressing one or two keys per interaction might be acceptable. Later still that typing in a user’s id might be feasible.

15. 17th June, 2003REBPS '0315 Knowledge Elicitation: Self- measurement Stakeholders collect quantitative data over a given period of time about some focused served system phenomenon of interest The RE collects this quantitative data, tabulates and summarises it The RE analyses the quantitative data for information that may inform requirements for computer-based systems

16. 17th June, 2003REBPS '0316 Knowledge Elicitation; Case Study Self-measurement Stakeholders collected information about user problems that arrived on their desk, e.g.: Category of user-problem Source of each user problem What happened to each user problem Data was collected by stakeholders by adding strokes to a pre-printed form RE tabulated and summarised data: 4 hours RE drew requirements conclusions

17. 17th June, 2003REBPS '0317 Knowledge Elicitation: Case Study Self-measurement Utility: The RE obtained knowledge of the order of number of long-term user problems arriving at various sites in the Help Desk in a given unit of time. This information was used to inform storage space requirements. It could have informed the degree of criticality assigned to the project.

18. Costs and Benefits TechniqueCostUtility Client Questionnaire Develop 3.00 h Administer 5.00 h Detailed characterisation of broad served system. Identifies focused served system. Stakeholder Interview Develop 2.00 h Administer 2.75 h/s Alignment to client goals Detailed characterisation of focused served system Good at improvement identification Stakeholder observation Administer 3.50 h/s Validate current processes Assess feasibility of change Measure phenomenon Administer 4.00 h Obtain quantified characterisation of key served system phenomena

19. 17th June, 2003REBPS '0319 Summary and Conclusions Goal-oriented approach to deriving requirements for CBSs Four techniques for eliciting business experts’ knowledge of goals and processes Client Questionnaire most cost-effective