Helping students learn requirements engineering

Many software engineering courses (and methods) begin with an assumption that software requirements are presented to software engineers in a complete, consistent, feasible, testable, and traceable form, and that the software engineer´s main job is to correctly transform the requirements into code. This is generally an unhealthy approach, as the requirements for virtually all significant software products are to some degrees unknown, unknowable, or the results of compromises requiring the software engineer´s participation and expertise. In USC´s first semester MS level software engineering core course, we have been experimenting with case study and role playing approaches to learning about software requirements engineering. The role playing approach involves a Theory W (win win) interpretation of software requirements as negotiated stakeholder win conditions. Students form three person teams to role play as the users, customers, and developers of a software application system (e.g., a library information system or an urban fire dispatching system). They use an experimental groupware requirements engineering support system called WinWin being developed at USC. The article summarizes our experiences in using the approach to date