ความต้องการด้าน ซอฟต์แวร์ (Software Requirement)

ความต้องการด้านซอฟต์แวร์(Software Requirement)

วัตถุประสงค์ • เพื่ออธิบายถึงความต้องการด้านซอฟต์แวร์ • เพื่ออธิบายถึงระดับของความต้องการด้านซอฟต์แวร์ • เพื่ออธิบายถึงประเภทความต้องการด้านซอฟต์แวร์ • เพื่ออธิบายถึงการวิเคราะห์ความต้องการ

ความต้องการ (Requirement) • เป็นวัตถุดิบสำคัญ ในการพัฒนาระบบหรือการผลิตซอฟต์แวร์ เพื่อใช้เป็นข้อกำหนดถึงหน้าที่และรายละเอียดต่างๆ ที่ระบบหรือซอฟต์แวร์จำต้องมี รวมถึงข้อจำกัดในการทำงานของระบบหรือซอฟต์แวร์ นั้น • ทีมวิศวกรจะต้องเก็บรวบรวมข้อมูลจากลูกค้าหรือผู้ใช้ แล้วมาจำแนกความต้องการในด้านต่างๆ ถ้าซอฟต์แวร์ไม่สามารถตอบสนองความต้องการที่แท้จริงได้ อาจไม่ได้รับความนิยมหรือไม่ได้รับความพึงพอใจจากลูกค้า • ความต้องการมีรายละเอียดต่างกันไป เริ่มตั้งแต่เป็นเอกสารฉบับย่อ ไปจนถึงลงรายละเอียดในระดับสูตรทางการคำนวณ

ระดับ (Level) ของความต้องการด้านซอฟต์แวร์ • ความต้องการของลูกค้าหรือผู้ใช้เป็นตัวกำหนดฟังก์ชันการทำงาน รูปลักษณ์ ความสามารถ และรายละเอียดอื่น ๆ ของระบบหรือซอฟต์แวร์ จำแนกเป็น 2 ระดับดังนี้ • ความต้องการของลูกค้า (User Requirement) • ความต้องการด้านระบบ (System Requirement)

ความต้องการของลูกค้า (User Requirement) • เป็นความต้องการที่มีต่อระบบซึ่งระบุโดยผู้ใช้ระบบ โดยจะอธิบายทั้งส่วนที่เป็นหน้าที่หลัก และส่วนที่ไม่ใช้หน้าที่หลักของระบบ โดยแสดงออกมาในรูปแบบเอกสารที่ใช้ภาษาธรรมชาติที่เข้าใจง่าย ที่แสดงถึงความคาดหวังในการบริการ หรือการทางานที่จะได้รับจากระบบและเงื่อนไขที่ต้องทำตาม

ความต้องการด้านระบบ (System Requirement) • เป็นการกำหนดความต้องการการทำงาน ฟังก์ชัน และบริการต่างๆ ที่ระบบจะต้องมี ความต้องการด้านระบบเป็นความต้องการที่ได้จากการวิเคราะห์ข้อมูลความต้องการของผู้ใช้มาแล้ว เป็นข้อมูลที่มีความสำคัญ การเขียนข้อกำหนดความต้องการด้านระบบ ควรใช้ภาษาธรรมชาติหรือภาษาที่เข้าใจง่าย

ตัวอย่าง: ระบบห้องสมุดมหาวิทยาลัย • นิยามความต้องการของผู้ใช้ (User requirements definition) • ระบบต้องเตรียมวิธีการนำเสนอและการเข้าถึงแฟ้มข้อมูลภายนอกที่สร้างโดยเครื่องมืออื่นๆ • ข้อกำหนดความต้องการของระบบ (System requirements specification) • ควรมีการอำนวยความสะดวกในการกำหนดประเภทของแฟ้มข้อมูลภายนอกให้แก่ลูกค้า • แฟ้มข้อมูลภายนอกแต่ละประเภทอาจมีเครื่องมือที่เกี่ยวข้องซึ่งอาจถูกประยุกต์ใช้กับแฟ้มข้อมูลได้ • แฟ้มข้อมูลภายนอกแต่ละประเภทอาจถูกนำเสนอเป็นรูปไอคอนเฉพาะบนส่วนแสดงผลของผู้ใช้ • การอำนวยความสะดวกควรถูกจัดเตรียมเอาไว้เป็นไอคอนการนำเสนอประเภทแฟ้มข้อมูลภายนอกให้กำหนดโดยผู้ใช้ • เมื่อผู้ใช้เลือกไอคอนแฟ้มข้อมูลภายนอก ผลของการเลือกจะเป็นการใช้เครื่องมือที่เกี่ยวข้องกับประเภทของแฟ้มข้อมูล

ประเภท (Category) ของความต้องการด้านซอฟต์แวร์ ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็น 3 ประเภท คือ • ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) • ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement) • ความต้องการจากปัจจัยภายนอก (External Requirement)

ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) เป็นความต้องการให้ซอฟต์แวร์ทำหน้าที่ใด ๆ ตามที่กำหนดไว้ ซึ่งเป็นสิ่งที่ซอฟต์แวร์ควรจะทำเป็นหน้าที่หลักในการทำงาน หรือเป็นบริการที่ซอฟต์แวร์ควรมี ยกตัวอย่างเช่น ระบบทะเบียน • นักศึกษาสามารถตรวจสอบผลการเรียนและสภาพนักศึกษาได้ • นักศึกษาสามารถลงทะเบียนและทำการเพิกถอนรายวิชาได้ • อาจารย์สามารถตรวจสอลกลุ่มนักศึกษาในรายวิชาที่เป็นผู้สอนได้ • อาจารย์สามารถตรวจสอบผลการเรียนของนักศึกษาในรายวิชาของตน หลังจากส่งผลการเรียนไปยังผ่ายทะเบียนแล้ว เพื่อดูความถูกต้อง • อาจารย์และนักศึกษาสามารถติดตามเอกสารคำร้องต่างๆ ที่ยื่นต่อฝ่ายทะเบียนได้ • เจ้าหน้าที่ฝ่ายทะเบียนสามารถ เพิ่ม ลบ และแก้ไข ข้อมูลต่างๆ ในระบบตามหน้าที่ได้

ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) • เป็นการบ่งบอกว่าระบบควรทำอะไร • ขึ้นอยู่ชนิดของซอฟต์แวร์ที่กำลังพัฒนา, ผู้ใช้เป้าหมาย, และวิธีการที่องค์กรใช้ในการเขียนเอกสารความต้องการนั้น • ถ้าเป็น user requirements ความต้องการที่เป็นหน้าที่หลัก จะเขียนในรูปแบบที่ค่อนข้างเป็นนามธรรม • ถ้าเป็น system requirements ความต้องการที่เป็นหน้าที่หลัก จะเขียนฟังก์ชันโดยรายละเอียด ข้อมูลนำเข้ามีอะไรบ้าง ข้อมูลออกมีอะไรบ้าง สิ่งที่คาดว่าจะได้รับ และอื่นๆ

ตัวอย่าง: ระบบห้องสมุดมหาวิทยาลัย • ระบบห้องสมุดมหาวิทยาลัย ซึ่งมี interface เดียว เชื่อมต่อไปยังหลายฐานข้อมูลที่รวบรวมบทความต่างๆ ไว้ ผู้ใช้สามารถดาวน์โหลดบทความที่ตีพิมพ์ในนิตยสาร หนังสือพิมพ์ และวารสาร ได้ • ผู้ใช้: นักเรียน และคณะ เป้าหมาย: เพื่อสั่งหนังสือและเอกสารจากห้องสมุดอื่น ความต้องการที่เป็นหน้าที่หลัก (Functional Requirements for a university library system) • ผู้ใช้จะสามารถค้นหาข้อมูลหนังสือหรือเอกสารได้จากทั้งฐานข้อมูล หรือจากส่วนย่อยของฐานข้อมูล • ระบบควรมีส่วนมุมมองที่เหมาะสม ที่ให้ผู้ใช้ อ่านหรือตรวจดูเอกสารที่ค้นหาได้ • ทุกๆ การสั่งหนังสือหรือเอกสารจากห้องสมุดอื่น ควรมีการระบุหมายเลขการสั่ง (order_id) เพื่อให้ผู้ใช้สามารถทาสำเนาเก็บไว้ในส่วนเก็บเอกสารถาวรได้

ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement) • เป็นความต้องการที่ไม่เกี่ยวข้องโดยตรงกับฟังก์ชันหลักของระบบ แต่เกี่ยวข้องทางอ้อมในลักษณะที่เป็นเงื่อนไขการทำงาน หรือข้อจำกัดของบริการ หรือการทำงานของระบบ • มักเกี่ยวข้องกับคุณสมบัติที่เกิดขึ้นในระบบ เช่น ความน่าเชื่อถือ, เวลาในการตอบสนอง, เนื้อที่จัดเก็บข้อมูล • นอกจากนี้ มักใช้บอกถึงข้อจำกัดของระบบ ได้แก่ ข้อจำกัดด้านเวลา, ข้อจำกัดด้านกระบวนการ, มาตรฐานการพัฒนา, ความสามารถของอุปกรณ์ I/O และวิธีการนำเสนอข้อมูลในส่วน user interface • ความต้องการนี้อาจรวมถึง ประสิทธิภาพ, ความปลอดภัย, ความสามารถในการทางาน, และคุณสมบัติอื่นๆ ที่เกิดขึ้นมาของระบบ

ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement) • ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ อาจมาจากความต้องการของผู้ใช้หลาย ๆ ด้านที่ไม่เกี่ยวข้องกับซอฟต์แวร์เพียงอย่างเดียว ดังนี้ • ความต้องการด้านผลิตภัณฑ์ (Product Requirement) • ความต้องการขององค์กร (Organizational Requirement) • ความต้องการจากปัจจัยภายนอก (External Requirement)

ความต้องการด้านผลิตภัณฑ์ (Product Requirement) • เป็นการระบุพฤติกรรมของผลิตภัณฑ์ แบ่งออกเป็น 3 ส่วน ได้แก่ • ความต้องการด้านประสิทธิภาพของผลิตภัณฑ์ (Performance Requirement) : ระบบประมวลผลได้เร็วแค่ไหน, หน่วยความจาที่ต้องการมีมากเท่าใด • ความต้องการด้านความน่าเชื่อถือ (Reliability Requirement) : ระดับความล้มเหลวที่สามารถยอมรับได้ • ความต้องการด้านการทำงานข้ามแพลตฟอร์มได้ (Portability Requirement) และใช้งานง่าย (Usability Requirement) :

ความต้องการขององค์กร (Organizational Requirement) • เป็นความต้องการที่มาจากนโยบายและระเบียบปฏิบัติของลูกค้าและผู้พัฒนา โดยกำหนดข้อตกลงระหว่างองค์กร ไว้เพื่อเป็นแนวทางในการพัฒนาที่ตรงตามความต้องการของทั้งสองฝ่าย

ความต้องการจากปัจจัยภายนอก (External Requirement) • เป็นความต้องการที่เกิดจากปัจจัยภายนอก ซึ่งส่งผลต่อซอฟต์แวร์และกระบวนการพัฒนา แบ่งเป็น 3 ส่วน ดังนี้ • ความต้องการการทำงานร่วมกัน (Interoperability Requirement) • ความต้องการในทางกฎหมาย (Legislative Requirement) • ความต้องการในด้านหลักจริยธรรม (Ethical Requirement)

ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement)

ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement) ตัวอย่าง: ระบบห้องสมุดมหาวิทยาลัย • ความต้องการที่ไม่เป็นเชิงฟังก์ชัน (Non-functional Requirements) • ความต้องการด้านผลิตภัณฑ์ 8.1 ส่วนติดต่อผู้ใช้ของระบบ LIBSYS ควรเขียนในรูปแบบ HTML แบบง่ายๆ โดยไม่ต้องทำเป็นเฟรม หรือเป็นแบบ Java applets • ความต้องการด้านองค์กร 9.3.2 กระบวนการพัฒนาระบบและเอกสารที่จะส่งมอบ ควรมีความสอดคล้องกับ กระบวนการและเอกสารการส่งมอบที่กำหนดไว้ในมาตรฐานของ XYZCo-SP-STAN-95. • ความต้องการด้านปัจจัยภายนอก 10.6 ระบบไม่ควรเปิดเผยข้อมูลส่วนตัวของผู้ใช้ระบบให้เจ้าหน้าที่ห้องสมุดทราบ ยกเว้นจะเป็นชื่อและหมายเลขอ้างอิงในห้องสมุด

ความต้องการทางด้านงานธุรกิจ (Domain Requirement) • เป็นความต้องการที่มาจากงานธุรกิจของระบบ และความต้องการเหล่านี้สะท้อนถึงคุณลักษณะและข้อจำกัดต่างๆ ของธุรกิจ ซึ่งความต้องการประเภทนี้เป็นได้ทั้ง functional หรือ non-functional • เป็นความต้องการที่ได้มาจาก application domain ของระบบมากกว่าที่จะได้มาจากความต้องการเฉพาะของผู้ใช้ระบบ • โดยทั่วไป ประกอบด้วยศัพท์เฉพาะทางของโดเมนนั้น ๆ หรือการอ้างอิงไปยัง แนวคิดของโดเมนนั้น ๆ • มันอาจเป็น functional requirements แบบใหม่, เป็นเงื่อนไขที่มีใน functional requirements หรือเป็นการกำหนดวิธีการคำนวณตามโดเมน

ความต้องการทางด้านงานธุรกิจ (Domain Requirement) ตัวอย่าง: ระบบห้องสมุดมหาวิทยาลัย • ความต้องการเชิงโดเมน (Domain Requirements) • จะมีส่วนติดต่อผู้ใช้ที่เป็นมาตรฐานเชื่อมไปยังฐานข้อมูลทั้งหมดที่อาศัยมาตรฐาน Z39.50 • เนื่องจากข้อจำกัดทางด้านลิขสิทธิ์ เอกสารบางอย่างต้องถูกลบออกทันทีที่ส่งไปถึงปลายทาง ซึ่งจะขึ้นอยู่กับความต้องการของผู้ใช้ด้วยว่า จะให้พิมพ์ที่ฝั่งระบบ Server ด้วยมือแบบ Local หรือจะพิมพ์ที่เครื่องพิมพ์ผ่านเครือข่าย

สรุป ความต้องการของผู้ใช้(User Requirement) • เป็นความต้องการที่มีต่อระบบซึ่งระบุโดยผู้ใช้ระบบ โดยจะอธิบายทั้งส่วนที่เป็นหน้าที่หลัก และส่วนที่ไม่ใช้หน้าที่หลักของระบบ ด้วยภาษาที่ผู้ใช้อ่านแล้วเข้าใจง่าย ไม่ควรใช้คำศัพท์เทคนิคมากเกินไป • ดังนั้น การเขียนข้อกำหนดความต้องการของผู้ใช้ จะต้องใช้ภาษาที่เข้าใจง่าย อาจใช้แผนภาพเพื่อแสดงรายละเอียด ในระดับที่ผู้ใช้พอจะเข้าใจได้ หรืออธิบายในลักษณะของตารางหรือแบบฟอร์มง่ายๆ อย่างไรก็ตามอาจเกิดปัญหา ดังนี้

สรุป ความต้องการของผู้ใช้ (User Requirement) • ขาดความชัดเจน • ไม่สามารถจำแนกประเภทของความต้องการได้อย่างชัดเจน • บางครั้งความต้องการมีจุดประสงค์เดียวกัน แต่เขียนออกมาในประโยคที่ต่างกัน จากปัญหาที่เกิดขึ้น การจัดทำเอกสารความต้องการต้องมีการแยกรายละเอียด ความต้องการของระบบออกจากผู้ใช้ เพื่อหลีกเลี่ยงความรู้สึกต่อต้าน ควรมีหลักปฏิบัติดังนี้ • กำหนดมาตรฐานของรูปแบบเอกสาร • จำแนกความจำเป็นของความต้องการ โดยจำแนกเป็น ความต้องการที่จำเป็น (Mandatory Requirement) (ต้อง) และความต้องการที่ปรารถนา (Desirable Requirement) (ควร)

ความต้องการด้าน ซอฟต์แวร์ (Software Requirement)