GOST 19.201 78 ระบบเอกสารประกอบโปรแกรมแบบครบวงจร เอกสารทางเทคนิค ข้อกำหนดสำหรับประเภทของบริการ

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

ทำไมคุณจึงต้องมีข้อกำหนดทางเทคนิค?

นักพัฒนาจำนวนมากมักจะดูถูกดูแคลนความสำคัญของข้อกำหนดทางเทคนิค อย่างไรก็ตาม ข้อกำหนดทางเทคนิคถือเป็นเอกสารสำคัญในการพัฒนาระบบข้อมูล เว็บไซต์ ระบบวิศวกรรม และอื่นๆ
ทุกวันนี้ เมื่อ Agile เป็นที่นิยม อาจดูเหมือนว่าเอกสารข้อกำหนดทางเทคนิคนั้นซ้ำซ้อน แต่นี่คือช่วงเวลาที่คุณต้องเผชิญหน้ากับการพัฒนาระบบข้อมูลที่จริงจัง ผลิตภัณฑ์ซอฟต์แวร์ขนาดใหญ่ หรือพอร์ทัล คุณสามารถอธิบายด้วยนิ้วของคุณว่าลูกค้าต้องการอะไรหากมีเอนทิตีออบเจ็กต์ 3-5 รายการในระบบ และหากมีมากกว่านั้นอย่างมีนัยสำคัญ บางสิ่งบางอย่างจะถูกลืมอย่างแน่นอน จากนั้นพวกเขาจะเริ่มวาดภาพบนกระดาษ เขียนบนผ้าเช็ดปากในร้านกาแฟ ส่งข้อความบน WhatsApp: “แต่คงจะดีถ้ามีไอคอนสีน้ำเงินอยู่ที่มุมขวา และเมื่อคุณวางเมาส์ไว้เหนือ ไอคอนเหล่านี้จะย้ายไปตรงกลางแล้วได้รับ ใหญ่กว่า!” เพื่อให้กระบวนการนี้เป็นระเบียบข้อกำหนดทางเทคนิคจะถูกสร้างขึ้นนั่นคือเอกสารเกี่ยวกับทุกสิ่งที่ควรจะเป็น
เงื่อนไขการอ้างอิงทำหน้าที่สำคัญหลายประการ:

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

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

ใครเป็นคนร่างข้อกำหนดทางเทคนิค?

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

• นักวิเคราะห์จากฝั่งลูกค้า - พวกเขาพิจารณาความจำเป็นของระบบและเสนอข้อกำหนดที่เป็นลายลักษณ์อักษรสำหรับโปรแกรมใหม่
• นักวิเคราะห์จากฝั่ง Developer - จะต้องตรวจสอบขอบเขตที่จะพัฒนาโปรแกรมหรือบริษัท คำนึงถึงโครงร่างอัลกอริธึมและความแตกต่างของงานที่ระบบจะดำเนินการทั้งหมด
• นักเขียนด้านเทคนิคคือพนักงานที่จะรวบรวมข้อมูลของนักวิเคราะห์ทั้งหมดและจดบันทึกตาม GOST

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

มาตรฐาน GOST ใดที่ใช้ในการเขียนข้อกำหนดทางเทคนิค

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

ในรัสเซีย ข้อกำหนดทางเทคนิค เขียนตาม GOST สองฉบับ:

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

ฉันควรเลือก GOST ใดสำหรับข้อกำหนดทางเทคนิค

หากคุณกำลังพัฒนาเอกสารสำหรับโปรแกรมที่คุณสร้างขึ้นสำหรับองค์กรเฉพาะ . หากคุณกำลังเขียนเอกสารสำหรับโปรแกรมมวลชนคุณก็เป็นของคุณ

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

GOST 34 แตกต่างจาก GOST 19 อย่างไรเมื่อเขียนข้อกำหนดทางเทคนิค

เพื่อความสะดวก ด้านล่างคือตารางจุดสำหรับการเขียนข้อกำหนดในการอ้างอิง

ด้านล่างนี้เราจะพิจารณาแต่ละส่วนคำสั่ง GOST และ GOST แยกกัน

GOST 19 สำหรับข้อกำหนดทางเทคนิค

เงื่อนไขการอ้างอิงจะต้องมีส่วนต่อไปนี้:

1. การแนะนำ;
2. เหตุผลในการพัฒนา
3. วัตถุประสงค์ของการพัฒนา
4. ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์
5. ข้อกำหนดสำหรับเอกสารประกอบโปรแกรม
6. ตัวชี้วัดทางเทคนิคและเศรษฐกิจ
7. ขั้นตอนและขั้นตอนของการพัฒนา
8. ขั้นตอนการควบคุมและการยอมรับ

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

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

ในส่วนที่ 2” เหตุผลในการพัฒนา » ต้องระบุ:

• เอกสารบนพื้นฐานของการพัฒนา;
• องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ
• ชื่อและ (หรือ) สัญลักษณ์ของหัวข้อการพัฒนา

ในส่วนที่ 3” วัตถุประสงค์ของการพัฒนา » ต้องระบุวัตถุประสงค์การทำงานและการปฏิบัติการของโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

มาตรา 4” ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์ “ควรมีส่วนย่อยดังต่อไปนี้

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

ในหมวดย่อย 4.1" ข้อกำหนดด้านการทำงาน » ต้องระบุข้อกำหนดสำหรับองค์ประกอบของฟังก์ชันที่ดำเนินการ การจัดระเบียบข้อมูลอินพุตและเอาต์พุต ลักษณะกำหนดเวลา ฯลฯ

ในหมวดย่อย 4.2" ข้อกำหนดด้านความน่าเชื่อถือ » ต้องระบุข้อกำหนดสำหรับการรับรองการทำงานที่เชื่อถือได้ (เพื่อให้มั่นใจว่าการทำงานมีความเสถียร การตรวจสอบข้อมูลอินพุตและเอาต์พุต ระยะเวลาการกู้คืนหลังจากความล้มเหลว ฯลฯ)

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

ในหมวดย่อย 4.4" ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค » ระบุองค์ประกอบที่ต้องการของวิธีการทางเทคนิค โดยระบุลักษณะทางเทคนิคหลัก

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

ในกรณีที่จำเป็น จะต้องรับประกันการปกป้องข้อมูลและโปรแกรม

ในส่วนย่อย " ข้อกำหนดในการติดฉลากและบรรจุภัณฑ์ » โดยทั่วไป ให้ระบุข้อกำหนดสำหรับการติดฉลากผลิตภัณฑ์ซอฟต์แวร์ ตัวเลือกการบรรจุหีบห่อ และวิธีการ

ในส่วนย่อย " ข้อกำหนดด้านการขนส่งและการเก็บรักษา » ต้องระบุเงื่อนไขการขนส่ง สถานที่จัดเก็บ สภาพการจัดเก็บ สภาพการจัดเก็บ ระยะเวลาการจัดเก็บในเงื่อนไขต่างๆ สำหรับผลิตภัณฑ์ซอฟต์แวร์

ในมาตรา 5” ข้อกำหนดสำหรับเอกสารประกอบซอฟต์แวร์ » องค์ประกอบเบื้องต้นของเอกสารโปรแกรม และหากจำเป็น จะต้องระบุข้อกำหนดพิเศษ

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

ในมาตรา 7” ขั้นตอนและขั้นตอนของการพัฒนา » กำหนดขั้นตอนที่จำเป็นของการพัฒนา ขั้นตอนและเนื้อหาของงาน (รายการเอกสารโปรแกรมที่ต้องได้รับการพัฒนา ตกลงและอนุมัติ) รวมทั้งตามกฎ กำหนดเวลาในการพัฒนา และกำหนดผู้ปฏิบัติงาน

ในมาตรา 8” ขั้นตอนการควบคุมและการยอมรับ » ต้องระบุประเภทของการทดสอบและข้อกำหนดทั่วไปสำหรับการยอมรับงาน

ในภาคผนวกของข้อกำหนดทางเทคนิค หากจำเป็น ให้ระบุสิ่งต่อไปนี้:

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

GOST 34 สำหรับข้อกำหนดทางเทคนิค

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

1. ข้อมูลทั่วไป
2. วัตถุประสงค์และเป้าหมายของการสร้าง (การพัฒนา) ระบบ
3. ลักษณะของวัตถุอัตโนมัติ
4. ความต้องการของระบบ
5. องค์ประกอบและเนื้อหาของงานสร้างระบบ
6. ขั้นตอนการควบคุมและการยอมรับระบบ
7. ข้อกำหนดสำหรับองค์ประกอบและเนื้อหาของงานเพื่อเตรียมออบเจ็กต์อัตโนมัติสำหรับการนำระบบไปใช้งาน
8. ข้อกำหนดด้านเอกสาร
9. แหล่งการพัฒนา

ข้อกำหนดทางเทคนิคอาจรวมถึงการใช้งานด้วย

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

ข้อกำหนดทางเทคนิคสำหรับส่วนต่างๆ ของระบบไม่รวมถึงส่วนที่ทำซ้ำเนื้อหาในส่วนต่างๆ ของข้อกำหนดทางเทคนิคสำหรับระบบโดยรวม

ในส่วนที่ 1 " ข้อมูลทั่วไป "ระบุ:

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

มาตรา 2” วัตถุประสงค์และเป้าหมายของการสร้าง (การพัฒนา) ระบบ » ประกอบด้วยส่วนย่อย:

• วัตถุประสงค์ของระบบ
• เป้าหมายในการสร้างระบบ

ในหัวข้อย่อย 2.1" วัตถุประสงค์ของระบบ » ระบุประเภทของกิจกรรมที่เป็นอัตโนมัติ (การจัดการ การออกแบบ ฯลฯ) และรายการวัตถุอัตโนมัติ (วัตถุ) ที่ควรจะใช้

สำหรับระบบควบคุมอัตโนมัติ (ACS) รายการส่วนควบคุมอัตโนมัติ (จุด) และวัตถุควบคุมจะถูกระบุเพิ่มเติม

ในหมวดย่อย 2.2" เป้าหมายของการสร้างระบบ » ระบุชื่อและค่าที่ต้องการของตัวบ่งชี้ทางเทคนิค เทคโนโลยี เศรษฐกิจการผลิต หรืออื่น ๆ ของวัตถุอัตโนมัติที่ต้องได้รับอันเป็นผลมาจากการสร้างระบบอัตโนมัติ (AS) และระบุเกณฑ์ในการประเมินความสำเร็จ ของเป้าหมายในการสร้างระบบ

ในส่วนที่ 3” ลักษณะของวัตถุอัตโนมัติ "ให้:

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

มาตรา 4” ความต้องการของระบบ » ประกอบด้วยส่วนย่อยดังต่อไปนี้:

• ข้อกำหนดสำหรับระบบโดยรวม
• ข้อกำหนดสำหรับฟังก์ชัน (งาน) ที่ดำเนินการโดยระบบ
• ข้อกำหนดสำหรับประเภทของหลักประกัน

องค์ประกอบของข้อกำหนดสำหรับระบบที่รวมอยู่ในข้อกำหนดทางเทคนิคในส่วนนี้สำหรับ NPP นั้นถูกกำหนดขึ้นโดยขึ้นอยู่กับประเภท วัตถุประสงค์ คุณลักษณะเฉพาะ และสภาวะการทำงานของระบบเฉพาะ แต่ละส่วนย่อยมีลิงก์ไปยังเอกสารด้านกฎระเบียบและทางเทคนิค (NTD) ในปัจจุบัน ซึ่งกำหนดข้อกำหนดสำหรับระบบประเภทที่เกี่ยวข้อง

ในหมวดย่อย 4.1" ข้อกำหนดสำหรับระบบโดยรวม "ระบุ:

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

ใน ข้อกำหนดสำหรับโครงสร้างและการทำงานของระบบ ให้ (ข้อ TOR 4.1.1):

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

ใน ข้อกำหนดด้านจำนวนและคุณสมบัติของบุคลากร บน AS จะได้รับ (ข้อ TOR 4.1.2):

• ข้อกำหนดสำหรับจำนวนบุคลากร (ผู้ใช้) ของ NPP
• ข้อกำหนดสำหรับคุณสมบัติของบุคลากร ขั้นตอนการฝึกอบรมและการควบคุมความรู้และทักษะ
• โหมดการทำงานที่จำเป็นสำหรับบุคลากรในโรงงาน

ใน ข้อกำหนดสำหรับตัวชี้วัดปลายทาง AS ให้ค่าพารามิเตอร์ที่แสดงถึงระดับความสอดคล้องของระบบตามวัตถุประสงค์ (ข้อ TK 4.1.3)

สำหรับ ACS ระบุ:

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

ใน ข้อกำหนดด้านความน่าเชื่อถือ รวม (ข้อ TOR 4.1.4):

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

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

ใน ข้อกำหนดสำหรับการยศาสตร์และความสวยงามทางเทคนิค (ข้อ TK 4.1.4) รวมถึงตัวบ่งชี้ AS ที่กำหนดคุณภาพที่ต้องการของการโต้ตอบระหว่างมนุษย์กับเครื่องจักรและความสะดวกสบายของสภาพการทำงานของบุคลากร

สำหรับลำโพงมือถือค่ะ ข้อกำหนดด้านการขนส่ง (ข้อ TK 4.1.7) รวมถึงข้อกำหนดการออกแบบที่ให้ความมั่นใจในความสามารถในการขนส่งวิธีการทางเทคนิคของระบบตลอดจนข้อกำหนดสำหรับยานพาหนะ

ใน ข้อกำหนดในการใช้งาน การบำรุงรักษา การซ่อมแซม และการจัดเก็บ รวม (ข้อ TOR 4.1.8):

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

ใน ข้อกำหนดในการปกป้องข้อมูลจากการเข้าถึงโดยไม่ได้รับอนุญาต (ข้อ TK 4.1.9) รวมถึงข้อกำหนดที่กำหนดไว้ในเอกสารเชิงบรรทัดฐานและทางเทคนิคที่ถูกต้องในอุตสาหกรรมของลูกค้า (แผนก)

ใน ข้อกำหนดด้านความปลอดภัยของข้อมูล (ข้อ TK 4.1.10) จัดทำรายการเหตุการณ์: อุบัติเหตุ ความล้มเหลวของอุปกรณ์ทางเทคนิค (รวมถึงการสูญเสียพลังงาน) ฯลฯ ซึ่งจะต้องมั่นใจในความปลอดภัยของข้อมูลในระบบ

ใน ข้อกำหนดสำหรับวิธีการป้องกันอิทธิพลภายนอก ให้ (ข้อ TOR 4.1.11):

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

ใน ข้อกำหนดในการกวาดล้างสิทธิบัตร (ข้อ TOR 4.1.12) ระบุรายชื่อประเทศที่ต้องรับประกันความบริสุทธิ์ของระบบและชิ้นส่วนของระบบสิทธิบัตร

ใน ข้อกำหนดสำหรับการสร้างมาตรฐานและการรวมเป็นหนึ่ง รวม (ข้อ TZ 4.1.13): ตัวบ่งชี้ที่กำหนดระดับที่ต้องการของการใช้มาตรฐาน, วิธีการแบบครบวงจรสำหรับการใช้งานฟังก์ชั่น (งาน) ของระบบ, ซอฟต์แวร์ที่ให้มา, วิธีการและแบบจำลองทางคณิตศาสตร์มาตรฐาน, โซลูชั่นการออกแบบมาตรฐาน, รูปแบบเอกสารการจัดการแบบครบวงจรที่จัดตั้งขึ้น โดย GOST 6.10.1 ตัวแยกประเภทข้อมูลทางเทคนิคและเศรษฐกิจแบบ All-Union และตัวแยกประเภทประเภทอื่น ๆ ตามขอบเขตการใช้งานข้อกำหนดสำหรับการใช้เวิร์กสเตชันอัตโนมัติมาตรฐานส่วนประกอบและคอมเพล็กซ์

ใน ข้อกำหนดเพิ่มเติม รวม (ข้อ TOR 4.1.14):

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

ในหมวดย่อย 4.2" ข้อกำหนดสำหรับฟังก์ชัน (งาน) "ดำเนินการโดยระบบนำไปสู่:

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

ในหมวดย่อย 4.3" ข้อกำหนดสำหรับประเภทของหลักประกัน » ขึ้นอยู่กับประเภทของระบบ ข้อกำหนดที่ให้ไว้สำหรับการสนับสนุนระบบทางคณิตศาสตร์ ข้อมูล ภาษา ซอฟต์แวร์ เทคนิค มาตรวิทยา องค์กร ระเบียบวิธี และประเภทอื่น ๆ

สำหรับ ซอฟต์แวร์ (ข้อ TK 4.3.1) ระบบกำหนดข้อกำหนดสำหรับองค์ประกอบ ขอบเขต (ข้อจำกัด) และวิธีการใช้วิธีการและแบบจำลองทางคณิตศาสตร์ อัลกอริธึมมาตรฐาน และอัลกอริธึมมาตรฐานที่จะพัฒนาในระบบ

สำหรับ การสนับสนุนข้อมูล ระบบจัดเตรียมข้อกำหนด (ข้อ TOR 4.3.2):

• องค์ประกอบ โครงสร้าง และวิธีการจัดระเบียบข้อมูลในระบบ
• การแลกเปลี่ยนข้อมูลระหว่างส่วนประกอบของระบบ
• ความเข้ากันได้ของข้อมูลกับระบบที่เกี่ยวข้อง
• เกี่ยวกับการใช้ all-Union และรีพับลิกันที่จดทะเบียน ตัวแยกประเภทอุตสาหกรรม เอกสารแบบครบวงจร และตัวแยกประเภทที่ดำเนินงานในองค์กรที่กำหนด
• เรื่องการใช้ระบบการจัดการฐานข้อมูล
• ถึงโครงสร้างของกระบวนการรวบรวม ประมวลผล ส่งข้อมูลในระบบและการนำเสนอข้อมูล
• เพื่อปกป้องข้อมูลจากการถูกทำลายระหว่างอุบัติเหตุและไฟฟ้าขัดข้อง;
• เพื่อควบคุม การจัดเก็บ การอัปเดต และการกู้คืนข้อมูล
• ถึงขั้นตอนการให้อำนาจทางกฎหมายกับเอกสารที่ผลิตโดยวิธีการทางเทคนิคของ NPP (ตาม GOST 6.10.4)

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

สำหรับ ซอฟต์แวร์ (ข้อ TK 4.3.4) ระบบจะจัดเตรียมรายการซอฟต์แวร์ที่ซื้อ รวมถึงข้อกำหนด:

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

สำหรับ การสนับสนุนด้านเทคนิค (ข้อ TOR 4.3.5) ระบบมีข้อกำหนดดังต่อไปนี้:

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

ใน ข้อกำหนดสำหรับการสนับสนุนทางมาตรวิทยา (ข้อ TOR 4.3.6) ให้:

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

สำหรับ การสนับสนุนองค์กร จัดเตรียมข้อกำหนด (ข้อ TOR 4.3.7):

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

สำหรับ CAD สนับสนุนระเบียบวิธี (ข้อ TOR 4.3.8) จัดทำข้อกำหนดสำหรับองค์ประกอบของเอกสารด้านกฎระเบียบและทางเทคนิคของระบบ (รายการมาตรฐาน ข้อบังคับ วิธีการ ฯลฯ ที่ใช้ในการดำเนินการ)

มาตรา 5” องค์ประกอบและเนื้อหาของงานเกี่ยวกับการสร้าง (พัฒนา) ระบบ » จะต้องมีรายการขั้นตอนและขั้นตอนของการทำงานเพื่อสร้างระบบตาม GOST 24.601, กำหนดเวลาในการดำเนินการ, รายชื่อองค์กรที่ดำเนินงาน, ลิงก์ไปยังเอกสารยืนยันความยินยอมขององค์กรเหล่านี้ในการมีส่วนร่วมในการสร้าง ระบบหรือบันทึกที่ระบุผู้รับผิดชอบ (ลูกค้าหรือผู้พัฒนา) ในการดำเนินงานนี้

ส่วนนี้ยังมี:

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

ในมาตรา 6” ขั้นตอนการควบคุมและการยอมรับระบบ "ระบุ:

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

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

รายการกิจกรรมหลักประกอบด้วย:

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

ตัวอย่างเช่น สำหรับระบบควบคุมอัตโนมัติ จะให้:

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

ในมาตรา 8” ข้อกำหนดด้านเอกสาร "ให้:

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

ในมาตรา 9” แหล่งพัฒนา » ควรแสดงรายการเอกสารและเอกสารข้อมูล (การศึกษาความเป็นไปได้ รายงานงานวิจัยที่เสร็จสมบูรณ์ เอกสารข้อมูลเกี่ยวกับระบบอะนาล็อกในประเทศและต่างประเทศ ฯลฯ) บนพื้นฐานของข้อกำหนดทางเทคนิคที่ได้รับการพัฒนาและควรใช้เมื่อสร้างระบบ .

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

• การคำนวณประสิทธิภาพที่คาดหวังของระบบ
• การประเมินระดับวิทยาศาสตร์และเทคนิคของระบบ

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

บทสรุป

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

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

ฉันหวังว่าบทความนี้จะช่วยให้คุณเขียนข้อกำหนดทางเทคนิคได้ง่ายขึ้นเล็กน้อย!

ชื่อ:

ระบบเอกสารโปรแกรมแบบครบวงจร

ถูกต้อง

วันที่แนะนำ:

วันที่ยกเลิก:

แทนที่ด้วย:

ข้อความ GOST 19.201-78 เอกสารประกอบโปรแกรมระบบรวม ข้อกำหนดทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ

GOST 19.201-78

มาตรฐานระดับรัฐ

ระบบเอกสารซอฟต์แวร์แบบรวมศูนย์

ข้อมูลจำเพาะทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ

สิ่งพิมพ์อย่างเป็นทางการ

ข้อมูลมาตรฐาน

มาตรฐานระดับรัฐ

ระบบเอกสารโปรแกรมแบบครบวงจร

ข้อมูลจำเพาะทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ

ระบบรวมเอกสารโปรแกรม

ข้อกำหนดทางเทคนิคสำหรับการพัฒนา ข้อกำหนดสำหรับเนื้อหาและรูปแบบการนำเสนอ

ตามคำสั่งของคณะกรรมการมาตรฐานแห่งรัฐสหภาพโซเวียตเมื่อวันที่ 18 ธันวาคม พ.ศ. 2521 ฉบับที่ 3351 ได้มีการกำหนดวันแนะนำ

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

มาตรฐานนี้สอดคล้องกับ ST SEV 1627-79 อย่างสมบูรณ์

1. บทบัญญัติทั่วไป

1.1. เงื่อนไขการอ้างอิงถูกร่างขึ้นตาม GOST 19.106-78 บนแผ่นงานรูปแบบ 11 และ 12 ตามกฎ GOST 2.301-68 โดยไม่ต้องกรอกข้อมูลในฟิลด์ของแผ่นงาน หมายเลขแผ่นงาน (หน้า) จะอยู่ที่ด้านบนของแผ่นงานเหนือข้อความ

1.2. เอกสารอนุมัติและหน้าชื่อเรื่องจัดทำขึ้นตาม GOST 19.104-78 อนุญาตให้ใช้ส่วนข้อมูล (คำอธิบายประกอบและเนื้อหา) แผ่นบันทึกการเปลี่ยนแปลงได้

ไม่รวมเอกสาร

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

1.4. เงื่อนไขการอ้างอิงจะต้องมีส่วนต่อไปนี้: บทนำ;

เหตุผลในการพัฒนา วัตถุประสงค์ของการพัฒนา

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

การใช้งานอาจรวมอยู่ในข้อกำหนดทางเทคนิค

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

(แก้ไขฉบับแก้ไขครั้งที่ 1)

สิ่งพิมพ์อย่างเป็นทางการ ★

ห้ามการสืบพันธุ์

) สำนักพิมพ์สแตนดาร์ด, 1978 © STANDARDINFORM, 2010

ฉบับ (มกราคม 2553) พร้อมการแก้ไขครั้งที่ 1 ได้รับการอนุมัติในเดือนมิถุนายน 2524 (IUS 9-81)

ส. 2 GOST 19.201-78

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

2.2. ส่วน “ฐานการพัฒนา” ควรระบุ: เอกสารบนพื้นฐานของการพัฒนาที่กำลังดำเนินการ; องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ ชื่อและ (หรือ) สัญลักษณ์ของหัวข้อการพัฒนา

2.1. 2.2. (แก้ไขฉบับแก้ไขครั้งที่ 1)

2.3. ส่วน “วัตถุประสงค์ของการพัฒนา” จะต้องระบุวัตถุประสงค์การทำงานและการปฏิบัติการของโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

2.4. ส่วน “ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์” ควรมีส่วนย่อยต่อไปนี้:

ข้อกำหนดสำหรับลักษณะการทำงาน ข้อกำหนดด้านความน่าเชื่อถือ เงื่อนไขการใช้งาน;

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

(แก้ไขฉบับแก้ไขครั้งที่ 1)

2.4.1. ส่วนย่อย "ข้อกำหนดสำหรับคุณลักษณะการทำงาน" ควรระบุข้อกำหนดสำหรับองค์ประกอบของฟังก์ชันที่ดำเนินการ การจัดระเบียบข้อมูลอินพุตและเอาต์พุต ลักษณะเวลา ฯลฯ

2.4.2. ส่วนย่อย "ข้อกำหนดด้านความน่าเชื่อถือ" จะต้องระบุข้อกำหนดเพื่อให้มั่นใจถึงการทำงานที่เชื่อถือได้ (เพื่อให้มั่นใจว่าการทำงานมีความเสถียร การตรวจสอบข้อมูลอินพุตและเอาท์พุต เวลาฟื้นตัวหลังจากเกิดความล้มเหลว ฯลฯ)

2.4.3. หัวข้อย่อย “สภาวะการทำงาน” จะต้องระบุสภาวะการทำงาน (อุณหภูมิโดยรอบ ความชื้นสัมพัทธ์ ฯลฯ สำหรับสื่อบันทึกประเภทที่เลือก) ที่ต้องรับประกันคุณลักษณะที่ระบุ ตลอดจนประเภทของบริการ จำนวนที่ต้องการและคุณสมบัติของ บุคลากร

2.4.4. ในส่วนย่อย "ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค" ระบุองค์ประกอบที่ต้องการของวิธีการทางเทคนิคโดยระบุถึงลักษณะทางเทคนิคหลัก

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

ในกรณีที่จำเป็น จะต้องรับประกันการปกป้องข้อมูลและโปรแกรม

(แก้ไขฉบับแก้ไขครั้งที่ 1)

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

2.4.7. ส่วนย่อย “ข้อกำหนดสำหรับการขนส่งและการจัดเก็บ” จะต้องระบุสำหรับผลิตภัณฑ์ซอฟต์แวร์ถึงเงื่อนไขการขนส่ง สถานที่จัดเก็บ เงื่อนไขการจัดเก็บ เงื่อนไขการจัดเก็บ ระยะเวลาการจัดเก็บในเงื่อนไขต่างๆ

2.5ก. ส่วน "ข้อกำหนดสำหรับเอกสารประกอบโปรแกรม" ควรระบุองค์ประกอบเบื้องต้นของเอกสารประกอบโปรแกรมและข้อกำหนดพิเศษหากจำเป็น (แนะนำเพิ่มเติม แก้ไขครั้งที่ 1)

2.5. ส่วน "ตัวชี้วัดทางเทคนิคและเศรษฐกิจ" ควรระบุ: ประสิทธิภาพทางเศรษฐกิจโดยประมาณ, ความต้องการรายปีโดยประมาณ, ข้อได้เปรียบทางเศรษฐกิจของการพัฒนาเมื่อเปรียบเทียบกับตัวอย่างหรืออะนาล็อกในประเทศและต่างประเทศที่ดีที่สุด

2.6. ในส่วน "ขั้นตอนและขั้นตอนของการพัฒนา" มีการกำหนดขั้นตอนการพัฒนาขั้นตอนและเนื้อหาของงานที่จำเป็น (รายการเอกสารโปรแกรมที่ต้องพัฒนาตกลงและอนุมัติ) รวมถึงตามกฎของการพัฒนา กำหนดกรอบเวลาและผู้ดำเนินการ

2.7. ส่วน "ขั้นตอนการควบคุมและการยอมรับ" ควรระบุประเภทของการทดสอบและข้อกำหนดทั่วไปสำหรับการยอมรับงาน

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

แผนภาพอัลกอริทึม ตาราง คำอธิบาย เหตุผล การคำนวณ และเอกสารอื่น ๆ ที่สามารถนำมาใช้ระหว่างการพัฒนา แหล่งการพัฒนาอื่นๆ

• GOST 19.001-77 เอกสารประกอบโปรแกรมระบบรวม บทบัญญัติทั่วไป
• GOST 19.005-85 เอกสารประกอบโปรแกรมระบบรวม แบบแผนพีของอัลกอริธึมและโปรแกรม การกำหนดกราฟิกแบบทั่วไปและกฎการดำเนินการ
• GOST 19.101-77 เอกสารประกอบโปรแกรมระบบรวม ประเภทของโปรแกรมและเอกสารโปรแกรม
• GOST 19.102-77 เอกสารประกอบโปรแกรมระบบรวม ขั้นตอนการพัฒนา
• GOST 19.103-77 เอกสารประกอบโปรแกรมระบบรวม การกำหนดโปรแกรมและเอกสารโปรแกรม
• GOST 19.104-78 เอกสารประกอบโปรแกรมระบบรวม จารึกพื้นฐาน
• GOST 19.105-78 เอกสารประกอบโปรแกรมระบบรวม ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม
• GOST 19.106-78 เอกสารประกอบโปรแกรมระบบรวม ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์
• GOST 19.201-78 เอกสารประกอบโปรแกรมระบบรวม ข้อกำหนดทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.202-78 เอกสารประกอบโปรแกรมระบบรวม ข้อมูลจำเพาะ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.301-79 เอกสารประกอบโปรแกรมระบบรวม โปรแกรมทดสอบและวิธีการ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.401-78 เอกสารประกอบโปรแกรมระบบรวม ข้อความโปรแกรม ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.402-78 เอกสารประกอบโปรแกรมระบบรวม คำอธิบายของโปรแกรม
• GOST 19.403-79 เอกสารประกอบโปรแกรมระบบรวม รายชื่อผู้ถือเดิม
• GOST 19.404-79 เอกสารประกอบโปรแกรมระบบรวม หมายเหตุอธิบาย ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.501-78 เอกสารประกอบโปรแกรมระบบรวม รูปร่าง. ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.502-78 เอกสารประกอบโปรแกรมระบบรวม คำอธิบายของแอปพลิเคชัน ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.503-79 เอกสารประกอบโปรแกรมระบบรวม คู่มือโปรแกรมเมอร์ระบบ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.504-79 เอกสารประกอบโปรแกรมระบบรวม คู่มือโปรแกรมเมอร์ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.505-79 เอกสารประกอบโปรแกรมระบบรวม คู่มือการใช้งาน ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.506-79 เอกสารประกอบโปรแกรมระบบรวม คำอธิบายของภาษา ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.507-79 เอกสารประกอบโปรแกรมระบบรวม รายการเอกสารการดำเนินงาน
• GOST 19.508-79 เอกสารประกอบโปรแกรมระบบรวม คู่มือการบำรุงรักษา ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 19.601-78 เอกสารประกอบโปรแกรมระบบรวม กฎทั่วไปสำหรับการทำซ้ำ การบัญชี และการจัดเก็บ
• GOST 19.602-78 เอกสารประกอบโปรแกรมระบบรวม หลักเกณฑ์การทำสำเนา การบัญชี และการจัดเก็บเอกสารโปรแกรมที่พิมพ์
• GOST 19.603-78 เอกสารประกอบโปรแกรมระบบรวม กฎทั่วไปสำหรับการเปลี่ยนแปลง
• GOST 19.604-78 เอกสารประกอบโปรแกรมระบบรวม กฎสำหรับการเปลี่ยนแปลงเอกสารโปรแกรมที่พิมพ์
• GOST 28195-89 การประเมินคุณภาพของซอฟต์แวร์ บทบัญญัติทั่วไป
• GOST 34.601-90 เทคโนโลยีสารสนเทศ ชุดมาตรฐานสำหรับระบบอัตโนมัติ ระบบอัตโนมัติ ขั้นตอนของการสร้างสรรค์
• GOST 34.602-89 เทคโนโลยีสารสนเทศ ชุดมาตรฐานสำหรับระบบอัตโนมัติ เงื่อนไขการอ้างอิงสำหรับการสร้างระบบอัตโนมัติ
• GOST R 56447-2015 ก๊าซ, ก๊าซคอนเดนเสท, น้ำมันและก๊าซและแหล่งน้ำมันและก๊าซคอนเดนเสท ซอฟต์แวร์สำหรับการประมวลผลและการตีความข้อมูลแผ่นดินไหว ข้อกำหนดด้านการทำงานและทางเทคนิคขั้นพื้นฐาน
• GOST R 56448-2015 ก๊าซ, ก๊าซคอนเดนเสท, น้ำมันและก๊าซ และแหล่งน้ำมันและก๊าซคอนเดนเสท ซอฟต์แวร์สำหรับการสร้างแบบจำลองทางธรณีวิทยาของเงินฝาก ข้อกำหนดด้านการทำงานและทางเทคนิคขั้นพื้นฐาน
• GOST R 56450-2015 ก๊าซ, ก๊าซคอนเดนเสท, น้ำมันและก๊าซ และแหล่งน้ำมันและก๊าซคอนเดนเสท ซอฟต์แวร์สำหรับการสร้างแบบจำลองอุทกพลศาสตร์ของระบบรวบรวมและบำบัดไฮโดรคาร์บอน ข้อกำหนดด้านการทำงานและทางเทคนิคขั้นพื้นฐาน
• GOST R 55711-2013 วิธีการทางเทคนิคที่ซับซ้อนของการสื่อสารทางวิทยุแบบดูเพล็กซ์แบบปรับอัตโนมัติ HF (HF) อัลกอริทึมของการทำงาน
• GOST R 56566-2015 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ส่วนที่ 9 โปรไฟล์กระบวนการเป้าหมาย
• GOST R 55692-2013 โมดูลอิเล็กทรอนิกส์ วิธีการคอมไพล์และดีบักโปรแกรมทดสอบสำหรับการควบคุมอัตโนมัติ
• GOST R 56449-2015 ก๊าซ, ก๊าซคอนเดนเสท, น้ำมันและก๊าซ และแหล่งน้ำมันและก๊าซคอนเดนเสท ซอฟต์แวร์สำหรับการสร้างแบบจำลองอุทกพลศาสตร์ของสนาม ข้อกำหนดด้านการทำงานและทางเทคนิคขั้นพื้นฐาน
• GOST R 56413-2015 เทคโนโลยีสารสนเทศ โปรไฟล์งาน ICT ของยุโรป
• GOST R ISO/IEC 15026-1-2016 วิศวกรรมระบบและซอฟต์แวร์ การรับประกันระบบและซอฟต์แวร์ ส่วนที่ 1 แนวคิดและคำศัพท์
• GOST R ISO/IEC 15026-4-2016 วิศวกรรมระบบและซอฟต์แวร์ การรับประกันระบบและซอฟต์แวร์ ส่วนที่ 4 การรับประกันวงจรชีวิต
• GOST R 56920-2016 วิศวกรรมระบบและซอฟต์แวร์ การทดสอบซอฟต์แวร์ ส่วนที่ 1 แนวคิดและคำจำกัดความ
• GOST R 56921-2016 วิศวกรรมระบบและซอฟต์แวร์ การทดสอบซอฟต์แวร์ ส่วนที่ 2: กระบวนการทดสอบ
• GOST R ISO/IEC 26555-2016 วิศวกรรมระบบและซอฟต์แวร์ เครื่องมือและเทคนิคการจัดการทางเทคนิคของสายผลิตภัณฑ์
• GOST R ISO/IEC 29155-1-2016 วิศวกรรมระบบและซอฟต์แวร์ โครงสร้างการวิเคราะห์เปรียบเทียบประสิทธิผลของโครงการเทคโนโลยีสารสนเทศ ส่วนที่ 1 แนวคิดและคำจำกัดความ
• GOST R 54360-2011 ระบบการจัดการข้อมูลห้องปฏิบัติการ (LIMS) คู่มือมาตรฐานสำหรับการตรวจสอบ LIMS
• GOST R 54593-2011 เทคโนโลยีสารสนเทศ ซอฟต์แวร์ฟรี บทบัญญัติทั่วไป
• GOST R ISO/IEC 12207-2010 เทคโนโลยีสารสนเทศ วิศวกรรมระบบและซอฟต์แวร์ กระบวนการวงจรชีวิตของซอฟต์แวร์
• คู่มือมาตรฐาน GOST R 53798-2010 สำหรับระบบการจัดการข้อมูลห้องปฏิบัติการ (LIMS)
• GOST R ISO/IEC 15504-1-2009 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ส่วนที่ 1: แนวคิดและคำศัพท์
• GOST R ISO/IEC 15504-2-2009 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ส่วนที่ 2: การดำเนินการประเมิน
• GOST R ISO/IEC 15504-3-2009 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ส่วนที่ 3: คู่มือการประเมิน
• GOST R 57098-2016 วิศวกรรมระบบและซอฟต์แวร์ การจัดการวงจรชีวิต คู่มือคำอธิบายกระบวนการ
• GOST R 57100-2016 วิศวกรรมระบบและซอฟต์แวร์ คำอธิบายของสถาปัตยกรรม
• GOST R 57101-2016 วิศวกรรมระบบและซอฟต์แวร์ กระบวนการวงจรชีวิต การจัดการโครงการ
• GOST R 57102-2016 เทคโนโลยีสารสนเทศ วิศวกรรมระบบและซอฟต์แวร์ การจัดการวงจรชีวิต ส่วนที่ 2: แนวทางการประยุกต์ใช้ ISO/IEC 15288
• GOST R 57122-2016 ก๊าซ, ก๊าซคอนเดนเสท, น้ำมันและก๊าซ และแหล่งน้ำมันและก๊าซคอนเดนเสท ซอฟต์แวร์ออกแบบการก่อสร้างบ่อน้ำ ข้อกำหนดด้านการทำงานและทางเทคนิคขั้นพื้นฐาน
• GOST R 57193-2016 วิศวกรรมระบบและซอฟต์แวร์ กระบวนการวงจรชีวิตของระบบ
• GOST R ISO/IEC 15504-5-2016 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ส่วนที่ 5: ตัวอย่างแบบจำลองการประเมินกระบวนการวงจรชีวิตซอฟต์แวร์
• GOST 34009-2016 วิธีการและระบบในการควบคุมการลากรางรถไฟ ข้อกำหนดซอฟต์แวร์
• GOST R 57318-2016 ระบบอัตโนมัติทางอุตสาหกรรมและการบูรณาการ การประยุกต์และการจัดการกระบวนการทางวิศวกรรมระบบ
• GOST R ISO/IEC 25001-2017 เทคโนโลยีสารสนเทศ วิศวกรรมระบบและซอฟต์แวร์ ข้อกำหนดและการประเมินคุณภาพระบบและซอฟต์แวร์ (SQuaRE) การวางแผนและการจัดการ
• GOST R ISO/IEC 33004-2017 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ข้อกำหนดสำหรับแบบจำลองอ้างอิงกระบวนการ แบบจำลองการประเมินกระบวนการ และแบบจำลองการเจริญเติบโต
• GOST R ISO/IEC 15414-2017 เทคโนโลยีสารสนเทศ การประมวลผลแบบกระจายแบบเปิด รุ่นอ้างอิง. ภาษาคำอธิบายองค์กร
• GOST IEC 60848-2016 ภาษาข้อกำหนด GRAFCET สำหรับไดอะแกรมฟังก์ชันตามลำดับ
• GOST R ISO/IEC 25051-2017 เทคโนโลยีสารสนเทศ วิศวกรรมระบบและซอฟต์แวร์ ข้อกำหนดและการประเมินคุณภาพระบบและซอฟต์แวร์ (SQuaRE) ข้อกำหนดด้านคุณภาพผลิตภัณฑ์ซอฟต์แวร์พร้อมใช้งาน (RUSP) และคำแนะนำในการทดสอบ
• GOST R ISO/IEC 33001-2017 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ แนวคิดและคำศัพท์เฉพาะทาง
• GOST R ISO/IEC 33002-2017 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ข้อกำหนดสำหรับการดำเนินการประเมินกระบวนการ
• GOST R ISO/IEC 33003-2017 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ข้อกำหนดสำหรับระบบการวัดกระบวนการ
• GOST R ISO/IEC 33020-2017 เทคโนโลยีสารสนเทศ การประเมินกระบวนการ ระบบการวัดกระบวนการสำหรับการประเมินความสามารถของกระบวนการ
• GOST R 57640-2017 เทคโนโลยีสารสนเทศ แบบจำลองการอ้างอิงกระบวนการ (RPM) สำหรับการจัดการความปลอดภัยของข้อมูล
• GOST R ISO/IEC 30121-2017 เทคโนโลยีสารสนเทศ แนวคิดในการจัดการความเสี่ยงที่เกี่ยวข้องกับการตรวจพิสูจน์หลักฐานทางนิติเวชที่นำเสนอในรูปแบบดิจิทัล
• GOST R 58041-2017 ก๊าซ, ก๊าซคอนเดนเสท, น้ำมันและก๊าซ และแหล่งน้ำมันและก๊าซคอนเดนเสท ระบบมาตรฐานซอฟต์แวร์สำหรับการแก้ปัญหาการค้นหาแร่ การสำรวจ และการพัฒนาแหล่งเงินฝาก ข้อกำหนดพื้นฐานและข้อกำหนดทางเทคนิค
• GOST R 58042-2017 ก๊าซ ก๊าซคอนเดนเสท น้ำมันและก๊าซ และแหล่งน้ำมันและก๊าซคอนเดนเสท ข้อกำหนดพื้นฐานสำหรับข้อมูลเบื้องต้นของระบบซอฟต์แวร์สำหรับการแก้ปัญหาการสำรวจแร่ การสำรวจ และการพัฒนาสาขา
• GOST R ISO/IEC 10746-1-2004 เทคโนโลยีสารสนเทศ การประมวลผลแบบกระจายแบบเปิด โมเดลพื้นฐาน ส่วนที่ 1 บทบัญญัติพื้นฐาน
• GOST R ISO/IEC 10746-4-2004 เทคโนโลยีสารสนเทศ การประมวลผลแบบกระจายแบบเปิด โมเดลพื้นฐาน ส่วนที่ 4 ความหมายทางสถาปัตยกรรม

มาตรฐานนี้สอดคล้องกับ ST SEV 1627-79 อย่างสมบูรณ์

กฎการออกแบบ

เงื่อนไขการอ้างอิงถูกร่างขึ้นตาม GOST 19.106-78 บนแผ่นงานรูปแบบ 11 และ 12 ตามกฎ GOST 2.301-68 โดยไม่ต้องกรอกข้อมูลในฟิลด์ของแผ่นงาน หมายเลขแผ่นงาน (หน้า) จะอยู่ที่ด้านบนของแผ่นงานเหนือข้อความ

เอกสารอนุมัติและใบปะหน้า

เอกสารอนุมัติและหน้าชื่อเรื่องจัดทำขึ้นตาม GOST 19.104-78

การเปลี่ยนแปลงและการเพิ่มเติม

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

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

องค์ประกอบของส่วนข้อกำหนดทางเทคนิค

เงื่อนไขการอ้างอิงจะต้องมีส่วนต่อไปนี้:

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

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

ในโปรแกรมการฝึกอบรม เราจะใช้โปรแกรมจริงที่มีอินเทอร์เฟซผู้ใช้แบบกราฟิก ซึ่งให้ความสามารถในการใช้งานฟังก์ชันเทมเพลตต่างๆ (เช่น โปรแกรมแก้ไขข้อความธรรมดา)

การแนะนำ

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

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

ชื่อโปรแกรม

ชื่อ – “โปรแกรมแก้ไขข้อความสำหรับการทำงานกับไฟล์ rtf”

คำอธิบายโดยย่อของสาขาการสมัคร

โปรแกรมนี้มีไว้สำหรับใช้ในแผนกเฉพาะทางที่สถานประกอบการของลูกค้า

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

เหตุผลในการพัฒนา

ส่วนควรระบุ:

เอกสารบนพื้นฐานของการพัฒนา องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ ชื่อและ (หรือ) สัญลักษณ์ของหัวข้อการพัฒนา

ส่วนย่อยควรมีข้อมูลที่มีอยู่ในข้อตกลง

พื้นฐานสำหรับการพัฒนา

พื้นฐานสำหรับการพัฒนาคือข้อตกลง (จดหมาย ฯลฯ) หมายเลข 000 ลงวันที่ 1 มกราคม 2544 (หมายเลขขาเข้าดังกล่าวและดังกล่าวจากดังกล่าวและดังกล่าว) ข้อตกลงดังกล่าวได้ตกลงกับผู้อำนวยการของ State Unitary Enterprise "Spetsyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich ซึ่งต่อไปนี้จะเรียกว่าลูกค้า และได้รับอนุมัติโดยผู้อำนวยการทั่วไป Blyumkins Ivan Aronovich ซึ่งต่อไปนี้จะเรียกว่าผู้รับเหมาในเดือนมีนาคม 2551 .

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

ชื่อและสัญลักษณ์หัวข้อการพัฒนา

ชื่อของหัวข้อการพัฒนาคือ “การพัฒนาโปรแกรมแก้ไขข้อความสำหรับการทำงานกับไฟล์ rtf”

การกำหนดหัวข้อการพัฒนา (รหัสหัวข้อ) คือ “RTF-007”

วัตถุประสงค์ของการพัฒนา

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

วัตถุประสงค์การใช้งาน

วัตถุประสงค์การทำงานของโปรแกรมคือเพื่อให้ผู้ใช้สามารถทำงานกับเอกสารข้อความในรูปแบบ rtf ได้

ส่วนย่อยควรระบุวัตถุประสงค์การทำงาน "ขยาย" ของโปรแกรม รายละเอียด - รายการฟังก์ชัน ฯลฯ - จะได้รับด้านล่างในส่วนที่เกี่ยวข้อง

วัตถุประสงค์ในการดำเนินงานสามารถตีความได้ค่อนข้างกว้าง ควรใช้โปรแกรมที่ไหนอย่างไรโดยใครกับอะไร?

ยางที่มีขนาดเท่ากันสามารถใช้กับรถยนต์ Zhiguli และ Volga ได้สำเร็จ แต่ไม่สามารถใช้กับ KamAZ ได้ และในทางกลับกัน แต่สำหรับยางแต่ละขนาด ก็สามารถกำหนดวัตถุประสงค์การปฏิบัติงานได้

ลองใช้แนวทางที่เป็นทางการ:

วัตถุประสงค์ในการดำเนินงาน

ต้องใช้โปรแกรมในแผนกเฉพาะทางที่สถานประกอบการของลูกค้า

ผู้ใช้โปรแกรมจะต้องเป็นพนักงานของแผนกเฉพาะทางในสถานประกอบการของลูกค้า

ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

ส่วนควรมีส่วนย่อยต่อไปนี้:

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

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

ข้อกำหนดด้านการทำงาน

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

ข้อกำหนดสำหรับองค์ประกอบของฟังก์ชันที่ดำเนินการ

โปรแกรมจะต้องจัดให้มีความสามารถในการทำหน้าที่ดังต่อไปนี้:

1.ฟังก์ชั่นสำหรับสร้างไฟล์ใหม่ (ว่าง)

2.ฟังก์ชั่นสำหรับเปิด (โหลด) ไฟล์ที่มีอยู่

4. ฟังก์ชั่นสำหรับแก้ไขไฟล์ปัจจุบันโดยใช้คลิปบอร์ดของระบบปฏิบัติการ

5.ฟังก์ชั่นการบันทึกไฟล์ด้วยชื่อเดิม

6.ฟังก์ชั่นการบันทึกไฟล์ที่มีชื่อแตกต่างไปจากเดิม

7. ฟังก์ชั่นสำหรับส่งเนื้อหาของไฟล์ปัจจุบันทางอีเมลโดยใช้โปรแกรมอีเมลไคลเอนต์ภายนอก

8. ฟังก์ชั่นแสดงข้อมูลออนไลน์ในรูปแบบสตริง (คำแนะนำ)

9.ฟังก์ชั่นระบบช่วยเหลือออนไลน์

10. ฟังก์ชั่นสำหรับแสดงชื่อโปรแกรม เวอร์ชั่นของโปรแกรม ลิขสิทธิ์ และความคิดเห็นของผู้พัฒนา

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

ข้อกำหนดสำหรับการจัดระเบียบข้อมูลอินพุต

ข้อมูลอินพุตของโปรแกรมจะต้องจัดระเบียบในรูปแบบของไฟล์ rtf แยกกันที่เป็นไปตามข้อกำหนด

ไฟล์ในรูปแบบที่ระบุจะต้องวาง (จัดเก็บ) ไว้ในสื่อท้องถิ่นหรือสื่อแบบถอดได้ซึ่งจัดรูปแบบตามข้อกำหนดของระบบปฏิบัติการ

ไม่ควรเปิดไฟล์ที่มีรูปแบบอื่น แต่มีนามสกุล rtf

ไฟล์ http:///file. rtf หรือ ftp:///file ไม่ควรเปิด rtf หากระบบไฟล์ได้รับการฟอร์แมตเป็น FAT32 ไม่ควรเปิดไฟล์จากสื่อในตัวเครื่องหรือสื่อแบบถอดได้ เช่น ในรูปแบบ ext3

ข้อกำหนดสำหรับการจัดระเบียบข้อมูลเอาต์พุต

ดูข้อกำหนดสำหรับการจัดระเบียบข้อมูลอินพุต

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

ข้อกำหนดด้านเวลา

ไม่มีข้อกำหนดสำหรับลักษณะการกำหนดเวลาของโปรแกรม

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

ข้อกำหนดด้านความน่าเชื่อถือ

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

ความน่าเชื่อถือเป็นสิ่งที่ละเอียดอ่อนและอันตรายมาก แต่รายการฟังก์ชันและโหมดความล้มเหลวตามข้อ 1.3.2 GOST 24.701-86 จะต้องจัดทำโดยลูกค้าและตกลงกับผู้รับเหมา เป็นไปได้มากว่าจะไม่สามารถคาดหวังสิ่งใดที่เข้าใจได้จากลูกค้า เป็นเรื่องที่ควรค่าแก่การอธิบายให้กับลูกค้าว่าการทำงานที่เชื่อถือได้ของโปรแกรมนั้นไม่ได้ขึ้นอยู่กับผู้รับเหมามากนัก แต่ขึ้นอยู่กับความน่าเชื่อถือของฮาร์ดแวร์และระบบปฏิบัติการ และยังต้องเสนอมาตรการที่เข้มงวดหลายประการให้กับลูกค้าเพื่อเพิ่มความน่าเชื่อถือและความเสถียร ของโปรแกรม

ข้อกำหนดสำหรับการรับรองการทำงานของโปรแกรมที่เชื่อถือได้ (เสถียร)

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

การจัดระบบจ่ายไฟสำรองของอุปกรณ์ทางเทคนิค การใช้ซอฟต์แวร์ลิขสิทธิ์ การดำเนินการตามคำแนะนำของกระทรวงแรงงานและการพัฒนาสังคมของสหพันธรัฐรัสเซียเป็นประจำซึ่งกำหนดไว้ในพระราชกฤษฎีกาวันที่ 01/01/01 “ ในการอนุมัติมาตรฐานเวลามาตรฐานระหว่างอุตสาหกรรมสำหรับงานบริการพีซีและอุปกรณ์สำนักงานและการบำรุงรักษาซอฟต์แวร์ ”; การปฏิบัติตามข้อกำหนด GOST เป็นประจำ การคุ้มครองข้อมูล ทดสอบซอฟต์แวร์ว่ามีไวรัสคอมพิวเตอร์หรือไม่

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

แนวทางที่มีมนุษยธรรมมากขึ้นเป็นไปได้ ความน่าเชื่อถือ (ของระบบตาม GOST เดียวกัน) ถือได้ว่าเป็นประสิทธิภาพที่ปราศจากความล้มเหลวของฟังก์ชัน i-th บางอย่างในช่วงเวลาที่กำหนด เราขอแนะนำให้ลูกค้าพิจารณาตัวบ่งชี้ต่อไปนี้เป็นเกณฑ์สำหรับการดำเนินงานที่เชื่อถือได้ของโปรแกรม: ลูกค้าเปิดและปิดไฟล์ 100 ครั้งภายในหนึ่งชั่วโมง หากโปรแกรมไม่ล้มเหลวภายในช่วงเวลาที่กำหนด จะถือว่ามีคุณสมบัติตรงตามข้อกำหนดด้านความน่าเชื่อถือ

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

ไม่มีข้อกำหนดเพื่อให้แน่ใจว่าการทำงานของโปรแกรมเชื่อถือได้ (เสถียร)

เวลาฟื้นตัวหลังจากความล้มเหลว

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

เวลาการกู้คืนหลังจากความล้มเหลวที่เกิดจากความผิดปกติของฮาร์ดแวร์หรือความล้มเหลวร้ายแรง (ขัดข้อง) ของระบบปฏิบัติการไม่ควรเกินเวลาที่จำเป็นในการกำจัดความผิดปกติของฮาร์ดแวร์และติดตั้งซอฟต์แวร์ใหม่

ลูกค้ายังรวบรวมรายการสถานการณ์ฉุกเฉินและตกลงกับผู้รับเหมาด้วย นี่คือเวลาที่ต้องรีบูทระบบปฏิบัติการ หากความล้มเหลวไม่ร้ายแรง ไม่ได้เกิดจากระบบปฏิบัติการขัดข้องหรือฮาร์ดแวร์ขัดข้อง

ความล้มเหลวเนื่องจากการกระทำของผู้ปฏิบัติงานไม่ถูกต้อง

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

เงื่อนไขการใช้งาน

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

สภาพภูมิอากาศในการทำงาน

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

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

ข้อกำหนดสำหรับประเภทของบริการ

ดูข้อกำหนดสำหรับการรับรองการทำงานของโปรแกรมที่เชื่อถือได้ (เสถียร)

โปรแกรมไม่ต้องการการบำรุงรักษาใดๆ

ประเภทของการบำรุงรักษาควรยืมมาจากส่วนย่อย “ข้อกำหนดสำหรับการดำเนินการที่เชื่อถือได้ (ยั่งยืน)”

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

ข้อกำหนดด้านจำนวนและคุณสมบัติของบุคลากร

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

ผู้ดูแลระบบจะต้องมีการศึกษาเฉพาะทางที่สูงกว่าและมีใบรับรองจากผู้ผลิตระบบปฏิบัติการ รายการงานที่ดำเนินการโดยผู้ดูแลระบบควรประกอบด้วย:

ภารกิจในการรักษาฟังก์ชันการทำงานของวิธีการทางเทคนิค งานการติดตั้ง (การติดตั้ง) และการบำรุงรักษาการทำงานของซอฟต์แวร์ระบบ - ระบบปฏิบัติการ งานติดตั้งโปรแกรม

ผู้ใช้โปรแกรม (ผู้ปฏิบัติงาน) จะต้องมีทักษะเชิงปฏิบัติในการทำงานกับส่วนต่อประสานกราฟิกกับผู้ใช้ของระบบปฏิบัติการ

บุคลากรต้องได้รับการรับรองกลุ่มคุณสมบัติ II ด้านความปลอดภัยทางไฟฟ้า (สำหรับการทำงานกับอุปกรณ์สำนักงาน)

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

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

ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค

ส่วนย่อยระบุองค์ประกอบที่ต้องการของวิธีการทางเทคนิคโดยระบุลักษณะทางเทคนิคหลัก

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

วิธีการทางเทคนิคจะต้องมีคอมพิวเตอร์ส่วนบุคคล (PC) ที่เข้ากันได้กับ IBM ซึ่งรวมถึง:

โปรเซสเซอร์ Pentium-1000 ที่มีความถี่สัญญาณนาฬิกา GHz - 10 ไม่น้อย มาเธอร์บอร์ดที่มี FSB, GHz - 5 ไม่น้อย ความจุ RAM, TB - 10 ไม่น้อย และอื่น ๆ...

ข้อกำหนดสำหรับข้อมูลและความเข้ากันได้ของซอฟต์แวร์

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

ในกรณีที่จำเป็น จะต้องรับประกันการปกป้องข้อมูลและโปรแกรม

ข้อกำหนดสำหรับโครงสร้างข้อมูลและวิธีการแก้ไข

โครงสร้างข้อมูลของไฟล์จะต้องมีข้อความที่มีมาร์กอัปซึ่งกำหนดโดยข้อกำหนดเฉพาะของรูปแบบ rtf

ไม่มีข้อกำหนดสำหรับโครงสร้างข้อมูล (ไฟล์) ที่อินพุตและเอาต์พุต รวมถึงวิธีการแก้ไข

ข้อกำหนดสำหรับซอร์สโค้ดและภาษาการเขียนโปรแกรม

ซอร์สโค้ดของโปรแกรมจะต้องนำไปใช้ในภาษา C ++ สภาพแวดล้อม Borland C++ Buider ควรใช้เป็นสภาพแวดล้อมการพัฒนาโปรแกรมแบบรวม

ข้อกำหนดสำหรับซอฟต์แวร์ที่ใช้โดยโปรแกรม

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

ข้อกำหนดสำหรับการปกป้องข้อมูลและโปรแกรม

ไม่มีข้อกำหนดสำหรับการปกป้องข้อมูลและโปรแกรม

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

ข้อกำหนดในการติดฉลากและบรรจุภัณฑ์

โปรแกรมจัดทำเป็นผลิตภัณฑ์ซอฟต์แวร์ - บนสื่อกระจาย (ออปติคอลภายนอก) (ซีดี)

เรากำลังพูดถึงการติดฉลากและบรรจุภัณฑ์ของสื่อการจัดจำหน่าย - ผลิตภัณฑ์ซอฟต์แวร์ (ดู GOST 19.004-80)

ข้อกำหนดการติดฉลาก

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

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

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

ข้อกำหนดด้านบรรจุภัณฑ์

ผลิตภัณฑ์ซอฟต์แวร์จะต้องบรรจุในภาชนะบรรจุภัณฑ์ของผู้ผลิต

ผู้ผลิตนั่นเอง ผู้รับเหมาไม่สามารถและไม่ควรรับผิดชอบมากกว่าผู้ผลิตตู้คอนเทนเนอร์

เงื่อนไขการบรรจุ

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

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

ขั้นตอนการบรรจุ

ผลิตภัณฑ์ซอฟต์แวร์ที่เตรียมไว้สำหรับบรรจุภัณฑ์จะอยู่ในบรรจุภัณฑ์ซึ่งเป็นกล่องที่ทำจากกระดาษลูกฟูก (GOST 7376-89 หรือ GOST 79 ตามแบบของผู้ผลิตคอนเทนเนอร์

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

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

ต้องใส่เอกสารประกอบการปฏิบัติงานไว้ในบรรจุภัณฑ์สำหรับผู้บริโภคพร้อมกับผลิตภัณฑ์ซอฟต์แวร์

เอกสารการจัดส่ง - รายการบรรจุภัณฑ์และรายการบรรจุภัณฑ์ - วางอยู่ที่ชั้นบนสุดของวัสดุกันกระแทก

บรรจุภัณฑ์สำหรับผู้บริโภคต้องปิดด้วยเทปกาว 6-70 ตาม GOST

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

กล่องพาเลทต้องมีเอกสารการจัดส่ง รวมถึงรายการบรรจุภัณฑ์ตาม GOST

ขนาดของพื้นที่บรรทุกสินค้าต้องไม่เกิน 1250 x 820 x 1180 มม.

น้ำหนักสุทธิ - ไม่เกิน 200 กก.

น้ำหนักรวม - ไม่เกิน 220 กก.

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

ข้อกำหนดด้านการขนส่งและการเก็บรักษา

ส่วนย่อยต้องระบุเงื่อนไขการขนส่งผลิตภัณฑ์ซอฟต์แวร์ สถานที่จัดเก็บ สภาพการจัดเก็บ สภาพการจัดเก็บ ระยะเวลาการจัดเก็บในสภาวะต่างๆ

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

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

สภาพการขนส่งและการเก็บรักษา

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

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

อุณหภูมิอากาศโดยรอบ° C - ตั้งแต่บวก 5 ถึงบวก 50; ความดันบรรยากาศ kPa - เช่นนั้น; ความชื้นสัมพัทธ์ในอากาศที่อุณหภูมิ 25 °C ก็เป็นเช่นนั้น

ข้อกำหนดพิเศษ

โปรแกรมจะต้องจัดให้มีการโต้ตอบกับผู้ใช้ (ผู้ปฏิบัติงาน) ผ่านทางส่วนต่อประสานกราฟิกกับผู้ใช้ที่พัฒนาขึ้นตามคำแนะนำของผู้ผลิตระบบปฏิบัติการ

ผู้พัฒนามาตรฐานนี้มองไปสู่อนาคต ในช่วงหลายปีที่ผ่านมาไม่มีโปรแกรมที่มีส่วนต่อประสานกับผู้ใช้แบบกราฟิก

ข้อกำหนดสำหรับเอกสารประกอบซอฟต์แวร์

ส่วนนี้ควรระบุองค์ประกอบเบื้องต้นของเอกสารโปรแกรมและข้อกำหนดพิเศษหากจำเป็น

องค์ประกอบของเอกสารโปรแกรมจัดทำโดย GOST 19.101-77

องค์ประกอบเบื้องต้นของเอกสารโปรแกรม

องค์ประกอบของเอกสารประกอบโปรแกรมควรประกอบด้วย:

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

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

ตามข้อ 2.6 GOST 19.101-77 “ อนุญาตให้รวมเอกสารการปฏิบัติงานบางประเภทได้ (ยกเว้นรายการเอกสารการปฏิบัติงานและแบบฟอร์ม) ความจำเป็นในการรวมเอกสารเหล่านี้ระบุไว้ในข้อกำหนดทางเทคนิค เอกสารที่ผสานได้รับการกำหนดชื่อและการกำหนดเอกสารที่ผสานอย่างใดอย่างหนึ่ง”

เอกสารประกอบซอฟต์แวร์ที่รวมอยู่ในรายการเบื้องต้นจะต้องจัดทำขึ้นตามข้อกำหนดของ GOST 19.106-78

ตัวชี้วัดทางเทคนิคและเศรษฐกิจ

ไม่ได้คำนวณประสิทธิภาพทางเศรษฐกิจโดยประมาณ

จำนวนการใช้โปรแกรมโดยประมาณต่อปีคือ 365 เซสชันการทำงานในเวิร์กสเตชันเดียว

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

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

ประโยชน์ทางเศรษฐกิจของการพัฒนา

ข้อได้เปรียบทางเศรษฐกิจของการพัฒนาเมื่อเปรียบเทียบกับอะนาล็อกในประเทศและต่างประเทศที่ดีที่สุดคือ:

จำนวนงาน

การพัฒนา

ผลประโยชน์ทางเศรษฐกิจ

ขั้นตอนและขั้นตอนของการพัฒนา

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

ขั้นตอนและขั้นตอนการพัฒนาได้รับการควบคุมโดย GOST 19.102-77 GOST 19.102-77 ไม่ได้ป้องกันการแยกงานแต่ละขั้นตอนรวมถึงการรวมงานแต่ละขั้นตอนเข้าด้วยกัน

ขั้นตอนการพัฒนา

การพัฒนาควรดำเนินการในสามขั้นตอน:

การพัฒนาข้อกำหนดทางเทคนิค การออกแบบรายละเอียด การดำเนินการ

ขั้นตอนการพัฒนา

ในขั้นตอนของการพัฒนาข้อกำหนดทางเทคนิค จะต้องเสร็จสิ้นขั้นตอนการพัฒนา การประสานงาน และการอนุมัติข้อกำหนดทางเทคนิคนี้

ในขั้นตอนการออกแบบโดยละเอียด ขั้นตอนการทำงานต่อไปนี้จะต้องเสร็จสิ้น:

การพัฒนาโปรแกรม การพัฒนาเอกสารโปรแกรม ทดสอบโปรแกรม

ในขั้นตอนการดำเนินการ ขั้นตอนการพัฒนาจะต้องเสร็จสิ้น - การเตรียมการและการถ่ายโอนโปรแกรม

ในขั้นตอนของการพัฒนาข้อกำหนดทางเทคนิคต้องดำเนินการดังต่อไปนี้:

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

ในขั้นตอนการพัฒนาโปรแกรม งานจะต้องดำเนินการเกี่ยวกับการเขียนโปรแกรม (การเขียนโค้ด) และการดีบักโปรแกรม

ในขั้นตอนของการพัฒนาเอกสารโปรแกรม การพัฒนาเอกสารโปรแกรมจะต้องดำเนินการตามข้อกำหนดของ GOST 19.101-77 ตามข้อกำหนดของข้อ องค์ประกอบเบื้องต้นของเอกสารประกอบโปรแกรมของข้อกำหนดทางเทคนิคนี้

ในระหว่างขั้นตอนการทดสอบของโปรแกรม จะต้องดำเนินการประเภทต่อไปนี้:

การพัฒนาการประสานงานและการอนุมัติโปรแกรม (ใน GOST ดูเหมือนว่าจะมีการพิมพ์ผิด - "คำสั่ง") และวิธีการทดสอบ ดำเนินการทดสอบการยอมรับ การปรับโปรแกรมและเอกสารโปรแกรมตามผลการทดสอบ

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

ขั้นตอนการควบคุมและการยอมรับ

ส่วนนี้ควรระบุประเภทของการทดสอบและข้อกำหนดทั่วไปสำหรับการยอมรับงาน

ประเภทของการทดสอบ

การทดสอบการยอมรับจะต้องดำเนินการที่ไซต์ของลูกค้าภายในกำหนดเวลา...

การทดสอบการยอมรับของโปรแกรมจะต้องดำเนินการตามโปรแกรมและวิธีการทดสอบที่พัฒนาขึ้น (ไม่ช้ากว่านั้นและระยะเวลาดังกล่าว) โดยผู้รับจ้างและตกลงโดยลูกค้า

ลูกค้าและผู้รับจ้างบันทึกความคืบหน้าของการทดสอบการยอมรับไว้ในรายงานการทดสอบ

ข้อกำหนดทั่วไปสำหรับการยอมรับงาน

ตามระเบียบปฏิบัติการทดสอบ ผู้รับจ้างร่วมกับลูกค้าลงนามในใบรับรองการยอมรับและการว่าจ้างโปรแกรม

การใช้งาน

ในภาคผนวกของข้อกำหนดทางเทคนิค หากจำเป็น ให้ระบุสิ่งต่อไปนี้:

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

ถ้ามีทำไมไม่เอามา และอย่าลืมโพสต์รายการ GOST ตามสิ่งที่ควรดำเนินการพัฒนา ตัวอย่างเช่น:

GOST 19.201-78 ข้อกำหนดทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ และอื่นๆ...

ข้อมูลจำเพาะทางเทคนิค

GOST 19.201-78

มาตรฐานสถานะของสหภาพโซเวียต

ตามคำสั่งของคณะกรรมการมาตรฐานแห่งรัฐสหภาพโซเวียตลงวันที่ 18 ธันวาคม พ.ศ. 2521 ฉบับที่ 3351 ได้มีการกำหนดวันแนะนำ

ตั้งแต่ 01/01/1980

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

1- บทบัญญัติทั่วไป

ส่วนข้อมูล (คำอธิบายประกอบและเนื้อหา) ใบลงทะเบียนการเปลี่ยนแปลงอาจไม่รวมอยู่ในเอกสาร

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

1.4- เงื่อนไขการอ้างอิงจะต้องมีส่วนต่อไปนี้:

ชื่อและขอบเขตของการสมัคร

พื้นฐานการพัฒนา

วัตถุประสงค์ของการพัฒนา

ข้อกำหนดทางเทคนิคสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

ตัวชี้วัดทางเทคนิคและเศรษฐกิจ

ขั้นตอนและขั้นตอนของการพัฒนา

ขั้นตอนการควบคุมและการยอมรับ

การใช้งาน

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

2- สารบัญส่วน

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

2.2- หัวข้อ “พื้นฐานการพัฒนา” ควรระบุ:

เอกสารบนพื้นฐานของการพัฒนา;

องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ

ชื่อและ (หรือ) สัญลักษณ์ของหัวข้อการพัฒนา

2.3- ส่วน “วัตถุประสงค์ของการพัฒนา” จะต้องระบุวัตถุประสงค์การทำงานและการปฏิบัติการของโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

2.4- ส่วน “ข้อกำหนดทางเทคนิคสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์” ควรมีส่วนย่อยต่อไปนี้:

ข้อกำหนดสำหรับลักษณะการทำงาน

ข้อกำหนดด้านความน่าเชื่อถือ

เงื่อนไขการใช้งาน;

ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค

ข้อกำหนดสำหรับข้อมูลและความเข้ากันได้ของซอฟต์แวร์

ข้อกำหนดในการติดฉลากและบรรจุภัณฑ์

ข้อกำหนดสำหรับการขนส่งและการเก็บรักษา

ข้อกำหนดพิเศษ

2.4.1- ส่วนย่อย "ข้อกำหนดสำหรับคุณลักษณะการทำงาน" จะต้องระบุข้อกำหนดสำหรับองค์ประกอบของฟังก์ชันที่ดำเนินการ การจัดระเบียบข้อมูลอินพุตและเอาต์พุต ลักษณะเวลา ฯลฯ

2.4.2- ส่วนย่อย "ข้อกำหนดด้านความน่าเชื่อถือ" จะต้องระบุข้อกำหนดเพื่อให้มั่นใจถึงการทำงานที่เชื่อถือได้ (เพื่อให้มั่นใจว่าการทำงานมีความเสถียร การตรวจสอบข้อมูลอินพุตและเอาท์พุต เวลาฟื้นตัวหลังจากเกิดความล้มเหลว ฯลฯ)

2.4.3- หัวข้อย่อย “สภาวะการทำงาน” จะต้องระบุสภาวะการทำงาน (อุณหภูมิโดยรอบ ความชื้นสัมพัทธ์ ฯลฯ สำหรับสื่อบันทึกประเภทที่เลือก) ที่ต้องรับประกันคุณลักษณะที่ระบุ ตลอดจนประเภทของบริการ จำนวนที่ต้องการและคุณสมบัติของ บุคลากร

2.4.4- ในส่วนย่อย "ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค" ระบุองค์ประกอบที่ต้องการของวิธีการทางเทคนิคโดยระบุถึงลักษณะทางเทคนิคหลัก

2.4.5ส่วนย่อย “ข้อกำหนดสำหรับข้อมูลและความเข้ากันได้ของซอฟต์แวร์” ควรระบุข้อกำหนดสำหรับโครงสร้างข้อมูลที่อินพุตและเอาต์พุตและวิธีการแก้ไข ซอร์สโค้ด และภาษาการเขียนโปรแกรม

ควรให้ข้อมูลและโปรแกรมตามความจำเป็น

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

2.4.7- ส่วนย่อย “ข้อกำหนดสำหรับการขนส่งและการจัดเก็บ” จะต้องระบุเงื่อนไขการขนส่งสำหรับผลิตภัณฑ์ซอฟต์แวร์ สถานที่จัดเก็บ สภาพการจัดเก็บ สภาพการจัดเก็บ ระยะเวลาการจัดเก็บในสภาวะต่างๆ

2.5- ส่วน "ตัวชี้วัดทางเทคนิคและเศรษฐกิจ" ควรระบุ: ประสิทธิภาพทางเศรษฐกิจโดยประมาณ, ความต้องการรายปีโดยประมาณ, ข้อได้เปรียบทางเศรษฐกิจของการพัฒนาเมื่อเปรียบเทียบกับตัวอย่างหรืออะนาล็อกในประเทศและต่างประเทศที่ดีที่สุด

2.6- ในส่วน "ขั้นตอนและขั้นตอนของการพัฒนา" จะมีการกำหนดขั้นตอนการพัฒนาขั้นตอนและเนื้อหาของงานที่จำเป็น (รายการเอกสารโปรแกรมที่ต้องพัฒนาตกลงและอนุมัติ) รวมถึงตามกฎแล้ว กรอบเวลาการพัฒนาและผู้ดำเนินการจะถูกกำหนด

2.7- ส่วน "ขั้นตอนการควบคุมและการยอมรับ" ควรระบุประเภทของการทดสอบและข้อกำหนดทั่วไปสำหรับการยอมรับงาน

2.8- ในภาคผนวกของข้อกำหนดทางเทคนิค หากจำเป็น ให้ระบุสิ่งต่อไปนี้:

รายการงานวิจัยและผลงานอื่น ๆ ที่แสดงให้เห็นถึงการพัฒนา

แผนภาพอัลกอริทึม ตาราง คำอธิบาย เหตุผล การคำนวณ และเอกสารอื่น ๆ ที่สามารถนำมาใช้ระหว่างการพัฒนา

แหล่งการพัฒนาอื่นๆ

มาตรฐานสถานะของสหภาพโซเวียต

ตามคำสั่งของคณะกรรมการมาตรฐานแห่งรัฐสหภาพโซเวียตลงวันที่ 18 ธันวาคม พ.ศ. 2521 ฉบับที่ 3351 ได้มีการกำหนดวันแนะนำ

ตั้งแต่ 01/01/1980

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

มาตรฐานนี้สอดคล้องกับ ST SEV 1627-79 อย่างสมบูรณ์

1. บทบัญญัติทั่วไป

1.1. เงื่อนไขการอ้างอิงถูกร่างขึ้นตาม GOST 19.106-78 บนแผ่นงานรูปแบบ 11 และ 12 ตามกฎ GOST 2.301-68 โดยไม่ต้องกรอกข้อมูลในฟิลด์ของแผ่นงาน หมายเลขแผ่นงาน (หน้า) จะถูกวางไว้ที่ด้านบนของแผ่นงานเหนือข้อความด้วย

1.2. เอกสารอนุมัติและหน้าชื่อเรื่องจัดทำขึ้นตาม GOST 19.104-78

ส่วนข้อมูล (คำอธิบายประกอบและเนื้อหา) ใบลงทะเบียนการเปลี่ยนแปลงอาจไม่รวมอยู่ในเอกสาร

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

1.4. เงื่อนไขการอ้างอิงจะต้องมีส่วนต่อไปนี้:

ชื่อและขอบเขตของการสมัคร

พื้นฐานการพัฒนา

วัตถุประสงค์ของการพัฒนา

ข้อกำหนดทางเทคนิคสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

ตัวชี้วัดทางเทคนิคและเศรษฐกิจ

ขั้นตอนและขั้นตอนของการพัฒนา

ขั้นตอนการควบคุมและการยอมรับ

การใช้งาน

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

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

(แก้ไขฉบับแก้ไขครั้งที่ 1)

2.2. หัวข้อ “พื้นฐานการพัฒนา” ควรระบุ:

เอกสารบนพื้นฐานของการพัฒนา;

องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ

ชื่อและ (หรือ) สัญลักษณ์ของหัวข้อการพัฒนา

(แก้ไขฉบับแก้ไขครั้งที่ 1)

2.3. ส่วน “วัตถุประสงค์ของการพัฒนา” จะต้องระบุวัตถุประสงค์การทำงานและการปฏิบัติการของโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

2.4. ส่วน “ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์” ควรมีส่วนย่อยต่อไปนี้:

ข้อกำหนดสำหรับลักษณะการทำงาน

ข้อกำหนดด้านความน่าเชื่อถือ

เงื่อนไขการใช้งาน;

ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค

ข้อกำหนดสำหรับข้อมูลและความเข้ากันได้ของซอฟต์แวร์

ข้อกำหนดในการติดฉลากและบรรจุภัณฑ์

ข้อกำหนดสำหรับการขนส่งและการเก็บรักษา

ข้อกำหนดพิเศษ

(แก้ไขฉบับแก้ไขครั้งที่ 1)

2.4.1. ส่วนย่อย "ข้อกำหนดสำหรับคุณลักษณะการทำงาน" จะต้องระบุข้อกำหนดสำหรับองค์ประกอบของฟังก์ชันที่ดำเนินการ การจัดระเบียบข้อมูลอินพุตและเอาต์พุต ลักษณะเวลา ฯลฯ

2.4.2. ส่วนย่อย "ข้อกำหนดด้านความน่าเชื่อถือ" จะต้องระบุข้อกำหนดเพื่อให้มั่นใจถึงการทำงานที่เชื่อถือได้ (เพื่อให้มั่นใจว่าการทำงานมีความเสถียร การตรวจสอบข้อมูลอินพุตและเอาท์พุต เวลาฟื้นตัวหลังจากเกิดความล้มเหลว ฯลฯ)

2.4.3. หัวข้อย่อย “สภาวะการทำงาน” จะต้องระบุสภาวะการทำงาน (อุณหภูมิโดยรอบ ความชื้นสัมพัทธ์ ฯลฯ สำหรับสื่อบันทึกประเภทที่เลือก) ที่ต้องรับประกันคุณลักษณะที่ระบุ ตลอดจนประเภทของบริการ จำนวนที่ต้องการและคุณสมบัติของ บุคลากร

2.4.4. ในส่วนย่อย "ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค" ระบุองค์ประกอบที่ต้องการของวิธีการทางเทคนิคโดยระบุถึงลักษณะทางเทคนิคหลัก

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

ในกรณีที่จำเป็น จะต้องรับประกันการปกป้องข้อมูลและโปรแกรม

(แก้ไขฉบับแก้ไขครั้งที่ 1)

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

2.4.7. ส่วนย่อย “ข้อกำหนดสำหรับการขนส่งและการจัดเก็บ” จะต้องระบุเงื่อนไขการขนส่งสำหรับผลิตภัณฑ์ซอฟต์แวร์ สถานที่จัดเก็บ สภาพการจัดเก็บ สภาพการจัดเก็บ ระยะเวลาการจัดเก็บในสภาวะต่างๆ

2.5ก. ส่วน "ข้อกำหนดสำหรับเอกสารประกอบโปรแกรม" ควรระบุองค์ประกอบเบื้องต้นของเอกสารประกอบโปรแกรมและข้อกำหนดพิเศษหากจำเป็น

(แนะนำเพิ่มเติม แก้ไขครั้งที่ 1)

2.5. ส่วน "ตัวชี้วัดทางเทคนิคและเศรษฐกิจ" ควรระบุ: ประสิทธิภาพทางเศรษฐกิจโดยประมาณ, ความต้องการรายปีโดยประมาณ, ข้อได้เปรียบทางเศรษฐกิจของการพัฒนาเมื่อเปรียบเทียบกับตัวอย่างหรืออะนาล็อกในประเทศและต่างประเทศที่ดีที่สุด

2.6. ในส่วน "ขั้นตอนและขั้นตอนของการพัฒนา" จะมีการกำหนดขั้นตอนการพัฒนาขั้นตอนและเนื้อหาของงานที่จำเป็น (รายการเอกสารโปรแกรมที่ต้องพัฒนาตกลงและอนุมัติ) รวมถึงตามกฎแล้ว กรอบเวลาการพัฒนาและผู้ดำเนินการจะถูกกำหนด

2.7. ส่วน "ขั้นตอนการควบคุมและการยอมรับ" ควรระบุประเภทของการทดสอบและข้อกำหนดทั่วไปสำหรับการยอมรับงาน

2.8. ในภาคผนวกของข้อกำหนดทางเทคนิค หากจำเป็น ให้ระบุสิ่งต่อไปนี้:

รายการงานวิจัยและผลงานอื่น ๆ ที่แสดงให้เห็นถึงการพัฒนา

แผนภาพอัลกอริทึม ตาราง คำอธิบาย เหตุผล การคำนวณ และเอกสารอื่น ๆ ที่สามารถนำมาใช้ระหว่างการพัฒนา

แหล่งการพัฒนาอื่นๆ

* ออกใหม่ (พฤศจิกายน 2530) โดยมีการเปลี่ยนแปลงครั้งที่ 1 ได้รับการอนุมัติในเดือนมิถุนายน 2524 (ICS 9-81)