Welcome, Guest.

What's Happening in Your Network

  • Learning the site and social connections - rcoplen



Promoter: 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.

  1. What are some tips on writing good, solid requirements?
  2. How can you identify and measure requirements quality?
  3. What are some educational resources for SMEs and analysts?

requirements quality




Adjudication: open

Type: Engineering

Commendation: multiple




Criteria | Categories | Bookmark This | Discuss | Respond | Judges | Votes

Deliverable: Quality Requirements

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.

Writing Quality Requirements

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.

Requirements Smells

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.

Better Requirements Parsing

Analyzing requirements is a good reality check on requirements quality. Requirements that cannot be easily analyzed are poorly written.

Foundations for Defect-Free Requirements

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.