1. Event Scheduling System
for Olympics Games 2012
Jasbir Dhillon Konstantin Polozov Na-Lee Ha Luthfa Hussain Rummana Ahmed

2. Process so far Initial client presentation
Analysis of the report and presentation
Elicitation plan
Meeting with client to clarify issues
Development of models
Plan and draft requirement document

3. Context Diagram

4. Context Diagram
Identify the work that need to be investigated to be able to build the product
Identify the stakeholders who are responsible for each work
Stakeholders that does not directly effect the system also identified
Clearly define the boundaries
Help understand the environment in which the system will be used
Help build a system that fits seamlessly in to its environment

5. Use Case Diagram

6. Use Case Diagram
System level – shows interaction between the users and the system
Easily understandable – can act as a bridge between business users and software developers.
Defines the scope and boundary of the system

7. Activity Diagram

8. Activity Diagram Shows the flow of activities when scheduling events
Models the developer’s understanding of activities involved in the scenario
Shows the internal behavior of operations but does not require design level details

9. Goal Graph

10. Goal Graph
High level goals and some non functional goals have been identified
Identifies business and system objectives
Identifies the stakeholders responsible for each objectives

11. Domain Class Diagram

12. Domain Class Diagram
Shows only the entities and their essential attributes
Implementation details not added
Shows what data needs to be stored to schedule events and allocate resources
Strong link between stored data and functionality
There is no point in storing data that is not going to be processed by some functionality. Functionalities exists to process data.

13. Open Issue & Recommendations
Fully develop requirement document using the VOLERE requirement process
Test each requirement using quality gateway
Test the whole specification using validation and verification technique such as formal analysis

14. Lesson learnt
Implicit knowledge problem & tacit knowledge problem can be over come by
Rephrasing questions
Use of diagrams
Different models are better suited for different systems
A set of models should be used to get a clear picture of the system
Implicit knowledge problem – current system is not documented or clearly defined
Tacit knowledge problem – People find it hard to describe knowledge they regularly use