The specifications are the reference document for your project. It formalizes the needs that your service provider or your agency must meet. Would you build a house without making plans? You could try. But then how do you control the end result, how do you ensure sound management of your budget and how do you ensure that deadlines are met? Specifications are the very structure of your project…
In which case to write a specification?
I would tell you in any case.
However, depending on the nature of your project, this document will be more or less detailed. For complex projects, such as the development of a tailor-made application or an e-commerce site integrated into your information system, it will be supplemented by a technical specification book.
A “one page” showcase site based on a template, it is true, is easier to develop, but the specifications in this specific case will have the advantage of validating the choice of your template in relation to your activity. Imagine that you choose a template designed for artistic sites while you are selling industrial products…
What steps for writing your specifications?
Are you in the starting blocks in front of your blank page? Take a step back …
If the writing of your document indeed goes through an editorial phase, it also aims to make you think about your project.
- What do I want to bring to my users?
- Which sites do I particularly like and which can be used as a benchmark?
- What features identified will bring value and create opportunities for return on investment?
- What are my priorities?
This process allows you to mature your project, it is an iterative process.
Then you can move on to formalization.
What content in your specifications?
This time, you have to go …
Of course, your specifications are specific to your project, but certain best practices should be applied so that the document can be used by your service provider. It is not a question here of building an exhaustive list of headings, but of giving you some starting points:
- Graphic approach (in relation to your graphic load for example);
- Accessibility (on which browsers, mobility access);
- Access rights and profiles (who has the right to intervene, on which functionalities);
If I can give you a little advice, stay humble and reasonable when defining the functional perimeter of your site or application. 70% of the functionalities are generally not used!
Instead, prioritize and define different development phases. You can then adjust your initial needs with feedback from your users.
If you don’t prioritize, will your budget probably do it for you anyway?
What risks without specifications?
Many development projects are going well and both parties are satisfied upon delivery.
However, in the event of disagreement (let’s remain optimistic, don’t we talk about conflicts?) The specifications will be your reference and you can refer to them at any time. You think you have clearly expressed your needs during meetings with your service provider, but a formal document cannot be discussed and you will save precious time.
You do not feel a soul of Victor Hugo or Émile Zola? Use lists and bullets, be concise, but clear!
3 – 2 – 1 Go! To your notebooks!