Requirements Traceability: Functional / Non-Functional
Let’s First Define a Functional Requirement, a Non-Functional Requirement, and Traceability
In the world of software development, requirements are gathered from multiple sources including but not limited to: customer
feedback, product managers, competitive analysis, business executives, etc. Requirements which relate specifically to the product’s behavior based upon user interaction are called functional requirements. Functional requirements can be expanded to include non-functional requirements, quality criteria that are applied to a system in its entirety. Examples of non-functional requirements include but are not limited to: supportability, performance, corporate look and feel, stability, XYZ compliancy (where XYZ is any government or industry policy or instruction set), extensibility, etc., just to name a few.
Traceability is a method of linking each requirement, be it functional or non-functional, to corresponding test execution results and vice versa, proving that all coding needed to deliver the product as per the requirements specification has been successfully implemented. Traceability requirements, functional and non-functional, show you how well an end product meets its original specifications.
Example for Dealing with Functional and Non-Functional Requirements in Testing
World Widgets, working on its next major product release, includes the following in its requirements specification:
Requirements:
A323. An authorized user creates a new customer record with all required fields (as designated by red text) filled in and which, upon saving, will get a a non-modifiable unique customer id (functional requirement).
B323. All new releases must be modified to be 508 compliant (non-functional requirement).
A test team reviews the requirements and writes the following test case:
Test Name: Create new customer record.
Req. ID: A323 (traceability)
Design Steps:
Step 1: File - New - Customer Record
Expected Result: Customer Record dialog box appears (with id field blank)
Step 2: User enters information into required fields.
Expected Result: fields are populated with text.
Step 3: User clicks Save button
Expected Result: Dialog box displays a unique id
Expected Result: Status line appears saying record is saved
Expected Result: Dialog box Edit button becomes active
Expected Result: Verify 508 compliancy ==> this ‘check’ gets added to every test case (traceability)
Because 508 compliance is a set of criteria which can be adopted in whole or in part and is subject to some interpretation, this ‘check’ should link to a document or checklist which outlines the extent of the compliance. This saves the test case from numerous and repetitive checks being listed while still reminding the tester of the global requirement. In this case, the document might specify that the system cannot overwrite user-specified black and white style sheets as one of many of the checks adopted which can be confirmed.
How to Get Traceability and How it Benefits the Business
Traceability is a bidirectional process between stated requirements, both functional and non-functional, and the completeness of the product in meeting those requirements. By assigning each requirement with a unique identifier and associating corresponding design spec, functional spec, and test design efforts to that unique identifier, companies can assess test coverage and product readiness. A system using flat files like Word or Excel can be used to deliver the traceability matrix but over time quickly becomes outdated, unsychronized, and unwieldy.
Consider, instead, a commercial over-the-shelf software (COTS) solution such as IBM Requisite Pro (Req Pro) or HP Quality Center. Look for integrated modules for managing requirements writing and work flow, test planning, test execution, reporting, and even defect tracking for end-to-end traceability on product readiness that allows your company to proclaim with confidence “It’s soup. Ship it!”
Image Credit:
