1. 2. Definition of the Software Requirement Knowledge ความหมายของขอบเขตsw
1.1. ภาพรวมของความต้องการในทาง se
1.1.1. มีข้อกำหนดแนวความคิดของความต้องการ sw
1.1.2. มีแรงจูงใจ
1.1.3. มีกระบวนการทั่วไปในการวิเคราะห์
1.1.4. มีกระบวนการส่งมอบความต้องการ
1.2. 2.1. req. คือ?
1.2.1. req จะต้องสามารถรองรับกับปัญหาบนโลกแห่งความเป็นจริง (หมายถึงมองข้อกำหนดของ ระบบ system มากกว่า การแก้ปัญหา solution เพราะจะทำให้กังวลกับปัญหาที่มี sw ที่ใช้กับ solution
1.2.2. ความต้องการทั่วไปจะมีความซับซ้อนและแตกต่างกันในด้านต่าง ๆ ด้าน คนที่แตกต่าง องกรณ์แตกต่าง และจากสิ่งแวดล้อม ซึ่งในความแตกต่างสามารถวาดความแตกต่างระหว่า product parameter and process parameter มีกระบวนการดังนี้
1.2.2.1. ฟังก์ชั่นความต้องการบนระบบ เช่น มี format some text หรือมีข้อกำหนดที่เป็นลายลักษณ์อักษร
1.2.2.2. สิ่งที่ไม่ใช่ฟังก์ชั่นของความต้องการ เช่น performance ประสิทธิภาพ, maintain req., safety req. etc.
1.3. 2.2 ระบบของความต้องการ และโปรแกรมควบคุมกระบวนการ
1.3.1. นิยามบางครั้งเรียกว่า user requirement
1.3.1.1. ลูกค้าในระบบ
1.3.1.2. end user
1.3.2. สิ่งที่ทำให้ req เกิดผลเสียกับระบบ
1.3.2.1. ผู้ใช้งาน user - คนที่จะทำงานกับระบบ ผู้ใช้มักจะมีกลุ่มที่แตกต่างกัน ประกอบด้วยบทบาทที่แตกต่างกัน และความต้องการ
1.3.2.2. ลูกค้า customer - ผู้ที่ได้รับมอบหมายเป็นตัวแทนของตลาดกำหนดเป้าหมายของระบบ
1.3.2.3. นักวิเคราาะห์ตลาด market analyst - ปกติจะไม่มีการเขียนโปรแกรมโดยไม่มีการว่าจ้าง ดังนั้นต้องมีการสร้างสิ่งที่ตลาดต้องการก่อน
1.3.2.4. สาระควบคุม Regulators - จะมีการทำโดเมนโปรแกรมประยุกต์หลายชนิด เช่น banking, ระบบขนส่งที่จะต้องได้รับการควบคุมซึ่งข้อกำหนดเหล่านี้จะต้องสอดคล้องกับหน่วยงานที่ดูแล
1.3.2.5. นักพัฒนาระบบ system dev. - ซึ่งนักพัฒนาเองต้องมีการระมัดระวังให้สามารถอยู่ภายใต้ความต้องการ
1.4. 2.3. ภาพรวมของการวิเคราะห์
1.4.1. เป็นกระบวนการของการทึ่งและวิเคราะ์เป็นการมองลำดับเชิงเส้นของกิจกรรมคือมุมมองที่เงียบสงบ
1.5. 2.4. การปฎิวัติวิศวกรรมความต้องการ req. eng. practice
1.5.1. การตรวจสอบถึงสาเหตุเป็นกระบวนการเชิงเส้นคือไม่ค่อยปฎิบัติในบริบทของจริง
1.6. 2.5. สินค้าและการส่งมอบ
1.6.1. วิศวกรรมที่ดีต้องมีกำหนด กระบวนการของผลิตภัณ+ส่งมอบ+มีการกำหนดให้ม่กที่สุด = เอกสาร
1.6.2. สิ่งที่ควรหลีกเลี่ยงเพื่อเป็นสาเหตุการผิดพลาดการตีความ
1.6.2.1. ประโยคยาวมีความซับซ้อนนส่วนย่อยของคำสั่ง
1.6.2.2. การใช้งานข้อตกลงมีมากกว่า 1เหตุผล (ตีความคลุมเคลือ)
1.6.2.3. ข้อเสนอหลายความต้องการเอามานำเสนอเป็นแค่ 1 ความต้องการเดียว
1.6.2.4. ความไม่สอดคล้องกันในการใช้งานของข้อตกลงเช่นการใช้คำพ้องในความหมาย เช่นใช้คำว่าต้องแทนคำว่าควร
1.6.3. เครื่องมือจัดการความช่วยเหลือในการรักษาติดตามข้อมูลมักประกอบด้วยฐานข้อมูลของความต้องการ
1.6.3.1. เพื่อเก็บรายละเอียดความต้องการและคณสมบัติ
1.6.3.2. เพื่อให้ dags ร่องรอยที่จะสร้างได้อัตโนมัติ
1.6.3.3. เพื่อให้การขยายพันธุ์ของการเปลี่ยนแปลงความต้องการสามารถวิเคราะห์ได้เป็นกราฟ
1.6.3.4. เพื่อรายงานการสร้างและสถานความต้องการ
1.6.3.5. เพื่อสร้างความต้องการที่สอดคล้องกับเอกสาร
1.6.3.6. นำไปใช้จัดการในการตั้งค่าตามความต้องการ
2. 3. รายละเอียดของหัวข้อความต้องการ
2.1. 3.1. กระบวนการวิศวกรรมความต้องการ
2.1.1. 3.1.1. แบบจำลองของกระบวนการ
2.1.1.1. +......
2.1.2. 3.1.2. นักแสดงกระบวนการ process actors.
2.1.3. 3.1.3. กระบวนการสนับสนุนและจัดการ
2.1.4. 3.1.4.กระบวนการคุณภาพและการปรับปรุง
2.2. 3.2. การดึงเอาความต้องการ req. elicitation
2.2.1. 3.2.1 แหล่งที่มาความต้องการ
2.2.1.1. เป้าหมาย
2.2.1.2. domain ความรู้
2.2.1.3. ผู้มีส่วนได้เสียของระบบ system stakeholder
2.2.1.4. สภาพแวดล้อมในการดำเนินงาน
2.2.1.5. สภาพแวดล้อมองกรณ์
2.2.2. 3.2.2. เทคนิค elicitation
2.2.2.1. เทคนิกการสัมภาษณ์ Interview
2.2.2.2. การจำลองสถานการณ์ Scenario
2.2.2.3. ภาพต้นแบบ Phototypes
2.2.2.4. การประชุมปรึกษาหารือ Facilitated meeting
2.2.2.5. สังเกตุการณ์ Observation
2.3. 3.3. การวิเคราะห์ความต้องการ
2.3.1. หัวข้อที่เกี่ยวข้องในการวิเคราะห์ความต้องการ
2.3.1.1. ตรวจสอบและแก้ปัญหาความขัดแย้งระหว่างความต้องการ
2.3.1.2. ค้นหาขอบเขตของระบบและวิธีการที่จะต้องมีปฎิสัมพันธ์กับสิ่งแวดล้ม
2.3.1.3. ความต้องการที่มีซอร์ฟแวซับซ้อน