Comprehensive approach to requirements traceability #1564
Comments
|
@ThibFrgsGmz trying to deepen the conversation here. How do you envision such a solution be offered at the F´ level? In my experience, this kind of process is managed at the project/institution level. That's usually (again, in my experience) managed with external tools and services, and I'm tempted to say that F´ should be agnostic to the choices made by each project/institution. Or am I missing your point? |
|
I completely understand your opinion. Let's put ourselves in the shoes of a user who has to develop a product for a customer. This customer has software requirements, right? If the user chooses FPrime to develop their product, how do they ensure that the components of the deployment topologies meet the upstream requirements? This is a question I still don't have an answer to. One could say that it's not the framework's responsibility, as it would add too much functionality to maintain and coexist with other processes. However, a framework, in my opinion, is a structure that is offered to a user to allow them to construct many products with the expectation of producing future products faster and cheaper than if they had developed without it. In this sense, the framework should have characteristics that reassure the user about its ability to provide an industrializable solution, such as
As food for thought, I'm just reading the book "Semantic Software Design" by Eben Hewitt where the following quote from Tech Blogger Jonathan Clarks is included: If I were to quickly think of an implementation, it would be with regexes, something like the following script: #!/bin/sh
# Requirements trace check - corresponding numbers should be the same
pattern="(GEN|FPRIME)-[A-Z]+-[0-9]+"
echo -n "SRS: "
grep -o -E $pattern SRS.md | sort | uniq | wc -l
echo -n "SDD: "
grep -o -E $pattern SDD.md | sort | uniq | wc -l
echo -n "SRS with TEST: "
grep -E $pattern SRS.md | grep TEST| wc -l
echo -n "ATP: "
grep -o -E $pattern ATP.md | sort | uniq | wc -l
echo -n "ALL: "
grep -o -E $pattern *.md | grep -o -E $pattern | sort | uniq | wc -l Without this traceability, how do you ensure that the topology you have designed meets the customer's requirements? |
|
Key approaches to requirements traceability in spacecraft software, drawing from industry practices and standards.
/**
* @requirements ACS-SW-123, ACS-SW-124
* @brief Implements attitude control law
*/
void AttitudeController::updateControlLaw() {
// Implementation
}
class TestAttitudeControl(unittest.TestCase):
"""
@requirements ACS-SW-123
@verifies Attitude control accuracy during nominal operations
"""
def test_pointing_accuracy(self):
# Test implementation
|
Feature Description
It would be interesting if F' offered a comprehensive approach to requirements traceability.
I'm referring to a requirements management tool that allows developers to work on individual activities while linking code and verification artifacts to lower or higher level requirements.
Functional safety and cybersecurity standards require the collection, referencing, and tracking of requirements.
In the face of changing customer requirements, test failures and engineering oversights, updating these artifacts can become a logistical nightmare. Project management automation can make this process more efficient and less time consuming.
The end result would be a
comprehensive two-way processthat ensures that any changes to requirements, design, or source code are easily understood, verified, and tracked throughout the life cycle.We would have system
requirements assigned to software engineering,high-level requirementsandlow-level requirements.I would not be able to propose a technical solution. Should requirements, for example, be listed in tables in markdown files, as components are?
Rationale
Many functional safety and cybersecurity standards mention requirements traceability.
On the one hand, it is essential to demonstrate that all requirements are met as implemented and tested in the code.
And on the other hand, it is important to demonstrate that there is code that does not meet any requirements.
This code may be the result of feature creep, code written to make a component reusable across multiple projects, dead code, or malicious code implemented and added by unscrupulous individuals. In all cases, it is essential to provide a justification for the presence or absence of such code.
The text was updated successfully, but these errors were encountered: