Page 272 - Software and Systems Requirements Engineering in Practice

ç
R
I
D
A
P
E
S
E
Q
U
P
T
H
A
ç
ç
4
N
T
E
N
I
C
H
V
E
$
E
L
M
E
O
P
ç ç # # H A P T E R ç ç ç 2 2 A P I D ç $ E V E L O P M E N T ç 4E C H N I Q U E S ç ç
REPRESENTATION IS THE MORE LIKELY IT IS TO HAVE INHERENT AMBIGUITIES
/N THE OTHER HAND INCREASING FORMALITY AND UNAMBIGUOUSNESS OF A
REPRESENTATION MAY LEAD TO INCREASED COMPLEXITY OF THE REPRESENTATION
!DDITIONAL EFFORT MAY BE NECESSARY TO PRECISELY DEFINE REQUIREMENTS
THAT AT LEAST SOME STAKEHOLDERS VIEW AS OBVIOUS )N GENERAL
STAKEHOLDERS WHO REPRESENT THE END USERS TEND TO PREFER TO WORK MORE
AT THE INFORMAL PROSE END OF THE COMMUNICATIONS SPECTRUM WHILE
ENGINEERS IN MANY DOMAINS TEND TO USE MORE FORMAL AUTOMATABLE
REPRESENTATIONS .EITHER SIDE IS PARTICULARLY ADEPT AT TRANSLATING
BETWEEN THESE REPRESENTATIONS WITHOUT SOME LOSS OF INFORMATION
5SING FORMAL REQUIREMENTS MODELING IN COMBINATION WITH STAKEHOLDER
TRAINING IN MODELING COULD ADDRESS THESE ISSUES BUT IT MAY NOT
BE PRACTICAL BECAUSE OF POTENTIALLY ADDITIONAL LEARNING CURVE COSTS
AS WELL AS POSSIBLE RESISTANCE FROM STAKEHOLDERS !NOTHER DIFFICULTY
WITH MODELING IS THAT THE CURRENT STATE OF MODELING TOOLS IS RELATIVELY
POOR I E THE DIFFICULTY OF USING THE TOOLS SOMETIMES DEFEATS THE
COMMUNICATION INTENT OF THE MODELS
0ROTOTYPES HAVE THE POTENTIAL OF BEING MORE EASILY COMPREHENSIBLE
BOTH TO STAKEHOLDERS AND DEVELOPERS WITHOUT MUCH SPECIAL TRAINING
7E HAVE FOUND THAT RAPID PROTOTYPING ALLOWS US TO QUICKLY MAKE
REPRESENTATIONS OF THE TARGET SYSTEM THAT HELP MINIMIZE OR REMOVE
AMBIGUITY FROM THE REQUIREMENTS ANALYSIS PROCESS 4HUS PROTOTYPES
CAN HELP ADDRESS THE COMPLEXITY THAT IS CAUSED BY UNCERTAIN
REQUIREMENTS AND BY DIFFERING STAKEHOLDER VIEWS
7E IDENTIFY THE SITUATIONS WHERE PROTOTYPING CAN BE EFFECTIVE IN
SHORTENING THE TIME IT TAKES TO IMPROVE THE COMMON UNDERSTANDING
BETWEEN THE STAKEHOLDERS AND IN UNCOVERING THE INCOMPLETENESS OF
THE REQUIREMENTS WITH RESPECT TO THE TARGET BUSINESS DOMAIN
0ROTOTYPING MAY ALSO BE USED DURING EARLY PHASES OF PRODUCT
DEVELOPMENT FOR EXAMPLE BY BUILDING A VERTICAL SLICE OF THE
ARCHITECTURE TO CHECK FOR POTENTIAL PERFORMANCE PROBLEMS ;0AULISH
= 0ROTOTYPING MUST BE RAPID IN THAT THE PROTOTYPES SHOULD BE
FREQUENTLY AVAILABLE EARLY IN THE DEVELOPMENT PROCESS AND BE EASILY
MODIFIED AS STAKEHOLDERS PROVIDE FEEDBACK
&OR PROTOTYPING TO BE RAPID PROTOTYPE DEVELOPERS OF SOFTWARE
PRODUCTS OFTEN DO NOT CONSIDER REUSE )N SUCH CASES THE PROTOTYPE CAN
BE VIEWED AS hTHROWAWAY CODEv AND WOULD NOT BECOME PART OF THE
PRODUCT DEVELOPMENT -ANAGERS THAT ENCOURAGE CODE REUSE WILL OFTEN
REQUIRE THAT THE PROTOTYPES HAVE THE POSSIBILITY OF BECOMING THE
SHIPPED PRODUCT 4HIS IS DIFFICULT TO ACHIEVE IN AN ENVIRONMENT WHERE
PRODUCT REQUIREMENTS ARE CONTINUOUSLY AND QUICKLY CHANGING &ROM
OUR EXPERIENCE WE ENCOURAGE THE USE OF SOME OF THE ANTICIPATED
PRODUCT DEVELOPMENT TOOLS TO DEVELOP THE PROTOTYPES 4HIS ENCOURAGES
THE SOFTWARE OR SYSTEMS ENGINEERS TO LEARN THE NEW TOOLS EARLY IN THE
DEVELOPMENT LIFE CYCLE ENSURING EFFECTIVENESS IN THE TARGET
TECHNOLOGIES WHEN PRODUCT DEVELOPMENT BEGINS