When I first started my consulting business, I intended to focus solely on understanding the capabilities of legacy systems. Unearthing requirements had become a bit of a pet passion of mine and I realized that in every BA role I’d had in years prior, I was always trying to find a way to better understand what existed today as a foundation to help us build a more solid and valuable future.
Little did I know this task had a special place in the BABOK – Maintain Requirements for Re-Use. The purpose of this task is:
“To manage knowledge of requirements following their implementation.”
OK, so a lot more goes into understanding the capabilities of legacy systems than reusable requirements, but reusable requirements are the primary output of this initiative.
(This post is one installment in our Journey Through the BABOK with BA Stories series.)
There is significant value in maintaining requirements for re-use. The activity can save future business analysts significant time in rediscovering requirements. It can also help speed up the requirements development process for future initiatives by helping provide ready-at-hand answers to questions about business rules, logic, and even, “Why did we do that?” (provided your requirements are documented with some context).
However, even slightly out-of-date requirements quickly lose their value. If you can’t trust the information you find in the requirements document and need to confirm it, the requirements become merely one more source of information, not the authoritative source of information.
Yet, often we do not have time during or after our projects to update requirements specifications or create “as is” system documentation. And, the requirements for one project tend to supersede those of the last one, meaning that project documentation is not necessarily the best way to capture this information.
I’ve started initiatives to have a central repository, much like Adriana describes in part 2 of her article on knowledge sharing strategies, in a few organizations. In one case, I slowly built a repository of use cases, taking each project assignment as an opportunity to discover system functionality in related areas and add it to the main source of requirements documentation. A couple of years later, I was surprised to learn that someone had picked up this documentation and used it as the starting point for a strategic project, which I felt validated the effort I’d put into the materials! While it was likely that some of the content was out-of-date, the structure I’d created for the requirements (another topic we’ll address from the BABOK perspective) proved useful in understanding the system functionality.
In another organization a BA I worked with, started a collection of wiki pages to capture key requirements and business rules. In another, I delegated this effort primarily to the test team, where their first task in supporting a new organization via our quality assurance process was to build a set of functional areas to regression test that were eventually elaborated into specific regression tests.
>>See What These Requirements Documents Look Like
Would you like a starting point for approaching common business analyst work scenarios? Along with work samples so you can see what a typical requirements document looks like? Check out the Business Analyst Template Toolkit – all of the requirements templates are fully annotated and editable by you, giving you a great starting point for starting your first business analyst project or formalizing your work samples.