SRE GROUP 5
REPORT
Events Scheduler for Olympic Games 2012
GROUP 5: System Requirements Engineering
Jasbir Dhillon
Konstantin Polozov
Luthfa Hussain
Na-Lee Ha
Rummana Ahmed
PROGRESS SO FAR
From the initial presentation from our clients and their report explaining the requirements in more detail, we drew up anelicitation plan. This plan showed our understanding of the current system, problems and opportunities that could be identified as well as techniques to be used to find requirements from the different stakeholders. We documented any ambiguitiesor questions that came upduring the process. These formed the basis for our second meeting with the clients where we clarified some issues, the system scope and used diagrams to make sure our understanding of what the system should do was the same as theirs.
Then we developed some models to clarify more in-depth understanding of the system goals and its requirements. Based on this were able to create a draft systems requirement specification and we followed the Volere requirement process.
OPEN ISSUES & RECOMMENDATION
How the data required for the system (such as athlete, facilities details) has not yet been decided. It could be collected and entered by the Olympiccommittee staff or the stakeholder with the information might enter the data via a website.
The hardware and software to run the system has not been decided. The number computers or their location have not been defined yet. Providing it does not cost much more than standard computers, the Olympic committee is prepared to provide what ever is necessary.
The next step will be to fully complete the requirement specification and to use quality assurance techniques to ensure that all the right requirements have been identified and that the requirements are right. To do this, the quality gatewaytechnique in the VOLERE process will be used. Each formalised potential requirement will be tested to filter out any unworthy requirements before they are added to the specification.
To test the specification as a whole, some verification and validation tools such as formal analysis will be used.
HOW WE WORKED
Our group had one meeting lasting approximately 4 hours, where we split the work up into segments such as:
§find out the project functional goals,
§to find out the project non-functional goals,
§prepare slides for the presentation
§elaborate some models.
We all worked on one of the above segments. During this meeting we also elaborated a goal modelling and a domain class diagram. This helped us gain clear mutual understanding of the system scope and functionalities. We constantly collaborated online and sent the work to each other to discuss our answers, ensure consistency and agreed on an answer for each task.
LESSON LEARNT
After meeting with a client we settled some ambiguities about the system that we had before. Mostly we understood what’s system scope was and how it will gather information from different stakeholders. During the meeting we found that asking direct questions are not always the best choice because client sometimes does not know what exactly they want or they find it difficult to explain it in words. This was especially made difficult by the fact there was no solid procedure or clearly defined current system in place to refer to. So we had to rephrase our questions so that we can lead client to the answer. That is why we found drawing diagrams much more useful for both developer and client. With the help of the diagrams clients understood much better what we are planning to build and how our model correspond to their.
Through studying several approaches for developing system requirement specification, we have learnt a variety of modelling techniques and their uses. We have learnt that different techniques have advantages and disadvantages over others and therefore different ones are better suited for different systems. One technique is generally not enough to give a clear picture of the system and therefore a good set of techniques should be used.
PROJECT DRIVERS
The Purpose of the Project
The Olympics Games is an international multi-sport event held every four years where 203 countries come together to compete in twenty six sports. Several hundred events are held to accommodate for these sports. The next Olympics is to be held in the Summer of 2012 in London. Each sport event for the Olympics will be held at one of the many facilities in London.
The Olympic Committee require a system which will be able to accurately schedule each sport event to each facility without making any errors such as double bookings. Currently, there is no active system in place thus we have been hired to produce a software system which will be able to accommodate these needs.
The situation of producing a schedule system is fairly serious as the Olympics is an important event in the United Kingdom. It attracts attention from all over the world and over 200 countries will be present for the Olympics thus an accurate system must be in place to provide a scheduling facility.
Goals of the Project
The goal that we would like to be able to achieve on behalf of the Olympics Committee is as follows:
-to be able to schedule all events accurately without in a reasonable amount of time without any conflict and reschedule events as and when necessary.
Advantage: This is the main purpose of the project. The advantage of having this is that a system will be in place which automatically schedules events without the need of any manual system. In the long term, this will help save money as it will prevent people from being hired to work on this.
The Client, the customer and other stakeholders
The Client and Customer
The customer for the product is is Mr Andrew Smith, the manager of the IT department for the Olympics 2012.
Other Stakeholders
The other stake holders of this product are as follows:
- The Olympic Committee
The Olympic Committee will require access to the system to be able to check when events are being held and reschedule events should three be an unforeseen circumstance. They are an important stakeholder. They will be involved in the development of the product.
- Athletes & Athletes’ Support Teams
Athletes and their support teams will benefit from the scheduling system as they will be aware of the times they need to attend events. They will also need to know of any last minute changes to timetables. They are an important stakeholder who will not be able to modify details on the system but can view details produced by the system.
- The Public
The public will need to know dates, time and location of each event to be to attend the sports they are interested in. It will allow them to reschedule their time as necessary to be able to attend the events and book appropriate accommodation, car parking facilities as necessary. They will not be involved in the development of the product and have a low priority in stakeholders.
- Government Units: This is a fairly important stakeholder. They do not have any direct access to the software but are able to view its details.
- Hospitals
Hospitals must have an up to date timetable at all times to ensure they have enough staff available to deal with injury during the times of each event.
- Police
Police benefit from the timetable as they need to be able to send enough staff out to the events have enough staff on standby.
-Means of Transportation
There should be regular transport between the locations of each event for people to travel too. During those times, Transport For London (TFL) and it’s associates will ensure travel is available to all. It will help increase transport profit
- Commercial & Business Companies
Commercial and Business companies benefit from the scheduling system as it allows them to attend events and promote their businesses at some of the events and possibly sponsor some of the events. However, they are not an important stakeholder of the system.
- Hotels
Hotels can increase profit during the times of the events. They are not very important but will have many people who will require accommodation. It is therefore necessary for them to be aware of events in advance to be able to maximise their profits.
Users of the Product
The users of the product are those who work for the IT department of the Olympics. There will be a staff of approximately 30 people working varied shifts always ensuring that the scheduling system is up to date. They are all experienced and trained IT users and will be inputting all the data related to the events. They will also be updating it on a regular basis ensuring that schedules are being up to date. They are the first point of contact for all the important stakeholders to come to should there be any immediate changes. Each user will have an assigned user name and password and only those with this facility will be able to make changes.
Some users may have disabilities thus it is important for the developers to ensure that these needs are catered for. We will need to obtain all such details from the Olympics Human Resources section and from the IT manager.
SPECIFICATION
CONSTRAINTS
Solution Constrains
Description: The product shall operate using Windows XP or Windows Vista
Rationale: Client use only Windows operating system
Fit Criterion: Product must be tested on Windows operating system to make sure it works correctly
Implementation Environment of the Current System
Description: Product must be ran on any hardware
Rationale: System consist totally of software parts and there is no fix hardware that it required
Fit Criterion: Product is only software and should be able to work on any computer as long as it has the correct software installed
Partner or Collaborative Applications
Description: System must work with TCP/IP
Rationale: System will be connected to the internet to communicate with stakeholders
Fit Criterion: System must be able to communicate over TCP/IP with stakeholders to collect all the information required
Off-the Shelf Software
Description: System may use existent scheduling systems
Rationale: Product does not need to create a new scheduling system, product task is to collect all information and produce timetable which can be done using already tested scheduling systems
Fit Criterion: Product only need to collect information from stakeholders and interpret this information to existent scheduling system so that it will produce the best timetable
Anticipated Workplace Environment
Description: System quickness depend on stakeholder
Rationale: System must collect information from all the stakeholders before producing the result and it will depend on stakeholders how fast they can produce needed information
Fit Criterion: System must be able to wait for a long time in idle mode before producing the result because the information result depend will be given by stakeholders and they may need time to produce it.
Schedule constrains
Description: The ESS should be delivered by January 2010
Rationale: The client want ESS be ready and tested before the Olympics Games
Fit Criterion:
Budget constrains
Description: Reasonable cost
Rationale: Client will choose the company who offered the best price/quality product
Fit Criterion: Product must be in reasonable cost so that the client choose it instead of competitors
FUNCTIONAL REQUIREMENTS
This chapter analyses the functional requirements into three sections of which include: the scope of the work; the scope of the product and the actual functional and data requirements of the system to be built. In order to analyse the scope of the work a context diagram has been modelled to identify the work needed to be able to build the product. Activity diagram was used to capture the workflow behaviour of a system.These business events are happenings in the real world that affects the work. The scope of the product uses a use case diagram which identifies the boundaries between the users (actors) and the product. In order to depict each functional requirement of the system we have used the requirements shell. This outlines the detailed functional requirements for the activity of the product. Finally, the data requirement uses a domain class diagram to clarify the system’s subject matter, this triggers the recognition of requirements not yet considered.
7. tHE sCOPE OF THE WORK
7a. Current Situation
The current system our client use, is a manual system whereby they input and calculate event scheduling through an excel sheet without the use of macros or advanced features. The main goal of the current system is to avoid conflicts that when assigning and scheduling an event. A scheduling system for the Olympics has not yet been required as a requirement in the past and therefore there exists no manual or automated system to carry out the scheduling of events.
7b. Context of the Work
Context diagram:
7c. Work Partitioning
Activity Diagram:
8. tHE sCOPE OF THE PRODUCT
8a. Product Boundary
Use Case Diagram:
9. FUNCTIONAL AND DATA REQUIREMENTS
9a. Functional Requirements
Requirement #: 1
Description:The ESS shall schedule all events without conflicting with other events.
1.1 - Shall avoid conflicts of staff assignment
1.2 - Shall avoid conflicts of facilities allocated to events
1.3 - Shall avoid conflicts of venues assigned to events
1.4 - Shall avoid conflicts when assigning public resources to events.
Rationale: To be able to schedule the Olympics events without any conflicts with other departments.
Fit criterion: The scheduled timetable shall agree with specific stakeholders such as:
- The Olympic Committee
- The Government unit: Head of emergency, transport & health department.
- The Facilities Management Team
- The Venues Management Team
- Sports Events Organiser
Requirement #: 2
Description:The ESS shall reschedule events on emergency.
Rationale: To be able to reschedule the Olympic events without causing other events or venues to clash when an emergency occurs.
Fit criterion: The rescheduled timetable shall agree with specific stakeholders such as:
- The Olympic Committee
- The Government unit: Head of emergency, transport & health department.
- The Facilities Management Team
- The Venues Management Team
- Sports Events Organiser
Requirement #: 3
Description:The ESS shall produce a timetable that matches the public’s entered choice of type.
Rationale: To be able to allow the public to specific events taking place at the Olympics. For example: A viewer may only want to view the timetable for the football event only.
Fit criterion: For each event selected to be viewed on the timetable should meet the public’s choice.
Requirement #: 4
Description:The ESS shall allocate each athlete to an event.
Rationale: To be able to allocate all athletes taking part in the Olympics to an event.
Fit criterion: When an athlete is assigned to an event the system will match the type of sport the athlete’s background consists of and the event being held at the Olympics. Otherwise the wrong athlete will be assigned to the wrong sporting event.
Requirement #: 5
Description:The ESS shall publish the timetable on the website.
Rationale: To be able to view a general timetable on the website by everyone.
Fit criterion: The timetable will fit the criterion of stakeholders before being published online:
- The Olympic Committee
- The Government unit: Head of emergency, transport & health department.
- The Facilities Management Team
- The Venues Management Team
- Sports Events Organiser
Requirement #: 6
Description:The ESS shall calculate the required public resources.
Rationale:?
Fit criterion: The required public resources should be in the range of how much resources is available and how much can be allocated.
Assumption: Resources = includes government unit such as hospitals, police, transportation, hotels and emergency.
Requirement #: 7
Description:The ESS shall send the timetable to the senior organisation.
Rationale: The timetable is sent for approval of the senior organisation. This will be sent via email and will need to be sent back as a signed hard copy.
Fit criterion: The timetable will need to be approved by the senior organisation before further action can take place.
DOMAIN CLASS DAIGRAM
- 1 -
SRE GROUP 5
GOAL GRAPH DAIGRAM
- 1 -
SRE GROUP 5
NON-FUNCTIONAL REQUIREMENTS
Requirement #: 1
Description: Have a reusable and an adaptable system
Rationale: The system should be reusable and should be easily changed for future events
Fit Criterion: The system should be changed for another event within a month
Requirement #: 2
Description: The system shall be user-friendly
Rationale: The system should be very easy to use, so that members of the public with little knowledge can use the system.
Fit Criterion: New users should be able to add their details, and view a timetable within 5 minutes of their first attempt at using the system
Requirement #: 3
Description: The timetable produced should be accurate
Rationale: There should be no events which clash on the timetable and other resources should be available when the event is scheduled.