Get best of the week

Persyaratan perangkat lunak jari

Posting tentang dasar-dasar pengembangan persyaratan - tanpa diagram, istilah, dan tabel yang rumit, tetapi dengan gif.

gambar

Singkatnya, langkah-langkah utama dalam mengembangkan persyaratan adalah:

  1. Kenapa kita harus melakukan sesuatu? (Perlu lebih banyak emas)
  2. Apa yang kita lakukan? (Semuanya seperti yang dilakukan orang, tetapi lebih murah)
  3. Bagaimana kita melakukan ini? (tentu saja dengan blockchain dan ahli data)
  4. Kapan kita akan melakukan ini? (kemarin, dan refactor "nanti")

Dan sekarang lebih terinci.

Jika Anda pernah diminta untuk melakukan sesuatu, itu berarti Anda menciptakan persyaratan. Mereka bisa dalam bentuk keinginan lisan, surat, tugas teknis, tugas atau apa pun.
Jadi persyaratannya ada di mana-mana.

gambar

Jika, setelah memenuhi permintaan, ada yang salah - itu mengacaukan pemain,
atau Anda salah mengatur tugas.

Seperti yang Anda tahu, tugas yang salah bisa sangat mahal. Sebagai contoh, jika selama setengah tahun tim dari 5 programmer mengembangkan sistem yang tidak diperlukan.

Di usia yang bergejolak ini, persyaratan desain Agile sering diabaikan. Tetapi metodologi yang fleksibel tidak selalu menyelamatkan Anda dari kerugian besar. Oleh karena itu, bahkan jika Anda tidak memiliki analis pada proyek, bahkan jika Anda bukan TI sama sekali, jangan lupakan akal sehat dan ambil dari praktik terbaik apa yang Anda butuhkan saat ini.

Jadi apa persyaratannya dan mengapa penting untuk dapat mengembangkannya?

Jadi, mari kita beralih ke sumber:

gambar

Yaitu, Anda dapat berbicara tentang persyaratan seperti tentang properti masa depan. Bagaimana dengan produk apa yang memenuhi tujuan pengembangan nantinya.

Di mana harus mulai mengembangkan persyaratan? Sebuah petunjuk tersembunyi dalam definisi: Anda harus mulai dengan tujuan - mengapa kita perlu melakukan apa saja.

1. Mengapa?


gambar

Seperti “ASAP !!!!” tidak perlu melakukan sesuatu - penting untuk menemukan waktu dan energi untuk mencari tahu mengapa ini perlu.

Karena sering, setelah mengklarifikasi tujuan, tugas berubah atau sepenuhnya dihilangkan.
Misalnya,

Pelanggan akan segera menunjukkan kepadanya semua pesanan yang dibuat dalam sistem. Katakanlah kita tegang dan mendorong tugas di tengah sprint untuk menampilkan semua pesanan untuk administrator. Setelah itu, pelanggan meminta untuk menampilkan di jendela terpisah daftar semua perusahaan yang pesanannya dia lihat. Mereka juga melakukannya. Kemudian pelanggan meminta untuk menarik tambahan semua perusahaan mitra. Oke ... Setelah beberapa waktu, kami bertemu dengan pelanggan dan melihat bagaimana dia mengunggah kedua daftar ke Excel, mengenali perbedaannya dan mulai menelepon perusahaan-perusahaan yang tidak memiliki pesanan untuk mengingatkan mereka untuk melakukan pemesanan melalui sistem kami.

Jika kami bertanya kepada pelanggan dari awal tujuan apa yang ingin ia capai dengan melihat semua pesanan, kami akan menghemat banyak waktu dan upaya dengan segera melaporkan kepada perusahaan yang tidak melakukan pemesanan sejauh ini.
Anda dapat menggunakan metode "Lima Alasan" atau lainnya. Tetapi biasanya orang tidak menentang: jika Anda menunjukkan minat pada pekerjaan mereka, solusi menjadi tersedia.

Setelah memutuskan suatu tujuan, penting untuk mendefinisikannya dengan jelas dan menetapkan kriteria yang dapat Anda katakan secara akurat bahwa tujuan tersebut telah tercapai.

Misalnya,

proses pemesanan bahan dianggap otomatis jika> 90% perusahaan mitra melakukan pemesanan melalui sistem.

Ini memfasilitasi pemahaman tentang tugas-tugas dan pada saat yang sama membebaskan tangan dalam memilih cara untuk mencapai tujuan.

Dan ya, jangan lupa untuk mengoordinasikan kecantikan ini dengan pelanggan. Secara umum, jangan lupa untuk mengoordinasikan persyaratan dengan semua pihak yang berkepentingan.

2. Apa?


Tujuannya dicapai dengan berbagai cara. Dan langkah penting kedua dalam mengembangkan persyaratan adalah hanya tentang memilih jalan - apa yang akan kita lakukan untuk mencapai tujuan.

gambar



, :

. . . // .

. — , .

. . .

Untuk memikirkan semua opsi, Anda perlu mencari tahu - apa yang terjadi sekarang? Bagaimana prosesnya bekerja tanpa sistem Anda, bagaimana cara kerja pengguna dan pelanggan? Sekalipun belum ada proses, informasi terperinci tentang keadaan saat ini sangat penting. Jadi kita akan mengerti solusi mana yang akan memperbaiki masalah, dan tidak membuat yang lain.

gambar

Setiap opsi implementasi memiliki pro dan kontra, sumber daya yang diperlukan dan tingkat hasilnya. Setelah memodelkan semua opsi, bekerja, atau setidaknya hanya mengatakan informasi ini dengan pihak yang berkepentingan, Anda akan dapat membuat pilihan yang seimbang dan terinformasi.

3. Bagaimana caranya?


Jadi, kami memahami tujuan kami dan apa yang akan kami lakukan untuk mencapainya. Tetap mencari tahu bagaimana kami menerapkan ini: halaman mana yang akan kami tunjukkan kepada pengguna, dalam bentuk apa kami akan menampilkan laporan untuk pelanggan, bagaimana kami akan menerima data dari sistem lain, bagaimana kami akan menyimpannya dan sebagainya.

Tahap ini adalah masalah teknologi. Dan jika Anda telah berhasil menyelesaikan dua sebelumnya, itu akan jauh lebih mudah.
Meskipun tekniknya tergantung pada konteksnya, ada baiknya untuk mengikuti “daftar periksa” Wigers dan orang-orang pintar lainnya. Jika bagi Anda beberapa jenis persyaratan tidak relevan saat ini - oke, kami tidak akan menjelaskannya. Tetapi penting untuk tidak melupakan dan menguji diri sendiri.

gambar

contohnya

  • Kuesioner harus berisi file dengan foto, karena foto diperlukan ketika memproses dokumen - ini adalah persyaratan bisnis . Dan mungkin aturan bisnis.
  • - , — . , .
  • , — , . , .
  • base64 . — .
  • , . : 10.

Untuk setiap persyaratan bisnis, sebagai suatu peraturan, ada beberapa persyaratan pengguna. Persyaratan pengguna didekomposisi menjadi beberapa yang fungsional. Untuk setiap persyaratan fungsional, persyaratan dan batasan non-fungsional harus dipertimbangkan.

Selain itu, persyaratan dan batasan non-fungsional dapat langsung mengalir dari persyaratan pengguna dan persyaratan serta aturan bisnis.
Dengan cara ini, pohon diperoleh dari persyaratan, di atas masing-masingnya merupakan persyaratan bisnis.

gambar

4. Kapan?


Di “hutan” persyaratan Anda, kemungkinan ada yang saling eksklusif dan berulang. Karena itu, sangat berguna untuk mendokumentasikan dan menyajikan semua keindahan ini dalam bentuk tabel dan diagram.

Ada banyak alat di sini: misalnya, BPMN untuk menggambarkan proses bisnis dan UML untuk membuat skema interaksi antara layanan dan komponen.

Jika Anda berhasil menjelaskan kepada semua orang apa dan bagaimana Anda ingin melakukannya dengan sistem, menggunakan serbet dan 3 noda kopi, maka Anda adalah John Wick dari analisis dan ini luar biasa.

gambar

Namun, sebagai aturan, level "spot" tidak memungkinkan Anda untuk melihat perangkap dan memikirkan semua skenario yang mungkin. Bagaimanapun, semuanya tampak jelas, tetapi saya menggambar diagram kecil - dan di sini Anda memiliki tantangan yang tak ada habisnya, dan cabang proses yang terlupakan, dan jalur terpendek menuju emas.
Karena itu, penting untuk mengetahui alat apa yang tersedia untuk membalikkan kekacauan.

Dalam bentuk skematis dan terstruktur, persyaratan harus diprioritaskan - tergantung pada utilitas (pelanggan dan pengguna akan memberi tahu Anda tentang hal ini) dan kompleksitas (tim pengembangan akan memberi tahu Anda tentang hal ini).

gambar

Dan kemudian Anda sudah dapat menyebar di sprint / tahap pengembangan dan implementasi. Nah, ulangi latihan ini dalam setiap iterasi. Dan Anda akan bahagia - tidak ada perubahan, pelanggan yang puas, tim yang bahagia, produk yang bekerja dan menguntungkan, elf memainkan harpa dengan latar belakang pelangi.

gambar

Tentu saja, akan selalu ada masalah. Akan ada perubahan, tenggat waktu yang terbakar, dan bug. Tidak selalu mungkin untuk melewati semua tahapan dan melakukan analitik normal, menyetujui atau bahkan hanya berbicara dengan pelanggan, mendokumentasikan dan melacak persyaratan. Tetapi dalam situasi apa pun, memahami "bagaimana seharusnya" membantu membuat produk lebih baik. Sekalipun saat ini Anda melakukan "bagaimana hasilnya" - Anda sadar bahwa Anda kehilangan dan Anda tahu risikonya. Dan jika Anda tahu risikonya, maka Anda bisa mengelolanya.

Saya sarankan membaca lebih lanjut tentang persyaratan dalam buku Wigers and Beatty: "Pengembangan persyaratan perangkat lunak". Meskipun buku ini tidak selalu sederhana, tetapi sangat bermanfaat. Sebagian besar materi lain tentang topik ini menceritakan kembali kebenaran-kebenaran ini dengan berbagai tingkat kebebasan.

Terima kasih atas perhatian dan desainnya.

More articles:


All Articles