Sure, you need to prepare for software development process. However, creating project specification is not about gathering a lot of info in one place. It's about gathering only valuable info. Learn how to do that.
Contrary to popular belief, great apps don’t just spawn out of thin air. They are an effect of careful planning, work of many people and long time of development. Preparation is as important for you as it is for the people that will eventually work for you. That is why it’s good to come prepared to talk with a software development agency you want to outsource your project to.
So how to write a good project specification?
Below you’ll find a set of essential information that should appear in the project specification document that you hand out for assessment and estimation.
The best way to start off is to make the document transparent – the top section should contain the most basic contact info: company name, website, people involved and their contact details.
Many people add a very short description of the project here – a few words about its grand idea and technology will spare the need to sift through the whole document.
Knowing what your company does and what role the app will play in your business will help us understand you and your needs better. When a development team understands why they’re coding something, they’ll be able to match their solutions to your goals.
All Development Teams work with certain sets of rules – it’s best to know if your rules are similar to the devs’ and what areas need to be adjusted in your future cooperation; which in turn will make the workflow that much more smooth.
Limitations – is there a budget constraint? Are you aiming for a specific deadline (if yes, why)?
Ownership – who do you want to lead the project – to make technical decisions, prioritize work, decide on Acceptance Criteria and so on?
People Involved – will the project be executed fully in a single development house? Will there be other developers involved? Will people from other areas (like Directors or Marketing Specialists) have input in the team’s work?
People you need – will you require a full team? Or just specific roles to be filled? Please consider if you require:
Workflow – are you used to working with any project framework like Scrum, Kanban or Waterfall? Will it be your requirement to work using it?
There are two ways to approach the features topic. Both have their advantages and disadvantages.
List – a detailed list of components and their desired attributes is a good way of handling teams over which you want (or need) to have more control or those that you feel need more guidance. The minus here is the limitations it puts on the Developers, especially if they are a self-organizing, highly specialized and self-sufficient team.
High level description – this is a great way to work with specialists. By roughly describing your needs regarding what you want the app to do, you allow for the team to plan their own solutions, tailored to your needs, when the real work begins. Instead of giving the Team a To-Do list, it allows for you to draw from experience of the Developers, Designers and Business Analysts that you plan to employ.
Data -knowledge about, or better yet, access to what you already have, will help us tremendously to evaluate the project and what needs to be done. This can be a multitude of things:
Existing App – is your project a new version of an already existing application?
For most it seems obvious that we should be aware for which platforms we’re to build the app. Web, desktop, mobile – Android and/or iOS. But if there are any additional requirements that you know exist, knowing them up-front saves everyone a lot of time.
Versions – what backward compatibility do you have in mind and why?
Dependencies – are there any APIs that need to be taken into account? Third party applications that we’ll need to connect to?
Stacks – are there any particular stacks you would want to use here? Why? If there is existing code, what language is it?
Good software specification allows the team you want to employ to address your business needs, the scope of your project and your expectations with more robust info than they’d derive from a simple brief.
As long as you show your vision and outline your needs in an unambiguous manner, every step after that draws from this clarity and creates better conditions for the success of your project.
Read next
Top reads
Become a better tech leader.
Join 200+ CTOs, founders and engineering managers and get weekly bite-sized leadership lessons that take <60 seconds to read.
Previous post
No previous chapters
