1 / 14

Change Requirements: An Explanation of What Stakeholders Try to Avoid

Change Requirements: An Explanation of What Stakeholders Try to Avoid and What They Try to Achieve . Johan F. Hoorn , Elly A. Konijn, H. van Vliet, & G. vd Veer Vrije Universiteit Computer Science Information Management and Software Engineering jfhoorn@cs.vu.nl. Contents. Problem

hedda
Download Presentation

Change Requirements: An Explanation of What Stakeholders Try to Avoid

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. Change Requirements: An Explanation of What Stakeholders Try to Avoid and What They Try to Achieve Johan F. Hoorn, Elly A. Konijn, H. van Vliet, & G. vd Veer Vrije Universiteit Computer Science Information Management and Software Engineering jfhoorn@cs.vu.nl

  2. Contents • Problem • Analysis • Model • Method • Case • Results • Conclusions M M I 9 9 0 0 9 Johan F. Hoorn, 2005

  3. Problem • How can requirements change be anticipated? Johan F. Hoorn, 2005

  4. Analysis • Where do change requests come from? Business model 1 Business model 2 • Change in business sub goals - Main goals: Profit - Sub goals: Cost-effectiveness, efficiency • How come business goals change? • Change in sub goals (strategic management) - Main goals: Earn my living - Sub goals: Fire employees (not me), improve IT to guarantee same output Johan F. Hoorn, 2005

  5. Model • Change of Stakeholder Requirements (CoStaR) (Hoorn & Van der Veer, 2003a; 2003b) One of the hypotheses: Valence Requirements Goals Stakeholder evaluation: Does a system feature support my goals? Does a system feature obstruct my goals? (after Frijda, 1986) Johan F. Hoorn, 2005

  6. Method • REquest, the Requirements Engineering questionnaire General approach: Items that combine - a must or a won’t requirement, with - support or obstruction of - a goal to achieve with the system or a goal state to avoid, scored for agreement on a 6-point rating scale Johan F. Hoorn, 2005

  7. Case • Eighteen managers of a logistic warehouse management system 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

  8. Results (1) • Original hypothesis: Valence Requirements Goals - Indeed, goals, valence, and requirements all evoked significant effects on agreement to requirements statements Johan F. Hoorn, 2005

  9. Results (2) ↑ Grand mean agreement  5 4 3.67 (1.14) 2.78 3 2.5 2.41 (1.04) 2.19 (.96) 1.8 (.98) 2 (1.44) (1.09) 1 0 Goals (to Goals (to Requirements Requirements Valence Valence approach) avoid) (must have) (won't have) (support) (obstruct) MANOVA (must vs won’t) * (support vs obstruct) * (goal approach vs avoid) Pillai’s Trace = .51, F(2,16)= 8.40, p= .003, ηp2= .51 Johan F. Hoorn, 2005

  10. - Goal-driven RE models should be unipolar Goals (approach) Requirements (must have) Valence (support) Valence (obstruct) Goals (avoid) Requirements (won’t have) Results (3) • Original hypothesis: Valence Requirements Goals • Bipolar conception does not hold • Regression: R2= .03, R2adj= -.03, F(1,16)= .47, p= .504 Johan F. Hoorn, 2005

  11. Results (4) • However, original structure should be completely revised Goals Requirements (to approach) (won’t have) Valence (support) Valence (obstruct) Requirements Goals (must have) (to avoid) Johan F. Hoorn, 2005

  12. no predictive power Yet, valence does have influence. Requirements vs. goals: Parameter coefficient= -.56, t= -4.04, p= .001, ηp2= .49 no predictive power 70%!! 90%!! Results (5) R2= .79, R2adj= .70 F(5,12)= 9.01, p= .001 Goals (approach) Requirements (won’t have) Valence (support) Valence is a moderator! Valence (support) Goals (avoid) Requirements (must have) R2= .93, R2adj= .90 F(5,12)= 30.30, p= .000 Johan F. Hoorn, 2005

  13. Conclusions (1) • RE should be oriented to goals • Requirements validation should be done • with structured questionnaires • (e.g., REquest) • Goals to achieve predict won’t requirements • Goal states to avoid predict must requirems • Like the weather, valence does not predict • mood (i.e. agreement) but it does influence it Johan F. Hoorn, 2005

  14. Conclusions (2) • Most important RE questions are: • 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

More Related