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 House you want to outsource your project to.
Here are some essential, important and useful information that should find their way onto the project specification that you hand out for assessment and estimation.
Good To Keep In Mind
- Take advantage of talking with specialists. No one expects you to know everything and have everything planned. The developers and Business Analysts that you’re addressing will be able to propose solutions and ideas, as long as they know it’s needed.
- The more constraints you put upon the project, the more difficult it will be to bring it to completion within them. Try to keep an open mind when possible.
- Try to not overdo it with description length – too short and concise info will not give a clear enough picture of what you need and a too long and detailed one will be difficult to sift through.
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.
- What does your company do?
- What role will the app play in fulfilling your company’s goals?
- Is this a completely new project, a new version of an existing one or upgrading what you have?
- What problems do you want to solve with this project?
- What goals do you want to achieve with it?
- Who is the target audience?
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:
- Front-End / Back-End / Fullstack Developers
- Product Owner / Business Analyst / Scrum Master
- UX/UI Designer / Graphic Designer
- Manual Tester / Automation Tester
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:
- Mockups, frameworks and graphic designs
- Usability test and user feedback
- Backlog, project roadmap, release plan, etc.
- Any other existing documentation
Existing App – is your project a new version of an already existing application?
- What’s not right with the current version? What needs to be improved?
- What do you and your users like about the current version that you want to leave in and/or improve?
- What’s the existing codebase and documentation, and can the Software House get access to it in order to appraise it?
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.
Get A Template!
So now you know what to give to get more in return – how about we help you out some more?
Here! Have a Software Specification Document Template that will help you structure everything and lead you through the questions 🙂