Effective Requirement Writing Techniques: Tips and Strategies

The essence of requirements engineering is to clarify requirements, the set of information shared by all stakeholders (analysis, UI/UX, development, test and POC teams, and the end-user).

If the requirements are unclear, they can be open to misinterpretation. A misunderstood requirement may lead to costly errors.

So, how can we write requirements effectively?

1.Avoid Ambiguous Expressions

Avoid phrases that could be interpreted differently by different people. Ensure that everyone understands the same thing when they read the requirements.

For instance, in the statement:

• The user will be able to easily record purchasing methods.

words like "easily," "normally," or "efficiently," which are subjective and lack precision, should be avoided.

To ensure consistency, use uniform terminology while writing requirements. Minimize the use of jargon or specialized terms. If such terms must be used, define them in the glossary section of your document to prevent any confusion.

2.Structure and Atomization

Ensure that requirements are written in a structured format, preferably as bullet points, and are atomic.

For Example:

• CompanyAbbreviation-ProjectAbbreviation-RequirementType(SRS or SSS)-UniqueRequirementNumber: Relevant SCC (Software Configuration Component), Relevant SCU (Software Configuration Unit), requirement.

FRHT-FOO-SRS-740070: The Bar SCE, Baz SCU will allow the user to query purchasing methods.

To maintain atomization, avoid using conjunctions like "or" or "and" in a requirement statement. These often indicate multiple tasks within a single requirement. Focus each requirement on a single task by eliminating such connecting words.

3.The Requirement Expresses The Entire Work To Be Done

A requirement should comprehensively address the scope of the task. To achieve this, it is essential to answer the following questions:

• In what conditions will it be used?
• When will it be executed?
• Who or what (person/system) will perform the task?
• What action or operation will be performed?
• What are the constraints on the affected person/object in specific situations?
• Under what conditions will the requirement not be applicable?

In addition to these points, ensure that the requirements:

• Align with the expectations of the end user while considering the interests of the company.
• Avoid conflicts with the expectations of legal departments or other organizational units.
• Are designed to meet the user’s needs without contradicting corporate goals or guidelines.

Example Requirement:

1. FRHT-FOO-SGS-740090: The Bar SCE, Baz SCU will enable the user to delete purchasing methods if they are not used in another record.

4.Maintain Consistency and Group Similar Requirements

We pay attention to grouping the requirements that describe the same work so that development and testing activities can be carried out easily in a way to covers 100% of the requirements, and if the end-user requests changes when the developed and tested product is presented to the end user if the end-user requests changes, we pay attention to grouping the requirements that describe the same work so that the engineering/contract change proposals that are deemed appropriate as a result of the analysis and analysis of the change request can be made easily and accurately.

Example:

1. FRHT-FOO-SGS-740060: The Bar SCE, Baz SCU will enable the user to record purchasing methods hierarchically.
2. FRHT-FOO-SGS-740070: The Bar SCE, Baz SCU will enable the user to query purchasing methods.
3. FRHT-FOO-SGS-740080: The Bar SCE, Baz SCU will enable the user to update purchasing records as active/inactive.
4. FRHT-FOO-SGS-740090: The Bar SCE, Baz SCU will enable the user to delete purchasing methods if they are not used in another record.

5.Ensure Traceability

In the event of contradictions, it is critical to resolve the contradictions in order to prevent the development of faulty products and avoid unnecessary costs. In order to resolve contradictions, we record the meetings and e-mail correspondence with the end user and associate them with the relevant addition/update/deletion requirement in the engineering/contract change proposal document to be written, so that we can see in which meeting or e-mail correspondence the end user stated his/her need or change request, By specifying which specification item I am basing the addition/update/deletion engineering/contract change proposals that will occur as a result of this request, we pay attention not to write a requirement that will take away from the functionality that the software will provide, not to write a requirement that will bring additional cost, and to ensure that when a requirement is looked at later, it is traceable why this requirement exists.

6.Prioritization of Requirements

It is essential to prioritize requirements and specify which ones should be developed first. This ensures the team focuses initially on mandatory requirements and subsequently on “nice-to-have” features.

Some of the techniques we use to prioritize requirements:

• Grouping or Sorting: This approach, you can assign a ranking or priority indicator to various requirements. For example, you can assign priority values as high/medium/low or even numeric values.
• Time Boxing/Budgeting: This approach can be used when there are fixed timelines and budgets to achieve project milestones. This approach is based on the principle of launching an MVP or core product with the required features on time, rather than launching a product with all features at a later date.
• Deliberation or Voting: This approach involves building consensus among stakeholders and prioritizing requirements based on various votes or inputs.

7.Verifiable and Testable Requirements

We make sure that the quality assurance or testing team can verify whether a requirement has been developed correctly.

1. System screens should be user-friendly.

We do not write statements in the requirements text that are not verifiable-testable, such as “user-friendly”. In addition, when writing requirements, we also specify how they will be verified and what the acceptance criteria will be.

Finally, even if the requirement is written by paying attention to the above items, the end user may not have expressed the need correctly, or the team member who performed the analysis may not have understood the end user's need correctly. In order to prevent wrong product development and unnecessary development costs, it should be kept in mind that as the development of the requirements is completed, the verification process should be carried out on the intermediate product, i.e. checking whether the product is built in accordance with the design documents, standards, and specifications and whether it works without errors, and then validation by showing it to the end user, i.e. whether the product works in real-world conditions and in accordance with user expectations, and recording the additional requests of the end user, if any, should be progressed by shaking hands.

Thanks for reading so far, I hope it was engaging for you.