Documenting And Managing Requirements (Tài Liệu Hóa Và Quản Lý Các Yêu Cầu.pdf

Nó sẽ bao gồm 3 phần chính: o Những loại User trong hệ thống Actors o Những feature có trong hệ thống Use cases o Mối quan hệ giữa Actors và Use cases Những mô hình này cung cấp một bộ

B Ộ GIÁO DỤC & ĐÀO TẠO UEH UNIVERSITY

TRƯỜNG CÔNG NGHỆ VÀ THIẾT KẾ UEH

- -

BÁO CÁO THUY ẾT TRÌNH MÔN H ỌC: PHÂN TÍCH NGHIỆP VỤ KINH DOANH

Đề tài: DOCUMENTING AND MANAGING REQUIREMENTS

(TÀI LIỆU HÓA VÀ QUẢN LÝ CÁC YÊU CẦU)

Mã l ớp học phần: 22D1INF50900904

Gi ảng viên giảng dạy: HỒ THỊ THANH TUYẾN

TP H ồ Chí Minh, ngày 4 tháng 3 năm 2022

M ỤC LỤC

L ỜI CẢM ƠN 3

CÁC THÀNH VIÊN VÀ B ẢNG PHÂN CÔNG CÔNG VIỆC 4

INTRODUCE (GIỚI THIỆU) 5

I THE IMPORTANCE OF DOCUMENTATION (TẦM QUAN TRỌNG CỦA TÀI LIỆU) 5

II THE REQUIREMENTS DOCUMENT (TÀI LIỆU YÊU CẦU) 5

1 Structure (Kết cấu) 5

2 Content of the Requirements Document (Nội dung của Tài liệu Yêu cầu) 5 III THE REQUIREMENTS CATALOGUE (DANH MỤC CÁC YÊU CẦU) 7 1 Type of requirements (Phân lo ại các yêu cầu) 7

a) General requirements (Yêu c ầu chung) 7

b) Technical requirements (Yêu c ầu kỹ thuật) 8

c) Functional requirements (Yêu c ầu chức năng) 8

d) Non-functional requirements (Yêu c ầu phi chức năng) 9

2 Hierarchy of requirements (Th ứ bậc các yêu cầu) 10

3 Documenting a requirement (Ghi l ại một yêu cầu) 10

IV MANAGING REQUIREMENTS (QU ẢN LÝ CÁC YÊU CẦU) 13

1 Qu ản lý yêu cầu là gì? 13

2 Các yêu c ầu được quản lý như thế nào? 14

3 Các yếu tố liên quan đến quản lý yêu cầu 14

CONCLUSION (KẾT LUẬN) 16

DEMO: QUẢN LÝ KHÁCH SẠN 16

TÀI LI ỆU THAM KHẢO 25

L ỜI CẢM ƠN

Trước hết, nhóm chúng em xin gửi lời cảm ơn chân thành và sâu sắc đến Cô Hồ Thị

Thanh Tuyến, trong quá trình học tập và tìm hiểu bộ môn Phân tích nghiệp vụ kinh

doanh, nhóm em đã nhận được sự hướng dẫn và chỉ dạy tận tình của Cô

Với tình cảm chân thành, nhóm em xin cảm ơn Cô, cảm ơn sự giảng dạy nhiệt tình về kiến thức chuyên môn cũng như khả năng làm việc nhóm và tinh thần học tập chủ động

để chúng em có thêm nhiều kiến thức để thực hiện bài thuyết trình một cách tốt nhất và tích lũy được kinh nghiệm cho sau này

Trong quá trình tìm hiểu và thực hiện đề tài mặc dù em đã có gắng hết sức song còn

những hạn chế về kiến thức cũng như kinh nghiệm thực tế và trình độ lý luận nên bài thuyết trình chắc chắn không tránh khỏi những thiếu sót, chúng em kính mong Cô bỏ qua Nhóm em rất mong nhận được ý kiến nhận xét từ Cô để chúng em có thể hoàn thiện Một lần nữa, chúng em xin bày tỏ sự biết ơn đến Cô Chúng em kính chúc Cô nhiều sức khỏe, thành công và hạnh phúc

Sinh viên c ủa Cô

CÁC THÀNH VIÊN VÀ B ẢNG PHÂN CÔNG CÔNG VIỆC

B ảng phân công công việc

Task Công việc cần làm Nhân sự Nội dung Deadline cá nhân

1 Soạn nội dung thuyết trình

Soạn câu hỏi và câu đáp án

Lan, Lam THE REQUIREMENTS DOCUMENT

19/2/2022

Ngân, Vân THE REQUIREMENTS

CATALOGUE Tâm, Diễm MANAGING REQUIREMENTS Lan, Lam Giới thiệu chung, tầm quan trọng

tài liệu Tâm, Diễm Conclusion

2 Ideal game, trò chơi tương

tác ALL Mỗi người tìm 2 câu hỏi cho trò

chơi 19/2/2022

3 Chọn mẫu powerpoint Diễm, Tâm Đẹp, nổi, chất lượng 26/02/2022

4 Chọn mẫu slide All Thống nhất được mẫu slide thuyết

trình 22/02/2022

5 Tóm tắt nội dung cho pp và

hình ảnh chèn Lan, Tâm, Diễm Nội dung ngắn gọn, hình ảnh phù hợp 23/02/2022

6 Phỏng vấn hoặc khảo sát ý

kiến bên có liên quan Lam, Ngân, Vân doanh nghiệp, tổ chức hoặc cá

nhân 22/02/2022

7 Tổng duyệt nội dung thuyết

trình ALL Chốt lại tổng thể bài thuyết trình

nhóm 26/02/2022

8 Tìm video liên quan ALL Nội dung phù hợp chủ đề thuyết

trình 25/02/2022

INTRODUCE (GIỚI THIỆU)

Chương này liên quan đến hai trong số các yếu tố chính của kỹ thuật yêu cầu:

• Ghi lại các yêu cầu đã được thu thập và quản lý

• Yêu cầu lập hồ sơ rõ ràng – đây là chìa khóa thành công của dự án Dự án thất bại

là do thiếu yêu cầu định nghĩa tốt và ngược lại

CỦA TÀI LIỆU)

Có nhiều lý do để cần tài liệu tốt:

• Giao tiếp, thảo luận tốt phải dựa trên cơ sở nền – là nguồn tài liệu tốt, nguồn tài liệu tốt sẽ cung cấp cơ sở chắc chắn để đảm bảo tất cả các yêu cầu liên quan nhất quán với nhau

• Nguồn tài liệu cung cấp cho các nhà quản lý và nhân viên kinh doanh, những người

là nguồn và chủ sở hữu của các yêu cầu với cơ sở chắc chắn để xác nhận rằng tài liệu ghi lại chính xác những gì họ cần

• Có thể làm việc ở khoảng cách xa (cách nửa vòng trái đất vẫn có thể truyền tài liệu đến nơi thông qua các công cụ CNTT điển hình là gmail) để phát triển và thử nghiệm các giải pháp kinh doanh

• Tài liệu yêu cầu sẽ xác định những gì phải làm, và các tiêu chí chấp nhận cần thiết

để kiểm tra các giải pháp sẽ được xác định

• Ngoài ra, tài liệu yêu cầu cũng được sử dụng sau khi triển khai của giải pháp kinh doanh, ví dụ như trong việc bảo trì hệ thống CNTT và trong quá trình thực hiện lợi ích

II THE REQUIREMENTS DOCUMENT (TÀI LIỆU YÊU CẦU)

• Để xem xét tài liệu đảm bảo cấu trúc tốt thì tài liệu yêu cầu cần cung cấp tất cả thông tin mà người đánh giá yêu cầu một cách dễ hiểu và ở dưới dạng dễ tiếp thu

• Một tài liệu có cấu trúc tốt sẽ cải thiện khả năng truyền đạt của thông tin trong đó

• Tài liệu yêu cầu có thể được phân vùng bởi khu vực kinh doanh hoặc cho các nhóm bên liên quan cụ thể

➢ Tóm lại, một tài liệu yêu cầu có tổ chức sẽ làm cho việc xem xét dễ dàng hơn và giúp đảm bảo rằng các yêu cầu đã thỏa thuận là chính xác

2 Content of the Requirements Document (Nội dung của Tài liệu Yêu cầu)

Tài liệu yêu cầu phải chứa các phần sau:

• Giới thiệu và nền tảng: phần này nên mô tả về tình hình kinh doanh và nguồn lực cho dự án Nó phục vụ để làm rõ các mục tiêu và phạm vi của công việc và đảm bảo rằng tất cả các bên liên quan đều nhận thức được bối cảnh kinh doanh cho các yêu cầu

• Các mô hình quy trình kinh doanh: Đây là nơi mà các mô hình quy trình sẽ trở thành nơi đặt và đưa ra tầm nhìn cho các quy trình mới Nếu được yêu cầu thay đổi, các quy trình ban đầu sẽ được sửa đổi phù hợp với đề xuất thay đổi

• Mô hình chức năng: Gồm sơ đồ hiển thị chức năng của đề xuất giải pháp phần

mềm Các dạng sơ đồ thường dùng là Context Diagram (sơ đồ ngữ cảnh) (mô tả bối cảnh của hệ thống, bao gồm các thực thể bên ngoài tương tác với hệ thống Các thực thể bên ngoài này có thể là các hệ thống khác, các service, hoặc các đơn

vị kinh doanh (yếu tố con người), hoặc các database, … Mô hình này cũng giúp xác định các dòng dữ liệu giữa các thực thể bên ngoài và hệ thống chính, và mô tả hướng đi của mỗi dòng dữ liệu Giới hạn của mô hình này là chỉ mô tả thực thể bên ngoài tương tác trực tiếp với hệ thống dưới dạng khám phá.) Use case

diagram ( là một sơ đồ để thể hiện cách những user trong system có thể tương tác với system bằng những feature gì Nó sẽ bao gồm 3 phần chính:

o Những loại User trong hệ thống ( Actors)

o Những feature có trong hệ thống (Use cases)

o Mối quan hệ giữa Actors và Use cases

Những mô hình này cung cấp một bộ mặt đẹp đẽ về chức năng của giải pháp được yêu cầu (bởi vì họ cung cấp một cái nhìn tổng quan đầy đủ về nó và họ cung cấp một phương tiện để cấu trúc danh mục yêu cầu)

• Mô hình dữ liệu: Một mô hình dữ liệu có liên quan khi tài liệu yêu cầu được xác định ở mức độ chi tiết để nó có thể được sử dụng để xây dựng một phần mềm giải pháp hoặc đánh giá một gói hàng không có sẵn Đồng thời, một mô hình dữ liệu cung cấp một cái nhìn vượt trội hơn nhiều về dữ liệu và cho phép nhà phân tích xem xét chính xác các quy tắc kinh doanh và các yêu cầu cần đáp ứng của giải pháp Hai

mô hình dữ liệu các kỹ thuật là mô hình hóa mối quan hệ thực thể và mô hình hóa lớp

• Danh mục các yêu cầu: Yêu cầu phải được ghi lại trong danh mục yêu cầu Cung cấp thông tin về từng yêu cầu riêng lẻ Các danh mục là thành phần quan trọng cho quá trình đánh giá các yêu cầu bởi vì nó là kho lưu trữ trung tâm của thông tin liên quan đến việc xác định, tham chiếu và nguồn của các yêu cầu

• Bảng chú giải thuật ngữ: Một trong những đặc điểm chất lượng chính của tài liệu yêu cầu là đảm bảo rằng nó cung cấp định nghĩa rõ ràng về các yêu cầu để nó có thể được đọc, hiểu dễ dàng Mỗi ngành, mỗi phòng ban đều có những thuật ngữ chuyên ngành riêng mà không phải ai cũng thể hiểu Vì vậy, bảng chú giải thuật ngữ khắc phục được vấn đề này và cung cấp nguồn của các định nghĩa thuật ngữ Bảng thuật

ngữ có thể được tạo chỉ cho một dự án cụ thể hoặc có thể có một bảng thuật ngữ

toàn tổ chức có thể được sử dụng, có thể ở dạng rút gọn

1 Type of requirements (Phân loại các yêu cầu)

Trong mọi lĩnh vực đều sẽ có những yêu cầu riêng khác nhau Các BA sẽ xem các danh

mục yêu cầu ấy như một bản ghi nhớ phụ để đảm bảo không bỏ sót yêu cầu của nhà kinh

doanh đưa ra Thực tế chúng ta có thể chia các loại yêu cầu:

• Yêu cầu chung

• Yêu cầu kỹ thuật

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

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

a) General requirements (Yêu cầu chung)

Thông thường, nó xác định chính sách kinh doanh, tiêu chuẩn và nhu cầu KD, có phạm vi

rộng Nhiều yêu cầu chung áp dụng cho toàn bộ thay đổi chương trình kinh doanh Có

các loại phụ cụ thể theo yêu cầu chung như:

+ Business constraints – Ràng buộc về kinh doanh: bao gồm các khía cạnh như ngân

sách, thời gian biểu và tài nguyên (VD: dự án có thời gian constraint là 3 tháng, mà bạn

cứ giả sử Assumption - giả định dự án làm 6 tháng => dự án của bạn sẽ không làm được

kỹ)

+ Business policies – Các chính sách kinh doanh : Nó đặt ra những quy tắc, luật lệ

của tổ chức công ty nhằm truyền đạt trách nhiệm cá nhân và nhóm; điều này cho phép

mọi người cùng nhau hướng tới mục tiêu của công ty (VD: Chính sách đánh giá hiệu

suất, chính sách trang phục, chính sách cơ hội bình đẳng,,)

+ Legal – Pháp lý: đây là những yêu cầu mà liên quan đến các quy định pháp luật và

quy định ràng buộc

+ Branding – nhãn hiệu: những yêu cầu này liên quan đến hình ảnh của tổ chức Thông thường, sẽ có tài liệu về thương hiệu, ví dụ như hướng dẫn về phong cách cho thương hiệu, sẽ đưa ra các yếu tố như biểu tượng, từ khóa, ngôn ngữ và màu sắc logo + Cultural – Văn hoá: những yêu cầu này liên quan đến loại văn hoá được yêu cầu trong tổ chức VD: văn hóa công ty, văn hóa phục vụ

+ Language –Ngôn ngữ: Những yêu cầu này đưa ra các ngôn ngữ nào được sử dụng trong tổ chức và cách giao tiếp với khách hàng và các tổ chức khác VD: làm trong công

ty tập đoàn đa quốc gia đòi hỏi bạn phải nói tiếng anh giỏi và biết thêm một thứ tiếng nữa

b) Technical requirements (Yêu cầu kỹ thuật)

Đây là những yêu cầu nêu rõ các chính sách kỹ thuật trong tổ chức, Áp dụng cho loạt các thay đổi Các loại phụ cụ thể của các yêu cầu kỹ thuật bao gồm:

+ Hardware – phần cứng: Yêu cầu về phần cứng như mô hình thiết bị phần cứng trong tổ chức, phần cứng CNTT ,các thiết bị liên quan đến công việc của tổ chức như thiết bị sản xuất hoặc thiết bị văn phòng

+ Software – phần mềm: Yêu cầu phần mềm như hệ điều hành, ứng dụng phần mềm, phần mềm mạng và truyền thông, phần mềm đám mây…

+ Interoperability – khả năng tương tác :Các yêu cầu về khả năng tương tác như giữ liên lạc giữa các hệ thống trong tổ chức.Vd: kết nối máy in với máy nhân viên thuận tiện công việc in ấn hồ sơ…

+ Internet requirements – Yêu cầu Internet : Các yêu cầu này liên quan đến các chính sách kỹ thuật điều chỉnh việc sử dụng internet và các dịch vụ hỗ trợ web

c) Functional requirements (Yêu cầu chức năng)

Nói đến các mong muốn của khách hàng/ stakeholder mà sản phẩm, hệ thống hay gì đó phải có, phải thực hiện được.Ví dụ: app Ngân hàng coi số dư, thanh toán, app chụp hình thì chụp hình được Tức là mong muốn của khách hàng khi sử dụng dịch vụ sản phẩm.Các yêu cầu chức năng tạo thành một yếu tố quan trọng trong danh mục các yêu cầu bởi

vì chúng xác định các tính năng cụ thể sẽ được cung cấp bởi một giải pháp Ngoài ra, các yêu cầu chức năng có thể thay đổi thường xuyên

Chúng ta có các loại Functional requirements như:

+ Data entry requirements – nhập các dữ liệu yêu cầu: liên quan đến thu thập và ghi lại các dữ liệu được yêu cầu trong giải pháp

+ Data maintenance requirements – Yêu cầu bảo trì dữ liệu : xử lý các thay đổi đối với dữ liệu được sử dụng trong giải pháp

+ Procedure requirements – Thủ tục các yêu cầu: Việc các quy tắc kinh doanh được

áp dụng trong quá trình làm việc không được hiểu rõ gây nhiều bất cập sau này Do đó Các yêu cầu này cần được xác định rõ ràng để chúng có thể được áp dụng chính xác.Các

kỹ thuật như cây quyết định hoặc bảng quyết định có thể rất hữu ích trong việc ghi chép các yêu cầu này

+ Retrieval requirements – yêu cầu truy xuất : liên quan đến các yêu cầu về dữ liệu và bao gồm việc cung cấp các báo cáo và phản hồi cụ thể cho các yêu cầu

d) Non-functional requirements (Yêu cầu phi chức năng)

Thật ra việc phân tích non-functional không mất nhiều thời gian và không lớn Thường chúng ta chỉ phân tích functional mà quên mất việc phân tích non-functional.Tại sao phải phân tích nó?

Vì chúng ta phải có

• Yếu tố về cơ sở hạ tầng (Chúng ta làm dự án CNTT cần có hạ tầng để chạy, phải

có server, máy móc, thiết bị…)

• Nắm được khả năng đáp ứng: có 2 khía cạnh 1 là khả năng đáp ứng hạ tầng hiện

có của hệ thống hiện có 2 là có thể thêm cái khả năng đáp ứng về mặt tài chính vì trong trường hợp đầu tư thêm hạ tầng hệ thống,mạng đường truyền abc gì đó cần xem tài chính có đủ hay không

• Phải hiểu rõ nó nếu không sẽ khó thực hiện phần mềm, hệ thống Ở hiện tại chúng

ta thực hiện như thế nào cần làm gì từ đó có những kế hoạch phù hợp, định hướng kinh doanh và đánh giá dễ dàng các vấn đề kỹ thuật

Các dạng yêu cầu phi chức năng như:

• Yêu cầu bảo mật: các hệ thống đòi hỏi rất cao về yêu cầu bảo mật đặc biệt tài chính liên quan ngân hàng

• Yêu cầu sao lưu: yêu cầu lưu trữ dữ liệu => rất quan trọng vì bất kì một gì đó sinh

ra dữ liệu và dữ liệu luôn là một trong những cái làm tăng dung lượng lưu trữ rất cao

• Yêu cầu về tính sử dụng: yêu cầu về mặt hữu dụng 24/7

• Yêu cầu về tính ổn định

• Yêu cầu về kích thước hệ thống

• Yêu cầu về hiệu năng

• Yêu cầu về tính hỗ trợ: hỗ trợ phía người dùng nhà cung cấp

• Các ràng buộc thiết kế (design constraints): yêu cầu liên quan cấu hình server, cấu hình số lượng server sử dụng cùng lúc

• Yêu cầu về giao tiếp hệ thống: ví dụ: giao tiếp về mặt ABI, yc giao tiếp chúng ta phải có đường truyền kênh riêng

• Yêu cầu tài liệu người dùng và hỗ trợ trực tuyến

• Các yêu cầu pháp lý, bản quyền và những ghi chú khác

• Các tiêu chuẩn áp dụng: VD pháp áp dụng tiêu chuẩn theo PCI aff thi thực hiện mặc thanh toán

• Các yêu cầu khác

=> Đây là thông tin cần phân tích và mô tả khi xây dựng một hệ thống Chúng ta

hay quên nó nó không khó nhưng ta hay quên Nó chỉ là yc nhỏ nhưng nó quyết định thành bại của hệ thống và các yc này đòi hỏi chúng ta có kiến thức về mặt hệ thống và kiến thức cơ bản CNTT đây cũng là lý do vì sao làm trong môi trường ITBA kiến thức

cơ bản về mặt IT mình phải có Mà kiến thức IT không phải là lập trình sai rồi nhưng mình cần phải hiểu được máy tính có cái gì, cấu trúc máy tính nó ntn, máy tính chạy ra sau, các thành phần máy tính như thế nào, các yc mặt phần cứng, phần mềm, mạng lúc đó

là yếu tố mình tìm hiểu Chứ không phải hơi chút học BA là lập trình code các bạn phải biết và hiểu rõ về máy tính và bạn cần hiểu rõ ITBA kiến thức mặt mặt It nó là kiến thức nghiệp vụ những kiến thức trong Romance đó mà chúng ta phải hiểu chứ không phải các bạn nói học code học It để làm BA sai mà các bạn làm BA trong môi trường gì thì các bạn phải nắm vững các kiến thức trong môi trường đó

2 Hierarchy of requirements (Thứ bậc các yêu cầu)

- Các yêu cầu phải có mối quan hệ, liên quan và logic với nhau

- Trong đó một số yêu cầu chung và yêu cầu kỹ thuật tham khảo các chính sách kinh doanh được hình thành, phát triển và mở rộng trong lĩnh vực phi chức năng và yêu cầu chức năng

* Lợi ích khi hiểu được thứ bậc các yêu cầu:

- Giup đảm bảo các yêu cầu sẽ nhất quán và mạch lạc

- Khi đưa ra các yêu cầu phi chức năng thì doanh nghiệp cũng như là các chính sách kỹ thuật sẽ giúp cung cấp thông tin một cách chi tiết nhất Đặc biệt là lý giải được vì sao cần phải đưa ra những yêu cầu này, nó hợp lý và cần thiết đến mức nào

*Ví dụ: Yêu cầu chức năng của hộp sữa carton là có thể tích 400ml và có một vài yêu cầu

chức năng phổ biến như là: Nguyên tắc kinh doanh; các giao dịch đúng, những dự án điều chỉnh và hủy bỏ; chức năng hành chính; giao diện bên ngoài; yêu cầu chứng chỉ; yêu cầu báo cáo; lịch sử dữ liệu; yêu cầu pháp lý và quy định,

Những yêu cầu này sẽ được xây dựng thêm trong các yêu cầu phi chức năng ví như là: hiệu suất; độ khả dụng; độ tin cậy; quy định; khả năng sử dụng,

• Hệ thống phân cấp các yêu cầu, liên kết các yêu cầu chức năng và yêu cầu phi chức năng giúp cung cấp một phương tiện nhu cầu kinh doanh ban đầu cho họ Nhờ vậy mà điều này sẽ giúp ích rất nhiều khi xem xét mức độ ưu tiên về yêu cầu, thời gian giao hả hay cả việc rớt yêu cầu

3 Documenting a requirement (Ghi lại một yêu cầu)

- Mỗi yêu cầu phải được lập thành văn bản để xác định rõ ràng những gì được yêu cầu

Và một mẫu danh mục yêu cầu tiêu chuẩn phải cần chứa các mục nhập sau đây:

+ Mã định danh: Đây thường là mã được liên kết với loại yêu cầu

+ Tên yêu cầu: Là tên được phân bổ cho một yêu cầu Có thể là một đoạn cụm từ ngắn cho biết yêu cầu liên quan đến gì

+ Mô tả yêu cầu: Ban đầu thì mô tả có thể ở mức độ phác thảo và sau đó nó sẽ được trình bày rõ ràng, chi tiết hơn qua các phiên bản của tài liệu yêu cầu

* Cấu trúc nên áp dụng đối với yêu cầu thực hành:

+ Tác nhân ( hoặc vai trò người dùng)

+ Cụm động từ

+ Tân ngữ ( danh từ hoặc cụm danh từ)

Ví dụ:

- Về yêu cầu chức năng: Nhân viên bán hàng có thể xem thông tin, địa chỉ khách hàng

- Về yêu cầu chung: Giải pháp phải tuân thủ các quy định của luật an toàn giao thông + Nguồn: (người tạo ra hoặc nguồn thông tin cho yêu cầu): Là tên của một bên liên quan hoặc cũng có thể là tham chiếu đến tài liệu chứa thông tin liên quan đến vấn đề đó

Ví dụ: Một bên liên quan có thể đã xác định được yêu cầu trong một cuộc phỏng vấn

• Họ có thể đưa ra các quyết định liên quan đến yêu cầu

+ Tác giả: Là nhà phân tích gợi và ghi lại yêu cầu

+ Loại yêu cầu: Là cái mà yêu cầu thuộc về Nó có thể chỉ ra các loại yêu cầu như là chung, kỹ thuật, chức năng hoặc phi chức năng hay không? Mặc dù có thể không cần thiết nêu ra điều này nếu mã định danh bao gồm tham chiếu đến loại

Loại yêu cầu có thể được xác định ở cấp độ phụ Ví dụ: Yêu cầu ( chung – hợp pháp) + Ưu tiên: Mức độ ưu tiên của yêu cầu được sử dụng khác nhau giữa các tổ chức doanh nghiệp hoặc cũng có thể khác nhau giữa các dự án

Phương pháp DSDM Atern đã đưa ra một cách tiếp cận ưu tiên với việc sử dụng

MoSCoW dễ nhớ và cụ thể như sau:

• M – must have: Cần thiết và bắt buộc ở bước tăng đầu tiên

• S – should have: cũng bắt buộc nhưng có thể được hoãn lại với thời gian ngắn để bước tăng thứ hai

• C – could have: có vẻ muốn nhưng không thực hiện được vì lý do thời gian và ngân sách

• W – sẽ không có thời gian này: là một yêu cầu được hoãn lại cho tới giai đoạn sau Một số yêu cầu là hoãn lại vì: Có thể yêu cầu đó được công nhận là cần thêm vào xem xét

và điều đó sẽ gây ra sự chậm trễ đối với một số yêu cầu nếu chúng được thực hiện ở bước đầu tiên

+ Khu vực kinh doanh: Tên của khu vực kinh doanh mà yêu cầu thuộc về Cũng có thể là

tên của chức năng kinh doanh, bộ phận hoặc là tên của quá trình kinh doanh

+ Các bên liên quan: Xác định các bên liên quan và lợi ích của họ cho từng yêu cầu sẽ cung cấp cho các nhà phân tích kinh doanh một lời nhắc nhở tốt nhất, sẽ đảm bảo được tất cả lợi ích của các bên liên quan đã được xem xét

+ Yêu cầu phi chức năng liên quan: Có một số yêu cầu chức năng được liên kết với yêu

cầu phi chức năng ( yêu cầu không chức năng cụ thể)

*Ví dụ: Để đảm bảo tốc độ yêu cầu thông tin thì về chính sách dịch vụ khách hàng vì thế

mà yêu cầu chức năng về truy cập thông tin tài khoản khách hàng có thể có thêm yêu cầu

về thời gian không liên quan đến nó để đáp ứng được hoạt động

+ Tiêu chí chấp nhận: Là tiêu chí mà cho phép nhân viên kinh doanh đồng ý rằng yêu cầu

đó đã được chuyển giao

+ Yêu cầu liên quan: Gồm các định danh của bất kỳ yêu cầu nào nếu như nó có mối quan

hệ liên quan đến yêu cầu này

Lý do liên quan: yêu cầu kinh doanh cấp cao cung cấp thêm thông tin kinh doanh cho các yêu cầu chức năng hoặc phi chức năng hay là các yêu cầu phi chức năng liên quan đến yêu cầu chức năng và ngược lại,

+ Tài liệu liên quan: Các tài liệu này thường là tài liệu dự án hoặc có thể là văn bản giải

trình kinh doanh Một hình thức tài liệu khác cũng có thể được liên kết với yêu cầu là tài liệu mô hình – được tạo ra cho dự án nhằm thay đổi kinh doanh

+ Bình luận: Là tổng hợp các nhận xét khác vô cùng hữu ích mà nhà phân tích đưa ra đối với một yêu cầu cụ thể

+ Lý do: Là các biện minh, lý giải cho các yêu cầu Và những lý do này có thể được xem hay tham khảo chéo với những lợi ích cụ thể trong kinh doanh

+ Nghị quyết: Có một số trường hợp là yêu cầu có thể được thực hiện, trì hoãn hay sáp nhập với yêu cầu khác và nghị quyết chính là thứ mà được sử dụng để ghi lại quyết định

và thời gian của quyết định này