Tài liệu đặc tả yêu cầu là những tài liệu yêu cầu chính thức về những gì cần phải thực hiện của đội phát triển phần mềm. Nó bao gồm tất cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu của hệ thống, không phải là tài liệu thiết kế hệ thống.

Như chúng ta biết “Hầu hết bugs trong phần mềm là do yêu cầu chức năng không đầy đủ hoặc không chính xác”. Mã phần mềm được viết thế nào không phải là vấn đề quan trọng, chúng ta sẽ không thể làm bất cứ điều gì nếu có những sự mơ hồ trong các yêu cầu.

Những sự mơ hồ về requirement và sửa chữa chúng trong thời gian sớm của vòng đời phát triển phần mềm là tốt nhất. Chi phí của việc sửa chữa lỗi sau khi phần mềm đã hoàn thành hoặc là đã release là khá cao. Vì vậy, điều quan trọng là có những phân tích yêu cầu và nắm bắt những yêu cầu chính xác trước khi thiết kế và giai đoạn thực hiện dự án.

• Làm thế nào để chắc chắn về sự hiểu đúng đắn của chúng ta về tài liệu đặc tả yêu cầu?

Chúng ta cần phải định nghĩa một vài tiêu chuẩn test và đảm bảo chắc chắn về sự hiểu đúng đắn của chúng ta về yêu cầu của phần mềm.

• Vậy nên làm thế nào để hiểu các yêu cầu trong thiết kế, thực hiện và kiểm tra các giai đoạn.

Khách hàng quy định các yêu cầu dự án cho giai đoạn đầu của sự phát triển của dự án. Khi bắt đầu thảo luận về các yêu cầu này mọi người đều có quan niệm riêng của mình về các yêu cầu, thấy rất nhiều sự mơ hồ về quy định tại các văn bản yêu cầu, mà cần phải gửi cho khách hàng để xem xét / làm rõ. Khách hàng sử dụng nhiều thuật ngữ mơ hồ, mà đã có rất nhiều ý nghĩa khác nhau, khó có thể phân tích ý nghĩa một cách chính xác nhất. 

Sau khi làm rõ các yêu cầu với khách hàng, phiên bản tiếp theo của các yêu cầu từ khách hàng đã rõ ràng, đủ để hiểu trong giai đoạn thiết kế.

“Yêu cầu phải rõ ràng và phù hợp”

Nhiều nhà thiết kế dự án không có ý tưởng rõ ràng về các module cụ thể và họ chỉ nghĩ đơn giản là thừa nhận một số yêu cầu trong giai đoạn thiết kế. Bất kỳ yêu cầu nào đều không nên được dựa trên các giả định. Yêu cầu phải được hoàn thành, bao phủ mỗi phần và toàn bộ các khía cạnh của hệ thống được phát triển.

Thông số kỹ thuật cần nêu cả hai loại: Những gì hệ thống nên làm và những gì không nên làm?

Để kiểm tra các yêu cầu tiến tới sự hoàn chỉnh, yêu cầu phân chia thành ba phần:

• Yêu cầu ‘Phải thực hiện’
• Những yêu cầu không quy định nhưng cần đưa ra các giả định để xác minh.
• Loại thứ ba là ‘tưởng tượng’ loại yêu cầu.

• Nhưng làm thế nào để quyết định các yêu cầu có liên quan hay không?

Câu trả lời đơn giản: Đặt mục tiêu dự án và đưa ra những câu hỏi cho những vấn đề liên quan: Nếu không thực hiện yêu cầu này sẽ gây ra vấn đề gì trong việc đạt được mục tiêu? Nếu không, thì đây là yêu cầu không liên quan. 

Trong đặc tả yêu cầu ngắn (SRS) nên giải quyết như sau:

• Chức năng của dự án (Điều gì nên làm và những gì không nên).
• Phần mềm, giao diện phần cứng và giao diện người dùng.
• Tính đúng đắn của hệ thống, an ninh và tiêu chí thực hiện.
• Vấn đề thực hiện (rủi ro)

Tags

ご質問がある場合、またはハチネットに協力する場合
こちらに情報を残してください。折り返しご連絡いたします。