Jawaban singkat : 830-1998 bukan standar, itu adalah praktik terbaik yang disarankan tentang cara menulis SRS dengan gaya 1998.
Saya tidak dapat menemukan bagaimana itu diunggulkan (bahkan dengan pencarian lanjutan IEEE :()
Tapi saya rasa itu karena seluruh metode tentang cara kami menentukan persyaratan telah berubah secara drastis dalam beberapa tahun terakhir.
Jadi, mulai sekarang, saya mencoba menjawab sedikit pertanyaan yang dimodifikasi:
Apa praktik terbaik industri / Apa praktik terbaik yang disarankan untuk menulis SRS dalam gaya 2012?
Pada metode klasik:
Biasanya saya menggunakan rekomendasi IEEE 1471 untuk dokumentasi perangkat lunak, walaupun itu juga diunggulkan oleh ISO / IEC 42010 baru-baru ini. Ini adalah jenis dokumentasi yang sangat kompleks, terutama digunakan untuk serah terima, meskipun sebagian besar berisi persyaratan (bab 7 di bagian dokumen gaya ISO baru)
Buku yang cukup bagus tentang dokumentasi formal adalah Mendokumentasikan Arsitektur Perangkat Lunak , buku mengejutkan yang bagus adalah buku ikonix lama , dan klasik lama adalah Kasus Penggunaan Efektif Penggunaan Cockburn .
Tentang bagaimana hal itu sebenarnya dilakukan dalam industri saat ini:
Sejujurnya, dokumentasi proyek formal, terutama dokumentasi persyaratan mati sebagian besar di usia Agile , karena Agile Manifesto tidak mendukung dokumentasi formal. Tidak ada satu, tunggal, spesifikasi formal besar, tetapi sebaliknya, ada yang disebut cerita pengguna , jaminan simpanan produk dan semacamnya. Ini karena pengembangan berulang, hanya sedikit fitur yang ditentukan secara informal untuk setiap siklus 2-4 minggu. Buku terkenal adalah User Stories Applied .
Ada yang disebut spesifikasi "dapat dieksekusi", yang formal , karena pada dasarnya adalah bahasa domain-spesifik (DSL) untuk pengujian. Mereka tidak lebih baik atau lebih buruk daripada OCL UML , tetapi mereka mungkin lebih mudah dipahami tetapi juga kurang ilmiah. Kebanyakan dari mereka disebut kerangka BDD, dan contohnya termasuk FitNesse , Mentimun , Jasmine - Anda akan menemukan banyak di antaranya. Ada juga buku-buku terkenal tentang BDD dan TDD pada umumnya.
Selain itu, spesifikasi oleh insinyur perangkat lunak diunggulkan oleh desain UX , termasuk arsitektur informasi dan desain interaksi, sehingga tidak dilakukan oleh orang yang benar-benar dapat mengkode saat ini, yang kadang-kadang dapat menyebabkan konflik. Ini adalah contoh yang tidak terlalu buruk tentang bagaimana seseorang terlihat (itu bukan standar!), Tetapi Anda akan menemukan lebih banyak di dalam komunitas interaksi UX /, tetapi bahkan ada situs pertukaran stackex terpisah untuk mereka. Mereka memiliki standar sendiri, praktik terbaik yang direkomendasikan, dll.
Tetapi bagaimana jika Anda ingin tetap menggunakan metode lama, misalnya. untuk pekerjaan di universitas?
Secara umum, cobalah untuk mematuhi IEEE 830 (tidak dapat menemukan di halaman web mereka apa yang digantikan dengan itu, meskipun IEEE tidak pernah bagus dengan ini, saya kira itu karena tidak masalah lagi sayangnya), dan pastikan Anda mencoba untuk merekam berguna informasi (misalnya, saya tidak berpikir bahwa sosok aktor tongkat tunggal -> tunggal gelembung dengan kata kerja-subjek dianggap berguna) dari mana keseluruhan tujuan dari para pengguna, secara keseluruhan rentang dari pengguna dan keseluruhan metode dari penggunaan dapat direkonstruksi kapan saja.
Mengapa Anda merekomendasikan buku? Mengapa Anda tidak menunjukkan kepada saya standar saja?
Sekali lagi, saya kira dokumen ini "diunggulkan" karena hari ini, kami memiliki sedikit kekacauan di sekitar spesifikasi persyaratan: ada banyak-banyak sudut pandang tentang bagaimana hal itu harus dilakukan.
Tidak ada otoritas tunggal yang dapat memberi tahu Anda: "ini adalah bagaimana spesifikasi harus dibuat" . Ada praktik terbaik , dan saya mencoba memberi Anda daftar dokumen dan arahan yang representatif , meskipun tidak lengkap, dan mungkin bias secara pribadi.
Pada akhirnya, yang penting adalah apakah dokumen yang Anda buat dapat memenuhi semua tujuan yang dimiliki semua orang yang pernah membacanya : apa yang ingin dilihat orang, apa yang perlu diketahui orang untuk memahami persyaratan dijelaskan dengan sangat baik dalam buku-buku ini, dan ini adalah praktik terbaik atas hak mereka sendiri, meskipun dalam komunitas yang jauh lebih kecil daripada komunitas IT tunggal yang tidak terbagi seperti yang kami miliki di tahun 1998.