Processes and entities for eLivingCampus

 We’ve moved beyond – “we’re building a map/kiosk/database of the livingcampus” to “we’re building a system to support the management of the living campus – we’re focussing on school groups, for example a school group of thirty year 4s will be visiting the living campus to undertake activities that fit in with both what is happening in the garden,  and the school curriculum, they’ll need some activities and resources, it would be good if we could arrange some expert gardeners to help.  They’re coming next Friday, what will be mature then?, we’ll need to have some material to work on in class for the week before that..”.  

We’ve been working on understanding what needs to be done for the eLivingCampus.   Functional requirements sit uneasily with agile development – they’re in the planning game etc but lengthy modelling to derive them has people itching to build something.  Although we’re agile, we still spend a bit of time in “Functional Requirements” (the Analysis of old).   We’re not then wedded to those functional requirements but the process of developing them is extremely useful.    The increase in the level of understanding over these two weeks is huge. 

Student groups don’t have experience of writing functional requirements “cold”.  As a rule, their functional requirements  are very shallow, left to their own devices, we get 15 variations on a login system but with no actual functions.  By exploring underlying structures and process, we come to a much better understanding of what the system has to actually do.      We use Entity relationship models  and Data flow diagrams, preferring whiteboards to case tools. 
 

The verb phrases from the relationships and the proceses lead directly to functional requirements – what the system has to actually do.   Those requirements drive the Interaction Design, where we’re headed next.