Có gì khác biệt giữa trường hợp sử dụng của người dùng khác nhau


42

Có một định nghĩa chính xác, nhưng đơn giản và dễ hiểu về sự khác biệt giữa "ca sử dụng", "Câu chuyện người dùng" và "Kịch bản sử dụng" không?

có khá nhiều lời giải thích, nhưng ngay bây giờ, tôi không thấy ai giải thích sự khác biệt trong một câu, hoặc hai ...

(ví dụ: http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison rất dài và khó để có được, thảo luận đầy đủ)


3
Cảm ơn câu hỏi của bạn. Vì một số lý do, những người đưa ra các phương pháp không bao giờ chính xác một cách có chủ ý (tôi giả định) để những suy nghĩ của họ không bao giờ bị buộc tội là không thể áp dụng cho tình huống nhất định. Điều này đang kéo toàn bộ ngành công nghiệp trở lại, nơi mỗi chúng ta phải tạo ra một sự thích ứng hoạt động trước khi sử dụng phương pháp luận. Tôi hy vọng cộng đồng chống lại hành vi này. Đôi khi, bạn chọn 2 cuốn sách và chúng định nghĩa mọi thứ khác nhau - Khoa học không hoạt động theo cách này.
NoChance

Tôi đề nghị bạn kiểm tra định nghĩa Wikipedia của từng điều khoản của bạn. Nó có thể giúp bạn hiểu rõ hơn các điều khoản có nghĩa là gì. Cũng lưu ý rằng các điều khoản đến từ các khái niệm khác nhau. Ví dụ: câu chuyện của người dùng là một công cụ / kỹ thuật Agile và Use Case là một công cụ / kỹ thuật OOA.
NoChance

Câu trả lời:



20

Đối với tôi, sự khác biệt lớn nhất giữa Câu chuyện người dùng và Ca sử dụng là:

  • Một câu chuyện sử dụng là một trọng lượng nhẹ tài liệu có thể được ghi trên thẻ (Để, như một, tôi muốn). Câu chuyện của người dùng không nắm bắt được tất cả các chi tiết, đó là một hỗ trợ không chính thức cho cuộc thảo luận.
  • Một trường hợp sử dụng là một nặng tài liệu mà cần một tài liệu văn bản. Nó mô tả "Dòng chảy thông thường" của các bước và / hoặc hành động và "Dòng chảy thay thế" được nêu chi tiết. Ca sử dụng nắm bắt tất cả các chi tiết, đó là một đặc điểm kỹ thuật chính thức.

Theo Scott W. Ambler về Kịch bản sử dụng , những tạo tác này trông giống như dòng chảy của Ca sử dụng:

Một kịch bản sử dụng , hay viết tắt là kịch bản, mô tả một ví dụ trong thế giới thực về cách một hoặc nhiều người hoặc tổ chức tương tác với một hệ thống. Chúng mô tả các bước, sự kiện và / hoặc hành động xảy ra trong quá trình tương tác. Các kịch bản sử dụng có thể rất chi tiết, cho biết chính xác cách thức ai đó làm việc với giao diện người dùng hoặc mức độ cao mô tả hợp lý các hành động kinh doanh quan trọng nhưng không cho biết cách họ thực hiện.

Thành thật mà nói, sự khác biệt với dòng chảy của Ca sử dụng không rõ ràng, ngay cả sau khi đọc đoạn này (câu cuối cùng có thể là quan trọng nhất):

Như bạn có thể tưởng tượng, có một số khác biệt giữa các trường hợp sử dụng và các tình huống. Đầu tiên, trường hợp sử dụng thường đề cập đến các tác nhân chung, chẳng hạn như Khách hàng, trong khi các tình huống thường đề cập đến các ví dụ về các tác nhân như John Smith và Sally Jones. Không có gì ngăn bạn viết một kịch bản chung chung, nhưng tốt hơn hết là cá nhân hóa các kịch bản để tăng tính dễ hiểu của chúng. Thứ hai, các kịch bản sử dụng mô tả một đường dẫn logic duy nhất trong khi các trường hợp sử dụng thường mô tả một số đường dẫn (khóa học cơ bản cộng với bất kỳ đường dẫn thay thế phù hợp nào). Thứ ba, trong các quy trình sử dụng UP, các trường hợp sử dụng thường được giữ lại làm tài liệu chính thức trong khi các kịch bản thường bị loại bỏ sau khi chúng không còn cần thiết.

Tôi có thể sai, nhưng Kịch bản sử dụng thực sự nghe giống như luồng sử dụng Case nhưng được đặt lại thương hiệu bằng một cú chạm Agile.


Tôi nghĩ cá nhân hóa các kịch bản là có hại (ít nhất là theo tôi hiểu). Bạn nói "thường tốt hơn để cá nhân hóa các kịch bản" - Nhưng điều gì sẽ xảy ra nếu Sally Jones rời công ty hoặc thay đổi vị trí - Kịch bản sẽ có giá trị gì?
NoChance

Cá nhân hóa không có nghĩa là thiết kế cho một người thực sự. Nó có thể dành cho một người thực sự, nhưng nó cũng có thể dành cho một người hư cấu, như với công cụ "Personas". Các lý lẽ cho việc sử dụng người dùng cụ thể (thực tế hoặc hư cấu), với một tính cách, là các kịch bản trở nên "thực" hơn. Lập trình viên dễ hiểu người dùng hơn khi hiểu tính cách của người dùng đó, thay vì cố gắng hiểu một người dùng không chính xác trừu tượng. Xin vui lòng cho tôi biết nếu tôi sai, hoặc nếu tôi hiểu nhầm ý kiến ​​của bạn.
Mads Skjern

Về A use case is an heavyweight document that needs a word document.. Martin Fowler nghĩ rằng Use case are at their best when they are short and readable. You should not be spending weeks, let alone months, generating use case documents before you begin development.
từ

3

Không có một định nghĩa chính xác về bất kỳ thứ gì trong số này. Tất cả thay đổi một chút (hoặc rất nhiều) từ công ty này sang công ty khác và từ hệ thống này sang hệ thống khác.

Đặt cược tốt nhất của bạn là tìm một ví dụ đã có sẵn cho dự án hiện tại của bạn và làm theo nó.

Nếu bạn đang tạo một hệ thống mới, bạn có thể tìm thấy các định nghĩa về các loại trường hợp sử dụng khác nhau cho bất kỳ hệ thống nào bạn thích - Chỉ cần chọn mẫu có vẻ truyền đạt ý định của bạn tốt nhất.

Đừng gác máy.


1
> Đừng để bị treo lên tên. Đừng lo lắng, tôi sẽ không! :) mặt khác, đó là một mục tiêu khá mong muốn khi trong một nhóm tất cả các thành viên có nghĩa và hiểu ý nghĩa của một từ theo cách tương tự

1
Tôi hoàn toàn đồng ý - nhưng ở cấp độ đội. Tôi chỉ thấy rằng ở cấp độ "Toàn cầu", tôi chưa bao giờ thấy hai người định nghĩa "Trường hợp sử dụng" theo cùng một cách.
Bill K

Không giống nhau, nhưng về xu hướng tương tự ... và ít nhất đó là những xu hướng mà tôi muốn biết và hiểu

3

Câu chuyện của người dùng luôn không chính thức và mô tả nhu cầu của người dùng. Một trường hợp sử dụng có thể là chính thức hoặc không chính thức và mô tả hành vi hệ thống.

Có thể có câu chuyện người dùng "công nghệ", điều tương tự không đúng với các trường hợp sử dụng.

Sau khi thực hiện, câu chuyện người dùng thường bị loại bỏ. Các trường hợp sử dụng có thể được duy trì trong suốt vòng đời sản phẩm.

Phạm vi cũng khác nhau. Câu chuyện của người dùng thường có phạm vi nhỏ hơn và do đó, trường hợp sử dụng bao gồm một số câu chuyện của người dùng. Yêu cầu thay đổi đối với hệ thống hiện tại được mô tả trong câu chuyện người dùng mới hoặc phiên bản cập nhật của trường hợp sử dụng.

Điểm giống nhau giữa các câu chuyện của người dùng và các trường hợp sử dụng là cả hai đều được sử dụng để lập kế hoạch và lên lịch.


1

Câu chuyện người dùng khi được phân tách thành các tác vụ có thể gán riêng cho nhà phát triển có thể hoặc không thể chi tiết hơn và bị ràng buộc trong phạm vi so với Kịch bản ca sử dụng. Câu chuyện của người dùng là về nhu cầu của Người dùng - Mục tiêu hoặc Kết quả từ việc họ sử dụng Hệ thống.

Ví dụ về Câu chuyện của người dùng là:

  1. Tôi là Khách hàng và tôi muốn thanh toán số dư tài khoản của mình trực tuyến - một chế độ xem khá cao cấp
  2. Tôi là Khách hàng và tôi muốn cập nhật năm hết hạn trên thông tin tín dụng được lưu trữ của mình - một chế độ xem chi tiết.

Ở mức độ trừu tượng cao nhất, Ca sử dụng nghe có vẻ rất giống nhau - Năm cập nhật thẻ hết hạn của khách hàng - nhưng đây là tuyên bố về chức năng chứ không phải mục tiêu.

Khi mức độ chi tiết của các kịch bản Ca sử dụng được xác định, chúng trở nên nhiều hơn về chức năng và thủ tục.

Điều kiện hậu của tình huống chính trong trường hợp sử dụng phải có cùng kết quả như đã nêu trong Câu chuyện của người dùng - Năm hết hạn thẻ tín dụng của khách hàng được cập nhật.

Tình huống sử dụng mô tả từng bước trong biểu đồ luồng văn bản hoặc quy trình (không nhất thiết là UML hoặc BPM - Tôi sử dụng sơ đồ luồng chức năng chéo tiêu chuẩn để rõ ràng và dễ sử dụng bởi người tiêu dùng chưa được đào tạo về trường hợp sử dụng.

Điểm mấu chốt là Câu chuyện của Người dùng mô tả Nhu cầu và Kết quả (Những gì Hệ thống cần Cung cấp) trong khi Các trường hợp sử dụng mô tả các tương tác giữa các Diễn viên cần để đáp ứng mục tiêu - VÀ điều gì có thể sai (Kịch bản mở rộng, Thay thế hoặc Lỗi) (cách người dùng tương tác với Hệ thống đạt được kết quả đó)

Để có một chiều sâu thảo luận về chủ đề này, tôi khuyên bạn nên đọc http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison trên trang web của Alistair Cockburn. Vì anh ấy là người ký Tuyên ngôn Agile, người đã đặt ra Câu chuyện người dùng và được coi là chuyên gia về Ca sử dụng trong vài thập kỷ qua, tôi nghĩ rằng anh ấy là một nguồn tuyệt vời để biết thêm thông tin.


2
Đây chỉ là một bức tường của văn bản; bạn có thể chỉnh sửa nó để dễ đọc
Martijn Pieters

1

Ghi chú tạm thời : Bài đăng này cần cải tiến để trả lời tốt hơn câu hỏi, chẳng hạn như 1) chi tiết bổ sung nên được đưa vào từ tài liệu tham khảo 2) một số trích dẫn có thể 3) tính chính xác của tiếng Anh 4) chất lượng tổng thể của tường thuật 5) v.v. trở lại nó Hãy tự cải thiện nó.


Nhìn vào các mẫu của họ có thể cung cấp cái nhìn sâu sắc có giá trị về sự khác biệt giữa các điều khoản này.

Ca sử dụng

Có nhiều mẫu cho các trường hợp sử dụng. Tôi tìm thấy 3 sau khi tìm kiếm nhanh: 1 , 2 , 3 . Một số điểm họ (đôi khi mơ hồ) có điểm chung là:

  1. Tên trường hợp sử dụng / tiêu đề
  2. Mô tả - một số văn bản ngắn mô tả phạm vi.
  3. Diễn viên / Diễn viên chính - người (người) tương tác với trường hợp sử dụng cụ thể này.
  4. Điều kiện tiên quyết - bất cứ điều gì mà trường hợp sử dụng này có thể cho là đúng trước khi bắt đầu vòng đời.
  5. Kịch bản thành công - một chuỗi các bước mô tả chính xác các sự kiện diễn ra.
  6. Tiện ích mở rộng - luồng ứng dụng khi nó lệch khỏi luồng của kịch bản thành công:

    1. Các luồng thay thế - các tùy chọn khác của luồng chính xác
    2. Luồng ngoại lệ - luồng sự kiện xảy ra khi có sự cố
  7. Đảm bảo thành công (còn gọi là Điều kiện đăng bài) - trạng thái áp dụng sau khi mọi thứ được thực hiện

Một số điểm bổ sung có thể được bao gồm là Cấp độ , Đảm bảo tối thiểu , Kích hoạt , v.v.

Trên đây là những gì được gọi là trường hợp sử dụng mặc quần áo đầy đủ . Bạn có thể đơn giản hóa việc tạo trường hợp sử dụng bằng cách sử dụng trường hợp sử dụng thông thường bằng cách chỉ sử dụng các điểm quan trọng nhất, ví dụ:

  1. Tiêu đề
  2. Diễn viên
  3. Chuỗi các sự kiện

Các trường hợp sử dụng đã được Ivar Jacobson tạo ra và phổ biến vào cuối những năm 80 đầu thập niên 90. Sau đó, những người khác cũng đóng góp cho công việc của anh ấy (một trong những người như vậy là Alistair Cockburn, tác giả của Văn bản sử dụng hiệu quả ). Để diễn giải Martin Fowler, các trường hợp sử dụng có thể sử dụng văn bản và sơ đồ UML, nhưng giá trị lớn nhất của chúng nằm ở văn bản của nó. Chúng là tốt nhất khi chúng không lớn và dễ đọc.

Câu chuyện của người dùng (còn gọi là Tính năng)

Câu chuyện người dùng - một câu chuyện nhỏ mô tả một tính năng cụ thể. Có một mô hình phổ biến về cách viết một câu chuyện người dùng, đó là:

Là một loại người dùng cụ thể,
tôi muốn làm một cái gì đó
để một số lý do .

Ngoài ra, câu chuyện của người dùng có thể có tiêu chí chấp nhận .

Như bạn có thể thấy mẫu này nhỏ hơn nhiều so với trường hợp sử dụng. Câu chuyện của người dùng thường được liên kết với khu vực phát triển phần mềm scrum / agile / xp. Chúng có nghĩa là được viết trên các vùng nhỏ trên bề mặt, chẳng hạn như ghi chú sau nó, và / hoặc trên bảng scrum. Ở đó, chúng (thường) được đưa ra các giá trị điểm tương đương với bao nhiêu nỗ lực cần được đầu tư vào tài liệu tham khảo câu chuyện người dùng đó .

Bill Wake đã phát triển bộ nhớ ĐẦU TƯ để mô tả những phẩm chất mà một câu chuyện người dùng tốt cần có, và tôi sẽ mượn bản tóm tắt ngắn của Martin Fowler về trang web đó từ trang web của anh ấy :

Độc lập : các câu chuyện có thể được phân phối theo bất kỳ thứ tự nào
Thỏa thuận : các chi tiết về những gì trong câu chuyện được tạo ra bởi các lập trình viên và khách hàng trong quá trình phát triển.
Có giá trị : chức năng được xem là có giá trị bởi khách hàng hoặc người dùng phần mềm.
thể ước tính: các lập trình viên có thể đưa ra một ước tính hợp lý để xây dựng câu chuyện
Nhỏ : các câu chuyện nên được xây dựng trong một khoảng thời gian nhỏ, thường là vấn đề của ngày-người. Chắc chắn bạn sẽ có thể xây dựng một vài câu chuyện trong một lần lặp.
thể kiểm tra: bạn sẽ có thể viết các bài kiểm tra để xác minh phần mềm cho câu chuyện này hoạt động chính xác.

Kịch bản sử dụng

Kịch bản sử dụng tuân theo mẫu GWT, viết tắt của Cho-Khi-Sau đó, như vậy:

Kịch bản : tiêu đề Đã
cho : một thực tế cụ thể
: một thực tế cụ thể khác (có thể là tùy chọn)
Khi : một số sự kiện xảy ra
Sau đó : một số sự kiện khác xảy ra

Các kịch bản sử dụng có liên quan đến Phát triển hướng hành vi. Nghe có vẻ rất giống với một bài kiểm tra. Martin Fowler trong bài đăng trên blog của mình đưa ra một số lịch sử và lý do đằng sau các kịch bản sử dụng. Đây là phần quan trọng:

Phần đã cho mô tả trạng thái của thế giới trước khi bạn bắt đầu hành vi bạn chỉ định trong kịch bản này. Bạn có thể nghĩ về nó như là điều kiện trước để thử nghiệm.
Phần khi đó là hành vi mà bạn chỉ định.
Cuối cùng, phần sau đó mô tả những thay đổi bạn mong đợi do hành vi được chỉ định.

Các kịch bản sử dụng có thể được sử dụng để viết bài kiểm tra cho ứng dụng của bạn. Để trích dẫn đoạn cuối của bài viết của Martin:

Mặc dù kiểu Cho-Khi-Sau đó có triệu chứng đối với BDD, ý tưởng cơ bản là khá phổ biến khi viết các bài kiểm tra hoặc đặc tả bằng ví dụ. Meszaros mô tả mô hình là Thử nghiệm bốn pha. Bốn giai đoạn của anh là Thiết lập (Đã cho), Tập thể dục (Khi), Xác minh (Sau đó) và Teardown. Bill Wake đã đưa ra công thức như Arrange, Act, Assert.


Tài liệu tham khảo cho nghiên cứu xa hơn:

Các trang Wikipedia cho trường hợp sử dụng , câu chuyện người dùng , kịch bản sử dụng
Blog của Martin Fowler về trường hợp sử dụng , câu chuyện người dùng , kịch bản sử dụng


0

Tôi không quen thuộc với Câu chuyện người dùng, nhưng khi tôi xem xét điều này vài năm trước:

Ca sử dụng là một nhiệm vụ chính.
Kịch bản người dùng là những cách khác nhau mà tác vụ có thể diễn ra. Vì vậy, Mỗi Ca sử dụng có một hoặc nhiều kịch bản. Ca sử dụng là bản tóm tắt, Kịch bản người dùng là một danh mục của tất cả các trường hợp có thể có của tác vụ trừu tượng đó.

Vì vậy:
Sử dụng Trường hợp A: Người dùng xác thực bằng id và mật khẩu.

Kịch bản:
1. ID được nhận dạng, mật khẩu đúng. (Kịch bản "ngày nắng")
2. ID được nhận dạng, mật khẩu không chính xác.
3. ID được nhận dạng, mật khẩu không chính xác lần thứ ba.
4. ID không được công nhận.

Tôi đã luôn nghĩ về các trường hợp sử dụng như một cách xác định các yêu cầu theo cách kể chuyện cho khách hàng theo cách của họ. Với những điều trên, nếu khách hàng nói "Nhưng nếu họ cố gắng đăng nhập vào giữa nửa đêm và một khi hệ thống ngừng hoạt động thì sao?", chúng tôi đã phát hiện ra một kịch bản khác cho nhiệm vụ xác thực và một số yêu cầu bổ sung.


0

Câu chuyện của người dùng theo quan điểm của khách hàng, đôi khi nó không chính xác hoặc không đầy đủ. Nó có thể không có sự xem xét về hiệu suất, xử lý lỗi hoặc không có gì về phụ trợ.

Một trường hợp sử dụng là từ quan điểm của dev. Nó chính xác và đầy đủ. Nó sẽ trả lời tất cả các yêu cầu từ khách hàng.


0

"Ca sử dụng" và "câu chuyện người dùng" giống nhau theo nghĩa họ thể hiện "yêu cầu" của khách hàng.

Ca sử dụng là cách hệ thống được sử dụng trong từng trường hợp, thường được biểu diễn dưới dạng tương tác giữa tác nhân và hệ thống hoặc giữa các hệ thống.

Câu chuyện của người dùng là điểm khởi đầu trong hành trình tạo ra một công cụ hỗ trợ máy tính cho phép người dùng cuối hoàn thành công việc và thường bắt đầu bằng một câu đơn giản sử dụng ai, cái gì, tại sao ("Là người dùng đóng ứng dụng, tôi muốn được nhắc lưu bất cứ thứ gì đã thay đổi kể từ lần lưu cuối cùng để tôi có thể bảo toàn công việc hữu ích và loại bỏ công việc sai lầm. "). Câu chuyện người dùng đó sau đó cần được đưa vào một trường hợp sử dụng mà các nhà phát triển sử dụng để xây dựng một ứng dụng và những người thử nghiệm để tiến hành thử nghiệm.

Từ quan điểm của QA Tester, họ không kiểm tra "câu chuyện của người dùng", mà là "trường hợp sử dụng", nghĩa là họ đang kiểm tra các chức năng của phần mềm.


1
Trong khi chính xác, điều này không thêm bất cứ điều gì vào câu trả lời đã được thực hiện trong 4 năm.
Adam Zuckerman

0

Mục đích của Kịch bản sử dụng là nắm bắt bản chất của sự tương tác của người dùng với hệ thống của bạn để đạt được mục tiêu, mà không đi sâu vào chi tiết của các hành động hệ thống hoặc thiết kế thực tế. Trọng tâm là người dùng, không phải hệ thống.

... Ca sử dụng cũng bao gồm các tuyên bố về những gì hệ thống sẽ làm, trong khi Kịch bản sử dụng sẽ tránh cuộc thảo luận này.

Bạn chưa xác định cách bạn sẽ thực hiện nó.

Từ trang web sản phẩm nghệ thuật .


Điều này không thêm bất cứ điều gì ở trên và ngoài câu trả lời được chấp nhận đã được đăng hơn bảy năm trước. Hơn nữa, trích dẫn các nguồn là tốt, nhưng sẽ tốt hơn để giải thích nó bằng lời nói của bạn: văn bản có ý nghĩa gì với bạn?

Chỉ cần rõ ràng: không có gì sai khi trả lời các câu hỏi cũ. Stack Exchange không có chính sách chống hoại tử. Nhưng nếu bạn đến trễ cuộc thảo luận, vui lòng đảm bảo thêm thông tin mới, có thể là thông tin không có sẵn bảy năm trước.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.