HOW TO COMPILE A SOFTWARE REQUIREMENTS DOCUMENT SO DEVELOPERS ESTIMATE YOUR PROJECT FAST?

“I want to make an app like Uber. How much will it cost?” — this is a popular request among customers. However, there’s no clear answer to this unless you have a well-crafted software requirements document at hand.

Over 7 years, CXDojo has worked on multiple projects, and thus, estimated their budgets. But we should admit that no project was the same. We approached software architecture and development keeping the customer’s unique needs in mind.

The cost of product development depends on many aspects, with the most essential being:

• Features. No matter the product you are going to build, you need to know what it will be able to do. For this, you should collect functional software requirements. Define what your product ‘must’ have — features that users cannot do without; ‘should’ have — features that would be better to include; and ‘could’ have — optional features that users would appreciate.
• Technology. Say you are looking to create an online shop. The easiest way to do this would be using a website builder. All it takes is to select a template, edit content boxes, and add some customization options. Another way is to create the online shop from scratch. It takes more time and money. Yet, the custom-built solution will have a unique look, a high degree of flexibility, and all the required features (with no extras that you should pay for). Sure, these are only 2 rough ways to approach this case out of numerous. But you got the point. Each project requires careful consideration of its goals; and the choice of technology stack heavily depends on them.

• Team. Let’s again refer to the example above. If you decide on using a website builder, you won’t need a lot of tech talent to perform the task. More so, if you are tech-savvy, you can build an e-commerce site yourself. On the other hand, a custom-made shop requires that you have a team of experts by your side — i.e. architects, designers, developers, QA engineers, etc. You should take their effort into account when estimating the cost of product development.

As you can see there are many factors that dictate the project estimate. And they will be different for every project. Therefore, in order to accurately plan the budget, it is crucial to get a clear picture of the required scope of work, roles and responsibilities, as well as features that need to be implemented.

A software requirement specifications document is created to clarify these details and articulate the product vision.

Here, at CXDojo, we often deal with 2 types of customers — those who have no software requirements specification (SRS) at all, and those who have very detailed software documentation.

It may sound surprising, but neither of the approaches is right for cost estimation.

❌ CASE 1: NO SOFTWARE DEVELOPMENT DOCUMENTATION

Software developers do not have any superpower. They are not wizards who build perfect products with the wave of a magic wand. Instead, developers rely on software specifications to produce clean and efficient code.

A software requirements document is necessary to ensure that developers and stakeholders are on the same page. That way, they are pursuing common goals and clearly understand what the final product will look like.

Without a proper understanding of the product’s requirements, there’s little chance anyone can accurately estimate its development cost. If the developers have an incomplete picture of the functionality before the project begins, you risk going over the budget or getting the unfinished product in the end.

To avoid this, you’d better have someone well-versed in creating software documentation. If there’s none, we’re here to help.

❌ CASE 2: OVERLY DETAILED SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT

Some customers go to the other extreme. They come up with a multi-page document based on a canonical software requirements specification template described by Karl Wiegers in his book.

Usually, this SRS document includes:

• Introduction — an overview of how the document is organized, as well as a short description of the product and its scope
• Overall description — a high-level overview of the product, its operating environment, who will use it and how, as well as its constraints
• System features — the product’s capabilities organized by functional areas, use cases, modes of operation, etc.
• Data requirements — various types of data the system is going to manipulate, models, structures, relationship diagrams, and all other things data
• External interface requirements —  instructions on how the system is going to communicate with users, external software, and hardware
• Quality attributes — characteristics like usability, performance, security & safety, scalability, and many more
• Other requirements — those that do not fall under any of the categories above

“Isn’t it helpful?” — you may ask. It is, but for the development itself. For cost estimation, such a document is somewhat excessive.

Before the actual development planning phase, the customer and the developers have to first agree on the cooperation. In order to provide the customer with rough estimates, it shouldn’t take ages for developers to analyze initial requirements for the software. More so, they are dynamic — they change along with the development goals that may clear up during onboarding workshops. So, it’s just a waste of time to run through all those details and update them accordingly.

✅ CASE 3: MINIMUM SOFTWARE DOCUMENTATION FOR PROJECT ESTIMATION

There’s no point in generating tons of documents at the budget planning stage. The idea is to create software documentation that is essential for understanding the level of the product’s complexity and scope of work.

Standard documentation for software development estimation includes the following.

PRODUCT OVERVIEW

This document describes what a new product should look like, its purpose, and the issues it is addressing. Basically, that’s the overall vision of what you are going to achieve. It doesn’t go into specifics of the product but focuses on its context and the value it brings.

Simply put, an overview is a high-level summary of the primary functions that your product performs. It may also include information about similar products and their features.

USER STORIES

It is an outline of user requirements in the form of use cases or user stories. That way, you shift the focus from ‘what’ your product is to ‘how’ it will be used.

User stories describe who is going to use your product, what they want to do, and why. They are written in a layman’s language — as if you retell user conversations.

Let’s get back to the example of online shops. In this case, one of the user stories will be as follows:

“As a regular buyer (who), I want to have my payment details saved (what) so that I don’t waste time inputting them over and over again (why).”  

User stories may have various levels of detail. But it is recommended that you split large detailed stories into smaller ones.

When we write them at CXDojo, we make sure that customers immediately see the result of the implementation of particular functionality. While developers know what they are building and what value the end user will get. So, if you don’t know where to start, you can always consult us.

SYSTEM FUNCTIONS

This is where you switch to the system’s perspective and focus on its functionality. The aim of this document is to specify the desired behavior of the system under certain conditions. It should be clear to both techies and non-techies.

The system’s functionality may include:

• Business rules
• Administrative functions
• Authentication rules
• Data manipulations
• Authorization levels
• etc.

Let’s identify the system’s feature on the basis of the user story described above.

User story

“As a regular buyer, I want to have my payment details saved so that I don’t waste time inputting them over and over again.” 

System feature

“The system shall auto-save payment information to the user’s profile post-sale.”

WIREFRAMES

A wireframe defines the basic structure of the product. It’s a surefire way to get an overview of the layout, information architecture, functional interface elements, and user flows. Generally, it is a visual representation of the product’s features.

Using wireframes, developers take a critical look at the elements that they will need to code, and thus, determine the scope of work, as well as the time required for completion.

Wireframes can be as simple as hand-drawn sketches. Or, you can use online prototyping tools to create a digital wireframe.

We are not going to burst into endless chatter. Our primary advice is you should keep software documentation agile, based on a lean approach to building a product.

The thing is CXDojo advocates for lean software development, which is done iteratively — in small increments. We break down the development process into sprints. Then, we agree on a certain set of tasks that should be performed during the sprint and acceptance criteria that the customer will refer to when validating the results. The beauty of this approach is that we can develop custom software within a couple of sprints. Sure, the early version has a minimum set of features, but it is still a working product that allows us to collect user feedback and improve it correspondingly. With each sprint, the list of capabilities grows and the minimum product finally turns into full-featured software.

What are the main tips for creating an agile software requirements document?

• Know the user. User stories serve as a roadmap for product development. Loosely written stories are insufficient for communicating software requirements. Customers are not always those who will be using the final product, so there’s a risk that essential features will be missing or excessive features will be added. Therefore, it is recommended to engage end users in writing the stories.
• Prioritize tasks. It is impossible to document all requirements in enough detail for a full-scale development process. In most cases, they are clarified and validated along the way. Therefore, it results in vague estimation. It makes sense to decide on certain versions of the product and set priorities for each.
• Be clear and concise. No one enjoys reading a wall of text, especially if it doesn’t contain any value. Each requirement should contain information that is essential for software product development. More so, avoid being ambiguous. The different people that will be reading your software requirements document should catch the exact meaning that you are trying to convey.
• Allow for changes. Changes will happen, for sure. Business goals may change, the overall vision of the product may change, and even user needs may change. So, you should always save some room for alterations in software requirements, and thus, budget.

Now, some readers may find themselves at the crossroads. Many startups and small businesses have only the core team aboard. And naturally, there’s no expert that can compile a well-thought-out software requirement specification document. Worry not. We know the ropes and can help you out.

Let’s get in touch! We have a great deal to discuss.