ReqCycle/toolRequirements

Definition

ReqCycle allows defining a custom data model to define requirement types and their scopes (engineering levels, projects).

Data model management

Here are below main requirements concerning creation and deletion of data models.

Behavior of Data Model creation or modification:

The creation of Data Models is available in ReqCycle Preference.The Data Model is created with version V1 (display: “DataModelName”).

All changes in the Data Models incremented the version.

If they are modification, the version is incremented when the user clicks on “Apply” button (display: “DataModelName (V2)”).

The new versions can contain one or several modifications. It is the application of these modifications that creates/changes the version of the data model. Each modification of “Data Types”, “Attributes”, “Naming Preferences” or “Scopes” to result in a change version.

If no changes, no version will be created.

Behavior of Data Model suppression:

User can delete a Data model in ReqCycle Preference. Here the process of suppression:

Case 1: Last version of Data Model used

If there are requirements (used) on the last version to stop immediately user if there are sources.

If data model is used on last version, this error message is displayed:

"There are requirement sources associated with that version of data model. You cannot delete this data model version".

=> “Delete action” is stop.

Case 2: Previous version of Data Model used

Step 1: If there are requirements (used) on other versions to stop immediately user if there are sources.

If data model is used on one of the previous versions.

=> message displayed « You can only remove last version - there are requirements associated with previous versions ».

Step 2: This message displayed: “Are you sure you want to delete this version of data model” (Yes/No).

It will delete associated requirement types and scopes on last version.

Case 3: Data Model not used

Step 1: If the Data Model is not used

No message is displayed, “Delete action” continues.

Step 2: This message is displayed: “Do you want to delete all versions of this Data Model or only the last?”

- “All versions of Data Model”, all version of Data Model are deleted (“Data Types”, “Attributes”, “Naming Preferences” and “Scopes” are deleted).

- “Last version of Data Model”, the last version of Data Model is deleted (“Data Types”, “Attributes”, “Naming Preferences” and “Scopes” return at the last version).

- “Cancel”, no version deleted, the action is stop.

Collaborative work

List of tool requirements to support end user UC listed on [1]

There are two main solution classes to support collaboration:

• either through local work and synchronization with a shared repository (shared directory on network drive, VCS repository like Git, SVN or ClearCase...)
• else through a direct access to the shared repository

Following tool requirements concern first solution class: local work (workspace) and exchanges with a shared repository

---

R-Collaborative-0010: share requirement set

Statement: ReqCycle shall provide a command available from a given selected Eclipse project, that exports a set of selected requirement sources and associated requirement data models to a given URL (ReqCycle parameter/preference - see R-Collaborative-0020 - ) referencing the shared repository of requirements. If shared repository is empty (first publication), then it is filled with requirement sources and requirement data models selected. Else, there is comparison on requirement source names and associated requirement data models (with their version). Two cases:

• First case: local requirement sources selected and the ones in the shared repository have same names and same associated requirement data models (with same version). In that case, comparison and merge is done on requirements themselves inside requirement sources on the basis of requirement ID and "lastModificationDate" attributes with following strategy:

 * if  "local" requirement has an ID not found on destination (new requirement) it is added to the destination repository. 
 * else, If requirement ID exists both locally and on shared repository, there is comparison of "creationDate" attribute to ensure that is is really same requirement (created or imported by one person only). 
 In case creation date is different, there is a conflict considered as an error (see errors paragraph below). Command is stopped with error message. Else (same creationDate), 
 if "lastModificationDate" value is more recent than the one on shared repository then requirement is updated on shared repository  (all attribute values are updated on destination with values coming from source).
 * special case for deleted requirements: if some requirements have been deleted locally, they are not deleted on the shared repository (we always keep requirements to be able to track associated traceability).

• second case: some local requirement sources selected have a name that can not be found on shared repository or there is difference in associated requirement data models or in versions of those data models.

This difference makes the comparison useless and commande is stopped with error that highlights differences between local repository (workspace) and shared repository and tells user to realign by either removing local sources or those of shared repository.

Post-condition of success: once command is ended, shared repository is updated with changes on requirements done locally.

Errors:

• if there is no URL defined in team configuration parameters, retrieval is impossible. An error dialog is displayed for end user with explanation "your team configuration is not defined. Please fill shared repository URL in ReqCycle preferences>team configuration".
• if there is a requirement in both local and shared repository that has same ID and different creation date, command is stopped with following message: "a requirement exists with same ID <requirement ID> but different creation date. Command is cancelled. Please fix this conflict and launch command again".

Source: end user collaborative UC "share requirements set"

Rationale: useful to initialize shared repository (first time) and to synchronize it with any change in requirements coming from one or several team members.

Scenario 1: one user has initialized a set of requirements (either created locally or imported from a given external source). He/she wants to share this set of requirements with the team through a shared repository that can be a shared directory on a network drive or a Version control repository like Git, SVN or ClearCase. Scenario 2: one user updated requirement maturity for two requirements and another one has updated text on three requirements. They both share their local set of requirements to the shared repository. note: if both have changed same requirement, only last change (date time) will be taken into account (other change will be overridden)..

R-Collaborative-0020: define parameters to access to requirement set shared repository.

Statement: ReqCycle shall provide a way to store in a persistent way (configuration) URL to the shared repository from which requirement set will be retrieved. ReqCycle shall add means to review this team configuration parameter (URL).

Post-conditions: once such a team configuration hase been defined, it becomes possible to retrieve a set of requirements using this team configuration.

Source: end user collaborative UC "get Requirement set from shared repository"

Rationale: there can be several requirement baselines and/or several configurations. It is important to be able to precise where tool shall look at.

Example: configuration with one data model in version 2, three requirements types with custom attributes and 2 requirement sources (functional and safety).

R-Collaborative-0030: get requirement set from shared repository.

Statement: ReqCycle shall provide a command available for a given Eclipse project, that retrieves reqCycle data model configuration and one or several requirements sources from a given URL (ReqCycle parameter/preference - see R-Collaborative-0020 - ) referencing the shared repository of requirements. If local ReqCycle configuration is empty or does not contain all requirement data models and requirement sources coming from shared repository, command asks end user whether he/she is OK to complete their ReqCycle configuration and their requirement sources.

• In case end user accepts, command completes current ReqCycle configuration with requirement data models and requirement sources coming from shared repository and not found locally: in workspace for data models and in project for requirement sources.
• Else, command is canceled.

Then command processes requirements sources that already existed locally (in selected project). There is a comparison done on ID and then on the "lastModificationDate" attribute. There are several cases:

 * if requirement ID coming from shared repository does not exist on local repository, requirement is added to the local repository.
 * else (case when requirement ID already exists) comparison of creation date. If requirement creation date is different then this is an conflict considered as an error. Command is stopped with error message (see below). 
 If requirement creation date is same and requirement coming from source (shared repository) is more recent (lastModificationDate) than local one, then local requirement is updated (all attribute values replaced by those coming from shared repository).
 Note: If some requirements have been deleted in shared repository, they are not deleted locally (we always keep requirements to be able to track associated traceability).

Post-condition of success: once command is ended, requirement source(s) is(are) created or updated in end user current Eclipse project and contain at least requirements that exist on shared repository (there can exist other requirements locally).

Errors:

• if there is no URL defined in team configuration parameters, retrieval is impossible. An error dialog is displayed for end user with explanation "your team configuration is not defined. Please fill shared repository URL in ReqCycle preferences>team configuration".
• if there is a requirement in both local and shared repository that has same ID and different creation date, command is stopped with following message: "a requirement exists with same ID <requirement ID> but different creation date. Command is cancelled. Please fix this conflict and launch command again".

Source: end user collaborative UC "get Requirement set from shared repository"

Rationale: for a new team member, a consistent set of requirements (baseline) shall be available in a centralized repository available for all team members and it shall be simple to retrieve it. When several team member have retrieved their requirements and that there were changes on the baseline, it is important to give ability for all team members to align their local version with the one coming from shared repository.

R-Collaborative-0040: serialize concurrent access

Statement:ReqCycle shall ensure that accesses to the shared repository are performed in an exclusive way (only one call handled at a given time) in order to ensure data integrity amongst read commands (get requirements) and write commands (share requirements set). So ReqCycle shall provide a mechanism to serialize all concurrent accesses to the shared repository.

Note: applies to R-Collaborative-001, R-Collaborative-0030, R-Collaborative-0110 and R-Collaborative-0120.

Source: new requirement to ensure data integrity.

R-Collaborative-0050: auto increment contribution

Statement: ReqCycle shall provide a command that retrieves last requirement index so that "auto increment" can be used locally with guarantee that index is not used by another team member

Source: new requirement to ensure unique requirement ID amongst team members.

R-Collaborative-0110: share traceability links

Statement: ReqCycle shall provide a command available from a given selected Eclipse project, that exports all traceability links created with ReqCycle tool (not those captured from existing models or code) and associated ReqCycle link types configuration to a given URL (ReqCycle parameter/preference - see R-Collaborative-0020 - ) referencing the shared repository of traceability links. First, shared repository is filled or updated with traceability configuration: all traceability link type definitions used by traceability links (for instance "refine", "satisfy", "implement", "verify"... two cases with very simple strategy:

• either link type definition does not exist on repository (new) and it is added
• else it already (same name) and it is not updated.

Then, once link type definition is aligned, there is comparison and merge on links themselves, based on the link type, link source object(s), link destination object(s) and link lastModificationDate.

 * if local link does not exist on shared repository (same link type and same link sources and same link destinations),  it means that this is a new link. It is added to the shared repository.
 * Else (local link already exists on repository), there is comparison of "creationDate" attribute to ensure that is is really same link (created or imported by one person only). 
 In case creation date is different, there is a conflict considered as an error (see errors paragraph below) and command is stopped with error message.
 Else (creationDate is same), there is comparison on lastModificationDate link attribute: if it is more recent locally, then link on shared repository is updated (all attribute values are updated on destination with values coming from source).
 * special case for deleted links: if some links have been deleted locally, they are not deleted on the shared repository (we always keep links to be able to track associated traceability) but are marked with special status "deleted"

Post-condition of success: once command is ended, shared repository is updated with changes on traceability done locally.

Errors:

• if there is no URL defined in team configuration parameters, retrieval is impossible. An error dialog is displayed for end user with explanation "your team configuration is not defined. Please fill shared repository URL in ReqCycle preferences>team configuration".
• if there is a link that exists in both local and shared repository (same sources and same destinations) with different creation date, command is stopped with following message: "a link exists with same sources <link sources> and same destinations <link destinations> but different creation date. Command is cancelled. Please fix this conflict and launch command again".

Source: end user collaborative UC "share requirements traceability"

Rationale: useful to initialize shared repository (first time) and to synchronize it with any change in traceability created in ReqCycle by one or several team members.

Scenario 1: one user has initialized a set of links. He/she wants to share those links with the team through a shared repository that can be a shared directory on a network drive or a Version control repository like Git, SVN or ClearCase. Scenario 2: one user updated links (creation of two links and update of one) and another one has updated two links and created 4 links. They both share their local traceability (only links created with ReqCycle, not those captured by ReqCycle) to the shared repository. note: if both have changed same link (with same creation date), only last change (date time) will be taken into account (other change will be overridden).

R-Collaborative-0120: get traceability links from shared repository.

Statement: ReqCycle shall provide a command available from a given selected Eclipse project, that retrieves reqCycle shared traceability links from a given URL (ReqCycle parameter/preference - see R-Collaborative-0020 - ) referencing the shared repository of traceability links created through ReqCycle. If local ReqCycle traceability configuration is empty or does not contain all link types defined in shared repository, command asks end user whether he/she is OK to complete their ReqCycle traceability configuration and associated link type definitions. In case end user accepts, command completes current ReqCycle configuration with link type definitions coming from shared repository and not found locally. Else, command is canceled. Then command processes links. There is a comparison done on link data (type+sources + destinations) and then on the "lastModificationDate" attribute. There are several cases:

* if link coming from shared repository does not exist on local repository (selected Eclipse project) with same link type and same sources and same destinations, then link is added to the local repository.
* else (case when same link already exists) comparison is one on creation date. If link creation date is different between repositories, there is a conflict, considered as an error. Command is stopped with error message (see below). 
If link creation date is same and link coming from source (shared repository) is more recent (lastModificationDate) than local one, then local link is updated (all attribute values replaced by those coming from shared repository) in selected Eclipse project.
Note: If some links have been deleted in shared repository, they are not deleted locally (we always keep links to be able to track history and because we do not know yet how to detect that they have been deleted).

Post-condition of success: once command is ended, link type definition(s) is(are) created or updated in end user current workspace and Eclipse project contains links that exist on shared repository (there can exist other links locally).

Errors: if there is no URL defined in team configuration parameters, retrieval is impossible. An error dialog is displayed for end user with explanation "your team configuration is not defined. Please fill shared repository URL in ReqCycle preferences>team configuration". if there is a requirement in both local and shared repository that has same ID and different creation date, command is stopped with following message: "a requirement exists with same ID <requirement ID> but different creation date. Command is cancelled. Please fix this conflict and launch command again".

Source: end user collaborative UC "get Requirement set from shared repository" Rationale: for a new team member, a consistent set of requirements (baseline) shall be available in a centralized repository available for all team members and it shall be simple to retrieve it. When several team member have retrieved their requirements and that there were changes on the baseline, it is important to give ability for all team members to align their local version with the one coming from shared repository.