Requirements Analysis (BABOK KA)

Ron Ross and Gladys Lam have written an important book for the business analyst community. It aims to get business analysts out of the technology ghetto that many of us get stuck in. Regardless of the type of analyst you are, I think it would be worth your time to get your hands on and read this book. I’ll explain why below.

There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant.

There are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article, expect to spend more time than average developing detailed requirements specifications.

Several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

For several decades, software reuse has been a recognized solution to improving efficiency of software development. However, implementing reuse in practice remains challenging and the IT community has little visibility into the state of the practice specifically as it pertains to reusing software requirements. This paper presents the results of a survey conducted in the global IT industry in 2010 and discusses the state of the practice for software requirements reuse.

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”

Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements?

So you want to be a better requirements analyst. Or maybe you’re completely new to business analysis and you just want to learn what requirements analysis involves, period.

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.