Đặc tả yêu cầu hệ thống bằng câu chuyện người dùng

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu phát triển phần mềm hướng hành vi ứng dụng công cụ behat 001 (Trang 21 - 24)

CHƯƠNG 1. KIỂM THỬ TRONG PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOA ̣T

1.3. Đặc tả yêu cầu hệ thống bằng câu chuyện người dùng

Trong quá trình phát triển phần mềm, để bàn giao đƣợc sản phẩm đáp ứng các yêu cầu nghiệp vụ của khách hàng thì việc tiếp nhận và mô tả yêu cầu của hệ thống cần có những cách thức phù hợp. Có một số phương pháp thường dùng nhƣ: biểu đồ ca sử dụng (user – case); đặc tả yêu cầu phần mềm theo IEEE 830;thiết kế ngữ cản h tương tác;câu chuyện người dùng (user story), …[5].

Trong các quy trình phát triển phần mềm theo phương pháp linh hoạt Agile để mô tả các yêu cầu hệ thống thường sử du ̣ng câu chuyê ̣n người dùng . Một câu chuyện người dùng thường bao gồm ba phần:

 Tiêu đề: Chứa một mô tả ngắn gọn, rõ ràng để xác định câu chuyện, còn đƣợc gọi là mẫu chuyện (story card).

 Mô tả - thân (Narrative):Thân câu chuyê ̣n là các mô tả để làm rõ chi tiết của câu chuyện, trong phần thân câu chuyê ̣nít chú tro ̣ng đến viê ̣c viết tài liê ̣u , thay vào đó là nhấn mạnh vào việc giao tiếp với khách hàng để cócâu chuyê ̣n.

Phần thân câu chuyê ̣n bao gồm các thông tin:

+ Ai (khách hàng hoặc thành viên đội phát triển) giữ vai trò chính trong câu chuyện đó.

+ Kết quả mà tác nhân đó mong muốn ở câu chuyện

+ Giá trị nghiệp vụmà tác nhân sẽ nhận đƣợc từ kết quả đó.

 Các tiêu chí kiểm thử chấp nhận: Là các tiêu chí để xác định điểm kết thúc câu chuyê ̣n, phần này mô tả các trường hợp cụ thể cho từng câu chuyê ̣n:

+ Mô tả m ột hoặc nhiều mệnh đề giả định điều kiện đúng trước khi khởi tạo ngữ cảnh.

+ Tiếp theo, xác định các sự kiện khởi tạo ngữ cảnh.

+ Cuối cùng, xác định các kết quả mong muốn trong một hoặc nhiều mệnh đề.

Một câu chuyện người dùng thường mô tả một tính năng tương đối hoàn chỉnh và ít phụ thuộc vào câu chuyện người dùng khác, điều đó giúp việc thay đổi yêu cầu trong quá trình phát triển dự án dễ dàng hơn, bởi khi thay đổi một câu chuyện người dùng hay thay đổi độ ưu tiên của nó thì dự án vẫn có thể tiếp tục được tiến hành bằng cách đưa vào vòng lặp các câu chuyện người dùng khác mà không làm ảnh hưởng đến tiến trình chung của dự án.

Quá trình xác định câu chuyện người dùng nên làm rõ các lớp người sử dụng, vai trò của khách hàng, đối tượng sẽ tương tác trực tiếp với hê ̣ thống ở câu chuyê ̣n đó. Việc xác định vai trò của người sử dụng rất quan trọng, quyết đinh giá trị mà hệ thống sẽ mang lại cho người sử dụng. Một câu chuyện người dùng có thể rất quan trọng cho lớp người dùng này nhưng lại ít quan trọng với các đối tượng khác. Sau khi xác định được người dùng nắm vai trò sử dụng trực tiếp thì câu chuyện người dùng được viết theo quan điểm của người dùng đó, điều này giúp cho việc phát triển hệ thống theo đúng mong muốn của người sử dụng.

Kiểm thử chấp nhận là một phần của câu chuyện người dùng bởi vì trong mỗi câu chuyện người dùngmô tả các tiêu chíđể xác định khi nào thì câu chuyện người dùng được đặt ở trạng thái kết thúc. Có hai vấn đề quan trọng trong kiểm thử chấp nhận và các câu chuyện người dùng.

 Thƣ́ nhất : Kiểm thử chấp nhận là kết quả của việc trao đổi giữa khách hàng và đội phát triển.

 Thứ hai: Việc trao được tiến hành trước khi một câu chuyện người dùng đƣợc cài đặt.

Điều này có nghĩa là kiểm thử chấp nhận được tiến hành trước khi cài đặt chương trình và kiểm thử đó phải do khách hàng viết hoặc được viết với sự tham gia của khách hàng nhằm mục đích làm cho sản phẩm phần mềm đáp ứng đúng mong muốn của người sử dụng, tăng độ tin cậy của sản phẩm. Đểviếtcâu chuyện người dùng có các bước cơ bản như sau:

i. Xác định mục đích của câu chuyện.

ii. Phân rã câu chuyện: Đối với các câu chuyện đã đƣợc định nghĩa quá dài và phức tạp thì ta có thể chia nhỏ chúng thành nhiều câu chuyện nhỏ hơn, tuy nhiên việc chia nhỏ này vẫn phải đảm bảo tính chất khép kín của câu chuyện.

iii. Giới hạn kích thước câu chuyện: Chi tiết của câu chuyện quyết đi ̣nh cách cài đặt câu chuyê ̣n đó . Do vâ ̣y, tùy thuộc vào kích thước, tầm quan tro ̣ng câu chuyện sẽ đƣợc xếp hạng ƣu tiên để làm tiêu chí đƣa vào các vòng lặp.

iv. Không áp đặt giao diện sử dụng cho câu chuyê ̣n : Khi xác định câu chuyện chỉ nên tổng quát hóa, câu chuyê ̣n không được phụ thuộc vào giao diện người dùng. Giao diện người dùng nên để phát triển ở giai đoạn sau.

v. Mô tả vai trò của người sử du ̣ng trong câu chuyện: Khi mô tả câu chuyê ̣n người dùng cần mô tả cả vai trò của người sử du ̣ng nó vào nô ̣i dung câu chuyê ̣n . Điều này giúp cho câu chuyê ̣n dễ hiểu và các tiêu chí kiểm thử chấp nhận đƣợc rõ ràng hơn.

Câu chuyê ̣n người dùng thường được viết dưới da ̣ng ngôn ngữ tự nhiên để

khách hàng có thể hiểu được và tự viết câu chuyện người dùng cho sản phẩm . Tuy nhiên, câu chuyện người dùng thường được mô tả theo mô ̣t da ̣ng thức thống nhất, giúp cho đội phát triển và người dùng cùng thống nhất cách hiểu về câu chuyê ̣n đó, viê ̣c lƣ̣a cho ̣n da ̣ng thƣ́c biểu diễn tùy tƣ̀ng dƣ̣ án , tùy thuộc vào văn hóa và ngôn ngữ của người sử du ̣ng . Mô ̣t da ̣ng thức phổ biến để biểu diễn câu chuyê ̣n người dùng như sau:

As a <User Role>

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu phát triển phần mềm hướng hành vi ứng dụng công cụ behat 001 (Trang 21 - 24)

Tải bản đầy đủ (PDF)

(112 trang)