Joel on Software

Joel on Software   Pojok Software Joel

 

Artikel-artikel "Joel on Software" lain dalam bahasa Indonesia

Artikel-artikel "Joel on Software" lain dalam bahasa Inggris

Email pengarang (hanya dalam bahasa Inggris)

 

Functional Specification yang Mudah - Bagian 2: Apa itu Spec?


Oleh Joel Spolsky
Diterjemahkan oleh Mas Agung Sachli
3 Oktober 2000

(Apakah anda telah membaca bagian satu? Kalau belum, baca dulu).

Kumpulan artikel ini mengenai spesifikasi fungsional, bukan spesifikasi teknis. Orang sering rancu dengan keduanya. Saya tidak tahu apakah ada standard istilah tersebut, namun definisi yang saya pergunakan adalah:.

  1. Sebuah functional specification menggambarkan bagaimana sebuah produk harus berjalan dari sudut pandang user. Dia tidak perduli dengan bagaimana hal itu diimplementasikan. Dia hanya membicarakan fitur. Dia membicarakan tentang Tampilan layar, menu, dialog, dan seterusnya.
  2. Sebuah technical specification menggambarkan implementasi internal dari program tersebut. Dia membicarakan tentang struktur data, model hubungan database, pemilihan bahasa pemrograman dan alat bantu, algoritma, dll.

Saat anda mendisain sebuah produk secara detail, hal yang paling penting untuk dicermati adalah hal yang dialami user. Tampilannya seperti apa, bagaimana mereka bekerja, apa yang mereka lakukan. Selanjutnya, anda perlu pikirkan bagaimana perpindahan dari sini ke sana. Tidak akan ada perdebatan tentang bahasa pemrograman apa yang akan dipakai sebelum memutuskan apa yang akan dilakukan oleh produk anda. Dalam kumpulan ini, saya hanya membicarakan tentang spesifikasi fungsional.

Saya telah menulis sebuah contoh spec kecil yang bisa memberikan anda gambaran seperti apa sebuah spesifikasi fungsional yang baik. Sebelum kita bergerak lebih jauh, silahkan membaca contoh spec tersebut.

Anda telah membacanya?

Tidak, anda belum baca. Sana, baca sekarang dan kemudian kembali lagi, sehingga kita dapat berbicara lebih banyak tentang apa yang harus dan tidak boleh dimiliki oleh sebuah spec yang baik. Saya akan tunggu anda di sini. Terima kasih.

(menunggu dengan sabar...)

[Image]

Ah, bagus. Anda telah kembali.

Ini beberapa hal yang saya tulis di setiap spec.

Sebuah disclaimer. Murni merupakan pembelaan diri. Jika anda menulis sesuatu seperti: "Spec ini belum lengkap", orang tidak akan datang ke kantor anda untuk menggigit kepala anda. Seiring perjalanan waktu, saat spec mulai selesai, anda dapat mengubahnya menjadi "sepanjang pengetahuan saya, spec ini telah lengkap, namun jika saya lupa sesuatu, silahkan beritahu saya". Hal ini mengingatkan saya, setiap spec memerlukan:

Seorang Penulis. Satu Penulis. Banyak perusahaan yang berpikir bahwa spec harus ditulis oleh sebuah tim. Jika anda pernah mencoba menulis secara berkelompok, anda tahu bahwa tidak ada hal yang lebih buruk lagi. Penulisan berkelompok hanya dilakukan oleh perusahaan konsultasi managemen yang dipersenjatai dengan lulusan baru pendidikan Harvard yang memerlukan berton-ton pekerjaan sehingga sesuai dengan bayaran mereka yang mahal. Spec anda harus dimiliki dan ditulis oleh satu orang. Jika anda mempunyai satu produk yang besar, pisahkan menjadi beberapa bagian dan berikan masing-masing area kepada orang yang berbeda untuk melakukannya. Perusahaan yang lain akan berpikir bahwa hal itu sangat egois atau bukan "pemain tim yang baik" untuk orang yang "menerima pengakuan" di sebuah spec dengan meletakkan namanya di situ. Omong kosong. Orang harus menerima tanggung jawab dan rasa memiliki atas hal yang mereka lakukan. Jika ada sesuatu yang salah dengan spec tersebut, harus ada pemilik spec, yang namanya ditulis di situ, yang harus bertanggung jawab untuk memperbaikinya.

Skenario. Saat anda sedang mendisain sebuah produk, anda perlu mempunyai bayangan beberapa skenario yang nyata bagaimana orang akan memakainya. Kalau tidak maka ujung-ujungnya adalah anda mendisain sebuah produk yang tidak ada hubungannya dengan dunia nyata (seperti Cue?Cat). Tentukan pemakai produk anda dan bayangkan sebuah cerita, benar-benar sebuah bayangan namun harus merupakan pengguna yang umum dari setiap kelompok yang menggunakan produk tersebut dengan cara yang benar-benar biasa. Bab 9 dari buku saya tentang mendisain UI (tersedia secara online gratis) membicarakan tentang menciptakan pengguna fiktif dan skenario. Di sinilah tempat anda meletakkan mereka. Semakin jelas dan realistis skenario tersebut, semakin baik pekerjaan anda dalam mendisain sebuah produk bagi pengguna nyata dan imajiner anda, yang menjelaskan kenapa saya cenderung memberikan begitu banyak detail yang dikarang.

Bukan tujuan. Saat anda sedang membangun sebuah produk dengan sebuah tim, setiap orang cenderung mempunyai fitur favorit, nyata ataupun khayalan yang harus mereka miliki. Jika anda melakukan semuanya itu, hal ini akan memakan waktu yang tidak terhingga dan biaya yang terlalu banyak. Anda harus mulai membuang fitur segera, dan cara yang terbaik untuk melakukan hal ini adalah dengan sebuah bagian "Bukan Tujuan" di spec tersebut. Hal-hal yang tidak akan dilakukan. Suatu Bukan Tujuan dapat berupa fitur yang tidak akan anda miliki ("tidak ada user interface secara telepati!) atau bisa saja sesuatu yang umum ("Kita tidak perdulu dengan kinerja untuk rilis ini. Produk ini boleh saja lambat, asalkan bekerja. Jika kita mempunyai waktu di versi 2, kita akan meng-optimalkan bagian yang lambat"). Bukan-tujuan ini akan memicu perdebatan, namun sangat penting sekali untuk diumumkan secara terbuka sesegera mungkin. "Tidak akan lakukan itu!" seperti yang dikatakan George Sr.

Sebuah Gambaran Umum. Ini seperti daftar isi dari spec anda. Bisa berupa flowchart sederhana, atau bisa juga sebuah diskusi arsitektur yang ekstensif. Setiap orang akan membaca bagian ini untuk mendapatkan gambaran umum, baru detailnya akan lebih jelas.

Detail, detail, detail. Akhirnya anda akan masuk ke bagian detail. Kebanyakan orang akan membaca sekilas bagian ini sampai mereka perlu tahu secara mendetail. Saat anda mendesain sebuah jasa berbasis web, cara yang baik untuk melakukan ini adalah memberikan nama yang berurutan untuk setiap layar, dan menyediakan sebuah bab yang menjelaskan masing-masing secara mendetail.

Details merupakan bagian yang paling penting dalam sebuah functional spec. Anda dapat lihat dalam contoh spec bagaimana saya sedemikian detailnya menjelaskan tentang semua kemungkinan kesalahan di halaman login. Apa yang terjadi kalau alamat email-nya tidak valid? Apa yang terjadi kalau password-nya salah? Semua kemungkinan ini berhubungan dengan kode nyata yang akan ditulis, tapi yang lebih penting lagi, berhubungan dengan keputusan yang akan dibuat oleh seseorang. Orang tersebut harus memutuskan kebijaksanaan apa yang akan diambil atas password yang terlupakan. Jika anda tidak dapat putuskan, anda tidak dapat menulis kode. Spec perlu mendokumentasikan keputusan tersebut.

Masalah yang belum selesai. Tidak apa-apa bila pada versi pertama dari spec meninggalkan masalah yang belum selesai. Saat saya menulis sebuah draft pertama, saya selalu mempunyai banyak masalah yang belum selesai, namun saya menandakannya (menggunakan style khusus sehingga saya dapat mencarinya lagi kemudian) dan, jika diperlukan, membahas alternatif yang ada. Saat programer mulai bekerja, semua kebutuhan ini akan muncul semua. (Anda mungkin berpikir tidak apa-apa membiarkan programer mulai dengan hal-hal yang mudah dulu, dan anda akan menyelesaikan masalah yang belum selesai belakangan. Ide yang buruk. Anda akan cukup mendapatkan kesulitan menyelesaikan masalah baru yang muncul saat programer mulai implemen kode, tanpa mempunyai masalah lama yang belum selesai yang sudah diketahui sebelumnya dan seharusnya sudah diselesaikan. Lagi pula, cara anda menyelesaikan semuah hal yang sulit akan ada dampak pada kode yang akan ditulis).

Catatan Samping. Saat anda menulis sebuah spec, ingat akan pembaca anda: programer, tester, marketing, penulis teknis, dll. Seiring anda menulis spec, anda mungkin terpikir hal hal yang berguna hanya untuk salah satu kelompok tersebut. Sebagai contoh, Saya memberi tanda pada pesan untuk para programer, yang biasanya menjabarkan beberapa detail implementasi teknis, sebagai "Catatan Teknis". Orang marketing akan mengabaikan hal ini. Programer memperhatikan itu. Spec saya sering kali penuh dengan "Catatan Testing", "Catatan Marketing" dan "Catatan Dokumentasi".

Spec Perlu Selalu Hidup. Banyak tim programming yang mengadopsi suatu mental "air terjun": Kami akan rancang program tersebut semuanya, tulis sebuah spec, cetak, dan lemparkan ke seberang tembok untuk programmer dan pulang ke rumah. Yang dapat saya katakan adalah: "Ha ha ha ha ha ha ha ha!"

Pendekatan seperti ini yang menyebabkan kenapa spec mempunyai reputasi yang begitu buruk. Banyak orang yang mengatakan pada saya, "spec itu percuma, karena tidak ada orang yang mengikutinya, mereka selalu ketinggalan, dan tidak pernah mencerminkan produk jadi".

Maafkan saya. Mungkin spec anda tidak termuktahir dan tidak mencerminkan produknya. Spec saya secara rutin di muktahirkan Pemuktahirannya berlanjut seiring dikembangkannya produk tersebut dan keputusan baru akan dihasilkan. Spec tersebut selalu mencerminkan pemahaman kolektif yang terbaik kami akan bagaimana produk ini harus bekerja. Spec tersebut hanya akan berhenti ketika produknya sudah selesai secara kode (yaitu, saat semua fungsionalitas sudah selesai, namun masih ada pekerjaan testing dan debuging).

Untuk membuat hidup orang lebih mudah, saya tidak mengeluarkan spec setiap hari. Saya biasanya menyimpan versi yang terkini di server di mana tim dapat menggunakannya sebagai referensi. Pada milestone tertentu, saya mencetak sebuah salinan spec tersebut dengan tanda revisi sehingga orang tidak perlu membaca ulang semuanya -- mereka dapat mencari tanda revisi untuk melihat perubahan apa yang telah dibuat.

Siapa yang harus menulis spec? Baca mengenai hal ini di Bagian 3.



Artikel ini aslinya bahasa Inggris dengan judul Painless Software Specifications Part 2  

Joel Spolsky adalah pendiri Fog Creek Software, sebuah perusahaan software kecil di New York City. Dia lulus dari Yale University, dan pernah bekerja sebagai programer dan manajer di Microsoft, Viacom, dan Juno.


Isi halaman-halaman ini mewakili opini dari satu orang.
Semua isi Hak Cipta ©1999-2005  dari Joel Spolsky. Hak Cipta dilindungi Undang-undang

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky