Before starting any project, it is obvious that you need to know what is expected to be delivered. However, when you have decided to implement a new business application, such as Microsoft’s Dynamics 365 Business Central , there are many options at hand within the application and many users may require different options.  Unless you perform a ‘Business Requirements Gathering Process’ , resulting in a formal ‘Business Requirements Document’ , your implementation will not have specific guidelines that determine its success and varying stakeholders in your business will be disappointed. 

Types of Requirements

There are many different types of requirements as listed below, but each one should answer two essential questions: [a] Does it support the problem we are trying to solve?  [b] Will it help us realize a benefit?

• Business requirements
  • What is the overall goal of this project from the company’s point of view
• Users requirements
  • Define your stakeholders that not only use the system but receive information from the system – what are their objectives to achieve a successful project
• System requirements:
  • Functional requirements
    • What does the system have to be able to do or output?
  • Non-functional requirements
    • How well does the system perform the functional requirements?

Each of the types of requirements can be broken down into specific identifiable requirements and should have a priority associated with it e.g must have, important, nice to have.

Requirements Gathering Process

Even though the process is usually referred to as Requirements Gathering, it is not adequate to just gather the requirements because most times the requirements are not documented or even known.  The end result may be known but the individual requirements may not be.  For example, in a Sales application, the main objective is to track the overall sales of a company, but what makes up that sales information?  What products do we sell?  Are each one of them profitable?  Who buys our products?

The process to gather requirements stems from elicitation which is an active effort to extract information from stakeholders, users, subject matter experts, etc.  Elicitation is not a step or task but rather a set of techniques you apply such as:

• Interviews with stakeholders
• Conduct workshops
• Questionnaires
• Prototyping
• Observation
• Brainstorming
• Mind Mapping

Once you have elicited the information and believe you have gathered requirements you need to analyze the requirements to make sure they make sense, are applicable, traceable, relevant and validated.  Then you need to document all the requirements and have them approved from all stakeholders, users and subject matter experts that contributed to the gathering of the requirements to ensure everyone is on the same page. With a detailed requirements document reviewed and approved, your project is now ready for implementation or software selection.

About The Author

Debbie Clark, Chief Operating Officer
Debbie has over 20 years of experience strategizing and implementing core operational systems, optimizing business processes and improving productivity for various organizations. Debbie has implemented over 100+ corporate ERP and related business applications from manufacturing, distribution, service and other industries, across all functional areas of each organization.