ASSIGNMENT 2 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and title Unit 9: Software Development Life Cycle

Submission date 16/12/2019 Date Received 1st submission

Re-submission Date Date Received 2nd submission

Student Name Nguyen Van Loc Student ID GCD18350

Class GCD0703 Assessor name Srikanth Raju Kandukuri

Student declaration

I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that
making a false declaration is a form of malpractice.

Student’s signature Văn lộc

Grading grid

P5 P6 P7 M3 M4 M5 M6 D3 D4
❒ Summative Feedback: ❒ Resubmission Feedback:

Grade: Assessor Signature: Date:

Signature & Date:
 ASSIGNMENT REPORT
SOFTWARE DEVELOPMENT LIFE CYCLE
(SDLC)

UNIVERSITY: UNIVERSITY OF GREENWICH VIET NAM

CLASS: GCD0703

NAME: NGUYEN VAN LOC

MENTOR: Srikanth Raju Kandukuri

EMAIL: locnvgcd18350@fpt.edu.vn
TABLE OF CONTENTS
TABLE OF CONTENTS............................................................................................................................................................. 4
TABLE OF FIGURE.................................................................................................................................................................... 4
TABLE OF TABLE...................................................................................................................................................................... 5
I. Task 1:.............................................................................................................................................................................. 5
1. Interview:............................................................................................................................................................... 5
2. Questionnaire:................................................................................................................................................... 10
3. JAD (Joint Application Development):..................................................................................................... 12
4. Observation method:...................................................................................................................................... 14
5. Documentation analysis:............................................................................................................................... 16
II. Task 2:........................................................................................................................................................................... 18
1. Use case:.............................................................................................................................................................. 18
2. Entity Relationship Diagram (ERD):........................................................................................................ 21
3. Data Flow Diagram (DFD):........................................................................................................................... 22
III. Task 3:....................................................................................................................................................................... 24
1. Flowchart Diagram:........................................................................................................................................ 24
2. Behavioral State Machine Diagram:......................................................................................................... 25
3. Reliability of Tune Source............................................................................................................................. 25
IV. Task 4:....................................................................................................................................................................... 26
Traceability Matrix:..................................................................................................................................................... 26

TABLE OF FIGURE
Figure 1: Sample Interview Schedule............................................................................................................................... 6
Figure 2: Sample interview report.................................................................................................................................... 8
Figure 3: JAD Meeting Room............................................................................................................................................. 12
Figure 4: a Document Analysis......................................................................................................................................... 17
Figure 5: Relationship Diagram....................................................................................................................................... 21
Figure 6: Context Diagram................................................................................................................................................. 22
Figure 7: DFD fragment for Search and Browse Songs........................................................................................... 22
Figure 8: DFD fragment for Purchase Songs............................................................................................................... 23
Figure 9: Flowchart for Search and Browse Songs................................................................................................... 24
Figure 10: Behavioral State Machine Diagram for a Customer Purchase.......................................................25
Figure 11: Example of RTM................................................................................................................................................ 27

TABLE OF TABLE
Table 1: Pros and Cons of Interview................................................................................................................................. 8
Table 2: Pros and Cons of Questionnaire..................................................................................................................... 11
Table 3: Pros and Cons of JAD........................................................................................................................................... 14
Table 4: Pros and Cons of Observation method......................................................................................................... 16
Table 5: Pros and Cons of Documentation analysis................................................................................................. 18
Table 6: Search and browse songs.................................................................................................................................. 19
Table 7: Purchase songs...................................................................................................................................................... 20

I. Task 1:
The first stage in any Software Development Lifecycle is identifying requirements. In many ways,
identifying requirements is the most important aspect of the entire SDLC. Although it can be done in
a limited way when the team uses the RAD or agile development method, the traditional methods
still invest considerable time in this step to better understand customer requirements and identify
improvements before moving on to the next stage. However, this is not an easy process because
analysts cannot easily gather actual requirements after a few conversations with stakeholders.
Therefore, the best analysts will apply some techniques to assist in extracting this request. Some
techniques are presented below.

1. Interview:
Interviews are the most commonly used method of gathering requests. Basically, an interview is
a process of asking and answering, which means that if you want to know something, you ask
someone. This technique can be used to validate facts, eliminate ambiguity, trigger enthusiasm,
engage end users, identify requests and solicit ideas and ideas. Generally, interviews are conducted
one - on - one face to face (one interviewer and one interview), but sometimes, due to time
constraints, several people are interviewed at the same time. There are five basic steps to the
interview process: selecting stakeholders to interview, designing interview questions, preparing for
interviews, conducting interviews, and follow-up interviews.

I.1. Selecting Interviewees

The main task of this step is to create a list called the interview schedule, which lists the people
to be interviewed, briefly describing the purpose of the interview, the time and place of the
interview.
 Figure 1: Sample Interview Schedule.

Because people in different positions may have different perspectives on the system, it is
important to include them in the interview to create more useful insights at both the low and upper
levels. When you interview people, you may identify additional information as needed and
additional people can provide information.

I.2. Interview Questions:

There are three types of interview questions that are often asked in an interview to collect requests.
They are closed, open and exploration questions.

 Closed questions: These are questions that are similar to multiple choice questions in a test.
They are used when interviewers need specific, accurate information. For example, it's better
to ask how many calls do you answer each day? Instead of asking, can you answer many calls
per day? This type of question helps analysts control the interview and get the information
they need. However, asking these questions can only get answers to what and why not.
 Open-ended questions: This type of question requires more in-depth answers and longer
answers. These questions are similar in many ways to an essay question in a test. They are
questions designed to gather rich information and give the interviewee more control over
the information revealed in the interview. Sometimes, such a question What should I ask?
Can trigger interesting discussions on various issues.
 Poll question: The third type of question, the probing question, usually tracks what has been
discussed whenever the interviewer feels ambiguous about the respondent's answer. These
questions are intended to help the interviewee think more thoroughly about the current
issue and encourage them to expand or confirm the information provided in the previous
answers. Therefore, helping analysts dig deep into the surface and gain more valuable
information. When you interview people, you may identify additional information as needed
and additional people can provide information. For example, a question could you explain in
a bit more detail?
 Another important factor is that your questions should predict what type of information the
interviewee is likely to know. Senior managers may not be able to answer questions about the
details of daily business processes while low-level employees may not be able to answer broad
policy-oriented questions. An appropriate combination of matching questions is what should be
asked in an interview to elicit as much information as possible.

I.3. Prepare to interview:

For the interview to run smoothly, it is necessary to have a common plan to outline the
questions in an appropriate order; predict possible answers and provide a way to track them; The
help of the switch between related topics. The plan also needs to determine the priority of the
questions in case of limited time.

Preparing for the interviewer is no less important than preparing for the interviewer. A notice
should be sent to inform the interviewee about the reason for the interview and the areas to be
discussed in advance are far enough to give the interviewee enough time to think about the issues
and to come. ranked their thoughts.

I.4. Conducted interviews:

Obviously, the main goal of any interview is to gather the necessary information, but to do that,
the first step is to reach an agreement in which the interviewer can ensure that the interviewee
willing to tell the whole story, not just the information they believe they want

According to studies, the best way to record all the valuable information that the interviewee
provides is to take notes carefully, which means writing down everything the interviewee said.
Although some things may not be relevant at first, they can still reveal important insights later. If the
interviewee and the organization's policies allow it, it is better to record the interview because the
recording ensures that no important points will be missed.

Finally, always be sure to clearly distinguish truth from opinion. For example, we handle too
many credit cards requests. This is an opinion rather than a fact. At this point, interviewers should
ask tentative questions like Hui How many people do you handle in a day? It is very important to
verify the truth because any difference between events and opinions can point out the main areas
for improvement.

I.5. Follow-up interview:

After the interview ends, the analyst should create an interview report summarizing the
information obtained from the interview in a useful format as shown below. In general, the report
should be written as soon as possible, because as time goes by, much information is likely to be
forgotten. It is ideal to write a report within 48 hours after the interview ends.
 Typically, respondents are required to read the report and inform the analyst if any clarifications
or updates are needed. Usually, there are a few changes, but the need for any significant change
indicates a second interview is needed.

Figure 2: Sample interview report.

Pros Cons
- Establishing relationships with stakeholders - Waste of time.
- Discover in-depth information. - Limited sample size.
- Provides excellent flexibility. - Enter data manually.
- Captures emotions and behavior. - Interview of interviewers.
- Select suitable candidates.
Table 1: Pros and Cons of Interview.

In order to meet all the requirements of Tune Source, we have choose the right solution to fit the
business requirement, such as interview, questionnaires, JAD, observation, etc… Getting through an
interview successfully is both an art and a science. There are a lot of unknowns, but focusing on key
areas or competencies and giving the right answers to the questions based on them in the interview
helps you get selected.

 Domain knowledge and skills:

 A good project manager should have 2 features—experience, as well as an in-depth
understanding of project management theories. While one without the other hinders performance,
in order to be the ideal project manager, you must have a solid foundation in project management
principles.

 Clear communication:

One of the most important skills for project managers is communication. Without this everything
else fails. Communication is the life and blood of any project. It’s claimed that about 90 percent of a
project manager’s time is spent communicating. In today's organizations, communication happens
between various groups and levels, including internal as well as external groups of stakeholders.

 Consistency and integrity:

Honesty and trustworthiness are of utmost importance in the world of business. Project
managers manage critical responsibilities and resources such as material, money, and human
resources. They also represent the organization to employees, customers, and vendors. They are
role models for their team members. Any lack of consistency and integrity can cost the organization
a lot more than money.

 Customer orientation:

Project managers are responsible for understanding the need of the customer and responding in
a timely, efficient manner in ways that meet customer expectations. They are also responsible for
establishing and maintaining effective relationships and gaining the trust and respect of customers.

 Developing others:

A project manager relies on their team to execute activities in order to achieve the desired
results. It is important that a project manager can assess talent, contribute actively towards
developing, mentor and coach team members and offer constructive feedback to them.

 Effective delegation:

One of the key success factors for a project manager is effective delegation. How effectively can
you get work done through others? Delegation must happen through empowerment without
interference or loss of control.

 Goal focus:

Being focused on goals is absolutely essential for project managers. You need a clear focus to
succeed. It is important for candidates to demonstrate the ability to align resources to achieve key
objectives, to plan and identify ways to improve and achieve greater efficiency and to monitor and
fine-tune execution with agility, hard work, perseverance, and good judgment.
 Managing ambiguity and risks:

A project manager has to deal with uncertainty. It is important that you can identify and
prioritize risks and take appropriate action in ambiguous situations. It is equally important to
manage others’ concerns in changing environments.

 Prioritizing and time management:

A project manager must tackle multiple tasks and issues. To be a successful project manager, you
have to choose your battles wisely. Since resources are always limited, they need to be prioritized.
Time is a valuable resource for the project because once lost it cannot be recovered easily. As a
result, time management is one of the key skills for any project manager

 Proactive decision making:

A project manager needs to be able to identify and prevent issues from impacting the project
adversely. It is important that the candidate demonstrates the ability to take proactive steps, avoid
procrastination, and not shy away from making tough decisions. Thus, candidates are often asked to
share examples and real-life scenarios from their projects and life where they made proactive
decisions

2. Questionnaire:
The questionnaire is a list of questions that some individuals are asked to obtain. In essence, it is
quite similar to a survey. Questionnaires are usually conducted to collect information and opinions
from a large number of people (e.g. customers or suppliers). There are four basic steps to the
question procedure.

2.1. Select participants:

As with the interview, the first stage is to select the people whose questions will be distributed.
However, selecting people who can provide profitable information is unrealistic. A standard
approach is to choose a sample or a subset of people who are able to provide information on behalf
of the entire group. It is important to realize that, unlike interviews, in the question method, not
every individual who receives the question will actually complete it. Statistically, only 30% -50% of
paper and e-mail questions are answered and this percentage is even lower for web-based
questions with only 5% -30%.

2.2. Questionnaire design:

Asking the right questions is important for effective questionnaire. The questions must be
clearly written and minimize the likelihood of being misunderstood; Therefore, closed questions are
more appropriate. These questions are supposed to help analysts separate facts from opinions. Here
are some guidelines for designing questionnaires that can be very helpful.
  Start with these tough and interesting questions to get the attention of your respondents.
 Group related questions into streamlined sections to make them simpler to answer.
 Do not put important items at the end of the question.
 Do not put too many items in one page.
 Avoid abbreviations. Avoid misunderstandings.
 Avoid questions or biased questions with suggestion options
 Number of questions to avoid confusion.
 Pre-order questions to identify confusing questions.
 Provide anonymity for respondents.

2.3. Managing questionnaires:

The key element in this step is to get participants to complete the questionnaire and then send it
back. Commonly used techniques include clearly explaining the purpose of the questionnaire and
the reasons for choosing participants; specify the due date; giving gifts to complete questionnaires
(for example, free keychains); etc.

2.4. Questionnaire Follow-up:

In this step, the analyst will issue a questionnaire report shortly after the question expiry. Doing
so ensures that the process for requesting claims is carried out in a timely manner and that
participants who request copies of results can receive them without delay.

Pros Cons
- Cost and time efficient. - Can provide dishonest answers and invalid
- National or even international insurance. information.
- Less pressure on respondents. - Some questions may be ignored or not
- Anonymity available. answered.
- Simple to administer and analyze. - Cannot fully capture emotional or
- Easy and fast for participants to complete. emotional responses.
- Lack of personal contact.
- Not suitable for complex projects.
Table 2: Pros and Cons of Questionnaire.

On the other hand, questionnaire is a tool to ask interviewees. There are two types of question,
closed question and opened question. Closed question usually followed by available answer is a
common type in questionnaires. Opened question demand further explore by questionnaire. In
order to get information as much as possible, opened question is suggested because it motivate
people to answer in their own idea, their own feelings. Here some example questions:

 What is the main aim of the Tune Source? How many employees or clients Tune Source may
recruit?
 What type of technologies does Tune Source use? Is there another efficient way?
 How to improve customer experiences?
 How Tune Source can sell it product to the customer?
 3. JAD (Joint Application Development):
JAD is a common development method used in request elicitation to allow project teams, users,
and management to collaborate in identifying system requirements. In fact, since being developed in
the late 1970s, it is often the most useful method to retrieve information from users. This technique
is claimed to be able to reduce the climbing range by 50% and avoid requirements that are too
specific or too vague.

In this method, a team of 10-20 users gather around and discuss system requirements with the
help of experienced neutral supporters of JAD techniques. This person will plan the meeting and
guide the discussion. However, he or she may not provide ideas or opinions and remain neutral
during the sessions. It is essential that the coordinators are skilled in both system analysis and
technical design and the dynamic group s and can speak both client and developer languages. The
coordinator usually has one or two note takers supporting him by using computers and CASE tools
to record information when the JAD session takes place.

Figure 3: JAD Meeting Room.

 There is another type of JAD that does not require everyone to meet in the meeting room. It is
called electronic JAD, or e-JAD. In this method, each participant participates in the session through a
specialized software on a networked computer and anonymously discusses topics es with others.
This technique also tackles the problem of traditional groups, where people are hesitant to ask
questions about the opinions of others, especially their bosses.

 3.1. Select participants:

There is not much difference in the selection of participants between JAD techniques and
interviews. This step is based on information that participants can provide, from low to high levels.
However, unlike an interview, having all JAD participants leave their office at the same time can be a
big problem. Therefore, strong management support and an expert on JAD or e-JAD techniques is
important for the JAD sessions to proceed adequately.

3.2. JAD Session design:

The duration of JAD sessions can last from a few hours to several weeks depending on the size
and scope of the project. In general, JAD or e-JAD sessions are likely to end within 1 to 3 weeks. The
output of this technique is not only to collect information but also to analyze distribution. Here are
some general guidelines to follow when designing JAD sessions.

 Review the project scope, objectives and definition documents.

 Engage stakeholders, including sponsors and project managers, technology writers, and
topic experts as part of the project team.
 Plan these sessions in a structured manner.
 Limit the use of closed-ended questions because they do not encourage open and candid
discussions that are the essence of JAD.
 A top-down approach is recommended
 JAD teams must have the support of senior management, both to allow time and effort,
and accept the team's conclusions and results.
 Ensure that each stakeholder has an empowered representative to make decisions in JAD
sessions. Middle management is preferred over executives.
 It is extremely important that each session creates JAD minutes, including the
participants' resolutions, action items, and open issues. These copies will be sent to all
team members and managers to maintain project motivation, accountability, political
vision and to avoid redo and shift priorities.
 Distribute your time wisely throughout the day as participants get tired easily.

3.3. Prepare for the JAD Session:

It is especially important to prepare analysts and participants, such as in interviews. In order for
the JAD sessions to be conducted successfully, ensuring that participants are aware of what is
expected of them is indispensable. If the goal is to improve the current system, participants should
think about how they will improve the system before the JAD session.
 3.4. Conducting JAD Session:
JAD sessions should strictly follow the basic rules defined during the design phase such as
following the schedule, respecting the opinions of others, not insulting individuals, accepting
disagreements and only having One person talks at a time. The coordinator is responsible for the
three main functions.

 Make sure the team is on the agenda. In any case, the team should not follow up unless
everyone agrees that the JAD session has generated some unexpected new information
and requires the JAD session (and perhaps the project) to move in a new direction.
 Help the group understand the technical jargon and jargon that surrounds the system
development process. He should also minimize the learning needed and guide
participants to provide information effectively.
 The information structure is provided on a public display area (for example, whiteboards,
flip charts or computer screens) so the team can identify the main problems and
resolutions.

Often, JAD participants can deploy a number of tools to help them fully identify the new system.
These tools can be use cases, diagrams, prototypes, etc. Everything is allowed as long as they are
useful in clarifying and defining requirements for the new system. Another factor that should not be
forgotten is that sessions are held only when all decision makers are present.

3.5. Post-JAD Follow-up:

After the JAD sessions are finished, a report is created and distributed among the session
attendants. Basically, the post-JAD report is similar to the interview report, however, because the
JAD sessions are longer and have more information, it can take up to one or two weeks to Prepare
report.

Pros
- Speed up the design.
- Generating a relatively large amount of high-
quality information.
- Promote teamwork with customers.
- Create a design from a customer's point of
view.
- Reduce development and maintenance costs.
- Allow primary users to participate
effectively.
- Discover many views on a topic.
Table 3: Pros and Cons of JAD.
Cons
- Trouble if the group is too big.
- Difficult to set goals and maintain focus
when there are too many different ideas.
- Depending on the size of the project, JAD
may require a significant time commitment.
- Selected participants can change or bias the
outcome.
- Request significant planning and planning
efforts.
- Request a skilled instructor

4. Observation method:
Observing, as the name implies, is the act of seeing what already exists to bring about greater
value insights in the current system. Observation is a more positive technique to elicit quality
requirements that allows analysts to look at the actual operation of existing installed systems,
instead of passively listening to others describing the interviews or JAD sessions.

In fact, most managers and employees find it difficult to remember how they work and how they
allocate time. It is even harder to explain to others. That is when observation is utilized. It is a good
way to supplement or verify the legality of information obtained in other techniques such as
interviews or JAD sessions.

Observations are not divided into separate steps like other techniques because the process will
vary depending on the target being monitored. Some basic rules that the analyst must keep in mind
when using this technique are: keep a low profile and do not interrupt, do not interfere, do not affect
the object being observed. It is also necessary to realize that observation results may not be a
normal daily routine because people tend to adjust the way they perform tasks when they know
they are being followed.

In most cases, observations will support the information users provide during interviews. When
not, it is an important signal that more careful analysis of business systems is needed.

• Identify objects: Determine what and why you want to watch. Do students want to see how
they react to a new environment? How do clients interact with staff? How do the bosses
interact? When you do observe, in order to better understand their practices and, hopefully,
why they are doing so, you try to learn habits, patterns, conduct, reactions and general
information on people in a given environment (although observations alone often do not tell
you the "why').
• Establish Recording Method: It is important to minimize and eliminate any disturbing, or
unfamiliar devices in the environment you want to observe to make observations most
effective. For example, video recordings are often less effective when the observed persons
are aware that they are filmed (but it is often unethical to film without saying so. Taking note
is the most common method, although photographs, auditory recordings and other methods
can be taken in certain public spaces.
• Develop questions and techniques: Determine whether you're making an informal or formal
observation (see explanations at the far right). Know your goal, determine whether you have
particular questions or are fully open-minded. What you hope to learn will help you to know
what 5 you are looking for specifically. Be ready to use the type of information you are
attempting to learn when entering an observation area.
• Observe and take note: Visit the room from which you hope to receive information. Be as
discreet as possible, take notes, photographs, audio and movies just when permitted, and it
does not disturb the environment. You have permission to do the research. You must code
certain actions, actions, words, visuals and other observed data in formal observations. If you
make formal observations.
• Analyze Behaviors and Inferences: Distinguish what you observed (which is factual
behavior) from why you observed. Usually you need to interview people, either during the
 observation itself or afterwards, for a sense of your observed data. Connect interactions,
responses, conduct and other phenomena.

Pros
- Obtain fairly reliable information.
- Extract information on physical
environment (e.g. noise level, flow, etc.)
- Relatively economic.
- A allows the analyst to make job
measurements.
- Improve accuracy
- Access to practical situations.
Table 4: Pros and Cons of Observation method.
Cons
- Difficult to grasp information in a session.
- Observers may only see what they want
and expect to see, not the big picture.
- May involve significant amount of time.
- Complete answers to any problems or any
problems that may be obtained by
observation alone.

5. Documentation analysis:
Document analysis is a crucial step in project management analysis. Project managers peruse
documents to get information about the current status of the project. The thing is that project
managers need to study different documents in order to understand what the operation is all about.

Analyzing documents give project managers a good sense of what the project is all about.
Document analysis is used to determine requirements by analyzing the existing documents. This
process also identifies the types of information that are important to the requirements. There are
numerous types of documents that are analyzed in project management to draw out the important
requirements. These include business plans, contractual agreements, marketing literature, requests
for proposal, logical data models, current process flows, business rule repositories, application
software documentations, interface documentation, policies, work procedures, requirement
documentations and other regulatory documentations like ordinances and local codes. It is
important to gather the necessary information first before organizing or scheduling an interview
with the stakeholders.

Document analysis is done in three stages. The first stage is the preparation stage which involves
the identification of materials that are suitable for relevant analysis. This is followed by the review
stage which involves studying the material and listing down questions for the stakeholders. Lastly,
the wrap-up stage involves reviewing the notes with the stakeholders and seeking answers to the
follow-up questions raised during the meeting.

Document analysis is very useful for the organization. It ensures that the project manager does
not work initially with a blank page. Having a data or information that can back him or her up is
crucial for effective project planning. However, it is important that the documents that the project
manager is analyzing are updated to reflect the current situation of the project otherwise bad
decisions are likely to be made.

Document analysis is a common investigation method that focuses on the compilation and
analysis of organizational records, data documents, and existing documents. Although some
definitions of the document analysis process can separate it into smaller steps, most are not.
Basically, it is just a process of reviewing any document that exists, evaluating a review and
ultimately creating new insights. In other words, document work involves reading a lot of written
material. Types of documents that can be checked include paper reports, memos, policy guides, user
training guides, organizational charts, forms, project descriptions, etc.

Unfortunately, these documents often contain information, or may not even be enough, of the
official system because the information of most systems is not well documented and updated about
recent changes. These differences, especially large differences, are strong signals that they need to
be considered for modification. Below is an example of how a document can be analyzed.

Figure 4: a Document Analysis

Pros Cons
 - Using existing information is usually cheap
and often free.
- Limit the interruption of daily routines.
- The data source is stable, unchanged and
can be reviewed many times.
- May complement other required evocative
methods.
Table 5: Pros and Cons of Documentation analysis.
- May not be flexible, incomplete, inconsistent.
- Information is limited to what already exists.
- Ineffective if existing documents are not
enough.
- It may take time.
- Unsuitable for evaluating user comments,
needs, or satisfaction with the service.
- Some documents may be sensitive and not
public

II. Task 2:
After investigated for business need, it is time to carry out a software investigation and create
supporting documentation in order to find out new situation in the future that Tune Source may
encounter.

1. Use case:

Use Case Name: Search and browse songs ID: TH-01 Priority: High

Actor: Customer

Description: This use case describes a customer who searches and browses through Tune Source
online app or site

Trigger: Customer accesses to app or web site to search and browse

Type: External

Preconditions:
1. App and website are available.
2. Tune Source databases is online and always update.

Normal Course:
1. System displays default homepage
2. Customer visit the website
3. Customer login with their account username and password
4. Customer select how to search for songs (title or artist or genre)
5. System displays titles that are matching search request
6. Customer enter search request
7. Customer select a title
8. Customer add the song to Favorites or remove it from Favorites or place it in shopping cart or
remove it from shopping cart.
9. System play a short sample of the selected song
Postconditions:
1. Systems recorded information about selected samples into customer’s Interests
2. Customer’s Favorites list might be modified.
3. Customer’s shopping cart list might be modified.

Exceptions:
E1: Login error
1. System displays message that username/password is not valid.
2. System asks Customer to re-enter username/password or contact customer service for help.

E2: Search request returns no results

1. System displays message that no results were found for that search
2. System asks Customer to try another search

Table 6: Search and browse songs

Use Case Name: Purchase songs ID: TH -02 Priority: High

Actor: Customer

Description: This use case describes the process of how a customer buy and download selected
songs

Trigger: Customer accesses to app or website to search and browse

Type: External

Preconditions:
1. Customer's cart contains one or more selections.
2. Customer is ready to proceed with payment.

Normal Course:
1. Customer go to payment page
2. System collects payment information or account information
3. System collects payment authorization
4. System displays shopping cart contents with price of each song and total price included
5. Customer verifies purchase authorization
6. Customer confirm payment transaction
7. System processes payment
8. System confirms payment acceptance
9. System removes items from shopping cart
10. System added songs to customer’s playlist
 11. System enables users to listen to and download the full version of the titles that were bought

Postconditions:
1. Shopping cart is empty
2. Songs is recorded
3. Sales transaction is recorded

Exceptions:
E1: Login error
1. System displays message that username/password is not valid.
2. System asks Customer to re-enter username/password or contact customer service for help.

E2: Search request returns no results

1. System displays message that no results were found for that search
2. System asks Customer to try another search

Table 7: Purchase songs.

II.1. Search and browse songs

The main trigger of this use case is the appearance of customers on the Tune Source website.
Although the actor is called a direct customer, he or she is not required to purchase. The
prerequisite is that the website and database are available, which means that customers can browse
through the select categories listed on the page. The system will display the default home page for
the firsts time access and custom page features matching options to old customers' s based on their
previous benefits. Customers can also access their favorite playlists, including paid songs and no
songs, after logging into the system. Because users do not follow a specific pattern, the order of
steps in the Regular Courses section is performed unchanged at all times. Each step is an
independent part of the other. Postconditions points to several things that can happen due to this
use case.

II.2. Purchase songs

Because the actors are here, Customers, try to buy the song (s), a prerequisite is to have at least
one item in the cart. After the customer has determined that he is ready to buy, he must provide
payment information and then the system will store payment information in the user account. After
the payment information is verified, the customer authorizes the transaction, the new purchase
information is recorded in the sales file and the tone is released for customers to download.
2. Entity Relationship Diagram (ERD):

Figure 5: Relationship Diagram.

 3. Data Flow Diagram (DFD):

3.1. Context Diagram:

Figure 6: Context Diagram.

3.2. DFD Fragment:

Below are two DFD fragments that represent two major use cases of Tune Source: Search and
browse songs; Purchase songs.

Figure 7: DFD fragment for Search and Browse Songs.

Figure 8: DFD fragment for Purchase Songs.
III. Task 3:

1. Flowchart Diagram:

Figure 9: Flowchart for Search and Browse Songs.

 2. Behavioral State Machine Diagram:

Figure 10: Behavioral State Machine Diagram for a Customer Purchase.

3. Reliability of Tune Source

Reliability is one of the most important factors in system development, and it’s especially
important for medical devices or missile control systems. Although the Tune Source system is not
required to be as reliable as military systems, it is still capable of providing reliability to the extent
that can meet users' needs. Here are some criteria related to reliability that the system needs to
meet.

 The system should be available for use 24 hours a day, 7 days a week, 365 days a year except
scheduled maintenance.
 The system can support 300 users concurrently during peak hours (from 9-11 am); 150
concurrent users at all other times.
 The system should be secured with access restrictions, encryption, authentication and virus
control. Therefore, the risk of attack and loss if a successful attack occurs is minimized, which
also prevents the personal information of the registered customer from being leaked.
 System maintenance should be scheduled and announced ahead of time. The duration of each
maintenance session must not exceed 2 hours. The total amount of time for each month
should be limited to 6 hours.
 The system will have a 99.99% efficiency. That means that for each day of service, the system
is only allowed to reduce a maximum of 86.4 seconds.
 The system must be cross-platform, meaning it can support different operating systems on
different devices such as: personal computers (MS Windows, macOS, Ubuntu, Linux, etc.),
 mobile devices (Android, Windows Phone, iOS) and some other devices Console devices like
PS4 or Xbox One should also be supported, but not necessarily.
 The system should be multilingual. That means, it is necessary to support at least some of the
most spoken languages including Chinese, English, Spanish, Portuguese, Russian, Arabic and
French.
 The support desk should be available 24 hours a day to help users or answer their questions.

IV. Task 4:

Traceability Matrix:
The traceability matrix is a document, often written in tabular form, that describes and follows
the life cycle of requests, both forward and backward. It correlates any two base documents that use
a many-to-many relationship to determine the completeness of the relationship. It is used to track
requirements, provide the current status of project requirements, help understand relationships
that exist in and on software requirements, design and implementation, and help evaluate. The
impact of changes on the requirements.

Traceability matrix is a powerful tool in request management. One cannot manage what is
traceable. Requests cannot be effectively managed without traceability requirements. It allows
change in one of the three system descriptions, which are requirements, specifications,
implementation, traceable to the corresponding parts of the other descriptions. Some of the other
benefits that traceability matrix can bring include preventing knowledge loss, supporting
verification processes, controlling changes, reducing risks, improving software quality, etc. The
following is an example of the required traceability matrix (RTM).
 Figure 11: Example of RTM.

Regarding the situation of Tune Source, a specific type of traceability matrix that might be
suitable will be discussed. It is a simple requirement - a traceability matrix designed to illustrate the
relationship between specific hardware or software components in the system used to fulfill the
requirements.

User Functional Design

Code Module Test Case
Requirement Requirement Element
TH-01 Class Songs
TH-02 Class Songs
The RTM given above is very helpful when customers make some changes to their requirements.
It allows two-way traceability.
REFERENCES
Requirements Techniques. (n.d.). Interview. [2019] Available at:
https://requirementstechniques.wordpress.com/elicitation/interview/ [Accessed 14 December
2019].

Business Analyst Learnings. (n.d.). Interviews: Requirements Elicitation Technique. [2019] Available

at: https://businessanalystlearnings.com/ba-techniques/2013/7/18/interviews-requirements-
elicitation-technique [Accessed 14 December 2019].

Requirements Techniques. (n.d.). Questionnaire. [2019] Available at:

https://requirementstechniques.wordpress.com/elicitation/questionnaire/ [Accessed 14
December 2019].

Brandenburg, L. (n.d.). What Questions Do I Ask During Requirements Elicitation?. [2019] Bridging-

the-gap.com. Available at: https://www.bridging-the-gap.com/what-questions-do-i-ask-during-
requirements-elicitation/ [Accessed 14 December 2019].

Modernanalyst.com. (2013). The Top Five Go-To Requirements Elicitation Methods [2019] Available
at: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/2483/The-Top-Five-Go-
To-Requirements-Elicitation-Methods.aspx [Accessed 14 December 2019].

En.wikipedia.org. (n.d.). Requirements elicitation. [2019] Available at:

https://en.wikipedia.org/wiki/Requirements_elicitation [Accessed 14 December 2019].

GeeksforGeeks. (n.d.). Software Engineering | Requirements Elicitation - GeeksforGeeks. [2019]

Available at: https://www.geeksforgeeks.org/software-engineering-requirements-elicitation/
[Accessed 14 December 2019].

Study.com. (n.d.). Joint Application Development: Definition, Phases & Methodology | Study.com.

[2019]

Available at: https://study.com/academy/lesson/joint-application-development-definition-phases-

methodology.html [Accessed 14 December 2019].

Webopedia.com. (n.d.). What is Joint Application Development? Webopedia Definition. [2019]

Available at: https://www.webopedia.com/TERM/J/Joint_Application_Development.html [Accessed
14 December 2019].

Pious, K. (2013). Techniques for Eliciting Quality Requirements – Observation. [2019] Captech

Consulting, Inc. Available at: https://www.captechconsulting.com/blogs/techniques-for-eliciting-
quality-requirements--observation [Accessed 14 December 2019].
Stockdale, B. (n.d.). Requirements Elicitation Technique - Observation. [2019] Seilevel Blog - Software
Requirements. Available at: http://www.seilevel.com/requirements/requirements-elicitation-
technique-observation [Accessed 14 December 2019].

Lled500.trubox.ca. (n.d.). An Introduction to Document Analysis – Research Methodology in Education.

[2019] Available at: https://lled500.trubox.ca/2016/244 [Accessed 14 December 2019].

En.wikipedia.org. (n.d.). Documentary analysis. [2019] Available at:

https://en.wikipedia.org/wiki/Documentary_analysis [Accessed 14 December 2019].

Lucidchart.com. (n.d.). What is a data flow diagram? | Lucidchart. [2019] Available at:

https://www.lucidchart.com/pages/data-flow-diagram [Accessed 14 December 2019].

En.wikipedia.org. (n.d.). Traceability matrix. [2019] Available at:

https://en.wikipedia.org/wiki/Traceability_matrix [Accessed 14 December 2019].

Softwaretestinghelp.com. (2019). How to Create Requirements Traceability Matrix (RTM) Example

Sample Template. [2019] Available at: https://www.softwaretestinghelp.com/requirements-
traceability-matrix/ [Accessed 14 December 2019].

Rajkumar (2019). Requirements Traceability Matrix (RTM) | SoftwareTestingMaterial. [2019]

Software Testing Material. Available at: https://www.softwaretestingmaterial.com/requirements-
traceability-matrix/ [Accessed 14 December 2019].

Shilpa (2017). 4 Simple steps to create Requirement Traceability Matrix (RTM) - Free Sample to
download - opencodez. [2019] opencodez. Available at: https://www.opencodez.com/software-
testing/create-requirement-traceability-matrix-rtm-free-sample-download.htm [Accessed 14
December 2019].