แร่ Rare Earth คืออะไร ทำไมถึงมีความสำคัญขนาดนั้น

แร่ Rare Earth (แรร์เอิร์ธ) เป็นแร่ที่มีคุณสมบัติเหมือนโลหะ คำว่า Rare Earth แปลว่าหายาก การหายากนี้ไม่ได้หมายความว่าจะหายากเหมือนทองคำแต่เป็นกระบวนการที่สกัดเพื่อนำมาใช้งานนั้นยากมาก สารที่สะกัดจากแร่ใช้เป็นส่วนประกอบของการผลิตอุปกรณ์อิเล็กทรอนิกส์ เช่น แบตเตอรี่ แผงวงจร ชิปประมวลผล คอมพิวเตอร์ เครื่องบิน จรวด เป็นต้น Rare Earth ประกอบไปด้วยธาตุทั้ง 17 ชนิด ได้แก่ Atomic Number   Symbol             Name                     21 Sc Scandium 39 Y Yttrium 57 La Lanthanum 58 Ce Cerium 59 Pr Praseodymium 60 Nd Neodymium 61 Pm Promethium 62 Sm Samarium 63 Eu Europium 64 Gd Gadolinium 65 Tb Terbium 66 Dy Dysprosium 67 Ho Holmium 68 Er Er

วิธีเก็บ วิเคราะห์ รวบรวม requirement อย่างไรให้มีประสิทธิภาพ




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

1. ค้นหาแหล่งข้อมูลที่เกี่ยวข้อง 
     แหล่งข้อมูลนั้นเป็นส่วนสำคัญที่จะทำให้เราได้ Requirement ที่สมบูรณ์ แหล่งข้อมูลที่จะค้นหาได้นั้นอาจจะมีหลายๆแหล่งก็ได้ เช่น เราต้องการที่จะออกแบบระบบ E-commerce เราจะต้องคิดถึงแหล่งข้อมูลที่เกี่ยวข้องว่าสามารถประกอบด้วยอะไรได้บ้าง เช่น 
    • ลูกค้า เป็นคนที่สามารถให้เราเข้าใจ flow การทำงานของ software ได้เป็นอย่างดี เพราะลูกค้าจะสามารถอธิบายได้ว่าสิ่งที่ลูกค้าจะทำบนหน้าเว็บมีอะไรบ้าง เช่น เริ่มจากลูกค้าดูหน้าสินค้า > add สินค้าเข้าตะกร้าสินค้า > กด promotion code > กด checkout สินค้า และกดจ่ายเงิน
    • Contents Management System(CMS)  ที่เลือกใช้ เช่น Magento, WordPress, joomla หรือ ต้องการพัฒนาระบบขึ้นมาเอง การเลือกใช้ CMS นั้นจะต้องพิจารณาถึงว่า CMS ตัวไหนตอบสนองความต้องการของเรามากที่สุด แต่ละ CMS มี feature ครบตามความต้องการของลูกค้าไหม หรือเราสามารพัฒนาขึ้นมาเองได้ไหม มีข้อจำกัดอะไรบ้าง ซึ่งเราจำเป็นจะต้องไปศึกษาแต่ละ CMS ก่อนเพื่อวางแผนในการพัฒนาซอฟต์แวร์
    • พนักงาน pack สินค้า และคนจัดส่ง คนทำงานเบื้องหลังก็มีส่วนสำคัญ ถ้าลูกค้าจ่ายเงินเสร็จแล้วระบบยังไม่จบ process ของการสั่งสินค้า จะต้องมีระบบให้พนังงานเหล่านี้ไปหยิบสินค้า ถ้าหยิบมาแล้วก็ต้องตัด stock ด้วย จากนั้นก็นำสินค้ามา pack พอ pack เสร็จถึงนำไปส่ง ซึ่งในกระบวนการทำงานต่างๆนั้นก็อาจจะมีการแสดงผลให้ลูกค้าได้ทราบสถานะของสินค้าด้วยว่าอยู่ในกระบวนการไหน ซึ่งพนักงานเหล่านี้จะเป็นแหล่งข้อมูลที่ดี ที่เราสามารถพัฒนาระบบ E-commerce ได้
    • ระบบจัดส่ง เมื่อมีการจัดส่งก็ต้องมีคนมารับสินค้า หรือเราอาจจะไปส่งสินค้าเองที่ไปรษณีย์ หรือ Kerry ก็ตาม แต่สิ่งที่จะเกิดขึ้นจากนั้นก็คือ ระบบเราควรจะไป integate กับระบบเหล่านี้ให้ได้เพื่อจะใช้เลข tracking ต่างๆในการแจ้ง user ลูกค้า
     นี้เป็นเพียงการยกตัวอย่างเบี้องต้นท่านั้นว่าแหล่งข้อมูลสำหรับการพัฒนาระบบหนึ่งขึ้นมามีอะไรบ้าง ซึ่งแต่ละแหล่งข้อมูลก็ถือเป็นส่วนสำคัญในการพัฒนาระบบ ยิ่งเราสามารถ list แหล่งข้อมูลที่เกี่ยวข้องได้มาเท่าไหร่ ก็จะทำให้การเก็บ Requirement มีความสมบูรณ์มากยิ่งขึ้น

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


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

4. ข้อจำกัดของระบบมีอะไรบ้าง
     ในการพัฒนาระบบเราต้องเข้าใจก่อนว่าอะไรทำได้อะไรทำไม่ได้ ระบบทุกระบบล้วนแล้วมีข้อจำกัดทั้งสิ้น
  • ข้อจำกัดเกี่ยวกับสถานที่ เช่น ระบบ E-commerce เรามีบริการจัดส่งให้ถึงมือลูกค้าภายในวันเดียว แต่บริการนี้อาจจะไม่ครอบคลุมทุกพื้นที่ของประเทศไทย เพราะในพื้นที่ห่างไกลนั้น เช่น อำเภอที่ห่างจากตัวเมืองมากๆหรือพื้นที่ที่เป็นเกาะ ไม่สามารถจัดส่งภายในวันเดียวได้เลย ซึ่งเมื่อทราบข้อจำกัดแล้วเราจะต้องสื่อสารกับลูกค้าให้ชัดเจน เช่น การจัดส่งสินค้าแบบได้รับสินค้าภายในวันเดียวจะต้องสั่งก่อนเวลา XX และพื้นที่บริการเป็นพื้นที่ที่ห่างจากศูนย์กระจายสินค้าของบริษัทไม่เกิน XX กิโลเมตร เป็นต้น การเข้าใจข้อจำกัดของระบบทำให้เราสามารถที่จะสร้างความเข้าใจที่ดีกับลูกค้าได้
  • ข้อจำกัดด้านกฎหมาย เช่น ในการออกแบบระบบจ่ายเงินของระบบ E-commerce มีกฏว่าเมื่อใดก็ตามที่มีการจ่ายเงินค่าสินค้าโดยบัตรเคดิตแล้ว จะต้องเป็นข้อมูลเพื่อรายการซื้อขายสินค้าไปยังหน่วยงานที่เกี่ยวข้อง 
  • ข้อจำกัดด้านเทคโนโลยี เช่น หากระบบ E-commerce ของเราพัฒนาด้วย Contents Management System(CMS) อาจจะข้อจำกัดที่ทำให้เราไม่สามารถพัฒนา feature เฉพาะทางตามที่เราต้องการได้ เพราะส่วนใหญ่ CMS จะมี feature หลักมาให้อยู่แล้ว
5. จัดทำแบบสอบถาม
     การทำแบบสอบถามนั้นจะทำให้เรามั่นใจได้ว่า สิ่งที่เราคาดเดา สิ่งที่เราคิดมานั้นจะมีคนใช้งานจริงๆ เมื่อเราพัฒนาขึ้นมา การทำแบบสอบถามเราควรออกแบบสอบถามให้ครบทุกกลุ่มเป้าหมายของคนที่จะมาใช้ระบบเรา แบบสอบถามไม่ควรชี้นำ เรียงลำดับของคำถามอย่างเหมาะสม เช่นระบบ E-commerce เราจะทำแบบสอบถามเพื่อดูว่าลูกค้าส่วนใหญ่มีวิธีการชำระเงินแบบไหน บัตรเครดิต การโอนเงิน เก็บเงินปลายทาง linepay หรือ internet banking การทำแบบสอบถามนั้นจะทำให้เราทราบว่าลูกค้าส่วนใหญ่เลือกใช้การชำระเงินแบบไหนบ้าง เพื่อเราจะนำข้อมูลของแบบสอบถามนั้นมาพัฒนาระบบการจ่ายเงิน



6. ใช้แบบจำลองเชิงแนวคิด(UML Unified Modeling Language) เข้ามาช่วย
     UML คือการสร้างแบบจำลองเชิงแนวคิดความสัมพันธ์เพื่อใช้ในการออกแบบ วิเคราะห์และจำลองวัตถุต่างๆที่เกิดขึ้นในระบบ แบบจำลองเป็นการถ่ายถอดแนวความคิดเพื่อให้สามารถเข้าใจปัญหาได้ง่ายขึ้น ดังนั้นเราจึงนิยมนำแบบจำลองประเภทต่างๆมาออกแบบเพื่อถ่ายทอดให้กับ ลูกค้า ผู้ใช้งาน นักพัฒนาระบบ เป็นต้น UML นั้นมีหลายประเภทด้วยกันแต่จะขอนำแสดงเฉพาะ UML ที่จะเป็นประโยชน์ต่อการเก็บ Requirement 
  • Use Case Diagram แสดงมุมมองการใช้งานของ User ว่ามีส่วนเกี่ยวข้องกับระบบอย่างไรบ้าง
  • Activity Diagram แสดงให้เห็นถึง flow การทำงานของระบบ
  • Sequence Diagram แสดงให้เห็นถึงลำดับและกิจกรรมที่เกิดขึ้นในระบบ
  • Class Diagram แสดงให้เห็นถึงความสัมพันธ์ข้อมูลของแต่ละ Class ส่วน Developer จะใช้ในการพัฒนาระบบ
  • State Diagram แสดงถึงวัตถุและการเปลี่ยนแปลงของวัตถุที่เกิดขึ้น เช่น ระบ E-commerce มีการเปลี่ยนแปลงสถานะของวัตถุดังนี้ สั่งสินค้า > จัดเตรียมสินค้า > บรรจุสินค้า > จัดส่งสินค้า > สินค้าถึงผู้รับ
ตัวอย่าง Activity Diagram ของระบบ E-commerce | ที่มา

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

7. Non-Functional Requirements
     การเก็บ Requirements ส่วนใหญ่แล้วเรามักจะไม่ได้คำนึงถึง Non-Functional Requirements ประสิทธิภาพของซอฟต์แวร์มากนักแต่ความจริงแล้วถือเป็นส่วนสำคัญอย่างมากที่จะทำให้ระบบเกิดความน่าเชื่อถือ ยกตัวอย่าง Non-Functional Requirements ที่ควรมี
  • Performance หรือประสิทธิภาพของระบบ เช่น ระบบ E-commerce โดยปกติจะต้องรองรับการทำงานของ User แบบใช้งานพร้อมกันได้ 1,000 คน
  • Security ระบบจะต้องมีความปลอดภัย ให้สิทธิ์แก่ผู้ใช้งานต่างๆอย่างเหมาะสม เช่น ระบบ E-commerce ในการจ่ายเงินแบบบัตรเคดิตจะมีการยืนยัน OTP ที่ส่งไปทางโทรศัพท์อีกครั้งหนึ่ง
  • Safety อาจจะใช้ในระบบซอฟต์แวร์ที่ต้องการความปลอดภัยสูง เช่น ระบบควบคุมความร้อนในห้องอบซาวน่า ระบบจะหยุดการทำงานทันทีที่พบว่าอุณหภูมิของห้องเกิน 60 องศาเซลเซียส
  • Usability ดูว่า User เข้าใจในการใช้งานระบได้มากแค่ไหน เช่น ระบบ E-commerce อาจจะวัดจากเวลาที่ Userr ทำรายการซื้อสินค้าได้สำเร็จ ถ้า User ใช้เวลาน้อย ก็แสดงว่าระบบใช้งานง่าย
  • Reliability สามารถวัดได้จาก Failure rate คือยิ่งซอฟต์แวร์มี Failure rate สูงนั้นหมายความว่าซอฟต์แวร์ยิ่งไม่มีความน่าเชื่อถือ เพราะนั้นอาจจะหมายถึง User ทำงานบางงานในระบบไม่สำเร็จ

8. จัดทำ Prototyping หรือ Mock-up

     การมี Prototyp หรือ mock-up ทำให้ User ได้เห็นสิ่ง function ที่จะถูก design มันเป็นสิ่งที่จะยืนยันความเข้าใจกับ User ได้ดี และ User สามารถตรวจสอบได้ด้วยว่า function การทำงานถูกต้องหรือไม่ มีส่วนใดขาดหายไปหรือไม่ การทำ mock-up นั้นอาจจะทำทุกส่วนของซอฟต์แวร์หรือเลือกทำเฉพาะส่วนที่ยากต่อการอธิบายก็ได้ การออกแบบ mock-up นั้นควรจะออกแบบให้ใช้งานง่ายเป็นไปตามหลักการออกแบของ User Interface Design ด้วย


ตัวอย่าง Mock-up ของระบบ E-commerce | ที่มา


ป้ายกำกับ

แสดงเพิ่มเติม

บทความยอดนิยม

Automation testing หรือ การทดสอบซอฟต์แวร์อัตโนมัติ คืออะไร ทำไมถึงสำคัญต่อการทดสอบซอฟต์แวร์

Performance Test คือ อะไร วัดประสิทธิภาพของระบบ ล่มไม่ล่ม จะรู้ได้อย่างไร

ถอดรหัสความลับเครื่อง Enigma จุดเริ่มต้นและจุดจบของสงครามโลกครั้งที่ 2