King Saud University College of Computer and Information Sciences Information Technology Department GUIDE FOR WRITING A PROJECT SRS DOCUMENT PREPARED FOR I T3 2 2 : S W E N G I N E E R I N G P R O J E C T Version: 3 Date: October 2010 Prepared by: Maha AlYahya and Latifa AlAbdulkarim Updated by: Latifa AlAbdulkarim Guide for writing a project SRS Document INTRODUCTION “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. 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. 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] STYLE CONVENTIONS FORMAT The SRS document should be typed. All text, Figures and Tables should appear on only one side of each sheet of paper. All pages other than the cover sheet should have page numbers that begin with “1” on the first page after the title page, and should continue through the last page of the reference page, but not the appendices. The right-hand margin should be 1.5 cm and the upper and lower margins 2 - 2.5 cm. The left-hand margin must be 4 cm on each page of the document because of the binding. The margin instructions should be followed in the appendices as well. The font size in the text should be in 12, in subsections 12 and in the main headings 14. The main headings are to be written in capitals and placed at the beginning of a new page. All headings are to be in bold letters. Leave two empty lines under the main heading, two empty lines above the subsection and one empty line under it. The headings should not Page 2 Guide for writing a project SRS Document have more than three numbers. A line spacing of 1.5 should be used in the text, 1 on the title page and in the abstract. The font to be used is Times New Roman. The page number is placed in the lower right corner. The text should not be indented and both margins on the page should be justified. When a paragraph continues on the next page, at least two lines of the paragraph should be left on the upper or lower end of the page. The paragraphs are separated from each other and from the headings with one empty line. A new chapter is started on a new page. One empty line is needed to separate two paragraphs. TEXT The text of the report should be written in complete sentences. The style should be formal. Formal style means to avoid slang, clichés, abbreviations that are common in spoken English or advertising. It is convention that formal reports are written in the third person. FIGURES AND TABLES All Figures and Tables should have a number and a caption. If a figure or table is extracted from a source, the source should be cited in the references. Page 3 Guide for writing a project SRS Document SRS REPORT CONTENTS The Software Requirements Specification document should include the following components: TITLE PAGE The title page should include: University, College, and Department centered University logo on right hand side Project logo just above the title Project title: The title should be a stand-alone statement that can fully describe the project by summarizing the main idea of the project. The title is supremely important. A successful title will attract readers while an unsuccessful one will discourage readers. Compose trial versions of the title as early as you can. Student names in alphabetical order, along with the IDs. Supervisor name Year and semester in HIjrii and Gregorian TABLE OF CONTENTS A table of contents should list each of the main sections of the SRS report, and the beginning page numbers for each section. INTRODUCTION “The introduction of the SRS should provide an overview of the entire SRS document. I.e. It should answer the following: a) Describe what the rest of the SRS contains. b) Explain how the SRS is organized.”[1] 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? Page 4 Guide for writing a project SRS Document 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] REQUIREMENTS DETERMINATION This section of the SRS document should show the different methods that the analysts have used in determining the requirements. Either by doing a) Literature review: By searching, assessing and comparing the features of similar existing systems using the table below. Add a" √” in the cell, where a specific feature is available in that system. Sys1 Sys2 Sys3 Sys4 Sys5 F1 F2 F3 F4 F5 … b) Stakeholder(s) Interview(s): In this subsection you should show the interview transcript that you have used to collect the interview details, and a summary of the interview. c) Questionnaire : In this subsection , you should show: 1. A sample of the analysts’ questionnaire. 2. Questionnaire results analysis table. 3. A summary of the outcomes. 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. These requirements should include at a minimum a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output. As this is often the largest and most important part of the SRS, 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] Page 5 Guide for writing a project SRS Document 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” “These include a) Validity checks on the inputs b) Exact sequence of operations c) Responses to abnormal situations, including 1) Overflow 2) Communication facilities 3) Error handling and recovery e) Relationship of outputs to inputs, including 1) Input/output sequences 2) Formulas for input to output conversion It may be appropriate to partition the functional requirements into sub functions or sub processes.” [1] Specific requirements format: 1. User requirement 1.1. System requirement 1 1.2. System requirement 2 1.3. System requirement 3 1.4. …..and so on. You may also define the system requirements as use cases, if you are going to deal with the system as objects: Use case: <Usecase name> Actor stimulus System response Priority Precondition(s) Postcondition(s) Page 6 Guide for writing a project SRS Document NON FUNCTIONAL REQUIREMENTS This section should answer all the special constraints and considerations in the project, i.e.: a) What are the factors required to establish the required reliability of the software system at time of delivery? b) What are the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. ? c) What are the factors required to protect the software from accidental or malicious access, use, modification, destruction, or disclosure? d) What are the different attributes of software that relate to the ease of maintenance of the software? e) What is the speed, availability, response time, recovery time of various software functions, etc.? 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, sequential diagrams, conceptual diagrams Class diagram. These models should be illustrated by data dictionaries that lists all of the names (entities, relationships, and attributes) used in the system models as in the table below: Name Description Type REFERENCES Always give complete citations for material on other sources. A proper reference involves two components: the citation in the text and the complete bibliographic entry in the References section. Use the Institute of Electrical and Electronics Engineers (IEEE) style for referencing. For more information see http://wwwlib.murdoch.edu.au/find/citation/ieee.html APPENDICES An appendix is included at the end of the report. It contains information referred to in the report that's too large to fit in the body of the report. Provide any appendices you have in this section. Page 7 Guide for writing a project SRS Document Appendices include the material needed for the report but which is unnecessary to include in the text itself (sample agreement form with client, graphs, and interview forms). The appendices must be referred to in the text and they must have all the necessary information needed for interpretation. Appendices are situated at the end of the thesis and numbered consecutively. The written form for reference to appendices within the text is: Appendix 1, Appendix 2, etc. In the References it is: APPENDIX 1, APPENDIX 2, etc. REFERENCES FOR THIS GUIDE [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. Page 8