Certified BA

Analysis, Design, and Project Management

Business Requirement Validation

Traceability

Requirements traceability refers to the “ability to follow the life of a requirement, in both forwards and backwards direction, i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases.” (SWEBOK, IEEE)

Truth Table Verified (Metrics) Unverified (No metrics)
KNOWN
Traceable; justifiable; documented; purpose		 Requirement:
Truth, factual, reality		 Opportunity:
Hope, possibility, prospect
UNKNOWN
Requirements w/o business case or problem statements; functions w/o requirements; undocumented; no purpose		 Out of scope:
Tenuous, conjecture, irrelevant		 Risk:
Fiction, chance, gamble
Truth Table

Tracing requirements involves documenting contextual links between the various requirements and between the work products developed to implement and verify the requirements.

The requirements may include business, user, functional and test requirements. The work products include requirements documents, design specifications, software code, test plans, test cases, and other artifacts of the development process.

Completing the picture by tracing customer requirements through development and testing verifies that the customer requirements are implemented and tested.

A requirements traceability matrix can simplify the process. It serves as a graphical representation of traceable relationships between requirements and work products.

With a traceability matrix, IT teams can easily track customer requirements through the software development cycle, diminishing the risk of missing stated or derived requirements, especially when developing large, complex systems.

To be consistent, the business requirements specification should be accurate, complete and clear. Below is a simple checklist which represents the attributes of a quality, standard business requirements specification.

Accuracy
Are the requirements consistent – not contradicting other requirements?
Are any requirements in conflict with given stated assumptions or constraints (business environment, technical environment, cost, schedule, and resources)?
Do the requirements support the stated business, system and project objectives?
Are all activities and operations necessary? Are any identified requirements not required or out of scope?
Are all data requirements necessary; are any not required or out of scope?
Completeness
Are the goals and objectives of the system clearly and fully defined?
Have all events and conditions been handled?
Have all operations been specified? Are they sufficient to meet the stated system objectives?
Have all required definitions and rules for objects and data been defined?
Does the specification satisfy the level of detail required by the design team?
Have all undefined, unresolved, incomplete specifications been identified for resolution?
Compliance
Do the deliverables conform to organizational standards, meet organizational process objectives, and follow industry standards?
Information Model – Object Specifications
Have all objects been identified?
Have all data elements been identified?
Have all necessary relationships been defined?
Have all identified data elements been "used"? (at least created and read)
Have all data items and relationships been correctly and precisely defined?
Have all data items been accurately attributed to the correct objects (Normalization)?
Have redundant or derived data items and relationships been identified (and/or eliminated)?
Functional Model – Activity Specifications
Have all required activities been specified?
Have all operations been correctly and precisely defined?
Have all outcomes of each operation been specified?
Do all operations identify the events or conditions that trigger them?
Do all operations identify the operator (system or user)?
Do all operations use strong, unambiguous action verbs?
Are all specifications clear and unambiguous?
Is the data used in the operation clearly understood?
Do required operations use rules, formulas or conditions to qualify or define the processing of the operation?
Do all operations specify or clearly imply an outcome?