According to BABOK v3, the following table represents the application of the Six Core Concepts to the Requirements Life Cycle Management Knowledge Area.

 

First, we need to clear up the scope of Requirements Life Cycle Management (RLCM). Whenever something is called “Life Cycle,” the implication is that we’re talking about more prolonged than the project. The same is true for SDLC (Software Development Life Cycle), STLC (Software Testing Life Cycle) as well as RLCM. None of these are talking about Project Cycle. So for RLCM, we are talking about processes that will span a period from cradle (the beginnings of the idea for the project) to grave (when the solution, not the project, is retired). 

Many forget that changes to a solution continue throughout its life. So the requirements will continue to be generated, just not as rapidly as when it’s being developed. RLCM will be a necessary function, though some modification to its processes is likely, as long as the solution is active.

Change

In the context of of the RLCM knowledge area, the Core Concept of Change refers to how requests are evaluated and managed as the system transitions from development to maintenance, evergreening or end of life. Each of those phases in the application life cycle will likely represent changes in the review process. A simplistic example is that it would probably be tough to justify changes for a third party application that is nearing the end of manufacturer support. The rules that decide how change requests are managed and evaluated must change to reflect each stage. Those changes are what is revealed here.

Need

All changes to the product must be made to meet a need. Once the need is identified, the changes must be traced back to it. Needs which change late in a solution’s life illustrate why RLCM is so important.

Whether you are utilizing a Waterfall or some Agile framework, the requirements were documented during the development of the solution. These requirements can be researched to provide valuable information concerning the resulting product which can help define what is needed.

Solution

Any changes to designs or solutions must be designed to meet the need. As the need changes, so does the solution, even if the need is long past the initial project. In the case of RLCM, there are many times that the practice of maintaining requirements ceases when the initial deployment is completed.

In my opinion, that is a very shortsighted practice. Instead, retain the initial project requirements in a searchable repository, and augment that information as changes to the functionality are applied.

Another practice is to simply view the source-code as the searchable repository for what the system does. The thinking is, nothing happens unless it is in the code, and the system was approved when it went into production. Therefore, the source-code should be a viable tool for determining the current state.

This also is shortsighted. It presumes that the person who needs to understand the current functionality has the same level of technical knowledge as the original developer. Items stored in a RCLM will be communicated in a way that is understood by both the Stakeholders as well as the developers.

Stakeholder

Always engage the stakeholders to identify and clarify the need, discuss the solution and verify acceptance of the results. The RCLM must reflect their understanding of what needs to change, as well as why and how.

Going beyond deployment, this may mean reviewing functional specifications to determine the previous intent. Additionally, any post deployment changes will need review as well. The goal is to have as clear of an understanding of the current system as possible, and allow for additional requirement changes to be captured and understood.

Value

Usually, when one thinks of adding Value, they are thinking of the Solution. In the context of RLCM, Value is looked at in terms, not of the solution, but the requirements which led to the solution. Perhaps it’s stating the obvious, but requirements can affect value. BABOK v3 mentions one way – through re-use beyond the current initiative. It seems that IIBA is seeking to address value in terms of the Life Cycle, which implies a longer view of the requirement than the initial implementation.  Frankly, I find that to be not a good example. 

I would suggest that the quality of the requirement significantly affects value in that it impacts the development, testing, and end solution. Though admittedly, the impact on Value using the requirement’s quality – that view is a short term view. Yet it is one where value is 100% of the time affected.

Context

The Core Concept of Context must be understood to provide traceability and prioritization functions for the RLCM. Without Context, it would be challenging to correctly determine what is most important and move that higher in the list.

BABOK v3, ch5

• BA Certification
• BACCM
• Business Analysis