How Do I Formulate Requirements Correctly?

Content

1. Creating structure with use cases
2. Requirements detail use cases
3. Formulate requirements clearly and unambiguously
4. Prioritise requirements correctly
5. Avoid typical pitfalls
6. How our system processes your requirements
7. Summary

1. Creating structure with use cases

Structure your software selection with use cases. Use cases are clusters for related requirements and are suitable as a structuring level typically with a strong business perspective. In addition, use cases can also bundle non-functional aspects, such as commercial or compliance requirements.

2. Requirements detail use cases

Requirements detail the use cases. They are usually formulated in more technical terms and specify exactly what the software needs to provide. In this way, requirements bridge the gap between the business focus (of the use case) and the technical functions of an IT application. They are the basis for the evaluation and selection of IT solutions.

3. Formulate requirements clearly and unambiguously

Precise wording is crucial. Please note the following points:

• Use a clear template: Formulate requirements according to the following pattern: ‘The software should do [X] to achieve [Y].’
  • [X]: The specific function or property.
  • [Y]: The resulting benefit or goal.

• Think from the provider's perspective: Requirements must be clear and comprehensible for IT providers. Avoid internal vocabulary and ambiguities and rely on clear definitions instead.
• Differentiate between functional and non-functional requirements:
  • Functional requirements describe what the system should do from a user perspective (e.g. ‘Create invoices in PDF format’, ‘Enable data export in CSV format’).
  • Non-functional requirements define compliance or commercial aspects (e.g. ‘response time under 2 seconds’, ‘ISO 27001 certification of the provider’, ‘price cap’).
• Formulate positively: Describe what the software should be able to do, such that a 'yes' by the provider to your requirements is to be evaluated positively. Instead of ‘The software had bugs in the past’, formulate: ‘The software must be without bugs 99% of the time.’

4. Prioritise requirements correctly

Not every requirement is equally important. Clear prioritisation according to the MoSCo(W) prioritization model is essential for evaluating solutions. Use the following scheme:

• Must have: Essential requirements that are critical for the system to function.

• Should have: Important but not vital; they can be left out temporarily if needed.

• Could have: Desirable features that can improve user experience but are not necessary.

Won't requirements must not be added to the Stackgini "Requirements" view in the first place.

5. Avoid typical pitfalls

Errors in the formulation of requirements can occur even with careful planning. Common examples are vague descriptions, unclear priorities or overlooked dependencies.

6. How our system processes your requirements

With your clearly defined and prioritised requirements, our system can work efficiently: We extract the key points and compare them with the profiles of the solutions. This is how we identify suitable solutions for your needs.

7. Summary

With clear use cases as well as precisely formulated and correctly prioritised requirements, you directly influence the relevance of the proposed solutions. It is therefore worth investing care and time in the requirements in order to ultimately find and select suitable solutions for your needs.