Requirements Elicitation Techniques and Strategies for Common Campus System

This document discusses the techniques and strategies for requirements elicitation in the Common Campus System. It explores the importance of interviews, questionnaires, prototyping, brainstorming, and analyzing documents. The data collected from these techniques is analyzed and justified for the redesign of the system. It also covers the functional and non-functional requirements, user scenarios, user stories, and use case descriptions. The document provides a system perspective through context and use case diagrams, as well as activity, sequence, state, and entity-class diagrams. References to relevant literature are also included.

Task 1: Requirements elicitation.
1. Requirements gathering techniques and reason why choosing this techniques.
According to Mochal (2008) explained that requirement collecting is very important stage in
software development cycle and good gathering techniques have to be selected.
Interviews, Questionnaires, Prototyping, Brainstorming and Analyzing of document.
a. According to Sommerville (2016) explained that questionnaires are effectively cheap, easy to use
and very fast at collecting requirement that come from stakeholders. Interviews are made on one
on one with stakeholder this helps to get vital information. Analyzing of software requirement
specification and design specification documents of the current common campus system helps to
identify the gaps in the system and redesign. Prototype is the best way of understanding the
problem where a prototype is design and given to stakeholder to use while capturing requirement
this is very important because accurate requirements are capture at less cost. Brainstorming helps
to generate different ideas by coming up with solution of problems or gaps in system. For
example during brainstorming system analysists suggested user interface of Common campus
should have green color, sliding pictures and details on dash boarded should not be scattered or
congested on one point. According to Preece, Rogers and Sharp (2017explained that good user
interface should user friendly and able to capture attentions of users. The website shall be easy to
learn how to operate and to remember how to use after being learned due to the graphical
representation of some features (menu, event, order now, drinks, Dive right in or sign in to re-
order,) that makes them obvious and straight forward. It has catch names and images of food,
uses perceptual boundaries, color to capture customers’ attention and price of each food and
beverage is attached making it easier to buy. Select and buy icons shall be visible.
2. Strategies, Details of technics, data collected and justification.
Drafting questioners and distributing to student and staff.
Requesting appointment from student and staff for interview.
Forming groups to brainstorm.
Details of technics, data collected and justification.
After interviewing students, restaurant person and Delivery person. Questions from interviews
were answered .For example interviewee asked interviewer a question of if there is need of new
system as compared to existing one? Majority of students 90% answered there is need of new
and gave reason, for example reasons they gave was a lot of time was wasted during waiting for
order and student could get wrong orders during delivery so students prefer to order themselves.
This data helps in redesigning of the system. Analyzing of documents helped researcher to obtain
data about different important document required for system to operate well and be captured for
example data about payment details, food menu, order details all this data is vital and need to be
captured during designing.Reciepts and food menus were obtained at restaurant showing
payment details and type of food available at restaurant. After giving student questioners to

answer some answers and reasons were obtained. For example question of, if there is a problem
with existing system? .Majority of student 80% answered yes there is a problem and gave
reasons such as activity of student getting food orders and booking for event is long ,slow and
consume a lot of time .Getting what you want in time is difficult so redesign of system is
important.
3. Questions.
Do you eat, drinking and interact at campus?
Which kind of items do you order?
Do you attend for event at campus?
Do you book for events?
Do you prefer delivery or pick up of order?
How do you make payments for orders you do make?
Is there a problem with existing system?
Do you need new new CCS system at Campus?
Which kind of improvement do you suggest we make?

Task 2: Requirements specification.
According to Pressman (2018) explained that both functional and non-functional requirements
are important during design of system and so they are important to be implemented .Functional
are requirements which a system has to do or implement for it to functions well while
nonfunctional requirements are requirements which a system cannot implement but a system will
continues functioning example speed of system processing food order is low.
4. User scenarios.
CCS Delivery person registers on CSS as a delivery person, Registration details are validated
using MqAuthServer and a student can be a Delivery person. Delivery accepts orders and change
status as delivered.CCS manager manages booking, schedule conflicts, creates and cancels
booked events.
5. User stories.
CCs Member registers on ccs.
CCs Delivery Person can be a student and same time delivery person.
Ccs member makes payment through Css to the bank or MQ Budget Office system.
Restaurant is auto registered.
6. Functional requirements.
All CCS Members shall register to get an account of css.
CCs member shall make payment first before ordering, through Css to the bank or MQ Budget
Office system.
The manager shall manage all booked event.
7. Non-functional requirements.
Performance.
Time to process order shall be 15 mins and employees should not be overloaded with a lot of
work so there is need to employ more workers.
Time for responding to order should be real time. System can notify ccs member if order food is
available or no in real time. System shall process all orders of student a university.
Security.
The system shall only allow only registered, validated student and staff are the one to access
ccs features and use. Roles also shall be given according to level for example a student cannot
read or write on manger level.
Reliability.
The system shall be available any time ccs member need to make orders thus systems shall be
free from failure. For example shall have 5 mins of time it is down per month.
According to Fenton and Pfleeger (2017) explained that nonfunctional requirements’
limitations and constraints have to be considered during design of system. Example security,
reliability and performance requirement are important and should be put into consideration
during designing.

Task3: System Perspective.
8. Figure 1 below showing Context Diagram of Common Campus System.
The context diagram above demonstrates how external users interact with the common campus
system. The context has covered major stakeholders of the common campus system.

9. Figure 2 below showing a Use Case Diagram of Common Campus System.
The use case diagram above shows how different acts and their uses cases are demonstrated
while interacting with the system.
Use cases are added on CCS Delivery Person because not only all orders which are ordered are
to be picked, some are to be delivered thus why a deliver person is important. Delivery persons
accepts order then changes status to delivery.

10. Table 1 below showing use case description of registration.
Use Case Description
Use Case Name Registration
Scenario Success Scenario: CCS Member are registered.
Failure Scenario: Fail to register due to invalid details
of ccs members.
Triggering Event The CCS Member wants to use features of ccs
system.
Actors CCS Member MQ AuthServer and MQ
AuthGroupAuthServer.
Purpose To use features of CCS.
Overview/Description This use case describes how CCS Member registers
on CCS to access features of CCS.
Type Business Requirement and Design Requirement.
Stakeholders Macquire University, students, Staff and Student
Group.
Pre-Conditions CCS is operational, The CSS Member enters his/her
credentials on registration form on CCS and they are
valid. The CCS is well connected to internet.
Post-Conditions The CCS Member is registered and can start using
features of CCS.
Special Requirements
Flow of Events
Actor Action System Response
CCS Members enters details on
registration form on ccs ,MQ
AuthServer and MQ
AuthGroupAuthServer validates CCS
Member’s details ,confirm registration
and send verification code on phone or
email .Member enters verification code
and registration is complete .CCS
Member can then login and start using
features of CCS.
System Authenticate of members, The system accepts
registration details, allows member to login to use
features of ccs.
Alternate Flow of Events/Exceptional Conditions
CSS Member Authentication, Enter
verification code and registration
complete notification is sent.
Invalid details, internet service not available, Invalid
code verification code

Table 2 below showing use case description of Payment.
Use Case Description
Use Case Name Payment
Scenario Success Scenario: Payment is made.
Failure Scenario: Fail to pay due to lack
of money account or not having it.
Triggering Event The CCS Member wants to order for
food of ccs system.
Actors CCS Member, Bank and MQ office
system.
Purpose To pay for order CCS.
Overview/Description This use case describes how CCS
Member pays for orders of service of
CCS.
Type Business Requirement and Design
Requirement.
Stakeholders Macquire University, students, Staff and
Student Group.
Pre-Conditions CCS is operational, The CSS Members
pay in advance to order for food on css
and they are valid registered and have
money. The CCS is well connected to
internet.
Post-Conditions The payment is made and ccs member
can order food on ccs.
Special Requirements
Flow of Events
Actor Action System Response
CCS Members enters account details to
makes payment to the bank or MQ
Budget office system. Bank and MQ
Budget Office verify payment details
and confirms payment
The system allows payment to be made
through it
Alternate Flow of Events/Exceptional Conditions
CSS Member Enters account details,
transaction verification is made,
confirmation and payment is complete
Invalid account details, internet service
not available, No money in account

11. Figure 3 below showing a Sequence Diagram of Registration.
The diagram above explains that registration starts when ccs member sign up on and process
continues to MQ AUTHSERVER for validation. If student group are the one to register a process
starts a fresh, student sign up on system and process continues to MQ AUTHGROUPSERVER
AUTHSERVER for validation .Process stops when student is registered and can access system
for use.

12. Figure 4 below showing activity diagram of Registration.
Activity is triggered when css member or group need to registers and continues up to validation
by servers .Server allows registration to be complete or rejects it.

Figure 5 below showing activity diagram of Payment.
Explaining activity diagram above .Activity is triggered when payment of order is made by ccs
member. Payment can be made to the bank or Mq budget office system.

13. Figure 6 below showing an entity-class diagram of Common campus system.
The class diagram above is detailed, with attributes and methods of all classes in the problem
statement. According to Lethbridge and Laganiere (2016) explained that Uml diagrams are well
detailed and help developer in quick completion of project because most of attributes and
methods are captured.

14. Figure 7 below showing a State diagram of Payment class.
Explaining state class diagram above .state is triggered when payment of order is made. Payment
can be made to the bank or Mq budget office system.

15. Figure 8 below showing ER diagram.
The ERD diagram above is detailed, with attributes and relationships between them in the
problem statement. Primary keys are MemberID, PaymentID, JobID and OrderNO.
Foreign keys are MemberID in entity payment, OrderNo in entity Restaurant, PaymentID and
orderNo in entity CCS Member,OrderNo in entity Delivery person and DeliveryPersonId in
entiry order.

Reference.
Sommerville, I (2016). Software engineering (10th Ed.).
University of St Andrews, Scotland: Pearson.
Fenton, E, N and Pfleeger, L, S. (2017).Software Metrics.
Rigorous and Practical Approach (3rd Ed.).Boston PWS publishing company.
Pressman, S,R,Ph.D. (2018).Software Engineering. Practitioner’s Approach (8thEd.).
Inc., 1221 Avenue of the Americas, New York, McGraw-Hill.
Preece, J, Rogers, Y and Sharp, H. (2017).Interaction design:
Beyond human- computer interaction (5th Ed) .New York: John Wiley & Sons, Pearson.
Lethbridge, C, T and Laganiere,R.(2016) Object-Oriented Software Engineering:
Practical Software Development Using UML and Java (3ndEd.). New York, McGraw-Hill.
Mochal, T. (2008).Techniques for gathering requirements. Retrieved 2/4/2019
from https://www.techrepublic.com/blog/10-things/10-techniques-for-gathering-requirements/.