May
4
On Requirements and Design
May 4, 2006 |
In a comment responding to an earlier post, Roger Cauvin pointed me to some criticism of popular definitions of requirements he’s made. In that post, he repeats a certain popular belief:
A proper definition of requirement must clearly distinguish between requirements and design.
Should it?
The reason people make this statement is that they want to avoid prematurely specifying the solution. That’s a valid concern, I agree. The story of the Fisher Space Pen is one that has a lot of resonance for us (I’ve even used it in classes, and was disappointed to learn that it’s not actually true), as most BAs have seen projects where a lot of unnecesasary work was done to solve a supposed problem that didn’t actually exist. It’s a good lesson to learn.
However, it’s not always true that a requirement should avoid specifying the design. To present a counter-example, several years ago, I wrote the requriements for Mazda Canada’s online vehicle pricing application (and from the look I just took at it, I think it’s still working as I specified it). Should I have written those requirement to permit it to be deployed as anything other than a web application? Frankly, I can’t see why. The business need was for an online application, and so I wrote requirements specifically for that platform.
I believe that the BA should be prepared to be involved in any decision so long as the stakeholders are not indifferent between alternative solutions. In this case, the platform on which the application was delivered was something the stakeholders cared about, and so I included it as a requirement. Under other circumstances, I would define requirements that were platform-neutral, or even strive towards solution neutrality.
The purpose of writing requirements is to figure out how to fill a business need. That’s what Business Analysts should concern themselves with, not whether they cross the line into design.
Comments
3 Comments so far
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog
“Should I have written those requirement to permit it to be deployed as anything other than a web application? Frankly, I can’t see why. The business need was for an online application, and so I wrote requirements specifically for that platform.”
Then they weren’t pure requirements. You wrote a specification that included requirements and design.
I’ll take your word for it that the business need was for an online application (as opposed to the more solution-neutral need, perhaps, for a remotely accessible application). Still, shouldn’t someone also be documenting the reason for that need? And isn’t that reason the real requirement?
But why are they not requirements?
I understand that you’re making the point that just because a client somes to us and says “I need an X” that you should not run out and build X without confirming that it’s actually a client need. No argument. But, if X really is what the business needs, then to me (personally, not officially) it’s a requirement. “Design” consists of choices the solution team makes that are not of interest to the customer.
I guess I’m asking, what is the benefit that you percieve from a rigid seperation of requirements and design?
“But, if X really is what the business needs, then to me (personally, not officially) it’s a requirement.
‘Design’ consists of choices the solution team makes that are not of interest to the customer.”
I actually disagree with latter part of this definition of “design”. Customers care very much about some forms of design, because they directly impact the fulfillment of requirements. For example, in many cases a user cares very much whether an application is web based or standalone. It impacts the accessibility and the ease of installation of the application. Yet I don’t see how anyone could:
1. Deny that accessibility and ease of installation are the types of attributes that usually fall squarely in the realm of requirmeents.
2. Deny that the decision to make the application web based is a choice of how to fulfill those requirements.
But then it’s pretty clear that making the application web based is design.
“I guess I’m asking, what is the benefit that you percieve from a rigid seperation of requirements and design?”
Fair question, and I guess I didn’t answer it directly.
It forces the requirements elicitor and analyst to ask “Why?”. It enables the designers to think outside the box. It informs the Q/A team of the metrics that ultimately matter to the customer.