อ่านฟรีได้ 2 จาก 9 หัวข้อ22%
สารบัญ9 หัวข้อหลัก
- 1.บทนำ — ระบบสารสนเทศและผลลัพธ์ที่ต้องการ
- 2.การเก็บความต้องการ
- 3.แบบจำลองกระบวนงาน: Context, DFD และ BPMN
- 4.Kanban, XP และ DevOps
- 5.Normalization และ Anomalies
- 6.Index และการปรับประสิทธิภาพฐานข้อมูล
- 7.UX, UI และ Accessibility
- 8.Version control, Code review และ CI/CD
- 9.Incident, Problem, Change และ Maintenance
หัวข้อ 1
บทนำ — ระบบสารสนเทศและผลลัพธ์ที่ต้องการ
| องค์ประกอบ | คำถาม |
|---|---|
| People | ใครใช้ ใครตัดสิน ใครดูแล ใครได้รับผล และมีทักษะ/แรงจูงใจอะไร |
| Process | งานเริ่ม–จบอย่างไร มีข้อยกเว้น อนุมัติ และจุดคอขวดตรงไหน |
| Data | แหล่ง นิยาม คุณภาพ Owner สิทธิ อายุ และ Lineage คืออะไร |
| Technology | Application, Database, Integration, Infrastructure และอุปกรณ์ใด |
| Control | กฎหมาย Security, Privacy, Audit, Quality และ Business continuity อย่างไร |
| Outcome | ลดเวลา/ข้อผิดพลาด เพิ่มสิทธิ บริการ รายได้ หรือการตัดสินใจอะไร |
| Environment | นโยบาย คู่ค้า ระบบเดิม งบ เวลา และข้อจำกัดภายนอกอะไร |
ระบบสารสนเทศและผลลัพธ์ที่ต้องการ
- 1Data
- 2Process + Context
- 3Information
- 4Decision/Action
- 5Outcome
- 6Feedback
ข้อมูลที่ประมวลแล้วไม่กลายเป็นความรู้หรือการตัดสินใจโดยอัตโนมัติ ต้องมีบริบท ความหมาย คุณภาพ และผู้รับผิดชอบ ระบบที่ส่งมอบฟีเจอร์ครบแต่ไม่สร้าง Outcome ยังไม่ถือว่าสำเร็จ
ประเภทระบบสารสนเทศ
- TPS — จุดประสงค์: บันทึกธุรกรรมปริมาณมากให้ถูก/เร็ว; ตัวอย่าง: ขาย รับคำขอ เบิกจ่าย ลงทะเบียน
- MIS — จุดประสงค์: สรุปรายงานประจำเพื่อควบคุมงาน; ตัวอย่าง: ยอดรายเดือน งานค้าง เทียบแผน
- DSS — จุดประสงค์: ช่วยวิเคราะห์ทางเลือกกึ่งโครงสร้าง; ตัวอย่าง: What-if, Forecast, Optimization
- ESS/EIS — จุดประสงค์: ภาพรวมเชิงกลยุทธ์แก่ผู้บริหาร; ตัวอย่าง: KPI, Trend, External signal
- OAS/Collaboration — จุดประสงค์: เอกสาร สื่อสาร ประชุม และ Workflow; ตัวอย่าง: Office suite, DMS, Chat
- KMS — จุดประสงค์: รวบรวม ค้น และใช้ความรู้; ตัวอย่าง: SOP, FAQ, Lessons, Expert directory
- ERP — จุดประสงค์: บูรณาการกระบวนการ/ข้อมูลหลักหลายหน้าที่; ตัวอย่าง: การเงิน พัสดุ บุคคล ผลิต
- CRM/Case management — จุดประสงค์: จัดการความสัมพันธ์/ประวัติและสถานะเรื่อง; ตัวอย่าง: บริการลูกค้า/ประชาชน ข้อร้องเรียน
- SCM — จุดประสงค์: วางแผนและติดตามห่วงโซ่อุปทาน; ตัวอย่าง: จัดซื้อ คลัง ขนส่ง Demand
- BI/Analytics — จุดประสงค์: รวม วิเคราะห์ และสื่อสารข้อมูล; ตัวอย่าง: Warehouse, Dashboard, Data science
ระบบจริงมักผสมหลายประเภท เช่น ERP เป็น TPS ในการบันทึกและสร้าง MIS/BI ได้ การจำแนกดูวัตถุประสงค์หลัก ไม่ใช่ชื่อผลิตภัณฑ์
ความรับผิดชอบหลัก
- เข้าใจปัญหา เป้าหมาย Stakeholder และบริบทองค์กร
- สำรวจกระบวนงาน ข้อมูล ระบบเดิม และข้อจำกัด
- Elicit, Analyze, Specify, Validate และจัดลำดับ Requirement
- ทำแบบจำลอง Process, Data, Interaction และ State
- เชื่อมภาษาธุรกิจกับทีมเทคนิคโดยไม่บิดความต้องการ
- ประเมินทางเลือก Build/Buy/Reuse และ Feasibility
- กำหนด Acceptance criteria และ Traceability
- จัดการ Change, Conflict, Assumption, Risk และ Decision
- สนับสนุน Testing, UAT, Migration, Training และ Adoption
- ติดตามผลหลังใช้และเรียนรู้จาก Incident/Feedback
นักวิเคราะห์ไม่ใช่ผู้จดคำสั่งผู้ใช้ตามถ้อยคำเท่านั้น ต้องแยก Need ออกจาก Solution ที่ถูกเสนอ ตรวจผลกระทบข้ามฝ่าย และท้าทายสมมติฐานด้วยหลักฐาน
การกำหนดปัญหาและขอบเขต
- 1Business outcome
- 2Current state
- 3Gap/Pain
- 4Root cause
- 5Options
- 6Scope/Constraint
- 7Success measure
- 8Sponsor decision
- Problem — ตัวอย่าง: ผู้ขอรอเฉลี่ย 20 วันและเอกสารถูกส่งกลับ 30%
- Symptom — ตัวอย่าง: เจ้าหน้าที่ทำ OT หรือผู้ใช้โทรตามมาก
- Root cause — ตัวอย่าง: ข้อมูลซ้ำ เกณฑ์ไม่ชัด ระบบไม่เชื่อม หรือกำลังคนไม่พอ
- Solution idea — ตัวอย่าง: ซื้อแอปใหม่ ใช้ AI หรือทำ Mobile app
- Outcome — ตัวอย่าง: ลดเวลาถึง 5 วันและ First-time-right ≥ 90% โดยไม่เพิ่มความเสี่ยง
- In scope — ตัวอย่าง: คำขอ ตรวจคุณสมบัติ อนุมัติ แจ้งผล และติดตาม
- Out of scope — ตัวอย่าง: การอุทธรณ์หรือระบบชำระเงินใน Release แรก
- Constraint — ตัวอย่าง: กฎหมาย งบ วันที่ ระบบเดิม สัญญา และข้อมูลที่ใช้ได้
การนิยาม Scope ต้องระบุ Interface และ Assumption ด้วย มิฉะนั้นฝ่ายละมองขอบเขตต่างกัน Scope creep คือการเปลี่ยนขอบเขตโดยไม่ประเมิน/อนุมัติ ไม่ใช่การเปลี่ยนทุกชนิด
Stakeholder analysis
- Sponsor/Business owner — ความสนใจ: ผลลัพธ์ งบ ความเสี่ยง และการตัดสิน
- End user — ความสนใจ: งานจริง ภาระ ความง่าย ข้อยกเว้น และการเข้าถึง
- Customer/Citizen — ความสนใจ: บริการ สิทธิ ความโปร่งใส ความเป็นส่วนตัว และช่องทางช่วย
- Operations/Support — ความสนใจ: Monitor, Incident, Backup, Runbook และภาระหลังส่ง
- Security/Privacy/Legal — ความสนใจ: Threat, Control, Law, Rights, Audit และ Evidence
- Data owner/Steward — ความสนใจ: นิยาม คุณภาพ Access, Sharing และ Retention
- Developer/Test/Architecture — ความสนใจ: ความเป็นไปได้ Interface, Quality และ Maintainability
- Vendor/Partner — ความสนใจ: Contract, SLA, Dependency, IP, Exit และ Change
- Auditor/Regulator — ความสนใจ: Compliance, Traceability และหลักฐาน
- Affected non-user — ความสนใจ: ผู้ที่ผลระบบกระทบแม้ไม่ได้กดใช้งาน เช่นผู้ถูก Scoring
ใช้ Power–Interest/Influence–Impact ช่วยวาง Engagement แต่ห้ามละเลยกลุ่มอำนาจต่ำที่รับผลสูง เช่นประชาชนกลุ่มเปราะบาง ต้องมีช่องทางให้เสียงและเยียวยา
หัวข้อ 2
การเก็บความต้องการ
- Interview — เหมาะกับ: ความรู้ลึก เหตุผล และเรื่องอ่อนไหว; ข้อจำกัด: Bias/จำไม่ครบ ต้องตรวจข้าม
- Workshop/JAD — เหมาะกับ: สร้างความเข้าใจและแก้ข้อขัดแย้ง; ข้อจำกัด: คนอำนาจสูงอาจครอบงำ ต้อง Facilitate
- Observation/Shadowing — เหมาะกับ: เห็นงานจริง Workaround และ Tacit knowledge; ข้อจำกัด: ผู้ถูกสังเกตอาจเปลี่ยนพฤติกรรม
- Document/System analysis — เหมาะกับ: กฎหมาย SOP, Form, Log, Data และระบบเดิม; ข้อจำกัด: เอกสารอาจไม่ตรงงานจริง
- Survey — เหมาะกับ: ข้อมูลกว้างและวัดรูปแบบ; ข้อจำกัด: คำถาม/ตัวอย่างมี Bias และไม่ลึก
- Prototype — เหมาะกับ: Requirement ที่ผู้ใช้เห็น/โต้ตอบแล้วเข้าใจ; ข้อจำกัด: อาจถูกคิดว่าใกล้เสร็จหรือยึด UI เร็วเกิน
- Focus group — เหมาะกับ: มุมมองกลุ่ม/ความต้องการแตกต่าง; ข้อจำกัด: ไม่แทนสถิติตัวแทนประชากร
- Interface analysis — เหมาะกับ: ความต้องการระหว่างระบบ/ฝ่าย; ข้อจำกัด: ต้องได้ Contract และ Error path
- Data analytics/process mining — เหมาะกับ: เห็นปริมาณ เส้นทาง เวลา และ Deviations จาก Log; ข้อจำกัด: Log อาจไม่ครบ/ผิดและไม่มีเหตุผลมนุษย์
- Experiment/Pilot — เหมาะกับ: ทดสอบสมมติฐานและผลจริง; ข้อจำกัด: ต้องออกแบบ Ethics, Metric และกลุ่มเทียบ
ใช้หลายวิธี Triangulation เพราะสิ่งที่คนบอก สิ่งที่เอกสารกำหนด และสิ่งที่ Log แสดงอาจต่างกัน ความต่างคือข้อมูลให้วิเคราะห์ ไม่ใช่เลือกแหล่งที่ถูกใจ
ประเภทของ Requirement
- Business requirement — ตัวอย่าง: ลดเวลาพิจารณาและข้อผิดพลาดตามเป้าหมาย
- Stakeholder requirement — ตัวอย่าง: ผู้ขอติดตามสถานะและเจ้าหน้าที่เห็นงานค้าง
- Functional requirement — ตัวอย่าง: ระบบคำนวณสิทธิ ส่งคำขอ อนุมัติ และแจ้งผล
- Non-functional/Quality — ตัวอย่าง: ตอบภายใน 2 วินาที 95th percentile ภายใต้ Load ที่ระบุ
- Transition requirement — ตัวอย่าง: ย้ายข้อมูล ฝึกผู้ใช้ ใช้ Parallel run และปิดระบบเก่า
- Constraint — ตัวอย่าง: ต้องใช้มาตรฐาน/เทคโนโลยี/สถานที่ข้อมูลตามกฎ
- Business rule — ตัวอย่าง: ผู้สมัครอายุ ≥ X ณวันที่กำหนด หรือวงเงินอนุมัติ
- Data requirement — ตัวอย่าง: นิยาม ฟิลด์ คุณภาพ Retention, Lineage และสิทธิ
- Interface requirement — ตัวอย่าง: API schema, Protocol, Timeout, Error, Version และ SLA
- Compliance requirement — ตัวอย่าง: PDPA, Accessibility, Audit, Records และกฎหมายเจ้าของเรื่อง
คำว่า ‘ใช้งานง่าย ปลอดภัย รวดเร็ว รองรับจำนวนมาก’ ยังทดสอบไม่ได้ ต้องระบุผู้ใช้ งาน เกณฑ์ สภาวะ หน่วย เปอร์เซ็นไทล์/ช่วงเวลา และข้อยกเว้น
Requirement ที่ดีควร
- จำเป็นและเชื่อม Outcome/แหล่งอำนาจ
- ถูกต้องและสะท้อน Need ไม่ใช่สมมติฐาน
- ชัด ไม่กำกวม และใช้คำเดียวอย่างสม่ำเสมอ
- ครบทั้ง Happy path, Alternate, Error และ Permission
- ทำได้ภายใต้เทคโนโลยี งบ เวลา และกฎหมาย
- ทดสอบ/ยืนยันได้ด้วย Acceptance criteria
- มีลำดับความสำคัญและผู้อนุมัติ
- Trace กลับ Source/Goal และไป Design/Test/Release ได้
- Atomic เท่าที่เหมาะและไม่มี Requirement ขัดกัน
- ระบุ Assumption, Dependency และ Version
| รูปแบบ | ตัวอย่าง |
|---|---|
| User story | As a ผู้ตรวจ, I want เห็นเอกสารขาด, so that ส่งกลับครั้งเดียว |
| Given–When–Then | Given คำขอขาดไฟล์บังคับ, When ส่ง, Then ระบบระบุรายการขาดและไม่สร้างเลขรับ |
| Business rule | คำนวณวันที่โดยใช้วันทำการจากปฏิทิน Version ที่อนุมัติ |
| Performance | 95% ของคำขอค้นหาตอบ ≤2 วินาทีที่ 500 concurrent users พร้อม Dataset X |
| Security | บัญชี Admin ต้อง MFA และ Session หมดหลังไม่ใช้งาน X นาทีตาม Risk |
| Accessibility | เส้นทางหลักใช้ Keyboard และชื่อ/สถานะถูกอ่านโดย Assistive technology ตามเกณฑ์ |
การจัดลำดับและจัดการการเปลี่ยนแปลง
- MoSCoW — ใช้: Must, Should, Could, Won't this time; Must ต้องมีเหตุและ Capacity
- Value vs Effort — ใช้: เห็น Quick win/Strategic bet แต่ต้องรวม Risk/Dependency
- Cost of Delay — ใช้: ผลเสียต่อเวลาเมื่อเลื่อน
- Risk-based — ใช้: ทำสิ่งลดความไม่แน่นอน/Compliance/Security ก่อน
- Kano — ใช้: Basic, Performance, Delighter ตามความคาดหวังผู้ใช้
- WSJF — ใช้: เปรียบ Cost of delay กับ Job size ในบริบทที่ใช้
- Story mapping — ใช้: เรียง Journey/กิจกรรมแล้วตัด Release ที่สร้าง End-to-end value
การจัดลำดับและจัดการการเปลี่ยนแปลง
- 1Change request
- 2Clarify reason
- 3Impact scope/time/cost/quality/risk
- 4Options
- 5Decision authority
- 6Update baseline/backlog
- 7Communicate
- 8Trace/test
- 9Verify outcome
Agile ไม่ได้แปลว่าไม่ควบคุม Change เพียงเปลี่ยนจากเอกสาร Change request หนักทุกครั้งเป็น Backlog/การวางแผนรอบสั้นที่ยังต้องโปร่งใสและเคารพ Goal/Capacity
SRS/Specification ควรครอบคลุมตามความเหมาะสม
- Purpose, Scope, Definitions และ References
- System context, Actors และ Assumptions
- Functional requirements/Use cases/Business rules
- Data model, Data dictionary และ Migration
- External interfaces/API/Hardware/Communication
- Quality attributes และ Capacity
- Security, Privacy, Safety, Compliance และ Audit
- Error handling, Monitoring, Backup/Recovery และ Support
- Acceptance criteria, Constraints, Dependencies และ Open issues
- Version, Approvals และ Change history
SRS, Backlog และ Traceability
- Backward — ตัวอย่างเชื่อม: Test/Feature → Requirement → Stakeholder/กฎหมาย/Outcome
- Forward — ตัวอย่างเชื่อม: Requirement → Design → Code/Config → Test → Release → Operation metric
- Bidirectional — ตัวอย่างเชื่อม: เห็น Requirement ตกหล่นและสิ่งที่สร้างโดยไม่มีเหตุ
- Version — ตัวอย่างเชื่อม: ทราบว่า Release ไหนใช้กฎ/Schema/Requirement ฉบับใด
Backlog ไม่ใช่กองข้อความสั้นที่ไม่ต้องมีรายละเอียด Requirement ต้องมีข้อมูลพอสำหรับระดับความเสี่ยงและเวลาที่ทีมจะทำ ส่วน SRS ไม่จำเป็นต้องเป็นเอกสาร Word เดียว อาจอยู่ในระบบที่ Link/Version ได้
อ่านสรุปฉบับเต็มทุกหัวข้อ
สมาชิก PRO ระบบจะจำหัวข้อที่อ่านค้างไว้ให้ด้วย
เนื้อหาสรุปนี้จัดทำขึ้นเพื่อการศึกษาส่วนบุคคล ห้ามคัดลอก ทำซ้ำ หรือนำไปใช้เพื่อวัตถุประสงค์ทางการค้าโดยไม่ได้รับอนุญาต