Requirements Analysis (BABOK KA)

Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.”

“Requirements are rules. They arise from business models, but they are different from those business models.”  Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they?  No!  Read this article to find out why.

In that article we presented our case that the typical approach to business requirements management was fundamentally flawed, with key issues being development of business requirements within a project context, and capture of those requirements using unstructured artifacts, particularly narrative.

The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a Business Analyst and the main sections they contain.

These are the main documents produced by a BA over the course of a project...
 

Thousands of business analysts have turned to software visualization from as a strategy to simplify their jobs and cut through the confusion. With iRise, business analysts are empowered to quickly assemble a high-fidelity working preview of an application before development ever begins. These visualizations look and act just like the final product, creating an accurate visual model for what to build.

Requirements continue to be a major problem area for most organizations. According to industry reports, the leading causes of quality, cost, and schedule problems are lack of understanding of the customer’s needs, incomplete requirement specifications, and managing changing requirements. In fact, requirements are so important that one of the definitions of quality is, “conformance to requirements”. If requirements are not good, the costs of poor quality will be high and the resulting products and services will not be good either. So what can an organization focus on now to measurably improve their requirements? This article will describe some practical strategies that organizations can use to measurably improve their requirements.

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.
 

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.
 

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.

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.

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.

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.

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