Writing Effective Use case

Spread the love
  •   
  •   
  •   
  •   
  •  
  •  
  •  
  •  
  •  

Writing Effective Use case

 

Nếu bạn đã từng đọc cuốn Visual Model For Software Requirement của tác giả Joy Beatty and Anthony Chen (Năm 2016, NXB Microsoft Press – ISBN: 9780735667730), một cuốn sách dạy các kỹ thuật “best practices” để nắm bắt, phân tích và thực hiện các yêu cầu phần mềm thông qua các mô hình trực quan thì Cuốn sách Writing Effective Use Cases của tác giả Alistair Cockburn (Năm 2000, NXB Addison-Wesley Professional, ISBN 0-201-70225-8) lại là cuốn sách dày 250 trang chỉ viết về duy nhất một chủ đề cách viết Use case và gửi tới thông điệp tới người đọc là: Để mắt tới câu chữ thay vì các sô đồ”.

Trong phát triển phần mềm, use case được coi là trung tâm của các yêu cầu và thậm chí là trung tâm của quá trình phát triển dự án. Tôi đã đọc cuốn Visual Model For Software Requirement trước và tại đây đã học được nhiều phương pháp để tiếp cận thu thập và phân tích yêu cầu trong đó có viết use case. Chính vì thế khi đọc sang cuốn Writing Effective use case nhiều kiến thức tôi đã biết lúc đầu, chỉ dự định đọc lướt qua. Thế nhưng khi đọc chi tiết cuốn sách này cùng với các ví dụ thực tế rất chi tiết mà tác giả đã đưa ra, tôi chiêm nghiệm lại những kỹ thuật mình vẫn đang áp dụng trong công việc và học hỏi thêm được rất nhiều “best practices” từ tác giả. Dưới đây là một số nhưng lưu ý khi viết use case từ cuốn sách mà kể cả những người có kinh nghiệm cũng đáng lưu tâm.

Template một use case:

Field
Use case title
Scope and Level
Primary actor
Preconditions
Stakeholders and
interests
Minimal guarantees
Success guarantees
Main success scenario
Extension scenario
Technology or Data
Variation List
Overall use case content

 

Use case như một bài văn xuôi

Để mắt tới câu chữ thay vì các sơ đồ.

Cá nhân tôi không đồng tình lắm quan điểm này, sơ đồ và mô hình vẫn thường giúp trưc quan hóa nhanh hơn câu chữ. Kết hợp giữa sơ đồ với diễn giải chữ sẽ hiệu quả hơn. Tuy nhiên theo tôi, sau mỗi sơ đồ vẫn luôn cần phần câu chữ diễn giải để đảm bảo người đọc hiểu đúng và đủ.

Viết use case đọc ngắn gọn, súc tích và dễ đọc

Mô tả vấn đề ngắn gọn, tập trung những điểm quan trọng. Use case dài sẽ khiến ít người muốn đọc.

Đi theo mô hình Top-Down. Bắt đầu từ use case tổng quan (strategic use case) sau đó đến các use case level chi tiết hơn (user goal, subfunction-level use cases).

Đặt tên use case với động từ ngắn thông báo mục tiêu cần đạt được.

Use case luôn bắt đầu từ sự kiện kích hoạt cho tới khi mục tiêu thành công hoặc thất bại và hệ thống kết thúc giao dịch liên quan.

Viết câu đầy đủ với động từ chủ động mô tả các mục tiêu subgoals đã hoàn thành.

Đảm bảo actor luôn phải có ở mỗi bước mô tả của use case. Làm nổi bật các điều kiện tạo nên tình huống không thành công của hệ thống và các hành động phục hồi cẩn phải xử lý tiếp theo.

Mô tả các tình huống ngoại lệ (alternative case) trong phần mở rộng (extension) thay vì dùng các câu lệnh if – else ở mô tả tình huống chính (main scenario).

Từ các tình huống ngoại lệ chúng ta có thể tách ra thành 1 use case mới, tuy nhiên chỉ làm điều này trong các tình huống thực sự cần thiết.

Chỉ dùng một hình thức câu

Trong khi viết các bước của use case chỉ dùng một hình thức câu. Đó là thì hiện tại.

Ví dụ:

“Customer enters card and PIN.”
“System validates that customer is authorized and has sufficient funds.”
“PAF intercepts responses from the web site, and updates the user’s portfolio.”
“Clerk finds a loss using search details for “loss”.

Đưa vào các sub-use case

Quy tắc đầu tiên, luôn sử dụng mối quan hệ bao gồm “includes relation” giữa các case. Nhưng người tuân theo quy tắc này báo cáo rằng họ và những người đọc cảm thấy dễ hiểu và ít nhầm lẫn hơn so với việc đọc tài liệu có sử dụng lẫn quan hệ “extends and specializes

Luôn làm rõ câu hỏi: Ai đang giữ bóng?

Hãy luôn viết tên của actor – người đang thực hiện hành động ở từ đầu hoặc thứ 2 trong câu.

Use case được viết đúng với mức mục tiêu (goal level)

Đảm bảo use case được gắn nhãn chính xác với mức mục tiêu của nó: tóm tắt (summary), người dùng (user goal) hoặc chức năng con (sub function).

Xác định thật rõ là viết business use case hay system use case.

Business use case: Phạm vi thiết kế sẽ là hoạt động nghiệp vụ. Thông thường business use case không đề cập tới kỹ thuật chi tiết mà tập trung mô tả hoạt động nghiệp vụ. Thông thường viết dưới dạng white-box form.

System use case: Phạm vi thiết kế sẽ đề cập tới hệ thống, tập trung liên quan tới kỹ thuật, công nghệ. Thông thường viết dưới dạng black-box form.

Khi thiết kế hệ thống, nên viết cả 2 loại business và system use case. Business use case sẽ vẽ ra ngữ cảnh cho các chức năng của hệ thống và vị trị hệ thống trong bức tranh toàn cảnh của doanh nghiệp

Không mô tả GUI (Graphic User Interface) trong use case

Các bước khi mô tả trong use case sẽ ghi nhận ý định thực sự của actor chứ không phải các bước thao tác người dùng trên giao diện. Việc đưa các mô tả thao tác người dùng trên giao diện sẽ gặp những nhược điểm sau:

  • Tài liệu trở nên dài hơn không cần thiết
  • Một thay đổi nhỏ về mặt thiết kế giao diện sẽ phải thay đổi mô tả yêu cầu trong use case trong khi thực chất logic, luồng và mục tiêu của nghiệp vụ không thay đổi.
  • Việc thiết kế hay thay đổi trên giao diện sẽ do đội thiết kế (designer) đảm nhiệm và sẽ được mô tả trong một tài liệu khác không phải tài liệu use case. Trong cuốn Visual Model For Software Requirement bạn sẽ được biết tài liệu này là DAR (Display – Action – Response) mô tả giao diện người dùng, các tương tác trên giao diện và phản hồi từ hệ thống, các rule validation trên giao diện …

Hai khả năng xảy ra đối với một use case

Ghi nhớ luôn có 2 khả năng kết thúc: Thành công – Thất bại.

Use case là bản cam kết đối với Stakeholders

Use case không chỉ ghi lại các tương tác hiển thị công khai giữa các actor và hệ thống mà còn là bản thỏa thuận giữa các bên liên quan – stakeholders. Liệt kê các bên liên quan và các lợi ích của họ trong mỗi use case. Thông thường:

  • Lợi ích của Actor chính cũng chính là tên của use case – phản ánh lợi ích của actor.
  • Đối với công ty thì quan tâm giá trị mà hệ thống sẽ đem lại so với chi phí bỏ ra.
  • Đối với các cơ quan quản lý thị trường thì thường là đảm bảo rằng công ty có thể chứng minh rằng họ tuân theo các hướng dẫn, quy định về pháp lý … thông thường là thông qua các hệ thống log
  • Một số bên liên quan khác thì quan tâm tới cơ chế phục hồi của hệ thống khi giao dịch thất bại giữa chừng …

Điều kiện cần –Preconditions

Luôn mô tả điều kiện cần trước khi thực hiện use case. Các điều kiện này sẽ không cần kiểm tra trong use case.

Một số kỹ thuật đặt câu hỏi để kiểm tra xem use case đã được mô tả đầy đủ chính xác hay chưa

Field Question
Use case title Tên use case đã là dạng cụm động từ chủ động mô tả mục tiêu của actor chính?

Hệ thống có thể đáp ứng được mục tiêu đó không?

 
Scope and Level Thông tin scope và level đã đầy đủ?

Nếu đây là toàn bộ phạm vi của hệ thống cần thiết kế, liệu đã đủ đảm bảo đội thiết kế không phải thiết kế một cái gì đó khác nằm ngoài phạm vi trên không?

Nội dung usecase mô tả có khớp với cấp mục tiêu được nêu trong phần Cấp – level không?

Use case có được mô tả dưới dạng black-box hay white box phù hợp với cấp độ?

Mục tiêu của use case có thực sự phù hợp với cấp độ đề cập?

Primary actor Actor chính có tên được đề cập có hành vi được mô tả trong use case?

Actor chính này có mục tiêu trong hệ thống đang thiết kế không?

 
Preconditions Đây có phải là điều kiện bắt buộc và được đảm bảo bởi hệ thống đang thiết kế?

Có đúng là điều kiện này không bao giờ được kiểm tra trong use case hay không?

 
Stakeholders and
interests.
Họ có được đề cập đến trong use case?
Minimal guarantees Nếu có, tất cả lợi ích của các bên liên quan có được bảo vệ hay không?
Success guarantees Tất cả các bên liên quan có hài lòng, đạt được mục đích không?
Main success scenario Kịch bản chính có chạy từ khi được kích hoạt cho đến khi kết thúc thành công?

Trình tự các bước có đúng không?

Các bước mô tả trong use case có từ 3-9 bước không?

 
Extension condition Hệ thống có thể phát hiện ra trường hợp này không?

Hệ thống có phải xử lý nó?

 
Technology or Data
Variation List.
Có chắc đây không phải là một kịch bản mở rộng cho kịch bản chính của use case?

Ví dụ: Tại kịch bản chính (main scenario) mô tả:

2. Người dùng xác nhận danh tính với hệ thống ATM

….

Technology & Data Variations List:

2a.Sử dụng bank card, nhận diện vân tay, token …

Overall use case content Đây có phải là những gì các nhà tài trợ cho dự án muốn?”

Đội phát triển phần mềm có thể thực hiện được điều này?

 

Use case phát triển theo chiều rộng trước

Use case phát triển theo chiều rộng trước, chiều sâu sau. Từ tổng quan sau đó mới đến chi tiết. Kỹ thuật này rất có nhiều lợi ích. Ở từng giai đoạn của dự án tương ứng với từng đối tượng người dùng thì mức độ chi tiết của tài liệu sẽ được làm mịn dần. Việc này cũng giúp cho người viết use case dễ dàng quản lý năng lượng, công sức sẽ bỏ ra khi viết use case.

Chi tiết các trường dữ liệu

Không đưa vào trong use case mà nên đưa vào một tài liệu riêng biết và tham chiếu đến.

Có thể nói, cho dù cuốn sách đã được viết từ năm 2000 nhưng đây là cuốn sách đáng giá để dành thời gian ra đọc.

Thông tin vê tác giả cuốn sách: Sau khi tìm hiểu thì được biết tác giả cũng là một trong những người giúp viết ra bản tuyên ngôn của phương pháp phát triển phần mềm Agile năm 2001 Manifesto for Agile Software Development và rất nhiều cuốn sách nổi tiếng khác về agile development và software engineering.

https://en.wikipedia.org/wiki/Alistair_Cockburn

Download

Leave a Reply

Your email address will not be published. Required fields are marked *