Requirements, Requirements, Requirements

This post is part of a series for Drexel’s INFO 324 class, Team Process and Product

When working on a software project, having clearly defined requirements for both functionality and design. If you don’t get everyone on the same page by writing correct, feasible, prioritized, unambiguous, and verifiable requirement statements that tell every what they need to implement; and then following them up with solid and unambiguous design statements that tell you how it should be done.

In our INFO 324 class, we had to read three articles about writing requirements, each with a slightly different approach. They were: “Writing Quality Requirements” by Karl E. Wiegers, “Business Requirements – What Is The Difference Between Good And Bad?” by Thomas Hathaway, “Writing good requirements is a lot like writing good code” by Jim Heumann.

Of the three articles, I agree with Wiegers the most, because he takes the most simplistic approach by breaking down each of the characteristics of a good statement and specification, along with some great examples. I also appreciated Heumann’s approach of  providing strategics and tools to writing requirements that come from the real world of working at IBM.