Software development specification

It’s important for your software
development team to have as much information as possible about your future product in order to provide accurate

Sometimes a feature that seems minor and insignificant can have a huge
impact on your budget and timeline. That’s why a detailed specification for any custom software development project
means so much.

What Is A Specification?

Everyone has to deal with planning at some point in their lives: purchases, trips, events, renovations, and so on. In
most cases, we think of the “big picture” first – what we want to accomplish, how much it will cost – but we usually
give little or no thought to the details before jumping in.

For most day-to-day matters, this isn’t a big deal: you can just choose from whatever options are presented to you
(chicken or beef, first class or coach, front row or balcony, etc.)

Sometimes, however, you’re faced with a scenario where your options aren’t quite so clear-cut: you need a custom
solution for your specific needs, and going in without a clear vision of what exactly you want or need is a surefire
recipe for ending up way behind schedule and way over budget.

That vision, formalized into a document, is the specification for your project.

Life Examples

  1. Say you want to create an online shop. You only have your main page designed so far, but you’d like to estimate
    how much it would cost to develop such a site.

    All the pages you need are perfectly standard-issue (categories, search, cart, etc.), the design template is
    complete…at first glance, it seems like your developers should have all they need to know to make an estimate, but
    what does a product page look like? What format should search results come in?

    If you don’t provide the answers your developers need to make an accurate estimate, you might be in for an
    expensive surprise later.

  2. Or let’s say you want to create a mobile app to post pictures – anyone can make one, right? But it makes a huge
    difference whether you want to host pics on the user’s phone or on a server somewhere.
  3. Or say you already have a website or app you’d like to tweak: add a few new features, update the UI, etc. Don’t
    be surprised when your new development team asks which technologies were used to develop it, or say they need
    login info. If you don’t have answers to these questions, your project simply won’t be moving forward.
  4. Or say you want a new app similar to an existing one. You might expect it would be a simple matter of pointing
    to examples and telling your development team “I want something like this,” but by now you can probably guess it
    won’t be so easy. You will need to specify what exactly makes your app different from the rest, and those
    differences will have an impact on the final estimate, even if they’re as minor as an additional page or an extra
  5. Or say you want some sort of social media integration in your product, like many apps and websites do nowadays.
    This is something you need to make absolutely clear to your developers up-front. And if you want the ability to
    log in via Twitter or Facebook in addition to being able to post to them, that’s yet another item for the

It’s also important to decide on the source of the content for your website or application.

If you want to display feeds, updates, charts, diagrams, or messages on certain pages or interfaces, your developers
need to understand where the displayed data should come from, or which users/admins/etc. should be able to create

It’s no secret that developers operate on a completely different playing field when considering clients’
requirements. When you say “I want my users to be able to contact me through my website,” they hear “contact form,
submit, mail server, validation.”

For the non-tech savvy, it sounds almost like a foreign language, doesn’t it? That’s why, instead of talking to
developers directly, you’ll usually communicate with them through business analysts and, yes, your specification.
Think of the spec as a Rosetta stone which allows developers and clients to understand each other.

Software development ideas

Finally, it’s important to describe use cases for your product: who will use it, what function it will serve for them,
what users will expect from it, etc. When your development team has a solid picture of who you want using your product
and why, they’ll be more likely to be on the same page as you and less likely to diverge from your vision.

Types Of Requirements

Brainstorming Notes

This is the initial draft of the specification, usually in the form of
brief notes and interface sketches. This is a raw, general description of the idea in its most embryonic form
before most of the details have begun to coalesce.

Example-Based Requirements

These requirements consist of links or other examples showcasing
applications or products similar to the one they want developed.

Business Requirements

These are high-level requirements describing the concept and purpose of
the app as well as its general functionality without going into technical details.

Functional Requirements

These are low-level technical requirements, the bare minimum necessary
for developers to make estimates and begin development.

Use Cases

In order to better understand the future user of the app, it’s critical for
developers and architects to know the main user scenarios of the app performed by different kinds of users. There are
no ironclad rules for how much detail should be in these requirements, but the more information you provide here, the
better the end product will be.

Why Is It So Important?

To estimate the amount of time and money needed to develop a project, you have to formalize the requirements, i.e.
translate them into a specification. While this process is often tedious and time-consuming, it’s vital to ensuring
that the description of your project – no matter how abstract – is converted into something your vendor will
understand and be able to use to develop precisely what you want without error or miscommunication.

The first step of composing a spec is determining the basic components of your project that you’ll need estimates for.
For example, a typical list of components for an online shop looks like this:

  • Registration/login/user account;
  • Shopping cart;
  • Product categories;
  • Product page;
  • Payment system(s);
  • Admin panel.

The next step is to describe the details of each component. Say you want new users to receive a coupon code after
registration, or animation elements in your categories list – these are things that need to be in your specification.
It’s also helpful if you provide wireframes (i.e. example layouts) of the pages on your site or the screens on your
app so that the developers will have a better idea of what elements you want and how you want them arranged.

Wireframe in software development specification / Redwerk's blog

This is what a wireframe looks like.

Formalizing your concept as a spec will give you a clearer view of what you
want. Dividing your project into components will help you understand which elements you absolutely need in your
first release and which ones can wait until later. In many cases, it simply makes more sense to launch with only the
core functionality and gradually add additional features over time. For example, you might launch your online store
without the feature where new users receive coupons and introduce it a few months later as a bonus for your
customers. This will help you make better use of your budget and improve customer loyalty – a win-win situation if
ever there was one!

Software development specification is critical to
interacting with your development team and troubleshooting issues. If something hasn’t been implemented in your
product, your specification provides ironclad proof.

Non-Technical Description

Describe the purpose of the project and who its end users should be.
Also, describe how your project is different from similar projects, if any.

Third-Party Components

Describe all third-party components you want integrated into your
product, e.g. social media, third-party analytics, maps, etc.

Design / Wireframe / Description Of Pages/Screens

Your developers will need clear descriptions of all the components that
will go into your project. The more information you provide, the more accurate an estimate you’ll receive. You should
provide information about each interface your product should have. If your product will have multiple
forms/pages/screens of the same type, you don’t need to describe them individually; just indicate how many there
should be. Interfaces with actual functionality (forms, calculators, etc.) need more detail than forms with just
static content (e.g. “About Us”). Also, in addition to designs and descriptions, you should provide an explanation of
how the elements should interact with each other – the “business logic” behind your product.


Provide information to the development team about any technologies you
would prefer to use (or avoid using).

Description Of Existing

If you have an existing product you want modified in some way (e.g.
reskinning, extra functionality, etc.), your development team needs all the information you can possibly provide
about it: technologies, documentation, source code, everything.

Quick Q&A

Why Do I Need To Provide A Spec?

The more detail you provide about your project, the less likely your development team will
under- or overestimate something in their estimate. Anything your specification is unclear on is something you may
have to waste time and money on later either to clarify what you wanted or to deal with issues that weren’t obvious
at first. Having clear requirements from the get-go will let you spend more of your time and budget on your project
and less on hammering out details. However, if you’re less than tech-savvy or you want an expert opinion, you might
need to spend extra on an IT consultant to make sure your requirements are not only clear, but also reasonable.

But What If I Don’t Know All The Details Yet?

No problem! Just provide your vendor with everything you have regarding the requirements.
Business analysts can deal with even minimal requirements, and consultants will ask you all the questions necessary
to fill in the gaps. The fewer details you have to start with, the longer the process will take, but the end result
will be the same: a detailed estimate with a clear budget and timeline. On the other hand, if your project is fairly
sizable and time is tight, it’s possible to hire a team that can start work with minimal requirements.

Why Not Make A Project Without A Spec?

If you start development with only a general outline of your product and no clarification on
the details, odds are good the finished product will have little resemblance to your concept: your development team
can’t read your mind; they can only follow what you put down in the spec, and anything that you don’t put down in
the spec is fair game for them to interpret in their own way. Worse still, you won’t be able to prove they didn’t
develop the app you wanted because you never wrote down your requirements in detail.

What’s The Bare Minimum My Spec Should Include?

At the very least, your spec needs to include low-level requirements for your product, such

  • Descriptions/designs of all forms/pages/screens;
  • Preferred/required third-party services/libraries (e.g. REST, Google Apps, PayPal, etc.);
  • Detailed descriptions of all business logic: formulas, diagrams, functionality, etc.

(Note that “business logic” doesn’t necessarily have to do with “business”; the winning conditions of a game, for
instance, count as part of its “business logic”)

Our Experience


We understand how important it is to have a detailed specification – but we also understand that it’s not always easy
for our clients to make such a specification on their own. That’s why we have specialists in our company who excel at
making specs. We’ll be happy to help you formalize your project and produce proper documentation. We take
specification seriously so that we can make sure our clients will always get the most accurate estimate possible.

Redwerk team

We can work with various types of requirements:

  • Brainstorming notes;
  • Example-based requirements;
  • Business requirements;
  • Functional requirements;
  • Use cases.

If the requirements are missing any information, we’ll send the client a
list of clarification questions. We try not to miss anything important, but we also know that no one wants to have
to digest 60 pages’ worth of technical description, especially in the early stage of project planning. That’s why we
try to make specs brief and written in easy-to-understand non-technical language. We also send all specs to the
client for approval before beginning work.

But that’s not to say we avoid technical discussion altogether: we can also
provide clients with proposals regarding the optimal way to implement certain features or recommend technologies to

The process usually looks like this:

  • Client provides us with all information about the project;
  • We ask questions about features and components which could affect the estimate;
  • If no spec is provided, we compose one with the client’s approval;
  • We provide the final estimate.

Get In Touch

Need help with product requirements and specification? Redwerk business analysts have lots of experience in this field for all sorts of projects, and we always make sure that your product spec is exactly what you want to build.
Contact us now for free requirements analysis!

Projects We Have Done

Hear From Our Customer

«When we needed to access a piece of hardware with an undocumented protocol, we went to Redwerk and they did it.
When we needed a massively concurential web application, we went again to Redwerk and they did it. When we needed
intimate knowledge of different operating systems, we went to Redwerk and they did it again. That’s reassuring. To
whom do you think we shall go with our next challenging project?»
— Darius Popa, Owner at DigitAIR

Why Specification Is Key Element Of Software Development And Project Estimation
5 (100%) 10 votes