Stated Requirements vs. Actual Requirements

In the beginning of my business analysis career, I struggled a bit understanding the true difference between stated requirements and actual requirements. It seemed that the majority of conversations I heard at the time was along the theme of "that is JUST a stated requirement." It sounded like it was being treated as a second class citizen and its value shouldn't be given that much weight. While exploring a couple other pillar requirement topics, I gained a deeper understanding of stated requirements. 

From 2010, Bogie and I take a trip to Mount Dickerman on a fantasic day hike.

From 2010, Bogie and I take a trip to Mount Dickerman on a fantasic day hike.

In short, the difference can be about an evolutionary process. I realize that this might sound like a hot mess of a thought string but perhaps the point I’m trying to make will become more clear via the below narrative. 

One of the main components of active listening is paraphrasing what you hear in your own words. This technique allows a stated requirement the ability to evolve into a more defined state. This concept really takes form in situations such as: 

- stakeholder states a requirement
- the BA restates that requirement
- the stakeholder restates the BA restatement
- (wash-rinse-repeat as necessary) 

and finally a stated requirement has evolved to the point in which everyone has a shared understanding of its true nature and personality. 

Requirements, although they look amazing at the time, may not be actual requirements until they have been modeled. This is another transformation that is evolutionary in nature. The act of modeling the requirement(s) leads to a greater understanding and this process changes them from the original state to actual requirements to be baselined for project implementation. 


© 2017 Dwayne Wright