It is funny how when looking back it seems so obvious how you should have done something, but at the start, finding the right method or rhythm is difficult. I know my first couple of requirements documents were kind of all over the place. Most of the templates I came across (internal & external to my company) focused on making sure requirements are clear (S.M.A.R.T.) and well written, but never on their structure as a whole. After some years of experience and great mentorship, I think I’ve come to a nice and clean way to keep your requirements organized.

Keep High-Level Requirements and Solution Requirements Together

Most templates recommended organizing requirements by first having business requirements then in a separate section having functional/solution requirements. Some organizations may even separate these out into different documents.

Traditional Model

• Business Requirements
  • Business Req 1
  • Business Req 2
  • Business Req 3
• Solution/Function Requirements (traced back)
  • Solution Req 1 : BR1
  • Solution Req 2 : BR1
  • Solution Req 3 : BR2
  • Solution Req 4 : BR3

This doesn’t work well for me. Instead, I prefer a requirements decomposition model.

Requirements Decomposition Model

• Requirements
  • Business Req 1
    • Solution Req 1
    • Solution Req 2
  • Business Req 2​
    • Solution Req 3
  • Business Req 3
    • Solution Req 4

The end result can be easily diagrammed (which will look like an organizational chart) and it helps stakeholders EASILY understand why everything is being done. The breakdown may not always be just 2 levels. I find that it usually breaks down a few levels before getting to actual solution requirements. I’ll give a non-IT-centric example to make it fun (and prove that Business Analysis Does Make You Sexier!).

Lets say I’m the business and I want to look better in a bathing suit, so I need to implement a system or process to help me do this. Lets break this down

• Business Objective: Get A Beach Ready Body
  • BR1: Lower % Body Fat
    • BR1.1: Eat Less Carbohydrates
      • SR1: Throw Away Carby Snacks
      • SR2: Remove/Reduce Carbs from Regular Diet
    • BR1.2: Do More Cardio Exercises
      • SR3: Establish cardio schedule
  • BR2: Gain More Muscle
    • BR2.1: Eat More Protein
      • SR4: Stock Fridge With Meat
      • SR5: Buy Protein Powder
    • BR2.2: Lift Heavy Weights
      • SR6: Buy heavy weights
      • SR7: Establish weight lifting schedule
  • BR3: Enhance Overall Wellness
    • ​BR3.1 : Get More Sleep
      • SR8: Got to bed by 10PM
    • BR3.2: Get More Nutrients
      • SR9: ​Consume daily multivitamins
    • BR3.3: Reduce Stress Levels
      • ​SR10: Morning Yoga (30 min)

​​​​I like this method because the alternative is having to trace requirements, which gets cumbersome and usually out of sync. Then you forget why you are doing yoga every morning for 30 minutes and it gets cut from the document and you get less than optimal results because your stress levels are too high releasing cortisol which leads to fat retention… etc… you get the picture.

Some of you are asking, what about the additional details within the requirements. Those don’t have to go away. In fact, one way to do this is to use your table of contents as the decomposition structure by taking advantage of the heading levels (Heading 1, Heading 2, etc). In the document itself, you can include the necessary details under the heading levels. This structure works well with both standard requirements structure as well as user stories and use cases.  What do you think? Do you have a better way to organize your requirements?