Here are some key guidelines to wri

Here are some key guidelines to writing a software requirements specification (SRS)"
1. Requirement Modeling asks, "What", not "How". What user interactions are involed, what objects are manipulated, what functions must be performed, what behaviors does system have, what interfaces, and what constraints apply?
2. Keep in mind the 3 goals of the SRS:
a. Describe 100%
b. Create enough information for the next step: software design. This information may include sample user documents currently used such as excel sheets, printed reports, etc. shown with the requirements description or placed in appendix section.
c. Define requirements that can be validated as "done" once design is completed and again when software is built.
3. Pretty diagrams can help but can also be confusing. Use more description in as text (called narratives), table, and charts along with simple diagrams. Key point is to have clear requirements, not just pretty diagrams.
4. Make sure you spend time to detail even the complicated requirements. Otherwise, unclear information will come back to bite you during design and coding phases.
5. Don't make it too long. Watch out for over-documenting those functions that are already well understood.
6. Keep the SRS up to date as you make changes during late phases such as design and coding phases.
7.Approximately 20% of the project time should be allocated to requirements definition.
8. A good requirements document will have enough detail to create the software design document and the test plan.

ผลลัพธ์ (ไทย) 1:

ที่นี่มีแนวทางสำคัญในการเขียนที่ระบุข้อกำหนดซอฟต์แวร์ (SRS)"1. ต้องสร้างโมเดลถาม "สิ่ง" ไม่ "วิธีการ" Involed สิ่งวัตถุมีอะไรโต้ตอบผู้ใช้จะจัดการ อะไรหน้าที่ต้องดำเนินการ ระบบมีพฤติกรรมอะไร สิ่งเชื่อมต่อ และใช้งานของข้อจำกัด2. เก็บไว้ในใจ 3 เป้าหมายของ SRS: ก.อธิบาย 100% b. สร้างข้อมูลเพียงพอสำหรับขั้นตอนถัดไป: การออกแบบซอฟต์แวร์ ข้อมูลนี้อาจรวมถึงผู้ใช้อย่างเอกสารที่ใช้ในปัจจุบันเช่น excel ของแผ่น พิมพ์รายงาน ฯลฯ ที่อยู่ในภาคผนวก หรือแสดงพร้อมคำอธิบายความต้องการได้ ต้องการกำหนดค.ที่สามารถตรวจสอบได้ "ทำ" เมื่อออกแบบ เสร็จเรียบร้อยแล้ว และอีกครั้ง เมื่อซอฟต์แวร์สร้าง3 แผนภาพสวยช่วย แต่อาจสับสน ใช้อธิบายเพิ่มเติมในข้อความ (เรียกว่าเรื่องเล่า), ตาราง และแผนภูมิพร้อมกับไดอะแกรมอย่างง่าย จุดสำคัญคือการ มีข้อกำหนดชัดเจน ไม่ใช่แค่สวยไดอะแกรม4. ตรวจสอบว่า คุณใช้เวลาในรายละเอียดแม้กระทั่งความซับซ้อน มิฉะนั้น ข้อมูลไม่ชัดเจนจะกลับมากัดคุณในระหว่างการออกแบบและขั้นตอนการเขียนโค้ด5. ไม่ทำให้ยาวเกินไป ดูออกสำหรับมากกว่าเอกสารฟังก์ชันที่จะเข้าใจแล้ว6. เสมอ SRS เป็นคุณทำการเปลี่ยนแปลงในช่วงระยะเวลาเช่นการออกแบบและเขียนระยะ7.ประมาณ 20% ของโครงการควรปันส่วนนิยามความต้องการ8. เอกสารความต้องการที่ดีจะมีรายละเอียดเพียงพอเพื่อสร้างเอกสารการออกแบบซอฟต์แวร์และแผนทดสอบ

ผลลัพธ์ (ไทย) 2:

นี่คือบางส่วนแนวทางที่สำคัญในการเขียนข้อกำหนดความต้องการซอฟต์แวร์ (SRS) คือ "
1. การสร้างแบบจำลองความต้องการถามว่า" อะไรคือ "ไม่" วิธีการ ". สิ่งที่ผู้ใช้โต้ตอบ involed สิ่งที่วัตถุที่มีการจัดการสิ่งที่ฟังก์ชั่นจะต้องทำสิ่งที่พฤติกรรมไม่ ระบบได้สิ่งที่อินเตอร์เฟซและสิ่งที่ใช้ จำกัด ?
2. เก็บไว้ในใจ 3 เป้าหมายของ SRS:
a. อธิบาย 100%
B สร้างข้อมูลเพียงพอสำหรับขั้นตอนต่อไปนี้.. การออกแบบซอฟต์แวร์ข้อมูลนี้อาจรวมถึงเอกสารของผู้ใช้กลุ่มตัวอย่างที่ใช้ในปัจจุบัน เช่นแผ่น Excel, พิมพ์รายงาน ฯลฯ แสดงด้วยคำอธิบายที่ต้องการหรือวางไว้ในส่วนภาคผนวก.
ค. กำหนดความต้องการที่สามารถตรวจสอบได้ว่า "ทำ" ครั้งหนึ่งการออกแบบเป็นที่เรียบร้อยแล้วและอีกครั้งเมื่อซอฟต์แวร์ที่ถูกสร้างขึ้น.
3. แผนภาพสวยสามารถช่วย แต่ยังสามารถทำให้เกิดความสับสน. ใช้คำอธิบายมากขึ้นในการเป็นข้อความ (เรียกว่าเรื่องเล่า) ตารางและแผนภูมิพร้อมกับไดอะแกรม Simple. จุดสำคัญคือการมีความต้องการที่ชัดเจนไม่ได้เป็นเพียงไดอะแกรมสวย.
4. ให้แน่ใจว่าคุณใช้เวลาในรายละเอียดแม้กระทั่ง ความต้องการที่ซับซ้อน มิฉะนั้นข้อมูลที่ชัดเจนจะกลับมากัดคุณในระหว่างขั้นตอนการออกแบบและการเข้ารหัส.
5 อย่าทำให้มันยาวเกินไป ดูจากการจัดเก็บเอกสารมากกว่าฟังก์ชั่นที่มีอยู่แล้วเข้าใจดี.
6 เก็บ SRS ถึงวันที่คุณทำการเปลี่ยนแปลงในช่วงปลายขั้นตอนเช่นการออกแบบและขั้นตอนการเข้ารหัส.
7.Approximately 20% ของเวลาโครงการควรจะจัดสรรให้นิยามความต้องการ.
8 เอกสารความต้องการที่ดีจะมีรายละเอียดเพียงพอที่จะสร้างเอกสารการออกแบบซอฟแวร์และการวางแผนการทดสอบ