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

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

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

<b>BÁO CÁO BÀI TẬP LỚN</b>

<b>MƠN PHÂN TÍCH VÀ QUẢN LÝ U CẦU PHẦN MỀM</b>

<b>ĐỀ 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</b>

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

<b>Sinh viên thực hiện:Tạ Quang HoàĐặng Minh ÁnhNgô Thị Khánh LyLê Bảo Lộc</b>

<b>Đỗ Quốc Huy</b>

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

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

<b>Bảng phân cơng cơng việc nhóm</b>

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

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

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

<small>1.2. Phạm vi, thời gian và kinh phí...</small>

<small>1.2.1. Phạm vi của thu thập yêu cầu...</small>

<small>1.2.2. Kinh phí cho việc thu thập...</small>

<small>1.3. Kĩ thuật thu thập yêu cầu...</small>

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

3. Đánh giá vấn đề...

<b><small>4. Hiểu mơi trường người dùng...</small></b>

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

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

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

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

7. Đánh giá cơ hội...

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

<small>8.1.Kì vọng về độ tin cậy :...</small>

<small>8.2. Kỳ vọng về hiệu suất:...</small>

<small>8.3. Những yêu cầu hỗ trợ :...</small>

<b><small>9.Tóm tắt của nhà phân tích...</small></b>

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

<b><small>10. Phân tích các yêu cầu của Stakeholder...</small></b>

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

<small>6.1. Biểu đồ use case...</small>

<small>6.1.1. Use case tổng quát...</small>

<small>6.1.2. Use case phân rã đăng nhập...</small>

<small>6.1.3. Use case phân rã Tìm kiếm sản phẩm...</small>

<small>6.1.4. Use case phân rã Xem sản phẩm...</small>

<small>6.1.5. Use case phân rã Quản lý giỏ hàng...</small>

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

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

<small>6.1.7. Use case phân rã Quản lý danh sách mong muốn...</small>

<small>6.1.8. Use case phân rã Quản lý tài khoản cá nhân...</small>

<small>6.1.9. Use case phân rã Quản lý sản phẩm...</small>

<small>6.1.10. Use case phân rã Quản lý đơn hàng...</small>

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

<small>6.1.12. Use case phân rã Quản lý kho hàng...</small>

<small>6.1.13. Use case phân rã Quản lý tài khoản nhân viên...</small>

<small>6.1.14. Use case phân rã Quản lý Danh mục...</small>

<small>6.2. Biểu đồ lớp...</small>

<small>6.3. Đặc tả chi tiết các use case...</small>

<small>6.3.1. Chức năng đăng nhập...</small>

<small>6.3.2. Chức năng đăng ký...</small>

<small>6.3.3. Chức năng Xem chi tiết sản phẩm...</small>

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

<small>6.3.5. Chức năng Thanh toán...</small>

<small>6.3.7. Chức năng Huỷ đơn hàng...</small>

<small>6.3.8. Chức năng Liên hệ...</small>

<small>6.3.9. Chức năng Xem lịch sử đơn hàng...</small>

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

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

<small>6.3.12. Chức năng Xem mỹ phẩm đề xuất...</small>

<small>6.3.13. Chức năng Thêm sản phẩm vào danh mục...</small>

<small>6.3.14. Chức năng Tìm kiếm sản phẩm theo giá...</small>

<small>6.3.15. Chức năng Tìm kiếm theo danh mục...</small>

<small>6.3.16. Chức năng Tìm kiếm theo từ khố...</small>

<small>6.3.17. Chức năng Chăm sóc khách hàng...</small>

<small>6.3.18. Chức năng Quản lý sản phẩm...</small>

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

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

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

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

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

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

<b>1.1. Giới thiệu</b>

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.

<b>1.4. Phát biểu bài toán</b>

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 qn gặp nhiều vấn đề như: thời gianchờ đợi lâu, ghi chép hố đơ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ý.

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

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

<b>1.5. Vấn đề</b>

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

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

<b>1.6. Đề xuất giải pháp</b>

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

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

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

<b>1.7. Mơ hình quy trình phần mềm</b>

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à hồ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

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

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.

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

<b>1.8. Tổng quan về kim tự tháp yêu cầu</b>

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

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

<i><b>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</b></i>

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

<i><b>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</b></i>

<i><b>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.</b></i>

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

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

<b>1.1. Giới thiệu</b>

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.

<b>1.1.1.</b> <i><b>Mục đích</b></i>

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

<b>1.1.2.</b> <i><b>Phạm vi</b></i>

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.

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

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.

<b>1.1.4.</b> <i><b>Tài liệu tham khảo</b></i>

<i>- Kruchten, Philippe. 1999. The Rational Unified Process. Menlo Park, CA: Addison </i>

<i>- Leffingwell, D. and Don Widrig. 2000. Managing Software Requirements. Menlo Park, </i>

CA: Addison Wesley.

<i>- Spence, I. and L. Probasco. 1998. Traceability Strategies for Managing Requirements </i>

<i>with Use Cases. Cupertino, CA: Rational Software Corporation.</i>

<b>1.1.5.</b> <i><b>Tổng quan</b></i>

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:

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

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 sốt và bảo trì 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.

<b>1.2. Quản lý yêu cầu</b>

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

<i>Khách hàng</i>

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.

<i>Người dùng</i>

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.

<i>Các bên liên quan</i>

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.

<i>Quản lý dự án</i>

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 hồn thành đúng lịch trình và ngân sách.

<i>Đảm bảo chất lượng (QA)</i>

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.

<i>Lập trình viên</i>

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.

<i>Lãnh đạo nhóm</i>

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

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.

<b>Khách hàng</b> Nguyễn Ánh Ly Đại diện shop mỹ phẩm

Shop mỹ phẩm

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

Quản lý bán hàng

Shop mỹ phẩm

<b>Bên liên quan</b> Nguyễn Trần Hồng

Kế tốn shop mỹ phẩm

Shop mỹ phẩm

<b>Quản lý dự án</b>

Tạ Quang Hoà

Người quản lý dự án phần mềm

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

<b>Lãnh đạo nhóm</b>

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

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

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

<b>Lập trình viên</b> Ngơ Thị Khánh Ly Lập trình viên Nhóm pháttriển dự án

<b>Chun viên phân tích nghiệp vụ </b>

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

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

<b>Đặc tả viên</b> Lê Bảo Lộc _{Đặc tả phần} _{Nhóm phát} _{dtc21h4801030057@}

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

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

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

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

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

<b>1.3. Các thông tin yêu cầu1.3.1.</b> <i><b>Mô tả thông tin</b></i>

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

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)

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

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)

<i>Các kiểu yêu cầu</i>

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

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

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

<i>Các thuộc tính</i>

<b>Thuộc tínhMơ tảKiểu^{Danh sách các giá}</b>

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

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

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)

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

Độ ổ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

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

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

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

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

<b>1.3.2.</b> <i><b>Dấu vết</b></i>

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

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

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

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

<b>1.3.3.</b> <i><b>Các báo cáo, thông số đo đạc</b></i>

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

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

được lưu và các truy vấn với các tiêu chí lọc như sau:- <b>Attribute Value/Giá trị thuộc tính: </b>

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.- <b>Attribute Value Range/Vùng giá trị thuộc tính: </b>

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

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

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

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

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.

<b>1.4. Quản lý thay đổi các yêu cầu</b>

<b>1.4.1.</b> <i><b>Xử lý và phê chuẩn yêu cầu thay đổi</b></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 hồn thành.

<b>1.4.2.</b> <i><b>Ban điều khiển thay đổi (CCB)</b></i>

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.

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

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

<b>1.4.3.</b> <i><b>Các kết quả bàn giao</b></i>

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

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

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

<b>1.4.4.</b> <i><b>Luồng công việc và các hoạt động</b></i>

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

<b>cầu tươngứng</b>

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

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

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)

<b>1.5. Các mốc thời gian</b>

<b>1.5.1.</b> <i><b>Khởi tạo/ Inception</b></i>

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

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

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

<i>1.5.1.1. Tiêu chuẩn đánh giá</i>

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 u cầu từ phía khách hàng

20/12/2023 26/12/2023 Hồ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 ucầu dự án.

1/1/2024 15/1/2024 Hồ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

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

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 Hồn thành đúng hạn, có thơng tin bước đầu về xây dựng phần mềm

<i>1.5.2.1. Tiêu chuẩn đánh giá</i>

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

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

<i>1.5.2.2. Kết quả</i>

<b>Nhiệmvụ/Kết quả</b>

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

<b>Đánh giá</b>

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 Hồ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

<b>1.5.3.</b> <i><b>Xây dựng/Construction</b></i>

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

<i>1.5.3.1. Tiêu chuẩn đánh giá</i>

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

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

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

<i>1.5.3.2. Kết quả</i>

<b>Nhiệm vụ/Kếtquả</b>

<b>Ngày kếtthúc</b>

<b>Đánh giá</b>

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

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

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

<b>1.5.4.</b> <i><b>Chuyển dịch/Transition</b></i>

- Hồ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ả.

<i>1.5.4.1. Tiêu chuẩn đánh giá</i>

Đá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 ngun 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.

<i> 1.5.4.2. Kết quả</i>

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

<b>Nhiệm vụ/Kếtquả</b>

<b>Ngày kếtthúc</b>

<b>Đánh giá</b>

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

<b>1.6. Đào tạo và nguồn lực</b>

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:

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

❖ Đà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.

<b>CHƯƠNG 4: STAKEHOLDER REQUEST1. Giới thiệu</b>

<i><b> Mục đích</b></i>

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

<i><b>Phạm vi, thời gian và kinh phí Phạm vi của thu thập yêu cầu </b></i>

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

<i><b> Kinh phí cho việc thu thập</b></i>

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

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

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

<b>1.3. Kĩ thuật thu thập yêu cầu </b>

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.

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

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

<b>3. Đánh giá vấn đề</b>

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.

<b>4. Hiểu môi trường người dùng</b>

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

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

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

<b>5.Tóm tắt để hiểu</b>

<i><b>5.1.Các vấn đề được bên liên quan mơ tả:</b></i>

<i><b>● Khó khăn trong việc quảng bá sản phẩm.● Thiếu Tính Nhanh Chóng và hiện đại.</b></i>

<b>● 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</b>

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

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

<b>● 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ệ</b>

thống trực tuyến.

<b>● 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ư</b>

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

<b>● 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ị .</b>

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

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.

<b>7. Đánh giá cơ hội</b>

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

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

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

<i><b>8.1.Kì vọng về độ tin cậy : </b></i>

<i><b>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</b></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.

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

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

<i><b>8.2. Kỳ vọng về hiệu suất:</b></i>

● 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

<b>-Nhu cầu bảo trì:</b>

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

- <b>đối với người quản trị </b>

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

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

<b>● 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 </b>

<i><b>10. Phân tích các yêu cầu của Stakeholder</b></i>

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

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

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

● <b>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 </b>

<b>●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 </b>

<b>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 </b>

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

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

<b>STRQ 4: </b>

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

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

● <b>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 </b>

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

<b>● 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</b>

<b>● 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</b>

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

<b>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 </b>

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

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

<i><b>11. Bảng truy vết </b></i>

STRQ1 FEAT 1, FEAT 2, FEAT 3 Khách hàng, STRQ2 FEAT 4, FEAT 5, FEAT 6,

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

16

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

<b>Nội Dung Đối Thoại:</b>

<b>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 </b>

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

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

<b>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 để </b>

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

<b>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 </b>

cho website.

<b>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 </b>

<b>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 </b>

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:Ngồi ra, tơi cũng muốn hệ thống có tính năng cho phép khách hàng

<b>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 </b>

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

<b>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ẽ </b>

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.

<b>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</b>

phẩm họ cần.

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

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

</div>