Writing Good Requirements
Any software development project is doomed to failure if it doesn't have well written, clearly articulated, non-ambiguous, and reasonably feasible requirements. Let us share some good advice on how to write quality requirements.
Requirements capture is the first step in any software development project. Mistakes made during this phase can have the most dramatic negative impact on the success of the overall project. How can we avoid those mistakes by writing high quality requirements?
This is a call for seasoned professionals to share knowledge and advice with their less experienced breathren on the subject of requirements quality.
Bookmark This |
Defines the customer's expectations for quality, the internal process and product attributes that indicate whether the quality factors are being satisfied, and the measures to be used to give visibility to the levels of quality being achieved.
This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these quality criteria. It may be too late to revise them, but you might learn some things that will help your team write better requirements the next time.
Part of the key to writing good requirements is identifying bad requirements in order to improve them. Check out this discussion on finding smelly or bad requirements.
Analyzing requirements is a good reality check on requirements quality. Requirements that cannot be easily analyzed are poorly written.
Elizabeth Stoops discusses two very important types of requirements: those that are “qualitative” (which describe the qualities of the software) and those that are “functional” (which describe how the software performs). Qualitative requirements are sometimes referred to as business requirements, that is, the requirements and constraints the business puts on the software. They define the boundaries of the software and what it must be able to do. What they do not define is how it will do as required. Unfortunately, all too often, the often ambiguous business requirements are all a software team or an analyst receives.
Contact | About | Privacy | Terms
Copyright © 2009 Dynamical Software, Inc. All Rights Reserved. Dynamical Software ® is a registered trademark of Dynamical Software, Inc.