Gathering Project Requirements: The Foundation for a Smooth Start to Software Development

You may have heard a lot about Elon Musk, who’s assembling a team for a flight to Mars. What happens if their Starship deviates course by just a fraction of a degree at the start? It will be a miracle if, instead of Mars, they hit Pluto at least. But most likely, they’ll fly away into the emptiness. There’s always a lot of emptiness around any ambitious project.

Or imagine the dialogue on board if they discovered, after their departure, that the rocket construction team had forgotten to build crew toilets. One solution or another might be found after the fact, but it’s always much better to think about the details before you start. It’s often difficult to add something afterwards.
Listen to “Gathering Project Requirements The Foundation for a Smooth Start to Software Development” on Spreaker.
That’s why anyone who comes to a software vendor with a project idea will be greeted with many questions. How can you be prepared to answer them? Where do you begin defining project boundaries and generating documentation? Basically, how do you gather the requirements for a project? Here, I’ll share a couple of tips based on 12 years of Django Stars experience.

Although no one knows what you want to make better than you do, the fact is that often even you don’t know the specifics at first. But you can start to learn them — with the right reference points.

These include the project’s goals, tech-stack, timeline, and so on. Do you want to launch your project with real success? How about becoming a guru of the technical requirements-gathering process for software development?

Why Spend Time on Requirements Preparation?

It may seem that a detailed clarification of a work plan is no more than a protracted 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, should be exactly what you want. It’s like building a house: the more clearly the plan is described, the more likely it is that the result will align with your vision. The better the contractors understand what they’re building, the lower possible redevelopment costs.

Therefore, preparing accurate and detailed requirements in advance — instead of saying “I have an idea, so let’s just get started” — can provide a number of benefits:

• 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 software 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 of your project 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 end product is more likely to turn out the way you want it. If you define your vision clearly, the rest is the vendor’s concern where it makes sense to rely on the effective approach to the development process.

What Do Project Requirements Consist of?

The first thing to remember is that requirements describe everything that needs to be implemented. Often, requirements for your software are concerned not only with certain features but also with the possibility of adding them later or even changing direction.

Going straight across the map is much faster than wandering in circles, feeling around for the right path. So how do you avoid getting lost? Answer: “by paying attention to several landmarks” (meaning: practical concepts). Let’s try to plot an approximate route through them.

1. Monitor the Quality Triangle

For starters, it makes sense to look at the Quality Triangle, a diagram that reflects the trade-offs inherent in any project.

It’s based on simple mechanics: if you fix one of the vertices, then you’ll have to balance the other two with each other – like on a teeter-totter.

For 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, by striving to make development fast, cheap, and detailed, you can choose only two of these three conditions. Otherwise, you’ll have to sacrifice quality, which is determined by the sum of these three factors.

2. Consider the three types of requirements in software

To correctly prioritize when interacting with a vendor, it’s useful to rely on a framework. A fairly convenient approach is the three-type classification of project requirements in software development.

Business requirements for software

In How to Create a Product That Investors Will Commit To, we mentioned that by getting carried away with the technical side, many founders forget about the value they should bring to customers (meaning the reason why customers buy the product).

Most likely, the main reasons to create the product are business problem solving and making a profit. In this regard, the software vendor will need detailed information about your industry, your leadership structure, market rules, etc.

User requirements for a software system

This type is closely intertwined with the previous one. It definitely makes sense to tirelessly ensure that the product will work properly, reliably, and without interruption. But it should also deliver positive emotions to users. In the eyes of users, convenience and design are factors that may outweigh the business benefits of using the product.

For example, let’s look at choosing a messenger for corporate purposes. Slack, Skype, Discord, or Signal offer fairly similar ways of solving roughly the same tasks, but they occupy separate market niches due to their slightly different user experiences. You’ll probably recall similar examples from your field. In a word, there’s an additional opportunity here to make your future product stand out from its competitors.

Technical requirements for software development

They include the platform for which the application is being developed, the features of the interface, and specific backend functionality. Of course, there’s no need for business representatives to delve into all the subtleties, but it’s useful for them to know about the existence of different technologies. Which one you choose will determine both the possibilities and the limitations of the project.

Since it cannot be argued that any technology is the best, a vendor’s expertise can be a weighty reason for choosing. That’s why we, for example, focus on knowing all the Python & Django ins and outs as a monostack company. As we see it, a sincere partner is more likely to make an in-depth assessment of whether their stack meets your expectations and, perhaps, suggest a more elegant, effective, or reasonable solution. It also allows their dedicated team to predict the challenges the product may encounter and how to deal with them.

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

When explaining your ideas to a developer, don’t assume that everyone understands everything in the same way, even if something seems obvious.

Try not to leave room for assumptions. Be as detailed as possible when discussing the objectives and features of the project you want to build.

Usually, the vendor’s team will meet you halfway, as it’s in the best interest of both parties. If something is unclear, confirm and approve it before you incur additional time or money expenses to fix it. Remember, many details are interdependent, so you need to get them all right.

Questions That Will Help You Identify and Gather Requirements

Before contacting a software vendor, it will be useful to check whether you’ve prepared the answers to the questions that will inevitably arise during the negotiation process. To make it easier to navigate, let’s group them into two categories.

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 you decide to provide another company with information about a future project or unique business solution you’ve invented. Are there criteria for checking the reliability and conscientiousness of the partner? Of course! Here are some of them:

• First, sign an NDA, something we’ve been doing at Django Stars since 2008. 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 like Clutch.
• 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” are settled, the project can move to further requirements-gathering steps, taking into account the information mentioned in the previous section.

First, you need to collect more details related to the product’s business objectives, scope, and tech stack. Then, once the data collection is complete, it’s time to review and prioritize the requirements. After all, some of them will be critical to making your product work properly and achieve business goals; others will be just wishes that may vary.

Detailed discussions with the software vendor will help finalize the requirements and put them on the documentation (along with the acceptance criteria for deliverables). That will allow you to move on to the most interesting part — managing their implementation.

Of course, no one can account for everything at once. Gathering requirements for software development is a tricky art, or at least a special practical skill. Some details and additions will come along as development progresses. This is what the prototyping, minimum viable product (MVP), and iteration cycles are used for: to gradually make your product more and more perfect. Here, I’ve illustrated only what needs to be considered in the initial stages when you’re choosing a software vendor.

I hope your takeaway from this article is that gathering the requirements for a project is a major process that shouldn’t be neglected. Often, it helps you not only move from words to deeds but also avoid pitfalls. It’s a way to arrive at the right prioritization of tasks and create more effective solutions through competent communication with the development team.

If you’d like to hire highly experienced specialists to smoothly navigate your project through all the steps from requirements gathering to a working product, send a message to the Django Stars team.