10 đặc tính chất lượng đánh giá của một yêu cầu phần mềm

I. Giới thiệu

Yêu cầu phần mềm là tất cả các yêu cầu về phần mềm do khách hàng (người sử dụng phần mềm) nêu ra, bao gồm các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác. Mục đích của yêu cầu phần mềm là xác định khả năng đáp ứng của phần mềm với các yêu cầu và mong muốn cuả khách hàng (người sử dụng phần mềm). Để xây dựng một phần mềm tốt, cần phải có một yêu cầu phần mềm tốt. Có thể dựa vào một số tiêu chí để đánh giá yêu cầu phần mềm.

II. Các đặc tính chất lượng để đánh giá yêu cầu phần mềm

1. Đầy đủ

• Mỗi yêu cầu phải mô tả đầy đủ chức năng mà nó được giao. Nó phải bao gồm tất cả các thông tin cần thiết cho các nhà phát triển để thiết kế và thực hiện các chức năng đó. Nếu biết mình đang thiếu một số thông tin về các yêu cầu mềm, hãy đánh dấu nó lại. Chúng ta cụ thể hóa các thông tin còn thiếu của mỗi yêu cầu phần mềm trước khi chuyển qua giai đoạn tiếp theo là giai đoạn phân tích và thiết kế.

• Không có khách hàng nào yêu cầu chúng ta cần phải làm rõ toàn bộ các yêu cầu trước khi bắt đầu xây dựng yêu cầu đó. Trong thực tế, chúng ta sẽ không bao giờ xác định được đầy đủ các yêu cầu phần mềm. Mỗi dự án, cho dù theo bất cứ mô hình phát triển phần mềm nào, là mô hình sử dụng lặp đi lặp lại hoặc mô hình gia tăng cũng cần xác định đầy đủ các yêu cầu cho mỗi lần lặp lại vòng đời phần mềm. Sử dụng các yêu cầu phần mềm ở mức tối thiểu không đáp ứng được thực tế là có rất nhiều người khác nhau sử dụng phần mềm này, với những thói quen sử dụng và những quyền lợi khác nhau. Việc phát biểu các yêu cầu chi tiết bằng lời nói thay vì viết ra cũng gây khó khăn cho các nhà phân tích, phát triển, và kiểm thử khi muốn hiểu về các yêu cầu phần mềm.

2. Chính xác

• Mỗi yêu cầu phải mô tả chính xác các chức năng mà nó cần được xây dựng. Cần phân tích để xác định chính xác đâu là nơi có thể cung cấp các yêu cầu phần mềm chính xác, là người sử dụng thông thường hay người dùng cao câp của hệ thống. Một yêu cầu phần mềm mâu thuẫn với yêu cầu cao hơn nó là một yêu cầu phần mềm không chính xác. Chỉ có đại diện người sử dụng thực tế mới có thể xác định chính xác các yêu cầu của người sử dụng , đó cũng là lý do người sử dụng phải xem xét và duyệt lại các yêu cầu phần mềm.

3. Khả thi

• Yêu cầu phần mềm phải khả thi trong các giới hạn về kinh phí, thời gian, nhân lực, cũng như khả năng của nền tảng phát triển. Để tránh các yêu cầu phần mềm không thể đạt được, những kĩ sư phần mềm cần phải liên tục kiểm tra những gì có thể và không thể được thực hiện về mặt kỹ thuật hoặc vượt quá chi phí. Mô hình gia tăng và mô hình chế thử là một phương pháp tốt để liên tục đánh giá tính khả thi của yêu cầu phần mềm.

4. Cần thiết

• Mỗi yêu cầu nên ghi chép một khả năng mà các bên liên quan thực sự cần hoặc một trong đó là cần thiết cho phù hợp với yêu cầu một hệ thống bên ngoài hoặc một tiêu chuẩn. Mọi yêu cầu nên bắt nguồn từ một nguồn có thẩm quyền để xác định yêu cầu. Theo dõi từng yêu cầu cụ thể của khách hàng, chẳng hạn như một trường hợp sử dụng, một nguyên tắc kinh doanh, hoặc một số nguồn gốc khác.

5. Ưu tiên

• Chỉ định một ưu tiên thực hiện cho từng yêu cầu chức năng, tính năng, sử dụng trường hợp, hoặc câu chuyện người sử dụng để chỉ ra cách cần thiết đó là một thông cáo sản phẩm cụ thể. Nếu tất cả các yêu cầu được xem là quan trọng không kém, đó là khó khăn cho quản lý dự án để đối phó với cắt giảm ngân sách, vượt kế hoạch, nhân sự thiệt hại, hoặc các yêu cầu mới được thêm vào trong quá trình phát triển. Ưu tiên là một chìa khóa cần thiết để lặp đi lặp lại phát triển thành công.

6. Rõ ràng

• Tất cả yêu cầu nên được định nghĩa một cách duy nhất, giải thích phù hợp, sqr dụng ngôn ngữ tự nhiên rất dễ bị mơ hồ. Viết yêu cầu trong ngôn ngữ đơn giản, ngắn gọn, đơn giản phù hợp với lĩnh vực người dùng.

• "Hiểu" là một mục tiêu chất lượng yêu cầu liên quan tới "rõ ràng": người đọc phải có khả năng hiểu những gì từng yêu cầu được nói. Xác định tất cả về chuyên môn và các điều khoản có thể gây nhầm lẫn trong một thuật ngữ.

7. Kiểm chứng

• Xem liệu ta có thể đưa ra một vài bài kiểm tra hoặc sử dụng các phương pháp xác minh khác, chẳng hạn như thanh tra, kiểm thử, để xác định xem sản phẩm đúng cách thực hiện từng yêu cầu. Nếu một yêu cầu là không thể kiểm chứng được, cần xác định liệu nó sẽ được thực hiện một cách chính xác hay sẽ trở thành một vấn đề, không phân tích khách quan. Yêu cầu đó là không đầy đủ, không phù hợp, không khả thi, hoặc không rõ ràng cũng chưa được kiểm chứng.

8. Phù hợp

• Phù hợp yêu cầu không mâu thuẫn với các yêu cầu khác cùng loại hoặc với kinh doanh cao cấp, hệ thống, hoặc yêu cầu người sử dụng. Bất đồng giữa các yêu cầu phải được giải quyết trước khi phát triển có thể tiến hành. Nếu chúng ta phát hiện ra một cặp yêu cầu mâu thuẫn, ta có thể không biết cái nào (nếu một trong hai) là chính xác cho đến khi ta làm một số nghiên cứu. Ghi lại nguồn gốc của từng yêu cầu cho phép bạn biết ai để nói chuyện với nếu bạn phát hiện ra xung đột.

9. Sửa đổi

• Chúng ta phải có khả năng sửa đổi các SRS khi cần thiết để duy trì một lịch sử thay đổi được thực hiện với từng nhu cầu. Điều này nói lên rằng mỗi yêu cầu được dán nhãn duy nhất và thể hiện riêng rẽ với các yêu cầu khác để ta có thể đề cập đến nó một cách rõ ràng. Mỗi yêu cầu sẽ xuất hiện chỉ một lần trong SRS.
• Thật dễ dàng để tạo ra mâu thuẫn bằng cách thay đổi chỉ có một thể hiện của một yêu cầu nhân đôi. Xem xét chéo tham khảo trường hợp tiếp theo trở lại báo cáo ban đầu thay vì sao chép các yêu cầu. Một bảng của nội dung và chỉ số sẽ làm cho SRS dễ dàng hơn để thay đổi. Yêu cầu lưu trữ trong một cơ sở dữ liệu hoặc một công cụ quản lý yêu cầu thương mại làm cho họ thành các đối tượng tái sử dụng.

10. Theo dõi

• Một yêu cầu theo dõi có thể được liên kết ngược đến nguồn gốc của nó và chuyển tiếp đến các yếu tố thiết kế và mã nguồn mà thực hiện nó và với các trường hợp thử nghiệm kiểm tra việc thực hiện là đúng. Yêu cầu truy xuất nguồn gốc được dán nhãn duy nhất với định danh liên tục. Chúng được viết theo một cách có cấu trúc liền mạch trái ngược với đoạn tự sự dài. Tránh gộp nhiều yêu cầu lại với nhau, các yêu cầu cá nhân có thể theo dõi để thiết kế khác nhau.

III. Kết luận

Trên đây là 10 tiêu chí đánh giá chung cho một yêu cầu phần mềm. Dựa vào các tiêu chí này ta có thể đánh giá, xây dựng một yêu cầu phần mềm tốt, giúp việc phát triển phần mềm trở nên dễ dàng và hiệu quả hơn.

IV. Tài liệu tham khảo

• http://ptgmedia.pearsoncmg.com/images/9780735679665/samplepages/9780735679665.pdf