Requirements Differences

[mommabear]

There is much to be learned by self-teaching a given programming language or three, but there are other business related aspects that have given rise to some questions. I hope I am posting in the appropriate forum section, and that my questions are not too quaint or elementary to merit answering.

• What is the difference between stand-alone, verifiable, quantifiable, and implementation-free requirements?
  
• In what scenario would they be best used?
  
• How often do you find yourself working on a development without frozen requirements?
  
• As a customer, why is it important to have a frozen requirement?

[chrishea]

What is the context for your questions? This sounds like a school assignment. If that is the case, I would hope that the course includes material that would address these questions or that you can do better research than just dropping the questions into a forum such as this one.

With respect to the last two points, developers want and need frozen requirements but actually getting a truly frozen requirement is quite difficult. You may do a good job of defining what will and won't be delivered (in your own mind) but at some point the user may finally understand what they are getting and it isn't what they imagined (or maybe they just didn't think about it too much). "Legally" you may have written an agreement that protects you but you now have a situation where the user may not be getting what they really want/need. Do you then stand by what was originally written or do you go through a revision to the requirement? At a minimum, if things were well defined, there can be some recognition that you tried to define it and that you are trying to deliver what you promised. Otherwise, you get finger pointing and attempts to place blame on the developer(s).

Customers also need well defined requirements so they know what they are supposed to get and so there is a reference which can be used to determine if they got it or not. From the Customer point of view, the Developer(s) need to be held to a requirement and a plan. Customers don't want to give the Developer(s) the latitude to arbitrarily cut the scope or redefine the deliverables. Thus, the requirement definition (and a defined plan and definition of deliverables) provides them some protection and a way to hold the Developer(s) accountable.

I don't think that most Customers really want totally frozen requirements because there is an element of learning and awareness as the project progresses that can lead to a need for changes. Rather than everything being totally frozen, there needs to be a good process for recognizing, defining, evaluating, costing and prioritizing potential changes. It is important that the user and the developers recognize the need to manage this and to have a proper process to do it. I don't think that "frozen" needs to be a permanent state that lasts until the project is done. That would be ideal for the developers but in many cases, it isn't realistic to expect it. "Unfreezing" needs to be a very temporary state and it needs to be accompanied by revised documentation and potentially, revised schedules and costs. Once something is agreed to, things are frozen again based on the revised plan. You can't do this very often for significant changes without the project ending up in a state of "churn". If that happens, the original requirement definition may not have been good enough, the Customer may not understand his/her needs well enough, or there may be multiple people involved with different views.

[mommabear]

I appreciate your input; I definitely have a better understanding of the aspects. While I am in school still, this wasn't any assignmen; this is just my own curiosity and wanting to fill in some blanks.

To summarize:
Customer POV - Defining and freezing requirements allows Marketing to start positioning the product to the customers; it helps them present the product capabilities and validate their initial requirements.

Engineer POV - You can't start shooting until you have a target.

I hope I understand you correctly.

Follow on question, if I may; how does this change in the Agile methodology, where nothing is ever static?

[jwenting]

if there's no requirements, there can be no product.
In an "agile" environment, there should still be requirements but they'll be broken up into chunks that are small enough to fit into a short iteration of a few days or weeks.

Of course in reality many people use the excuse of "being agile" to avoid planning and essentially working without knowing what they are working on.
These people inevitably fail, but often it takes a long time if they have a good marketing and management team that's expert in getting venture capitalists to keep sending in the blank checks.

In my experience it's marketing that's responsible for most changing requirements and scope creep. However much we as techies give them, they always want more and they always want it in a shorter timespan, and always want changed what we've already done to their prior specifications without taking into consideration the time and effort needed to make those changes.