1 / 19

Vrije Universiteit Faculty of Sciences Department of Computer Science

Sources of Requirements Change. A Goal and Viewpoints-driven Explanation. Johan F. Hoorn. Vrije Universiteit Faculty of Sciences Department of Computer Science Section Information Management & Software Engineering Sub section Human Computer Interaction, Multimedia & Culture. Contents.

rossa
Download Presentation

Vrije Universiteit Faculty of Sciences Department of Computer Science

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. Sources of Requirements Change. A Goal and Viewpoints-driven Explanation Johan F. Hoorn Vrije Universiteit Faculty of Sciences Department of Computer Science Section Information Management & Software Engineering Sub section Human Computer Interaction, Multimedia & Culture

  2. Contents • Status • Problem: Requirements change • The requirements-analysis rift • The goals-to-requirements chiasm • Stakeholder logistics • Conclusions/Discussion • Questions M M I 9 9 0 0 9 Johan F. Hoorn, 2005

  3. Status • Postdoc project: 2001-Aug 2005 • Supervisors:Gerrit van der Veer and Hans van Vliet • Six international publications, three pending • Mens-Machine Interactie • Supervising committee Johan F. Hoorn, 2005

  4. Status (2) • Industries involved Johan F. Hoorn, 2005

  5. Problem • Requirements change Software development-track Change requirements Requirements negotiation System design Requirements elicitation System specification Software implementation $ $$ $$$ $$$$ $$$$$$$$$$$ The later a change occurs, the more costs are involved in redesign Johan F. Hoorn, 2005

  6. The requirements-analysis rift • Stakeholders regard requirements as something of the business • Stakeholders regard goals to achieve with the system as something personal • They fail to see the connection - it’s a viewpoints problem Focus switch Requirements: Business view Goals: Personal view Focus switch Johan F. Hoorn, 2005

  7. How do we know? • Capacity Management System • Police Academy students (novice users) • Scored agreement to requirements and goals from business or personal viewpoint Johan F. Hoorn, 2005

  8. F(1,30)= 10.19, p= .003, ηp2= .25. Parameter coefficient= .91, t= 3.19, p< .004

  9. The goals-to-requirements chiasm • Requirements that the system MUST have change due to situations stake- holders want to AVOID • Requirements that the system WON’T have change due to situations stake- holders want to ACHIEVE Johan F. Hoorn, 2005

  10. How do we know? • Capacity Management System (police officers) • Logistic Warehouse Management System (managers) • Commercial Off-the-Shelf Computers (interaction designers) • Braille Mouse (blind pupils) Johan F. Hoorn, 2005

  11. Type of questions must/won’t support/obstruct goal approach/avoid E-mail ordering increases efficiency E-mail ordering decreases efficiency E-mail ordering increases inefficiency E-mail ordering decreases inefficiency Paper ordering forms increase efficiency Paper ordering forms decrease efficiency Paper ordering forms increase inefficiency Paper ordering forms decrease inefficiency Example items Johan F. Hoorn, 2005

  12. Four replications R2adj= .90, F(5,12)= 30.30, p= .000 R2adj= .70, F(5,12)= 9.01, p= .001 R2change= .16, F(2,11)= 11.88, p= .002 COTS R2adj= .31, F(1,13)= 7.30, p= .018 R2adj= .23, F(1,13)= 5.18, p= .040 R2adj= .65, F(5,8)= 5.84, p= .015 R2adj= .73, F(2,11)= 18.28, p= .000 Johan F. Hoorn, 2005

  13. What if the rift co-occurs with the chiasm? Johan F. Hoorn, 2005

  14. Problem revisited • Requirements change Software development-track Change requests Software implementation System design System use $$$$ $$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$ The later a change occurs, the more costs are involved in redesign Johan F. Hoorn, 2005

  15. Stakeholder logistics Performance Effectiveness = .25 R2= .34, F(1,925)= 236.58, p= .000 Efficiency = .35 Usability Satisfaction 16% R2= .16, F(1,926)= 181.85, p= .000 Effort - Survey among 1943 employees - 25 different banking systems Johan F. Hoorn, 2005

  16. Conclusions/Discussion (1) • Beware of the requirements-analysis rift • (changes in viewpoints) - You ask for their goals - You specify requirements to serve these goals - You go back to the work floor - They agree more or less to what you propose - And then while using the system they start complaining that it does not serve them well Johan F. Hoorn, 2005

  17. Conclusions/Discussion (2) • Beware of the goals-to-requirements chiasm • (changes come from crossed relations) • Ask them: • What are the things you want to achieve with the system? • What should the system NOT have to support that? • What are the things you want to avoid with the • system? • What should be ON the system to support that? Johan F. Hoorn, 2005

  18. Conclusions/Discussion (3) • Look at lower-level personal goals • (changes do not come from source concerns) • In most of our studies, personal goals at work were • related to • Effectiveness (e.g., getting targets, less costs, help colleagues) • Efficiency (e.g., being fast and accurate, better planning) • Effort (e.g., less work load, comprehensibility) Johan F. Hoorn, 2005

  19. Requirements change Questions? M M I 9 9 0 0 9 Johan F. Hoorn, 2005

More Related