Đơn vị 2 / 11

Phân tích yêu cầu và phân tích nhu cầu của các bên liên quan

Lợi nhuận:

  • Khả năng phân biệt các yêu cầu chức năng và phi chức năng và viết các biểu thức yêu cầu rõ ràng, có thể đo lường được với sự hỗ trợ của trí tuệ nhân tạo
  • Khả năng sử dụng trí tuệ nhân tạo với các lời nhắc có cấu trúc để trích xuất câu chuyện của người dùng, tiêu chí chấp nhận và giới hạn phạm vi từ ghi chú phỏng vấn
  • Tập thói quen kiểm tra các yêu cầu do AI tạo ra để tìm sự mơ hồ, mâu thuẫn và thiếu các quy tắc và xác nhận chúng với các bên liên quan

Phân tích yêu cầu là nhiệm vụ xác định một cách đầy đủ, rõ ràng và có thể kiểm chứng được những gì hệ thống nên làm. Đây là một trong những giai đoạn mà chuyên gia MIS tạo ra nhiều giá trị nhất; bởi vì sai lầm ở đây sẽ tăng theo cấp số nhân vào cuối dự án. Có hai loại phân tích yêu cầu cơ bản. Yêu cầu chức năng mô tả công việc mà hệ thống phải thực hiện: “Hệ thống sẽ gửi email cho khách hàng khi xác nhận đơn hàng”. Yêu cầu phi chức năng mô tả hệ thống phải như thế nào: các phẩm chất như hiệu suất, bảo mật, khả năng sử dụng và khả năng truy cập. "Màn hình báo cáo sẽ mở trong vòng chưa đầy 2 giây ở mức tải trung bình" là yêu cầu phi chức năng.

Một yêu cầu tốt có ba đặc điểm: rõ ràng (có một cách diễn giải duy nhất), có thể đo lường được (có ngưỡng có thể kiểm tra được) và có thể theo dõi được (rõ ràng nhu cầu kinh doanh đó xuất phát từ đâu). "Hệ thống phải nhanh" không đáp ứng được những điều này; “nhanh” là chủ quan, không thể đo lường, không thể kiểm tra. Ở giai đoạn này, AI là công cụ hỗ trợ đắc lực trong việc soạn thảo các yêu cầu và nắm bắt các từ ngữ mơ hồ; nhưng chỉ có bên liên quan mới quyết định quy tắc kinh doanh nào là thực tế.

Câu chuyện của người dùng và tiêu chí chấp nhận

Một định dạng phổ biến trong cách viết yêu cầu hiện đại là câu chuyện của người dùng: "Là một [vai trò], vì [mục đích], tôi muốn [tính năng]." Ví dụ: "Là đại diện bán hàng, tôi muốn tính toán chiết khấu từ màn hình di động để có thể báo giá nhanh tại hiện trường." Câu chuyện ngắn gọn và mang tính kinh doanh; Nó không áp đặt một giải pháp kỹ thuật.

Mọi câu chuyện phải có tiêu chí chấp nhận: các điều kiện có thể kiểm chứng phải được đáp ứng để câu chuyện được coi là "ổn". Mẫu được sử dụng thường xuyên là mẫu "Cho/Khi/Thì": "Cho: khách hàng thuộc phân khúc VIP. Khi nào: đơn hàng trên 10.000 TL. Khi đó: hệ thống áp dụng chiết khấu 5%." Mô hình này loại bỏ sự mơ hồ vì nó kết nối rõ ràng điều kiện và kết quả mong đợi.

Mẹo: Khi viết câu chuyện của người dùng cho trí tuệ nhân tạo, hãy nhớ nói "tạo ít nhất 2 tiêu chí chấp nhận ở định dạng Cho trước/Khi/Sau đó cho mỗi câu chuyện". Khi mô hình buộc phải tạo điểm chuẩn, những khoảng trống ẩn trong yêu cầu sẽ lộ rõ.

Từng bước: Trích xuất yêu cầu được hỗ trợ bởi AI

Bước 1 - Thu thập đầu vào thô. Nhật ký cuộc gọi, email, ảnh chụp màn hình hiện có, danh sách khiếu nại. Đầu vào càng thực tế thì càng ít bịa đặt.

Bước 2 - Trích xuất tập truyện đầu tiên. Cung cấp đầu vào thô cho trí tuệ nhân tạo và yêu cầu nó tạo ra bản thảo câu chuyện của người dùng. Bước này không phải là một danh sách đầy đủ, nhưng là bước đầu tiên.

Bước 3 - Thêm tiêu chí chấp nhận. Tạo tiêu chí Cho trước/Khi nào/Sau đó cho mỗi câu chuyện. Một câu chuyện không thể đưa ra tiêu chí thực sự có nghĩa là nó chưa được xác định đầy đủ.

Bước 4 - Quét tìm mâu thuẫn và khoảng trống. Hỏi AI “có mâu thuẫn, trùng lặp hoặc tình huống không xác định nào giữa các yêu cầu này không?” Hãy hỏi và kiểm tra nó. Lọc kết quả như một con người.

Bước 5 - Ưu tiên và xác nhận. Ưu tiên các câu chuyện với các bên liên quan dựa trên giá trị kinh doanh và tính cấp bách. Quyết định ưu tiên thuộc về đơn vị kinh doanh chứ không phải AI.

Đừng quên các yêu cầu phi chức năng

Hầu hết các dự án đều gặp khó khăn trong lĩnh vực này vì họ quên những phần phi chức năng khi viết các yêu cầu chức năng. Một báo cáo có thể hoạt động “chính xác” nhưng nếu phải mất 45 giây để mở thì sẽ không có ai sử dụng nó. Bảng sau đây trình bày các loại yêu cầu phi chức năng thường bị bỏ qua và các ví dụ viết có thể đo lường được.

thể loại

biểu hiện xấu

biểu thức đo lường được

Hiệu suất

"Phải nhanh"

"Phản hồi truy vấn < 2 giây ở mức tải trung bình"

khả năng tiếp cận

"Mọi người đều có thể sử dụng nó"

"Tuân thủ WCAG 2.1 AA; điều hướng bàn phím đầy đủ"

Bảo mật

"Nó phải an toàn"

"Dữ liệu cá nhân được mã hóa ở phần còn lại; quyền truy cập dựa trên vai trò"

sẵn có

"Chắc phải dễ dàng"

"Người dùng mới hoàn tất đơn hàng trong 3 bước mà không cần đào tạo"

Sẵn có/liên tục

"Không nên va chạm"

"Thời gian hoạt động hàng tháng ≥ 99,5%"

Ba trường hợp nhỏ: Bằng những con số

Trường hợp 1 - Giá của một nhu cầu không thể đo lường được. Màn hình được phát triển trong một ngân hàng với yêu cầu "màn hình báo cáo phải mở nhanh", mở trong 22 giây khi tải trường. Nhà phát triển nghĩ rằng anh ấy đang cung cấp từ "nhanh" trong môi trường của mình (2 giây). Nếu yêu cầu được viết là "< 3 giây vào giờ cao điểm, thông lượng thực tế", vấn đề sẽ nằm trong quá trình thử nghiệm. Việc tái phát triển tốn 3 tuần và chi phí bổ sung có thể đo lường được.

Trường hợp 2 - Khoảng trống được nắm bắt theo tiêu chí chấp nhận. Khi viết tiêu chí chấp nhận cho câu chuyện “hệ thống áp dụng chiết khấu” trong một dự án thương mại điện tử, các bên liên quan nhận thấy rằng điều gì sẽ xảy ra nếu chiết khấu xung đột với phiếu giảm giá và chiết khấu VIP hoàn toàn không được thảo luận. Một câu hỏi Cho trước/Khi nào/Sau đó đã ngăn chặn lỗi giảm giá gấp đôi trước khi đi vào hoạt động; Lỗi này gây thất thoát doanh thu nghiêm trọng ở các dự án tương tự.

Trường hợp 3 - Quy tắc do AI tạo ra. Trong một dự án nhân sự, AI đã thêm câu “yêu cầu nghỉ việc được tự động phê duyệt trong vòng 24 giờ” vào bản dự thảo yêu cầu. Không có sự chấp thuận tự động nào như vậy được thảo luận trong cuộc họp; Mô hình đã đưa ra một quy tắc có vẻ “hợp lý”. Bên cạnh mỗi yêu cầu, chuyên gia viết “nguồn: cuộc phỏng vấn/tài liệu nào?” Khi thêm cột, anh đã loại bỏ 4 câu không có nguồn.

Nhắc yếu / Nhắc mạnh

Dấu nhắc yếu:

Viết câu chuyện của người dùng cho dự án này.

Lời nhắc mạnh mẽ:

Vai trò của bạn: Bạn là nhà phân tích kinh doanh MIS. Trích xuất các câu chuyện của người dùng từ ghi chú phỏng vấn bên dưới. Quy tắc: - Định dạng: “Là [vai trò], cho [mục đích], tôi muốn [tính năng].”- Viết ÍT NHẤT 2 tiêu chí chấp nhận cho mỗi câu chuyện ở định dạng Cho trước/Khi nào/Sau đó.- Thêm cột “Nguồn” bên cạnh mỗi câu chuyện: nó đến từ câu nào?- Dán nhãn [UNCERTAIN] bất kỳ quy tắc nào không rõ ràng trong ghi chú; phù hợp.- Viết các yêu cầu phi chức năng có thể đo lường được (hiệu suất, bảo mật, khả năng tiếp cận) trong một phần riêng biệt. Ghi chú phỏng vấn: [văn bản]

Lời nhắc mạnh mẽ thực thi định dạng câu chuyện, tiêu chí chấp nhận, truy xuất nguồn gốc và các yêu cầu phi chức năng cùng một lúc; Điều này giúp việc kiểm soát đầu ra dễ dàng hơn.

Bốn mẫu có thể sao chép

1) Làm rõ yêu cầu:

Xem lại yêu cầu dưới đây. Đánh dấu từng câu mơ hồ, không thể so sánh được hoặc có nhiều cách giải thích và viết câu hỏi làm rõ cho mỗi câu. Đừng bịa ra câu trả lời. Yêu cầu: [văn bản]

2) Quét mâu thuẫn:

Trong danh sách yêu cầu bên dưới, hãy tìm những mục mâu thuẫn với nhau, lặp đi lặp lại hoặc để lại khoảng trống logic. Báo cáo từng phát hiện kèm theo số mục và giải thích bằng một câu. Danh sách: [văn bản]

3) Xây dựng tiêu chí chấp nhận:

Viết ít nhất 4 tiêu chí chấp nhận cho câu chuyện của người dùng sau ở định dạng Cho trước/Khi/Sau đó, bao gồm các trường hợp giới hạn và ngoại lệ. Đồng thời liệt kê bất kỳ điểm nào vẫn chưa rõ ràng. Câu chuyện: [văn bản]

4) Sơ lược phạm vi:

Soạn thảo các mục "Trong phạm vi" và "Ngoài phạm vi" dưới dạng bảng hai cột theo các yêu cầu sau. Dán nhãn [BẮT BUỘC XÁC NHẬN] cho bất kỳ mục nào bạn không chắc chắn. Yêu cầu: [văn bản]

Những lỗi thường gặp

  • Nghĩ rằng giải pháp là một nhu cầu. "Thêm menu thả xuống" là một giải pháp chứ không phải là một yêu cầu. Yêu cầu cho biết "người dùng phải có thể chọn quốc gia từ danh sách đã xác định"; Nhóm CNTT thiết kế giải pháp.
  • Bỏ qua những cái không có chức năng. Đơn giản chỉ cần viết ra “phải làm gì” và quên “làm thế nào” (tốc độ, bảo mật, khả năng tiếp cận) là lỗ hổng phổ biến nhất và tốn kém nhất.
  • Dùng những tính từ không thể đo lường được. Những từ như "nhanh, dễ dàng, an toàn, thân thiện với người dùng" là không hợp lệ nếu không có ngưỡng.
  • Không để ý đến quy luật mà AI đã đặt ra. Mô hình có thể thêm các quy tắc “hợp lý” nhưng không thực sự được nói ra; Yêu cầu nguồn lực cho mọi nhu cầu.
  • Để lại ưu tiên cho AI. Việc cần làm đầu tiên là quyết định giá trị doanh nghiệp; Đơn vị kinh doanh đưa ra điều này.
Thận trọng: Câu nguy hiểm nhất trong phân tích yêu cầu là “mọi người đều đã biết điều này rồi”. Các giả định ngầm không được đưa vào tài liệu, không bao giờ được đưa vào mã và xuất hiện trên thực tế. Hỏi AI “điều gì được giả định nhưng không được ghi trong yêu cầu này?” làm cho những giả định ẩn này hiển thị.

Tóm lại

Phân tích yêu cầu xác định những gì hệ thống nên làm một cách rõ ràng, có thể đo lường được và có thể theo dõi được. Yêu cầu chức năng mô tả công việc, yêu cầu phi chức năng mô tả các phẩm chất và yêu cầu phi chức năng thường bị lãng quên. Câu chuyện của người dùng và các tiêu chí chấp nhận Cho trước/Khi nào/Thì là những công cụ mạnh mẽ giúp loại bỏ sự không chắc chắn. Trí tuệ nhân tạo tăng tốc đáng kể việc sản xuất bảng phân cảnh, tiêu chí chấp nhận, phát hiện xung đột và làm rõ câu hỏi; Tuy nhiên, tính đúng đắn của quy tắc kinh doanh, phạm vi và quyết định ưu tiên cũng như nguồn gốc của từng câu là trách nhiệm của con người. Không hoàn thiện bất kỳ yêu cầu nào không có nguồn gốc và không thể đo lường được.

Nhiệm vụ ứng dụng

Viết một yêu cầu kinh doanh dài một đoạn cho một “hệ thống hẹn trực tuyến” tưởng tượng (ví dụ: “Khách hàng có thể đặt lịch hẹn trực tuyến, nhân viên có thể xem lịch”). (1) Tạo ít nhất 5 câu chuyện của người dùng và 2 tiêu chí chấp nhận cho mỗi câu chuyện với lời nhắc mạnh mẽ từ yêu cầu này. (2) Tìm ít nhất 2 lỗ hổng ẩn trong các tiêu chí do mô hình đưa ra (ví dụ: hẹn hai người cùng lúc, quy tắc hủy). (3) Bao gồm ít nhất 3 yêu cầu phi chức năng ở dạng có thể đo lường được. (4) Xác định ít nhất 3 mục là “Nằm ngoài phạm vi”. (5) Đánh dấu một quy tắc mà mô hình có thể đã đặt ra và viết cách bạn xác nhận nó.

danh sách kiểm tra

  • [ ] Tôi đã viết riêng các yêu cầu chức năng và phi chức năng.
  • [ ] Mọi yêu cầu đều rõ ràng, có thể đo lường và kiểm tra được.
  • [ ] Mỗi câu chuyện đều có tiêu chí chấp nhận Cho trước/Khi nào/Sau đó.
  • [ ] Tôi có thể truy tìm nguồn gốc (cuộc trò chuyện/tài liệu) của từng yêu cầu.
  • [ ] Tôi đã đánh dấu các quy tắc có thể có mà AI đã đặt ra và để lại chúng để xác nhận.
  • [ ] Tôi đã xác định mức độ ưu tiên cùng với đơn vị kinh doanh.