Use Case Và Use Case Testing

--- Bài mới hơn ---

  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Viết Unit Test Cho Javascript Với Jasmine
  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Use case là một tài liệu mô tả từ đầu đến cuối hành vi của hệ thống từ góc nhìn của người sử dụng. Use case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (Actor) và hệ thống. Mỗi Use case sẽ mô tả cách thức người dùng tương tác với hệ thống để đạt được mục tiêu nào đó. Ngoài ra, Use case cũng xác định trình tự các bước mô tả mọi tương tác giữa người dùng và hệ thống. Tuy nhiên, Use case được định nghĩa theo thuật ngữ của người dùng, không phải của hệ thống, mô tả những gì mà người dùng làm và người dùng nhìn thấy hơn là những gì đầu vào hệ thống mong đợi và đầu ra của hệ thống là gì.

    Những thành phần của Use case

    1. Brief description: Mô tả ngắn gọn giải thích các trường hợp
    2. Actor: Người dùng hệ thống
    3. Precondition: Là các điều kiện được thỏa mãn trước khi bắt đầu thực hiện
    4. Basic flow: hay “Main Scenario” là những luồng cơ bản trong hệ thống. Đó là luồng giao dịch được thực hiện bởi người dùng để hoàn thành mục đích của họ. Khi người dùng tương tác với hệ thống, vì đó là workflow bình thường nên sẽ không có bất kì lỗi nào xảy ra và người dùng sẽ nhận được đầu ra như mong đợi.
    5. Alternate flow: Ngoài workflow thông thường, hệ thống cũng có thể có workflow thay thế. Đây là tương tác ít phổ biến hơn được thực hiện bởi người dùng với hệ thống
    6. Exception flow: Là các luồng ngăn cản người dùng đạt được mục đích của họ
    7. Post conditions: Các điều kiện cần được kiểm tra sau khi hoàn thành.

    Use case diagram

    Use case diagram là một sơ đồ biểu diễn bằng hình ảnh về các hành vi của người dùng trong một hệ thống, cách người dùng tương tác với hệ thống. Nó chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát giữa các đối tượng người dùng (Actors)

    • System: Nó có thể là một trang web, một ứng dụng hoặc bất kỳ component nào khác. Nó thường được biểu diễn bằng một hình chữ nhật. Nó chứa đựng các trường hợp sử dụng (Use case). Người dùng được đặt bên ngoài ‘hình chữ nhật’.
    • Use case: thường được biểu diễn bằng các hình bầu dục, chỉ định các hành động bên trong nó.
    • Actors: là những người sử dụng hệ thống. Nhưng đôi khi nó có thể là các hệ thống khác, người hoặc bất kỳ tổ chức nào khác.

    Use case testing là một kỹ thuật kiểm thử chức năng của kiểm thử hộp đen, vì thế chúng ta sẽ không cần quan tâm đến code. Nó giúp Tester xác định được các kịch bản kiểm thử được thực hiện trên toàn bộ hệ thống từ đầu đến cuối của mỗi giao dịch.

    Một vài đặc điểm của Use case testing

    • Use case testing không phải được thực hiện để quyết định chất lượng của phần mềm
    • Use case testing không đảm bảo bao phủ được toàn bộ ứng dụng của người dùng
    • Dựa trên kết quả kiểm thử từ Use case, chúng ta không thể quyết định việc triển khai môi trường của sản phẩm
    • Nó sẽ giúp tìm ra được những lỗi từ kiểm thử tích hợp

    Ví dụ về Use case testing

    Ví dụ với trường hợp kiểm tra điểm của sinh viên của hệ thống quản lý giáo dục

    Actors: Students, Teacher, Parents

    Pre-condition:

    1. Hệ thống phải có kết nối mạng Internet
    2. Người dùng phải có ‘Student ID’

    Qua bài viết này tôi hi vọng các bạn có thể hiểu rõ hơn về Use case và Use case testing. Viết Use case là một quá trình lặp lại. Bạn chỉ cần dành một chút thời gian để thực hành và cần có kiến thức tốt về hệ thống để thiết kế Use case. Tóm lại, chúng ta có thể sử dụng ‘Use Case testing’ trong một ứng dụng để tìm các liên kết còn thiếu, các yêu cầu không hoàn chỉnh… Tìm chúng và sửa đổi hệ thống sẽ đạt được hiệu quả và chính xác cho hệ thống.

    Nguồn: https://www.softwaretestinghelp.com/use-case-testing/

    All Rights Reserved

    --- Bài cũ hơn ---

  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Bản Vẽ Use Case (Use Case Diagram)
  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Bản Vẽ Use Case (Use Case Diagram)

    --- Bài mới hơn ---

  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Use Case Và Use Case Testing
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Trong bài trước chúng ta đã biết vai trò của bản vẽ Use Case là rất quan trọng, nó giúp chúng ta hiểu yêu cầu, kiến trúc chức năng của hệ thống và chi phối tất cả các bản vẽ còn lại. Trong bài này chúng ta sẽ tìm hiểu về các thành phần cấu tạo nên bản vẽ này, cách xây dựng và sử dụng nó.

    1. Các thành phần trong bản vẽ Use Case

    Đầu tiên, chúng ta xem một ví dụ về Use Case Diagarm.

    Bây giờ chúng ta sẽ tìm hiểu kỹ hơn về các thành phần của bản vẽ.

    1.1 Actor

    Actor được dùng để chỉ người sử dụng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống chúng ta đang xem xét. Lưu ý, chúng ta hay bỏ quên đối tượng tương tác với hệ thống, ví dụ như Bank ở trên.

    Actor được biểu diễn như sau:

    Use Case là chức năng mà các Actor sẽ sử dụng. Nó được ký hiệu như sau:

    1.3 Relationship(Quan hệ)

    Relationship hay còn gọi là conntector được sử dụng để kết nối giữa các đối tượng với nhau tạo nên bản vẽ Use Case. Có các kiểu quan hệ cơ bản sau:

    – Association

    – Generalization

    – Include

    – Extend

    1.4 System Boundary

    System Boundary được sử dụng để xác định phạm vi của hệ thống mà chúng ta đang thiết kế. Các đối tượng nằm ngoài hệ thống này có tương tác với hệ thống được xem là các Actor.

    2. Các bước xây dựng Use Case Diagram

    Chúng ta đã nắm được các ký hiệu của bản vẽ Use Case, bây giờ là lúc chúng ta tìm cách lắp chúng lại để tạo nên bản vẽ hoàn chỉnh. Thực hiện các bước sau để xây dựng một bản vẽ Use Case:

    + Bước 1: Tìm các Actor

    Trả lời các câu hỏi sau để xác định Actor cho hệ thống:

    – Ai sử dụng hệ thống này?

    – Hệ thống nào tương tác với hệ thống này?

    Xem xét ví dụ về ATM ở trên chúng ta thấy:

    Như vậy có 03 Actor: Customer, ATM Technician và Bank

    + Bước 2: Tìm các Actor

    Trả lời câu hỏi các Actor sử dụng chức năng gì trong hệ thống? chúng ta sẽ xác định được các Use Case cần thiết cho hệ thống.

    Xem xét ví dụ ở trên ta thấy:

    • Customer sử dụng các chức năng: Check Balance, Deposit, Withdraw và Transfer
    • ATM technician sử dụng: Maintenance và Repair
    • Bank tương tác với tất cả các chức năng trên.

    Tóm lại, chúng ta phải xây dựng hệ thống có các chức năng: Check Balance, Deposit, Withdraw, Transfer, Maintenance và Repair để đáp ứng được cho người sử dụng và các hệ thống tương tác.

    + Bước 3: Xác định các quan hệ

    Phân tích và các định các quan loại hệ giữa các Actor và Use Case, giữa các Actor với nhau, giữa các Use Case với nhau sau đó nối chúng lại chúng ta sẽ được bản vẽ Use Case.

    Nhìn vào bản vẽ trên chúng ta nhận biết hệ thống cần những chức năng gì và ai sử dụng. Tuy nhiên, chúng ta chưa biết được chúng vận hành ra sao? Sử dụng chúng như thế nào? Để hiểu rõ hơn hệ thống chúng ta cần phải đặc tả các Use Case.

    Có 2 cách để đặc tả Use Case.

    Cách 1: Viết đặc tả cho các Use Case

    Chúng ta có thể viết đặc tả Use Case theo mẫu sau:

    • Tên Use Case //Account Details
    • Mã số Use Case //UCSEC35
    • Mô tả tóm tắt// Hiển thị thông tin chi tiết của Account
    • Các bước thực hiện // Liệt kê các bước thực hiện
    • Điều kiện thoát // Khi người dùng kích nút Close
    • Yêu cầu đặc biệt// Ghi rõ nếu có
    • Yêu cầu trước khi thực hiện// Phải đăng nhập
    • Điều kiện sau khi thực hiện // Ghi rõ những điều kiện nếu có sau khi thực hiện Use Case này

    Cách 2: Sử dụng các bản vẽ để đặc tả

    Chúng ta có thể dùng các bản vẽ như Activity Diagram, Sequence Diagram để đặc tả Use case. Các bản vẽ này chúng ta sẽ bàn ở những bài tiếp theo.

    4. Sử dụng UseCase Diagram

    – Phân tích và hiểu hệ thống

    – Thiết kế hệ thống.

    – Làm cơ sở cho việc phát triển, kiểm tra các bản vẽ như Class Diagram, Activity Diagram, Sequence Diagram, Component Diagram.

    – Làm cơ sở để giao tiếp với khách hàng, các nhà đầu tư.

    – Giúp cho việc kiểm thử chức năng, kiểm thử chấp nhận.

    5. Kết luận

    Đến đây, chúng ta đã tìm hiểu được bản vẽ đầu tiên và rất quan trọng (use case diagram), các bạn cần tiếp tục thực hành để nắm rõ hơn về bản vẽ này cũng như cách xây dựng và sử dụng chúng trong quá trình phát triển sản phẩm phần mềm.

    Để giúp các bạn hiểu rõ hơn về bản vẽ Use Case trong bài tiếp theo chúng ta sẽ thực hiện qua từng bước bài thực hành xây dựng Use Case Diagram.

    Bài tiếp: Thực hành xây dựng bản vẽ Use Case

    Bài trước: Cơ bản về phân tích và thiết kế hướng đối tượng

    --- Bài cũ hơn ---

  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Unit Test Cho Nodejs Với Mocha
  • Viết Unit Test Trong C# Với Nunit
  • User Story Và Use Case

    --- Bài mới hơn ---

  • Test Javascript Code Với Jest
  • Tìm Hiểu Unit Testing Trongcore
  • Viết Thư Upu Quốc Tế
  • Bật Mí Cách Trình Bày Văn Bản Đẹp Trong Excel
  • Cách Viết Bài Essay Agree
  • Các lập trình viên thường có thói quen đi vào dự án và bắt đầu lập trình ngay. Họ nói với người dùng của mình rằng: “Tôi biết tất cả những gì mà bạn cần” khi nghe người dùng nói về yêu cầu của họ.

    Những phương pháp Agile chỉ ra rằng đó là một cái bẫy cho các lập trình viên. Agile cũng cho thấy những nhà phát triển phải làm việc với người dùng trong suốt dự án để hiểu người dùng cần gì nếu muốn tránh bẫy lỗi lập trình.

    Đó là lý do tại sao User Story là một trong những công cụ tốt nhất để triển khai theo phương pháp Agile.

    1. User Story là gì?

    Khái niệm User Story

    User Story còn được một số người gọi với cái tên là Scenario (kịch bản) để mô tả một yêu cầu từ người dùng.

    Hầu hết User Story được viết bằng ngôn ngữ của người dùng. Vì thế, bất kì người dùng nào cũng có thể đọc và hiểu ngay. User story thường gần gũi với từ ngữ thường ngày của người dùng.

    User Story thường được viết trên Card, giấy note, tài liệu Words, Excels… tùy dự án.

    2. Use Case là gì?

    Khái niệm Use Case

    Use case cũng có vài điểm gần giống như một User Story nhưng nó sẽ mô tả cách tương tác giữa người dùng và phần mềm. Use Case là một mô tả đầy đủ về tất cả những trường hợp mà người dùng sử dụng phần mềm sẽ gặp phải.  

    Qua đó, giúp người lập trình nắm bắt những cách giúp người dùng tương tác với phần mềm để đạt kết quả mong muốn. Đồng thời, loại bỏ những thao tác sai khiến người dùng không đạt kết quả khi sử dụng phần mềm.

    3. Sự giống và khác nhau giữa User Story và Use Case

    3.1 Giống nhau:

    Các User Story thường được bắt đầu giống như các Use Case. Mỗi User Story sẽ mô tả một cách sử dụng phần mềm, tập trung vào kết quả và đều được viết bằng ngôn ngữ người dùng.

    Cả User Story và Use Case đều sử dụng ngôn ngữ tự nhiên của của doanh nghiệp và chỉ kể một phần chứ không phải tất cả.

    3.2 Khác nhau:

    Mặc dù User Story và Use Case được định nghĩa khá giống nhau chúng vẫn có những khác biệt. Đảm nhận những vai trò khác nhau trong một dự án phần mềm và giúp dự án được vận hành tốt hơn.

    “Tính năng tìm kiếm và thay thế trong trình soạn thảo văn bản”

    Hãy so sánh một User Story cho chức năng tìm kiếm và thay thế bằng một Use Case với cùng tính năng sẽ giúp bạn hiểu được sự khác nhau.

    Không khó để tìm ra User Story cho ví dụ trên. Có rất nhiều cách để tìm ra User Story bạn có thể bắt đầu bằng cách viết ra một tấm thẻ (card) như sau:

    Ví dụ về chức năng tìm kiếm và thay thế User Story (Serch and Replace)

    Bây giờ, nếu bạn không quen với User Story, bạn có thể nghĩ rằng: “chức năng tìm kiếm và thay thế trong trình soạn thảo của tôi cần nhiều hơn thế”.Thông thường User Story sẽ không đủ thông tin để giúp người dùng hiểu được phần mềm sẽ cần gì.

    Còn đây là ví dụ về Use Case để bạn có thể hiểu được cách mà Use Case hoạt động:

     

     

    Nếu tôi là một nhà phát triển và đang xây dựng một trình soạn thảo, tôi có thể viết một chức năng tìm kiếm và thay thế theo một Use Case cụ thể như trên.

    Một vài điểm thú vị của Use Case đó là trong khi bạn đọc về ví dụ trên hẳn bạn đang nghĩ về thứ gì đó giống như khung tìm kiếm và thay thế (Replace dialog) trong Notepad hoặc Microsoft Word.

    Chức năng tìm kiếm và thay thế của Microsoft Word

    Và có rất nhiều cách khác nhau để bạn xây dựng phần mềm để thực hiện Use Case. Bạn đã từng sử dụng chức năng tìm kiếm và thay thế trong Word hoặc Notepad chưa? Chúng có gì khác nhau?

    Chức năng tìm kiếm và thay thế của Notepad++

    Có rất nhiều điểm khác biệt giữa chúng về giao diện, cách sử dụng… Tuy nhiên, nếu bạn so sánh chúng với Use Case trong ví dụ trên, bạn sẽ thấy rằng chúng đều đi theo cùng diễn biến của những sự kiện cơ bản.

    • User Story là những gì cần thiết:

    User Story thường được viết trên Cards

    Khi bạn viết một User Story, những gì bạn mô tả là nhu cầu của người dùng. Một điều gì đó mà người dùng cần để thực hiện công việc của họ mà nếu bạn không tạo ra phần mềm cho họ thì điều đó sẽ tồn tại mãi.

    Chẳng hạn trong ví dụ trên là chức năng tìm kiếm và thay thế. Nếu không có phần mềm người dùng sẽ phải tìm và thay thế một cách thủ công, mất nhiều thời gian và không hiệu quả.

    • Use Case là cách mà phần mềm sẽ tương tác đối với yêu cầu của người dùng:

    Một nhà phát triển phần mềm cần khả năng đọc một Use Case và hiểu phần mềm cần làm gì. Có rất nhiều chi tiết và mô tả mọi thứ mà người phát triển cần xây dựng để đáp ứng nhu cầu người dùng.

    Đó là lý do tại sao Use Case cần được chi tiết, rõ ràng và không mơ hồ. Bạn có thể thấy Use Case trong ví dụ trên được viết chi tiết từng bước thao tác người dùng và cách mà phần mềm phản hồi.

    • User Story phải dễ đọc và hiểu đối với người dùng:

    Cấu trúc thường có của 1 user story

    Khi bạn viết một User Story, điều bạn cần tập trung là làm cách nào để bất kì ai cũng có thể đọc hiểu. User Story cần được mô tả một cách đầy đủ trong vài câu, đó là lý do vì sao User Story thường là một bảng tóm tắt và được viết trong những tấm thẻ, giấy note, ghi chú…

    • Use Case sẽ mô tả một đầy đủ về cách phần mềm tương tác với người dùng:

    Khi bạn lên danh sách các Use Case, điều bạn cần làm chính là đưa ra một giải pháp về chức năng phần mềm cho nhu cầu của người dùng. Nó phải là một giải pháp mà những người phát triển có thể triển khai khi xây dựng phần mềm.

    Một User Story có thể có nhiều Use Case và khi bạn tập hợp tất cả Use Case vào một tài liệu. Lúc đó, bạn sẽ có một tập hợp đầy đủ mô tả những tương tác giữa người dùng với phần mềm mà bạn sẽ làm.

    Và nếu phần mềm của bạn phải tương tác với nhiều hệ thống, bạn có thể xem các hệ thống như là những người dùng trong Use Case.

    Để hiểu rõ hơn về user story và use case trong quá trình sử dụng bạn có thể tham gia khóa đào tạo phân tích nghiệp vụ phần mềm của BAC.

    Nguồn:

    Tham khảo bài viết: Phân biệt User Scenirio, User Story và Use Case

    CÁC KHOÁ HỌC BUSINESS ANALYST chúng tôi DÀNH CHO BẠN

    Khoá học Online:

    Khoá học Offline:

    Tại Tp.HCM:

    Tại Hà Nội:

    Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất. 

    BAN BIÊN TẬP NỘI DUNG BAC

    --- Bài cũ hơn ---

  • Cách Viết Content Quảng Cáo Facebook Giúp Tăng Đơn Hàng
  • Từ Điển Phương Trình Hóa Học
  • Mẫu Offer Letter Tiếng Anh Chuẩn Nhất
  • Ielts Writing Task 1
  • 07 Bí Quyết Để Viết Kịch Bản Video Quảng Cáo Thành Công
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn

    --- Bài mới hơn ---

  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Viết Unit Test Cho Javascript Với Jasmine
  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Unit Test Là Gì? 10 Frameworks Unit Test Cho Javascript
  • 1. Khái niệm use case quản lý khách sạn

    Use case là một kỹ thuật được dùng trong kỹ thuật phần mềm của hệ thống quản lý khách sạn nhằm nắm bắt yêu cầu chức năng của hệ thống. Nó mô tả các thao tác đặc trưng từ người dùng bên ngoài (actor) vào hệ thống.

    2. Mô hình sơ đồ use case quản lý khách sạn

    a. Tại Bộ phận Lễ tân

    b. Tại Bộ phận Kế toán

    c. Tại Bộ phận Kinh doanh

    d. Tại Bộ phận Nhân sự

    3. Đặc tả use case quản lý khách sạn

    a. Use case quản lý đăng nhập

    + Hệ thống yêu cầu actor cung cấp thông tin đăng nhập gồm tên đăng nhập và mật khẩu.

    + Hệ thống check lại thông tin đăng nhập và thông báo thành công/thất bại cho actor. Nếu đăng nhập thành công hệ thống dựa trên thông tin đăng nhập sẽ đồng thời phân quyền tùy theo loại nhân viên. Nếu đăng nhập thất bại, hệ thống sẽ hiện thông báo cho người dùng và yêu cầu đăng nhập lại.

    b. Use case Đăng xuất

    + Actor thực hiện chức năng đăng xuất khỏi hệ thống.

    + Hệ thống hiển thị yêu cầu xác nhận từ actor

    + Actor dùng xác nhận đăng xuất

    + Hệ thống đăng xuất tài khoản actor khỏi hệ thống. Nếu Actor không xác nhận đăng xuất thì hệ thống sẽ giữ nguyên hiện trạng.

    c. Use case Đặt phòng

    + Bộ phận Lễ tân đăng nhập vào hệ thống

    + Chọn chức năng đặt phòng cho khách hàng

    + Hệ thống hiển thị form yêu cầu nhập thông tin khách hàng và ngày nhận phòng. Bao gồm: Số CMND; Họ tên; Địa chỉ; SĐT.

    + Bộ phận lễ tân nhập thông tin và ngày nhận phòng của khách đầy đủ theo form

    + Hệ thống tự động kiểm tra thông tin phòng ngày mà khách hàng yêu cầu, đồng thời lọc danh sách các loại phòng và các phòng tương ứng mà khách hàng có thể thuê vào ngày đó.

    TH1: Còn loại phòng mà khách hàng yêu cầu:

    + Lễ tân chọn phòng theo yêu cầu của khách hàng đã đặt.

    + Hệ thống kiểm tra dữ liệu lễ tân vừa nhập và lưu lại thông tin đặt phòng của khách. Nếu thông tin khách hàng đã tồn tại trong hệ thống thì sẽ không lưu thông tin khách hàng nữa mà chỉ lưu thông tin đặt phòng.

    TH2: Loại phòng mà khách hàng yêu cầu đã hết phòng trống:

    + Hệ thống sẽ báo hết loại phòng đã chọn và cảnh báo để yêu cầu chọn loại phòng khác.

    + Lễ tân sẽ thông báo cho khách và tiếp tục tìm kiếm loại phòng khác hoặc thời gian khác nếu khách hàng yêu cầu. Nếu khách hàng không còn nhu cầu thực hiện hủy phiếu đăng ký.

    + Hệ thống thông báo và yêu cầu thực hiện lại.

    d. Use case kiểm tra tình trạng phòng

    + Actor đăng nhập vào hệ thống

    + Actor chọn chức năng “Đặt phòng” hoặc “Thuê phòng” với một phòng.

    + Hệ thống sẽ tìm kiếm thông tin phòng dựa vào mã phòng và phản hổi lại tình trạng hiện tại của phòng (đang ở, đã được đặt trước hoặc còn trống)

    + Kết thúc use case

    e. Use case tìm thông tin đặt phòng

    + Lễ tân thực hiện chức năng đăng ký phòng đặt trước, chọn chức năng “Tìm thông tin đặt phòng”

    + Lễ tân nhập số CMND của khách hàng để tiến hành tìm thông tin đặt phòng.

    + Hệ thống tìm kiếm thông tin đặt phòng của khách hàng và trả về kết quả

    f. Use case Lập phiếu dịch vụ

    + Bộ phận lễ tân đăng nhập hệ thống và chọn chức năng lập phiếu dịch vụ.

    + Hệ thống sẽ tạo ra phiếu dịch vụ ứng với thông tin nhận phòng tương ứng và hiển thị thông tin ra để lễ tân xem, đồng thời yêu cầu lễ tân chọn các dịch vụ mà khách hàng yêu cầu.

    + Hệ thống lưu lại phiếu sử dụng dịch vụ, đồng thời lưu thông tin chi tiết xuống “Chi tiết phiếu dịch vụ”.

    + Kết thúc Use case.

    + Lưu thông tin phiếu sử dụng dịch vụ của khách hàng vào hệ thống nếu use case thực hiện thành công.

    g. Use case Thống kê doanh thu

    + Nhân viên kế toán đăng nhập hệ thống và chọn nút “Thống kê”

    + Hệ thống hiển thị menu thống kê: theo ngày, theo tháng, theo quý, theo năm.

    + Nhân viên kế toán chọn một trong các mục.

    + Hệ thống sẽ thống kê và in ra giấy.

    --- Bài cũ hơn ---

  • Use Case Và Use Case Testing
  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Bản Vẽ Use Case (Use Case Diagram)
  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?

    --- Bài mới hơn ---

  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Bản Vẽ Use Case (Use Case Diagram)
  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Use Case Và Use Case Testing
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Ô kayyyy lét xờ gâuuuu 😎

    Giả dụ trường hợp ở đây: Anh em đã có Use Case Diagram, đã capture được tổng quan các requirement theo góc nhìn của người dùng. Đó là thứ để chúng ta bỏ vào các document như FRD hoặc SRS.

    Tuy nhiên, Use Case Diagram khá là chung chung để các stakeholders có cái nhìn trực quan về những requirements được mô tả. Do đó, anh em cần phải diễn đạt nó một cách chi tiết hơn nữa.

    Use Case Specification, hay nói cách khác là ĐẶC TẢ USE CASE sẽ giúp anh em làm chuyện đó.

    Đặc tả Use Case tồn tại dưới dạng một cái bảng ghi chú. Nó mô tả tất tần tật các thông tin về Use Case, giúp anh em đọc vào một phát là hiểu ngay Use Case Diagram nó vẽ vậy là ý gì.

    Một cách tổng quan, Use Case Specification gồm 3 thành phần chính:

    • Use Case Name: Tên Use Case
    • Use Case ID: Mã Use Case
    • Use Case Description: Tóm gọn nhanh sự tương tác được thể hiện trong Use Case là gì.
    • Actor: Những đối tượng thực hiện sự tương tác trong Use Case.
    • Priority: Mức độ ưu tiên của Use Case so với các Use Case còn lại trong dự án.
    • Trigger: Điều kiện kích hoạt Use Case xảy ra.
    • Pre-Condition: Điều kiện cần để Use Case thực hiện thành công.
    • Post-Condition: Những thứ sẽ xuất hiện sau khi Use Case được thực hiện thành công.
    • Basic Flow: luồng tương tác CHÍNH giữa các Actor và System để Use Case thực hiện thành công.
    • Alternative Flow: luồng tương tác THAY THẾ giữa các Actor và System để Use Case thực hiện thành công.
    • Exception Flow: luồng tương tác giữa các Actor và System mà Use Case thực hiện thất bại.
    • Business Rule: các quy định về mặt Business mà hệ thống bắt buộc phải nghe theo, làm theo.
    • Non-Funtional Requirement: Vì Use Case chỉ dùng để thể hiện Functional Requirement, nên anh em phải bổ sung các yêu cầu về Non-Functional ở đây luôn.

    …………………………………………………………………..

    Một số thông tin bổ sung thêm cho anh em.

    Use Case Description chỉ cần mô tả ngắn gọn theo cú pháp của User Story: Là “Actor”, tui muốn làm “Use Case Name”, để đạt được “mục đích – lý do” gì đó. Đẹp là không quá 3 dòng cho phần tóm gọn Use Case này.

    Ví dụ đối với diễn đàn Medium đi chẳng hạn. Chúng ta sẽ vẽ Use Case Diagram và viết đặc tả Use Case cho phân hệ quản lý xác thực người dùng như sau.

    USE CASE SPECIFICATION

    Pre-Condition(s):

    • Tài khoản người dùng đã được tạo sẵn
    • Tài khoản người dùng đã được phân quyền
    • Thiết bị của người dùng đã được kết nối internet khi thực hiện đăng nhập

    Post-Condition(s):

    • Người dùng đăng nhập ứng dụng thành công
    • Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.

    Basic Flow

    1. Người dùng truy cập ứng dụng Medium.

    2. Người dùng chọn phương thức đăng nhập bằng tài khoản Medium

    3. Người dùng nhập tài khoản Medium và chọn lệnh đăng nhập

    4. Hệ thống xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng

    5. Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.

    Alternative Flow

    2a. Người dùng chọn phương thức đăng nhập bằng tài khoản Gmail

    2a1. Hệ thống chuyển sang màn hình đăng nhập của Google

    3a. Người dùng nhập tài khoản Google và chọn lệnh đăng nhập

    4a. Google xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng

    Use Case tiếp tục bước 5.

    2b. Người dùng chọn phương thức đăng nhập bằng tài khoản Facebook

    2b1. Hệ thống chuyển sang màn hình đăng nhập của Facebook

    3b. Người dùng nhập tài khoản Facebook và chọn lệnh đăng nhập

    4b. Facebook xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng

    Use Case tiếp tục bước 5.

    Exception Flow

    4c. Hệ thống xác thực thông tin đăng nhập không thành công và hiển thị thông báo.

    4c1. Người dùng chọn lệnh hủy đăng nhập.

    Use Case dừng lại.

    4c2. Người dùng chọn lệnh lấy lại mật khẩu

    Use Case tiếp tục Use Case UC1-3

    4c3. Người dùng chọn lệnh khóa tài khoản

    Use Case tiếp tục Use Case UC1-4

    Non-Functional Requirement

    NFR1.1-1: Time out cho màn hình đăng nhập dưới 60 giây.

    NFR1.1-2: Mật khẩu của người dùng phải được hash bằng MD5.

    Đó là đặc tả Use Case. Hi vọng ví dụ này đủ để anh em hình dung, mường tượng ra được chân tay mặt mũi của Use Case Specification.

    Anh em có thể làm một Use Case Specification cho một Use Case (tức một hình Oval). Vậy ở ví dụ trên thì anh em sẽ có 1 sơ đồ Use Case Digram, gồm 5 Use Case, thì sẽ ứng với 5 Use Case Specification.

    Tuy nhiên, có thể anh em sẽ thấy confuse ở một số chỗ…

    Thường khi làm đặc tả Use Case mình sẽ rất dễ bị nhầm lẫn ở hai chỗ:

    • Trigger và Pre-Condition
    • Alternative Flow và Exception Flow.

    4.1. Trigger và Pre-Condition

    Trigger nghĩa là một thứ gì đó để kích hoạt cho Use Case chạy, khởi xướng cho Use Case chạy. Còn Pre-Condition nghĩa là một thứ gì đó, mà phải có nó thì Use Case mới chạy được.

    Use Case có thể có Pre-Condition hoặc không, nhưng Trigger thì thường phải có.

    Ví dụ Use Case rút tiền tại máy ATM.

    Tức Use Case chỉ xảy ra khi ông khách hàng này ổng thực hiện lệnh rút tiền. Cụ thể thì có thể là ổng bấm cái nút “Rút tiền” trên màn hình. Đó là trigger để Use Case xảy ra.

    Còn Pre-Condition là các điều kiện cần phải có để ông này ổng rút tiền thành công. Vì ổng không thể nào rút tiền được nếu trong tài khoản không còn tiện hoặc ổng chưa đút thẻ vô máy.

    Hoặc Output (hoặc Post-Condition) của Use Case này có thể là trigger của Use Case khác.

    Cũng ở ví dụ rút tiền tại máy ATM bên trên, Post-Condition ở đây có thể là:

    • Khách hàng nhận được tiền mặt sau khi thực hiện rút tiền.
    • Số dư của khách hàng đã bị trừ đi khoảng tiền đã rút.

    Nếu những post-conditions này xảy ra thì Use Case: Rút tiền tại máy ATM đã được thực hiện xong. Và đồng thời nó cũng là trigger cho Use Case tiếp theo: Gửi tin nhắn SMS thông báo cho khách hàng.

    Để phân biệt rõ hơn giữa Trigger và Pre-Condition thì anh em cứ tưởng tượng như thế này…

    Trong giải điền kinh xóm chiếu mở rộng, ông Tèo là trọng tài, ông Tủn là vận động viên thi đấu. Cả 2 ông này đều là Actor. Một ông là Actor ở vai trò trọng tài, còn một ông là Actor ở vai trò vận động viên tham dự.

    Use Case thì thể hiện sự tương tác của Actor trong một môi trường/ phạm vi cụ thể nào đó. Vậy ở đây, Use Case thể hiện sự tương tác chạy đua trong một giải điền kinh, mà cả Actor trọng tài và Actor vận động viên đều tham gia vào.

    Vậy thì đâu là Trigger, và đâu là Pre-Condition?

    Trigger chính là cò nổ của ông Tèo trọng tài. Ổng giơ súng lên trời, bắn cái đùng, là ông Tủn vận động viên bắt đầu chạy. Hay nói cách khác, khi cò nổ, thì là lúc Use Case bắt đầu.

    Còn Pre-Condition là những điều kiện tiên quyết mà ông Tủn phải ô kê hết thì mới cho ổng tham dự giải đấu, ví dụ:

    Ví dụ vậy, không đạt được những điều kiện này, ông Tủn không được phép tham gia chạy ở giải điền kinh xóm chiếu mở rộng. Hay nói cách khác, không đạt được những điều kiện này, Use Case sẽ không được thực hiện thành công.

    Đó là sự khác biệt giữa Trigger và Pre-Condition.

    Tuy nhiên thực tế thì anh em cũng không cần quá quan tâm vấn đề này làm gì. Trigger trong Use Case có thể là bất kỳ thứ gì, có thể là tác động từ phía người dùng, hoặc tác động từ chính hệ thống. Miễn nó thể hiện được hình ảnh cò nổ để Use Case chạy là được.

    4.2. Alternative Flow và Exception Flow

    Flow là các luồng tương tác giữa các Actor và hệ thống với nhau. Basic Flow là luồng tương tác chính, là happy case đơn giản nhất có thể xảy ra.

    Ví dụ chạy từ Quận 1 ra Quận 7 thì cứ men theo Cách Mạng Tháng 8 ra Hoàng Diệu, rồi cứ cắm đầu Nguyễn Văn Linh là ra. Đó chính là Basic Flow, là đường ngắn nhất, cơ bản nhất.

    Nhưng thực tế còn rất nhiều đường khác mà anh em có thể đi: như quẹo qua Quận 8, đi Võ Văn Kiệt, Phạm Thế Hiển…. Hoặc thậm chí đi giữa đường xe bị lủng bánh, không có chỗ vá, phải dắt bộ ngược zề, và không qua được Quận 7 nữa, chuyến đi thất bại.

    Những trường hợp đó mình sẽ gom hết lại, và quy nó thành Alternative Flow hoặc Exception Flow. Cụ thể:

    • Alternative Flow: những hướng khác giúp anh em đi từ Quận 1 tới Quận 7 thành công, như các tuyến đường khác chẳng hạn.
    • Exception Flow: những trường hợp mà nó ngăn chặn, khiến cho anh em không qua Quận 7 được, làm kế hoạch qua Quận 7 mình bị thất bại, như: lủng xe, hết xăng, bị công an giam xe…

    Vậy xét qua lăng kính Use Case, đặc tính của 3 luồng tương tác này như sau:

    Ví dụ trong mô hình quản lý e-Learning, anh em có một Use Case: Hủy kích hoạt tài khoản học viên chẳng hạn. Use Case này sẽ có các Flow như sau.

    1. Admin mở tài khoản học viên cần hủy kích hoạt
    2. Hệ thống hiển thị màn hình thông tin học viên

    3. Admin chọn lệnh hủy kích hoạt

    4. Hệ thống yêu cầu nhập mã OTP để xác nhận

    5. Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt

    6. Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt

    7. Hệ thống hiển thị thông báo đã hủy kích hoạt.

    1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên.

    Use Case tiếp tục bước 3.

    4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha

    4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận

    5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt

    6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạt

    Use Case tiếp tục bước 7.

    5b. Admin nhập sai mã reCaptcha.

    5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.

    Use Case dừng lại.

    5c. Admin nhập sai mã OTP.

    5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.

    Use Case dừng lại.

    Đối với luồng chính (Basic Flow), anh em sẽ đánh số thứ tự xuất hiện 1, 2, 3, 4, 5…., theo số nguyên. Còn đối với Alternative hay Exception Flow, anh em nên thêm các ký tự chữ cái a, b, c, d… bên cạnh để làm dấu cho dễ phân biệt.

    Và để dễ hình dung và quản lý các steps có trong flow hơn, mình sẽ bonus thêm cho anh em phần sau đây, kaka 😎

    4.3. Bonus: Mô tả Flow sao cho ngầu

    Mình cá là 69% anh em lần đầu viết flow cho use case sẽ thấy hơi… rối bời, và không biết tổ chức các steps sao cho logic hết.

    Để giải quyết vấn đề này, hãy vẽ nó. Một lần nữa, việc vẽ lên ngôi.

    Dùng chữ khó quá thì chúng ta phải dùng hình. Anh em sẽ thể hiện Basic Flow, Alternative Flow và Exception Flow kèm hình vẽ như sau.

    BASIC FLOW

    1. Admin mở tài khoản học viên cần hủy kích hoạt

    2. Hệ thống hiển thị màn hình thông tin học viên

    3. Admin chọn lệnh hủy kích hoạt

    4. Hệ thống yêu cầu nhập mã OTP để xác nhận

    5. Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt

    6. Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt

    7. Hệ thống hiển thị thông báo đã hủy kích hoạt.

    ALTERNATIVE FLOW

    1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên.

    Use Case tiếp tục bước 3.

    4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha

    4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận

    5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt

    6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạt

    Use Case tiếp tục bước 7.

    EXCEPTION FLOW

    5b. Admin nhập sai mã reCaptcha.

    5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.

    Use Case dừng lại.

    5c. Admin nhập sai mã OTP.

    5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.

    Use Case dừng lại.

    Đó là những gì mình dùng để mô tả Flow, một cách rõ ràng, logic và sáng sủa nhất có thể.

    Các step ở Basic Flow, Alternative Flow hay Exception Flow nó đều đối xứng với nhau, thể hiện rõ thằng nào là thay thế của thằng nào, và thằng nào là Exception của thằng nào.

    Riêng luồng tương tác nào Exception thì anh em để dạng nét đứt cho dễ phân biệt.

    Các step bắt đầu (có thể là Trigger hoặc không) và kết thúc anh em hãy tô màu đen, để các Stakeholder có thể nắm được độ phức tạp của Use Case một cách nhanh nhất.

    Còn đối với các Exception Flow – những flow làm fail Use Case, anh em hãy tô đỏ các step cuối cùng mà Use Case xảy ra không thành công (chẳng hạn step 5b1 hoặc 5c1).

    .

    .

    .

    TÓM GỌN

    Đặc tả Use Case về bản chất rất đơn giản vì nó mang ngôn ngữ tự nhiên của người dùng. Vấn đề chỉ nằm ở một số điểm hay nhầm lẫn và cách chúng ta tổ chức các Use Case như thế nào cho logic và hiệu quả mà thôi 🙂

    Mình sẽ tóm gọn giá trị của Use Case (cả Diagram và Specification) qua 2 bài notes về Use Case như sau:

    1. Use Case giúp anh em thể hiện được rõ Requirement theo góc nhìn của người dùng cuối (rất quan trọng, vì nó giúp mình hiểu rõ bản chất vấn đề hơn).
    2. Theo đó, những gì được thể hiện trong Use Case rất tự nhiên, ai đọc vô cũng hiểu hết trơn.
    3. Use Case có thể chia nhỏ phạm vi theo nhiều phân hệ, hoặc cụm tính năng. Và nó cũng có thể nhìn dưới góc độ high-level. Do đó, dễ hơn cho mình rất nhiều để cover đủ các yêu cầu trong một dự án lớn.
    4. Use Case là bước đệm tuyệt vời giữa việc mô tả tổng quát mô tả chi tiết sự tương tác thông qua Sequence Diagram (con nhà UML).
    5. Use Case được dùng để tạo các Epic, và các User Stories trong dự án Scrum, làm mọi thứ được nhất quán và rất chặt chẽ.
    6. Use Case còn được dùng để tạo các Test Case sau này.

    Bái bai và hẹn gặp lại 😎

    --- Bài cũ hơn ---

  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Unit Test Cho Nodejs Với Mocha
  • Viết Unit Test Trong C# Với Nunit
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • Use Case Diagram Và 5 Sai Lầm Thường Gặp

    --- Bài mới hơn ---

  • Use Case Và Use Case Testing
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Viết Unit Test Cho Javascript Với Jasmine
  • Hê lô anh em. Ở kỳ trước mình đã nói về BPMN – một đồ nghề khá hữu dụng của BA. Hôm nay mình sẽ tiếp tục nói về 1 trong những đồ nghề khác cũng cực kỳ quan trọng không kém, đó chính là Use Case.

    Bản thân mình thời gian đầu dùng Use Case cũng gặp rất nhiều khó khăn. Một mớ bồng bông câu hỏi cứ lởn quởn trong đầu: bản chất của Use Case là gì, dùng cho mục đích nào, vẽ vậy đúng hay chưa, có chi tiết quá không, hoặc thậm chí vẽ Use Case xong cũng chẳng biết để làm gì???

    Use Case là kỹ thuật dùng để mô tả sự tương tác giữa người dùng và hệ thống với nhau, trong một môi trường cụ thể và vì một mục đích cụ thể.

    Sự tương tác ở đây có thể là:

    • Người dùng tương tác với hệ thống như thế nào?
    • Hoặc, hệ thống tương tác với các hệ thống khác như thế nào?

    Và dĩ nhiên, sự tương tác này phải nằm trong một môi trường cụ thể, tức là nằm trong một bối cảnh, phạm vi chức năng cụ thể, hoặc rộng hơn là trong một hệ thống/ phần mềm cụ thể.

    Sau cùng, việc mô tả sự tương tác này phải nhằm diễn đạt một mục đích cụ thể nào đó. Use Case phải diễn rả được Requirement theo góc nhìn cụ thể từ phía người dùng.

    Ví dụ sơ đồ Use Case diễn tả sự tương tác giữa người dùng là độc giả với trang blog Thinhnotes chẳng hạn.

    • Tương tác ở đây là gì?

      1. Độc giả đọc bài notes
      2. Độc giả yêu thích bài notes
      3. Độc giả chia sẻ bài notes
      4. Độc giả nhận xét bài notes
      5. Độc giả gửi bài notes cho độc giả khác qua email
    • Môi trường cụ thể?

      Quá đơn giản, đó là trang blog chúng tôi (không phải trang Admin).

    • Mục đích cụ thể?

      1. Người dùng có thể đọc được bài notes trên blog (đơn giản bỏ qua)
      2. Người dùng có thể bày tỏ được sự yêu thích bài notes
      3. Người dùng có thể chia sẻ bài notes này trên các nền tảng khác để nhiều người khác có thể đọc được
      4. Người dùng có thể viết nhận xét khen chê gạch đá các kiểu cho tác giả
      5. Người dùng có thể gửi bài notes này qua email cho một người bất kỳ.

    Đó là tất tần tật những nội dung mà một Use Case sẽ thể hiện.

    Về hình thức thì Use Case tồn tại ở 2 dạng:

    • Hình vẽ Use Case (Use Case Diagram)
    • Đặc tả Use Case (Use Case Specification).

    Use Case Diagram là một thành viên trong họ UML (Unified Modeling Language).

    Mỗi Diagram trong bộ UML này đều có những mục đích khác nhau. Tùy trường hợp, tùy dự án mà anh em sẽ “rút hàng” ra chiến như thế nào cho hợp lý.

    2.1. Actor, Use Case, Communication Link và Boundary

    Cũng không có gì quá phức tạp, Use Case Diagram gồm 5 thành phần chính:

    • Actor
    • Use Case
    • Communication Link
    • Boundary of System
    • Và, Relationships.

    Actor thì có thể là Người dùng, hoặc một System nào đó. Vì UML quy định Actor là hình thằng người nên có thể anh em sẽ nhầm lẫn chỗ đó phải là người dùng nhưng hổng phải.

    Một số câu hỏi anh em có thể tự lẩm bẩm trong đầu để xác định Actor như sau:

    • Ai là người sử dụng hệ thống?
    • Ai sẽ là người Admin của hệ thống (tức người cài đặt, quản lý, bảo trì… hệ thống)?
    • Hệ thống này có được sử dụng bởi bất kỳ một hệ thống nào khác không? (*)
    • Hệ thống lưu trữ dữ liệu, vậy ai là người input dữ liệu vào hệ thống?
    • Hệ thống lưu trữ dữ liệu, vậy ai là người cần những dữ liệu output?

    Ở mục (*), mình muốn highlight cho anh em chỗ này. Không phải giải pháp/ phần mềm nào làm ra đều được sử dụng bởi con người. Có những phần mềm làm ra, để cho… phần mềm khác sử dụng.

    Chẳng hạn như làm các services. Mình có một anh bạn làm BA, giải pháp mà ảnh cùng đồng bọn làm ra là 1 services không được dùng bởi con người, mà được dùng bởi một hệ thống khác để xác thực người dùng.

    Còn Use Case là anh em sẽ thể hiện dưới dạng hình Oval, thể hiện sự tương tác giữa các Actor và hệ thống.

    Communication Link thể hiện sự tương tác giữa Actor nào với System. Nối giữa Actor với Use Case.

    Boundary of System là phạm vi mà Use Case xảy ra. Ví dụ trong hệ thống CRM, phạm vi có thể là từng cụm tính năng lớn như Quản lý khách hàng, Quản lý đơn hàng, hoặc cả một module lớn như Quản lý bán hàng.

    Ô kê nãy giờ dễ ẹc, mấy cái này nhìn sơ qua là anh em biết ngay cái một.

    Cái cuối cùng mới chính là cái mà mình tin là nhiều anh em vẫn còn rất dễ lộn, đó là Relationship.

    2.2. Relationship

    Relationship gồm 3 loại: Include, Extend, và Generalization.

    Include nghĩa là mối quan hệ bắt buộc phải có giữa các Use Case với nhau.

    Xét về nghĩa, Include nghĩa là bao gồm, tức nếu Use Case A có mối quan hệ include Use Case B, thì nghĩa là: Use Case A bao gồm Use Case B. Để Use Case A xảy ra, thì Use Case B phải đạt được.

    Xét ví dụ trên, chúng ta có Use Case: Nhận xét bài notes. Use Case này include 2 Use Case khác là: Đăng nhập WordPressSoạn thảo nhận xét.

    Rõ ràng anh em thấy: để nhận xét được một bài viết, anh em cần phải đăng nhập vào 1 tài khoản nào đó, để blog nhận diện anh em là ai, tên gì, quê quán, giai gái ra sao.

    Ví dụ ở blog mình là anh em sẽ cần đăng nhập vào tài khoản WordPress. Sau khi đăng nhập xong, anh em phải soạn thảo nhận xét, tức là gõ nhận xét, chỉnh sửa, xóa tới xóa lui. Sau khi viết xong nhận xét, anh em sẽ bấm nút Submit để hoàn thành chẳng hạn.

    Chỉ khi nào xong 2 bước trên ( đăng nhậpsoạn thảo nhận xét), thì anh em mới có thể xong bước Nhận xét bài notes được.

    Hay nói cách khác để Use Case: Nhận xét bài notes xảy ra, thì Use Case: Đăng nhập WordPressUse Case: Soạn thảo nhận xét phải bắt buộc hoàn thành trước tiên.

    Một số điểm cần chú ý khi vẽ Include cho Use Case

    Thực sự không có quy tắc nào rõ ràng cho việc khi nào cần tách Use Case ra thành các Use Case nhỏ và cho nó một mối quan hệ Include cả.

    Việc tách hay không tách phụ thuộc duy nhất vào người vẽ. Và lý do lớn nhất để mối quan hệ Include ra đời là giúp cho các Use Case của chúng ta DỄ QUẢN LÝ hơn; làm cho Use Case Diagram trông có vẻ nguy hiểm hơn mà thôi 😎

    Và anh em chỉ nên tách Use Case khi nó có độ phức tạp lớn và những thứ tách ra được có thể được tận dụng ở các Use Case sau này.

    Độ phức tạp lớn thì khi tách ra mình mới có được những Use Case vừa phải, đủ để diễn đạt dễ hiểu cho các stakeholders. Còn tận dụng được ở các Use Case sau là sao?

    Ví dụ Use Case A gồm 2 Use Case nhỏ bên trong là X và Y. Do đó Use Case A được tách thành Use Case X và Use Case Y.

    Tương tự, Use Case B gồm Use Case Y bên trong, nên được tách thành Use Case Y.

    Nhưng, Use Case C gồm Use Case X và Use Case Z bên trong, nhưng chỉ có Use Case X là được tách ra cho mối quan hệ Include. Vì có thể Use Case Z “không đáng” để tách ra thành một Use Case nhỏ hơn.

    Chúng ta tách Use Case X từ Use Case A để Use Case C có thể tận dụng được mà không cần vẽ lại. Tương tự, tách Use Cas Y từ Use Case B để Use Case A có thể tận dụng mà cũng không cần vẽ lại.

    Điều này giúp Use Case Diagram của chúng ta trở nên chặt chẽ, logic gọn nhẹ hơn rất nhiều.

    Còn Use Case Z, vì nó không được “dùng lại” ở một Use Case bất kỳ nào sau đó, nên người vẽ có thể cân nhắc có tách nó ra hay không!

    Nếu Use Case đó đủ lớn và khá là high-level, thì có lẽ chúng ta nên tách. Còn nếu ngược lại, Use Case đã rõ ràng, là một requirement từ phía User cụ thể thì không đáng để anh em tách nó ra thành một Use Case nhỏ, chỉ làm hình thêm thêm rối mà thôi.

    Extend là mối quan hệ mở rộng giữa các Use Case với nhau.

    Nếu Include là mối quan hệ bắt buộc, thì Extend là một mối quan hệ không bắt buộc. Nó thể hiện mối quan hệ có thể có hoặc có thể không giữa các Use Case với nhau.

    Một Use Case B là extend của Use Case A thì có nghĩa Use Case B chỉ là một thứ optional, và chỉ xảy ra trong một hoàn cảnh cụ thể nào đó.

    Lấy ví dụ Grab phía trên, anh em sẽ dễ dàng có được một mối quan hệ Extend như sau.

    À…à…Nhắc tới lúc có lúc không, tức là nhắc tới điều kiện xảy ra.

    Anh em có thể thể hiện rõ ý chỗ này bằng một thứ luôn đi kèm với Extend, đó là Extension Point 😎

    Extension Point nôm na là điều kiện mà Use Case có mối quan hệ Extend sẽ xảy ra. Còn để sát nghĩa thì anh em có thể hiểu chữ Point ở đây nghĩa là điểm dữ liệu thể hiện sự khác biệt.

    Tức nếu dữ liệu này là A thì Use Case không xảy ra, nhưng nếu dữ liệu này là B thì Use Case sẽ xảy ra.

    //Theo mình nhớ là hình như anh em chỉ có thể gửi tiền tip cho tài xế, nếu cuốc xe đó anh em chấm họ maximum là 5 sao.//

    Vậy thì anh em sẽ vẽ Use Case Diagram chỗ đó như sau.

    Extension Point ở đây là dữ liệu Driver Rating. Nếu Driver Rating đạt giá trị 5 sao, thì Use Case: Gửi tiền tip cho lái xe sẽ xảy ra, và hoàn toàn optional, tùy thuộc vào khách hàng.

    Extension Point không nhất thiết phải là một dữ liệu nào đó trên hệ thống, mà có thể là một “điều kiện” bất kỳ, miễn là nó thể hiện được trường hợp cụ thể mà Use Case sẽ xảy ra.

    Ở một ví dụ khác.

    c) Generalization

    Generalization đơn giản là quan hệ cha con giữa các Use Case với nhau. Nhưng khác biệt với Include và Extend là nó còn được dùng để thể hiện mối quan hệ giữa các… Actor với nhau.

    Đầu tiên là mối quan hệ cha-con giữa các Use Case. Ví dụ:

    • Đăng nhập thì có thể đăng nhập qua số điện thoại, hoặc đăng nhập qua email.
    • Đặt hàng thì có đặt hàng qua điện thoại, hoặc đặt hàng qua website.
    • Thanh toán thì thanh toán qua thẻ ATM, qua thẻ thanh toán quốc tế, hoặc qua ví điện tử.
    • Hoặc tìm kiếm thì có thể tìm kiếm bằng từ khóa, hoặc tìm kiếm theo nhóm sản phẩm.

    Hoặc mối quan hệ cha-con giữa các Actor. Ví dụ:

    • Khách hàng gồm khách hàng cũ và khách hàng mới
    • Hoặc Vendor thì có thể gồm Retailers và Wholesalers.

    Nhìn chung, Generalization giúp anh em thể hiện rõ hơn các yêu cầu bằng việc gom nhóm các Use Case lại theo quan hệ cha-con. Cá nhân mình thì rất ít khi vẽ relationship này, chủ yếu chỉ dùng Include và Extend là chính.

    Còn một điểm nữa là Generalization có tính kế thừa. Tức thằng cha có gì thì thằng con có cái đó, kể cả Use Case hay Actor.

    Ví dụ Use Case A có include đến Use Case B và C. Thì Use Case A’ là con của Use Case A cũng sẽ có mối quan hệ Include đến Use Case B và C, mặc dù không được thể hiện trên hình.

    Ô kê, vậy là xong phần Relationship – một trong những phần chuối nhất, dễ lộn nhất trong Use Case. Hi vọng những ví dụ trên giúp anh em hiểu được cụ thể như thế nào là Include, Extend và Generalization trong một Use Case Diagram 😎

    Use Case Diagram là thứ để anh thể hiện được requirement của khách hàng.

    Vẽ sao mà khách hàng nhìn vô một phát là thấy khoái liền. Khách hàng mà chân nhịp nhịp, miệng lẩm bẩm: “Đúng rồi…đúng rồi…, tính năng này có,… tính năng kia có luôn, à… tích hợp lấy dữ liệu này có, ô kê ô kê,… vầy là đủ rồi!”, thì coi như anh em đã vẽ khá good 🙂

    3.1. Chuyện đặt tên

    Trong mô hình hóa, chuyện đặt tên là rất-rất-rất quan trọng.

    Vì đã nói “mô-hình-hóa” tức là chúng ta dùng hình ảnh để nói chuyện, thì khi đó hàm lượng chữ chiếm rất ít. Và chính vì nó ít, nên những gì chúng ta ghi trên diagram phải rất súc tích, cô đọng và có giá trị ngay tức thì.

    Chỉ cần người đọc họ nhìn vô diagram mà thấy ngay 1 dòng chữ khó hiểu, thì ngay lập tức tụt bà nó hết mood, hết muốn xem tiếp rồi.

    Nói về Use Case thì có 1 vài lưu ý sau cho anh em:

    • Actor thì phải đặt tên bằng danh từ, không dùng động từ, và cũng không mệnh đề quan hệ gì hết.
    • Tên Use Case thì phải ghi rõ ràng, rành mạch, đẹp nhất là dưới format: Verb + Noun.

    BA chúng ta vẽ Use Case nhằm mục đích diễn tả yêu cầu cho stakeholders hiểu, do đó anh em không được dùng những từ kỹ thuật trong đây, không thể hiện sự nguy hiểm ở đây, người ta đọc zô hông hiểu gì hết là trớt quớt.

    Và đặc biệt là tránh đặt tên quá dài và không nên dùng kiểu bị động.

    3.2. Vẽ Use Case mà thành phân rã chức năng

    Đây chính xác là lỗi mà mình hay gặp nhất, rất thường xuyên gặp khi vẽ Use Case.

    Dấu hiệu nhận biết rõ ràng nhất là khi Use Case Diagram của anh em đầy rẫy chữ “manage”, manage cái này, manage cái kia…

    Đầu tiên là chữ Manage rất rộng nghĩa. Yêu cầu quản lý A gồm 5 việc, thì không có nghĩa yêu cầu quản lý B cũng gồm 5 việc. Use Case là diagram thể hiện yêu cầu của End-Users, nhằm đạt được một mục đích nào đó.

    Ở ví dụ trên, nếu nói Manage Gears, Manage Brakes, hay Manage Air Conditioner thì quá tối nghĩa, chả ai hiểu nhằm mục đích sau cùng là để làm gì.

    Nguyên nhân có thể do người vẽ chưa nắm đủ thông tin về yêu cầu của End-Users, ảnh chưa hiểu rõ rốt cuộc thì người dùng họ muốn làm gì trên hệ thống, hay hệ thống phải tương tác những gì với hệ thống khác.

    Từ đó mới có chuyện anh em nhìn vô Use Case Diagram ở trên mà cảm thấy mông lung như một trò đùa. Do đó, chúng ta chỉ vẽ Use Case khi đã có đủ thông tin cần thiết:

    Ngoài ra, khi đã có đủ thông tin nhưng Use Case mình vẽ vẫn bị confuse. Lý do có thể do các Use Case mình vẽ bị lệch các cấp độ Requirement với nhau.

    Ví dụ Use Case A thì thể hiện Business Requirement, tức là rất high level. Nhưng sang Use Case B và C thì lại nói rất detail tới mức Solution Requirement như.

    Để sửa lại Use Case trên, đơn giản mình chỉ cần bỏ Use Case A: Quản lý học viên ra, vì nó là thứ rất chung chung, không thể hiện được mục đích cụ thể, so với 2 Use Case còn lại.

    Anh em tham khảo một số hình sau sẽ rõ.

    Vấn đề của hình này là ôm đồm quá nhiều. Dẫn đến quá nhiều Use Case xuất hiện trong cùng một Diagram, đã vậy cũng không có Boundary of System rõ ràng.

    Như anh em thấy, Use Case này vẽ rất sai ở những điểm như sau:

    • Xác định sai Use Case (nên mới nhiều UC như vậy): những thứ như single, double, num of guest… rõ ràng đâu phải là một Use Case, đâu phải là một sự tương tác.
    • Đặt tên Use Case sai: quá nhiều cụm danh từ cho Use Case.
    • Không có Boundary of System.
    • Những Use Case có extend không ghi chú cụ thể điều kiện khi nào thì UC extend xảy ra.

    Một note nhỏ quan trọng cho anh em, Use Case Diagram sạch đẹp là chỉ nên có trên dưới 10 Use Case trong đó. Các Use Case còn lại anh em hãy dùng Boundary of System để phân chia theo phân hệ một cách hợp lý nhất có thể.

    Hình này rõ ràng là quá thứ dữ. Thật ra trường hợp này cũng khá phổ biến, mình trước kia bị hoài. Mấu chốt đến từ một số điều sau:

    • Một số Use Case đặt tên sai
    • Chưa tận dụng các Relationship để thể hiện, khiến cho các Use Case quá rời rạc nhau, và trông rất không hợp logic.
    • Người vẽ không dùng Boundary of System để phân nhóm, giới hạn các Use Case.
    • Và đặc biệt, người vẽ quá chú trọng đến các chức năng cơ bản nhất, đó là: CRUD – Create/Read/Update/Delete.

    3.4. Quá chi tiết các chức năng CRUD

    Như ví dụ trên, mỗi thực thể là một lần CRUD. Như vậy quá tốn effort, trong khi 96,69% là ở phân hệ nào, hay dữ liệu nào, anh em cũng đều cần phải CRUD dữ liệu hết.

    Điều này tạo ra một sự lặp đi lặp lại ở các Use Case Diagram, nhưng không thể hiện được gì nhiều cho người xem. Để giải quyết vấn đề này, anh em có thể có làm 1 trong 2 cách sau.

    Thêm một dòng note trước đoạn mô tả Use Case trong tài liệu: “Toàn bộ dữ liệu đều có chức năng Thêm/ Đọc/ Sửa/ Xóa và chịu tác động bởi sự phân quyền từ phía Quản trị hệ thống” hoặc đại loại vậy. Để cho các stakeholder biết được rằng hệ thống có chức năng CRUD các dữ liệu này.

    Nhưng nên nhớ CRUD ở đây là đứng từ góc nhìn End-Users: hệ thống có cho phép End-Users CRUD dữ liệu hay không?

    Ví dụ hệ thống CRM lấy dữ liệu khuyến mãi từ hệ thống ERP. Thì về bản chất CRM phải có khả năng Create dữ liệu khuyến mãi, thì mới lấy dữ liệu khuyến mãi từ ERP về được.

    Nhưng theo góc nhìn của End-Users, thì không một người dùng nào (kể cả System Admin) có thể tạo thủ công dữ liệu khuyến mãi trên CRM, mà End-Users họ chỉ Đọc/ Sửa/ Xóa dữ liệu được lấy về này thôi.

    Do đó ở đây anh em cần mô tả rõ là có phải tất cả dữ liệu đều cho phép End-Users CRUD được hay không (không tính phân quyền).

    Tạo hẳn một Use Case với tên là: Manage “X”, với X là một đối tượng bất kỳ.

    Nếu không đầy đủ 4 tính năng CRUD, thì anh em có thể làm 1 cái note nhỏ bên trên, nói rõ Manage là có những tính năng gì, không có những tính năng gì.

    Cuối cùng vẫn quay về vấn đề thẩm mỹ. Nguyên nhân việc Use Case mất thẩm mỹ đến từ 2 lý do:

    • Mắt thẩm mỹ kém: chiếm 0,00000000000069%
    • Ẩu, cẩu thả: chiếm 99,00000000000000069%

    Làm gì cũng vậy, đặc biệt là mô hình hóa để làm document. Ẩu là thứ mình nên cố gắng hạn chế nó nhất. Vì làm đúng 1 lần, đẹp 1 lần, sau này đỡ mắc công làm lại chứ hông có gì hết.

    Một số điểm anh em cần chú ý sau:

    • Kích cỡ các Use Case trong Diagram là phải như nhau, kể cả cha-con, lẫn các mối quan hệ Include. Tuy nhiên, Use Case có Extend sẽ được vẽ to hơn một chút.
    • Nhớ phải đánh dấu Use Case ID trong hình vẽ.
    • Các mối quan hệ không được chồng chéo lẫn nhau. Anh em có thể vẽ 1 Actor ở 2 vị trí khác nhau để tránh các đường nối bắt chéo lên nhau.
    • Khi vẽ Use Case Diagram, tập trung vào câu hỏi What để tìm ra Use Case, tránh câu hỏi How, vì khi đó anh em rất dễ đi vào detail.
    • Và nếu được, hãy tô màu lên Use Case để nhìn Diagram được rõ ràng, sáng sủa và mạch lạc 🙂

    .

    .

    .

    Hi vọng qua bài này anh em đã hiểu rõ bản chất của Use Case, và biết cách vẽ Use Case Diagram. À mà không những biết cách vẽ, mà còn vẽ đúng, vẽ đẹp và tránh được những lỗi sai thường gặp nữa.

    Bái bai và hẹn gặp lại anh em!!!

    --- Bài cũ hơn ---

  • Bản Vẽ Use Case (Use Case Diagram)
  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Unit Test Cho Nodejs Với Mocha
  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn Mới Nhất 2022

    --- Bài mới hơn ---

  • Bản Vẽ Use Case (Use Case Diagram)
  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Use Case Và Use Case Testing
  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Use case là một kỹ thuật được sử dụng trong kỹ thuật phần mềm của hệ thống thống trị khách sạn nhằm nắm bắt yêu cầu chức năng của nền móng. Nó giới thiệu các thao tác đặc trưng từ user bên ngoài (actor) vào hệ thống.

    a. Tại Bộ phận Lễ tân

    a. Use case thống trị tải nhập

    • phân khúc sử dụng (actor) bao gồm: Lễ tân, nhân sự mua bán, nhân sự nhân sự, NV Kế toán, nhân sự Dịch vụ.
    • Use case này giới thiệu các bước tải nhập của các actor vào hệ thống.
    • Các bước thực hiện:

    + hệ thống kiểm tra lại thông tin đăng nhập và thông báo thành công/thất bại cho actor. Nếu tải nhập thành công hệ thống dựa trên thông tin tải nhập sẽ cùng lúc phân quyền tùy theo loại nhân viên. Nếu đăng nhập fail, nền móng sẽ hiện thông báo cho user và yêu cầu đăng nhập lại.

    b. Use case tải xuất

    + nền tảng hiển thị yêu cầu xác nhận từ actor

    + nền móng tải xuất tài khoản actor khỏi nền tảng. Nếu Actor không công nhận tải xuất thì nền móng sẽ giữ nguyên trạng thái.

    c. Use case Đặt phòng

    • đối tượng sử dụng: Lễ tân
    • Use case này cho phép bộ phận lễ tân tiếp nhận việc đặt phòng trước của khách hàng.
    • Các bước thực hiện:

    + Bộ phận Lễ tân tải nhập vào nền móng

    + Bộ phận lễ tân nhập thông tin và ngày nhận phòng của khách đầy đủ theo form

    TH1: Còn loại phòng mà KH yêu cầu:

    + nhấn nút “Đăng ký” để hoàn tất việc đặt phòng trước của khách.

    + nền móng check dữ liệu lễ tân vừa nhập và lưu lại thông tin đặt phòng của khách. Nếu thông tin KH vừa mới tồn tại trong nền móng thì sẽ không lưu thông tin KH nữa mà chỉ lưu thông tin đặt phòng.

    TH2: Loại phòng mà khách hàng yêu cầu đang hết phòng trống:

    + nền tảng sẽ báo hết loại phòng đang lựa chọn và cảnh báo để yêu cầu chọn loại phòng khác.

    + Lễ tân sẽ thông báo cho khách và liên tục search loại phòng không giống hoặc thời gian khác nếu KH yêu cầu. Nếu khách hàng không còn nhu cầu thực hiện hủy phiếu đăng ký.

    + hệ thống thông báo và yêu cầu thực hiện lại.

    d. Use case rà soát hiện trạng phòng

    • đối tượng sử dụng: toàn bộ nền móng
    • Use case này cung cấp thông tin về hiện trạng phòng của 1 phòng bất kỳ nào đó cho các actor.
    • Các bước thực hiện:

    + Actor đăng nhập vào nền tảng

    + Actor chọn chức năng “Đặt phòng” hoặc “Thuê phòng” với một phòng.

    + nền tảng sẽ tìm kiếm thông tin phòng phụ thuộc mã phòng và phản hổi lại tình trạng ngày nay của phòng (đang ở, vừa mới được đặt trước hoặc còn trống)

    + chấm dứt use case

    e. Use case tìm thông tin đặt phòng

    • phân khúc sử dụng: Lễ tân
    • Use case này cho phép get thông tin đặt phòng của một khách hàng đến nhận phòng mà đang đặt phòng trước đây.
    • Các bước thực hiện:

    + Lễ tân nhập số CMND của KH để tiến hành tìm thông tin đặt phòng.

    f. Use case Lập phiếu dịch vụ

    • phân khúc sử dụng: Lễ tân
    • Use case này cho phép bộ phận lễ tân tiếp nhận yêu cầu và lập phiếu sử dụng dịch vụ của khách hàng.
    • Các bước thực hiện:

    + nền móng sẽ tạo ra phiếu dịch vụ ứng với thông tin nhận phòng tương ứng và hiển thị thông tin ra để lễ tân xem, đồng thời yêu cầu lễ tân chọn các dịch vụ mà khách hàng yêu cầu.

    + kết thúc Use case.

    g. Use case tổng hợp doanh thu

    • Đối tượng: nhân sự Kế toán
    • Use case này cho phép nhân viên kế toán tổng hợp doanh thu của khách sạn theo yêu cầu của thống trị.
    • Các bước thực hiện:

    + hệ thống hiển thị menu thống kê: theo ngày, theo tháng, theo quý, theo năm.

    + nhân sự kế toán lựa chọn một trong các mục.

    + nền tảng sẽ đo đạt và in ra giấy.

    Nguồn: https://www.bravo.com.vn

    --- Bài cũ hơn ---

  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Unit Test Cho Nodejs Với Mocha
  • Viết Unit Test Trong C# Với Nunit
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • Nhóm Tài Liệu Cho Ba: User Story, Use Case Và Functional Specification Document

    --- Bài mới hơn ---

  • 14 Mẹo Để Viết Requirement Tốt Hơn
  • Trích Dẫn Và Lập Danh Mục Tài Liệu Tham Khảo Theo Chuẩn Chicago
  • Cách Tạo Danh Mục Tài Liệu Tham Khảo Có Trích Dẫn Trong Microsoft Word
  • Cách Viết Email (Phần 1)
  • Cách Viết Email Rõ Ràng Và Chuyên Nghiệp
  • Trong bài viết trước, BAC đã gửi đến bạn đọc quy trình làm việc đầu tiên của người BA với loại tài liệu Project Vision Document với mục đích để có một góc nhìn tổng quan đối với dự án.

    Tiếp đến, để mô hình hóa được các yêu cầu đó cho team dev hiểu và bắt đầu thực thi dự án, người BA cần xây dựng các loại tài liệu. Có thể kể đến là Use Case/ User Story và Functional Specification.

    1. User story (US) và Use case (UC)

      User story (còn được gọi là Scenario) dùng để mô tả một nhu cầu /yêu cầu của người dùng. Trong khi đó Use case là cách thể hiện sự tương tác giữa người dùng và hệ thống. Tuy nhiên, cả 2 đều được tạo ra nhằm mục đích cụ thể hóa những yêu cầu của người dùng đối với hệ thống.

    Với những dự án thực hiện theo phương pháp Agile, họ tập trung vào cách nào là hiệu quả nhất để delivery sản phẩm tốt nhất đến cho khách hàng. Và loại tài liệu phổ biến được dùng đó là User story. User story được viết dưới dạng mong muốn của người dùng với hệ thống nhưng cũng chính là những chức năng mà hệ thống cần có.

    • Xác định rõ ràng với các thành viên trong team của bạn cần thực hiện những phần nào trước (Cụ thể trong kì Sprint này cần làm những gì?)
    • Đảm bảo mọi người có chung một cái hiểu đúng về vấn đề
    • Là điều kiện mà tester dựa vào đó để kiểm thử US

    Ví dụ về một US: Là một người dùng, tôi muốn đăng nhập vào hệ thống để mua sắm online.

    Nguồn ảnh: www.visual-paradigm.com

    Vậy để viết User story được tốt nhất, bạn có thể áp dụng theo phương pháp INVEST. Đây là từ viết tắt của:

    • I – Independent: US có thể đứng độc lập như một chức năng của hệ thống hay không?
    • N – Negotiable: US có thể thay đổi hay xóa đi mà không ảnh hưởng đến những phần còn lại của dự án hay không?
    • V – Valuable: US này có thực sự hữu ích đối với người dùng cuối hay không?
    • E – Estimable: Bạn có thể ước tính được độ rộng của US này hay không? Điều này sẽ giúp bạn quyết định xem liệu có nên tách ra US thành nhiều US không?
    • S – Small: Liệu US này có vừa đủ thực hiện trong Sprint kì này không?
    • T – Testable: Bạn có thể đánh giá được US này hay không?

    Bạn có thể có thể tham khảo bài viết sau để hiểu hơn UC/US: Link

    Hay một ví dụ về sơ đồ UC: Làm thủ tục checkin và kiểm tra tại sân bay

    Nguồn ảnh: chúng tôi

    • Mục đích của UC: Mô tả lại quy trình làm thủ tục check-in và kiểm tra tại sân bay
    • Business actors: Hành khách (Passenger) bao gồm đối tương như Trẻ nhỏ (Minor Passenger), Người khuyết tật (Passenger with Special Needs), người hướng dẫn (Tour Guide).
    • Bối cảnh: Làm thủ tục checkin theo cá nhân, theo nhóm và kiểm tra. Đối với trường hợp kí gửi hàng hóa là một case extend của case checkin.

    2. FSD

      Tài liệu Functional Specification Document (FSD) (hay tên gọi khác là Functional Requirements Document (FRD)), hỗ trợ cho các quản lí dự án phát triển phần mềm hạn chế những nhầm lẫn hay đi lệch hướng của dự án.

    Nhu cầu đào tạo doanh nghiệp

    là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của quốc tế. Ngoài các khóa học public, còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.

    Khoá học Online:

    Khoá học Offline:

    --- Bài cũ hơn ---

  • Process Documentation: Ý Nghĩa Và Cách Để Viết Tài Liệu Mô Tả Quy Trình
  • 7 Quy Tắc Viết Chữ Hán Trong Tiếng Trung Chuẩn, Đẹp, Nhanh
  • 5 Cách Viết Chữ Kiểu Trên Facebook Độc Đáo 2022
  • Cover Letter Là Gì? Những Cách Viết Cover Letter Chuyên Nghiệp Mẫu
  • 8 Cover Letter Để Đọc Thử Nếu Chưa Biết Viết Như Thế Nào
  • Cách Viết Test Case Cho Phần Mềm

    --- Bài mới hơn ---

  • Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử
  • 13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào
  • Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile
  • Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop
  • Bài 4. Kiểm Thử Ứng Dụng Di Động
  • 1. Test Case là gì?

    Các test case giúp hướng dẫn tester thông qua một chuỗi các bước để xác thực xem application có lỗi hay không và hoạt động theo yêu cầu của người dùng hay không. Học cách viết các test case đòi hỏi các kỹ năng viết cơ bản, chú ý đến chi tiết và tester phải hiểu rõ về application được test.

    Thông thường, các test case được viết cho một mô-đun nhất định hoặc một phần của application, được nhóm thành một test suite. Không phải thông thường, một phiên test sẽ bao gồm nhiều test case vì thường sẽ có nhiều hơn một kịch bản cụ thể được test.

    2. Một test case được viết tốt sẽ cho phép bất kỳ tester nào cũng hiểu được và thực hiện được test.

    Khi viết test case, điều quan trọng là bạn phải đặt mình vào vị trí của người dùng và nghĩ về tất cả những điều bạn cho là cần thiết để application hoạt động đúng. Trước tiên là bạn phải nổ lực để viết các test case tốt trước sẽ giúp bạn tiết kiệm thời gian và công sức sau này. Các test case được viết tốt sẽ tạo ra sự khác biệt giữa một application được test tốt và một application được test không tốt.

    Viết các test case – đặc biệt là viết một số lượng lớn trong cùng một lúc – có thể là một công việc tốn thời gian. Ở đây, chúng ta sẽ nghiên cứu một số mẹo về cách viết các test case, cùng với một mẫu của một test case ở cuối bài viết này.

    3. Cách viết test case cho phần mềm:

    3.1. Sử dụng một tiêu đề rõ ràng

    Một test case tốt bắt đầu với một tiêu đề rõ ràng. Như một best practice, tốt nhất là đặt tên cho test case cùng với tên mô-đun mà bạn đang test. Ví dụ: nếu bạn đang test trang login, hãy thêm “ Login successfully.

    Summary: Verify if a user will be able to login with a valid username and valid password.

    Pre-condition: User created an account before.

    Step by Step

    1. Navigate to button 5. Observe

    Expected result: Login successfully when entering username and password are correct

    5. Công cụ để viết test case

    Không có một phương pháp chính xác để viết lại nội dung các test case của bạn, nhưng có nhiều công cụ giúp quá trình viết các test case hiệu quả. Ví dụ, các test case thường được viết trong file excel. Nhiều testing team vẫn lựa chọn phương pháp này. Nó khá linh hoạt, bạn có thể tạo quy trình và phương pháp theo dõi các test case của riêng mình, nhưng nó cũng có thể cực kỳ tốn thời gian và cồng kềnh.

    Một số team sử dụng các công cụ quản lý dự án để ghi lại các test case của họ. Đây là một thay thế tuyệt vời cho excel vì có khả năng share giữa các member trong team

    Với một công cụ dành riêng cho các test case, bạn có thể viết các test case của mình, thực hiện các test của mình, báo cáo kết quả và cộng tác với nhóm của bạn trong mỗi bước của quy trình.

    6. Lợi ích thêm của viết test case

    Việc luyện tập viết test case giúp cho testing team có thể coverage được nhiều case nhất có thể xuyên suốt application, nhưng việc viết các test case thậm chí có tác động hơn đến việc đảm bảo chất lượng và trải nghiệm người dùng.

    • Bạn sẽ tìm thấy những lỗi trong thiết kế sớm hơn
    • Bạn sẽ tìm thấy các vấn đề về khả năng sử dụng
    • Những thành viên mới có thể nhận và test application mà không cần phải đào tạo nhiều
    • Nó có thể tạo sự đồng cảm với người dùng của bạn
    • Nó giúp bạn và những người khác hiểu về product

    Khi viết test case bạn đã đặt bạn vào vị trí của người dùng, điều này tạo nên sự đồng cảm cho những người dùngthực sự sẽ sử dụng product của bạn. Điều này có thể giúp dễ dàng feedback trở lại về thiết kế và quá trình phát triển. Khi bạn viết các test case, bạn sẽ xác định các vấn đề và các điểm cần cải thiện, những vấn đề này có thể được giải quyết trước khi application được đưa lên production.

    Viết test case có nghĩa là bất kỳ thành viên nào mới đều có thể dễ dàng tăng tốc độ làm việc trên dự án mà không cần đào tạo nhiều. Cuối cùng, các test case phác thảo chính xác cách sử dụng product và những gì được mong đợi.

    Một bộ các test case tốt sẽ giúp các thành viên khác trong team có thể share cho người khác để dễ dàng tìm hiểu về dự án. Hãy nghĩ về việc hỗ trợ khách hàng. Team hỗ trợ có thể duyệt các test case để hiểu các tính năng sắp tới sẽ hoạt động như thế nào. Họ có thể sử dụng những test case đó để viết tài liệu kỹ thuật và nội dung trợ giúp.

    7. Phần kết luận

    Viết các test case cần phải thực hành và có hiểu biết về phần mềm đang được test. Các test case được viết tốt có thể làm cho quá trình test của bạn trơn tru hơn và giúp bạn tiết kiệm thời gian trong quá trình sau này. Hãy dùng một công cụ để bạn có thể quản lý và sắp xếp các test case của mình một cách hiệu quả.

    Tham khảo

    All Rights Reserved

    --- Bài cũ hơn ---

  • Lập Trình Ứng Dụng Facebook
  • Cách Tạo Một Facebook Apps Và Lấy App Id, Secret Key
  • Cách Tải Ứng Dụng Trên App Store Cho Iphone
  • Điểm Danh Sự Thành Công Của Các App Bán Hàng Tại Việt Nam 2022
  • Viết App Ngành Bán Hàng Theo Yêu Cầu Tại Hà Nội
  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)

    --- Bài mới hơn ---

  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case
  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Cách Viết Rails Api Document
  • Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?
  • Đầu tiên, chúng ta cùng tìm hiểu:

    A. Testcase là gì?

      Testcase là các trường hợp kiểm thử bao gồm các hành động được thực hiện nhằm kiểm tra từng chức năng của ứng dụng phần mềm có hoạt động đúng theo như mong muốn hay không.

    B. Làm thế nào để có thể viết được Testcase tốt?

    I. Trước khi bắt tay vào việc viết Testcase thì chúng ta cần nhớ những điểm sau đây:

    • Là 1 newbie, mới gia nhập công ty, chúng ta nên hỏi QA leader về template viết Testcase và xin file đó để làm. ( Vì mỗi công ty sẽ có cách viết khác nhau)
    • Viết Testcase nhớ phải bám sát tài liệu yêu cầu ( spec)
    • 1 Testcase ID không quá 15 bước ( step)
    • Trước khi viết Testcase thì ta nên đọc và phân tích tài liệu thật kĩ càng, có chỗ nào chưa hiểu thì đặt Q&A ( Question & Answer) với các member trong team hoặc QA leader hoặc khách hàng để việc viết testcase và test được chính xác và chắc chắn hơn.

    II. Những nguyên tắc để viết TestCase tốt:1. Các trường hợp kiểm thử cần phải đơn giản và minh bạch: (Test Cases need to be simple and transparent)

    • Tạo các testcase đơn giản nhất có thể nhưng vẫn phải rõ ràng và dễ hiểu.

    2. Tạo Testcase với vai trò mình là End -user (người dùng ứng dụng đó)

      Mục tiêu cuối cùng của bất kì dự án phần mềm nào cũng là đáp ứng được tất cả các yêu cầu của khách hàng. Vậy nên đặt vị trí của mình là người dùng thì sẽ thực hiện test được hiệu quả hơn. Chứ không nên có suy nghĩ mình chỉ là QA, chỉ là tester nên mình cứ test theo những gì spec nói thôi. Khi thấy UI nó khó dùng thì ta nên ta feedback lại với PM hay với mọi người để tất cả cùng cân nhắc có nên thay đổi hay không.

    3. Mỗi testcase đều phải được xác định

      Đặt tên ID cho từng testcase để dễ dàng theo dõi

    b, Phân vùng tương đương (Equivalence Partition): Kỹ thuật này phân vùng phạm vi thành các phần / nhóm bằng nhau có xu hướng có cùng hành vi.

    c,Kỹ thuật Bảng quyết định (Decision tables) : Phương pháp này tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.

    d, Kỹ thuật đoán lỗi (Error Guessing Technique): Đây là đoán / dự đoán lỗi có thể phát sinh trong khi thực hiện test manual.

    5. Review chéo (Peer Review): Sau khi tạo xong Testcase, hãy nhờ đồng nghiệp của bạn review giúp, có thể là QA leader hay QA cùng team để phát hiện ra các case mà bạn còn thiếu hoặc bạn chưa nghĩ tới.

    C. Thực hành viết Testcase:

      Khi join vào dự án, chúng ta được QA Leader giao cho nhiệm vụ là viết Testcase cho màn Login của 1 website với UI như thế này:

    Ta sẽ viết theo format chuẩn như sau:

    Testcase ID Test Scenario Test Steps Test Data Expected Results Actual Results Status

    LG01

    Check UI

    As expected

    Pass

    LG02

    Check button Sign in when user input valid data

    4. User can login successfully and system go to the Homepage

    As expected

    Pass

    LG03

    Check button Sign in when user input invalid data

    4. User cannot login and system shows error message: Email is invalid.

    As expected

    Pass

    Qua 3 ví dụ trên các bạn có thể dễ dàng hơn với việc với Testcase rồi đúng không nào? Tương tự các case trên, các bạn áp dụng Kĩ thuật Bảng quyết định, ta sẽ có thêm các case sau:

    --- Bài cũ hơn ---

  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • Cách Test Api Như Thế Nào?
  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Cách Sử Dụng Api WordPress Rest
  • Web hay
  • Links hay
  • Push
  • Chủ đề top 10
  • Chủ đề top 20
  • Chủ đề top 30
  • Chủ đề top 40
  • Chủ đề top 50
  • Chủ đề top 60
  • Chủ đề top 70
  • Chủ đề top 80
  • Chủ đề top 90
  • Chủ đề top 100
  • Bài viết top 10
  • Bài viết top 20
  • Bài viết top 30
  • Bài viết top 40
  • Bài viết top 50
  • Bài viết top 60
  • Bài viết top 70
  • Bài viết top 80
  • Bài viết top 90
  • Bài viết top 100