Requirements Elicitation Techniques

This document discusses various techniques for gathering requirements in software development, such as interviews, questionnaires, prototyping, brainstorming, and analyzing documents. It also provides strategies, data collected, and justifications for each technique. The document includes questionnaire questions, user scenarios, user stories, functional and non-functional requirements, system perspective, and diagrams.

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

Use case descriptions.
10.0. Table 1 below showing use case description of registration.
Use Case Description
Use Case Name Order food
Scenario Success Scenario: CCS Member receives food
ordered.
Failure Scenario: Fail to fails to receive food order
due out of order or not available.
Triggering Event The CCS Member needs to order for food.
Actors CCS Member, Restaurant person and delivery
person.
Purpose To order for food on CCS.
Overview/Description This use case describes how CCS Member orders
food on of CCS.
Type Business Requirement and Design Requirement.
Stakeholders Macquire University, students, Staff and Student
Group and delivery person.
Pre-Conditions CCS is operational, The CSS Member prepays for
order CCS. The CCS is well connected to internet.
Post-Conditions The CCS Member is receives order by delivery or
goes to pick food.
Special Requirements
Flow of Events
Actor Action System Response
CCS Members prepay for order, Order
is prepared at restaurant, Delivery
persons accept to deliver order or CCS
Member can pick ordered food.
The system allows ordering process to take place.
Alternate Flow of Events/Exceptional Conditions
CSS Member orders food and food is
delivered to them or they can pick it
Food is out of stock, No payment for order is made
and internet service not available

Use case descriptions.
10.1. Table 2 below showing use case description of validation.
Use Case Description
Use Case Name Validation/cross checking
Scenario Success Scenario: CCS Member are validated and
can access system.
Failure Scenario: CCS Member cannot access ccs due
to invalid details of ccs members.
Triggering Event The CCS Member details needs to be validated to
enable them access CSS.
Actors CCS Member, MQ AuthServer and MQ
AuthGroupAuthServer.
Purpose To validate details of CCS members.
Overview/Description This use case describes how CCS Member details are
validated on 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 ccs system, MQ AuthServer and MQ
AuthGroupAuthServer validates details.. The CCS is
well connected to internet.
Post-Conditions The CCS Member is validated, can login and start
using features of CCS.
Special Requirements
Flow of Events
Actor Action System Response
CCS Members enters details 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 Authenticates 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
11.0. Figure 3 below showing a Sequence Diagram of ordering food.
Ordering process starts when ccs member prepays at bank before ordering and order is prepared
at restaurant .when order is ready .Restaurant person confirm all payments are made .CSS
member can pick order or order can be delivered .when order is to be delivered. Delivery person
accepts order and delivers it to CCS Member. Process ends when css member receives ordered
food

12.0. Figure 4 below showing activity diagram of ordering food.
Ordering activities starts when ccs member prepays at bank before ordering and order is prepared
at restaurant .when order is ready .Restaurant person confirm all payments are made .CSS
member can pick order or order can be delivered .when order is to be delivered. Delivery person
accepts order and delivers it to CCS Member. Process ends when css member receives ordered
food

12.1. Figure 5 below showing activity diagram of Payment.
Activity is triggered when css member or group need to validate details after registering and
validation take place by servers .Server allows validation to be complete or rejects it.

13.0. Diagram 6 below showing an entity-class diagram of Common campus system.

14.0. Figure 7 below showing a State diagram of Payment class.
Event is state diagram is triggered when prepaid of order is made. Ordered is processed at
Restaurant and decision of delivering or picking is made. Order can be delivered by delivered
person or it can be picked by ccs member .State is ends when order is received by ccs member.

15.0. Figure 8 below showing ER diagram.
Justification.
I added entity payment because it is in a processing involving ordering, payment of services used
must be paid for .This is not charity organization where services are for free.Alot of expenses
incurred during operation of restaurant from man power to buying of raw materials to be used.so
payment is must.

Reference
Kaner, C and Bond, P, W 2017, Software Engineering Metrics: What Do They
Measure and How Do We Know?
Connolly, M. & Begg, C 2015, Database systems A practical approach to
Design, implementation and management. (6th Ed.). Harlow, Essex, England:
Addison-Wesley (Pearson Education Limited).