Requirements Analysis (BABOK KA)

44287 Views
38 Likes
1 Comments

This article promotes a new approach to requirements management that reduces project complexity and improves communication between business and IT. This new approach can be used on its own, or as a supplement or precursor to existing approaches. Critical features of the approach are: detachment of business requirements from individual projects; and the production of testable requirements that can be shown to be complete, consistent, and correct prior to use within the SDLC.
 

17451 Views
4 Likes
2 Comments

We present a requirements framework and methodology that may be different from what you are doing. Its three prominent characteristics are a framework, a new model, and visualization. The framework ensures completeness of all requirements. The new model is the Decision Model, transforming important business thinking into a tangible and manageable business requirement. The visualization simulates user scenarios, alleviating the need for abstract specifications or models.
 

21547 Views
16 Likes
6 Comments

Extreme Inspections are a low-cost, high-improvement way to assure specification quality, effectively teach good specification practice, and make informed decisions about the requirements specification process and its output, in any project. The method is not restricted to be used on requirements analysis related material; this article however is limited to requirements specification. It gives firsthand experience and hard data to support the above claim. Using an industry case study I conducted with one of my clients I will give information about the Extreme Inspection method - sufficient to understand what it is and why its use is almost mandatory, but not how to do it. I will also give evidence of its strengths and limitations, as well as recommendations for its use and other applications.

26355 Views
20 Likes
11 Comments

Widely-accepted conventional requirements models continue to create creep—changes to settled requirements which are a major cause of project overruns. Business Analysts and others will continue to encounter such creep so long as they follow flawed models focusing on requirements of a product or system being created without adequately also discovering the REAL, business requirements the product must satisfy to provide value.

26554 Views
19 Likes
3 Comments

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.

93215 Views
51 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.

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

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

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

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

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

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

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

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

8272 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

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

 



 

Copyright 2006-2021 by Modern Analyst Media LLC