Yesterday, I talked about user requirements.
In the world of requirements, even if you do a great job gathering and analyzing requirements, there will still be a couple of gray areas. There may be a couple of reasons for this. The main reason is that this is a new system that you are developing to replace an old one (or a system of workflows), therefore, there will be some unknowns.
When writing requirement documentation, you want to ensure that you capture those and present them to your client. These are known as assumptions, dependencies, and constraints.
During a workshop, someone asked me what she should do if she doesn’t get all the information that she needs to complete her requirements. I told her that assumptions were the best way to cover these unknowns, and make the client responsible for saying if the assumptions are correct or not. It’d be great to have the client look at these before you finalize the requirements. However, we both know that we don’t live in a perfect world.
Assumptions are circumstances that you are assuming to be true in order for the project to be successful. For instance, there was one project where the client would not tell us the hours of operation (I still don’t get why). Therefore, we wrote an assumption to cover this, so that the client couldn’t come back later saying that we should be operating 24/7. It read like this:
“We assume that the hours of operation are between 7:00 a.m. and 9:00 p.m.”
The best way to describe dependencies is to talk about work-breakdown structures (WBS). WBS is a way to breakdown larger tasks into smaller ones. When you are planning a project, you use this breakdown and add resources and cost. You link tasks together that shows that in order for one to happen, the first has to occur. It’s the same with dependencies.
Dependencies are relationships between requirements. A linkage that shows that one requirement is dependent on another. A great example that I found online is:
“It is assumed that Cortex will be Posix.4 compliant , depending on the future availability of CORBA on Posix.4 compliant operating systems. Meanwhile, Cortex will run on some UNIX operating systems such as Solaris and HP/UX.”
This shows that the system will be compliant depending on access to future versions of the system.
Assumptions and dependencies are usually put in the same document section. The reason is that they usually correlate because your dependencies are usually dependent on your assumptions.
Constraints are needed so that you restrict the scope to something that is true and manageable. When I say true, I mean that the client can’t come back later saying that you need to add 100 more requirements.
A good example: The proposed system will only be used by Company X’s employees
Yes, it’s a cheesy example, but it is an easy way to show you that constraints are not bad; they are usually good. I had one company who didn’t want to have any constraints because they were afraid the client would frown upon them. What happened? A scope was never really defined, so last minute, the client started adding all these requirements and “nice-to-have” features. It wasn’t pretty.
Assumptions, dependences, and constraints can aid you in developing requirements that are within scope. It also helps cover the gray areas that will always be present in requirements gathering and analysis. Use them. They are your friend.