"Requirements specification" and "catalogue of requirements" are also indispensable in the SME environment
Let's assume that you receive one offer each based on various conversations with possible providers. Since you have not given the providers any concrete specifications (written requirements), but have simply spoken with them, it becomes almost impossible to compare the offers with each other. This is because you responded more to a requirement with one provider than with the other. This means that one provider has focused more on a specific requirement than another.
For this reason, it is important for every procurement of software or hardware to draw up a requirements specification as well as a catalogue of requirements. If this is not done, there is no way to check later whether the requirements and goals have been met or not.
But what exactly is a requirements specification?
Basics specifications
A specification sheet (also called requirements specification, requirements catalogue, customer specification or user specification) describes the totality of the requirements of the client for the delivery and service of a contractor.
The requirements must be formulated in a specification as generally as possible and as restrictively as necessary. This gives the contractor the opportunity to develop a suitable solution (e.g. a software) without being limited in his solution competence by requirements that are too specific.
The client can use the specifications in a tender and send them to several potential contractors. When responding to the requirements specification, the contractors draw up a requirements specification which describes in concrete form how they intend to solve the requirements in the requirements specification. Based on a cost/benefit analysis, the client then has the opportunity to select the most suitable supplier or product.
Content of a specification
A specification should be structured as follows:
Introduction
Description of the current situation
Description of the target situation
Possibly description of interfaces
Functional requirements (What should the product do?)
Non-functional requirements (How well should the system perform?)
Usability (ease of use)
Reliability
Efficiency
Modifiability
Transferability
Maintainability
Risk acceptance
Sketch of the development cycle and system architecture
Scope of delivery
Acceptance criteria
Tip: Draw up the requirements specification together with the employees who know the processes, because this avoids false or inaccurate requirements being placed on a new software.
The requirements and expectations should be formulated in such a way that they can later objectively assess the fulfilment.
If there are confidential contents in the specifications, first have the suppliers sign a confidentiality agreement before you pass on the specifications.
How detailed should a specification be?
If the requirements are only roughly specified, the supplier may deliver an unusable IT solution/software and the contract is still considered fulfilled from a legal point of view.
For a detailed specification, a requirements analysis should be carried out using the methods of requirements engineering and the corresponding time invested.
However, a comprehensive and detailed requirements specification is also no guarantee for a good IT solution, as it is not the only influencing factor. A lot depends on how committed the supplier is to working with you on a good IT solution implementation.
It is essential that the following points are specified in detail:
Required delivery items and services
Business processes to be supported
Data to be managed (data requirements)
Important/critical functions
Data interfaces
The supplier's commitment should already be apparent in the phase of drawing up the specifications. If you already have doubts at this stage that the supplier will deliver a good solution, you should seek discussion with the supplier (management). In the worst case, you would have to replace the supplier, but sooner rather than later, otherwise this will result in much higher costs.
Must and Can Criteria
It makes sense to divide the requirements into "must" and "can" requirements in the specifications. This makes it clear to the provider which requirements are mandatory and which are "nice to have".
The difference between "must" and "can" requirements is described below:
Must-have requirement: A requirement with a must-have criterion is absolutely necessary for the intended application. If the offered solution does not support a must-have criterion, it is not useful for the intended application.
Can requirement: The optional criteria (nice to have) are improvements to the offer, but they are not absolutely necessary.
Independent support from actesy
If you need support with the creation of a requirements specification and/or the requirements catalogue, we can gladly accompany and advise you in this process. Actesy can score points as a completely independent consultant with over 30 years of IT experience. This independence results from the fact that actesy does not sell any business software and therefore has no party preference for a possible IT provider, but is itself only active as a data orchestrator and integrator. However, the experience gained from a large number of different IT projects helps SMEs in particular to establish requirements as well as to select a suitable software solution for the future. This means that you always have an independent and experienced partner at your side who can help you in all areas of IT in a needs-based and uncomplicated manner.
