p03 Akpl Software Requirement

Analisis Kebutuhan Perangkat
Lunak
Tim Dosen
SOFTWARE REQUIREMENT
WHAT, WHY and WHO - 2
Requirement Management & Development
Elicitation
Elicitation encompasses all of the activities involved with discovering
requirements, such as interviews, workshops, document analysis,
prototyping, and others.
The key actions are:
• Identifying the product’s expected user classes and other stakeholders.
• Understanding user tasks and goals and the business objectives with which
those tasks align.
• Learning about the environment in which the new product will be used.
• Working with individuals who represent each user class to understand their
functionality needs and their quality expectations
Usage-Centric or Product-Centric
• Requirements elicitation typically takes either a usage-centric or a
product-centric approach, although other strategies also are possible.
• The usage-centric strategy emphasizes understanding and exploring
user goals to derive the necessary system functionality.
• The product-centric approach focuses on defining features that you
expect will lead to marketplace or business success. A risk with
product-centric strategies is that you might implement features that
don’t get used much, even if they seemed like a good idea at the
time. We recommend understanding business objectives and user
goals first, then using that insight to determine the appropriate
product features and characteristics.
Analysis
Analyzing requirements involves reaching a richer and more precise understanding of
each requirement and representing sets of requirements in multiple ways.
Following are the principal activities:
1. Analyzing the information received from users to distinguish their task goals from functional
requirements, quality expectations, business rules, suggested solutions, and other
information
2. Decomposing high-level requirements into an appropriate level of detail
3. Deriving functional requirements from other requirements information
4. Understanding the relative importance of quality attributes
5. Allocating requirements to software components defined in the system architecture
6. Negotiating implementation priorities
7. Identifying gaps in requirements or unnecessary requirements as they relate to the defined
scope
Spesification
Requirements specification involves representing and
storing the collected requirements knowledge in a
persistent and well-organized fashion.
The principal activity is:
Translating the collected user needs into written
requirements and diagrams suitable for comprehension,
review, and use by their intended audiences.
Validation
Requirements validation confirms that you have the correct set of requirements
information that will enable developers to build a solution that satisfies the
business objectives.
The central activities are:
• Reviewing the documented requirements to correct any problems before the
development group accepts them.
• Developing acceptance tests and criteria to confirm that a product based on the
requirements would meet customer needs and achieve the business objectives.
Iteration is a key to requirements development success. Plan for multiple cycles of
exploring requirements, progressively refining high-level requirements into more
precision and detail, and confirming correctness with users. This takes time and it
can be frustrating. Nonetheless, it’s an intrinsic aspect of dealing with the fuzzy
uncertainty of defining a new software system.
Requirement Management Activities
• Defining the requirements baseline, a snapshot in time that represents an agreed-
upon, reviewed, and approved set of functional and nonfunctional requirements,
often for a specific product release or development iteration
• Evaluating the impact of proposed requirements changes and incorporating
approved changes into the project in a controlled way
• Keeping project plans current with the requirements as they evolve
• Negotiating new commitments based on the estimated impact of requirements
changes
• Defining the relationships and dependencies that exist between requirements
• Tracing individual requirements to their corresponding designs, source code, and
tests
• Tracking requirements status and change activity throughout the project
“EVERY PROJECT HAS REQUIREMENTS”
When bad requirements happened to good
people
• Kesalahan proses requirement dapat dilakukan dengan cara
mengulang kembali (rework), namun proses ini memakan cost 30 – 50
persen dari Development Cost, sedangkan kegagalan Requirement
dapat dilakukan kembali (rework) dengan memakan cost 75 – 85
persen dari Development Cost
• Sebagai contoh ilustrasi, Membangun Jembatan, jembatan sudah
mulai dibuat, ternyata yang dibutuhkan bukan jembatan melainkan
jalan. Artinya semua dikerjakan ulang dan cost yang sebelumnya
sudah dikeluarkan tidak dapat dikembalikan lagi
Kurangnya Keterlibatan User
• Konsumen/user biasanya bersikap acuh dan mereka tidak mengerti
fungsi keterlibatan mereka dalam kesuksesan proyek PL
• Konsumen/user kadang tidak berani mengambil keputusan karena
mereka juga mengalami tekanan dari atasan mereka
Rencana Tidak Tepat dan Permintaan Yang
Mustahil
• Membangun perangkat lunak tidak dalam kondisi yang tergesa-gesa
• Konsumen tidak paham teknologi, jadi seringkali permintaan mereka
diluar akal sehat
• Contoh : membuat PL semuanya serba otomatis, padahal otomatis
juga ada batasnya
• Permintaan banyak, budget rendah
Requirement yang Ambigu
• Komunikasi konsumen/user lemah
• Ambigu mendorong developer mengartikan
permintaan yang berbeda dengan ekspektasi
• Diperlukan proses validasi untuk menghindari
ambiguitas ini
Gold Platting
• Merupakan istilah daripada : Developer menambahkan fungsionalitas
yang tidak sesuai kebutuhan karena mereka merasa konsumen akan
menyukainya
• Hal ini menjadi percuma apabila user/konsumen tidak peduli
• Don’t forget : “Every things that you build costs time and money”
Tugas Kolaboratif
Kerjakan dalam kelompok kecil ber 4 atau 5.
I. Jelaskan maksud dan aktifitas apa saja dalam keempat fase
Requirement Development (Elisitasi, Analisis, Spesifikasi, Validasi)
II. Berikan contoh kasus untuk kelima hal di bawah ini
1. When bad requirements happened to good people
2. Kurangnya Keterlibatan User
3. Rencana Tidak Tepat dan Permintaan Yang Mustahil
4. Requirement yang Ambigu
5. Gold Platting

p03 Akpl Software Requirement

Uploaded by

Copyright:

Available Formats

p03 Akpl Software Requirement

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

p03 Akpl Software Requirement

Uploaded by

Copyright:

Available Formats

Analisis Kebutuhan Perangkat

You might also like