Hi Marina,

I think definitely that DOORS is capable of doing this.

I know automotive OEM that did all this in DOORS. They used the powerful integrated scripting language DXL to automate things. The customizable data model allows you to store anything.

But DOORS is not a test management software, so it lacks build in functionality to execute tests. 

It sounds like you are just starting, so I would suggest also to take the IBM ELM Platform into account which includes DOORS Next as Requirements Tool and also a testmanagement tool and workflow management tool.

To your other questions:

To allow impact analysis it is always good to have the top level requirements in the system. Also for later project phases. I also would suggest to always update the requirements on later changes. Esp if you might have follow up projects.

regards

Nikolai

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Hi Marina,

for the OSLC you can go here: https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors-next/7.1?topic=services-doors-next-as-oslc-service-provider or https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors/9.7.2?topic=function-extending-doors-by-using-oslc-services

BR,

Gianluca

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Thanks Gianluca. We will learn, in the meantime I would like to provide some evidence that we will be not #1 (beta-testers), that such solution is already running.

Hi Marina,

for the OSLC you can go here: https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors-next/7.1?topic=services-doors-next-as-oslc-service-provider or https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors/9.7.2?topic=function-extending-doors-by-using-oslc-services

BR,

Gianluca

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Hi Marina,

there are several customer around the world using DOORS/DOORS Next, OSLC and other component of the Engineering Lifecycle Management platform connected together. This solution was released in 2009 with the first version of Engineering Workflow management tool (previously known as RTC, Rational Team Concert) and then other component. So, you're not the beta tester for sure.

BR,

Gianluca

Thanks Gianluca. We will learn, in the meantime I would like to provide some evidence that we will be not #1 (beta-testers), that such solution is already running.

Hi Marina,

for the OSLC you can go here: https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors-next/7.1?topic=services-doors-next-as-oslc-service-provider or https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors/9.7.2?topic=function-extending-doors-by-using-oslc-services

BR,

Gianluca

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

------------------------------
Marina Magalnik
Information Manager
NTA Israel
marinam@nta.co.il
+972 - 52 - 8395505
------------------------------


Original Message:
Sent: Fri March 14, 2025 06:13 AM
From: Malte Plath
Subject: DOORS requirements lifecycle

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

------------------------------
Malte Plath

Hi Marina

IBM ELM definitely includes all the tools you require to manage a project through the entire lifecycle including planning, task creation, linking tasks to changes / requirements / tests, managing requirements, producing test plans, managing change etc etc. The ONLY thing I would say is that this entire integrated approach can be quite difficult to create if you have not used ELM before.

The DNG component on it's own will allow you to manage change and and has some built in planning ability but has no specific test features. Additionally, the change management works across an entire project rather than individual or groups of modules if you aren't using the ELM Global Config Management application (can be more trouble than it's worth TBH for smaller projects). For testing, you can define your own modules / fields etc to capture tests and V&V evidence but this would be a more manual process of either creating new modules for each test or adding fields for each test (the same as you would have done in Classic DOORS).

Linkage in DNG is pretty good too as you can specify the type of links between modules so you can have a DERIVED link, a DECOMPOSED link, a TESTED BY link etc - each identifying their own specific purpose and you can view this traceability in a nice diagram with suspect link identification etc. I think you will find you can do most of what you want with just DNG and consider extending functionality with JavaScript / plugins if absolutely necessary. You can purchase plugins to support additional features from companies such as 321 Gang and Softacus if you need to extend the functionality too if you don't feel up to writing your own - as I say, you probably don't need this - I only used these features for things such as Risk management tables to make my life a little easier.

Contrary to some of the comments on here regarding Classic DOORS, there is the facility for change management and API access. You need a change management server configured for change control and you must be using the latest version of DOORS with the Web Access component for API access. If you have a good system for Baseline management and / or duplication of modules for branches, you can quite easily identify changes between versions. With Classic DOORS I was a fan of creating lots of Baselines upon each change following PDR / CDR and then baselining when I had my V&V methods in place and then upon each test cycle. DOORS Classic does have a rudimentary way of creating new fields / columns for each test and will even pop up a window as you progress through tests showing you what needs doing and entering your result.

Let me know if you need any more help or advice, I've only been using DNG / ELM for a year or so but it's been quite an intensive learning process :)

------------------------------
Mark Bebbington
------------------------------


Original Message:
Sent: Mon March 17, 2025 03:06 AM
From: Marina Magalnik
Subject: DOORS requirements lifecycle

Hi Malte,

we use the DNG last version. In this case, is it ok to manage requirements during all project stages? 

------------------------------
Marina Magalnik
Information Manager
NTA Israel
marinam@nta.co.il
+972 - 52 - 8395505


Original Message:
Sent: Fri March 14, 2025 06:13 AM
From: Malte Plath
Subject: DOORS requirements lifecycle

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

------------------------------
Malte Plath

Hi Marina,

two cautions when it comes to DOORS Classic:

• DOORS Classic is not capable of configuration management.  So, if you want to update requirements after they have been handed to design, implementation and test, you will have to have a well thought-out process to keep a clear separation between what was agreed - and consequently implemented, and what is the current working version.
• DOORS Classic is "old technology".  There are no APIs to speak of.  If you want to integrate it into a "tool landscape", or even just gather metrics, you will have to write your own adapters to enable even a basic interoperation.  Any of the more modern competitors offer more interoperability "out of the box".

Best Regards,

Malte Plath

Senior Requirements Engineer

Valyue Consulting GmbH

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park
------------------------------

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park
------------------------------

Hi Marina, the IIBA (International Institute of Business Analysis) states that requirements have a lifecycle and should be maintained and reused until they are retired. This is how we use the DNG product at the State of Minnesota.

Robyn Riley, CSM®

Advanced Business Analyst, CLM SME | Program Management Division

Pronouns: She/her/hers

Name pronunciation: rah-bin rye-lee

 

Minnesota IT Services | Partnering with DHS and Mnsure

444 Lafayette Rd.

St. Paul, MN 55101

O: 651-461-4631

Information Technology for Minnesota Government | mn.gov/mnit

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature">

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature" style="color: #0078D4; text-decoration: none">Book time to meet with me

Caution: This e-mail and attached documents, if any, may contain information that is protected by state or federal law. E-mail containing private or protected information should not be sent over a public (nonsecure) Internet unless it is encrypted pursuant to DHS standards. This e-mail should be forwarded only on a strictly need-to-know basis. If you are not the intended recipient, please: (1) notify the sender immediately, (2) do not forward the message, (3) do not print the message and (4) erase the message from your system.

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park
------------------------------

Hi Robyn,

Thank you very much for the information! I have a few follow-up questions:

1. When do you decide on the retirement of a requirement?

2. How long do you use DOORS in your process?

3. Do all applications / processes align with the requirements?

4. Is there an O&M phase where real-time/ periodical data provides evidence/verification for requirements in DOORS?

Looking forward to your insights!

Hi Marina, the IIBA (International Institute of Business Analysis) states that requirements have a lifecycle and should be maintained and reused until they are retired. This is how we use the DNG product at the State of Minnesota.

Robyn Riley, CSM®

Advanced Business Analyst, CLM SME | Program Management Division

Pronouns: She/her/hers

Name pronunciation: rah-bin rye-lee

 

Minnesota IT Services | Partnering with DHS and Mnsure

444 Lafayette Rd.

St. Paul, MN 55101

O: 651-461-4631

Information Technology for Minnesota Government | mn.gov/mnit

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature">

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature" style="color: #0078D4; text-decoration: none">Book time to meet with me

Caution: This e-mail and attached documents, if any, may contain information that is protected by state or federal law. E-mail containing private or protected information should not be sent over a public (nonsecure) Internet unless it is encrypted pursuant to DHS standards. This e-mail should be forwarded only on a strictly need-to-know basis. If you are not the intended recipient, please: (1) notify the sender immediately, (2) do not forward the message, (3) do not print the message and (4) erase the message from your system.

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park

Hi Marina,

1. A requirement is retired when it is no longer valid or used in the system. It might be a business rule that is no longer valid or a functional requirement that is obsolete.
2. We use DNG to keep track of the current state of a system, and update requirements whenever an enhancement is made to the system.
3. The requirements in DNG describe the "as is" state of the system as of today.
4. We use the entire CLM suite for our system development lifecycle which means our requirements in DNG are linked to test cases in ETM and work items in EWM. We can look at a solution requirement (functional or non-functional) and see it's complete history including any work items that are linked to it and the test cases and results of those tests. Within DNG if we have a traditional project, then we start with business requirements and decompose them into solution requirements. If we have a scrum or agile product, we link requirements, processes, rules, etc. to the stories in EWM.

Hope this helps.

Hi Robyn,

Thank you very much for the information! I have a few follow-up questions:

1. When do you decide on the retirement of a requirement?

2. How long do you use DOORS in your process?

3. Do all applications / processes align with the requirements?

4. Is there an O&M phase where real-time/ periodical data provides evidence/verification for requirements in DOORS?

Looking forward to your insights!

Hi Marina, the IIBA (International Institute of Business Analysis) states that requirements have a lifecycle and should be maintained and reused until they are retired. This is how we use the DNG product at the State of Minnesota.

Robyn Riley, CSM®

Advanced Business Analyst, CLM SME | Program Management Division

Pronouns: She/her/hers

Name pronunciation: rah-bin rye-lee

 

Minnesota IT Services | Partnering with DHS and Mnsure

444 Lafayette Rd.

St. Paul, MN 55101

O: 651-461-4631

Information Technology for Minnesota Government | mn.gov/mnit

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature">

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature" style="color: #0078D4; text-decoration: none">Book time to meet with me

Caution: This e-mail and attached documents, if any, may contain information that is protected by state or federal law. E-mail containing private or protected information should not be sent over a public (nonsecure) Internet unless it is encrypted pursuant to DHS standards. This e-mail should be forwarded only on a strictly need-to-know basis. If you are not the intended recipient, please: (1) notify the sender immediately, (2) do not forward the message, (3) do not print the message and (4) erase the message from your system.

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park

Hi Robyn,

Thank you again - your answer really helped me understand your approach.

If a requirement has been verified during the testing phase - do you consider it "fulfilled" and close it, or do you continue tracking it throughout the operational phase (e.g., using real-time or performance data) to ensure it remains valid and satisfied over time?

In other words, do you treat some requirements as continuously active rather than "closed," especially in long-term projects?

Hi Marina,

1. A requirement is retired when it is no longer valid or used in the system. It might be a business rule that is no longer valid or a functional requirement that is obsolete.
2. We use DNG to keep track of the current state of a system, and update requirements whenever an enhancement is made to the system.
3. The requirements in DNG describe the "as is" state of the system as of today.
4. We use the entire CLM suite for our system development lifecycle which means our requirements in DNG are linked to test cases in ETM and work items in EWM. We can look at a solution requirement (functional or non-functional) and see it's complete history including any work items that are linked to it and the test cases and results of those tests. Within DNG if we have a traditional project, then we start with business requirements and decompose them into solution requirements. If we have a scrum or agile product, we link requirements, processes, rules, etc. to the stories in EWM.

Hope this helps.

Hi Robyn,

Thank you very much for the information! I have a few follow-up questions:

1. When do you decide on the retirement of a requirement?

2. How long do you use DOORS in your process?

3. Do all applications / processes align with the requirements?

4. Is there an O&M phase where real-time/ periodical data provides evidence/verification for requirements in DOORS?

Looking forward to your insights!

Hi Marina, the IIBA (International Institute of Business Analysis) states that requirements have a lifecycle and should be maintained and reused until they are retired. This is how we use the DNG product at the State of Minnesota.

Robyn Riley, CSM®

Advanced Business Analyst, CLM SME | Program Management Division

Pronouns: She/her/hers

Name pronunciation: rah-bin rye-lee

 

Minnesota IT Services | Partnering with DHS and Mnsure

444 Lafayette Rd.

St. Paul, MN 55101

O: 651-461-4631

Information Technology for Minnesota Government | mn.gov/mnit

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature">

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature" style="color: #0078D4; text-decoration: none">Book time to meet with me

Caution: This e-mail and attached documents, if any, may contain information that is protected by state or federal law. E-mail containing private or protected information should not be sent over a public (nonsecure) Internet unless it is encrypted pursuant to DHS standards. This e-mail should be forwarded only on a strictly need-to-know basis. If you are not the intended recipient, please: (1) notify the sender immediately, (2) do not forward the message, (3) do not print the message and (4) erase the message from your system.

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park

Hi Marina, great questions! Our requirements have statuses, from draft, to approved, and then implemented. Once a requirement or set of requirements go into production, we mark the status as "implemented". If a new work effort affects that requirement then the status is changed to reflect this (to draft) and then the requirements lifecycle begins again until that requirement (we reuse existing requirements) is implemented. So in a sense the requirement is "active" until it is retired. Hope this helps. We had our IBM representative present at one of our DNG user group meetings and he put together a wonderful slide deck that goes through this lifecycle of a requirement very well.

Robyn

Hi Robyn,

Thank you again - your answer really helped me understand your approach.

If a requirement has been verified during the testing phase - do you consider it "fulfilled" and close it, or do you continue tracking it throughout the operational phase (e.g., using real-time or performance data) to ensure it remains valid and satisfied over time?

In other words, do you treat some requirements as continuously active rather than "closed," especially in long-term projects?

Hi Marina,

1. A requirement is retired when it is no longer valid or used in the system. It might be a business rule that is no longer valid or a functional requirement that is obsolete.
2. We use DNG to keep track of the current state of a system, and update requirements whenever an enhancement is made to the system.
3. The requirements in DNG describe the "as is" state of the system as of today.
4. We use the entire CLM suite for our system development lifecycle which means our requirements in DNG are linked to test cases in ETM and work items in EWM. We can look at a solution requirement (functional or non-functional) and see it's complete history including any work items that are linked to it and the test cases and results of those tests. Within DNG if we have a traditional project, then we start with business requirements and decompose them into solution requirements. If we have a scrum or agile product, we link requirements, processes, rules, etc. to the stories in EWM.

Hope this helps.

Hi Robyn,

Thank you very much for the information! I have a few follow-up questions:

1. When do you decide on the retirement of a requirement?

2. How long do you use DOORS in your process?

3. Do all applications / processes align with the requirements?

4. Is there an O&M phase where real-time/ periodical data provides evidence/verification for requirements in DOORS?

Looking forward to your insights!

Hi Marina, the IIBA (International Institute of Business Analysis) states that requirements have a lifecycle and should be maintained and reused until they are retired. This is how we use the DNG product at the State of Minnesota.

Robyn Riley, CSM®

Advanced Business Analyst, CLM SME | Program Management Division

Pronouns: She/her/hers

Name pronunciation: rah-bin rye-lee

 

Minnesota IT Services | Partnering with DHS and Mnsure

444 Lafayette Rd.

St. Paul, MN 55101

O: 651-461-4631

Information Technology for Minnesota Government | mn.gov/mnit

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature">

c4df03b16a834c8ebb2aa83ff418951d@state.mn.us?anonymous&ep=signature" style="color: #0078D4; text-decoration: none">Book time to meet with me

Caution: This e-mail and attached documents, if any, may contain information that is protected by state or federal law. E-mail containing private or protected information should not be sent over a public (nonsecure) Internet unless it is encrypted pursuant to DHS standards. This e-mail should be forwarded only on a strictly need-to-know basis. If you are not the intended recipient, please: (1) notify the sender immediately, (2) do not forward the message, (3) do not print the message and (4) erase the message from your system.

Hi Marina. Perhaps the following will help you justify your intuition (which I think is correct!)

No system is built once and never changes.

When the system is modified due to a change request, existing requirements remain valid (except the ones being changed or ones that become obsolete due to the changes).

How will you determine which requirements are new, which must be changed, and which become obsolete if you do not maintain your requirements through the operational lifecycle?

Without good requirements, how will you estimate the cost of the change request to determine whether it's "worth it" without the change request becoming a major effort itself? There are some great stories out there about programs that got cost and schedule under control once they had good requirements and a change order evaluation process: the number of change orders dropped a lot, and program cost and schedule stopped growing out of control -- because it became efficient in time and money to create good cost estimates for changes. All too often change requests don't have good cost estimates associated with them, because (ironically) it's too costly to generate them. Your milage may vary, and I'm not an expert in your domain.

And do you have requirements related to end of operational life (decommissioning)? It's likely that regulations will change between now and then, so keeping a current, valid set of decommissioning requirements will help all parties.

------------------------------
Daniel Moul
Principal Product Manager
IBM
Research Triangle Park