การเตรียม TK. ข้อกำหนดในการอ้างอิง: ข้อกำหนดทางกฎหมายและแนวทางปฏิบัติที่ดีที่สุด

คำจำกัดความของขอบเขตของโครงการ การพัฒนาข้อกำหนดทางเทคนิค

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

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

คำนิยาม

ควรสังเกตว่า ณ เวลานี้ไม่มีคำจำกัดความมาตรฐานของข้อกำหนดอ้างอิง (TOR) สำหรับโครงการนวัตกรรม ในฐานข้อมูลมาตรฐานแห่งชาติปัจจุบัน มีสามมาตรฐานที่เกี่ยวข้องกับ TK ทั้งหมดอยู่ในสาขาเทคโนโลยีสารสนเทศ:

GOST 19.201-78 ระบบเดียวเอกสารประกอบซอฟต์แวร์ งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ

GOST 25123-82 เครื่องคอมพิวเตอร์และระบบประมวลผลข้อมูล งานด้านเทคนิค ลำดับของการก่อสร้าง การนำเสนอ และการออกแบบ

GOST 34.602-89 เทคโนโลยีสารสนเทศ. ชุดมาตรฐานสำหรับระบบอัตโนมัติ เงื่อนไขการอ้างอิงสำหรับการสร้าง ระบบอัตโนมัติ.

ตัวอย่างเช่นใน "GOST 19.201-78. ระบบรวมเอกสารของโปรแกรม งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ” ให้คำจำกัดความของ TOR ดังต่อไปนี้: “ข้อกำหนดในการอ้างอิงสำหรับระบบอัตโนมัติเป็นเอกสารที่ได้รับอนุมัติอย่างถูกต้องซึ่งกำหนดเป้าหมาย ข้อกำหนด และข้อมูลเบื้องต้นเบื้องต้นที่จำเป็นสำหรับการพัฒนาระบบอัตโนมัติและมีข้อมูลเบื้องต้น การประเมินประสิทธิภาพทางเศรษฐกิจ”

มันบอกว่า TK อนุญาต:

ถึงผู้รับเหมา - เพื่อทำความเข้าใจสาระสำคัญของงานเพื่อแสดงให้ลูกค้าเห็น "ลักษณะทางเทคนิค" ของผลิตภัณฑ์ในอนาคต ผลิตภัณฑ์ซอฟต์แวร์หรือระบบอัตโนมัติ

ลูกค้า - เพื่อให้รู้ว่าเขาต้องการอะไร

ทั้งสองฝ่าย - เพื่อนำเสนอผลิตภัณฑ์สำเร็จรูป

ถึงผู้บริหาร - เพื่อวางแผนการดำเนินโครงการและทำงานตามแผน

ให้กับลูกค้า - เพื่อเรียกร้องจากผู้รับเหมาว่าผลิตภัณฑ์ตรงตามเงื่อนไขทั้งหมดที่ระบุใน TOR

ถึงผู้รับเหมา - ปฏิเสธที่จะทำงานที่ไม่ได้ระบุไว้ใน TOR;

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

หลีกเลี่ยงข้อผิดพลาดที่เกี่ยวข้องกับข้อกำหนดที่เปลี่ยนแปลง (ในทุกขั้นตอนและขั้นตอนของการสร้าง ยกเว้น การทดสอบ).

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

ยิ่ง TOR มีรายละเอียดมากเท่าใด ความขัดแย้งระหว่างลูกค้าและนักพัฒนาก็จะยิ่งน้อยลงในระหว่างการทดสอบการยอมรับ

TK ทำหน้าที่หลักสี่ประการ:

ถูกกฎหมาย. TK เป็นเอกสารทางกฎหมาย และเนื่องจากแอปพลิเคชันรวมอยู่ในสัญญาระหว่างลูกค้าและผู้รับเหมา

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

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

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

สาระสำคัญของ TK

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

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

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

การทำงานกับ TK เป็นขั้นตอนที่ยากและมีความรับผิดชอบ เนื่องจากยังไม่มีข้อมูลจำนวนมาก ความสำเร็จของโครงการตามที่ผู้เชี่ยวชาญระบุว่า 50 -70% ขึ้นอยู่กับการดำเนินการตามขั้นตอนของการพัฒนา TOR ที่มีคุณสมบัติเหมาะสม

ตามกฎแล้ว ขั้นตอนของการพัฒนาข้อกำหนดทางเทคนิคจะนำหน้าด้วยการศึกษาหัวข้อ การคำนวณ และการสร้างแบบจำลอง

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

TK ตกลงกับลูกค้าหรือพัฒนาร่วมกัน

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

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

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

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

ต่อไปนี้เป็นตัวอย่างโครงสร้างของ TK จากแหล่งต่างๆ

ตัวอย่างเช่น TK อาจมีส่วนต่างๆ:

เรื่องของ TK;

วัตถุประสงค์ของงานที่ทำ

ข้อกำหนดในการรายงาน

ลำดับการจัดระเบียบงาน

ตัวอย่างจาก GOST 19.201-78 ดังกล่าว

การแนะนำ;

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

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

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

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

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

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

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

อนุญาตให้รวมแอปพลิเคชันไว้ในเงื่อนไขการอ้างอิง

ตัวอย่าง TOR สำหรับการให้บริการที่ปรึกษาดังต่อไปนี้

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

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

ข้อกำหนดคุณสมบัติสำหรับผู้สมัคร

ตัวอย่าง TOR สำหรับการดำเนินงานวิจัย "การพัฒนาแนวคิด กลยุทธ์การพัฒนา และการศึกษาความเป็นไปได้ในการสร้างอุทยานเทคโนโลยีและนวัตกรรมในเมือง Perm" (ต่อไปนี้จะเรียกว่า R&D)

พื้นฐานการวิจัย

นักแสดงและนักแสดงร่วม

1. วัตถุประสงค์ของการวิจัย

   ข้อมูลเบื้องต้น

   ข้อกำหนดพื้นฐานสำหรับการทำวิจัย

   แผนปฏิทินสำหรับการดำเนินการวิจัย

   ตั้งใจใช้ผลการวิจัย

   ขั้นตอนการส่งมอบและยอมรับผลการวิจัย

ตัวอย่างโครงสร้างของเทมเพลต TOR สำหรับ R&D

พื้นฐานในการทำงาน

เพชฌฆาต

เงื่อนไขการทำงาน

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

ผลการวิจัยและพัฒนา

สินค้าอยู่ระหว่างการพัฒนา

ความต้องการทางด้านเทคนิค

พารามิเตอร์หลักที่จะได้รับจากการทำงาน:

ข้อกำหนดการออกแบบขั้นพื้นฐาน (ถ้ามี)

ข้อกำหนดตามประเภทหลักประกัน (ถ้ามี)

ข้อกำหนดสำหรับการกำหนดมาตรฐาน การรวม ความเข้ากันได้กับวัตถุที่ผสมพันธุ์และความสามารถในการแลกเปลี่ยนกันได้

ข้อกำหนดสำหรับการรับรองความปลอดภัยในชีวิตมนุษย์และสุขภาพและการปกป้องสิ่งแวดล้อม

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

ข้อกำหนดสำหรับความน่าเชื่อถือและความทนทาน

ข้อกำหนดด้านสรีรศาสตร์และสุนทรียศาสตร์ทางเทคนิค (ถ้ามี)

ข้อกำหนดสำหรับการดำเนินงาน ความสามารถในการให้บริการ และการบำรุงรักษา (ถ้ามี)

ข้อกำหนดด้านความยืดหยุ่น (ถ้ามี)

ข้อกำหนดด้านประสิทธิภาพ (ถ้ามี)

ข้อกำหนดการรับรอง

ข้อกำหนดอื่น ๆ และข้อกำหนดพิเศษตามอุตสาหกรรม

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

ข้อกำหนดด้านเอกสาร

ลำดับการรับงาน

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

คุณสมบัติของการพัฒนาข้อกำหนดทางเทคนิคสำหรับโครงการนวัตกรรม

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

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

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

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

ตัวบ่งชี้ที่สรุปไว้ในรายการข้อกำหนดมีระบุไว้ในเอกสารซึ่งเรียกว่าข้อกำหนดเพิ่มเติม

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

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

TOR แบบขยายอาจรวมถึง:

1. รายละเอียดโครงการ

2. เป้าหมายทางการตลาดและเศรษฐกิจของโครงการ

3. พารามิเตอร์เวลา

4. พารามิเตอร์ทางเทคนิค

5. พารามิเตอร์การผลิต

8. ข้อกำหนดสำหรับการออกแบบและการยศาสตร์

9. มาตรฐานและข้อบังคับ

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

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

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

พิจารณาตำแหน่งของ TK ในโครงสร้าง กระบวนการสร้างนวัตกรรมในองค์กร(นวัตกรรมในองค์กร) ตาม .

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

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

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

เมื่อ TOR เป็นเอกสารได้รับการอนุมัติ การวางแผนงานในโครงการจะดำเนินการ

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

ดังนั้น TK

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

ลองวิเคราะห์ตัวอย่างนี้:

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

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

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

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

นี่เป็นเพียงตัวอย่างปฏิทินซ้ำๆ

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

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

TOR มักประกอบด้วยรายการใดบ้าง

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

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

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

ไปที่จุด

คำอธิบายของเว็บไซต์

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

เพื่อใคร - กลุ่มเป้าหมายของเว็บไซต์:

• ผู้ซื้อที่มีศักยภาพ
• ผู้ขายสินค้า (ร้านค้า ร้านค้าออนไลน์)
• ศูนย์บริการ
• พันธมิตร (บริษัท)
• ผู้บริโภคสินค้า (ผู้ที่ซื้อไปแล้ว)

ทำไมถึงต้องมีเว็บไซต์:

• เพื่อเสริมสร้างภาพลักษณ์ของบริษัท
• เพื่อเพิ่มยอดขาย
• เพื่อความสะดวกของลูกค้า

ประเภทไซต์:

• ขององค์กร
• เว็บไซต์ - นามบัตร
• ร้านอินเตอร์เน็ต

เวอร์ชันภาษา:

• ภาษาอังกฤษ
• รัสเซีย

เว็บไซต์ต้องแก้ปัญหาบางอย่าง ดังนั้นเราจึงก้าวต่อไปตามเป้าหมายและวัตถุประสงค์ของไซต์

เป้าหมายและวัตถุประสงค์ของไซต์

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

ผู้ซื้อผลิตภัณฑ์ที่มีศักยภาพ.

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

ปัญหาต้องได้รับการแก้ไข:

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

• ส่งข้อมูลเกี่ยวกับร้านค้า
• ส่งข้อมูลการขายปลีก

ให้โอกาสในการถามคำถามผ่านองค์กรให้คำปรึกษาออนไลน์ของผู้ซื้อที่มีศักยภาพโดยผู้เชี่ยวชาญขององค์กรในการเลือกซื้อสินค้า

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

ตอนนี้เราระบุโมดูลของไซต์

การทำงานของเว็บไซต์

ในการแสดงรายการฟังก์ชันของไซต์ คุณต้องตัดสินใจว่าต้องการอะไร:

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

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

คำอธิบายของฟังก์ชั่นเว็บไซต์

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

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

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

ก่อนอื่นคุณต้องบอกเกี่ยวกับบริษัท อาจมีเพจเกี่ยวกับบริษัท ประวัติบริษัท ผู้ติดต่อ รีวิว

โดยธรรมชาติแล้วควรมีรายการเมนู "ผลิตภัณฑ์" พร้อมรายการย่อย " แคตตาล็อกสินค้า"," เปิดตัว ", "บทวิจารณ์ผลิตภัณฑ์"

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

เกี่ยวกับบริษัท

• ประวัติบริษัท
• รายชื่อผู้ติดต่อ
• ความคิดเห็น

ข่าว

• พัฒนาการ
• หุ้น
• ใหม่บนเว็บไซต์

สินค้า

• แคตตาล็อกสินค้า
• เผยแพร่
• รีวิวสินค้า

บริการ

• ฝ่ายบริการ
• บริการรับประกัน
• บริการหลังการรับประกัน

ผู้บริโภค

• ซื้อและจัดส่ง
• ใช้
• เกี่ยวกับบริการ

ร้านค้าและร้านค้าออนไลน์

• รูปถ่ายสินค้า
• คำถามที่พบบ่อย

ศูนย์บริการ

• วิธีการเป็นศูนย์บริการ
• คำถามที่พบบ่อย

พันธมิตร

• ขอความร่วมมือ
• คำถามที่พบบ่อย

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

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

สิ่งสำคัญในตอนนี้คือการอธิบายตรรกะของงาน

ตรรกะการทำงาน

ฉันจะอธิบายตามรูปด้านบน

ด้านบนของไซต์ยังคงเหมือนเดิมในทุกหน้าของไซต์ ฟีดข่าวจะปรากฏเฉพาะบน หน้าแรก. ในหน้ารองทางด้านซ้าย เราแสดงรายการย่อยเมนูของรายการที่เราอยู่ในปัจจุบัน (เช่น หากเราอยู่ในหน้า "บริการ" เราจะแสดงลิงก์ไปยัง "บริการรับประกัน", "โพสต์ -บริการรับประกัน") ดังนั้น การเปลี่ยนในลิงก์เหล่านี้จะนำไปสู่หน้าที่เกี่ยวข้อง ที่นี่ ใต้รายการย่อยทางด้านซ้าย เราแสดงข้อมูลสำหรับการติดต่อที่ปรึกษาออนไลน์ (Skype, ICQ) บล็อกการส่งเสริมการขายและการเผยแพร่ยังคงอยู่ในแต่ละหน้า ส่วนท้ายของไซต์จะแสดงเหมือนกันทุกหน้า

อธิบายตรรกะทั่วไปของงานโดยประมาณ

ตอนนี้เราอธิบายแต่ละบล็อกโดยละเอียด ตัวอย่างเช่น "ฟีดข่าว"

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

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

ควรมีอะไรอีกบ้าง? เป็นการดีที่จะระบุความเข้ากันได้

ความเข้ากันได้

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

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

บทสรุป

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

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

และอย่าลืมความท้าทาย!

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

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

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

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

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

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

ฉันคิดว่าตอนนี้ผู้อ่านควรมีคำถาม:

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

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

งานด้านเทคนิคคืออะไร?

สิ่งแรกที่เราจะทำในตอนนี้คือค้นหาว่านี่คือสัตว์ชนิดใด "ข้อกำหนดในการอ้างอิง"

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

โปรดทราบว่า GOST ไม่ได้ให้คำจำกัดความอย่างชัดเจน แต่กล่าวว่า: “ TOR สำหรับ NPP เป็นเอกสารหลักที่กำหนดข้อกำหนดและขั้นตอนสำหรับการสร้าง (การพัฒนาหรือความทันสมัย ​​- การสร้างเพิ่มเติม) ของระบบอัตโนมัติตาม โดยดำเนินการพัฒนา NPP และยอมรับเมื่อเริ่มดำเนินการ”

หากมีคนสงสัยว่าฉันกำลังพูดถึง GOST อะไรอยู่ พวกเขาคือ:

• GOST 2.114-95 ระบบ Unified สำหรับเอกสารการออกแบบ ข้อมูลจำเพาะ;
• GOST 19.201-78 ระบบรวมเอกสารโปรแกรม งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
• GOST 34.602-89 เทคโนโลยีสารสนเทศ ชุดมาตรฐานสำหรับระบบอัตโนมัติ เงื่อนไขการอ้างอิงสำหรับการสร้างระบบอัตโนมัติ

วิกิพีเดียมีคำจำกัดความที่ดีกว่ามาก (ความจริงเกี่ยวกับ TK โดยทั่วไปไม่ใช่เฉพาะซอฟต์แวร์): “ งานด้านเทคนิคเป็นเอกสารการออกแบบต้นฉบับ เทคนิควัตถุ. งานด้านเทคนิคกำหนดวัตถุประสงค์หลักของวัตถุที่กำลังพัฒนา ลักษณะทางเทคนิค ยุทธวิธี และทางเทคนิค ตัวชี้วัดคุณภาพ และข้อกำหนดทางเทคนิคและเศรษฐกิจ คำแนะนำในการทำตามขั้นตอนที่จำเป็นในการสร้างเอกสาร (การออกแบบ เทคโนโลยี ซอฟต์แวร์ ฯลฯ) และองค์ประกอบตามที่กำหนด ตลอดจนข้อกำหนดพิเศษ งานที่เป็นเอกสารต้นทางสำหรับการสร้างสิ่งใหม่มีอยู่ในทุกส่วนของกิจกรรม แตกต่างกันในชื่อ เนื้อหา ลำดับของการดำเนินการ ฯลฯ (เช่น งานออกแบบในการก่อสร้าง งานต่อสู้ การบ้าน สัญญาสำหรับ งานวรรณกรรม ฯลฯ ) e.)"

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

เป็นตัวหลักแต่ตัวเดียว ถึงเวลาทำสิ่งสำคัญ: วางทุกอย่าง "บนชั้นวาง" ตามที่สัญญาไว้

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

• ข้อกำหนดด้านการทำงาน
• ข้อกำหนดสำหรับการรักษาความปลอดภัยและสิทธิ์การเข้าถึง
• ข้อกำหนดสำหรับคุณสมบัติบุคลากร
• …. เป็นต้น คุณสามารถอ่านเกี่ยวกับพวกเขาใน GOST ที่กล่าวถึง (และด้านล่างฉันจะพิจารณารายละเอียดเพิ่มเติมอีกเล็กน้อย)

ฉันคิดว่ามันชัดเจนสำหรับคุณแล้วว่าข้อกำหนดที่มีการกำหนดไว้อย่างดีสำหรับการทำงานเป็นกุญแจสู่ข้อกำหนดในการอ้างอิงที่ประสบความสำเร็จ ข้อกำหนดเหล่านี้มีไว้สำหรับงานและวิธีการส่วนใหญ่ที่ฉันพูดถึง ข้อกำหนดด้านการทำงาน 90% ของความซับซ้อนของการพัฒนาข้อกำหนดในการอ้างอิง อย่างอื่นมักจะเป็น "ลายพราง" ตามข้อกำหนดเหล่านี้ หากข้อกำหนดมีการกำหนดไว้ไม่ดี ไม่ว่าคุณจะใส่ลายพรางที่สวยงามอะไรก็ตาม โครงการที่ประสบความสำเร็จจะไม่ทำงาน ใช่ จะปฏิบัติตามข้อกำหนดทั้งหมดอย่างเป็นทางการ (ตาม GOST J) TOR ได้รับการพัฒนา อนุมัติและลงนาม และได้รับเงินสำหรับมันแล้ว แล้วไง? แล้วความสนุกก็เริ่มขึ้น: จะทำอย่างไร? หากนี่เป็นโครงการตามคำสั่งของรัฐก็ไม่มีปัญหา - มีงบประมาณที่ไม่พอดีกับกระเป๋าใด ๆ ทุกอย่างจะมีความกระจ่างในกระบวนการดำเนินการ (ถ้ามี) ด้วยวิธีนี้งบประมาณส่วนใหญ่ของโครงการในคำสั่งของรัฐจะถูกตัดออก (พวกเขายิง "TK" ซึ่งรวมกันเป็นสิบล้าน แต่ไม่ได้เริ่มทำโครงการ ปฏิบัติตามพิธีการทั้งหมดไม่มีความผิด รถใหม่ใกล้บ้าน สวย!). แต่เรากำลังพูดถึงองค์กรการค้าที่มีการนับเงินและผลที่ได้กลับแตกต่างออกไป ดังนั้นมาจัดการกับสิ่งสำคัญวิธีการพัฒนา เงื่อนไขการอ้างอิงที่เป็นประโยชน์และใช้งานได้.

ฉันพูดเกี่ยวกับประเภทของข้อกำหนดแล้ว แต่คุณสมบัติล่ะ? หากประเภทของข้อกำหนดอาจแตกต่างกัน (ขึ้นอยู่กับเป้าหมายของโครงการ) แล้วด้วยคุณสมบัติทุกอย่างจะง่ายขึ้นมี 3 รายการ:

1. ความต้องการจะต้อง เข้าใจได้;
2. ความต้องการจะต้อง เฉพาะเจาะจง;
3. ความต้องการจะต้อง ทดสอบแล้ว;

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

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

• ในภาษาใด (ในแง่ของความซับซ้อนของความเข้าใจ) ควรเขียนข้อกำหนดในการอ้างอิง?
• ควรระบุข้อกำหนดของฟังก์ชันต่างๆ อัลกอริธึม ชนิดข้อมูล และเทคนิคอื่นๆ หรือไม่
• และการออกแบบทางเทคนิคคืออะไรซึ่งโดยวิธีการที่กล่าวถึงใน GOST และเกี่ยวข้องกับข้อกำหนดในการอ้างอิงอย่างไร

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

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

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

เรามีอะไรในทางปฏิบัติ? เป็นเรื่องตลกที่จะดูเมื่อผู้กำกับได้รับการอนุมัติตามข้อกำหนดในการอ้างอิงซึ่งเต็มไปด้วยคำศัพท์ทางเทคนิคคำอธิบายประเภทข้อมูลและค่าโครงสร้างฐานข้อมูล ฯลฯ แน่นอนเขาพยายามทำความเข้าใจเนื่องจากจำเป็น เพื่อยืนยันพยายามค้นหาคำที่คุ้นเคยระหว่างบรรทัดและไม่สูญเสียข้อกำหนดทางธุรกิจลูกโซ่ สถานการณ์ที่คุ้นเคยคืออะไร? และจบลงอย่างไร? ตามกฎแล้ว TOR ดังกล่าวได้รับการอนุมัติแล้วจึงดำเนินการและใน 80% ของกรณีนั้นไม่สอดคล้องกับความเป็นจริงของงานที่ทำเลยเพราะ หลายอย่างที่พวกเขาตัดสินใจเปลี่ยนแปลง ทำซ้ำ เข้าใจผิด คิดผิด ฯลฯ เป็นต้น จากนั้นชุดส่งมอบก็เริ่มต้นขึ้น “แต่นี่ไม่ใช่วิธีที่เราต้องการ” แต่ “ใช้ไม่ได้ผลสำหรับเรา” “มันซับซ้อนเกินไป” “ไม่สะดวก” เป็นต้น คุ้นเคย?! ดังนั้นฉันจึงรู้ว่าฉันต้องเติมการกระแทกให้ทันเวลา

แล้วในทางปฏิบัติเรามีอะไรบ้าง? แต่ในทางปฏิบัติ เรามีเส้นขอบที่ไม่ชัดเจนระหว่างข้อกำหนดในการอ้างอิงและการออกแบบทางเทคนิค มันลอยอยู่ระหว่าง TK และ TP ในหลากหลายวิธี และที่ไม่ดี และกลายเป็นอย่างนั้นเพราะวัฒนธรรมการพัฒนาเริ่มอ่อนแอ ส่วนหนึ่งเป็นผลมาจากความสามารถของผู้เชี่ยวชาญ ส่วนหนึ่งเป็นเพราะความปรารถนาที่จะลดงบประมาณและกำหนดเวลา (หลังจากทั้งหมด เอกสารใช้เวลานาน - นี่คือข้อเท็จจริง) มีปัจจัยสำคัญอีกประการหนึ่งที่มีอิทธิพลต่อการใช้การออกแบบทางเทคนิคเป็นเอกสารแยกต่างหาก: การพัฒนาอย่างรวดเร็วของเครื่องมือการพัฒนาอย่างรวดเร็ว เช่นเดียวกับวิธีการพัฒนา แต่นี่เป็นเรื่องราวที่แยกจากกัน ฉันจะพูดสองสามคำเกี่ยวกับเรื่องนี้ด้านล่าง

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

คุณต้องการข้อกำหนดทางเทคนิคจริงๆหรือ? แล้วโครงการวิศวกรรมล่ะ?

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

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

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

มาศึกษาคำถามกันต่อ: "ข้อกำหนดใดบ้างที่ควรรวมอยู่ในข้อกำหนดในการอ้างอิง"

การกำหนดข้อกำหนดสำหรับระบบสารสนเทศ โครงสร้างของข้อกำหนดในการอ้างอิง

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

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

แม้ว่าการกำหนดข้อกำหนดเป็นส่วนหลัก เงื่อนไขอ้างอิงและในบางกรณีจะกลายเป็นส่วนเดียวของ ToR คุณควรให้ความสนใจกับข้อเท็จจริงที่ว่านี่เป็นเอกสารสำคัญ และควรร่างขึ้นตามนั้น จะเริ่มต้นที่ไหน? ก่อนอื่น คุณต้องเริ่มด้วยเนื้อหา เขียนเนื้อหาแล้วเริ่มคลี่ออก โดยส่วนตัวแล้ว ฉันทำสิ่งนี้: ขั้นแรกฉันร่างเนื้อหา อธิบายเป้าหมาย ข้อมูลเบื้องต้นทั้งหมด จากนั้นฉันใช้ส่วนหลัก - การกำหนดข้อกำหนด ทำไมไม่กลับกันล่ะ? ฉันไม่รู้ มันสะดวกกว่าสำหรับฉัน ประการแรก นี่เป็นช่วงเวลาที่น้อยกว่ามาก (เมื่อเทียบกับข้อกำหนด) และประการที่สอง ขณะที่อธิบายข้อมูลเบื้องต้นทั้งหมด คุณปรับให้เข้ากับสิ่งสำคัญ แล้วแต่ใครชอบ. เมื่อเวลาผ่านไป คุณจะพัฒนาเทมเพลตข้อกำหนดในการอ้างอิงของคุณเอง ในการเริ่มต้น ฉันขอแนะนำให้ใช้เนื้อหาตามที่อธิบายไว้ใน GOST ทุกประการ มันยอดเยี่ยมสำหรับเนื้อหา! จากนั้นเราจะเริ่มอธิบายแต่ละส่วนโดยไม่ลืมคำแนะนำสำหรับคุณสมบัติสามประการต่อไปนี้: ความเข้าใจ ความจำเพาะ และความสามารถในการทดสอบ ทำไมฉันถึงยืนยันเรื่องนี้มาก? เพิ่มเติมเกี่ยวกับเรื่องนี้ในหัวข้อถัดไป และตอนนี้ฉันขอเสนอ all-tact เพื่อผ่านจุดเหล่านั้นของ TK ที่แนะนำใน GOST

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

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

ส่วนที่ 1 ข้อมูลทั่วไป

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

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

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

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

หมวดที่ 3 ลักษณะของออบเจกต์อัตโนมัติ

ส่วนที่ 4 ความต้องการของระบบ

GOST ถอดรหัสรายการข้อกำหนดดังกล่าว:

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

แม้ว่าที่จริงแล้วแน่นอนว่าส่วนหลักจะเป็นส่วนที่มีข้อกำหนดเฉพาะ (หน้าที่) ส่วนนี้อาจมีความสำคัญอย่างยิ่ง (และในกรณีส่วนใหญ่) สิ่งที่สำคัญและมีประโยชน์:

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

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

GOST แยกแยะประเภทต่อไปนี้:

• คณิตศาสตร์
• ข้อมูล
• ภาษาศาสตร์
• ซอฟต์แวร์
• เทคนิค
• มาตรวิทยา
• องค์กร
• ระเบียบวิธี
• และคนอื่น ๆ…

เมื่อมองแวบแรกอาจดูเหมือนว่าข้อกำหนดเหล่านี้ไม่สำคัญ สิ่งนี้เป็นจริงสำหรับโครงการส่วนใหญ่ แต่ไม่เสมอไป. เมื่อใดควรอธิบายข้อกำหนดเหล่านี้:

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

หมวด ๕ องค์ประกอบและเนื้อหาของงานในการสร้างระบบ

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

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

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

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

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

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

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

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

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

ส่วนที่ 8 ข้อกำหนดด้านเอกสาร

พิจารณาว่าจะมีการนำเสนอคู่มือผู้ใช้อย่างไร

บางทีลูกค้าอาจยอมรับมาตรฐานองค์กร ดังนั้นคุณต้องติดต่อพวกเขา

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

ส่วนที่ 9 แหล่งที่มาของการพัฒนา

ดังนั้นจึงเป็นการดีกว่าที่จะอ้างอิงถึงรายงานการสำรวจความต้องการของบุคคลสำคัญ

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

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

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

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

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

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

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

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

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

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

ฉันหวังว่าความคิดจะชัดเจน หากคุณมีคำถามเฉพาะ เขียนไว้ ฉันจะพยายามช่วย

เข้า เงื่อนไขอ้างอิงมีความเฉพาะเจาะจงมากขึ้นมีคำแนะนำมากมาย มีแม้กระทั่งรายการคำที่ไม่แนะนำให้ใช้ในแง่ของการอ้างอิง K. Vigers เขียนเรื่องนี้ไว้อย่างน่าสนใจในหนังสือ “Development of Software Requirements” นี่คือคำแนะนำที่น่าสนใจและเรียบง่ายที่สุดในความคิดของฉัน:

• อย่าใช้คำที่มีคำพ้องความหมายมากมาย หากจำเป็น เป็นการดีกว่าที่จะให้คำจำกัดความที่ชัดเจนของคำศัพท์ในส่วนข้อกำหนดและคำจำกัดความของข้อกำหนดในการอ้างอิง
• คุณควรพยายามอย่าใช้ประโยคยาวๆ
• หากข้อกำหนดดูเหมือนกว้างเกินไปสำหรับคุณ จะต้องมีรายละเอียดให้เล็กลง แต่ข้อกำหนดเฉพาะ
• ใช้ไดอะแกรม, กราฟ, ตาราง, ภาพวาดมากขึ้น - วิธีนี้จะรับรู้ข้อมูลได้ง่ายขึ้นมาก
• ควรหลีกเลี่ยงคำต่อไปนี้: "มีประสิทธิภาพ", "เพียงพอ", "ง่าย", "เข้าใจได้", "เร็ว", "ยืดหยุ่น", "ดีขึ้น", "ดีที่สุด", "โปร่งใส", "ยั่งยืน", "เพียงพอ" , “เป็นมิตร”, “ง่าย” ฯลฯ รายการต่อได้ แต่ผมคิดว่าแนวคิดชัดเจน (พยายามต่อด้วยตัวเอง)

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

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

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

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

ตามปกติในชีวิต:

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

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

ลองให้กระบวนการที่กล่าวถึงข้างต้นเป็นวิธีที่เป็นระบบมากขึ้น แล้วเขาจะมองยังไง?

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

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

เรามาดูกันว่าคุณจะจัดระเบียบวิธีการรวบรวมข้อมูลเกี่ยวกับกิจกรรมของบริษัทได้อย่างไร

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

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

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

ทีนี้ลองมาพิจารณาว่าแนวทางการศึกษาข้อกำหนดของระบบสารสนเทศจะมีลักษณะอย่างไรด้วยการไตร่ตรองเพิ่มเติมในข้อกำหนดในการอ้างอิง

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

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

ภาคผนวก 1 อธิบายกระบวนการทางธุรกิจในรูปแบบ EPC

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

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

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

เหตุใดจึงต้องมีข้อกำหนด

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

ข้อกำหนดในการอ้างอิงสำหรับไซต์มีลักษณะอย่างไร

ความปรารถนาของคุณ “บล็อกที่มีเนื้อหาฟรี หน้าเกี่ยวกับฉันและผู้ติดต่อ”นักแสดงเห็นสิ่งนี้:

คุณคิดว่านี่เพียงพอที่จะสร้างเว็บไซต์หรือไม่?

คุณได้ไซต์ที่เสร็จสมบูรณ์แล้ว ทันใดนั้น กลับกลายเป็นว่าคุณหมายถึงสิ่งนี้:

ความแตกต่างของคำอธิบายมีความสำคัญมาก

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

ฉันแนะนำว่าอย่านำสิ่งต่าง ๆ ไปสู่สุดขั้ว แต่ให้เข้าใกล้การจัดเตรียมเงื่อนไขการอ้างอิงสำหรับไซต์อย่างมีสติ

สิ่งที่เขียนในแง่ของการอ้างอิง?

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

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

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

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

ส่วนหลักของข้อกำหนดในการอ้างอิงสำหรับการพัฒนาไซต์

1. ข้อมูลเกี่ยวกับลูกค้า นั่นคือ เกี่ยวกับคุณ

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

2. ข้อมูลเกี่ยวกับโครงการ

จะเป็นอย่างไร: เว็บไซต์นามบัตร ร้านค้าออนไลน์ พอร์ทัลองค์กร ห้องสมุดอิเล็กทรอนิกส์?

3. กลุ่มเป้าหมายของเว็บไซต์

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

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

4. เป้าหมายและงานที่ไซต์ควรแก้ไขสำหรับลูกค้าและสำหรับผู้ชม

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

ระบุวัตถุประสงค์โดยตรงของไซต์ของคุณ

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

5. กรอบงานโครงการ (หน้าที่หลัก)

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

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

6. โครงสร้าง (แผนที่) ของไซต์

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

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

แผนผังการเชื่อมต่อระหว่างกันของส่วนต่างๆ ของไซต์

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

7. หน้าบุคคล

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

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

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

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

8. ข้อกำหนดการออกแบบเว็บไซต์

ในขั้นตอนนี้ต้องระวัง สมมติว่าผู้ออกแบบเป็นมืออาชีพ คุณไม่จำเป็นต้องจดบันทึกทุกขั้นตอน อย่าบอก: “ทำให้ปุ่มนี้ล้นจากสีน้ำเงินเป็นสีแดง และข้อความนี้ในขนาดที่ 12 และเพื่อให้กะพริบ”. ระบุความปรารถนาหลักของคุณ ตัวอย่างเช่น แสดงเว็บไซต์/แบนเนอร์/สิ่งพิมพ์ที่มีอยู่ซึ่งคุณคิดว่าเหมาะสมกับการออกแบบของคุณ บอกเราว่าคุณต้องการสีอะไร สมมติว่าคุณต้องการสร้างไซต์สำหรับการฝึกสตรีโดยเฉพาะ นักออกแบบอาจ "เห็น" ไซต์นั้นเป็นสีชมพู แต่คุณชอบสีม่วงและสีส้ม คำอธิบายทั่วไปความปรารถนาจะช่วยหาจุดประนีประนอมระหว่างวิสัยทัศน์ของคุณกับรูปลักษณ์ที่เป็นมืออาชีพของนักออกแบบ

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

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

9. ฟังก์ชันการทำงานของไซต์

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

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

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

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

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

10. คำอธิบายของเนื้อหา

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

11. ข้อกำหนดทางเทคนิค

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

ไม่ต้องการที่จะผิดหวังอย่างสมบูรณ์เมื่อยอมรับไซต์จากนักพัฒนาซอฟต์แวร์ใช่หรือไม่ จากนั้นอ่านบทความนี้อย่างระมัดระวัง!

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

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

ทำไมคุณถึงต้องการงานนี้?

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

พวกเขาเขียนอะไรในแง่ของการอ้างอิง?

งานนี้ตอบคำถามต่อไปนี้:

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

ส่วนหลักของข้อกำหนดในการอ้างอิงสำหรับการพัฒนาเว็บไซต์

1. ข้อมูลเกี่ยวกับลูกค้า นั่นคือ เกี่ยวกับคุณ

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

2. ข้อมูลเกี่ยวกับโครงการ

จะเป็นอย่างไร: ไซต์นามบัตร บล็อก ร้านค้าออนไลน์ พอร์ทัลองค์กร ห้องสมุดอิเล็กทรอนิกส์?

3. กลุ่มเป้าหมายของเว็บไซต์

อธิบายกลุ่มเป้าหมายของคุณ บอกสิ่งที่พวกเขาต้องการและวิธีที่พวกเขาจะสนใจ

4. เป้าหมายและงานที่ไซต์ควรแก้ไขสำหรับลูกค้าและสำหรับผู้ชม

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

ระบุวัตถุประสงค์โดยตรงของไซต์ของคุณ

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

5. กรอบงานโครงการ (หน้าที่หลัก)

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

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

6. โครงสร้าง (แผนที่) ของไซต์

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

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

7. หน้าบุคคล

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

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

8. ข้อกำหนดการออกแบบเว็บไซต์

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

9. ฟังก์ชันการทำงานของไซต์

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

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

10. คำอธิบายของเนื้อหา

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

11. ข้อกำหนดทางเทคนิค

จุดยากสำหรับผู้ที่เข้าใจเพียงเล็กน้อยในการสร้างไซต์

หากคุณไม่เข้าใจ ให้เปิดตรรกะ

ตัวอย่างเช่น ไซต์ของคุณควร:

• ดูดีเท่ากันบนจอภาพที่มีความกว้างต่างกัน (การออกแบบที่ตอบสนอง)
• ปรับ SEO ให้เหมาะสมสำหรับการโปรโมต
• สามารถต้านทานไวรัสได้
• มีฟังก์ชัน seo ในตัวเป็นต้น

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