Process Change for SSS & SSDD Requirement Numbering

1. Process Change for SSS & SSDD Requirement Numbering Problem - Duplicate requirement identifying numbers Pat Roof RDA 540-644-2247 proof@teamscci.com

2. Duplicate Requirement Identifier Issues • Currently there is no single attribute in the SSS and SSDD DOORS modules that will quickly identify or reference a specific requirement • Requirement identifier is NOT unique. • Duplicate requirement identifier does not support NSWCDD’s test traceability to unique requirement identifiers • Risk of overlooking a requirement that may need testing for current increment because a requirement with the exact requirement identifying number has already been was tested • Tool features are compromised as well • Updates to the modules can only be made manually. The import feature to update the modules cannot be used because the tool’s Import feature requires at least one attribute be used that can uniquely identify the records to be updated. • Link By Attribute feature requires manipulation such as script modifications or customized filtering applied before this feature can be utilized. • The current process assumes that an identifier can both 1) identify the requirement in the database and 2) provide functional history. The identifying number cannot do both. By adding a Functional ID this will provide the functional SSID or SDID history of a new requirement.

3. History of Current Process • Reuse of requirement identifier numbers (duplicates) began with the implementation of V6 and has propagated to V5.4 requirement development • Effectivity View (Single Module) • Attributes were created to show requirement’s version or increment applicability • Approved change to an existing requirement for the next increment or version yielded: • A new row under the requirement being modified inserted into DOORS. • The modified requirement entered into the row and share the same SSID or SDID number of the requirement that it is taking the place of for the next version/increment. • The version/increment set to the applicable value. • The SSS requirement linked to the child requirement that has the applicable version/increment and vice versa. • If the object text has been changed for the next version, the SRMB will determine whether or not to assign a new SSID. • If the object text has been changed for the next version, the ERB will determine whether or not to assign a new SDID.

4. Example of Current Process For Increment 2 development – a Sub is added to platform applicability Another record added Requirement identifier stays the same For Increment 3 development - DDG is added to platform applicability Another record added Requirement identifier stays the same

5. Example of Current Process 3 Requirements (records in the SSDD module) with the same identifying number

6. Proposed Requirement Identifier Change • Requirement identifiers for both SSS and SSDD to be a unique number for each record/requirement in the DOORS Database • Create in the SSS a FunctionalSSID attribute which will contain the SSID number to indicate from which existing requirement the new incremental requirement/record was derived • Create in the SSDD a FunctionalSDID attribute which will contain the SDID number to indicate from which existing requirement the new incremental requirement/record was derived • Create consistent SDID requirement identifiers numbers to those SSDD requirements which were directly derived from the SSS and the SSDD requirement text does not deviate from the original SSS requirement text (i.e add a decimal character and two zeros (.00) to the end of those SDID numbers. See slide #13)

7. Proposed Change Add Functional ID Attribute SDID sequentially numbered - unique for each requirement/record

8. Proposed Change Current Process • Create Functional ID Attribute in both SSS and SSDD • Copy numbers from SSID and SDID attribute into Functional ID attribute • Sequentially number SSID and SDID numbers Proposed Process

9. Snapshot of Current SSS Duplicate SSID #s

10. Example of SSSUnique SSID #s with Functional SSID Attribute(SSID #s are augmented sequentially)

11. Snapshot of Current SSDD Duplicate SDID #s

12. Example of SSDDUnique SDID #s with Functional SDID Attribute(SDID #s are augmented sequentially after decimal)

13. Example of SSDDUnique SDID #s for those SSDD requirements unchanged from it’s parent SSS requirement (# 4 on slide 6)

14. Impact • Number of duplicate identifiers • SSS currently has 11 requirements with duplicate SSID numbers • SSDD currently has 229 requirements with duplicate SDID numbers • SSDD currently has 1298 requirements that retain the SSS identifier (not consistent with SDID numbering scheme as these numbers do not have decimal character and two zeros (.00)) • System Architect (SA) Amy Sicalides should speak to this, her slides follow.

15. Unique SSS/SSDD Approach – System Architect (SA) Impacts • Unique SSS Approach: No Impact as SSS requirements are never imported into the SA Minispec Definition type. • SSDD Current Approach: SDID Numbers must be unique in DOORS, because SA cannot handle duplicate SSDD Requirement Numbers (Example: two instances of 444.01 in the DOORS SSDD Module). Continuing to propagate this problem will result of data corruption in SA for the Minispec Definition. • Unique SSDD Approach: When new SSDDs are created in the DOORS SSDD Module and imported into the Minispec Definition type in SA, these new SSDDs need to be assigned to a “home” in the architecture • Each Minispec needs to be assigned to a CSCI in one or more L1 Sequence Diagrams • Minispec assignment to diagrams does not happen automatically • The RE for a given change package needs to assess their SSDDs for a given candidate and identify the “homes” for assignment in SA. • Based on the Unique SSDD approach, two usrprops.txt changes are required for the Minispec Definition in order to provide additional information to the RE in the SA Tool: • Add a Functional SDID Attribute (text field) • Add an Increment(s) Attribute (text field)

16. SDID Name Description Platform SSID Functional SDID(*) Increment(s) (*) SDID Name must be unique DOORS SSDD Module SA Minispec Definition SDID Name Reqt Location SA-DOORS Input/Output Attributes (*) Requires a usrprops.txt change since attributes are currently not defined for the SA Minispec Definition

17. Recommendations • Change all SSS and SSDD duplicate requirement identifiers to unique requirement identifiers • In SSS module • Create a Functional SSID attribute • Copy id numbers from the SSID attribute into Functional SSID attribute • Increment SSID numbers so each requirement/record will have a unique number • In SSDD module • Create a Functional SDID attribute • Copy id numbers from the SDID attribute into Functional SDID attribute • Increment SDID numbers so each requirement/record will have a unique number • Consistent SDID identifiers • Add a decimal and two zeros (.00) to those SSDD requirements unchanged from the SSS • Create a Process CR to modify JI-078 to reflect that each SSDD requirement must have a unique requirement identifying number