I define a phrase template as a ready-made skeleton for a single requirement or a user story in natural language. In requirements engineering, I use phrase templates to write clear and uniform sentences. First, a phrase template gives placeholders. Then, I fill the placeholders with concrete content. As a result, I get well-structured sentences that stakeholders can read and check.
For example, I often use the ISO/IEC/IEEE 29148 template: [] []. For example, When a valid card is sensed, the system shall display the “Enter your PIN” message on the dialog screen within 200 ms. Moreover, I use this template to separate the trigger, the actor, the action, and any constraints. Therefore, I avoid ambiguity. In addition, I keep each requirement focused on one behavior or property.
I also use phrase templates for user stories. For example, I apply Cohn’s classic template: As a I want so that . For example, As a line manager, I want to make ad hoc inquiries to the accounting system so that I can do financial planning for my department. Furthermore, I always add acceptance criteria. Consequently, the user story becomes testable and less ambiguous.
When writing requirements with phrase templates, I follow simple conventions. First, I use auxiliary verbs to mark requirement strength. For example, shall marks mandatory requirements. Should signals strongly desired but not mandatory requirements. May expresses suggestions. Will or the present tense states facts that are not requirements. Second, I prefer active verbs and short sentences. Third, I avoid combining multiple requirements in one sentence.
However, I exercise caution with general words and structures. For instance, when I use universal quantifiers such as all or always, I check whether exceptions exist. If exceptions exist, I specify them. Also, I avoid nominalizations that hide steps or procedures. For example, the noun authentication can hide the actual authentication steps. Therefore, I verify whether I must add requirements for the procedure itself.
Moreover, I adapt phrase templates when requirements grow complex. For example, I combine WHEN, WHILE, and WHERE clauses to express timing and location conditions. In addition, I can use domain-specific templates such as EARS for cyber-physical systems when appropriate. EARS helps me keep structure, and therefore it reduces ambiguity.
In practice, I pair phrase templates with form templates and document templates. While phrase templates handle single sentences, form templates structure medium-size work products such as use cases. Finally, I follow simple writing rules. I focus on one requirement per template, I use precise terms, and I write acceptance criteria. As a result, I produce clear, consistent, and testable requirements.