What is an Effective Requirement?

Chris from Telelogic presented a Webinar on Writing Effective Requirements yesterday. I noticed around 500 attendees, looks like there are several of us asking: “What is an effective requirement?”

In my role as a solution architect I have to ensure that the technical teams and the business teams share a vision of what is being built. From my entrepreneurial experience I recognize the value of a compelling vision, a focused mission and measureable success objectives. Assuming all these are in place we then begin to gather more specific requirements.

The picture here shows that is well worth the time to create quality requirements early in a waterfall project phase. Agile does reduce some the risks of unclear requirements by providing feedback earlier, however, the guidelines Chris shared for what makes a good requirement, apply to both creating a requirement document in waterfall process and a user story in an agile process.

Let’s look at an example of a good user requirement:

The internet user shall be able to access their current account balance in less than 5 seconds.

Here we define a user type: the internet user. The “to be verb” is prefixed with “shall” which has a consistent meaning of mandatory (along with "will" or "must"), “should” means optional, “may” is desirable. The positive end result is “access to their current account balance”. Measurable success criteria is “5 seconds”

This example meets these structural elements of a requirement:

• Complete Sentence
• States subject and predicate
  - Subject is a user type
  - Predicate is a condition, action or intended result
• Consistent use of Language
• Specifies
  - Desired goal or result (User requirement)
  - Function (System requirement)
  - Constraint (either)
• Contains a success criterion or other measurable indication of the quality
  

In addition to following structure, Chris shared these characteristics of a good requirement:

• Correct - Technically and legally possible
• Complete - Expresses a whole idea or statement
• Clear - Unambiguous and not confusing
• Consistent - Not in conflict with other requirements
• Verifiable - It can be determined that the system meets the requirement
• Traceable - Uniquely identified and can be tracked
• Feasible - Can be accomplished within cost and schedule
• Modular - Can be changed without excessive impact
• Design-Free - Does not pose a specific solution on design
• Positive - Written in the affirmative, not the negative

The challenge is seek out the user type, end result and success measure in EVERY requirement defined. This is one of the challenges I face working in a waterfall process is to hold the team accountable to follow these guidelines without slowing down an already very time consuming phase. I confess, I am often eager to get into the design and code phase and I let these things slip. One of the reasons I am choosing to write this post is to present guidelines at the beginning of the phase. I hoping Eric who is stepping up to fill a business analyst role will find these useful – let me know!

I asked Chris at the end of the presentation what is the difference between a requirement and a user story. He replied that they are basically the same and that these guidelines apply to both. The guidelines are useful, I agree, specifically on how to write a requirement, a user story, however is not the same. A user story in an agile process emphasizes the role of conversation and testing, in addition to the written requirement.

As Mike Cohen reminds of this and highlights further differences in a great article, Advantages of User Stories for Requirements:

User stories are not just these small snippets of text. Each
user story is composed of three aspects:

1. Written description of the story, used for planning and as a reminder
2. Conversations about the story that serve to flesh out the details of the story
3. Tests that convey and document details that can be used to determine when a story is complete

I see several other major differences with what we do with these requirements in agile approach vs a waterfall process.

• Agile prioritizes all requirements; waterfall typically groups them by functionally
• Agile only elaborates requirements when they are about to be implemented; Waterfall completes requirement details in the requirements gathering phase
• Agile welcomes new and changing requirements; waterfall discourages changes using change control processes.

In conclusion, I think there are some useful guidelines here for writing effective requirements that can help our teams within our current waterfall process and I think the competency will continue to be valuable in writing user stories in an agile process.

Want more? Check out these other interesting links I found:

We don't need no Stinking Requirments, reminding us agile processes still need requirments (also nice link at the end on writing requirments)

The 1997 article by Steve McConnell with a narative around the picture above.

Wikipedia links: User Stories and Requirements