คุณสมบัติ ของนักวิเคราะห์ระบบที่ดี

1.  มีความรู้ “ในระบบงานธุรกิจ” ที่พัฒนา สามารถมองกว้างในภาพรวม และขั้นตอนของงานในรายละเอียด
2. มีความสามารถในการนำ ทำงานประสาน ร่วมกับผู้อื่น  
3. มีความสามารถ ในการแก้ปัญหา  มีแผนสำรอง กำหนดโซลูชั่นทางเลือก หรือปรับแก้ข้อจำกัดของทางเลือกหลัก
4. มีความสามารถ ในด้านการ วิเคราะห์ ต้นทุน-ผลตอบแทน ของโครงการ 
5. มีตรรกะ (Logic) และความรู้พื้นฐาน ในด้านการเขียนโปรแกรม (Coding)
6. ต้องติดตาม เทคโนโลยีใหม่ๆ อย่างสม่ำเสมอ เพื่อ การคาดการณ์ แนวโน้มด้านไอที ปัจจัย ที่ส่งผลกระทบจากการ  “เปลี่ยนผ่าน” และเตรียมการณ์ “รับมือ” ต่อสภาพแวดล้อมที่เปลี่ยนแปลง
7. มีประสบการณ์ในการทำงานด้านวิเคราะห์วิเคราะห์ระบบ
8. สามารถ ประยุกต์และปรับใช้ นวัตกรรมใหม่ และสามารถ นำเครื่องมือ และวิธีการมาใช้ได้อย่างเหมาะสม ภายใต้ข้อจำกัดด้านงบประมาณ 
9. มีความสามารถในการ “ไขแจ้ง (เล่าเรื่อง)” การตีความและการแปลงภาษาทางด้านเทคนิค (Concrete Language) ให้เป็นภาษาสำหรับบุคคลทั่วไป (Natural Language) ทำความเข้าใจได้ สรุปก็คือทำเรื่องยากให้เป็นเรื่องง่าย
10. สามารถเลือกใช้ เครื่องมือ และวิธีการติดต่อ สื่อสารได้อย่างเหมาะสม ต่องาน และตรงกลุ่มผู้ใช้งาน ไม่ว่าจะเป็น การนำเสนอผ่านสไลด์ (Presentation), การจัดทำเอกสารประกอบต่างๆ อย่าง  เช่น กฎเกณฑ์ข้อกำหนด (System Requirement Specification) การสร้างเอกสาร งานออกแบบ (Design Specifications), เอกสารแสดงการใช้สัญลักษณ์ (Symbol & Notation)  รวมถึง การพูด เผชิญหน้าปากเปล่า (Verbal & Face-to-Face) ตัวต่อตัว หรือต่อทีม การนัดหมาย-รายงาน-วาระต่างๆ ผ่านอีเมล์ การประชุมทางไกล (Video Conference)  และการ
    ใช้กระดานข่าวสาร (Web-board)  การใช้สื่อหรือวิธีการต่างๆ ตามที่กำหนด   

 

ความต้องการทางด้านฟังก์ชั่นงาน (Functional Requirements)

Functional Requirements

ความต้องการระบบ ที่ใช้ ระบุึฟังก์ชั่นที่ระบบงาน หรือคอมโพเน้นต์ที่สามารถนำมาใช้ทำงานได้

ความต้องการในส่วนฟังก์ชั่นงานโดยปกติแล้วประกอบไปด้วย

• กฏเกณฑ์/ข้อกำหนดทางธุรกิจ (Business Rules)
• การแก้ไขรายการให้ถูกต้อง, การปรับปรุง, การยกเลิก (Transaction corrections, adjustments,cancellations)
• ฟังก์ชั่นในส่วนจัดการระบบ (Administrative functions)
• การยืนยันตัวตน (Authentication)
• การให้อำนาจ (Authorization) – ฟังก์ชั่นที่มอบหมายผู้ใช้ให้เป็นตัวแทน 
• ติดตามการตรวจสอบ (Audit Tracking)
• ส่วนต่อประสานภายนอก (External Interfaces)
• ความต้องการการรับรอง (Certification Requirements)
• ความต้องการการออกรายงาน (Reporting Requirements)
• ประวัติข้อมูล(Historical Data)
• กฏเกณฑ์หรือข้อกำหนดความต้องการ (Legal or Regulatory Requirements)

ทิป แอพฯ ไลน์ New Registered Email (เปลี่ยนเมล์เดิม เป็นเมล์ใหม่)

เราสามารถ เปลี่ยนเมล์ที่เคยลงทะเบียนกับไลน์ ได้ดังนี้:

*ขั้นตอน อาจแตกต่างกันบ้างเล็กน้อย ขึ้นอยู่กับรุ่นอุปกรณ์ ที่เราใช้

1) เปิดการตั้งค่า (Settings) ใน LINE
2) แตะ Accounts
3) แตะ Email Registration 
4) แตะ Change Your Email
5) ใส่อีเมล์เดิมและรหัสผ่านเข้าไป แล้วแตะ  OK
6) ใส่อีเมล์ใหม่และรหัสผ่านที่เราต้องการลงทะเบียนเข้าไป แล้วแตะ OK.

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

Function Specfications ไม่จำเป็นในกรณีใด

ฟังก์ชั่นนอลสเปค เป็นแฟนตาซีเกินจริง

มันไม่ได้สะท้อนความเป็นจริง  แอพพลิเคชั่นไม่ใกล้เคียงความเป็นจริงจนกว่านักพัฒนาจะสร้างมันขึ้นมา นักออกแบบ ร่างมันออกมา และมีคนใช้งานได้จริง ฟังก์ชันนอล สเปคจะเป็นเพียงข้อความบนกระดาษเท่านั้น 

ฟังก์ชั่นนอลสเปค ที่เนื้อหา เอนเอียงสมยอม

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

ฟังก์ชั่นนอลสเปค ที่ทำให้เกิด ความเข้าใจผิดในการทำข้อตกลง

คนส่วนใหญ่ มักทำความตกลง จาก ข้อความในวรรคตอน ไม่ใ่ช่ ข้อตกลงที่แท้จริง

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

ฟังก์ชั่นนอลสเปค บีบคั้น ให้เรา ทำการตัดสินใจในเรื่องสำคัญมาๆ แต่มีข้อมูลน้อยที่สุด

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

ฟังก์ชั่นนอลสเปค ที่ทำให้ ฟีเจอร์ เกินภาระ (Overload)

กรณีที่ ไม่มีการ ถอยกลับ(ลดทอน และมุ่งไปในส่วนที่ สำคัญและจำเป็น) ในระหว่าง ระยะกำหนดสเปค

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

ฟังก์ชั่นนอลสเปค ไม่ทำให้ คุณมีวิวัฒนาการ, เกิดการเปลี่ยนแปลง และการคิดทบทวนใหม่

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

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

ฺBusiness Analysis Techniques (เทคนิควิเคราะห์แบบ HEPTALYSIS)

เทคนิคงานวิเคราะห์ ทางธุรกิจแบบ HEPTALYSIS

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

• โอกาสทางการตลาด
• ผลิตภัณฑ์/วิธีจัดการปัญหา
• แผนการปฏิบัติงาน
• เครื่องมือทางการเงิน
• ทุนทรัพยากรบุคคล
• ศักยภาพผลตอบแทน
• ส่วนต่างความปลอดภัย