Apa cara yang tepat untuk membuat dokumen persyaratan?


23

Saat ini atasan saya sedang membuat dokumentasi persyaratan / spesifikasi untuk saya menggunakan perangkat lunak bugtracking. Ini sepertinya ide yang buruk bagi saya, semua persyaratan ada di tiket kecil ini dan saya harus mengklik di webform bodoh ini untuk mendapatkan persyaratan. Apa solusi perangkat lunak yang waras untuk persyaratan / spesifikasi perangkat lunak?

Untuk lebih jelasnya, saya sedang membangun komponen perangkat lunak yang besar ini dengan beberapa fitur dan fitur-fitur ini ditetapkan dalam perangkat lunak bugtracking ini.

Jawaban:


17

Saya agak terkejut bahwa tidak ada yang sejauh ini merekomendasikan penggunaan wiki untuk persyaratan pelacakan.

Saya menemukan ini sebagai sistem yang hampir sempurna, karena:

  • Ini memungkinkan orang untuk berkolaborasi pada persyaratan dan membuat aspek ini sangat terlihat;
  • Ini memungkinkan Anda untuk dengan mudah memperbarui persyaratan saat proyek berlangsung;
  • Anda dapat masuk dan melihat sejarah kapan saja, dalam kasus perselisihan "bukan itu yang kami sepakati";
  • Kebanyakan wiki modern memiliki kemampuan pemformatan yang layak, sehingga terlihat hampir sebagus dokumen Word;
  • Anda dapat hyperlink langsung dari persyaratan Anda ke dalam dokumentasi aktual;
  • Anda tidak perlu khawatir tentang orang yang mengerjakan salinan berbeda / usang;
  • Persyaratan dapat mulai diperlakukan sebagai proses berulang, seperti halnya desain / implementasi;
  • Jika persyaratan mulai menjadi sangat besar / rumit, mudah untuk membaginya di seluruh halaman / topik.
  • Kebanyakan wiki menerima HTML, jadi jika Anda benar-benar membutuhkan pemformatan tingkat lanjut, Anda mungkin dapat menggunakan alat seperti Windows Live Writer .

Diberi pilihan, saya hampir selalu memilih metode wiki hari ini, itu benar-benar sangat menyakitkan dibandingkan dengan dokumen Word kuno atau mencoba menjejalkan semuanya ke dalam pelacak bug.


Saya telah menemukan bahwa Anda dapat dengan relatif mudah menanamkan data dari sistem pelacakan Anda ke wiki Anda, dan jika Anda mengatur beberapa bug hierarkis Anda dapat mengelompokkannya ke dalam persyaratan, maka tonggak proyek memiliki halaman wiki, seperti halnya proyek, dan pelanggan serta itu semua mudah untuk mendapatkan kepala Anda di sekitar. Wiki lem, tetapi masih menggunakan pelacak bug. Selidiki kemampuan pelacak bug Anda untuk menunjuk ke halaman web di wiki!
Tim Williscroft

Tentu saja, wiki bukan pengganti untuk sistem pelacakan bug, itu pelengkap. Perencanaan dan kolaborasi proyek paling baik dilakukan di wiki; masalah masih perlu dilacak pada IMS atau antrian prioritas.
Aaronaught

6

Saya selalu menggunakan IEEE Std 830-1998 (Praktek yang Dianjurkan IEEE untuk Spesifikasi Kebutuhan Perangkat Lunak) sebagai templat untuk dokumen SRS saya. Lihat http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Dokumen SRS final itu sendiri biasanya merupakan dokumen OpenOffice.org tunggal, tetapi biasanya ada banyak bagian penyusunnya, termasuk spreadsheet dan diagram.

Saya biasanya meletakkan semua dokumen ini dalam repositori yang saya masukkan ke dalam sistem kontrol revisi , seperti SVN atau CVS. Semua analis bisnis, perancang, pengembang, penguji, manajer proyek, dan klien lainnya memiliki akses ke repositori ini, sehingga mereka dapat membacanya dan melakukan pengeditan.

Ingat, SRS adalah dokumen yang hidup dan terus berkembang. Itu akan terus berubah dan tumbuh untuk beberapa waktu. Tidak hanya penting bagi semua pemangku kepentingan untuk memiliki akses ke SRS, tetapi juga penting untuk memiliki sejarah perubahan yang lengkap, dan kemampuan untuk mengembalikan perubahan ini juga, jika perlu. Jadi sistem kontrol revisi berfungsi baik untuk tujuan ini. Semoga berhasil!


5

Menggunakan bug-tracker untuk manajemen kebutuhan memiliki kecenderungan untuk menyembunyikan kurangnya kolaborasi dan komunikasi di dalam perusahaan.

Tanpa menjatuhkan penilaian pada metode tertentu:

  • jika Anda akan menggunakan air terjun, Anda memerlukan dokumen multi-halaman yang terstruktur dengan baik, akurat, dan banyak (bukan satu paragraf yang banyak orang ketik sebagai deskripsi bug). Dokumen-dokumen ini juga tidak mungkin ditulis dan dipelihara pada tingkat kualitas yang layak jika tenaga pemasaran / penjualan (yang berasal dari persyaratan) tidak bekerja dengan baik bersama dengan staf teknik.
  • jika Anda akan menggunakan salah satu metode gesit, maka satu unit persyaratan adalah cerita pengguna, diwakili oleh kartu cerita. Kartu itu sendiri bukan keharusan, hanya titik awal dari percakapan.

Pengalaman (singkat) dari salah satu majikan saya di masa lalu dengan menggunakan pelacak bug untuk persyaratan adalah memberi banyak orang cara yang sangat mudah untuk berhenti berkomunikasi sepenuhnya. Orang-orang hanya menulis permintaan, membuangnya di pelacak bug, dan menganggap itu akhirnya menjadi kenyataan.

Tentu saja mereka melakukannya tanpa memperhatikan:

  • kualifikasi mereka sendiri
  • saham mereka dalam proyek tersebut
  • konflik dengan persyaratan lain
  • kesenjangan dalam persyaratan
  • biaya
  • pertimbangan teknis
  • dll.

TAPI ... begitu persyaratan tidak lengkap dimasukkan, maka akan ditetapkan, & siapa pun yang ditugaskan untuk menyelesaikan informasi tidak lengkap bukan? Maksud saya begitu ada di sistem, dengan anggapan orang tidak menjatuhkan barang, bukankah seharusnya diselesaikan? Saya tidak menyarankan orang awam perangkat lunak yang lengkap untuk memasukkan item, tetapi bahkan jika mereka melakukannya .. itu ada di sistem & harus ditangani. Contoh: bisnis menambahkan persyaratan "tanda terima cetak" ke pelacak bug & menugaskannya ke analis bus, analis bus memprosesnya dengan mengisi lubang (melalui lebih banyak komunikasi jika perlu), lalu dev mendapatkannya.
John MacIntyre

Tidakkah gangguan komunikasi menjadi gejala masalah proses? (niat tulus)
John MacIntyre

@JohnMacIntyre (1): hasilnya ping-pong bukan kolaborasi. Penugasan tidak selalu merupakan orang yang tepat, masalah yang jarang dapat diselesaikan hanya oleh satu orang; di mana lebih banyak orang dibutuhkan, penerima tugas jarang memiliki wewenang untuk mengarahkan mereka apa yang harus dilakukan, jarang melihat semua dependensi (persyaratan jarang independen); yang hilang adalah manfaat
swasusun

@JohnMacIntyre (2): gangguan komunikasi tentu saja merupakan tanda bahwa proses mereka tidak berfungsi atau bahwa mereka tidak memiliki proses apa pun atau mereka hanya tidak memiliki komunikasi dan budaya kolaborasi yang sehat di perusahaan mereka. Posisi saya adalah mereka harus mengatasi akar penyebab itu.
azheglov

@asheglov - Saya kira ini bisa menjadi masalah jika penerima hak adalah pelaksana dan tidak diizinkan untuk menetapkan kembali atau berbicara dengan siapa pun. Tetapi posisi saya bukanlah itu alat, dan bahwa ini akan terjadi dengan alat terbaik bukan?
John MacIntyre

2

Saya percaya bahwa dokumen "Word" adalah cara yang salah untuk mencari persyaratan, karena alasan berikut:

  1. Tidak ada cara untuk "membedakan" dua dokumen untuk melihat apa yang telah berubah.
  2. Antarmuka pengguna mencegah penggunaan gaya yang konsisten di seluruh. Ya, menggunakan gaya dapat dilakukan, tetapi kebanyakan orang tidak dapat diganggu karena kesulitannya.
  3. Format dokumen pada dasarnya tersembunyi. Tentu, ada spesifikasi untuk file OLE, yang saya kira dokumen "Word" adalah, tetapi Microsoft telah mengubur semua yang berguna di bawah banyak omong, jadi tidak ada yang benar-benar tahu. Cepat atau lambat, "Word" Anda yang mengkilap dan baru tidak akan membuka dokumen.
  4. Tidak bermain dengan baik dengan format lain. Yaitu, kecuali Anda menggunakan Windows dan IE, Anda tidak beruntung jika seseorang mengatur dokumen proyek dalam file HTML dengan tautan ke file format "Word". Klik tautan yang salah, dan Anda harus duduk selama periode unduhan-dan-mulai-kata yang panjang, mengganggu alur pemikiran. Hyperlink dari dokumen "Word" kepada orang lain mungkin berfungsi atau tidak.
  5. "Word" pada dasarnya untuk menulis dokumen yang dimaksudkan untuk muncul di atas kertas. Tujuan yang mengagumkan, tetapi tujuan yang membuatnya kurang berguna untuk dilihat secara online.

Saya tidak punya saran alternatif yang saya punya pengalaman, tapi saya sudah memikirkan tentang Teks Terstruktur atau Penurunan Harga Python sebagai alternatif.


1
Saya pikir sebagian besar argumen ini terdengar seperti FUD. Word mungkin bukan pilihan terbaik, tetapi tidak seburuk itu: 1. Ini memiliki fitur revisi / kolaborasi yang cukup bagus untuk melacak dan menerima / menolak perubahan, sehingga jauh lebih ramah pengguna daripada alat vcs + diff lainnya. 2. Gaya lebih menonjol sejak pita UI 2007. Menjelaskan mengapa gaya harus digunakan mungkin lebih mudah daripada menjelaskan seluruh perangkat lunak baru 3. Word terbaru dapat membaca / menyimpan file Word 97 yang dibuat 16 tahun yang lalu. Word 2003 dapat membaca / menyimpan file 2010 menggunakan paket kompatibilitas. Saya setuju dengan 4. dan 5. meskipun pdf dapat menjadi pilihan untuk dilihat secara online.
kapex

@kapep - argumen saya bukan FUD dalam arti klasik "Ketakutan, Ketidakpastian dan Keraguan", mungkin Anda menggunakan "FUD" dengan cara yang berbeda. Setiap argumen saya dapat dijawab. Misalnya, Anda bisa mengatakan "Lakukan kontrol-shift- @ pada menu" Sisipkan "untuk mendapatkan perbedaan baris demi baris dari dokumen saat ini terhadap dokumen lain". Itu tidak bisa dilakukan, karena semua yang Anda tawarkan adalah pendapat yang berlawanan. Microsoft memiliki sejarah meninggalkan format dokumen, atau setidaknya membuatnya mahal atau sulit untuk menggunakan format lama, yang meningkatkan penjualan, saya kira.
Bruce Ediger

Ok saya harus mengoreksi saya, hanya 3. tampaknya menjadi argumen FUD yang sering digunakan ketika datang ke bashing kata / doc untuk menjadi milik. Tentu format microsoft ditinggalkan - tetapi file doc telah ada sejak waktu yang sangat lama, jadi 'cepat atau lambat' hanya berlaku untuk versi kuno dari abad lalu, jika mereka memutuskan untuk meninggalkan dukungan di> 2016 atau kapan kata berikutnya akan dirilis. Saya juga hanya ingin menunjukkan bahwa ada cara mudah untuk "membedakan" dokumen. Tentu saja itu tidak membandingkan baris per baris, itu tidak masuk akal dalam format berbasis non-baris. Ini lebih seperti inline diff di sini di SE.
kapex

2

Kami umumnya menggunakan Word, tetapi pada kenyataannya bagaimana Anda membuatnya dalam perangkat lunak lebih penting daripada bagaimana Anda mengumpulkan data untuk membuatnya dan apakah orang yang mengumpulkan informasi cukup tahu untuk mengetahui kapan suatu persyaratan terlalu rumit dan akan jauh lebih mahal daripada persyaratan yang lebih sederhana namun tidak menambahkan nilai nyata kepada siapa pun (seperti ketika mereka menginginkan nomor ID untuk selalu diberikan agar tidak pernah dilewati) atau ketika itu akan bertentangan dengan persyaratan yang ada atau fitur yang direncanakan lainnya. Seringkali pengguna yang sebenarnya tidak pernah diajak bicara dan ada banyak kejutan ketika manajer mereka tidak tahu sesuatu yang benar-benar harus dilakukan dan itu tidak ada dalam versi baru dari perangkat lunak.

Kami juga dapat menggunakan berbagai file pdf, Excel atau Visio. Semuanya untuk proyek dikumpulkan dan diedit dari SharePoint, jadi kita bisa melihat versi sebelumnya jika perlu.


1

Saya memelihara jaminan simpanan produk (satu per proyek atau produk) yang berisi Cerita Pengguna . Mereka dapat disimpan dalam perangkat lunak pelacakan bug seperti yang Anda gunakan. Saya pribadi menggunakan Excel untuk backlog dan Trac untuk sprint backlog (Anda mungkin menggunakan alat seperti alat itu).

Saat diperlukan saja, saya membuat dokumen Word yang menggambarkan Kisah Pengguna dengan lebih detail dan melampirkannya ke cerita pengguna. Tapi saya mencoba menghindari ini dengan membagi cerita pengguna menjadi cerita yang lebih kecil.

Cerita pengguna kecil lebih mudah dikelola (termasuk estimasi)

Saya suka dokumen Word karena memungkinkan saya untuk meletakkan tautan, memformat teks, meletakkan tabel, tangkapan layar, dan lainnya, dan semua orang dapat membacanya.

Tentu saja, setiap Kisah Pengguna dijelaskan secara rinci dalam sesi estimasi, dan perencanaan sprint, dan saya selalu tersedia untuk lebih banyak pertanyaan ketika pengembang memutuskan untuk mengerjakannya. Umpan balik yang sering menggunakan tinjauan sprint mencegah pengembang melakukan sesuatu yang berbeda dari yang diminta oleh pemilik produk.


1

Secara pribadi, di masa lalu saya telah menggunakan Dokumen Word, tetapi telah memutuskan untuk menemukan alat di masa depan untuk mengelola ini untuk saya ... terutama dengan kemampuan untuk mengatur bug ke persyaratan, karena banyak waktu, bug tersebut dalam persyaratan, bukan penyimpangan antara spesifikasi & implementasi.

Bahkan tidak pernah terpikir oleh saya untuk menggunakan alat pelacak bug, tetapi itu masuk akal.

Karena penasaran, apa tentang hal yang tidak Anda sukai?

EDIT: satu peringatan; beri tahu manajer Anda untuk mengubah citra perangkat lunak pelacakan bug. Kalau tidak, semua yang ada di dalamnya dianggap bug. Saya memiliki masalah politik ini di klien terakhir saya, di mana saya menempatkan tugas di pelacak bug. Tidak baik.


1

Saya menulis persyaratan database 6 atau 7 tahun yang lalu untuk menangani ini. Setiap catatan kebutuhan memiliki deskripsi singkat, memo "definisi", dan memo "catatan" (keduanya kaya teks, dengan kemampuan untuk menyematkan tangkapan layar, dll.). Ada bidang-bidang lain juga, untuk proyek, yang dapat dikirim, nomor urut (sehingga dapat dipesan secara logis), kasus penggunaan / fitur yang terkait dengan, perkiraan waktu, bidang untuk orang yang menanganinya, jika seseorang telah memilihnya untuk implementasi, dll.

Ada juga "Status" - "Dimasukkan", untuk sementara kami merancang fitur; "Disetujui", ditetapkan setelah sekelompok persyaratan ditinjau dan ditentukan untuk siap diimplementasikan; "Diimplementasikan", ditetapkan oleh programmer begitu mereka berpikir persyaratan telah selesai, dan "Divalidasi" begitu teknologi QA setuju dengan programmer. (Jika teknologi QA tidak setuju, ia dapat mengaturnya kembali ke "Disetujui" sehingga programmer mendapatkannya kembali.) Persyaratan juga dapat "Ditangguhkan", "Ditolak" atau "Dipertanyakan" (artinya Dewan Kontrol Perubahan perlu melihatnya .)

Trik untuk melakukan ini dengan baik adalah rincian yang wajar. Terkadang masuk akal untuk memiliki satu persyaratan kalimat (mis. "Masalah yang dijelaskan dalam edisi 12345 sudah diperbaiki"), tetapi secara umum, persyaratan harus menggambarkan semua aspek penting dari seluruh fitur (atau sebagian besar dari satu fitur). Misalnya, fitur "laporan baru" yang khas akan memiliki persyaratan untuk format laporan (seperti apa outputnya), dan persyaratan untuk dialog opsi (menjelaskan bidang, validasi, dll.) Bahkan mungkin ada yang ketiga jika ada generator yang rumit mengolah data, bukan hanya permintaan mudah atau sesuatu. Selain itu, kami akan membuat persyaratan "Bantuan" untuk topik bantuan yang sesuai.

Ada keuntungan besar menyimpan hal-hal ini dalam catatan basis data daripada dokumen besar. Banyak pemrogram dapat mengerjakan persyaratan pada saat yang bersamaan. Catatan individual dikunci sehingga hanya satu orang yang dapat mengedit pada satu waktu, tetapi mereka dapat dibuka dan dibaca ketika orang lain sedang mengedit. Namun, keuntungan terbesarnya adalah menyediakan dokumentasi yang mudah untuk mencari apa saja persyaratannya, dan mencatat bagaimana penerapannya. Kami memiliki lebih dari 25.000 persyaratan di sana sekarang, dan kami dapat dengan mudah menemukan semua persyaratan dengan kata-kata spesifik di semua bidang, atau definisi, atau catatan, atau apa pun, dalam waktu kurang dari 10 detik. (Cobalah dengan dokumen Word senilai 6+ tahun.)

Saya dapat melihat mengapa orang mungkin mengatakan itu adalah ide yang buruk untuk melakukan persyaratan dalam "pelacak bug", tetapi dugaan saya adalah itu karena alat menghisap, bukan karena menjaga persyaratan dalam database yang dapat dicari adalah ide yang buruk.


1
Ada perangkat lunak pelacakan persyaratan komersial yang tersedia, seperti PINTU.
M. Dudley

1

Saya pernah menggunakan http://www.pivotaltracker.com/ tetapi di perusahaan saya saat ini kami menggunakan .doc sebagai sumber spesifikasi inti dan Lighthouse sebagai fitur gabungan wishlist & pelacakan masalah. Bagi saya sulit untuk membuat orang lain di tim mulai menggunakan alat lain ketika mereka sudah terbiasa dengan Word.


0

Jika Anda dapat mengikuti metodologi Agile, tautan berikut dapat memandu Anda dalam memilih alat Manajemen Proyek Agile yang baik:

Dan sungguh-sungguh, cobalah metodologi Agile - ia mengajarkan pendekatan yang sederhana, elegan, tanpa basa-basi, tanpa jazzy, dan masuk akal dalam apa pun yang Anda lakukan, sehingga setiap anggota tim memahami dan menghargai peran dan upaya setiap anggota lainnya.

Semoga berhasil!

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.