Software Requirements, Soren Lauesen Home


Book: Software requirements - styles and techniques

(Soren Lauesen, Addison-Wesley, 2002, 600 pages)Download sample (pdf)

Cover of Software RequirementsMost 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.


SL-07: An exemplary requirements specification

Cover of Requirements SL-07 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. It covers functional requirements, security, usability, etc. All requirements are verifiable. Free download:

Template SL-07 with examples: English version 5.5 (docx, 21-11-2017) Danish version 5.5 (docx, 21-11-2017)

Earlier versions of the template have been used with success in 100+ very different projects, public tender processes as well as in-house projects, agile as well as waterfall, e.g. home care management in a municipality, including route optimization; a pharmaceutical company's innovative document management system; electronic health records; stock management for movie production; claims management for car insurance with GIS as documentation. Experiences from these projects have been included in version 5.4 of SL-07.

All the requirements are written in tables. Column one is the customer's demands. Column two may be an imagined solution or the supplier's proposed solution. This principle was introduced in my Addison Wesley book, Software Requirements, for some kinds of requirements. Now it used for all requirements and more complex situations.

The new template version (5.4) has a section on flows and their relation to the requirements (B1), new requirements on test (J6), exit strategy (J7), improved minimum requirements, integration requirements, security requirements, usability requirements, 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

Guide to requirements SL-07
This booklet shows the template and explains section by section why it is written in this way and what to be aware of. It also has sections on what to remember in the contract, how to elecit the requirements, how to select the supplier, and how to test the system. Both the Danish and English version 4 match version 5.4 of the template.

Online version: English version 5 (pdf, 21-11-2017) Danish version 5 (pdf, 21-11-2017)

As booklet: You can buy the English version (ISBN 978-1523320240) as well as the Danish version (ISBN 978-1523319589) on www.amazon.de and www.amazon.co.uk. Price around 24 Euro.


Use cases versus task descriptions - an experiment

Use cases are widely used as a substantial part of requirements, also when little programming is expected (COTS-based systems). Are use cases effective as requirements? To answer this question we made an experiment. We invited professionals and researchers to specify requirements for the same project: Acquire a new system to support a hotline. Among the 15 replies, eight used traditional use cases that specified a dialog between user and system. Seven used a related technique, task description, which specified the customer's needs without specifying a dialog.

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)


CMS requirements - template with examples

(Miriam Tang and Jan Keller Pedersen, 2007, 80 pages)Download (pdf)

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.


Requirements papers

2011: Soren Lauesen & Mohammad Kuhail: Task descriptions versus use cases. An extended version of the paper below (use cases versus task descriptions). It includes discussions from the conference, the history of task descriptions, etc. The final version is published in Requirements Engineering (a Springer Journal): ISSN 0947-3602 Requirements Eng (2012) 17:3-18, DOI 10.1007/s00766-011-0140-1, November 2011. See more about the use case experiment.

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.