Page 276 - Software and Systems Requirements Engineering in Practice

A
P

2
I
E
V
D
$

A
ç
H
#
P
R
ç
T
E
E
H
N
C
4
E
I
S
ç ç # H A P T E R ç ç ç 2 A P I D ç $ E V E L O P M E N T ç 4E C H N I Q U E S ç ç
E
Q
U
ç
L
O
P
M
T
N
E
0ROTOTYPES ENSURE THAT AT LEAST A PART OF THE SYSTEM REQUIREMENTS IS
DECOMPOSED VERY EARLY WITH RESPECT TO A CANDIDATE TECHNOLOGY AND
THAT THE STAKEHOLDERS CAN EVALUATE THESE ARTIFACTS AS THEY REFINE AND
NEGOTIATE THE MAJORITY OF SYSTEM REQUIREMENTS 3TAKEHOLDER AGREEMENT
ON PROTOTYPE VALIDITY PROVIDES A COMMON AREA OF INTERPRETATION FOR THE
HIGH LEVEL REQUIREMENTS STILL BEING ELABORATED
4IME TO -ARKET
!NY ACTIVITY THAT CAN BE ELIMINATED SHORTENED OR PERFORMED
CONCURRENTLY IS AN IMPORTANT SOURCE OF DEVELOPMENT PROCESS
IMPROVEMENTS )F REQUIREMENTS ENGINEERING ACTIVITIES TAKE A LONG
TIME AND THEY ARE USED AS A PRECONDITION FOR STARTING DEVELOPMENT
THE TIME TO MARKET MAY BE UNDESIRABLY LONG
%ARLY PHASES OF PROJECT INCEPTION SUFFER FROM A HIGH DEGREE OF
UNCERTAINTY BOTH ABOUT THE FEATURE SET AND ABOUT THE DETAILS OF HOW
THE SYSTEM WILL SATISFY THE REQUESTS OF STAKEHOLDERS )T IS NOT UNCOMMON
TO HAVE UNCERTAINTY EVEN ABOUT WHO THE STAKEHOLDERS ARE FOR A SPECIFIC
PROJECT SINCE AT THIS STAGE MANY INFRASTRUCTURE AND TECHNOLOGY ISSUES
ARE UNCONSTRAINED &OR EXAMPLE THE TYPE OF APPLICATIONS PLANNED FOR
A NEW PRODUCT DETERMINES WHETHER THE DATA CENTER SECURITY AND
0ROTOTYPINGõANDõ3IZE
$URING SOME PRIVATE COMMUNICATIONS WITH #APERS *ONES HE SUGGESTED
SOME INTERESTING GUIDELINES FOR PROTOTYPING DEPENDING ON THE SIZE OF
THE FUTURE PRODUCT &OR SMALL APPLICATIONS BELOW FUNCTION POINTS
THE ENTIRE PRODUCT CAN BE BUILT AS A DISPOSABLE PROTOTYPE TO TRY OUT
FEATURES SUCH AS INTERFACES AND ALGORITHMS $ISPOSABLE PROTOTYPES ARE
SAFER THAN EVOLUTIONARY PROTOTYPES DUE TO THE COMMON USE OF SHORTCUTS
AND SLOPPY METHODS 0ROTOTYPES ARE USUALLY ABOUT PERCENT OF THE
SIZE OF THE APPLICATIONS THEMSELVES SO PROTOTYPES ARE VERY USEFUL FOR
APPLICATIONS IN THE SIZE RANGE OF TO FUNCTION POINTS 4HIS IS
WHERE YOU ARE MOST LIKELY TO FIND hTIME BOXEDv PROTOTYPES DEVELOPED
IN A MONTH OR SO 7HEN APPLICATIONS REACH FUNCTION POINTS IT IS
DIFFICULT TO DO A PERCENT PROTOTYPE BECAUSE FUNCTION POINTS IS A
NONTRIVIAL APPLICATION IN ITS OWN RIGHT 4HEREFORE FOR THESE CASES
PROTOTYPES ARE USUALLY ONLY FOR INTERFACES OR A FEW KEY ALGORITHMS
7HEN APPLICATIONS REACH FUNCTION POINTS IT IS NOT FEASIBLE TO
BUILD A PERCENT PROTOTYPE SO THE BEST YOU GET ARE SMALL PROTOTYPES
FOR SPECIFIC TOPICS SUCH AS USER INTERFACES AND CRITICAL ALGORITHMS 4HUS
PROTOTYPES ARE USUALLY UNDER FUNCTION POINTS IN TOTAL SIZE NO MATTER
HOW BIG THE APPLICATION IS "ECAUSE THE DIFFICULTY OF CONSTRUCTING
MEANINGFUL PROTOTYPES INCREASES WITH APPLICATION SIZE THIS IS ONE OF
THE REASONS BIGGER APPLICATIONS TEND TO HAVE MORE REQUIREMENTS CREEP
AND WORSE QUALITY THAN SMALLER APPLICATIONS