Managing Secure Data in Separate Networks
Managing "secure requirements" on a separate network requires two separate environments.
Feature needed to "merge" "Unsecure Data" with "Secure Data" in a one-way data copy to the "Secure Network". On the "Unsecure Network", the existence of "Secure Placeholders" coul "link" with the actual requirements on the "Secure Network". All "Unsecure Data" would be maintained on the "Unsecure Network"; and "Secure Data" would be maintained on the "Secure Network". The frequency for the data copy would be dependent on baseline process on the "Unsecure Network". Could be performed with an Export/Import feature, or a Baseline Merge feature. |
3 answers
With RRC V3 the simplest approach (and maybe the only approach?) would be to export requirements in a CSV file from the unsecure repository and import them into the secure repository. There are limitations with this approach, namely: plain text only, does not maintain trace relationships, text size potentially limited by any intermediate tool you use if you massage the CSV file (using Excel, for example).
We'd like to offer a more robust import/export facility ... something like ReqIF (which is OMG's evolution of the RIF specification), but we aren't there yet. Any other ideas, anyone? |
I would be curious how "secure" this information needs to be? We have considered this situation and expect to be able to simply restrict access at the user level to a separate RRC project. Thus, only the people authorized to work with this information will have access to either update or view/approve.
This assumes there is no independent access at the database level and that the Administrator has sufficient authority to have access as well. We use the Link To/From link type between projects, although I believe any of the System-defined links can be used between projects. And, "embeds" can be used across projects as well. The other consideration is whether or not uniqueness is important. My understanding is that RRC is limited to providing uniqueness only within a specific instance of the JTS. Thus, multiple instance are likely to generate duplicate ID values. (DM - please correct me if this is no longer the case) |
|
How "secure" is defined as a corporate requirement to isolate requirements in two separate physical networks. Users are isolated/allocated to each network. When data is combined only the "secure" isolated users are allowed data access to the "merged" repository. Software/encrypted role definition tables is not a valid solution.
I would be curious how "secure" this information needs to be? We have considered this situation and expect to be able to simply restrict access at the user level to a separate RRC project. Thus, only the people authorized to work with this information will have access to either update or view/approve. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.