In this KnowledgeKnugget™ you will learn how current Software Development Methodologies such as Agile, Iterative, and Waterfall impact your business analysis activities.

An SDM Influences Requirements Elicitation and Analysis

A Software Development Life Cycle (SDLC – aka SDM or Software Development Methodology) is a workflow for delivering and maintaining an information technology solution. Typically, it consists of a set of activities, tasks, or steps that create one or more needed deliverables or artifacts, i.e., a requirements document, a training program, a database design, the program code, etc.). The ultimate deliverable of a methodology is a deployed or installed solution (including manual and automated components) that its intended target audience can use.

As a business analyst, you are a major player in the process of defining the solution. Therefore, you need to understand how the methodology influences your requirements elicitation, specification, and documentation. Each type of software development methodology handles changes in the requirements over the life of the project differently.

How do the different methodologies affect your requirements definition efforts? As the individual responsible for translating business needs into requirements at various levels of detail, you will be involved in specific aspects of the project at different times and different levels of intensity. The major differences have to do with the level of detail of the requirements, the timing of the requirements analysis and specification activities, and the form in which you document the requirements.

The three different types of methodologies currently in use are Waterfall (Structured), Iterative, and Agile.

Actually, there is a fourth approach. The “Ad Hoc” (aka: Chaotic) approach assumes you have very little knowledge of what you are doing or how to get it done. This approach is essential when a revolutionary new technology is introduced. There are no clearly defined activities or deliverables and work progresses in a “whatever needs to get done” flow. As a side note, the method is often disparagingly referred to as the “CAL, TAL, PAL” approach (“Code a little, Test a little, Pray a lot”). Since little is known about what needs to be done when, requirements activities tend to be ad hoc, spur of the moment tasks that seldom involve a full-time business analyst. Often the need for requirements is not obvious until a fully developed solution fails to meet the customers’ needs. Changing requirements often lead to considerable unscheduled rework in this approach as the customer rejects one solution after another. Due to its lack of definition, this approach is seldom referred to as a methodology.

… [end of excerpt]