What Are Requirements?
Requirements - by secretlondon123 via Flickr
Requirements are descriptions of the end-result of your project. They are a way to gain consensus on exactly what it should do, and impose some constraints as well.
Good requirements DO NOT impose a particular solution unless there is a valid business reason. Let me explain.
A Tale Of Two Requirements
- Perform [function] with less than [some constraint or specification] delay using [specific software program or system].
- Perform [function] with less than [some constraint or specification] delay.
I am NOT saying these are great examples of requirements, I could do a whole training course just on the topic of requirements. Just note that in the first example, the requirement mandates a particular solution. This may be valid, but watch for it like a hawk.
Many times, the solution is assumed. Instead, it should be up to the experts on the project team to figure out the best solution.
Oh, and if you want some more info on this topic, keep the following in mind and click through to the article:
Good Requirements ARE SORTA NUTS
Easy PM Definitions
- Easy Project Management Definition Series
- What Is A Project?
- What Are Requirements?
- What Are Stakeholders?
Jul 8th, 2009 at 10:19 pm
Hi Josh,
Not sure if your description is complete enough. Generally speaking (from construction) there are 4 different types of specifications:
1) Proprietary Product Specifications (sometimes called Commercial Off the Shelf specifications)
2) Method Specifications (they tell the seller how the buyer wants something done);
3) End Result Specifications (the owner (buyer) tells the seller (contractor or vendor) what he wants the product to do at the end;
4) Performance Specifications (which tells the seller what performance criteria (i.e. mean time between failures, caller access times, drop rates etc) they expect the product of the project to meet or fulfill.
Essentially, specifications are intended to serve two fundamental purposes:
1) They provide sufficient information to potential bidders (sellers) so they can create an accurate cost estimate (bid)
2) After award, they form the basis for contract performance measurement.
My reason for adding this to your post is because first hand experience indicates that very few buyers (owners) realize there are more than one way to specify what it is they need or want and more importantly, because there is a clear correlation between the amount of scope defined and the appropriate contract type (i.e. Firm Fixed Price, Cost Plus etc) we see clients often trying to use FFP type contracts with insufficient scope definition.
To learn much more about specifications, I would urge you to visit the Construction Specifications Institute (CSI- http://www.csinet.org ) All kinds of “best practices” in specification writing can be found there.
BR,
Dr. PDG, Jakarta
http://www.getpmcertified.com
Reply
Jul 8th, 2009 at 10:40 pm
PS; To preempt any complaints that I “missed” or ignored some of the types of specifications, there are many different names some of these go by (i.e. End Result specifications are often referred to as Technical Specifications)and within each broad category there are often sub categories (i.e. under Performance Specifications, we find a sub category called Warranty Specifications and under that heading, we find Labor and Materials warranties (which are very common in nearly all contracts) and more frequently, contractors are being required to guarantee or warranty peformance for some number of years. (i.e. similar to an automobile, 5 years or 500,000 KM)
There are also Military Specifications (MILSPEC) which are even more convoluted, but generally speaking, fit within one of those 4 major categories.
Also appreciate that in most contracts, while one method will predominate, the specifications are often combined. (especially end result with performance specifications)
BR,
Dr. PDG, Jakarta
http://www.getpmcertified.com
Reply
Jul 8th, 2009 at 11:36 pm
Twitter Comment
PM Student: What Are Requirements? [link to post]
– Posted using Chat Catcher
Jul 9th, 2009 at 10:58 am
Josh,
IEEE 1220-1994 is a good starting point for requirements.
I’d suggest that the requirements elicitation paper at SEI is another “must read.”
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html
These approach seperate the business domain – construction, IT, defense – from the principles of requirements management. That way we can move away from anecdotal approached and get to the foundations of the problems with requirements.
Here’s a quicj post with some more resources.
http://herdingcats.typepad.com/my_weblog/2009/07/baseline-magazine-it-project-survey.html
Requirememts engineering is some domains is a profession – conducted by Systems Engineers. In other domains it’s an afterthought. And many example in between.
Most project failures – according to the research in all domains can be attributed to requirements failures in some way. This is pretty much universally agreed.
So now what? How can this situation be improved. In our domain, the requirements elicitation is moved to the Systems Engineering discipline.
Reply
Jul 9th, 2009 at 11:59 am
And this would be why there are so many failed IT Projects?
When convoluted and technical terms are introducee into a requirements document, the business people glaze over and relinquish ownership to a technical person to write the requirements document. Consequently the specification document is technically sound but lacks business requirements.
I have rarely seen a project fail because the tecnical specifications were inaccurate. I have however, seen many projects fail due to poor business and user requirements (specified by the wrong people), inaccurate success metrics (performance metrics)and poor choice of Vendor selection.
Business specifications or requirements are exactly that – business and user requirements and should be specificied ONLY by those pertinent people/parties. Not by a self appointed person that believes that he/she knows what the business and users require.
Project specificiations or technical requirements are specified by the technical team, systems architect etc and detail technically what is required for the system to work and how.
Question. Who gets the blame when the system doesn’t deliver what the business thought it was going to deliver?
Answer? Not the right person/people/party. Not the business person/people that should have specified their requirements. Perhaps the Project Manager, techie or Vendor? Why?
Kind regards
Sarah
Reply
Jul 14th, 2009 at 9:25 am
Sarah,
To answer your question – “who gets blamed” – needs to look at the organization of the Project.
In successful IT and other complex programs, the management team must be structured in for success.
The Book Project Delivery System: Fourth Edition, http://www.amazon.com/Project-Delivery-System-CH2M-Mangers/dp/0965261611/ref=sr_1_2?ie=UTF8&s=books&qid=1247584942&sr=8-2
provides good insight into how to make the connection between all the participants in a project.
Without these connections the only person(s) to blame are the business owners. It was their money and they didn’t organize the project correctly. The same answer (the business is to blame) would be for a “store opening failure,” a merge and acquisition failure, a new product line failure.
The notion that IT projects are somehow different from store openings, M&A’s, new product launches is the core source of failure.
Reply
Jul 14th, 2009 at 12:59 pm
A necessary precursor to requirements gathering (of whatever sort) is clarifying the objective. A solid objective makes project success much more likely, and requirements naturally flow from it. Engaging in requirements specification without a stated objective is more often associated with failure – and too often in the rush to show project progress via GANTT, this objective-making step gets paid too little heed.
Reply
Jul 22nd, 2009 at 3:27 pm
Requirements gathering should be a collaborative effort. Granted I’ve only worked in IT projects but the ones that worked well the requirements were good as a result of back and forth communication. Excuse me business owner, what do you mean by X or Y? Do you possibly mean Z? Could we get clarification on A? Stuff like that. I know it sounds basic and I guess it is but so important.
Though unfortunate the talk of blame is real in every situation. Sure the business owner may take the brunt of the blame but the IT department can also take credibility hits when the fit hits the shan. Teamwork, communication, clarity. Good things.
Reply