From 058b9c246ea54b01ee510b0b0105431460cec1e7 Mon Sep 17 00:00:00 2001 From: "Dr. Gernot Starke" Date: Mon, 19 Aug 2024 11:35:09 +0100 Subject: [PATCH 1/6] propose simplified scenario template. --- _articles/06-quality-requirements.md | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/_articles/06-quality-requirements.md b/_articles/06-quality-requirements.md index 4b5c140..ebfd448 100755 --- a/_articles/06-quality-requirements.md +++ b/_articles/06-quality-requirements.md @@ -27,19 +27,38 @@ Quality scenarios, in short, are a pragmatic, easy-to-use and general approach t >You find {{ requirement_posts | size }} examples of such quality requirements on this site (see [examples](/requirements)). -### General structure of quality scenarios +### General structure of quality scenarios (SEI-version) ![general form of quality scenarios](/images/articles/q-requirements/q-scenario.png){:width="50%"} * **Event/stimulus**: Any condition or event arriving at the system. -* **Response**: The activity undertaken after the arrival of the stimulus. -* **System** (or part of the system): Some artifact is stimulated, which may be the whole system or some distinct pieces (artifacts) of it. +* **Source of stimulus**: The entity (person, system, or other actor) that generates the stimulus. +* **Environment**:The conditions or context under which the stimulus occurs. +* **Artifact**: The part of the system that is affected by the stimulus. +* **Response**: How the system should react to the stimulus. The activity undertaken after the arrival of the stimulus. * **Metric** (response measure): The response should be measurable in some fashion, so that this scenario (quality requirement) can be objectively assessed or tested. +Although this template is widely used, it suffers from some drawbacks: +* The template's detailed nature can make it time-consuming to complete, especially for numerous scenarios. +* Teams might feel compelled to fill out all sections in detail, even when not necessary for every scenario. +* The comprehensive approach might not align well with fast-paced, agile development methodologies. +In practice, a slightly reduced template proved to be sufficient, let's call it the Q42-Requirements template: +### Pragmatical Quality Scenario + +**Context/Background**: A brief description of the situation. This includes the type of system, the relevant environment or operational setting, and the specific condition being considered. + +**Source**: The origin of the event or stimulus that triggers the scenario. This could be a stakeholder action (e.g., user interaction, administrator action) or an external event (e.g., system load, security threat, API call). + +**Metric/Acceptance Criteria**: A clear, measurable outcome that determines whether the system meets the desired quality attribute. This could be expressed as a specific performance metric, threshold, or success criterion that must be achieved under the given context. + +Only three (instead of SEI six) attributes, but understandable and precise. ### Summary -**Quality scenarios** document and clarify the required quality attributes. They help to describe required or desired qualities of a system in a pragmatic and informal manner, making the abstract term “quality” more concrete, specific and tangible. +**Quality scenarios** document and clarify the required quality attributes. +They help to describe required or desired qualities of a system in a pragmatic and informal manner, making the abstract term “quality” more concrete, specific and tangible. + +We propose you try the pragmatic and simple Q42-Quality-Scenario template for your own projects. From 7d4d31552851a53a8349c8791676ab28d23aa995 Mon Sep 17 00:00:00 2001 From: "Dr. Gernot Starke" Date: Mon, 19 Aug 2024 15:01:32 +0100 Subject: [PATCH 2/6] converted "D"-scenario to pattern form --- ...-data-throughput-for-visual-test-system.md | 31 ------------------- ...-data-throughput-for-visual-test-system.md | 27 ++++++++++------ 2 files changed, 18 insertions(+), 40 deletions(-) delete mode 100755 nreqs/_posts/2023-03-18-data-throughput-for-visual-test-system.md diff --git a/nreqs/_posts/2023-03-18-data-throughput-for-visual-test-system.md b/nreqs/_posts/2023-03-18-data-throughput-for-visual-test-system.md deleted file mode 100755 index 1bba709..0000000 --- a/nreqs/_posts/2023-03-18-data-throughput-for-visual-test-system.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Data Throughput for Visual Test System" -tags: efficient usable -related: throughput, efficiency, performance, capacity -permalink: /requirements/data-throughput-for-visual-test-system ---- - -
- -**Background**: Our hardware boards enhance simple webcams with image recognition capabilities. -Our (proprietory) advanced image recognition algorithms are embedded in the firmware of these boards. - -These boards are used for example in license-plate recognition systems in many public parking facilities. - -The quality requirement relates to the firmware test and verification system. - -**Scenario**: An update of the firmware is available (usually with additional functionality of improved recognition performance). Prior to release, we need to verify that this updated firmware recognizes with at least the accuracy of the previous versions. -The test and verification process needs approximately 1000 hours of video and image playback. - -**Metric**: The 1000 real-hours of video need to be played back to the device-under-test in less than 72 hours. - -That means that a video taken in real-time needs to be played back to the device-under-test in at least 14-fold speed. The test and verification system needs to ensure this throughput from both software and hardware (I/O, network and processing capabilities). - -

- - - - - - - diff --git a/requirements/D/_posts/2023-03-18-data-throughput-for-visual-test-system.md b/requirements/D/_posts/2023-03-18-data-throughput-for-visual-test-system.md index 1bba709..b01bb96 100755 --- a/requirements/D/_posts/2023-03-18-data-throughput-for-visual-test-system.md +++ b/requirements/D/_posts/2023-03-18-data-throughput-for-visual-test-system.md @@ -6,21 +6,30 @@ permalink: /requirements/data-throughput-for-visual-test-system ---
+#### Context/Background -**Background**: Our hardware boards enhance simple webcams with image recognition capabilities. -Our (proprietory) advanced image recognition algorithms are embedded in the firmware of these boards. +The system consists of hardware boards that enhance simple webcams with image recognition capabilities. +These boards contain proprietary advanced image recognition algorithms embedded in their firmware. +The boards are used in applications such as license-plate recognition systems in public parking facilities. +A test and verification system is used to validate firmware updates prior to release. +The quality requirement pertains to the performance of this firmware test and verification system. -These boards are used for example in license-plate recognition systems in many public parking facilities. +#### Source -The quality requirement relates to the firmware test and verification system. +An update of the firmware is available, typically including additional functionality or improved recognition performance. -**Scenario**: An update of the firmware is available (usually with additional functionality of improved recognition performance). Prior to release, we need to verify that this updated firmware recognizes with at least the accuracy of the previous versions. -The test and verification process needs approximately 1000 hours of video and image playback. +#### Metric/Acceptance Criteria -**Metric**: The 1000 real-hours of video need to be played back to the device-under-test in less than 72 hours. - -That means that a video taken in real-time needs to be played back to the device-under-test in at least 14-fold speed. The test and verification system needs to ensure this throughput from both software and hardware (I/O, network and processing capabilities). +* The test and verification system must process 1000 real-hours of video and image playback in less than 72 hours +* This translates to a minimum playback speed of 14 times real-time (1000 hours / 72 hours ≈ 14) +* Specific criteria include: + * Consistent maintenance of at least 14x playback speed throughout the entire test process (or less if tests are performed in parallel) + * Accurate data transmission to the device-under-test at this accelerated rate + * No loss of video frames or degradation of image quality during accelerated playback + * Verification that the updated firmware recognizes images with at least the accuracy of previous versions + * Complete processing of all 1000 hours of test data within the 72-hour timeframe + * Accurate logging and reporting of test results, including any anomalies or performance issues detected

From 0a4d51a57f2da461f9a84ae67721ac5f49c15341 Mon Sep 17 00:00:00 2001 From: "Dr. Gernot Starke" Date: Mon, 19 Aug 2024 15:01:45 +0100 Subject: [PATCH 3/6] converted all A-scenarios to pattern form --- ...00-09-03-access-find-function-in-3-secs.md | 16 ++++-- ...3-18-accurate-estimate-of-contract-rate.md | 19 +++++-- .../A/_posts/2023-06-21-add-new-product.md | 15 ++++-- ...07-03-accountability-detailed-audit-log.md | 30 +++++++---- ...07-03-authenticity-of-digital-document..md | 38 ++++++++----- .../2023-07-23-access-control-is-enforced.md | 54 +++++++++---------- .../A/_posts/2023-09-04-affordable-crm.md | 46 ++++++++-------- .../2023-09-04-appearance-requirements.md | 44 +++++++++++---- ...-09-04-assess-impact-of-proposed-change.md | 36 ++++++++++--- ...023-12-05-accurate-vehicle-position-gps.md | 22 ++++++++ .../A/_posts/2024-04-20-accessible-ui.md | 23 +++++++- 11 files changed, 242 insertions(+), 101 deletions(-) diff --git a/requirements/A/_posts/2000-09-03-access-find-function-in-3-secs.md b/requirements/A/_posts/2000-09-03-access-find-function-in-3-secs.md index 882fdd5..72d08e5 100755 --- a/requirements/A/_posts/2000-09-03-access-find-function-in-3-secs.md +++ b/requirements/A/_posts/2000-09-03-access-find-function-in-3-secs.md @@ -6,12 +6,22 @@ permalink: /requirements/access-find-function-quickly ---
+#### Context/Background -Users must be able to access the _find_ function within 3 seconds of accessing the interface. +The system is a software application with a graphical user interface, accessible via mobile or desktop platforms. +The application includes various functions, with the "find" function being a critical feature for locating specific types of data within the system. -**Background**: Users operate the system via a graphical frontend (i.e. like in a typical mobile or desktop application). -One important type of function within the system is _finding_ certain types of date. +#### Source +User interaction - A user accesses the find function from the application's main interface. + +#### Metric/Acceptance Criteria + +The "find" function must be accessible to users within 3 seconds of the interface loading. +This can be measured by: +*. Time from interface load completion to the "find" function becoming interactive and ready for use. +*. Success rate: At least 99% of users should be able to access the "find" function within the 3-second timeframe. +*. Consistency: This performance metric should be maintained across different devices and network conditions typical for the application's intended use.

diff --git a/requirements/A/_posts/2023-03-18-accurate-estimate-of-contract-rate.md b/requirements/A/_posts/2023-03-18-accurate-estimate-of-contract-rate.md index e4c0f0f..2a4888b 100755 --- a/requirements/A/_posts/2023-03-18-accurate-estimate-of-contract-rate.md +++ b/requirements/A/_posts/2023-03-18-accurate-estimate-of-contract-rate.md @@ -7,14 +7,25 @@ permalink: /requirements/accurate-estimate-of-insurance-rate
-**Scenario**: A user configures a health insurance contract in the online app. +#### Context/Background -**Reaction**: The system calculates a price estimate based on the currently available information. +The system is an online application for configuring health insurance contracts. +The final price of the insurance rate needs to be determined by the backoffice employees of the insurance company due to legal and organizational reasons. +This constraint cannot currently be relaxed. -**Metric**: This estimate must be within a ±15% margin relative to the final price. +#### Source -**Background**: The final price of the insurance rate needs to be determined by the backoffice employees of the insurance company due to legal and organizational reasons. This constraint cannot currently be relaxed. +User interaction: A user configures a health insurance contract in the online app. +#### Metric/Acceptance Criteria + +The system must calculate a price estimate based on the currently available information. +This estimate must be within a ±15% margin relative to the final price. +This can be measured by: +* Comparing the system-generated estimate to the final price determined by backoffice employees +* Calculating the percentage difference between the estimate and final price +* Ensuring that at least 95% of estimates fall within the ±15% margin +* Regularly auditing a sample of contracts to verify compliance with this metric

diff --git a/requirements/A/_posts/2023-06-21-add-new-product.md b/requirements/A/_posts/2023-06-21-add-new-product.md index 74bb372..db5bce8 100755 --- a/requirements/A/_posts/2023-06-21-add-new-product.md +++ b/requirements/A/_posts/2023-06-21-add-new-product.md @@ -7,15 +7,20 @@ permalink: /requirements/add-new-product
-**Background**: Editor uses administration panel to add a new product to a webshop -**Source**: Editor +#### Context/Background -**Stimulus**: Adds new product +The system is a webshop with an administration panel for editors to manage products. +Editors can add new products to the webshop through this administration panel. -**Reaction**: Product is visible in the webshop in under 60 minutes +#### Source -**Metric**: The time taken for a newly added product to become visible and available for users in the webshop is 60 minutes or less +Editor uses the administration panel to add a new product to the webshop. + +#### Metric/Acceptance Criteria + +The time taken for a newly added product to become visible and available for users in the webshop is 60 minutes or less, +for at least 95% of newly added products.

diff --git a/requirements/A/_posts/2023-07-03-accountability-detailed-audit-log.md b/requirements/A/_posts/2023-07-03-accountability-detailed-audit-log.md index 58400db..d6aa7d7 100755 --- a/requirements/A/_posts/2023-07-03-accountability-detailed-audit-log.md +++ b/requirements/A/_posts/2023-07-03-accountability-detailed-audit-log.md @@ -7,21 +7,31 @@ permalink: /requirements/detailed-audit-log
-**Stimulus**: A user submits a request to access personal data stored in the system. -**Environment**: System operates in compliance with privacy and data protection regulations. +#### Context/Background -**Response:** The system should maintain a detailed audit log of all user actions, including data access, modification, and deletion, along with associated timestamps and user identifiers. -This log should be tamper-proof, accessible only to authorized personnel, and retained for a minimum of five years. +The system stores personal data and operates in compliance with privacy and data protection regulations. +The system maintains detailed audit logs of all user actions related to personal data. +These logs are crucial for ensuring accountability, transparency, and compliance with regulations. +The logs facilitate the identification and investigation of any unauthorized or suspicious activities related to personal data. -**Background:** In this scenario, the accountability requirement is described for a system that stores personal data and operates in compliance with privacy and data protection regulations. -When a user requests access to their personal data, the system should respond by maintaining a detailed audit log that captures all user actions related to data access, modification, and deletion. -The log should include timestamps and user identifiers, ensuring traceability and accountability for all data-related activities. -It should be tamper-proof and accessible only to authorized personnel to prevent unauthorized modifications. -Furthermore, the log should be retained for a minimum of five years, aligning with data retention requirements. +#### Source -By meeting this accountability requirement, the system promotes transparency, facilitates compliance with regulations, and enables the identification and investigation of any unauthorized or suspicious activities related to personal data. +User submits a request to access personal data stored in the system. +#### Metric/Acceptance Criteria + +The system must maintain a detailed audit log of all user actions, including data access, modification, and deletion. +The audit log must meet the following criteria: +* Include associated timestamps and user identifiers for each action +* Be tamper-proof to prevent unauthorized modifications +* Be accessible only to authorized personnel +* Be retained for a minimum of five years +* Capture 100% of user actions related to personal data +* Be searchable and retrievable within 24 hours of a request by authorized personnel +* Undergo regular integrity checks to ensure no tampering has occurred +* Be backed up securely to prevent data loss +* Comply with all relevant privacy and data protection regulations

>This "requirement" describes a solution approach to accountability. diff --git a/requirements/A/_posts/2023-07-03-authenticity-of-digital-document..md b/requirements/A/_posts/2023-07-03-authenticity-of-digital-document..md index 474c025..5bcc196 100755 --- a/requirements/A/_posts/2023-07-03-authenticity-of-digital-document..md +++ b/requirements/A/_posts/2023-07-03-authenticity-of-digital-document..md @@ -7,19 +7,31 @@ permalink: /requirements/authenticity-of-digital-document
-**Stimulus**: A user attempts to verify the authenticity of a digital document. - -**Environment**: System operates in a context where document integrity and trustworthiness are critical. - -**Response**: The system should provide a robust digital signature mechanism that verifies the authenticity and integrity of the document, ensuring that any modifications or tampering can be detected. - Additionally, the system should maintain a secure and tamper-proof audit trail that records all document-related activities, including creation, modifications, and approvals, with timestamps and user identifiers. - -**Background:** In this scenario, the authenticity requirement is described for a system where document integrity and trustworthiness are crucial. -When a user attempts to verify the authenticity of a digital document, the system should respond by providing a robust digital signature mechanism. -This mechanism ensures that the document's authenticity and integrity can be validated, enabling the detection of any unauthorized modifications or tampering. - -Furthermore, the system should maintain a secure and tamper-proof audit trail that records all document-related activities. This includes the creation, modifications, and approvals of the document, along with timestamps and user identifiers. By capturing these details in the audit trail, the system enhances accountability and transparency, allowing users to track the document's history and ensuring that the document's authenticity can be reliably verified. - +#### Context/Background + +The system operates in an environment where document integrity and trustworthiness are critical. +It provides functionality for users to verify the authenticity of digital documents. +The system employs a robust digital signature mechanism to ensure document authenticity and integrity. +A secure and tamper-proof audit trail is maintained for all document-related activities. + +#### Source + +A user attempts to verify the authenticity of a digital document. + +#### Metric/Acceptance Criteria + +The system must provide a robust digital signature mechanism and maintain a secure audit trail. +The authenticity verification process must meet the following criteria: +* Digital signature mechanism correctly verifies the authenticity and integrity of 100% of unmodified documents +* Any modifications or tampering to a document are detected with 100% accuracy +* The audit trail records all document-related activities, including creation, modifications, and approvals +* Each audit trail entry includes accurate timestamps and user identifiers +* The audit trail is tamper-proof, with any attempts at unauthorized modification being detected and logged +* Digital signature verification process completes within 5 seconds for documents up to 10MB in size +* Audit trail entries are created and logged within 1 second of the corresponding document activity +* The system provides a clear, user-friendly interface for users to initiate and understand the results of the authenticity verification process +* The audit trail is searchable, allowing authorized users to retrieve the complete history of a document within 30 seconds +* The system maintains 99.99% uptime for the authenticity verification service

diff --git a/requirements/A/_posts/2023-07-23-access-control-is-enforced.md b/requirements/A/_posts/2023-07-23-access-control-is-enforced.md index 2608892..9bea8e0 100755 --- a/requirements/A/_posts/2023-07-23-access-control-is-enforced.md +++ b/requirements/A/_posts/2023-07-23-access-control-is-enforced.md @@ -7,38 +7,38 @@ permalink: /requirements/access-control
-### Stimulus -A user attempts to access a sensitive feature or confidential information within the system. - -### Environment -Multi-user environment with varying levels of user roles and permissions. - -### Response -The system should enforce appropriate access controls based on the user's role and permissions. -If the user's role grants access to the requested feature or information, the system should allow access without any impediments. -However, if the user's role does not have the required permissions, the system should deny access and display a relevant and user-friendly error message. -Additionally, any access control violations should be logged and reported to authorized personnel for further investigation. - - -### Background -In this scenario, the access control requirement is defined for a multi-user system with different levels of user roles and permissions. -When a user attempts to access a sensitive feature or confidential information, the system should respond by enforcing appropriate access controls. +#### Context/Background -Precise metrics to determine when the requirement is met include: +The system operates in a multi-user environment with varying levels of user roles and permissions. -**Authentication**: Users must be authenticated before accessing any sensitive data. Authentication should be based on a strong authentication method, such as multi-factor authentication (MFA) or biometric authentication. +* Sensitive features and confidential information are present within the system. +* Access control is crucial to maintain data security and privacy. +* The system employs role-based access control (RBAC) to manage user permissions. +* An audit trail is maintained for all access attempts to sensitive data. -**Authorization**: The system should grant access to sensitive customer data based on the principle of least privilege. Authorized users should have only the minimum level of access necessary to perform their tasks. +#### Source -**Role-Based Access Control** (RBAC): Access to sensitive data should be determined by user roles. Precise roles should be defined, such as "Customer Service Representative," "Financial Analyst," and "Administrator," and access permissions should be assigned accordingly. - -**Data Classification**: Sensitive customer data should be classified based on its level of sensitivity (e.g., public, internal, confidential). Access controls should be configured according to these classifications, with stricter controls for highly sensitive data. - -**Audit Trail**: The system should maintain a detailed audit trail of all access attempts to sensitive data. This includes recording the user's identity, timestamp, accessed data, and the outcome (granted or denied). Audit logs should be tamper-proof and securely stored. - -**Access Revocation**: The system should allow authorized personnel to revoke access permissions immediately when necessary, such as in cases of employee termination or data breaches. +A user attempts to access a sensitive feature or confidential information within the system. -**Session Management**: Sessions should have a timeout mechanism to automatically log users out after a period of inactivity to prevent unauthorized access in the event a user leaves their session unattended. +#### Metric/Acceptance Criteria + +The system must enforce appropriate access controls based on the user's role and permissions. + +The access control mechanism must meet the following criteria: +* 100% of access attempts must be authenticated before granting access to any sensitive data +* Multi-factor authentication (MFA) or biometric authentication is implemented for accessing highly sensitive data +* User roles are precisely defined (e.g., "Customer Service Representative," "Financial Analyst," "Administrator") +* Access permissions are assigned based on the principle of least privilege +* Sensitive data is classified into at least three levels (e.g., public, internal, confidential) +* Access controls are configured according to data classification, with stricter controls for highly sensitive data +* 100% of access attempts (successful and failed) to sensitive data are logged in a tamper-proof audit trail +* Audit logs include user identity, timestamp, accessed data, and outcome (granted or denied) +* Authorized personnel can revoke access permissions immediately, with changes taking effect within 60 seconds +* User sessions automatically timeout after a maximum of 30 minutes of inactivity +* Access denials display a relevant and user-friendly error message within 2 seconds +* 100% of access control violations are logged and reported to authorized personnel within 5 minutes +* The system maintains 99.99% uptime for the access control service +* Access control policy updates are applied system-wide within 5 minutes of being implemented

diff --git a/requirements/A/_posts/2023-09-04-affordable-crm.md b/requirements/A/_posts/2023-09-04-affordable-crm.md index f8f0a87..0438ed2 100755 --- a/requirements/A/_posts/2023-09-04-affordable-crm.md +++ b/requirements/A/_posts/2023-09-04-affordable-crm.md @@ -7,27 +7,31 @@ permalink: /requirements/affordable-crm
-### Source: -Finance department of a mid-sized company. - -### Stimulus: -The company wishes to adopt a new Customer Relationship Management (CRM) software system. - -### Environment: -The company has a limited budget set aside for the software, which includes initial purchase, setup, training, and first-year operational costs. - -### Response: -The total cost of ownership (TCO) for the first year of the CRM software should not exceed the set budget. - -### Response Measure: - -* Initial licensing cost: ≤ $10,000. -* Setup and deployment costs: ≤ $5,000. -* Training costs for 50 employees: ≤ $3,000. -* Maintenance and support for the first year: ≤ $2,000. -* Operational costs, including cloud hosting, for one year: ≤ $4,000. - -* Total First-Year TCO: ≤ $24,000. +#### Context/Background + +A mid-sized company is planning to adopt a new Customer Relationship Management (CRM) software system. +The company has allocated a limited budget for the software, covering initial purchase, setup, training, and first-year operational costs. +The total cost of ownership (TCO) for the first year is a critical factor in the decision-making process. +The company needs to ensure that the chosen CRM solution fits within their budgetary constraints while meeting their operational needs. + +#### Source + +Finance department of a mid-sized company wishes to adopt a new Customer Relationship Management (CRM) software system. + +#### Metric/Acceptance Criteria + +The total cost of ownership (TCO) for the first year of the CRM software must not exceed the set budget of $24,000. +This TCO is broken down into the following specific cost categories: +* Initial licensing cost must be less than or equal to $10,000 +* Setup and deployment costs must not exceed $5,000 +* Training costs for 50 employees must be kept at or below $3,000 +* Maintenance and support costs for the first year must be less than or equal to $2,000 +* Operational costs, including cloud hosting, for one year must not surpass $4,000 +* The sum of all these costs (Total First-Year TCO) must be less than or equal to $24,000 +* All costs must be verifiable through official quotes, invoices, or contracts +* Any potential hidden costs or fees must be identified and included in the TCO calculation +* The chosen CRM solution must meet at least 90% of the company's functional requirements within this budget +* The TCO calculation must be completed and verified at least 30 days before the final decision on CRM adoption

diff --git a/requirements/A/_posts/2023-09-04-appearance-requirements.md b/requirements/A/_posts/2023-09-04-appearance-requirements.md index d9f88b0..fce1d7c 100755 --- a/requirements/A/_posts/2023-09-04-appearance-requirements.md +++ b/requirements/A/_posts/2023-09-04-appearance-requirements.md @@ -7,25 +7,51 @@ permalink: /requirements/appearance-requirements
-### Stimulus +#### Context/Background + +The system is a mobile application with a user interface (UI) for performing common tasks such as creating an account or making a purchase. +The appearance of the UI is critical for user experience and brand consistency. +The application needs to maintain visual consistency, color scheme compliance, text legibility, proper image resolution, responsive design, and acceptable loading times across various devices and screen sizes. +The UI should adhere to accessibility standards such as WCAG 2.0. + +#### Source + A user interacts with a mobile application's user interface (UI) to perform a common task, such as creating an account or making a purchase. -### Response -The appearance requirement will be considered met when the following precise metrics are achieved: +#### Metric/Acceptance Criteria +The appearance requirement will be considered met when the following precise metrics are achieved: -**Visual Consistency**: Across the entire application, all user interface elements, including buttons, text fields, and icons, should maintain a consistent visual style. This consistency should be visually assessed, and it should be confirmed that at least 95% of UI elements adhere to the established style guide. +* Visual Consistency: + * At least 95% of UI elements must adhere to the established style guide + * This adherence should be visually assessed and documented -**Color Scheme Compliance**: The application's color scheme, as defined in the style guide, should be correctly implemented. This includes background colors, text colors, and accent colors. Compliance should be verified using automated tools, with no more than 5% deviation from the specified color codes. +* Color Scheme Compliance: + * No more than 5% deviation from the specified color codes is allowed + * Compliance should be verified using automated color analysis tools -**Text Legibility**: All text displayed in the application should be legible and meet accessibility standards. The font size, contrast ratios, and line spacing should comply with accessibility guidelines such as WCAG (Web Content Accessibility Guidelines) 2.0. Automated accessibility testing tools should confirm that 100% of text elements meet these criteria. +* Text Legibility: + * 100% of text elements must meet WCAG 2.0 accessibility guidelines + * Font size, contrast ratios, and line spacing should be compliant + * Automated accessibility testing tools should confirm this compliance -**Image Resolution**: All images and icons should be displayed in their intended resolution and aspect ratio. Automated testing should ensure that 100% of images are rendered without distortion or pixelation. +* Image Resolution: + * 100% of images and icons must be rendered without distortion or pixelation + * Automated testing should verify correct resolution and aspect ratio -**Responsive Design**: The application's appearance should adapt seamlessly to various screen sizes and orientations. Testing on multiple devices and screen sizes should confirm that the UI layout remains visually appealing and functional. No critical layout issues should be observed on at least 95% of devices tested. +* Responsive Design: + * UI layout must remain visually appealing and functional on at least 95% of tested devices + * Testing should cover multiple devices and screen sizes + * No critical layout issues should be observed in these tests -**Loading Times**: The application's UI elements, including images and graphics, should load within acceptable timeframes. Precise loading times should be defined for each UI element (e.g., main screen, product images) and should not exceed 3 seconds for any individual element. Automated performance testing should validate compliance. +* Loading Times: + * No individual UI element should exceed a 3-second loading time + * Automated performance testing should validate this requirement + * Specific loading time targets should be defined for each major UI element (e.g., main screen, product images) +* Overall Compliance: + * The application must pass all the above criteria in at least 3 consecutive testing cycles + * Any failures must be documented, addressed, and re-tested until compliance is achieved

diff --git a/requirements/A/_posts/2023-09-04-assess-impact-of-proposed-change.md b/requirements/A/_posts/2023-09-04-assess-impact-of-proposed-change.md index 26d1f9f..260d497 100755 --- a/requirements/A/_posts/2023-09-04-assess-impact-of-proposed-change.md +++ b/requirements/A/_posts/2023-09-04-assess-impact-of-proposed-change.md @@ -7,20 +7,42 @@ permalink: /requirements/assess-impact-of-proposed-change
-### Stimulus -A software development team needs to analyse / assess the impact of a proposed change to a specific module of a financial software application. +#### Context/Background + +The system is a financial software application with multiple modules. +A software development team needs to analyze and assess the impact of a proposed change to a specific module. +The system's analysability is crucial for efficient change management and maintenance. +Tools and practices are in place to support code documentation, dependency mapping, and change simulation. + +#### Source + +A software development team initiates an impact analysis for a proposed change to a specific module of the financial software application. + +#### Metric/Acceptance Criteria -### Response The system's analysability requirement will be considered met when the following precise metrics are achieved: -**Change Impact Assessment Time**: The team should be able to assess the impact of the proposed change within 2 hours of reviewing the relevant documentation and source code. +* Change Impact Assessment Time: + * The team must be able to assess the impact of the proposed change within 2 hours + * This time starts from the moment the team begins reviewing relevant documentation and source code + * The assessment should cover all potential areas affected by the change -**Code Comment Density**: The code for the affected module should have a minimum code comment density of 20%, ensuring that code documentation is sufficiently detailed. +* Code Comment Density: + * The affected module must have a minimum code comment density of 20% + * This density should be measured using automated code analysis tools + * Comments should be meaningful and provide clear explanations of code functionality -**Dependency Mapping**: The system should provide a visual dependency map of the module, indicating all dependencies on other components. The map should be generated within 5 minutes of requesting it. +* Dependency Mapping: + * The system must provide a visual dependency map of the module, that indicates all dependencies on and from other components + * Generation time for the dependency map must not exceed 5 minutes + * The map should be accurate, showing 100% of actual dependencies -**Change Simulation**: The system should offer a simulation tool that allows the team to simulate the proposed change's impact on the module's behavior. The simulation should complete within 10 minutes and provide clear results. +* Overall Compliance: + * All three criteria (assessment time, comment density, and dependency mapping) must be met for the requirement to be satisfied + * Compliance should be verified through at least 3 different change scenarios + * Any failures in meeting these criteria should be documented and addressed + * The system should maintain this level of analysability for at least 90% of all modules

diff --git a/requirements/A/_posts/2023-12-05-accurate-vehicle-position-gps.md b/requirements/A/_posts/2023-12-05-accurate-vehicle-position-gps.md index f95436f..6d54d50 100644 --- a/requirements/A/_posts/2023-12-05-accurate-vehicle-position-gps.md +++ b/requirements/A/_posts/2023-12-05-accurate-vehicle-position-gps.md @@ -17,4 +17,26 @@ permalink: /requirements/accurate-vehicle-position-gps **Background**: The GPS position retrieval rate via satellite might be insufficient low, such that in-between positions are determined using extrapolation. +#### Context/Background + +The system is a vehicle navigation system that displays the vehicle's position on a map. +GPS data might be retrieved at an insufficient rate for smooth position updates. +To compensate for this, the system uses extrapolation to determine in-between positions. +This extrapolation is crucial for providing a smooth and accurate representation of the vehicle's movement on the map. + +#### Source + +The vehicle's position on the map of the navigation system is being updated. +The current position is determined by extrapolation rather than direct GPS data. + +#### Metric/Acceptance Criteria + +The extrapolated position of the vehicle must be recalculated with a frequency greater than 10Hz. + +This requirement will be considered met when: + +* The system consistently maintains a position update rate higher than 10 times per second +* This update rate is maintained under various driving conditions (e.g., different speeds, urban vs. rural environments) +* The transition between extrapolated positions and new GPS data is smooth, with no visible jumps on the map +
diff --git a/requirements/A/_posts/2024-04-20-accessible-ui.md b/requirements/A/_posts/2024-04-20-accessible-ui.md index 9cc2e5b..d6e24bb 100755 --- a/requirements/A/_posts/2024-04-20-accessible-ui.md +++ b/requirements/A/_posts/2024-04-20-accessible-ui.md @@ -11,8 +11,27 @@ permalink: /requirements/accessible-user-interface **Metrics:** -* Accessibility Compliance: Achieve and maintain WCAG 2.1 AA compliance for all user interfaces. -* Screen Reader Compatibility: Ensure 100% compatibility with leading screen readers. + + +#### Context/Background + +Software UI must be accessible to users with various disabilities. +System aims to comply with WCAG 2.1 AA and be compatible with leading screen readers. + +#### Source + +Development team implementing and maintaining the software UI with accessibility focus. + +#### Metric/Acceptance Criteria + +* Achieve and maintain WCAG 2.1 AA compliance for all user interfaces + * 100% pass rate on automated WCAG 2.1 AA tests + +* Ensure 100% compatibility with leading screen readers (e.g., JAWS, NVDA, VoiceOver) + * All UI elements properly labeled and described + * Full keyboard navigation possible + * Dynamic content changes appropriately announced +
From 4cbfe6c3c3482bbf9e6ccdb31b6c0730a1edca01 Mon Sep 17 00:00:00 2001 From: "Dr. Gernot Starke" Date: Sat, 24 Aug 2024 21:13:29 +0100 Subject: [PATCH 4/6] two more requirements examples converted to new structure --- ...09-04-budget-constrained-library-update.md | 23 +++++++++---------- ...2000-02-03-core-functions-mac-win-linux.md | 17 ++++++++++++-- requirements/_req-template-simple.md | 0 3 files changed, 26 insertions(+), 14 deletions(-) create mode 100644 requirements/_req-template-simple.md diff --git a/requirements/B/_posts/2023-09-04-budget-constrained-library-update.md b/requirements/B/_posts/2023-09-04-budget-constrained-library-update.md index 31485b6..f82caf3 100755 --- a/requirements/B/_posts/2023-09-04-budget-constrained-library-update.md +++ b/requirements/B/_posts/2023-09-04-budget-constrained-library-update.md @@ -7,24 +7,23 @@ permalink: /requirements/budget-constraint-library-update
-### Source: -Product owner. -### Stimulus: -The system uses a specific library as a core component, which gets security updates every week. +#### Context/Background -### Environment: -Development environment, automated build and test pipeline. +* The system uses a commercial library as a core component. +* An automated build and test pipeline for the system is in place. +This is available for all developers within their development environment. -### Response: -An update of this library must be possible with a maximum time budget of 2 developer-hours on average. - +#### Source -### Response Measure: +* This commercial library gets regular security updates every month. +* In some cases (e.g. _zero day exploits_) additional updates are delivered from the vendor. +The product owner requires that these updates are incorporated with only limited manual effort. -* Manual effort required for such updates must not exceed 2hrs for a single developer on average. -* cost of automation (build and test) is not considered, as these are already available. +#### Metric/Acceptance Criteria +* An update of this library must be possible with a maximum time budget of less than 2 developer-hours on average. +* The cost of automation (build and test) is not considered, as these are already available.

diff --git a/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md b/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md index 0a038a2..c8ecf6f 100755 --- a/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md +++ b/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md @@ -7,11 +7,24 @@ permalink: /requirements/core-functions-on-mac-win-linux
-**Background**: The system offers a few complex core business functions. +#### Context/Background + +* The system offers a few complicated core business functions. +* The system is available on different operating systems, especially MacOS, Windows and a few major Linux distributions. + +#### Source + +* A new release of one of the supported operating (OS) systems becomes available. + +#### Metric/Acceptance Criteria + +* The new release of the OS does not affect the ability to work on this platform, + at least in comparable execution environments (concerning cpu and memory capacity). + * Core functions can be re-used on MacOS, Windows and Linux applications without changes to their source code. -* Future releases or distributions of these operating systems shall not affect their ability to work on these platforms, at least in comparable execution environments (concerning cpu and memory capacity). +

diff --git a/requirements/_req-template-simple.md b/requirements/_req-template-simple.md new file mode 100644 index 0000000..e69de29 From c9dad46f9f7cff7317ea71583de0c81bf0f9322b Mon Sep 17 00:00:00 2001 From: "Dr. Gernot Starke" Date: Sat, 31 Aug 2024 08:09:29 +0200 Subject: [PATCH 5/6] compatible battery models --- ...-06-compatible-with-5-battery-providers.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md b/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md index 1626760..e0942a6 100755 --- a/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md +++ b/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md @@ -7,12 +7,21 @@ permalink: /requirements/compatible-with-5-battery-providers
-**Background**: The systems' energy is supplied by a rechargeable onboard battery, that is provided by one of several different external suppliers (_vendors_). -As examples of such systems, think of a mobile phone, a standalone GPS navigation device or a portable music player. -The system shall be compatible with battery models provided by the five preferred battery suppliers. +### Context/Background -The concrete list of suppliers will be available about 6 months prior to product release. -Battery specifications from several vendors are available upon request. +* The system's energy is supplied by a rechargeable onboard battery provided by an external supplier that is mechanically attached to a circuit board. +* The current version of that board fits only batteries of ONE specific supplier. + +### Source + +Product management has decided to reduce dependency of this specific supplier and to modify the circuit board. + +### Metric/Acceptance Criteria + +* The circuit board (thus the system) shall be compatible with battery models from the five preferred battery suppliers. +* The system shall successfully operate with battery models from all these five suppliers without requiring any hardware modifications. +* The system shall pass functional tests with each battery model under standard operating conditions. +* The system's performance, especially battery life, shall vary by less than 10% across the different battery models.

From 74dce77f072024146269ff6de57befbf02a2e0c4 Mon Sep 17 00:00:00 2001 From: "Dr. Gernot Starke" Date: Tue, 3 Sep 2024 20:27:14 +0200 Subject: [PATCH 6/6] more consistency, again --- .../2000-02-03-core-functions-mac-win-linux.md | 6 +++--- ...00-02-06-compatible-with-5-battery-providers.md | 2 +- .../2000-09-06-consistent-keyboard-shortcuts.md | 14 ++++++++++---- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md b/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md index c8ecf6f..25fe624 100755 --- a/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md +++ b/requirements/C/_posts/2000-02-03-core-functions-mac-win-linux.md @@ -11,7 +11,7 @@ permalink: /requirements/core-functions-on-mac-win-linux #### Context/Background * The system offers a few complicated core business functions. -* The system is available on different operating systems, especially MacOS, Windows and a few major Linux distributions. +* The system is available on different operating systems, especially macOS, Windows and a few major Linux distributions. #### Source @@ -19,10 +19,10 @@ permalink: /requirements/core-functions-on-mac-win-linux #### Metric/Acceptance Criteria -* The new release of the OS does not affect the ability to work on this platform, +* The new release of the OS does not affect the ability to work on this platform, at least in comparable execution environments (concerning cpu and memory capacity). -* Core functions can be re-used on MacOS, Windows and Linux applications without changes to their source code. +* Core functions can be re-used on macOS, Windows and Linux applications without changes to their source code.
diff --git a/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md b/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md index e0942a6..2a84126 100755 --- a/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md +++ b/requirements/C/_posts/2000-02-06-compatible-with-5-battery-providers.md @@ -1,5 +1,5 @@ --- -title: Compatible with 5 major battery providers +title: Compatible with 5 different battery providers tags: flexible related: flexibility, adaptability, interoperability, compatibility permalink: /requirements/compatible-with-5-battery-providers diff --git a/requirements/C/_posts/2000-09-06-consistent-keyboard-shortcuts.md b/requirements/C/_posts/2000-09-06-consistent-keyboard-shortcuts.md index 5550063..2733390 100755 --- a/requirements/C/_posts/2000-09-06-consistent-keyboard-shortcuts.md +++ b/requirements/C/_posts/2000-09-06-consistent-keyboard-shortcuts.md @@ -8,13 +8,19 @@ permalink: /requirements/consistent-keyboard-shortcuts
-**Stimulus**: User expects/requires to use a keyboard (instead of a mouse) to navigate within the user interface, in all parts of the user interface. +### Context/Background -**Reaction**: User can use the system with keyboard-only, without resorting to a mouse or trackpad. +* The user can use keyboard shortcuts to select and execute functions within the graphical user interface. +* The system must support keyboard-only navigation across all parts of the interface. -**Metric**: Keyboard shortcuts are consistent. Functions that are identical or similar in different parts of the system (like "save", "copy", "paste") have identical shortcuts throughout the system. +### Source +Somebody navigates the graphical interface with only a keyboard, without using a mouse or trackpad. -**Background**: User can use keyboard shortcuts to select and execute functions within the (graphical) user interface. +### Metric/Acceptance Criteria + +* The user shall be able to perform all actions with the keyboard alone. +* Keyboard shortcuts must be consistent throughout the system: +Identical or similar functions, such as "save", "copy", and "paste", shall have identical shortcuts across the entire system.