1. CONTENTS OF THE SRS REPORT

2. Software Requirements Specification (SRS) template The SRS document describes recommended approaches for the specification of software requirements. It is based on a model in which the result of the software requirements specification process is an unambiguous, correct, and complete specification document. 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.

3. 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. Should not describe any design or implementation details. These should be described in the design stage of the project.

4. The basic issues that the SRS writer(s) shall address are the following: a) Functionality. What is the software supposed to do? b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software? c) Performance. What is the speed, availability, response time, recovery time of various software functions etc.? d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations? e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?”[1]

5. TITLE PAGE The title page should include: University, College, and Department centered University logo on right hand side Project logo just above the title Student names in alphabetical order, along with the IDs. Supervisor name Year and semester in HIjrii and Gregorian

6. PROJECT SCOPE Project scope is the boundary of the project. Think of the “project scope” as an imaginary box you are describing that will enclose all the activities for the team’s activities. It not only defines what you are doing, but it sets the boundaries on what the team will not be doing. Scope answers what’s inside the box? What’s outside the box? What is the project going to look like? How much is your project going to contain?

7. USER CHARCTARISTICS “This subsection of the SRS should describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise. It should not be used to state specific requirements, but rather should provide the reasons why certain specific requirements are later specified in Section 4 of the SRS.”[1]

8. SPECIFIC REQUIREMENTS “This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. The following principles apply: a) Specific requirements should be stated in conformance with all of the requirements characteristics. b) All requirements should be uniquely identifiable. c) Careful attention should be given to organizing the requirements to maximize readability.”[1]

9. USER REQUIREMENTS AND SYSTEM REQUIREMENTS User requirements should determine the different software services required by the customer, in a high level natural language. Then for each user requirement, system requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed as “shall” statements starting with “The system shall”

10. NON FUNCTIONAL REQUIREMENTS This section should answer all the special constraints and considerations in the project, i.e.: What are the factors required to establish the required reliability of the software system at time of delivery? What are the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. ? What are the factors required to protect the software from accidental or malicious access, use, modification, destruction, or disclosure? What are the different attributes of software that relate to the ease of maintenance of the software? What is the speed, availability, response time, recovery time of various software functions, etc.?

11. SYSTEM MODELS This section should illustrate the system models that reflect the overall system processes from different perspectives according to the software type. Either as: 1-Behavioural Models: Data processing models that show how data is processed as it moves through the system (Data Flow Diagram and Entity Relation diagram). 2- OR Object Models: Use case diagrams and Class diagram.

12. References: [1] IEEE (1998) IEEE Recommended Practice for Software Requirements Specifications.IEEE Std 830-1998 (Revision of IEEE Std 830-1993) The Institute of Electrical and Electronics Engineers, Inc GUIDE FOR WRITING A PROJECT SRS,Prepared by: Maha Al-Yahya and Latifa AlAbdulkarim