See more: Y-Foundation case CMS requirements Use cases versus task descriptions Book: Software Requirements Requirements papers
The customer can assess how well the solution supports users, etc. and use this in the supplier selection. SL-07 requirements have many other advantages: Five times shorter, five times faster to write, five times faster to reply to, and business goals met. Disadvantage: It takes five days to learn the method.
The approach is available as a guide to writing SL-07 requirements, illustrated with the Electronic Health Record (EHR). Also available: The requirements document itself for copy and edit, the figures, and a contract matching the requirements.
English version 9: On-line Guide booklet (pdf) EHR Requirements (docx) EHR Figures (pptx) Contract for the requirements (docx)
Danish version 9: On-line vejledning (pdf) EPJ-krav (docx) EPJ-Figurer (pptx) Kontrakt til kravene (docx)
The guides are also available on Amazon as paper booklets of 127 pages. Price around 14 Euro. UK: 9798425802224. DK: 9798426357747.
The requirements cover functional requirements, security, usability, integration, management of the acquisition, phasing out, etc. All the requirements are verifiable. Around 30% of the requirements correspond to what traditionally are written as use cases or user stories. Typically, 50% of the requirements can be reused across domains.
Make sure you read the online guide in two-page view. You may have to download it. The guide shows the EHR requirements section by section on the right-hand page, and explains on the left-hand page why they are written in this way, and what not to write. The guide also has sections on how to elicit the requirements, how to select the supplier, how to test the system, and how to manage the entire process.
Want help to write problem-oriented requirements? Simply send a message to: slauesen@os.dk
All requirements are written in tables. Column one is the customer's demands - what he will use the system for, or the problems to eliminate. Column two may be the customer's imagined solution (in black), later the supplier's proposed solution (in red). Have a look at the Y-Foundation requirements below, to see what it looks like in a real, complex case.
The SL-07 contract is problem-oriented too. As a result, the contract is 8 pages with 4 appendices (one of them being the requirements). Traditional contracts such as K02 are 50+ pages with 16 appendices. See more on contracts (in Danish)
The EHR requirements have been reused with success in 150+ very different projects, public tender processes as well as in-house projects, agile as well as waterfall. Examples: Home care management in a municipality, including route optimization; a pharmaceutical company's innovative document management system; electronic vet records (animal health records); stock management for movie production; claims management for car insurance with GIS as documentation. Experiences from these projects have helped me improve SL-07 from release to release.
SL-07 history: I made the exemplary EHR requirements in 2007 on request from the Danish Ministry of Research and Development, as part of their standard contract for software acquisition (K02). My students named the requirements SL-07. The EHR example is from those years. I have updated SL-07 several times since then.
The experiences were published at the REFSQ 2018 conference: Lauesen, Soren: Problem-Oriented Requirements in Practice - a Case Study (pdf). In: E. Kamsties et al. (Eds.): REFSQ 2018, LNCS 10753, pp. 3–19, 2018, Springer, https://doi.org/10.1007/978-3-319-77243-1_1.
It was recognized at the REFSQ conference, that this was the first, ever published real-world IT requirements specification. It even had real-world supplier proposals and real-world issues and conflicts.
The requirements were 34 pages, written as problem-oriented requirements. The suppliers wrote their proposed solution in column 2, in some cases supplemented with a Solution note. As an example, the winning supplier used a solution note to show a detailed, new screen that gave a great overview of the grant applications. His reply consisted of the requirements, extended with the solution pieces, in total 44 pages. The reply became an appendix to the contract: Requirements and the supplier's reply (pdf, 44 pages)
We selected the supplier based on financial benefit, risk and total cost: Note to the board on supplier selection (docx). The document also includes a post-evaluation of the project. Was the goals met? And why was it late?
The project was 9 months late. What happened on the way? The project month by month (docx)
During testing we encountered many issues (errors and requests for change). We recorded those that we couldn't deal with immediately. Initally we recorded 23 issues, later 107. Here is a merged list of all 130: All issues/errors chronologically (docx) All issues/errors by type (xlsx)
The way the requirements were structured, made it fairly easy to make a test script for acceptance testing (i.e. the customer's test of the system): Test plan (docx)
Some of the documents exist in Danish too:
Kravspecifikation og leverandørens svar (pdf, 44 sider)
Notat til bestyrelsen om leverandørvalg (docx) Indeholder også en eftervurdering af projektet.
Testplan (docx)
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 editors' problems ended up nicely in the requirements. This allowed a fair comparison of CMS systems according to the needs of a specific customer. Miriam and Jan modified the example a bit for use in a real acquisition, and sent it to several CMS suppliers and several potential customers for comments. The feedback was very positive: the specification reflected the real needs and problems in a constructive way.
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.
Paper: 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)
Development according to the requirements: The experiment started as a four-hour written exam, where students should make a data model, describe tasks, design a graphical user interface, etc. Task descriptions had proved a good basis for designing and developing good user interfaces. To check this once more, Soren developed and documented a hotline system in MS Access, based on his own reply to the assignment. You can download design documents, database with the VBA program, test documentation, and lessons learned. Download implementation documents (zip)
Announcement of the book 2002: 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 slides Download (zip+pptx)
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 material Download (pdf)
Download (docx) 2022c: Mohammad Amin Kuhail and Soren Lauesen (2022): User Story Quality in Practice: A Case Study (pdf). 21 pages. A more readable version than the original in: Software 2022, 1, 223-243 https://doi.org/10.3390/software1030010
2018: Soren Lauesen: Problem-Oriented Requirements in Practice - a Case Study (pdf). In: E. Kamsties et al. (Eds.): REFSQ 2018, LNCS 10753, pp. 3–19, 2018, Springer, https://doi.org/10.1007/978-3-319-77243-1_1. See more about the Y-Foundation.
2011a: Soren Lauesen & Mohammad Kuhail: Task descriptions versus use cases (pdf).
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.
2011b: Soren Lauesen & Mohammad Kuhail: Use cases versus task descriptions (pdf).
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.
2005a: Soren Lauesen (2005):
COTS Tenders and Integration Requirements (pdf).
Invited paper for Requirements Engineering Journal (REJ). An expanded version of the 2004a paper below - includes all the necessary integration requirements. Has less about the research method. 2005b: Soren Lauesen & Jens-Peder Vium:
Communication Gaps in a Tender Process(pdf).
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.
2004a: Soren Lauesen:
COTS Tenders and Integration Requirements (pdf).
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. 2004b: Soren Lauesen:
Experiences from a tender process (pdf).
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. 2003a: Soren Lauesen & Jens-Peder Vium:
Erfaringer fra en EU udbudsforretning - hvad gik godt og hvor var problemerne? (pdf) An early Danish version of the previous paper. In contrast to the English versions, this one contains summaries of the interviews with the suppliers. 2003b: Soren Lauesen:
Task Descriptions as Functional Requirements (pdf). IEEE Software 2003, March/April, pp. 58-65. This paper is the first scientific presentation of the task concept, which I invented together with Marianne Mathiassen around 1997.
2002a: Soren Lauesen: Software requirements - styles and techniques (44 pages sample, pdf). Addison-Wesley/Pearson, 608 sider, ISBN 0 201 74570 4. The textbook on requirements: More on the book. 2002b: 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 (pdf). Requirements
Engineering Journal (2001) 6, pp. 37-50. Springer Verlag, 2001.
2000: Dansk Dataforening (Danish IT Association) & Soren Lauesen: IT-acquisition,
The requirements specification. Dansk Dataforening, 75 pages. (In Danish). Some key parts
of the 1999 book. Unfortunately, at that time I used the term Use Case With Solutions rather than Task Description. I considered tasks a special version of use cases, and didn't yet understand the basic diffence: Demand/problem versus Solution. This caused a lot of confusion in the Danish IT community. 1999: Soren Lauesen (1999): Software Requirements, Styles and Techniques. Samfundslitteratur, Copenhagen, 190 pages. An early version of Lauesen (2002): Software requirements - styles and techniques. See above.
1998: Soren Lauesen & Houman Younessi:
Six styles for usability requirements (pdf). 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 (pdf). 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 order cost calculation (pre-calculation) based on experience data. They thought the system was successful, but our study showed that nothing had improved. The critical system parts were not used because they were too cumbersome. The cause was that analysts had used traditional requirements, where you cannot see the work context.
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@os.dk.
Soren's other requirements papers