Elicitation (BABOK KA)

With business analysis projects, as with all endeavors, you have to know where you are going before you can chart your course to get there. In other words, before you can decide whether to take a train, bus, or plane, what time of day you will travel, and what you will carry, you have to decide where you are going.

So it is with requirements. Before you can chart how you are going to implement a solution, everyone involved in the development effort must agree on why you need it to start with and that it is the very best solution available. Business requirements are fundamental to any development effort because they define where you are going by articulating the business problem and its solution—why it is needed and how to measure its success.

The Business Analysis Body of Knowledge (BABOK® 2.0) is the definitive guide to the profession of business analysis. Every business analyst can profit from it, and few analysts can afford to be without it.

The purpose of this article is to assist the business analyst engaged in the elicitation of stakeholder requirements. The key to any successful elicitation is asking the right questions whether it be in interviews or a facilitation session. Although the right questions are dependent on the solution scope, there are generic questions that the business analyst can use to start the elicitation regardless of the solution scope. The author begins the article using a mind map to capture keywords of generic questions and then provides a list of generic questions drawn from that map of which specific solution scope questions can be added by the business analyst.

Given the economic downturn, "cheaper, better, faster" seems to be a universal mantra in business. To stay competitive, organizations must continually strive to be more agile and develop higher-quality solutions more quickly-despite obstacles such as geographically distributed teams, limited budgets and resources, quick delivery times, language barriers and government regulations. These challenges require teams to consider new ways of doing business so they can be more responsive to frequent business changes.

In Part 1 of  this article, I talked about the new skills and attitudes business analysts need to bring to agile development... Now it's time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let's take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.
 

Quality requirements contribute to the success of agile and traditional project management projects. The requirements definition process followed in a traditional project management framework and the features-based storyboarding that is typical of agile approaches are different, but they also have many similarities. The actual process used to define and gather requirements may be different, but the criteria for quality requirements remain constant. What are these similarities and differences in the process of gathering requirements? What happens to the role of the business analyst in an agile environment?

I am not sure if there are many other fields in corporate America that require the finesse necessary to execute the professional pushback as greatly as business analysis. Just by the shear nature of what analysts do, we are constantly uncovering inefficiencies and making recommendations for improvements or enhancements. Sometimes those recommendations are system-focused but they can also be people and process focused.

The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.

No matter what requirements gathering process you subscribe to-waterfall, unified, or another approach-your discovery will be markedly easier if you can identify the right subject matter experts from the beginning. Whether they exist inside or outside your organization, people who intimately know your project's product or service, its actors, and its building tools will help you create more inclusive requirements, identify your unknowns, and grow in your own knowledge of the industry.

In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly.

In particular, I'll be mentioning storyboards, wireframes and prototypes.
I'll also cover what level of quality and detail you should adopt when applying these techniques.

The reason is simple, anyone involved in Information Security needs a detailed understanding around how things work; where the dependencies are, the inner workings of programs and applications, who has administrative control over sensitive information, where the information is being stored, and how clients and programs interact with the data.

Performing threat risk assessments (TRA) involves an intimate understanding of a solution or service. This means everything from the pretty UI right down to the bits of code your development team scribed to make it look that way. 

The only way to understand these systems is via detailed communication with stakeholders, architects, business analysts, systems and network administrators, executives, clients and their technical resources, board members, vendors, ISPs, and the list goes on.

The ubiquity of software project failures – with failure defined as projects that fundamentally failed to meet business-sponsor expectations, missed scheduled completion dates, or exceeded budget – is a pronounced theme in any number of independent research reports on custom software development. The Standish Group, for example, cited that only 31% of projects delivered 100 percent of the expected value, were on-time, and on-budget and a report from the Aberdeen Group found 90 percent of projects came in late, of which 30 percent were simply cancelled before delivery.

Analysts and users alike cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group’s annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. Requirement miscommunications is also the primary factor behind the prevalence of rework, which according to industry statistics, can add up to 40 percent of the total development effort within a given software project. A 2005 survey conducted by iRise and Decipher found that almost three-quarters (73%) of organizations budget for rework, thus, in effect, planning for failure. Moreover, almost one-third set aside more than 25% in their budgets for these change orders, money that could be funneled directly into innovation rather than re-doing work that should have been com¬pleted the first time.

Ultimately, rework costs companies the ability to get to market quickly and saps competitive advantage; while companies are busy fixing applications, their competitors are busy capturing market share.

The solution to these costly, frustrating problems is the creation of accurate requirements before development even begins. By allowing the business analyst to col¬laborate with stakeholders, users, architects, user expe¬rience designers and developers early on in the development process, all parties are involved in the definition of the product and all parties know what will be built long before a single line of code is written.

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile.

My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business.

I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.