Most IT systems fail to meet expectations. They don't meet business goals and don't support users efficiently. Why? Because the requirements didn't address the right issues. Writing a good requirements specification doesn't take more time. This book shows how it is done - many times faster and many times smarter. This book covers many aspects of requirements. Styles: Traditional and more cost/effective ways of expressing requirements. Techniques: Ways of gathering, verifying, and maintaining requirements; ways of getting commitment from the stakeholders and support - yet limit - innovation; ways of ensuring that you meet your business goals. It discusses the styles and techniques useful for different project types, for instance software developed specifically for the customer, software bought off-the shelf and adapted for the customer (COTS), and software developed for a broad market. The book illustrates everything through real-life examples. It also deals with difficult requirements, for instance how to specify ease-of-use, how to specify very complex computations, and how to deal with 200 reports that the old system has, and the new system may or may not need. The book shows two complete, real-life specifications and large parts of several others. It also has exercises and figures for presentation.
Introduction & Basic Concepts
The Requirements Process
Checking & Validation
App A Danish Shipyard
App B Public Health Admin
App C Noise Source Location
App D Budgeting & Accounting
Have you ever used a new piece of software that didnt meet your expectations? If so, it might be because nobody stated the expectations in a tangible manner. Software requirements are about writing the right expectations in the right way.
These days, many people get involved in writing requirements. It is not only a job for specialists; users, customers, suppliers, and programmers also get involved. In small companies we sometimes even see employees without special training being asked to write requirements for a new software product. Furthermore, the roles of expert user, analyst, designer, and programmer seem to blend more and more. This book is important and relevant for many people involved in software requirements:
The analyst,working as a requirements engineer or a consultant, can find tricks here and there, and he can look at requirements written by other specialists.
The customercan find ways to ensure that the new product will meet his business goals, and suggestions for handling contracts and tenders.
Software supplierscan find ideas for helping the customer and for writing competitive proposals.
Userscan prepare themselves for working with specialists or the developers. They can also find ways to describe their work tasks, and examples of what to write and what not to write in their requirements.
Programmersand other developers can learn how to express requirements without specifying technical details, and how to reduce risks when developing a system.
IT studentscan learn about theory and practice in requirements engineering, and get a foundation for case studies and projects.
You dont have to read the whole book.How can we cover so many topics for so many audiences? The answer is simple: you dont have to read all of the book. If you read most of Chapter 1, you should then be able to read sections of the book in almost any order, according to your needs.
When I began to work in the software industry in 1962, software requirements were relatively unimportant since at the time hardware was very expensive, and software was comparatively cheap. Renting a computer for an hour cost the same as paying someone to work for 30 hours and computers were 5000 times slower than they are today.
Software development was carried out either on a time and materials basis, or as a small part of the really important job making better hardware. The customer paid until he had a program that printed results he could use with some effort. Nobody thought of usability. Everything to do with computers was a specialists job.
Today things have completely changed. Hardware is cheap, and software development is expensive and very hard to keep within budget particularly if the customer wants a result matching his expectations. For this reason software requirements are growing in importance as a means for the customer to know in advance what solution he will get and at what cost.
Unfortunately, software requirements are still a fuzzy area. Little guidance is available for the practitioner, although several textbooks exist. One particularly critical issue is the lack of real-life examples of requirements specifications.
This textbook is based on real-life examples, and it discusses the many ways of specifying software requirements in practice. We emphasize practical issues such as:
During my time in industry, I have worked as a programmer, a project manager, and later as a department manager and quality manager. However, I always loved programming and had a key role in the critical parts of the programs. We programmed many things, from business applications, scientific applications, and process control, to compilers, operating systems, and distributed databases.
When I worked as a developer from the mid-1970s, our team had to write software requirements, but we always felt uncertain about what we wrote. Was it # Prefacerequirements or design specifications? We realized that requirements were important, but felt stupid not knowing what to do about it. Furthermore, nobody else in our multinational company could show us a good example of software requirements, although there were corporate rules and guidelines for what to write.
In the mid-1980s I became a full professor in software engineering at Copenhagen Business School. That let me see development from two other sides: the user side and the customer side. I didnt have the constant pressure of turning out code and products, so I had time to look at the industry from another perspective.
For a long period I studied humancomputer interaction and came up with systematic ways of developing good user interfaces the missing links between studying the users and producing a good prototype. To my disappointment, industry didnt care at that time (the Web has now changed that attitude).
In the early 1990s, I decided that it was time to change subject. I asked around in industry to find out what was the most difficult part of development. Everyone I asked said "requirements and all that stuff at the beginning of the project." That was how I became interested in requirements.
I went to my research advisor, Jon Turner of New York University, and said, "Jon, I want to do research in requirements." He looked at me for some seconds and said, "Dont." "Why?" I asked. He replied that it was impossible to do anything significant in that area, and what researchers actually did had little to do with what industry needed. Alan M. Davis (1992) has observed the same thing.
This was a real challenge to me. To begin with, I had great problems in getting to see other peoples requirements. I talked to developers from many companies and asked them: "Do you write software requirements?" Usually they said yes. I then asked, "Could I see the one you are using or writing right now?" There was a pause then various replies, such as, "No, its confidential, and it would be too much trouble to get permission for you to read it." Or, "Well, it isnt quite finished yet; maybe you could see it later." Or even this amazing variant, "Well, were working on it, but right now we are too busy testing the system. When we have finished testing, we will write the requirements, and then you may see them."
Every now and then I got permission to see some real-life software requirements. Usually they were inspired by the IEEE 830 guidelines, since they contained all the introductory sessions such as Scope and Audience. However, when it came to the specific requirements, they were bewildering, and IEEE 830 suggested no guidance. Part of what I saw was program design; there were also some dataflow diagrams, and the rest made little sense to me. Where were the requirements?
Six months later, I saw some software requirements that were so good that I could learn from them. Jens-Peder Vium was the first to show me a good requirements specification, and it is included in this book as the Danish Shipyard case (see Chapter 11). Although vastly better than anything else I had seen at that time, it too had deficiencies, and together we worked on improving the various techniques involved. Soon my studies gained momentum, and I got to see many other good requirements, some of which are included in this book. A year later, so many people wanted me to look at their requirements that I had to say no to many of them.
My conclusion from these initial studies was that people were ashamed of the requirements they had written, but they didnt know how to make them better. Furthermore, everybody had some good parts in their specification, and some serious weaknesses. If all the good things could be combined, we would be close to a general solution. However, there were some important problems that none of the practitioners seemed able to solve:
Research, experiments, and luck helped me develop answers to these questions. These answers are included throughout the book, for instance in sections 3.8, 6.6, 6.11, and 8.7.
The book is a considerably extended version of an earlier book, which we used successfully at professional courses for analysts and developers, as well as for computer science students. Depending on the audience, we selected different parts of the book for discussion. We have even used the book with Information Systems (IS) students with no understanding of programming. In this case we combined it with a short course in data modeling, data flow, and basic understanding of development activities.
The figures in the book are available in PowerPoint format, and the checklists as Word documents. Solutions to some of the exercises are available for teachers. E-mail the author at firstname.lastname@example.org. Most of the figures are rich in detail, and as a result, you can easily spend 530 minutes discussing a single figure. In a typical course, only about one-third of the figures are discussed.
The book suggests two kinds of course activities, discussions and exercises. Discussions are themes for course room discussions, and may also be used for homework. Exercises are for homework or for teamwork during course hours.
You can run the exercises in many ways. At professional courses, we assign exercises to teams of three to five participants. Each team has to outline the answer in one to two overheads. That should be possible in about an hour, depending on the participants background and level of knowledge.
For university students, the exercises are given as homework, but here too we tend to restrict answers to a few overheads. One or two teams present their solution to the other students. About 15 minutes are allowed for a presentation, including discussion. The students are asked to control the presentation themselves. They should usually imagine that they are developers or consultants, while the other students are "customers". It is important to listen to the "customer", explain the solution again if the customer hasnt understood it, and identify weaknesses in ones own solution. A successful presentation identifies many weaknesses. This attitude is extremely important in practice, but difficult to achieve because we all tend to defend our own solutions.
However, exercises alone are not sufficient for training in requirements engineering. While programming exercises may give you programming training, this is not so with requirements. The art of discovering real demands and stating real requirements cannot be practiced through written exercises.
It is necessary to practice using real companies. For university courses, we always combine the course with the students doing project work in a real company. The first part of the project is that the students have to find a company or organization on their own. This also trains them to find the way to the right people; a very important skill in requirements engineering.
This book has only one author, yet I mostly write "we" in the text. This is because most of the experiences I discuss and report here have originated in talks and collaboration with someone else. Thus a large and varied selection of my colleagues have contributed to the book and justify my use of "we".
I would particularly like to thank the following:
Jens-Peder Vium, of Innovation & Quality Management, for permission to use the Danish Shipyard case (Chapter 11), and for many inspiring discussions and joint presentations. He has been a consultant for many years, and is an important source of knowledge about many different kinds of projects.
Susan Willumsen, at that time a masters student, for her collaboration and sharp observations during the Danish Shipyard study.
Houman Younessi, of Swinburne University, now Rensselaer at Hartford, for many theoretical and practical discussions that were the starting point of this book, and for some of the ideas behind the style concept and the maintainability requirements.
Otto Vinter, of Bruel & Kjaer, for permission to use part of the Noise Source Location requirements (Chapter 14), some of the case studies, and for many inspiring discussions, particularly about error sources and prevention methods.
Karin Lomborg (now Karin Berg) of Deloitte & Touche, for permission to use part of the Midland Hospital case (Chapter 12).
Jan C. Clausen, of Katalyse, for helping me to see the basic difference between tasks and use cases, and for many inspiring discussions about requirements and usability.
Klaus Jul Jeppesen, of Asea Brown Boveri, now the IT University, for information about large projects in control and manufacturing, customer negotiations, etc.
Marianne Mathiassen, masters student, and Lotte Riberholt Andersen, Jeanette Andersen, and Annemarie Raahauge, of West Zealand county, for collaboration when developing the technique first known as use cases with solutions, later renamed to Tasks & Support.
Lene Funder Andersen, Lene Frydenberg, Jens Wolf Frandsen, and Marc Olivier Collignon, diploma students, for being the first to try Tasks & Support in real life. They successfully managed to use the technique for writing requirements and run the tender process for a large telecommunications company. They also helped the company select the right proposal from among twenty suppliers.
Dorte Olesen, Lars Henrik Søfren, and Jette M. Rosbæk, of West Zealand county, for their impressive work when trying out Tasks & Support in a new hospital project.
Erik Simmons, Intel Corporation, for teaching me Planguage and for reviewing the book as carefully as if it had been a requirements document. (Like a typical developer, I couldnt repair all the defects.)