Requirements Language

As we collect requirements we are going to need to perform some sort of evaluation.  We know the attributes of good requirements, now we will compare those attributes against the documented requirements.  However, we will not stop our evaluation at the type of language. We will extend this evaluation to other areas that can cause difficulty for the effective and efficient development of the product.

Perspective 

We are likely to have multiple stakeholders and customers that will drive the end product expectations.  Experience suggests this multiplicity and diversity of input can put the product requirements at odds.  In other words, some requirements that conflict with others and customer prioritization of the requirements may also be in conflict.  We will then need to juggle the requirements that make it to the final product and further refine those; specifically, what appears in which instantiation of the prototype or product iteration.  To do effectively, we will need to balance stakeholders as well as their respective priorities against time, cost and risks to the project.

Conflicting

Our evaluation efforts should find conflicting or contradictory requirements. These are opposing requirements that may be born out of the variation in our customer’s use of the proposed product or even the stakeholder’s perspective of the product.  We will talk about stakeholders more in the next blog post.  We will use tools like Quality Function Deployment and Pugh Matrix to help uncover and understand these conflicting requirements.

Technical Dependencies

The evaluation also allows us the opportunity to understand the technical dependencies of the requirements.  We will not only weed out what does not belong, we will also understand the interactions of the various requirements as it is related to the development of the product.  This provides the development team with learning opportunities that will help in the planning and the development of the product.