Four simple tests to assess if requirements are not done

These are Business Requirements level tests that work and will improve your requirements quality irrespective of delivery methodology:

If the requirements lack context: Requirements always exist to support “what” the business wants to do, not “how” it wants to do it. The “what” part of this is the context of business process. Lack of understanding of what business processes are impacted by requirements means someone has no idea of how requirements impact each other, the impact of removing requirements, or the ability to assure that the requirements collectively are complete or will meet a specific business objective. The way a company applies context in its documentation also creates the structure of the documentation.

If the interdependency is not evident: How do you look for proof that interdependency is documented? Look for a section in the material called “dependencies”, check the “issues list”, and look for an analysis technique called a context diagram (every line on a context diagram is an interdependency). Why is interdependency so important? There are two aspects to scope: internal to the system (e.g., its functionality, the workflow and information flow, etc), and external to the system (e.g., how this system needs to interact with other systems, how the workflow being automated hands off across other departmental units). In the absence of knowing the interdependencies, you only ever know part of the story on scope, so it becomes probable that you will encounter significant scope shift on any system of any degree of complexity.

Unclear business objectives: Objectives must be Specific, Measurable, Achievable, Results-oriented, and Time-bounded (easy to remember as ‘SMART’). The absence of objectives eliminates the ability to assess solution tradeoffs, makes difficult the prioritization of functionality, and other problems. You can test if a particular function meets needs with user acceptance tests. You cannot test if the collective system meets needs unless you have clear objectives.

 

You cannot tell from the description of business need how information is going to move:   The only way to elaborate this is to ask the questions, “What information do you need to know to approve that policy?”, “what do you do with that information?”, “where do you get the information from?”, “who else do you give the information to?” etc. The more detailed the description of what the business wants to do, the more the description of process will center on how information needs to move in support of the business process. Until you get to the level of detail that is expressing information movement, you have no idea from the documentation what the business intent is. It’s easy to test – just look for the nouns. Lots of nouns used consistently when describing a step in a process mean you’re probably OK.

From an analyst perspective, you are “done” when the requirements have quality. To have requirements quality, requirements must be:

Correct – the requirement is an accurate elaboration of a documented business objective or goal

Unambiguous – the requirement has only one interpretation

Complete – the requirement is self contained with no missing information

Consistent – the requirement is externally consistent with its documented sources such as higher-level goals and requirements

Ranked – the requirement is prioritized for some purpose

Verifiable – the requirement is usable (e.g., testable) by the testers who must verify and validate it

Modifiable – the requirement specifies only one thing 

Traceable – the requirement has its own unique identifier that can be used for tracing purposes

 

Read the Article at IAG Consulting

Click here for more Business Analysis Resources