Requirements Management and Communication (BABOK KA)

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.

The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software.  Software is everywhere. Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success.

Business analysts are at the sharp end of one of the great challenges of information technology – how to build the systems organizations need. At the same time, organizations are demanding more sophisticated systems – the “dumb” systems of yesteryear are no longer enough.

Why has it been necessary to write so many different, book-length treatises about requirements management on software projects? Is it not possible to develop an approach to handling software requirements that is simple enough to express concisely -- and yet can work with large, complex projects as well as smaller efforts?

At the risk of using a word that disturbs many in the field of software engineering, requirements management is just a process. The more simply this process can be described, the more likely it will be to work in real software organizations. So rather than consider every possible nuance relating to managing software requirements, this article will attempt to express the essence of an approach that can work well on virtually any Agile software development project. In the appendix, I include a detailed example illustrating the key ideas.

Author: Theodore F. Rivera, Software Group Strategist, IBM

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.

The real world is a complex place, resulting in complex requirements for any system that has to work there. This is true regardless of development paradigm. Although "agile in the small" methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater after putting too much faith in the overly simplistic strategies of those processes. Luckily, with a bit of discipline, it is straightforward to address the inherent challenges of complex requirements in an agile manner without resorting to the documentation-heavy practices favored by the traditional community.

The Scrum method has popularized the idea of managing requirements as a stack of small, functional chunks, captured in a prioritized stack called a "product backlog". The idea is that at the beginning of each iteration/sprint, you pull an iteration's worth of work off the top of the stack. If only it were that easy. Although Scrum has helped us to get away from the onerous change prevention strategies (oops, I mean change management strategies) of traditional methods, it has blinded a generation of developers to the inherent complexities and nuances of understanding and implementing requirements.

Author: Scott Ambler

Study after study has shown poor requirements management is the leading cause of failure for traditional software development teams. When it comes to requirements, agile software developers typically focus on functional ones that describe something of value to end users—a screen, report, feature, or business rule. Most often these functional requirements are captured in the form of user stories, although use cases or usage scenarios are also common, and more advanced teams will iteratively capture the details as customer acceptance tests. Over the years, agilists have developed many strategies for dealing with functional requirements effectively, likely one of the factors leading to the higher success rates enjoyed by agile teams. Disciplined agile teams go even further, realizing that there is far more to requirements than just this, that we also need to consider nonfunctional requirements and constraints.

Nonfunctional requirements (NFRs), also known as "technical requirements" or "quality of service" (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common NFRs include accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.

A constraint defines a restriction on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this—agilists will have the courage to make tomorrow's decisions tomorrow, disciplined agilists have the humility to respect yesterday's decisions as well.

Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with NFRs and constraints.

Author: Scott Ambler

Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.

Author: Jan Kusiak

While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.

This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.

The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the
relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.

Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild

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.