Quality Attribute (Non-Functional Requirement)

NFR_QA

Quality Attribute คือ คุณสมบัติเชิงคุณภาพของสิ่งต่างๆ ภายในระบบที่มีการทำงาน เช่น สถาปัตยกรรมระบบ โมดูล อ็อบเจ็คต์ หน้าจอ เป็นต้น และรวมถึงคุณภาพของระบบและระหว่างระบบภายในบริบทเดียวกัน เนื่องจากสิ่งต่างๆ เหล่านี้ต้องมีการประมวลผล มี input และมี output เกิดขึ้น การจะให้ทำงานได้มีคุณภาพที่ดีจึงมีการกำหนดคุณสมบัติเชิงคุณภาพเอาไว้ โดยควรมีคุณภาพอะไรบ้างก็ขึ้นกับบริบทของระบบนั้นๆ ว่า stakeholder ต้องการระบบที่มีศักยภาพแค่ไหน

FunctionMechanismQA

การกำหนด Quality Attribute ได้มาจากการเก็บรวบรวมความต้องการประเภท Non-Functional Requirement โดยเจ้า Quality Attribute เองก็ยังแบ่งออกได้เป็น 3 ประเภท ได้แก่

  • System Quality คือ คุณภาพระบบ มีหลักๆ อยู่แค่ 6 ตัว ได้แก่ Availability, Modifiability, Performance, Security, Testability และ Usability ซึ่งเจ้า System Quality นี่ล่ะที่เราๆ มักเรียกอีกอย่างว่า ‘Non-Functional Requirement’ นั่นเอง
  • Business Quality คือ คุณภาพในเชิงธุรกิจที่ระบบได้สนองต่อธุรกิจของ stakeholder มีหลายตัว มักเป็นศัพท์ธุรกิจ อาทิ Increase Net Profit, Increase Competitiveness, Short Time to Market, Reduce Paper Work เป็นต้น ถ้าสังเกตให้ดี ก็จะร้องอ๋อ…ว่ามันก็คือ Business Goal นั่นเอง แต่ต่างๆ เล็กน้อยที่ขอบเขตและ Level of Abstraction เพราะ Business Goal เป็นการมองภาพรวมของทั้งระบบหรือทั้งโครงการ แต่ Business Quality สามารถใช้มองในระดับที่ลึกในรายละเอียดกว่าได้ เช่น Business Quality ของ Domain Layer, ของโมดูล Report Manager, ของกลไก Transaction Management, ของสถาปัตยกรรมระบบ เป็นต้น
  • Architecture Quality คือ คุณภาพของสถาปัตยกรรมระบบ ไม่ได้มองที่การทำงานแบบ System Quality แต่มองที่ประโยชน์และการนำไปใช้ มีไม่มากนัก อาทิ Conceptual Integrity, Buildability, Correctness and Completeness เป็นต้น

อ่านเพิ่มเติม

Architectural Requirement Context

ArchReqContext

สมัยนี้มีความต้องการเพิ่มจากแต่ก่อนหลายประเภท ประเภทหนึ่งที่เริ่มได้ยินกันบ่อยขึ้นคือ ‘Architectural Requirement’ ซึ่งในบทความนี้ขอนำเสนอในมุมบริบทสำหรับความต้องการที่มีผลต่อการออกแบบและสร้างสถาปัตยกรรมซอฟต์แวร์ และมีผลต่อซอฟต์แวร์โดยรวม

สำหรับคำว่า ‘Architectural Requirement’ หมายถึง ความต้องการสำหรับการออกแบบและสร้างสถาปัตยกรรมซอฟต์แวร์ ซึ่งจริงๆ มันก็คือ non-functional requirement หรือ quality attribute นั่นเอง แต่เนื่องจากความต้องการประเภทนี้มีความสำคัญมากๆ ต่องานสถาปัตยกรรมนั่นเอง จึงมีคนคิดความต้องการประเภทใหม่แล้วตั้งชื่อว่า ‘Architectural Requirement’ ให้มันชัดเจนไปเลยนั่นเอง

สำหรับบทความนี้มีรายละเอียดหลายประเด็น ขอให้ภาพรวมเพื่อให้เข้าใจง่ายๆ ไว้ดังนี้ครับ: เมื่อเริ่มโครงการ เราต้องวิเคราะห์ปัจจัยภายนอก แล้วดูว่า stakeholder มีความกังวลต่อเรื่องใดบ้าง พวกเขาต้องการอะไร อยากให้มีระบบไอทีอะไรไปช่วย อยากให้ระบบไอทีทำอะไรได้บ้าง เมื่อเราเข้าใจภาพรวมแล้ว ก็เก็บรวบรวมความต้องการ โดยเฉพาะ functional requirement หรือ use case และ non-functional requirement หรือ quality attribute แล้วอธิบายเป็น quality scenario ความต้องการใดที่วิเคราะห์แล้วเข้าใจแล้วรีบเอาไปเขียน test case ไม่ว่าด้าน functional test case และ non-functional test case จากนั้นรีบไปหาโซลูชั่น โซลูชั่นที่ได้ก็ต้องวิเคราะห์ประโยชน์ว่าคุ้มไหมดีไหม แล้วรีบออกแบบและพัฒนาระบบ…ประมาณนี้ครับ รูปข้างบนเป็นการอธิบายความสัมพันธ์ระหว่างประเด็นสำคัญต่างๆ อ้อ…ในงานสถาปัตยกรรมซอฟต์แวร์เน้นโซลูชั่นด้านกลไกการทำงานภายใน (architectural mechanism) มากกว่าฟังก์ชั่นนะครับ

อ่านเพิ่มเติม

Architectural Drivers

 

 

 

ArchitectingContext

 

สถาปัตยกรรมคือต้นแบบของการพัฒนาระบบจริง และ เป็นกรอบในการดำเนินการและขับเคลื่อนกระบวนการพัฒนาระบบ

SystemMechanismQA

นอกจากมุ่งเน้นพัฒนาฟังก์ชั่นการทำงานของระบบแล้ว ต้องมุ่งเน้นกลไกการทำงานภายใน และ คุณภาพให้สอดคล้องกัน

 

  • Architectural Drivers หรือ ปัจจัยขับเคลื่อนกระบวนการทาง software architecture ได้จากการเลือก requirement ขึ้นมา (ประมาณ 20% ตามทฤษฏีของ Pareto) จาก requirement ทั้งหมด ทำโดย software architect
  • Architectural Drivers ประกอบด้วย
    • ส่วนหนึ่งจาก Business Goals (business requirements / stakeholder needs)
    • ส่วนหนึ่งจาก Non-Functional Requirements
    • ส่วนหนึ่งจาก Functional Requirements

Architectural Drivers คือตัวขับเคลื่อนสำคัญต่อกระบวนการสร้าง software architecture เปรียบเสมือนกรอบในการสร้าง software architecture

อ่านเพิ่มเติม