Menulis Spesifikasi Kebutuhan Perangkat Lunak


15

Saya punya beberapa pertanyaan tentang menulis spesifikasi dan mereka adalah:

  1. Ketika kita menulis spesifikasi perangkat lunak, di bawah topik "Definisi persyaratan pengguna" kita harus menentukan "Fungsi" dan "Kendala" saja?

  2. Apakah "Antarmuka Pengguna" termasuk dalam "fungsi" atau "kendala"?

  3. Apa bidang utama utama (persyaratan) yang dapat dipecah oleh suatu perangkat lunak (misalnya UI)?


Artikel ini mungkin bermanfaat: 10 Kesalahan
Umum

Jawaban:


16

Walaupun saya bukan penggemar berat mengumpulkan semua persyaratan secara rinci di muka (karena mereka dapat berubah begitu banyak selama proyek non-sepele), jika Anda menulis dokumen persyaratan, template spesifikasi persyaratan Volere adalah panduan yang sangat baik .

Meskipun mungkin terlalu banyak untuk beberapa proyek, itu menyediakan daftar hal yang baik untuk dipikirkan, bahkan jika itu hanya untuk secara mental memeriksa daftar bahwa Anda tidak memerlukan item itu untuk persyaratan ini.

Berikut tautan ke informasi lebih lanjut tentang templat:

http://www.volere.co.uk/template.htm

Templat itu sendiri (dan buku Menguasai Proses Persyaratan - yang sebenarnya sedikit lebih murah daripada templat dan berisi teks templat lengkap) berisi banyak informasi, contoh, dan saran dalam berbagai bagian mengenai apa yang harus dilakukan di setiap bagian.

Berikut ringkasan bagian di dalamnya (dikutip dari tautan di atas):

  1. Tujuan Proyek

  2. Stakeholder

  3. Kendala yang Dimandatkan

  4. Konvensi dan Definisi Penamaan

  5. Fakta dan Asumsi yang Relevan

  6. Lingkup Pekerjaan

  7. Model Data Bisnis dan Kamus Data

  8. Lingkup Produk

  9. Persyaratan Fungsional dan Data

  10. Persyaratan Tampilan dan Perasaan

  11. Persyaratan Kegunaan dan Kemanusiaan

  12. Persyaratan Kinerja

  13. Persyaratan Operasional dan Lingkungan

  14. Persyaratan Perawatan dan Dukungan

  15. Persyaratan Keamanan

  16. Persyaratan Budaya dan Politik

  17. Persyaratan resmi

  18. Masalah Terbuka

  19. Solusi Off-the-Shelf

  20. Masalah baru

  21. Tugas

  22. Migrasi ke Produk Baru

  23. Risiko

  24. Biaya

  25. Dokumentasi dan Pelatihan Pengguna

  26. Ruang tunggu

  27. Gagasan untuk Solusi


10

Saya sarankan membaca Joel pada perangkat lunak. Saya tidak yakin apakah itu menjawab pertanyaan spesifik Anda, tetapi ia memiliki tinjauan yang sangat baik tentang apa artinya menulis spesifikasi fungsional :

Fungsi paling penting dari sebuah spesifikasi adalah merancang program . Bahkan jika Anda mengerjakan sendiri semua kode, dan Anda menulis spec semata-mata untuk keuntungan Anda sendiri, tindakan menulis spec - menggambarkan bagaimana program bekerja dalam detail kecil - akan memaksa Anda untuk benar-benar merancang program ...

... ketika Anda mendesain produk Anda dalam bahasa manusia, hanya perlu beberapa menit untuk mencoba memikirkan beberapa kemungkinan, merevisi, dan meningkatkan desain Anda. Tidak ada yang merasa buruk ketika mereka menghapus paragraf dalam pengolah kata. Tetapi ketika Anda mendesain produk Anda dalam bahasa pemrograman, perlu berminggu - minggu untuk melakukan desain berulang. Yang lebih buruk, seorang programmer yang hanya menghabiskan 2 minggu menulis beberapa kode akan sangat terikat pada kode itu, tidak peduli betapa salahnya ...

... Saat Anda menulis spec, Anda hanya perlu mengkomunikasikan bagaimana program seharusnya bekerja satu kali . Semua orang di tim bisa membaca spek. Orang-orang QA membacanya sehingga mereka tahu bagaimana program seharusnya bekerja dan mereka tahu apa yang harus diuji. Orang-orang pemasaran menggunakannya untuk menulis kertas putih vaporware samar-samar mereka untuk muntah di situs web tentang produk yang belum dibuat. Orang-orang pengembangan bisnis salah baca untuk memutar fantasi aneh tentang bagaimana produk akan menyembuhkan kebotakan dan kutil dan barang-barang, tetapi mendapat investor, jadi tidak apa-apa. Pengembang membacanya sehingga mereka tahu kode apa yang harus ditulis. Pelanggan membacanya untuk memastikan pengembang membangun produk yang ingin mereka bayar. Para penulis teknis membacanya dan menulis manual yang bagus ...

Ketika Anda tidak memiliki spec, semua komunikasi ini masih terjadi, karena itu harus , tetapi itu terjadi ad hoc . Orang-orang QA bermain-main dengan program mau tak mau, dan ketika sesuatu terlihat aneh, mereka pergi dan mengganggu para programmer lagi untuk mengajukan pertanyaan bodoh lain tentang bagaimana hal itu seharusnya bekerja ...

tanpa spesifikasi terperinci, tidak mungkin membuat jadwal ... Dalam terlalu banyak organisasi pemrograman, setiap kali ada perdebatan desain, tidak ada yang pernah berhasil membuat keputusan, biasanya karena alasan politik. Jadi programmer hanya mengerjakan hal-hal yang tidak kontroversial. Seiring berjalannya waktu, semua keputusan sulit didorong sampai akhir ... Menulis spec adalah cara yang bagus untuk menentukan semua keputusan desain yang menjengkelkan, besar dan kecil, yang ditutup-tutupi jika Anda tidak memiliki spec. ..


@gnat Saya pikir kutipan dari artikel itu tidak perlu. Jika Anda ingin menyorot pilihan kutipan Anda, saya sarankan Anda memposting jawaban Anda sendiri untuk pertanyaan itu.
Jonathan Swinney

pertimbangkan untuk membacakan jawaban Anda di kastil lain: kapan jawaban bukan jawaban? "biarkan saya jelas: respons semacam ini bukan jawaban . Jika Anda melihat ini, benderai. Moderator, jika Anda melihatnya ditandai, hapus "
gnat

1
Jika Anda tidak setuju dengan kutipan yang dikutip, silakan mengeditnya. Namun, memiliki jawaban yang hanya berupa tautan tidak dianggap sebagai jawaban yang baik dan dapat dihapus berdasarkan kebijakan mutu kami. Pos yang merujuk pada sumber atau referensi di luar situs harus menyediakan informasi yang cukup untuk terus menambah nilai jika tautan tidak dapat diakses karena alasan apa pun.
Thomas Owens

6

Ketika kita menulis spesifikasi perangkat lunak, di bawah topik "Definisi persyaratan pengguna" kita harus menentukan "Fungsi" dan "Kendala" saja?

Persyaratan adalah kombinasi dari dua hal ...

  1. Apa yang terjadi. Persyaratan fungsional.
  2. Seberapa baik melakukannya? Persyaratan Non Fungsional atau "Kendala"

Apakah "Antarmuka Pengguna" termasuk dalam "fungsi" atau "kendala"?

Saya akan mengatakan "Antarmuka Pengguna" akan menjadi kategori persyaratan seperti yang telah Anda identifikasi dalam pertanyaan terakhir Anda.

Apa bidang utama utama (persyaratan) yang dapat dipecah oleh suatu perangkat lunak (misalnya UI)?

Tergantung pada perangkat lunaknya. Anda dapat mengelompokkan persyaratan berdasarkan bagian sistem atau Anda dapat mengelompokkannya berdasarkan use case atau persyaratan bisnis yang dipenuhi fungsi.

Tentu saja semua ini adalah sekunder dari tujuan Anda yang sebenarnya yaitu untuk menentukan deskripsi yang jelas, tidak ambigu, dan dapat diuji dari sistem perangkat lunak.


4

Persyaratan utama untuk suatu persyaratan adalah bahwa ia dapat diuji. Jika Anda tidak dapat menemukan cara untuk menguji suatu persyaratan, kemungkinan besar itu tidak akan dilaksanakan seperti yang dimaksudkan penulis.

Saya belum pernah melihat dokumen persyaratan yang terbatas pada Fungsi dan Kendala saja, tetapi saya dapat melihat beberapa nilai dalam memiliki struktur seperti ini - memaksa penulis untuk mengkategorikan persyaratan menjadi "hal-hal yang perlu dilakukan perangkat lunak", dan "mengatur perangkat lunak perlu diikuti. "

Saya pikir antarmuka pengguna memiliki persyaratan di kedua kategori

Kendala:

  • "layar pengaktifan akan menampilkan dua tombol:" Mulai ", dan" Berhenti "
  • "Font tampilan tidak boleh lebih kecil dari 10 poin."

Fungsi:

  • "Ketika Starttombol ditekan, perangkat lunak harus membuat koneksi TCP / IP ke WOPR "

Contoh Anda bukan persyaratan, itu desain. Spesifik tentang bagaimana persyaratan harus dipenuhi adalah keputusan desain, bukan persyaratan. Jadi, "dua tombol" adalah keputusan desain. Menjadi jelas ketika Anda menyadari ada banyak cara lain yang valid untuk mencapai tujuan yang sama (Mulai atau Hentikan sesuatu). Jadi, untuk membuatnya lebih dari persyaratan Anda akan mengatakan "UI akan menyediakan sarana untuk Memulai dan Menghentikan sesuatu". Tapi saya akan melangkah lebih jauh, karena menggunakan UI juga merupakan keputusan desain. Jadi untuk persyaratan sistem, "Sistem harus menyediakan sarana untuk Memulai dan Menghentikan sesuatu"
Dunk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.