Câu trả lời ngắn : 830-1998 không phải là một tiêu chuẩn, đây là cách thực hành tốt nhất được đề xuất về cách viết SRS theo phong cách năm 1998.
Tôi không thể tìm thấy cách nó được siêu âm (ngay cả với tìm kiếm nâng cao của IEEE :()
Nhưng tôi đoán đó là vì toàn bộ phương pháp về cách chúng tôi xác định các yêu cầu đã thay đổi mạnh mẽ trong những năm gần đây.
Vì vậy, từ bây giờ, tôi cố gắng trả lời một chút câu hỏi đã sửa đổi:
Thực hành công nghiệp tốt nhất là gì / Những thực tiễn tốt nhất được đề xuất khi viết SRS theo phong cách năm 2012 là gì?
Về phương pháp cổ điển:
Thông thường tôi sử dụng các đề xuất của IEEE 1471 cho tài liệu phần mềm, mặc dù gần đây nó cũng được áp dụng bởi ISO / IEC 42010. Đây là một loại tài liệu rất phức tạp, nó chủ yếu được sử dụng cho chuyển giao, mặc dù nó chứa các yêu cầu chủ yếu (đó là chương 7 trong tài liệu kiểu ISO mới)
Một cuốn sách tốt vừa phải về tài liệu chính thức là Documenting Software Architectures , một cuốn sách hay đáng ngạc nhiên là cuốn sách iconix cũ , và một cuốn sách cổ điển cũ là Các trường hợp sử dụng hiệu quả bằng văn bản của Cockburn .
Về cách nó thực sự được thực hiện trong ngành công nghiệp ngày nay:
Sự thật mà nói, tài liệu dự án chính thức, đặc biệt là tài liệu yêu cầu đã bị tiêu diệt phần lớn trong thời đại của Agile , vì Tuyên ngôn Agile không khuyến khích tài liệu chính thức. Không có một, duy nhất, đặc điểm kỹ thuật chính thức lớn, nhưng thay vào đó, có cái gọi là câu chuyện người dùng , tồn đọng sản phẩm và như vậy. Điều này là do sự phát triển lặp lại, chỉ một số ít các tính năng được chỉ định không chính thức cho mỗi chu kỳ 2-4 tuần. Một cuốn sách nổi tiếng là Câu chuyện người dùng được áp dụng .
Có những cái gọi là thông số kỹ thuật "thực thi", là chính thức , vì về cơ bản chúng là ngôn ngữ dành riêng cho miền (DSL) để thử nghiệm. Chúng không tốt hơn hoặc kém hơn OCL của UML , nhưng có lẽ chúng dễ nắm bắt hơn nhưng cũng kém khoa học hơn. Hầu hết trong số chúng được gọi là khung BDD và các ví dụ bao gồm FitNesse , Dưa chuột , Hoa nhài - bạn sẽ tìm thấy một loạt lớn trong số này. Ngoài ra còn có những cuốn sách nổi tiếng về BDD và TDD nói chung.
Ngoài ra, đặc điểm kỹ thuật của các kỹ sư phần mềm được thiết kế bởi UX , bao gồm kiến trúc thông tin và thiết kế tương tác, do đó, những người thực sự có thể viết mã hiện nay có thể dẫn đến xung đột. Đây là một ví dụ không tồi về ngoại hình của một người (nó không phải là một tiêu chuẩn!), Nhưng bạn sẽ tìm thấy nhiều hơn nữa trong cộng đồng UX / tương tác, nhưng thậm chí còn có một trang web stackexchange riêng cho họ. Họ có tiêu chuẩn riêng, khuyến nghị thực hành tốt nhất, vv
Nhưng nếu bạn muốn gắn bó với các phương pháp cũ, vd. cho công việc đại học?
Nói chung, hãy cố gắng tuân thủ IEEE 830 (không thể tìm thấy trên trang web của họ những gì nó được sử dụng, mặc dù IEEE không bao giờ tốt với điều này, tôi đoán đó là vì nó không còn quan trọng nữa), và hãy chắc chắn rằng bạn đã thử để ghi lại thông tin hữu ích (ví dụ: tôi không nghĩ rằng một nhân vật dính một diễn viên -> bong bóng đơn với chủ đề động từ được coi là hữu ích) từ đó mục tiêu chung của người dùng, phạm vi tổng thể của người dùng và phương pháp tổng thể của việc sử dụng có thể được xây dựng lại bất cứ lúc nào.
Tại sao bạn giới thiệu sách? Tại sao bạn không chỉ cho tôi tiêu chuẩn thay thế?
Một lần nữa, tôi đoán tài liệu này là "siêu nhân" bởi vì ngày nay, chúng ta có một chút hỗn loạn xung quanh đặc tả yêu cầu: có rất nhiều quan điểm về cách nó nên được thực hiện.
Không có cơ quan duy nhất nào có thể nói với bạn: "đây là cách các thông số kỹ thuật nên được thực hiện" . Có những thực tiễn tốt nhất và tôi đã cố gắng cung cấp cho bạn một danh sách đại diện các tài liệu và hướng dẫn , mặc dù không có nghĩa là hoàn thành, và có lẽ là thành kiến cá nhân.
Vào cuối ngày, điều quan trọng là tài liệu bạn tạo ra có thể hoàn thành tất cả các mục tiêu mà tất cả những người từng đọc nó có : những gì mọi người muốn xem, những gì mọi người cần biết để hiểu các yêu cầu được mô tả khá tốt trong những cuốn sách này, và đây là những thực tiễn tốt nhất theo cách riêng của họ, mặc dù trong các cộng đồng nhỏ hơn nhiều so với một cộng đồng CNTT đơn lẻ, không phân chia những gì chúng ta có thể có vào năm 1998.