Feat Req inspection - Baselibs#2812
Conversation
|
|
|
The created documentation from the pull request is available at: docu-html |
| - Issue link | ||
| * - REQ_01_01 | ||
| - Is the requirement formulation template used? | ||
| - see :need:`gd_temp__req_formulation`, this includes the use of "shall". |
There was a problem hiding this comment.
Passed: YES
All requirements follow the template.
| - | ||
| * - REQ_02_01 | ||
| - Is the requirement description *comprehensible* ? | ||
| - If you think the requirement is hard to understand, comment here. |
There was a problem hiding this comment.
Passed: YES
All requirements are fairly easy to understand.
| - | ||
| * - REQ_02_02 | ||
| - Is the requirement description *unambiguous* ? | ||
| - Especially search for "weak words" like "about", "etc.", "relevant" and others (see the internet documentation on this). This check shall be supported by tooling. |
There was a problem hiding this comment.
Passed: NO (4/14 failed)
- feat_req__baselibs__core_utilities: It's open to interpretation what "core software utilities and common infrastructure components" means. Listing them explicitly or linking this requirement to an existing list would be better. Also "multiple" seems vague, and also implies that the number of modules using base libs is relevant here. maybe just drop it.
- feat_req__baselibs__safety: The phrase "selected functionalities" makes is vague. It could be interpreted as such that only a "selected" subset of functionalities that need to be ASIL-B are actually ASIL-B, or maybe "selected functionalities" are on the user side? I assume that this requirement is to be understood as: "Each base library component shall be qualified at the same safety integrity level as required by its consuming platform components, up to ASIL-B.". If that is true - then it needs to be rephrased in that way.
- feat_req__baselibs__consistent_apis: It's unclear what is meant by ""consistent""? Consistent naming, error handling...? Consistency over time? My interpretation is that is should use uniform API design patterns across all components, but it's not entirely clear.
- feat_req__baselibs__containers_library: "container types not present in the C++ standard library" depends on which C++ standard is used.
| - | ||
| * - REQ_02_03 | ||
| - Is the requirement description *atomic* ? | ||
| - A good way to think about this is to consider if the requirement may be tested by one (positive) test case or needs more of these. The requirement formulation template should also avoid being non-atomic already. Note that there are cases where also non-atomic requirements are the better ones, for example if those are better understandable. |
There was a problem hiding this comment.
Passed: YES
Note: several requirements list the capabilities of the components, which makes those requirements not strictly atomic. However, this might be preferred on the feature level.
| - | ||
| * - REQ_02_04 | ||
| - Is the requirement description *feasible* ? | ||
| - If at the time of the inspection the requirement has already some implementation, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_impl` shows this. In case the requirement has no implementation at the time of inspection (i.e. not implemented at least as "proof-of-concept"), a development expert should be invited to the Pull-Request review to explicitly check this item. |
There was a problem hiding this comment.
Passed: YES
All requirements already implemented at the time of this inspection.
| - | ||
| * - REQ_06_01 | ||
| - Does the requirement consider *external interfaces*? | ||
| - The SW platform's external interfaces (to the user) are defined in the Feature Architecture, so the Feature and Component Requirements should determine the input data use and setting of output data for these interfaces. Are all output values defined? |
There was a problem hiding this comment.
Passed: YES
The output interfaces of base libraries are coupled with individual components, and are arguably to be defined within component requirements.
| - | ||
| * - REQ_07_01 | ||
| - Is the *safety* attribute set correctly? | ||
| - Derived requirements are checked automatically, see :need:`gd_req__req_linkage_safety`. But for the top level requirements (and also all AoU) this needs to be checked manually for correctness. |
There was a problem hiding this comment.
Passed: YES
Note: the justification via traceability is missing - see comment for REQ_03_01.
| - | ||
| * - REQ_07_02 | ||
| - Is the *security* attribute set correctly? | ||
| - For feature requirements this checklist item is supported by automated check: "Every requirement which satisfies a stakeholder requirement with security attribute set to YES inherits this". But the feature requirements/architecture may additionally also be subject to a :need:`wp__feature_security_analysis` |
There was a problem hiding this comment.
Passed: NO (12/14 failed)
all the feature requirements here inherit from stkh_req__functional_req__base_libraries stakeholder requirement, which has a security set to YES. This means all the requirements here should also set this attribute to YES. Following requirements have it falsely set to NO:
- feat_req__baselibs__core_utilities
- feat_req__baselibs__safety
- feat_req__baselibs__multi_language_apis
- feat_req__baselibs__consistent_apis
- feat_req__baselibs__maintainable_design
- feat_req__baselibs__json_library
- feat_req__baselibs__flatbuffers_library
- feat_req__baselibs__result_library
- feat_req__baselibs__containers_library
- feat_req__baselibs__bitmanipulation
- feat_req__baselibs__filesystem_library
- feat_req__baselibs__concurrency_library
| - | ||
| * - REQ_08_02 | ||
| - Is the requirement verifiable by design or code review in case it is not feasibly testable? | ||
| - In very rare cases a requirement may not be verifiable by test cases, for example a specific non-functional requirement. In this case a requirement analysis verifies the requirement by design/code review. If such a requirement is in scope of this inspection, please check this here and link to the respective review record. A test expert is invited to the inspection to confirm their opinion that the requirement is not testable. |
There was a problem hiding this comment.
Inspection pending on REQ_08_01 findings from Test Manager
| - | ||
| * - REQ_09_01 | ||
| - Do the feature requirements defining a safety mechanism contain the error reaction leading to a safe state? | ||
| - Alternatively to the safe state there could also be "repair" mechanisms. Also do not forget to consider REQ_05_01 for these. |
There was a problem hiding this comment.
Passed: YES
Note: None of the requirements here is defining a safety mechanism, yet several components contain operation that could fail and need a safety mechanism. However, defining safety mechanisms is arguably better suited for individual libraries' component requirements.
2 participants
Refers: #2479