Transcript Lesson 4 Software Requirements

Lesson 4
Software Requirements
www.ict.up.ac.th/uthais/
KANOKWATT SHIANGJEN
บทนำ
เพื่อให้ นิสิตเข้ ำใจหลักแนวคิดของกำรจัดเก็บควำมต้ องกำรของ
ผู้ใช้ (User Requirement) และ ควำมต้ องกำรของระบบ (System
Requirement)
เพื่อให้ นิสิตเข้ ำใจ ควำมแตกต่ ำงของควำมต้ องกำรในส่ วนที่เป็ น
ฟั งก์ ชัน (Function) และ ไม่ เป็ นฟั งก์ ชัน (Non-Function)
เพื่อให้ นิสิตเข้ ำใจถึงสำเหตุท่ เี รำต้ องทำ และจัดกำรกับข้ อมูล
ควำมต้ องกำรของผู้ใช้ อย่ ำงเป็ นระบบ
School of Information and Communication Technology., University of Phayao
2
Contents
ฟั งก์ ชัน (Functional) และ ไม่ เป็ นฟั งก์ ชัน (Non-Functional
Requirements)
ควำมต้ องกำรของผู้ใช้ (User Requirements)
ควำมต้ องกำรของระบบ (System Requirements)
กำรติดต่ อระหว่ ำงระบบ (Interface Specification)
เอกสำรที่จัดเก็บรำยละเอียดควำมต้ องกำรของซอฟต์ แวร์
(The Software Requirements Document)
School of Information and Communication Technology., University of Phayao
3
ควำมต้ องกำร (Requirement)
ปั ญหำที่สำคัญเกี่ยวกับควำมต้ องกำร ก็คือควำมไม่ ชดั เจนใน
ระหว่ ำงกำรจัดเก็บข้ อมูล และกำรแบ่ งกลุ่มของควำมต้ องกำร
ออกเป็ น 2 ส่ วน คือ
 ความต้ องการของผู้ใช้ (User Requirements)
 ความต้ องการของระบบ (System Requirements)
School of Information and Communication Technology., University of Phayao
4
ควำมต้ องกำรของผู้ใช้ (User Requirements)
เป็ นสิ่งที่ผ้ ูใช้ ได้ ให้ สัมภำษณ์ หรื อบอกกล่ ำวเพื่อให้ ทรำบถึงสิ่งที่
เขำต้ องกำร ซึ่งมักเป็ นเงื่อนไข (Constraint) ในกำรปฏิบัติงำน
มักจะอยู่ในรูปของนำมธรรม (Abstract) เช่ น
 ต้ องการระบบลงทะเบียนเรี ยนนิสิตที่สามารถตรวจสอบเบื ้องต้ นว่า
นิสติ ได้ เรี ยนผ่านวิชาก่อนหน้ า (Pre-Required) มาแล้ ว
 ต้ อ งการะบบที่ ส ามารถตรวจสอบจบ (ดูว่า ลงทะเบี ย นครบตาม
โครงสร้ างหลักสูตรหรื อไม่)
School of Information and Communication Technology., University of Phayao
5
ควำมต้ องกำรของระบบ (System Requirements)
เป็ นสิ่งที่ระบบต้ องกำร เพื่อตอบสนองกับควำมต้ องกำรของผู้ใช้
ประกอบด้ วย ฟั งก์ ชันกำรทำงำนของระบบ (System ‘s function) ,
กำรให้ บ ริ ก ำร (Services)
และเงื่อ นไขในกำรดำเนิ นกำร
(Operational Constraint).
เอกสำรที่ จั ด เก็ บ ควำมต้ อ งกำรของระบบต้ อ งมี ค วำมถู ก ต้ อง
แม่ นยำ (Precise) และต้ องมีกำรอธิบำยขึน้ ตอนกำรทำงำนอย่ ำง
ละเอี ย ด ซึ่ ง เรำอำจน ำมำใช้ เป็ นส่ ว นหนึ่ ง ในกำรจั ด ท ำสั ญ ญำ
ระหว่ ำงผู้ว่ำจ้ ำงได้
School of Information and Communication Technology., University of Phayao
6
ควำมต้ องกำรของระบบ (System Requirements)
ตัวอย่ ำงของควำมต้ องกำรระบบ
 ระบบต้ องมีการจัดเก็บโครงสร้ างของรายวิชา และรายวิชาก่อนหน้ า
โดยต้ องมีการตรวจสอบผลการศึกษาของนิสติ ว่า นิสติ ได้ ผา่ นการ
ลงทะเบียนเรี ยนรายวิชาก่อนหน้ ามาแล้ ว และสอบผ่าน จึงจะ
สามารถทาการลงทะเบียนในวิชานี ้ได้
 ระบบต้ องมีการจัดเก็บโครงสร้ างหลักสูตรของแต่ละสาขาวิชาว่า
ต้ องลงทะเบียนอย่างน้ อยกี่หน่วยกิต และในแต่ละหมวดวิชาที่เข้ า
ศึกษาถูกต้ องตามโครงสร้ างหลักสูตรหรื อไม่?
School of Information and Communication Technology., University of Phayao
7
Functional and Non-Functional Requirements
ควำมต้ องกำรของระบบซอฟต์ แวร์ แบ่ งได้ ออกเป็ น 3 ประเภท คือ
 Functional Requirements เป็ นสิง่ ที่ระบบต้ องให้ บริ การ และวิธีการที่
ระบบจะตอบสนองต่อข้ อมูลเข้ า ภายใต้ สถานการณ์ตา่ ง ๆ กัน
 Non-Functional Requirements เป็ นเงื่อนไขในการให้ บริ การ หรื อ
ดาเนินการเกี่ยวกับฟั งก์ชนั ที่กระทากับระบบ รวมถึง มาตรฐาน และ
เวลาที่ใช้ กับระบบทังหมด
้
 Domain
Requirements เป็ นความต้ อ งการตามลัก ษณะของ
แอพพลิ เ คชั่น ที่ ท างานในระบบ ซึ่ง อาจเป็ นฟั ง ก์ ชัน หรื อ ไม่ เ ป็ น
ฟั งก์ชนั ก็ได้
School of Information and Communication Technology., University of Phayao
8
Functional Requirements (1/2)
เป็ นสิ่งที่ระบบควรที่จะทำ (Should Do) ซึ่งจะขึน้ อยู่กับประเภทของ
ซอฟต์ แวร์ ท่ จี ะต้ องพัฒนำ เพื่อตอบสนองควำมต้ องกำรของผู้ใช้
ควำมต้ อ งกำรจำกผู้ ใช้ จ ะอยู่ ในลั ก ษณะนำมธรรม (Abstract)
นิ สิ ต
จำเป็ นต้ องแปลงออกมำให้ อยู่ในรู ปของรำยละเอียดฟั งก์ ชันกำรทำงำน
ระบบ ประกอบด้ วย ข้ อมูลเข้ ำ ข้ อมูลออก ข้ อยกเว้ นต่ ำง ๆ และอื่นๆ เช่ น
 ผู้ใช้ ต้องสามารถค้ นหารายละเอียดของหนังสือได้ (ISBN, ชื่อหนังสือ, ผู้แต่ง)
 ผู้ใ ช้ ต้ อ งสามารถยื ม -คื น หนัง สื อ ได้ ด้ ว ยตนเอง โดยไม่ ต้ อ งมี บ รรณารั ก ษ์
(RFID)
 ต้ องมีระบบป้องกันการนาหนังสือออกจากห้ องสมุดโดยไม่ได้ รับอนุญาาต
School of Information and Communication Technology., University of Phayao
9
Functional Requirements (2/2)
กำรจัดเก็บ Function Specification ของระบบต้ องมีควำมสมบูรณ์
(Completeness) และ สอดคล้ อง (Consistency) ซึ่งในระบบงำนจริง เป็ นไป
ได้ ยำกที่เรำจะสำมำรถจัดเก็บควำมต้ องกำรได้ ครบถ้ วนสมบูรณ์ ภำยใน
ครั ง้ เดียว
ควำมต้ อ งกำรของผู้ ใช้ สำมำรถเปลี่ ยนแปลงได้ ตลอดเวลำ ระหว่ ำงกำร
พัฒนำ รวมถึงควำมต้ องกำรที่ซ่อนอยู่ จนกว่ ำโปรแกรมจะถูกติดตัง้ และใช้
งำนจริง ควำมต้ องกำรก็ยังสำมำรถเปลี่ยนแปลงได้
School of Information and Communication Technology., University of Phayao
10
Non-Functional Requirements (1/2)
เป็ นควำมต้ องกำรที่ไม่ ได้ มำจำกควำมต้ องกำรของผู้ใช้ โดยตรง แต่เป็ นสิ่ง
ที่เกี่ยวข้ องกับควำมต้ องกำรของผู้ใช้ เช่ น ควำมน่ ำเชื่อถือ ควำมปลอดภัย
ควำมรวดเร็วในกำรตอบสนองกับผู้ใช้ ควำมสำมำรถในกำรจัดเก็บข้ อมูล
ปริมำณมำก
Non-Functional Requirement โดยส่ วนใหญ่ จะเกี่ยวข้ องกับภำพรวมของ
ระบบ ไม่ ขนึ ้ เฉพำะเจำะจงลงไปกับผู้ใช้ คนใด คนหนึ่ง ประกอบด้ วย
 Product Requirements
 Organizational Requirements
 External Requirements
School of Information and Communication Technology., University of Phayao
11
Non-Functional Requirements (2/2)
School of Information and Communication Technology., University of Phayao
12
Domain Requirements
เป็ นควำมต้ องกำรของ Application
ในระบบ มำกกว่ ำควำมต้ องกำร
เฉพำะที่ได้ มำจำกผู้ใช้ เท่ ำนั น้ โดยอำจเป็ นฟั งก์ ชัน หรื อไม่ ใช่ ฟังก์ ชันของ
ระบบ เช่ น
 ต้ องสามารถเชื่อมต่อกับฐานข้ อมูลได้ มากกว่า 1 แหล่งข้ อมูล (Web Service)
 การ Download เอกสารต้ องมีการระบุสิทธิ การเข้ าถึงก่อน เนื่องจากมี ระดับ
ของความสาคัญาของเอกสาร สาหรับผู้ใช้ แต่ละคน
 ในการสร้ างเอกสาร PDF ต้ องมีการ Generate รหัสผ่านสาหรับเปิ ดเอกสาร
School of Information and Communication Technology., University of Phayao
13
ควำมต้ องกำรของผู้ใช้ (User Requirements)
ควำมต้ องกำรของผู้ ใช้ ควรจะสำมำรถอธิ บ ำยได้ ทั ้ง ในรู ป แบบของ
Functional และ Non-Functional Requirements เพื่อให้ นักวิเครำะห์ ระบบ
สำมำรถเข้ ำใจในพฤติ ก รรม กำรใช้ งำนระบบ กำรใช้ เครื่ องหมำย
สัญลักษณ์ ต่ำงๆ รวมถึงสิ่งที่ควรหลีกเลี่ยง ในกำรออกแบบระบบ
อย่ ำงไรก็ตำม ปั ญหำที่เกิดขึน้ จำก ธรรมชำติของควำมต้ องกำร คือ
 ความไม่ชดั เจน (Lack of Clarity) เช่น ภาษาที่ใช้ มีความกากวม
 ความสับสน (Requirements Confusion) เช่น ไม่สามารถแยกแยะระหว่าง
Functional, Non-Functional และ System Goals ในการออกแบบได้
 การผสมความต้ องการ (Requirements Amalgamation) เป็ นการรวมเอา
ความต้ องการหลายๆ มารวมเป็ นความต้ องการเดียว
School of Information and Communication Technology., University of Phayao
14
ควำมต้ องกำรของระบบ (System Requirements) (1/2)
ควำมต้ องกำรของระบบ จะเป็ นสิ่งที่ขยำยออกมำจำกควำมต้ องกำรของ
ผู้ ใช้ โดยเป็ นจุ ด เริ่ ม ต้ น ของ วิศวกรซอฟต์ แวร์ ที่ จ ะใช้ ในกำรออกแบบ
ระบบ เพื่อให้ รองรั บกับควำมต้ องกำรของผู้ใช้
ในทำงทฤษฎี ควำมต้ องกำรของระบบควรที่จะสำมำรถอธิบำยกำรทำงำน
กับ External Entity ที่มีต่อระบบได้ ง่ำย แต่ ในทำงปฏิบัติ รำยละเอี ยดที่ใช้
ในกำรออกแบบระบบนัน้ จะมีควำมซับซ้ อน ยำกแก่ กำรอธิบำยได้ โดยง่ ำย
หำกต้ องใช้ ประสบกำรณ์ ในกำรแบ่ งงำน (Break-Down)
จำกวิศวกร
ซอฟต์ แวร์ ท่ ีมีประสบกำรณ์
กำรใช้ ภำษำธรรมชำติ (Natural Language) ในกำรเขียนควำมต้ องกำรของ
ระบบจะท ำให้ เกิ ด ควำมสั บ สน ยำกต่ อกำรท ำควำมเข้ ำใจ ควรใช้
สัญลักษณ์ (Notations) มำตรฐำน เพื่อใช้ อธิบำยกำรทำงำนจะดีกว่ ำ
School of Information and Communication Technology., University of Phayao
15
ควำมต้ องกำรของระบบ (System Requirements) (2/2)
กำรที่ จ ะท ำควำมเข้ ำใจระหว่ ำงควำมต้ องกำรของผู้ ใช้ และวิ ศ วกร
ซอฟต์ แวร์ ให้ เข้ ำใจตรงกันนัน้ สำมำรถใช้ สัญลักษณ์ แทนคำอธิบำยเพื่อให้
ได้ ควำมหมำยที่ตรงกัน ประกอบด้ วย
 Structured Natural Language คือ การสร้ างฟอร์ มมาตรฐาน หรื อแม่แบบ
สาหรับจัดเก็บความต้ องการ (การบ้ าน PSP)
 Design Description Languages คือ การสร้ าง Abstract สาหรับ Interface
Specification คล้ ายเขียนฟั งก์ชนั การทางานไว้ ก่อน แต่ยงั ไม่มี
 Graphical Notations คือ การใช้ ภาพแสดงแทนข้ อความ เช่น USE-CASE
และ Sequence Diagram เป็ นต้ น
 Mathematical Specifications คือการใช้ สญา
ั ลักษณ์ ทางคณิตศาสตร์ มาใช้
อธิบายเช่น Finite-State Machine หรื อ SET เป็ นต้ น
School of Information and Communication Technology., University of Phayao
16
Structured Natural Language
คำสำคัญ
Function
Description
คำอธิบำย
ฟั งก์ชนั การทางาน
คาอธิบายการทางานของฟั งก์ชนั
Inputs
Source
Outputs
Destination
ข้ อมูลเข้ าสาหรับฟั งก์ชนั
แหล่งที่มาของข้ อมูลเข้ า
ข้ อมูลผลลัพธ์ที่คาดว่าจะได้ จากฟั งก์ชนั
ส่งผลลัพธ์ข้างต้ นต่อไปยังฟั งก์ชนั การทางานใดต่อไป
Action
Requires
Pre-Condition
กระบวนการทางานภายในฟั งก์ชนั ตังแต่
้ รับข้ อมูล ประมวลผล แสดงผล
สิ่งที่จาเป็ นสาหรับฟั งก์ชนั
เงื่อนไขก่อนเข้ าทางานในฟั งก์ชนั
Post-Condition
Side Effects
เงื่อนไขการออกจากฟั งก์ชนั
ผลกระทบของฟั งก์ชนั ต่อฟั งก์ชนั อื่น ๆ
School of Information and Communication Technology., University of Phayao
17
Design Description Languages
ให้ ไปดูในหัวข้ อของ Interface Specifications
School of Information and Communication Technology., University of Phayao
18
Graphical Notations
School of Information and Communication Technology., University of Phayao
19
Mathematical Specifications
Condition
Score >=80
70 <= Score < 80
60 <= Score < 70
50 <= Score < 60
Score < 50
Action
Set Grade = ‘A’
Set Grade = ‘B’
Set Grade = ‘C’
Set Grade = ‘D’
Set Grade = ‘F’
School of Information and Communication Technology., University of Phayao
20
Interface Specification
ซอฟต์ แวร์ ส่วนใหญ่ ท่ ีมีกำรใช้ งำนในองค์ กร จำเป็ นต้ องมีกำรปฎิบัติงำน
ร่ วมกับระบบเดิมที่มีอยู่ก่อนแล้ วในบริ ษัท จึงเป็ นข้ อจำกัดในกำรทำงำนที่
เรำต้ องทรำบ เช่ น บริ ษัทใช้ งำนฐ่ ำนข้ อมูล SQL Server 2000 แต่ เรำ
พัฒนำบน SQL Server 2010 ดังนัน้ คำสั่งบำงคำสั่งใน 2010 อำจจะไม่
สำมำรถใช้ ได้ กับ 2000
ดังนัน้ กำรเตรี ยมกำร Interface ระหว่ ำงระบบงำนใหม่ กับงำนเดิมจึงมีควำม
จำเป็ นอย่ ำงยิ่ง โดยสำมำรถแบ่ งกำร Interface ออกเป็ น 3 แบบ คือ
 Procedural Interfaces
 Data Structures
 Representations of Data
School of Information and Communication Technology., University of Phayao
21
Procedural Interfaces
เป็ นกำรเขียนโปรแกรมเพื่อเรี ยกใช้ งำน (Services) โปรแกรม
หรื อ ซั บ โปรแกรมที่ มี อ ยู่ แล้ วในระบบ บำงครั ้ ง เรี ยกว่ ำ
Application Programming Interfaces (APIs) เช่ น ในระบบปฎิบัติ
กำรวินโดว์ จะเรี ยกว่ ำ Windows APIs ซึ่งเป็ นโปรแกรม หรื อซับ
โปรแกรมที่ให้ บริกำรใน วินโดว์ อยู่แล้ ว เพื่อทำงำนบำงอย่ ำง
โดยที่นิสิตสำมำรถ CALL APIs ของ Windows มำใช้ ได้ โดยไม่
ต้ องสร้ ำง หรือเขียนโปรแกรมขึน้ มำใหม่
School of Information and Communication Technology., University of Phayao
22
Data Structures
เป็ นโครงสร้ ำงข้ อมูลที่ต้องมีกำรส่ ง และรั บ ระหว่ ำงระบบย่ อย
หนึ่ง ไปยังอีกระบบย่ อยหนึ่ง เช่ นกำร PASS BY VALUE /
REFERENCE ในภำษำ C++ หรือ Visual Basic เป็ นต้ น
School of Information and Communication Technology., University of Phayao
23
Representations of Data
กำรแทนข้ อมูลเพื่อรั บส่ งระหว่ ำงระบบย่ อย ส่ วนใหญ่ จะอยู่ใน
ระบบ Real-time System หรื อ Embedded ซึ่งเป็ นสมองกลฝั งตัว
ไว้ ในอุปกรณ์ อิเล็กทรอนิกส์ ต่ำง ๆ เช่ น
 การส่งข้ อมูลในรูปแบบของ Bit คาสัง่ ผ่าน RS-232 เพื่อให้ ห่นุ ยนต์
ทางาน
 การส่ ง ผ่ า นข้ อมู ล ในระบบเครื อ ข่ า ย ที่ ต้ องทราบต้ น ทาง และ
ปลายทาง รวมถึ ง รู ป แบบการเชื่ อ มต่อ ระหว่า งเครื อ ข่ า ย เช่ น ใน
โทรศัพท์มือถือ
School of Information and Communication Technology., University of Phayao
24
The Software Requirements Document
เอกสำรจัดเก็บควำมต้ องกำรของซอฟต์ แวร์ บำงครัง้ อำจเรียกว่ ำ
Software Requirements Specification: SRS)
เอกสำรจัดเก็บควำมต้ องกำร ต้ องทำกำรเปลี่ยนควำมต้ องกำร
ของผู้ใช้ และบุคคลที่เกี่ยวข้ องทัง้ หมด มำจัดทำให้อยู่ในรูปของ
เอกสำร โดยต้ องมีกำรจัดระดับของควำมต้ องกำร พิจำรณำจำก
ชนิดของระบบที่กำลังพัฒนำ รวมถึงกระบวนกำรในกำรพัฒนำ
ด้ วย
กรมกลำโหมสหรัฐอเมริกำ ร่ วมกัน IEEE ได้ กำหนดมำตรฐำน
สำหรับกำรจัดทำเอกสำรเพื่อจัดเก็บควำมต้ องกำรดังต่ อไปนี ้
School of Information and Communication Technology., University of Phayao
25
กลุ่มผู้ใช้ งำนเอกสำรควำมต้ องกำร
School of Information and Communication Technology., University of Phayao
26
โครงสร้ ำงของเอกสำร
Introduction
General Description
Specific Requirements
Appendices
Index
School of Information and Communication Technology., University of Phayao
27
Introduction
วัตถุประสงค์ ของเอกสำรควำมต้ องกำร (Purpose of the
Requirements Document)
ขอบเขตของผลิตภัณฑ์ (Scope of the Product)
คำจำกัดควำม, คำย่ อ และ อักษรย่ อ (Definitions,
Acronyms and Abbreviations)
เอกสำรอ้ ำงอิง (References)
ภำพรวมส่ วนที่เหลือของเอกสำร (Overview of the
Remainder of the Document)
School of Information and Communication Technology., University of Phayao
28
General Description
มุมมองของผลิตภัณฑ์ (Product Perspective)
ฟั งก์ ชันกำรทำงำนของผลิตภัณฑ์ (Product Functions)
ลักษณะของผู้ใช้ (User Characteristics)
ข้ อจำกัดทั่วไป (General Constraints)
สมมติฐำน และกำรอ้ ำงอิง (Assumptions and
Dependencies)
School of Information and Communication Technology., University of Phayao
29
Specific Requirements
ครอบคลุ ม Functional,
Non-Functional
และ Interface
Requirements ซึ่งเป็ นส่ วนที่มีเนือ้ หำมำกที่สุด แต่ เนื่ องจำกควำม
แตกต่ ำ งของมำตรฐำนในแต่ ล ะองค์ ก ร ท ำให้ ไ ม่ ส ำมำรถระบุ
โครงสร้ ำงมำตรฐำนลงไปในส่ วนนีไ้ ด้
โดยเอกสำรจะแสดงให้ เห็นถึงกำรปฎิสัมพันธ์ ระหว่ ำงภำยนอก
กั บ ระบบ ฟั งก์ ชั น กำรท ำงำนของระบบ ประสิ ท ธิ ภ ำพ ควำม
ต้ องกำรทำงด้ ำนฐำนข้ อมู ล เงื่อนไขกำรออกแบบ คุณลั กษณะ
ของระบบที่มีคุณภำพ
School of Information and Communication Technology., University of Phayao
30
Appendices
เอกสำรอื่นๆ ที่รวบรวมไว้ ในภำคผนวก
School of Information and Communication Technology., University of Phayao
31
Index
ดัชนีในกำรค้ นหำคำสำคัญ (Keyword) ที่ใช้ ในเอกสำร
School of Information and Communication Technology., University of Phayao
32
สรุ ป (1/4)
ควำมต้ องกำรในกำรพัฒนำซอฟต์ แวร์ สำมำรถแบ่ งได้ เป็ น 2 ส่ วน
คือ
 User Requirements คือ ความต้ องการที่ได้ จากผู้ใช้ ซึง่ จะมี ลกั ษณะ
เป็ นนามธรรม (Abstract)
 System Requirements คือ ความต้ องการของระบบ เป็ นสิ่งที่ขยาย
ออกมาจากความต้ อ งการของผู้ใ ช้ อาจมี บ างส่ว นไม่อ ยู่ใ นความ
ต้ องการของผู้ใช้ ก็ได้ แต่ระบบจาเป็ นที่จะต้ องมี
School of Information and Communication Technology., University of Phayao
33
สรุ ป (2/4)
ควำมต้ องกำรของระบบซอฟต์ แวร์ แบ่ งได้ ออกเป็ น 3 ประเภท คือ
 Functional Requirements เป็ นสิ่งที่ระบบต้ องให้ บริ การ และวิธีการ
ที่ระบบจะตอบสนองต่อข้ อมูลเข้ า ภายใต้ สถานการณ์ตา่ ง ๆ กัน
 Non-Functional Requirements เป็ นเงื่อนไขในการให้ บริ การ หรื อ
ดาเนินการเกี่ยวกับฟั งก์ชนั ที่กระทากับระบบ รวมถึง มาตรฐาน และ
เวลาที่ใช้ กับระบบทังหมด
้
 Domain
Requirements เป็ นความต้ องการตามลักษณะของ
แอพพลิ เ คชั่น ที่ ท างานในระบบ ซึ่ง อาจเป็ นฟั ง ก์ ชัน หรื อ ไม่ เ ป็ น
ฟั งก์ชนั ก็ได้
School of Information and Communication Technology., University of Phayao
34
สรุ ป (3/4)
กำรที่ จ ะท ำควำมเข้ ำใจระหว่ ำงควำมต้ องกำรของผู้ ใช้ และวิ ศ วกร
ซอฟต์ แวร์ ให้ เข้ ำใจตรงกันนัน้ สำมำรถใช้ สัญลักษณ์ แทนคำอธิบำยเพื่อให้
ได้ ควำมหมำยที่ตรงกัน ประกอบด้ วย
 Structured Natural Language คือ การสร้ างฟอร์ มมาตรฐาน หรื อแม่แบบ
สาหรับจัดเก็บความต้ องการ (การบ้ าน PSP)
 Design Description Languages คือ การสร้ าง Abstract สาหรับ Interface
Specification คล้ ายเขียนฟั งก์ชนั การทางานไว้ ก่อน แต่ยงั ไม่มี
 Graphical Notations คือ การใช้ ภาพแสดงแทนข้ อความ เช่น USE-CASE
และ Sequence Diagram เป็ นต้ น
 Mathematical Specifications คือการใช้ สญา
ั ลักษณ์ ทางคณิตศาสตร์ มาใช้
อธิบายเช่น Finite-State Machine หรื อ SET เป็ นต้ น
School of Information and Communication Technology., University of Phayao
35
สรุ ป (4/4)
Interface Specification เป็ นกำรออกแบบเพื่อให้ สำมำรถเชื่อมต่ อ
กับ ระบบงำนเดิมของบริ ษัท ได้ เนื่ องจำก สถำปั ตยกรรม และ
สิ่งแวดล้ อมของบริ ษัท จะเป็ นข้ อจำกัดในกำรพัฒนำระบบที่เรำ
ต้ องทรำบ
The Software Requirement Document เป็ น เอกสำรจัดเก็บควำม
ต้ องกำร ต้ องทำกำรเปลี่ยนควำมต้ องกำรของผู้ใช้ และบุคคลที่
เกี่ยวข้ องทัง้ หมด มำจัดทำให้ อยู่ในรู ปของเอกสำร โดยต้องมีกำร
จัดระดับของควำมต้ องกำร พิจำรณำจำกชนิดของระบบที่กำลัง
พั ฒ นำ รวมถึ ง กระบวนกำรในกำรพั ฒ นำ โดยมี ก ำรก ำหนด
รูปแบบมำตรำฐำนกำรจัดเก็บจำก กรมกลำโหมสหรัฐ และ IEEE
School of Information and Communication Technology., University of Phayao
36
The Software Requirements Document
เอกสำรจัดเก็บควำมต้ องกำรของซอฟต์ แวร์ บำงครัง้ อำจเรียกว่ ำ
Software Requirements Specification: SRS)
เอกสำรจัดเก็บควำมต้ องกำร ต้ องทำกำรเปลี่ยนควำมต้ องกำร
ของผู้ใช้ และบุคคลที่เกี่ยวข้ องทัง้ หมด มำจัดทำให้อยู่ในรูปของ
เอกสำร โดยต้ องมีกำรจัดระดับของควำมต้ องกำร พิจำรณำจำก
ชนิดของระบบที่กำลังพัฒนำ รวมถึงกระบวนกำรในกำรพัฒนำ
ด้ วย
กรมกลำโหมสหรัฐอเมริกำ ร่ วมกัน IEEE ได้ กำหนดมำตรฐำน
สำหรับกำรจัดทำเอกสำรเพื่อจัดเก็บควำมต้ องกำรดังต่ อไปนี ้
School of Information and Communication Technology., University of Phayao
37
References
 Ian Sommerville. Software Engineering 8th
Edition. Addison Wesley Publishers., 2007
 Watts S Humphrey. A Self Improvement Process
for Software Engineers. Addison Wesley
Professional., 2005
 Software Engineering Institute | Carnegie Mellon.
[online] http://www.sei.cmu.edu/., 2010
School of Information and Communication Technology., University of Phayao
38