Gathering and analyzing the requirements
When a customer requirement can't be achieved with out-of-the-box functionality of finance and operations apps, then you must start the analysis stage. When a requirement is a must-have, then you need to consider customization.
The focus of requirements collection should cover all the aspects of the existing business processes as well as the future state of business processes. The whole requirement gathering and understanding process is a highly scientific approach that needs expertise and the ability to give attention to details.
You must be able to describe the future state of business processes in finance and operations apps based on a proposed solution and comparing it with out-of-box functionality.
There must always be an explicit link between business processes and the requirements. It should start at a high level for the coverage perspective, but the requirements must be collected in detail.
A business process is a collection of related, structural activities and requirements with interconnection among them, some of which can be represented in a flowchart comprising decision points and dependencies.
A subprocess is a level in a business process for each business process function. Detailing business functions starts at this level. A subprocess could be dedicated to a single functional area or it could be a cross-functional area as well.
A requirement is a series of activities, or steps within a subprocess. Organizations may leverage use case scenarios to explain the requirements clearly. A use case is a pattern of behavior and a sequence of related activities. Every organization must keep a goal of collecting the requirements as structured as possible.
It is important that you understand the importance of creating and maintaining documented processes. Make sure that the following documents will be created, maintained, and kept up-to-date to address the requirements:
- Solution design document (SDD) - This is in-depth documentation of the solution details and solution blueprint that is represented in an end-to-end flow diagram showing all the solution elements that are envisioned and agreed to be leveraged moving forward.
- Business requirement document (BRD) - After the SDD is prepared, you should revisit the original business requirement document, to ensure that all the business processes and subprocesses are covered, and that all the requirements (functional and non-functional) are addressed.
- Ensure all documents are SMART – You should clearly describe the project objectives in a SMART (Specific, Measurable, Achievable, Repeatable, and Time bound) format.
- Project plan - A project plan is a roadmap document on how to achieve the objectives in the implementation phases. A project plan must facilitate a concise and effective communication. The project plan must define the Work breakdown structure (WBS), which identifies all the work that needs to be done to complete the project.
- Communication plan- The plan should formally define who should be given specific information and when that information should be delivered.
- Quality and acceptance plan - This plan secures the acceptance of the deliverables and identifies the external dependencies, as these may directly or indirectly impact the project plan.
- Change management plan - You need to capture the change request in a log, with adequate information to answer questions about why, what, who, where, and when.
- The fit-gap review - The fit-gap document is the primary input document to write the Functional Design Document (FDD). It is important to review the fit-gap document in detail before starting with the FDD.
- Functional Design Document (FDD) - This document describes the features of the customizations. The document can include things such as flowcharts, screenshots, wire frames, and will contain an organized list of requirements that can be used for development, testing, and client sign-off. The process of the fit-gap review session is critical prior to writing an FDD.
- Technical design document (TDD) - After the functional design document is completed and signed off, the development team needs to start writing a technical design document. It includes information about the programmatic approach of how a particular requirement will be implemented. TDDs are prepared primarily by the developer for the final development.
- Define use case scenarios - This describes a business process in detail. This consists of sequences of tasks and includes decision and conditional steps.