Functional Requirements Specification: Enterprise Systems
Prior to system selection, it’s generally a best practice to generate a user requirements document to define what is required and desired in a new system. Requirements include technology stacks and platforms, user functionality, integration requirements, and security / control. (Note: I have not included the user requirements document (URS) in the list of project deliverables for enterprise systems as the URS is generally a selection document and not an implementation document.)
Even if a URS or selection requirements document isn’t created, once a system is selected and before design (and configuration), I highly recommend that the project team get an understanding of the system functionality and generate an initial draft of a functional requirements specification document (FRS) to establish a target for success. Even if all the requirements aren’t thought through, it’s imperative to get the team and the implementation partner on the same page with what is required of the system.
Don’t skip this step and don’t leave it up to the implementation partner to draft and own this document.
As the project team and implementation partner refine their understanding of the new business processes and the part the system plays in those processes, the FRS is expanded and refined.
During testing, the requirements are verified and, if necessary, updated to reflect the new processes and use of the system.
Even if the system is validated in compliance with 21 CFR Part 11, I don’t recommend approving the FRS until after Go Live when there may be additional changes to the system as a result of post Go Live system support activities. The FRS is a change management tool and when the system is handed over to the group responsible for ongoing operations, this is a key document for the management of the system.
As this is an operational document, for ease of system and change management, I recommend including test references for each of the requirements in the FRS to provide traceability to specific testing. This makes it easier for reviewers to confirm that the requirements were tested (required for SOX and GxP validated systems), and it makes it easier for anyone who needs to verify functionality during ongoing operations due to changes or implementation of new functionality.
Who creates: the internal Business Analyst assuming there’s one on the project team. If not, sections can be assigned to the functional leads and the Project Manager can be responsible for consolidating into a single document and managing throughout the project.
Who approves: for controlled systems (SOX, GxP), approvals are generally required. For others, it depends on internal business process requirements and what was defined in the Project Document. Systems subject to SOX have documents that are approved by the functional leads and Business Sponsor. Validated system (GxP) documents are approved by functional leads, the Business Sponsor, and QA in alignment with document control procedures.
When: an initial draft is created during the requirements and design sessions and revised as the system is configured and business processes are refined. A final draft should be in place prior to integrated or end user testing and revised once testing is complete and finalized/approved prior to project closeout.
What’s Included
Purpose: defines what is included in the document and why the document exists.
Scope: details what is and is not within the scope of the document and for the most part, the system, too.
Document owner: specifies who is responsible for ensuring that the document is maintained and updated for the life of the system. This isn’t necessarily (and generally isn’t) the person who will be updating it, rather it’s the person who will be approving, at a minimum. Typically, this is the Business System Owner.
General notes: I like to see assumptions and context provided for all project and system documents to provide readers / consumers with a complete picture of the document, the scope, and it’s purpose. This is the section for all of this and for anything that may provide greater clarity, assuming it’s not captured elsewhere in the document.
Related documents: a system doesn’t operate in a vacuum and references to other documents included in the FRS should be noted to make it easier to manage the system and understand how the FRS relates to other documents like tests, configuration, and change control.
Test document references: to demonstrate that the requirements were tested, I recommend including the specific test references within each FRS requirement. The testing takes many forms and a list of the test documents referenced elsewhere in the document is typically included here. It provides an easy roadmap for the reader, reviewer, or consumer of the FRS document.
Requirements: I generate a table of detailed requirements in logical grouping to make them easier to manage. I include a requirement number, the detailed requirement, and I reference a specific test to provide traceability to testing.
Abbreviations / acronyms:every system implementation has it’s own abbreviations and acronyms that others may not understand so providing a list of them and their meanings is helpful to the reader.
Approvals (if applicable): I recommend that despite the controlled status of the system (SOX, GxP), that there always be a document approver even if it’s just the Business System Owner. This section will have lines for the approver signature and date.
Other Things to Note
The vendor may generate a requirements document based on early requirements and/or design sessions and it generally only includes the elements they care about for the implementation and not for operational use. The FRS is not just a project document; it becomes a living document used to manage and control the system and therefore should be owned by the client/customer and not the implementation partner.
How long is this document?
As with all of the other documents, it depends on the complexity of the system and the requirements. The more detailed the document, the better documented the understanding of the requirements by the implementation team. Since this is a document that lives after project close out, clarity is critical. Mine have ranged from 5 pages for simple, uncontrolled systems to 30 pages for complex, validated or SOX controlled systems.
Why Share This Now? Back when I was an accountant, working for my dad’s accounting firm, we had a lot of small businesses as clients. The owners of the small businesses struggled with basic bookkeeping and accounting which meant that we couldn’t add value to them and their businesses because we were so focused on the fundamentals. We created a few accounting classes for them in the form of Accounting 101, 102, 201, and 202 so we could do more with them.
I’m applying the same principles here. If I can help my clients (prospective or current) help themselves with projects and project deliverables, then I get to elevate my role beyond the day-to-day and into a strategic and advisory role which, frankly, is a lot more fun!
Check out my blog post Project Deliverables: Enterprise Systems for the complete list of deliverables with links other blog posts.
Have Questions or Require Assistance?
Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.
About the Author
Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.
