Skip to content

Added support for requirement refinement #445

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

poldi2015
Copy link
Contributor

@poldi2015 poldi2015 commented Mar 8, 2025

LinkedSpecificationItem is covered when covered by at least one SpecificationItem of the same type.

@poldi2015 poldi2015 self-assigned this Mar 8, 2025
@github-project-automation github-project-automation bot moved this to 📫 Backlog in OpenFastTrace Mar 8, 2025
@poldi2015 poldi2015 changed the title Added support for requirement refinement into the Linker and LinkedSp… Added support for requirement refinement (resolves #445) Mar 8, 2025
@poldi2015 poldi2015 changed the title Added support for requirement refinement (resolves #445) Added support for requirement refinement (resolves #444) Mar 8, 2025
@poldi2015 poldi2015 linked an issue Mar 8, 2025 that may be closed by this pull request
@poldi2015 poldi2015 changed the title Added support for requirement refinement (resolves #444) Added support for requirement refinement Mar 8, 2025
Copy link

sonarqubecloud bot commented Mar 8, 2025

Quality Gate Failed Quality Gate failed

Failed conditions
56.2% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

@poldi2015 poldi2015 moved this from 📫 Backlog to 🎁 Ready for Review in OpenFastTrace Mar 8, 2025
@redcatbear
Copy link
Collaborator

To be frank, I don't think this is a good idea. If a requirement has a certain mandatory coverage artifact type, I find it misleading to allow covering it by a different type. Also, refinement can simply be done by covering the parent with multiple requirements on the current level.

Let us discuss the rationale behind this. As it stands, I reject the PR.

@poldi2015
Copy link
Contributor Author

To be frank, I don't think this is a good idea. If a requirement has a certain mandatory coverage artifact type, I find it misleading to allow covering it by a different type. Also, refinement can simply be done by covering the parent with multiple requirements on the current level.

Let us discuss the rationale behind this. As it stands, I reject the PR.

Yes let's discuss. Most likely it needs a bit more background. This is in fact one of the topics that I want to discuss with you.

What do you mean with "refinement can simply be done by covering the parent with multiple requirements on the current level.".

What I actually need is more or less: If have a requirement of type "req" withneeds is req or (design and test). We currently use that a lot in our architecture (at least > 500 requirements) as we have two levels of architects: system and team architects. In some cases the team architects decide to refine the system level requirements, in most cases not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🎁 Ready for Review
Development

Successfully merging this pull request may close these issues.

Requirement refinement
2 participants