Update IEEE_SRS_TEMPLATE.md.

IEEE_SRS_TEMPLATE.md

@@ -239,26 +239,75 @@ __________
 
 ### 5.1 Performance Requirements
 
+*If there are performance requirements for the product under various
+circumstances, state them here and explain their rationale, to help the
+developers understand the intent and make suitable design choices. Specify the
+timing relationships for real time systems. Make such requirements as specific
+as possible. You may need to state performance requirements for individual
+functional requirements or features.*
+
 ### 5.2 Safety Requirements
 
+*Specify those requirements that are concerned with possible loss, damage, or
+harm that could result from the use of the product. Define any safeguards or
+actions that must be taken, as well as actions that must be prevented. Refer to
+any external policies or regulations that state safety issues that affect the
+product’s design or use. Define any safety certifications that must be
+satisfied.*
+
 ### 5.3 Security Requirements
 
+*Specify any requirements regarding security or privacy issues surrounding use
+of the product or protection of the data used or created by the product. Define
+any user identity authentication requirements. Refer to any external policies or
+regulations containing security issues that affect the product. Define any
+security or privacy certifications that must be satisfied.*
+
 ### 5.4 Software Quality Attributes
 
+*Specify any additional quality characteristics for the product that will be
+important to either the customers or the developers. Some to consider are:
+adaptability, availability, correctness, flexibility, interoperability,
+maintainability, portability, reliability, reusability, robustness, testability,
+and usability. Write these to be specific, quantitative, and verifiable when
+possible. At the least, clarify the relative preferences for various attributes,
+such as ease of use over ease of learning.*
+
 ### 5.5 Business Rules
 
+*List any operating principles about the product, such as which individuals or
+roles can perform which functions under specific circumstances. These are not
+functional requirements in themselves, but they may imply certain functional
+requirements to enforce the rules.*
+
 __________
 
 ## 6. Other Requirements
 
+*Define any other requirements not covered elsewhere in the SRS. This might
+include database requirements, internationalization requirements, legal
+requirements, reuse objectives for the project, and so on. Add any new sections
+that are pertinent to the project.*
+
 __________
 
 ## Appendix A: Glossary
 
+*Define all the terms necessary to properly interpret the SRS, including
+acronyms and abbreviations. You may wish to build a separate glossary that spans
+multiple projects or the entire organization, and just include terms specific to
+a single project in each SRS.*
+
 __________
 
 ## Appendix B: Analysis Models
 
+*Optionally, include any pertinent analysis models, such as data flow diagrams,
+class diagrams, state-transition diagrams, or entity-relationship diagrams.*
+
 __________
 
 ## Appendix C: To Be Determined List
+
+*Collect a numbered list of the TBD (to be determined) references that remain in
+the SRS so they can be tracked to closure.*