Download presentation
Presentation is loading. Please wait.
Published byRosa Cummings Modified over 10 years ago
2
1 Vrije Universiteit Faculty of Sciences Department of Computer Science Section Information Management & Software Engineering Subsection Human Computer Interaction, Multimedia & Culture Johan F. Hoorn and Evelien Kok Goals are personal, requirements business – the requirements analysis twist
3
2 Contents Status Problem Goal Theory Model Field study Results Discussion Questions M M I 9 9 0 0 9 Johan F. Hoorn, 2005
4
3 Status Postdoc project: 2001-Aug 2005 Supervisors: Gerrit van der Veer and Hans van Vliet Four international publications, three pending Industries involved Mens-Machine Interactie Johan F. Hoorn, 2005
5
4 Problem Requirements change through business model change Johan F. Hoorn, 2005 Example: goes from non-profit to commercially oriented organization
6
5 Non-profit? Serves society Not self supporting Commercial? Serves own good Makes money Business model Politics demands change Work process slow Work process must be fast Supporting IT can leave much to the user Supporting IT leaves little to the user (control!) Johan F. Hoorn, 2005
7
6 Non-profitCommercial Business model Supporting IT can leave much to the user Supporting IT leaves little to the user (control!) Capacity Management System (CMS) -Action planning -Shifts (day, night, special) -Holidays http://www.brilmanbouw.nl/images/verbouwing-planbord2.JPG Johan F. Hoorn, 2005
8
7 Goal Pinpoint the factors that lead to a change request so to anticipate them during system design Johan F. Hoorn, 2005
9
8 Client Sources of conflict, regarding goals Business goalsPersonal goals Requirements change Stakeholders ManagementWorkfloor egotistic vs. altruistic egotistic vs. altruistic vs. Event Theory Johan F. Hoorn, 2005
10
9 Agreed requirements Relevance unexplained change ProfitQualityCareerLoyalty egotistic altruistic business personal Goals Adapted from Hoorn & Van der Veer, 2003a; 2003b Hypothesis: Changes in the relevance of goals, goal orientation (ego vs. altru), and business or personal view, change the agreement to the requirements Model Johan F. Hoorn, 2005
11
10 Field study Ethnography, task analysis by Evelien, who works at Concern Information Management Police - Goals (business and personal in the flavors egotistic and altruistic), categorized for relevance (relevant vs. irrelevant) - Requirements on the CMS (must and won’t) Johan F. Hoorn, 2005
12
11 Four groups of police officers (novice CMS users) rated agreement to goals and requirements, each from a different point of view: Group 1 – Business egotistic goals Group 2 – Business altruistic goals Group 3 – Personal egotistic goals Group 4 – Personal altruistic goals Johan F. Hoorn, 2005
13
12 Example items: BE Relevant scale (#items= 12) I find it important that my corps spends more money on allocating personnel completely disagree disagree agree agree completely disagree a little a little agree 0 -------------- 1 -------------- 2 -------------- 3 -------------- 4--------------5 Schedules are definite 48 hours in advance Requirements Must scale (#items= 12) completely disagree disagree agree agree completely disagree a little a little agree 0 -------------- 1 -------------- 2 -------------- 3 -------------- 4--------------5 Johan F. Hoorn, 2005
14
13 Scale reliabilities Questionnaire versionPEPABEBA Cronbach’s (#) (#) (#) (#) Relevant scale.71 (2).86 (3).84 (4).83 (3) Irrelevant scale.83 (3).78 (2).77 (2).77 (3) Requirements Must.98 (3).67 (2).74 (2).67 (2) Requirements Won’t.86 (3).81 (4).78 (3).80 (2) N=33n=8n=8n=9n=8 Results Johan F. Hoorn, 2005
15
14 F (1,30) = 10.19, p=.003, η p 2 =.25. Parameter coefficient=.91, t= 3.19, p<.004 Egotistic vs. altruistic is insignificant!
16
15 Discussion (1) When stakeholders expressed their agreement to the goals to achieve with the system, they did this from a personal point of view However, the focus switched to the point of view of the business when it came to expressing agreement to the system’s requirements that were gathered to serve these goals Johan F. Hoorn, 2005
17
16 Tricky bit in requirements engineering and task analysis: - You ask for their goals - You specify requirements to serve these goals - You go back to the workfloor - 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 Discussion (2) Johan F. Hoorn, 2005 Requirements change!
18
17 Questions? Johan F. Hoorn, 2005
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.