Page 232 - Software and Systems Requirements Engineering in Practice
P. 232
ç ç 3 O F T W A R E ç ç 3 Y S T E M S ç 2 E Q U I R E M E N T S ç % N G I N E E R I N G ç ) N ç 0 R A C T I C E
$ERIVATION !NALYSIS
$ERIVATION ANALYSIS IS CONCERNED WITH DISCOVERING THE ORIGIN OR
RATIONALE OF A FUNCTION MODULE ETC 4HE RELEVANT DESIGNS ARE TRACED
BACK FIRST TO THE REQUIREMENTS AND THEN FROM THE REQUIREMENTS TO THE
STAKEHOLDERS REQUESTS OR MARKET DEMANDS OR BUSINESS GOALS THAT
LED TO THE DECISION TO ADD THE REQUIREMENT TO THE PRODUCT !LTERNATIVELY
A PRODUCT COMPONENT OR COMPONENT REQUIREMENT IS TRACED BACK TO THE
ORIGINAL RATIONALE FOR CREATING IT $ERIVATION IS NECESSARY TO UNDERSTAND
WHY A FEATURE OR FUNCTION IS IN A PRODUCT WITHOUT WHICH INTELLIGENT
DECISIONS REGARDING A CHANGE TO THE REQUIREMENT CANNOT BE MADE
#OVERAGE !NALYSIS
#OVERAGE ANALYSIS MEASURES THE RATIO OF DEFINED TO ACTUAL PRODUCT
FEATURES )T IS USED TO DETERMINE WHETHER THE REQUIREMENTS OR FEATURES
OF INTEREST HAVE BEEN IMPLEMENTED IN THE PRODUCT 4HIS IS ACCOMPLISHED
BY TRACING FROM THE ORIGINAL SYSTEM OR CONTRACT REQUIREMENTS DIRECTLY
TO TEST CASES .OTE THAT THE TESTS ARE THE BEST WAY TO MEASURE COMPLETION
OR COMPLIANCE AS DESIGNS MAY NOT HAVE BEEN IMPLEMENTED )F A
PRODUCT IS RELEASED TO THE MARKET WITHOUT THE FEATURES DEEMED AS
BEING IMPORTANT IT MAY FAIL )F THE PRODUCT IS BEING DELIVERED AS PART
OF A CONTRACT THEN COVERAGE ANALYSIS IS USED TO MEASURE CONTRACT
COMPLIANCE E G WHAT WAS AGREED ON VERSUS WHAT IS CURRENTLY BEING
DELIVERED 4HE ARCHITECT CAN ALSO USE COVERAGE ANALYSIS TO ASSIST WITH
AN IMPACT ANALYSIS THAT IS THE COST OF MAKING A CHANGE MAY BE LOWER
IF IMPLEMENTATION OF A PRODUCT FEATURE HAS NOT YET STARTED
2OUTINE 2EQUIREMENTS -ANAGEMENT !CTIVITIES
2OUTINE REQUIREMENTS MANAGEMENT ACTIVITIES ARE THOSE THAT TAKE PLACE
ON MOST IF NOT ALL PROJECTS 4HEY MAY NOT INVOLVE A LOT OF MANUAL
EFFORT BUT DEPENDING ON THE NATURE OF THE PROJECT THEY MAY BE CRUCIAL
TO A POSITIVE OUTCOME
)DENTIFYING 6OLATILE 2EQUIREMENTS
6OLATILITY IS USUALLY MEASURED BY GATHERING STATISTICS FROM A REQUIREMENTS
DATA MANAGEMENT SYSTEM 2$-3 /NE OF THE ADVANTAGES OF AN 2$-3
IS THAT WHENEVER A REQUIREMENT IS CHANGED VERSION MANAGEMENT IS
TRANSPARENT TO THE USER -OST IF NOT ALL 2$-3 PRODUCTS CAN PROVIDE
VOLATILITY REPORTS )F THEY DO NOT THEN IT IS USUALLY A SIMPLE MATTER TO
CREATE SUCH A REPORT 4WO METRICS ARE OF SPECIAL INTEREST THE VOLATILITY
OF THE OVERALL REQUIREMENT SET AND THE VOLATILITY OF INDIVIDUAL
REQUIREMENTS ! BASELINE TYPICALLY CANNOT BE ESTABLISHED UNTIL
AGGREGATE VOLATILITY NUMBER OF REQUIREMENTS CHANGING PER UNIT OF
TIME DROPS TO A SUFFICIENTLY LOW VALUE THAT THE REQUIREMENTS ARE
DEEMED STABLE 4HE POINT AT WHICH THAT OCCURS WILL BE DIFFERENT FOR
DIFFERENT TYPES OF PROJECTS +EEP IN MIND THAT A VOLATILITY METRIC IS
ONLY VALID WHERE ALL THE REQUIREMENTS ANALYZED ARE AT THE SAME LEVEL
E G HIGH LEVEL CUSTOMER REQUIREMENTS