In keeping with our requirements work, we will start by identifying the attributes of a good requirement.  We start our project off with the requirements, so it stands to reason if we start off poorly or in the wrong direction, we will not make the objective.  This situation will get worse the longer we spend time with poor requirements.

Requirements Attributes

Requirements are not loose; these are tangible statements of the product that are able to be refuted or confirmed.  As we have seen, requirements are part of our project contract closure, but it is also part of our product testing.  To be able to effectively do either of these means we must have requirements that fit the attributes defined below:

1. Cohesive
2. Complete
3. Consistent
4. Correct
5. Observable
6. Feasible
7. Unambiguous
8. Required
9. Verifiable
10. Traceable

Requirements Failures

Requirements not written in a way that meets the attributes defined above poses some level of risk to the endeavor or the project outcome.  For example, disjointed rather than cohesive requirements will result in the project participants taking conflicting design approaches or solutions to the project.  If the requirements are ambiguous we may see similar failure types as a result too varied interpretation of the requirement possible.  If a requirement is not feasible, we are spending money to do work that will ultimately produce nothing.  Similarly, if a requirement is not correct, we will spend time developing something that will work, but has nothing to do with our objective or our customer needs.

There are many things to consider when writing requirements.  We should not take the approach that all of the requirements must be written in one pass. There are many reasons for that, first and foremost being we do not know everything about the product at the start of the project.  The requirements will unfold or reveal themselves as we work to develop the product. We will discuss that in more detail in a future blog.