Requirements Analysis (BABOK KA)

91427 Views
50 Likes
2 Comments

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.

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

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

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

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

19054 Views
25 Likes
7 Comments

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.

13245 Views
13 Likes
1 Comments

If requirements management practices were songs entering a popularity contest, requirements validation would hardly be a favorite contender. It's easy to understand why: validation is usually a tedious, time consuming task, and, as with nearly every quality control activity, it is supposed to reveal defects, going against our natural desire of being right, not making mistakes, and singing in tune.

16391 Views
2 Likes
0 Comments

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.

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

8018 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

14965 Views
4 Likes
2 Comments

It has been just over a year since I published my book, and that makes it easier for me to measure what has happened since then.

I have spent this year visiting many companies and discussing their business analysis function. In some cases, I have performed an assessment on the business analysts as well as the business analysis function within many large Corporates.

It has now got to the point where I could document the findings before I start the investigation. The reason for this is that the problems are the same. From articles and discussions from other countries it appears the problems are similar the world over. These are the problems I encounter most often:

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

5427 Views
1 Likes
0 Comments

When your users are physicians and nurses, they don't have time to sit in meetings explaining what they want out of an application or to wade through documents validating requirements. Patient care is their number one priority.

To get over that obstacle, the development team at the University of Texas M.D. Anderson Cancer Center relies on a simulation tool. Using iRise's visualization tool, physicians and nurses can see what the application will look like based on requirements given and quickly change or validate those requirements.
Those applications are part of an electronic medical record (EMR) system that the cancer center has been working on for the past three years, after they could not find a packaged application that met the hospital's unique needs. Sherry Preston, manager of EMR support and development at the center, called the project a work in progress that will continue to evolve.

18624 Views
8 Likes
1 Comments

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.

20769 Views
7 Likes
0 Comments

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.

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











Copyright 2006-2020 by Modern Analyst Media LLC