Page 283 - Software and Systems Requirements Engineering in Practice

A
ç

P
ç
$
I
D
#
H
E
S
A
E
R
P
T
E
C
ç
4
H
Q
U
N
I
T
E
L
E
V
O
E
N
P
M
ç ç # 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 ç ç
SIMILARITY TO THE WORK DONE IN AN AGILE DEVELOPMENT PROJECT WITH THE
NOTABLE DIFFERENCE THAT OUR PROCESS GENERALLY DOES NOT TRY TO PRODUCE
A FINISHED PRODUCT AND THUS IT CAN ITERATE VERY QUICKLY AS SOON AS THE
FEATURE MODIFICATIONS ARE COMPLETE ;3CHWABER ET AL =
7E HAVE HAD SUCCESS ON PROJECTS WHERE PROTOTYPE REVIEW AND
ELICITATION SESSIONS WERE STRICTLY AND PERIODICALLY SCHEDULED AND ALSO
ON PROJECTS WHERE THERE WAS NO A PRIORI SCHEDULE FOR THE REQUIREMENTS
REVIEW SESSIONS 5PDATES ON THE PROTOTYPE S REPRESENTATION OF
REQUIREMENTS CAN USUALLY BE DONE VERY QUICKLY IN A DAY OR LESS IN MOST
CASES 4HE REVIEW SESSIONS CAN BE SCHEDULED ON DEMAND OR IN ADVANCE
WITH A SPECIFIC SCHEDULE )T IS IMPORTANT TO HAVE FREQUENT UPDATES AND
REVIEWS ;-ATOS = 7E RECOMMEND THAT EACH STAKEHOLDER INVOLVED
IN A SPECIFIC ASPECT OF A SYSTEM SHOULD BE INVOLVED IN A REVIEW SESSION
AT LEAST ONCE A WEEK DURING PROTOTYPE DEVELOPMENT
2EVIEWS CAN BE DONE ONE ON ONE WITH SPECIFIC STAKEHOLDERS OR
PREFERABLY WITH THE PARTICIPATION OF MULTIPLE STAKEHOLDERS IN ORDER
TO REDUCE THE DUPLICATION OF PRESENTATION EFFORT AND TO FOSTER
COMMUNICATION AMONG THE STAKEHOLDERS 4HE PRESENCE OF MULTIPLE
STAKEHOLDERS IS STRONGLY ENCOURAGED IN THE EARLY REVIEWS BECAUSE
THESE ARE AN OPPORTUNITY FOR UNCOVERING LARGE AND FUNDAMENTAL
DISCREPANCIES 4HE PROBABILITY OF DISCOVERING DISCREPANCIES ALSO GOES
DOWN WITH SUBSEQUENT ITERATIONS UNLESS NEW ASPECTS OR DETAILS ARE
BEING ADDED TO THE REQUIREMENTS REPRESENTATION
3UFFICIENT PROGRESS IN PROTOTYPING RELIES ON FEEDBACK OF DOMAIN
EXPERTS AND OTHER PRODUCT STAKEHOLDERS 4HEIR FEEDBACK ON THE
PROTOTYPE REVIEWS NEEDS TO BE INFORMATIVE TIMELY AND ACTIONABLE
4HE REVIEW COMMENTS SHOULD BE AS SPECIFIC AND DETAILED AS PRACTICAL
EXPLICITLY ACCEPTING OR REJECTING SPECIFIC PARTS OF THE PROTOTYPE
7HENEVER POSSIBLE THE RATIONALE FOR A GIVEN COMMENT SHOULD BE
GIVEN IN ORDER TO CAPTURE THE IMPLIED ASSUMPTIONS PARTICULARLY WHEN
SOME APPROACH IS REJECTED .ONCOMMITTAL EVALUATIONS SHOULD BE
AVOIDED WHENEVER POSSIBLE EVEN IF THE RIGHT CHOICE IS NOT CLEAR )N THIS
SITUATION CHOOSING TO GO FORWARD WITH PROTOTYPING MULTIPLE
APPROACHES IN PARALLEL MAY BE SUPERIOR TO SAYING THAT THE CURRENT
APPROACH hMAY BE OKAY v
%XPERIENCED DOMAIN EXPERTS WITH A BROAD UNDERSTANDING OF
THEIR MARKETS ENVIRONMENTS AND OTHER CRITICAL ASPECTS OF THE PRODUCT
CONTEXT ARE RARE AND THEY ARE UNLIKELY TO BE AVAILABLE FOR EXTENDED
PERIODS OF TIME IN THE EARLY STAGES OF PRODUCT PLANNING AND
DEVELOPMENT /UR APPROACH TO PROTOTYPING AS A MEANS OF ELICITING
REQUIREMENTS RELIES ON USING THE DOMAIN EXPERTS FEEDBACK FOR
EVOLVING THE UNDERSTANDING OF THE IMPORTANT REQUIREMENTS OF THE
PLANNED SYSTEM 7E EMPHASIZE MAXIMIZING THE VALUE OF THE FEEDBACK
COLLECTED DURING THE PERIODS WHEN THE DOMAIN EXPERTS ARE AVAILABLE
4HIS CAN BE DONE BY PRESENTING INTERMEDIATE RESULTS TO THE DOMAIN
EXPERTS AND THEN COLLECTING THEIR COMMENTS ON THE VALUE OF CERTAIN
FEATURE IMPLEMENTATIONS AND NECESSARY IMPROVEMENTS