Requirement Specification details
While the usage of Requirement Specifications is mandatory, their capabilities are all optional. Customers can decide about the features to use to meet their business process needs in the best way. The following sections can be used when defining a Requirement Specification.
Basic
This section is used for numbering and naming purposes
| Field | Description |
|---|---|
| ID | Each record will receive an automatic ID that is generated during initial save. This ID cannot be changed afterwards and will be inherited by the requirements that belong to this specification. |
| Title | A mandatory identifier that will be used as descriptor for the specification and shown to the users whenever they have to select the related specification |
| Description | More text can be added to describe the purpose and context of a specification |
| Group Name | Select the user group which will be set as Additional Owner for all requirements belonging to this specification. Use this field if dedicated access permissions should be applied across multiple teams and specifications (that is, to drive visibility across business units). This field also can be left blank if the additional ownership does not matter. This field’s list of options should be reviewed by your site administrator to make sure that only valid user groups can be selected (see chapter Set Up). |
| Requirements Counter | This counter is set automatically. Each new requirement will automatically increment to this counter. It is also used to drive the ID of requirements within this specification’s context. |
| Top Level Requirement | After creation of the Requirement Specification, the system will automatically create the matching top-level requirement and link it in this field. This top-level requirement will be used to collect all sub requirements. The naming of this new requirement is predefined by an automation. Your site administrator may change this in the Requirement Specifications script `onCreate’ |
Details
Define responsibility for the specification and its requirements in here. This drives approval defaults.
| Field | Description |
|---|---|
| Business Unit | Optional field to be used by reporting and filtering. |
| Customer | Optional field to be used by reporting and filtering. |
| Project | Optional field to be used by reporting and filtering. If this field is a text field and does not allow to select from your active projects, see the Set Up topic. |
| Internal Approvers | List of users to be involved in related Requirement Approval processes. If users are defined in here, this list will be copied to all new approval processes and with that grant approval permission for the selected users. Usage of this field is optional. |
| External Approvers | List of users to be involved in related Requirement Approval processes to manage the external approval. If users are defined in here, this list will be copied to all new approval processes and with that enforce the given workflow step (External Review) of the approval process. Usage of this field is optional. |
Reference Specification Data
The requirements definition might be based on external inputs and files. If so, the given sources of information can be captured in here, enabling to track when information was received by whom and when. These fields are just used for reference and are all optional.
You can also use the Files tab to upload any input files to the specification record. However, this tab does not enable to manage information per file (like the sender and date received).