In the previous article you could read about how to find appropriate software company, which carries out the project of your idea. When you finally make a decision you will face another challenge. You probably already have a vision of your own project, however, the problem arises when you need to describe it on paper. How to start, what such a document should include, what should be avoided? This means writing a good specification of requirements, which aims to cover all the necessary functionalities of the new system in one document.

Read also: What shall we pay attention to when choosing software development company?

How to start?

1. Start with a brief description of your company/organisation. Try to define what type of organisation it is and how it performs.
2. Define the scope for which the system will be dedicated to. Will it be designed for the internal use or will it serve the external users.
3. Describe the business processes, which will be implemented in your company. The business processes are the repeated actions carried out within a specific organisation. Such processes will be converted into system functionalities.
4. Think about the objective of the system. You need to know the answers to the following questions: what the target is, which areas need to be assisted, what processes need to be improved. Then you should present the requirements of specific functionalities, which are to be introduced into the system. You can do it through the user stories, which describe the necessary functionalities in a simple way, from the users perspective. It will help the developer to visualise how you want to use the system. You can draw the plan step by step or present it in a graphic form. Please find the example below:

It is worthwhile to include in the graph the responsibilities of the system’s users as well as the initial entry matrix for the users of the specific functionalities.

Precious hint: Describe everything in a very specified way, the more details the better.

What do you need to remember about?

Do not disregard the non-functional requirements, such as: safety, productivity, responsiveness, availability (WCAG). It is crucial as it all makes the whole system work, and it translates into users perception. Therefore, we need to take into account the non-functional requirements from the very beginning when creating the system.

Do not assume that you will obtain something that you consider relevant without mentioning it in the document. Be precise when setting out your expectations. Explain the terminology, specification of your sector and your company.

Which mistakes to avoid?

Try to avoid the general descriptions, which may be in interpreted in a wrong way or taken out of context. It often happens that the client is not able to visualise the system and not sure what exactly the system should cover. For example, they need the system to generate the reports but they are not sure how it should work.

If you happen to be in a similar position, do not hesitate to express that you are not sure about certain aspects. Provide a general information and request the support from the Analyst. You will discuss the details then, and the team may suggest a solution and present how it should all work.

If you happen to have already the system and need to process it again from the start do not consider looking at or comparing it to the existing one. Do not create the descriptions of the same functionalities. Concentrate on defining how each function works, not on the design of the system.

Prioritization of requirements

The prioritization of requirements is helpful when you need the fastest activation of the system in MVP. Think which elements should be included in initial version of the system. Some functionalities – the less important ones – may be added at a later stage. It may also help to obtain financial resources necessary to further software development.

Read also: MVP – How To Start?

To summarize, the specification of requirements should include:

• The company goals,
• Brief description of business field,
• Project’s objective,
• Guidance to users group and the main recipient,
• General description of business processes in organisation,
• Description of specific areas that need system’s assistance,
• Definition of requirements and tasks that need realisation,
• Specification of users number and the amount of information,
• List of non-functional requirements.

The example of well-defined requirements:

“The system, for both the clients and the traders, should be responsive and prepared to be displayed on both large screens and smartphones” – if it has been described which parts of the system are available for the clients and traders, the requirement becomes very precise.

“The trader on the list of offers for acceptance, approves the clients offer. The mail with the confirmation is being sent to the client. The offer obtains the status ‘accepted’, and the client can’t edit the offer at this point. The offers becomes visible for the storage department”. – it has been set out who is responsible for a specific procedure, it has been specified which offers can be dealt with and what the results of that procedure will be.

The example of incorrectly defined requirements:

“The system should have a flexible interface” – it is not clear what flexibility is considered. Responsiveness? Customization?

“The system should enable quick additions of new positions to the offer” – what does the ‘quick’ mean? How to measure it?

“The user accepts the offer” – which user? What happens after the acceptance?

The separate case is the requirements that happen to be incomplete, and even incorrect:

“The system should enable the selection of the colour of the specific elements of product B, as it has been described in product A” – sounds good but it turns out that: product A can select only one main colour for the whole product, product B can arrange different colours for its specific elements, but certain colours will not connect together as for the necessity of maintaining the coherent tone of the whole product B. There is a simple list of colours in product A, while in product B there is a few lists of colours. The selection of one usually causes the restriction of colour lists on the remaining selection lists.

As it is commonly known, everyone uses their own business terminology. It is important to use the language in a clear and understandable way for the parties involved. Remember that the specification of requirements doesn’t require any expert knowledge. The main aim of this document is to collect all functionalities that the system needs to have, in accessible and structured way.

You can create the specification of requirements by yourself but remember that you may always ask for assistance. If you need to – request the advice from the analytical team. If you look for a professional assistance – check the services from the third parties, such as ours.

Consulting means the services of assistance with appropriately selected IT tools, in terms of operational systems for instance. Deep analysis is performed along with specification of requirements in the course of the series of meetings with the best specialists. The meetings often bring out all the concerns of the participants as well as the expectations and questions. Such a preparation helps to establish a common vision of the system, which will result in an adequately performed work.

Please check the specific stages of consulting at Evertop.