---
title: "Systems analysis in IT — การวิเคราะห์ระบบในด้าน IT"
source: "https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT"
wiki: "systems-analysis.info/int"
article: "Systems_analysis_in_IT_—_การวิเคราะห์ระบบในด้าน_IT"
language: "th"
categories:
  - "Category:Systems analysis"
  - "Category:Thai"
revision_id: 7622
wiki_created_at: 2026-09-07T01:04:35Z
wiki_modified_at: 2026-09-07T01:04:35Z
downloaded_at: 2026-09-07T23:19:55Z
---

# Systems analysis in IT — การวิเคราะห์ระบบในด้าน IT

**การวิเคราะห์ระบบในด้าน IT** (*Systems Analysis and Design*) — แนวทางในการออกแบบและพัฒนาระบบสารสนเทศตั้งแต่แนวคิดจนถึงการใช้งานจริง ครอบคลุมการระบุความต้องการ การกำหนดข้อกำหนดอย่างเป็นทางการ การสร้างแบบจำลองของโดเมนและกระบวนการ รวมถึงการประเมินทางเลือกและความเสี่ยง กล่าวอีกนัยหนึ่ง การวิเคราะห์ระบบในด้าน IT คือขั้นตอนของการพัฒนาที่ผู้เชี่ยวชาญศึกษาปัญหา กำหนดสิ่งที่ระบบต้องทำ และพัฒนาโซลูชันเพื่อสร้างระบบนั้น

**การวิเคราะห์ระบบแบบดั้งเดิม** ครอบคลุมขอบเขตการประยุกต์ใช้ที่กว้างขวาง*,* ไม่เพียงแต่การพัฒนาซอฟต์แวร์เท่านั้น แต่ยังรวมถึงการเปลี่ยนแปลงองค์กร กลยุทธ์ และด้านอื่น ๆ<a href="https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7" class="external autonumber" rel="nofollow">[1]</a> <a href="https://systems-analysis.ru/systems_analysis.html" class="external autonumber" rel="nofollow">[2]</a>

## หัวข้อและภารกิจของการวิเคราะห์ระบบในด้าน IT

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

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

ภารกิจของการวิเคราะห์ระบบประกอบด้วย:

- **การระบุความต้องการและเป้าหมายของผู้มีส่วนได้เสีย** นักวิเคราะห์รวบรวมและชี้แจงความคาดหวังของลูกค้า ผู้ใช้งาน และฝ่ายที่เกี่ยวข้องอื่น ๆ โดยใช้การสัมภาษณ์ แบบสอบถาม การสังเกต และการวิเคราะห์กระบวนการปัจจุบัน ผลลัพธ์คือ**ข้อกำหนดเบื้องต้น** ที่แบ่งแยกระหว่างข้อกำหนดเชิงฟังก์ชัน («สิ่งที่ระบบต้องทำ») และข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน (ความน่าเชื่อถือ ประสิทธิภาพ ความปลอดภัย ฯลฯ)<sup>[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-Zowghi-2)</sup>

<!-- -->

- **การกำหนดและจัดทำเอกสารข้อกำหนดอย่างเป็นทางการ** คำขอถูกแปลงเป็นข้อกำหนดที่ตรวจสอบได้ ข้อกำหนดที่กำหนดขึ้นอย่างดีควรชัดเจนและไม่คลุมเครือ ครบถ้วน สอดคล้องกัน ตรวจสอบได้ และสามารถติดตามได้ถึงเป้าหมายระดับสูงกว่า ชุดข้อกำหนดควรสอดคล้องและเป็นเนื้อเดียวกัน<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA7123-4)</sup> ในทางปฏิบัติจะใช้เอกสารมาตรฐาน: SRS (*Software Requirements Specification*) ตาม ISO/IEC/IEEE 29148 รวมถึงในบางอุตสาหกรรม URS (*User Requirements Specification*) และข้อกำหนดเชิงฟังก์ชัน<sup>[\[5\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-5)[\[6\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-6)[\[7\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-7)</sup>

<!-- -->

- **การวิเคราะห์และสร้างแบบจำลองระบบ** เพื่อทำความเข้าใจว่าระบบจะทำงาน*อย่างไร*และมีปฏิสัมพันธ์กับโลกภายนอก จะสร้างแบบจำลอง: ไดอะแกรม Use Case สำหรับสถานการณ์การใช้งาน, DFD สำหรับกระแสข้อมูลและกระบวนการทางธุรกิจ, ไดอะแกรมคลาส/คอมโพเนนต์ ฯลฯ แบบจำลองเป็นพื้นฐานสำหรับการเปรียบเทียบโซลูชันและสถาปัตยกรรมทางเลือก<sup>[\[8\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-8)[\[9\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-9)[\[10\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO42010-10)</sup>

<!-- -->

- **การประเมินความเป็นไปได้และการเลือกโซลูชัน** มีการดำเนินการ *feasibility study* (ความเป็นไปได้ทางเทคนิค องค์กร เศรษฐกิจ กำหนดการ) และการเปรียบเทียบทางเลือกสถาปัตยกรรม (*trade-off*) สำหรับการประเมินคุณภาพสถาปัตยกรรมตามแอตทริบิวต์ (เช่น ประสิทธิภาพ ความสามารถในการปรับขนาด ความสามารถในการปรับเปลี่ยน) จะใช้วิธีการเช่น ATAM (*Architecture Tradeoff Analysis Method*)<sup>[\[11\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-11)[\[12\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ATAM-12)</sup> การเลือกระหว่าง เช่น สถาปัตยกรรมแบบ monolithic และ microservices <a href="https://aws.amazon.com/ru/compare/the-difference-between-monolithic-and-microservices-architecture/" class="external autonumber" rel="nofollow">[3]</a> อาศัยการแลกเปลี่ยนที่ชัดเจน (ความซับซ้อนในการดำเนินงาน vs. ความสามารถในการปรับขนาดอิสระและความเร็วในการส่งมอบ) ตามคำแนะนำของคู่มืออุตสาหกรรม<sup>[\[13\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-13)[\[14\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-14)</sup>

<!-- -->

- **การเตรียม Artifact ของโครงการ** ผลลัพธ์จากการวิเคราะห์ประกอบด้วย:
  - ข้อกำหนดที่ได้รับการอนุมัติ (พร้อมระบุความสำคัญ)
  - แบบจำลองเชิงแนวคิดของระบบ (ไดอะแกรม/คำอธิบาย)
  - การตัดสินใจด้านสถาปัตยกรรมและการออกแบบ (แผนผังข้อมูล อินเทอร์เฟซระบบภายนอก)
  - แผนการนำไปใช้งาน (ขั้นตอน/โมดูล)
  - สิ่งสำคัญคือต้องรับประกัน *ความสามารถในการติดตาม* (bidirectional traceability) ของข้อกำหนดต่อองค์ประกอบการออกแบบและการทดสอบ<sup>[\[15\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-15)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA7123-4)</sup>

ความสำเร็จของโครงการ IT ขึ้นอยู่กับแนวปฏิบัติที่เป็นผู้ใหญ่ในการทำงานกับข้อกำหนดและสถาปัตยกรรมอย่างมีนัยสำคัญ การศึกษาที่ดำเนินการโดย McKinsey และ Oxford แสดงให้เห็นว่าโครงการ IT ขนาดใหญ่มักเกินงบประมาณและกำหนดเวลา การศึกษานี้ยังเน้นย้ำว่าการจัดการกลยุทธ์อย่างถูกต้อง การมีปฏิสัมพันธ์กับผู้มีส่วนได้เสีย และการรวบรวมข้อกำหนดอย่างมีทักษะมีความสำคัญเพียงใด ทั้งหมดนี้สามารถส่งผลอย่างมากต่อความสำเร็จหรือความล้มเหลวของโครงการ<sup>[\[16\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-16)</sup>

## แนวทางและระเบียบวิธีในการวิเคราะห์ระบบ IT

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

- **แนวทางแข็งและแนวทางอ่อน** ในโครงการ IT แนวทางแข็ง (hard systems) สันนิษฐานว่าเป้าหมายและข้อกำหนดสามารถกำหนดได้อย่างเป็นทางการล่วงหน้า การแยกย่อยและการออกแบบ «จากบนลงล่าง» แนวทางอ่อน (soft systems) ใช้เมื่อเป้าหมายไม่ชัดเจนและมีหลายมุมมอง: ใช้องค์ประกอบของ Soft Systems Methodology (SSM) (เช่น *rich picture* คำจำกัดความรากเหง้า CATWOE) เพื่อประสานความเข้าใจปัญหาและการเปลี่ยนแปลงที่ต้องการ จากนั้นแปลผลลัพธ์เป็นข้อกำหนดอย่างเป็นทางการ<sup>[\[17\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-17)[\[18\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-18)</sup>

<!-- -->

- **ระเบียบวิธี SSM (Soft Systems Methodology)** เดิมพัฒนาโดย*ปีเตอร์ เช็คแลนด์* สำหรับการเปลี่ยนแปลงองค์กร SSM มีประโยชน์ในขั้นตอนก่อนโครงการ IT: ตั้งแต่การสำรวจสถานการณ์ปัญหาและการกำหนดคำจำกัดความรากเหง้า (รวมถึงผ่าน CATWOE) ไปจนถึงการเปรียบเทียบแบบจำลองเชิงแนวคิดกับความเป็นจริงและการบรรลุการรับรู้ร่วมระหว่างผู้มีส่วนได้เสีย<sup>[\[19\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-19)[\[20\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-20)</sup>

<!-- -->

- **ระเบียบวิธีเชิงโครงสร้าง: SADT/IDEF0** SADT สร้างแบบจำลองระบบเป็นลำดับชั้นของฟังก์ชัน สัญกรณ์มาตรฐาน IDEF0 (IEEE 1320.1) บันทึกฟังก์ชันและอินเทอร์เฟซ I-C-O-M (Inputs, Controls, Outputs, Mechanisms) วิธีนี้สะดวกสำหรับการแยกย่อยเชิงฟังก์ชันและการกำหนดขอบเขตระบบโดยไม่ขึ้นกับอัลกอริทึม<sup>[\[21\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-21)[\[22\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-22)</sup>

<!-- -->

- **การวิเคราะห์เชิงวัตถุ:** UML และ SysML (MBSE) UML กลายเป็นภาษาพื้นฐานสำหรับข้อกำหนดและการออกแบบ (ไดอะแกรม Use Case, คลาส, ลำดับ ฯลฯ) และอำนวยความสะดวกในการตรวจสอบสถานการณ์กับผู้ใช้ SysML ขยาย UML สำหรับวิศวกรรมระบบ (ไดอะแกรมข้อกำหนด ไดอะแกรมพารามิเตอร์) และอาศัยแนวทาง MBSE ที่แบบจำลองเป็น Artifact หลักตลอดขั้นตอนตั้งแต่ข้อกำหนดจนถึงการทดสอบ<sup>[\[23\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-23)[\[24\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-24)[\[25\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-25)</sup>

<!-- -->

- **การสร้างแบบจำลองกระบวนการทางธุรกิจ:** BPMN มาตรฐาน BPMN ใช้สำหรับการอธิบายกราฟิกของกระบวนการ (pools, กระแสงาน, เหตุการณ์, เกตเวย์) รวมถึงการเปรียบเทียบ *as-is/to-be* ในข้อกำหนดและการบูรณาการ<sup>[\[26\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-26)[\[27\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-27)</sup>

<!-- -->

- **ความเชื่อมโยงกับวิศวกรรมข้อกำหนด** กระบวนการประกอบด้วยขั้นตอน elicitation–analysis–specification–validation–change management เกณฑ์ «ข้อกำหนดที่ดี» และโครงสร้าง SRS ถูกกำหนดโดย ISO/IEC/IEEE 29148 สำหรับการจัดลำดับความสำคัญจะใช้เทคนิค **MoSCoW** (Must/Should/Could/Won't) และวิธีการเลือกหลายเกณฑ์ เช่น AHP ในกระบวนการแบบ Agile กิจกรรมการวิเคราะห์ระบบสะท้อนอยู่ใน backlog refinement และการติดตามข้อกำหนด<sup>[\[28\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-28)[\[29\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-29)[\[30\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-30)[\[31\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-31)</sup>

<!-- -->

- **ความเชื่อมโยงกับวิศวกรรมระบบ** สำหรับระบบที่ซับซ้อน (ไซเบอร์ฟิสิคัล) จะใช้ V-model: บนสาขา «ซ้าย» — การวิเคราะห์ระบบและสถาปัตยกรรม บนสาขา «ขวา» — การบูรณาการ การตรวจสอบและการยืนยัน โดยเชื่อมโยงกับ Artifact ของสาขาซ้าย วิธีการประเมินสถาปัตยกรรมตามแอตทริบิวต์คุณภาพประกอบด้วย ATAM (การวิเคราะห์ trade-off)<sup>[\[32\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-32)[\[33\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-33)</sup>

การวิเคราะห์ระบบใน IT ผสมผสานแนวทางที่ผ่านการพิสูจน์ — ตั้งแต่วิธีการอ่อนในการประสานวิสัยทัศน์ ไปจนถึงสัญกรณ์และมาตรฐานที่เป็นทางการ การเลือกเครื่องมือถูกกำหนดโดยระดับความแน่นอนของงาน: เมื่อมีความไม่แน่นอนสูง บทบาทของ SSM และการอำนวยความสะดวกจะเพิ่มขึ้น เมื่อขอบเขตชัดเจน — แบบจำลองที่เป็นทางการ (UML/SysML, IDEF0, BPMN) และกฎระเบียบ

## ความเชื่อมโยงกับสถาปัตยกรรม IT และสถาปัตยกรรมองค์กร

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

- **สถาปัตยกรรมระบบ IT** ในความหมายแคบ สถาปัตยกรรมซอฟต์แวร์คือการจัดระเบียบของคอมโพเนนต์ ความสัมพันธ์ และหลักการที่ใช้เป็นแนวทางในการออกแบบโซลูชัน นักวิเคราะห์ต้องคำนึงถึงสไตล์สถาปัตยกรรม (layered, client–server, microservices, event-driven ฯลฯ) เนื่องจากข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน (ความน่าเชื่อถือ ความสามารถในการปรับขนาด ความสามารถในการปรับเปลี่ยน) มักกำหนดการตัดสินใจด้านสถาปัตยกรรมและการแลกเปลี่ยนของมัน<sup>[\[34\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SEI_ATAM-35)</sup> ในขั้นตอนการวิเคราะห์ช่วงต้น จะมีการก่อรูป **วิสัยทัศน์สถาปัตยกรรม** (high-level vision) และพัฒนาโครงร่างโซลูชันเบื้องต้นเพื่อตรวจสอบความเป็นไปได้ของข้อกำหนด (ความยาวของการวนซ้ำและรายละเอียดขึ้นอยู่กับระเบียบวิธี)<sup>[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-TOGAFIntro-36)</sup>

<!-- -->

- **Pattern และการตัดสินใจเบื้องต้น** สำหรับการตอบสนองข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน จะใช้ architectural patterns เช่น สำหรับการสื่อสารแบบอะซิงโครนัสและการเชื่อมต่อแบบหลวม — publish–subscribe ผ่าน message broker ในสถาปัตยกรรม event-driven<sup>[\[37\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-AzureEvent-37)</sup>

<!-- -->

- **TOGAF (The Open Group Architecture Framework)** หนึ่งในเฟรมเวิร์กสถาปัตยกรรมองค์กรที่แพร่หลายที่สุด ประกอบด้วยวิธีการ ADM (Architecture Development Method) และ Artifact การจัดการสถาปัตยกรรม (repository, catalogs/matrices, หลักการ) ใน TOGAF การจัดการข้อกำหนดเป็นกระบวนการข้ามสาย ที่บูรณาการในทุกระยะของ ADM<sup>[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-TOGAFIntro-36)</sup> สำหรับการสนับสนุนข้อกำหนดและการติดตามจะใช้ catalogs และ matrices (เช่น ข้อกำหนด ↔ บริการ, ฟังก์ชัน ↔ คอมโพเนนต์) รวมถึงมีการแยกแยะ ***Architecture Building Blocks*** และ ***Solution Building Blocks***<sup>[\[38\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-38)[\[39\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-39)</sup> หลักการและมาตรฐานขององค์กรถูกบันทึกใน catalogs ที่เกี่ยวข้องและทำหน้าที่เป็น**ข้อกำหนด**ที่ไม่ใช่เชิงฟังก์ชันภายนอกสำหรับทีมโครงการ<sup>[\[40\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-40)</sup> ความสอดคล้องของโซลูชันกับสถาปัตยกรรมเป้าหมายได้รับการยืนยันผ่านขั้นตอน Architecture Compliance Review<sup>[\[41\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-41)</sup> แนวทาง TOGAF สันนิษฐาน **Architecture Vision** เบื้องต้นและการพัฒนารายละเอียดในภายหลัง (ข้อมูล/แอปพลิเคชัน/เทคโนโลยี) พร้อมแผนการโยกย้ายและการจัดการการเปลี่ยนแปลงข้อกำหนด<sup>[\[42\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-42)[\[43\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-43)</sup>

<!-- -->

- **Zachman Framework** ออนโทโลยีที่เก่าแก่และทรงอิทธิพลของ Artifact สถาปัตยกรรมองค์กร นำเสนอเป็นเมทริกซ์ 6×6 (มุมมอง × แง่มุม «อะไร/อย่างไร/ที่ไหน/ใคร/เมื่อไหร่/ทำไม») แถว «นักออกแบบ» สอดคล้องกับการวิเคราะห์และการออกแบบระบบ คอลัมน์กำหนดความสมบูรณ์ในการพิจารณาข้อมูล ฟังก์ชัน/กระบวนการ บทบาท ตำแหน่ง และแรงจูงใจ เฟรมเวิร์กทำหน้าที่เป็นการจำแนกประเภท (ไม่ใช่ระเบียบวิธี) และช่วยให้มั่นใจถึงความสมบูรณ์ของคำอธิบายโซลูชันในภูมิทัศน์ขององค์กร<sup>[\[44\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-Zachman1987-44)</sup>

<!-- -->

- **ความเชื่อมโยงกับสถาปัตยกรรมองค์กร (Enterprise Architecture, EA)** นักวิเคราะห์ระบบทำงานในบริบทของ EA: ข้อกำหนดใหม่ถูกติดตามไปยังความสามารถทางธุรกิจและรูปแบบการดำเนินงาน ใช้มาตรฐานและข้อจำกัดหลักการขององค์กร (ความปลอดภัย ความเข้ากันได้ ฯลฯ)<sup>[\[45\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-45)[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-TOGAFIntro-36)</sup> ในขั้นตอนการเริ่มต้นโครงการจะมีการก่อรูป ***Architecture Vision*** (เป้าหมาย/ข้อจำกัด ข้อกำหนดระดับสูง) จากนั้นนักวิเคราะห์จะพัฒนารายละเอียดโดยรักษาการติดตามถึงวิสัยทัศน์และมาตรฐานองค์กร การไม่ปฏิบัติตามมาตรฐานจะถูกตรวจพบในการ Architecture Review และอาจนำไปสู่การแก้ไขโซลูชัน<sup>[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-46)</sup>

โดยสรุป: การวิเคราะห์ระบบและการออกแบบสถาปัตยกรรมก่อให้เกิดคู่ «ข้อกำหนด → การตัดสินใจด้านสถาปัตยกรรม → การแลกเปลี่ยนตามแอตทริบิวต์คุณภาพ» การเลือกวิธีการ (สไตล์/pattern, Artifact ของ TOGAF, การจำแนกตาม Zachman) ถูกกำหนดโดยลักษณะของโครงการและกรอบสถาปัตยกรรมองค์กร

## กระบวนการและแนวปฏิบัติ

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

- **SDLC แบบดั้งเดิม (Waterfall)** ขั้นตอน System Analysis & Requirements Definition มาก่อนการออกแบบและการนำไปใช้งาน ข้อกำหนดถูกกำหนดไว้ใน **SRS** โดยละเอียดเป็นพื้นฐานของการวางแผนและสัญญา มีประสิทธิภาพในโดเมนที่มีความเสถียรและมีการควบคุม ความเสี่ยงของ «การแช่แข็ง» ข้อกำหนดลดลงด้วย SRR/review และการจัดการการเปลี่ยนแปลงผ่าน **CCB**<sup>[\[47\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_CCB-49)</sup>

<!-- -->

- **ระเบียบวิธีแบบ Agile** การวิเคราะห์ดำเนินการอย่างต่อเนื่อง: แทนที่จะใช้ SRS สุดท้าย จะมีการจัดการ product backlog จาก user stories พร้อมเกณฑ์การยอมรับที่ปรับปรุงใน backlog refinement ใช้ **BDD** (Given–When–Then) ความเสี่ยงของการสูญเสียสถาปัตยกรรมโดยรวมได้รับการชดเชยด้วยการพัฒนาสถาปัตยกรรมในระยะแรกและการติดตามข้อกำหนด ↔ การนำไปใช้งาน/การทดสอบที่โปร่งใส<sup>[\[50\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-MS_Trace-52)</sup>

<!-- -->

- **DevOps และ SRE** การ release บ่อยครั้งต้องการข้อกำหนดการดำเนินงาน «ตามค่าเริ่มต้น»: ระบบอัตโนมัติ การสังเกตการณ์ การย้อนกลับ ข้อกำหนดที่ไม่ใช่เชิงฟังก์ชันถูกกำหนดเป็น SLO/SLI จัดการ error budget เพิ่มงานเกี่ยวกับ logs/metrics/traces/alerts ใน backlog สำหรับการปล่อยโดยไม่มี downtime — pattern **blue/green** และอื่น ๆ<sup>[\[53\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-AWS_BlueGreen-55)</sup>

<!-- -->

- **การจัดการข้อกำหนดและความเสี่ยง** ข้อกำหนดใน ALM มีสถานะและความเชื่อมโยงกับงาน/release/defect จำเป็นต้องมี version control, change impact analysis และการจัดลำดับความสำคัญใหม่อย่างสม่ำเสมอ<sup>[\[56\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-Azure_Backlog-57)</sup>

<!-- -->

- **การประกันคุณภาพ (QA)** คุณภาพถูกสร้างขึ้นในขั้นตอนข้อกำหนด: review, «Three Amigos», แผน *Acceptance Test Plan*, การทดสอบอัตโนมัติของเกณฑ์การยอมรับ (BDD/ATDD)<sup>[\[58\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-MS_SpecFlow-59)</sup>

<!-- -->

- **การสังเกตการณ์และความน่าเชื่อถือ** ข้อกำหนดประกอบด้วย SLA/SLO, MTTR และ MTBF พร้อมเป้าหมายที่วัดได้และวิธีการควบคุม พารามิเตอร์มาจากฝ่ายธุรกิจ/ปฏิบัติการและถูกสร้างไว้ในสถาปัตยกรรมและการทดสอบความน่าเชื่อถือ<sup>[\[60\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-GCloud_Obs-61)</sup>

## เมตริกและคุณภาพของ Artifact

สำหรับการประเมินงานของนักวิเคราะห์ระบบและคุณภาพของผลลัพธ์ จะใช้เกณฑ์ที่ยอมรับโดยทั่วไป **ข้อกำหนดและแบบจำลองที่มีคุณภาพ** เป็นรากฐานของโครงการที่ประสบความสำเร็จ ดังนั้นจึงได้รับการจัดการตลอดวงจรชีวิต (elicitation → specification → verification/validation → change management) แอตทริบิวต์คุณภาพพื้นฐานของข้อกำหนดถูกกำหนดไว้ในมาตรฐาน ISO/IEC/IEEE 29148 และ (ในประวัติศาสตร์) IEEE 830<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

- **ความถูกต้อง (Correctness)** — ข้อกำหนดสะท้อนความต้องการที่แท้จริงและสอดคล้องกับผู้เชี่ยวชาญในโดเมน ได้รับการยืนยันโดยการตรวจสอบ (review/inspection, ต้นแบบ, สถานการณ์)<sup>[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA7123-4)</sup>

<!-- -->

- **ความสมบูรณ์ (Completeness)** — ครอบคลุมแง่มุมและเงื่อนไขที่สำคัญ
  - *ความสมบูรณ์ของข้อกำหนดเดี่ยว*: ระบุรายละเอียดที่จำเป็น (เช่น «ตัวชี้วัดเปลี่ยนเป็นสถานะ **สีแดงเมื่อเกิดความล้มเหลว**» ไม่ใช่แค่ «กลายเป็นสีแดง»)
  - *ความสมบูรณ์ของข้อกำหนด*: ครอบคลุมสถานการณ์/บทบาท กำหนด NFR ใช้ checklist และการติดตามไปยังเป้าหมายทางธุรกิจ การตรวจสอบความสมบูรณ์โดยอิสระมีประโยชน์ (QA/review)<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **ความชัดเจน (Unambiguity)** — การตีความในลักษณะเดียวเท่านั้น ช่วยด้วย glossary, template ในรูปแบบ «ระบบ **ต้องทำ A เมื่อ B หาก C**», ตัวอย่าง ไดอะแกรมมีคำอธิบาย การตรวจสอบ — หลักการ **«สี่ตา»**<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **ความสอดคล้อง (Consistency)** — ข้อกำหนดไม่ขัดแย้งกันเองและกับข้อจำกัดภายนอก ใช้การจัดโครงสร้าง ตารางแอตทริบิวต์รวม การ review ของทีม ตรวจสอบกฎระเบียบ/มาตรฐาน<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **ความสามารถในการตรวจสอบ/ทดสอบ (Verifiability)** — การบรรลุเป้าหมายได้รับการยืนยันโดยการทดสอบ/การสาธิต/การวิเคราะห์ การกำหนดที่ตรวจสอบไม่ได้จะถูกแทนที่ด้วยเกณฑ์ที่วัดได้ สำหรับ NFR จะกำหนดเมตริกและกำหนดเกณฑ์การยอมรับล่วงหน้า<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_SEH-63)</sup>

<!-- -->

- **ความสามารถในการปรับเปลี่ยนและการติดตาม (Modifiability & Traceability)** — ID ที่ไม่ซ้ำกัน โครงสร้างที่มีตรรกะ («หนึ่งความคิด — หนึ่งย่อหน้า»), ไม่มีการซ้ำซ้อน รักษาความเชื่อมโยง «ข้อกำหนด ↔ แหล่งที่มา/เป้าหมาย/การออกแบบ/การทดสอบ» จัดการ**เมทริกซ์การติดตาม (RTM)**<sup>[\[64\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **การจัดอันดับและจัดลำดับความสำคัญ** — คุณภาพของชุดข้อกำหนด ใช้เทคนิค **MoSCoW** และ MCDM (เช่น **AHP**) การจัดลำดับความสำคัญร่วมกับฝ่ายธุรกิจมีผลต่อการวางแผนและความเสี่ยง<sup>[\[65\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-Saaty-66)</sup>

**เมตริกคุณภาพข้อกำหนด** (ตัวอย่าง):<sup>[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

- ความหนาแน่นของ defect ในข้อกำหนด (ข้อสังเกตต่อ 100 ข้อกำหนด)
- จำนวนการเปลี่ยนแปลงหลังจากการกำหนด baseline
- เมตริก coverage: สัดส่วนข้อกำหนดที่มีการทดสอบ สัดส่วนข้อกำหนดที่ติดตามไปยังเป้าหมายทางธุรกิจ
- ความเสถียรของข้อกำหนด (อัตราส่วนที่เพิ่ม/ลบต่อจำนวนรวมในช่วงเวลา)
- ขนาด/ความซับซ้อนของข้อกำหนด (จำนวนข้อกำหนดเฉลี่ยใน use case, ความลึกของการแยกย่อย)
- ความพึงพอใจของผู้มีส่วนได้เสีย (การสำรวจ)

ในกระบวนการที่เป็นผู้ใหญ่ (เช่น **CMMI** ระดับ 3+) จะมีกฎระเบียบคุณภาพข้อกำหนด: การตรวจสอบอย่างเป็นทางการ, การตรวจสอบความสอดคล้องกับ template, การรวบรวม/วิเคราะห์เมตริก<sup>[\[67\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SEI_CMMI-67)</sup> ในโดเมนที่สำคัญ (การบิน, อวกาศ ฯลฯ) จะใช้ **วิธีการที่เป็นทางการ** เพื่อเพิ่มความน่าเชื่อถือ<sup>[\[68\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_FM-68)</sup>

## ข้อผิดพลาดทั่วไป

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

ปัญหาทั่วไป ผลที่ตามมา และวิธีการป้องกัน

- **ข้อกำหนดที่ไม่สมบูรณ์และขาดหายไป** บทบาทที่มีสิทธิ์พิเศษ กรณีขอบเขต และ NFR ถูกมองข้าม *ผลที่ตามมา:* การแก้ไขสถาปัตยกรรมและการเลื่อนการเปิดตัว วิธีป้องกัน: checklist, การระดมความคิด «what if...», การมีส่วนร่วมของนักทดสอบในช่วงต้น, การติดตามไปยังเป้าหมายทางธุรกิจ<sup>[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **การกำหนดที่ไม่ชัดเจนและคลุมเครือ** *ผลที่ตามมา:* นักพัฒนาใช้งาน «ผิดสิ่ง» ลูกค้าไม่พอใจ วิธีป้องกัน: เกณฑ์ที่วัดได้ glossary, template «A เมื่อ B หาก C», peer‑review<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SEI_Pitfalls-69)</sup>

<!-- -->

- **ข้อกำหนดที่ขัดแย้งกัน** *ผลที่ตามมา:* ความล่าช้าในการชี้แจง การทำงานซ้ำในการบูรณาการ วิธีป้องกัน: การจัดโครงสร้าง การตรวจสอบกฎธุรกิจ/กฎระเบียบ, การแก้ไขความขัดแย้งในการ session, การตรวจสอบความสอดคล้องใน review<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **Gold‑plating (อาการ «แผ่นทอง»)** *ผลที่ตามมา:* การเพิ่มขนาด ความซับซ้อน จุดล้มเหลวใหม่ วิธีป้องกัน: เชื่อมโยงข้อกำหนดแต่ละข้อกับเป้าหมาย/เมตริก ใน Agile — ไม่รวมสิ่งที่ไม่จำเป็นใน backlog กำหนด scope ดู YAGNI

<!-- -->

- **รายละเอียดมากเกินไปในที่ที่ไม่จำเป็น** วิธีป้องกัน: แยก *อะไร/ทำไม* (ข้อกำหนด) ออกจาก *อย่างไร* (การออกแบบ/การนำไปใช้งาน) ใช้ *design‑free requirements* เมื่อเหมาะสม<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **การละเมิดการจัดการข้อกำหนด** *ผลที่ตามมา:* ความสับสนในเวอร์ชัน การใช้งาน «ผิดสิ่ง» วิธีป้องกัน: แหล่งความจริงเดียวใน ALM, ประวัติและสถานะ, RTM และ change impact analysis การจัดการการเปลี่ยนแปลงผ่าน CCB<sup>[\[64\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **การขาดการมีส่วนร่วมของผู้ใช้** วิธีป้องกัน: การสัมภาษณ์ การสังเกต ต้นแบบ การแสดงผลสม่ำเสมอ การตรวจสอบกับผู้มีส่วนได้เสียอย่างชัดเจน<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **«อัมพาตการวิเคราะห์» ที่ยาวนานเกินไป** วิธีป้องกัน: เขตความเพียงพอ การวนซ้ำและการ timeboxing การเปิดตัว MVP/increment และการปรับตามข้อมูลป้อนกลับ<sup>[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

<!-- -->

- **การละเลยข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน** วิธีป้องกัน: ระบุ NFR (เช่น FURPS+) กำหนดเกณฑ์ที่วัดได้ รวมไว้ในแผนการทดสอบและการตัดสินใจด้านสถาปัตยกรรม<sup>[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)</sup>

<!-- -->

- **ข้อผิดพลาดในการสื่อสารและ «ปัจจัยมนุษย์»** วิธีแก้ไข: พัฒนาการสัมภาษณ์และการอำนวยความสะดวก รักษาความเป็นกลาง บันทึกการตัดสินใจและแหล่งที่มาของข้อกำหนด (การติดตามไปยังเป้าหมาย)<sup>[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

ปัญหาส่วนใหญ่สรุปได้เป็นคุณภาพของการกำหนด ความสมบูรณ์ และความสามารถในการจัดการข้อกำหนด การใช้มาตรฐาน ISO/IEC/IEEE 29148 และแนวปฏิบัติ SWEBOK (ความสามารถในการตรวจสอบ การติดตาม การวนซ้ำ) ช่วยลดความเสี่ยงของการเลื่อนกำหนดเวลาและการทำงานซ้ำอย่างมีนัยสำคัญ<sup>[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-SWEBOK-1)</sup>

## ข้อจำกัด

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

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

## ผลกระทบของเทคโนโลยีสมัยใหม่ต่อการวิเคราะห์ระบบในด้าน IT

การวิเคราะห์ระบบใน IT มีการพัฒนาอย่างต่อเนื่องภายใต้อิทธิพลของนวัตกรรมทางเทคโนโลยี นักวิเคราะห์ในศตวรรษที่ 21 ทำงานในสภาวะของการเติบโตอย่างระเบิดของข้อมูล การนำ AI มาใช้งานอย่างกว้างขวาง วงจรการพัฒนาที่รวดเร็ว และความสนใจที่เพิ่มขึ้นต่อความปลอดภัย การปฏิบัติการวิเคราะห์ระบบที่ประสบความสำเร็จต้องการการเรียนรู้ความรู้ใหม่ (Data Science, ความปลอดภัยทางไซเบอร์, เทคโนโลยีคลาวด์) และความยืดหยุ่นในการใช้วิธีการ

- **ข้อมูลและ AI/ML: สิ่งที่เพิ่มเข้ามาในการวิเคราะห์** สำหรับระบบที่มี AI ตั้งแต่เริ่มต้นจะมีการกำหนดเป้าหมายและบริบทการใช้งาน ข้อกำหนดสำหรับแหล่งที่มาและคุณภาพข้อมูล รวมถึงเมตริกความเชื่อถือในการตัดสินใจของโมเดล (ความน่าเชื่อถือ ความปลอดภัย ความสามารถในการอธิบาย ความเป็นส่วนตัว ความยุติธรรม) มีการวางแผนการตรวจสอบ **TEVV** (testing, evaluation, verification, validation) การตรวจสอบในการดำเนินงาน และการปิด/ถอน model อย่างปลอดภัย ขั้นตอนเหล่านี้สอดคล้องกับฟังก์ชัน **GOVERN–MAP–MEASURE–MANAGE** จากกรอบการจัดการความเสี่ยง AI ของ NIST และสะท้อนอยู่ใน SRS, สถาปัตยกรรม และแผนการตรวจสอบ/การดำเนินงาน<sup>[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)</sup>

<!-- -->

- **DevSecOps: ความปลอดภัย «ซ้าย» และตามค่าเริ่มต้น** การฝังความปลอดภัยในทุกขั้นตอนของ **CI/CD** กลายเป็นบรรทัดฐาน: การตรวจสอบอัตโนมัติ (SAST/DAST) การสแกน dependencies และ containers นโยบายการ deploy, baseline observability มีการใช้ registries ที่เชื่อถือได้สำหรับ artifacts และ images ที่มาตรฐาน «hardened» รวมถึงหลักการ Zero Trust ในการวิเคราะห์ระบบจะอธิบาย **จุดตรวจสอบ pipeline** (เงื่อนไขการผ่านขั้นตอน) ความเชื่อมโยงของข้อกำหนดกับการควบคุมความปลอดภัย และกฎการเปลี่ยนผ่านระหว่างสภาพแวดล้อม (dev/test/stage/prod) ล่วงหน้า<sup>[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DoD_DevSecOps-71)</sup>

<!-- -->

- **สิ่งที่เปลี่ยนแปลงในเอกสาร (Artifact)** ส่วนใดที่ปรากฏหรือได้รับการชี้แจงในเอกสารสำคัญเมื่อมี Big Data และ AI/ML และเมื่อทำงานตาม DevSecOps:
  - **SRS / ข้อกำหนด**: เป้าหมายและบริบทการใช้งาน AI ข้อกำหนดข้อมูล (ต้นกำเนิด คุณภาพ ข้อจำกัดทางจริยธรรมและกฎหมาย) เมตริก model (ความแม่นยำ ความน่าเชื่อถือ เวลาตอบสนอง) แผน TEVV (testing, evaluation, verification, validation) ข้อกำหนดด้านความโปร่งใส/ความสามารถในการอธิบาย และความเป็นส่วนตัว เกณฑ์การปิด/ถอน model จากการดำเนินงาน<sup>[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **สถาปัตยกรรมและการตัดสินใจ (Architecture, ADR)**: ผลลัพธ์ของการสร้างแบบจำลองภัยคุกคาม มาตรการ «ความปลอดภัยตามค่าเริ่มต้น» (การเข้ารหัส การควบคุมการเข้าถึง การจัดการ secret, หลักการสิทธิ์น้อยที่สุด) ข้อจำกัดในการใช้ข้อมูล/โมเดล รายการ ADR พร้อมการประเมินความเสี่ยงและการแลกเปลี่ยน<sup>[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **แผนการตรวจสอบและยืนยัน (V&V / TEVV)**: สถานการณ์ทดสอบ models และข้อมูล เกณฑ์การยอมรับสำหรับเมตริกคุณภาพ การตรวจสอบ data/model drift ขั้นตอนการประเมินซ้ำและการยืนยันซ้ำเป็นระยะ<sup>[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **นโยบาย CI/CD และ «ประตู» pipeline**: การตรวจสอบอัตโนมัติ SAST/DAST, SCA (dependencies), การสแกน container การลงนามและเก็บ artifacts ใน trusted registries กฎการเลื่อนระหว่างสภาพแวดล้อม (dev/test/stage/prod) และเงื่อนไขการบล็อก build เมื่อการตรวจสอบล้มเหลว ข้อกำหนด observability ตามค่าเริ่มต้น<sup>[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **แผนการจัดการข้อมูลและโมเดล**: catalog แหล่งที่มาและ lineage เกณฑ์คุณภาพและความพร้อมใช้งานของข้อมูล เวอร์ชันของ datasets/models ตารางการ (ฝึก)อบรมและการควบคุม bias นโยบายการเข้าถึงและการจัดเก็บ แผนการปิดใช้งาน model อย่างปลอดภัยและการลบข้อมูลหากจำเป็น<sup>[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)</sup>
  - **การดำเนินงานและ observability (Ops/Runbook)**: เมตริกความเชื่อถือ AI และ SLO การตรวจสอบและการบันทึก การแจ้งเตือนการเสื่อมประสิทธิภาพ/ความผิดปกติ แผนการตอบสนองต่อเหตุการณ์ fallback/kill‑switch สำหรับคอมโพเนนต์ AI ข้อกำหนดการรายงานและการวิเคราะห์หลังเหตุการณ์<sup>[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DoD_DevSecOps-71)</sup>
  - **การติดตาม** (end‑to‑end): การเชื่อมโยงที่ชัดเจน «**ข้อกำหนด ↔ การควบคุม/การตรวจสอบใน pipeline**» และ «**ข้อกำหนด ↔ การทดสอบ/การตรวจสอบในการดำเนินงาน**» เพื่อให้สามารถพิสูจน์ความปลอดภัยและคุณภาพตลอดวงจรชีวิต<sup>[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)</sup>
- **บทบาทของนักวิเคราะห์ระบบ**
  - จัดการบริบทและความเสี่ยงของ AI (ผู้กระทำ สถานการณ์การใช้งาน ข้อสันนิษฐานและข้อจำกัดของข้อมูล)
  - รับประกันการติดตาม «**ข้อกำหนด ↔ การควบคุมความปลอดภัยใน pipeline**»
  - กำหนดข้อกำหนดที่ไม่ใช่เชิงฟังก์ชันที่ตรวจสอบได้ (ความปลอดภัย ความโปร่งใส การสังเกตการณ์) ตลอดวงจรชีวิตของระบบ<sup>[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-DoD_DevSecOps-71)</sup>

## ความแตกต่างจากการวิเคราะห์ระบบแบบดั้งเดิม

คำว่า «การวิเคราะห์ระบบ» มีความหมายกว้างกว่าการพัฒนาซอฟต์แวร์ในเชิงประวัติศาสตร์ การวิเคราะห์ระบบแบบดั้งเดิม — แนวทางในการแก้ปัญหาแบบสหวิทยาการที่ซับซ้อน (สังคม เศรษฐกิจ การจัดการ) โดยอาศัยการคิดเชิงระบบและวิธีการเชิงปริมาณ มักใช้เพื่อสนับสนุนการตัดสินใจด้านการจัดการ ใน IT การวิเคราะห์ระบบหมายถึงวินัยประยุกต์ในด้านวิศวกรรมซอฟต์แวร์ที่มุ่งเน้นการสร้างระบบสารสนเทศ

ด้านล่างนี้คือความแตกต่างที่สำคัญ

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

<!-- -->

- **พื้นฐานระเบียบวิธี** สำนักแบบดั้งเดิมอาศัยการคิดเชิงระบบและมักใช้คณิตศาสตร์ แนวทางแข็ง (hard systems) — การกำหนดปัญหาอย่างเป็นทางการ เกณฑ์เชิงปริมาณ การเพิ่มประสิทธิภาพ (เช่น ใน operations research) ระเบียบวิธีอ่อน (soft systems) ยอมรับความหลากหลายของมุมมอง ตัวอย่างคือ *Soft Systems Methodology (SSM)* ที่ผ่านการอภิปรายและแบบจำลองเชิงแนวคิดจะประสานการเปลี่ยนแปลงที่ต้องการ ใน IT พื้นฐานคือวินัยวิศวกรรม: วิศวกรรมข้อกำหนด การออกแบบซอฟต์แวร์ เฟรมเวิร์กสถาปัตยกรรม มีการใช้กระบวนการมาตรฐาน (ISO/IEC/IEEE 15288, 12207, 29148) สัญกรณ์ UML/SysML และแนวปฏิบัติการจัดการการเปลี่ยนแปลง

<!-- -->

- **บทบาทและ Artifact** ในการวิเคราะห์แบบดั้งเดิม บทบาท «นักวิเคราะห์ระบบ» มักไม่เป็นทางการ ผลลัพธ์คือรายงานการวิเคราะห์ คำแนะนำ แบบจำลองทางคณิตศาสตร์ สถานการณ์ «what‑if» ใน IT บทบาทนักวิเคราะห์ (หรือนักวิเคราะห์ธุรกิจ) ถูกกำหนดอย่างเป็นทางการ มีการออกข้อกำหนด แบบจำลองระบบ (UML, ER) ข้อกำหนดอินเทอร์เฟซ, user stories และ backlog — Artifact ที่นักพัฒนาและนักทดสอบใช้โดยตรง

<!-- -->

- **วงจรชีวิตและกระบวนการ** การวิเคราะห์แบบดั้งเดิมไม่มีเทมเพลตเดียว: ขั้นตอนขึ้นอยู่กับปัญหา (ใน SSM — จากการศึกษาสถานการณ์ถึงการนำการเปลี่ยนแปลงไปใช้งาน) ใน IT มีวงจร SDLC มาตรฐาน: ในโมเดล Waterfall มีระยะการวิเคราะห์ข้อกำหนดแยกต่างหาก ในแนวทางแบบ iterative และ Agile การวิเคราะห์เป็นกิจกรรมถาวรของทุก sprint แนวปฏิบัติสมัยใหม่ (DevOps, CI/CD) ขยายขอบเขตการวิเคราะห์ไปยังการดำเนินงาน: คำนึงถึงข้อกำหนดด้านการบำรุงรักษา การสังเกตการณ์ และความสามารถในการอัปเดต กล่าวอีกนัยหนึ่ง การวิเคราะห์ระบบใน IT ถูกสร้างไว้ในวงจรชีวิตการพัฒนา ในขณะที่แบบดั้งเดิมมักดำเนินการเป็นกิจกรรมโครงการ/การให้คำปรึกษา

## นักวิเคราะห์ระบบ

**นักวิเคราะห์ระบบใน IT** — ผู้เชี่ยวชาญที่รับผิดชอบการคิดเชิงระบบในการออกแบบและพัฒนาระบบสารสนเทศ: การกำหนดและตรวจสอบข้อกำหนด การสร้างแบบจำลอง (UML/BPMN) การประสานการตัดสินใจด้านสถาปัตยกรรม และการรับประกันการบูรณาการ บทบาทและข้อกำหนดคุณสมบัติในสหพันธรัฐรัสเซียถูกกำหนดไว้ในมาตรฐานวิชาชีพและ FSES

**เป้าหมายหลักของประเภทกิจกรรมวิชาชีพ:** การรับประกันความสอดคล้องของบริการ IT ระบบอัตโนมัติ ระบบสารสนเทศอัตโนมัติ ระบบการจัดการอัตโนมัติ ผลิตภัณฑ์ซอฟต์แวร์ ผลิตภัณฑ์ข้อมูล หรือเครื่องมือ (ต่อไปนี้เรียกว่า ระบบ) กับสภาพแวดล้อม ข้อกำหนดและข้อจำกัดเริ่มต้น เป้าหมายของการทำให้เป็นระบบอัตโนมัติและกิจกรรมที่เป็นระบบอัตโนมัติ โดยการพัฒนาและถ่ายทอดการตัดสินใจในการออกแบบที่มีคุณภาพและเชื่อมโยงกันไปยังผู้มีส่วนได้เสียในระหว่างการเปิดตัวและประสานการทำงานของผู้ปฏิบัติงานแต่ละรายตลอดวงจรชีวิตของระบบ (*มาตรฐานวิชาชีพ «นักวิเคราะห์ระบบ» (คำสั่งกระทรวงแรงงานสหพันธรัฐรัสเซียลงวันที่ 27.04.2023 № 367н*)<sup>[\[72\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_note-72)</sup>

## อภิธานศัพท์คำศัพท์สำคัญ

### แนวคิดพื้นฐานและผู้เข้าร่วม

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

### ข้อกำหนด: ประเภทและเอกสาร

- ข้อกำหนดเชิงฟังก์ชัน — อธิบายสิ่งที่ระบบต้องทำ ฟังก์ชันและพฤติกรรมของมัน
- ข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน — อธิบายแอตทริบิวต์คุณภาพของระบบ (ความน่าเชื่อถือ ประสิทธิภาพ ความปลอดภัย ความสะดวกในการใช้งาน ความสามารถในการปรับขนาด ฯลฯ)
- ข้อกำหนดเบื้องต้น (Primary) — เอกสารที่มีชุดข้อกำหนดเบื้องต้นที่รวบรวมในขั้นตอนแรกของโครงการ
- SRS (Software Requirements Specification) — เอกสารมาตรฐานที่อธิบายข้อกำหนดซอฟต์แวร์โดยละเอียดตามมาตรฐานสากล (เช่น ISO/IEC/IEEE 29148)
- URS (User Requirements Specification) — เอกสารที่อธิบายข้อกำหนดผู้ใช้ต่อระบบในแง่ของกระบวนการทางธุรกิจและความคาดหวังของผู้ใช้ปลายทาง

<!-- -->

- ข้อกำหนดที่มีนัยสำคัญทางสถาปัตยกรรม (ASR) — ข้อกำหนดที่มีผลกระทบอย่างมีนัยสำคัญต่อการตัดสินใจและการแลกเปลี่ยนด้านสถาปัตยกรรม
- ข้อกำหนดข้ามฟังก์ชัน (CFR) — คำพ้องความหมายของข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน เน้นลักษณะข้ามสายของมัน
- เกณฑ์การยอมรับ (Acceptance Criteria) — เงื่อนไขที่ตรวจสอบได้ที่เมื่อปฏิบัติตามแล้ว งานตามข้อกำหนดถือว่าได้รับการยอมรับ
- Definition of Ready (DoR) — ข้อตกลงเกี่ยวกับความพร้อมของรายการ backlog สำหรับการพัฒนา (ความชัดเจน การประเมิน เกณฑ์)
- Definition of Done (DoD) — ข้อตกลงเกี่ยวกับ «ความสมบูรณ์» ของงาน (โค้ด การทดสอบ เอกสาร การ deploy)
- ข้อจำกัด (Constraint) — เงื่อนไขที่เข้มงวดที่จำกัดโซลูชัน (กำหนดเวลา แพลตฟอร์ม มาตรฐาน ใบอนุญาต)
- ข้อสันนิษฐาน (Assumption) — ข้อสันนิษฐานที่ยอมรับโดยไม่มีหลักฐาน ต้องการการตรวจสอบในภายหลัง
- คุณภาพข้อกำหนด — คุณสมบัติตาม ISO 29148: ความชัดเจน ความสมบูรณ์ ความสอดคล้อง ความสามารถในการตรวจสอบ ความเป็นอะตอม

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

- การกำหนดข้อกำหนดอย่างเป็นทางการ — กระบวนการแปลงคำขอที่ไม่เป็นทางการเป็นข้อกำหนดที่ชัดเจน ตรวจสอบได้ และไม่คลุมเครือ
- การติดตามข้อกำหนด — ความสามารถในการติดตามวงจรชีวิตของข้อกำหนดจากแหล่งที่มาถึงการนำไปใช้งาน การทดสอบ และการ deploy
- Bidirectional traceability (การติดตามแบบสองทิศทาง) — ความสามารถในการติดตามความเชื่อมโยงระหว่างข้อกำหนด องค์ประกอบการออกแบบ และสถานการณ์ทดสอบทั้งในทิศทางไปข้างหน้าและย้อนกลับ
- MoSCoW — เทคนิคการจัดลำดับความสำคัญของข้อกำหนดที่จำแนกเป็น Must-have (ต้องมี), Should-have (ควรมี), Could-have (อาจมี) และ Won't-have (จะไม่มี)
- BDD (Behavior-Driven Development) — ระเบียบวิธีการพัฒนาที่การทดสอบเขียนในภาษาธรรมชาติที่มุ่งเน้นพฤติกรรมของระบบจากมุมมองผู้ใช้ (รูปแบบ Given–When–Then)

### สัญกรณ์และการสร้างแบบจำลอง

- UML (Unified Modeling Language) — ภาษาการสร้างแบบจำลองกราฟิกที่เป็นมาตรฐานสำหรับการระบุ การแสดงภาพ การสร้าง และการจัดทำเอกสารของคอมโพเนนต์ระบบซอฟต์แวร์
- SysML (Systems Modeling Language) — ส่วนขยายของ UML สำหรับวิศวกรรมระบบที่รองรับการสร้างแบบจำลองด้านต่าง ๆ ของระบบที่ซับซ้อน รวมถึงข้อกำหนด พฤติกรรม โครงสร้าง และพารามิเตอร์
- BPMN (Business Process Model and Notation) — มาตรฐานสัญกรณ์กราฟิกสำหรับการอธิบายกระบวนการทางธุรกิจที่ช่วยให้สามารถแสดงภาพกระแสงาน เหตุการณ์ เกตเวย์ และ pool
- MBSE (Model-Based Systems Engineering) — แนวทางวิศวกรรมระบบที่แบบจำลองเป็น Artifact หลักในทุกขั้นตอนของวงจรชีวิตระบบ ตั้งแต่ข้อกำหนดจนถึงการทดสอบ
- ArchiMate — สัญกรณ์สถาปัตยกรรมองค์กร (ธุรกิจ แอปพลิเคชัน เทคโนโลยี) และความสัมพันธ์ของมัน
- DMN (Decision Model and Notation) — การสร้างแบบจำลองการตัดสินใจทางธุรกิจและตารางกฎ
- DFD (Data Flow Diagram) — ไดอะแกรมกระแสข้อมูล (บริบท ระดับการแยกย่อย)
- ERD (Entity-Relationship Diagram) — แบบจำลองโดเมนที่มี entity, ความสัมพันธ์ และแอตทริบิวต์
- CRUD-matrix — ความสอดคล้องของการดำเนินการ Create/Read/Update/Delete กับ entity และบทบาท/ฟังก์ชัน

### สไตล์สถาปัตยกรรมและการประเมินโซลูชัน

- สถาปัตยกรรมแบบ Monolithic — แนวทางสถาปัตยกรรมที่ระบบทั้งหมดพัฒนาเป็นโมดูลเดียวที่แบ่งแยกไม่ได้
- สถาปัตยกรรมแบบ Microservices — แนวทางสถาปัตยกรรมที่ระบบถูกสร้างเป็นชุดของบริการขนาดเล็กที่ deploy และปรับขนาดได้อย่างอิสระ
- Trade-off (การแลกเปลี่ยน) — การเลือกระหว่างลักษณะหรือโซลูชันที่ไม่เข้ากันหรือขัดแย้งกัน ที่การปรับปรุงลักษณะหนึ่งเกิดขึ้นโดยแลกกับการเสื่อมลักษณะอื่น
- ATAM (Architecture Tradeoff Analysis Method) — วิธีการประเมินสถาปัตยกรรมซอฟต์แวร์ที่ใช้วิเคราะห์การแลกเปลี่ยนระหว่างแอตทริบิวต์คุณภาพ (เช่น ประสิทธิภาพ ความสามารถในการปรับขนาด)

### สถาปัตยกรรมองค์กรและเฟรมเวิร์ก

- TOGAF (The Open Group Architecture Framework) — หนึ่งในเฟรมเวิร์กสถาปัตยกรรมองค์กรที่แพร่หลายที่สุด ประกอบด้วยวิธีการ ADM (Architecture Development Method) สำหรับการพัฒนาและจัดการสถาปัตยกรรม
- Zachman Framework — ออนโทโลยีของ Artifact สถาปัตยกรรมองค์กร นำเสนอเป็นเมทริกซ์ 6×6 ที่จำแนกด้านต่าง ๆ ของสถาปัตยกรรมจากมุมมองต่าง ๆ

### แนวทางการวิเคราะห์และกระบวนการพัฒนา

- แนวทางแข็ง (Hard Systems) — ระเบียบวิธีการวิเคราะห์ระบบที่สันนิษฐานเป้าหมายและข้อกำหนดที่กำหนดได้อย่างเป็นทางการล่วงหน้า การแยกย่อยและการออกแบบ «จากบนลงล่าง» มีประสิทธิภาพสำหรับงานที่กำหนดไว้อย่างชัดเจน
- แนวทางอ่อน (Soft Systems) — ระเบียบวิธีการวิเคราะห์ระบบที่ใช้เมื่อเป้าหมายไม่ชัดเจนและมีหลายมุมมองของผู้มีส่วนได้เสีย มุ่งเน้นการประสานความเข้าใจปัญหาและการเปลี่ยนแปลงที่ต้องการ
- SSM (Soft Systems Methodology) — ระเบียบวิธีเฉพาะของแนวทางระบบอ่อน พัฒนาโดยปีเตอร์ เช็คแลนด์ ใช้เครื่องมือเช่น rich picture, คำจำกัดความรากเหง้า และ CATWOE
- Waterfall (โมเดล Waterfall) — ระเบียบวิธีการพัฒนาซอฟต์แวร์แบบดั้งเดิมที่ขั้นตอน (การวิเคราะห์ การออกแบบ การนำไปใช้งาน การทดสอบ การนำไปใช้) ดำเนินการตามลำดับ โดยต้องทำให้ขั้นตอนก่อนหน้าเสร็จสมบูรณ์ก่อนเริ่มขั้นตอนถัดไป
- Agile — กลุ่มของระเบียบวิธีการพัฒนาซอฟต์แวร์แบบยืดหยุ่นที่มุ่งเน้นการพัฒนาแบบวนซ้ำ การปรับตัวต่อการเปลี่ยนแปลง การมีปฏิสัมพันธ์กับลูกค้า และการส่งมอบคุณค่าอย่างต่อเนื่อง

### วิธีการเลือกและข้อผิดพลาดทั่วไป

- AHP (Analytic Hierarchy Process) — วิธีการเลือกหลายเกณฑ์ที่ช่วยจัดโครงสร้างปัญหาที่ซับซ้อนและประเมินทางเลือกตามลำดับชั้นของเกณฑ์
- Gold-plating (อาการ «แผ่นทอง») — ข้อผิดพลาดในการวิเคราะห์ระบบที่ประกอบด้วยการเพิ่มฟังก์ชันที่ผู้มีส่วนได้เสียไม่ต้องการ ซึ่งนำไปสู่การเพิ่มขนาดและความซับซ้อนของโครงการ

## ลิงก์

- ISO/IEC/IEEE 15288:2023 — System life cycle processes
- ISO/IEC/IEEE 12207:2017 — Software life cycle processes
- ISO/IEC/IEEE 29148:2018 — Requirements engineering
- ISO/IEC/IEEE 42010:2022 — Architecture description
- ISO/IEC 25010:2023 — Product quality model (SQuaRE)
- ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
- ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
- ISO/IEC/IEEE 42020:2019 — Architecture processes
- ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
- IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation

<!-- -->

- UML 2.5.1 — OMG Specification
- BPMN 2.0.2 — OMG Specification
- SysML v1.7 — OMG Specification

<!-- -->

- TOGAF Standard, 10th Edition — The Open Group
- ArchiMate 3.2 — The Open Group

<!-- -->

- SEI ATAM — Architecture Tradeoff Analysis Method
- NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)

<!-- -->

- SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
- Guide to the Systems Engineering Body of Knowledge (SEBoK)

<!-- -->

- BABOK Guide v3 — IIBA
- Google SRE Books — Official site
- Microsoft Azure Well-Architected Framework — Official docs
- การวิเคราะห์ระบบอย่างเข้าใจง่าย YouTube
- การวิเคราะห์ระบบใน IT อย่างเข้าใจง่าย YouTube

## วรรณกรรม

- ISO/IEC/IEEE (2023). *15288: System Life Cycle Processes*.
- INCOSE (2023). *INCOSE Systems Engineering Handbook*, ฉบับที่ 5
- ISO/IEC/IEEE (2018). *29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering*.
- IIBA (2015). *A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3*.
- The Open Group (2022). *The TOGAF® Standard, 10th Edition*. เวอร์ชันฟรีอย่างเป็นทางการ
- OMG (2017). *Unified Modeling Language (UML®) 2.5.1 Specification*. PDF.
- OMG (2014). *Business Process Model and Notation (BPMN™) 2.0.2 Specification*. PDF.
- OMG (2024). *Systems Modeling Language (SysML®) 1.7 Specification*. PDF.
- The Open Group (2022). *ArchiMate® 3.2 Specification*. ดาวน์โหลดฟรีอย่างเป็นทางการ (ตามใบอนุญาต)
- Bass, L.; Clements, P.; Kazman, R. (2021). *Software Architecture in Practice*, ฉบับที่ 4
- Wiegers, K.; Beatty, J. (2013). *Software Requirements*, ฉบับที่ 3
- Rozanski, N.; Woods, E. (2012). *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*, ฉบับที่ 2
- Meadows, D. (2008). *Thinking in Systems: A Primer*.
- Senge, P. M. (2006). *The Fifth Discipline: The Art & Practice of the Learning Organization* (rev. ed.).
- Blanchard, B. S.; Fabrycky, W. J. (2010). *Systems Engineering and Analysis*, ฉบับที่ 5
- Robertson, J.; Robertson, S. (2012). *Mastering the Requirements Process: Getting Requirements Right*, ฉบับที่ 3
- van Lamsweerde, A. (2009). *Requirements Engineering: From System Goals to UML Models to Software Specifications*.
- Hull, E.; Jackson, K.; Dick, J. (2017). *Requirements Engineering*, ฉบับที่ 4
- Kendall, K. E.; Kendall, J. E. (2023). *Systems Analysis and Design*, ฉบับที่ 11
- Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). *Systems Analysis and Design: An Object-Oriented Approach with UML*, ฉบับที่ 8
- Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). *Systems Analysis and Design in a Changing World*, ฉบับที่ 7
- Fowler, M. (2003). *UML Distilled: A Brief Guide to the Standard Object Modeling Language*, ฉบับที่ 3
- Delligatti, L. (2013). *SysML Distilled: A Brief Guide to the Systems Modeling Language*.
- Silver, B. (2011). *BPMN Method and Style*, ฉบับที่ 2
- Lankhorst, M. et al. (2017). *Enterprise Architecture at Work: Modelling, Communication and Analysis*, ฉบับที่ 4
- Richards, M.; Ford, N. (2020). *Fundamentals of Software Architecture*.
- Fairbanks, G. (2010). *Just Enough Software Architecture: A Risk-Driven Approach*.
- Keeling, M. (2017). *Design It!: From Programmer to Software Architect*.
- Evans, E. (2003). *Domain-Driven Design: Tackling Complexity in the Heart of Software*.
- Vernon, V. (2013). *Implementing Domain-Driven Design*.
- Brandolini, A. (2018). *Introducing EventStorming: An Act of Deliberate Collective Learning*.
- Simsion, G.; Witt, G. (2015). *Data Modeling Essentials*, ฉบับที่ 4
- Silverston, L. (2008–2009). *The Data Model Resource Book*, Vols. 1–3 (rev. eds.).
- Keeney, R. L.; Raiffa, H. (1993). *Decisions with Multiple Objectives: Preferences and Value Trade-Offs*, ฉบับที่ 2
- Saaty, T. L. (1980). *The Analytic Hierarchy Process*; (1990) *Decision Making for Leaders*.

## หมายเหตุ

1.  <span id="cite_note-SWEBOK-1">↑ <sup>[1.00](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-0)</sup> <sup>[1.01](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-1)</sup> <sup>[1.02](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-2)</sup> <sup>[1.03](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-3)</sup> <sup>[1.04](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-4)</sup> <sup>[1.05](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-5)</sup> <sup>[1.06](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-6)</sup> <sup>[1.07](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-7)</sup> <sup>[1.08](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-8)</sup> <sup>[1.09](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-9)</sup> <sup>[1.10](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-10)</sup> <sup>[1.11](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-11)</sup> <sup>[1.12](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SWEBOK_1-12)</sup> IEEE Computer Society (2025). *Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a*. Requirements Engineering: elicitation techniques. <a href="https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf" class="external free" rel="nofollow">https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf</a></span>
2.  <span id="cite_note-Zowghi-2">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-Zowghi_2-0) Zowghi, D.; Coulin, C. (2005/2014). *Requirements Elicitation: A Survey of Techniques, Approaches, and Tools*. <a href="https://eecs481.org/readings/requirements.pdf" class="external free" rel="nofollow">https://eecs481.org/readings/requirements.pdf</a></span>
3.  <span id="cite_note-ISO29148-3">↑ <sup>[3.00](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-0)</sup> <sup>[3.01](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-1)</sup> <sup>[3.02](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-2)</sup> <sup>[3.03](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-3)</sup> <sup>[3.04](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-4)</sup> <sup>[3.05](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-5)</sup> <sup>[3.06](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-6)</sup> <sup>[3.07](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-7)</sup> <sup>[3.08](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-8)</sup> <sup>[3.09](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-9)</sup> <sup>[3.10](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-10)</sup> <sup>[3.11](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-11)</sup> <sup>[3.12](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO29148_3-12)</sup> ISO/IEC/IEEE 29148 (2011/2018). *Systems and software engineering — Requirements engineering*. *ISO* overview page: «Defines the construct of a good requirement…». <a href="https://www.iso.org/standard/45171.html" class="external free" rel="nofollow">https://www.iso.org/standard/45171.html</a></span>
4.  <span id="cite_note-NASA7123-4">↑ <sup>[4.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA7123_4-0)</sup> <sup>[4.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA7123_4-1)</sup> <sup>[4.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA7123_4-2)</sup> NASA (2020). *NPR 7123.1C — Systems Engineering Processes and Requirements*. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». <a href="https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&amp;page_name=all" class="external free" rel="nofollow">https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&amp;page_name=all</a></span>
5.  <span id="cite_note-5">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-5) GMU (George Mason University). *IEEE Software Requirements Specification Template (SRS)*. <a href="https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc" class="external free" rel="nofollow">https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc</a></span>
6.  <span id="cite_note-6">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-6) Westfall, L. (Cal Poly, .edu). *The What, Why, Who, When and How of Software Requirements* (упоминает URS). <a href="https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf" class="external free" rel="nofollow">https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf</a></span>
7.  <span id="cite_note-7">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-7) Stanford University IT (.edu). *Functional Specification Document Template*. <a href="https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx" class="external free" rel="nofollow">https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx</a></span>
8.  <span id="cite_note-8">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-8) Penn State (.edu). *Elements of a Use Case Diagram*. <a href="https://www.e-education.psu.edu/geog468/l8_p4.html" class="external free" rel="nofollow">https://www.e-education.psu.edu/geog468/l8_p4.html</a></span>
9.  <span id="cite_note-9">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-9) UC Irvine (.edu). *Data Flow Diagram*. <a href="https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/" class="external free" rel="nofollow">https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/</a></span>
10. <span id="cite_note-ISO42010-10">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ISO42010_10-0) ISO/IEC/IEEE 42010 (2011/2022). *Architecture description* — требования к описанию архитектуры и точкам зрения. <a href="https://standards.ieee.org/ieee/42010/5334/" class="external free" rel="nofollow">https://standards.ieee.org/ieee/42010/5334/</a></span>
11. <span id="cite_note-11">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-11) Cornell University (.edu). *CS 5150 — Feasibility Studies*. <a href="https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf" class="external free" rel="nofollow">https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf</a></span>
12. <span id="cite_note-ATAM-12">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-ATAM_12-0) Carnegie Mellon SEI. *Architecture Tradeoff Analysis Method (ATAM) — overview*. <a href="https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/" class="external free" rel="nofollow">https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/</a></span>
13. <span id="cite_note-13">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-13) Microsoft Azure Architecture Center. *Architecture styles: microservices — benefits & complexity*. <a href="https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/</a></span>
14. <span id="cite_note-14">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-14) Google Cloud. *What Is Microservices Architecture? — Monolithic vs. microservices (обзор)*. <a href="https://cloud.google.com/learn/what-is-microservices-architecture" class="external free" rel="nofollow">https://cloud.google.com/learn/what-is-microservices-architecture</a></span>
15. <span id="cite_note-15">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-15) NASA (2023). *Requirements Management — Traceability, Bidirectional traceability (definitions)*. <a href="https://www.nasa.gov/reference/6-2-requirements-management/" class="external free" rel="nofollow">https://www.nasa.gov/reference/6-2-requirements-management/</a></span>
16. <span id="cite_note-16">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-16) McKinsey (2012). *Delivering large-scale IT projects on time, on budget, and on value*. <a href="https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value" class="external free" rel="nofollow">https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value</a></span>
17. <span id="cite_note-17">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-17) University of Cambridge, IfM. *Soft Systems Methodology (SSM) — CATWOE, 3Es*. <a href="https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/" class="external free" rel="nofollow">https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/</a></span>
18. <span id="cite_note-18">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-18) Lancaster University (ePrints). *Soft Systems Methodology and root definitions*. <a href="https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf" class="external free" rel="nofollow">https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf</a></span>
19. <span id="cite_note-19">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-19) University of Cambridge, IfM. *Soft Systems Methodology (SSM)*. <a href="https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/" class="external free" rel="nofollow">https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/</a></span>
20. <span id="cite_note-20">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-20) UCL Discovery (.ac.uk). M. Haklay. *Soft System Methodology (SSM)*. <a href="https://discovery.ucl.ac.uk/1296/1/paper13.pdf" class="external free" rel="nofollow">https://discovery.ucl.ac.uk/1296/1/paper13.pdf</a></span>
21. <span id="cite_note-21">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-21) IEEE Std 1320.1-1998 (R2004). *Functional Modeling Language — Syntax and Semantics for IDEF0*. <a href="https://standards.ieee.org/ieee/1320.1/2003/" class="external free" rel="nofollow">https://standards.ieee.org/ieee/1320.1/2003/</a></span>
22. <span id="cite_note-22">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-22) ISO/IEC/IEEE 31320-1:2012. *IDEF0: Function Modeling*. <a href="https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf" class="external free" rel="nofollow">https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf</a></span>
23. <span id="cite_note-23">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-23) University of Washington (.edu). *UML Class Diagrams / UML overview (course material)*. <a href="https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf" class="external free" rel="nofollow">https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf</a></span>
24. <span id="cite_note-24">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-24) JHU/APL (.edu). *Modeling with SysML — tutorial*. <a href="https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf" class="external free" rel="nofollow">https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf</a></span>
25. <span id="cite_note-25">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-25) MIT OCW (.edu). O. de Weck. *Introduction to Systems Modeling Languages (incl. SysML, MBSE)*. <a href="https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf" class="external free" rel="nofollow">https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf</a></span>
26. <span id="cite_note-26">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-26) IBM. *What is Business Process Modeling and Notation (BPMN)?*. <a href="https://www.ibm.com/think/topics/bpmn" class="external free" rel="nofollow">https://www.ibm.com/think/topics/bpmn</a></span>
27. <span id="cite_note-27">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-27) IBM Docs. *Business Process Modeling Notation (BPMN) model*. <a href="https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model" class="external free" rel="nofollow">https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model</a></span>
28. <span id="cite_note-28">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-28) IEEE/ISO/IEC 29148:2018. *Systems and software engineering — Requirements engineering (overview)*. <a href="https://standards.ieee.org/ieee/29148/6937/" class="external free" rel="nofollow">https://standards.ieee.org/ieee/29148/6937/</a></span>
29. <span id="cite_note-29">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-29) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. <a href="https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/" class="external free" rel="nofollow">https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/</a></span>
30. <span id="cite_note-30">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-30) T. L. Saaty. *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 1994. <a href="https://pubsonline.informs.org/doi/10.1287/inte.24.6.19" class="external free" rel="nofollow">https://pubsonline.informs.org/doi/10.1287/inte.24.6.19</a></span>
31. <span id="cite_note-31">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-31) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. <a href="https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management</a></span>
32. <span id="cite_note-32">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-32) MIT OCW (.edu). *V-Model — Fundamentals of Systems Engineering*. <a href="https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/" class="external free" rel="nofollow">https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/</a></span>
33. <span id="cite_note-33">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-33) Carnegie Mellon SEI (.edu). *Architecture Tradeoff Analysis Method (ATAM) — overview*. <a href="https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/" class="external free" rel="nofollow">https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/</a></span>
34. <span id="cite_note-AzureStyles-34">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-AzureStyles_34-0) Microsoft Azure Architecture Center. *Architecture styles*. <a href="https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/</a></span>
35. <span id="cite_note-SEI_ATAM-35">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SEI_ATAM_35-0) Kazman, R.; Klein, M.; Clements, P. *ATAM: Method for Architecture Evaluation*. CMU/SEI Technical Report, 2000. <a href="https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf" class="external free" rel="nofollow">https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf</a></span>
36. <span id="cite_note-TOGAFIntro-36">↑ <sup>[36.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-TOGAFIntro_36-0)</sup> <sup>[36.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-TOGAFIntro_36-1)</sup> <sup>[36.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-TOGAFIntro_36-2)</sup> <sup>[36.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-TOGAFIntro_36-3)</sup> The Open Group. *Introduction — The TOGAF® Standard*. <a href="https://www.togaf.org/chap01.html" class="external free" rel="nofollow">https://www.togaf.org/chap01.html</a></span>
37. <span id="cite_note-AzureEvent-37">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-AzureEvent_37-0) Microsoft Azure Architecture Center. *Event-Driven Architecture style*. <a href="https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven</a></span>
38. <span id="cite_note-38">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-38) Jonkers, H. et al. *ArchiMate® and the TOGAF® Framework*. The Open Group (white paper). <a href="https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf" class="external free" rel="nofollow">https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf</a></span>
39. <span id="cite_note-39">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-39) Estrem, W. *Building Blocks Revisited*. The Open Group (presentation). <a href="https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf" class="external free" rel="nofollow">https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf</a></span>
40. <span id="cite_note-40">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-40) The Open Group. *Architecture Principles*. <a href="https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf" class="external free" rel="nofollow">https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf</a></span>
41. <span id="cite_note-41">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-41) The Open Group. *IT Architecture Compliance*. <a href="https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm" class="external free" rel="nofollow">https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm</a></span>
42. <span id="cite_note-42">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-42) *The TOGAF® Standard, Version 9.2* (спецификация). The Open Group. <a href="https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf" class="external free" rel="nofollow">https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf</a></span>
43. <span id="cite_note-43">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-43) Engelsman, W.; van Sinderen, M. *Supporting Requirements Management in TOGAF and ArchiMate*. The Open Group (white paper). <a href="https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf" class="external free" rel="nofollow">https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf</a></span>
44. <span id="cite_note-Zachman1987-44">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-Zachman1987_44-0) Zachman, J. A. *A Framework for Information Systems Architecture*. *IBM Systems Journal*, 26(3), 276–292, 1987. <a href="https://doi.org/10.1147/sj.263.0276" class="external free" rel="nofollow">https://doi.org/10.1147/sj.263.0276</a></span>
45. <span id="cite_note-45">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-45) MIT CISR. *Classic Topics — Enterprise Architecture* (определение EA как «organizing logic for business process and IT capabilities…»). <a href="https://cisr.mit.edu/content/classic-topics-enterprise-architecture" class="external free" rel="nofollow">https://cisr.mit.edu/content/classic-topics-enterprise-architecture</a></span>
46. <span id="cite_note-46">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-46) The Open Group. *IT Architecture Compliance*. <a href="https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm" class="external free" rel="nofollow">https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm</a></span>
47. <span id="cite_note-Royce-47">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-Royce_47-0) Royce, W. W. (1970). *Managing the Development of Large Software Systems*. IEEE WESCON. Репринт (PDF): <a href="https://www.praxisframework.org/files/royce1970.pdf" class="external free" rel="nofollow">https://www.praxisframework.org/files/royce1970.pdf</a></span>
48. <span id="cite_note-DAU_SRR-48">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DAU_SRR_48-0) Defense Acquisition University. *System Requirements Review (SRR) — Acquipedia*. <a href="https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/" class="external free" rel="nofollow">https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/</a></span>
49. <span id="cite_note-NASA_CCB-49">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_CCB_49-0) NASA (2023). *Requirements Management — baseline, change control (CCB)*. <a href="https://www.nasa.gov/reference/6-2-requirements-management/" class="external free" rel="nofollow">https://www.nasa.gov/reference/6-2-requirements-management/</a></span>
50. <span id="cite_note-MS_Agile-50">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-MS_Agile_50-0) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. <a href="https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management</a></span>
51. <span id="cite_note-MS_BDD-51">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-MS_BDD_51-0) MSDN Magazine (Microsoft). *BDD Primer: Behavior‑Driven Development with SpecFlow*. <a href="https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin</a></span>
52. <span id="cite_note-MS_Trace-52">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-MS_Trace_52-0) Microsoft Learn. *End‑to‑end traceability in Azure DevOps*. <a href="https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability</a></span>
53. <span id="cite_note-SRE_SLO-53">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SRE_SLO_53-0) Google SRE. *Service Level Objectives*; *Error Budget Policy*. <a href="https://sre.google/sre-book/service-level-objectives/" class="external free" rel="nofollow">https://sre.google/sre-book/service-level-objectives/</a> ; <a href="https://sre.google/workbook/error-budget-policy/" class="external free" rel="nofollow">https://sre.google/workbook/error-budget-policy/</a></span>
54. <span id="cite_note-AzureMon-54">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-AzureMon_54-0) Microsoft Learn. *Azure Monitor — Overview*. <a href="https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview</a></span>
55. <span id="cite_note-AWS_BlueGreen-55">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-AWS_BlueGreen_55-0) AWS Whitepaper. *Blue/Green Deployments on AWS*. <a href="https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html" class="external free" rel="nofollow">https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html</a></span>
56. <span id="cite_note-Azure_Workflow-56">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-Azure_Workflow_56-0) Microsoft Learn. *Manage change — track, triage, and implement change requests*. <a href="https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change</a></span>
57. <span id="cite_note-Azure_Backlog-57">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-Azure_Backlog_57-0) Microsoft Learn (Azure Boards). *Backlogs overview — create and manage your product backlog*. <a href="https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview</a></span>
58. <span id="cite_note-MS_Test-58">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-MS_Test_58-0) Microsoft Learn (Azure Test Plans). *What is Azure Test Plans?*. <a href="https://learn.microsoft.com/en-us/azure/devops/test/overview" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/azure/devops/test/overview</a></span>
59. <span id="cite_note-MS_SpecFlow-59">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-MS_SpecFlow_59-0) MSDN Magazine. *Behavior‑Driven Design with SpecFlow*. <a href="https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow" class="external free" rel="nofollow">https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow</a></span>
60. <span id="cite_note-IBM_MTTR-60">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-IBM_MTTR_60-0) IBM. *MTTR vs. MTBF: What’s the difference?*. <a href="https://www.ibm.com/think/topics/mttr-vs-mtbf" class="external free" rel="nofollow">https://www.ibm.com/think/topics/mttr-vs-mtbf</a></span>
61. <span id="cite_note-GCloud_Obs-61">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-GCloud_Obs_61-0) Google Cloud. *Google Cloud Observability*. <a href="https://cloud.google.com/products/observability" class="external free" rel="nofollow">https://cloud.google.com/products/observability</a></span>
62. <span id="cite_note-IEEE830-62">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-IEEE830_62-0) IEEE Std 830‑1998. *IEEE Recommended Practice for Software Requirements Specifications* (исторический стандарт). Учебная копия (PDF): <a href="https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf" class="external free" rel="nofollow">https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf</a></span>
63. <span id="cite_note-NASA_SEH-63">↑ <sup>[63.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_SEH_63-0)</sup> <sup>[63.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_SEH_63-1)</sup> <sup>[63.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_SEH_63-2)</sup> <sup>[63.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_SEH_63-3)</sup> NASA. *Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2)*. <a href="https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf" class="external free" rel="nofollow">https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf</a></span>
64. <span id="cite_note-NASA_RM-64">↑ <sup>[64.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_RM_64-0)</sup> <sup>[64.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_RM_64-1)</sup> NASA (2023). *Requirements Management — traceability, baseline, CCB*. <a href="https://www.nasa.gov/reference/6-2-requirements-management/" class="external free" rel="nofollow">https://www.nasa.gov/reference/6-2-requirements-management/</a></span>
65. <span id="cite_note-MoSCoW-65">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-MoSCoW_65-0) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. <a href="https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/" class="external free" rel="nofollow">https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/</a></span>
66. <span id="cite_note-Saaty-66">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-Saaty_66-0) Saaty, T. L. (1994). *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 19–43. <a href="https://doi.org/10.1287/inte.24.6.19" class="external free" rel="nofollow">https://doi.org/10.1287/inte.24.6.19</a></span>
67. <span id="cite_note-SEI_CMMI-67">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SEI_CMMI_67-0) SEI / CMMI Institute. *Capability Maturity Model Integration (CMMI) — Overview*. <a href="https://www.sei.cmu.edu/cmmi/" class="external free" rel="nofollow">https://www.sei.cmu.edu/cmmi/</a></span>
68. <span id="cite_note-NASA_FM-68">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NASA_FM_68-0) NASA Langley. *What is Formal Methods?*; NASA‑GB‑002‑95 Guidebook. <a href="https://shemesh.larc.nasa.gov/fm/fm-what.html" class="external free" rel="nofollow">https://shemesh.larc.nasa.gov/fm/fm-what.html</a> ; <a href="https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf" class="external free" rel="nofollow">https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf</a></span>
69. <span id="cite_note-SEI_Pitfalls-69">↑ <sup>[69.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SEI_Pitfalls_69-0)</sup> <sup>[69.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-SEI_Pitfalls_69-1)</sup> SEI (CMU). *Common Testing Problems: Pitfalls to Prevent and Mitigate* (о типичных проблемах требований/трассируемости). <a href="https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/" class="external free" rel="nofollow">https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/</a></span>
70. <span id="cite_note-NIST_AI_RMF-70">↑ <sup>[70.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-0)</sup> <sup>[70.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-1)</sup> <sup>[70.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-2)</sup> <sup>[70.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-3)</sup> <sup>[70.4](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-4)</sup> <sup>[70.5](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-5)</sup> <sup>[70.6](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-6)</sup> <sup>[70.7](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-NIST_AI_RMF_70-7)</sup> NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. NIST AI 100‑1. <a href="https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf" class="external free" rel="nofollow">https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf</a></span>
71. <span id="cite_note-DoD_DevSecOps-71">↑ <sup>[71.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DoD_DevSecOps_71-0)</sup> <sup>[71.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DoD_DevSecOps_71-1)</sup> <sup>[71.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DoD_DevSecOps_71-2)</sup> <sup>[71.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DoD_DevSecOps_71-3)</sup> <sup>[71.4](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DoD_DevSecOps_71-4)</sup> <sup>[71.5](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-DoD_DevSecOps_71-5)</sup> U.S. DoD CIO (2021). *DoD Enterprise DevSecOps Reference Design*. <a href="https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf" class="external free" rel="nofollow">https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf</a></span>
72. <span id="cite_note-72">[↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A7%E0%B8%B4%E0%B9%80%E0%B8%84%E0%B8%A3%E0%B8%B2%E0%B8%B0%E0%B8%AB%E0%B9%8C%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B9%83%E0%B8%99%E0%B8%94%E0%B9%89%E0%B8%B2%E0%B8%99_IT#cite_ref-72) <a href="https://www.consultant.ru/document/cons_doc_LAW_448246/" class="external text" rel="nofollow">Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н)</a>.</span>