Ulasan Persyaratan Kunci Elemen

1.NURUL C. (2011420007)

2.MARIYA K. (2011420026)

3.JUNIAR A. (2011420143)

4.YANTI DWI A.(2011420031)

5.CHAIDIR ALI M.(2011420121)

6.MUHAMMAD ARIFIN (2011420095)

Ulasan Persyaratan Kunci Elemen

Kebutuhan itu harus melibatkan wakil dari kedua pelanggan dan tim pengembangan, serta setiap manajer .

Tujuannya :

ü  Untuk mencapai kesepakatan dasar antara semua pihak bahwa kasus penggunaan bersama dengan model domain.

ü  Elemen apapun prototipe berada di tempat, menangkap persyaratan fungsional dari sistem.

Ketika semua orang berada di sebuah ruangan secara bersama-sama, dengan fasilitator / moderator terjadi percakapan di jalur dan juru tulis yang mencatat hasil dan item tindakan. Kata kuncinya adalah penelusuran : harus jelas bagaimana kebutuhan masing-masing, satu jejak ke dalam atau lebih kasus penggunaan, dan bagaimana satu atau lebih kelas dari model domain dan satu atau lebih unsur prototipe bekerja sama dengan kasus-kasus digunakan untuk mengatasi kebutuhan.

Bila ada desain perangkat lunak berorientasi objek, Anda mencoba untuk struktur perangkat lunak yang ada di dunia nyata, masalah ruang karena perubahan dunia nyata lebih jarang daripada persyaratan perangkat lunak. Dasar seluruh objek kegiatan kami adalah pemodelan, terutama bagian pemodelan statis dari kegiatan merupakan sebuah model dari abstraksi masalah domain. Evolusi diagram kelas awal yang menunjukkan model domain ke titik di mana Anda dapat kode dari mereka. Penting, jika Anda menangkap abstraksi kunci awal dan bersifat efektif.

Selama pemodelan use case dengan perluasan, kebutuhan-kebutuhan kami akan memfokuskan pada upaya untuk mencoba mengubah perilaku pengguna kami secara detail, karena perilaku perangkat lunak ditentukan oleh kebutuhan pengguna. Dengan kata lain, apabila kita membutuhkan perangkat lunak untuk melakukan, tergantung pada bagaimana pengguna mengakses dan apa yang pengguna coba lakukan. Perlu diingat bahwa semakin didefinisikan dengan baik atas perilaku sistem, maka akan semakin mudah dalam membangun sistem.

Seperti pada Gambar 1-1, kami berfikir bahwa ide yang baik untuk menggunakan prototipe adalah untuk membantu menentukan kasus penggunaan. Kami mendorong klien kami untuk menggunakan prototyping cepat sesering mungkin. Idenya adalah bahwa pengembang dan pengguna berdiskusi bersama saling membangun sesuatu. "Bukti dari konsep" ini adalah besar namun yang memisahkan kita dari eXtreme Programming (XP), buat para komunitas jangan kesalahan bukti prototipe konsep untuk deliverable, shippable software bahkan jika Anda sudah menjalankan beberapa unit test 300 atau lebih kecuali Anda menyukai pengguna Anda menekan Ctrl-Alt-Delete, ketika dihadapkan dengan "layar biru kematian."

Pada saat Anda mencoba menunjukkan sebuah bukti konsep prototipe yang telah dibangun dengan mengorbankan desain “bulletproof”, Anda akan cenderung melakukan hal yang paling sederhana yang mampu Anda kerjakan. Seorang kru konstruksi dalam memasang set film: Mereka dapat membangun sebuah "rumah" terlihat fantastis dari luar, hanya bagian dalam sebagian kecil dari waktu yang dibutuhkan untuk membangun rumah yang nyata, tapi berusaha untuk refactors fasad film ke sebuah rumah yang nyata. Untuk rumah yang nyata, Anda perlu cetak biru, skema listrik, dan rencana untuk pipa. Perlu diingat bahwa bukti dari konsep prototipe yang sama adalah seperti rumah fasad set film. Jangan membangun prototipe Anda dalam kode. Beberapa klien kami menggunakan abstraksi dari GUI disebut aliran interaksi diagram yang sangat efektif untuk tujuan ini.

Desain grafis (GUI) secara paralel dengan perilaku sistem yang diperlukan umumnya merupakan sebuah pendekatan yang sangat baik. Ini melibatkan iterasi, dengan pengguna, aspek presentasi dari sistem, dan setelah mencapai penutupan pada beberapa layar, menulis kasus penggunaan yang terkait. Ini memantul bolak-balik sehingga sangat efektif di lingkungan yang tepat. Anda harus memperluas pemikiran ini untuk meninjau apa yang menjadi kebutuhan Anda : teks untuk kasus penggunaan tertentu harus cocok dengan baik dengan elemen GUI terkait (s), dalam hal deskripsi kasus penggunaan terhadap sifat dasar dari unsur-unsur, dan respons sistem terhadap tindakan pengguna.

Beberapa orang terkemuka di masyarakat yang berorientasi obyek (OO) menganjurkan sebaliknya. Mereka juga bersikeras, Anda tidak harus bicara tentang spesifik GUI dalam teks kasus penggunaan. Anda tidak harus bicara tentang apa-apa yang spesifik, bahwa Anda harus meninggalkan teks Anda sebagai abstrak. Kami percaya bahwa Anda tidak bisa menggerakkan sebuah kasus penggunaan abstrak turun melalui kode. Anda tidak harus berbicara tentang apakah kolom ini berisi satu set tombol radio, atau jendela yang memiliki kedua scroll bar vertikal dan horizontal, tetapi Anda harus benar-benar berbicara tentang "panggilan dan respon," aktor dan system. Anda harus menuliskan nama benda-benda yang akan diikutsertakan. Cara terbaik untuk memastikan tingkat tinggi penelusuran kasus penggunaan dalam analisis dan desain.

Sebuah kasus penggunaan yang paling efektif dinyatakan dari perspektif pengguna sebagai satu set. Aspek lain yang penting dari pemodelan use case melibatkan tindakan alternatif. Seperti dijelaskan di Bab 3, itu sangat penting untuk memikirkan semua program tindakan alternatif, di mana harus menjadi sebagian besar waktu, dengan bertanya, "Apa lagi yang bisa terjadi? Apakah ada hal lain yang bisa terjadi? Apakah Anda yakin? ".

10 Top Persyaratan Ulasan Kesalahan

1)   Jangan khawatir jika kasus penggunaan empat halaman.

Rangkaian dasar dari suatu kasus penggunaan panjangnya harus satu atau dua paragraf dan setiap rangkaian alternatif harus terdapat satu atau dua kalimat. Penggunaan teknik seperti memanggil dan mendahului kontruksi dari sebuah kasus obyek modelling dengan UML. Keefisienan hasil kita dituntut dari template use case yang panjangnya menghasilkan panas jauh lebih ringan.

2)  Jangan mempertanyakan apakah semua program telah dipertimbangkan pada setiap kasus penggunaan.

Kegigihan dalam pencarian untuk rangkaian alternatif merupakan tindakan yang penting. Banyak prilaku menarik dari sistem yang akan terceminkan dan tidak ada dalam mata kuliah.

3)  Jangan khawatir jika kasus penggunaan ditulis dalam suara pasif.

Suara pasif adalah saat penulis tidak tahu siapa atau apa yang melakukan suatu tindakan tertentu, dan itu tidak boleh terjadi dalam use case. Penjelasan tindakan diperlukan dalam kasus penggunaan.

4)  Jangan mempertanyakan kasus penggunaan tanpa program alternatif tindakan.

Pengalaman kami bahwa lebih dari 90 persen dari kasus penggunaan yang baik memiliki satu alternatif tindakan. Penggunaan kata seperti "check" / "memastikan" / "memvalidasi" / "memverifikasi" dalam teks yang digunakan adalah sinyal harus jelas bahwa ada setidaknya satu kursus alternatif, terkait dengan kondisi kesalahan. Sebuah use case juga cenderung memiliki satu jalur, dimana aktor sering mengambil daripada yang ditetapkan oleh program dasar. Anda juga harus rajin menggali pada jalur lainnya.

5)  Jangan pastikan referensi kasus penggunaan teks obyek domain.

Alasan utama kita bahas pemodelan domain (Bab 2). Sebelum kita berbicara tentang pemodelan use case (Bab 3) bahwa tujuan utama dari pemodelan domain adalah untuk membangun sebuah daftar istilah untuk kasus penggunaan teks yang akan digunakan. Teknik ini akan membantu Anda dalam upaya yang lebih spesifik dalam menangani kasus Anda, dan juga akan membantu Anda fokus pada penelusuran, karena penggunaan kasus dan diagram kelas akan bekerja sama. Jadi lebih mudah untuk melakukan analisis ketahanan (subjek Bab 5) dengan cepat jika Anda sudah menggunakan kasus Anda.

6)  Jangan pastikan bahwa model domain secara akurat mencerminkan dunia nyata benda konseptual.

Anda akan membangun kode dari diagram kelas yang memiliki detail yang cukup. Diagram ini berkembang dari tingkat tinggi, dimana kelas diagram yang menunjukkan model domain awal ketika Anda menjelajahi perilaku dinamis dari sistem yang Anda buat. Evolusi ini tidak akan terjadi seperti yang seharusnya, jika Anda tidak mendapatkan hak mengatur obyek domain di tempat yang seharusnya.

7)  Gunakan kasus penggunaan Anda pada tingkat tinggi, Klien non teknisi tidak memiliki petunjuk tentang apa itu.

Kasus penggunaan yang baik memiliki data yang cukup untuk memungkinkan penggunanya dalam mendorong pengembangan sistem dari persyaratan, penemuan di semua jalan melalui kode. Ini berfungsi sebagai alat yang sangat efektif untuk melakukan negosiasi. Persyaratan dengan pelanggan dan mengelolah harapan pelanggan. Ini hanya bekerja pada teks use case khusus yaitu pada aktor yang melakukan hal ini atau sistem yang melakukan hal ini. Pelanggan tidak bisa menandatangani suatu kasus penggunaan jika pelanggan tidak mengerti.

8)  Jangan menggunakan jenis prototipe GUI atau mockup layer untuk membantu memvalidasi perilaku sistem.

Prototipe, apakah mereka mengambil bentuk sepenuhnya untuk diterapkan pada gambar di atas kertas, umumnya memberikan "jump start" untuk menemukan tugas dan mengeksplorasi kasus penggunaan. Untuk memastikan bahwa penggunaan teks pada kasus sesuai dengan navigasi yang menunjukkan prototipe adalah dengan cara yang terbaik untuk memastikan, bahwa Anda akan membangun sistem yang tepat. Jika Anda tidak memiliki kerangka acuan visual, maka Anda akan menjalankan resiko bahwa pengguna antarmuka akan membangun hal-hal yang tidak sesuai dengan kebutuhan pengguna Anda sebagaimana dinyatakan dalam kasus penggunaan.

9)  Pastikan teks cocok dengan perilaku sistem yang diinginkan pengguna.

Ungkapan pengguna mengacu pada prinsip menggunakan kasus penggunaan yang menangkap apa yang mau dilakukan untuk mendorong analisis, desain, pengujian dan bagaimana implementasinya. Jika penggunaan teks pada kasus anda tidak menawarkan korelasi tinggi dengan apa yang digunakan dan akan membangun sistem yang salah.

10)Jangan meninjau persyaratan sama sekali sebaliknya, mengundang fitur–it is dengan membiarkan coders membangun apa pun yang user inginkan.

Fitur–itis yang datang dengan mengorbankan jadwal adalah hasil yang diprediksi membiarkan tim pemrograman memutuskan dan terus berubah. Salah satu prinsip XP adalah persyaratan berubah tiap hari dan tidak masuk akal, sehingga mencoba untuk berhubungan dengan mereka secara eksplisit. Orang – orang XP memiliki slogan keren untuk menggambarkan fenomena ini. Orang yang mengikuti pendekatan ini, akan kehilangan tidak hanya penelusuran persyaratan, tetapi kemampuan untuk membangun kepercayaan antara user dan pengembang yang hanya menghasilkan negoisasi secara intensif / face to face.