ASSIGNMENT 01 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and
Unit 09: Software Development Life Cycle
title
Date Received 1st
Submission date
submission
Re-submission Date Received 2nd
Date submission
Student Name Student ID

Class Assessor name

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

Grading grid
P1 P2 P3 P4 M1 M2 D1 D2
❒ Summative Feedback: ❒ Resubmission
Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

 Assignment Brief 02 (RQF)
Higher National Certificate/Diploma in Business

Student Name/ID Number:

Unit Number and Title: Unit 09: Software Development Life Cycle

Academic Year:

Unit Assessor:

Assignment Title: Undertake a software development life cycle

Issue Date: 07/12/2020

Submission Date:

Internal Verifier Name:

Date:

Submission Format:

Format:

● The submission is in the form of 1 document.

● You must use the Times font with 12pt size, turn on page numbering; set line spacing to 1.3
and margins to be as follows: left = 1.25cm, right = 1cm, top = 1cm, bottom = 1cm. Citation
and references must follow the Harvard referencing style.
Submission:

● Students are compulsory to submit the assignment in due date and in a way requested by the
Tutor.
● The form of submission will be a soft copy posted on http://cms.greenwich.edu.vn/.

● Remember to convert the word file into PDF file before the submission on CMS.

Note:

● The individual Assignment must be your own work, and not copied by or from another student.

● 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 understand and follow the guidelines to avoid plagiarism. Failure to comply
this requirement will result in a failed assignment.

Unit Learning Outcomes:

LO3 Undertake a software development lifecycle.

LO4 Discuss the suitability of software behavioural design techniques.

Assignment Brief and Guidance:

Tasks

At this stage, you have convinced Tune Source to select your project for development. Complete the
following tasks to analyse and design the software.
Task 1 – Analysis (1)

1. Identify the stakeholders, their roles and interests in the case study.
Review the requirement definition of the project. Clearly indicate which stakeholder(s) provide
what requirements.

Word limit: 150 – 200.

Identify FRs and NFRs of Tune Source Project.

Discuss the relationships between the FRs and NFRs.

Word limit: 300 – 400 words.

2. Discuss the technique(s) you would use to obtain the requirements.

If needed, you may state suitable additional assumptions about the project in order to justify the
technique(s) that you choose.

Techniques: JAD, Interview, Observation, etc.

Demonstrate how to collect requirements based on chosen technique.

Word limit: 700 – 1000.

3. Discuss how you would trace these requirements throughout the project by using Requirement
Traceability matrix. You will have to provide real usage of it.
Word limit: 400 – 500 words.

Task 2 – Analysis (2)

Analyze the requirements that you identified in Task 1 using a combination of structural and behavioral
modelling techniques that you have learnt.

Scope: You only need to construct following items for the system. You will have to include:

 Use Case Diagram for the whole system.

 Use Case specification for 2 Use cases.
 Context Diagram for the whole system.
 Data Flow Diagram – Level 0 for the whole system.
 ERD for the whole system.
For each diagram, you will have to explain properly.

Word limit: 1000 – 1200 words.

Task 3 – Design

Based on the analysis result, discuss how you would conduct the design phase:

1. Discuss how the user and software requirements are addressed in the design phase.
 You will explain how Mock-up, and Wireframe are used in the project. You should include
some of the mockup or wireframe (at least 5) design of the Tune Source project to justify that it
matches users’ requirements.
 You will explain which architecture (client – server, n-tier, microservices, etc.) is suitable for
the project with clear illustrations and why.
 Then you will address which technical solution stack could be suitable to implement the project
with clear explanations.
2. Discuss how activity diagram and pseudocode are used to specify the software behaviour.
3. Discuss how UML state machine can be used to specify the software behaviour. Differentiate
between FSM and extended FSM using the case study.
4. Discuss how the data-driven approach improves the reliability and effectiveness of software.
Word limit: 800 – 1500.

Task 4 – Software quality management

1. Discuss two software quality attributes that are applicable to the project.
2. Discuss two quality assurance techniques that can help improve the software quality in the project.
3. Discuss how the design techniques and approaches that you have used can help improve the
software quality.
Word limit: 400 – 1500.
Learning Outcomes and Assessment Criteria (Assignment 02):
Learning
Pass Merit Distinction
Outcome

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

M5 Suggest two software

behavioural specification D4 Present
LO4 Discuss the methods and illustrate justifications of how
suitability of P7 Explain how user and their use with an example. data driven software
software software requirements M6 Differentiate between can improve the
behavioural have been addressed. a finite state machine reliability and
design techniques (FSM) and an extended- effectiveness of
FSM, providing an software.
application for both.
Table of Contents
Assignment Brief 02 (RQF)...........................................................................................................................4
Higher National Certificate/Diploma in Business.....................................................................................4
Analysis (1)..................................................................................................................................................10
I. Requirement definition.............................................................................................................................10
1. Stakeholders.........................................................................................................................................10
2. Identify stakeholders for Tune Source project.....................................................................................12
3. Requirement.........................................................................................................................................13
4. The requirement definition of the project............................................................................................13
II. Requirement elicitation techniques.........................................................................................................14
1. Interview..............................................................................................................................................14
2. Joint Application Development (JAD)................................................................................................15
3. Questionnaires......................................................................................................................................16
4. Document Analysis..............................................................................................................................17
5. Observation..........................................................................................................................................17
6. Selecting the Appropriate Techniques.................................................................................................18
Analysis (2)..................................................................................................................................................18
1. ERD......................................................................................................................................................19
2. Flowchart.............................................................................................................................................20
Search function....................................................................................................................................20
Design..........................................................................................................................................................22
1. Use case diagram.................................................................................................................................23
2. Context diagram...................................................................................................................................26
3. User interface.......................................................................................................................................28
Search function....................................................................................................................................28
Purchase & download function............................................................................................................28
4.Test case................................................................................................................................................29
Conclusion...................................................................................................................................................31
References....................................................................................................................................................31
Analysis (1)

I. Requirement definition

1. Stakeholders

It has a link with the music business, according to the Tune Source scenario: John Margolis,
Megan Taylor, and Phil Cooper. John and Phil worked together to build multiple brick-and-
mortar stores in southern California selling hard-to-find and classical music, rock, country, and
folk recordings. Tune tune has recently partnered with an online consulting business (ISP). The
initiative is sponsored by Carly Edwards, Assistant Vice President, Marketing. Management: My
organization is now working with Tune Source to create the prototype. ABC's project manager is
myself. Device users include individuals who stream music from the Tune Source website and
those who utilize retail kiosks.
1.1. Internal Stakeholders
Internal Stakeholders are organizations, entities, or groups that have a vested interest in the
corporation's operations. You will have an influence on and be impacted by the entity's success
or failure, regardless of the organization's interests. Primary Stakeholders is the second phrase
for Internal Stakeholders.
Business Analysists
The business analyst serves as a liaison between the project's clients and the technical team of
software engineers. The business analyst for the project met with the project's clients, reviewed
the program, created requirements, reported, described the project to the technical team, and
engaged with them throughout the development process.
A commercial analysis
• Producing a comprehensive business analysis, identifying difficulties, opportunities, and
solutions for a company
• Forecasting and budgeting
• Preparation and oversight
• Financial analysis
• Analysis of Variation
• Costs
• Information gathering and dissemination
• Defining business requirements and communicating them to stakeholders
During the SDLC, the business analyst will do the following tas
• Help with business cases
• Carry out high-level feasibility analyses
• Compile prerequisites
• Develop and/or evaluate test scenarios for use in schools
• Dealing with change requests
• Requirements monitoring throughout implementation
• Managing the Project Scope
• The procedure includes approval, integration, and deployment.
System Analysis
Create an internet music system using the following components:
• Connects to a music distribution system over the internet.
• Data models and system performance
• Models of user interfaces and processes
• The user's perspectiv
• The procedure includes approval, integration, and deployment.

Project Manager
Oversee the whole Tune Source software development project to ensure quality, timeliness, and
budget compliance.
Programmer
As a group, we directly run software such as code configuration routines and database queries.
1.2. External Stakeholders
External stakeholders are persons who are not members of the management team but are
impacted in some manner by the company's activities. Outside parties influence the market
environment. Another term for them is secondary stakeholders. They are the ones that analyze
the company's financial data to learn about its efficiency, profitability, and liquidity. The
following individuals are external stakeholders in the Tune Source software development project
Tune Source’s Owner
Tune Source is situated in Los Angeles, California. Tune Source was developed by music
industry professionals
John Margolis, Megan Taylor, and Phil Cooper. The network chief is in charge of supervising all
operations.
They are in charge of all system work, employee actions, and other system-related activities.
They are in charge of installing and maintaining workstations. A secure login system must be
used to access all customer, employee, product, and service records
Sponsor
The sponsor for Tune Source Project is Carly Edwards
Users
The audience is defined as the general public. This episode is totally interchangeable with the
rest.
The target audience refers to the product's planned client base. This episode is a spin-off from the
original largeaudience show, and it focuses on small groups:
The customer is the one who will buy the merchandise.
Knowing about the product and convincing others to buy it KOL (Key Opinion Leader)
Someone who is aware of a product but has not yet acted on it.
Customers are the most significant stakeholders in network services. To select from Tune
Source's offers, they'll need to use a different login screen. They demand a demonstration of the
most recent products and services offered by Tuning Source. They must also question and offer
feedback on any concerns that develop. Customer = User: The buyer, sometimes referred to as
the User, is the one who pays for the goods. Customers are classified into two types:
Customers in the Trade Utilize the Product Consumer Resale Products = Final Customer = End
User (Trade) Clientele: A consumer may also be referred to as a product user or an end user.
Consumers are those who buy and use physical goods. End user: a person who uses intangible
items.
2. Identify stakeholders for Tune Source project

It has a link with the music business, according to the Tune Source scenario: John Margolis,
Megan Taylor, and Phil Cooper. John and Phil worked together to build multiple brick-and-
mortar stores in southern California selling hard-to-find and classical music, rock, country, and
folk recordings. Tune root has recently partnered with an online consulting business (ISP).
The initiative is sponsored by Carly Edwards, Assistant Vice President, Marketing.
Management: My organization is now working with Tune Source to create the prototype. ABC's
project manager is myself.
Device users include individuals who stream music from the Tune Source website and those who
utilize retail kiosks.
3. Requirement

As an example (Dennis, 2014) A need might be a single recorded physical or functional

necessity that a particular design, product, or process tries to meet. It is widely used in
engineering design in a correct meaning, such as in systems engineering, software engineering,
or enterprise engineering. It's a wide notion that can refer to any required (or sometimes
desirable) function, attribute, capacity, trait, or quality of a system in order for it to be valuable
and useful to a customer, company, internal user, or other stakeholders. A requirement
specification or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there
are literally different types of specifications) refers to a specific, highly objective/clear (and often
quantitative) requirement (or sometimes, set of requirements) to be satisfied by a cloth, design,
product, or service.
4. The requirement definition of the project

We will work with stakeholders to develop the specs and include some of the fundamental
responsibilities that the project would necessitate. Let's begin by making an account, looking for
music, listening to it, and then placing an order. Before making an order, customers may also see
invoices and make adjustments to orders directly on the invoice. You may buy the music or pay
for a monthly charge and get unlimited downloads. The consumer can resume the update at any
point during the procedure. Customer information wouldbe kept confidential.
Functional requirements
As an example (Sommerville, 2016) Functional prerequisites These are assertions about the
services that the system should deliver, how the system should respond to inputs, and how the
system should behave in specific scenarios.
In certain circumstances, the functional requirements may expressly indicate what the system
should and should not accomplish.
Functional for Tune Source
Customers may use the internet or retail kiosks to search for and purchase digital music
downloads.
Special features include: • Search for songs in the optical media collection.
• Play the song you've chosen.
• Buy individual downloads for a fixed fee per copy.
• Create a consumer registration account and pay a subscription fee for limitless downloads.
• Purchase download-able tunes and presents.
Music selections will be personalized to the consumer on subsequent visits to the website based
on past sales. Customers' interests may be used to alert them of unique discounts on CDs that can
be purchased at the daily Tune Source web site or in a Tune Source shop.
Nonfunctional Requirements
Follow as (Sommerville, 2016) Non-functional requirements These are constraints on the
services or functions offered by the system. They include timing constraints, constraints on the
event process, and constraints imposed by standards. Non-functional requirements often apply to
the system as an entire instead of individual system features or services.
Nonfunctional for Tune Source
To make music finding easier, a digital music archive would be built.
If a customer's music transfer fails, he or she can choose to restart it or be routed to a backup
download link.
The download speed will be monitored and maintained at an acceptable rate (not too slow)
All client information would be kept strictly confidential.
All payment information will be kept strictly confidential.

II. Requirement elicitation techniques

1. Interview

As an example (Dennis, 2016) The interview is the most commonly used approach for eliciting
requirements. All things considered, it is normal—if you need to know something, you usually
ask someone. When everything is said and done, interviews are conducted one on one (one
questioner and one interviewee), however due to time constraints, a few persons may be met at
the same time. The meeting method consists of five major steps: selecting interviewees,
designing inquiry questions, preparing for the meeting, leading the meeting, and post-meet
growth.
The interviews are split into two categories:
• A private interview is one in which the interviewer prepares questions ahead of time and tries
to elicit replies from stakeholders.
• An open ended interview is one in which the interviewer does not need to arrange any
questions and the questions are completely random during the interview.
2. Joint Application Development (JAD)

As an example (Dennis, 2016) Joint application development (JAD) is a data collection

technique that allows the project team, clients, and the board to collaborate to identify framework
requirements. IBM developed the
JAD strategy in the late 1970s, and it is typically the most useful method for acquiring customer
data. Tricks Jones assures that JAD can cut scope creep in half and avoid framework
requirements from being either explicit or very cryptic, both of which can cause problems later in
the SDLC. JAD is a structured procedure in which 10 to 20 clients gather under the supervision
of a facilitator skilled in JAD procedures. The facilitator is a person who organizes the meeting
and assists the talk but does not engage in it as a member. The individual does not provide
opinions or hypotheses on the topics being discussed and remains impartial during the
conversation. The facilitator must be an expert in both process approaches and frameworks, as
well as inquiry and planning tactics. A pair of copyists assist the facilitator by taking notes,
creating duplicates, and so forth. As the JAD meeting progresses, the copyists will frequently use
PCs and CASE devices to capture data.

Figure 1: Room for JAD

 Table 2: Pros & cons of JAD
3. Questionnaires

As an example (Dennis, 2014) A questionnaire is a collection of questions designed to elicit

information from persons. Surveys are frequently used when a large number of people are
required to provide data and hypotheses. Surveys, in our experience, are typically used for
frameworks intending to use the outside of the business (e.g., by customers or merchants) or for
frameworks with commerce clients distributed across many geographic locations. Most people
think of paper when they think of surveys, but increasingly, more surveys are sent electronically,
either through the mail or on the Internet. When compared to sending paper surveys, electronic
distribution can save a significant amount of money.
Questionnaire Structure
Why
Usually leads to deeper motives and structure knowledge.
What
-The most of the time, this leads to facts.
-What is the client's issue?
When
-When does the issue occur?
How
-Usually results in a debate of mechanism rather than form.
Could
-Maximum openness can result in no results.
 Table 3: Pros & cons of Questionnaire techniques
4. Document Analysis

As an example (Dennis, 2014) Document analysis is frequently used by project teams to

comprehend the same system. In an ideal circumstance, the project team has established the
present system and will generate documentation, which will then be updated for all future
projects. In this instance, the project team should begin by studying the documentation and
testing the system.

Table 4: Pros & cos of document analysis

5. Observation

As an illustration (Dennis, 2014) Observation, or the act of observing forms being carried out,
might be a beneficial strategy for integrating information into the current structure. Instead of
listening to how others depict a problem in interviews or JAD sessions, perception allows the
investigator to sense the reality of the issue. Several studies have indicated that many supervisors
do not recall how they function or how they spend their time. Perception may be an excellent
method for validating data obtained from other sources such as interviews and surveys. This
method is commonly used in conjunction with other processes that are required, such as
interviews and document analysis.

Table 5: Pros and cons of Observation techniques

6. Selecting the Appropriate Techniques

As an example (Dennis, 2014) Each of the requirements elicitation methodologies discussed has
advantages and disadvantages. There is no single approach that is always superior to the others,
and most businesses benefit from a combination of methods. As a result, it is vital to understand
the benefits and drawbacks of each method, as well as when to employ each. One point that has
gone unmentioned is the analysts' interaction. In general, report investigation and perception
require the least amount of preparation, whereas JAD sessions are the most difficult.

Figure 2: type of information

In general, assessing and viewing materials necessitates the least amount of training time,
whereas JAD sessions provide the most difficult problems. So we went with the technical
interview.

Analysis (2)

Introduce: Modeling techniques are based around the use of algorithms - sequences of
instructions for solving specific problems. You use a particular algorithm to create that type of
model.
Requirements Modelings is the process used in software development projects where
requirements and solutions constantly evolve through collaborative efforts and teamwork.
• Requirements modeling is essentially the planning stage of a software application or system.
• The process will begin when a business or an entity approaches a software development team
to create an application or system from scratch or update an existing one.
• Requirements modeling comprises several stages:
• Scenario-based modeling
• Data modeling
• Flow-oriented modeling
• Class-based modeling
• Behavioral modelling
1. ERD

Figure 6: ERD
The database of Tune Source may be viewed here. Tables such as Gift Code, Customer, Order,
Order Detail, Object, Type, and Admin are provided. The Gift Code table is used to keep track of
gift codes for consumers. The customer table is used to store customer information. The order
table contains information about customer orders. The order detail table stores customer
information. A product table stores song information. Create a table category to contain
information about the type of album
2. Flowchart
Search function

Figure 7: Search function

The music search function flowchart is illustrated below. Users enter keywords into the search
box and hit the search button; if the term matches or is identical to a song already in the database,
the song information is displayed; otherwise, the message "not found" is displayed. Purchase &
Download function

Figure 8: Purchase & Download Function

This is where you may buy and download music. When the user selects music and taps the buy
button, the gadget will ask for user information such as name, phone number, and account
number. Then, check to see if your account balance is adequate to purchase the music; if so, you
will be told of payment success and download authorization; if not, you will be alerted of
"insufficient money not the account" and payment failure
Design

Introduce about use cases and use case diagram

A use case: is a methodology used in system analysis to identify, clarify and organize
system requirements. The use case is made up of a set of possible sequences of
interactions between systems and users in a particular environment and related to a
particular goal. The method creates a document that describes all the steps taken by a user
to complete an activity. Use cases are typically written by business analysts and can be
employed during several stages of software development, such as planning system
requirements, validating design, testing software and creating an outline for online help
and user manuals. A use case document can help the development team identify and
understand where errors may occur during a transaction so they can resolve them.
A use case diagram: is the primary form of system/software requirements for a new
software program underdeveloped. Use cases specify the expected behavior (what), and
not the exact method of making it happen (how). Use cases once specified can be denoted
both textual and visual representation (i.e. use case diagram). A key concept of use case
modeling is that it helps us design a system from the end user's perspective. It is an
effective technique for communicating system behavior in the user's terms by specifying
all externally visible system behavior.
A use case diagram is usually simple. It does not show the detail of the use cases:
 It only summarizes some of the relationships between use cases, actors, and
systems.
 It does not show the order in which steps are performed to achieve the goals of
each use case.
As said, a use case diagram should be simple and contains only a few shapes. If
yours contain more than 20 use cases, you are probably misusing use case
diagram.
1. Use case diagram
 Figure 3: Use case diagram
The usage case diagram for the Tune Source system is shown below. The ability to
search for songs, listen to selected music, establish an account, and update are
among the essential features that have been analyzed and implemented. The
administrator may add, modify, and delete music as well as manage consumer
accounts. Marketing may manage customer complaints and error reports.

Table 6: Analysis function

2. Context diagram
3. User interface
Search function

Figure 9: Search function

This is the website that customers visit when they are seeking for anything specific. When a
consumer enters a term into the search field, the system locates the answer and presents the full
result information, as well as a link to listen to the album.
Purchase & download function

Figure 10: Login function

 Figure 11: Enter information
This is the interface to enter customer information

Figure 12: Gift code

Then the system will ask to enter Gift code, if there is no Gift code, users can skip

4.Test case
 Table 9: Test case
Conclusion

The following is the research and selection of a suitable plan to add to the Tune Source project. I
wrote the project specs, designed the user interface for Tune Source, and fully tested it

References

Dennis, W. R., 2014. In: B. L. Golub, ed. System analysis & design. s.l.:Don Fowley.
Dennis, W. R., 2016. System analysis & design. 10 ed. s.l.:Don Fowley.
Sommerville, I., 2016. Functional and non-functional requirements. Matt Goldstein ed. s.l.:Trudy
Kimber.
Sommerville, L., 2016. In: M. Goldstein, ed. Software Engineering. s.l.:Trudy Kimber, p. 113.