An Ingredient in a Requirements Center of Excellence: Documenting Software Requirements Methodology

ArgonDigital - enterprise automation experts

Share This Post

We’ve posted on the creation of a Requirements Center of Excellence (COE) recently because our clients have expressed interest in COEs to help mature their organizations and their business analysts’ capabilities. And one of the primary resources – a key ingredient, if you will – for an RCOE is a documented requirements methodology.

I’ve recently worked on a project where our client has asked us to assess how their organization is doing with regards to requirements. Like many firms with complex projects, they experienced some failed projects in the past year, and hence wanted to shore up many parts of their software development organization, including their requirements processes.

I was delighted to hear from the customer that they do have defined requirements management guidelines…that is, until they sent me a 96 page document. While I was thrilled that they had a documented process, I was completely overwhelmed by the pure size of the document. Once I started to review the content, I faced a wall of words. 96 pages of words. Yeah, there were a few diagrams buried in the document, but for the most part, the document contained pure text describing their requirements process.

So the challenge is that if I’m intimidated by this document, and I am fairly experienced with requirements methodologies, can you imagine what the new business analyst who was just hired feels like? To wade their way through a document of that size will be an endeavor unto itself. And it is simply not possible to find a small bit of information about a particular topic easily. Essentially, the document is not consumable in any way.

The sad part is that there is some really terrific information that is buried in that document. Unfortunately, that information is hard to find, especially to someone who may need it quickly. 

So, what is the solution?  Put your methodology information into some sort of intranet.

We use SharePoint, but any sort of wiki type of software works well. Keep the pages short and limited to one topic, and use  pictures and graphics (visual aids) to enhance understanding.

By having each page as an individual topic, this allows for all information about the topic to be consolidated.  Consider establishing a template so that all information is shared in a common format. This makes it easier to find specific information about a topic. For example, a typical template may be:

  • Description
  • When to use
  • When not to use
  • How to do
  • Examples
  • Links to templates
  • Related topics

Documenting and describing your methodology in this way makes it consumable for others. It makes it easy to find information easily and quickly. And since it is consumable, it enables your organization to use the information, which helps enable adherence to your requirements methodology, helping your organization take another step towards maturing!

An added resource: for a high-level look at the strategic value of a Requirements Center of Excellence, download the PDF here – https://seilevel.com/requirements-resources/

More To Explore

Business Objectives Model

How to Create a Business Objectives Model

The Business Objectives Model (BOM) is a foundational model that helps you define and manage the scope of your software development projects. It bridges the gap between the business problem

ArgonDigital | Making Technology a Strategic Advantage