Required or Not

  1. Posted on December 8, 2011 1:52:PM by Earl Beede to Practicing Earl
  2. Technique, humor, requirements

I really enjoy teaching my company's requirement seminars. I enjoy it because, frankly, there really is no industry consensus of what a requirement is. As an instructor, I am free to say any darn thing I like.

For an example as to the lack of consensus, client after client will tell me that they have a requirements document full of requirements. I then ask them if they actually deliver to all of those requirements and they say, more often than not, "No, we have to cut scope."

"So," I say, "some of those requirements were not required, correct?"

"Well," they say, "we have 'must have' and 'nice to have' and, 'in our dreams' classifications so, in a way, we have things that are not required in our requirements document."

"So," I say (I like to say 'so', I guess), "you deliver all the items in the 'must have' classification, correct?"

"No," they reply, "we cut scope there too."

"So," I say (see, I am really into 'so'), "then you do have requirements that are not required."

"They would be required if we did them," they retort.

That is the nut of the issue. Requirements are required only when we choose to make them required and, if we choose, they are not requirements but merely nice statements created for our mutual entertainment and the wasting of company resources. We are perfectly comfortable saying that a requirement is, for whatever reason suits us at the time, not required. With that kind of logic, I can teach just about anything and be correct.

What causes this crazy talk, I think, is a confusion between big R and little r requirements. Little r requirements are around us all the time. I like to use a simple statement that captures little r requirements on a software project: A requirement (little r) is a decision we impose on an implementation. A corollary would be that if there is no implementation, then the decision/requirement is moot. If we are to implement something, then we have to live by the decision or say we didn't meet the requirements (little r).

Little r requirements can be made by anybody on just about anything. While knowledge and experience is preferred, I have not seen that little r requirements mandate it. We tend to capture little r requirements by the decision making source. Decisions by marketing people end up in the Marketing Requirements document, decisions by users end up in the User Requirements specification, etc. The interesting analysis is what are these various decision makers making decisions about. Turns out, they are making decisions on just about everything but mostly on how to implement the solution. Little r requirements.

For example, I had one client who in the Business Requirements document said that a certain GUI button on a selected screen must have a width of X pixels wide. Now usually, I would call the size of a button, heck, even the choice of a button, a design decision in order to meet some usability goal but there it was—the button width was in the Business Requirements document. Someone or other decided that is what the button should be and lo, it was a requirement.

"But wait," you, a requirements expert, might say, "we have known for years that those are bad requirements. Requirements should be about the 'what' not the 'how'." I agree, but that does not seem to help us out in the real world. Out there, everybody is making decisions about whatever they feel they must make decisions about and we are required to capture them in our requirements documents. These 'how' decisions are what the implementor must live with or be held accountable. Any why are they "bad"? Little r requirements are a real decisions about things that need to be decided about.

Little r requirements are bad only when the wrong person is making the decision or the right person is making it at the wrong time. What makes a decision a bad decision is when we base the decision on woefully incomplete knowledge.

I worked with a company that had one of the founders, a brilliant UI designer, end up as the VP of Marketing because all of the founders had to end up as VP of something. When they were small, the VP of Marketing did all the UI design. Right person, right time. As they grew and new marketing staff came on board, they looked to their boss to see what roll they played. They saw their boss doing the UI design so they too would do UI design. Unfortunately, they were not UI designers. Wrong people to make those decisions and the projects suffered. The company could only fix the situation by moving the UI designing VP back to the technology side of the house (with a big fancy title). Marketing staff were NOT allowed to do UI design.

What decisions should Marketing be making? They should decide a) who the critical customers were, b)what main product functions were necessary to server those customers, and c) what aspects (characteristics, qualities, etc.) the customers would judge the greatness of the product by. Those decisions could result in really impressive big R requirements.

We will never have complete knowledge. Decisions need to be made to keep the project moving but I think the approach of "last responsible moment" has a lot of merit to it. At least align the needed decisions to the best decision makers.

So look at your requirements and see if you have big R or little r requirements. Chances are that if your requirements are not required, you only have little r. Probably somebody has made a decision that is either too early or is not the right person to make that decision.

Post a Comment:

 
 

Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).

 

Contact Earl