The benefits of adopting requirements patterns:
First, they provide guidance: suggesting the information to include, giving advice, warning of common pitfalls, and suggesting other matters you ought to consider. Second, they save time: you don’t have to write each requirement from scratch, because the pattern gives you a suitable starting point, a foundation to build on. Third, patterns promote consistency across requirements of the same type. Of these, guidance is of the greatest value. Saving specification time and increasing consistency are nice, but sound guidance that leads to much better requirements can avoid immense trouble and work later on.
What is the difference between requirement pattern and a template
Requirement patterns represent standards to producing individual requirements, rather than a “fill-in-the-blank” document, as with many software requirements templates. Second, requirement patterns provide context around a template. It should say, for example, when to use the individual requirement template, and how to write requirements based on it. It provides not only the form to follow when writing requirements of the same type, but also the applicability of the pattern, and examples of requirements written using the pattern.
Example of requirement pattern
Pattern name: Basic requirement pattern
Applicability: Functional and non-functional requirements that don’t fit in any of the specific patterns in our catalog.Requirement ID | Unique identifier |
Title | Name of the requirement (up to 6 words) |
Summary | Brief description of the requirement |
Details | Detailed behavior that is required from the software application (decompose high-level requirements into enough detail to reveal exactly what is being requested). |
References | Use cases and other requirements that are relevant to understanding this one. |
Example:
Requirement ID | FR-4 |
Title | Personalized web store experience |
Summary | Present different versions of a page to customers based on membership to a particular customer group. |
Details | When a logged in customer visits a web store page, the system will display personalized content based on the customer group the customer belongs to. |
References | UC-3: Define personalized content for each customer group (back office function). |
Pattern name: Reporting
Applicability: Use it to define the requirements for a report that shows specified information that may include numeric and textual values and graphical representation to the user.Requirement ID | Unique identifier |
Title | «Report name» report |
Summary | Provide a report that shows «Information to show» «Selection criteria» sorted by «Sort sequence». The purpose of this report is to «Business intent». |
Details | «ID» For each «Item type name», the report will show the following:
[«ID» The report is intended to be run automatically «Automatic run details».] |
References | List here the use cases and other requirements that are relevant to understanding this one. |
Example:
Requirement ID | FR-6 |
Title | “Daily Sales” Report |
Summary | Provide a report that shows all sales occurred in the previous day. The purpose of this report is to allow the VP of Sales to monitor the performance of the sales team on a daily basis. |
Details | FR-6.1 The report will show the following information for the sales transactions occurred in the previous day:
FR-6.3 The report will run automatically every business day at 7am. FR-6.4 The report will be sent by email to the account manager supervisor eath time it is issued. |
References | ST-17: Standard report layout (applicable to all corporate reports) |
Tailoring requirements patterns to your particular needs
Patterns are usually an abstraction, and you may have to do a little work to adapt them to each particular situation. As you can see in the example of requirement FR-6, not all elements from the requirement pattern may be needed — in that case, “sorted by” information was not necessary for the specific report (it could be important, though, for a different report that needed ordering by date, alphabetical order, etc.). On the other hand, the original pattern did not include a provision for describing the report being sent to specific users (captured in FR-6.4). It is, however a good starting point, that you can tailor to each particular need.Even if there is some work involved in tweaking the requirements patterns every time you need to use them, collecting patterns from your projects and other people’s projects will help you to improve your requirements writing skills, and save time completing your next requirements documents.