There seems to be a very grey area between requirements and the actual design.
What general rules of thumb do people apply to make sure they are focussing on requirements and not implmentation/design??
There seems to be a very grey area between requirements and the actual design.
What general rules of thumb do people apply to make sure they are focussing on requirements and not implmentation/design??
Ultimately, requirements map back to business needs. If you can't map it to a business need, it's probably design.
If the "requirements" include a lot of specific technology solutions to be used or describe specific user interface controls, these requirements are imposing design constraints on the developers. Including design constraints in the requirements is not wrong or bad. You just have to be careful *not* to impose inappropriate, unnecessary, or premature design constraints. It can lead to suboptimal designs and can unnecessarily restrict the options available to the developers.Originally Posted by beej199
BTW, I address this requirements vs. design issue in Chapter 16 of my book "More About Software Requirements."
One of the rules of thumb that we use is that if the business wants it, it is a requirement. Often times the business wants things that should be considered design. Maybe you could call them design constraints.
As Karl mentioned, you have to be careful that you don't just accept everything the business asks for, so you need to ask why they want something. If they can't legitimately map it back to a business need, then they may have crossed the line.
One of the simplest cases is standardized look and feel. It is typically the job of marketing to decide how things will look. Many people would call this portion design, but it still needs to be part of the requirements because the business has a specific desire.
Ultimately, it comes down to who says what. In some organizations, engineering totally runs the show so PMs are implicitly (or explicitly) told to keep their hands of huge swaths of the specification process. In other organizations, the business/marketing carries the bigger stick and gets to exert far more influence over the process. I hate to say it all comes down to politics, but in many organizations it is as simple as what the org structure looks like.
My thoughts are summarized in this blog post:
http://requirements.seilevel.com/blo...t-depends.html
joe
What happened to the good old standbye? That being:
"What" is Requirements.
"How" is Design.
Dave W
I'm Sony.
I want to entertain people (what I want to do).
I'm going to sell a new TV (how I'm going to do that).
Does that make everything related to the TV a design decision?
The What and How are very tightly coupled to the particular problem that you are choosing to solve, and making the decision on what problem to solve is the real trick.
This is where my organization gets confused because I can turn the design phrase of "I'm going to sell a new TV" into yet another requirement to satisfy the first requirement.
I want to entertain people (what I want to do).
To do this, I need to sell a T.V. (what I need to do)
2 requirements.
It's not that simple. "What" and "How" leapfrog down the abstraction scale. The answer to a "what" question at one level is a "how" at the next level down, and it just keeps on going. Here's an example:
If we ask, "What will the user be able to do with the product?" the answer might identify some use cases. If we then ask, "How will we let the user perform those use cases," we come up with a list of specific functional requirements, which isn't design even though it's answering a "how" question. Those functional requirements can also be though of as answers to the question, "What should the developer build?"
So one person's "what" is the next person's "how". It's a little hard to explain, but if you think about the abstraction scale from business objectives at the top down to code at the bottom of the scale, you'll see this pairwise relationship of whats and hows. I address this issue in chapter 16 of my book "More About Software Requirements."
To make matters worse, a functional requirement that includes a legitimate design constraint is describing a "how" as part of a clear requirement, for a perfectly fine reason! So the what/how distinction is too simplistic.
Nothing in this business is easy....
Posting Permissions
Reply With Quote