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ÔNGKHOA 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ẨMONLINE

Giảng viên hướng dẫn: ThS Phạm Thị ThươngNhóm: 4 - KTPM K20B

Sinh viên thực hiện:Tạ Quang HoàĐặng Minh ÁnhNgô Thị Khánh LyLê 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

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

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.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

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.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.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àngmỹ 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ảnlý 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ân tích khả năng và xác định phạm vi dự án.

❖ Lập kế hoạch ban đầu và xác định các rủi ro ban đầu.● Phát triển (Elaboration):

❖ Xác định và phân tích chi tiết các yêu cầu của hệ thống.❖ Thiết kế kiến trúc hệ thống và xác định các thành phần chính.❖ 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.

❖ 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

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

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 Giới thiệu

Tài liệu này cung cấp hướng dẫn sử dụng trong dự án để xây dựng các tài liệu yêu cầu tiêuchuẩn, định nghĩa các loại yêu cầu, xác định thuộc tính, và thiết lập các dấu vết giữa các yêu cầu Nóđề xuất một chiến lược tổng thể quản lý yêu cầu và là nguồn tài nguyên hữu ích cho tất cả các bêntham gia vào dự án này.

1.1.1. Mục đích

Mục tiêu của bản kế hoạch này là xây dựng và tài liệu hóa một cách tiếp cận có hệ thống đểthu thập, tổ chức, và mô tả các yêu cầu của hệ thống Bản kế hoạch cũng thiết lập và duy trì các thỏathuận giữa khách hàng và đội phát triển về các yêu cầu thay đổi của hệ thống

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ủadự án.

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

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

- 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õivà 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 đượcsử 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

naly@cosmeticshop.com

Người dùng Nhân viên cửa hàng

Quản lý bán hàng

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

Lãnh đạo nhóm

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

Đặng Minh Ánh Kiểm tra chất lượng phần mềm

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áttriển dự án

dtc2154108030088@ictu.edu.vn

Chuyên viên phân tích nghiệp vụ

Đỗ Quốc Huy Quản lý, phân tích yêu cầu

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

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

thuộc tính yêu cầu

support@asan.com www.asana.com

Google Docs Tạo và làm việc với các tài liệu

through our internal technical support team

docs.google.com

Google Drive Lưu trữ, update các tài liệu

through our internal technical support team

drive.google.com

1.3 Các thông tin yêu cầu1.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)

ngữ chung dự án.Supplementary

Requirements Specification (SUP)

Tài liệu này mô tả các yêu cầu phi chức năng của hệ thống.

Supplementary Requirement (SUPL)

Requirements Management Plan (RMP)

Tài liệu này mô tả các yêu cầu và các chiến lược cụ thểđể 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.Supplementary

Requirement (SUPL)

Yêu cầu phi chức năng của hệ thống.

Độ ưu tiên (Priority), Status (Trạng thái), Difficulty (Độ khó), Stability (Tính ổn định), Risk (Rủi ro), Defect (Khuyết điểm), Cost (Chi phí), Test (Kiểm thử)

Các thuộc tính

Thuộc tínhMô tảKiểuDanh 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

Must (phải đáp ứng)

FEAT, UC, SUPLShould (nên đáp

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

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

list Functional (Chức năng)

FEAT

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.

Proposed (được đề xuất)

FEAT, UC,SUPLApproved (đã

được phê chuẩn)Incorporated (đã được tích hợp)Validated (đã được thẩm định)

Độ khó

High (cao)

FEAT, UC,SUPLMedium (trung

bình)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

High (cao)

FEAT, UC,SUPLMedium (trung

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

lập kế hoạch (Planned Iteration)

Lần lặp thực tế (Actual

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

Contact Name

Chi phí (Cost) real

FEAT, UC, SUPL, STRQ

Khuyết điểm

Stakeholder Priority

(Ưu tiên của cácbên liên quan)

High (cao)

STRQMedium (trung

bình)Low (thấp)

Proposed/Được đề xuất

Đượ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

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 tranhLarge Customers/Khách hàng

Độ 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ạ đến1 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

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

Mọi thuật ngữ Glossary phảicó ý 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ệudự án.

Supplementary Requirement (SUPL)

Yêu cầu phi chức năng, ví dụ: 1 luật nghiệp vụ.Yêu cầu bổ sung: Ghi nhớ mật khẩ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

(Số lần lặp)all

Glossary Terms Hiển thị tất cảcác yêu cầu có kiểu

Liệt kê tất cả các yêu cầu thuộc kiểu Supplementary

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).

Đề 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

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

3Draft 3Tập yêu cầu về phát hành, Update Vision, Lập kế hoạch cho giai đoạn triển khai

đầy đủ chức năng

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ùngcó 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"

Submitter Proposed

Review CR/Xét duyệt yêu cầu thay đổi

Nội dung của Change Request (CR) được xem xét trong cuộc họp của Change Control Board (CCB) để quyết định tính hợp lệ của CR Nếu được chấp nhận, CR sẽ được phê chuẩn cho việc triển khai ngay lập tức, dựa trên các yếu tố như độ ưu tiên, lịch biểu, nguồn tài nguyên, và độ rủi ro Quyết định này được đưa ra bởi nhóm quản lý dự án

Confirm Duplicate or Reject/Xác nhậnlặp hoặc từ chối

Nếu RC được xác định là trùng lặphoặc bị từ chối do không hợp lệ,CCB sẽ thông báo và yêu cầu thôngtin bổ sung từ người gửi để làm rõquyết định xác nhận (nếu cần)

CCB Delegate Proposed

Update CR/Cập nhật yêu cầu thay đổi

Nếu cần thông tin bổ sung để đánh giá CR hoặc nếu CR bị từ chối (ví dụ:xác nhận là không hợp lệ, ), ngườigửi yêu cầu sẽ được thông báo và 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

Submitter Proposed

Assign &

Schedule Work/Gán & lập lịch công việc

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

Make

Changes/Tạo các thay đổi

Thành viên dự án chịu trách nhiệmthực hiện công việc được giao (vídụ: requirements, analysis &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

Verify Changes in Test Build - Thẩm định các thay đổi trong tiến trình build và test

Sau khi CR được đánh dấu làResolved, các thay đổi được đưavào hàng đợi chờ kiểm thử và đượcgiao cho người kiểm thử thực hiện.Sau đó, chúng được thẩm địnhtrong test build của sản phẩm

Tester Incorporated

Verify Changes in Release Build/Thẩm định thay đổi trong build phát hành

Sau khi các thay đổi được giải quyếtvà 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)

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ề

● 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.

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

20/12/2023 26/12/2023 Hoàn thành đúng tiến độ và đầy đủ thông tin về yêu cầu khách hàng

RequirementsManagement Plan

Tài liệu mô tả chiến lược phân tích và quản lý các yêucầu dự án.

1/1/2024 15/1/2024 Hoàn thành đúng hạnCác chiến lược phân tíchvà quản lý yêu cầu phù hợp

Priority Xác định độ ưutiên & gán yêu cầu/lần lặp.

16/1/2024 20/1/2024 Độ ưu tiên được gán một cách hợp lý dựa trên mức độ quan trọng và ảnh hưởng của từng

yêu cầu.Stakeholder

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ầucủa bên liên quan

Vision

Document/Tàiliệu tổng quan(tầm nhìn)

Phân tích xác định các FEAT 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ôngtin về khảo sát,thu thập yêu cầu, use case

20/12/2023 31/1/2024 Hoàn thành đúng hạn, có thông tin bước đầu về xây dựng phần mềm

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.

1.5.2.2 Kết quả

Nhiệmvụ/Kết quả

Mô tảNgày bắt đầuNgày kếtthúc

Đánh giá

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

1/2/2024 6/2/2024 Giúp rõ ràng hóa và ổn định hơn về phạm vi của dự án.

Use Case Mô tả các UC của dự án

7/2/2024 13/2/2024 Hoàn thành đầy đủ và chính xác, phản ánh đúng nhu cầu và mong muốn của khách hàngTài liệu SUPL Phân tích, xác định

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

Lập kế hoạch cho các lần lặp tiếp theo

Tiếp nhận yêu cầu của khách hàng, lậpkế hoạch cho các lần lặp tiếp theo

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.

1.5.3.2 Kết quả

Nhiệm vụ/Kếtquả

Ngày kếtthúc

Đánh giá

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

Thu thập ý kiến của khách hàng các yêu cầu về phát hành sản phẩm

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/20245/3/2024Kinh 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ânbố cho lần lặp tiếp theo

đúng với dự kiến,sẵn sàng chotriể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

cầu về tập pháthành, kế hoạchcho triển khaiversion 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ả

Nhiệm vụ/Kếtquả

Ngày kếtthúc

Đánh giá

Triển khai sản phẩm đến người dùng cuối - Version 1.0

Triển khai sản phẩm đến người dùng và thu thập ý kiến từ họ Phân tích kết quả phản hồi.

6/3/2024 10/3/2024

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

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ảnlý Yêu cầu gồm:

❖ Đặ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 REQUEST1 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.

- đố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 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

● FEAT 12: khách hàng có thể chọn lọc sản phẩm theo danh mục, giá cả , thương hiệuSTRQ 6: hệ thống cho phép khách hàng đánh giá sản phẩm

● 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ị

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

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