Enhancement Request - Copy Requirements Data

 

How we handle enhancement request for allowing copy of requirements. Purpose of this video is to show what works for OpenRose Team when it comes to handling Enhancement Requests.

Direct Link to YouTube Video : 

https://www.youtube.com/watch?v=eXM-EaQc_So

Video Transcript :

Hi, Welcome to OpenRose, a Free and Open-Source requirements management application. 

Find more information at 

https://github.com/OpenRose

Today, we are going to talk about a new enhancement request that I would like to start working on. Our team has received a request to make it possible to allow data to be copied within the application. Let me first go over the request.

If you go to the OpenRose project on GitHub and look at the project, we are now talking about this enhancement. It’s a one-liner request that we are now assessing: “Copy requirements including child requirements.” That’s the main objective. We need to write the server-side code that supports allowing the copy of the existing requirement structure, and we should support the ability to copy outside of the currently selected requirement structure.

What this means is that if you already have a structure, then you should not allow the copy to place new requirements within the child requirement structure. Instead, it should copy outside the selected structure.

Anyway, we'll discuss this in more detail, but based on this enhancement request, we thought we should be a little bit more precise about what it is that we want to do with this request, how we will implement it, what the different impacts are, and how we actually document what we’re going to do.

To do that, we converted the overall objective of the requirement into a concept we call “Concept of Copy Requirements,” and this is published on our wiki. Right now, we don't have a public-facing deployment of OpenRose for our customers to look at our internal requirements, so we decided to just publish this as a concept in a wiki page. Ultimately, it's still using the markdown format, so we could easily convert this into requirements within our OpenRose repository.

Copying Requirements at the Project Level

The feature here is to copy the requirements which are at the project level, i.e., the entire project or a specific Item Type or a specific set of Requirements, including its Child Requirements. So here we're going to talk about the Project and Item Type.

Copying a Project

When you do a copy, the copied project should be placed in the same repository because the repository contains the project. The naming convention of the copied project will be adding a suffix at the end, which is nothing but `_Copy` and a random number. This number will be automatically generated. So, the project name remains the same, but there will be an additional suffix in the project name itself. The Item Type's name and the Requirements' name inside the project will just remain the same.

Copying the Item Type within the Project is equal to adding this suffix with the random number to the Item Type itself, which is nothing but a copy that we produce, and then all the requirements beneath that Item Type will just be the same structure with the same name that we have now.

Because we are talking about copying the requirements, we have to also discuss the impact on some other associated data.

Traceability

In our concept, when we discussed this in our team, all the links, whether they are parent or child traces, should be kept. Whether they are links or traces against the requirement within the same project or across other projects in the same repository, all those traceability links should be maintained. That is the outcome of our discussion within the team.

Change Log

We decided that we should not keep any of the change log history. We don't want any of the information about how these requirements evolved over time in the copy that we create. A copy is a kind of fresh start, so we will not make any changes to the change log data. Any existing requirement attribute that we have, like status, priority, severity, description, all those values will be maintained and kept as they are. We are not going to reset any of those values in the copy. We will literally make a copy as if we are doing a copy-paste in a Word document.

Baseline Data

We know that a project has baselines, and those baselines could be scoped at the project level or at the item type level. We are not going to copy any of the existing baseline data. The idea is that the baselines that were taken in the source project are for a specific reason and purpose. The copy that we are creating may not have the same purpose. The copied project or new project that we are creating, or the new item type that we are creating, may have a different purpose altogether. That's why we're not going to actually copy the baseline data. If a baseline needs to be captured, then new baselines will be created in the newly copied project or Item Type.

Here's a simple example: Let's say I have a project A, which has a parking lot Item Type along with software as an Item Type, and then we have requirements and sub-requirements below those Item Types. Everything here remains as it is. We are not changing the naming convention or the data for Item Type, requirements, and sub-requirements. The only thing we will change is the Project name that will go from “Project A” to “Project A_Copy” with the random numbers that we generate. The actual data just remains as it is. That's how we will do a Project copy. If you do the Item Type copy, then the only change will be the Item Type name. All other data for the requirements and sub-requirements within the Item Type will remain as it is.

As discussed, we will not have any baseline, we will not have any change log, but the traceability or the links that we have within the project or across the project will be maintained and carried forward in the copy.

We have a small note here. This was something we discussed in our team, where we know that every Project has a Parking Lot Item Type, and we can only have one system Parking Lot Item Type. We proposed to allow the Parking Lot Item Type to be copied. This might be the scenario where a customer needs to have a lot of data in the Parking Lot, which they have kept aside for some specific purpose, and now they want to take a copy of that Parking Lot and work with that data. We will allow a copy to be created, but when you create the copy, the new Item Type name, which will have the Parking Lot with a suffix of _copy and a random number, that particular new name has to be changed by the user. They cannot rename it back to “Parking Lot” because you can only have one Item Type called “Parking Lot” and of type system.

This means we will just leave with a new Item Type that the user can call something other than “Parking Lot,” and it will not be a system Item Type. It will be considered as a custom or user-defined Item Type like how you would create other Item Types like business requirements, stakeholder requirements, user requirements, software requirements, hardware requirements, non-functional requirements, etc. The Parking Lot can be copied, but you will have to call it something other than “Parking Lot” and it will not be classified as a system item type because you can only have one such Item Type.

Copying Requirements

Now, let's talk about copying Requirements. We’re not talking about copying the Project or Item Type, but rather copying the Requirements.

Here, if you have a Requirement with some Child Requirements or Sub-Requirements, the same logic applies. The main Requirement that you are copying will have a suffix added to the name of the Requirement, and it will be called `_copy` with a random number. However, the sub-requirement naming convention will not change. All the data for the sub-requirements will remain as it is.

Again, for traceability, we will keep all the traces, whether they are within the Project, within the set of Requirements you're copying, outside the set of Requirements, or across multiple Projects. All those traces will be kept in our implementation of copy Requirements.

The change log will not be kept because the purpose of the copy and creation of the copy is to start fresh with the set of Requirements. We don't believe that having those change logs would be important.

Here’s an example: If you have a requirement named “Login Functionality” with two sub-requirements—“Username” and “Password” field requirements—when you do the copy, the only thing that will change is that we will be adding `_copy` with a random number as a suffix to the requirement name.

Benefits of Allowing the Copy of Requirements

Now, what are the benefits of allowing the copy of the requirements?

Consistency

One key benefit is consistency. The copied Project, Item Type, and Requirements retain the same structure and naming conventions as the original, making it easier to navigate and understand. This is important for traceability, as we’re going to keep all the traceability links across all three types of copies. That is also a significant benefit.

Efficiency

Efficiency is another big benefit. Users will save significant time and effort by being able to easily copy large amounts of Requirements data. Allowing copy is going to make our users more efficient. They can create different templates or sets of requirements in the Parking Lot and then copy them over. We also know that not only can we copy, but after copying, we also have the existing feature that allows moving. So, users can move the copied data across the same project or other projects. This efficiency improvement is something we would like to see in our product.

Template Projects

We have customers or users who want to repeat certain activities again and again. They could be an event management company, wedding planner, or working with sets of requirements they deliver repeatedly. Whether they’re delivering consultancy services, releasing a Hollywood film, or producing a Hollywood film, all these users would require the ability to create templates and then repeat what they have done in the past, improving upon it.

That’s why the copy feature will enable templating Projects, templating Item Types, or templating Requirement structures and then creating a copy to implement the same again. Please remember that OpenRose is not only for corporates and teams. Individual users, consultants, and contributors can also install OpenRose on their standalone computers. This copy feature will help them template their work and then repeat that template in the future, delivering similar or better products and services to their customers.

Design Decisions About the Copy ID

We initially thought of a method whereby the first copy would have the number "1," the second copy would have the number "2," and so on. The approach was great, but we realized that we would have to keep checking the database for all the siblings or the area where we are copying the target data to verify that there is no existing copy with "Copy 1," "Copy 2," or "Copy 3" as a name. If an existing entry was found, we would update or increment the number by one.

While it’s not a problem to write that logic, we felt it could demand more resources to query the database. With a large implementation of OpenRose, it could take more time to go through the existing set of data to verify the copies. Instead, we thought it better to use a random number because it will solve the same purpose. We expect our customers to rename the copied data at some point, whether it has a number "1, 2, 3" or a random number generated. The idea is to support our customers in simply copying and renaming the copied data as needed.

We are trying to reduce the number of transactions and SQL queries sent to the database. We aim to reduce the logic to implement and the error handling around it, giving users feedback in some form. Instead, we chose to reduce these activities and go with the random number approach. The team decided on this, and that's how we agreed upon this particular requirement.

Documenting the Requirement

As you can see, a simple requirement that started with a one-liner—“Copy”—led us to sit down and create this detailed document. This document will feed not only the team implementing it but also future developers looking at the code to enhance it or fix bugs. They will know the original thoughts, what was discussed within the team in the past, and how they decided on the solution to implement.

To help customers understand how this copy feature would work, I created a small diagram using Paint-brush. The structure within OpenRose is that we have a repository that can contain one or many Projects. Each Project can contain one or many Item Types. Each Item Type can contain one or many requirements. Each requirement can contain one or many sub-requirements, creating a hierarchical structure of requirements within Item Types.

When we want to do a copy, we select a Project. For an entire Project copy, the new Project will be created in the same Repository. It cannot be created outside of the Repository. The new Project will contain all the data copied over as a new Project in the same Repository. For an Item Type copy, it will sit under the same Project because an Item Type must be associated with a Project, not a Repository. If you want the copied Item Type in another Project, you can move it using the move Item Type capability.

For copying requirements and sub-requirements, the main Requirement being copied will have a suffix added, like `_copy` with a random number. The sub-requirements' naming conventions will remain the same. The copied data will be linked to the parent requirement.

With that, we have pretty much covered how we want to implement this feature. Let’s start implementing and working on it! We have the enhancement request, a detailed concept in a wiki, and a diagram. The video I’m creating right now will also be useful for the team working on this in the future or new contributors to the project. The idea is to show an example of how we are enhancing the product and how we expect users to look at requirements—not just as a three-liner user story or a simple set of text requirements, but detailed enough to help both the current team and future enhancements or bug fixes.

Thank you for your time today. Please share this video with others who can benefit from our work. We are also happy to receive contributions in forms other than source code, such as documentation, presentations, podcasts, and discussions to make it possible for others to use our product in the future, helping them do it right and reduce waste.

Thank you, and have a great day!