ทำไมต้องแยกแยะความแตกต่างระหว่างข้อกำหนดด้านการใช้งานกับความต้องการใช้งานไม่ได้

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

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

การแยกข้อกำหนดอย่างชัดเจนจะช่วยให้ออกแบบระบบที่เหมาะสมได้ง่ายขึ้น

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

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

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

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

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

เมื่อความต้องการทุกอย่างมีลำดับความสำคัญ / น้ำหนักเท่ากัน (โดยเฉพาะ "บังคับ") คุณอาจต้องกังวลมากกว่าเพียงแค่แยกข้อกำหนดด้านหน้าที่และไม่ใช่หน้าที่

อย่างไรก็ตามมีเหตุผลหลายประการที่จะแยกข้อกำหนดทั้งสองประเภท:

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

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

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

การกำหนดเวอร์ชัน หากคุณอยู่ในสภาพแวดล้อมขององค์กรที่มี "มาตรฐาน" จำนวนมาก - คุณสามารถเขียนเอกสาร UI หรือความปลอดภัย (เพื่อบอกชื่อคู่) ซึ่งสามารถกำหนดเวอร์ชันได้ ด้วยวิธีนี้คุณสามารถเขียนข้อกำหนดเฉพาะของแอปพลิเคชันได้ (ส่วนใหญ่เป็นข้อกำหนดในการทำงาน): "แอปพลิเคชันจะต้องปฏิบัติตามข้อกำหนดด้านความปลอดภัยที่กำหนดไว้ใน XYZ-Company-SecReq-DocumnentNamingStandard.docx"

ทำไมต้องแยกแยะความแตกต่างระหว่างข้อกำหนดด้านการใช้งานกับความต้องการใช้งานไม่ได้

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

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

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

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

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

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

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

การแยกมีประโยชน์หลายประการ

1. ประหยัดเวลาในการทดสอบ (เช่นทดสอบความต้องการการใช้งานเท่านั้น)
2. ประหยัดเวลาในการเปลี่ยนแปลงข้อกำหนดในอนาคต (เช่นข้อกำหนดที่ไม่เกี่ยวกับการทำงานจะใช้เวลาน้อยลงในการตรวจสอบ / อนุมัติ / นำไปใช้ / ทดสอบ)
3. ในโลกที่มีการควบคุม (เช่นองค์การอาหารและยา ฯลฯ ) ความต้องการที่ไม่ใช้งานจำเป็นต้องมี 1 / 10th ของจำนวนเอกสารที่จำเป็นสำหรับการใช้งาน
4. ให้ความสามารถแก่ทีมในการแบ่งงานระหว่างสมาชิกในทีมอาวุโส (หน้าที่) และรุ่นน้อง (ไม่ใช่หน้าที่)

ฉันสามารถไปที่ ...

ดูเหมือนว่าสองวันบนพื้นผิวในระยะยาวในระยะยาวมันสามารถประหยัดงานได้หลายสัปดาห์หรือหลายเดือนในอนาคต