Skip to content
Browse
BABOK Guide
BABOK Guide
10. Techniques
Introduction 10.1 Acceptance and Evaluation Criteria 10.2 Backlog Management 10.3 Balanced Scorecard 10.4 Benchmarking and Market Analysis 10.5 Brainstorming 10.6 Business Capability Analysis 10.7 Business Cases 10.8 Business Model Canvas 10.9 Business Rules Analysis 10.10 Collaborative Games 10.11 Concept Modelling 10.12 Data Dictionary 10.13 Data Flow Diagrams 10.14 Data Mining 10.15 Data Modelling 10.16 Decision Analysis 10.17 Decision Modelling 10.18 Document Analysis 10.19 Estimation 10.20 Financial Analysis 10.21 Focus Groups 10.22 Functional Decomposition 10.23 Glossary 10.24 Interface Analysis 10.25 Interviews 10.26 Item Tracking 10.27 Lessons Learned 10.28 Metrics and Key Performance Indicators (KPIs) 10.29 Mind Mapping 10.30 Non-Functional Requirements Analysis 10.31 Observation 10.32 Organizational Modelling 10.33 Prioritization 10.34 Process Analysis 10.35 Process Modelling 10.36 Prototyping 10.37 Reviews 10.38 Risk Analysis and Management 10.39 Roles and Permissions Matrix 10.40 Root Cause Analysis 10.41 Scope Modelling 10.42 Sequence Diagrams 10.43 Stakeholder List, Map, or Personas 10.44 State Modelling 10.45 Survey or Questionnaire 10.46 SWOT Analysis 10.47 Use Cases and Scenarios 10.48 User Stories 10.49 Vendor Assessment 10.50 Workshops

2. Business Analysis Key Concepts

2.5 Requirements and Designs

BABOK® Guide

Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of business analysis. However, it is important to recognize that business analysts are also responsible for the definition of design, at some level, in an initiative. The level of responsibility for design varies based on the perspective within which a business analyst is working.

Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle.

The classification as a requirement or a design may become less significant as the business analyst's work progresses to a greater understanding of and eventual fulfillment of the need. The tasks in the BABOK® Guide such as Trace Requirements (p. 79) or Specify and Model Requirements (p. 136) may refer to requirements, but the intent is to include designs as well.

Business analysis can be complex and recursive. A requirement (or set of requirements) may be used to define a design. That design may then be used to elicit additional requirements that are used to define more detailed designs. The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the designs. Whether it is the business analyst or some other role that completes the designs, the business analyst often reviews the final designs to ensure that they align with the requirements.

The following table provides some basic examples of how information may be viewed as either a requirement or a design.

Table 2.5.1: Requirements and Design

Requirement

Design

View six months sales data across multiple organizational units in a single view.

A sketch of a dashboard.

Reduce amount of time required to pick and pack a customer order.

Process model.

Record and access a medical patient’s history.

Screen mock-up showing specific data fields.

Develop business strategy, goals, and objectives for a new business.

Business Capability Model.

Provide information in English and French.

Prototype with text displayed in

English and French.

   

Stakeholders may present a need or a solution to an assumed need. A business analyst uses activities found in Elicitation and Collaboration (p. 53), Strategy Analysis (p. 99), Requirements Analysis and Design Definition (p. 133), and Solution Evaluation (p. 163) to transform that request into a requirement or design. Regardless of the focus of the stakeholder, the importance of the role of the business analyst lies in continuously asking the question ‘why?’. For example, “Why is either the requirement or design necessary to provide value to an enterprise and to facilitate the realization of an enterprise’s goals and objectives?”

Figure 2.5.1: Requirements and Design Cycle

Requirements and Design Cycle