ข้อกำหนดของซอฟต์แวร์

ข้อกำหนดของซอฟต์แวร์คือคำอธิบายคุณสมบัติและฟังก์ชันการทำงานของระบบเป้าหมาย ข้อกำหนดแสดงถึงความคาดหวังของผู้ใช้จากผลิตภัณฑ์ซอฟต์แวร์ ข้อกำหนดอาจชัดเจนหรือซ่อนอยู่รู้หรือไม่รู้จักคาดหวังหรือไม่คาดคิดจากมุมมองของลูกค้า

วิศวกรรมความต้องการ

กระบวนการรวบรวมข้อกำหนดซอฟต์แวร์จากไคลเอนต์วิเคราะห์และจัดทำเป็นเอกสารเรียกว่าวิศวกรรมความต้องการ

เป้าหมายของวิศวกรรมความต้องการคือการพัฒนาและรักษาเอกสาร 'ข้อกำหนดข้อกำหนดของระบบ' ที่ซับซ้อนและมีความหมาย

กระบวนการวิศวกรรมความต้องการ

เป็นกระบวนการสี่ขั้นตอนซึ่งประกอบด้วย -

• การศึกษาความเป็นไปได้
• การรวบรวมความต้องการ
• ข้อกำหนดข้อกำหนดของซอฟต์แวร์
• การตรวจสอบความต้องการซอฟต์แวร์

ให้เราดูกระบวนการโดยย่อ -

การศึกษาความเป็นไปได้

เมื่อลูกค้าเข้าใกล้องค์กรเพื่อรับผลิตภัณฑ์ที่ต้องการได้รับการพัฒนาจะมีแนวคิดคร่าวๆเกี่ยวกับฟังก์ชันทั้งหมดที่ซอฟต์แวร์ต้องดำเนินการและคุณลักษณะทั้งหมดที่คาดหวังจากซอฟต์แวร์

เมื่ออ้างอิงถึงข้อมูลนี้นักวิเคราะห์จะทำการศึกษาโดยละเอียดว่าระบบและฟังก์ชันการทำงานที่ต้องการนั้นสามารถพัฒนาได้หรือไม่

การศึกษาความเป็นไปได้นี้มุ่งเน้นไปที่เป้าหมายขององค์กร การศึกษานี้วิเคราะห์ว่าผลิตภัณฑ์ซอฟต์แวร์สามารถนำไปใช้จริงได้หรือไม่ในแง่ของการนำไปใช้งานการมีส่วนร่วมของโครงการต่อองค์กรข้อ จำกัด ด้านต้นทุนและตามค่านิยมและวัตถุประสงค์ขององค์กร สำรวจด้านเทคนิคของโครงการและผลิตภัณฑ์เช่นความสามารถในการใช้งานความสามารถในการบำรุงรักษาผลผลิตและความสามารถในการผสานรวม

ผลลัพธ์ของระยะนี้ควรเป็นรายงานการศึกษาความเป็นไปได้ที่ควรมีข้อคิดเห็นและคำแนะนำที่เพียงพอสำหรับการจัดการว่าควรดำเนินโครงการหรือไม่

การรวบรวมความต้องการ

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

ข้อกำหนดข้อกำหนดของซอฟต์แวร์

SRS เป็นเอกสารที่สร้างขึ้นโดยนักวิเคราะห์ระบบหลังจากรวบรวมข้อกำหนดจากผู้มีส่วนได้ส่วนเสียต่างๆ

SRS กำหนดวิธีที่ซอฟต์แวร์ที่ต้องการจะโต้ตอบกับฮาร์ดแวร์อินเทอร์เฟซภายนอกความเร็วในการทำงานเวลาตอบสนองของระบบการพกพาซอฟต์แวร์ข้ามแพลตฟอร์มต่างๆความสามารถในการบำรุงรักษาความเร็วในการกู้คืนหลังจากการขัดข้องความปลอดภัยคุณภาพข้อ จำกัด ฯลฯ

ข้อกำหนดที่ได้รับจากลูกค้าเขียนด้วยภาษาธรรมชาติ เป็นความรับผิดชอบของนักวิเคราะห์ระบบในการจัดทำเอกสารข้อกำหนดในภาษาทางเทคนิคเพื่อให้ทีมพัฒนาซอฟต์แวร์สามารถเข้าใจและเป็นประโยชน์ได้

SRS ควรมาพร้อมกับคุณสมบัติดังต่อไปนี้:

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

การตรวจสอบความต้องการซอฟต์แวร์

หลังจากมีการพัฒนาข้อกำหนดข้อกำหนดข้อกำหนดที่ระบุไว้ในเอกสารนี้จะได้รับการตรวจสอบความถูกต้อง ผู้ใช้อาจขอวิธีแก้ปัญหาที่ผิดกฎหมายไม่สามารถใช้งานได้จริงหรือผู้เชี่ยวชาญอาจตีความข้อกำหนดไม่ถูกต้อง ส่งผลให้ต้นทุนเพิ่มขึ้นอย่างมากหากไม่ได้แทงหน่อ ข้อกำหนดสามารถตรวจสอบได้ตามเงื่อนไขต่อไปนี้ -

• หากสามารถนำไปปฏิบัติได้จริง
• หากถูกต้องและตามฟังก์ชันและโดเมนของซอฟต์แวร์
• หากมีความคลุมเครือ
• หากมีความสมบูรณ์
• หากสามารถแสดงให้เห็นได้

ขั้นตอนการลบความต้องการ

กระบวนการกระตุ้นความต้องการสามารถแสดงได้โดยใช้แผนภาพ folloiwng:

• Requirements gathering - นักพัฒนาจะพูดคุยกับลูกค้าและผู้ใช้ปลายทางและรู้ความคาดหวังของพวกเขาจากซอฟต์แวร์
• Organizing Requirements - ผู้พัฒนาจัดลำดับความสำคัญและจัดเรียงข้อกำหนดตามลำดับความสำคัญความเร่งด่วนและความสะดวก

• Negotiation & discussion - หากข้อกำหนดมีความคลุมเครือหรือมีข้อขัดแย้งบางประการในข้อกำหนดของผู้มีส่วนได้ส่วนเสียต่างๆหากมีก็จะมีการเจรจาและหารือกับผู้มีส่วนได้ส่วนเสีย จากนั้นข้อกำหนดอาจได้รับการจัดลำดับความสำคัญและลดทอนอย่างสมเหตุสมผล

  ข้อกำหนดมาจากผู้มีส่วนได้ส่วนเสียต่างๆ เพื่อขจัดความคลุมเครือและความขัดแย้งจะมีการหารือเพื่อความชัดเจนและถูกต้อง ข้อกำหนดที่ไม่สมจริงถูกบุกรุกอย่างมีเหตุผล

• Documentation - ข้อกำหนดที่เป็นทางการและไม่เป็นทางการใช้งานได้และไม่ใช้งานได้ทั้งหมดได้รับการจัดทำเป็นเอกสารและพร้อมใช้งานสำหรับการประมวลผลขั้นต่อไป

เทคนิคการปลดปล่อยความต้องการ

ข้อกำหนด Elicitation เป็นกระบวนการค้นหาข้อกำหนดสำหรับระบบซอฟต์แวร์ที่ต้องการโดยการสื่อสารกับลูกค้าผู้ใช้ปลายทางผู้ใช้ระบบและผู้อื่นที่มีส่วนได้ส่วนเสียในการพัฒนาระบบซอฟต์แวร์

มีหลายวิธีในการค้นหาข้อกำหนด

สัมภาษณ์

การสัมภาษณ์เป็นสื่อที่แข็งแกร่งในการรวบรวมข้อกำหนด องค์กรอาจทำการสัมภาษณ์หลายประเภทเช่น:

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

แบบสำรวจ

องค์กรอาจทำการสำรวจในกลุ่มผู้มีส่วนได้ส่วนเสียต่างๆโดยสอบถามเกี่ยวกับความคาดหวังและความต้องการของพวกเขาจากระบบที่กำลังจะเกิดขึ้น

แบบสอบถาม

เอกสารที่มีชุดคำถามวัตถุประสงค์และตัวเลือกที่กำหนดไว้ล่วงหน้าจะถูกส่งมอบให้กับผู้มีส่วนได้ส่วนเสียทั้งหมดเพื่อตอบซึ่งรวบรวมและเรียบเรียง

ข้อบกพร่องของเทคนิคนี้คือหากไม่มีตัวเลือกสำหรับปัญหาบางอย่างที่ระบุไว้ในแบบสอบถามปัญหาอาจถูกปล่อยทิ้งไว้โดยไม่มีใครดูแล

การวิเคราะห์งาน

ทีมวิศวกรและนักพัฒนาอาจวิเคราะห์การทำงานที่จำเป็นต้องใช้ระบบใหม่ หากไคลเอ็นต์มีซอฟต์แวร์เพื่อดำเนินการบางอย่างอยู่แล้วจะมีการศึกษาและรวบรวมข้อกำหนดของระบบที่เสนอ

การวิเคราะห์โดเมน

ซอฟต์แวร์ทั้งหมดอยู่ในหมวดหมู่โดเมนบางประเภท ผู้เชี่ยวชาญในโดเมนสามารถเป็นตัวช่วยที่ดีในการวิเคราะห์ข้อกำหนดทั่วไปและข้อกำหนดเฉพาะ

การระดมความคิด

การอภิปรายอย่างไม่เป็นทางการจัดขึ้นระหว่างผู้มีส่วนได้ส่วนเสียต่างๆและข้อมูลทั้งหมดของพวกเขาจะถูกบันทึกไว้เพื่อการวิเคราะห์ข้อกำหนดเพิ่มเติม

การสร้างต้นแบบ

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

การสังเกต

ทีมผู้เชี่ยวชาญเยี่ยมชมองค์กรหรือสถานที่ทำงานของลูกค้า พวกเขาสังเกตการทำงานจริงของระบบที่ติดตั้งที่มีอยู่ พวกเขาสังเกตเวิร์กโฟลว์ในตอนท้ายของลูกค้าและวิธีจัดการกับปัญหาการดำเนินการ ทีมงานเองได้ข้อสรุปบางอย่างที่ช่วยในการกำหนดข้อกำหนดที่คาดหวังจากซอฟต์แวร์

ลักษณะข้อกำหนดของซอฟต์แวร์

การรวบรวมข้อกำหนดของซอฟต์แวร์เป็นรากฐานของโครงการพัฒนาซอฟต์แวร์ทั้งหมด ดังนั้นจึงต้องมีความชัดเจนถูกต้องและชัดเจน

ข้อกำหนดข้อกำหนดซอฟต์แวร์ที่สมบูรณ์ต้องเป็น:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• แหล่งที่มาที่น่าเชื่อถือ

ข้อกำหนดของซอฟต์แวร์

เราควรพยายามทำความเข้าใจว่าข้อกำหนดประเภทใดที่อาจเกิดขึ้นในขั้นตอนการกระตุ้นข้อกำหนดและข้อกำหนดประเภทใดที่คาดว่าจะได้รับจากระบบซอฟต์แวร์

ความต้องการซอฟต์แวร์โดยกว้างควรแบ่งออกเป็นสองประเภท:

ความต้องการการทำงาน

ข้อกำหนดซึ่งเกี่ยวข้องกับลักษณะการทำงานของซอฟต์แวร์จัดอยู่ในหมวดหมู่นี้

กำหนดฟังก์ชันและฟังก์ชันการทำงานภายในและจากระบบซอฟต์แวร์

ตัวอย่าง -

• ตัวเลือกการค้นหาที่กำหนดให้ผู้ใช้ค้นหาจากใบแจ้งหนี้ต่างๆ
• ผู้ใช้ควรสามารถส่งรายงานไปยังฝ่ายบริหารได้
• ผู้ใช้สามารถแบ่งออกเป็นกลุ่มและกลุ่มสามารถได้รับสิทธิ์แยกกัน
• ควรปฏิบัติตามกฎทางธุรกิจและหน้าที่การบริหาร
• ซอฟต์แวร์ได้รับการพัฒนาโดยให้ความเข้ากันได้ลดลงเหมือนเดิม

ข้อกำหนดที่ไม่ใช่หน้าที่

ข้อกำหนดซึ่งไม่เกี่ยวข้องกับลักษณะการทำงานของซอฟต์แวร์จัดอยู่ในหมวดหมู่นี้ เป็นลักษณะโดยนัยหรือคาดหวังของซอฟต์แวร์ซึ่งผู้ใช้ตั้งสมมติฐาน

ข้อกำหนดที่ไม่ใช้งาน ได้แก่ -

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• การกู้คืนระบบ
• Accessibility

ข้อกำหนดถูกจัดประเภทตามเหตุผลเป็น

• Must Have : ซอฟต์แวร์ไม่สามารถพูดได้ว่าใช้งานได้หากไม่มีพวกเขา
• Should have : การปรับปรุงการทำงานของซอฟต์แวร์
• Could have : ซอฟต์แวร์ยังคงสามารถทำงานได้อย่างถูกต้องตามข้อกำหนดเหล่านี้
• Wish list : ข้อกำหนดเหล่านี้ไม่ได้จับคู่กับวัตถุประสงค์ใด ๆ ของซอฟต์แวร์

ในขณะที่พัฒนาซอฟต์แวร์ต้องใช้ "สิ่งที่ต้องมี" "สิ่งที่ควรมี" เป็นประเด็นของการถกเถียงกับผู้มีส่วนได้ส่วนเสียและการปฏิเสธในขณะที่ "สามารถมี" และ "รายการที่ต้องการ" สามารถเก็บไว้สำหรับการอัปเดตซอฟต์แวร์ได้

ข้อกำหนดส่วนติดต่อผู้ใช้

UI เป็นส่วนสำคัญของซอฟต์แวร์หรือฮาร์ดแวร์หรือระบบไฮบริด ซอฟต์แวร์ได้รับการยอมรับอย่างกว้างขวางหากเป็น -

• ใช้งานง่าย
• ตอบสนองอย่างรวดเร็ว
• จัดการข้อผิดพลาดในการปฏิบัติงานได้อย่างมีประสิทธิภาพ
• ให้ส่วนต่อประสานผู้ใช้ที่เรียบง่าย แต่สอดคล้องกัน

การยอมรับของผู้ใช้ส่วนใหญ่ขึ้นอยู่กับว่าผู้ใช้สามารถใช้ซอฟต์แวร์ได้อย่างไร UI เป็นวิธีเดียวที่ผู้ใช้จะรับรู้ระบบ นอกจากนี้ระบบซอฟต์แวร์ที่มีประสิทธิภาพจะต้องมีอินเทอร์เฟซผู้ใช้ที่น่าดึงดูดชัดเจนสอดคล้องและตอบสนอง มิฉะนั้นจะไม่สามารถใช้ฟังก์ชันของระบบซอฟต์แวร์ได้อย่างสะดวก ระบบจะบอกว่าดีหากมีวิธีการใช้อย่างมีประสิทธิภาพ ข้อกำหนดของอินเทอร์เฟซผู้ใช้มีการกล่าวถึงสั้น ๆ ด้านล่าง -

• การนำเสนอเนื้อหา
• ง่ายต่อการนำทาง
• อินเตอร์เฟซที่เรียบง่าย
• Responsive
• องค์ประกอบ UI ที่สอดคล้องกัน
• กลไกการตอบรับ
• การตั้งค่าเริ่มต้น
• เค้าโครงที่เด็ดเดี่ยว
• การใช้สีและพื้นผิวอย่างมีกลยุทธ์
• ให้ข้อมูลความช่วยเหลือ
• แนวทางผู้ใช้เป็นศูนย์กลาง
• การตั้งค่ามุมมองตามกลุ่ม

นักวิเคราะห์ระบบซอฟต์แวร์

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

นักวิเคราะห์ระบบมีหน้าที่รับผิดชอบดังต่อไปนี้:

• การวิเคราะห์และทำความเข้าใจข้อกำหนดของซอฟต์แวร์ที่ต้องการ
• ทำความเข้าใจว่าโครงการจะมีส่วนร่วมในวัตถุประสงค์ขององค์กรอย่างไร
• ระบุแหล่งที่มาของความต้องการ
• การตรวจสอบความต้องการ
• พัฒนาและดำเนินการตามแผนการจัดการความต้องการ
• เอกสารเกี่ยวกับธุรกิจเทคนิคกระบวนการและข้อกำหนดของผลิตภัณฑ์
• การประสานงานกับลูกค้าเพื่อจัดลำดับความสำคัญของข้อกำหนดและลบและความคลุมเครือ
• สรุปเกณฑ์การยอมรับกับลูกค้าและผู้มีส่วนได้ส่วนเสียอื่น ๆ

เมตริกและมาตรการของซอฟต์แวร์

การวัดซอฟต์แวร์สามารถเข้าใจได้ว่าเป็นกระบวนการในการหาปริมาณและเป็นสัญลักษณ์ของคุณลักษณะและลักษณะต่างๆของซอฟต์แวร์

Software Metrics ให้มาตรการสำหรับด้านต่างๆของกระบวนการซอฟต์แวร์และผลิตภัณฑ์ซอฟต์แวร์

มาตรการด้านซอฟต์แวร์เป็นข้อกำหนดพื้นฐานของวิศวกรรมซอฟต์แวร์ พวกเขาไม่เพียง แต่ช่วยควบคุมกระบวนการพัฒนาซอฟต์แวร์ แต่ยังช่วยรักษาคุณภาพของผลิตภัณฑ์ขั้นสูงสุดให้ดีเยี่ยม

ตามที่ Tom DeMarco (วิศวกรซอฟต์แวร์) กล่าวว่า“ คุณไม่สามารถควบคุมสิ่งที่คุณไม่สามารถวัดผลได้” จากคำพูดของเขาเป็นที่ชัดเจนมากว่ามาตรการซอฟต์แวร์มีความสำคัญอย่างไร

ให้เราดูเมตริกซอฟต์แวร์:

• Size Metrics - LOC (Lines of Code) ซึ่งส่วนใหญ่คำนวณจากซอร์สโค้ดบรรทัดที่จัดส่งหลายพันบรรทัดแสดงเป็น KLOC

  Function Point Count เป็นการวัดการทำงานที่ซอฟต์แวร์มีให้ การนับคะแนนฟังก์ชันกำหนดขนาดของลักษณะการทำงานของซอฟต์แวร์

• Complexity Metrics - ความซับซ้อนของ Cyclomatic ของ McCabe จะวัดขอบเขตบนของจำนวนเส้นทางอิสระในโปรแกรมซึ่งถูกมองว่าเป็นความซับซ้อนของโปรแกรมหรือโมดูลของโปรแกรม มันแสดงในแง่ของแนวคิดทฤษฎีกราฟโดยใช้กราฟการไหลของการควบคุม

• Quality Metrics - ข้อบกพร่องประเภทและสาเหตุผลที่ตามมาความรุนแรงของความรุนแรงและผลกระทบเป็นตัวกำหนดคุณภาพของผลิตภัณฑ์

  จำนวนข้อบกพร่องที่พบในกระบวนการพัฒนาและจำนวนข้อบกพร่องที่ลูกค้ารายงานหลังจากติดตั้งหรือส่งมอบผลิตภัณฑ์ที่ลูกค้าปลายทางกำหนดคุณภาพของผลิตภัณฑ์

• Process Metrics - ในขั้นตอนต่างๆของ SDLC วิธีการและเครื่องมือที่ใช้มาตรฐานของ บริษัท และประสิทธิภาพของการพัฒนาคือเมตริกกระบวนการซอฟต์แวร์
• Resource Metrics - ความพยายามเวลาและทรัพยากรต่างๆที่ใช้แสดงถึงเมตริกสำหรับการวัดทรัพยากร