As an experienced software development company, we know that writing a good specification of system requirements is critical to the success of any software project. Working with dozens of companies from various industries, we have accumulated knowledge and created a vision of what the ideal specification should look like.
What is the technical specification?
A specification is a document that defines goals, tactics and a plan for the implementation of a project. It should contain restrictions such as budget, dates or technical restrictions. A more developed version may also include technical details, such as those involved, such as stakeholders or contact points. The specification should also include a description of business logic and a list of system functionalities. An additional advantage is the inclusion of graphic designs in the case of projects with graphical interface (eg mobile applications, web applications)
Why create a specification?
Such a document is usually used for the valuation of temporary work on a project, in many cases it is even necessary. In addition, it is often an attachment to the contract, indicating the extent to which work is to take place. To put it simply, the client should only expect what is written in the specification, so he should also care about building a reliable document describing the project, not just the development team. Of course, the situation changes in the case of a project based on the principle of T & M (time and materials) where on weekly sprints, tasks are set for the nearest time. Equally, construction of the specifications in this case should take place simultaneously with the progress of the project. And moreover:
- - increases the accuracy of time / cost estimates
- - it allows to see in advance the unexplained system behavior issues
- - prevents future problems resulting from not specifying information
- - defines the roles of team members in the project
What should the specification look like - on the example of a mobile application
The specification at the beginning should have a crackle, i.e. a short fragment (not more than 1/2 A4 pages) describing the project "from the bird's eye" not going into technical or functional details, but more describing what functionalities the application performs and what the user can do in it .
The document should contain a description of the screens (including attached graphics or mock-ups). Each of the screens should have a functional description, ie a description of what a user can do in a given location (eg click) and an explanation of the process in which information appears on the screen.
For example, in the application for ordering a taxi, the screen with the map should have a description that explains how the user can order a ride, but also very importantly how the data on possible journeys appear on the screen (eg via an API query). You should also remember about the transitions to a different place of the application that the user may make (eg going to the settings screen) or actions that may happen to him, e.g. a pop-up notification.
If the project concerns both the application and the api (backend) from which it is to be used, it is worth considering whether it is not worth separating the specifications into two documents or sections, separately describing the application and api. All this in order not to drown in the technical details, because mixing screen descriptions with the complicated logic of calculating road fares may even make reading difficult.
In addition, the specification should contain technical requirements, i.e. description of supported device and system versions, dependencies between external systems (if they exist), and the use of external services (eg Google Maps)
How to get to writing, or where to start?
When starting building specifications, you have to prepare yourself for several iterations. We do not have to require ourselves to describe the project accurately the first time, because at the moment we are just starting to materialize it on a piece of paper. The best way is to start from "total to detail". We begin to describe the main points of the system one by one, for example in one sentence. A good way for larger projects is to divide the project into modules, for example in the case of CRM, the ordering, dispatch and call center module, and describe each of them as a separate project in turn.
When we have a ready-made high-level sketch, we can begin to describe the details of the functionality and the dependencies between the individual modules. It is most often at this stage that the most unprejudiced issues appear, which will be precisely clarified.
Do not be afraid to repeatedly iterate on the document, carry out its reconstruction, at this moment such operation is "free" for us and it is much easier to model the project using text than to change the ready code whose creation often took several weeks.
When we recognize that the documentation is complete, it is time to show it to our colleagues in order to get comments, collect questions and make changes based on them, either stylistically or fully functional description. I think that this step is necessary because it is they who become the first "users" of our system in the design version! A look from another point on the project often throws a completely new light on it and you may find that you have forgotten some important issues.
What's next?
With the specification prepared in this way, we can start the project valuation. Of course, during the course there will be questions from our side that will add details in the documentation. But in this case, the more the better.
We provide the service of preparing specifications for the client. This process looks very similar to the above presented with the difference that we write it. Our job is to interview the client and ask a series of questions about the project. If you are interested in our offer, I invite you to visit our website and contact also get to know how we work and what is our exprience.
