Requirement Elicitation and Specification for Campus Common System (CCS)

This report analyzes the requirements for the development of the Campus Common System (CCS) and discusses various requirement gathering techniques and specification methods.

Student Name
Student ID 1
Application, Modelling and Development – Campus Common System (CCS)
Submitted by
Course
Professor
Date

Student Name
Student ID 2
Introduction
The Campus Common is a region on grounds where individuals can meet, eat, drink, as well as
can mingle. This is the new social area on grounds of the college for staff, students as well as
guests to enjoy. CCS Managers are the main persons who are responsible for overseeing event
bookings. They make occasion appointments and oversee plan clashes. They can also deny these
booking solicitation and furthermore can change the status of the coming events. Food as well as
beverages could be ordered through CCS by any mode. When a student makes an order for food,
these orders must be pre-paid by credit card system. The students can pick the order from CCS or
the orders can be delivered by delivery staff. The student must register for being a delivery
person. In this report, we will analyze all the requirements for CCS system development. This
framework will mean to give a method for students, staff and the social groups to book spaces at
Campus for events.
Task 1: Requirement Elicitation
Requirement Gathering Techniques
1. Questionnaires/Surveys - This technique can enable an expert to gather data from numerous
individuals in moderately short measure of time. This technique is helpful when stakeholders are
spread across the campus of university. This is particularly useful when partners are spread out
geologically, or there are dozen to many respondents whose info will be expected to help set up
framework necessities. The questions ought to be engaged and composed by an element or
undertaking objective. Questions ought to not be excessively long.
2. User Observation - The second requirement gathering methodology which we can use is
direct observation which can be better choice as compared to interviewing and questionnaires. In

Student Name
Student ID 3
order to get better comprehension of work processes of the organization, we can analyze all the
processes deeply. It can be helpful by getting a full knowledge of the processes by which user
collaborates with the framework. (Eid, 2015).
3. Analyzing Existing Documents - Analyzing existing reports can be better requirement
gathering process. By analyzing the current process can enable the analyst to comprehend the
business, or framework, and its present circumstance. Existing documentation can be helpful to
give all the details of the stakeholders to the analyst . This will enable the investigator to plan
interviews or polls to ask of partners.
4. Focus Group - This is mainly group of individuals who are clients by whom we can get
feedback. The criticism can be gathered about circumstances, needs, and issues to decide
prerequisites or it tends to be gathered to refine and approve the officially evoked necessities.
5. Feasibility study – Feasibility of the current frameworks as well as the possibility of
supplanting them can give layout prerequisites subtleties. (Axia Consulting, 2018).
Strategy for Choosing Requirement Gathering Technique
Getting all the necessities in an appropriate structure is one of the key advantages of requirement
gathering process which implies various attributes that can be characterized and followed for
every necessity while ensuring that they are being fulfilled. Stakeholders in case of CCS are
much aware of all the processes and the opportunities which can be possible, but they are
unaware about best approach. So, it will be best for us to divide the entire project into small and
for that we will use feasibility study and taking Questionnaires/Surveys of stakeholders. We will
ask for all the documents and ask them the actual documentation for better observe their internal
process.

Student Name
Student ID 4
Second option which we will use for requirement gathering is focus group. We will survey some
customer for feedback and will implement that feedback in developing the system. For setting up
trust, genuine and open info is required. Sometimes, customer may not be agreeable in talking
up, so it is imperative to fabricate in comfort place with them and be prepared to hear them out.
Tuning in and being set up to comprehend their issues may help to gather useful requirements.
(Eriksson, 2016).
Task 2: Requirement Specification
Two User Scenarios
CCS Manager is required to check all the orders whether delivered or pending at the end of the
day. If the customer is student, payment should be done prior of placing an order. When an order
is picked up or delivered, the user must change the status in CCS system. Also, all the event
bookings must be done by manager. The manager must be responsible to enter all the details
about event booking like event date, time, number of persons and so on.
According to CCS delivery person’s perspective, the delivery person can accept delivery and
after delivering the food, he must change the status of the order by logging into the system.
User Stories from Different Actors
1. In order to become a member of CCS, the student or staff employee need to register into the
system by providing valid identification proof.
2. CCS person available at the location at the time of order, change the status of order as picked
up when order is picked up by delivery boy for delivery.
3. Delivery person, after delivering the order change the status of the order.

Student Name
Student ID 5
4. CCS Managers can book an event by entering all the booking details into the system.
Functional Requirements
1. Students/ Staff – A form must be filled by students or staff in order to be a member in CCS.
The students or staff will get membership only after their approval by the server.
2. CCS Staff – When a user orders food by making some online payment through cards, The
CCS staff then change the status to pick up when the order is picked up by delivery staff.
3. Delivery Staff – The delivery staff of CCS must be able to change the status of order as
delivered when order gets delivered.
Non-Functional Requirements
1. Usability – The system must be easy-to use, user friendly and efficient. The system must
fulfill all its requirements.
2. Security – The system must be secured from external as well as internal vulnerability. Proper
security policies should be implemented.
3. Reliability – The system must be reliable as users are dependent on the system and the system
must provide correct information in very minimum time period.
Task 3: Diagrams for Different System Perspective
Context Diagram

Student Name
Student ID 6
Use Case
In the above use case, I have used four actors – Staff/ Students, CCS Staff, Delivery Boy and
CCS Manager. I have taken four use cases in above procedure. Firstly, Staff or student register
into the system in order to be a member. After becoming a member, they places an order by
making pre-payment by using online payment mode. After making payment, order is processed

Student Name
Student ID 7
by CCS staff and placed on the shelf. The order can either be picked or delivered. If order is
picked, CCS staff who is at the counter, update the status to picked up and when delivered,
delivery boy updates the status to delivered. On the other hand, CCS manager makes event
booking.
Use Case Description
Placing an Order
Use Case Name Placing an order
Trigger After registration, user places an order by making an online
payment.
Precondition The user makes registration in order to be a member.
Basic Path It will use Place Order tag in the web application.
Alternative Paths After registration, this option directly appears in order to place
the order.
Post-condition Order is processed
Exception The order can be canceled at any time
Other None
Functional
Requirement
 User registers into the system
 User places an order
 User makes the payment
Sequence Diagram

Student Name
Student ID 8
Entity Class Diagram
State Diagram

Student Name
Student ID 9
Task 4: Data and Storage Consideration
ER Diagram

Student Name
Student ID 10
Tables
Restaurant (RestaurantID, RestaurantNAme, RestaurantContact)
Primary key  RestaurantID
CCSMEmber (MemberID, MemberName, MemberContactNo, Staff/Student, RestaurantID)
Primary key  MemberID
Foreign Key  RestaurantID
DeliveryPerson (PersonID, PersonName, PersonAddress, PersonContact)
Primary key  PersonID
Order (OrderID, OrderedItem, Qty, OrdereddateTime, OrderStatus, memberID, deliveryID)
Primary key  OrderID
Foreign Key  memberID, deliveryID