Practical Software Requirements: A Manual of Content and Style

Practical Software Requirements reveals how to write the documentation needed at the very beginning of the software development process: documentation of the customer's problem, and specification of the software so that it can be programmed and tested, and so that the final user documentation can be written.

Whereas most books on requirements provide a recommended table of contents, a single one-size-fits-all approach to specification methods, and writing advice not going much beyond "Every page shall be numbered," Practical Software Requirements concentrates heavily on making the document comprehensible and useful to its readers. But describing requirements is difficult and tricky in most real-world projects; it's really a job of technical writing. As a result, many requirements documents go forever unread, even by the customers who sign off on them, because they're too difficult to understand.

Practical Software Requirements treats requirements and specifications as a form of technical writing. Description techniques are presented for a wide variety of different types of customer problems and software. Instead of a one-size-fits-all technique such as "data flows and functions for everything," numerous techniques are presented, suitable to different types of problems and software. Instead of putting software into a few broad categories, the techniques apply to small "problem types" that are useful for breaking down a wide variety of larger problems. Techniques are supplied even for the smallest details of the document:

• how to word individual requirement statements,
• how to write use cases, common types of ambiguity and
• how to correct them,
• how to write a useful definition, and more.

The basics of requirements are also covered, enabling programmers or managers or others who have stepped into a requirements-gathering role for the first time to avoid common mistakes.

Practical Software Requirements also includes two full-sized example documents from real projects, suitable for use as a starting point in writing new requirements. They're relatively small projects, but not toy projects. They're real, complete with the unexpected complexity of the real world.

Whether you're a programmer or project manager writing requirements for the first time-- or an experienced system analyst-- this book will help you do it skillfully and effectively.

What's inside:

• Elements of a software problem
• User (and other) interface design documentation
• How useful requirements derive from known programming techniques
• Describing the problem domain
• Non-hierarchical methods for breaking down problems
• Applying Michael Jackson's "problem frames"
• Common mistakes and how to fix them
• Example documents from real projects

Why don't people read requirements documents? That's the problem solved by this book by focusing on what belongs in the document and how to write it so people can read, understand and use it. With Practical Software Requirements, you will give programmers, testors, user-interface designers and tech writers all the information they need to do their jobs.

This fresh view of requirements injects new sparkle and usefulness into what is often perceived as a dull but necessary task. The book offers practical advice like how to word a definition, how to name states and events and even how to avoid boring the reader. It brims with a wide selection of examples - from embedded applications that control machinery to large business applications that direct human organizations.

Whether you're a programmer or project manager writing requirements for the first time - or an experienced system analyst - this book will help you do it skillfully and effectively.

The book is about techniques for describing a problem to be solved by a piece of software without describing the design of software components. In other words, providing the information that the software designer needs at the correct level of detail, without trying to specify a software design.

Designing software involves joining informal, real–world problems to the formal world of computers. In the real world problems are messy, vague, and unbounded. Unfortunately, computers only solve problems that are well–defined, unambiguous and well–bounded. Requirements writing is the art of reducing a messy–real world problem to a neat, well–defined, unambiguous description which can be used to drive development of a computerized solution.

This is one of the first books to effectively bridge that gap. I say "effectively", because it is certainly not the first try––every software methodology has techniques for capturing requirements. However, the methodologies hopelessly intertwine requirements gathering with system interface specification and even system design. This inevitably results in requirements being given short–shrift.

Many of the techniques this book teaches are equally applicable to creating documentation for existing software. Every technical writer should learn to create models of the problem their software solves and then explain software functions using only the terms defined within the model.

I highly recommend this book. However, I do know some people who did not like it. If you find it disappointing, I suggest that you try practicing with one or two techniques, then give it another read. The ideas are often more subtle than they appear at first glance. Expect that you may need months to really absorb its advice.

this tells you all you need to know about requirements.

indeed, it tells a lot more than that because it explains things not just state them.

it kills some urban legends and myths about requirements that everyone should know but most people do not. but then most people do not know what they don‘t know. scare your phb, impress your colleagues with your wisdom after reading this book.

if you work with requirements, software, systems engineering, and especially systems architecture you need to read this book. even if you have read others and or think you know all about requirements you can still learn things that you didn‘t know or why what you thought was true actually is.

this book would work symbiotically with the art of systems architecture by rechtin and maier. read them both.

. .