This is the final instalment in the Beachcamp series. We talk about the requirements structure which helps produce complete requirements.

Beachcamp: Day 9

Quite often in large and complex projects a business analyst deals with the stress of identifying the “right” set of requirements. It is easy to lose track of the details, as my own experience shows. For this reason, I suggest using the following approach to ensure that there are no oversights.

All stakeholder needs should be transformed into high level requirements. These requirements should then be mapped to functional areas of the proposed solution to ensure that nothing has been missed at this level. It is an important checkpoint as it defines project scope and investments into the project.

After the first checkpoint, you are ready to work on business requirements which specify the required capabilities of the future solution. These capabilities should be confirmed with the business and then converted into business requirements with links back to the rules at the top of the triangle. This step establishes good traceability of the requirements.

When the business requirements have been confirmed and approved, it is time to package them into use cases and add functional and non-functional requirements allocated per functional area. In doing so, you will create delivery packages (this is similar to Scrum). By adding complementary information about the GUI and other details, you can simplify the task for software developers and other specialists involved into the project.


As you see, each new iteration improves the solution specification. It creates additional value to the business by providing well developed documentation which will be used by staff in their daily activities.

This step seems to be obvious but modern approaches (Agile and Scrum, for example) tend to ignore documentation and instead emphasise the speed of coding and thus fast “delivery” of a solution. However, my practice shows that these approaches do not always result in a positive outcome.

Conclusion

This post concludes the Beachcamp series. We went through each knowledge area specified in the BABOK and discussed the key objectives and tasks within these knowledge areas. I hope you’ve learned a lot from the series and the knowledge area maps provide a useful reference for you.

Please remember that business analysis is a complex endeavour and there is a lot to be learned beyond what is described in the BABOK, so I encourage you to check out our products and the rest of this blog.