Wednesday 14 December 2011
Sunday 30 October 2011
Catalog and type of requirement pattern
Many types of requirements crop up again and again, no matter what a particular new system is for. The idea of requirement patterns is to provide guidance on how to specify common types of requirements, to make it quicker and easier to write them, and to improve the quality of those requirements. A requirement pattern is applied at the level of an individual requirement: to explain how to write a requirement of that type. The anatomy of a requirement pattern contains various kinds of information to help both the writer of a requirement and developers and testers. A requirement pattern can also suggest additional topics for which to write requirements.
The "Software Requirement Patterns" book contains 37 requirements patterns, which together can account for well over half of all requirements for typical commercial systems. These patterns are shown in the diagram below, organized into eight domains:
The "Software Requirement Patterns" book contains 37 requirements patterns, which together can account for well over half of all requirements for typical commercial systems. These patterns are shown in the diagram below, organized into eight domains:
Catalog of requirement patterns
The following table describes the circumstances in which to apply each of the 37 requirement patterns (their "applicability"):
Requirement pattern name | Use this requirement pattern ... |
---|---|
Fundamental | |
Inter-system interface | to specify basic details for an interface between the system being specified and any external system or component with which it needs to interact. |
Inter-system interaction | to specify a particular type of interaction across an inter-system interface. |
Technology | to specify technology that must (or must not) be used to build or run the system, or with which the system must be capable of interacting or otherwise compatible. |
Comply-with-standard | to specify that the system must comply with a particular standard. |
Refer-to-requirements | to specify that some or all requirements in an external requirements specification must be satisfied as if those requirements were present in the current specification. |
Documentation | to specify that a particular type of documentation needs to be produced. |
Information | |
Data type | to define how a particular atomic item of information (a single field) for a particular business purpose is to be represented and/or displayed, or specify how a standard data type is always to be displayed (for example, all dates). |
Data structure | to define a compound data item (one that comprises multiple individual pieces of information) that occurs in more than one place or that contains too much to define neatly in one requirement. |
ID | to define a scheme for assigning unique identifiers for some type of entity or to indicate that a data item (or combination of data items) can be used as a unique identifier. |
Calculation formula | to specify how to calculate a particular kind of value, or how to determine a value via a process of logical steps. |
Data longevity | to specify for how long a certain type of information must be retained or for how long it must be available with a given degree of ease. |
Data archiving | to specify the moving or copying of data from one place of permanent storage to another. |
Data entity | |
Living entity | to define a type of entity for which information is stored and which has a lifespan (that is, is created, can be modified any number of times, and eventually terminated). |
Transaction | to define a type of event in the life of a living entity, and/or a function for entering such a transaction. |
Configuration | to define parameter values that control how the system behaves. |
Chronicle | to specify that a certain type or range of types of event (occurrence) in the life of the system must be recorded. |
User function | |
Inquiry | to define a screen display function that shows specified information to the user. |
Report | to define a report that shows specified information to the user. |
Accessibility | to specify the extent to which the system (or part of it) must be accessible by people with a certain kind of disability or other specific need—that is, how convenient it must be for them to use. |
Performance | |
Response time | to specify how much time the system may take to respond to a request. |
Throughput | to specify a rate at which the system—or a particular inter-system interface—must be able to perform some type of input or output processing. |
Dynamic capacity | to specify the quantity of a particular type of entity for which the system must be able to perform processing at the same time. |
Static capacity | to specify the quantity of a particular type of entity that the system must be able to store permanently (typically in a database). |
Availability | to define when the system is available to users: the system’s “normal opening times” (which could be “open all hours”) plus how dependably the system (or a part of the system) is available when it should be. |
Flexibility | |
Scalability | to specify a way in which a system must be able to expand without undue pain, typically to accommodate growth in business volume. |
Extendability | to mandate that a specific aspect of the system be built to make it easy to extend by “plugging in” extra software. |
Unparochialness | specify a particular way in which the system must not be limited to one business environment. |
Multiness | to specify that the system must accommodate multiple something-or-others at the same time, each of which has its own fundamentally distinct user interface or whose data must be kept rigorously apart from that of the others. |
Multi-lingual | to specify that the system is capable of displaying its user interface in more than one alternative natural language (for at least one class of user, though not necessarily all). |
Installability | to specify how easy it must be to install or upgrade the system (or a part of the system). |
Access control | |
User registration | to specify how new users are registered (set up in the system), with emphasis on capturing those details by which a user can later be authenticated (log in). |
User authentication | to specify that a person must make their identity known to the system before they can access anything non-public or anything for which they cannot remain anonymous (in short, anything for which they must log in). |
User authorization | |
Specific authorization | to specify that a set of users is authorized (or is not authorized) to do or see certain things. |
Configurable authorization | to specify that the definition of which users can do what is to be configurable (that is, can be changed dynamically). |
Approval | to specify that a particular action (or set of actions) must be approved (or, in some circumstances approved) by a second person before it takes place. |
Commercial | |
Multi-organization unit | to specify a type of organizational construct that the system must be able to support, whether that be units of a specific type or a more complex structure (such as a hierarchy). |
Fee/tax | to specify any fee or tax the system must calculate, report on, or levy. |
Tuesday 18 October 2011
Anatomy of requirement pattern
A requirement pattern contains nine sections:
- Basic details:
- Manifestation, to enable different variants of the same pattern to be distinguished.
- Owning domain.
- Related patterns, if any.
- Anticipated frequency—the number of requirements of this type in a typical system.
- Pattern classifications.
- Pattern author.
- Applicability: the situations in which the pattern can be used (and in which it shouldn't be used).
- Discussion: of the topic in general, and how to go about specifying requirements of this type.
- Content: A list of the items of information that a requirement of this type can contain.
- Template(s): A fill-in-the-blanks starting point for the definition of a requirement.
- Example(s): One or more real requirement definitions. Sometimes these are a more useful starting point for a requirement than the template.
- Extra requirements: A discussion of all the topics for which you might need to write further requirements.
- Considerations for development: Suggestions for developers on how to implement this type of requirement.
- Considerations for testing: Suggestions on what to bear in mind when testing requirements of this type.
Monday 17 October 2011
What Is Requirement Pattern & Its Example
A pattern is a guide. It gives you a form to follow when writing requirements. It can provide detailed suggestions on what to say, how to say it, and extra topics to consider.
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
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.
[ Read More ]
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.
Subscribe to:
Posts (Atom)