Các phương pháp hiện đại để mô tả các yêu cầu chức năng cho hệ thống. Alistair Coburn. Đánh giá cuốn sách và bổ sung

Cuốn sách mô tả một phương pháp viết một phần của báo cáo vấn đề, đó là phương pháp ca sử dụng.

Nó là gì? Đây là mô tả kịch bản tương tác của người dùng với hệ thống (hoặc với doanh nghiệp). Trong trường hợp này, hệ thống hoạt động như một hộp đen (và điều này giúp có thể chia nhiệm vụ thiết kế phức tạp thành thiết kế tương tác và đảm bảo tương tác này). Đồng thời, các tiêu chuẩn ký hiệu được đưa ra, đảm bảo dễ đọc, kể cả đối với những người không tham gia và cho phép một số kiểm tra về tính đầy đủ và tuân thủ các mục tiêu của các bên liên quan.

Ví dụ trường hợp sử dụng

Kịch bản trông như thế nào, sử dụng ví dụ về ủy quyền trên trang web qua email:

(Hệ thống) Đăng nhập vào website để truy cập tài khoản cá nhân. ~~ (mực nước biển)

Bối cảnh: Một khách hàng trái phép đăng nhập vào trang web để trang web nhận ra anh ta và hiển thị thông tin cá nhân cho anh ta: lịch sử duyệt web, lịch sử mua hàng, số điểm thưởng hiện tại, v.v., sử dụng email làm thông tin đăng nhập. 
Cấp độ: mục tiêu người dùng
Nhân vật chính: khách hàng (khách truy cập cửa hàng trực tuyến của chúng tôi)
Phạm vi: Tương tác của khách hàng với trang web cửa hàng trực tuyến
Các bên liên quan và lợi ích:

  • nhà tiếp thị muốn xác định số lượng khách truy cập trang web tối đa để có được mức độ bao phủ lớn hơn cho các thư cá nhân,
  • chuyên gia bảo mật muốn đảm bảo rằng không có trường hợp truy cập trái phép vào dữ liệu cá nhân của khách truy cập, bao gồm cả việc cố gắng đoán mật khẩu của một tài khoản hoặc tìm kiếm tài khoản có mật khẩu yếu,
  • kẻ tấn công muốn truy cập vào phần thưởng của nạn nhân,
  • đối thủ cạnh tranh muốn để lại đánh giá tiêu cực về sản phẩm,
  • Botnet muốn lấy được cơ sở khách hàng của cửa hàng và sử dụng một cuộc tấn công để khiến trang web không thể hoạt động.

Điều kiện tiên quyết: khách truy cập không được phép.
Đảm bảo tối thiểu: khách truy cập sẽ biết liệu nỗ lực ủy quyền thành công hay không thành công.
Bảo đảm thành công: khách truy cập được ủy quyền.

Kịch bản chính:

  1. Khách hàng bắt đầu ủy quyền.
  2. Hệ thống xác nhận rằng khách hàng không được ủy quyền và không vượt quá số lần ủy quyền không thành công trong một phiên nhất định (tìm kiếm mật khẩu yếu cho nhiều tài khoản) theo “Quy tắc bảo mật số 23”.
  3. Hệ thống tăng bộ đếm số lần thử ủy quyền.
  4. Hệ thống hiển thị mẫu ủy quyền cho khách hàng.
  5. Khách hàng nhập email và mật khẩu của mình.
  6. Hệ thống xác nhận sự hiện diện của khách hàng có email như vậy trong hệ thống và mật khẩu trùng khớp và số lần đăng nhập vào tài khoản này không bị vượt quá theo “Quy tắc bảo mật số 24”.
  7. Hệ thống ủy quyền cho khách hàng, thêm lịch sử duyệt web và giỏ của phiên này với phiên cuối cùng của tài khoản khách hàng này.
  8. Hệ thống hiển thị thông báo ủy quyền thành công và chuyển sang bước tập lệnh mà máy khách đã bị gián đoạn để ủy quyền. Trong trường hợp này, dữ liệu trên trang được tải lại có tính đến dữ liệu tài khoản cá nhân.

Tiện ích mở rộng:
2.a. Khách hàng đã được ủy quyền:
 2.a.1. Hệ thống sẽ thông báo cho khách hàng về thực tế của việc ủy ​​quyền đã thực hiện trước đó và đề nghị làm gián đoạn tập lệnh hoặc chuyển sang bước 4 và nếu bước 6 được hoàn thành thành công thì bước 7 sẽ được thực hiện với phần làm rõ:
 2.a.7. Hệ thống hủy kích hoạt ứng dụng khách theo tài khoản cũ, ủy quyền ứng dụng khách theo tài khoản mới, trong khi lịch sử duyệt web và giỏ hàng của phiên tương tác này vẫn giữ nguyên trong tài khoản cũ và không chuyển sang tài khoản mới. Tiếp theo, chuyển sang bước 8.
2.b Số lần ủy quyền đã vượt quá ngưỡng theo “Quy tắc bảo mật số 23”:
 2.b.1 Sang bước 4, trên mẫu ủy quyền sẽ hiển thị thêm hình ảnh xác thực
 2.b.6 Hệ thống xác nhận nhập captcha đúng
    2.b.6.1 Captcha nhập sai:
      2.b.6.1.1. hệ thống cũng tăng số lần thử ủy quyền không thành công cho tài khoản này
      2.b.6.1.2. hệ thống hiển thị thông báo lỗi và quay lại bước 2
6.a. Không tìm thấy tài khoản nào có email này:
 6.a.1 Hệ thống hiển thị thông báo lỗi và đưa ra lựa chọn chuyển sang bước 2 hoặc chuyển sang kịch bản “Đăng ký người dùng” và lưu email đã nhập,
6.b. Mật khẩu của tài khoản có email này không khớp với mật khẩu đã nhập:
 6.b.1 Hệ thống tăng số lần đăng nhập không thành công vào tài khoản này.
 6.b.2 Hệ thống hiển thị thông báo lỗi và đưa ra lựa chọn chuyển sang kịch bản “Khôi phục mật khẩu” hoặc chuyển sang bước 2.
6.c: Bộ đếm số lần đăng nhập cho tài khoản này đã vượt quá ngưỡng cho “Quy tắc bảo mật số 24”.
 6.c.1 Hệ thống hiển thị thông báo chặn đăng nhập tài khoản trong X phút và chuyển sang bước 2.

Có gì tuyệt vời

Kiểm tra tính đầy đủ và tuân thủ các mục tiêu, nghĩa là bạn có thể đưa ra yêu cầu cho nhà phân tích khác để xác minh, ít mắc lỗi hơn ở giai đoạn hình thành vấn đề.

Làm việc với hệ thống loại hộp đen cho phép bạn tách biệt việc phát triển và phối hợp với khách hàng về những gì sẽ được tự động hóa khỏi các phương pháp triển khai.

Nó là một phần trong con đường của nhà phân tích, một trong những phần chính của khả năng sử dụng. Kịch bản của người dùng xác định các hướng di chuyển chính của anh ta, điều này làm giảm đáng kể quyền tự do lựa chọn của nhà thiết kế và khách hàng, đồng thời giúp tăng tốc độ phát triển thiết kế.

Tôi rất hài lòng với vị trí trong phần mô tả nơi xác định các trường hợp ngoại lệ cho từng bước tương tác. Một hệ thống CNTT hoàn chỉnh phải cung cấp một số loại xử lý ngoại lệ, một số thủ công, một số tự động (như trong ví dụ trên).

Kinh nghiệm cho thấy rằng việc xử lý ngoại lệ thiếu cân nhắc có thể dễ dàng biến một hệ thống thành một hệ thống cực kỳ bất tiện. Tôi nhớ câu chuyện khi ở thời Xô Viết, để có được quyết định, bạn phải nhận được nhiều sự chấp thuận từ các dịch vụ khác nhau và thật đau đớn biết bao khi dịch vụ cuối cùng nói - nhưng đơn đăng ký của bạn lại sai tên hoặc một số lỗi khác trong dấu câu, làm lại mọi thứ và phối hợp lại mọi thứ.

Tôi thường gặp những tình huống trong đó logic vận hành của một hệ thống không được tính toán trước các trường hợp ngoại lệ đòi hỏi phải làm lại hệ thống một cách đáng kể. Vì lý do này, phần lớn công việc của nhà phân tích được dành cho việc xử lý ngoại lệ.

Ký hiệu văn bản, trái ngược với sơ đồ, cho phép xác định và đề cập đến nhiều trường hợp ngoại lệ hơn.

Bổ sung phương pháp từ thực tế

Ca sử dụng không phải là phần được ưu tiên độc lập trong tuyên bố, không giống như câu chuyện của người dùng.

Trong trường hợp trên, hãy xem xét ngoại lệ “6.a. Không tìm thấy tài khoản nào có email này.” và bước tiếp theo “6.a.1 Hệ thống hiển thị thông báo lỗi và chuyển sang bước 2.” Những điều tiêu cực nào đã bị bỏ lại phía sau? Đối với khách hàng, bất kỳ khoản hoàn trả nào cũng tương đương với việc tất cả công việc anh ta thực hiện để nhập dữ liệu đều bị ném vào bãi rác. (Chỉ là nó không hiển thị trong kịch bản!) Bạn có thể làm gì? Xây dựng lại tập lệnh để điều này không xảy ra. có khả năng làm cái này không? Bạn có thể - làm ví dụ, hãy xem tập lệnh ủy quyền của Google.

Tối ưu hóa kịch bản

Cuốn sách nói về sự chính thức hóa nhưng lại đề cập rất ít về các phương pháp tối ưu hóa những kịch bản như vậy.

Nhưng có thể củng cố phương pháp này bằng cách tối ưu hóa các kịch bản và phương pháp chính thức hóa ca sử dụng cho phép thực hiện điều này. Cụ thể, bạn cần suy nghĩ về từng ngoại lệ xảy ra, xác định nguyên nhân và xây dựng lại kịch bản để loại bỏ ngoại lệ hoặc giảm thiểu hành trình của khách hàng.

Khi đặt hàng từ cửa hàng trực tuyến, bạn phải nhập thành phố giao hàng. Có thể cửa hàng không thể giao hàng đến thành phố mà khách hàng đã chọn vì không giao hàng ở đó, do hạn chế về kích thước hoặc do thiếu hàng trong kho tương ứng.

Nếu chúng ta mô tả đơn giản kịch bản tương tác ở giai đoạn đăng ký, chúng ta có thể viết “thông báo cho khách hàng rằng không thể giao hàng và đề nghị thay đổi thành phố hoặc nội dung của giỏ hàng” (và nhiều nhà phân tích mới bắt đầu dừng lại ở đó). Nhưng nếu có nhiều trường hợp như vậy thì kịch bản có thể được tối ưu hóa.

Điều đầu tiên bạn cần làm là cho phép bạn chỉ chọn thành phố nơi chúng tôi có thể giao hàng. Khi nào nên làm điều này? Trước khi chọn sản phẩm trên trang web (tự động phát hiện thành phố qua IP có làm rõ).

Thứ hai, chúng tôi chỉ cần đưa ra lựa chọn về những mặt hàng mà chúng tôi có thể giao cho khách hàng. Khi nào nên làm điều này? Tại thời điểm lựa chọn - trên ô sản phẩm và thẻ sản phẩm.

Hai thay đổi này sẽ giúp ích rất nhiều trong việc loại bỏ ngoại lệ này.

Yêu cầu về đo lường và số liệu

Khi xem xét nhiệm vụ giảm thiểu việc xử lý ngoại lệ, bạn có thể đặt nhiệm vụ báo cáo (trường hợp sử dụng không được mô tả). Có bao nhiêu trường hợp ngoại lệ, chúng xảy ra trong trường hợp nào, cộng với bao nhiêu tình huống sắp xảy ra đã được vượt qua thành công.

Nhưng than ôi. Kinh nghiệm cho thấy yêu cầu báo cáo cho các kịch bản theo hình thức này là chưa đủ, cần xem xét yêu cầu báo cáo cho các quy trình được mô tả chủ yếu không ở dạng ca sử dụng.

Truy cập vào khả năng sử dụng

Trong thực tế, chúng tôi đã mở rộng biểu mẫu mô tả trường hợp sử dụng với mô tả các thuộc tính cụ thể của thực thể và dữ liệu để khách hàng đưa ra quyết định, giúp nâng cao khả năng sử dụng sau này.

Để thiết kế khả năng sử dụng, chúng tôi đã thêm phần đầu vào - hiển thị dữ liệu.

Trong trường hợp có ủy quyền, đây là thực tế là máy khách được ủy quyền trong hệ thống. Nếu khách hàng được ủy quyền trước thì hiển thị cảnh báo về việc chuyển lịch sử điều hướng và giỏ hàng sang tài khoản mới sau khi ủy quyền thành công.

Nói chung, đây là màn hình hiển thị thông tin cần thiết cho khách hàng để họ có thể đưa ra quyết định về các hành động tiếp theo của mình theo kịch bản (bạn có thể hỏi liệu dữ liệu này có đủ cho khách hàng hay không, cần thêm gì nữa, thông tin gì khách hàng cần đưa ra quyết định).  
Cũng nên chia thông tin đã nhập thành các trường đầu vào nếu chúng được xử lý riêng biệt và hình thành các ngoại lệ khác nhau.

Trong ví dụ với ủy quyền ứng dụng khách, nếu bạn tách thông tin đã nhập thành thông tin đăng nhập và mật khẩu thì cần thay đổi tập lệnh ủy quyền để làm nổi bật các giai đoạn nhập thông tin đăng nhập riêng và mật khẩu riêng (và việc này được thực hiện trong Yandex, Google, nhưng không được thực hiện ở hầu hết các cửa hàng trực tuyến).

Đạt được các chuyển đổi dữ liệu cần thiết

Bạn cũng có thể trích xuất các yêu cầu về thuật toán chuyển đổi dữ liệu từ tập lệnh.

ví dụ:

  • Để đưa ra quyết định mua sản phẩm trong cửa hàng trực tuyến, khách hàng cần biết trên thẻ sản phẩm khả năng, chi phí, thời gian giao hàng đến thành phố của mình đối với sản phẩm này (được tính toán bằng thuật toán dựa trên tình trạng còn hàng của sản phẩm tại các thông số kho bãi và chuỗi cung ứng).
  • Khi nhập một cụm từ vào dòng tìm kiếm, khách hàng sẽ được hiển thị các gợi ý tìm kiếm theo thuật toán (do thuật toán tạo ra…).

trong tổng số

Nói chung, thật không may, sau khi đọc cuốn sách, không rõ làm thế nào để đi từ một nhà phân tích đến các vấn đề kinh doanh đến một đặc tả kỹ thuật chính thức cho một nhà phát triển. Cuốn sách chỉ kể một phần của quy trình, với các bước đầu vào không rõ ràng và các bước tiếp theo cũng không rõ ràng. Bản thân ca sử dụng thường không phải là một tuyên bố hoàn chỉnh cho nhà phát triển.

Tuy nhiên, đây là một cách rất tốt để chính thức hóa và xử lý các kịch bản tương tác giữa một đối tượng và một chủ thể, khi sự tương tác gây ra sự thay đổi về một điều gì đó trong chủ thể. Đây là một trong số ít phương pháp viết cho phép xác minh các yêu cầu bằng các điểm tìm kiếm ngoại lệ rõ ràng.

Cuốn sách này là một cuốn sách phải đọc đối với các nhà phân tích để bắt đầu viết những vở kịch có thể kiểm chứng được.

Nguồn: www.habr.com

Thêm một lời nhận xét