So, what’s a requirements definition? In this video, I’m going to talk about what exactly it is, what goes into it, how you do it, and how important it is in your ERP implementation. 

A requirements definition is just a comprehensive list of your requirements. It’s as simple as that, but how do you find those requirements? 

I’ve seen clients have 15 line items in their ERP requirements definition, and that’s not good enough. I’ve also seen clients with 3,000 line items on every functional area, but that might be an overkill. We have to find the sweet spot between how well your requirements are documented so that vendors can then respond in an efficient way and help you find the right product for your practice. 

RelatedWhy Government Organizations Need to Modernize Their ERP Systems

So, how do you develop a requirements definition? It can be as simple as documenting your requirements on an Excel sheet, but you have to be really careful here.


You can’t just say, “I need a system that does accounts payable for us.” Any system can do that, but what does that mean for your organization? Ask yourself: 

  • What are the nuances of accounts payable at your organization or your city or county? 
  • What are the nuances of timekeeping in your organization? 
  • What policy decisions and local ordinances impact those requirements? 

You can’t just say, “I need a system to do checks for us.” You need to really define what that means to see whether or not a system can fit your needs. 

So, the first thing to do is define your processes. Define your future processes. Document them, map them, and if you’re using a tool like IBM’s Blueworks Live, it can actually automate the process of at least starting on the requirements definition for you. 


These days, when we do requirements definition, we use IBM’s Blueworks live to come up with the base level of requirements, and then we build on top of them using Excel. When a finalized requirements definition is produced, it ends up being two to 3,000 lines long and with multiple different tabs attached per functional area. 

So, let’s take an example of a financial system and the requirements definition associated with it. What do you think goes into a requirements definition and how would you break it down? 

The first tab, function, or component that we look at is general ledger. Keep in mind, as you’re populating different areas of the requirements definition, you might end up populating some other areas as well, like general leisure.

Think about a requirements definition document as broken down into functional areas that relate to finance, HR, or payroll. You’ll have general leisure. You’ll have a tab for accounts payable, accounts receivable. You’ll have requirements for HR management, benefits administration, and all of which will live in an Excel sheet or a Word document that helps you track what requirements must go into an ARP solicitation or an RFP. 

So, the different components of a requirements definition follow closely with the different functional areas within your organization. There are also specific items like IT, security, cybersecurity, VPN securities requirements definition, and who gets to see what part of the system.


The other important element of a requirements definition is the integration requirements. When you buy an ERP system, you need it to talk to other elements of your IT organization. 

You might have a very specialized system in your organization that won’t go away because of how specialized it is, but it needs to be integrated with your ERP system. So, you have to have a tab or a function within the requirements definition that specifically talks about which external systems may be owned by you, by the state, or by the county. 

Which systems does your ERP system need to interface with? That needs to be clearly defined. Another important element is GIS. How does GIS function within your organization? Is it a countywide initiative? Do you use the state system? Who feeds the data that goes into these layers? How is your new ERP system going to consume this data in the GIS?

All of that needs to be documented and defined in a very specific way in your requirements definition. If done right, keeping these components in mind will help you come up with a requirements definition that will protect you through the implementation and beyond.

Request Information

Contact us to discuss your current workflow
and infrastructure needs.