Because Requirements Analysis and Design Definition has a broader scope than many see envision, including measuring requirements and designs against overall organizational strategy, this Knowledge Area remains essential to Business Analysis. Here is where models, designs, and solutions are documented, revised, and verified.

Inputs to this Knowledge Area include the Solution Scope, which represents potential gains. Outputs of Requirements and Designs will feed into any prototypes, beta versions, and eventually an operating solution. So, again, this is the central piece.

So how is this affected by the BACCM?

Change

During Knowledge Area 2 – Elicitation and Collaboration, the Business Analyst worked to discover details about the need as well as what will satisfy the need. During the Requirements Analysis and Design Definition, there is a shift from understanding the need toward proposing optional solutions. The analyst could view each potential solution as a collection of changes and evaluate each set until one solution is chosen.

I know that sounds like Waterfall. For Agile proponents, the process is actually similar – however, it is performed against small chunks and reviewed in increments. The significant difference is that each product increment provides an opportunity to change in Agile, while Waterfall is much less adaptive.

Need

While we may have produced multiple solution options, these options are evaluated against the Need. For this, there may have been some metrics discussed that define precisely what the need is. Then the potential solutions can be measured against those metrics to see how well each solution works.

For the assessment of need, remember that this element of the BACCM does not concern itself with cost or environmental factors. These are functional concerns at this point.

Some of the options, such as commercially available software packages, may provide additional capabilities beyond those that are described for the defined need. In this evaluation, the assessment needs to represent only those functions relating to the defined need. To do otherwise would introduce scope creep before the project even started. The overhead of the unneeded functionality, even if it is included in the price, may drive up the total operational or deployment cost as well.

Value

On the other hand, the Core Concept of Value is much concerned about cost. But it does not stop there. Value may be a combination of the value gained – the cost of delivery and ongoing operational expenses. However, value may also include such factors as improving resource utilization for higher-value tasks. In such a case, the value can be intangible. Other value expressions could be compliance related, where the value derived is motivated by legal concerns more than financial.

That last statement is not intended to be a judgment on an organization. Many highly ethical enterprises existed for decades before legislation such as Sarbanes Oxley required improved audit controls on the processes of publicly traded companies. It merely means that the environment may have changed, which created a value on compliance, which was quite expensive to fulfill.

Context

Going back to another element ignored by the Core Competency of Need, there is Context. On the simplest terms, Context is concerned with how the solution option fits within the organization.

One interesting side note is how there can be an interplay between Value and Context. A solution may be feasible but require added resources – thus driving up cost and decreasing the realized value of that solution. Another solution that can be supported without the additional overhead would then both fit better in the context and provide higher value.

Stakeholder

At all points in this discussion, the concerns of stakeholders are to be considered. These concerns will be reflected as part of the need. But more than that, any documentation of solution options, as well as the selection solution, must be understandable to all stakeholders.

At first, this will be decision-makers and subject matter experts associated with the initiative. However, as the requirements near development, the delivery team needs to be increasingly consulted and included in conversations.

Solution

Now that all of the options have been measured against Need, Value, and Context, the Requirement Analysis and Design Definition can settle on a specific solution. Up to this point, the solutions have been discussed in a context of broad direction, not a thorough definition. The requirements have been high level for multiple reasons.

One of the common reasons is that the audience involved in making decisions will not require all the details to set a direction. But perhaps more importantly is to maximize the value of the analysis itself. If multiple options are being proposed, it merely may not be feasible to define the designs for all of those variations.

Once a direction has been determined, the analysis can become more focused on the solution. This option will then be refined in greater detail so that all requirements and designs will be captured, reviewed, verified, and validated before the start of delivery (either for the requirement, or the solution as a whole – depending on the SDLC chosen).

• BA Certification
• BACCM
• Business Analysis