- นำ requirement มาสร้างเป็นเอกสารและป้อนเข้าไปในรอบต่อไป spiral
- กระบวนการในการรวบรวมข้อมูลเกี่ยวกับระบบ
- ทั้งสิ่งที่ต้องการและที่สิ่งมีอยู่แล้ว
- กลั่นกรองออกมาเป็น user requirement และ system requirement จากข้อมูลที่ได้
- การมีปฏิสัมพันธ์กับผู้มีส่วนได้เสียของระบบ เริ่มจากผู้จัดการไปยังหน่วยงานกำกับดูแลภายนอก
- โดยปกติ ระบบมักมีผู้มีส่วนได้เสียหลายกลุ่ม
- ในกระบวนการ RE มักจะมีการสัมภาษณ์ผู้มีส่วนได้ส่วนเสีย ทั้งอย่างเป็นทางการและไม่เป็นทางการ
- ประเภทของการสัมภาษณ์
- การสัมภาษณ์แบบคำถามปลายปิด ตามรายการคำถามที่กำหนดไว้ล่วงหน้า
- การสัมภาษณ์แบบคำถามปลายเปิดที่มีการสำรวจประเด็นต่าง ๆ กับผู้มีส่วนได้ส่วนเสีย
- การสัมภาษณ์ที่มีประสิทธิภาพ
- สัมภาษณ์อย่างใจกว้าง -- เต็มใจที่จะฟังผู้มีส่วนได้ส่วนเสีย
- หลีกเลี่ยง requirement ที่คิดไว้ล่วงหน้า
- ใช้คำถามที่มีประโยชน์ เพื่อให้ได้ requirements
- ทดลองใช้ prototype system ร่วมกัน
- โดยปกติการสัมภาษณ์จะทำทั้งแบบปลายปิดและแบบปลายเปิด
- การสัมภาษณ์เป็นสิ่งที่ดีสำหรับการทำความเข้าใจโดยรวมเกี่ยวกับสิ่งที่ผู้มีส่วนได้ส่วนเสียต้องการ และจะได้รู้ว่าพวกเขามีปฏิสัมพันธ์กับระบบอย่างไร
- ผู้สัมภาษณ์ต้องมีใจกว้างโดยไม่ต้องคิดล่วงหน้าว่าระบบควรทำงานอย่างไร
- พยายามให้ผู้ใช้อธิบายเกี่ยวกับระบบ
- พูดจูงใจให้เขา บอกหรือแนะนำ สิ่งที่ต้องการจากระบบ
- อย่าไปตั้งคำถามโง่ ๆ ว่า “คุณต้องการอะไรจากระบบ”
- Application specialists อาจจะพูดคนละภาษากับ requirements engineer
- พูดคนละภาษารวมถึงใช้ภาษาพูดเดียวกันแต่ทำความเข้าใจยาก
- การสัมภาษณ์ ไม่สามารถใช้ได้ดับการทำความเข้าใจข้อกำหนดของโดเมน
- requirements engineer มักไม่สามารถเข้าใจศัพท์เฉพาะของโดเมน (เช่นศัพท์ทางการแพทย์)
- ความรู้เกี่ยวกับโดเมนบางอย่าง ดูเหมือนจะเข้าใจได้ง่าย แต่พบว่าเป็นการยากที่จะพูดหรือคิดว่าไม่น่าจะพูดออกมาเป็นคำพูดได้
- ดังนั้นจะผิดพลาดมาก ถ้าเขียน requirements ออกมาโดยใช้ความเข้าใจของผู้ดำเนินการสัมภาษณ์เองล้วน ๆ
- สถานการณ์ (Scenarios) และเรื่องราวของผู้ใช้ (user stories) เป็นตัวอย่างชีวิตจริงในการใช้ระบบ
- เรื่องราวและสถานการณ์เป็นคำอธิบายว่าระบบอาจใช้งานใดได้บ้าง
- เนื่องจากผู้มีส่วนได้เสียมักจะทำงานอยู่บนพื้นฐานของสถานการณ์จริง
- ต้องฟังเรื่องราวของพวกเขา
- เราสามารถแสดงความคิดเห็นเกี่ยวกับสถานการณ์หรือเรื่องราวของพวกเขา แต่ต้องทำด้วยความเคารพและให้เกียรติกันและกัน
- เรื่องราวของผู้ใช้ที่มีโครงสร้างอย่างเป็นรูปแบบ
- สถานการณ์ (Scenarios) ควรประกอบด้วย
- คำอธิบายเมื่อตอนเริ่มต้นของสถานการณ์
- คำอธิบายเกี่ยวกับการดำเนินเหตุการณ์ตามปกติของสถานการณ์
- คำอธิบายของสิ่งผิดพลาดที่อาจเกิดขึ้นได้
- ข้อมูลเกี่ยวกับกิจกรรมอื่น ๆ ที่อาจจะเกิดขึ้นในขณะเดียวกัน
- คำอธิบายสถานะเมื่อสถานการณ์เสร็จสิ้น
- เป็นขั้นตอนการเขียนข้อกำหนดของผู้ใช้และระบบในเอกสารข้อกำหนด
- User requirement ต้องเป็นที่เข้าใจของ end user และ customer ที่ไม่มีพื้นฐานทางเทคนิค
- System requirement เป็นข้อกำหนดที่ละเอียดขึ้น และอาจรวมถึงข้อมูลทางเทคนิคเพิ่มเติม
- Requirement อาจเป็นส่วนหนึ่งของสัญญาในการพัฒนาระบบ
- ดังนั้นสิ่งสำคัญคือต้องทำให้ “สมบูรณ์แบบ” ที่สุด
- โดยหลักการ requirement ควรระบุว่าระบบควรทำอย่างไร และการออกแบบควรอธิบายถึงวิธีการเหล่านั้น
- ในทางปฏิบัติ requirement และการออกแบบจะแยกออกจากกันไม่ได้
- Requirement จะถูกเขียนเป็นประโยคภาษาธรรมชาติเสริมด้วยไดอะแกรมและตาราง
- ภาษาธรรมชาติ ใช้สำหรับเขียนข้อกำหนดเนื่องจากใช้งานง่ายและเป็นสากล ซึ่งหมายความว่าผู้ใช้และลูกค้าสามารถเข้าใจ requirement ได้ตรงกัน
- คิดค้นรูปแบบมาตรฐานและใช้สำหรับทุก requirement
- ใช้ภาษาอย่างสม่ำเสมอ
- ใช้คำว่า “ต้อง” เพื่อแสดง ข้อกำหนดที่บังคับ (mandatory requirements)
- ใช้คำว่า “ควร” เพื่อแสดง ข้อกำหนดพึงประสงค์ (desirable requirements)
- ใช้ไฮไลต์ข้อความเพื่อระบุส่วนสำคัญของ requirements
- หลีกเลี่ยงการใช้ศัพท์แสงทางคอมพิวเตอร์ (computer jargon)
- ระบุเหตุผล ที่ต้องมี requirements นั้น ๆ
- ขาดความชัดเจน
- ยิ่งทำให้มีความแม่นยำสูงขึ้น ก็จะยิ่งทำให้อ่านเอกสารได้ยากขึ้น (กลายเป็นภาษาทางกฎหมาย)
- มีความสับสนในเรื่อง requirements
- Functional และ non-functional requirements มีแนวโน้มที่จะผสมกันมากขึ้น
- การควบรวม requirements
- Requirements หลาย ๆ อย่างสามารถเขียนรวมกันได้ ทำให้คนรับช่วงงานมีความยากลำบากในการตีความ
- วิธีการในการเขียนข้อกำหนดที่มีอิสระ มีอยู่อย่างจำกัด และ Requirement มักจะถูกเขียนขึ้นในรูปแบบมาตรฐาน
- วิธีนี้ทำงานได้ดีกับข้อกำหนดบางประเภท เช่น ข้อกำหนดสำหรับระบบควบคุมแบบฝังตัว
- บางครั้งก็ไม่ยืดหยุ่นสำหรับการเขียนข้อกำหนดทางธุรกิจ
- นิยามของฟังก์ชันหรือ entity
- คำอธิบายของ input และแหล่งที่มา
- คำอธิบายของ output และแหล่งปลายทาง
- ข้อมูลเกี่ยวกับข่าวสารที่จำเป็นสำหรับการประมวลผล
- คำอธิบายของการดำเนินการที่จะต้องดำเนินการ
- เงื่อนไขก่อนและหลัง (ถ้ามี)
- ผลกระทบของฟังก์ชั่น (ถ้ามี)
- ใช้เพื่อเสริมภาษาธรรมชาติ
- มีประโยชน์อย่างยิ่ง เมื่อต้องกำหนดจำนวนของทางเลือกที่เป็นไปได้ของการดำเนินการ
- ยกตัวอย่าง เช่น ระบบปั๊มอินซูลิน
- คำนวณหาอัตราการเปลี่ยนแปลงระดับน้ำตาลในเลือด
- Requirement ในรูปแบบตาราง จะอธิบายถึงวิธีคำนวณความต้องการอินซูลินในสถานการณ์ต่างๆ
- Use-case เป็นสถานการณ์สมมติที่ผนวกอยู่ใน UML
- Use-case ระบุ actor ที่อยู่ในปฏิสัมพันธ์และอธิบายการปฏิสัมพันธ์ด้วยตัวเอง
- กลุ่มของ use-case อธิบายปฏิสัมพันธ์ที่เป็นไปได้ทั้งหมดของระบบ
- โมเดลกราฟิกระดับสูงนี้ อาจเสริมด้วยรายละเอียดเพิ่มเติมแบบตาราง
- Sequence diagram ของ UML อาจใช้เพื่อเพิ่มรายละเอียดให้กับ use-case โดยการแสดงลำดับของการประมวลผลเหตุการณ์ในระบบ
- เอกสารข้อกำหนดของซอฟต์แวร์เป็นคำอธิบายอย่างเป็นทางการว่านักพัฒนาระบบต้องใช้อะไรบ้าง
- ควรมีทั้งนิยามของ user requirements และข้อกำหนดของ system requirements
- มันไม่ใช่เอกสารการออกแบบ
- ควรบอกว่าระบบควรทำอะไร (WHAT the system should do)
- ไม่ควรบอกว่าระบบควรทำงานอย่างไร (HOW the system should do)
- ข้อมูลในเอกสาร requirement ขึ้นอยู่กับชนิดของระบบและแนวทางการพัฒนาที่ใช้
- ระบบที่พัฒนาขึ้นเรื่อย ๆ (incremental) จะมีรายละเอียดในเอกสาร requirement น้อยกว่า
- เอกสาร requirement ได้รับการออกแบบให้เป็นมาตรฐาน เช่น มาตรฐาน IEEE
- สามารถใช้งานได้กับ requirement สำหรับโครงการวิศวกรรมระบบขนาดใหญ่