Solution Assessment and Validation (BABOK KA)

The purpose of the Trips-R-You Flight Booking Case Study is to provide an integrated, end-to-end set of requirement examples. In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. This case study, and associated artefacts, use the more traditional business terms Goals, High-level Requirements (HLRs), and Detail Requirements. Only functional requirements are addressed, and only within the context of a project chartered to deliver an IT-based solution.

The success of process improvement projects is greatly influenced by good planning for gathering requirements or user stories. Part of the planning is identifying which of the analysis techniques will be effective for the elicitation of business needs with stakeholders. One objective for these techniques is to enhance project team collaboration by establishing a common understanding of the business process, thus providing a knowledge basis for developing changes. This article explores using job task instructions as an analysis technique for supporting project team collaboration by providing a platform to keep team members informed with the decisions on workplace changes.

A requirement is “a condition or capability needed by a user to solve a problem or to achieve an objective” (AKA a goal). Thinking in terms of problems and goals thus is a core competence for the requirements engineer. But what in fact is a problem or a goal? This may seem to be a rather philosophical question. As requirements engineers we should be quite specific on this point as the problems and goals of our clients are the raison d’être for our work.

Business analysis is a broad discipline and we have a whole range of tools and techniques at our disposal. We may get involved within projects, but also outside of them. Many BA teams are actively seeking earlier engagement—when we are engaged prior to a project being initiated we can work with our stakeholders to ensure that the problem space is thoroughly understood. We can encourage stakeholders to think about many possible solution options, and can work with them to ensure that the option that is chosen is the best fit and has the best chance of delivering maximum benefit. Early engagement also helps us avoid the 'first solution trap'.

I take the approach that as Business Analysts, the line between requirements and design is an imaginary line. We need to be pragmatic (abandon purist thinking) and not be afraid to wear the design cloak, to adopt design thinking. 

 

So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.

---

Author: Michael Roy, Business Analysis Professional / Requirements Leader

Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.

 

The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.

So you’ve developed a set of requirements for some portion of your next systems development project. Now what? Experienced project managers and software developers understand the value of translating requirements into rational project plans and robust designs. These steps are necessary whether the next release represents 1 percent or 100 percent of the final product. As shown in Figure 1, requirements serve as the foundation for project plans, designs, code, and tests. In addition to these connections, there is a link between the requirements for the software to be built and other project and transition requirements. Those include data migrations, training design and delivery, business process and organizational changes, infrastructure modifications, and others.

Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles...

Gathering and documenting requirements to develop software is often seen by business analysts as their core task. Actually, they are there to deliver value to the business—everything else is secondary.

I never really understood the hubbub associated with system design. People tend to look upon it as a complicated process. Actually it's not, yet the corporate landscape is littered with disastrous system projects costing millions of dollars, all because developers overlooked some rather simple principles for design and focused on technology instead.

This article reviews the complexity of the role of the business analyst (BA) facilitator in obtaining a stakeholder agreement (i.e., a consensus or a compromise) on solution features and/or user requirements. The BA facilitator achieves this agreement by maintaining a neutral posture in guiding the stakeholders though a dialogue in a series of meetings.

Most of the projects inevitably struggle at some point or the other if the scope is not defined properly. The right note to start a project is to have a clear Project and Solution/Product scope at hand. It is very critical for a Business Analyst to clearly understand and define the Solution Scope in black and white before even going into the Requirement Elicitation phase. This article focuses primarily on key aspects of understanding and defining Solution Scope in traditional methodologies.  

Checkpoint Beta is not mandatory. It is, however, extremely helpful for the business analyst. Checkpoint Beta is also an informal meeting, this time with the solution team. It is held prior to committing the solution to the final, formal solution document andobtaining final confirmation from the business community.

Business requirements are usually captured in narratives and graphics that, regardless of how detailed, structured, cross-referenced and validated, are fundamentally imprecise. A data-driven approach to specifications has the potential to help avoid these problems and subsequently decrease the risk and increase the return on companies' IT investments.

We present a requirements framework and methodology that may be different from what you are doing. Its three prominent characteristics are a framework, a new model, and visualization. The framework ensures completeness of all requirements. The new model is the Decision Model, transforming important business thinking into a tangible and manageable business requirement. The visualization simulates user scenarios, alleviating the need for abstract specifications or models.