Apakah analisis persyaratan berguna dalam pengembangan game?

9

Saya seorang mahasiswa rekayasa perangkat lunak dengan fokus pengembangan game. Seberapa besar bagian yang dimainkan analisis kebutuhan dalam pengembangan game?

Saya bertanya karena saya mencoba memutuskan apakah akan mengikuti kelas analisis kebutuhan. Berikut ini deskripsi:

Studi mendalam tentang penelitian saat ini dan praktik dalam elisitasi persyaratan, persyaratan, analisis, spesifikasi persyaratan, verifikasi dan validasi persyaratan, dan manajemen persyaratan.

Apakah tipe pengetahuan ini berguna bagi pengembang game independen? (Alternatifnya adalah kecerdasan buatan atau arsitektur perangkat lunak.)

education software-engineering requirements

— Joey Green
sumber

Untuk memperjelas, apa alternatif Anda?

— ChrisE

Ya, berikan sedikit lebih banyak situasi Anda, tolong. Apakah ini sesuatu yang harus diambil selain tugas inti Anda atau apakah Anda mencoba menentukan apakah RA adalah bagian dari inti Anda?

— Jason Pineo

Apa yang terlibat dalam kelas arsitektur perangkat lunak Anda? Jika itu lebih diarahkan untuk merancang suatu sistem maka saya pasti akan menyarankan mengambil itu. Analisis persyaratan terdiri dari "Saya tidak peduli bagaimana saya melakukannya, apa yang saya ingin perangkat lunak saya lakukan?" Merancang sistem terdiri dari "Saya tahu apa yang ingin saya lakukan, bagaimana saya bisa mencapainya dengan cara yang paling efisien?"

— Ray Dey

Alat / teknik terapan apa pun yang akan membantu Anda menghindari Analisis Paralisis akan bermanfaat.

— Patrick Hughes

7

Analisis persyaratan akan sangat berguna, apakah Anda seorang pengembang independen atau Anda bekerja untuk perusahaan besar. Analisis persyaratan memungkinkan Anda memecah proyek Anda menjadi potongan-potongan yang dapat dikelola. Ini memungkinkan Anda memperkirakan waktu proyek Anda akan mengambil, dan menimbang nilai fitur terhadap jadwal pengembangan yang Anda inginkan dan upaya yang diperlukan.

Jika Anda berada di perusahaan game indie yang lebih besar, itu akan membantu Anda bekerja sama dengan pengembang dan produsen konten lainnya untuk memastikan semua orang selalu melakukan sesuatu dan Anda dapat memenuhi target pengembangan Anda. Jika Anda bekerja untuk perusahaan besar, analisis persyaratan pembelajaran akan menjadikan Anda salah satu dari sedikit pengembang dalam rapat yang benar-benar dapat memberikan perkiraan waktu yang realistis untuk suatu fitur alih-alih hanya menarik sejumlah dari pantat Anda.

Selain semua itu, validasi persyaratan dapat mencakup hal-hal seperti pengujian unit dan verifikasi fitur, yang sangat berharga bagi pengembang tanpa departemen QA besar di belakangnya.

— Gregory Avery-Weir
sumber

+1 Semua yang dikatakan di sini adalah benar, dan juga menyikapi gagasan bahwa Anda mungkin akan melakukan pemrograman korporat sampai Anda berhasil di kancah indie.

— ChrisE

Bagaimana itu tidak berguna? Anda harus menganalisis apa pun yang Anda lakukan secara terstruktur. Hanya karena beberapa istilah tidak jelas tidak berarti tidak mungkin untuk diukur.

— johnny

2

Saya pikir kelas ini akan memiliki antara nol dan sangat sedikit relevansinya dengan pengembangan game. Tentu saja metode semi formal atau formal yang Anda sebutkan tidak digunakan dalam pengalaman saya.

Game biasanya memiliki persyaratan yang sangat cair, dan bahkan jika mungkin untuk menginvestasikan waktu dan praktik terbaik ke dalam persyaratan pengumpulan, banyak dari apa yang Anda dapatkan pada akhirnya adalah istilah yang tidak bermakna dan tidak jelas yang merujuk pada kesenangan, kecanduan, pencelupan, dan sebagainya. Jarang sekali Anda memiliki kiriman yang sangat jelas karena, seperti yang kita suka berpura-pura membuat perangkat lunak adalah rekayasa, itu sebenarnya lebih merupakan kerajinan, mengingat berbagai cara yang berbeda yang dapat diekspresikan oleh pemrogram. Ini berlaku ganda untuk game.

— Kylotan
sumber

Saya harap "persyaratan cairan" bukan eufemisme untuk "fitur creep". : \ Saya tidak setuju bahwa "banyak" dari apa yang akan Anda dapatkan adalah istilah yang tidak bermakna dan tidak jelas seperti "kesenangan", "kecanduan", dll. Itu mewakili persyaratan non-teknis, yang merupakan bagian dari persyaratan yang dipikirkan dengan matang dokumen.

— PatrickB

2

Saya pikir persyaratan cairan tentu saja merupakan eufemisme untuk fitur creep, tetapi jika Anda ingin berkompetisi di lingkungan ritel dan hit-driven, Anda harus menerima fitur creep sejak hari pertama. Hal-hal yang dapat Anda pelajari dengan mengumpulkan dan menganalisis persyaratan untuk 'pelanggan perangkat lunak' tradisional terlalu berbeda dari bagaimana perangkat lunak hiburan perlu bekerja. Khususnya Anda memiliki satu masalah utama yaitu klien Anda bukan pengguna akhir Anda, dan masalah besar lainnya dalam persyaratan teknis tidak dapat dijabarkan ketika Anda tahu bahwa fitur creep tidak dapat dihindari.

— Kylotan

Saya tidak percaya dia mengatakan dia bersaing atau bahkan membuat produk yang dijual. Banyak game indie tidak dirancang untuk bersaing dengan game ritel, mereka biasanya bahkan tidak berada di lapangan bermain yang sama dengan judul AAA. Sial, Steam mendorong semua game indie ke kotak pasir kecil mereka sendiri, mungkin lebih sebagai label peringatan. Ketika pengembang indie Anda, Anda, secara definisi memiliki kendali atas apa yang ingin Anda lakukan. Jika tidak, maka Anda akan bermitra / berinvestasi, dan Anda tidak akan benar-benar menjadi indie, bukan? Either way, saya sepertinya tidak menemukan fitur creep di game hobi apa pun yang saya kerjakan. YMMV.

— PatrickB

1

Saya tidak berpikir independen biasanya berarti 'permainan hobi', itu biasanya berarti 'perusahaan kecil tidak bergantung pada dana penerbit'. Dengan demikian situasi klien / pelanggan Anda bisa lebih sederhana daripada yang saya sarankan di atas, tetapi Anda bisa dibilang lebih rentan terhadap kekuatan pasar. Tetapi pada akhirnya, sebagian besar analisis persyaratan formal akan gagal karena sangat sulit untuk memenuhi syarat "kebutuhan bisnis" dalam hal permainan. Game berbeda secara signifikan dari perangkat lunak lain dalam hal ini dan oleh karena itu saya dengan rendah hati akan menyarankan bahwa cara lain untuk menentukan perangkat lunak lebih relevan.

— Kylotan

Apa cara lainnya?

— johnny

2

Analisis persyaratan jauh lebih ditujukan pada perangkat lunak perusahaan, dengan saluran komunikasi formal dan hal semacam itu, sedikit atau tidak ada yang akan ada untuk pengembang indie. Ini tidak terlalu berguna untuk permainan karena banyak persyaratan tidak dapat diuji atau diverifikasi secara formal. Jika Anda memiliki bilah alat dan Anda berkata, "Mengklik tombol ini akan drop-down menu dengan XYZ di atasnya", maka Anda dapat membayar seseorang hampir tidak ada yang mengklik tombol dan melihat apa yang terjadi. Apakah gim Anda menyenangkan? Ketel ikan yang sangat berbeda.

RA dapat bermanfaat untuk menentukan apakah game berfungsi; tetapi ketika datang ke hal-hal seperti keseimbangan, replayability dan faktor-faktor lain yang menentukan faktor kesenangan utama permainan, maka sulit atau tidak mungkin untuk mengujinya. Jadi pada akhirnya, itu tergantung pada apakah Anda akan menerapkan ide yang sudah ada atau tidak; atau apakah Anda sedang mencari kesuksesan di gameplay novel.

— DeadMG
sumber

0

Lewati.

Bidang Pengembangan Game apa yang Anda minati? Saya mengasumsikan Programmer tetapi ...

Desainer: Mereka banyak menulis. Banyak sekali. Biasanya ada dokumen desain yang mengkomunikasikan visi desainer tetapi untuk semua orang kecuali produsen atau penerbit Anda biasanya akan mendapatkan informasi dari desainer itu sendiri.

Programmer: Lead menentukan persyaratan teknis yang akan sangat tergantung pada platform dan pipa aset. Anda akan belajar bagaimana melakukan ini saat Anda bekerja dengan pemimpin Anda di pekerjaan.

Artis: Sekali lagi ini adalah artis utama bersama dengan programmer utama yang biasanya menetapkan persyaratan untuk aset seni. Belajar di tempat kerja.

Analisis persyaratan, seperti kursus yang kemungkinan besar akan mereka ajarkan, berguna untuk perusahaan besar yang berusaha membenarkan pengeluaran uang dan untuk outsourcing. Dan itu sering dilakukan oleh seseorang yang pernah berkode dan mungkin sejak itu lupa. menusuk

Jika Anda berencana untuk pergi indie, ambil subjek bisnis / akuntansi / manajemen. Anda akan membutuhkannya untuk bertahan hidup dan tidak kacau. Semoga berhasil.

— bkersten
sumber

Saya juga akan menganggap programmer, karena ia menandai programmer;)

— The Communist Duck

1

-1 Jadi, Anda tidak hanya ketinggalan bahwa orang tersebut menandai untuk pemrogram, Anda juga melewatkan bahwa itu untuk pengembangan indie, yang akan segera menyiratkan bahwa tidak akan ada pemimpin teknologi untuk belajar darinya. Analisis persyaratan berguna - bahkan ketika tidak melakukan spesifikasi sistem lengkap - mempelajari cara mendapatkan pola pikir yang benar untuk menganalisis masalah. Selain itu, praktik dalam menulis akan selalu bermanfaat jika perlu muncul untuk memberi masukan kepada penerbit. Saran Anda, terus terang, tidak ditujukan kepada audiens target atau memberikan wawasan yang bermanfaat tentang topik tersebut.

— ChrisE

-1 Setuju. Cukup banyak perangkat lunak jelek di luar sana yang tidak melakukan apa yang orang butuhkan dan cukup banyak game indie yang menderita desain mengerikan yang tidak menyelesaikan masalah teknis dan beralih ke penulisan ulang tanpa akhir dan game yang belum dirilis. Metode formal adalah formalitas yang mungkin tidak dilalui oleh game indie secara eksplisit, tetapi memiliki latar belakang memang mengarah pada pola pikir "berhenti dan berpikir" daripada "kode dan perbaiki" yang terlalu lazim. Coders adalah selusin sepeser pun, namun perangkat lunak berkualitas sangat jarang. Anda menghitungnya.

— PatrickB

1

Ha ha ha. Semua pengembangan game, terutama indie, adalah tentang menjadi gesit dan beriterasi pada ide inti. Analisis kebutuhan tidak memiliki apa-apa untuk ditawarkan dan sebagian besar merupakan proses berat di depan. Jadi saya menggeneralisasi jawaban saya. Jika mereka berencana untuk menggunakan indie yang memiliki jaringan pengembang dan artis setengah berpengalaman, akan sulit untuk melakukannya tanpa. Jadi, Anda harus jenius di semua bidang pengembangan game dan bisnis atau Anda menemukan mentor, pemimpin teknologi dll. Cobalah untuk tidak menjadi orang yang begitu sensitif.

— bkersten

1

@PatrickB Analisis persyaratan tidak akan memengaruhi cara perangkat lunak dirancang. Analisis persyaratan dipenuhi dengan potongan informasi yang tidak berguna yang hampir tidak akan pernah digunakan oleh pengembang game (diagram use case terutama muncul di benak). Ini adalah topik yang cukup diarahkan pada pemangku kepentingan dan karenanya lingkungan perusahaan. Saya setuju bahwa pengembang harus mendaftar persyaratan (fitur) tetapi itu harus masuk akal. Merancang perangkat lunak adalah topik yang sepenuhnya terpisah yang hampir tidak disentuh oleh analisis persyaratan (di universitas)

— Ray Dey