Page 288 - Software and Systems Requirements Engineering in Practice
P. 288
ç ç 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
LONG AS THE STORIES ARE REPRESENTATIVE AND UNAMBIGUOUS IN DEFINING
THE DESIRED FUNCTIONALITIES THEY CAN SERVE AS A SIMPLE PROTOTYPE
4RANSPARENCY
(IGH LEVEL AGREEMENT ON REQUIREMENTS MAY CONCEAL CONFLICTS AT THE
LOWER LEVELS OF A COMPLEX SYSTEM 7E CONCENTRATE ON UNCOVERING AND
VERIFYING THE DETAILS BY INCORPORATING THEM INTO THE PROTOTYPES AS
EARLY AS POSSIBLE $OMAIN EXPERTS NEED TO CLARIFY BOTH THE GENERAL
RULES AND THEIR EXCEPTIONS AS EARLY AS POSSIBLE 3OFTWARE OR SYSTEMS
ENGINEERS NEED TO PROVIDE GOOD VISIBILITY INTO THEIR ASSUMPTIONS
ABOUT THE IMPLEMENTATION AND THE ASSOCIATED CONSTRAINTS
4HERE ARE A FEW IMPORTANT ACTIVITIES THAT CONTRIBUTE TO ACHIEVING
SATISFACTORY TRANSPARENCY .O TIME SHOULD BE SPENT ON PREPARING A
SMOOTH PRESENTATION WITH A ROUGH PROTOTYPE RATHER IT IS MORE
IMPORTANT TO SHOWCASE THE MOST RECENT AND QUESTIONABLE ADDITIONS TO
THE PROTOTYPE !LSO THE PROTOTYPE SHOULD BE CREATED AROUND SCENARIOS
THAT ARE RELATIVELY COMPLEX IN ORDER TO BRING ANY POTENTIAL PROBLEMS
TO THE SURFACE 7E WANT TO AMPLIFY THE hDEMO EFFECTv THAT IS
hUNEXPECTED THINGS WILL HAPPEN v 4HIS IS SOMEWHAT OF A CHALLENGE TO
MANY DEVELOPERS WHO CONSIDER A SMOOTH PRESENTATION TO BE OF
INTRINSICALLY HIGHER VALUE )T SOMETIMES SHOWS EVEN IN AGILE PRODUCT
DEVELOPMENTS WHERE TEAMS DEVOTE SIGNIFICANT TIME TO PREPARING A
SMOOTH END OF ITERATION PRESENTATION USING WORKAROUNDS OR EVEN
CODE PATCHES TO ENSURE THAT ERRORS STAY HIDDEN )N PROTOTYPING THIS IS
STRICTLY COUNTERPRODUCTIVE AND SHOULD NOT BE DONE
!NOTHER IMPORTANT ASPECT OF TRANSPARENCY IS THE EXTRAPOLATION
OF THE UNDOCUMENTED REQUIREMENTS FROM THE DOCUMENTED ONES
!LL SIGNIFICANT PARTICIPANTS IN THE PROTOTYPING PROCESS SHOULD USE
THEIR OWN INTERPRETATIONS OF THE SYSTEM AS REPRESENTED BY THE
PROTOTYPE OR EXISTING REQUIREMENTS AND EXTRAPOLATE IT INDEPENDENTLY
TO DEFINE WHAT THEY SEE AS COMPLEX USER SCENARIOS "Y COMPARING THE
EXTRAPOLATIONS AND ASSUMPTIONS FROM MULTIPLE SOURCES ADDITIONAL
CONFLICTS ARE LIKELY TO BE UNCOVERED
4HE COMPLEXITY CARD GAME AS PRACTICED IN MANY AGILE
METHODOLOGIES ;3CHWABER ET AL = CAN SERVE AS A GOOD INTRODUCTORY
STEP FOR THE EXTRAPOLATION ACTIVITY 7HEN MULTIPLE STAKEHOLDERS ON THE
DEVELOPMENT SIDE MAKE WILDLY DIVERGENT COMPLEXITY AND EFFORT
ESTIMATES FOR SOME TASKS IT IS VERY LIKELY THAT THEY ARE BASING THEIR
ESTIMATES ON SIGNIFICANTLY DIFFERENT ASSUMPTIONS ABOUT THE SYSTEM
REQUIREMENTS 4HE OUTLIERS IN TERMS OF COMPLEXITY ESTIMATES ARE GOOD
CANDIDATES TO START THE PROCESS OF PRESENTING THEIR ASSUMPTIONS AND
THE DERIVED COMPLEXITY ISSUES
4ESTING
)N EARLY STAGES IT IS USEFUL TO PRACTICE TEST FIRST DEVELOPMENT ;"ECK
= ;3ANGWAN ET AL = )N ADDITION TO COMMENTING ON PREPARED
PROTOTYPES THE DOMAIN EXPERT CAN HELP THE DEVELOPERS CONSTRUCT A