What is Requirement?

What is Requirement?

OpenRose - Requirements Management

An Open Source and FREE Requirements Management Application / Tool

Direct Link to YouTube Video : https://www.youtube.com/watch?v=3qQzKbfvRPA

Video Transcript :

 
Hi, welcome to OpenRose, an open-source and free requirements management application. Please visit https://github.com/openrose for more information.

Let's go to the project dashboard, and this time, let's open a deep hierarchical level project. This is just a demo project, so when I open that project in the TreeView and start expanding the project, I can see some sample item types along with a Parking Lot, which is the system item type. Inside item type one, I have a top-level item, then item one and item two, which are broken down into further items. You can see I've given the names which indicate a kind of logical hierarchical structure in the name.

Here, you can see L1, L2, L3, L4—that's the level. The project is considered as level one, and item types are at level two. We then have a few items sitting at level three, and when we expand the level three item, we can see levels four, five, and six items. The "C3" here indicates there are three children below L1, and these three children are the three item types for the given project. The "C3" for item type one indicates there are three items as child items sitting below this item type. Let me expand that, and we can see three immediately available children below item type one.

Let's expand this, and we can see there are two children, which are items 1.1 and 1.2, sitting below item one at level three. These two items are at level four. Expanding this further, we can see three more children, and then three more children, and five more children, and so on. The deepest hierarchical item is at level nine in this sample project.

Now, these items are nothing but requirements. OpenRose allows capturing information about individual requirements in the context of an item. An item is generally defined by its name, status, priority, severity, and description. When you write the description in markdown format, the preview can be seen below the actual description, or you can click on this button to view the information in preview mode. The information captured in the description is important as it describes the requirement, that particular atomic single requirement. The child requirements are the breakdown structure used for defining the requirement in a more granular fashion within the same item type.

It's also possible to link a top-level item or some item from certain types of data within OpenRose to other items. Here, I have a link as a child link going from the top requirement to the bottom requirement, and I can click on it to open that item at the bottom. The idea here is to have an items breakdown structure, which is the requirements breakdown structure, as well as traceability to define certain relations between items stored at different levels within the project or across many projects.

Now, why am I stressing so much about an item, which is a requirement, being an atomic individual object-based requirement model? Every project, every team, every initiative, every individual who captures requirements may want to use these requirements in different contextual purposes within that project or initiative. I wanted to show you another project to describe more about why an item or requirement is classified as an object-based requirement within OpenRose.

Let's jump back to the project list. I have a new project here called "What is Requirements." To capture this information in this video, I thought it would be nice to go into this new project and capture some of my thoughts. Here, I decided to put the Parking Lot at the bottom. I can simply use the up and down button to change the location of data within the given hierarchical level and move them up and down within that level easily using the Details View.

What I did was ask questions to an AI or copilot engine. I asked several questions about what the requirements are for different industries: shipping, defense, ship-breaking, entertainment, wedding planner firms, hospitals, election bodies, and electric car manufacturers. The answers I got were that for the shipping industry, requirements could be broadly classified as safety standards, environmental regulations, labor standards, and training and certifications. For the defense industry, security clearance, technical specification, compliance with regulations, quality assurance, and innovation and research are top contenders for item types. For the ship-breaking industry, environmental regulations, worker safety, waste management, economic considerations, and compliance with national laws are very important requirements.

In the entertainment industry, Regulatory Compliance, health and safety standards, licensing and permissions, talent contracts, technical specifications, content rating, and classification are crucial requirements. For electric car manufacturers, requirements include Regulatory Compliance, technology and innovation, supply chain management, manufacturing facilities, charging infrastructure, workforce training and certifications, testing, marketing and sales, HR, finance and investments, and sustainability practices.

When capturing such requirements, they may be described in many different forms. We are not bound to describe a requirement as just a textual requirement. We may create models, architectural diagrams, or capture information from third-party conferences. There could be many ways to describe requirements. It's essential to capture these details within the requirement definition itself.

When I asked these questions to the AI engine, I captured their responses in markdown format and started capturing information about where more details can be found. The reference that the AI model gave me is here, but it could be that you, as an individual or a team, capture information about the requirement and describe it in more detail. You may store that information in third-party applications like SharePoint, PowerPoint, Excel, Power BI, YouTube videos, photo galleries, or even a video captured on your holiday. It could be an interior image captured from a finished hotel lobby, a car you saw on the road, or a picture of that car. There could be many ways to capture the details of a specification for a requirement, and linking this information to the metadata in the requirements management solution is vital.

Modeling the requirement could be in many forms, while you can easily describe your requirement in this description box and have a hierarchical structure defined for your requirements to break them down into smaller individual pieces.

With that, I would like to conclude this video explaining how requirements are captured within OpenRose, how they are structured, and how they can be linked to different parts of your project or across many projects. Thank you so much for listening today and understanding a little more about OpenRose, a free requirements management application for users to download and use. Please help us spread the word about OpenRose by telling your colleagues and friends. Hopefully, they will also benefit from using OpenRose for their upcoming projects and initiatives.

Thank you so much, and have a great day. Bye-bye.