October 1, 2020
This article is the second of a three-part series, “ Selecting an Automated Compliance Management Software Platform.”
Requirements gathering is central to the success of the compliance software selection process. The project team (with input from users, regulators, and industry experts) turns the needs of the organization into actionable requirements outlined in the project plan.
The solution must align with business goals, compliance requirements, and stakeholder needs. Therefore, it’s critical to determine the business requirements before you start interviewing software vendors. Once you have established and documented why the system is needed, who is involved in the project, and when the system is required you can then define the requirements for the system.
Define High-Level Success Criteria Early
At the highest level, the project team must establish key objectives and business requirements. These should be clearly stated and quantifiable.
Examples of success criteria:
- Monitor and eliminate the risk for regulatory violations
- Decommission old system by [date]
- Reduce audit preparation time by at least 50%
- Maintain a continuous state of compliance
- Replace legacy XYZ system
- Centralize Reliability Statistics and eliminate spreadsheets
All of your goals should be visible throughout the selection, planning, and implementation of the software solution. In addition, the goals should be identified as short-term, medium-term, or long-term. Anything that does not directly contribute to achieving the defined success criteria should be marked as “nice to have” rather than being a defined objective in the solution scope.
A compliance management system implementation can be complex with many moving parts and multiple criteria for success. Consider how your system needs to accommodate changing regulations, system growth, and expansion, changing SOPs, and other adjustments. Going forward, you’ll need to take an agile approach to accommodate incremental changes that rapidly adapt to changing requirements.
Define Solution Scope: Functional and Nonfunctional Requirements
Within the project plan, the solution scope focuses on defining both functional and nonfunctional features, characteristics that are needed for the compliance software to work. The time and detail invested in the solution scope (system including inputs, behavior, outputs) will make your project expectations and outcomes more predictable.
Functional solution requirements are the characteristics required in the system that will help you meet your compliance requirements and business needs. They describe the way a product must behave.
Guidelines for documenting functional requirements:
- Focus on what the system needs to do, not how it should do it. Different software solutions will solve the same problem using different approaches. Evaluate the system not on how it does something, but rather, how well it does something.
- Get input from all stakeholders. Not only does stakeholder input helped guide the system into what it needs to be, but it also focuses on functional considerations that will promote adoption among users.
- Use a weighted ranking system to assign importance to different system requirements.
For example:
- Mandatory=1
- Should Have=2
- Nice to Have but not Required=3
Nonfunctional requirements are the quality attributes and general characteristics of the software. Nonfunctional requirements are often hard to quantify but are essential to judge the operation and performance of a system rather than specific functionality. While not related to performance as defined in the functional requirements, they are important elements to consider in the overall project scope.
Comparison Chart: Examples of Functional Scope vs. Nonfunctional Requirements
| Functional Requirements | Nonfunctional Requirements |
| Business Rules | Positive User Experience |
| Authorization Levels | Access Changes |
| Audit Tracking / Audit Trail | Legal and Regulatory Adherence |
| Change Tracking | Successful Production Launch |
| Administrative Functions | Scalability |
| External Connections/Interfaces | NERC / NERC CIP Compliance |
| Data Controls | Access Logs |
| Electronic Signatures | Data Integrity |
| Certification Requirements | Interoperability |
| Reporting Requirements | Testability |
The Search Begins: Shortlisting Vendors
Once the criteria and requirements are documented and understood by the project team, it’s time to reach out to software vendors. The goal is to get a clear understanding of what each potential vendor has to offer in an automated compliance management solution. This includes how well the solution aligns with your requirements, implementation methodology, cost, and resources.
Be sure to review multiple vendors without bias. You can learn a lot from this process; perhaps a vendor has a good product that you didn’t know about. Maybe a vendor that comes highly recommended doesn’t meet half of your priority requirements. Some vendors may offer features that you hadn’t been aware of. This also enables vendors to anticipate needs you may not have considered and ask the right questions during the requirements gathering phase of a project.
Use the checklist below as a start point in your vendor research/evaluation process.
Click the evaluation checklist thumbnail to open in a new window.
Conclusion:
Creating a requirements document is the foundation of any software project. It defines the expectations and scope of your compliance management system. It establishes a common vernacular, minimizes scope creep, and creates a mutually agreed-upon project plan that meets business needs and expectations.
Compliance management is a systematic, continually evolving, and changing process. Throughout your journey, the people on your team, your processes and requirements, and your project plan will be critical for your success.
