REKAYASA PERANGKAT LUNAK (IF 1483)

Presentasi berjudul: "REKAYASA PERANGKAT LUNAK (IF 1483)"— Transcript presentasi:

1 REKAYASA PERANGKAT LUNAK (IF 1483)
Pertemuan 5 Requirements Engineering Heriyanto IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

2 IF 1483 - RPL TEKNIK INFORMATIKA
Deskripsi Menjelaskan requirement engineering IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

3 Tujuan Instruksional Umum (TIU)
Mahasiswa mampu membuat dan menganalisa requirement engineering dari perangkat lunak IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

4 Introduction to Requirements
Definisi “A feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose” Fitur/ciri dari system atau deskripsi dari system, kemampuan dari system untuk memenuhi kegunaan/tujuan dari sistem Tipe Requirements Functional Non-functional Strengths/Penekanan Must/Shall Should Will Functional describes an interaction between the system and its environment acceptable states, how the system should respond to stimuli Non-functional Constraint, a restriction of the system that limits our choices for constructing a solution User Interface Requirements Constraints placed upon the system to ensure usability System Requirements Constraints placed upon the system by physical or environmental factors Performance Requirements Constrains placed upon the operation of the system in order to achieve stated goals Must/Shall - system has to do this, cannot be delivered without Should - important, but not essential for the system to do this Will - possibility, but could be eliminated or postponed to another release Discussion Topic: Brainstorming - requirements for university registration system? IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

5 Requirements Engineering
REQUIREMENTS ELICITATION DEFINITION AND ANALYSIS AND SPECIFICATION Problem analysis Problem description Prototyping and testing Documentation and validation Requirements Definition Complete listing of everything the customer expects the proposed system to do Primarily for customer’s understanding Requirement Specification Restates the requirements in technical terms appropriate for development of system design Primarily for software development team’s understanding Have we captured Are we using Is this function Have we captured all the user need? the right feasible? what the user techniques or expects? views? IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

6 IF 1483 - RPL TEKNIK INFORMATIKA
Requirements Goal/Tujuan Untuk memahami masalah(problem) Keperluan dari memahami Requirement Organization Existing Systems Processes Improvements Setelah semua informasi didapat, apa yang selanjutnya dilakukan? To Review: The goal of requirements is to be sure that we understand the problem, before we set out to provide a solution. To Understand Requirements Organization - formal structure Existing Systems - how they operate and how they are built Processes - operating procedures, description of tasks Improvements - what needs to be changed (10 Minutes) Discussion Topic: What are some techniques/methods to gather information in the problem domain? IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

7 Requirements Elicitation Cara Memperoleh Requirement
Teknik memperoleh requirements Interview / Meeting Survey / Questionnaire Observasi Ethnography / Temporary Assignment Business Plans Review Internal / External Documents Review Software Pros/Cons of Each Technique INTERVIEW + Qualitative & Quantitative info - Requires skill + Detail and summary info - Results may contain bias + Good for surfacing requirements - Produce misleading or inaccurate info QUESTIONNAIRE + Anonymous -> more honest Responses - Imperfect Recall + Can survey many people easily - No answer = no information + Best for limited responses, close-ended ?s - Misunderstood questions + Gets many users involved - Low reliability or validity GROUP MEETING + Decisions can be made - More people = more time for decision + Both detail & summary info - Wastes time, interruptions + Good for surfacing requirements - Arguments about turf/politics + Gets many users involved - Wrong participants, low results OBSERVATION + Surface unarticulated procedures, criteria - Not representative time period + Not biased by opinion - Behavior change due to observation + Good problem domain understanding - Time consuming IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

8 Cara memperoleh Informasi Information Gathering
Organisasi Existing System Sistem yang sudah ada Proses Improvements Organization Business Plan Existing internal documents Group Meetings Organization Chart Existing Systems Review Software Application Documentation Interview internal managers Interview external users of the same software Processes Business Plans Interviews/Meetings Observation Improvements Surveys Interviews/Meetings with key people IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

9 Requirements Analysis Analisa Kebutuhan
Tujuan Menjembatani gap antara problem domain dan technical domain Tasks/Kegiatan Problem Recognition Evaluation and synthesis Modeling Specification Review Problem Recognition: Recognition of the basic problem elements as perceived by the customer Evaluation & Synthesis Definition of solution and Develop a unified view of the application Models Represent your ideas about the application Specification/Documentation Prepare final forms and written analysis Review Review with customer & with peers entire analysis IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

10 Prinsip di dalam Analisa Kebutuhan Requirements Analysis Principles
Domain informasi dari problem harus direpresentasikan dan dimengerti Fungsi dari software yang akan dibuat harus didefinisikan Perilaku dari software harus direpresentasikan Model yang menggambarkan informasi, fungsi dan perilaku harus dipisahkan Proses Analysis dimulai dari informasi yang esensial menuju detil implementasi Systematic process for examining a problem: Look at information domain to ensure complete understanding Models are used to communicate the information clearly and compactly Partitioning reduces complexity Essential/implementation views are necessary to accommodate logical constraints imposed by processing requirements and physical constraints imposed by other system elements IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

11 IF 1483 - RPL TEKNIK INFORMATIKA
Requirements Review? Apakah requirements complete/lengkap? Apakah requirements concise/ringkas? Apakah requirements correct/benar? Apakah requirements consistent/konsisten? Apakah requirements modular? Apakah sudah mengakomodasi change/perubahan? Apakah requirements realistic/realistis? Apakah requirement benar2 dibutuhkan oleh customer? Apakah requirements traceable/bisa ditelusuri? Complete - do we have everything? Concise - lack of ambiguity Correct - is everything right? Consistent - Do all the pieces match up? Are all conflicts resolved? Modular - Traceability - Can the representation be tied back directly to explicitly stated requirements? Accommodation for change - As things inevitably change and grow, can be make changes to the model/representation without having to start over? IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

12 IF 1483 - RPL TEKNIK INFORMATIKA
Ringkasan Materi Definisi requirement Cara Memperoleh requirement Analisa Kebutuhan IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

13 IF 1483 - RPL TEKNIK INFORMATIKA
Tugas Tiap kelompok berdiskusi untuk menentukan requirement dari software yang akan di develop IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK

14 IF 1483 - RPL TEKNIK INFORMATIKA
Referensi Software Engineering:  A Practitioner's Approach (Bab 10 & 11) Pengarang :  Roger S. Pressman Penerbit:  Fourth Edition, McGraw-Hill, 1997 IF RPL TEKNIK INFORMATIKA UPN “VETERAN” YK