Requirements Management and Communication (BABOK KA)

23007 Views
15 Likes
1 Comments

 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.

26066 Views
9 Likes
15 Comments

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.

 

28336 Views
6 Likes
1 Comments

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.

25868 Views
17 Likes
1 Comments

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.

22410 Views
11 Likes
0 Comments

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."

44922 Views
20 Likes
8 Comments

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.
 

34051 Views
23 Likes
9 Comments

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.

31431 Views
11 Likes
2 Comments

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.

5579 Views
3 Likes
3 Comments

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.”
 

82845 Views
438 Likes
3 Comments

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.

19164 Views
5 Likes
2 Comments

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.

21805 Views
1 Likes
0 Comments

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.

9955 Views
3 Likes
0 Comments

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

20319 Views
4 Likes
0 Comments

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.

8067 Views
2 Likes
0 Comments

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

Page 8 of 9First   Previous   3  4  5  6  7  [8]  9  Next   Last   

 



 




Copyright 2006-2025 by Modern Analyst Media LLC