At netlogx, our team works with various government organizations at the local and state level, offering reliable solutions for various challenges—especially as it relates to large-scale system changes. As trusted consultants, we aim to tackle changes by implementing a smooth transitional process strategically backed by data and the right consultative support.
When finding and delivering the best solutions for our clients, it is imperative that we first identify both the functional and technical requirements for the business system. Without first eliciting the need for the change, the system will not ultimately align with overarching business goals or with efficient business processes.
Let’s dive into how to set up your organization for success when preparing for a large-scale system change or technology modernization.
Differentiating Functional vs. Technical Requirements
First, it is critical to note that functional requirements differ from technical requirements. While serving different aspects of the system, they will ultimately ensure the proper business processes are identified and successfully implemented.
Functional requirements describe what a system is supposed to do. In contrast, technical requirements describe precisely how a system will achieve the goals set by the functional requirements. These two factors are interconnected, describing what will be built within the system to perform the needs expressed by the business. For example, a functional requirement could express that the system needs the ability to store patient information, whereas a technical requirement could convey that information needs to be stored in a relational database and the system needs to have 99% uptime.
In short, functional requirements focus on the purpose of the system, while technical requirements focus on the necessary action of the system.
How to Identify Vital Business Requirements: Start by Asking “Why?”
Business Process Mapping
There are a variety of methods one can utilize to elicit requirements. Typically, we start with business process mapping to define the business processes that the system needs to support in the future.
Business process maps help us define at a high level what the system will need to do, prompting the requirements to become a more detailed description of those goals. Since business process mapping opens the floor to collaboration, it usually poses critical questions about the system. In this scenario, the best way to approach this analysis is through curiosity and consideration. For instance, if group conversations uncover requirements that will be needed, we will note and document them.
Acknowledge Interconnected Requirements
Next, we identify other system requirements that can help set the baseline for the project. For example, when designing an Electronic Health Records (EHR) system, we will identify the system requirements (functional and technical) or requests for proposals (RFPs) for other EHRs around the country. From there, we review the business processes and map requirements to each step of the process, ensuring that there is a requirement describing every aspect of what the system needs the ability to do functionally. Although this is a tedious process, it is necessary for accuracy.
Reviewing the Process (with the Appropriate Parties)
Process management is not always predictable. Sometimes, we may encounter process steps that lack a corresponding functional requirement. In that case, we must define the requirements from scratch. Once we have compiled a list of requirements, we schedule meetings with the relevant subject matter experts (SME) to review the requirements and refine them to meet their needs. Notably, we categorize each requirement to determine which SME is appropriate for the review process.
For example, if our consultants review billing requirements for an EHR, we would intend to meet with the finance team rather than the medical staff. In contrast, when reviewing the technical requirements, we typically meet with IT experts or system administrators who provide their expertise on the technicalities of the system.
After reviewing all the requirements and receiving the sign-off from the relevant stakeholders, we finalize the list of system requirements.
What to Include in a Business Requirement Document
The business requirements document is a robust collection of every categorized requirement and is often used as a reference point by all parties involved—including stakeholders, developers, and external consultants.
Typically, the netlogx team builds a requirements traceability matrix (RTM) that lists all requirements, categorizes them into functional or technical requirements, and further categorizes them into the appropriate vertical from there. The RTM often contains historical versions of older requirements to ensure that the original intent is not lost as a requirement evolves. This information maps it to the appropriate business process. Additionally, the requirement will have an associated priority so the developers understand the importance of each requirement—especially during the RFP process—to select the best system for our clients.
netlogx prefers to follow a three-prong priority system:
- The requirement must be met exactly as it is written
- The requirement needs to be met, but the team remains open-minded to how it will be fulfilled
- The requirement is nice to have but not necessary
Establishing the RTM benefits everyone involved in the project. It instructs the developers on how to build the system while providing the client with a blueprint they can use to hold the developers accountable. It also helps the testing team define testing criteria and use cases for testing. This allows everyone to work from the same source of truth for a successful project.
The Impact Business Systems Have on Organizational Success
The list of requirements for the business systems acts as a roadmap to a successful project. When the functional and technical are clearly defined, this helps to keep everyone on the same page to complete the goal. If you don’t have requirements and work from business process diagrams or something less substantial, there is inadequate documentation to build a system. This leaves your team with no description of what the system needs to do or how to do it. Imagine building a house without a blueprint… it has the same effect.
Not having clearly defined requirements can cause a project to fail because everyone will inherently interpret things differently. What often happens is that the system will be built by technical resources without a full understanding of what the end users need the system to do. Then, the end users will test the system and find everything wrong with it and why it doesn’t work for them, resulting in starting the build and test process over again from scratch. Iterative approaches to building and testing can have a valuable place in an overarching systems development life cycle, but always with requirements defined prior to starting the build process.
In short, business requirements ensure that the system is capable of doing what the organization needs the system to do. If the client wants to spend thousands or millions of dollars building out a system to support the business, we need to spend the time and money upfront to ensure that the implementation is successful and doesn’t waste more time and money.
Let netlogx guide your team from uncertainty to clarity. Request a consultation today.
