เหตุใดข้อกำหนดจึงมีความสำคัญในด้านวิศวกรรมซอฟต์แวร์

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

" ซอฟต์แวร์ทำงานบนเอกสารที่ครอบคลุม " นี่เป็นส่วนหนึ่งของคำประกาศ Agile

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

เริ่มต้นด้วยคำอธิบายเล็กน้อยว่าข้อกำหนดใดบ้างในแง่ของการพัฒนาซอฟต์แวร์

ข้อกำหนดในการพัฒนาแอพคืออะไร?

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

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

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

การพัฒนาซอฟต์แวร์อาจมีข้อกำหนดหลายประเภท

ข้อกำหนดทางธุรกิจ

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

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

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

หากไม่มีข้อกำหนดทางธุรกิจที่ชัดเจน การตัดสินใจที่ไม่ดีก็สามารถทำได้ การตัดสินใจที่จะทำให้การพัฒนาช้าลง ขัดขวางกำหนดเวลา และส่งผลให้มีขั้นตอนการพัฒนาเพิ่มเติม

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

ข้อกำหนดมีสองประเภท: การทำงานและ nonfunctional พูดง่าย ๆ ความแตกต่างมีดังนี้:

ข้อกำหนดด้านการทำงาน คือข้อกำหนดอะไร - ระบบนี้ออกแบบมาเพื่อทำอะไร? ตามชื่อที่แนะนำ พวกเขาอธิบายการทำงานของซอฟต์แวร์

ข้อกำหนดที่ไม่ทำงาน เป็น ข้อกำหนด อย่างไร - ระบบนี้จะทำในสิ่งที่ได้รับการออกแบบมาอย่างไร? ข้อกำหนดเหล่านี้อธิบายว่าคุณลักษณะแต่ละรายการควรทำงานอย่างไรภายใต้เงื่อนไขใด ควรมีข้อจำกัดอะไรบ้าง และอื่นๆ

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

ข้อกำหนดด้านการทำงานหลักในกรณีนี้คือ:

1. แอปต้องสามารถส่งข้อความได้
2. แอพต้องรองรับการถ่ายโอนไฟล์และสื่อ
3. เป็นต้น

สิ่งเหล่านี้ค่อนข้างตรงไปตรงมา และเข้าใจได้ง่ายว่าทำไมข้อกำหนดด้านฟังก์ชันจึงมีความสำคัญ: โครงร่างของฟังก์ชันการทำงาน ในตัวอย่างนี้ ข้อกำหนดที่ไม่เป็นไปตามข้อกำหนดอาจเป็นดังนี้ :

1. บริการต้องมีฟังก์ชันการทำงานเต็มรูปแบบในเบราว์เซอร์หลักทั้งหมด: Microsoft Edge, Google Chrome (สองเวอร์ชันล่าสุด), Mozilla Firefox (สองเวอร์ชันล่าสุด), Opera, Safari (เวอร์ชันล่าสุด)
2. ต้องรองรับรูปแบบมือถือ
3. เป็นต้น

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

เป็นความจริงที่กระบวนการ Agile แบบวนซ้ำนั้นมี ความเป็นไปได้ที่จะทำให้เกิดการเปลี่ยนแปลงในขั้นตอนใดๆ ของการพัฒนา แต่นั่นไม่ได้หมายความถึงข้อกำหนดที่กล่าวมาทั้งหมด คุณเพียงแค่ต้องทำให้พวกเขามีความยืดหยุ่น

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

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

ดาบของ Damocles ที่ไม่มีข้อกำหนด

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

อย่างไรก็ตาม ปัญหานี้ไม่ได้ส่งผลกระทบต่อผู้ทดสอบเท่านั้น ไม่มีข้อกำหนดอย่างเป็นทางการ หมายถึงสิ่งต่อไปนี้:

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

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

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

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

มารอยู่ในรายละเอียด: อะไรทำให้ข้อกำหนดข้อกำหนดซอฟต์แวร์ที่ดี?

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

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

ไม่ว่าเอกสารของคุณจะเต็มไปด้วยเทคโนโลยีเพียงใด มีกฎทั่วไปสำหรับการจัดการข้อกำหนดของซอฟต์แวร์ มีแม้กระทั่งมาตรฐานอย่างเป็นทางการ: IEEE Std 830-1998 "แนวทางปฏิบัติที่แนะนำสำหรับข้อกำหนดของซอฟต์แวร์" นี่คือสิ่งที่ SRS ที่ดีควรเป็นตามมาตรฐาน:

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

• ไม่คลุมเครือ วัตถุประสงค์หลักประการหนึ่งของ SRS คือการกำจัดการสื่อสารที่ผิดพลาด นั่นเป็นเหตุผลว่าทำไมทุกข้อกำหนดข้อกำหนดต้องเขียนเพื่อให้มีการตีความที่เป็นไปได้เพียงอย่างเดียว ไม่ใช่เรื่องแปลกที่ SRS จะรวมอภิธานศัพท์

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

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

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

• ตรวจสอบ ได้ ต้องมีวิธีทดสอบข้อกำหนดแต่ละข้อที่คุณรวมไว้ใน SRS เพื่อให้พิจารณาตรวจสอบได้ ข้อกำหนดต้องมีแนวคิดที่วัดผลได้และเป็นรูปธรรม

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

• ติดตาม ได้ การระบุแหล่งที่มาของข้อกำหนดแต่ละข้อที่กำหนดไว้ใน SRS ควรเป็นเรื่องง่าย

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

ข้อกำหนดมีประโยชน์ไม่ว่าคุณจะเชี่ยวชาญด้านการพัฒนาแอปพลิเคชัน iOS และ Android หรือการพัฒนาเว็บ เป็นเอกสารเอนกประสงค์ และรูปลักษณ์โดยทั่วไปนั้นขึ้นอยู่กับนักพัฒนาและลูกค้าของพวกเขา

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

บทสรุป

ต่อไปนี้คือประเด็นที่พบบ่อยที่สุดเมื่อข้อกำหนดของซอฟต์แวร์มีประโยชน์:

• เข้าใจเป้าหมาย
• ประมาณการต้นทุนการพัฒนา
• การสร้างกำหนดการที่ครอบคลุม
• การจัดลำดับความสำคัญ

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