Does Formal Requirements Documentation Have a Place in Agile?

The question above is one I have faced many times, and is usually one of the first questions Business Analysts ask when confronted with an agile method. Many times this comes not so much as a question, but as a statement like, “This agile method must incorporate our documentation.” Whether this sentiment comes as a question or a statement, my answer tends to be the same: It can fit, if it has to fit.

To be certain, Formal Requirements Documents do not have a place in all, or even most, agile environments. However, just because an organization has a non-negotiable obligation to produce Formal Requirements Documents doesn’t mean agile delivery methods are not an option for that team. While Formal Requirements Documents, like Business Requirements Specifications (BRS) or Business Requirements Documents (BRD), seem to be the opposite of agile, they are often a required part of doing business. Oftentimes this is in regulated environments, such as companies that have certain documentation as part of an ISO or CMMI certification that has been achieved, or consulting firms with contractual obligations for documentation.

The path to integrating Formal Requirements Documents into agile methods includes:

• Comprehending the underlying request or regulation for Formal Requirements Documents
• Performing a gap-analysis of desired agile work products and required formal work products
• Leveraging templates and automation tools to ease the publication of Formal Requirements Documents

The above steps provide a good framework for integrating agile and formal documentation. In reality, the first step is finding out if Formal Requirements Documentation really HAS to be produced. Although many demands for Formal Requirements Documentation are valid, many others are simply the knee-jerk response of a community accustomed to a lot of formal documentation. This is often one of the more difficult tasks in the process, and requires a touch of process analysis, method knowledge and a knack for organizational change management. However, once the requirement for Formal Requirements Documentation has been validated, I assure the team our new process will result in the required documentation and then immediately take the focus away from document-centric thinking. As with most agile engagements, the focus should be on requirements methods that capture what is needed to build a shared understanding; including the use of iteratively developed user stories and inclusive modelling techniques that enable active stakeholder participation.

Throughout the process of understanding the regulation or contract that is dictating the Formal Requirements Documentation, one will typically find the regulations rarely dictate how or when to capture the requirements, the level of traceability detail required or mandate formal reviews. Given these facts, there is obviously still plenty of room for agile methods within a formal framework. It is also important to get an understanding of which desired agile requirements components will comprise the Formal Requirements Documentation, and determine if there is a gap between the desired agile requirement artefacts and the regulatory constraints. Often additional artefacts will be needed, such as business rules or requirements pertaining to sensitive data. However, comprehension of the regulation is particularly critical in this area, as these additions are typically dependent on the risk or profile of the project. Typical examples might be User Stories (or Light Weight Use Cases), high-level business process sketches, and User Interface prototypes — all of which will be created in an agile and highly collaborative manner with the team and business stakeholders. Additionally, there might be mandated security rules or requirements pertaining to sensitive personal data that are typically created by an analyst based on industry specifications or standards.

Once a team has decided what its method will be, and completed a gap-analysis to confirm all the documentation needs are covered by the new method and work products, the next step is to look at how the final document will come together. This planning step is essential prior to the project kickoff so the Business Analysts and Delivery Teams will be able to focus on the design and build of the project rather than worry about the formation of documentation. The creation of lightweight templates and traceability matrices will go a long way toward ensuring a clean and compliant document can be produced from the agile work products. Many thought leaders in the space strongly advocate for templates, like Mike Cohn’s widely used User Story Template: “As a [end user role], I want [the desire] so that [the rationale].” Beyond the traditional benefits these templates give a team, they also become very important in the final assembly and publication of formal documentation.

A vital component to creating Formal Requirements Documentation from an agile project is automation for requirements traceability, version control and document publishing. There are many tools on the market that can assist with this, or custom applications or scripts can be used. Without some sort of automation, creating the Formal Requirements Documentation will become an onerous manual process. The proper level of automation will allow a team to quickly extract, assemble and publish a formal document from a collection of agile and mandated work products. The ease and quickness of automation is what allows the formal document publication to keep pace with the agile method — allowing for publication of new formal documents as often as the team sees fit or the regulations mandate. A typical scenario is to produce a formal document at the beginning and end of every sprint in order to capture the normal changes to requirements and prioritization that takes place during an agile sprint.

In summary, Formal Requirements Documentation can absolutely be integrated into the agile process, becoming just another by-product of an agile delivery team.

One good technique to achieve this is to:

• Gain deep understanding of the regulations
• Perform a gap-analysis of the agile work products and the mandated documents
• Use templates and automation for traceability matrices and document publishing

While this type of hybrid method is often frowned on by some ‘agile purists,’ I find it extremely agile to acknowledge that one process does not fit all, and a bit of flexibility is usually the answer.

Don’t forget to leave your comments below.

---

Kurt Solarte is a Managing Consultant working for IBM Australia in Sydney; focusing on Agile Development methods. Kurt recently spent eight years with IBM Global Business Services in the U.Ss as a Sr. Business Analyst; where he specialized in keeping business analysis alive and relevant in the agile delivery of eCommerce, web portal, and business analytics projects.