Page 277 - 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

LICENSING STAFF ARE STAKEHOLDERS OR NOT SEE THE SECTION h3ELECTING
3IGNIFICANT 3TAKEHOLDERSv IN #HAPTER 4HE LENGTH OF THIS EARLY PHASE
TIME PERIOD WHERE THE RISKS ARE VERY HIGH AND GENERALLY
NONMEASURABLE DIRECTLY IMPACTS THE TOTAL DURATION OF THE PROJECT
-OST SOFTWARE AND SYSTEMS PROJECTS SUFFER FROM SOME
REQUIREMENTS RELATED PROBLEMS )N GENERAL THESE PROBLEMS MANIFEST
THEMSELVES IN DEVELOPMENT TESTING OR QUALITY ASSURANCE ACTIVITIES
AND THUS TEND TO CAUSE LARGE REWORK COSTS AND SCHEDULE DELAYS
/BVIOUSLY THE EARLIER THAT THESE REQUIREMENTS PROBLEMS ARE IDENTIFIED
THE BETTER CHANCE THE PROJECT TEAM HAS TO MITIGATE THE RISKS

õ 0RACTICESõANDõ%XPERIENCE
!S WE VE DISCUSSED IN CERTAIN SITUATIONS THERE IS MUCH VALUE IN
DEVELOPING A PROTOTYPE THAT IS USED TO DISCOVER AND EVOLVE THE
FEATURES OF AN ENVISIONED NEW PRODUCT 3OME SPECIFIC RECOMMENDED
PROTOTYPING PRACTICES ARE GIVEN UNDER THE HEADINGS THAT FOLLOW

2EQUIREMENTSõ%NGINEERINGõANDõõ
0ROTOTYPEõ$EVELOPMENTõINõ0ARALLEL
2EQUIREMENT ELICITATION AND ANALYSIS ARE GENERALLY A PRECONDITION FOR
SUCCESSFUL DEVELOPMENT WORK #ONVERSELY PROGRESS ON DEVELOPING
THE SYSTEM LEADS TO IMPROVED UNDERSTANDING OF THE PROBLEM AND
SOLUTION DOMAIN AND THUS CONTRIBUTES TO THE EVOLUTION OF THE
REQUIREMENTS TOWARD A VIABLE AND USEFUL SET #ONCURRENT WORK ON
REQUIREMENTS AND PROTOTYPE DEVELOPMENT HAS BEEN WIDELY ACCEPTED
AS A BEST PRACTICE AND IN MANY SITUATIONS IT MAY BE THE BEST APPROACH
!N EXAMPLE CONCURRENT PROCESS IS GIVEN IN &IGURE ;3ONG ET AL
= AND AN EXAMPLE OVERLAP OF PROTOTYPE DEVELOPMENT PROTOTYPE
TESTING AND FEATURE ANALYSIS ACROSS MULTIPLE ITERATIONS IS GIVEN IN
&IGURE
(ERE ARE SOME TIPS FOR CONCURRENT REQUIREMENTS ENGINEERING AND
DEVELOPMENT

v 7ORK ON EACH ACTIVITY WITH THE GOAL OF ACHIEVING SOME
PROGRESS SUCH THAT THE WORK RESULTS CAN CONTRIBUTE TO OTHER
PROJECT ACTIVITIES
v 7HEN USING PAIRED PROGRAMMING THE TEAM MEMBER WHO
IS MORE EXPERIENCED WITH THE DOMAIN WORKS MORE ON
REQUIREMENTS AND DOMAIN UNDERSTANDING WHILE THE OTHER
TEAM MEMBER WORKS ON THE IMPLEMENTATION DETAILS IN CLOSE
COLLABORATION
v "OTH REQUIREMENTS AND DEVELOPMENT STAFF MEET PERIODICALLY
TO EXCHANGE INFORMATION !N EVEN BETTER PRACTICE IS IF A SINGLE
COLLOCATED SMALL TEAM IS DOING BOTH REQUIREMENTS ENGINEERING
AND PROTOTYPE DEVELOPMENT SEE #HAPTER