Câu chuyện người dùng vs Yêu cầu

Câu chuyện người dùng nắm bắt những gì người dùng muốn làm với hệ thống ở mức cao. Tôi hiểu rằng câu chuyện người dùng sẽ tiếp tục thúc đẩy một số yêu cầu cấp thấp. Là câu chuyện người dùng giống như yêu cầu cấp cao cho hệ thống?

Thành thật mà nói, sau khi dành gần hai năm đắm chìm trong phát triển Agile, tôi vẫn nghĩ "câu chuyện người dùng" chỉ là một thuật ngữ ưa thích cho "yêu cầu chức năng".

Nó khác ở mức độ hời hợt , ví dụ: nó luôn có một hình thức nhất định ( "là X, tôi muốn Y sao cho Z ..." ), nhưng các yếu tố chính - xác định các bên liên quan và lý do - cũng vốn có yêu cầu chức năng bằng văn bản. Thật dễ dàng để viết một câu chuyện người dùng tồi như viết một yêu cầu tồi ( "như [tên công ty của chúng tôi], tôi muốn [tính năng mơ hồ] để tôi có thể [làm điều gì đó rõ ràng là một phần công việc của tôi, như 'Bán nhiều hơn cho khách hàng'] " ).

Theo kinh nghiệm của tôi, những gì người dùng gần như không bao giờ nắm bắt được, là những yêu cầu phi chức năng như hiệu suất và bảo mật. Các loại yêu cầu này rất khó để viết đúng và định dạng của câu chuyện người dùng đơn giản là không tốt cho việc nắm bắt chúng, bởi vì chúng thiên về chất lượng sản phẩm chung và giảm thiểu rủi ro (nhưng không loại trừ) thay vì gặp một người dùng cụ thể nhu cầu.

Vì vậy, tôi thực sự nghĩ về các câu chuyện của người dùng như một tập hợp các yêu cầu, với một công thức cụ thể và vẫn sử dụng các thuật ngữ thay thế cho nhau khá nhiều.

Một câu chuyện lợi thế lớn của người dùng có các yêu cầu vượt trội là từ "yêu cầu" gợi ý rằng một tính năng được yêu cầu khi nó thường chỉ là mong muốn . Về lý thuyết, người dùng có thể được ưu tiên và đưa vào bất kỳ bản phát hành nào, trong khi các yêu cầu dường như là điều kiện tiên quyết cho mỗi bản phát hành.

Tất nhiên, để phân biệt được nói đến vấn đề, khách hàng và / hoặc quản lý cấp cao của bạn phải nắm lấy nó; bạn sẽ không có ích gì nếu bạn có 30 câu chuyện người dùng được nhóm lại thành một "dự án" mà tất cả phải được hoàn thành cùng một lúc. Bạn cũng có thể gọi chúng là "yêu cầu" trong trường hợp đó vì thực tế chúng là bắt buộc.

Ron Jeffries đã viết cách đây rất lâu về các câu chuyện của người dùng 3C ( http://xprogramming.com/articles/expcardconversation Confirm Confirmation ) với sự nhấn mạnh vào một thẻ (mô tả ngắn), cuộc trò chuyện giữa khách hàng và nhóm giao hàng một khi câu chuyện của người dùng trở thành hành động, và xác nhận đồng ý của một câu chuyện sau cuộc trò chuyện đó.

về cơ bản, trước cuộc trò chuyện, các câu chuyện của người dùng chỉ là phạm vi được lên kế hoạch - những ý tưởng sơ bộ về những gì chúng ta có thể làm. Sau cuộc trò chuyện, bạn nên có cách để xác nhận rằng câu chuyện đã hoàn thành. Vì vậy, tùy thuộc vào thời gian khi bạn xem câu chuyện trong dòng thời gian này, một câu chuyện có thể chỉ là một ý tưởng rộng về phạm vi hoặc một yêu cầu chi tiết.

ngày nay, ý nghĩa của "câu chuyện người dùng" dường như bị thu hẹp lại chỉ là phần "thẻ" trong phần 3 của Jeffries. trong trường hợp đó, một câu chuyện của người dùng không phải là một yêu cầu mà là một lời hứa sẽ tổ chức một cuộc trò chuyện về các yêu cầu.

Bạn có thể tìm thấy một tấn vàng khôn ngoan về những câu chuyện của người dùng trên wiki c2 ( http://xp.c2.com/UserStory.html )

Câu chuyện người dùng và yêu cầu là những con thú rất khác nhau.

Yêu cầu

Các yêu cầu giả định rằng thiết kế của ứng dụng được thực hiện trước và sự phát triển đó là việc thực hiện thiết kế đó. Do đó, yêu cầu tập trung vào cách thực hiện một chức năng.

Ví dụ về yêu cầu:

• Xây dựng biểu mẫu liên hệ người dùng với các trường sau: tên, họ, email, văn bản miễn phí và nút gửi. Khi nhấn nút gửi, một email sẽ được gửi đến nhóm hỗ trợ của chúng tôi.

Câu chuyện của người dùng

Câu chuyện của người dùng tập trung vào những gì cần đạt được và nhấn mạnh rằng thiết kế của sản phẩm được thực hiện vào phút cuối và đó là sự hợp tác giữa người sản phẩm và người phát triển. Các chi tiết được quyết định trong quá trình thực hiện dựa trên cơ hội.

Ví dụ về một câu chuyện:

• Là người dùng của Jimmy, tôi muốn liên hệ với nhóm hỗ trợ của bạn khi tôi không thể sử dụng trang web đúng cách để họ có thể giúp tôi.

Sự khác biệt là gì?

Như bạn có thể thấy, chắc chắn có sự khác biệt về số lượng chi tiết được cung cấp, nhưng cũng có rất nhiều thông tin chỉ có trong câu chuyện, cụ thể là mục đích mà chúng tôi đang cố gắng đạt được với tính năng này.

Mặc dù có vẻ như mục đích tương đối không quan trọng, đây là một giả định sai lầm trong phát triển nhanh. Thông thường có hai trường hợp trong đó biết mục đích là rất quan trọng: giảm chi phí cơ hội và cho phép sự nhanh nhẹn.

Chi phí cơ hội

Nếu có những giả định ẩn trong yêu cầu, nó có thể rất khó đạt được. Ví dụ: có máy chủ mail không? Nếu không, yêu cầu có thể mất nhiều thời gian hơn để được phát triển. Trong một số trường hợp khác, một cách đơn giản hơn để đạt được cùng một mục tiêu có thể bị bỏ qua vì thiết kế.

Ngược lại, câu chuyện của người dùng là về một người dùng liên hệ với bộ phận hỗ trợ của chúng tôi. Nếu việc gửi thư là không khả thi hoặc quá tốn kém, chúng ta có thể nghĩ ra một giải pháp khác ngay lập tức: ví dụ, viết vào cơ sở dữ liệu hoặc sử dụng một biểu mẫu qua tài liệu Google hoặc chỉ cần đặt địa chỉ email thay vì biểu mẫu. Điều này không thể dễ dàng thực hiện với một yêu cầu, nhưng nó dễ dàng được thực hiện với một câu chuyện và một người làm sản phẩm.

Nhanh nhẹn

Vì lý do này, với các yêu cầu chúng ta thường có xu hướng nghĩ về các giả định ẩn trước đó và đảm bảo không có bất kỳ trở ngại nào. Vì vậy, trong trường hợp này, có thể có một yêu cầu khác, được lên lịch trước, đảm bảo rằng một máy chủ thư có mặt.

Điều này dẫn chúng ta đến một sự khác biệt lớn giữa câu chuyện và yêu cầu đó là hệ thống phân cấp . Như tôi đã nêu ở trên, các yêu cầu phải, theo bản chất của chúng, phải được sắp xếp theo một số thứ bậc tự nhiên để đáp ứng sự phụ thuộc. Câu chuyện, mặt khác, tập trung vào mục đích và không có ràng buộc như vậy.

Điều này là do thiết kế, vì trong agile, điều quan trọng cơ bản là thêm, xóa, sắp xếp lại và sửa đổi các câu chuyện khi cần trong quá trình thực hiện dự án. Các yêu cầu thường có thể được thêm vào, đôi khi được sửa đổi hoặc loại bỏ, nhưng nói chung rất khó khăn để di chuyển chúng vì tất cả các phụ thuộc. Nó chỉ đơn giản là không được thực hiện rất thường xuyên. Nếu bạn đang làm việc với các yêu cầu, việc thực hiện nhanh nhẹn của bạn sẽ bị ảnh hưởng, hoặc có thể sẽ không nhanh nhẹn chút nào, theo nghĩa là có thể nắm lấy sự thay đổi.

Đối với tôi, một yếu tố quan trọng của Câu chuyện người dùng là nó nắm bắt Tại sao và Cách người dùng sử dụng hệ thống. Nó đặc biệt hữu ích vì nó không chỉ định nhiều về cách thức hệ thống cung cấp các chức năng cần thiết. Khi cần kiểm tra giao diện người dùng và khả năng sử dụng, Câu chuyện người dùng có thể là tài liệu quan trọng nhất.

Chắc chắn, bạn có thể yêu cầu selenium xác minh rằng các nút nhất định có trong HTML hoặc chụp ảnh màn hình hoặc xác minh rằng các pixel nhất định là nơi bạn hy vọng rằng chúng là. Nhưng nếu có văn bản gây hiểu lầm hoặc không rõ người dùng nên sử dụng hệ thống như thế nào hoặc người dùng khó có thể tìm ra cách đạt được mục tiêu của họ, đột nhiên bạn không còn có một hệ thống hoàn chỉnh nữa. Bây giờ đào tạo là cần thiết để sử dụng hệ thống. Xem xét hệ thống hoàn thành theo các kịch bản người dùng là một thành phần quan trọng của kiểm tra thủ công.

Có một bộ óc được ghi lại trong các câu chuyện / kịch bản của người dùng sẽ ảnh hưởng đến nhiều quyết định thiết kế chi tiết về việc triển khai. Trừ khi các nhà phát triển nói chuyện trực tiếp với người dùng hoặc xem họ sử dụng hệ thống, kịch bản người dùng có thể là liên kết duy nhất để cho phép họ hiểu nhu cầu của người dùng.

Cuối cùng, họ cho phép những người kinh doanh chỉ định những gì họ cần mà không gợi ý làm thế nào để đạt được điều đó. Việc mô tả một giải pháp sẽ dễ dàng hơn nhiều so với nhu cầu và các kịch bản người dùng cung cấp một khung để mô tả các nhu cầu mà không đề xuất một giải pháp cụ thể. Yêu cầu kinh doanh phổ biến nhất mà tôi đã nghe là "Tôi muốn nó giống như Excel, nhưng trên web" chưa bao giờ là thứ họ thực sự cần.

Vì vậy, tôi muốn nói rằng một câu chuyện hay không nên bao gồm bất kỳ chi tiết cụ thể nào về cách hệ thống nên được thực hiện. Nó sẽ nói, "Mỗi tháng một lần, hệ thống A cần được cập nhật với bất kỳ dữ liệu mới nào từ hệ thống B. Dữ liệu đó có thể yêu cầu sửa chữa. Khách hàng có lịch sử nhập dữ liệu không hợp lệ và không nhận ra vấn đề trong nhiều tuần." Không nên nói, "Hệ thống phải chấp nhận tệp CSV1 ít nhất một lần một tháng và ném NumberFormatException nếu cột 3 không phải là số." Bạn có thấy sự khác biệt? Kịch bản mô tả sự cần thiết, không phải bất kỳ giải pháp cụ thể. Sau đó, khi kiểm tra, bạn quay lại kịch bản để đảm bảo rằng giải pháp phù hợp với nhu cầu. Yêu cầu có thể trộn một số nhu cầu với một số giải pháp, hoặc thậm chí tập trung hoàn toàn vào các giải pháp.

Tình cờ gặp phải điều này trong một cuộc tìm kiếm trên google và nghĩ rằng tôi sẽ đưa ra ý kiến ​​của mình.

Thực sự không có sự khác biệt giữa một yêu cầu và một câu chuyện người dùng. Cả hai đều nêu rõ kết quả hoặc mục tiêu mong muốn từ góc độ người dùng.

Sự khác biệt duy nhất là cách mục tiêu hoặc kết quả này được nắm bắt bởi một nhà phân tích kinh doanh. Trong trường hợp này là trong từ ngữ.

Thí dụ:

Với tư cách là trưởng nhóm, tôi muốn xem nhóm nào của mình đang làm việc trong các vụ kiện thế chấp để tôi có thể theo dõi hiệu suất của họ.

Giải pháp sẽ hiển thị các thành viên trong nhóm làm việc trong các trường hợp thế chấp.

Cả hai điều trên có thể được diễn giải theo cùng một cách nhưng cả hai cũng có nhiều điều mơ hồ. Điểm chính ở đây là một sự khác biệt trong phong cách. Tôi nghĩ rằng vấn đề chúng ta chủ yếu nhìn thấy là chúng ta sẽ đi xa đến đâu để xác định giải pháp trước khi chúng ta rời khỏi thế giới yêu cầu và vào thế giới của thiết kế chức năng. Có phải nhà phân tích kinh doanh nói rõ "danh sách người dùng đã đăng nhập bằng tên thứ nhất và thứ hai trên menu ứng dụng chính" hay đó là quá nhiều thông tin? Khi chúng tôi ngồi nói chuyện với các bên liên quan và tất cả chúng tôi đều biết giải pháp và có thể diễn giải nó sẽ trông như thế nào, ngay cả ngôn ngữ mã có khả năng sẽ được xây dựng và cách nó sẽ được triển khai để chúng tôi thực sự cần chơi trò chơi thuần túy " hãy xác định mục tiêu chứ không phải giải pháp ". Đây là nơi tôi cảm thấy sự nhầm lẫn thực sự là.

Các yêu cầu thường đưa ra giả định mà chúng ta không biết gì về giải pháp chỉ là kết quả mong muốn. Vâng, điều này làm cho mọi thứ trở thành bất khả tri nhưng điều đó có thực sự giúp chúng ta trong chu kỳ phát triển không? Nếu chúng ta có thể xác định chính xác một cái gì đó sớm thì tại sao không làm điều đó?

Tất cả trong tất cả mặc dù tôi sẽ không lo lắng về những câu chuyện của người dùng và yêu cầu khác biệt. Cuối cùng, bạn muốn xác định đủ thông tin for.someone để phát triển một giải pháp. Một câu chuyện người dùng ở mức quá cao sẽ bị đánh bật lại và yêu cầu được chia thành các câu chuyện người dùng nhỏ hơn. Giống như kiểu "hệ thống sẽ". Yêu cầu có thể sẽ bị đánh bật lại vì quá mơ hồ nếu nó không có đủ chi tiết.

Cuối cùng đi với những gì các nhà phát triển và các bên liên quan của bạn muốn thấy và làm việc từ đó.

Tôi nghĩ rằng có rất nhiều sự không nhất quán về ý nghĩa của các yêu cầu từ, ngay cả trong sách giáo khoa cổ điển. Sự không nhất quán tương tự áp dụng cho các câu chuyện của người dùng. Các tổ chức và sách giáo khoa khác nhau đối xử với các điều khoản khác nhau. Ví dụ, cách mà sách giáo khoa Kỹ thuật phần mềm cổ điển của Roger Pressman nói về các yêu cầu khá khác so với sách Yêu cầu phần mềm Agile của Dean Leffingwell. Tôi tôn trọng cả hai và cả hai đều có thể hợp lệ.

Yêu cầu có thể là những thứ chúng ta mã hóa có tính đặc thù phi thường mà ít để lại cho trí tưởng tượng. Mặt khác, có thể lập luận rằng các yêu cầu nên chỉ định vấn đề kinh doanh là gì và không chỉ định giải pháp. Tôi nghĩ rằng nó có nhiều sắc thái hơn và câu trả lời nằm ở đâu đó trên một quang phổ duy nhất cho mỗi công ty và ngành công nghiệp (không phải tất cả sự phát triển phần mềm xảy ra trong CNTT).

Tôi được dạy rằng khơi gợi các yêu cầu dẫn đến phân tích, dẫn đến thiết kế, dẫn đến kiến ​​trúc dẫn đến xây dựng yêu cầu hoặc đặc tả kỹ thuật, dẫn đến một cái gì đó có thể được mã hóa. Tôi không tin điều này biến mất nhanh nhẹn. Thời điểm khi những điều này xảy ra không thay đổi và đó là sự khác biệt quan trọng nhất. Trong mô hình thác nước, khơi gợi và xây dựng xảy ra sớm. Trong nạc và scrum, khơi gợi và trau chuốt xảy ra ở các giai đoạn khác nhau với sự trau chuốt hơn xảy ra khi bạn tiến gần hơn đến việc thực hiện trong một lần chạy nước rút. Như thiết kế nổi lên làm việc.

Trong tổ chức của chúng tôi, chúng tôi đang nghiêng về mô hình sử thi, tính năng và câu chuyện của Leffingwell, không phải là yêu cầu mà là sự phân chia và ưu tiên công việc. Yêu cầu là một điều khác nhau. Các yêu cầu được quản lý riêng vì chúng tôi bắt buộc phải làm như vậy đối với các cơ quan quản lý. Tuy nhiên, một số nhóm chắc chắn đang phát triển các yêu cầu trong câu chuyện của người dùng trong quá trình tăng tốc chương trình và lập kế hoạch chạy nước rút.

Các yêu cầu chức năng thường là một đặc tả chính thức cho phép bạn biết chính xác nếu phần mềm của bạn hoạt động hay không. Câu chuyện người dùng thường là một cách không chính thức hơn nhiều để mô tả nhu cầu về một câu chuyện người dùng của bạn. Nó không chỉ định một đặc tả cứng nhắc để xác định xem phần mềm là "hợp lệ" hay "không hợp lệ". Mặc dù bạn có thể kiểm tra một phần của nó, nhưng việc hoàn thành thực sự câu chuyện người dùng (nếu bạn thực hiện đúng) là khi người dùng của bạn nói "vâng, điều đó giải quyết vấn đề của tôi!". Ghi nhớ bản tuyên ngôn nhanh nhẹn:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Trong cuốn sách "Câu chuyện người dùng được áp dụng", Mike Cohn nói cụ thể rằng một số điều không ánh xạ tới câu chuyện của người dùng và bạn không phải chỉ sử dụng điều đó.

Trong nhóm của riêng tôi, chúng tôi sử dụng như sau:

• Câu chuyện người dùng : một nhu cầu kinh doanh của một số loại người dùng. Nhấn mạnh ở đây là về nhu cầu , và tại sao anh ta cần nó. Như những người khác đã nói, điều quan trọng ở đây là không chỉ định cách thức thực hiện và đi sâu vào nhu cầu thực sự của người dùng (ví dụ: anh ta không cần xem dữ liệu trong bảng, anh ta cần xem giá trị chính xác của dữ liệu, và anh ta quen thuộc với bảng để làm việc đó).
• Lỗi : Một hành vi bất ngờ của phần mềm làm giảm khả năng sử dụng bình thường. Thường đi kèm với một "Tầm quan trọng" (không phụ thuộc vào mức độ ưu tiên của sự phát triển) đánh giá mức độ ảnh hưởng của nó đến quy trình làm việc của người dùng.
• Nợ kỹ thuật. Một cái gì đó không ngăn cản việc sử dụng phần mềm nhưng sẽ làm suy yếu chúng tôi , các nhà phát triển, trong tương lai. Ví dụ: một số lớp khó đọc, quá trình xây dựng chậm, một số mã không được kiểm tra đơn vị, IDE hiển thị các cảnh báo kỳ lạ ...
• Cải thiện : thay đổi phần mềm không cho phép các tình huống mới, nhưng mang lại trải nghiệm đẹp hơn. Ví dụ: thay đổi phông chữ, thiết kế lại một biểu mẫu để làm cho nó rõ ràng hơn, thêm mặc định hợp lý cho ứng dụng, v.v.

Các yêu cầu chức năng sẽ không cho phép chúng tôi nhận ra rằng một tính năng chúng tôi đã triển khai không giải quyết được nhu cầu của người dùng, mặc dù bài kiểm tra dưa chuột của chúng tôi đã vượt qua và chúng tôi đã triển khai mọi từ được viết. Một câu chuyện là một cuộc thảo luận, và nó không chính thức. Vấn đề là để những người thực hiện hiểu vấn đề là gì. Chúng không phải là một công cụ hợp đồng. Nếu bạn làm "scrum but ... " và câu chuyện của bạn chỉ đơn giản là một cách thú vị để viết các yêu cầu của phần mềm, thì có, không có sự khác biệt.

Vấn đề không phải là câu chuyện của người dùng, vấn đề là sự thay đổi lớn trong mô hình trong cách bạn tiếp cận công việc cần thực hiện. Bạn không làm hợp đồng, bạn đang giúp một số người dùng của bạn giải quyết vấn đề. Nếu bạn không xem các câu chuyện người dùng của mình là công cụ thảo luận với người dùng thực , thì bạn không sử dụng các câu chuyện của người dùng, bạn đang sử dụng cú pháp yêu cầu sôi nổi .

Phần còn lại ở đây là ý kiến ​​của tôi: câu chuyện của người dùng không bao giờ có thể thành công theo cách đơn phương. Bạn cần khách hàng của bạn để làm việc với nó. Water-scrum-fall chắc chắn là một mớ hỗn độn yêu cầu kỳ lạ nhưng không phải là yêu cầu. Nếu bạn có hợp đồng giá thầu cố định với các yêu cầu cụ thể, không sử dụng các lần lặp và câu chuyện người dùng, sẽ không có vấn đề gì . Sử dụng phần còn lại của bộ công cụ nhanh: Kiểm tra đơn vị / chức năng tự động, xem lại mã, tích hợp liên tục, tái cấu trúc, v.v ... Đảm bảo rằng phần mềm của bạn đang hoạt động liên tục và bạn có thể gửi nó ngay lập tức. Làm cho nó có sẵn ở dạng chưa hoàn thành của nó cho khách hàng để anh ta có thể cung cấp càng nhiều phản hồi càng tốt. Nếu bạn làm điều đó, bạn của tôi, ngay cả khi bạn không làm "Câu chuyện người dùng" và "Scrum", bạn sẽ nhanh nhẹn hơn nhiều người gọi là cửa hàng "Agile".

Tôi tin rằng mọi người sẽ thực hiện và gắn nhãn mọi thứ khác nhau tùy thuộc vào kinh nghiệm trong quá khứ và bất kỳ ngôn ngữ nào hoạt động cho công ty đó để hoàn thành công việc là không đáng để tranh cãi.

Tuy nhiên, IMO, Câu chuyện người dùng tuân theo cách tiếp cận của Agile về "khách hàng trong tòa nhà hoặc khách hàng có sẵn ngay lập tức", trong đó tài liệu không nhất thiết cần thiết bởi vì các chi tiết nằm trong đầu khách hàng và có sẵn để SRS chính thức có thể không bắt buộc Bây giờ "Nhiệm vụ" của "Câu chuyện người dùng" là cách nhà phát triển sẽ xây dựng các câu chuyện của người dùng theo tiêu hóa.

Một câu chuyện người dùng ví dụ có thể là:

Là người dùng quản trị, tôi muốn xem dữ liệu khách hàng của mình được liệt kê trong lưới

và một "nhiệm vụ" có thể là:

1. Tạo một lưới liệt kê dữ liệu sẽ được hiển thị

2. Bật Sắp xếp trên lưới sẽ sắp xếp cột được chọn

Bây giờ mỗi nhiệm vụ được ước tính và hoàn thành trong lần chạy nước rút tương ứng của nó.

Từ quan điểm "truyền thống", trong đó "khách hàng khó nắm bắt được, chúng tôi cần viết ra để họ có thể xác nhận rằng chúng tôi đã hiểu đúng trước khi chúng tôi bắt đầu lập kế hoạch / mã hóa", Đặc tả yêu cầu phần mềm là sẽ là những ý tưởng trong đầu khách hàng và được khơi gợi và sau đó được viết ra và chính thức hóa, sau đó được căn cứ và quản lý.

Trong trường hợp này, một "yêu cầu chức năng" là chi tiết khó chịu của SRS đó và là một phần của Ý tưởng lớn hơn. Vì vậy, theo tôi, một câu chuyện của người dùng có thể được coi là một phần của "Yêu cầu" chính thức và nhiệm vụ của câu chuyện người dùng đó là một (hoặc một trong nhiều) yêu cầu chức năng.

Trong câu chuyện người dùng mẫu, "Yêu cầu" chính thức sẽ là một tài liệu dài với các biểu đồ dòng chảy và nói chung sẽ là tài liệu lấy trung tâm, trái ngược với cách tiếp cận "Agile" lấy khách hàng làm trung tâm.

Sự khác biệt là, "Yêu cầu" chính thức sẽ nằm dọc theo dòng của một số tài liệu 10 trang phác thảo phần quản trị của ứng dụng cho biết một số danh sách sẽ cần thiết, một số bảo mật dựa trên vai trò, v.v. và sau đó là một số chức năng các yêu cầu sẽ là "các lưới liệt kê sẽ cho phép sắp xếp", "thông tin người dùng sẽ được liệt kê trong một lưới", v.v.

và tôi tin rằng những ngày này các điều khoản là hỗn hợp và trộn lẫn .. điều đó không quan trọng