Applications Modelling and Development Report for ISYS254 Course

This report provides a comprehensive analysis of applications modelling and development, encompassing various aspects of the software development lifecycle. The report begins with a discussion on requirements elicitation, exploring techniques such as interviews, questionnaires, observations, and facilitated workshops. It then delves into requirements specification, including user scenarios, user stories, and the definition of functional and non-functional requirements. The core of the report focuses on system perspectives, presenting diagrams like context diagrams, use case diagrams, sequence diagrams, entity class diagrams, and state diagrams to visualize the system's functionality and behavior. Finally, the report addresses data and storage considerations, including an ER diagram and a list of tables, providing a structured overview of the data management aspects of the application. This document serves as a valuable resource for students studying applications modeling and development, offering insights into the key concepts and methodologies involved in the creation of software applications.

Running head: APPLICATIONS MODELLING AND DEVELOPMENT
Applications Modelling and Development
Name of the Student
Name of the University
Author’s note:

1APPLICATIONS MODELLING AND DEVELOPMENT
Table of Contents
Task 1: Requirements elicitation.....................................................................................................2
Q1) Requirement Gathering Techniques:....................................................................................2
Q2) Strategy of Information Gathering:......................................................................................5
Task 2: Requirements specification.................................................................................................5
Q3) User Scenarios:.....................................................................................................................5
Q4) User Stories:.........................................................................................................................6
Q5) Functional Requirements:.....................................................................................................6
Q6) Non-Functional Requirements:............................................................................................7
Task 3: Diagrams for different system perspectives........................................................................9
Q7. Context Diagram:..................................................................................................................9
Q8. Use Case Diagram:.............................................................................................................10
Q9. Use Case Description:.........................................................................................................11
Q10. Sequence Diagram:...........................................................................................................12
Q11.Entity Class Diagram:........................................................................................................13
Q12. State Diagram:..................................................................................................................14
Task 4: Data and storage considerations.......................................................................................15
Q13. ER Diagram:.....................................................................................................................15
Q14. List of Tables:...................................................................................................................15
Bibliography:.................................................................................................................................18

2APPLICATIONS MODELLING AND DEVELOPMENT
Task 1: Requirements elicitation
Q1) Requirement Gathering Techniques:
Interviews: The interview is one of the most significant processes of gathering
requirements where the system analyst is responsible for interacting with the participant face-to-
face. The business analyst is assigned to interview the system owner and system users at the
initial stages of the software project management. The analysts must properly communicate the
aims of objectives of the project and interview. The questions must be created prior to interview
process. Each response and answer of the participant should be recorded in an organized way.
More than one interviewers can be responsible for conducting the interview. Same can be for
interviewee. Interviews can be group interviews too. Three main types of interviews are mostly
followed in the analysts. These interview categories are structured, unstructured and semi-
structured interviews. The structured interview is the most efficient way of conducting interview
process. In the structured interview, the interviewee is asked particular questions that are
associated with one or more objectives of the project. Specific type of data is collected in the
structured interview. The unstructured interview is the opposite of structured interview. In this
interview no specific objective oriented questions are asked to the interviewee. Semi structured
interview is used when the interviewer wants user perspective through open ended questions.
Questionnaire: The questionnaire is considered as an informal method in the information
gathering technique. The questionnaire includes many more respondents than interview
participants. The questionnaire is mainly used when the analyst requires collecting data from a
vast amount of target people and/or respondents are in different geographical locations. The
questionnaire is also considered to be most suitable information gathering technique for

3APPLICATIONS MODELLING AND DEVELOPMENT
collecting data from less important users. The responses collected from respondents are later
processed for statistical analysis. In most of the cases, the questions asked in the questionnaire is
also has a range of solutions from which the respondents have to choose. The questionnaire can
be categorized into fixed format ad free format questionnaire. In the fixed format questionnaire,
the respondents are allowed to select the predefined responses. The respondents select one or
more answers based on the condition analyst has set. The analysis of responses collected through
fixed format questionnaire is simpler. However, the fixed format questionnaire is more static and
does not allow respondents to give their own idea or thinking. The free format questionnaire
allows the users to provide their responses freely regarding each individual questions. The
respondent provide their answer to a particular space allocated to for the answer to that specific
question. The explanations are done in the free format questionnaire.
Observations: The observation is done by the analyst while watching the client operating
their daily tasks at job. The analysts interact with the client to understand their daily tasks and
significance of each task. This technique allows the analyst to get a better idea of how the tasks
might be performed by the users along with the requirements of completing one process.
Observation is also categorized in two forms such as passive and active. In the active
observation, the analyst can freely interrupt the user for asking questions while the observation
technique is performed. The passive observation does not allow the analyst to interact with the
user during observation process. However, the analyst continuously takes notes of the works are
done. The analyst asks questions prepared based on collected notes when a process ends.
Facilitated Workshop: In order to put a lot of people in one common group to discuss
and agree upon a common topic, the facilitated workshop information gathering technique can be
used. The cross-functional requirements regarding a product can be done in a very quicker way

4APPLICATIONS MODELLING AND DEVELOPMENT
through the use of this technique. This process allows collecting data faster than interview
process but the quality of the collected data is better than questionnaire. Proper planning is done
before facilitated workshop is conducted.
Focus Group: Synergistic conversations between the representatives of the users remain
in the main focus of this method. The analyst gather feedback from the representatives regarding
the opportunities, needs and issues for identifying the system requirements. A trained moderator
remains in charge for monitoring and controlling the conversation. Based on the roles of the
participants, ideas are discussed along with that logistics are created.
Brainstorming: The group members provided their own creative ideas regarding a
particular problem, requirement or risk. The suitable subject matter experts are responsible for
imaginatively brainstorming regarding the possible solutions. Various ideas collected from the
group members are then prioritized based on the solutions which are perceived to be more
efficient and effective.
Prototyping: The prototyping technique is applied for gathering initial requirements
which can be utilized for constructing the initial software called prototype. The prototype is a
small part of the desired solution that reflects one or few requirements of the system. The
prototyping is done in iterative process. The developed prototypes are tested and user feedbacks
are collected. Based on the feedback, the changes in the prototypes are done.
Document Analysis: The document analysis information gathering technique considers
task and procedure related written documentation as a very significant parts. Document analysis
is done on the base on the business contexts. The document analysis provides a good idea of how
business operations should be done instead of how they are at present.

5APPLICATIONS MODELLING AND DEVELOPMENT
Q2) Strategy of Information Gathering:
The information gathering will be done using three techniques such as interview,
questionnaire and document analysis. These three methods have been selected because these
techniques fulfill the drawbacks of each other. The interview process allows collecting quality
data from few participants. However, as the interview process is expensive and time consuming
not all the user groups are considered in the interview process. The questionnaire will be used for
collecting data from the potential users who will have least amount of interaction with the
system. These two techniques are more focused on the user requirement rather than business
requirement. In order to collect the requirements of business, the document analysis technique
will be used.
Task 2: Requirements specification
Q3) User Scenarios:
Delivery Person: The first thing that user will do in the system is login. However, in
order to login to the system, the delivery person must register into the system. The registration
process requires personal details, bank details, driver license number and photocopy. After the
delivery logs into the system, he will be marked as active in the system and system will track his
location through phone’s GPS. The delivery person can stop accepting order while still in the
system. The delivery person will accept order from the restaurant. The user will also mark the
food as delivered when member receives it.
CSS Manager: The CSS manager also logs into the system to execute their works. They
will access the event request page to see all the requests. This page will have few buttons that
will accept the request or reject it. The CSS manager can also mark the request as save for later.

6APPLICATIONS MODELLING AND DEVELOPMENT
The CSS Manager will have an event calendar that will show the date of event and name of
event. The CSS manager can click on the date and see all the activities of that date. The CSS
Manager can change the date of a event after booking or cancel the booked event.
Q4) User Stories:
As a member I want the system to have an account option so that I can see the activities I
have done in the system
As CSS manager I want the system to provide a dynamic event calendar so that I can
easily track the date of events
As a delivery person I want the system to track the current address of the user so that I
can deliver the food accurate location
As a restaurant I want the system to allow me accepting or rejecting order so that I can
manage orders based on the current situations
Q5) Functional Requirements:
Member Authentication and Authorization: This functional requirement is essential for
controlling and monitoring the activities of the members. As the student and staff members will
get few different advantages from the system, they will imply different authorization levels for
these two members. The staff can order food without paying the partial payment for the order.
The authentication will be done based on the login id and password provided to them at the time
of registration. Each registration process is also different for these two members. This is because,
the data collected from staff member is different from the student member.
Order Processing: The system will monitor and control the entire order processes. The
members can select the food and other available items they want to order. The system also has a

7APPLICATIONS MODELLING AND DEVELOPMENT
cart that can allow the members to adjust the order before it is confirmed. Once the order is
confirmed, the system sends the order details along with the payment and customer details to the
restaurant. The restaurant the order and mark the order as preparing. Once the order is prepared,
the restaurant owner can handover the order to a delivery person. As soon as restaurant owner
mark the order as transferred, the system notifies the member that it will delivered soon. The
delivery person gets the address location of the order owner and delivers the order to that
location. After delivering the order, the delivery person collect the sign and mark the order as
complete. The system stops all processes associated with the order and sends a link for providing
feedback on the order.
Event Management: The system provides a GUI to the CSS manager that shows all the
event related data to the CSS Manager. They will access the event request page to see all the
requests. This page will have few buttons that will accept the request or reject it. The CSS
manager can also mark the request as save for later. The CSS Manager will have an event
calendar that will show the date of event and name of event. The CSS manager can click on the
date and see all the activities of that date. The CSS Manager can change the date of an event after
booking or cancel the booked event.
Q6) Non-Functional Requirements:
Scalability: The system requires to be very scalable in terms of changing the processing
capacity. The system works heavily during the event days. On the other days, the system require
minimum resources. The system scalability will allow the organization to scale up or down the
associated resources. As the resources will be less, the organization can save operational costs.
Moreover, in case the system require heavy processing power, the organization can increase the

8APPLICATIONS MODELLING AND DEVELOPMENT
data storage, processor and other peripherals. The scalability will not only allow the organization
to save a lot of money but also make the system justified to organization needs.
Security: Security to some extent is always a requirement for every system. No matter
how significant the system is there is always a risk of cyberattack. The system will perform
many financial transactions. As the members will store back details and use the system for digital
payment, the system must be secure enough to prevent hacking. The security must be installed in
the server and virtual processing. Encryption methods are really a great way of sending data from
the server to the user end and vice versa without disclosing the real raw data to the open internet
environment.
Usability: The system will be used by five types of users. Two of those user groups (staff
members and student members) will have the same functionalities. The system must have a good
quality of UI that is simple enough to understand easily. The system must provide a good GUI
for every user. The user interactions for login and registration must be very unique and
innovative. The system should provide a great interactive GUI to the CSS manager. It is because
the CSS Manger does the most work over the system.

9APPLICATIONS MODELLING AND DEVELOPMENT
Task 3: Diagrams for different system perspectives
Q7. Context Diagram:
Figure 1: Context Diagram
(Source: Created by Author)

10APPLICATIONS MODELLING AND DEVELOPMENT
Q8. Use Case Diagram:
Figure 2: Use Case Diagram
(Source: Created by Author)

11APPLICATIONS MODELLING AND DEVELOPMENT
Q9. Use Case Description:
Use Case Name Login
Use Case ID UC_Member_01
Description The member must login to their individual account for booking spaces
and placing order
Purpose Store all the activities done in the system against an user
Trigger User wants to access the system
Actor(s) Member (Staff and Student)
Stakeholder(s) Member, Macquarie University
Pre-condition An existing account is must have for the member
Activity Actor System
Member clicks on login link The system redirect the user to
login page
Member fill-up the login form and
submit it
System checks the login credentials
If the login id or password is wrong
the reject request
If the data are correct then allow
login
Post-condition The user will be able to see account page
Alternate Path(s) The member can re-create an account if login id and password both forget
Exception(s) The user id is blocked

12APPLICATIONS MODELLING AND DEVELOPMENT
Q10. Sequence Diagram:
Figure 3: Sequence Diagram
(Source: Created by Author)

13APPLICATIONS MODELLING AND DEVELOPMENT
Q11.Entity Class Diagram:
Figure 4: Entity Class Diagram
(Source: Created by Author)

14APPLICATIONS MODELLING AND DEVELOPMENT
Q12. State Diagram:
Figure 4: State Chart Diagram
(Source: Created by Author)

15APPLICATIONS MODELLING AND DEVELOPMENT
Task 4: Data and storage considerations
Q13. ER Diagram:
Figure 5: Entity Relationship Diagram
(Source: Created by Author)
Q14. List of Tables:
Table: Delivery_Man
Attribute Data Type Data Length Integrity Constraint Reference
Table
member_number Number 10 Primary Key None
first_name String 60 None None

16APPLICATIONS MODELLING AND DEVELOPMENT
last_name String 60 None None
residential_address String 60 None None
phone String 60 None None
email_address String 60 None None
member_level String 60 None None
Table: Delivery_Man
Attribute Data Type Data Length Integrity Constraint Reference Table
staff_id Number 10 Primary Key None
first_name String 60 None None
last_name String 60 None None
current_address String 60 None None
phone String 60 None None
anum_salary Decimal 12, 2 None None
bank_details String 200 None None
Table: Restaurant_Entity
Attribute Data Type Data Length Integrity Constraint Reference
Table
restaurant_numbe
r
Number 10 Primary Key None
registered_name String 60 None None
address String 60 None None

17APPLICATIONS MODELLING AND DEVELOPMENT
business_id String 60 None None
owner_name String 60 None None
contact_number Number 10 None None
fax String 60 None None
email String 60 None None
contact_person String 60 None None
contact_phone Number 10 None None
Table: Order_Entity
Attribute Data Type Data Length Integrity
Constraint
Reference
Table
member_number Number 10 Foreign Key
Primary Key
Member
staff_id Number 10 Foreign Key
Primary Key
DeliveryPerson
restaurant_number Number 10 Foreign Key
Primary Key
Restaurant
date_of_order Date/Time Primary Key None
status String 60 None None
cost Decimal 12, 2 None None
delivery_address String 60 None None

18APPLICATIONS MODELLING AND DEVELOPMENT
delivery_expected_tim
e
Date/Time None None

19APPLICATIONS MODELLING AND DEVELOPMENT
Bibliography:
Khan, F., Jan, S.R., Tahir, M., Khan, S. and Ullah, F., 2016. Survey: dealing non-functional
requirements at architecture level. VFAST Transactions on Software Engineering, 9(2), pp.7-13.
Brhel, M., Meth, H., Maedche, A. and Werder, K., 2015. Exploring principles of user-centered
agile software development: A literature review. Information and software technology, 61,
pp.163-181.
Lucassen, G., Dalpiaz, F., van der Werf, J.M.E. and Brinkkemper, S., 2015, August. Forging
high-quality user stories: towards a discipline for agile requirements. In 2015 IEEE 23rd
international requirements engineering conference (RE) (pp. 126-135). IEEE.
Soares, J.A.C., 2017. Automatic model transformation from UML sequence diagrams to
coloured petri nets.
Horsburgh, J.S., Aufdenkampe, A.K., Mayorga, E., Lehnert, K.A., Hsu, L., Song, L., Jones, A.S.,
Damiano, S.G., Tarboton, D.G., Valentine, D. and Zaslavsky, I., 2016. Observations Data Model
2: A community information model for spatially discrete Earth observations. Environmental
modelling & software, 79, pp.55-74.
Eckhardt, J., Vogelsang, A. and Fernández, D.M., 2016, May. Are" non-functional" requirements
really non-functional? an investigation of non-functional requirements in practice. In 2016
IEEE/ACM 38th International Conference on Software Engineering (ICSE) (pp. 832-842). IEEE.