Software Requirements: Styles & Techniques: Styles and Techniques [Englisch] [Taschenbuch]

Suitable for most any IT professional who wants to build better software, Software Requirements: Styles and Techniques offers a surprisingly readable textbook-style treatment of software engineering's numerous attempts to get it right with defining requirements. Surveying almost every conceivable style of defining requirements, yet remaining thoroughly practical, this book can let your organisation do more with its requirements documents, which is a good step to creating software that succeeds better with your users.

Though everyone in software design knows about requirements, actual examples have usually remained shrouded in secrecy whether out of concerns over intellectual property or client confidentiality. One considerable strength of this title is that the author has seen many good and bad requirements documents and come up with several complete samples for a Danish shipyard and two hospital systems that can be published here.

Reading Software Requirements will likely convince you that you can do better with your requirements documents. Though there is no one "best" way, certain types of requirements work for certain situations better than others. This text can help you choose. Certain to be required reading for serious software analysts, this title can also benefit virtually anyone who works with software design documents. Its clear presentation style, remarkably devoid of jargon, helps make this book a great resource for a wide range of readers, with or without a background in traditional software engineering. --Richard Dragan

Suitable for most any IT professional who wants to build better software, Software Requirements: Styles and Techniques offers a surprisingly readable textbook-style treatment of software engineering's numerous attempts to get it right with defining requirements. Surveying nearly every conceivable style of defining requirements, yet remaining thoroughly practical, this book can let your organization do more with its requirements documents, which is a good step to creating software that succeeds better with your users.

Though everyone in software design knows about requirements, actual examples have usually remained shrouded in secrecy whether out of concern over client or intellectual property confidentiality. One considerable strength of this title is that the author has seen many good and bad requirements documents and has included here several complete samples for a Danish shipyard and two hospital systems.

The book begins by describing several dozen types of requirements styles, along with the advantages (and disadvantages) of each. Each requirements style differs by notation (text-based, graphical, or using Unified Modeling Language), level of audience (for nontechnical or technical users), focus (data, functional, performance, and usability), and whether it's used early or late in the project development cycle. While the author highlights those conventions that have worked best based on his extensive industry experience and research, each type of notational style gets due coverage. Sample requirements for a hotel-booking application anchor these early sections.

Not surprisingly, requirements are often hard to ascertain. The author's very thorough chapter on nearly 20 techniques to elicit requirements from users (using interviews, focus groups, and the like) is a real standout. Throughout this title, he offers plenty of advice on tracing requirements so that you can prove your software meets all user expectations. This text concludes with an extensive requirements document for a system used to track shipping repairs for a Danish shipyard, two systems for hospitals, and a membership database for a European political organization.

Reading Software Requirements will likely convince you that you can do better with your requirements documents. Though there is no one best way, certain types of requirements work for certain situations better than others. This text can help you choose. Certain to be mandatory reading for serious software analysts, this title can also benefit virtually anyone who works with software design documents. Its clear presentation style, remarkably devoid of jargon, helps make this book a great resource for a wide range of readers, whether or not they have a background in traditional software engineering. --Richard Dragan

Topics covered: Introduction to requirements, domain and product-level requirements, requirements for different project types, traditional, fast, and two-step approaches to defining requirements, types of data requirements (data models, dictionaries, data expressions, and virtual windows), types of functional requirements (including context diagrams, event and function lists, feature requirements, screens and prototypes, task descriptions, scenarios and use cases), functional details (including tables and decision tables), Unified Modeling Language diagrams used with requirements (including state, activity, class, collaboration, and sequence diagrams), requirements for product integration (for nontechnical and technical audiences), defining quality requirements, specifying accuracy, performance, and usability; security and maintainability requirements, product life cycle and requirements for each step (including contracts, proposals, design and programming, acceptance testing and delivery, requirements management, release planning, tracing and tool support), elicitation issues and techniques, stakeholders, working with focus groups, business goals and cost/benefit, domain-requirements tracing, checking and validation, real-world examples of techniques in action, case studies (and sample requirements) for a Danish shipyard database, two medical systems, a noise source location application, and a system to manage members of a political association.

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.

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.

 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¿s done - many times faster and many times smarter.  What are the highlights?

• Two complete real-life requirements specifications (the traditional and the fast approach) and examples from many others.
• Explanations of both traditional and fast approaches, and discussions of their strengths and weaknesses in different project types (tailor-made, COTS, and product development).
• Real-life illustrations of all types of requirements, stakeholder analysis, cost/benefit and other techniques to ensure that business goals are met.
• Proven methods for dealing with difficult or complex requirements, such as specifying ease-of-use, or dealing with 200 reports that might be needed because they are in the old system.

 Who is it for?  Everyone involved in the software supply chain, from analysts and developers to end users, will learn new techniques, benefit from requirements written by other specialists, and discover successes and failures from other companies. Software supplierswill find ideas for helping customers and writing competitive proposals. Programmers and other developers will learn how to express requirements without specifying technical details, and how to reduce risks when developing a system. Students aspiring to IT careers will learn the theory and practice of requirements engineering, and get a strong foundation for case studies and projects.  Who is the author? Soren Lauesen is currently professor at the IT-University of Copenhagen. He has worked in the IT industry for 20 years and has been a professor at Copenhagen Business School for 15. He has been co-founder of three educational and two industrial development organizations. His industry projects have encompassed compilers, operating systems, process control, temporal databases, and software quality assurance. His research interests include human-computer interaction, requirements specification, object-oriented design, quality assurance, marketing and product development, and interaction between research and industry. He has a broad range of other interests ranging from biology to dancing and foreign cultures.

Soren Lauesen has close to forty years' industrial and academic experience in software development. He has worked as a developer of real-time systems and other software, co-founded software development centers at two companies, and worked as a management consultant for ILO in Ghana. He is currently a professor at the IT University, Copenhagen, Denmark, dividing his time between research, teaching and consulting.

Have you ever used a new piece of software that didn’t 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 customer can find ways to ensure that the new product will meet his business goals, and suggestions for handling contracts and tenders.

Software suppliers can find ideas for helping the customer and for writing competitive proposals.

Users can 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.

Programmers and other developers can learn how to express requirements without specifying technical details, and how to reduce risks when developing a system.

IT students can learn about theory and practice in requirements engineering, and get a foundation for case studies and projects.

You don’t have to read the whole book. How can we cover so many topics for so many audiences? The answer is simple: you don’t 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.

 

Background

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 specialist’s 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:

• what analysts write in real-life specifications; what works and what doesn’t work
• the balance between giving the customer what he needs and over-specifying the requirements
• the balance between completeness and understandability
• the balance between describing what goes on in the application domain and what goes on in the computer
• reducing the risk to both customer and supplier
• writing requirements so that they can be verified and validated
• writing low-cost requirements specifications.

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 didn’t 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 human—computer 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 didn’t 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, "Don’t." "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 people’s 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, it’s confidential, and it would be too much trouble to get permission for you to read it." Or, "Well, it isn’t quite finished yet; maybe you could see it later." Or even this amazing variant, "Well, we’re 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...