Software Requirements: Styles and Techniques

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.

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 suppliers will 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.

Amazon.com

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