| | |
|
|
|
|
|
3 System Features
From Web 2.0 Wiki, Wiegers Wiki Template
|
This template is organized by system feature, which is just one possible way to arrange the functional requirements. Other organizational options include by use case, mode of operation, user class, stimulus, response, object class, or functional hierarchy (IEEE 1998b). Combinations of these elements are also possible, such as use cases within user classes. There is no single right choice; you should select an organizational approach that makes it easy for readers to understand the product's intended capabilities.
3.N System Feature X
State the name of the feature in just a few words, such as "3.1 Spell Check." Repeat subsections 3.x.1 through 3.x.3 for each system feature.
3.N.1 Description And Priority
Provide a short description of the feature and indicate whether it is of high, medium, or low priority. Priorities are dynamic, changing over the course of the project. If you're using a requirements management tool, define a requirement attribute for priority.
3.N.2 Stimulus / Response Sequences
List the sequences of input stimuli (user actions, signals from external devices, or other triggers) and system responses that define the behaviors for this feature. These stimuli correspond to the initial dialog steps of use cases or to external system events.
3.N.3 Functional Requirements
Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present for the user to carry out the feature's services or to perform a use case. Describe how the product should respond to anticipated error conditions and to invalid inputs and actions. Uniquely label each functional requirement.
|
|
|
| |
| | |
|
|
|
|