ความต้องการในการใช้งานหรือไม่ใช้งาน?

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

ฉันสงสัยเกี่ยวกับข้อกำหนดที่ไม่ได้เชื่อมโยงกับการกระทำบางอย่างหรือมีเงื่อนไขเพิ่มเติมตัวอย่างเช่น:

1. ในรายการอุปกรณ์ที่เลือกสามารถทำซ้ำอุปกรณ์ได้
2. ฐานข้อมูลต้องมีอย่างน้อย 100 รายการ
3. สกุลเงินของค่าบางอย่างจะต้องเป็นดอลลาร์สหรัฐ
4. อุปกรณ์จะต้องมีชื่อและค่าการใช้พลังงานในวัตต์

ข้อกำหนดเหล่านั้นเป็นหน้าที่หรือไม่ใช้งานหรือไม่

ข้อกำหนดด้านหน้าที่กำหนดสิ่งที่ระบบหรือแอปพลิเคชันจะทำ - โดยเฉพาะในบริบทของการโต้ตอบภายนอก (กับผู้ใช้หรือกับระบบอื่น)

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

อ้างถึงWikipedia: ข้อกำหนดของหน้าที่สำหรับรายละเอียดเพิ่มเติม

ข้อกำหนดที่ไม่สามารถใช้งานได้คือข้อกำหนดใด ๆ ที่ไม่ได้อธิบายถึงพฤติกรรมอินพุต / เอาต์พุตของระบบ โปรดทราบว่าเรายังคงพูดถึงข้อกำหนดไม่ใช่รายละเอียดการใช้งานดังนั้นเพียงเพราะเราใช้วลี "ไม่ทำงาน" ไม่ได้หมายความว่ามีเกมอะไรที่ควรใส่ในส่วนนั้น

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

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

ข้อกำหนดที่ไม่เกี่ยวกับการใช้งานไม่ได้เป็นแบบอัตนัยหรือเป็นคลื่นมือซึ่งตรงกันข้ามกับสิ่งที่บางคนที่นี่ดูเหมือนจะแนะนำ ในความเป็นจริงพวกเขาควรมีตัวชี้วัดที่แข็งแนบมากับพวกเขา (เช่นเวลาตอบสนองไม่เกิน 100 มิลลิวินาที) ข้อกำหนดของ NF ยังไม่ใช่รายละเอียดการนำไปปฏิบัติหรืองานเช่น "อัพเกรด ORM framework" - ไม่มีเงื่อนงำที่ใครจะได้รับแนวคิดนั้น

รายละเอียดเพิ่มเติมที่Wikipedia: ข้อกำหนดที่ไม่สามารถใช้งานได้

หากต้องการระบุตัวอย่างในคำถามโดยเฉพาะ:

1. ในรายการอุปกรณ์ที่เลือกสามารถทำซ้ำอุปกรณ์ได้

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

2. ฐานข้อมูลต้องมีอย่างน้อย 100 รายการ

   • ดูเหมือนกฎธุรกิจดังนั้นจึงเป็นข้อกำหนดสำหรับการใช้งาน อย่างไรก็ตามดูเหมือนว่าจะไม่สมบูรณ์ อะไรคือเหตุผลสำหรับกฎนี้ จะเกิดอะไรขึ้น / ควรเกิดขึ้นหากฐานข้อมูลมีน้อยกว่า 100 รายการ

3. สกุลเงินของค่าบางอย่างจะต้องเป็นดอลลาร์สหรัฐ

   • ความต้องการด้านการใช้งาน แต่ไม่ใช่ข้อกำหนดที่ระบุไว้อย่างถูกต้อง ถ้อยคำที่เป็นประโยชน์มากขึ้นคือ: ระบบจะรองรับหนึ่งสกุลเงิน (USD) แน่นอนว่าสิ่งนี้จะได้รับการแก้ไขหากจำเป็นต้องสนับสนุนสกุลเงินมากกว่าหนึ่งสกุลและข้อกำหนดจะต้องมีข้อมูลเกี่ยวกับการแปลงสกุลเงินและอื่น ๆ

4. อุปกรณ์จะต้องมีชื่อและค่าการใช้พลังงานในวัตต์

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

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

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

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

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

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

ดังนั้นเรามาดูตัวอย่าง

  1. ผลิตภัณฑ์ซอฟต์แวร์ตอบสนองต่อผู้ใช้ปลายทาง

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

  2. การโหลดสถิติผู้ใช้ดำเนินการ 90% ของเวลาต่ำกว่า 100 มิลลิวินาที เมื่อทดสอบกับเครื่องที่มีการทำงานตามที่ระบุในภาคผนวก G ตอนที่ 2 และโหลดต่ำกว่า 10% สำหรับ CPU ต่ำกว่า 50% สำหรับหน่วยความจำและไม่มีการใช้งานดิสก์ R / W ที่ใช้งานอยู่

มันเป็นข้อกำหนด หากภาคผนวก G ตอนที่ 2 มีความแม่นยำเพียงพอฉันสามารถนำเครื่องพร้อมกับฮาร์ดแวร์ที่คล้ายกันและทำการทดสอบการตรวจสอบความถูกต้องในแผนก QA และฉันจะได้รับผลลัพธ์ไบนารีเสมอ: ผ่านหรือล้มเหลว

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

มันเป็นข้อกำหนดที่ไม่ใช่หน้าที่หรือไม่? มันคือ. มันระบุคุณสมบัติที่ผลิตภัณฑ์จะต้องมีเช่นเวลาตอบสนองสูงสุด / เฉลี่ยให้กำหนดเกณฑ์ร้อยละ

  3. แอปพลิเคชันเขียนเป็น C #

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

  4. codebase C # ของผลิตภัณฑ์เป็นไปตามกฎขั้นต่ำที่แนะนำของ Microsoft และกฎ Globalization ของ Microsoft

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

  5. หน้าต่างหลักของแอปพลิเคชันมีเส้นขอบสีน้ำเงินขนาด 10px (# 00f) ที่มีสีชมพู (#fcc) วงกลมเหล่านั้นจะถูกวางที่ขอบด้านในของเส้นขอบและมีเส้นผ่านศูนย์กลาง 3px คั่นด้วย 20px จากกัน

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

  6. ระบบติดตามยานพาหนะวัดความเร็วด้วยความแม่นยำ± 0.016 ไมล์ต่อชั่วโมง

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

  7. ระบบติดตามยานพาหนะวัดความเร็วของยานพาหนะ

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

  8. หน้าเว็บไซต์ใช้เวลา 850 ms เพื่อโหลด

นี่ไม่ใช่ข้อกำหนด คือพยายามเป็นหนึ่ง แต่ไม่ถูกต้องทั้งหมด คุณจะให้ความสำคัญกับสิ่งนี้อย่างไร หน้าอะไร ทั้งหมดหรือไม่ ทดสอบผ่านเครือข่ายท้องถิ่น 1Gbps บนเครื่องไคลเอนต์แบบ quad-core และเซิร์ฟเวอร์แปดหลักที่มี SSD ที่ใช้ที่ 2% หรือผ่านโมเด็มของแล็ปท็อปเก่าและเส็งเคร็งในขณะที่เว็บไซต์กำลังโฮสต์โดยเซิร์ฟเวอร์ขนาดเล็กที่ใช้ 99% ? "โหลด" มีความหมายอย่างไร มันหมายถึงการดาวน์โหลดหน้า? กำลังดาวน์โหลดและแสดงหรือไม่ ส่งคำขอ POST ด้วยข้อมูลขนาดใหญ่แล้วโหลดการตอบสนองและแสดงผลหรือไม่

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

^{¹การจัดการโครงการเทคโนโลยีสารสนเทศ: การใช้กลยุทธ์การจัดการโครงการกับซอฟต์แวร์ฮาร์ดแวร์และการรวมเข้าด้วยกัน James Taylor, ISBN: 0814408117}

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

ต้องบอกว่าความต้องการที่ไม่ใช่หน้าที่การใช้งานที่คุณกำลังอธิบายเป็นจริงข้อกำหนดการทำงานกับข้อกำหนดทางเทคนิค (ซึ่งจริง ๆ แล้วจะทำให้มันเป็นข้อกำหนดที่ไม่ดี) ตัวอย่างของข้อกำหนดที่ไม่สามารถใช้งานได้สำหรับกรณีของคุณอาจเป็นดังนี้:

- UI จะต้องไม่ถูกล็อคในขณะที่ภาพเคลื่อนไหวของลูกเต๋ากำลังทำงาน

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

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

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

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

หนึ่งจุดสุดท้าย - หากคุณยังไม่สามารถ (มาถึง) ด้วยการวัดวัตถุประสงค์ของ "ility" นั่นไม่ได้หมายความว่าลูกค้าไม่ต้องการมัน คลุมเครือ! = ไม่จำเป็น อย่างไรก็ตามมันอาจหมายถึงเราจำเป็นต้องพัฒนาวิธีที่ดีกว่าในการวัดสิ่งต่าง ๆ ดึงออกและปรับแต่งข้อกำหนดที่ไม่ใช่หน้าที่เพิ่มขึ้นหรือสัญญาในรูปแบบ (Agile ฯลฯ ) ที่สามารถทำงานได้โดยไม่ต้องมีมาตรการล่วงหน้าทุกอย่าง

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

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

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

ฟังก์ชั่นหรือไม่ทำงาน? ฉันจะไม่พูด ส่วนใหญ่หากไม่ใช่ตัวอย่างทั้งหมดที่แสดงรายการจะมีลักษณะเป็นกฎทางธุรกิจให้ฉัน (การระบุข้อ จำกัด ที่เกี่ยวข้องกับกระบวนการและกฎการตัดสินใจที่กระบวนการของระบบต้องปฏิบัติตาม)

พวกเขาเป็นสิ่งที่วิศวกรจำนวนมากลืมหรือไม่ทราบเนื่องจากกฎเกณฑ์ทางธุรกิจมักจะถูกรวบรวมเป็นส่วนหนึ่งของการวิเคราะห์ธุรกิจ

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

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

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

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