Most IT systems fail to meet expectations. They don't meet the business goals and don't support users efficiently. Why? Because the requirements didn't address the right issues. Amazingly, it is faster to write a good specification, but you have to know how. This book provides:
PowerPoint slidesDownload (zip+ppt)
Contains all the figures from the book plus some extra slides. There is one file for each chapter.
Pearson Education retains the copyright to the material, but allows restricted copying for teaching purposes. It is a condition that the source and copyright notice is preserved on all the material. This means that you can show the slides, of course, but also modify the slides and make hand-out copies for teaching purposes, as long as you state the source and copyright notice.
Teacher materialDownload (pdf)Download (doc)
A suggested course plan (curriculum) for a 12-week requirements course.
Solutions for some of the exercises are available for teachers. Since these exercises are mandatory on some courses around the world, we make sure the solutions are not available on-line. If you are a teacher, contact the author at slauesen@itu.dk.
Case: Membership administration (7 pages)Download (doc)
This is a short, complete requirements specification (Chapter 15 of the book). It follows the fast approach explained in the book. It was written, reviewed by the customer and revised in 14 work hours.
IT developers and consultants often ask for a good software requirements specification as a starting point for their own project. SL-07 is such a specification. It is part of the requirements for an Electronic Health Record system (EHR), but serves also as a template. Until now it has been used successfully in 60 projects ranging from public acquisitions to product development and agile in-house projects. It covers functional requirements, security, usability, etc. Version 4 has an improved way of specifying integration requirements, ways to select the right supplier, etc.
I made the template on request from the Danish Ministry of Research and Development, as part of their standard contract for software acquisition (K02). See Danish version
Booklet: Soren Lauesen: Guide to requirements SL-07 - template with examples version 2. Lauesen Publishing, 2011, 97 pages, ISBN 978-87-992344-1-7. Order the booklet from Amazon.com. (Don't try Amazon.co.uk. They offer version 1 only and it is out of print.)
Online version: New 16-06-2011 Guide booklet (pdf)
The booklet shows the template and explains section by section why it is written in this way. It also explains critical items in the contract, how to elecit the requirements, and how to test the system. Version 2 has new sections to match version 4 of the template. The booklet is based on the principles from the Addison-Wesley book, but updated and made more compact. All the requirements are written in tables. Column one is the customer's demands. Column two is a sample solution or a proposed solution.
Want a second opinion? Have a look at Ian Alexander's review of the booklet: Reviews
It turned out that the traditional use cases covered the customer's needs poorly in areas where improvement was important but difficult. Use cases also restricted the solution space severely because the use cases were much of a solution already. Tasks didn't have these problems and allowed an easy comparison of solutions. The results were published at the REFSQ 11 conference and got the Best Paper Award. The SL-07 template uses task descriptions rather than use cases.
New 11-01-2012Paper: Soren Lauesen & Mohammad Kuhail: Task descriptions versus use cases. In: Requirements Engineering (a Springer Journal): ISSN 0947-3602 Requirements Eng (2012) 17:3-18, DOI 10.1007/s00766-011-0140-1, November 2011. Download paper (pdf)
The experiment: Download the hotline case (pdf) Download Danish version (pdf) Download all replies (zip)
System implementation: Task descriptions had proved a good basis for designing effective user interfaces. To check this once more, Soren developed and documented a hotline system in MS Access based on his own task descriptions and an E/R model. You can download his design documents, VBA program, test documentation, and lessons learned. Download implementation documents (zip)
Miriam and Jan have a lot of experience with Contents Management Systems (CMS) and know all the problems that web editors encounter in practice. They wanted to write a Master's thesis about selecting the right CMS. It turned out to be difficult since customers had very different demands that couldn't be quantified in the same way.
They ended up using the SL-07 template to describe the requirements for a CMS. Companies that want to buy a CMS can use these requirements as a basis and modify them for their own needs. For me as a thesis supervisor, it was fascinating to see how the web editor's problems ended up nicely in the requirements. This allowed a fair comparison of CMS systems according to the needs of a specific customer. They modified the example for use in a real acquisition, sent it to several CMS suppliers, and got their feedback.
2011: Soren Lauesen & Mohammad Kuhail: Use cases versus task descriptions. In: D. Berry and X. Franch (Eds.): REFSQ 2011, LNCS 6606, pp. 106–120, 2011. Springer-Verlag Berlin Heidelberg 2011. Got the Best Paper Award on the conference. See more about the use case experiment.
2005: Soren Lauesen (2005): COTS Tenders and Integration Requirements. Invited paper for Requirements Engineering Journal (REJ). An expanded version of the previous paper - includes all the necessary integration requirements. Has less about the research method.
2005: Soren Lauesen & Jens-Peder Vium: Communication Gaps in a Tender Process. Invited paper for Requirements Engineering Journal (REJ). An English version of the previous paper. It gives a full account of the entire requirements specification, with excerpts of the more interesting parts.
2004: Soren Lauesen: Experiences from a tender process. In: Regnell et al. (eds.): Proceedings of REFSQ'04, Riga, Essener Informatik Beitrage, ISBN 3-922602-91-6, pp. 29-46. A case study of a large acquisition process. It gives the customer's view on the process and the five supplier's views. The customer used task descriptions, but had no experience with it. This caused several problems. The new system was expected to integrate with around 20 other systems, but nobody knew how to handle the requirements for this. This case caused me (Lauesen) to start developing techniques for dealing with integration requirements.
2004: Soren Lauesen: COTS Tenders and Integration Requirements. Proceedings of the 12th International Requirements Engineering Conference, Kyoto, RE 2004, pp. 166-175. Shows a way to handle some of the integration requirements in such a way that the supplier gets enough freedom, but doesn't get a monopoly for future additions. Got the Best Paper Award on the conference.2003: Soren Lauesen & Jens-Peder Vium: Erfaringer fra en EU udbudsforretning - hvad gik godt og hvor var problemerne? An early Danish version of the previous paper. In contrast to the English versions, this one contains summaries of the interviews with the suppliers.
2003: Soren Lauesen: Task Descriptions as Functional Requirements. IEEE Software 2003, March/April, pp. 58-65. This paper is the first scientific presentation of the task concept, which we invented around 1997. 2002: Soren Lauesen: Software requirements - styles and techniques. Publishing House of Electronics Industry, Beijing, 348 pages. (In Simplified Chinese). Contains everything from the Addison-Wesley edition, except the index.
2001: Soren Lauesen & Otto Vinter: Preventing Requirement Defects: An Experiment in Process Improvement. Requirements Engineering Journal (2001) 6, pp. 37-50. Springer Verlag, 2001.
2000: Dansk Dataforening & Søren Lauesen: IT-anskaffelse, Kravspecifikationen. Dansk Dataforening, 75 pages. (In Danish). Some key parts of the 1999 book in a handy format. It also used the term Use Case rather than Task Description, which has caused a lot of confusion in the Danish community.
1999: Soren Lauesen: Software Requirements, Styles and Techniques. Samfundslitteratur, Copenhagen. This is a preliminary version of the Addison-Wesley version, 2002. One of the specs in the preliminary version is in Danish - the one written by Deloitte and Touche. In contrast to the 2002 version, the preliminary version has no data requirements, no UML diagrams, no security requirements, and no project models. It uses the term Use Case rather than Task Description. At this point in time I had not realized how different tasks are from the prevailing use cases. One commercial example I had studied was a system that could be adequately described by 4 tasks. It had instead been described as 81 use cases.
1998: Soren Lauesen: Object-oriented
systems in real life. Case study details and observations
The data behind the next paper (Real-life . . .).
1998: Soren Lauesen: Object-oriented systems in real life. IEEE Software, 1998, March/April, p. 76-83. Also published in two Japanese journals: Nikkei Computer, 1998.6.22, p. 209-217, and Nikkei Computer Books, ISBN 4-8222-0771-4, p. 118-129.
1998: Soren Lauesen & Houman Younessi: Six styles for usability requirements. In: Eric Dubois, Andreas L. Opdahl, Klaus Pohl (eds.): Proceedings of the Fourth International Workshop on Requirements Engineering: Foundations of Software Quality REFSQ’98, Presses Universitaires de Namur, pp. 155-166.
1996: Soren Lauesen & Jens-Peder Vium: Lessons learned from assessing a success. In: Proceedings of Fifth European Conference on Software Quality, Irish Quality Association, Dublin, pp. 335-344. A case study of a large COTS acquisition in a shipyard. The shipyard wanted an ERP system in order to meet several business goals. The most important was to improve the accuracy of price quotation. They thought the system was successful, but our study showed that due to the traditional way of expressing requirements, they couldn't improve the accuracy.