Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Government, Requirements Management, Scope Management
Do you write effective requirements?
Do you write effective requirements?

Every project has requirements. Requirements are important since they define compliant project deliverables. A simple way of thinking about requirements is that the requirement itself must be married to the verification data to ensure compliance. Said differently, we must ensure that our project requirements are verified for compliance. A simple acronym to use is SAVE the DATE. Sounds a little corny, but if you remember it, you will write effective requirements.

The first word we will use is SAVE. Each requirement must be Specific, Achievable, and Verifiable at some Event. Most of use write specific and achievable requirements. But we must also think about how we will verify compliance and when. This is as important as the requirement itself. If the requirement can't be verified, then what are we paying for? Requirements such as "The contractor shall use the minimum number of parts..." or "The contractor shall use the maximum number of..." aren't verifiable. What is the minimum or maximum number? It is any number the contractor proposes. Be specific.

Next, how will we verify compliance? This is where DATE comes in. Verification methods include Demonstrate, Analyze, Test, or Examine. Pick one or more methods to verify each requirement. Once a verification method is selected, we must specify when you are going to verify compliance. Often times, the verification event is the date of project deliverable receipt. But that is not always the case. Larger projects can have a several different test events scheduled throughout the project. Everyone including the project team and the developer should have a clear understand of what the requirements are and how they will be verified. This is effective requirements writing.

All of this information can then be grouped in a matrix that includes the requirement number, the requirement description, the verification method, and the verification event. Then, as verification data is gathered, we can check each requirement off the list until we have met all of the project requirements. We call this a verification cross reference matrix. Clean, simple, and organized.

Do you do this in your organization or do you have a different strategy that is equally effective?
Sort By:
I do not agree with you. Sorry if I missunsdertood your point. The requirements have to be written as well formed requirements. To understand that people can read IEEE Std 1233 standard. Second, when you have that on hand, you have to perform project quality activities as defined inside your project quality plan. Those activities, if you decide to perform them on requirements, are quality assurance and quality control activities. To the first one, you have more than the quality attributes you stated. People can search for IEEE Std 830. But first of all, what project manager needs to understand, is that she/he is focused on project requierements not on product requirements. And project requirements (the project scope) is derivated from product scope. The business analyst is the role that will define the product scope.
I really appreciate your feedback Sergio! And thanks for pointing out IEEE Std 1233. That document does go into great detail about what makes an effective requirement. It does specify that requirements must be testable. That was really the point of my posting. All too often, people don't think about how the requirement will be verified.

I work on large government projects that tend to have hundreds, if not thousands, of requirements that the system being developed must comply with. And we conduct dozens of developmental and operational test events. It makes it so much easier to work with the developer when we identify specific/achievable requirements, how we will verify compliance, and at which event(s) we will verify compliance.

When you have a contract involved, the clearer the requirements and verification methods, the better. It really makes life easier for the project manager when the project team and the contracted performer agree on the requirements and the verification methods. Hence, I think that the project manager absolutely must be involved to some degree in requirement definition to ensure the requirements have been written effectively. Especially when those requirements will be put on contract. Ultimately the project manager will be responsible for bringing the project in at agreed upon cost, schedule, and performance goals. The requirements play heavily into that.

Once again, thanks for your feedback Sergio! I think we should all have IEEE Std 1233 added to our reference library to use when writing requirements. It is one more tool for us to use to successfully manage our projects.
Thanks very much to you because I spend my time in this type of forums to learn from others and improving myself. And I learnt from your comments and your statement. Thank you very much.
...
1 reply by Jason Grabowski
Mar 04, 2016 11:14 PM
Jason Grabowski
...
We are here for the same reasons Sergio. So glad that I found these forums for discussing our profession and learning along some really knowledgeable professionals such as yourself and the others the frequent this site.
Mar 04, 2016 10:42 PM
Replying to Sergio Luis Conte
...
Thanks very much to you because I spend my time in this type of forums to learn from others and improving myself. And I learnt from your comments and your statement. Thank you very much.
We are here for the same reasons Sergio. So glad that I found these forums for discussing our profession and learning along some really knowledgeable professionals such as yourself and the others the frequent this site.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"There are three kinds of lies: lies, damned lies and statistics."

- Mark Twain