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

! PRACTICE TO ACHIEVE A SIMPLIFIED REPRESENTATION OF FUNCTIONALITY
WHEN PROTOTYPING IS TO CONCENTRATE ON A SMALL SUBSET OF SYSTEM
ASPECTS COUPLED WITH TRANSPARENCY TO OTHERS "Y NOT TRYING TO ADDRESS
ALL THE ISSUES THE EVENTUAL SYSTEM NEEDS TO DEAL WITH WE CAN SELECT A
REPRESENTATION THAT IS PARTICULARLY GOOD FOR MEETING MOST OF OUR GOALS
&OR EXAMPLE A STORYBOARD OR AN ACTIVITY DIAGRAM PROVIDES A GOOD
REPRESENTATION FOR USER DRIVEN INTERACTIVE WEB APPLICATIONS (OWEVER
FOR AN ASYNCHRONOUS WEB APPLICATION USING !JAX FOR EXAMPLE THIS
REPRESENTATION WOULD NOT BE AS USEFUL IN CAPTURING THE RICHNESS OF
SYSTEM INTERACTIONS DRIVEN BY ASYNCHRONOUS UPDATES 5SING THIS
REPRESENTATION IN THE ASYNCHRONOUS WEB APPLICATIONS OR FOR EXAMPLE
IN AVIONICS OR PROCESS CONTROL SOFTWARE WOULD IMPLY THAT WHILE OUR
PROTOTYPE IS USEFUL IN UNDERSTANDING THE USER DRIVEN INTERACTIONS IT
MAY NOT BE APPLICABLE TO THE REQUIREMENTS RELATED TO ASYNCHRONOUS
AND EVENT DRIVEN BEHAVIORS
%ARLY PHASES OF REQUIREMENTS DISCOVERY ARE CHARACTERIZED BY A
GREAT DEAL OF UNCERTAINTY AND GENERALLY INCONSISTENT VIEWS AMONG THE
STAKEHOLDERS 4HE GOAL OF REQUIREMENTS DISCOVERY IS TO UNDERSTAND
THESE INCONSISTENCIES AND TO REDUCE THE UNCERTAINTY BY CREATING
A COMMON UNDERSTANDING OF THE SYSTEM NEEDS CAPABILITIES AND
POTENTIAL CONFLICTS AMONG STAKEHOLDERS 7E ARE NOT TARGETING THE
CONFLICTS THAT ARE ALREADY KNOWN TO SOME OF THE STAKEHOLDERS SINCE
THOSE ARE LIKELY TO BE ALREADY DOCUMENTED BY THEM /UR EMPHASIS IS
ON UNDERSTANDING THE CONFLICTS THAT WILL BE BROUGHT TO THE SURFACE BY
THE DEVELOPMENT AND DEPLOYMENT OF THE TARGET SYSTEM

2APIDõ)TERATIONõOFõ2EQUIREMENTS 3TAKEHOLDERõ&EEDBACK
3CHEDULING A MEETING WITH THE GOAL OF IDENTIFYING INCONSISTENCIES
AMONG STAKEHOLDERS IS NOT A VERY PRODUCTIVE APPROACH IN OUR
EXPERIENCE SINCE WE DON T KNOW A PRIORI WHAT ALL THE INCONSISTENCIES
ARE ! MORE CONSTRUCTIVE APPROACH TO REQUIREMENTS DISCOVERY IS TO ELICIT
REQUESTS FROM INDIVIDUAL STAKEHOLDERS PRESENT THESE REQUESTS IN A
COMMON AND UNAMBIGUOUS FORM AND THEN COLLECT FEEDBACK FROM THE
STAKEHOLDERS #ONFLICTS AND INCONSISTENCIES CAN BE DETECTED IN TWO WAYS
EITHER THE HARMONIZED VIEW CAN T BE CONSTRUCTED DUE TO OUR PERCEPTION
OF CONFLICTS OR THE HARMONIZED VIEW GETS REJECTED BY SOME STAKEHOLDERS
BECAUSE THEIR PERCEPTION OF THE SYSTEM DIFFERS FROM OUR ASSUMPTIONS
%ITHER WAY WHEN SUCH CONFLICTS ARE DETECTED THEY MUST BE OPENLY
PRESENTED TO THE STAKEHOLDERS FOR A RESOLUTION TO BE JOINTLY DETERMINED
'OAL MODELING AS DESCRIBED IN #HAPTER CAN BE AN EFFECTIVE WAY OF
COMMUNICATING HIGH LEVEL REQUIREMENTS CONFLICTS TO STAKEHOLDERS
4HE ITERATIVE NATURE OF THIS PROTOTYPING PROCESS ALLOWS US TO
CONCENTRATE ON MANAGEABLE UNITS AND TO MAKE QUICK PROGRESS TOWARD
A COMMON AND UNAMBIGUOUS REPRESENTATION 4HIS ALSO HELPS THE
STAKEHOLDERS TO PROGRESSIVELY EVOLVE THEIR PERCEPTION OF REAL
REQUIREMENTS BASED ON THE EVOLVING PRESENTATION OF THE PROPOSED
SOLUTION 4HIS ASPECT OF REQUIREMENTS PROTOTYPING HAS A GREAT DEAL OF