The language of requirements is a challenge to explain: there is an art involved in writing declarative statements that specify what needs to happen without inadvertently limiting the implementation.   Certainly, the choice of words is important: words like “select” and “supply” are more vague than “click the radio button for” and “type into the text box,” but there’s more to it.  I’ll elaborate on that in a future post.

I continue to be more convinced that multiple methods of delivering requirements are needed to draw a complete picture.  So even though one might have the language challenge under control, various types of models (both graphical and verbose) can help to provide views into the system’s requirements from all sides.  But how do they relate to each other, and how do the models relate to the declarative statements that provide the granular detail of what is needed?

The methodology I’ve seen implemented most frequently, when boiled down to brass tacks, is just interviewing and observing users and identifying requirements, and then backing them up with more intricate system models.  The more I reflect, however, I think there may be a smarter way.  One approach I’ve seen from a few sources is to depict the system’s primary uses in the form of use cases, which can be further broken down into any number of scenarios that depict the use case with specific input values and paths through the use case; and then, writing requirements that support each use case.  One point made in a highly recommended article at TechTarget.com is: requirements that don’t tie back to a use case may be a warning sign of missing use cases.   Working through a deliberate methodology like this might be a  step towards preventing any significant gaps in requirements capture.

The above article from TechTarget also considers data elements, and recommends entity-relationship diagrams to zero in on the data elements.  As a product manager, I see that fitting in a little deeper into the cycle at the business analysis/design stage, not at the customer requirements/analysis stage.  What do you think?