-
Notifications
You must be signed in to change notification settings - Fork 22
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
base: main
Are you sure you want to change the base?
Conversation
|
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. |
LinkedSpecificationItem
is covered when covered by at least oneSpecificationItem
of the same type.