Software requirements specification lock stock and barrel

So you’ve come to the point when your blurry product idea started to get its shape. You conducted market research and maybe even managed to talk to a few of your potential users to understand their needs better. 

 Learn why validation is the key to start the app development by watching our Live Session with  Alister Sneddon, a fintech expert, and co-founder of a London-based startup 

Maybe you decided whether your product would be a web or a mobile application. Made some sketches and described how things work. Now it’s time to take your notes and start developing, right?

What you need to know about software development is that it’s not as straightforward as baking cookies from a recipe. Contemporary applications are fairly complex systems, often impossible to describe in every detail like a cookie formula. Features that seem easy to implement in one technology can be a pain in another. A lot also depends on whether you’re making a B2B or B2C product. To keep it short, there are more than one or two dependencies that make writing a software requirements specification an uphill struggle.

To make it less painful, you can engage in documenting your software product. It might be just as beneficial as a recipe for baking cookies, depending on the stage your product is in. If you’re up for it, read on to learn:

• What is a software requirements specification and why it’s so difficult to write one that makes sense for a software house?
• How to pick the features for a software requirements specification?
• What can you expect from a software house when you want to stay flexible and detailed at the same time?

What, why, when, and who of software requirements specification

There’s no simple explanation of what a software requirements specification (gently named “the spec”) is. Developers, business analysts, project managers, fellow founders - everyone will give you a different definition. 

• Developers and architects would say that the specification shows a detailed list of desired features and other information that determine the app’s architecture.
• Business analysts would look for business models and information about your target group.
• Project managers would try to understand the priorities and deadlines for your product.

Whose perspective is the right one? There is no answer to that. A good specification has them all.

What?

So what is a project specification then? We like to say that it is documentation you start your project with and update it with time. It contains everything you know about your market, competitive solutions, your target group, and its preferences when it comes to how the app looks, feels, and what one can do with it. 

See what other documents are useful with software development. 

Such documentation can be as informal as a note in Google Docs, or as structured as a Confluence project. The form doesn’t matter as much as the fact that it’s a living organism. Therefore, you should be particular about keeping it alive, watering it with new ideas, adding new details and descriptions.

You’ll think, ok, it looks like quite a thick book. Yes, it does, but only at the first glance. We’ll get to that later on.

Why?

Why bother to prepare a software requirements specification? There are at least two good reasons.

1. Reason one - you. So that you understand your vision and product and find the words to describe it.
2. Reason two - everyone else. So that other people can understand the magic and novelty behind your idea and bring it to life. And that’s a whole lot different story.

Translating a vision into a tangible and marketable product requires more than just a bullet-pointed list of expected features. When you write a project specification, you help everyone involved in building your application more aware of your business goals, your market perspective, and your expectations as a founder. What’s more, by writing your spec down, you leave less space for misunderstandings and misinterpretations - a very common blocker in such a complex process as software development.

The grey areas and unknowns are not obvious at the first glance. The ability to spot and address them comes with time and practice. If you don’t have the experience yet, reach out to a software house with business analysts on board. It will unlock a broader perspective and allow you to complement your documentation with areas you might have neglected in conceptualizing a project. 

When?

So when does a specification emerge? Even if it’s not written down, it’s born the moment you start thinking of your idea. The question is when to give it a more tangible form.

When you’re running fast to get your product to the market before the competition, the last thing you care for is a detailed specification of how each part of your product should look and work. That’s why so many young companies depend on a package of randomly generated pieces of spec. And they work fine as long as you’re the master and commander, the founder and developer in one person. When your startup gets bigger and you need to either hire new developers or build processes and procedures to get hold of the flow of new requirements, it turns out your notes are not enough. 

A project specification is usually a product of growing companies that realise the demand for their software’s updates is bigger than they can handle, and therefore requires additional development forces. Then, it’s time for a professional spec.

Who?

Should you write software requirements specifications yourself? It depends. Good specifications (and by good we mean understandable for a product development team) are as hard to find as cheap apartments in Manhattan. One can see them coming mostly from very experienced teams who worked on software products in the past. Such teams often comprise the perspective of at least a business analyst, software architect, and software developers.

If you happen to possess the perspective of an advanced project manager, a business analyst, or a software architect, chances are the development team will be able to understand and get use of your specification.

What if you neither have such experience or a team? You can ask a software house for help. An IT partner familiar with transforming visions to scopes, who works with companies at different stages, and has developed a stable and repeatable scoping process is your second option.  

How to build a specification: a proven process

Let’s take a closer look at what happens when you approach your IT partner with a handcrafted document with your project description. There are several scenarios of possible next steps, each of them depends on how detailed and techy documentation as well as on what you expect from a collaboration with a software house.

Let’s say you’re a startup founder who wants to build an application. You expect a VC to fund your undertaking, so you researched a few interesting technologies to leverage in your product. 

Of course, when talking about a software requirement specification, we’re not chasing perfection. What we really need is “good enough” for our specific circumstances. The key is to choose such language, wording, and problem statements that would make the development team understand the product flow and recognise potential technical challenges. 

So how to work with a software house on a specification?

Do your homework and build a repository

Starting with a specification is far from exciting unless gathering tons of information and insights is what excites you most. Before you hire (or outsource) developers to evaluate and improve your specification, there’s a lot of homework waiting for you. Ideally, by that time you’ll have your ideas gathered, insights noted down, target customers, and competition researched. 

Remember that whether you want it or not, you’re preparing product documentation from the moment you start thinking of building an application. Every piece of information you collect can be a change breaker. That’s why try to keep and regularly update the repository of your app’s knowledge. You’ll need it when you decide to take it to the next level.

Based on them, you’ll write the shape of your product with special attention to:

• solving the most burning problems of your target group,
• listing all the things a user can do in the application,
• pointing out priority features that make your application stand out,
• depicting the business model to make sure your IT partner focuses on making the app your revenue stream.

Your specification can take different forms, depending on the lifestage of your product, or even on your individual preferences. We see SRSes presented as:

• Pitch decks,
• Excel tables,
• User flows,
• Story maps,
• Pdf documents with business background and list of application modules,
• Jira backlogs.

Have a software house take a look 

Software development requirements come in all shapes and sizes. Regardless of its form, you’ll want your IT partner to get familiar with your specification and advise on the next steps. And there are plenty of options to choose from.

• A call to explain the details - works for technical founders who understand the software development process.
• A scoping session to confirm your assumptions and fill in the gaps - a common choice for teams with a prototype, wireframes, or a detailed product specification.
• A full product design workshop - ideal if you’re non-technical and need help in translating your business vision and research in a scoping document a development team can start to work with.

What should the software specification include

You can think of a software requirements specification (SRS) as full documentation of your project. Of course, it’s full in the sense that it comprises your full knowledge for a particular point in time. You don’t have to have all the answers upfront. Still, you may want to pay attention to the following characteristics that influence the way the application is designed and built. Similarly as in an RFP (Request For Proposal), these are:

1. Business requirements. Deadlines, release plans (e.g. a new version for Black Friday, New Year, or a particular conference), agreements with investors. Even though they don’t say anything about the application’s scope, business requirements determine the technologies used in the product as well as the pace of the development. 
2. Market research. The information from surveys and competition research is a valuable source for the UX designers, especially if you don’t have your own layouts in place.
3. Technologies. This point is a bit tricky, especially if you’re not a developer. With so many buzzwords around, founders often want to use artificial intelligence, machine learning, or microservices, even if the product doesn’t require such advanced solutions. 
4. Non-functional requirements, also called qualities, define the objectives regarding expected traffic load or peaks as well as the third-party integrations with payment gateways, social media, or other software your app would use.
5. Functional requirements. The most straightforward part of an SRS. That’s the description of your application behavior divided into single features.

How to get to the point when you know your spec has everything it needs? 

When you’re building a digital product for the first time, assessing what to include in (and what to exclude from) tour software specification can be overwhelming. Applications, as we know and use them, are often quite big systems with complex business logic. How to make the right choices from the beginning? 

If you’re new to product development, make sure you take the most from the cooperation with a software partner. A proven way to do it is to take part in a product workshop or a scoping session.

Scoping session or product design workshops? Learn more about the product discovery stage of software development!

An experienced development team will help you assess the structure of your documentation as well as its form and the level of details. On top of that, during a workshop, you’ll have a chance to avoid risks such as betting on a non-prospective technology, or overcomplicating the scope of your project.

When struggling with describing your app’s features, here’s a step-by-step formula we recommend. It’s called the INVEST framework. We use it to write user stories and epics.

INVEST creates a frame for describing project requirements. Each of the letters stands for one attribute a properly written requirement should have. They also create a set of rules you might want to follow when writing your specification.

Independent - by any means, avoid dependencies on other stories. This way you make it simple. 
Negotiable -  leave room for questions, discussions, and advice.
Valuable -  choose only the features that have value for your users or your business.
Estimable - use clear and concise language to leave no room for assumptions and allow the development team to estimate the feature’s complexity. 
Small - the smaller the feature, the better. Treat each click like a single feature and you’ll be sure they won’t be too big. 
Testable - think of the ways you can tell whether your feature is coded in the right way. 

Most common challenges in preparing a software requirements specification

By now, you should have already grasped the idea of what an SRS is and why writing it is not a piece of cake. If you’re writing the spec for the first time, you may find it difficult to put your ideas on paper. And it’s only getting started.

Let’s see why preparing a software requirements specification can end up in a big headache, both for you as the founder, and for the software developers who would read it afterwards.

Founder’s headache

Preparing the specification yourself, you have to remember you’re not doing it for yourself. At least, not if other people are to embody your business vision. If you are a technical person, preferably a software developer, it could be a bit easier for you to find the business-tech balance in the description of your product. We found out that founders are often faced with four common challenges related to a spec document.

• Depth. A short story or a 300-page novel? One superhero or a bunch of Avengers? Writing a spec you’ll need to decide how deep you want to go with the description of your main idea, features, and milestones. We’re guessing you might want to document everything from the start to help the development team understand better. The risk is that you’ll spend weeks documenting things others won’t understand.
• Language. High-level business descriptions sprinkled with marketing magic or straight-to-the-point technical language? You’ll need to find a balance between the two. Whatever you come up with needs to be understood by a business analyst and a software developer. 
• Structure. Make it a story or a bullet list? What to put first? Making a structured document out of a loose vision board is a challenge of many founders.
• Technology. The temptation to slide on a wave of AI, ML or blockchain hype is big, especially if one doesn’t know the ups and downs of certain tech technologies.  It also doesn’t mean that your app needs it. 
• Leaps. Will your readers know what you know? Certainly not. What you find obvious might be unclear for people who would work with your specification. Mental leaps are not your spec’s best friends.

Gathering requirements is one of the biggest challenges at the beginning of software development. See our insights about this process based on 20+ years of experience in creating digital products! 

Software house’s lessons learnt

A software requirements specification is also a challenge for a software house. Many of them already know how to overcome founder’s headaches and write documentation useful for software teams. Having done it for many early-stage startups as well as growing product companies, we pointed out two areas we find particularly important (yet not easy to cover) in a software specification.

• Mutual understanding. In order to grasp the product idea, find potential solutions, or recommend technologies, we need to deeply understand the problem you’re trying to solve. After all, we want you to succeed, not just build your product from a features list.
• Flexibility vs. rigidity. How not make the spec rigid enough to give our clients stability but flexible enough to save on time- and budget-consuming detailed change recording? Our team knows how to assess which pieces of information require more time and love, and which like flexibility.

Software requirements specification: key takeaways

When we talk to our customers, no matter if they’re just starting their product development or need to expand an existing team, coming up with a clear, concise, and understandable SRS is a non-trivial challenge. So is establishing a mutual understanding, a uniform language between the founder and the software team. 

When does it make sense to write a specification?

• When you’re building an app from scratch
• When your product is scaling up and you need to involve external developers 
• When you’re handing over the development to a new software team

The process of writing an SRS looks short and sweet, although it’s quite difficult to implement. That’s why, instead of spending weeks on in-depth specification of each feature, you might want to work together with your IT partner on preparing the documentation in accordance with the best practices. If that’s your first time with a product spec, you’ll probably avoid many rookie mistakes and will increase your chances to build a successful product. The good news is that you don’t have to do it on your own.

If you’re struggling with preparing a software requirement specification, reach out to our product design team. We’ll help you out.