Requirements Elicitation Techniques

Task1: Requirements elicitation.
1. Requirements gathering techniques.
According to Kaner and Bond (2017 explained that requirement collecting is very important stage
in software development cycle and good gathering techniques have to be selected.
Interviews.
Questionnaires.
Prototyping.
Brainstorming.
Analyzing of document.
Appropriate gathering techniques to use.
According to Connolly and Begg (2015) explained that questionnaires are effectively cheap, easy
to use and very fast at collecting requirement that come from stakeholders. Before Interviews it
is good to set appointment and issue an interviewee with questions for them to prefer. Analyzing
of documents used during development of software is encourage and document used during
operation. It helps to look for loop hole in the system and address them. Prototype is the easy
way of collecting requirement you develop a prototype give it to stakeholders for them to
understand and make use of it and raise requirements they need. Brainstorming bring together
different actors to help analyzing and bring different options.
2. Strategies.technics, data and justification.
Issuing out questioners to student and staff and request them to answer.
Make appointments with student and staff for interview.
Requesting documentation of the system from management of campus.
Details of technics, data collected and justification.
Majority of students(80%) interviewed wanted some improvement on existing system to be
made according to answers provided .Data from student was generated and helped in
redesigning the new system .Analyzing of documents at university for example student records
helps to know the number of student available at campus. So when designing database you have
to know scalability of it or number it is supposed to hold. Student who used a prototype which
was designed suggested user interface should have clear images of different food type and
arranged well .This data is helpful in designing user friendly interface.

3. Questionnaire questions.
Do you make orders at campus?
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?
Do like current user interface of CCS?
How should we improve the existing system?
Do you need CCS system at Campus?
Task 2: Requirements specification.
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 is validated by servers.
CCs Delivery Person can be a student and same time delivery person.
Ccs members prepays for order before ordering.
6. Functional requirements.
All CCS Members shall have account to access features of CSS.
It is a must to make payment of all orders through Css to the bank or MQ Budget Office system.
Manger shall has to create, edit and deny books of event.
7. Non-functional requirements.
Security
All ccs member shall use passwords and usernames to access system.
Password length shall be 8 digits.
System shall log out after 1 mins of not being active it is a safety measure.
Scalability.
System shall be able to hold all student and staffs registered on it.
Performance.

System shall process all tractions with no delays, for example should take 15 mins and Css
member receives it.
Task3: System Perspective
8. Figure 1 below showing Context Diagram of Common Campus System.
The context diagram above show different external user mapped on common campus system.

9. Figure 2 below showing a Use Case Diagram of Common Campus System.
CCS Delivery Person accepts orders and delivers order to ccs members then changes status as
delivered .some orders are picked by css members others are delivered so adding delivery person
is important in this use case. Use case ends when food order is received