<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

ASSIGNMENT 2 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and title Unit 9 So ware Development Life Cycle:

Submission date 04/20/2023 Date Rec v 1stei ed submission

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

1

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

 Summative Feedback:  Resubmission Feedback:

<b>Internal Verifier’s Comments:</b>

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

Signature & Date:

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

Table of contents

INTRODUCTION ... 7

UNDERTAKE A SOFTWARE INVESTIGATION TO MEET A BUSINESS NEED (P5) ... 8

I. Iden fy the stakeholders, their roles and interests in the case study ... 8

II. Requirement ... 8

1. De ni on ... 8

2. Dis nguish func onal and non-func onal requirements ... 9

3. The rela onship between func onal and non-func onal requirements... 10

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

IV. System requirements ... 14

USE APPROPRIATE SOFTWARE ANALYSIS TOOLS/TECHNIQUES TO CARRY OUT A SOFTWARE INVESTIGATION AND CREATE SUPPORTING DOCUMENTATION (P6) ... 15

I. Use case diagram ... 15

1. De ni on ... 15

2. Iden fy actors and use cases for each actor ... 15

3. Draw a use case diagram ... 16

4. Use case descrip on ... 21

II. Data Flow Diagram ... 23

1. De ni on ... 23

2. Draw a Data Flow Diagram ... 23

III. En ty Rela on Diagram ... 24

1. De ni on ... 24

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

2. En ty Descrip on ... 24

3. Rela onships between en es ... 26

4. ERD chart ... 26 .

EXPLAIN HOW USER AND SOFTWARE REQUIREMENTS HAVE BEEN ADDRESSED (P7) ... 28

I. Website interface design ... 28

II. Architectural design ... 41

III. Address which solu on stack could be suitable to implement the project ... 41

Discuss how you would trace these requirements throughout the project (M3) ... 43

Discuss two approaches to improving so ware quality (M4) ... 44

I. Discuss two so ware quality a ributes that are applicable to the project ... 44

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

II. Discuss two quality assurance techniques that can help improve the so ware quality in the project ... 45 Suggest two so ware behavioural speci ca on methods and illustrate their use with an example (M5) ... 46 Di eren ate between a nite state machine (FSM) and an extended-FSM, providing an applica on for both. (M6) ... 47 CONCLUSION ... 49 REFERENCE ... 50

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

List of Figures

Figure 1: Usecase level 1 ... 16

Figure 2: Book Management ... 17

Figure 3: Category Management ... 17

Figure 4: Orders Management ... 17

Figure 5: Customer Management ... 18

Figure 6: Customer Account ... 18

Figure 7: Employee Account ... 18

Figure 8: Order detail Management ... 19

Figure 9: Account ... 19

Figure 10: Order ... 19

Figure 11: Pay... 20

Figure 12: Data Flow Diagram level 0 ... 23

Figure 13: Context Diagram ... 24

Figure 20: Login Admin ... 30

Figure 21: Add book and list of book ... 31

Figure 22 : Payment ... 32

Figure 23: Informa on ... 33

Figure : Informa on 24 ... 33

Figure 25: Edit Pro le... 34

Figure 26 : Your Pro le ... 34

Figure 27 : Feedback ... 35

Figure 28 :Login Admin ... 35

Figure 29 : Home Admin ... 36

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

Figure 30 : Add Book ... 36

Figure 31 : List Book ... 37

Figure : Add Employee 32 ... 37

Figure 33: List Book ... 38

Figure 34 : Add Customer ... 38

Figure 35 : List Customer ... 39

Figure 36 : List Order... 39

Figure 37 : Order detail ... 40

Figure 38 :List Feedback... 40

Figure 39: LAMP stack ... 42

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

List of Table

Table 1 Func onal and Non Func onal Requirements : ... 10

Table 2: Interview ... 14

Table 3: Actors and use cases for each actor ... 16

Table 4: Func on table of use case ... 21

Table 5: Func on Login ... 21

Table 6: Func on Login ... 22

Table 7: Func on Register ... 22

Table 8: Func on Register ... 22

Table 9: Func on Logout ... 23

Table 10: Func on Logout ... 23

Table 11: En ty Descrip on ... 26

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

INTRODUCTION

In this report, I will teach the knowledge collected by technology, including 5 technologies: interviews, ques onnaires, JAD, Document analysis and observa on. Among them, I give de ni ons and related factors. I can use it too The applica on of interview technology has paved the way for project development. I also created The system designed charts, such as: applica on diagram, ac vity diagram, data owchart and en ty Rela onal card. I created a rela onship database that contains all informa on from the physical rela onship diagram. The data required by the system. In addi on, I also created a report for the website func on, including The main func ons of the system. The so ware of the system reac on is below.

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

UNDERTAKE A SOFTWARE INVESTIGATION TO MEET A BUSINESS NEED (P5)

I. Identify the stakeholders, their roles and interests in the case study

A stakeholder is any individual, group or party that has an interest in an organiza on and the results of its ac ons. for example in the tune source system here the stakeholders are customers, employees administrators, project investors, government, and the community. The stakeholders: Phill Lewis, Kevin Hart and Ariana Grande

Administrator

Administrator stakeholders are the owners of an organiza on. They provide capital or equity to the project and have a say in how things run. There can be mul ple owners and each administrator will have equity in the project.

Project Sponsor: David Beckham

Project Sponsor can include owners but they can also be outside vendors who typically have a right to accurate and mely informa on such as regular nancial statements. Sponsor may also have the right to approve or reject major decisions like mergers and acquisi ons. System User

The System User represents the end-users who will use the system or product being developed in the project. Their role is to provide input on func onal requirements, user experience (UX), and usability considera ons. Their interests may include having a system or product that meets their needs, is user-friendly, and provides a posi ve experience. Customers

Customers are the en es or individuals who will use or bene t from the project outcome.

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

Their role is to provide input on requirements, provide feedback during project execu on, and accept the final deliverables. Their interests may include receiving a high-quality product or service that meets their needs, is delivered on me, and is within budget. It's important to note that stakeholders' roles and interests may evolve throughout the project lifecycle, and effec ve stakeholder management is crucial for project success. Understanding the roles and interests of stakeholders helps in iden fying and managing their expecta ons, addressing their concerns, and ensuring their ac ve par cipa on and support throughout the project.

II. Requirement 1. Definition

</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">

Represents a need that an Informa on System should ful ll. Condi ons can be func onal( what the so ware or element should do, a func onality),non-func onal( how the system will do, that is, constraints or rates) and environmental( assessed constraints similar as legal restric ons or norms). This bracket can be seen from the stoner point of view( accessible for stakeholders) or from the system point of view( on a specialized and more detailed posi on).

2. Distinguish functional and non-functional requirements

Requirements analysis is very cri cal process that enables the success of a system or so ware project to be assessed. Requirements are generally split into two types: Func onal and Non-func onal requirements.

Func onal Condi ons These are the condi ons that the end stoner speci cally demands as introductory installa ons that the system should o er. All these func onali es need to be inescapably incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the opera on performed and the a air an cipated. They're principally the condi ons stated by the stoner which one can see directly in the final product, unlike the non-func onal condi ons.

Non-func onal condi ons These are principally the quality constraints that the system must sa sfy according to the design contract. The precedence or extent to which these factors are enforced varies from one design to other. They're also called non-behavioral condi ons.

They basically deal with issues like: Portability

Security

</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">

Maintainability Reliability Scalability Performance Reusability Flexibility

Following are the di erences between Func onal and Non Func onal Requirements Functional Requirements Non Functional Requirements A func onal requirement de nes a system or its

component.

A non-functional requirement de nes the quality a ribute of a so ware system. It specifies “What should the software system

do?”

It places constraints on “How should the software system fulfill the func onal requirements?”

</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">

Func onal requirement is specified by User. Non-func onal requirement is speci ed by technical peoples e.g. Architect, Technical leaders and so ware developers.

It is captured in use case. It is captured as a quality attribute. Defined at a component level. Applied to a system as a whole. Helps you verify the functionality of the

Example

1) Emails should be sent with a latency of no greater than 12 hours from such an ac vity. 2) The processing of each request should be done within 10 seconds

3) The site should load in 3 seconds when the number of simultaneous users are > 10000

3. The relationship between functional and non-functional requirements

Func onal Condi ons and non-func onal condi ons are both important in the development of a successful so ware system. Func onal condi ons de ne the speci c features and func onality that the so ware system must give to meet the stoner's requirements. Non-func onal condi ons, on the other hand, describe the performance, usability, security, and other quality characteris cs that the system must parade. Func onal condi ons concentrate on what the so ware system should do, while non-func onal condi ons concentrate on how it should do it. In other words, func onal

</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">

condi ons are concerned with the" what" of the system, while non-func onal condi ons are concerned with the" how."

The rela onship between func onal and non-func onal condi ons is that they're both necessary in order to produce a successful so ware system. The functional condi ons de ne what the system is supposed to do, while the non-func onal condi ons de ne how well it should do it. For illustra on, a func onal demand might be that a system must allow druggies to produce and save documents, while anon-func onal demand might be that the system must be suitable to handle a large number of druggies contemporaneously without decelera ng down.

while func onal condi ons are necessary to describe the func onality of the system,non-func onal condi ons are necessary to insure that the system meets the necessary quality norms and performs e ec vely under di erent condi ons. Both types of condi ons are important and should be considered in the development of any so ware system.

</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">

III. Discuss the technique(s) you would use to obtain the requirements Justification for the technique(s):

Decades of resource-related project planning issues decades ago, although it was rarely used in this issue. The reason is a simple and fast technology that will create a new metable when using the metable, as long as the original metable -usually shorter. These results prompted us to summarize this technology to further study it. In this article, the di erences and general forms of reasoning technology are proposed, which can obtain a survey of the rela onship between the metable. The results obtained show that the proposed summary is worth it. Several computer tests were performed to determine the impact of general concepts on algorithm e iciency. We use collec ve requirements, observation, and ques onnaire/survey.

Observational Method:

The term Observa onal research is used to refer to a number of di erent types of experimental research in which behavior is systema cally observed and recorded. Naturalistic Observation:

non-Natural observa on is a method of observa on, including observing human behavior in the eld of customers and investors. For example, observe customers and behaviors using the melody source. Your research will invalidate the research. Therefore, the observa on value of camou age may be low, so it may have a higher value because people do not know that their behavior is observed and recorded. However, we now know that people are o en accustomed to observing. Over me, they start to act naturally in front of researchers. In other words, people have developed the habit of being observed over me.

Participants' observations:

</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">

Another way to observe the data in the research is to observe the par cipants. In the observa ons of par cipants, people will ac vely use the system, and act as a comment based on their observa ons and interac ons, documents, photos and other cultural relics. The only di erence between natural observa on and par cipa on observa ons is that the par cipa ng observa on researchers have become ac ve members or the project of the project.

Survey

In any form of research, you will interact with the public. These are also known as your par cipants. Par cipants can choose from the target test or random from the street. In these two cases, researchers must understand the importance of the sentence he use. If you understand these two terms, you will get more successful data acquisi on. Simpleness is to explain everything when their needs for par cipants. Explain the di erences between inves ga on and ques onnaire surveys. The ul mate goal of the survey is to learn more

</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">

about some people. There are several reasons for this. In this project example, inves ga ons are used to understand more informa on about certain consumer behaviors in order to produce products according to user requirements.

Survey in research example

We will check the examples we used when we discussed the ques onnaire before. Assume that the ques onnaire is used as the main research of the company's scope survey. The inves ga on aims to experience the experience of people at home. The survey not only focuses on its own experience, but also the experience of the en re labor force. The process of managing the ques onnaire is not inves ga on. Collect data, collect (quan ta ve) and combine with other forms of data acquisi on is a survey.

Interview 1. Focus group

A common method of conduc ng research interviews is conduc ng focus group interviews. In this method, mul ple people are interviewed at the same me. Focus group facilitators typically encourage par cipants to interact with each other and observe the group to gain insight into real-life a tudes and perspec ves. Focus group par cipants o en respond in a more relaxed and natural way. This is because group environments can feel more authen c than other interview environments.

2. Structured interview

Another op on is a structured interview. Structured interviews typically consist of closed ques ons that the respondent can answer yes or no. Interviewers usually ask each interviewee exactly the same ques ons in the same order. In many cases, researchers follow a standard format that can be easily replicated, allowing structured interviews to be conducted quickly.

3. Unstructured interview

</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">

Unstructured interviews, also called informal interviews, are the opposite of structured interviews. In unstructured interviews, the interviewer does not ask each interviewee standardized ques ons. Instead, unstructured interviews rely on open-ended ques ons that require longer answers than a simple yes or no. In an unstructured interview, the interviewer can also ask follow-up ques ons to help the respondent deepen their answers. An unstructured interview, therefore, resembles a real conversa on. 4. Semi-structured interview

You can also use semi-structured interview techniques that combine parts of structured and unstructured interviews. Interviewers will follow a general plan and set of ques ons, but are o en exible enough to make changes. This allows interviewers to be crea ve in ge ng the data they need for their research.

5. Personal interview

A face- -face interview takes place as a face- -face exchange between an interviewer to toand an interviewee. Face- -face interviews are best when you want to speak directly to

</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">

and ask ques ons. You can also ask follow-up ques ons for addi onal insight. Face- -toface interviews typically have a higher response rate than other interview op ons and are ideal when you need to collect large amounts of accurate data.

6. Phone interview

A telephone interview is also possible. A phone interview is an easy way to get answers. This survey method is also rela vely inexpensive, making it ideal if you want to collect data quickly without consuming too many resources.

Phill Lewis Founder Feature of System, The mo o of the company.

1. What new features will be added to the system in the future 2. Bene ts gained from customer feedback

3. Who will the project target? Kevin Har Founder Typical features and

problems

encountered in the system

1. What are the problems in the system?

2. Project when downgrading

members does the project have? 4. Is the buying process on the system reasonable? Ariana Grande Founder Useful informa on

about the book, the

1. Where do you get your books from?

</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">

eye-catching

interface of the book ^{2. Does the book-}selling interface a ract and retain customers?

3. How does your project's book front end meet the security and permission requirements? David Beckham Sponsor Selling books through

</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">

the customer's request?

Table 2: Interview IV. System requirements

Functional requirements of the system: Admin:

Login Logout

Customer Management add, edit, delete, arrange, search ) ( Order Management add, edit, delete, arrange, search ) ( Employee Account add, edit, delete, arrange, search ) ( Book Management add, edit, delete, arrange, search ) ( Order Detail Management add, edit, delete, arrange, search ) ( Category Manager add, edit, delete, arrange, search ) ( User:

Login Logout Register

Customer Account Order

Feedback Payment

Non-functional requirements of the system: Performance:

</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">

The page is designed to be easy to see and easy to use Can be compa ble with many computers

</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">

USE APPROPRIATE SOFTWARE ANALYSIS TOOLS/TECHNIQUES TO CARRY OUT A SOFTWARE INVESTIGATION AND CREATE SUPPORTING DOCUMENTATION (P6)

I. Use case diagram 1. Definition

A use case illustra on is a way to epitomize details of a system and the druggies within that system. It's generally shown as a graphic de ni on of rela ons among di erent rudiments in a system. Use case plates will specify the events in a system and how those events in ow, s ll, use case illustra on doesn't describe how those events are enforced. A use case is a methodology used in system analysis to iden fy, clarify, and organize system condi ons. In this environment, the term" system" refers to a commodity being developed or operated, similar to a correspondence- order product deals and service Web points. Use case plates are employed in UML( Uni ed Modeling Language), a standard memorandum for the modeling of real-world objects and systems. There are a number of bene ts to having a use case illustra on over analogous plates similar to

owcharts.

Use case diagram uses

The reasons why an organiza on would want to use case diagrams include: Represent the goals of systems and users.

Specify the context a system should be viewed in. Specify system requirements.

Provide a model for the ow of events when it comes to user interac ons. Provide an outside view of a system.

Show’s external and internal in uences on a system. How use case diagrams work

System objec ves can include planning overall requirements, valida ng a hardware design, tes ng and debugging a so ware product under development, crea ng an

</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">

online help reference or performing a consumer-service-oriented task. For example, use cases in a product sales environment would include item ordering, catalog upda ng, payment processing, and customer rela ons. A use case diagram contains four components.

The boundary, which de nes the system of interest in rela on to the world around it.

The actors, usually individuals involved with the system de ned according to their roles.

The use cases, which are the speci c roles played by the actors within and around the syste m.

The rela onships between and among the actors and the use cases. 2. Identify actors and use cases for each actor

</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31">

Actor Use case

Logout

Customer Management add, ( edit, delete, arrange, search ) Order Management add, edit, (

delete, arrange, search ) Employee Account add, edit, (

delete, arrange, search ) Book Management add, edit, (

delete, arrange, search ) Order Detail Management (

add, edit, delete, arrange, search )

Category Manager add, edit, ( delete, arrange, search )

Logout Register

Customer Account Order

Feedback Payment Table 3: Actors and use cases for each actor

3. Draw a use case diagram

</div><span class="text_page_counter">Trang 32</span><div class="page_container" data-page="32">

Figure 1: Usecase level 1

</div><span class="text_page_counter">Trang 33</span><div class="page_container" data-page="33">

Figure 2: Book Management

Figure 3: Category Management

</div><span class="text_page_counter">Trang 34</span><div class="page_container" data-page="34">

Figure 4: Orders Management

</div><span class="text_page_counter">Trang 35</span><div class="page_container" data-page="35">

Figure 5: Customer Management

Figure 6: Customer Account

</div><span class="text_page_counter">Trang 36</span><div class="page_container" data-page="36">

Figure 7: Employee Account

</div><span class="text_page_counter">Trang 37</span><div class="page_container" data-page="37">

Figure 8: Order detail Management

Figure 9: Account

</div><span class="text_page_counter">Trang 38</span><div class="page_container" data-page="38">

Figure : Order10

</div><span class="text_page_counter">Trang 39</span><div class="page_container" data-page="39">

Figure : Pay11

1 UC01 Login Allow people with accounts to access the system

2 UC02 Register Actor provides informa on to create an account to access the system

4 UC04 Add Book Add new books to their system 5 UC05 Update Book Update books to their system 6 UC06 Delete Book Delete books in their system

7 UC07 Arrange Book Arrange book by book id, Arrange book name by book name

8 UC08 Search Book Search for book by book name 9 UC09 Add Category Add new category to their system 10 UC10 Update Category Update category to their system 11 UC11 Delete Category Delete category in their system 12 UC12 Arrange Category Arrange category by category id, Arrange

category name by category name 13 UC13 Search Category Search for category by category name 14 UC14 Add Orders Add new orders to their system 15 UC15 Update Orders Update orders to their system 16 UC16 Delete Orders Delete orders in their system

</div><span class="text_page_counter">Trang 40</span><div class="page_container" data-page="40">

d d b d d18 UC18 Search Orders Search for orders by orders id 19 UC19 Add Customer Add new customer to their system 20 UC20 Update Customer Update customer to their system 21 UC21 Delete Customer Delete customer in their system 22 UC22 Arrange Customer Arrange customer by customer id,

Arrange customer name by customer name

23 UC23 Search Customer Search for customer by customer name 24 UC24 Add Customer

Account

Add new customer account to their system

25 UC25 Update Customer

Account Update customer account to their system 26 UC26 Delete Customer

Account Delete customer account in their system

</div>