Two posts on Requirements. Two! This guy must be a major process weenie!
No, ask my friends, I am not a process weenie. Getting the requirements is the first step towards a successful project. Do this right and the rest flows like fine wine. Do it wrong and the project is a Death March to hell.
The requirements document is the root document for the whole project. From this one document, the engineers figure out what to build, and how long it will take, the marketing people figure out how much to charge, and the users figure out if they want to give you money. It simply has to be right.
Everyone who read the email had a vision in their head about the CarNet Player. You probably pictured it in the dash of your own automobile. I am also 100% confident none of us had exactly the same picture. The requirements will remove the variation in each persons mental picture until will all see the same thing. They help us remove ambiguity.
Here are my suggestions. Nothing will make this easy. Did I mention Requirements are hard?
- Read the books! Read them now, not while you are under pressure to produce the document.
- Take all the time you need. We can not do a schedule without the requirements? SO make a schedule to research, interview, and write the requirements.
- Requirements are Unlimited. Yes, unlimited. Reach for the moon, ask for everything and leave no crazy idea out. If you can not implement cold fusion, it is OK. We will trim the possibilities later.
- Get the right People. First, don’t get the entire engineering, marketing and sales team together in a big room and announce the next great thing. Get a few people who represent each group and start the process. When you have the requirements specified, you can actually answer some questions about the next great thing. The big announcement will go much better.
- Keep the requirements and business case separated. Most people think it is good to keep the requirements separate from the functional specification. We don’t want technical details in with the requirements. Along the same lines, keep the business case out of the requirements.
- Don’t confuse features with functions. Requirements specify functions. Playing audio is a function of the CarNet Player. Playing an MP3 format file is a feature. Specifying features limits the implementation.
- Don’t make a Swiss Army product. Products that do one thing and do it well work much better than all things for all people products.
- Ask inside the company first. If, like me, you are starting from scratch, there is no one to ask. If you are in an established company, interview the people you work with. Customer service is the best place to start. They will definitely have a list, and be glad to share. Sales, manufacturing, engineering, even the billing people in accounting should be considered. These people will want to talk to you, not just say ‘whatever’.
- Use a tool. If you have access to one, use it. Learn the language of the tool and use it well.
- Test the requirements. Do a review, walk through and formal review.
- Put the requirements under change control. Once you have version 1.0, don’t make changes without reviewing them. At the root document a requirement change will change many other realted documents. Use a traceability matrix to keep track of related documents.
Use Functions, Attributes, Constraints, and Preferences
This is taken from Exploring Requirements: Quality Before Design by Donald C. Gause, and Gerald M. Weinberg. Their way of classifying requirements is very helpful.
A function is the what of a product. It describes what the product will accomplish. These are the actions the product performs. For example, the CarNet Player must be able to play audio. Playing MP3 format files is a feature. Separate functions would be how it gets the audio, stores the audio, and so on.
Functions are classified as evident, hidden or frill. An evident function would be that the player must fit into a car.
Attributes are desired characteristics. These describe the product. Things like user-friendly, reliable, manufacturable, safe, and low power are attributes.
Classify attributes into Must, Want, and Ignore.
Constraints limit attributes. These are the testable items in the requirements. An attribute the product must have is limited by the constraints.
If we say the player can fit into a car, that gives a lot of leaway. Something that plays music and fits into a car would be Doug and his guitar. If it must fit into a standard size car stereo enclosure, we have constrained the size. We can put a number to it of X by Y by Z. This can be tested.
Preferences are desirable but optional constraints. Some solutions are preferable. If we can deliver all the must have attributes within the constraints we are done. That may not the the preferred solution. Preferences give us guidance. We prefer the player supports all audio formats. If it can not, we still have a product.
Make the constraints, and preferences measurable. We don’t have to know exactly what fast is, but if we can measure it we can find out.
We are done, now what?
First, test for ambiguity. Poll people about the document. When people describe the product in their own words, do they all use the same words? Are their radical differences in what they describe? If the answer is yes, back to the word processor. Schedule, number of man hours needed, and cost are good metrics to test.
Test the requirements. Do a review, walk through and formal review.
Put the requirements under change control.
Let’s Get Started
An upcoming post will be the requirements for the CarNet Player. Once that is done, we can start on the supporting documents, the design and implementing our vision. Stay tuned.
A last note
I am assuming most of my audience are engineers like myself. If you are, the next time you start a project, please get involved with the requirements. Volunteer to write them if you have to. At least try to be on the team. You’ll be making you life easier for the duration of the project.