KONSEP DAN PRINSIP-PRINSIP ANALISIS

Oleh: Davin Pratama 535110006 Nofantarius 535110014 Danny Kristianto 535110034 Yulianto 535110042

Persyaratan pada rekayasa perangkat lunak adalah proses penemuan, perbaikan, pemodelan, dan spesifikasi. Persyaratan dan peran dari sistem dialokasikan untuk perangkat lunak yang awalnya di buat oleh system egineer yang di selesaikan secara rinci.

Proses Rekayasa Perangkat Lunak

Donald Reifer mendeskripsikan proses yang dibutuhkan dalam rekayasa perangkat lunak sebagai berikut: Yang dibutuhkan pada rekayasa adalah penggunaan sistematis prinsip terbukti, teknik, bahasa, dan alat-alat yang digunakan untuk mengefektifkan analisis, dokumentasi, dan evolusi dari kebutuhan pengguna yang terus-menerus dan spesifikasi dari perilaku eksternal dari sistem untuk memenuhi kebutuhan pengguna tersebut. Sehingga rekayasa perangkat lunak memerlukan penggunaan pendekatan sistematis yang sudah teruji.

Analisis Kebutuhan
Analisis kebutuhan adalah sebuah tugas pada rekayasa perangkat lunak yang menjembatani perbedaan antara rekayasa persyaratan tingkat sistem dan design dari perangkat lunak. Requirements engineering/rekayasa persyaratan menghasilkan spesifikasi dari suatu perangkat lunak, seperti karakteristik operasionalnya (fungsi-fungsi, data, dan behavior), membandingkan tampilan muka perangkat lunak dengan elemen-elemen dari sistem yang lain, dan menentukan batasanbatasan yang dimiliki perangkat lunak.

 Requirements analysis menyediakan pendesain perangkat lunak(atau dalam hal ini disebut analyst/analis) untuk 'memperhalus' alokasi perangkat lunak dan build model untuk fungsifungsi, data, dan behavior yang akan dijalankan perangkat lunak. Requiements analysis juga memberikan representasi informasi dan fungsi-fungsi yang dapat diterjemahkan menjadi desain data, arsitektural, interface, hingga component-level. Kemudian, requirements specification/spesifikasi persyaratan membantu analyst dan pengguna untuk mengukur kualitas perangkat lunak yang sudah dibangun.

 Software requirements analysis dibagi menjadi lima bagian : (1) problem recognition, (2) evaluation and synthesis, (3) modelling, (4) specification, dan (5) review. Secara dasar, analyst mempelajari System Specification (jika ada) dan Software Project Plan. Sangatlah penting untuk mengenal perangkat lunak dalam konteks system dan melakukan review perangkat lunak untuk menghasilkan estimasi rencana. Kemudian, komunikasi untuk analisis harus dibangun agar pengenalan masalah dapat dipastikan. Tujuannya adalah untuk mengenali berbagai masalah dasar yang didialami dalam sudut pandang konsumen/pengguna.

 Evaluasi masalah dan pembuatan solusi adalah bagian besar lainnya untuk seorang analisis. Analyst harus :
o mendefinisikan semua data object secara eksternal, o mengevaluasi aliran dan isi informasi, o mengetahui dan menguraikan semua fungsi perangkat lunak, o mengenal behavior perangkat lunak dalam konteks yang mempengaruhi sistem, o membangun karakteristik interface sistem, dan mencari batasan-batasan desain lainnya.

Setiap tugas tersebut membantu menjelaskan masalah sehingga mendapatkan sebuah pendekatan atau solusi.

 Sebagai contoh, sebuah supplier auto parts/suku cadang memerlukan sebuah sistem pengendalian logistik. Analyst menemukan masalah-masalah dengan sistem manual yang sekarang berupa: (1) ketidakmampuan untuk mendapatkan status sebuah komponen secara cepat (2) dua atau tiga hari untuk memproses sebuah berkas (3) pemesanan ulang yang berkali-kali ke penyedia yang sama karena tidak ada cara uuntuk mengenali penyedia dengan komponen yang diinginkan, dan sebagainya.

 Saat masalah telah teridentifikasi, analyst menentukan informasi apa saja yang dihasilkan oleh sistem yang baru dan data apa saja yang akan dimiliki sistem. Misalkan, konsumen berpikir bahwa karyawan logistik akan mencatat nomor identifikasi dari setiap suku cadang saat suku cadang tersebut meninggalkan area logistik.

 Setelah mengevaluasi masalah-masalah dan informasi yang diinginkan (input dan output), analyst akan mulai membuat satu atau lebih solusi. Mula-mula, data objects, processing functions, dan behavior sistem akan dijabarkan secara detil. Kemudian arsitektur dasar yang akan diimplementasikan akan dipertimbangkan.

 Pendekatan client/server mungkin cocok, tapi apakah perangkat lunak yang memiliki arsitektur ini termasuk kedalam garis besar yang terdapat di Software Plan? Sebuah database management system (DBMS) mungkin diperlukan, tapi apakah pengguna dapat mengasosiasikannya? Proses evaluasi dan pembuatan solusi akan terus dilakukan samapai analyst dan pengguna merasa percaya diri bahwa perangkat lunak dapat memasuki tahap pengembangan selanjutnya.

 Dalam proses evaluasi dan pembuatan solusi, fokus utama analyst adalah pada 'apa' bukan 'bagaimana'. Data apa saja yang akan dibuat dan diambil oleh sistem, fungsi-fungsi apa saja yang harus dilakukan sistem, behavior apa saja yang ditunjukkan oleh perangkat lunak, tampilan muka apa saja yang akan muncul, dan batasan-batasan apa saja yang akan diaplikasikan? Didalam proses evaluasi dan pembuatan solusi, analyst membuat model dari sistem untuk mengenali data dan aliran data, functional processing, operational behavior, dan information content. Model tersebut menjadi pondasi dari desain perangkat lunak dan sebagai basis dari pembuatan sepsifikasi perangkat lunak.

Persyaratan Elisitasi Pada Perangkat Lunak

Sebelum syarat-syarat dapat di analisis, di modelkan, dan di ketahui, syarat-syarat tersebut harius berkumpul di proses elisistasi. contoh: Pelanggan mempunyai masalah yang mungkin dapat diselesaikan dengan menggunakan solusi komputer. Pengembang merespon permintaan tolong dari si pelanggan. Terjadilah komunikasi, namun seiring komunikasi tersebut, biasanya terdapat celah miskomunikasi.

Initiating The Process

Syarat elisitasi yang paling sering digunakan adalah untuk merencanakan sebuah meeting / interview. Metting pertama antara software engineer dan Customer mungkin akan terlihat canggung. Namun, komunikasi tersebut harus dimulai. Gause dan Weinberg menyarankan agar software engineer memulai terlebih dahulu dengan menanyakan pertanyaan yang akan mengarah pada pokok pemahaman dari masalah.

 Pertanyaan yang diajukan harus berfokus kepada customer, tujuan keseluruhan, dan manfaatnya. Sebagai contoh, software engineer dapat bertanya:
o Siapa yang meminta pekerjaan ini? o Siapa yang akan menggunakan software ini? o Apa yang menjadi benefit jika solusi ini berhasil?

Pertanyaan-pertanyaan diatas membantu untuk mengidentifikasi semua orang yang mempunyai keinginan dalam membuat sebuah software.

 Beberapa pertanyaan berikutnya memungkinkan software engineer untuk mendapatkan pemahaman yang lebih baik dari masalah dan customer dapat menyuarakan pandangannya tentang solusi tersbut:
o Bagaimana anda dapat mengkarakteristikkan hasil yang baik yang akan dihasilkan oleh solusi yang berhasil? o Apa solusi dari masalah ini? o Dapatkah anda menunjukkan pada cakupan apa solusi akan digunakan? o Akankah ada masalah khusus pada performa yang dapat mempengaruhi cara solusi bekerja?

 Beberapa pertanyaan yang terakhir berfokus pada keefektifan dari sebuah meetting. Gause dan Weinberg menyebutnya meta-questions.
o Apakah anda adalah orang yang tepat untuk menjawab pertanyaan ini? o Apakah pertanyaan saya sesuai dengan masalah yang anda punya? o Apakah saya menanyakan terlalu banyak pertanyaan? o Dapatkah saya bertanya kepada anda pertanyaan yang lainnya?

 Beberapa pertanyaan di atas tersebut akan membantu untuk mencairkan suasana dan memulai komunikasi yang penting untuk mendapatkan analisis yang tepat. Namun format tanya jawab tersebut bukanlah suatu pendekatan yang paling sukses. Pada kenyataannya, sesi Q&A digunakan hanya untuk pertemuan pertama dan digantikan oleh pertemuan dengan format yang menggabungkan unsur pemecahan masalah, negosiasi, dan spesifikasi.

Facilitated Application Specification Techniques

Terlalu sering customer dan software engineer mempunyai pola pikir saya dan kamu. Banyak terjadi kesalahpahaman yang berimbas pada tidak didapatkannya informasi penting dan hubungan kerja yang tidak dapat mencapai keharmonisan. Karena masalah-masalah tersebut beberapa investigator independent menciptakan sebuah tim yang berorientasi pada pengumpulan persyaratan yang diterapkan selama tahap-tahap awal anaslisis dan spesifikasi. Yang di namakan Facilitateed Application Specification Techniques (FAST).

 Berbagai pendekatan untuk FAST telah diusulkan. masing-masing membuat penggunaan skenario yang sedikit berbeda, tetapi semua menerapkan beberapa variasi pada pedoman dasar berikut:
o Sebuah meeting dilakukan pada lokasi netral dan dihadiri oleh kedua piihak (software engineers dan customer) o Aturan untuk persiapan dan partisipasi sudah ditetapkan o Sebuah agenda disarankan dalam bentuk formal untuk mencakup semua hal penting, namun juga cukup informal untuk dapat mendorong ide-ide bebas.

o Terdapat fasilitator (dapat berupa si customer, si pengembang, atau pihak ketiga) yang mengendalikan meeting. o Diperlukan mekanisme definisi (dapat berupa kertas kerja, flip charts, chat room, atau e-book. o Bertujuan untuk mengidentifikasi masalah, mengusulkan komponen-komponen pemecahan masalah, menegosiasikan pendekatan yang berbeda, dan menentukan target awal persyaratan solusi dalam suasana yang konduktif untuk pencapaian tujuan

Quality Function Deployment

QFD adalah sebuah teknik manajemen kualitas yang menerjemahkan keperluan-keperluan dari customer ke dalam persyaratan teknik dari suatu software. Dikembangkan pertama kali di Jepang dan digunakan pertama kali pada Galangan Kapal Kobe pada 1970an, QFD mengkonsentrasikan pada maksimalnya kepuasan pelanggan dari proses rekayasa perangkat lunak.

 QFD mengidentifikasi 3 tipe yang dibutuhkan, antara lain: Normal Requirements: tujuan dan sasaran yang dinyatakan untuk produk atau sistem selama pertemuan dengan customer. Jika persyaratan tersebut ada, maka customer terpuaskan. Expected Requirements: persyaratan ini implisit untuk produk atau sistem dan mungkin begitu mendasar sehingga pelanggan tidak secara eksplisit menyatakannya. ketidakhadiran mereka akan menjadi penyebab ketidakpuasan yang signifikan.

Exciting Requirements: fitur ini melampaui harapan pelanggan dan terbukti sangat memuaskan ketika hadir. Sebagai contoh, software pemrosesan kata diminta dengan fitur standard. produk yang dihadikan berisi sejumlah kemampuan tata letak halaman yang cukup memuaskan dan tak terduga.

 Dalam kenyataannya, QFD meliputi proses rekayasa secara keseluruhan. Namun, banyak konsep QFD berlaku untuk kegiatan perysaratan elisitasi. Pada meeting dengan customer, Function Development digunakan untuk menentukan nilai dari masing-masing fungsi yang digunakan oleh system. Information deployment mengidentifikasi baik objek data dan event yang harus digunakan dan dibuat oleh system. Finally, task deployment memeriksa behavior dari system atau produk dengan konteks sesuai lingkupnya.

 Value analysis dilakukan untuk menentukan prioritas relatif dari syarat yang ditentukan selama penyebaran tiga fungsi diatas.

Use-Cases
Sebagai persyaratan yang telah dikumpulkan sebagai bagian dari meeting informal, FAST, atau QFD, si software engineer dapat membuat beberapa skenario yang dapat mengidentifikasi kegunaan untuk sistem yang akan dibangun. Skenario-skenario tersebut disebut Use-Cases, menyediakan deskripsi bagaimana sistem dapat digunakan.

 Untuk membuat use-case, si analis pertama kali harus mengindentifikasi berbagai macam tipe dari orang (atau device) yang menggunakan sistem atau produk. aktor ini sangat mewakili peran device yang berperan sebagai sistem operasi. *aktor adalah segala sesuatu yang berkomunikasi dengan sistem atau produk dan yang berada di luar sistem itu sendiri. Catatan penting yang perlu diketahui bahwa actor dan user merupakan hal yang berbeda. Tipikal user dapat memainkan sejumlah peran yang berbeda saat menggunakan sistem, disisi lain actor merupakan kelas entitas eksternal yang hanya memerankan satu peran.

 Sekali actor sudah dapat diidentifikasi,use-cases dapat dikembangkan. Use-case mendeskripsikan cara dimana actor berinteraksi dengan sistem. Jacobson menyarankan beberapa pertanyaan yang harus dijawab oleh use-case: 1. Apa fungsi atau tugas utama yang dilakukan aktor? 2. Sistem informasi apa yang akan diperoleh, dihasilkan atau diubah oleh aktor? 3. Akankah aktor menginformasikan ke sistem tentang perubahan lingkup eksternal? 4. Informasi apa yang diharapkan aktor dari sistem?

 Setiap use-case memberikan skenario yang jelas dari interaksi antara aktor dan software. Juga dapat digunakan untuk menentukan persyaratan waktu atau kendala lainnya untuk skenario. Use-case mendeskripsikan skenario-skenario yang akan dirasakan berbeda oleh aktor-aktor yang berbeda. Wyder menunjukkan bahwa penyebaran fungsi mutu dapat digunakan untuk mengembangkan nilai prioritas berimbang untuk setiap use-case.

Prinsip Analisis
Hampir selama 2 dekade, berbagai model analisis telah dikembangkan. Namun, semua cara-cara analisis berhubungan dengan prinsip operasional: 1. Lokasi informasi dari sebuah masalah harus dapat diwakili dan dipahami. 2. Fungsi-fungsi pada software yang digunakan untuk dijalankan harus didefinisikan 3. Tindakan dari software harus direpresentasikan. 4. Model yang menggarmbarkan informasi, fungsi dan perilaku harus dipilah-pilah dengan cara yang mengungkapkan detail secara berlapis. 5. Proses analisis harus bergerak dari informasi penting terhadap detail implementasi.

 Disamping prinsip-prinsip analisis operasional, Davis mengusulkan beberapa prinsip sebagai syarat rekayasa: 1. Mengerti masalah sebelum anda memulai membuat model analisis. 2. Kembangkan prototype tentang bagaimana interaksi yang munci antara manusia / mesin yang dapat dipahami user. 3. Merekam asal dan asalan untuk setiap kebutuhan. 4. Menggunakan beberapa tampilan dari kebutuhan. 5. Membuat peringkat persyaratan. 6. Mengeliminasi multitafsir.

The Information Domain

Semua aplikasi software dapat secara kolektif dinamakan data processing. Software dibuat untuk memproses data, untung mengubah suatu bentuk data ke bentuk lain; untuk menerima input, memanipulasinya dalam berbagai cara, dan menghasilkan output. Prinsip analisis operasional pertama memerlukan sebuah penelitian dari sumber informasi dan pembuatan model data.

 Domain informasi / sumber informasi memiliki 3 pandangan yang berbeda dari data dan control masing-masing setelah di proses oleh program komputer: 1. Konten informasi, mewakili data individu dan objek kontrol yang merupakan beberapa koleksi besar informasi ditransformasikan oleh perangkat lunak 2. Arus informasi, merupakan cara di mana data dan kontrol berubah karena selalu bergerak melalui sistem 3. Struktur informasi, merupakan organisasi internal berbagai data dan item kontrol.

Modeling
Kita membuat model-model fungsional untuk mendapatkan pemahaman yang lebih baik dari suatu entitas yang akan dibangun. Ketika sebuah entitas berupa sebuah hal fisik ( bangunan, mesin, pesawat ) kita dapat membuat model yang bentuknya identik namun dengan ukuran yang lebih kecil. Namun, ketikan entitas yang akan dibangun adalah software, sebuah model harus mengambil bentuk yang berbeda. Harus mewakili sebuah informasi yang diubah software, fungsi-fungsinya (dan sub-fungsi) yang memungkingkan transformasi terjadi, dan sifat-sifat dari sistem tepat setelah transformasi terjadi.

 Model-model dari fungsi dan sifat-sifat yang dibuat yang diperlukan pada prinsip analisis 1. Functional models, merupakan informasi transformasi software, dan guna mencapai hal ini, model harus melakukan 3 fungsi dasar: input processing output. 2. Behavioral models, program komputer selalu ada di berbagai tempat, dan perilaku eksternal tersebut diamati (printing, computing, polling) yang berubah hanya ketika ada event-event tertentu.

 Model yang dibuat selama analisis persyaratan mempunyai beberapa peran penting: 1. Model membantu analis dalam memahami informasi, fungsi, dan sifat-sifat sistem, sehingga membuat tugas analis menjadi lebih mudah dan lebih sistematis 2. Model menjadi titik fokus untuk review dan menjadi kunci untuk penentuan kelengkapan, konsistensi, dan ketepatan dari sebuah spesifikasi 3. Model menjadi dasar untuk design, menyediakan desainer sebuah representasi penting dari software yang dapat dipetakan kedalam konteks implementasi

Partitioning
Masalah-masalah terkadang terlalu besar dan kompleks untuk dipahami secara keseluruhan. Karena alasan ini, digunakanlah partition (pemecahan/pembagian) masalah-masalah tersebut kedalam beberapa bagian sehingga fungsi keseluruhan dapat dicapai. Pada dasarnya, partitioning menguraikan masalah menjadi bagian-bagian penyusunnya.

Pandangan yang Mendasar

Sebuah pandangan yang mendasari kebutuhan software menghadirkan fungsi yang harus dicapai dan informasi yang harus diproses tanpa memperhatikan rincian pelaksanannya. Implementasi tampilan dari kebutuhan software menyajikan perwujudan dari fungsi-fungsi dan sturktur informasi yang nyata. Dalam beberapa kasus, representasi fisik dikembangkan sebagai langkah awal untuk memdesain software. Namun, kebanyakan sistem berbasis komputer ditentukan dengan cara mengakomodasi perintah dari beberapa rincian implementasi terentu.

 Kita telah mengetahui bahwa perangkat lunak membutuhkan rekayasa yang harus difokuskan kepada apa software harus menyelesaikan masalah, bukan kepada bagaimana pengolahan akan dilaksanakan.

Software Prototyping
Analisis harus dilakukan terlepas dari paradigma rekayasa perangkat lunak yang diterapkan. Namun, bentuk yang digunakan untuk dianalisis akan bermacam-macam. Pada situasi yang lain, elisitasi kebutuhan (melalui FAST, QFD, use-cases, atau brainstorming yang lain diperlukan, penerapan prinsip analisis, dan sebuah model dari software yang akan dibentuk, disebut prototype, yang dibuat untuk penilaian customer dan pengembang. Akhirnya, beberapa keadaan membutuhkan konstruksi dari prototipe pada awal dari analisis.

Memilih Pendekatan Prototyping

Paradigma dalam prototyping dapat berupa closeended atau open-ended. Pendekatan close-ended sering disebut throwaway prototyping. Dengan menggunakan pendekatan ini, prototipe berfungsi hanya semata-mata sebagai demonstrasi kasar. Hal itu kemudian di gantikan, dan software dibuat dengan paradigma yang berbeda. Menggunakan pendekatan open-ended, atau evolutionary prototyping, menggunakan prototipe sebagai bagian utama dari suatu kegiatan analisis yang akan dilanjutkan ke dalam desain dan konstruksi.

 Sebelum pendekatan close-ended atau openended dapat dipilih, perlu untuk ditentukan terlebih dahulu apakah sistem yang akan dibangun ini dapat menerima prototyping. Beberapa faktor urut prototyping yang dapat didefinisikan: 1. Wilayah aplikasi 2. Kompleksitas aplikasi 3. Karakteristik customer 4. Karakteristik projek

 Dalam keseharian, semua aplikasi yang membuat tampilan visual yang dinamik, berinteraksi secara aktif dengan user, atau kebutuhan algoritma untuk pengelolaan kombinatorial yang harus dikembangkan merupakan kandidat untuk prototiping. Karena customer harus berinteraksi dengan protipe pada langkah selanjutnya, adalah penting bahwa: 1. Customer berkomitmen untuk evaluasi dan penyempurnaan protipe. 2. Customer dapat membuat syarat keputusan secara tepat waktu.

Prototyping Methods and Tools

Agar prototiping software dapat efektif, prototipe harus dikembangkan dengan cepat agar customer dapat menetapkan hasil dan merekomendasi apabila terjadi perubahan. Untuk menciptakan prototiping yang cepat, berikut 3 kelas dasar dari methods and tools yang dapat digunakan: 1. Four generation techniques 2. Reusable software components 3. Formal specification and prototyping environments

Fourth Generation Techniques

Mencakup array yang luas dari query database dan bahasa reporting, generator program dan aplikasi, dan tingkat bahasa non-procedural lainnya. Karena 4FT memungkinkan pembuat software untuk menciptakan kode yang dapat dieksekusi secara cepat, cara ini sangat tepat untuk prototiping yang cepat.

Reusable Software Components

Pendekatan lain yang digunakan untuk mempercepat prototiping adalah untuk merakit, dari pada membangun, sebuah prototipe dengan menggunakan beberapa komponen software yang sudah ada. penyatuan prototyping dan menggunakan kembali komponen program akan bekerja hanya jika sistem library dikembangkan sehingga komponen yang ada dapat dikategorikan dan kemudian diambil. Harus dicatat bahwa produk software yang sudah ada dapat digunakan sebagai prototipe untuk memperbaharui dan mengimprovisasi produk kompetitif lainnya.

Formal Specification and Prototyping Environtments

Selamat hampir lebih dari 2 dekade, sejumlah bahasa dengan spesifikasi formal dan alat-alat telah dikembangkan sebagai pengganti bahasa alami dalam teknik spesifikasi. Sekarang ini, para pengembang mengembangkan lingkup interaktif yang: 1. Membuat analis lebih interaktif membuat sistem / software dengan spesifikasi berbasis bahasa. 2. Memanggil alat yang otomatis menerjemahkan spesifikasi berbasis bahasa ke dalam kode yang executable. 3. Membuat customer dapat menggunakan kode yang dapat dijalankan dari prototipe untuk mendapatkan kebutuhan formal

Specification
Prinsip Spesifikasi Spesifikasi, terlepas dari cara mana yang telah dilalui untuk mencapai hal tersebut, dapat juga dilihat sebagai proses representasi. Persyaratan diwakili dengan suatu cara yang akhirnya mengarah pada implementasi software yang sukses. Diataptasi dari Balzer and Goodman, berikut beberapat prinsip dari spesifikasi:

1. Terpisah secara funsional dari pelaksanaan 2. Mengembangkan model dengan perilaku yang diinginkan dari suatu sistem yang meliputi data dan respon fungsional dari sistem terhadap berbagai rangsangan dari lingkungan. 3. Menetapkan konteks di mana perangkat lunak beroperasi dengan menentukan cara di mana komponen sistem lainnya berinteraksi dengan perangkat lunak. 4. Membuat model kognitif daripada mendesain atau mengimplementasikan model. Model kognitif mendeskripsikan sistem seperti yang dialami oleh komunitas pengguna

5. Mendefinisikan lingkungan di mana sistem beroperasi dan menunjukkan bagaimana "koleksi yang terjalin oleh agen yang bereaksi terhadap rangsangan dalam lingkungan yang dihasilkan oleh agen-agen lain 6. Menetapkan isi dan struktur dari spesifikasi dengan cara yang akan memungkinkan untuk menjadi setuju untuk berubah. prinsip-prinsip kedalam realisasi. tersebut harus ditranslasikan

 Representasi kita telah melihat bahwa persyaratan perangkat lunak dapat ditentukan dalam berbagai cara. Namun, jika persyaratan tersebut diharuskan untuk kertas atau media presentasi elektronik, berikut beberapa cara yang dapat diikuti: 1. Format dan isi representasi harus relevan dengan problem 2. Informasi yang terkandung dalam spesifikasi harus tepat 3. Diagram dan bentuk notasi lainnya harus dibatasi dalam jumlah tertentu dan konsisten dalam penggunaannya. 4. Representasi harus dapat di revisi

 Spesifikasi Kebutuhan Software spesifikasi kebutuhan perangkat lunak diproduksi pada puncak dari tugas analisis. Fungsi dan performa dialokasikan kepada software sebagai bagian dari rekayasa sistem yang diperhalus dengan membentuk deskripsi informasi yang lengkap. Deskripsi fungsi yang detail, representasi dari perilaku sistem, dan indikasi dari performa yang dibutuhkan serta kendala design, kriteria validasi yang sesuai, dan informasi lainnya yang berkaitan dengan kebutuhan tersebut.

Sebuah Introduction dari sebuah persyaratan spesifikasi software menyatakan tujuan dan sasaran dari software tersebut, mendeskripsikan itu semua di dalam konteks yang berdasarkan pada sistem komputer. Sebuah deskripsi informasi (information description) menyediakan deskripsi yang detail dari masalah yang harus diselesaikan oleh software. Deskripsi masing-masing fungsi diperlukan untuk menyelesaikan masalah yang di presentasikan didalam functional description. Bagian deskripsi perliaku (behavioral description) dari spesifikasi meneliti pengoperasian software sebagai konsekuensi dari kejadian eksternal dan karakteristik kontrol internal.

Kriteria validasi merupakan hal yang paling penting dan ironisnya juga merupakan hal yang paling sering diabaikan pada perysaratan spesifikasi software. Pada akhirnya, spesifikasi meliputi daftar pustaka dan appendix. Daftar pustaka mereferensikan semua dokumen yang berkaitan dengan software tersebut, juga termasuk dokumen rekayasa software lainnya, referensi teknikal, dan standards. Appendix melputi informasi yang berfungsi sebagai tambahan dari spesifikasi.

Specification Review
Sebuah review dari persyaratan kebutuhan software dibuat oleh kedua pihak, baik pengembang software maupun customer. Karena spesifikasi membentuk dasar dari tahap pengembangan selanjutnya. Sekali review selesai dibuat, persyaratan kebutuhan software sudah ditandatangani oleh pihak customer maupun pengembang. Spesifikasi tersebut berupa kontrak untuk pengembang software. Permintaan perubahan dalam persyaratan setelah spesifikasi telah diselesaikan tidak akan dihilangkan.