ทำไมต้องมี Non-Functional Requirement

ทำไมต้องมี Non-Functional Requirement
21/10/20   |   47k

หากตัด Requirement ที่ว่า "ต้องรองรับปริมาณการใช้งานได้ 1 ล้าน user ต่อวัน" ออกนั้น ฟังก์ชันการทำงานของ software ของเราก็ยังทำงานปกติดีอยู่ หากผู้ใช้มีแค่ "เราคนเดียว"

 

อีกมุมหนึ่งของ Software Requirement 

ยังมีสิ่งที่เจ้าของ Requirement คาดหวังว่าจะได้รับและมีความสำคัญพอๆ กับฟีเจอร์ที่ต้องการ แต่กลับถูกพูดถึงไม่เยอะนักในการส่งมอบงาน รู้ตัวอีกทีก็อาจพบว่า เว็บล่มเมื่อมีผู้ใช้มากกว่าที่คิดไว้ , ข้อมูลสำรองไม่สามารถนำกลับมาใช้ได้ , โดนแฮ็กจากช่องทางที่ไม่ได้ควบคุมความปลอดภัยเอาไว้ และยังมีตัวอย่างปัญหาอีกมากมาย หรือบางครั้งหัวข้อเหล่านี้อาจถูกเขียนขึ้นมาแบบคร่าว ๆ เอาไว้ว่า "ระบบต้องทำงานได้ 24/7 ไม่ล่ม" , "ต้องรองรับปริมาณการใช้งานได้ 1 ล้าน user ต่อวัน" Requirement เหล่านี้เป็นความคาดหวังจากประสบการณ์เจ้าของ Requirement เองที่ได้ประสบพบเจอมา

 

สังเกตุได้ว่า หากตัด Requirement ที่ว่า "ระบบต้องทำงานได้ 24/7 ไม่ล่ม" หรือ "ต้องรองรับปริมาณการใช้งานได้ 1 ล้าน user ต่อวัน" ออกนั้น ฟังก์ชันการทำงานของ software ของเราก็ยังทำงานปกติดี ถ้าเป็นระบบขายสินค้า ฟังก์ชันในการกดใส่ตะกร้าและจ่ายเงินก็ยังใช้งานได้ ถ้าเป็นเว็บหางานผู้สมัครงานก็ยังค้นหางานและส่งใบสมัครงานได้ปกติ 

 

ด้วยปัจจัยเหล่านี้เราจึงแยก Requirement ออกเป็น 2 ส่วนคือ

Functional Requirement และ Non-Functional Requirement

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

 

 

Non-Functional Requirement คืออะไร

Non-Functional Requirement เป็น Requirement ที่ใช้เพื่อเสริมให้ซอฟต์แวร์เราสามารถทำงานได้ลื่นไหลขึ้น มีประสิทธิภาพมากขึ้น น่าพอใจมากขึ้น หรือน่าเชื่อถือมากขึ้น ตามแต่ตกลงกันกับเจ้าของ Requirement ซึ่งจะพูดถึงหลากหลายมุมมองของการพัฒนาซอฟต์แวร์
ตั้งแต่ข้อตกลงด้านมาตรฐาน, กฏหมาย, ข้อมูล, การใช้งาน, ความปลอดภัย, ประสิทธิภาพ/การรองรับการใช้งานรูปแบบต่าง ๆ และอีกมากมาย

 

 

ถ้าไม่มี Non-Functional Requierment ซอฟต์แวร์ก็ยังทำงานได้ตาม Business Logic ที่ถูกกำหนดไว้เหมือนเดิมไม่มีเปลี่ยนแปลง

 

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

 

ซอฟต์แวร์บริหารงานในโรงงาน

กลุ่มผู้ใช้งานอาจเป็น HR หรือ ผู้จัดการโรงงานเท่านั้น

 

สิ่งที่ต้องสนใจเพิ่มเติมคือ

- ความปลอดภัยเพื่อไม่ให้ข้อมูลรั่วไหล
- หากระบบล่มต้องสามารถกู้คืนได้ภายใน 1 ชั่วโมง
- รูปแบบการเก็บข้อมูลส่วนบุคคลต้องเป็นไปตามมาตรฐาน PDPA (มีเอกสารประกอบ)
หากเป็น Platform ที่มีขนาดใหญ่ขึ้นมาหน่อย
เช่น 

 

 

เว็บหางานที่มีกลุ่มผู้ใช้ทั้งในประเทศและต่างประเทศ

สิ่งที่ต้องสนใจเพิ่มเติมคือ
- ระบบความปลอดภัย ป้องกันการสวมรอย การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาติ และความปลอดภัยด้านต่าง ๆ
- ต้องความน่าเชื่อถือของระบบ ว่าจะยังทำงานได้อยู่ตลอด
- ต้องมีความสามารถการขยายการรองรับ User ที่มีจำนวนเพิ่มขึ้น
- รูปแบบการเก็บข้อมูลส่วนบุคคลต้องเป็นไปตามมาตรฐาน PDPA (มีเอกสารประกอบ)
- ความเร็วในการตอบสนองต่อ User
- ความน่าเชื่อถือด้านข้อมูลจะต้องถูกต้อง 100% ตามที่ User กระทำต่อฟีเจอร์นั้น ๆ
จะเห็นได้ว่า Non-Functional Requierment นั้นเป็นส่วนที่สำคัญกับซอฟต์แวร์ที่ส่งมอบและผู้ใช้งาน ไม่แพ้ Functional Requirement เพราะฉะนั้นเรามาสรุปกันอีกรอบว่า Software Requirement ประกอบไปด้วยอะไรบ้าง

 
Requirement = Functional Requirement + Non-Functional Requirement

เมื่อมี Requirement ก็ต้องมีการทดสอบควบคู่กันไปเสมอเพื่อยืนยันว่าซอฟต์แวร์ที่ส่งมอบนั้นตรงตามความต้องการของ User หรือไม่

ดังนั้นการทดสอบจึงต้องทดสอบทั้ง Functional และ Non-Functional ด้วย

Acceptance Test = Functional Testing + Non-Functional Testing

บทความนี้จะขอยกตัวอย่างหัวข้อ Non-Functional Requirement มาไว้คร่าว ๆ เป็นแนวทางให้ไปลองปรับใช้กับโปรเจ็คนะครับ

 

Compatibility
ตัวอย่าง สามารถรันได้บนแพลตฟอร์มอะไรบ้าง, ต้องทำงานร่วมกับ 3rd party application อะไรบ้าง


Scalability
ตัวอย่าง เราจะควบคุมการเพิ่ม ลด ของ work load อย่างไรโดยที่ไม่ให้ performance ตก


Availability
ตัวอย่าง ซอฟต์แวร์จะพร้อมใช้งานเมื่อไหร่บ้าง (24/7) ? , มีกำหนดช่วง downtime หรือไม่
 

 

Documentation

ตัวอย่าง ต้องมีเอกสารอะไรบ้างให้กับผู้ใช้งาน
 

 

 

Recoverability

ตัวอย่าง หากระบบล่มมีวิธีการกู้คืนอย่างไรบ้าง ,​ มีการสำรองข้อมูลอย่างไร ,
 

 

 

Capability

ตัวอย่าง ระบบสามารถรองรับการใช้งานได้กี่ transaction / Hrs.
 

 

 

Maintainability

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

 

 

Security

ตัวอย่าง มีการต้ัง Timeout เมื่อไม่มี action จาก User ไว้เป็นเวลากี่นาที, รหัสผ่านต้องถูกรีเซ็ตทุก ๆ กี่วัน
 

 

 

Manageability

ตัวอย่าง สามารถตรวจสอบและปรับเปลี่ยน config ได้โดยไม่ต้อง build software ใหม่
 

 

 

Data Integrity

ตัวอย่าง มาตรฐานการ Compress และ Decompress เป็นแบบใด, วิธีการดำเนินการต่อเมื่อการ immport ข้อมูลที่ผิดพลาดจะต้องย้อนกลับไปทำต่อได้อย่างครบถ้วน
 

 

 

Usability

ตัวอย่าง รองรับกี่ภาษา อะไรบ้าง , สี / layout / flow ตรงตามมาตรฐานที่ต้องการหรือไม่

 

 

อย่าลืมคิดวิธีการทดสอบซอฟต์แวร์ไปพร้อม ๆ กับการคิดฟีเจอร์นะครับ ^^

 

 

tags : requirement non-functional requirement



ติดตามข่าวสารและเรื่องราวดีๆ ทาง Email