Assignment 2 Software Development Life Cycles (1631 Distinction)

ASSIGNMENT 02 FRONT SHEET
Qualification

BTEC Level 5 HND Diploma in Computing

Unit number and title

Unit 09: Software Development Life Cycle

Submission date

Date Received 1st submission

Re-submission Date

Date Received 2nd submission

Student Name

Bui Quang Minh

Student ID

GCD210325

Class

GCD1104

Assessor name

Tran Trong Minh

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
P5

P6

P7

M3

M4

M5

M6

D3

D4


❒ Summative Feedback:

Grade:
Internal Verifier’s Comments:

Signature & Date:

❒ Resubmission Feedback:

Assessor Signature:

Date:


Table of content
TASK 1: ANALYSIS (1) ............................................................................................................................................... 3
I. Identifying stakeholders and FRs, NFRs of TuneSource Project (P5.a)............................................................. 3
1. Identifying stakeholders and reviewing requirements ............................................................................... 3
2. FRs and NFRs ............................................................................................................................................... 4
2.1 What is FRs and NFRs ............................................................................................................................ 4
2.2 Identifying FRs and NFRs of TuneSource Project .................................................................................. 4
2.3 Discussing relationship between FRs and NFRs .................................................................................... 5
I. Discussing the techniques would be used to obtain the requirements (P5.b) ................................................ 6
1. Describing techniques would be used ......................................................................................................... 6
2. Demonstrating how to collect requirements based on chosen technique ................................................. 6
3. SRS (Software Requirements Specification) for the Tune Source ............................................................... 7
3.1 Introduction ........................................................................................................................................... 7
3.2 General discription ................................................................................................................................ 8
3.3 Software features and requirements .................................................................................................... 8
III. Discussing how would trace these requirements throughout the project (M3) ........................................... 8
TASK 2: ANALYSIS (2) ............................................................................................................................................. 12
I. Analysing identified requirements in Task 1 (P6) ........................................................................................... 12
1. ERD (Entity Relationship Diagram) ............................................................................................................ 12
2. Flow chart .................................................................................................................................................. 13

3. DFD (Data Flow Diagram) .......................................................................................................................... 16
TASK 3: DESIGN...................................................................................................................................................... 18
I. Discussing how user and software requirements are addressed in design phase (P7) ................................. 18
1. How mockup and Wireframe are used in the project ............................................................................... 18
2. Explaining which architecture is suitable for the project .......................................................................... 21
3. Addressing solution stack that can be suitable to implement the project ............................................... 22
3.1 What is Tech Stack............................................................................................................................... 22
3.2 Influences the choice of A Tech Stack ................................................................................................. 22
3.3 Suitable solution stack ......................................................................................................................... 23
II. Discussing how activity diagram and pseudocode are used to specify software behavior (M5) ................. 24
1. Activity diagram ......................................................................................................................................... 24
2. Pseudocode ............................................................................................................................................... 25


III. Discussing how UML state machine can be used to specify software behavior and differences between
FSM and extended FSM using case study (M6) ................................................................................................. 26
1. How UML state machine can be used to specify software behavior ........................................................ 26
2. FSM and extended FSM ............................................................................................................................. 28
2.1 What is FSM ......................................................................................................................................... 28
2.2 What is extended FSM......................................................................................................................... 29
2.3 Differentiating between FSM and extended FSM ............................................................................... 29
IV. Discussing how data-driven approach improves the reliability and effectiveness of software (D4)........... 29
1. What is data-driven ................................................................................................................................... 29
2. What is data-driven for.............................................................................................................................. 29
3. How data-driven approach improves the reliability and effectiveness .................................................... 30
TASK 4: SOFTWARE QUALITY MANAGEMENT ....................................................................................................... 32
I. Discussing two software quality attributes that are applicable to the project (M4.a) .................................. 32
1. Usability ..................................................................................................................................................... 32
2. Reliability ................................................................................................................................................... 32
II. Discussing two quality assurance techniques that can help improve software quality project (M4.b) ....... 33

1. Code reviewing .......................................................................................................................................... 33
2. Testing ....................................................................................................................................................... 34
III. Discussing how design techniques and approaches that is used can help improve software quality (D3) . 35
1. What is software quality............................................................................................................................ 35
2. What are the 3 C’s of Software Quality ..................................................................................................... 36
3. How design techniques and approaches help to improve software quality ............................................. 36


TASK 1: ANALYSIS (1)
I. Identifying stakeholders and FRs, NFRs of TuneSource Project (P5.a)
1. Identifying stakeholders and reviewing requirements











John Margolis (Entrepreneur): Co-founder of Tune Source. Role: Strategic decision-making, profitability.
Megan Taylor (Entrepreneur): Co-founder of Tune Source. Role: Classical music expertise, supplier
relationships.
Phil Cooper (Entrepreneur): Co-founder of Tune Source. Role: Store operations, and inventory
management.
Carly Edwards (Project Sponsor): Assistant VP of Marketing. Role: Project sponsorship, aligning with
strategic goals.
Customers: Existing and potential customers. Interests: Finding rare recordings, convenient shopping,

digital downloads, and subscription services.
Development Team: IT department and developers. Role: Implementation of digital music download
system.
Internet Service Provider (ISP): Hosts Tune Source's website. Role: Reliable hosting and technical support.
Music Suppliers: Providers of digital music downloads. Interests: Expanding reach, increasing sales.
Marketing Department: Tune Source's marketing team. Interests: Promoting the service, and driving
sales.
Competitors: Other music retailers and platforms. Interests: Monitoring Tune Source's impact on the
market.

Review the requirement definition of the project
1. Business Need: Increase sales by selling digital music downloads through in-store kiosks and the website.
 Provided by: Carly Edwards (Project Sponsor)
2. Business Requirements:
Search for music in the 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.
 Provided by: Carly Edwards (Project Sponsor) and Customers (interests and needs)


3. Business Value:
Increase sales by enabling customers to purchase specific digital music tracks.
Reach new customers interested in rare and hard-to-find music.
Gain revenue from customer subscriptions to download services.
Increase cross-selling as customers decide to purchase entire CDs.
Generate revenue from music download gift cards.
 Provided by: Carly Edwards (Project Sponsor)

2. FRs and NFRs
2.1 What is FRs and NFRs
Functional Requirements (FRs) are specific capabilities or features that a system must possess to satisfy its
intended purpose. They describe what the system should do and can be objectively verified or tested. FRs are
typically focused on the system's functionalities and behavior.
Example FRs for an online shopping website:
o
o
o
o
o

The system will allow users to create an account.
The system will provide search functionality for users to find products.
The system will allow users to add products to a shopping cart.
The system will support different payment methods for users to complete their purchases.
The system will send order confirmation emails to users after successful purchases.

Non-Functional Requirements (NFRs) define the qualities or characteristics that a system should possess,
typically addressing aspects such as performance, security, usability, and reliability. NFRs are not directly
related to the system's functionalities but focus on how well the system performs and behaves.
Example NFRs for an online shopping website:
o
o
o
o
o

Performance: The system should load product pages within two seconds.
Security: The system should encrypt sensitive user data, such as passwords and payment

information.
Usability: The system's user interface should be intuitive and easy to navigate.
Reliability: The system should have an uptime of at least 99% to minimize downtime and disruptions.
Scalability: The system should be able to handle a high volume of simultaneous user requests during
peak times.

2.2 Identifying FRs and NFRs of TuneSource Project
Based on the given information, we can identify the following Function Requirements (FRs) and NonFunction Requirements (NFRs) for the Tune Source project:


Functional Requirements (FRs):







Online Catalog: Develop an online catalog that allows customers to search for CDs.
E-commerce Functionality: Enable customers to purchase CDs through the website.
Search Functionality: Implement a search feature that allows customers to search for specific artists,
albums, genres, etc.
User Accounts: Provide the option for customers to create user accounts for easier future purchases
and personalized recommendations.
Payment Processing: Integrate a secure payment gateway to process customer payments.
Order Tracking: Allow customers to track the status of their orders, including shipping information
and delivery updates.

Non-Functional Requirements (NFRs):









Performance: Ensure that the website loads quickly and provides a responsive user experience.
Security: Implement robust security measures to protect customer data and prevent unauthorized
access.
Reliability: Ensure high uptime and minimal downtime for the website to prevent disruptions in sales.
Usability: Design the website interface to be user-friendly, intuitive, and easy to navigate.
Compatibility: Ensure compatibility with various web browsers and operating systems.
Accessibility: Make the website accessible to users with disabilities by adhering to accessibility
standards.
Performance Monitoring: Implement tools to monitor website performance, track metrics, and
identify areas for improvement.

These FRs and NFRs provide a basis for developing and implementing the Tune Source project to meet the
needs of customers and ensure a successful online presence for the company.

2.3 Discussing relationship between FRs and NFRs
Systems need both functional requirements and non-functional requirements to be usable. Functional
requirements define how the system must work and non-functional requirements detail how it should
perform. Without functional requirements, the system will not work. Without at least some non-functional
requirements being met to a certain level, users will become frustrated. Documenting functional
requirements and non-functional requirements helps to avoid disappointment with a new system. It is also
important in keeping the project on track, to budget and delivered on time. Documenting requirements is
also more likely to lead to greater satisfaction with the end product for both business stakeholders and end
users.

I. Discussing the techniques would be used to obtain the requirements (P5.b)
1. Describing techniques would be used
Joint Application Development (JAD) is a process in which business information is gathered for the
development of new information technology systems or to improve user involvement or develop and
improve quality in systems.
In this technique IT, specialists and business users collaborate in discussion, project management and
learning groups, talking about the new information system. With the participation of both parties, it is
possible to develop and solve the requirements of the new software system in an easier way. The meetings
can be hours, days or weeks, depending on the intensity of the workshops.
Individual interviews with stakeholders, such as Carly Edwards (Project Sponsor), Megan Taylor (Cofounder), and customers, can provide deeper insights into their specific needs and expectations. These
interviews can be conducted in person, over the phone, or through video conferencing. The interviewer
should prepare a set of open-ended questions to prompt stakeholders to provide detailed responses. For
example, questions can be focused on understanding the desired features, user experience, and specific
functionalities of the digital music download system. Through interviews, stakeholders can express their
perspectives and provide valuable input for the requirements gathering process.
User observation should be planned to ensure that all elements are constant surrounding the observation.
This will assist in uncertainty, and the consultant can focus on the user and assist in knowing what to look for.
The analyst will not be distracted and record, or note, irrelevant issues. The more useful information
gathered, the less time it will take to the analyst to dissect and evaluate afterwards. Timing of the
observation can also prove relevant when planning. For optimal results, the consultant should schedule three
different periods of observation: low, normal, and peak times. This may prove helpful in because the user
may interact with the system differently during different times. The consultant will take into consideration
the differences in times time settings and use it to obtain to construct better requirements to assist in all
three times. When observing the user, there are two approaches the consultant can take, passive or active.

2. Demonstrating how to collect requirements based on chosen technique
I would choose JAD and interview techniques to collect requirements based on the chosen technique.
1. Joint Application Development (JAD):

a. Plan the JAD session:




Identify the key stakeholders to include in the session, such as Carly Edwards (Project Sponsor),
Megan Taylor (Co-founder), and representatives from the development team.
Set a date, time, and location for the session.
Prepare the agenda, including specific topics and objectives to be discussed.


b. Conduct the JAD session:





Start the session by introducing the purpose and goals of the session, emphasizing the importance of
collaborative participation.
Encourage stakeholders to share their ideas, perspectives, and requirements.
Facilitate discussions to clarify and resolve any conflicts or ambiguities in the requirements.
Summarize the collected requirements at the end of the session and ensure that all stakeholders
agree on the documented requirements.

2. Interviews:
a. Identify interview participants:



Determine the key stakeholders to interview, including Carly Edwards (Project Sponsor) and Megan

Taylor (Co-founder).
Consider conducting interviews with a sample of customers to gather their perspectives as well.

b. Prepare interview questions:




What are the essential features that you envision in the digital music download system?
How do you imagine the user experience when searching for and purchasing digital music
downloads?
Are there any specific requirements or capabilities that you consider critical for the success of the
system?

c. Conduct the interviews:



Start the interviews by explaining the purpose and assuring stakeholders that their input is valuable.
Ask the prepared interview questions, giving stakeholders enough time to provide detailed

3. SRS (Software Requirements Specification) for the Tune Source
3.1 Introduction
1. Purposes
 Sales Growth: By offering customers the convenience of online shopping, Tune Source aims to
increase its annual sales. The existing reputation of Tune Source as the go-to place for rare audio
recordings will be leveraged to attract customers to the online platform.
 Website Maintenance: The project includes the ongoing maintenance and management of the
website. The IT department at Tune Source, along with the assistance of the Internet Service
Provider (ISP), will ensure the smooth functioning of the website and address any technical issues

that may arise.
 Customer Satisfaction: The project aims to enhance the overall customer experience by providing
an intuitive and efficient website interface. Customers should be able to easily search for their
desired CDs, access detailed information about the recordings, and make purchases securely.


2. Scope
The scope of the Tune Source project includes developing an online platform for customers to search
for and purchase CDs in the genres of jazz, rock, country, and folk. It involves implementing features
such as catalogue browsing, search functionality, music sample playback, user registration and
accounts, secure online payment processing, and website maintenance. The scope also encompasses
integration with the existing IT infrastructure and ensuring compatibility with evolving web
technologies.

3.2 General discription
1. Business requirements
 Providing access to a comprehensive music archive with a focus on hard-to-find and classic
jazz, rock, country, and folk recordings.
 Allowing customers to listen to music samples before making a purchase.
 Introducing customer subscription accounts for unlimited downloads.
 Selling music download gift cards.
 Capitalizing on digital music sales to drive cross-selling opportunities.
 Achieving revenue growth through increased sales and new revenue streams.
2. User needs
 Access to a wide range of music genres.
 Easy search and discovery of music.
 Personalized accounts and preferences.
 Subscription options for unlimited music downloads.
 Gift card options for gifting music.
 Reliable and responsive website experience.

3.3 Software features and requirements
1. Features
 Music Search: Users can search for music tracks based on artist, album, genre, or other criteria.
 Music Sampling: Users can listen to short music samples to preview tracks.
 Online Purchasing: Users can purchase music tracks and albums online.
 Gift Card Sales: Users can purchase gift cards for digital music downloads.
 Account Management: Users can create and manage personalized accounts, including order
history and preferences
2. Functional requirements and Non-Functional requirements
These requirements are defined at part I, 2. FRs and NFRs (above)

III. Discussing how would trace these requirements throughout the project (M3)
I would use SDLC to trace these requirements throughout the project. SDLC is a process that defines the
various stages involved in the development of software for delivering a high-quality product. SDLC stages
cover the complete life cycle of a software i.e. from inception to retirement of the product.


Purpose:
Purpose of SDLC is to deliver a high-quality product which is as per the customer’s requirement.
SDLC has defined its phases as, Requirement gathering, Designing, Coding, Testing, and Maintenance. It is
important to adhere to the phases to provide the Product in a systematic manner.

Figure 1. SDLC phases

SDLC Phases








Requirement gathering and analysis
Design
Implementation or coding
Testing
Deployment
Maintenance

Requirement Gathering and Analysis
During this phase, all the relevant information is collected from the customer to develop a product as per
their expectation. Any ambiguities must be resolved in this phase only.
Business analyst and Project Manager set up a meeting with the customer to gather all the information like
what the customer wants to build, who will be the end-user, what is the purpose of the product. Before
building a product a core understanding or knowledge of the product is very important.






The stakeholders, including John Margolis, Megan Taylor, and Phil Cooper, provide the business
requirements for TuneSource, such as the ability to search and purchase digital music downloads,
listen to music samples.
The requirements are documented in the Requirements Specification document, which includes
unique identifiers for each requirement.

Design






The design phase focuses on converting the requirements into a detailed system design that serves
as a blueprint for implementation.
System architecture, component design, database design, and user interface design are developed
during this phase.
Design decisions consider factors like system scalability, performance, security, and usability.
Design artifacts, such as architectural diagrams, data models, and wireframes, are created to
document the system's design.

Implementation or Coding





In this phase, the software solution is built based on the design specifications.
Programmers write code, following coding standards and best practices.
The implementation may involve the integration of various software components, libraries, and
frameworks.
Version control systems are often used to manage code changes, track revisions, and facilitate
collaboration among developers.

Testing
Testing starts once the coding is complete and the modules are released for testing. In this phase, the
developed software is tested thoroughly and any defects found are assigned to developers to get them fixed.
Retesting, regression testing is done until the point at which the software is as per the customer’s
expectation. Testers refer SRS document to make sure that the software is as per the customer’s standard.






The testing phase aims to ensure the quality, reliability, and functionality of the software.
Test cases are designed and executed to verify that the software meets the specified requirements.
Different testing types, such as unit testing, integration testing, system testing, and user acceptance
testing, are conducted.
Defects and issues identified during testing are logged, tracked, and resolved through collaboration
with developers.

Deployment
Once the product is tested, it is deployed in the production environment or first UAT (User Acceptance
testing) is done depending on the customer expectation.


In the case of UAT, a replica of the production environment is created and the customer along with the
developers does the testing. If the customer finds the application as expected, then sign off is provided by
the customer to go live.
Maintenance
After the deployment of a product on the production environment, maintenance of the product. If any issue
comes up and needs to be fixed or any enhancement is to be done is taken care by the developers.




The maintenance phase focuses on supporting and enhancing the software after it has been
deployed.
It involves addressing user feedback, fixing bugs, and making updates or enhancements to meet

changing requirements.
Regular maintenance tasks, such as performance monitoring, security updates, and system backups,
are performed to ensure the software's stability and reliability.

Figure 2. SDLC illustration


TASK 2: ANALYSIS (2)
I. Analysing identified requirements in Task 1 (P6)
1. ERD (Entity Relationship Diagram)

Figure 3. ERD illustration

The customer will have a one-to-many relationship with the bill entity because the customer can have one or
more invoices
Purchase will have a one-to-many relationship with bill because purchase can print one or more bills
Song will have a one-to-many relationship with purchase because music can be purchased by one or more
people
Category will have a one-to-many relationship with music because each genre can have one or more songs


2. Flow chart

Figure 4. Flowchart of searching song

Figure 5. Flowchart of adding new song


Figure 6. Flowchart of editing song

Figure 7. Flowchart of deleting song


Figure 8. Flowchart of purchasing song


3. DFD (Data Flow Diagram)

Figure 9. DFD level 0

Figure 10. DFD level 1 – sign up and sign in


Figure 11. DFD level 1 – user

Figure 12. DFD level 1 - admin


TASK 3: DESIGN
I. Discussing how user and software requirements are addressed in design phase (P7)
1. How mockup and Wireframe are used in the project
What is a wireframe?
A wireframe is a skeletal blueprint or framework that outlines the basic design and functions of a user
interface (such as a website or application).
The goal of a wireframe is to quickly and easily communicate:




The contents of the page

The page structure and layout
The app’s functions

In other words, a wireframe describes the basic structure, functions, and content of the page.
Wireframes can be low-fidelity or high-fidelity, depending on your needs and preferences. A low-fidelity
wireframe is often sketched out on paper or a whiteboard and is a useful way to brainstorm the basic outline
for your design. A high-fidelity wireframe has more detail and may include simple workflows and
interactions.
 In the Tune Source project, wireframes can be used to outline the basic structure of the website and
kiosk interfaces. They can show the arrangement of key components, such as the search bar, music
listings, sample playback, add-to-cart functionality, and checkout process. Wireframes help in earlystage concept development, allowing stakeholders to provide feedback on the overall flow and
structure of the system.
What is a mockup?
A mockup is the next, more in-depth iteration of the wireframe outline. A mockup is a static wireframe that
includes more stylistic and visual UI details to present a realistic model of what the final page or application
will look like.
A good way to think of it is that a wireframe is a blueprint and a mockup is a visual model.
A mockup typically includes additional visual details such as:





Colors, styles, graphics, and typography
Styled buttons and text
Navigation graphics
Component spacing