Page 237 - Software and Systems Requirements Engineering in Practice

ç ç 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

ORGANIZATION TO CREATE A PRODUCT TO FULFILL A NEED DEFINED BY MARKETING
AND SALES ! TYPICAL SOMETIMES COSTLY MISTAKE ON PROJECTS IS TO WAIT
UNTIL THE ANALYSES ARE NEEDED BEFORE IMPLEMENTING A TRACE STRATEGY
'OAL "ASED 4RACEABILITY
'OAL BASED TRACEABILITY STARTS WITH BUSINESS GOALS OR OBJECTIVES AND
TRACES ARE THEN USED TO DETERMINE THAT THE BUSINESS OBJECTIVES HAVE BEEN
MET /N MANY OF THE PROJECTS THAT WE HAVE WORKED ON GOAL BASED TRACES
ARE SOMETIMES ABSENT (OWEVER WITHOUT THE TRACES IN PLACE BACK TO THE
ORIGINAL GOALS IT CAN BE VERY DIFFICULT ESPECIALLY FOR NONFUNCTIONAL
REQUIREMENTS TO MAKE THE NECESSARY TRADEOFFS WHEN PRIORITIZING
FEATURES 'OAL MODELING AS DESCRIBED IN #HAPTER HAS THE ADVANTAGE
OF IMPLICIT TRACING THAT IS WHEN RELATIONSHIPS ARE CREATED BETWEEN GOALS
AND SUBGOALS THE TRACES ARE IMPLICITLY DEFINED 0ROBLEMS MAY ARISE
BECAUSE DIFFERENT ORGANIZATIONS DEFINE BUSINESS GOALS PRODUCT FEATURES
AND DETAILED REQUIREMENTS &OR EXAMPLE A BUILDING ALARM SYSTEM HAS
THE LOW LEVEL REQUIREMENT THAT ALARMS SHALL HAVE THREE DIFFERENT BLINK
RATES 4HE DEVELOPER IMPLEMENTING THE REQUIREMENT DOES NOT
UNDERSTAND WHY THE REQUIREMENT IS THERE E G BLINK OR NO BLINK SHOULD
BE GOOD ENOUGH ESPECIALLY WITH MULTIPLE COLORS BUT GOING BACK TO THE
BUSINESS GOALS WE SEE THAT THE DIFFERENT BLINK RATES ARE NEEDED SO THAT THE
PRODUCT WILL SELL IN MARKETS WHERE SECURITY STAFF MAY BE COLOR BLIND

4YPES OF 4RACES
7E CAN GROUP TRACES INTO CATEGORIES AS DEFINED IN ;*ARKE = 4HESE
CATEGORIES INCLUDE

v &ORWARD FROM REQUIREMENTS !LLOCATION TO SYSTEM COMPONENTS
TO ESTABLISH ACCOUNTABILITY AND SUPPORT CHANGE IMPACT
v "ACKWARD TO REQUIREMENTS 6ERIFICATION OF SYSTEM
COMPLIANCE TO REQUIREMENTS AND AVOIDANCE OF GOLD PLATING
v &ORWARD TO REQUIREMENTS #HANGES IN STAKEHOLDER NEEDS OR
ASSUMPTIONS THAT MAY REQUIRE RADICAL REASSESSMENT OF
REQUIREMENTS RELEVANCE
v "ACKWARD FROM REQUIREMENTS #ONTRIBUTION STRUCTURES
CRUCIAL FOR VALIDATING REQUIREMENTS

4RACE TYPES ARE RELATED TO ANALYSIS THAT IS DERIVATION ANALYSIS
REQUIRES BACKWARD TRACING WHILE COVERAGE ANALYSIS AND IMPACT
ANALYSIS REQUIRE FORWARD TRACING
%XAMPLE %NGINEERING 0ROJECT "ASED 4RACEABILITY -ODEL
3TARTING POINTS FOR DEFINING A REQUIREMENTS TRACE STRATEGY ARE THE
CREATION OF A TRACEABILITY MODEL h6v MODEL AND THE CREATION OF A PROJECT
METAMODEL SEE #HAPTER 4HE h6v MODEL SEE &IGURE CAN BE USED
AS A GUIDE TO ASSIST IN DEFINING A TRACING STRATEGY !N ALTERNATIVE APPROACH