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 only. 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.
Booklet: Soren Lauesen: Guide to requirements SL-07 - template with examples. Lauesen Publishing, 2007, 74 pages, ISBN 978-87-992344-0-0. Order the book Download book sample (pdf)See Danish version
IT developers and consultants often ask for an exemplary 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.
The booklet shows the specification and explains section by section why it is written this way. It also explains critical items in the contract and how to test the system. It is based on the principles from the Addison-Wesley book, but updated and made more compact. All the requirements are written in tables. The left column is the customer's demands. A sample solution or the proposed solution is in the right-hand column.
I made large parts of the template on request from the Danish Ministry of Research and Development, as part of a standard contract for software acquisition (K02). Earlier versions of the template have been used with success in 40 very different projects, for instance requirements to the new CMS of the Danish Defense, to Novo's environmental reporting system, and to a COTS vendor's next version of his product. Experiences from these 40 projects helped me improve this version.
Want a second opinion? Have a look at Ian Alexander's review of the book: Reviews
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.
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.
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.
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.
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.
2001: Soren Lauesen & Otto Vinter: Preventing Requirement Defects: An Experiment in Process Improvement. Requirements Engineering Journal (2001) 6, pp. 37-50. Springer Verlag, 2001.
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.
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.
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.