Skip to main content

Software Requirements 3, by Karl E Wiegers, Joy Beatty, Microsoft Press


One of the areas often overlooked when writing software systems is thoroughly understanding what needs to be developed. Specifically who are the users that are going to interact with the system, what are they trying to accomplish with the software, and how is the system expected to behave under normal and error conditions. In short, developing software requirements and specifications before the software is written.

"Software Requirements 3" addresses these questions, with clear answers and advice in a rather longish format of roughly 673 pages.

The book starts with a story about the importance of software requirements: a case of an employee who changed her last name without getting married, and the accounting software's inability to handle the change, with the repercussions that the employee will not get paid until the the "bug" is fixed. The book mentions that this is not an atypical situation, and that 
... errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product
The book proceeds to explain how to prevent problems like these from happening in the future, through explaining the mechanics of requirements gathering starting with defining who the customer is, and who the decision makers are, followed by a tour of the requirement gathering process, including requirements elicitations, and appropriate documentation.  The book advocates readable, concise, and precise requirements documentation, and ample use of imagery to explain difficult concepts.

The book offers advice on how to reduce development risk, through frequent customer checkpoints as things are developed, to minimize the mismatch between customer expectations, and what developers build. The book also advocates building prototypes to illustrate concepts, and drive conversations to minimize the gap between what's being build, and what customers expect.

The book addresses the often ignored fact that requirements frequently change during the development process, and offers a full chapter on handling these changes, and tools for managing the changes.

The book is geared toward the business analyst, but software engineers would benefit greatly from reading it. And despite the book's length, the authors' writing style is approachable, and it was a pleasure to read.

Comments

Popular posts from this blog

Kindle Paperwhite

I have always been allergic to buying specialized electronic devices that do only one thing, such as the Kindle, the iPod, and fitness trackers. Why buy these when technology evolves so fast that a multi-purpose device such as the phone or a smart watch can eventually do the same thing, but with the convenience of updates that fix bugs and add functionality? So, I was shocked when this weekend I made an impulse buy and got the newest Kindle Paperwhite—a special purpose device for reading eBooks. I was walking past the Amazon store in the mall and saw that the newest Kindle Paperwhites were marked down by $40 for the holidays. The device looked good in the display, so I went in to look at it closely. The Paperwhite is small and light, with a 6” screen that is backlit and waterproof.   The text was crisp and readable, and in the ambient light, it felt like I am reading a printed book. I was sold and bought it on the spot. At home I have struggled to put it down. The bo...

A paper a day keeps the doctor away: NoDB

In most database systems, the user defines the shape of the data that is stored and queried using concepts such as entities and relations. The database system takes care of translating that shape into physical storage, and managing its lifecycle. Most of the systems store data in the form of tuples, either in row format, or broken down into columns and stored in columnar format. The system also stores metadata associated with the data, that helps with speedy retrieval and processing. Defining the shape of the data a priori, and transforming it from the raw or ingestion format to the storage format is a cost that database systems incur to make queries faster. What if we can have fast queries without incurring that initial cost? In the paper " NoDB: Efficient Query Execution on Raw Data Files ", the authors examine that question, and advocate a system (NoDB) that answers it. The authors start with the motivation for such a system. With the recent explosion of data...

A paper a day keeps the dr away: Dapper a Large-Scale Distributed Systems Tracing Infrastructure

Modern Internet scale applications are a challenge to monitor and diagnose. The applications are usually comprised of complex distributed systems that are built by multiple teams, sometimes using different languages and technologies. When one component fails or misbehaves, it becomes a nightmare to figure out what went wrong and where. Monitoring and tracing systems aim to make that problem a bit more tractable, and Dapper, a system by Google for large scale distributed systems tracing is one such system. The paper starts by setting the context for Dapper through the use of a real service: "universal search". In universal search, the user types in a query that gets federated to multiple search backends such as web search, image search, local search, video search, news search, as well as advertising systems to display ads. The results are then combined and presented back to the user. Thousands of machines could be involved in returning that result, and any poor p...