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.