In this KnowledgeKnugget™ you will learn how traditional Waterfall (a.k.a. Structured) System Development approaches affect business analysis activities.

The Role of the Business Analyst in a Traditional Waterfall SDM

“Structured” (a.k.a. “Waterfall”) methodologies treat the software development process as a manufacturing or construction process. Progress is viewed as a steady flow from project initiation through analysis, design, development, testing, and delivery. During the initiation of the project, the business analyst might be involved in creating a business case. The skill set for this activity includes problem analysis, goals and objectives definition, cost-benefit analysis, and presentation to senior management.

In the Analysis phase, the business analyst’s responsibility is the creation of a Requirements Definition Document (or RDD for short) or something similar. During this phase, significant effort goes into requirements definition and business analysis to capture, clarify, and confirm the requirements. the business analyst elicits and analyzes business and stakeholder needs which are expressed in natural language and/or models. Process and data models are typical of waterfall methodologies and enhance communication between the various stakeholders on the project. This can lead to early identification of potentially volatile areas.

In the design phase of the project, the business analyst together with Subject Matter Experts (SME’s) and developers defines solution and transition requirements as well as technical specifications.

In many organizations, the business analyst is again involved in the Testing phase and usually is responsible for acceptance testing. Any changes that arise after acceptance of a phase are managed with varying degrees of success through a rigorous “Change Management” process.

The role of business analysis is most clearly defined and delineated in the Waterfall approach. the business analyst will be a major player in particular during the Analysis phase of the project. In Waterfall, the premise is that it is possible to clearly define most if not all stakeholder requirements during this phase. the business analyst defines the solution requirements as complete as possible during the design phase. Since it is unrealistic to expect that nothing will change, you will also typically be responsible for managing changes to the requirements throughout the life of the project.

As a senior business analyst, you are usually responsible for Requirements Management in which the requirements are traced back to problems as well as through all process models, data models, and all other project artifacts. Requirements Management effort in the waterfall method is very high but absolutely necessary to deal cost-effectively with changes in requirements during the development of the project (and the IT industry found out the hard way that it cannot live without changing requirements).

Although testing is not a recognized business analysis activity, many organizations also assign the responsibility for acceptance testing to the business analyst. This is presumably based on the recognition that no one understands the requirements better than the business analyst does. If you are in this situation, you need an entirely different set of skills to effectively verify and validate that the delivered software actually does what the business community requested.