Requirements Management and Communication (BABOK KA)

 Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.  Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
 

Like it or not, every business analyst will have to stand up in front of a group and present. The group might be your business clients, the project stakeholders or just your fellow team members but for many people, one of two things will happen: it will frighten the life out of them OR they’ll umm and ah their way through, sending the audience to sleep.  Why is this so?
 

The product backlog is a beautifully simple artifact – a prioritized list of the outstanding work necessary to bring the product to life. To work with the product backlog effectively, it needs regular attention and care; it needs to be carefully managed, or groomed. Business analysts can play an important role to ensure that this is done well.

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

The voluminous amounts of information that an analyst collects during the discovery and elicitation phases warrant a good deal of planning and organization in order to make business or user requirements into a usable, cohesive whole. As with any other organization process, the key element to requirements’ organization success is thorough preparation and planning.

 You remember the game of telephone, right? The test of communication skills where one person whispers a message to his neighbor, and that message is translated multiple times from person to person until eventually, the last contestant repeats her interpreted message aloud. The goal is for the final person in the chain to correctly hear the original message, but invariably, there is laughter all around as the message is misconstrued.

In agile projects, you deliver the product in a series of successive and sensibly staged releases. Each release represents the culmination of a series of requirements decisions... One of your biggest challenges is ongoing-how to group and sequence requirements for optimal delivery. Let's take a look at adapting requirements workshops to meet that challenge.

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.

As the process of capturing and documenting business requirements matures, there is often a watershed moment when an organization must decide whether to perform traceability of requirements as part of that process. Most companies involved with a formal methodology for software development utilize some degree of traceability; but those not familiar with it could be put off by the overhead of requirements management (RM), of which traceability is a component. Therefore, it helps to understand some of the value aspects of instituting traceability.

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."

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.
 

From a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.

Agile development practices introduced, adopted and extended the XP-originated "User Story" as the primary currency for expressing application requirements within the agile enterprise. The just-in-time application of the user story simplified software development and eliminated the prior waterfall like practices of overly burdensome and overly constraining requirements specifications for agile teams.

However, as powerful as this innovative concept is, the user story by itself does not provide an adequate, nor sufficiently lean, construct for reasoning about investment, system-level requirements and acceptance testing across the larger software enterprises project team, program and portfolio organizational levels. In this whitepaper, we describe a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the largest software enterprise, while still providing a quintessentially lean and agile subset for the agile project teams that do most of the work.

Where application development is concerned, the ability to produce great code is just one small component of overall success. Just as essential is the ability for the developers to clearly grasp the business requirement – and deliver against an accurate functional specification.

Nick McKenzie, technical director at nVisionIT, notes that the process for the creation of an application is not always clearly understood. “From the business owner, to the user, to the developer, there are different perspectives and different expectations at play. As requirements pass through this chain, inconsistencies or assumptions can be introduced which can derail this process.”
 

Business analysis is an important aspect of agile software development projects, but the agile approach is significantly different than the traditional, serial approach of yesteryear. Because the agile approach to business analysis is different the approach to requirements specification is also different, for many traditionalists this will prove to be a significant cultural shock to them at first. In this article I briefly overview how business analysis activities fit into an agile approach, question some of the dogma around documentation within the traditional community, summarize some of the evidence showing that agile approaches are more effective in practice than traditional approaches, and end with strategies for specifying requirements on an agile project.