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 estimates.

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 menu.

  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 estimate.

Scheme

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.

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.

Technologies

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

Description of existing components

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 as:

  • 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

THE PROCESS

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 use.

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.00/5 (100.00%) 9 votes