How to Write Good Software Requirements
I find it hard to believe that even in 2013 software professionals are still having difficulties getting good software requirements. How can we finally start writing quality software requirements? I think a good starting point is this two-part article, “ Software Requirements: Classifying Customer Input,” by Karl Wiegers, an expert in the field of requirements.
The first part of the article explores the initial business requirements, use case, and business rules; part 2 looks into the quality attributes, external interface requirements, constraints, data definitions, and solution ideas. This piece is important because your first interactions with the business side of an organization may determine your success or failure.
Now that we know the importance of the initial contacts with the business user, we have to actually write good requirements. For that, I recommend checking out CMSWire.com, which offers us eight tips to capture better requirements. The author explores the fact that the process of gathering requirements is flawed.
Smartsheet.com tells us what goes into good requirements by stating that good requirements are verifiable, meet specific needs, are clear and understandable, and are attainable. If you’re not convinced of the importance of requirements, an article on Redmond Developer News warns us of the true cost of bad requirements, stating a study found that one in every three dollars is wasted on bad requirements.
Let’s assume you have the requirements gathering part figured out; the next issue on this journey is proper requirements management (RM). It’s a fact of life that requirements change, and for a rundown on these changes, IBM offers a four-part series.
Part 1 of the IBM series is a refresher course on why RM is so important. Part 2 looks at how to write good requirements. Part 3 covers the reason for baselining your requirements, and the final article wraps up the discussion of why requirements traceability is important.
If you are wondering about how the requirements gathering and requirements management process applies to agile, ScrumAlliance.org has a good piece that details how to manage requirements during a Scrum.
Hopefully this has been helpful as you try to wrap your head around the issues that exist with the many facets of requirements.
Do you have a handle on your requirements process?
