ASSIGNMENT 2 BRIEF

Qualification BTEC Level 5 HND Diploma in Computing

Unit number Unit 9: Software Development Life Cycle

Assignment title Undertake a Software Development Lifecycle

Academic Year 2020 – 2021

Unit Tutor Vo Ngoc Mai

Issue date Submission date

IV name and date Le Luong Minh Man

Submission Format:

Format: The submission is in the form of 1 document

You must use font Calibri size 12, set number of the pages and use multiple line spacing at
1.3. Margins must be: left: 1.25 cm; right: 1 cm; top: 1 cm and bottom: 1 cm. The reference
follows Harvard referencing system.
Submission Students are compulsory to submit the assignment in due date and in a way requested by
the Tutors. The form of submission will be a soft copy posted on
http://cms.greenwich.edu.vn/
Note: The Assignment must be your own work, and not copied by or from another student or from
books etc. If you use ideas, quotes or data (such as diagrams) from books, journals or other sources, you
must reference your sources, using the Harvard style. Make sure that you know how to reference properly,
and that understand the guidelines on plagiarism. If you do not, you definitely get failed

Unit Learning Outcomes:

LO3 Undertake a software development lifecycle

LO4 Discuss the suitability of software behavioural design techniques

Assignment Brief and Guidance:

Task1

Page 1
Now your team had been accepted to create the Software to Tune Source. As a member of a
development team, your task now is to produce the requirements for Tune Source. You also need to
specify the technique(s) or processes you used in order to get these requirements.
Task 2
Based on the requirements which established in Task1 provide the following diagrams: Use Case, ERD,
DFD.. which can help to identify more clearly about the system you are going to implement.
Task 3
Based on your understanding about the Tune Source’s requirements in Task1 and Task 2, show how the
requirement can be addressed. Your method could include software behavioural specification methods
and reliability and effectiveness of software.
Task 4
Your client want to improve the software quality. Create a report which shows how software quality
could be improved from tracing requirements and programme design.

Page 2
 Learning Outcomes and Assessment Criteria

Pass Merit Distinction

LO3 Undertake a software development lifecycle

P5 Undertake a software M3 Analyse how software D3 Critically evaluate

investigation to meet a requirements can be how the use of the
business need. traced throughout the function design paradigm
software lifecycle. in the software
development lifecycle can
P6 Use appropriate M4 Discuss two improve software quality.
software analysis approaches to improving
tools/techniques to carry software quality.
out a software
investigation and create
supporting
documentation.

LO4 Discuss the suitability of software behavioural

design techniques
D4 Present justifications
P7 Explain how user and M5 Suggest two software of how data driven
software requirements behavioural specification software can improve the
have been addressed. methods and illustrate reliability and
their use with an effectiveness of software.
example.

M6 Differentiate between
a finite state machine
(FSM) and an extended-
FSM, providing an
application for both.

Page 3
Contents
1 P5 Undertake a software investigation to meet a business need. ............................................................................ 5
1.1 Identify the stakeholders, theirs roles and interests in the case study............................................................. 5
1.1.1 Introduction ............................................................................................................................................... 5
1.1.2 Identify the stakeholders, theirs roles and interests of the Tune Source project: .................................... 5
1.1.3 Requirement definition of the project (FRs and NFRs).............................................................................. 5
1.1.4 The relationship between functional requirement and non-functional requirement: ............................. 7
1.2 Discuss the technique(s) you did use to obtain the requirements.................................................................... 7
1.2.1 Introduction ............................................................................................................................................... 7
1.2.2 Some requirement gathering techniques:................................................................................................. 9
1.2.3 Conclusion the techniques that suitable with the Tune Source .............................................................. 13
2 P6 Use appropriate software analysis tools/techniques to carry out a software investigation and create
supporting documentation. ............................................................................................................................................. 13
2.1 Introduction [11].............................................................................................................................................. 13
2.2 Tool and techniques ........................................................................................................................................ 13
2.2.1 Data Flow Diagrams [12] ......................................................................................................................... 13
2.2.2 Entity relationship diagram: .................................................................................................................... 15
2.2.3 Flowchart: ................................................................................................................................................ 16
2.2.4 Pseudocode ............................................................................................................................................. 17
3 P7) Explain how user and software requirements have been addressed. .............................................................. 19
3.1 Introduction [15].............................................................................................................................................. 19
3.2 Identifying the Major Use Cases ...................................................................................................................... 20
3.3 Elaborating on the Use Cases .......................................................................................................................... 20
4 Reference................................................................................................................................................................. 21

Page 4
1 P5 Undertake a software investigation to meet a business need.
1.1 Identify the stakeholders, theirs roles and interests in the case study.
1.1.1 Introduction

A stakeholder is either an individual, group or organization who is impacted by the outcome of a project.
They have an interest in the success of the project, and can be within or outside the organization that is
sponsoring the project. Stakeholders can have a positive or negative influence on the project. Or they can
be a person, like any other member of the project, and some will be easier to manage than others. You’re
going to have to learn to deal with a variety of personalities and make sure you’re having a productive
dialogue with them to know the project goals you’ve been hired to meet.

1.1.2 Identify the stakeholders, theirs roles and interests of the Tune Source project:

Name Role Interest

Carly Edwards, Assistant Vice Project Providing the resources for the project – pay for
President, Marketing. sponsor the project. But don’t appear to have specific
requirement.
Tune Source Company Owner Achieve the goal of the , libility, increase sale
margins.
ABC Company. Champion • New product excitement.
• Demand end-of-year bonus.
• Retain and expand skill level.
• Strike threats supposedly have decreased.
Received numerous requests for
additional traning.
End user • Can approach with the technology.
• Satisfy the demand of the need when buy
the product.
Table 1: Stakeholer, role and interest.

1.1.3 Requirement definition of the project (FRs and NFRs)

1.1.3.1 Functional Requirement

Definition

Page 5
A Functional Requirement (FR) is a description of the service that the software must offer. It describes a
software system or its component. A function is nothing but inputs to the software system, its behavior,
and outputs. It can be a calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to perform.

Value of Functional Requirement

• Helps you to check whether the application is providing all the functionalities that were mentioned
in the functional requirement of that application
• A functional requirement document helps you to define the functionality of a system or one of its
subsystems.
• Functional requirements along with requirement analysis help identify missing requirements. They
help clearly define the expected system service and behavior.
• Errors caught in the Functional requirement gathering stage are the cheapest to fix.
• Support user goals, tasks, or activities

Functional requirement of the Tune Source project

• Search for music in our digital music archive.

• Listen to music samples.
• Purchase individual downloads at a fixed fee per download.
• Establish a customer subscription account permitting unlimited downloads for a monthly fee.
• Purchase music download gift cards.

1.1.3.2 Non-functional requirement [1]:

Definition

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a

requirement that specifies criteria that can be used to judge the operation of a system, rather than specific
behaviors. They are contrasted with functional requirements that define specific behavior or functions. The
plan for implementing functional requirements is detailed in the system design. The plan for implementing
non-functional requirements is detailed in the system architecture, because they are usually architecturally
significant requirements.

Value of Non-functional testing are:

Page 6
 • The nonfunctional requirements ensure the software system follow legal and compliance rules.
• They ensure the reliability, availability, and performance of the software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.

Non-funtioncal requirement of the Tune Source project

• The system must guarantee that costumers’ sensitive data transmitted securely.
• The system shoulde be able to handle multiple transactions concurrently.
• The system must be available 24/7.
• The system must be easy to use and compatible with major web browser.
• The system should be sufficiently fast to accommodate various internet connections speeds.

1.1.4 The relationship between functional requirement and non-functional requirement:

A functional requirement describes what a software system should do, while non-functional requirements
place constraints on how the system will do so.

An example of a functional requirement would be: A system must send an email whenever a certain
condition is met (e.g. an order is placed, a customer signs up, etc).

A related non-functional requirement for the system may be: Emails should be sent with a latency of no
greater than 12 hours from such an activity.

The functional requirement is describing the behavior of the system as it relates to the system's
functionality. The non-functional requirement elaborates a performance characteristic of the system.

1.2 Discuss the technique(s) you did use to obtain the requirements.
1.2.1 Introduction

Techniques describe how tasks are performed under specific circumstances. A task may have none or one
or more related techniques. A technique should be related to at least one task.

The following are some of the well-known requirements gathering techniques :

Brainstorming: Brainstorming is used in requirement gathering to get as many ideas as possible from group
of people. Generally used to identify possible solutions to problems, and clarify details of opportunities.

Page 7
Document Analysis: Reviewing the documentation of an existing system can help when creating AS–IS
process document, as well as driving gap analysis for scoping of migration projects. In an ideal world, we
would even be reviewing the requirements that drove creation of the existing system – a starting point for
documenting current requirements.

Focus Group: A focus group is a gathering of people who are representative of the users or customers of a
product to get feedback. The feedback can be gathered about needs/opportunities/ problems to identify
requirements, or can be gathered to validate and refine already elicited requirements.

Interface analysis: Interfaces for a software product can be human or machine. Integration with external
systems and devices is just another interface. User centric design approaches are very effective at making
sure that we create usable software.

Interview: Interviews of stakeholders and users are critical to creating the great software. Without
understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy
them. We also have to recognize the perspective of each interviewee, so that, we can properly weigh and
address their inputs.

Observation: By observing users, an analyst can identify a process flow, steps, pain points and
opportunities for improvement. Observations can be passive or active (asking questions while observing).
Passive observation is better for getting feedback on a prototype (to refine requirements), where active
observation is more effective at getting an understanding of an existing business process.

Prototyping: Prototyping is a relatively modern technique for gathering requirements. In this approach, you
gather preliminary requirements that you use to build an initial version of the solution - a prototype. You
show this to the client, who then gives you additional requirements. You change the application and cycle
around with the client again.

Requirement Workshops: Workshops can be very effective for gathering requirements. More structured
than a brainstorming session, involved parties collaborate to document requirements. One way to capture
the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams).

Reverse Engineering: When a migration project does not have access to sufficient documentation of the
existing system, reverse engineering will identify what the system does. It will not identify what the system
should do, and will not identify when the system does the wrong thing.

Page 8
Survey/Questionnaire: When collecting information from many people – too many to interview with
budget and time constraints – a survey or questionnaire can be used. The survey can force users to select
from choices, rate something (“Agree Strongly, agree…”), or have open ended questions allowing free-form
responses.

1.2.2 Some requirement gathering techniques:

1.2.2.1 Interviews[2]

1.2.2.1.1 Definition
Interview is a method of collecting information through many different ways. But it is often a question-and-
answer interview, in the way a person interviews a person or an interviewer withmany people.
Respondents' answers reflect their views, consciousness, qualifications and actions. The interviewer must
prepare the basic steps for the interview process: Select the appropriate audience to interview, design
interview questions, prepare for the interview, conduct interviews and follow up after the interview.

1.2.2.1.2 Advantage and Disadvantage [3]

1.2.2.1.2.1 Advantage
• It provides flexibility to the interviewers
• The interview has a better response rate than mailed questions, and the people who cannot read
and write can also answer the questions.
• The interviewer can judge the non-verbal behavior of the respondent.
• The interviewer can decide the place for an interview in a private and silent place, unlike the ones
conducted through emails which can have a completely different environment.
• The interviewer can control over the order of the question, as in the questionnaire, and can judge
the spontaneity of the respondent as well.

1.2.2.1.2.2 Disadvantage
• Conducting interview studies can be very costly as well as very time-consuming.
• An interview can cause biases. For example, the respondent’s answers can be affected by his
reaction to the interviewer’s race, class, age or physical appearance.
• Interview studies provide less anonymity, which is a big concern for many respondents.
• There is a lack of accessibility to respondents (unlike conducting mailed questionnaire study) since
the respondents can be in around any corner of the world or country.

Page 9
1.2.2.2 Joint Applicaton Development [4]

1.2.2.2.1 Definition
Joint Applicaton Development (JAD) is a process that accelerates the design of information technology
solutions. JAD uses customer involvement and group dynamics to accurately depict the user's view of the
business need and to jointly develop a solution. Before the advent of JAD, requirements were identified by
interviewing stakeholders individually. The ineffectiveness of this interviewing technique, which focused on
individual input rather than group consensus, led to the development of the JAD approach.

1.2.2.2.2 Advantage and Disadvantage [5]

1.2.2.2.2.1 Advantage
• Time Saving: All of the stakeholders are in the same place at the same time with no outside
distractions. This enables the group to reach consensus on the requirements of the system much
faster. System requirements are documented as they are determined, therefore the development
process is significantly speeded up.
• Cost Saving: Reduced cost is a result of an accelerated analysis and design process.
• Ownership of the System: Due to the interactive nature of a JAD, all issues and ideas can be
discussed resulting in a system that meets everyone's expectations.

1.2.2.2.2.2 Disadvantage:
• Time commitment: Depending on the size of the project, a JAD may require a significant time
commitment. All JAD participants must be able to meet at the designated times and will need to
suspend all other activities for these periods.
• JAD commitment: The organization must have a clear understanding of the approach and guidelines
of a JAD. A JAD can only produce effective and productive results if the organization is firmly
committed to this approach.

1.2.2.3 Questionaires:

1.2.2.3.1 Definition
The use of questionnaires is an information-gathering technique that allows systems analysts to study
attitudes, beliefs, behavior, and characteristics of several key people in the organization who may be
affected by the current and proposed systems. Attitudes are what people in the organization say they want
(in a new system, for instance); beliefs are what people think is actually true; behavior is what
organizational members do; and characteristics are properties of people or things.

Page 10
1.2.2.3.2 Advantage and disadvantage [6]

1.2.2.3.2.1 Advantage
• Questionnaires are inexpensive: questionnaire cost efficient questionnaires are one of the most
affordable ways to gather quantitative data.
• Questionnaires are practical: Apart from being inexpensive, questionnaires are also a practical
way to gather data. They can be targeted to groups of your choosing and managed in various
ways.
• Questionnaires offer a quick way to get results: It’s quick and easy to collect results with online
and mobile tools. This means that you can gain insights in as little as 24 hours
• Scalability: Questionnaires and surveys allow you to gather information from a large audience.
• Compatability: When data has been quantified, it can be used to compare and contrast other
research and may be used to measure change. This makes monthly or yearly questionnaire more
and more valuable over time.

1.2.2.3.2.2 Disadvantage
• Dishonest answers: While there are many positives to questionnaires, dishonesty can be an issue.
• Unanswered questions: When using questionnaires, there is a chance that some questions will be
ignored or left unanswered.
• Differences in understanding and interpretation: The trouble with not presenting questions to users
face-to-face is that each may have different interpretations of your questions.
• Some questions are difficult to analyze: Questionnaires produce a lot of data. Multiple choice
questions can be tabulated and graphed, but open-ended questions are different.
• Open-ended questions allow for individualized answers which cannot be quantified and must be
reviewed by a human.

1.2.2.4 Document analysis [7]

1.2.2.4.1 Definition
Document analysis is a form of qualitative research that uses a systematic procedure to analyze
documentary evidence and answer specific research questions. Similar to other methods of analysis in
qualitative research, document analysis requires repeated review, examination, and interpretation of the
data in order to gain meaning and empirical knowledge of the construct being studied.

Page 11
1.2.2.4.2 Advantage /disadvantage [8]:

1.2.2.4.2.1 Advantage
• Effectively: this is the way of gathering data because documents are manageable and practical
resources. Documents are commonplace and come in a variety of forms, making documents a very
accessible and reliable source of data. .
• Stability: documents are stable, “non-reactive” data sources, meaning that they can be read and
reviewed multiple times and remain unchanged by the researcher’s influence or research process

1.2.2.4.2.2 Disadvantage
• Not prefectly: A document will not perfectly provide all of the necessary information required to
answer your research questions. Some documents may only provide a small amount of useful data
or sometimes none at all. Other documents may be incomplete, or their data may be inaccurate or
inconsistent.
• Not available to access: sometimes there are gaps or sparseness of documents, leading to more
searching or reliance on additional documents then planned

1.2.2.5 Observation [9]:

1.2.2.5.1 Definition
An observation is a data collection method, by which you gather knowledge of the researched
phenomenon through making observations of the phenomena, as and when it occurs. You should aim to
focus your observations on human behaviour, the use of the phenomenon and human interactions related
to the phenomenon. You can also make observations on verbal and nonverbal expressions.

1.2.2.5.2 Advantage/Disadvantage

1.2.2.5.2.1 Advantages
Very direct method for collecting data or information – best for the study of human behavior.

• Data collected is very accurate in nature and also very reliable.

• Improves precision of the research results.
• Problem of depending on respondents is decreased.

1.2.2.5.2.2 Disadvantages of Observation

• Problems of the past cannot be studied by means of observation.
• Having no other option one has to depend on the documents available.

Page 12
 • Observations like the controlled observations require some especial instruments or tools for
effective working, which are very much costly.
• One cannot study opinions by this means.

1.2.3 Conclusion the techniques that suitable with the Tune Source

Because this project is very current, it appears on some shopping online website, so that is not new ideas.
Moreover, the business requirement of the Tune Source project is very clear to help my team to
implemment in real environment. And I decide to choose Document analysis and Interviews for the
technique of the Tune Source because, the way is easy to implement, we can collect the information from
the stakeholder to do the project which have the evidence of the reliable and stable when it works.
Moreover, when using this method, the requirement will meet with the demand of the customer, by that,
avoid some unexpect mistakes and avoid the theft from the emails or messages to ensure the protect
necessary data and information.

2 P6 Use appropriate software analysis tools/techniques to carry out a software investigation and create
supporting documentation.
2.1 Introduction [11]

Structured analysis is a development method that allows the analyst to understand the system and its
activities in a logical way.

It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing
system and develop a new system specification which can be easily understandable by user.

2.2 Tool and techniques

During Structured Analysis, various tools and techniques are used for system development.

2.2.1 Data Flow Diagrams [12]

2.2.1.1 Introduction:
• It is a technique developed by Larry Constantine to express the requirements of system in a
graphical form.
• It shows the flow of data between various functions of system and specifies how the current system
is implemented.

Page 13
 • It is an initial stage of design phase that functionally divides the requirement specifications down to
the lowest level of detail.
• Its graphical nature makes it a good communication tool between user and analyst or analyst and
system designer.
• It gives an overview of what data a system processes, what transformations are performed, what
data are stored, what results are produced and where they flow.

2.2.1.2 Data flow diagram level 0 and level 1 for the Tune Source projecy

2.2.1.2.1 Data flow diagram level 0

Figure 1: DFD level 0 of Tune Source project.

2.2.1.2.2 Data flow diagram level 1

Add song:

Page 14
 Figure 2: DFD level 1 of Add song function.

Create account

Figure 3: DFD level 1 of Create account function.

Login

Figure 4: DFD level 1 of Login function.

Purchase gift card

Figure 5: DFD level 1 of Purchase giftcard function.

2.2.2 Entity relationship diagram:

2.2.2.1 Introduction
An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database. An entity
in this context is an object, a component of data. An entity set is a collection of similar entities. These
entities can have attributes that define its properties.

Page 15
By defining the entities, their attributes, and showing the relationships between them, an ER diagram
illustrates the logical structure of databases. ER diagrams are used to sketch out the design of a database.

2.2.2.2 ERD for the Tune Source project [13]

Figure 6: ERD for the Tune Source project

2.2.3 Flowchart:

2.2.3.1 Introduction [14]

A flowchart is a picture of the separate steps of a process in sequential order. It is a generic tool that can be
adapted for a wide variety of purposes, and can be used to describe various processes, such as a
manufacturing process, an administrative or service process, or a project plan. It's a common process
analysis tool and one of the seven basic quality tools.

Elements that may be included in a flowchart are a sequence of actions, materials or services entering or
leaving the process (inputs and outputs), decisions that must be made, people who become involved, time
involved at each step, and/or process measurements.

Page 16
2.2.3.2 Flowchart for the Tune Source project:

Figure 7: Flowchart for the Tune Source project.

2.2.4 Pseudocode

2.2.4.1 Introduction
In computer science, pseudocode is a plain language description of the steps in an algorithm or another
system. Pseudocode often uses structural conventions of a normal programming language, but is intended

Page 17
for human reading rather than machine reading. It typically omits details that are essential for machine
understanding of the algorithm, such as variable declarations and language-specific code. The
programming language is augmented with natural language description details, where convenient, or with
compact mathematical notation. The purpose of using pseudocode is that it is easier for people to
understand than conventional programming language code, and that it is an efficient and environment-
independent description of the key principles of an algorithm

2.2.4.2 Pseudocode example for the Tune Source project

Add shopping cart pseudocode

Figure 8: Add shopping cart.

Remove shopping cart

Page 18
 Figure 9: Remove shopping cart

3 P7) Explain how user and software requirements have been addressed.
3.1 Introduction [15]

User requirements are typically written when discussing the use cases for a project. The requirements
definition is done with the customer or product managers that know how the embedded system will be
used by the user.

Many user requirements deal with how a user will interact with a system and what that user expects. If
there is a screen or human machine interface aspect to the system, a user requirement may be based on
what happens when the user selects an action on the screen. Maybe with a button press not only does a
process start, but it also switches to another screen and provides an audible notification. When user
requirements such as these are written down, they can often break into multiple system requirements
later due to switching of screens, the maximum delays in starting the process, and finally what the next
screen should look like. One pitfall is starting to try to write the system requirements during a user
requirement meeting. This often detracts from gaining insight into the requirements of the user, and key
functionality pieces could be missed.

Page 19
3.2 Identifying the Major Use Cases

Figure 10: Major Use case diagram.

3.3 Elaborating on the Use Cases

Figure 11: Elaborating of purchase individual downloads.

Figure 12: Elaborating of purchase music download gift cards.

Page 20
 Figure 13: Elaborating of establish an account.

Figure 14: Elaborating of view shopping cart.

Figure 15: Elaborating of Add song.

4 Reference
1. Guru99.com. 2020. What Is Non-Functional Requirement? Types And Examples. [online] Available at:
<https://www.guru99.com/non-functional-requirement-type-example.html> [Accessed 26 October 2020].
2. Martymodell.com. 2020. The Interview And Other Data Gathering Methods. [online] Available at:
<http://www.martymodell.com/pgsa2/pgsa07.html> [Accessed 26 October 2020].
3. Group, S., 2020. Advantages And Disadvantages Of Interview In Research. [online] Sociology Group: Sociology
and Other Social Sciences Blog. Available at: <https://www.sociologygroup.com/advantages-disadvantages-
interview-research/> [Accessed 26 October 2020].
4. Umsl.edu. 2020. Joint Application Development (JAD). [online] Available at:
<https://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm> [Accessed 26 October 2020].
5. Dlsweb.rmit.edu.au. 2020. Joint Application Development. [online] Available at:
<http://www.dlsweb.rmit.edu.au/Toolbox/knowmang/content/gathering_data/jad.htm> [Accessed 26 October
2020].
6. Survey Anyplace. 2020. 10 Advantages And Disadvantages Of Questionnaires - Survey Anyplace. [online]
Available at: <https://surveyanyplace.com/questionnaire-pros-and-cons/> [Accessed 26 October 2020].
7. Methods.sagepub.com. 2020. Standard Error Of Measurement - SAGE Research Methods. [online] Available at:
<https://methods.sagepub.com/Reference/the-sage-encyclopedia-of-educational-research-measurement-
and-evaluation/i19746.xml> [Accessed 26 October 2020].
8. Lled500.trubox.ca. 2020. An Introduction To Document Analysis – Research Methodology In Education. [online]
Available at: <https://lled500.trubox.ca/2016/244> [Accessed 26 October 2020].
9. Keyword-suggest-tool.com. 2020. ™ "Observation Data Collection Method" Keyword Found Websites Listing |
Keyword Suggestions. [online] Available at: <https://www.keyword-suggest-
tool.com/search/observation+data+collection+method/> [Accessed 26 October 2020].

Page 21
10. Slideshare.net. 2020. MBA Notes Research Methodology. [online] Available at:
<https://www.slideshare.net/shakehandwithlife/notes-research-methodology-sem-iii-mba-mdu-rohtak-dde>
[Accessed 26 October 2020].
11. Tutorialspoint.com. 2020. Structured Analysis - Tutorialspoint. [online] Available at:
<https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_structured.htm>
[Accessed 26 October 2020].
12. Tutorialspoint.com. 2020. System Analysis And Design Tutorial - Tutorialspoint. [online] Available at:
<https://www.tutorialspoint.com/system_analysis_and_design/index.htm> [Accessed 26 October 2020].
13. Smartdraw.com. 2020. Entity Relationship Diagram (ERD) - What Is An ER Diagram?. [online] Available at:
<https://www.smartdraw.com/entity-relationship-diagram/> [Accessed 26 October 2020].
14. Asq.org. 2020. What Is A Flowchart? Process Flow Diagrams & Maps | ASQ. [online] Available at:
<https://asq.org/quality-resources/flowchart> [Accessed 26 October 2020].
15. Sciencedirect.com. 2020. User Requirement - An Overview | Sciencedirect Topics. [online] Available at:
<https://www.sciencedirect.com/topics/engineering/user-requirement> [Accessed 26 October 2020].

Page 22