Câu hỏi: SWR302 - Phần 6: Đặc tả yêu cầu và cách viết yêu cầu tốt

Để xác định template phù hợp với yêu cầu ví dụ được viết dựa trên quan điểm của hệ thống, chúng ta cần phân tích yêu cầu. Yêu cầu yêu cầu hệ thống hiển thị danh sách tất cả các thùng chứa hóa chất đang có trong kho nếu hóa chất được tìm thấy trong kho hóa chất. Template phù hợp với yêu cầu này là 'optional precondition optional trigger event the system shall expected system response'. Template này mô tả các điều kiện không bắt buộc, sự kiện kích hoạt và phản hồi của hệ thống khi đáp ứng yêu cầu.

Khi phát triển SRS (Software Requirements Specification), bạn sẽ gặp phải một số thách thức. Thứ nhất, việc thêm tính năng mới, đưa ra giả định và vượt quá phạm vi yêu cầu. Điều này có thể dẫn đến sự phức tạp và khó khăn trong việc quản lý yêu cầu. Thứ hai, việc phát triển ý tưởng, chẳng hạn như trên một miếng vải hoặc một bảng trắng. Điều này có thể dẫn đến sự không rõ ràng và khó khăn trong việc xác định yêu cầu. Thứ ba, khách hàng biết rõ những gì họ muốn nhưng ý tưởng hoặc câu trả lời của họ không rõ ràng. Điều này có thể dẫn đến sự khó khăn trong việc hiểu và thực hiện yêu cầu.

Câu hỏi này yêu cầu bạn chọn phương pháp không thường được sử dụng để đại diện cho yêu cầu phần mềm. Các lựa chọn bao gồm: mô tả bằng ngôn ngữ tự nhiên được cấu trúc và viết cẩn thận, mô hình hình ảnh minh họa quá trình biến đổi, trạng thái hệ thống và thay đổi giữa chúng, mối quan hệ dữ liệu, luồng logic và các yếu tố khác; định nghĩa yêu cầu bằng cách sử dụng ngôn ngữ mô tả chính xác toán học; ngôn ngữ được bạn 'tạo ra' và viết theo ý thích của mình. Lựa chọn không thường được sử dụng là 'ngôn ngữ được bạn 'tạo ra' và viết theo ý thích của mình'. Điều này là vì các yêu cầu phần mềm thường được xác định rõ ràng và cụ thể, và không nên được viết theo ý thích cá nhân của người viết.

Mẫu bản yêu cầu chung được viết từ góc độ người dùng được thể hiện như sau: "Tên lớp người dùng hoặc tên người dùng tham gia shall được phép làm gì với một đối tượng Điều kiện đủ Thời gian hoặc chất lượng phản hồi" Ví dụ: "Người dùng khách hàng shall được phép đặt hàng trực tuyến Điều kiện đủ: khách hàng đã đăng ký tài khoản Thời gian phản hồi: trong vòng 5 phút Chất lượng phản hồi: chính xác 100%" Mẫu này cho phép người dùng thể hiện rõ yêu cầu của mình từ góc độ người dùng, giúp cho việc viết yêu cầu trở nên rõ ràng và dễ hiểu hơn.

Các thuật ngữ sau có thể được sử dụng thay thế cho nhau. Dưới đây là giải thích về các thuật ngữ này và thuật ngữ tiêu chuẩn trong ngành công nghiệp.

Trong kỹ thuật yêu cầu, tài liệu tự do có một số vấn đề. Thứ nhất, tài liệu tự do hạn chế sử dụng tham chiếu trước (Limited Use of Forward References). Điều này có nghĩa là người đọc phải tìm kiếm thông tin trong tài liệu trước khi có thể hiểu được các khái niệm mới. Thứ hai, tài liệu tự do khó địa hóa thông tin cụ thể (Hard to localize specific information). Điều này có nghĩa là khi cần tìm kiếm thông tin cụ thể trong tài liệu, người đọc phải dành nhiều thời gian và công sức để tìm kiếm. Các vấn đề này có thể làm giảm hiệu quả và hiệu suất trong quá trình yêu cầu.

Khi viết SRS, việc ghi nhãn các yêu cầu là rất quan trọng. Điều này cho phép chúng ta tham khảo các yêu cầu cụ thể trong yêu cầu thay đổi, lịch sử sửa đổi, liên kết, hoặc ma trận theo dõi yêu cầu. Ngoài ra, việc ghi nhãn yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong nhiều dự án khác nhau. Điều này giúp tiết kiệm thời gian và công sức trong quá trình phát triển phần mềm. Hơn nữa, việc ghi nhãn yêu cầu cũng giúp cải thiện sự hợp tác giữa các thành viên trong nhóm khi họ thảo luận về các yêu cầu.

Đáp án đúng: "System feature". Trong mẫu đặc tả yêu cầu phần mềm (Software Requirements Specification), mục Overall description (mô tả tổng quan) gồm các tiểu mục mô tả bối cảnh sản phẩm: "Product perspective" (vị trí sản phẩm trong hệ thống lớn hơn), "User classes and characteristics" (các nhóm người dùng và đặc điểm của họ), "Operating environment" (môi trường vận hành), "Design and implementation constraints" (ràng buộc thiết kế và cài đặt) và "Assumptions and dependencies" (giả định và phụ thuộc). Cả năm mục này đều đúng là thành phần của Overall description nên không được chọn. Còn System features là một chương riêng của mẫu SRS, nơi mô tả từng tính năng kèm yêu cầu chức năng chi tiết, không thuộc phần mô tả tổng quan, vì vậy đây là câu trả lời cho câu hỏi dạng NOT.

Đáp án đúng gồm ba ý: "Feasible", "Correct" và "Verifiable". Một phát biểu yêu cầu tốt cần các đặc tính như đầy đủ, đúng, khả thi, cần thiết, có ưu tiên, không mơ hồ và kiểm chứng được. Feasible (khả thi) nghĩa là có thể cài đặt được với công nghệ, ngân sách và thời gian của dự án. Correct (đúng) nghĩa là phát biểu mô tả chính xác điều bên liên quan cần, được xác nhận bởi nguồn của yêu cầu. Verifiable (kiểm chứng được) nghĩa là có thể thiết kế kiểm thử hay phép đo để biết yêu cầu đã được đáp ứng hay chưa. "Flexible" sai vì linh hoạt không phải đặc tính của một phát biểu yêu cầu tốt; một yêu cầu được viết lỏng để dễ diễn giải theo nhiều cách thực chất là mơ hồ, đi ngược tiêu chí không mơ hồ và kiểm chứng được. Linh hoạt có thể là một thuộc tính chất lượng của hệ thống, nhưng đó là nội dung yêu cầu chứ không phải phẩm chất của câu chữ.

Câu tuyên bố trên cho rằng tất cả màn hình trong hệ thống phải tải nhanh chóng. Để đánh giá tính chính xác và khả thi của tuyên bố này, chúng ta cần xem xét từng khía cạnh. Tính chính xác (correct) của tuyên bố này có thể được đánh giá là đúng vì nó xác định rõ yêu cầu về tốc độ tải màn hình. Tuy nhiên, tính khả thi (feasible) của tuyên bố này có thể không hoàn toàn đúng vì tốc độ tải màn hình phụ thuộc vào nhiều yếu tố như cấu hình hệ thống, dung lượng dữ liệu, và hiệu suất phần cứng. Vì vậy, tuyên bố này có thể được đánh giá là 'Correct và Feasible' nhưng với một số hạn chế.

Đáp án đúng: "External interface requirements". Trong khuôn mẫu SRS (đặc tả yêu cầu phần mềm) phổ biến, mục External interface requirements (yêu cầu giao diện ngoài) mô tả mọi điểm hệ thống tiếp xúc với bên ngoài, chia thành giao diện người dùng, giao diện phần mềm, giao diện phần cứng và giao diện truyền thông; vì vậy user interfaces (giao diện người dùng) thuộc mục này. Phương án "Overall description" sai vì mục này trình bày bối cảnh: góc nhìn sản phẩm, các lớp người dùng, môi trường vận hành, ràng buộc và giả định. Phương án "System features" chứa các yêu cầu chức năng được nhóm theo tính năng, không đặc tả giao diện. Phương án "Data requirements" chứa mô hình dữ liệu logic, từ điển dữ liệu, báo cáo và yêu cầu toàn vẹn, lưu trữ dữ liệu.

Mục tiêu quan trọng của việc viết yêu cầu là đảm bảo rằng bất kỳ ai đọc yêu cầu đều có cùng hiểu biết về yêu cầu đó. Điều này có nghĩa là yêu cầu phải rõ ràng, dễ hiểu và không gây nhầm lẫn. Mục tiêu này giúp tránh những hiểu lầm không cần thiết và đảm bảo rằng tất cả các bên liên quan đều có cùng mục tiêu. Ví dụ, nếu yêu cầu không rõ ràng, một người đọc có thể hiểu nó một cách khác với người đọc khác, dẫn đến việc thực hiện sai yêu cầu. Vì vậy, việc viết yêu cầu một cách rõ ràng và dễ hiểu là rất quan trọng để đảm bảo rằng tất cả các bên liên quan đều có cùng hiểu biết về yêu cầu.

Đáp án đúng: "Design features". Khuôn đặc tả yêu cầu phần mềm (SRS) mô tả hệ thống phải làm gì chứ không mô tả nó được thiết kế ra sao, nên không có mục đặc điểm thiết kế; thiết kế chỉ xuất hiện dưới dạng ràng buộc thiết kế và triển khai mà khách hàng áp đặt. Các mục điển hình của khuôn SRS gồm giới thiệu, mô tả tổng quan, tính năng hệ thống, yêu cầu dữ liệu, yêu cầu giao diện bên ngoài và thuộc tính chất lượng. "Quality Attributes" là mục ghi yêu cầu phi chức năng như hiệu năng, bảo mật, khả dụng. "External interface" là mục mô tả giao diện người dùng, phần mềm, phần cứng và giao tiếp với bên ngoài. "Data requirements" mô tả mô hình dữ liệu logic, từ điển dữ liệu, báo cáo. "System features" là phần chính chứa các yêu cầu chức năng nhóm theo tính năng.

Đáp án đúng: "Ensuring clarity, consistency, and avoiding ambiguities". Hệ thống phức tạp có rất nhiều yêu cầu đan xen giữa nhiều nhóm người dùng và hệ thống con, nên thách thức chính của việc đặc tả là viết sao cho mỗi yêu cầu rõ ràng, các yêu cầu không mâu thuẫn nhau và không có cách hiểu kép; đây là các đặc tính chất lượng của một bộ yêu cầu tốt mà hoạt động đặc tả và thẩm định phải bảo đảm. Phương án "Eliminating low-priority requirements" sai vì yêu cầu ưu tiên thấp vẫn được ghi lại và có thể làm ở bản sau; ưu tiên hóa không phải thách thức của việc viết tài liệu. Phương án "Skipping stakeholder validation" là một thói quen xấu, không phải thách thức cần vượt qua. Phương án "Focusing only on functional needs" sai vì hệ thống phức tạp càng cần đặc tả cả yêu cầu phi chức năng như hiệu năng, bảo mật, độ tin cậy.

Đáp án đúng: "Consistency, ensuring that requirements do not conflict with other requirements or higher-level business, user, or system requirements.". Ngoài đặc tính của từng yêu cầu riêng lẻ, cả tập yêu cầu còn phải có bốn đặc tính: complete (đầy đủ), consistent (nhất quán), modifiable (sửa được) và traceable (truy vết được). Định nghĩa nhất quán trong đáp án là đúng: yêu cầu không mâu thuẫn nhau và không mâu thuẫn với yêu cầu nghiệp vụ, yêu cầu người dùng hay yêu cầu hệ thống ở tầng trên. "Completeness, meaning it is acceptable if some necessary information is absent as long as the core requirements are documented." sai vì đầy đủ nghĩa là không thiếu thông tin cần thiết, chỗ chưa biết phải đánh dấu TBD. "Modifiability, which allows changes to be made without maintaining a history of changes or considering dependencies among requirements" sai vì sửa được đòi hỏi giữ lịch sử thay đổi và nắm quan hệ giữa các yêu cầu. "Traceability, where requirements should be loosely linked and not necessarily connected to their origin or to derived elements" sai vì truy vết đòi hỏi nối mỗi yêu cầu ngược về nguồn gốc và xuôi tới thiết kế, mã, test.

Đáp án đúng gồm hai ý: "More detail should be included when the work is being done for an external client or when system testing will be based on the requirements." và "Less detail can be included if the work is being done internally for your company and developers have considerable domain experience." Mức chi tiết của yêu cầu (level of detail) không cố định mà tuỳ bối cảnh: càng nhiều người đọc ở xa, càng ít cơ hội hỏi lại trực tiếp và càng nhiều thứ dựa vào tài liệu thì càng phải viết chi tiết. Khách hàng bên ngoài cần yêu cầu đủ rõ để làm căn cứ nghiệm thu và hợp đồng, còn kiểm thử hệ thống dựa trên yêu cầu thì cần đủ chi tiết để thiết kế ca kiểm thử. Ngược lại, dự án nội bộ với đội phát triển giàu kiến thức miền (domain experience) và gần người dùng có thể viết gọn hơn vì khoảng trống được lấp bằng trao đổi trực tiếp. Phương án "always necessary to specify all requirements at the same high level of detail" sai vì ép một mức chi tiết đồng nhất cho mọi yêu cầu, trong khi yêu cầu rủi ro cao mới cần chi tiết nhất. Phương án "fine-grained level is always better, regardless of the project’s context" sai vì chi tiết quá mức tốn công viết, khó bảo trì và không thêm giá trị khi người đọc đã hiểu rõ.

Trong tài liệu yêu cầu, giả định về người dùng của phần mềm được mô tả ở phần mô tả đặc điểm của người dùng. Đây là phần quan trọng để hiểu rõ về đối tượng sử dụng phần mềm, bao gồm cả đặc điểm cá nhân, kỹ năng và kinh nghiệm của họ. Thông tin này sẽ giúp các nhà phát triển tạo ra phần mềm phù hợp với nhu cầu và khả năng của người dùng, từ đó đảm bảo rằng phần mềm được sử dụng một cách hiệu quả và an toàn.

Trong ngành công nghiệp phần mềm, thuật ngữ tiêu chuẩn để chỉ các điều kiện trao đổi là 'Software Requirements Specification' (SRS). Điều này là một tài liệu chi tiết mô tả các yêu cầu của phần mềm, bao gồm cả các yêu cầu chức năng và phi chức năng. SRS được sử dụng để xác định các yêu cầu của phần mềm, giúp cho việc phát triển phần mềm trở nên hiệu quả hơn. Nó cũng giúp cho việc giao tiếp giữa các thành viên trong đội ngũ phát triển phần mềm trở nên dễ dàng hơn. SRS thường bao gồm các phần như mô tả tổng quan, mô tả chức năng, mô tả phi chức năng, và các yêu cầu cụ thể.

Khi viết Specification yêu cầu phần mềm, bạn nên viết chi tiết hơn trong trường hợp nào? Câu trả lời đúng là khi khách hàng tham gia sâu vào quá trình phát triển phần mềm. Điều này có nghĩa là khách hàng sẽ tham gia vào các cuộc thảo luận, cung cấp thông tin chi tiết về yêu cầu của họ và sẽ được cập nhật thường xuyên về tiến độ của dự án. Việc này giúp đảm bảo rằng phần mềm cuối cùng được phát triển đáp ứng đúng nhu cầu của khách hàng và giảm thiểu khả năng xảy ra sai sót. Ngoài ra, việc khách hàng tham gia sâu vào quá trình phát triển cũng giúp tăng cường sự hiểu biết và đồng thuận giữa các bên liên quan, từ đó giúp dự án được hoàn thành một cách hiệu quả hơn.

Tính chất xuất sắc của yêu cầu là tính nhất quán. Tính nhất quán trong yêu cầu có nghĩa là các yêu cầu không xung đột với nhau hoặc với các yêu cầu ở cấp cao hơn như yêu cầu kinh doanh, yêu cầu người dùng hoặc yêu cầu hệ thống. Điều này đảm bảo rằng các yêu cầu được thống nhất và không mâu thuẫn với nhau, giúp cho việc triển khai và thực hiện dự án trở nên dễ dàng hơn. Ví dụ, nếu một yêu cầu yêu cầu một chức năng cụ thể, thì các yêu cầu khác không nên yêu cầu chức năng đó. Tính nhất quán giúp đảm bảo rằng các yêu cầu được rõ ràng và dễ hiểu, giảm thiểu khả năng xảy ra sai sót trong quá trình triển khai.