Study Report: Establishing Business

Requirements (Chapter 5)
1. Fundamental Definition of Business Requirements

Business requirements represent the highest level of the requirements

hierarchy. They are essentially the foundational "why" of any initiative,
documenting the organizational goals and the specific business problems the
system is intended to solve.

From the perspective of a child, business requirements are the reasons we

decide to build a lemonade stand—perhaps to earn enough money to buy a
new bicycle by the end of the summer. For an undergraduate student, these
requirements represent the high-level organizational goals and the strategic
justification behind a system implementation, defining the desired outcomes
that justify the investment of resources.

From a professional standpoint, business requirements are the rigorous

documentation of high-level business objectives, either for the organization
building the product or the customer procuring it. These requirements focus
explicitly on the business benefits and value propositions—such as cost
reduction, revenue growth, or regulatory compliance—typically originating
from a funding sponsor, an acquiring customer, or a product visionary. In
practice, these requirements are formally housed within the Vision and
Scope Document, which serves as the primary container for the project's
strategic direction.

2. The Vision and Scope Framework

The Vision and Scope framework provides the strategic boundaries required
to prevent project drift. While the terms are often used interchangeably, a
Senior Business Analyst must distinguish between the ultimate destination
(Vision) and the current roadmap (Scope).

Product Vision For a child, the vision is a mental picture of what our
lemonade stand will look like when it eventually becomes the most popular
shop in the city. To an undergraduate, the vision is the long-term strategic
direction describing the product’s ultimate purpose and the value it will
provide over its entire lifecycle. Professionally, the Product Vision is a
statement of the strategic goal for the product. it reflects the business
requirements and provides a stable context for all subsequent development,
regardless of how many individual projects it takes to achieve that vision.

Project Scope For a child, the scope is deciding that today we are only
building the wooden table and the sign, not the whole shop. An
undergraduate sees scope as the defined boundary of the current effort,
identifying what is included and excluded in a particular release.
Professionally, Project Scope identifies the specific portion of the product
vision that the project team will address in a targeted development cycle or
increment. It defines the functional boundaries and sets the limitations of the
current solution.

Strategic Alignment Table

Concept Focus Primary Question Answered

Business The What market gap or business pain point

Need Problem/Opportunity are we addressing?

Product The Ultimate What is the ideal final state of the

Vision Solution product?

Project Which specific parts of the vision are we

The Current Effort
Scope delivering now?

3. Anatomy of the Vision and Scope Document

The Vision and Scope document is the essential deliverable for establishing
project boundaries. It is structured into three primary thematic sections:

1. Business Requirements

o Background: Historical context and the rationale for the project.

o Business Opportunity: The market gap, competitive threat, or

internal need.

o Business Objectives: Quantifiable, time-bound goals (e.g.,

"Reduce stockroom waste by 15%").

o Success Metrics: Defined KPIs to measure value post-

implementation.

o Customer Needs: High-level needs that the product must

satisfy.
 o Business Risks: Potential threats to achieving the business
objectives.

2. Scope and Limitations

o Major Features: High-level capabilities (e.g., "Automated

Chemical Requisition").

o Scope of Initial Release: The functional MVP (Minimum Viable

Product).

o Scope of Subsequent Releases: The roadmap for future

iterations.

o Limitations and Exclusions: Explicitly stated items that are

not being built.

3. Business Context

o Stakeholder Profiles: Analysis of those influenced by or

influencing the project.

o Project Priorities: The balance between features, quality,

schedule, and cost.

o Operating Environment: The technical landscape and physical

location of use.

4. Identifying Business Benefits and Objectives

The origin of business requirements is critical for ensuring funding and

organizational buy-in. According to the Wiegers/Beatty framework, these
requirements typically originate from:

 Funding Sponsors: Executives providing the budget who require a

clear ROI.

 Acquiring Customers: External entities that mandate specific

business outcomes.

 User Managers: Leaders responsible for the staff who will utilize the
system daily.

 Marketing Departments: Strategic groups identifying market trends

and competitive advantages.

 Product Visionaries: Individuals with a high-level concept for a

transformative solution.
5. Scope Representation Techniques

To avoid the ambiguity of natural language, senior analysts utilize visual

models to represent system boundaries and hierarchical capabilities.

5.1 Context Diagram

The Context Diagram establishes the boundary between the system and
external entities. Using the Chemical Tracking System as a baseline, this
model identifies the primary interactors:

[Chemist] ------------------> | | <---------------- [Stockroom Clerk]

| Chemical Tracking |

[Health & Safety Dept] <----- | System | <---------------- [Training

Database]

| |

[Procurement System] <------- | | ----------------> [Inventory

Report]

5.2 Ecosystem Map

Unlike a Context Diagram, which focuses on a single system, the Ecosystem

Map illustrates how multiple systems relate within the enterprise.

 Inventory Management Cluster:

o Chemical Tracking System (Core)

o Warehouse Management System (Upstream data)

o Bar Code Labeling Service (Shared utility)

 Compliance and Safety Cluster:

o MSDS (Material Safety Data Sheet) Database

o OSHA Reporting Engine

o Employee Training Portal

 Financial Cluster:

o Procurement System

o Accounts Payable Module

5.3 Feature Tree

A "Feature" is one or more logically related system capabilities that provide
value to a user. Professionally, features are the primary unit for release
planning and prioritization. Below is a Feature Tree for a Web Browser,
decomposed into functional requirements:

[Web Browser]

+-- [Bookmarks]

| |-- Add a Bookmark

| |-- Edit Bookmarks

| |-- Export Bookmarks

| | |-- 1. The system shall display bookmarks in a collapsible tree.

| | |-- 2. The user shall be able to resequence bookmarks via drag-and-

drop.

| | |-- 3. The system shall display bookmark properties on hover.

| | +-- 4. The user shall be able to modify a bookmark's URL and

description.

+-- [Cookies Management]

+-- [Tabbed Browsing]

+-- [Add-In/Extension Support]

5.4 Event List

The Event List identifies external stimuli that trigger a system response,
defining the functional scope of the application.

Event Source Response

Chemical container Stockroom System creates new inventory record and

arrives Clerk prints label

Request for System notifies Health & Safety and

Chemist
disposal updates status to "Pending"

Monthly audit System System generates regulatory usage report

triggered Timer for OSHA

6. Conflict Resolution in Business Requirements

When stakeholders hold competing goals, the Senior BA must facilitate a

resolution based on established decision-making logic.

1. Identify Decision Leaders: Clearly establish who holds the final

authority. On most projects, this is the Project Sponsor for
budget/strategic issues or the Product Owner for feature priorities.

2. Align with Business Objectives: Use documented objectives as the

"North Star." If a requirement does not directly support a defined
success metric, it should be deprioritized.

3. Seek Consensus: Facilitate workshops to reach a "meeting of the

minds" where all parties support the chosen direction.

4. Defined Decision Rules: Before conflicts arise, agree on whether

decisions will be made by vote, consensus, or delegation.

7. Maintaining Scope Focus and Completion

"Scope Creep" is the most common cause of project failure. Analysts must
exercise authoritative control over the system boundary.

BA Command Set for Scope Control:

 Scope Validation: "Reject any proposed feature or requirement that

does not directly contribute to a defined Business Objective."

 Impact Assessment: "No change is free. Before accepting a scope

adjustment, perform a formal analysis of its impact on the schedule,
budget, and existing features."

 Traceability Verification: "Every functional requirement must trace

back to a specific user task and business requirement."

Completion Criteria: An iteration or project is deemed "complete" only

when the implemented requirements collectively satisfy the predefined
business objectives. If the system is built but the "why" remains unaddressed
(e.g., the system exists but airport counter costs have not decreased), the
project has not achieved true completion.

8. Vision and Scope in the Agile Environment

Agile projects adapt the Vision and Scope framework to accommodate rapid
change while maintaining a stable strategic core.

The Agile Perspective: In agile development, the high-level Product Vision

remains stable, while the Project Scope is dynamic and managed through a
prioritized Product Backlog. The Product Owner is the steward of this
vision. Requirements are explored in a "just-in-time" fashion, learning enough
to perform thoughtful prioritization and iteration planning. This allows the
team to deliver value quickly while using feedback to refine the scope of
future iterations.

9. Final Synthesis: Business Requirement Traceability

Project success depends on the vertical alignment of requirements.

Disconnects in this chain result in "Gold Plating" (functionality without value)
or "Expectation Gaps" (value without functionality).

The Alignment Flow and Organizational Roles: Business Need

(Managers / Marketing) -> Business Requirements (Sponsor / Product
Manager) -> User Requirements (BA / User Representatives) ->
Functional Requirements (BA / Developers / Testers)

In this hierarchy, the Business Need identifies the pain, Business

Requirements define the target, User Requirements describe the tasks to hit
that target, and Functional Requirements specify the technical behavior the
developers must implement and the testers must verify.

Study Report: Finding the Voice of the User

(Chapter 6 Analysis)
1. Introduction: The Criticality of the User Voice

In the discipline of requirements engineering, the "Voice of the User" acts as

the essential bridge within the requirements hierarchy. To navigate the
complexities of product development, a Lead Business Analyst must manage
three distinct layers:

1. Business Requirements: The high-level objectives and benefits the

organization seeks to achieve (the "Why").

2. User Requirements: The specific goals or tasks that users must

perform to derive value from the system (the "What").
 3. Functional Requirements: The behavioral specifications that
developers implement to enable those user tasks (the "How").

The "Voice of the User" primarily populates the User Requirements level.
When this voice is muffled or misinterpreted, we encounter the "Expectation
Gap"—the divergence between the customer’s actual needs and the
developer’s perception of those needs. As established in the source context,
frequent customer engagement is the primary mechanism for risk mitigation
against this gap. Without regular contact points (interviews, demos, and
prototype evaluations), the developer’s trajectory drifts away from the
business reality.

The "Sawtooth" Effect: Narrowing the Expectation Gap Over Time

The following diagram illustrates how frequent contact points (indicated by
^) snap the development trajectory back toward the actual user need,
preventing a catastrophic discrepancy at delivery.

Actual Need ----------------------------------------------------->

/| /| /| /|

/| /| /| /|

/ | / | / | / | <- Expectation Gap

/ | / | / | / |

Dev Path -------------------------------------------------------->

^ ^ ^ ^

Contact Contact Contact Final

Point Point Point Delivery

2. Understanding and Classifying User Classes

Strategic requirements elicitation requires a clear distinction between a

Customer and a User. A customer is an individual or organization that
requests, pays for, or receives the benefit of the product (e.g., Gerhard, the
senior manager). A user is a subset of the customer category who interacts
with the system directly or receives its outputs.

 Direct Users: Operate the product hands-on to complete tasks.

 Indirect Users: Do not operate the software but rely on its outputs,
such as reports or data feeds.
To avoid the "Overlooked Stakeholder" trap, a Business Analyst must perform
a User Class Analysis early in the project. Identifying these classes ensures
that the system satisfies diverse task-frequency and expertise profiles.

User Class Classification Table

User Class
Definition Example Application
Type

Chemists using the "Chemical

Direct Operates the system hands-on
Tracking System" to locate
User to complete tasks.
containers.

Indirect Receives outputs or data Warehouse Managers receiving

User without direct interaction. daily automated activity reports.

Help Desk personnel accessing

Secondary Uses the system occasionally
logs to troubleshoot chemist
User for support or maintenance.
issues.

Represents the user's voice A Marketing Manager defining

User
when real users are features for a commercial Web
Surrogate
inaccessible. Browser.

Note: Regulatory Stakeholders (such as compliance auditors) are

technically stakeholders outside the developing organization. While they are
not a "User Class" in terms of interaction, they are critical sources of
Business Rules and Constraints.

Methodology for Identifying User Classes

1. Stakeholder Impact Analysis: Review organization charts to find

departments that provide input to or receive output from the system.

2. Process Flow Decomposition: Analyze the "actors" in every

business process to identify who initiates actions or receives data.

3. External Actor Identification: Look beyond the firm for government

agencies, standards bodies, or "Loser Groups"—those who may be
negatively impacted and whose resistance could threaten project
adoption.

3. User Personas: Bringing Requirements to Life

A User Persona is an archetypal representation of a specific user class. By
moving beyond generic "User" labels, personas ground requirements in
specific goals, technical competencies, and environmental constraints. This
allows the development team to empathize with the human element of the
software.

Key Benefits of Personas in the Requirements Process

 Enhanced Empathy: Personas help developers understand the "Why"

behind a user's task, leading to more intuitive UI/UX design.

 Strategic Prioritization: They provide a lens to evaluate which

features provide the most value to the most critical user classes.

 Requirement Validation: Personas act as a "litmus test" for

developers to ask: "Would this specific feature help 'Scientist Sarah'
achieve her goal under a 30-second time constraint?"

4. Strategies for Connecting with User Representatives

Relying on "User Surrogates" (managers or marketing) carries high risk; they

often "telepathically" guess user needs rather than observing them. To
mitigate this, we establish a formal partnership.

The User-BA Partnership Agreement

The User's Bill of Rights The User's Bill of Responsibilities

1. To educate BAs and developers

1. To speak in business language rather
about the business domain and
than technical jargon.
jargon.

2. To dedicate the necessary time

2. To have BAs learn about their specific
to provide and clarify
business tasks and objectives.
requirements.

3. To be specific and precise when

3. To have requirements recorded in an
providing input to avoid
understandable,Appropriate form.
ambiguity.

4. To make timely decisions when

4. To receive explanations of all
the BA asks for resolution or
requirements practices and deliverables.
clarification.

5. To change requirements, while 5. To respect a developer's

respecting the cost/impact of those assessment of cost and technical
changes. feasibility.

Elicitation Strategies:

 Usage-Centric: Focuses on user goals and tasks (e.g., Use Cases).

This is the preferred strategy as it ensures the system supports actual
work.

 Product-Centric: Focuses on defining a list of features. This carries

the risk of "Gold Plating"—adding functionality that users never
actually utilize.

5. The Product Champion Approach

A Product Champion is a key user representative serving as the primary

interface between the user community and the BA. They are the "voice" that
resolves internal user conflicts and provides decisive input.

Product Champion Expectations

 Elicit and consolidate requirements from peers within their class.

 Review requirements and evaluate prototypes for accuracy.

 Make binding, timely decisions on behalf of their constituent group.

In distributed environments, the BA may need Multiple Product

Champions (representing different locations or functions) or External
Product Champions (actual customers in a commercial market).

Product Champion Traps to Avoid

1. The Vocal Minority: A champion who prioritizes their personal

workflow over the needs of the entire class.

2. Lack of Authority: A representative who cannot make binding

decisions, leading to schedule slippage.

3. The "Former User": An individual who once did the job but is now out
of touch with current business processes.

4. The Over-Scheduled Champion: A high-value expert who lacks the

bandwidth to participate, creating an elicitation bottleneck.

6. User Representation on Agile Projects

In agile development, the user voice is formalized through the Product
Owner (PO). The PO acts as the "on-site customer" and the final authority
on requirement value.

 Containers of the Voice: Requirements are captured in the Backlog

as User Stories.

 Timing and Detail: Unlike traditional models that specify

requirements up front, agile utilizes "Just-in-Time" elicitation.
Documentation is lightweight, focusing on the detail required for the
current iteration, with deeper analysis occurring as a story moves to
the top of the backlog.

7. Resolving Conflicting Requirements

Cultural conflict often arises when different user classes have incompatible
goals (e.g., security vs. ease of use). To maintain a collaborative team
culture, a Decision Rule must be selected before the first conflict occurs.
The Project Manager or Lead BA typically facilitates the selection of this
rule.

Five Decision-Making Styles

1. Majority Rule: A democratic vote within the stakeholder group.

2. Consensus: Discussion continues until all members can support a

single decision.

3. Leader Decides After Discussion: The leader (BA/PM) listens to all

input but makes the final call.

4. Delegation: Authority is granted to a specific SME or sub-group.

5. Veto Power: One specific stakeholder (e.g., the Sponsor) has the right
to block any decision.

8. Practical Applications: From Voice to Specification

Actionable specifications follow a logical flow: Feature → User

Requirement → Functional Requirement.

Feature Tree Decomposition: Web Browser Example

Demonstrating the breadth of requirements decomposition:

 Feature: Bookmarks

o User Requirement: Add a Bookmark

  Functional Requirement: The system shall save the current
URL.

o User Requirement: Edit Bookmarks

 Functional Requirement: The system shall allow the user to

modify a bookmark's name.

 Feature: Tabs

o User Requirement: Open New Tab

 Functional Requirement: The system shall display a blank

page upon new tab initiation.

o User Requirement: Move Tab

 Functional Requirement: The system shall update the tab

sequence in the UI.

 Feature: Add-Ins

o User Requirement: Install Add-In

 Functional Requirement: The system shall verify the add-

in’s digital signature before installation.

Next Steps Checklist for the Lead Business Analyst

 [ ] Perform User Class Analysis: Identify distinct task-frequency and

expertise profiles using organization charts and process flows.

 [ ] Conduct Stakeholder Impact Analysis: Assess how the system

will change the daily operations of both direct and indirect users.

 [ ] Formalize Product Champions: Appoint knowledgeable,

authorized representatives for each major user class.

 [ ] Define a Conflict Escalation Path: Establish and agree upon a

primary Decision Rule with the project sponsor.

 [ ] Establish the Partnership: Review the "User-BA Partnership

Agreement" with all representatives to align expectations on rights and
responsibilities.
Study Report: Chapter 9 — Playing by the
Rules
1. Introduction to Business Rules

Business rules are the fundamental "logic" of an organization. A critical

distinction for any Systems Analyst to grasp is that business rules exist
independently of any software system. They are the policies, standards, and
regulations that dictate how a business operates in the physical world.
Software is merely the medium used to automate or enforce these pre-
existing rules. As noted in the source context, deciphering these
requirements is often as difficult as deciphering the lyrics to the 1963 classic
"Louie Louie"—yet failure to do so results in systems that fail to meet the
actual business need.

The "3 Define Rule" - Business Rules

 For a Child: Like the rules of a board game or a playground, these tell
everyone how to play the game fairly so nobody gets confused or hurt.

 For an Undergrad: An organizational framework that establishes the

boundaries, logical conditions, and expected behaviors of a business
entity.

 For a Professional: A set of organizational principles, standards, and

regulations that dictate business conduct and governance, existing as
the origin for specific system constraints and operational logic.

Business Rule vs. Software Requirement

Rules are the origin; requirements are the implementation. The following
table delineates this relationship:

Category Business Rule Software Requirement

Role The Origin / Policy The Implementation / Behavior

Persisten Exists whether or not a Exists only within the software project
ce system is built. scope.

Ownershi Owned by the Business Owned by the Development/Analysis

p Stakeholder/SME. Team.

Example Only licensed pilots The system shall cross-reference the User
 can fly commercial ID with the FAA License Database before
aircraft. enabling flight controls.

2. The Business Rules Taxonomy

Utilizing a formal taxonomy ensures that the Business Analyst (BA) performs
a comprehensive elicitation. Categorizing rules prevents the omission of
subtle logic that "tribal knowledge" often obscures.

2.1 Facts

Facts are statements of truth that define the business domain and, crucially,
describe the relationships between business entities.

 Child: Things that are always true, like "Dogs have four legs."

 Undergrad: Structural constants that define the relationship between

different parts of an organization.

 Professional: A statement of truth that defines a fundamental

relationship between two business terms or entities within the
organizational domain.

Examples (Chemical Tracking System):

1. Every chemical container must be associated with a specific status

(e.g., "In Stock," "Disposed").

2. A Material Safety Data Sheet (MSDS) is a mandatory relationship for

every cataloged chemical.

3. Each laboratory is assigned to exactly one department.

2.2 Constraints

Constraints restrict the actions available to the system or its users to ensure
safety, security, or compliance.

 Child: "You are not allowed to go into the street."

 Undergrad: Operational boundaries that limit the design and

construction choices for a system.

 Professional: A policy that limits the options available to

stakeholders, often mandated by external regulatory bodies or internal
safety standards.
Constraint Example: "Only users with 'Hazardous Materials Training' Level
4 are permitted to request explosive-grade chemicals."

2.3 Action Enablers

These rules trigger specific actions under defined conditions, typically

following an "If [Condition], Then [Action]" structure.

 Child: "If you finish your vegetables, then you can have a cookie."

 Undergrad: Conditional logic that initiates a process based on a

specific state change in the system.

 Professional: An operational trigger that automates a business

response to a defined event, ensuring process consistency.

Logic Flow Diagram:

[Start Event: User requests chemical]

[Check Condition: Is chemical in stock?] -- No --> [Action: Notify

Procurement]

| |

Yes v

| [End Process]

[Action: Notify user of pickup location]

2.4 Inferences

Inferences derive new facts from existing data points through logical
evaluation.

 Child: "If the grass is wet but it didn't rain, the sprinklers must have
been on."

 Undergrad: A conclusion drawn by the system based on a set of

known facts.
  Professional: Logic that creates a new data state or "fact" by
evaluating the intersection of multiple existing business entities or
attributes.

Example: "If a chemical container has a flashpoint below 100°F, the system
classifies that container as 'Flammable'."

2.5 Computations

Computations are mathematical formulas used to drive quantitative business

decisions.

 Child: "Adding up all your pennies to see if you can buy a toy."

 Undergrad: Quantitative algorithms that process raw data to produce

a numeric result.

 Professional: Mathematical logic used to determine values such as

risk scores, tax liabilities, or inventory valuation for financial reporting.

Sample Computation Formula:

Total_Hazardous_Load = Sum(Container_Volume) where Container_Type =

'Hazardous'

Architect's Pro-Tip: Always document the source of the formula (e.g., "EPA
Regulation 40 CFR"). This ensures auditability and allows for easy updates
when regulations change.

3. Atomic Business Rules

To ensure clarity and maintainability, rules must be atomic—meaning they

are indivisible and address only one specific policy.

The "3 Define Rule" - Atomic Rules

 For a Child: A rule that only tells you to do one thing, like "Put your
shoes away."

 For an Undergrad: A discrete, irreducible unit of logic that cannot be

broken down without losing its intent.

 For a Professional: A granular unit of logic that focuses on a single

policy, ensuring precise traceability and reducing maintenance
overhead in technical specifications.

Comparison Exercise
  Complex/Combined Rule: "Chemists can order chemicals if they are
safety certified and the order is under $500, but managers must
approve anything over $500 or any order placed by a non-certified
intern."

 Decomposed Atomic Rule 1: "All chemical orders must be initiated

by a safety-certified user."

 Decomposed Atomic Rule 2: "Chemical orders with a total value

exceeding $500.00 require Manager approval."

4. Discovering and Documenting Business Rules

Discovery Techniques

 Document Analysis: Reviewing policy manuals, government

regulations, and industry standards (e.g., OSHA).

 SME Interviews: Extracting "tribal knowledge" from Subject Matter

Experts.

 Reverse Engineering: Examining legacy code to find logic that was

never formally written down.

Architect's Warning: Beware the "Oral Tradition." Many business rules exist
only in the heads of senior employees. The BA's job is to codify this tribal
knowledge into a "Business Rules Catalog" to prevent project failure when
key staff depart.

Documentation Standards: The Business Rules Catalog

A BA should use a centralized catalog to track rules across the enterprise.

Rule
Definition Type Source
ID

Every container is assigned a unique Inventory Policy

BR-10 Fact
Barcode. v1.2

Containers must be stored in ventilated Constrai

BR-11 Safety Manual
lockers. nt

Inferenc OSHA Standard

BR-12 Flashpoint < 100°F = Flammable.
e 1910

5. Business Rules and Software Requirements

Business rules are the "parents" of functional requirements. A single rule
often has a "one-to-many" relationship with project deliverables.

The Relationship Model (One-to-Many Influence)

--> [Functional Requirement A]

| (The validation logic)

[Business Rule] ------------------> [Quality Attribute: Security]

(The Policy/Origin) | (The access level required)

--> [Constraint]

(The design restriction)

Example:

--> [FR: System checks user cert status]

[Rule: Only certified pilots] --|

--> [QA: High Availability of DB]

Software Enforcement Methods

1. Input Validation: Blocking data entry that violates a rule (e.g.,

preventing an order if a user's certification has expired).

2. Automated Triggers: Performing an action when a condition is met

(e.g., generating a re-order request when stock falls below a
threshold).

3. Report Filtering: Restricting data visibility to comply with security

rules (e.g., masking the location of sensitive chemicals for non-security
staff).

6. Practical Applications and Synthesis

"Playing by the rules" reduces project risk by ensuring that technical delivery
is perfectly aligned with business governance. Without documented rules,
developers are forced to guess, leading to "gold plating" or functionality that
creates legal or safety risks.
Final Practical Scenario: Chemical Tracking System (CTS)

During a compliance audit prep, the BA identifies the following logic:

 Fact: Every chemical container has a relationship to a specific Lab

Room.

 Constraint: A single Lab Room cannot exceed a total volume of 50

liters of "Class 1 Flammables."

 Action Enabler: If a container's volume is updated and exceeds the

room limit, then the system must alert the Safety Officer.

 Inference: If a container has not been moved in 18 months, it is

classified as "Abandoned Asset."

 Computation: The "Disposal Cost" is calculated as: (Volume *

Hazard_Multiplier) + Base_Processing_Fee.

Study Report: Chapter 10 — Documenting the

Requirements
1. Thematic Analysis of Chapter 10

Chapter 10 focuses on the Specification subdiscipline of requirements

development. As illustrated in Figure 1-5, this phase represents the critical
transition point where Requirements Development activities provide the
baseline necessary for Requirements Management to begin. Transitioning
from an "oral tradition"—where requirements are vulnerable to the fallibility
of memory and scattered notes—to a persistent, well-organized, and
shareable form is mandatory for project success. A robust specification
prevents the friction inherent in miscommunicated assumptions and ensures
that the interests of all stakeholders intersect at a clear, common
understanding rather than a "mind-reading" exercise.

2. Core Concept: The Software Requirements Specification (SRS)

The Software Requirements Specification (SRS) is the primary deliverable of

the specification process, serving as the central repository of truth for what
the team intends to construct.
The 3 Define Rule

 Child (Analogy): An SRS is like a recipe for a birthday cake or the

instruction manual for a big box of Lego bricks. It tells you exactly what
pieces you need and how they should work together so the end result
looks just like the picture on the box.

 Undergrad: The SRS is a formal repository that houses both functional

requirements (the system's behaviors) and non-functional
requirements (the system's qualities), as defined in Chapter 1. It acts
as the definitive source for the project’s technical goals.

 Professional: Per the industry-standard ISO/IEC/IEEE 2011(E), the

SRS is a comprehensive document describing the expected behavior of
a software system. It is the foundation for development, testing, and
project management. Crucially, a professional SRS describes behavior
as fully as necessary to allow construction to proceed at an
acceptable level of risk, without falling into the fallacy of "100%
completeness" before development begins.

Definition of Specification "Specification involves representing and storing

the collected requirements knowledge in a persistent and well-organized
fashion. The principal activity is translating the collected user needs into
written requirements and diagrams suitable for comprehension, review, and
use by their intended audiences." — Source: Figure 1-4 and Chapter 1 text.

3. Labeling Requirements for Persistence and Tracing

To ensure requirements exist in a "shareable form," every individual

requirement is mandated to have a unique and persistent label. This is not
merely an administrative task; it is the prerequisite for Requirements
Management (Chapter 27). Unique labeling enables the tracking of
requirement status throughout the lifecycle and provides the necessary
hooks for traceability matrices.

Practical Example: A functional requirement for a flight check-in system

follows a structured naming convention: [PRINT.BOARDING_PASS.01]

 PRINT: Represents the high-level system feature.

 BOARDING_PASS: Identifies the specific functional area or user task.

 01: A unique sequence number used for status tracking and cross-
referencing.
4. Dealing with Incompleteness (The TBD Protocol)

Requirements are rarely static or complete upon the first draft. The "To Be
Determined" (TBD) marker is a formal protocol for managing gaps and
identifying technical risks.

The 3 Define Rule

 Child: A TBD is like a "place-holder" card in a game that says, "We will
decide what this card does later once we know the rules better."

 Undergrad: A TBD is a marker used to flag areas where additional

exploration or information is needed before the requirement can be
finalized.

 Professional: The TBD protocol is a risk-management tool. It prevents

developers from "guessing" the intent of a fuzzy requirement, which
invariably leads to expensive rework. It serves as a marker for pending
stakeholder decisions.

Why TBDs Occur Recommended Action

Waiting for a stakeholder or customer Assign a specific owner to resolve the

decision. issue.

Technical feasibility is currently

Set a target date for resolution.
unknown.

External interface details are missing Document the nature of the missing
from a third party. information.

Evading difficult Escalate to the project sponsor to

decisions/Accountability. prevent schedule slippage.

5. User Interfaces (UI) and the SRS

The SRS is mandated to maintain a strict separation between user

requirements (tasks) and functional requirements (behaviors). While UI
designs are valuable, the SRS focuses on the logical behavior that the UI
elements must facilitate. In accordance with Figure 1-2, a single Feature
often maps to multiple User Requirements, which in turn map to specific
Functional Requirements.

Mapping Hierarchy from Feature to UI: Feature: Flight Check-In | -->

User Requirement (Use Case: Check in for Flight) | --> Functional
Requirement (System shall print boarding pass) | --> UI Element (A "Print"
button on the Kiosk screen)

6. The Software Requirements Specification Template

A standard SRS must be organized according to the following components

(adapted from the Wiegers/Beatty template):

1. Introduction: Define the system's purpose and its intended audience.

2. Overall Description: Describe the high-level context, user classes,

and operating environment.

3. System Features: Detail the functional requirements organized by

feature or stimulus.

4. Data Requirements: Detail the logical data model and data

transformation logic.

5. External Interface Requirements: Describe connections to users,

hardware, and other software systems.

6. Quality Attributes: Detail the "–ilities," such as performance, safety,

and availability.

7. Internationalization and localization requirements: Specify

requirements for different cultures, languages, and cultural
conventions.

8. [Other Requirements]: Address any unique constraints, such as

legal or database requirements, not covered elsewhere.

 Appendices: Include a Glossary of terms and relevant Analysis Models

(diagrams).

7. Requirements Specification on Agile Projects

Agile projects require a "shareable form" to manage the "Backlog," although

the documentation is handled iteratively.

The 3 Define Rule for "Backlog"

 Child: It is a "To-Do" list for building a treehouse. You write down all
the things you want, like a ladder, and pick the most important ones to
do first.
  Undergrad: The backlog is a prioritized repository of user stories,
features, and epics that represent the pending work for future
iterations.

 Professional: Grounded in requirements management, the backlog is

the primary tool used to adjust scope for a certain iteration. As
cited in Chapter 20, it houses epics, user stories, and features, allowing
the team to maintain a list of pending work that is refined "just-in-
time."

Comparison of Specification Approaches:

Feature Traditional SRS Agile Specification

Comprehensive and up-

Timing Iterative and "just-in-time."
front.

Level of High; detailed "shall" Low initially; refined during iteration

Detail statements. planning.

Primary
Functional requirements. Epics, user stories, and features.
Unit

Formal change control Expectations of change built into

Change
process. the backlog.

8. Practical Application: From Theory to Practice

Next Steps Checklist (Adapted from p. 24):

 [ ] Write down requirements-related problems that you have

encountered on your current or previous project.

 [ ] Identify each as a requirements development or requirements

management problem.

 [ ] Map the requirements terminology and deliverables used in your

organization to those shown in this chapter.

 [ ] Perform a simple assessment on just a few pages of one of your

requirements documents to see where your team might have some
clear improvement areas.

 [ ] Arrange a training class on software requirements for your entire

project team to establish a common vocabulary.
Warning: Gold Plating Gold plating occurs when a developer adds
functionality that was not in the requirements specification (often because
they believe the "users will love it"). Because this functionality is out of
scope, the time spent is wasted effort that violates project boundaries.
Always trace functionality back to its origin and business justification.

Study Report: Software Requirements -

Chapter 11: Writing Excellent Requirements
1. Foundations of Requirements Quality

In my experience as a consultant, I have found that project failure rarely

stems from technical incompetence; it stems from a lack of clarity regarding
what is being built. To establish a baseline for quality, we must look to the
rigorous definitions provided in the industry-standard Table 1-1:

 Business Requirement: A high-level objective of the organization or

customer.

 User Requirement: A goal or task that specific user classes must be

able to perform.

 Functional Requirement: A description of a behavior the system

exhibits under specific conditions.

 Business Rule: A policy or regulation that defines or constrains the

business. While not a requirement itself, it is frequently the origin of
one.

The "3 Define Rule": Functional Requirement

To ensure every stakeholder understands the core of our work, we define a

Functional Requirement across three levels of complexity:

 For a Child: It’s like the instructions for a toy. If you push the blue
button, the toy must make a "beep" sound. It tells you exactly what
happens when you do something.

 For an Undergrad: A functional requirement is a technical

specification of system behavior. It defines the outputs the system
must produce in response to specific inputs and the state transitions
that occur under defined conditions.
  For a Professional: A functional requirement is a formal statement,
traditionally using the "shall" convention, documented in the Software
Requirements Specification (SRS). It describes a specific behavior that
developers must implement to satisfy a user requirement and,
ultimately, a business objective.

The Requirements Hierarchy (Figure 1-1)

Industry experience shows that requirements do not exist in a vacuum. The

following diagram illustrates the critical relationships, specifically how
Business Rules influence every level of the requirements chain:

[ Business Rules ] <----------------------------.

: :

: (influence) :

v :

[ Business Requirements ] :

(Vision & Scope Document) : (influence)

| :

v :

[ User Requirements ] <..........................:

(User Requirements Document) :

| :

v :

[ Functional Requirements ] <........................:

| (influence) :

| :

+---> [ Quality Attributes ] <............'

|---> [ External Interfaces ]

'---> [ Constraints ]

(Software Requirements Specification)

2. Characteristics of Excellent Requirements

As a Senior BA, I evaluate requirements based on two distinct levels: the

individual statement and the total collection.

Essential Traits of a Single Requirement Statement

 Complete / Correct: Accurately represents the stakeholder need with

all necessary info.

 Feasible: Can be implemented within known constraints. Consultant’s

Note: This is often the primary point of friction between BAs and
Developers; early technical vetting is essential.

 Necessary / Prioritized: Only includes what is required for value or

compliance.

 Unambiguous / Verifiable: Has only one interpretation and can be

proven through testing.

Essential Traits of a Requirements Collection

 Complete: No required functionality is missing.

 Consistent: No two requirements conflict (e.g., different response

times for the same action).

 Modifiable: The collection is structured so that changes can be made

without introducing inconsistencies.

 Traceable: Each requirement can be linked back to its source and

forward to its implementation.

The "3 Define Rule": Requirements Baseline

A Requirements Baseline is a pivotal milestone in any project lifecycle:

 For a Child: It’s like a "finalized list" of rules for a game. Everyone
agrees on the list, and if you want to change a rule later, you have to
get everyone to agree again.

 For an Undergrad: It is a version-controlled snapshot of the

requirements that has been formally agreed upon. It serves as the
"source of truth" for a specific release.

 For a Professional: The baseline marks the formal transition from

requirements development to requirements management. It is the
 "reviewed and approved" set of requirements that provides the stable
foundation for change control.

3. Guidelines for Writing: Perspective and Style

A critical success factor is distinguishing between what the user wants to

achieve and how the system must behave to allow it.

User Perspective (User

System Perspective (Functional Requirements)
Requirements)

Focus: Goals, tasks, and

Focus: System behavior and responses.
usage scenarios.

Example: "I want to find a Example: "The system shall return a list of
chemical in the inventory." chemicals matching the user's search criteria."

Writing Style Good Practices

We recommend the following checklist for all SRS documentation:

 [ ] Active Voice: Use "The system shall..." rather than "It would be
desired that..."

 [ ] Clarity: Use short, direct sentences.

 [ ] Glossary Adherence: Use only standard terminology.

 [ ] Avoid Subjective Terms: Remove vague words such as easy,

intuitive, fast, user-friendly, or robust. These are not verifiable.

 [ ] The "Shall" Convention: All functional requirements must use

"shall" to denote a binding commitment.

4. Precision: Avoiding Ambiguity and Incompleteness

Identifying Ambiguity

Ambiguity occurs when a requirement is open to multiple interpretations.

This is the "hidden killer" of budgets, as it shifts the decision-making from
the analyst to the developer.

The "3 Define Rule": Requirement Ambiguity

 For a Child: It’s like being told to "clean your room soon." You might
think that means "before bed," but your parents might mean "right
now."
  For an Undergrad: It is linguistic uncertainty in technical
documentation where the phrasing allows for multiple valid but
different logical interpretations.

 For a Professional: It is the risk of "interpretation burden," where the

lack of clarity shifts the design burden to the developer. This leads to
wasted effort and incorrect implementations that often only surface
during late-stage testing, where rework costs are highest.

Strategies for Incompleteness

To manage what we don't yet know, we recommend:

 Logic Analysis: Specifically looking for "else" conditions in every "if"

statement.

 TBD (To Be Determined) Markers: Use these as a formal strategy to

manage known incompleteness. Never leave a gap blank; mark it TBD
to ensure it is tracked and resolved.

5. Practical Applications and Visual Representation

Feature to Requirement Decomposition (Figure 1-2)

A Feature Tree helps visualize scope. Below is an expanded decomposition of

a Web Browser.

[ Web Browser ]

├── [ Bookmarks ]

│ ├── Add a Bookmark

│ ├── Export Bookmarks

│ ├── Go to Bookmarked Location

│ └── Edit Bookmarks

│ └── Functional Req: The system shall display bookmark properties.

├── [ Cookies ]

├── [ Tabs ]

└── [ Add-Ins ]

Chemical Tracking System: Quality Improvement

  Before (Poor): "The system should be fast when a chemist searches
for a chemical and should show all the info they need."

 After (Excellent): "The system shall display the search results for a
chemical query within 2 seconds of the user clicking the 'Search'
button. Each result shall include the chemical name, its current
laboratory location, and the remaining volume."

The Business Analyst Role

The BA acts as the "bridge" between stakeholders and the technical team.
Per Figure 1-3, the BA eicits requirements from user representatives in
corporate settings, while in commercial product development, they often
partner with or perform the role of a Product Manager to define the
market-driven feature set.

6. Conclusion and Next Steps

The impact of "Excellent Requirements" cannot be overstated. Industry data

shows that rework consumes 30–50% of total development costs. More
importantly, requirements errors account for 70–85% of those rework
costs. Investing in writing quality is not a delay; it is a primary risk-
mitigation strategy.

Next Steps for the Project Team

To improve writing quality immediately, we recommend the following actions

derived from the source's best practices:

1. Analyze Past Issues: Document requirements-related problems from

previous projects to identify root causes.

2. Assess Current Assets: Perform a formal assessment on a sample of

current requirements to identify clear improvement areas.

3. Arrange a Training Class: Provide the entire project team (including

customers and testers) with a shared vocabulary and understanding of
requirements engineering.

Study Report: Chapter 12 — A Picture Is Worth

1024 Words
1. Introduction: The Power of Visual Analysis
In the discipline of Requirements Engineering, the transition from the "Voice
of the Customer" to "Analysis Models" represents a critical evolution from
raw elicitation to structured understanding. While natural language is the
traditional vehicle for requirements, large blocks of text are prone to
semantic ambiguity and overlook logical gaps. Visual models serve as
superior containers for knowledge, functioning as a primary mechanism for
risk reduction. By representing requirements through various logical lenses,
we identify what is missing or incorrect long before a single line of code is
written, ensuring a holistic shared understanding across all stakeholders.

Textual vs. Visual Requirements

Attribute Textual Description Visual Representation

High risk of ambiguity; relies

Uses standardized notations
on individual reader
Clarity (UML/DFD symbols) to enforce a
interpretation of natural
precise, singular interpretation.
language.

Risk Difficult to spot missing logic Efficiently highlights missing data

Detectio or conflicting statements flows, disconnected states, and
n across dense paragraphs. "black holes" in logic.

High; requires the brain to Low; provides an immediate

Cognitiv
synthesize linear text into a architectural view of system
e Load
mental model. behavior and data movement.

2. The Fundamental Principle: Modeling Requirements

Modeling requirements is the process of creating structured abstractions that

define system needs while filtering out implementation-level "noise."

 Level 1 (Child): It is like drawing a map of a playground before you

build it, showing exactly where the swings and slides go so no one gets
confused.

 Level 2 (Undergrad): It is a structured abstraction of system

behavior used to organize requirements knowledge into formats that
are easier to analyze and validate than plain text.

 Level 3 (Professional):

Requirements modeling is the strategic application of standardized notations

to represent functional requirements and system constraints. This process
facilitates logical decomposition, manages cognitive load by isolating specific
system facets, and defines an interface contract that reduces architectural
risk.

3. Data Flow Diagrams (DFD)

Data Flow Diagrams (DFDs) are essential for identifying the boundaries of a
system and the transformation of data as it moves between processes and
entities.

 Child Definition: A picture showing how a letter travels from your

house to the post office and eventually to your friend's front door.

 Undergrad Definition: A diagram that identifies the processes, data

stores, and external entities involved in a system and how information
flows between them.

 Professional Definition: A modeling technique used to define system

scope by representing functional decomposition and the
transformation of data through various logical processes and persistent
stores.

Visual Representation: DFD (Chemical Tracking System)

[Chemist] --(Chemical Request)--> (1.1 Validate Request) --(Valid Data)-->

[Inventory DB]

+ --(Safety Info)--> [Health & Safety Dept]

Practical Application: Finding Missing Requirements

In the Chemical Tracking System, a DFD reveals hidden requirements by

identifying:

1. Process Gaps: A "Disposal" process that lacks a data flow to the

Health and Safety Department external entity for regulatory
reporting.

2. Missing Entities: A flow of "Shipment Data" appearing from nowhere,

indicating that the Vendor was overlooked as a critical external entity.

3. Black Holes: Identifying an "Inventory Update" process that receives

data from the Stockroom but never produces an output, indicating a
missing functional requirement for confirmation or logging.

4. Swimlane Diagrams
Swimlane diagrams clarify process ownership by partitioning activities into
lanes representing specific actors or system components.

 Child Definition: A chart that shows who is in charge of each part of a

race, like who starts the timer and who runs the different laps.

 Undergrad Definition: A process flow diagram partitioned into

"lanes" to show the handover of tasks between different stakeholders
or system modules.

 Professional Definition: A diagrammatic representation of a

business workflow that maps activities to specific roles or functional
areas to identify hand-off points—the primary locations where
requirements failure and communication breakdowns occur.

Visual Representation: Process Responsibility Mapping

Chemist Stockroom Clerk Database / System

Requests Chemical

Validates Container Availability

Delivers
Container

Updates Container Status to

'Received'

Practical Application

Swimlane diagrams are high-leverage tools for identifying "Overlooked

Stakeholders." If a process requires a lane for a "Compliance Auditor" to
approve a hazardous material request, but that role was never identified in
the Chapter 1 stakeholder analysis, the diagram makes the omission
undeniable.

5. State-Transition Diagrams (STD) and State Tables

These models elaborate on the logic of systems that change behavior based
on their current status and the events that trigger transitions.

 Child Definition: A drawing of a traffic light showing it goes from

Green to Yellow to Red, and explaining what makes it change.
  Undergrad Definition: A model showing the different life cycles an
object goes through and the specific events that trigger changes
between those cycles.

 Professional Definition: A formal representation of a finite-state

machine that defines mutually exclusive states and the triggers that
initiate transitions, used to prevent "state-space explosion" where a
system enters an undefined or illegal condition.

Visual Representation: State Transition Flow

[Ordered] --Container Arrives--> [Received] --Emptied--> [Empty] --Dispose--

> [Disposed]

Practical Application: Chemical Tracking System (CTS)

In the CTS, a container cannot be "Disposed" unless it has first passed

through the "Empty" state. If the requirements allow a container to move
directly from "Received" to "Disposed," the STD highlights this logical error,
preventing chemists from "losing" full containers in the system.

6. Dialog Maps

Dialog maps represent the architecture of the user interface, mapping the
navigation paths between different displays.

 Child Definition: A map that shows you which buttons to press to get
from the main screen of a game to the high-score list.

 Undergrad Definition: A high-level representation of the user

interface that shows the paths a user can take to navigate through an
application.

 Professional Definition: An abstraction of the user interface

architecture that maps user navigation and system responses to
ensure a deterministic and efficient user experience.

Visual Representation: Multi-Screen Navigation Flow

[Login Screen]

[Main Menu] -----------------+

| |

[Request Chemical] -> [View MSDS] -> [Dispose Container]

Practical Application

By sticking to essential user tasks, a dialog map prevents "Gold Plating." If

a developer suggests an "Attractive Search History" screen that does not
support a core task in the navigation map, it is easily identified as an out-of-
scope feature that adds cost without business value.

7. Decision Tables and Decision Trees

These models document complex business logic and "Business Rules"

(Chapter 9 taxonomy) to ensure all combinations of conditions are
addressed.

 Child Definition: A list of "If... Then..." rules, like "If it is raining, then
stay inside; if it is sunny, then go out."

 Undergrad Definition: Tools for representing complex logic with

multiple variables to ensure all possible combinations of conditions and
system actions are covered.

 Professional Definition: A compact, tabular representation of

combinatorial logic used to define how business rules determine
deterministic system actions based on an exhaustive set of conditions.

Visual Representation: Decision Table (Personnel System)

Condition Rule 1 Rule 2 Rule 3 Rule 4

Marital Status Changed? Yes No Yes No

Legal Name Change Requested? No Yes Yes No

Action: Allow Name Change X X X

Practical Application

The "Sparkle Starlight" scenario from the Personnel System demonstrates

why these are vital. The original system only allowed a name change if
marital status changed (Rule 1). A decision table would have revealed Rule 2:
a legal name change is valid even if marital status remains "No"
(unchanged).

 Decision Trees: Best for sequential logic and visual branching.

 Decision Tables: Best for combinatorial logic where multiple

conditions interact.
8. Event-Response Tables

This format bridges the gap between external triggers and the behavior the
system must exhibit to satisfy requirements.

 Child Definition: A list of what happens when you push different

buttons, like "If you ring the doorbell, the bell chimes."

 Undergrad Definition: A table that connects external, time-based, or

state-based triggers to the required system response and the resulting
state.

 Professional Definition: Descriptions of behaviors the system will

exhibit under specific conditions, used to ensure all functional
requirements are derived from valid business triggers.

Visual Representation: Event-Response Mapping

Event System Response Resulting State

Chemist requests Check inventory; Notify

Request Pending
container Stockroom

Container
Stockroom fulfills order Log assignment; Notify Chemist
Assigned

Practical Application

Event-response tables are the foundation for Functional Requirements.

They ensure every "shall" statement in the SRS is tied to a specific trigger,
preventing the implementation of "orphan" functionality that lacks a
business justification.

9. Strategic Implementation: Modeling on Agile Projects

In Agile, the philosophy is "just enough" modeling to facilitate

communication without creating a documentation bottleneck.

1. Model to Manage the Backlog: Use high-level models like feature

trees to organize user stories and prioritize the next iteration.

2. Transient vs. Persistent Modeling: Agile models are often transient

(whiteboard sketches used for immediate "shared understanding").
They only become persistent (formal documentation) if the knowledge
must be preserved for long-term maintenance or regulatory
compliance.
 3. Risk-Based Effort: Spend more time modeling the complex "back-
end" logic (like chemical disposal rules) and less time on "well-
understood" UI elements.

10. Conclusion and Final Reminder

Visual models are not merely "pretty pictures"—they are essential containers
for requirements knowledge. They provide the clarity needed to transition
from vague user input to a precise system design that is resistant to logical
failure.

The ultimate goal of requirements modeling is to reach a shared

understanding that is good enough to proceed with design and
construction at an acceptable level of risk.