Báo cáo phân tích quản lý yêu cầu

Báo cáo bài tập lớn môn phân tích quản lý yêu cầu, Phân tích quản lý yêu cầu website cửa hàng mĩ phẩm

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO BÀI TẬP LỚN

MÔN PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU PHẦN MỀM

ĐỀ TÀI: PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU DỰ ÁN XÂY DỰNG WEBSITE BÁN MỸ PHẨM

Lê Bảo Lộc

Đỗ Quốc Huy

Thái Nguyên, Ngày 07 Tháng 05 Năm 2024

Bảng phân công công việc nhóm

1 Tạ Quang Hoà

- Phân chia công việc cho nhóm

- Xây dựng tổng quan

2 Lê Bảo Lộc - Viết tài liệu đặc tả Usecase và các nội dung

chương 6

3 Đặng Minh Ánh

- Viết tài liệu Requirements Management Plan – RMP, Supplementary Requirement

và các nội dung chương 2, chương 7

4 Đỗ Quốc Huy

- Viết tài liệu Stakeholder Requests, Glossary và các nội dung chương 3, chương 4

5 Ngô Thị Khánh Ly

- Viết tài liệu Vision dự án, thiết kế Testcase

và nội dung chương 5

- Kết luận cho nội dung thảo luận

MỤC LỤC

CHƯƠNG I TỔNG QUAN VỀ PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU

1.1 Giới thiệu

1.3 Thành viên dự án

1.4 Phát biểu bài toán

1.5 Vấn đề

1.6 Đề xuất giải pháp

1.7 Mô hình quy trình phần mềm

1.8 Tổng quan về kim tự tháp yêu cầu

CHƯƠNG 2: BẢN KẾ HOẠCH YÊU CẦU

1.1 Giới thiệu

1.1.1 Mục đích

1.1.2 Phạm vi

1.1.3 Định nghĩa, Các từ viết tắt, và Các ký hiệu

1.1.4 Tài liệu tham khảo

1.1.5 Tổng quan

1.2 Quản lý yêu cầu

1.2.1 Các tổ chức, Trách nhiệm, và Thông tin liên lạc

1.2.2 Bảng liên lạc

1.2.3 Các công cụ, Môi trường, và Cơ sở hạ tầng

1.3 Các thông tin yêu cầu

1.3.1 Mô tả thông tin

1.3.2 Dấu vết

1.3.3 Các báo cáo, thông số đo đạc

1.4 Quản lý thay đổi các yêu cầu

1.4.1 Xử lý và phê chuẩn yêu cầu thay đổi

1.4.2 Ban điều khiển thay đổi (CCB)

1.4.3 Các kết quả bàn giao

1.4.4 Luồng công việc và các hoạt động

1.5 Các mốc thời gian

1.5.1 Khởi tạo/ Inception

1.5.2 Chuẩn bị/Elaboration

1.5.3 Xây dựng/Construction

1.5.4 Chuyển dịch/Transition

CHƯƠNG 3: GLOSSARY

CHƯƠNG 4: STAKEHOLDER REQUEST

1 Giới thiệu

1.1 Mục đích

1.2 Phạm vi, thời gian và kinh phí

1.2.1 Phạm vi của thu thập yêu cầu

1.2.2 Kinh phí cho việc thu thập

1.3 Kĩ thuật thu thập yêu cầu

2 Thiết lập hồ sơ người dùng hoặc bên liên quan

3 Đánh giá vấn đề

4 Hiểu môi trường người dùng

5.Tóm tắt để hiểu

5.1.Các vấn đề được bên liên quan mô tả:

6 Đầu vào của nhà phân tích về vấn đề của bên liên quan

7 Đánh giá cơ hội

8.Đánh giá độ tin cậy và nhu cầu hỗ trợ

8.1.Kì vọng về độ tin cậy :

8.2 Kỳ vọng về hiệu suất:

8.3 Những yêu cầu hỗ trợ :

9.Tóm tắt của nhà phân tích

9.1 Các yêu cầu đã được xác nhận bởi người dùng/bên liên quan này

10 Phân tích các yêu cầu của Stakeholder

11 Bảng truy vết

CHƯƠNG 5: TÀI LIỆU VISION

5.1 Giới thiệu

5.1.1 Mục đích

5.1.2 Phạm vi

5.1.3 Tài liệu tham khảo

5.1.4 Tổng quan

5.2 Vai trò

5.2.1 Cơ hội nghiệp vụ

5.2.2 Phát biểu vấn đề

5.2.3 Phát biểu về vai trò của sản phẩm

5.3 Các mô tả người dùng và Stakeholder

5.3.1 Các thuật ngữ thị trường

5.3.2 Mô tả Stakeholder

5.4 Tổng quan về sản phẩm

5.4.1 Viễn cảnh sản phẩm

5.4.2 Tóm tắt về các khả năng

5.5 Các đặc trưng sản phẩm

5.6 Các ràng buộc

5.7 Các yêu cầu sản phẩm khác

5.7.1 Yêu cầu chức năng

5.7.2 Yêu cầu phi chức năng

6.1 Biểu đồ use case

6.1.1 Use case tổng quát

6.1.2 Use case phân rã đăng nhập

6.1.3 Use case phân rã Tìm kiếm sản phẩm

6.1.4 Use case phân rã Xem sản phẩm

6.1.5 Use case phân rã Quản lý giỏ hàng

6.1.6 Use case phân rã Quản lý đơn hàng cá nhân

6.1.7 Use case phân rã Quản lý danh sách mong muốn

6.1.8 Use case phân rã Quản lý tài khoản cá nhân

6.1.9 Use case phân rã Quản lý sản phẩm

6.1.10 Use case phân rã Quản lý đơn hàng

6.1.11 Use case phân rã Quản lý đánh giá khách hàng

6.1.12 Use case phân rã Quản lý kho hàng

6.1.13 Use case phân rã Quản lý tài khoản nhân viên

6.1.14 Use case phân rã Quản lý Danh mục

6.2 Biểu đồ lớp

6.3 Đặc tả chi tiết các use case

6.3.1 Chức năng đăng nhập

6.3.2 Chức năng đăng ký

6.3.3 Chức năng Xem chi tiết sản phẩm

6.3.4 Chức năng Thêm sản vào danh sách mong muốn

6.3.5 Chức năng Thanh toán

6.3.7 Chức năng Huỷ đơn hàng

6.3.8 Chức năng Liên hệ

6.3.9 Chức năng Xem lịch sử đơn hàng

6.3.10 Chức năng Thêm sản phẩm vào giỏ hàng

6.3.11 Chức năng Xoá sản phẩm khỏi giỏ hàng

6.3.12 Chức năng Xem mỹ phẩm đề xuất

6.3.13 Chức năng Thêm sản phẩm vào danh mục

6.3.14 Chức năng Tìm kiếm sản phẩm theo giá

6.3.15 Chức năng Tìm kiếm theo danh mục

6.3.16 Chức năng Tìm kiếm theo từ khoá

6.3.17 Chức năng Chăm sóc khách hàng

6.3.18 Chức năng Quản lý sản phẩm

6.3.19 Chức năng Phê duyệt đánh giá khách hàng

CHƯƠNG 7: SUPPLEMENTARY REQUIREMENT

7.1 Mục đích

7.2 Phạm vi

7.3 Định nghĩa, Các từ viết tắt, và Các ký hiệu

7.4 Tài liệu tham khảo

7.5 Tổng quan

7.6 Chức năng

7.7 Khả năng sử dụng

7.8 Độ tin cậy

7.9 Hiệu suất

7.10 Khả năng hỗ trợ

7.11 Các ràng buộc về thiết kế

7.12 Tài liệu người dùng trực tuyến và yêu cầu hệ thống trợ giúp

7.13 Các yêu cầu về giao diện

KẾT LUẬN

Kết quả đạt được

Khó khăn

Kế hoạch

CHƯƠNG I TỔNG QUAN VỀ PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU

1.1 Giới thiệu

Chương này giới thiệu sơ lược về thông tin, phát biểu bài toán và đề xuất ý tưởng của dự án Qua

đó giúp độc giả có được cái nhìn tổng quan về nội dung, phạm vi của tài liệu cũng như những côngviệc mà đội dự án sẽ làm

1.4 Phát biểu bài toán

Cửa hàng Mỹ phẩm Ánh Ly là đơn vị đã có nhiều năm kinh nghiệm trên thị trường mỹ phẩmvới lối kinh doanh truyền thống Tuy nhiên, cửa hàng đang phải đối mặt với nhiều khó khăn, tháchthức trong quá trình quản lý đơn hàng, nhân viên, sản phẩm tồn kho và báo cáo doanh thu

Hiện tại, quá trình đặt hàng thông qua fanpage hoặc tại quán gặp nhiều vấn đề như: thời gianchờ đợi lâu, ghi chép hoá đơn không chính xác dẫn đến nhầm lẫn và tốn thời gian của cả nhân viên,khách hàng Bên cạnh đó, việc quản lý sản phẩm tồn kho, quản lý nhân viên, khách hàng thân thiếtcũng gây nhiều khó khăn cho quản lý

Do đó, cửa hàng cần một công cụ hỗ trợ tối ưu hơn trong việc quản lý bán hàng Để giải quyếtbài toán đó, dự án sẽ tập trung vào việc xây dựng một Website bán hàng trực tuyến cho cửa hàng

mỹ phẩm Ánh Ly Website sẽ được thiết kế với giao diện thân thiện, dễ sử dụng, đầy đủ chức năng

để giúp tăng doanh số bán hàng, nâng cao chất lượng dịch vụ cũng như tiết kiệm thời gian, chi phícho doanh nghiệp

1.5 Vấn đề

Vấn đề của cửa hàng mỹ phẩm Ánh Ly là việc quản lý đơn đặt hàng của người dùng thông quafanpage hay trực tiếp tại cửa hàng gặp nhiều thách thức Từ đó dẫn đến sự nhầm lẫn các đơn hàng,chi phí và thời gian của cả hai bên Nhất là trong thời đại công nghệ thông tin phát triển, sự tích hợpcông nghệ vào bán hàng sẽ giúp nâng cao trải nghiệm khách hàng cũng như tăng doanh thu cho đơnvị

Ngoài ra, cửa hàng còn gặp khó khăn trong việc quản lý nhân viên, hàng tồn kho cũng nhưbáo cáo thu chi hàng ngày/tuần/tháng Các công việc trên đều được thực hiện trên giấy tờ nên gâytốn thời gian, thất lạc và khó khăn khi tìm kiếm Chính vì thế, việc xây dựng một Website bán hàngtrực tuyến sẽ giúp giải quyết những thách thức trên Các vấn đề về quản lý đơn hàng, sản phẩmtrong kho, quản lý nhân viên, sẽ được tích hợp trên website, qua đó giúp nâng cao hiệu quả quản

lý và kinh doanh cho cửa hàng

1.6 Đề xuất giải pháp

Giải pháp đề xuất của đội dự án cho vấn đề của cửa hàng hiện thời là phát triển một websitebán hàng để giúp những khách hàng ở xa có thể đặt hàng thuận tiện, nhanh chóng và theo dõi đượcđơn hàng của mình Bên cạnh đó còn giúp cửa hàng quản lý sản phẩm, nhân viên sát sao hơn, cũngnhư giúp việc tạo báo cáo thống kê dễ dàng, tăng tính nhận diện thương hiệu cho cửa hàng

Các khả năng của giải pháp này có thể gồm:

● Có giao diện thân thiện, dễ sử dụng

● Giúp khách hàng có thể đặt hàng thuận tiện, nhanh chóng và theo dõi được đơn hàng củamình

● Hỗ trợ quản lý chặt chẽ về sản phẩm, quản lý nhân viên hay khách hàng thân thiết

● Tăng tính nhận diện của thương hiệu, mở rộng khả năng tiếp cận nhiều tệp khách hàng ở trên

cả nước

● Hỗ trợ cập nhật sản phẩm đơn giản và linh hoạt

● Giúp tối ưu hóa trải nghiệm người dùng, mang đến những dịch vụ tiện ích cho khách hàng

1.7 Mô hình quy trình phần mềm

Mô hình quy trình phần mềm RUP (Rational Unified Process) là một mô hình phát triển phầnmềm tiêu chuẩn và linh hoạt, dựa trên các nguyên tắc lập trình hướng đối tượng và các quy trìnhquản lý dự án Dưới đây là một tóm tắt về các pha và hoạt động chính trong quy trình RUP:

● Khởi đầu (Inception):

❖ Xác định nhu cầu và mục tiêu của dự án

❖ Phát triển một kế hoạch chi tiết cho dự án

❖ Xác định và quản lý các rủi ro tiềm ẩn

● Xây dựng (Construction):

❖ Phát triển các thành phần và chức năng của hệ thống

❖ Tiến hành kiểm thử và debug để đảm bảo chất lượng

❖ Tạo ra tài liệu và hướng dẫn sử dụng hệ thống

● Chuyển giao (Transition):

❖ Chuẩn bị và triển khai hệ thống cho người dùng cuối

❖ Cung cấp hỗ trợ và bảo trì cho hệ thống sau khi triển khai

Mỗi pha trong RUP được chia thành nhiều vòng lặp (iterations), trong đó các hoạt động đượcthực hiện một cách lặp đi lặp lại để cải thiện và hoàn thiện sản phẩm phần mềm Quy trình RUPcũng đặc biệt chú trọng vào việc lập trình hướng đối tượng và việc sử dụng mô hình Use Case để mô

tả yêu cầu của hệ thống và tương tác của người dùng

Mô hình quy trình RUP là một trong những mô hình phát triển phần mềm phổ biến và được

sử dụng rộng rãi trong ngành công nghiệp phần mềm Nó cung cấp một cách tiếp cận có cấu trúc vàlinh hoạt cho việc phát triển phần mềm, giúp đảm bảo chất lượng và đáp ứng được nhu cầu củakhách hàng.

Cơ cấu tổ chức

● Team hoặc nhóm dự án (Project Team):

❖ Là nhóm người lao động trực tiếp trên dự án.

❖ Bao gồm các vai trò như lập trình viên, kiến trúc sư phần mềm, kiểm thử viên, quản lý dự

án, v.v.

❖ Mỗi thành viên đảm nhận các nhiệm vụ cụ thể tương ứng với vai trò của họ trong dự án.

● Lãnh đạo dự án (Project Leadership):

❖ Bao gồm các vai trò như Product Manager (Quản lý Sản phẩm), Project Manager (Quản lý

dự án), và Technical Manager (Quản lý Kỹ thuật).

❖ Quản lý và điều phối hoạt động của nhóm dự án.

❖ Đảm bảo rằng dự án tiến triển theo kế hoạch và đáp ứng được các yêu cầu của khách hàng.

● Người sử dụng (End Users):

❖ Là nhóm người cuối cùng sẽ sử dụng sản phẩm phần mềm.

❖ Cung cấp thông tin phản hồi và yêu cầu để giúp định hình và cải thiện sản phẩm.

❖ Tham gia vào quá trình kiểm thử và chuyển giao sản phẩm.

● Khách hàng và Stakeholders (Customers and Stakeholders):

❖ Là nhóm người hoặc tổ chức có liên quan trực tiếp đến dự án và có lợi ích trong sản phẩm cuối cùng.

❖ Cung cấp thông tin về yêu cầu, ưu tiên, và mong đợi của họ đối với sản phẩm.

❖ Tham gia vào việc xác nhận và phê duyệt các yêu cầu và phát triển sản phẩm.

1.8 Tổng quan về kim tự tháp yêu cầu

Hình 1 : Kim tự tháp yêu cầu

Needs: Yêu cầu được đề xuất bởi Stakeholder

Feature(Tính năng): Một dịch vụ được cung cấp bởi hệ thống để phục vụ yêu cầu của

Stakeholder

Use Case: Mô mô tả về hành vi của hệ thống.

Supplementary requirement: Các yêu cầu bổ xung, thường là các yêu cầu phi chức năng Scenario (Kịch bản): Một chuỗi hành động cụ thể, một đường hành động đi qua một Use

Case

Test Case: Đặc tả về một đầu vào kiểm thử, các điều kiện thực thi và kết quả mong đợi.

CHƯƠNG 2: BẢN KẾ HOẠCH YÊU CẦU

1.1.2. Phạm vi

Bản kế hoạch này cung cấp các hướng dẫn cho hoạt động quản lý của dự án Website bán mỹphẩm trực tuyến

1.1.3. Định nghĩa, Các từ viết tắt, và Các ký hiệu

Từ vựng và các thuật ngữ sử dụng trong dự án này được cung cấp trong tài liệu Glossary của

dự án

1.1.4. Tài liệu tham khảo

- Kruchten, Philippe 1999 The Rational Unified Process Menlo Park, CA: Addison

Wesley

- Leffingwell, D and Don Widrig 2000 Managing Software Requirements Menlo Park,

CA: Addison Wesley

- Spence, I and L Probasco 1998 Traceability Strategies for Managing Requirements

with Use Cases Cupertino, CA: Rational Software Corporation.

1.1.5. Tổng quan

Tài liệu này cung cấp các mô tả chi tiết về quản lý yêu cầu trong dự án Website bán mỹ phẩm trực tuyến, bao gồm:

1 Cách tổ chức và quản lý yêu cầu trong dự án, bao gồm cách xác định, gán thuộc tính, theo dõi

và sửa đổi các yêu cầu

2 Quy trình quản lý thay đổi yêu cầu, bao gồm cả luồng công việc và các hoạt động liên quanđến kiểm soát và bảo trì yêu cầu dự án

3 Xác định các mốc thời gian quan trọng để hoàn thành công việc và mô tả các tiêu chuẩn được

sử dụng để đánh giá yêu cầu trong dự án

1.2 Quản lý yêu cầu

1.2.1. Các tổ chức, Trách nhiệm, và Thông tin liên lạc

Khách hàng

Cá nhân hoặc tổ chức có trách nhiệm tài chính cho hệ thống, có thể không phải là người dùngcuối trong trường hợp của hệ thống lớn Có vai trò nhận bàn giao sản phẩm cuối cùng

Người dùng

Những người sẽ sử dụng hệ thống và có vai trò thực hiện các nhiệm vụ sử dụng hệ thống

Các bên liên quan

Tổ chức hoặc cá nhân có ảnh hưởng đến và bị tác động bởi kết quả hệ thống

Quản lý dự án

Người có trách nhiệm và vai trò tổng thể trong dự án, đảm bảo nhiệm vụ được lập lịch, phân công và dự án hoàn thành đúng lịch trình và ngân sách

Đảm bảo chất lượng (QA)

Bộ phận đảm bảo chất lượng sản phẩm, thực hiện kiểm định chất lượng và báo cáo để đảm bảo chuẩn dự án được thực hiện đúng

Lập trình viên

Người phát triển có trách nhiệm xây dựng các chức năng sản phẩm theo yêu cầu và tham gia

từ thu thập thông tin đến triển khai

Lãnh đạo nhóm

Người lãnh đạo nhóm giữ vai trò giao tiếp giữa quản lý dự án và thành viên phát triển, đảm bảo tuân thủ chuẩn và lịch biểu của dự án.

Khách hàng Nguyễn Ánh Ly Đại diện shop

mỹ phẩm

Shop mỹ phẩm

Shop mỹ phẩm

nvien@cosmeticshop.com

Bên liên quan Nguyễn Trần

Hoàng

Kế toán shop

mỹ phẩm

Shop mỹ phẩm

ntha@cosmeticshop.com

Quản lý dự án

Tạ Quang Hoà

Người quản lý

dự án phần mềm

Nhóm pháttriển dự án

dtc21h4801030002@ictu.edu.vn

Nhóm pháttriển dự án

dtc2154801030008@ictu.edu.vn

Lập trình viên Ngô Thị Khánh Ly Lập trình viên Nhóm phát

triển dự án

dtc2154108030088@ictu.edu.vn

dtc21h4801081003@ictu.edu.vn

Đặc tả viên Lê Bảo Lộc Đặc tả phần Nhóm phát dtc21h4801030057@

mềm triển dự án ictu.edu.vn

1.2.3. Các công cụ, Môi trường, và Cơ sở hạ tầng

support@asan.com www.asana.co

m

Google Docs Tạo và làm

việc với các tài liệu

through our internal technical support team

http://

docs.google.co

m Google Drive Lưu trữ,

update các tài liệu

through our internal technical support team

http://

drive.google.co

m

1.3 Các thông tin yêu cầu

1.3.1. Mô tả thông tin

● Các kiểu tài liệu

Stakeholder

Requests (STR)

Các đòi hỏi chính từ stakeholders

Stakeholder Request (STRQ)

Vision (VIS) Tài liệu này chứa các điều

kiện hoặc khả năng của bản phát hành hệ thống hiện thời

Feature (FEAT)

Use-Case

Specification (UCS)

Mô tả và xây dựng Use case Use Case (UC)

Glossary (GLS) Tài liệu này chứa các thuật Glossary Item (TERM)

Supplementary Requirement (SUPL)

để quản lý và phát triển của

kế hoạch quản lý yêu cầu

Requirements ManagementPlan (RMP)

Các kiểu yêu cầu

Stakeholder

Request (STRQ)

Một đòi hỏi từ phía stakeholder - ví dụ: Yêu cầu cần phải nâng cấp

(Enhancement request), Yêucầu thay đổi (Change

Request), đòi hỏi thay đổi một yêu cầu, một lỗi được phát hiện

Stakeholder Priority(Ưu tiên của các bên liên quan), Cost (Chi phí), Origin(Nguồn gốc)

Feature (FEAT) Một chức năng/dịch vụ

được hệ thống cung cấp trực tiếp đáp ứng một yêu cầu của stakeholder

Độ ưu tiên (Priority), Type(Kiểu), Status (Trạng thái), Difficulty (Độ khó), Stability (Tính ổn định), Risk (Rủi ro),Planned Iteration (Lặp lại theo kế hoạch), Actual Iteration (Lặp lại thực tế), Origin (Nguồn gốc), ContactName (Tên liên lạc), Defect(Khuyết điểm), Cost (Chi phí)

Use Case (UC) Mô tả hành vi của hệ thống Độ ưu tiên (Priority), Status

thông qua một chuỗi các hành động Một Use Case nên tạo ra một kết quả trực quan hoặc giá trị đối với tác nhân.

(Trạng thái), Difficulty (Độ khó), Stability (Tính ổn định), Risk (Rủi ro), PlannedIteration (Lặp lại theo kế hoạch), Actual Iteration (Lặp lại thực tế), Defect (Khuyết điểm), Cost (Chi phí), Test (Kiểm thử), Origin(Nguồn gốc)

Glossary Item

(TERM)

Thuật ngữ được sử dụng trong từ vựng của dự án

Các thuộc tính

Thuộc tính Mô tả Kiểu Danh sách các giá

Độ ưu tiên

(Priority)

Độ ưu tiênđược gán bởinhóm quản lý

dự án Dựavào độ ưu tiên

để lọc ra cácyêu cầu chotừng lần lặpcủa RUP

list

Must (phải đáp ứng)

FEAT, UC, SUPL

Should (nên đáp ứng)

Could (có thể đápứng?)

Won't (không cầnđáp ứng)

Usability (Khả năng sử dụng)Reliability (Độ tin cậy)

Performance (Hiệu suất)Supportability (Khả năng hỗ trợ)Design Constraint(Ràng buộc thiết kế)

Implementation (Triển khai)Physical (Vật lý)Interface (Giao diện)

Trạng thái

(Status)

Được thiết lập bởi nhóm quản lý sau khi xét duyệt

và thương lượng với khách hàng

Low (thấp)

Độ ổn định

(Stability)

Được thiết lập bởi người pháttriển phần mềm Là một tiêu chí để gán

độ ưu tiên cho yêu cầu

list

High (cao)

FEAT, UC,SUPL

Medium (trung bình)

Low (thấp)Lần lặp được

Competitors (đối thủ cạnh tranh)Large Customers (khách hàng lớn)n/a

Contact Name

Chi phí (Cost) real

n/a

FEAT, UC, SUPL, STRQ

Khuyết điểm

Stakeholder

Priority

(Ưu tiên của các

bên liên quan)

list

High (cao)

STRQ

Medium (trung bình)

Low (thấp)

Danh sách các giá trị

Mô tả [Định nghĩa mỗi giá trị thuộc tính]

Proposed/Được đề xuất

Status

Được đề xuất bởi một stakeholder request

Approved/Đã được phê chuẩn

Được phê chuẩn bởi người quản lý dự án/bộ phận đảm bảo chất lượng

High/Cao Difficulty/Độ Quá khó, tốn quá nhiều kinh phí hoặc

nguồn tài nguyên để triển khai Nên

được quan tâm hàng đầu hoặc bị loại bỏ

Medium/Trung bình

Khó, nhưng có thể làm được vì không

có quá nhiều rủi ro Chỉ nên quan tâm sau khi các yêu cầu khó mức cao được giải quyết

High/Cao

Stability/Độ ổn định

Sẽ không có khả năng thay đổi

Hotline/Đường dây nóng

Origin/Nguồn gốc

Từ bộ phận hỗ trợ kỹ thuật hoặc các bên bán hàng – khách hàng nhỏ lẻ

Partners/Bên tham gia

Từ các đối tác khách hàng, nhóm phát triển cộng tác

Competitors/Bên đối thủ Từ các đối thủ cạnh tranh

Độ rủi ro cao khi thực hiện

Low/ L

Độ rủi ro thấp, có thể được quản lý và kiểm soát, đưa ra phương án giải quyết

1.3.2. Dấu vết

- Tiêu chuẩn thiết lập dấu vết cho các kiểu yêu cầu

Stakeholder Mọi yêu cầu của

Request (STRQ) stakeholder có trạng thái là

“Approved” phải ánh xạ đến

1 hoặc nhiều Features

Feature (FEAT) Mọi Feature với trạng thái là

“Approved” hoặc lớn hơn phải ánh xạ đến 1 hoặc nhiều Use Cases, hoặc có thể ánh xạ đến 1 hay nhiều Supplementary

Requirements

Use Case (UC) Tất cả Use Case cần mô tả

chi tiết các tương tác giữa các tác nhân bên ngoài (actors) và hệ thống

Các Use Case cần xác định

và mô tả rõ các tác nhân tham gia trong tương tác

Glossary Item

(TERM)

Mọi thuật ngữ Glossary phải

có ý nghĩa duy nhất và sử dụng thống nhất trong tất

cả các kết quả và các tài liệu

1.3.3. Các báo cáo, thông số đo đạc

Các báo cáo và chỉ số của dự án được tạo ra sử dụng công cụ Requirement Metrics (có sẵn từ thanh menu của công cụ) Các báo cáo được tạo dựa trên các loại yêu cầu hoặc các khung nhìn đã

được lưu và các truy vấn với các tiêu chí lọc như sau:

- Attribute Value/Giá trị thuộc tính:

Lọc theo giá trị thuộc tính để trả về các yêu cầu với thuộc tính khớp với tiêu chí lọc

- Attribute Value Range/Vùng giá trị thuộc tính:

Lọc theo vùng giá trị thuộc tính để trả về các yêu cầu với giá trị thuộc tính khớp với tiêu chí lọc

- Requirement Type/Lọc theo kiểu yêu cầu:

Trả về các yêu cầu thuộc kiểu tương ứng khớp với kiểu của nó

Features Hiển thị tất cả

các yêu cầu thuộc kiểu Feature

y Requirements

Stakeholder

Request

Liệt kê mọi yêu cầu thuộckiểu

Stakeholder Request (NEED) ở trạng thái được đề xuất mới

Use Case Survey Liệt kê tất cả

các yêu cầu thuộc kiểu Use Case

1.4 Quản lý thay đổi các yêu cầu

1.4.1. Xử lý và phê chuẩn yêu cầu thay đổi

● Các yêu cầu thay đổi, yêu cầu nâng cấp hoặc đề xuất từ stakeholder được tiếp nhận

● CCB đánh giá ảnh hưởng của thay đổi đối với các thông tin khác, chi phí và lịch biểu

● Trách nhiệm triển khai các thay đổi được giao cho các thành viên tương ứng

● Các thay đổi được tích hợp vào build và trải qua quá trình kiểm thử

● Các yêu cầu thay đổi được đánh giá và đóng lại sau khi hoàn thành

1.4.2. Ban điều khiển thay đổi (CCB)

CCB là một nhóm các bên liên quan có trách nhiệm đánh giá tác động của các thay đổi, xác định độ ưu tiên và phê chuẩn chúng

● Người quản lý điều khiển thay đổi

Vai trò của người quản lý điều khiển thay đổi là xem xét quy trình quản lý thay đổi Thường,vai trò này được thực hiện bởi Ban Điều khiển Cấu hình (CCB), bao gồm đại diện từ mọi bênliên quan như khách hàng, nhà phát triển và người dùng Trong các dự án nhỏ, người quản lý

dự án hoặc kiến trúc sư phần mềm có thể đảm nhận vai trò này

Người quản lý điều khiển thay đổi cũng chịu trách nhiệm định nghĩa quy trình quản lý yêu cầuthay đổi, như đã được mô tả trong kế hoạch quản lý cấu hình phần mềm (CM Plan)

● Các bên liên quan

Đề xuất các yêu cầu thay đổi

1.4.3. Các kết quả bàn giao

Bảng baseline các kết quả sau mỗi lần lặp

Requirements Management Plan, Xác định độ ưu tiên & gán yêu cầu/lần lặp, Vision Document/Tài liệu tổng quan(tầm nhìn), Tài liệu stakeholder request

31/1/2024

cầu FEAT, Use Cases,Tài liệu SUPL,Lập kế hoạch cho các lần lặp tiếp theo

25/2/2024

3 Draft 3 Tập yêu cầu về phát hành,

Update Vision, Lập kế hoạch cho giai đoạn triển khai

5/3/2024

đầy đủ chức năng

10/3/2024

1.4.4. Luồng công việc và các hoạt động

Mô tả các hoạt động trong tiến trình quản lý yêu cầu thay đổi.

cầu tương ứng

Submit CR/Gửi

yêu cầu thay đổi

Stakeholder có thể đề xuất CR(Change Request) CR sau đó sẽđược nhập vào hệ thống theo dõiyêu cầu thay đổi (Change RequestTracking System, ví dụ: Người dùng

có thể đề xuất CR để thêm một tínhnăng mới vào hệ thống CR sẽ đượcđưa vào hệ thống quản lý yêu cầuthay đổi và chờ xem xét từ CCB,trong trạng thái "Proposed"

độ rủi ro Quyết định này được đưa

CCB Delegate Proposed

có thể cập nhật CR với thông tin mới Sau khi cập nhật, CR sẽ được

đề xuất lại vào CCB Review Queue

và coi như một CR mới

Khi một Change Request (CR) được

mở, người quản lý dự án sẽ phân công công việc cho thành viên tương ứng, dựa vào loại của CR (ví dụ: enhancement request, defect, documentation change, test defect, vv.), và tạo các cập nhật cần thiết cho lịch biểu dự án

Project Manager

design, implementation,produce,user-support, materials, design test, ) để triển khai các thay đổi Saukhi hoàn thành, thực hiện việc xétduyệt và kiểm thử đơn vị, sau đó CRđược đánh dấu là Resolved

Assigned Team Member

Sau đó, chúng được thẩm địnhtrong test build của sản phẩm

Sau khi các thay đổi được giải quyết

và xác minh trong test build của sảnphẩm, CR được đưa vào hàng đợichờ phát hành để được xác minh lạitrong release build của sản phẩm,tạo thông báo phát hành, và sau đó

CR được đóng

CCB Delegate (System Integrator)

Validated

1.5 Các mốc thời gian

1.5.1. Khởi tạo/ Inception

Trong giai đoạn này sẽ khảo sát hiện trạng, xác định và phân tích yêu cầu sơ bộ từ khách

hàng Xây dựng tài liệu Requirements Management Plan, xác định các ưu tiên Tài liệu tầm nhìn xácđịnh vấn đề cần giải quyết của dự án, mục đích và các bên liên quan chính

Trong giai đoạn này, một bản trình bày PowerPoint toàn diện về hệ thống sẽ được tạo, đó sẽ

là một bằng chứng về khái niệm cho dự án Bản trình bày này sẽ được xem xét bởi các bên liên quanchính để đánh giá tính hợp lý và khả thi

1.5.1.1 Tiêu chuẩn đánh giá

Stakeholders định rõ phạm vi, thực hiện các ước lượng về chi phí và lịch biểu cho dự án:

● Thương lượng về tập yêu cầu cần triển khai và chia sẻ để tất cả các bên liên quan hiểu rõ về chúng

● Các thương lượng cũng bao gồm ước lượng về lịch biểu và chi phí, độ ưu tiên, rủi ro, và đảm bảo rằng quy trình phát triển là phù hợp

● Mọi rủi ro được xác định và chiến lược được áp dụng cho từng rủi ro cụ thể

Nếu không đạt được kết quả mong đợi tại mốc thời gian này, dự án có thể phải bị từ bỏ hoặc được xem xét lại

1.5.1.2 Các kết quả

Nhiệm vụ/Kết

Ngày bắt đầu Ngày kết thúc Đánh giá

Khảo sát hiện

trạng

Khảo sát và thu thập, đánhgiá những yêu cầu từ phía khách hàng

1/1/2024 15/1/2024 Hoàn thành đúng hạn

Các chiến lược phân tích

và quản lý yêu cầu phù hợp

và ảnh hưởng của từng

yêu cầu.

Stakeholder

request

Xác định tập yêu cầu của các bên liên quan

20/1/2024 25/1/2024 Đưa ra được tập yêu cầu

của bên liên quan

Xây dựng tài liệu tầm nhìn cho dự án

16/1/2024 31/1/2024 Tài liệu đưa ra một cái

nhìn tổng quan và chi tiết về phạm vi dự án và mục tiêu

Draft 1 Bao gồm thông

tin về khảo sát,thu thập yêu cầu, use case

1.5.2.1 Tiêu chuẩn đánh giá

● Tài liệu Vision của sản phẩm và các yêu cầu đã được xác định và ổn định

● Kiến trúc của hệ thống được đánh giá là ổn định và đáp ứng yêu cầu của dự án

● Phương pháp kiểm tra, đánh giá đã được phê chuẩn

● Kế hoạch cho giai đoạn xây dựng đã được lập và đủ chi tiết để hỗ trợ tiến triển côngviệc sang giai đoạn này

● Chi tiêu nguồn tài nguyên thực tế so với lịch biểu là chấp nhận được và nằm trong ranhgiới dự kiến

Dự án có thể bị hủy bỏ hoặc phải xem xét lại nếu không đạt được các tiêu chuẩn đánh giá tại mốc này

các yêu cầu bổ sung Thu thập thêm (nếu cần và update vào Vision

14/2/2024 20/2/2024 Được thực hiện đúng

kế hoạch và cung cấp thêm thông tin quan trọng cho tài liệu Vision

21/2/2024 25/2/2024 Đảm bảo website đáp

ứng yêu cầu người dùng

Draft 2 Thu thập các feat,

tài liệu yêu cầu bổ sung và kế hoạch cho các lần lặp tiếp theo

1/2/2024 25/2/2024 Thu thập được các

chức năng của website, kế hoạch chocác lần lặp tiếp theo

1.5.3. Xây dựng/Construction

- Trong giai đoạn này, sẽ thực thi xây dựng các thành phần của hệ thống, bao gồm cả mã nguồn,giao diện người dùng, và các thành phần cơ sở dữ liệu Chuẩn bị và thực hiện các kịch bản kiểmthử cho hệ thống Cập nhật tập yêu cầu về phát hành theo tiến triển của dự án

1.5.3.1 Tiêu chuẩn đánh giá

● Tiêu chuẩn đánh giá cho giai đoạn này bao gồm việc trả lời các câu hỏi sau:

● Sản phẩm đã đạt được mức độ ổn định và đủ trưởng thành để phát hành, triển khai đến cộngđồng người dùng không?

● Sự chuẩn bị và tích hợp của sản phẩm có đáp ứng được các yêu cầu đã đề ra không?

● Tất cả các bên liên quan có sẵn sàng cho việc chuyển dịch sản phẩm đến cộng đồng ngườidùng không?

● Chi phí thực tế và nguồn tài nguyên đã sử dụng so với kế hoạch đã được đề ra có ở mức chấpnhận được không?

● Mức độ chất lượng của sản phẩm đáp ứng các tiêu chí đã đặt ra hay không?

● Hiệu suất của hệ thống có đáp ứng được nhu cầu của người dùng không?

Giai đoạn này có thể phải làm lại nếu kết quả dự án chưa chạm đến mốc này

29/2/202 4

Thu thập được nhiều đánh giá bổ sung cho việc phát hành

Update Vision Cập nhật yêu cầu về

phát hành và ánh xạ đến các tầng yêu cầu liên quan

kế hoạch, cập nhật thêm yêu cầu sau khi phát hành version 1

Lập kế hoạch cho Kinh phí chi trả cho lần 4/3/2024 5/3/2024 Kinh phí đảm bảo

giai đoạn triển

khai

lặp vẫn nằm trong dự kiến Lập kế hoạch phân

bố cho lần lặp tiếp theo

đúng với dự kiến, sẵn sàng cho triển khai

Draft 3 Yêu cầu về phát hành

phần mềm, bản update vision, kế hoạch cho giaiđoạn triển khai

27/2/202 4

cầu về tập phát hành, kế hoạch cho triển khai version 1

1.5.4. Chuyển dịch/Transition

- Hoàn thiện các tính năng chưa đầy đủ và các phần mềm gắn kết Thực hiện kiểm thử toàn diện

để đảm bảo chất lượng và tính ổn định của hệ thống Tiến hành kiểm thử hệ thống để đảm bảotính tương thích và tính hoạt động hợp nhất Triển khai phần mềm trên cơ sở hạ tầng của trangweb để đảm bảo rằng nhân viên và người quản lý có thể sử dụng nó một cách hiệu quả

1.5.4.1 Tiêu chuẩn đánh giá

Đánh giá kết quả của giai đoạn này qua việc trả lời các câu hỏi sau:

● Người dùng có thỏa mãn với sản phẩm không?

● Hiệu suất của hệ thống dưới áp lực và tải công việc cao có ổn định không?

● Sản phẩm có tương thích trên các nền tảng khác nhau không?

● Chi phí nguồn tài nguyên thực tế so với lập kế hoạch là chấp nhận được?

Tại mốc này, sản phẩm đã được phát hành đến môi trường người dùng và chu kỳ bảo trì sau phát hành được khởi tạo

1.5.4.2 Kết quả

6/3/2024 10/3/202

4

Triển khai thànhcông

Tính toán chi phí

và kết thúc dự

án

Chi phí là nằm trong dự kiến Dự án mang lại lợi nhuận đáng kể Thời gian không vượt quá so với dự kiến

11/3/2024

15/3/2024

Chi phí vẫn nằmtrong mức dựkiến, thu được lợinhuận và thờigian hoàn thànhđúng hạn

1.6 Đào tạo và nguồn lực

Mô tả các công cụ phần mềm, nhân sự và đào tạo cần thiết để thực hiện các hoạt động Quản

❖ Đặc tả viên: Lê Bảo Lộc

❖ Chuyên viên phân tích nghiệp vụ: Đỗ Quốc Huy

❖ Đảm bảo chất lượng: Đặng Minh Ánh

● Đào tạo:

❖ Đào tạo về quản lý yêu cầu: Đảm bảo nhóm quản lý dự án hiểu rõ quy trình quản lý yêu cầu

và các công cụ quản lý yêu cầu liên quan.

❖ Đào tạo về công nghệ: Cung cấp đào tạo cho nhóm phát triển về các công nghệ cụ thể được

sử dụng trong dự án như ngôn ngữ lập trình, framework, và công nghệ cloud.

❖ Đào tạo về kiểm thử: Đảm bảo nhóm kiểm thử có kiến thức và kỹ năng cần thiết để thực hiện kiểm thử chất lượng cao.

CHƯƠNG 4: STAKEHOLDER REQUEST

1 Giới thiệu

Mục đích

● Mục đích của việc thu thập yêu cầu của các bên liên quan là để cung cấp cho đội ngũ phát triển phần mềm đầy đủ các mong muốn của các stakeholder đối với website bán mỹ phẩm trực tuyến

● Cung cấp tài liệu trực quan mô tả các yêu cầu thu thập được từ phía stakeholder từ đó làm cơ

sở cho phần xây dựng chức năng

● Xác định và hiểu rõ những gì các bên liên quan mong đợi từ dự án hoặc hệ thống

● Xác định rõ phạm vi của dự án và giới hạn những thay đổi sau này

● Đảm bảo rằng giải pháp được phát triển đáp ứng được mong đợi và yêu cầu của các bên liên quan, tối ưu hóa hiệu suất hệ thống

● Xác định ưu tiên của các yêu cầu, giúp tập trung vào những điểm quan trọng nhất đối với các bên liên quan

Phạm vi, thời gian và kinh phí

Phạm vi của thu thập yêu cầu

● Tài liệu này là cơ sở xác định các mong đợi của các bên liên quan đối với website bán mỹ phẩm

● Là cơ sở cho việc thu thập yêu cầu của các bên liên quan

● Là tài liệu đầu vào cho việc xác định yêu cầu phần mềm, lập kế hoạch quản lý yêu cầu

● Xác định đối tượng của quá trình thu thập yêu cầu

Kinh phí cho việc thu thập

Kinh phí cho việc thu thập yêu cầu : 10 Triệu.

thời gian cho việc thu thập yêu cầu : 20/12/2023 - 25/1/2024

1.3 Kĩ thuật thu thập yêu cầu

Dự án lựa chọn kỹ thuật phỏng vấn để thu thập yêu cầu của stakeholder Nhóm dự án sử dụng kĩ thuật này để có thể hiểu rõ hơn về nhu cầu và mong muốn của các bên liên quan, thu thập thông tin chi tiết, xác định rủi ro và thách thức, cũng như xây dựng mối quan hệ tích cực Cuộc phỏng vấn giúp tạo ra một môi trường giao tiếp sâu sắc, đồng thời đảm bảo sự tham gia và hiểu biếtcủa các bên liên quan

2 Thiết lập hồ sơ người dùng hoặc bên liên quan

● Chủ cửa hàng mỹ phẩm Ánh Ly , địa chỉ cửa hàng : 129 đường CMT8 ,phường Trưng Vương ,

tp Thái Nguyên

● Nhân viên bán hàng , nhân viên chăm sóc khách hàng của mỹ phẩm Ánh Ly

● Khách hàng truy cập vào trang web để mua hàng

3 Đánh giá vấn đề

Mô hình kinh doanh bán hàng trực tuyến đang trở thành trọng tâm quan trọng của thị trườnghiện đại Để thành công, các doanh nghiệp cần tập trung vào trải nghiệm mua sắm thuận lợi, chấtlượng sản phẩm, chiến lược tiếp thị linh hoạt, và quản lý an ninh thông tin và quyền riêng tư chặtchẽ

Lợi ích của mô hình này là người chủ sở hữu không cần trực tiếp tham gia vận hành cửahàng , mà chỉ cần có tiềm lực kinh tế và tầm nhìn chiến lược Điều này giúp tiết kiệm thời gian vàcông sức của chủ sở hữu

Tuy nhiên, việc quản lý một cửa hàng kinh doanh mà không có công cụ hỗ trợ sẽ gặp rấtnhiều trở ngại Đôi khi những khó khăn này đạt mức độ nghiêm trọng và ảnh hưởng đến hoạt độngkinh doanh

4 Hiểu môi trường người dùng

● Đa số người dùng có kiến thức cơ bản trong việc sử dụng máy vi tính và điện thoại thông minh

● Sản phẩm website bán mỹ phẩm trực tuyến được kỳ vọng sẽ cung cấp cho người dùng những

chức năng cơ bản đáp ứng được nhu cầu quản lý kinh doanh của cửa hàng.

● Đảm bảo rằng trang web được tối ưu hóa cho các thiết bị di động để phục vụ người dùng trênnhiều nền tảng

● Quy trình mua sắm trên trang web cần được tối ưu hóa để giảm thiểu sự phức tạp và tăngcường trải nghiệm người dung

● Hỗ trợ trực tuyến và chăm sóc khách hàng qua các kênh liên lạc

● Người dùng muốn giao diện trang web bắt mắt , phong phú

5.Tóm tắt để hiểu

5.1.Các vấn đề được bên liên quan mô tả:

● Khó khăn trong việc quảng bá sản phẩm.

● Thiếu Tính Nhanh Chóng và hiện đại.

● Khó khăn trong việc thực hiện chính sách quyền riêng tư cho khách hàng mà không có nền

tảng trực tuyến chính thức

● Giảm cơ hội tương tác và giao tiếp với khách hàng,

● Gặp khó khăn trong việc quản lý kho và theo dõi số lượng hàng tồn kho mà không có hệ

thống trực tuyến

● Chưa thống kê được chính xác doanh thu của cửa hàng do chưa có đủ các tài liệu cũng như

công cụ hỗ trợ để đối chiếu

● Khó khăn trong việc thu thập phản hồi từ khách hàng về sản phẩm và dịch vụ.

● Gặp khó khăn trong việc xây dựng thương hiệu và chiến lược tiếp thị

6 Đầu vào của nhà phân tích về vấn đề của bên liên quan

Các vấn đề kể trên thực sự ảnh hưởng đến hoạt động kinh doanh của quán

Nguyên do chủ yếu của các vấn đề trên là do chưa có giải pháp công nghệ thông tin hỗ trợ việcquản lý kinh doanh của quán

Để vượt qua những vấn đề này, việc phát triển một trang web quản lý bán hàng trực tuyến cóthể giúp cửa hàng tối ưu hóa hoạt động kinh doanh, tăng cường mối quan hệ với khách hàng, và đápứng đúng đắn với xu hướng thị trường hiện đại

7 Đánh giá cơ hội

● Chủ cửa hàng , bộ phận phục vụ khách, người quản lý nội dung sẽ quản lý website

● Thành công của cửa hàng với website bán hàng đo lường qua doanh số bán hàng, số lượng vàchuyển đổi khách hàng, tương tác tích cực, và xây dựng thương hiệu Dữ liệu phân tích vàbảo mật thông tin cũng quan trọng trong việc duy trì và phát triển

8.Đánh giá độ tin cậy và nhu cầu hỗ trợ

8.1.Kì vọng về độ tin cậy :

Giao Diện Người Dùng (UI): Giao diện người dùng thân thiện và dễ sử dụng là yếu tố quan trọng đối

với độ tin cậy Một trang web trực quan, thiết kế tốt sẽ thu hút khách hàng truy cập

Bảo Mật: Các biện pháp bảo mật mạnh mẽ giúp đảm bảo an toàn thông tin cá nhân và giao dịch tài

chính, làm tăng độ tin cậy của khách hàng

8.2 Kỳ vọng về hiệu suất:

● Website chịu được cường độ sử dụng cao

● Các phản hồi của website không được quá 1 phút cho một phản hồi

- Nhu cầu bảo trì:

● Website được thực hiện bảo trì 1 năm một lần để đảm bảo không có sai sót phát sinh trongquá trình vận hành

● Bất cứ khi nào có sự cố xảy ra, thì phải được sửa chữa kịp thời

● STRQ 1: hệ thống cho phép khách hàng quản lý tài khoản cá nhân

● STRQ 2: hệ thống cho phép khách hàng quản lý giỏ hàng và đơn hàng

● STRQ 3:hệ thống cho phép khách hàng quản lý sản phẩm trong danh sách mong muốn

● STRQ 4:hệ thống cho phép khách hàng tìm kiếm sản phẩm

● STRQ 5:hệ thống cho phép khách hàng lọc sản phẩm

● STRQ 6:hệ thống cho phép khách hàng đánh giá sản phẩm

- đối với người quản trị

● STRQ 7:hệ thống cho phép người quản trị quản lý sản phẩm

● STRQ 8:hệ thống cho phép người quản trị quản lý thống kê doanh thu và báo cáo kết quả

● STRQ 9:hệ thống cho phép người quản trị quản lý kho hàng

10 Phân tích các yêu cầu của Stakeholder

STRQ 1:hệ thống cho phép khách hàng quản lý tài khoản cá nhân

● FEAT 1: khách hàng có đăng nhập và đăng xuất tài khoản của mình

● FEAT 2: khách hàng có thẻ đăng ký tài khoản mới

● FEAT 3: khách hàng có thể quản lý thông tin cá nhân trong tài khoản của mình

STRQ 2: hệ thống cho phép khách hàng quản lý giỏ hàng và đơn hàng

● FEAT 4: khách hàng có thể thêm sản phẩm trong giỏ hàng

● FEAT 5: khách hàng có thể xóa sản phẩm trong giỏ hàng

● FEAT 6: khách hàng có thể hủy đơn hàng khi cần thiết

● FEAT 7: khách hàng có thể gửi đi đơn hàng của mình

● FEAT 8 : khách hàng có thể xem lịch sử đơn hàng của mình

STRQ 3:hệ thống cho phép khách hàng thêm,xóa sản phẩm trong danh sách mong muốn

● FEAT 9: khách hàng có thể thêm sản phẩm vào danh sách mong muốn

● FEAT 10: khách hàng có thể xóa sản phẩm trong danh sách mong muốn

● FEAT 13: khách hàng có thể viết đánh giá sản phẩm

STRQ 7: hệ thống cho phép người quản trị quản lý sản phẩm

● FEAT 14: phép người quản trị có thể thêm sản phẩm sản phẩm mới

● FEAT 15 : người quản trị có thể chỉnh sửa thông tin sản phẩm

● FEAT 16 : phép người quản trị có thể xóa sản phẩm

STRQ 8:hệ thống cho phép người quản trị quản lý thống kê doanh thu và báo cáo kết quả

● FEAT 17: người quản trị có thể xem thống kê doanh thu

● FEAT 18: người quản trị có thể xem kết quả báo cáo doanh thu

STRQ 9: Hệ thống cho phép người quản trị quản lý kho hàng

● FEAT 19: người quản trị có thể xem thống kê số lượng hàng tồn kho

11 Bảng truy vết

STRQ1 FEAT 1, FEAT 2, FEAT 3 Khách hàng,

STRQ2 FEAT 4, FEAT 5, FEAT 6,

16 STRQ8 FEAT 17 , FEAT 18 Người quản trị

Biên bản phỏng vấn

Biên Bản phỏng vấn : Website bán mỹ phẩm trực tuyến Ánh Ly

Ngày: [8/2/2024]

Thành phần tham gia:

1 [Tên chủ sở hữu] - Chủ sở hữu cửa hàng mỹ phẩm Ánh Ly

2 [Tên Business Analyst (BA)] Đỗ Quốc Huy

Nội Dung Đối Thoại:

BA: Chào chị.chị có thể cung cấp cho tôi tôi những nhu cầu cụ thể mà chị mong

muốn có trong website bán hàng của mình được không?

Chủ cửa hàng : Trước hết, tôi mong muốn hệ thống có tính năng cho phép khách hàng quản lý tài khoản cá nhân của họ Cụ thể là, khách hàng có thể đăng nhập, đăng ký tài khoản mới và quản lý thông tin cá nhân trong tài khoản.

BA: Tôi ghi nhận yêu cầu đó Việc quản lý tài khoản cá nhân là rất quan trọng để

khách hàng có thể dễ dàng truy cập và quản lý thông tin của mình Chúng ta sẽ xây

dựng tính năng đăng nhập, đăng ký tài khoản mới và quản lý thông tin cá nhân

cho website

Chủ cửa hàng: Tiếp theo, tôi cũng muốn hệ thống có tính năng cho phép khách hàng quản lý giỏ hàng và đơn hàng của họ Cụ thể là, khách hàng có thể thêm, xóa sản phẩm trong giỏ hàng, hủy đơn hàng khi cần và xem lịch sử đơn hàng của

mình

BA:Tôi hiểu, những tính năng về quản lý giỏ hàng và đơn hàng sẽ rất hữu ích cho

khách hàng Chúng tôi sẽ xây dựng các tính năng này

Chủ cửa hàng:Ngoài ra, tôi cũng muốn hệ thống có tính năng cho phép khách hàng

thêm và xóa sản phẩm trong danh sách sản phẩm ưa thích Điều này sẽ giúp tôi

nắm bắt được sản phẩm nào được khách hàng quan tâm nhiều

BA:Tôi ghi nhận yêu cầu này Tính năng quản lý danh sách sản phẩm ưa thích sẽ

giúp chị theo dõi được sản phẩm được khách hàng quan tâm nhiều Chúng ta sẽ

bổ sung tính năng thêm và xóa sản phẩm trong danh sách này

Chủ cửa hàng Ánh Ly: Tiếp theo, tôi muốn hệ thống có tính năng tìm kiếm sản phẩm theo từ khóa Điều này sẽ giúp khách hàng dễ dàng tìm kiếm và truy cập sản

phẩm họ cần

BA: Tôi ghi nhận yêu cầu về tính năng tìm kiếm sản phẩm theo từ khóa Đây là

một tính năng rất cần thiết để khách hàng có thể dễ dàng tìm kiếm và truy cập sản