4.2 Environment of the SRSIt is imp

4.2 Environment of the SRS
It is important to consider the part that the SRS plays in the total project plan, which is defined in IEEE Std
610.12-1990. The software may contain essentially all the functionality of the project or it may be part of a
larger system. In the latter case typically there will be an SRS that will state the interfaces between the
system and its software portion, and will place external performance and functionality requirements upon
the software portion. Of course the SRS should then agree with and expand upon these system requirements.
IEEE Std 1074-1997 describes the steps in the software life cycle and the applicable inputs for each step.
Other standards, such as those listed in Clause 2, relate to other parts of the software life cycle and so may
complement software requirements.
Since the SRS has a specific role to play in the software development process, the SRS writer(s) should be
careful not to go beyond the bounds of that role. This means the SRS
a) Should correctly define all of the software requirements. A software requirement may exist because
of the nature of the task to be solved or because of a special characteristic of the project.
b) Should not describe any design or implementation details. These should be described in the design
stage of the project.
c) Should not impose additional constraints on the software. These are properly specified in other
documents such as a software quality assurance plan.
Therefore, a properly written SRS limits the range of valid designs, but does not specify any particular
design.

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

4.2 สิ่งแวดล้อมของ SRSสิ่งสำคัญคือการพิจารณาส่วนที่ SRS เล่นแผนโครงการ การที่กำหนดไว้ในมาตรฐาน IEEE610.12-1990. ซอฟต์แวร์นี้อาจประกอบด้วยหลักฟังก์ชันทั้งหมดของโครงการ หรืออาจเป็นส่วนหนึ่งของการระบบขนาดใหญ่ ในกรณีหลัง มักจะมี SRS ที่จะรัฐอินเทอร์เฟซระหว่างการระบบและส่วนของซอฟต์แวร์ และจะวางความต้องการและใช้งานภายนอกตามส่วนซอฟต์แวร์ แน่นอน SRS ควรแล้วยอมรับ และขยายตามความต้องการของระบบเหล่านี้IEEE Std 1074-1997 อธิบายขั้นตอนในวงจรชีวิตของซอฟต์แวร์และใช้ปัจจัยการผลิตสำหรับแต่ละขั้นตอนเกี่ยวข้องกับส่วนอื่น ๆ ของวงจรชีวิตซอฟต์แวร์มาตรฐานอื่น ๆ เช่นที่ระบุไว้ในข้อ 2 และดังนั้น อาจเติมเต็มความต้องการซอฟต์แวร์ตั้งแต่ SRS มีบทบาทเฉพาะการเล่นในกระบวนการพัฒนาซอฟต์แวร์ ควรจะ SRS writer(s)ระวังอย่าไปเกินกว่าขอบเขตของบทบาทที่ หมายความว่า SRS) ควรถูกกำหนดทั้งหมดของข้อกำหนดของซอฟต์แวร์ ความต้องการซอฟต์แวร์อาจมีอยู่เนื่องจากลักษณะ ของงานได้รับการแก้ไข หรือเนื่อง จากลักษณะพิเศษของโครงการb) ควรอธิบายรายละเอียดการใช้งานหรือออกแบบ เหล่านี้ควรอธิบายในการออกแบบขั้นตอนของโครงการc) ควรกำหนดข้อจำกัดเพิ่มเติมซอฟต์แวร์ เหล่านี้อย่างถูกต้องได้ระบุไว้ในที่อื่น ๆเอกสารเช่นแผนการประกันคุณภาพซอฟต์แวร์ดังนั้น SRS เขียนอย่างถูกต้องจำกัดช่วงของการออกแบบที่ถูกต้อง แต่ไม่ได้ระบุเฉพาะใด ๆการออกแบบ

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

4.2 สภาพแวดล้อมของ SRS
มันเป็นสิ่งสำคัญที่จะต้องพิจารณาเป็นส่วนหนึ่งที่ SRS เล่นในแผนโครงการทั้งหมดซึ่งถูกกำหนดไว้ในมาตรฐาน IEEE Std
610.12-1990 ซอฟต์แวร์อาจมีหลักทุกฟังก์ชันการทำงานของโครงการหรือมันอาจเป็นส่วนหนึ่งของ
ระบบที่มีขนาดใหญ่ ในกรณีหลังนี้มักจะจะมี SRS ที่จะระบุการเชื่อมต่อระหว่าง
ระบบและเป็นส่วนหนึ่งของซอฟแวร์และจะวางประสิทธิภาพการทำงานและความต้องการใช้งานภายนอกเมื่อ
ส่วนซอฟแวร์ ของหลักสูตร SRS แล้วควรจะเห็นด้วยกับการขยายความและความต้องการของระบบเหล่านี้.
IEEE Std 1074-1997 อธิบายขั้นตอนในวงจรชีวิตของซอฟต์แวร์และปัจจัยการผลิตที่ใช้บังคับสำหรับแต่ละขั้นตอน.
มาตรฐานอื่น ๆ เช่นที่ระบุไว้ในข้อ 2, ความสัมพันธ์กับคนอื่น ๆ ชิ้นส่วนของวงจรชีวิตของซอฟแวร์และอื่น ๆ อาจจะ
เติมเต็มความต้องการซอฟต์แวร์.
ตั้งแต่ SRS มีบทบาทเฉพาะในการเล่นในกระบวนการพัฒนาซอฟต์แวร์นักเขียน SRS (s) ควรจะ
ระวังไม่ให้ไปเกินขอบเขตของบทบาทว่า ซึ่งหมายความว่า SRS
) ที่ถูกต้องควรกำหนดทุกความต้องการของซอฟแวร์ ความต้องการซอฟต์แวร์ที่อาจมีอยู่เนื่องจาก
ลักษณะของงานที่จะแก้ไขหรือเพราะลักษณะพิเศษของโครงการ.
ข) ไม่ควรอธิบายการออกแบบหรือการดำเนินงานรายละเอียดใด ๆ เหล่านี้ควรจะอธิบายไว้ในการออกแบบ
ขั้นตอนของโครงการ.
ค) ไม่ควรกำหนดข้อ จำกัด เพิ่มเติมเกี่ยวกับซอฟแวร์ เหล่านี้มีการระบุไว้อย่างถูกต้องอื่น ๆ ใน
เอกสารดังกล่าวเป็นแผนประกันคุณภาพซอฟต์แวร์.
ดังนั้นที่เขียนถูกต้อง SRS จำกัด ช่วงของการออกแบบที่ถูกต้อง แต่ไม่ได้ระบุใด ๆ โดยเฉพาะ
การออกแบบ

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

4.2 สภาพแวดล้อมของ SRSมันเป็นสิ่งสำคัญที่จะต้องพิจารณาส่วนที่ SRS เล่นในแผนโครงการทั้งหมด ซึ่งกำหนดไว้ใน IEEE Std610.12-1990 . ซอฟต์แวร์อาจมีหลักทั้งหมดการทำงานของโครงการ หรือมันอาจเป็นส่วนหนึ่งของระบบขนาดใหญ่ ในกรณีหลังนี้โดยปกติจะมี SRS จะระบุการเชื่อมต่อระหว่างส่วนของระบบและซอฟต์แวร์ และสถานที่ภายนอกและความต้องการประสิทธิภาพการทำงานบนซอฟต์แวร์ส่วน แน่นอนว่า SRS แล้วควรเห็นด้วย ขยายตามความต้องการของระบบเหล่านี้IEEE Std 1074-1997 อธิบายขั้นตอนในซอฟต์แวร์วงจรชีวิตและกระผมสามารถใช้ได้สำหรับแต่ละขั้นตอนมาตรฐานอื่น ๆเช่นที่ระบุไว้ในข้อ 2 มีความสัมพันธ์กับส่วนอื่น ๆของซอฟต์แวร์วงจรชีวิตและอาจเติมเต็มความต้องการของซอฟต์แวร์ตั้งแต่ SRS มีบทบาทเฉพาะเล่นในกระบวนการพัฒนาซอฟต์แวร์ , SRS นักเขียน ( s ) ควรระวังไม่ไปไกลกว่าขอบเขตของบทบาทที่ ซึ่งหมายความว่า SRS) ควรถูกกำหนดทั้งหมดของซอฟต์แวร์ตามความต้องการ ความต้องการซอฟต์แวร์ที่อาจมีอยู่ เพราะของธรรมชาติของงานที่ต้องแก้ไข หรือเป็นเพราะลักษณะพิเศษของโครงการข ) ไม่ควรจะอธิบายการออกแบบใด ๆหรือรายละเอียดการใช้งาน เหล่านี้ควรจะอธิบายในการออกแบบขั้นตอนของโครงการc ) ไม่ควรกำหนดข้อจำกัดเพิ่มเติมเกี่ยวกับซอฟต์แวร์ เหล่านี้จะถูกระบุไว้ในอื่น ๆเอกสาร เช่น การประกันคุณภาพซอฟต์แวร์แผนจึงถูกเขียน SRS จำกัดช่วงของการออกแบบที่ถูกต้อง แต่ไม่ได้ระบุเฉพาะเจาะจงใด ๆการออกแบบ