Requirement Characteristics
Different sections are available in the properties of a requirement.
To access requirements, see Listing Requirements.Requirement general characteristics
Code
The code enables unique identification of the requirement.
Parent requirement
This is the requirement to which this requirement is attached.
Requirement type
A requirement type defines a risk typology standardized within the context of an organization.
Regulation framework
A regulation is a set of directives, compulsory or not, defined by a government in a law, by standard bodies as "best practices" or as an internal policy in an organization.
For more details on regulations, see Defining Regulations.Priority
Priority can be:
• Low
• Medium
• High
Source of Legislation
Legislations can be come from different sources:
• Stock Market Regulator
• Government
• National Bank
Type of legislation source
Legislation sources can be of two types:
• primary: legislation prevailing over any other legislation source
• secondary: derived legislation occupying a rank lower than primary legislation in the legal hierarchy; it provides information complementing primary legislation and can be presented in the form of rules, directives, decrees and frameworks.
Sanction type
• Penal pecuniary at risk penalty
• Administrative - medium risk of penalty
• Administrative - high risk of penalty
• Accessories
• Liability
• Penal detention
• N/A
Sanction
Here you can enter a text concerning the sanction applied if the requirement is not met.
Issuer
Here you can enter the requirement issuing organization.
Suggested test
This text indicates a text enabling verification of whether the requirement is met or not.
Analysis
• Risk factors
A risk factor is an element which contributes to the occurrence of a risk or which triggers a risk. Several risks can originate from the same risk factor. Examples: the use of a hazardous chemical product, the complexity of an application, the size of a project, the number of involved parties, the use of a new technology, the lack of quality assurance, the lack of rigor in requirement definition, etc.• Event type Basel (level 1)
• Event type Basel (level 2)
Responsibilities
HOPEX Compliance enables definition of responsibilities of each participant related to a requirement via the RACI matrix:
For more details, see "RACI", page 718.Scope
The Scope section of requirement properties enables connection of requirements to other objects:
• Business process
A business process represents a system that offers products or services to an internal or external client of the company or organization. At the higher levels, a business process represents a structure and a categorization of the business. It can be broken down into other processes. The link with organizational processes will describe the real implementation of the business process in the organization.• Organizational processes
An organizational process is a set of operations performed by org-units within a company or organization, to produce a result. It is depicted as a sequence of operations, controlled by events and conditions.• Entities
An entity can be internal or external to the enterprise: an entity represents an organizational element of enterprise structure such as a management, department, or job function. It is defined at a level depending on the degree of detail to be provided on the organization (see org-unit type). Example: financial management, sales management, marketing department, account manager. An external entity represents an organization that exchanges flows with the enterprise, Example: customer, supplier, government office.• Risks
A risk is a hazard of greater or lesser probability to which an organization is exposed.• Risk types
A risk type defines a risk typology standardized within the context of an organization.• Applications
An application is a set of software tools coherent from a software development viewpoint.Sub-requirements
Second level requirements (or sub-requirements) can be defined.
Milestones and Statuses
A specific tab enables specification of requirement milestones and statuses.
Expiration date - term of adjustment
This is the date limit by which the requirement must be fulfilled.
Creation date
Date on which the requirement was created.
Last update
This is the date on which the last import was made.
Official status (from import)
• To be validated
• Validated
• Updated
• Deleted
Regulations and requirements are never deleted automatically. If a regulation/requirement is obsolete, status passes to "Deleted".Internal status
You can indicate if the requirement:
• is To be assessed
• has already been Assessed
• N/A