Starting a new project can be fun and exciting, especially when working with customizable solutions like FileMaker and Salesforce. You likely had many meetings and gathered significant research to finally decide on this path. But how do you begin the actual application development project?
Along the way, you probably wrote down all of the cool ideas over the last several weeks, months, or years. Now now you need to transform them into more specific documentation so software developers can go build the final product. That’s where gathering requirements comes into play.
What is Requirements Gathering?
Requirements gathering is the first step when you start a new project. The process lays the foundation to make an effective tool for your company’s needs. Requirements gathering is a skill: not everyone knows how to do it, why to do it, or what it entails when done well.
It is a detail-oriented and meeting-heavy process. It might take longer than you expect, but the investment in getting a clear and detailed understanding of your needs is well worth it.
In real life, requirements gathering never really ends. As you work, more ideas will come to you, and you’ll need to go through the same process. However, at the start of the project, you’ll have an intense focus on gathering requirements sufficient to define your project. We’ve listed the top five things you should expect when doing so.
Expectation 1: Ask a Lot of Questions
It’s so important to know that gathering requirements requires a lot of questions. Key stakeholders will confidently say something that may appear concrete, which leads you to believe there isn’t anything else to add. But you’ll always need to go deeper with the who, what, when, where, and why questions. These more specific follow-up questions elicit the details you need to know before you can build.
Sometimes, those details confirm what you thought was true, and sometimes, those details expose the real truth behind the original statement from a stakeholder. Sometimes, you have to cross out the so-called requirement because after asking a question or two, it turns out to be irrelevant. Other times, it is way more complex than was originally described.
It’s great to catch issues like this earlier rather than later. It is much easier to revise a document than to rewrite code. Late-breaking changes to requirements could disrupt momentum of the project. As a customer, it is always better to give too much information than too little.
Expectation 2: Set Aside More Time Than You Think You Need
It is not easy, nor is it quick to gather requirements when building a new application. If you try to rush the process of gathering the requirements, you will most likely find it causes issues later in the project that take even longer in the end. If you discover during development that whole chunks of functionality were missed altogether during requirements gathering, you will experience delays or additional costs to the project. So, be sure to have a patient attitude when it comes to this part of the process and be thorough. It will all be worth it.
Expectation 3: Your Goal is to Understand Scope
The reason to go through this process of gathering requirements is to understand how long, wide, and deep this solution will go, can go, and could go in the future. This allows IT professionals like us to understand the process and why the process should be built this way. Then, you can provide feedback on where potential gaps or issues may arise. Without this step, it will be very difficult, if not impossible, to provide a satisfactory product.
It also makes it possible for you to choose a subset of requirements to build first and save other identified features for later. You can prioritize effectively when you know clearly what is needed and why. You do not have to build everything all at once.
Expectation 4: You MUST Understand Non-functional Requirements
One of the least glamorous steps in gathering requirements is documenting the non-functional requirements of the application.
Non-functional requirements are behind-the-scenes items, such as security, capacity, usability, aesthetics, speed, and regulatory requirements. It’s important to be explicit on these items to avoid unpleasant surprises and unhappy users when you deploy your final application. It’s also important to review them at the beginning of the project and again toward the end to make sure they are still correct in view of what you’ve learned about the functional requirements.
It’s easy to forget or just skip over non-functional requirements on purpose. However, it’s critical to understand these requirements for the success of the project and the future of the product.
If you want to take a deeper dive into non-functional requirements with examples, then check out this article.
Expectation 5: Leverage Sketches to Eliminate Confusion
When gathering requirements, it can be difficult for you and your stakeholders to understand one another because of the diverse styles and experiences we all have. Key stakeholders often have things clearly laid out in their minds but might not excel at transferring that knowledge to other people.
In order to make sure that requirements are properly understood, business analysts or technical leads will create sketches to help refine the requirements further. Doing these sketches (often called wireframes or mockups) helps remove any confusion. A picture here really is worth a thousand words.
It also provides an opportunity for the development team to understand they need. They can better articulate their ideas to the stakeholders in hopes of improving a feature or making it more performant when built. 
Moving Forward with Your Requirements Gathering
To build a great house, you need to draw up detailed, well-thought-out plans. To build a great application, you need to gather detailed, thoughtful requirements properly. That’s why we make it part of our process to do this every time we work with a new client or on a new project. If you’d like to learn more about our process or would like to explore working with our team, contact us to speak with a consultant.
