Gathering Software Project Requirements

You may have heard a lot about Elon Musk, who is putting together a team to fly to Mars. What happens if their Starship deviates from its original course by just a fraction of a degree? It would be a miracle if they didn’t hit Pluto instead of Mars. They’ll most likely fly away into the void. Any ambitious project is always surrounded by a lot of emptiness.
Consider the conversation on board if they discovered after they left that the rocket construction team had forgotten to build crew toilets. One solution or another may be discovered after the fact, but it is always much better to consider the details before you begin. It is frequently difficult to add something later.

As a result, anyone approaching a software vendor with a project idea will be bombarded with questions. How can you be ready to respond to them? Where do you start when it comes to defining project boundaries and creating documentation? Basically, how do you gather project requirements? I’ll share a few pointers based on my years of Nile Bits experience. Although no one knows what you want to create better than you, the truth is that you don’t always know the specifics.

However, with the right reference points, you can begin to learn them.
These include the project’s objectives, technology stack, timeline, and so on. Do you want to see your project succeed from the start? What about becoming a technical requirements gathering guru?

Why spend time on requirements preparation?

A detailed clarification of a work plan may appear to be nothing more than a lengthy process of negotiations and project evaluation. But the truth is that project requirements affect everything in the project: the start date, cost, end date, and, most importantly, the end product. It’s similar to building a house: the more clearly the plan is described, the more likely the end result will match your vision. The better the contractors understand what they’re doing, the lower the redevelopment costs could be.
As a result, instead of saying “I have an idea, so let’s just get started,” preparing accurate and detailed requirements in advance can provide a number of advantages:

• More accurate time and money estimates. The time frame you expect is often not how long the project development takes in reality. The requirements you gather help the vendor estimate time more precisely so that you know better what you can count on. The same can be said for the budget. Proper requirement prioritization helps you avoid wasting money on things you don’t really need. By the way, when you’re gathering requirements for a project, there’s no need to pay for the developers’ time yet.
• A faster and smoother start. The better-prepared the project requirements are, the less time the parties will spend clarifying expectations and the faster they can move from the discovery phase to development.
• Faster delivery. A clear understanding of the requirements by all participants helps you quickly progress from stage to stage and avoid misunderstandings and downtime during the development process.
• The vendor can form the perfect team. It’s crucial to select developers who are right for the project. They should be chosen according to the subject area, technology stack, and applied solutions.
• The fundamental ability to make desired changes in the future. Much is determined by the initial choice of the technology stack. (This is particularly true in legacy projects.) Potential “add-ons” largely depend on the “foundation” you’ve chosen, and a well-thought-out architecture allows you to avoid confusion and software conflicts.

As a result, the finished product is more likely to meet your expectations. If you define your vision clearly, the rest is up to the vendor, where it makes sense to rely on an efficient development process.

What do project requirements consist of?

The first thing to keep in mind is that requirements define everything that must be implemented. Frequently, requirements are concerned not only with specific features, but also with the possibility of adding them later or changing course.
Going straight across the map is much faster than going in circles and feeling for the right path. So, how do you avoid becoming disoriented? “By paying attention to several landmarks,” is the answer (meaning: practical concepts). Let’s try to figure out an approximate path through them.

1. Monitor the Quality Triangle

To begin, consider the Quality Triangle, a diagram that depicts the trade-offs inherent in any project.
It works on simple mechanics: if you fix one of the vertices, you must balance the other two with each other, much like a teeter-totter.
As an example,

• If you want to achieve a certain amount of work, then a decrease in time in some measure can be offset by an increase in the budget (by hiring additional developers) – and vice versa.
• If you reduce development time, then to reduce costs you’ll have to simplify the product. (Here, growth along the Scope axis indicates the costs growth, i.e., the functionality you’re ready to cut off.)

Simply put, you can choose only two of these three conditions if you strive to make development fast, cheap, and detailed. Otherwise, you must forego quality, which is determined by the sum of these three factors.

2. Consider the three types of requirements

A framework can help you prioritize correctly when interacting with a vendor. The three-type classification of project requirements is a fairly practical approach.

Business requirements

We mentioned in How to Create a Product That Investors Will Commit To that many founders get carried away with the technical side and forget about the value they should bring to customers (meaning the reason why customers buy the product).
The primary motivations for developing the product are most likely business problem solving and profit maximization. The software vendor will require detailed information about your industry, leadership structure, market rules, and so on.

User requirements

This type is inextricably linked to the previous one. It makes perfect sense to work tirelessly to ensure that the product works properly, reliably, and without interruption. However, it should also provide users with positive emotions. Convenience and design, in the eyes of users, may outweigh the business benefits of using the product.
Consider the decision to hire a messenger for business purposes. Slack, Skype, Discord, and Signal all provide similar ways to accomplish similar tasks, but they occupy distinct market niches due to their slightly different user experiences. Similar examples from your field are likely to come to mind. In a nutshell, there is an additional opportunity here to differentiate your future product from its competitors.

Technical requirements

They consist of the platform for which the application is being developed, interface features, and specific backend functionality. Of course, business representatives do not need to understand all of the nuances, but they should be aware of the existence of various technologies. Whichever one you select will determine both the project’s possibilities and limitations.

Because no technology can be argued to be the best, a vendor’s expertise can be a compelling reason to select them. A genuine partner, in our opinion, is more likely to conduct an in-depth assessment of whether their stack meets your expectations and, if necessary, suggest a more elegant, effective, or reasonable solution. It also enables their dedicated team to anticipate potential challenges and how to deal with them.

3. Constantly check the understanding of the requirements by all participants

Don’t assume that everyone understands everything the same way when explaining your ideas to a developer, even if something appears obvious.

Make an effort to avoid making assumptions. When discussing the objectives and features of the project you want to build, be as specific as possible.

Usually, the vendor’s team will meet you halfway because it is in both parties’ best interests. If something is unclear, confirm and approve it before investing more time or money to fix it. Remember that many details are interdependent, so get them all right.

Questions That Will Help You Identify and Gather Requirements

Before contacting a software vendor, make sure you’ve prepared answers to the inevitable questions that will arise during the negotiation process. Let’s divide them into two categories to make it easier to navigate.

Your business impact

• For which company is the software developed? The developers might ask this question to get a general idea of your type of activity, taking into consideration industry trends and expectations. If you deem it necessary, add a few sentences about your biggest challenges and priorities this year, or about your clients or partners to whom the project may be relevant.
• What is your previous business experience? Any details will be helpful here: how long you’ve been in business, what your long-term goals are, whether you have experience in launching startups, etc. Answering this group of questions will allow the vendor to define your development and marketing strategy better. Based on this, they can assess certain prospects for the product, as well as opportunities and threats.
• How and why did you get the idea to create a product? Clarify the purpose of the product and the problems it’s intended to solve. How long have you been facing this problem or dealing with these pain points? Additional factors may need to be considered to come up with a better solution.
• Why did you decide to outsource, and how did you find us? This will enlarge the vendor’s understanding of your vision of the ideal collaboration and help the team come closer to meeting your expectations.
• Who are your main competitors, and how will you differ from them? Many software products have a number of similar functions, such as user registration, messaging, or making payments. But these details are less important than the requirements that form the core of your product and will allow it to stand out and win market share. The challenge is to bring them to light.

Development process management

• Who is your contact person? Determine who the development team can contact if it needs to get a clarification, make a decision, or approve changes. It’s also helpful to rethink how your company’s size and leadership structure can affect process agility and decision-making speed.
• Who makes the final decisions at your end? The developer needs to know this to understand your expectations and increase communication speed and smoothness. Also, consider if there is anyone else in your company — a superior, colleague, or coworker — you’d like or need to include in the discussions to add a different perspective.
• What are the project creation terms? Often, when creating and delivering a product, a business needs to take into account its obligations to partners and investors, as well as the marketing situation (for example, industry exhibitions or seasonality). We all understand that it’s important not only to release a product to the market, but to choose the right moment to do it.
• What is the planned budget? This item is closely related to scope and time. Again, the balance of the three components determines the quality of the product (see the explanation of the Quality Triangle). If you’re waiting for funding or the budget may be affected by additional factors, including time milestones, it’s useful for the vendor to know about this in advance.

How to protect your idea

Caution is understandable when deciding to share information about a future project or a novel business solution you’ve devised with another company. Are there any criteria for determining the partner’s dependability and conscientiousness? Without a doubt! Here are a few examples:

• First, sign an NDA, something we’ve been doing at Nile Bits since 2014. Feel free to raise this issue in your negotiations. Today, it’s not considered as a sign of distrust on your part, but rather a common courtesy.
• Check the vendor’s reputation by looking at detailed customer reviews on reputable sites.
• Also, it’s useful to bear in mind that the vendor must be able to ensure the safety of your data from leak and damage. This requires a certain structuring of processes and a responsible attitude from each team member. A good guide here is, for example, checking the compliance of vendor’s information security management systems with ISO standards.

Once the “acquaintance questions” have been answered, the project can proceed to the next stage of requirements gathering, taking into account the information mentioned in the previous section.
First, gather more information about the product’s business objectives, scope, and technology stack. Once the data has been collected, it is time to review and prioritize the requirements. After all, some of them will be critical to ensuring that your product works properly and meets business objectives, while others will simply be wishes that may vary.

Detailed discussions with the software vendor will aid in finalizing the requirements and documenting them (along with the acceptance criteria for deliverables). This will allow you to proceed to the most interesting part of the process: managing their implementation.
Naturally, no one can account for everything all at once. Gathering requirements for software development is a difficult art, or at the very least a unique practical skill. Some details and additions will be added as development continues. This is what prototyping, minimum viable product (MVP), and iteration cycles are for: to gradually improve your product. I’ve only shown what needs to be considered in the early stages of selecting a software vendor.

I hope you’ve learned from this article that gathering project requirements is a critical step that should not be overlooked. It frequently assists you not only in moving from words to actions, but also in avoiding pitfalls. It is a method of arriving at the correct task prioritization and creating more effective solutions through competent communication with the development team.