Blog

One of many improvements the latest version of Microsoft Dynamics Sure Step methodology has brought along is the revised purpose of the Functional Requirements Document (FRD). This document has long served as cornerstone of every Analysis process of every implementation project: it was the main deliverable of the Analysis phase and it both documented customer’s requirements and explained how they will be met with Microsoft Dynamics NAV solution.

Typically, it was first drafted after detailed Gap/Fit Analysis has been conducted. If a project was a complex one, this was some time half way through Diagnostic phase; generally it wasn’t until early Analysis. In any case, it always followed the Gap/Fit Analysis, and served as a detailed explanation of:

1. Business processes relevant for the new solution
2. Results of Gap/Fit analysis: resolutions for gaps and configuration for fits
3. Data migration requirements
4. Data integration requirements
5. Software and hardware requirements
6. Security requirements
7. Testing requirements
8. Training requirements

Obviously, this document didn’t only answer the question What, but to a significant extent it also dealt with How, especially, in the gap resolutions and fit configurations.

When it was completed this document was probably closest to what PMBOK refers to as Scope Statement: it specified the detailed product and project scope, and served as basis for development of project work breakdown structure. Finalization and customer acceptance of this document was a major implementation milestone: it marked the end of Analysis phase, and moved project further to Design phase.

And now for something completely different.

Latest version of Sure Step has redefined the Functional Requirements Document and considerably changed its purpose.

Let me try to sum up the major differences between old and new Sure Step view of FRD:

1. In (new) Sure Step, you will never draft a Functional Requirements Document during Diagnostic phase. The closest the Diagnostic phase will get you to functional requirements is the requirements worksheet, called Functional and Non-Functional Requirements Spreadsheet. This document will later serve as input to many requirements document you’ll write during Analysis phase.
2. All non-functional requirements have been taken out of this document, and moved to another document called Non-Functional Requirements Document. Main difference is that functional requirements address business processes and how they map to standard solution, while non-functional requirements address primarily infrastructure: security, integration, platform, interoperability, performance, etc.
3. Functional Requirements Document now only answers the question What. It explains what must be achieved in the new system, and it doesn’t bother with explaining how.
4. Functional Requirements Document is now input to detailed Fit Gap Analysis (notice that Gap/Fit Analysis has been renamed to Fit Gap Analysis). This is a major development of FRD concept: since it merely explains what are the requirements, the task of detailed Fit Gap Analysis is to explain how these requirements will be met—and only to an extent, final answer to this question comes in the Design phase when design documents are written.

Functional Requirements Document is still one of the central documents of the Analysis phase, however it’s focus has been narrowed down, and its purpose has been redefined. Its position in the analysis process now seems more logical: it makes more sense to document the requirements in a structured, understandable and presentable way, and then to analyze them in detail against the standard functionality of Microsoft Dynamics NAV. How a requirement will be met doesn’t have to be documented together with the requirements, and it is better if it is documented separately elsewhere.

In my opinion, with Fit Gap Analysis being conducted after Functional Requirements Document has been finalized, the flow of Analysis phase is more logical: scope is determined first, then it is developed and clarified further during Fit Gap Analysis.