Take a look at the new version of this page: [ beta version ]. Tell us what you think.

ABSTRACT

Requirements is too often seen as a "stenographer's task", one where the requirements engineer passively listens and records while the stakeholders state their needs. However, this approach relies on stakeholders knowing what they need, and what they want. Experience tells us that except for rare visionaries, people do not know what they want until they see it. Many of the useful products that we take for granted today, did not come about from the stakeholders' imagination, but from an invention. In this tutorial we explain and illustrate how to use creative techniques to invent requirements that result in more useful, usable and competitive products. We provide a guide for invention, and show participants how to use this guide to invent innovative requirements for a familiar system.

REFERENCES

• 1: Daupert, D. (2002) The Osborn-Parnes Creative Problem Solving manual. Available from www.ideastream.com/create.
• 2: Floyd, C., Mehl, W.-M., Reisin, F.-M., Schmidt, G., & Wolf, G. (1989). Out of Scandinavia: Alternative Approaches to Software Design and System Development. Human-Computer Interaction, 4(4), 253--350.
• 3: Isaksen, G. & Dorval, K. (1993) Changing views of creative problem solving: Over 40 years of continuous improvement. ICN Newsletter. 3 (1).
• 4: Neil Maiden , Sharon Manning , Suzanne Robertson , John Greenwood, Integrating creativity workshops into structured requirements processes, Proceedings of the 2004 conference on Designing interactive systems: processes, practices, methods, and techniques, August 01-04, 2004, Cambridge, MA, USA [doi>10.1145/1013115.1013132]
• 5: Neil Maiden , Suzanne Robertson, Developing use cases and scenarios in the requirements process, Proceedings of the 27th international conference on Software engineering, p.561-570, May 15-21, 2005, St. Louis, MO, USA [doi>10.1145/1062455.1062555]
• 6: Neil Maiden , Alexis Gizikis , Suzanne Robertson, Provoking Creativity: Imagine What Your Requirements Could Be Like, IEEE Software, v.21 n.5, p.68-75, September 2004 [doi>10.1109/MS.2004.1331305]
• 7: Mich L., Anesi C & Berry D.M., 2004, 'Requirements Engineering and Creativity: An Innovative Approach Based on a Model of the Pragmatics of Communication', Proceedings REFSQQ'2004 Workshop, Riga 2004.
• 8: L. Nguyen , J. Carroll , P. A. Swatman, Supporting and Monitoring the Creativity of IS Personnel during the Requirements Engineering Process, Proceedings of the 33rd Hawaii International Conference on System Sciences-Volume 7, p.7008, January 04-07, 2000
• 9: Obsorn A.F., 1953, 'Applied Imagination: Principles and Procedures of Creative Problem Solving', Charles Scribener's Sons, New York.
• 10: Pennell L. & Maiden N.A.M., 2003, 'Creating Requirements - Techniques and Experiences in the Policing Domain', Proceedings REFSQ'2003 Workshop, June 2003, Velden Austria.
• 11: James Robertson, Eureka! Why Analysts Should Invent Requirements, IEEE Software, v.19 n.4, p.20-22, July 2002 [doi>10.1109/MS.2002.1020281]

INDEX TERMS

Primary Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.1 Requirements/Specifications
          Subjects: Elicitation methods (e.g., rapid prototyping, interviews, JAD)

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.1 Requirements/Specifications
          Subjects: Methodologies (e.g., object-oriented, structured)

General Terms:
Design, Human Factors

Keywords:
creativity, requirements, use cases