"A requirement states the least stringent condition that must hold to solve or avoid a problem that a prospective customer faces."Assume we are developing a temperature control system, and the problems that prospective customers face include:
- Prospective customers feel too cold or too hot in their homes.
- Prospective customers will feel frustrated if it takes more than one minute of their time per day to maintain a comfortable temperature.
Here are two possible ease of use constraints:
a. The system will be a thermostat with a dial to set the desired temperature, a switch that determines cooling or heating mode, and an on/off switch.It is conceivable that we could solve problem 2 with a temperature control system that did not have the user interface specified in constraint 'a'. Therefore, ease of use constraint 'a' is not a requirement, as it is not the least stringent condition that must hold to solve problem 2.
b. For a user that fits profile 'x', it should take no longer one minute of his time per day to maintain a comfortable temperature in his home.
Constraint 'b', on the other hand, flatly restates the prospect problem in terms of a negative condition. It is therefore a requirement.
3 comments :
Hey. I chuckled when I read this. Not only did you support your definition of a requirement, but you also supported my definition of a requirement.
Who knows - perhaps in all of the real world examples, we actually agree on this, even though we use very different language to describe our perspectives.
I completely agree that example "a" specifies the implementation and is therefore a solution-design artifact and not a requirement.
I also noticed that you had an ideation step in going to example "b" - you decided that the problem of regulating a 'target temperature' was the problem you were choosing to capture as a requirement for the system.
You could have chosen to buy the person a wardrobe of layered clothing that they could change throughout the day (that's what I do when my wife is in charge of the thermostat). You could have proscribed a program of temperature desensitization, so that the person had a broader definition of "comfortable". Or you could have used hypnosis to make the person unaware of anything short of life-threatening extremes.
Well, I tried to be careful here. I'm not sure if what you call "ideation" is a good thing when it comes to requirements.
I framed one of the problems as the ease (in terms of time expended) of maintaining a comfortable temperature. Given this problem, there was no "ideation" in expressing the requirement as a limit on the amount of time it should take to maintain a comfortable temperature. The requirement did nothing more than restate the problem in terms of its inverse.
Perhaps the problem statement contains some implicit "ideation". To the extent that's the case, I think the problem statement (and thus the requirement) is flawed.
Don't get me wrong. "Ideation" sounds like a great thing. But it seems more like design than requirements to me.
Rereading this entry and comments, I now don't think it's fair to contend that it contained any "ideation". By "maintain comfortable temperature", I did not mean setting a target temperature. Certainly, an A/C system with a thermostat might be a natural solution to the problem. But I explicitly rejected the alleged constraint containing that assumption as design. My intent was to frame the problem of feeling too hot or too cold as a requirement. That's what I meant by "temperature". Perhaps "perceived temperature" would have been clearer.
Post a Comment