1 / 19

Eliciting Stakeholders’ Knowledge of Goals and Processes to derive IT Support

Eliciting Stakeholders’ Knowledge of Goals and Processes to derive IT Support. Stewart Green The University of the West of England. Presentation Structure. Problems Deriving requirements from goals and processes Four knowledge elicitation techniques Summary. Problems.

tawana
Download Presentation

Eliciting Stakeholders’ Knowledge of Goals and Processes to derive IT Support

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Presentation Structure • Problems • Deriving requirements from goals and processes • Four knowledge elicitation techniques • Summary REBPS '03

  3. 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? REBPS '03

  4. 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) REBPS '03

  5. Deriving Requirements: Overview Diagram Requirements for new serving system CBSs Conceptualisation of current served system Conceptualisation of new served system 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 CONCEPTUALISE CURRENT SERVED SYSTEM DERIVE REQUIREMENTS FOR NEW SERVING SYSTEM CBSs REBPS '03

  6. 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. REBPS '03

  7. Knowledge Elicitation: Four Techniques • Questionnaire (explicit knowledge) • Interview (explicit knowledge) • Contextual Design (implicit knowledge) • Self-observation and measurement (new knowledge). REBPS '03

  8. 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 REBPS '03

  9. 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) REBPS '03

  10. 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 REBPS '03

  11. 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 REBPS '03

  12. 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 REBPS '03

  13. 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 REBPS '03

  14. 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 mightbe feasible. REBPS '03

  15. 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 REBPS '03

  16. 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 REBPS '03

  17. 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. REBPS '03

  18. Costs and Benefits

  19. 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 REBPS '03

More Related