Current Articles | Search | Subscribe (RSS)

Entries for the 'Requirements Management and Communication (BABOK KA)' Category

» FEATURED: 10 Ways Documents and Spreadsheets Sabotage the Business Analyst’s Career

(3117 Views) (1 Comments)

10 Ways Documents and Spreadsheets Sabotage the Business Analyst’s Career

At long last, Business Analysts are stepping into the spotlight... Most BAs, however, still rely on documents and spreadsheets to manually stitch together their requirements. For those BAs, this article points out five ways that documents and spreadsheets are hurting your career and preventing you from joining the growing number of BAs who ar...

» FEATURED: Connect the Dots with Requirements Traceability, Part 2

(2198 Views) (2 Comments)

Connect the Dots with Requirements Traceability, Part 2

The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. When I’ve set up such matrices in the past, I made a copy of the baselined SRS and deleted everything except the labels for the functional requirements.

» FEATURED: Technical Writing Guidelines for Documenting Business Requirements

(5511 Views) (3 Comments)

Technical Writing Guidelines for Documenting Business Requirements

The purpose of this article is to assist business analysts in writing business requirements. This article provides six guidelines on technical writing. The six I cite here are the major ones I consider when writing a business requirements document (BRD).There are, of course,other technical writing guidelines; for comprehensive texts, see Further Re...

» FEATURED: Connect the Dots with Requirements Traceability, Part 1

(4156 Views) (2 Comments)

Connect the Dots with Requirements Traceability, Part 1

Simple requirements changes often have far-reaching impacts, necessitating that many parts of the product be modified. It’s hard to find all the system components that might be affected by a requirement modification. Assessing the impact of a proposed change is easier if you have a road map that shows where each requirement or business rule was imp...

» FEATURED: Requirements Reviews - When You Want Another Opinion, Part 2

(2092 Views) (0 Comments)

Requirements Reviews - When You Want Another Opinion, Part 2

Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It’s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a t...

» FEATURED: Requirements Reviews - When You Want Another Opinion - Part 1

(4030 Views) (2 Comments)

Requirements Reviews - When You Want Another Opinion - Part 1

In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities.

» FEATURED: Using Adaptability as a Guide to Navigate the Uneven Terrain of Requirements Elicitation

(2174 Views) (0 Comments)

Using Adaptability as a Guide to Navigate the Uneven Terrain of Requirements Elicitation

Adaptability is a word that is not used enough in the context of business analysis and collecting requirements. Though it is used in the project world, “adaptability” is more synonymous with project methodology or project teams as a whole than it is with requirements elicitation or requirements management. Being adaptive to your surroundings is wha...

» FEATURED: Selecting Appropriate Requirements Views

(5631 Views) (1 Comments)

Selecting Appropriate Requirements Views

There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article I offer some ideas about how to make that choice.

» FEATURED: Six Ways to Avoid Requirements Workshop “Traffic Jams”

(4192 Views) (0 Comments)

Six Ways to Avoid Requirements Workshop “Traffic Jams”

As we travelled around India we were initially amazed at how the traffic flowed. India is a populous country, of course, and they have an ever-increasing number of vehicles. No matter what time of day it was, the traffic seemed heavy. So, how can their constant flow of traffic work?

» FEATURED: Some Alternative Requirements Views

(4809 Views) (0 Comments)

An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable...

» FEATURED: Why Create Multiple Requirements Views?

(6244 Views) (2 Comments)

If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish pr...

» When Not Knowing The Answer is OK - Especially for the Business Analyst

(5587 Views) (4 Comments)

When Not Knowing The Answer is OK - Especially for the Business Analyst

Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME i...

» FEATURED: How Detailed Should Requirements Be? Part 3 - When More Requirements Detail Is Advisable

(8491 Views) (4 Comments)

How Detailed Should Requirements Be? Part 3 - When More Requirements Detail Is Advisable

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.

» FEATURED: How Detailed Should Requirements Be? Part 2 - When Less Requirements Detail Is Appropriate

(6798 Views) (2 Comments)

How Detailed Should Requirements Be? Part 2 - When Less Requirements Detail Is Appropriate

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.

» Requirements Reuse: the State of the Practice

(3045 Views) (0 Comments)

Requirements Reuse: the State of the Practice

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

Page 1 of 5

First Previous [1] 2 3 4 5 Next Last

Join the Premier Community for
Business Analysts, Business Process Professionals,
Systems Analysts, Data Analysts, and more…

Business Analyst Articles: Business Analysis & Systems Analysis

Entries for the 'Requirements Management and Communication (BABOK KA)' Category

Join the Premier Community for Business Analysts, Business Process Professionals, Systems Analysts, Data Analysts, and more…

Business Analyst Articles: Business Analysis & Systems Analysis

Entries for the 'Requirements Management and Communication (BABOK KA)' Category

Join the Premier Community for
Business Analysts, Business Process Professionals,
Systems Analysts, Data Analysts, and more…