Guidelines for Software Requirement and Specification

Title Page, Group # and contact persons email address

Names and Ids Document title (and subtitle if applicable) Date ???
Table of Contents, List of Tables, List of Figures, Abstract Sometimes, depending on your target audience, the abstract is placed first (i.e. Before the title page). You might choose to do this if, for example, you are handing the document to an highlevel executive. The reasoning here being that the executive may never read the document, but if the abstract is visible without opening the document then theres a better chance that they will read it (especially if it is short). If this where your goal then you would use a clear cover when you bind the document. 1.0 Introduction 1.1 Purpose What is in this document? Why does this document exist? Who is the intended audience(s)? What is/are the intended purpose(s) of this document 1.2 Scope This doc is an extension of the original SRSso state this here What is the relationship between this doc and the original SRS? How should the two be viewed in the future? (answer: they combine to form a complete specification) 1.3 Definitions and Conventions Are there any special terms used in this document? What do references to other documents look like? 1.4 References Include a list of all documents that you refer to. References can also be placed at the end of the document. I prefer to put them in the intro when possible. That is, when there are less than 6 references. I prefer this because the reader read the list quickly thus they will know what documents your shortforms (e.g. [OAMSRS]) refer to. 1.5 Overview Describe the remaining sections of this document and their contents 2.0 General Description 2.1 Product Perspective

See SRS section 2.1 and (for OAM projects) section 2.3 2.2 Product Functions What new use cases now apply to the system? Note: Internationalize System is not a Use Case Another way to look at this: What does it mean to the user to internationalize the system? What can a user do the system that he or she could not do before? What can the system do to the User/Subscriber that it could not do before? What about the Administrator/Operator? 2.3 User Characteristics (subscribers and the operator) How has your view of the user changed? How do these changes alter the requirements of the system? 2.4 Legacy Constraints You are modifying an existing systemthat system runs on a specific platform 2.5 Implementation Requirements

The implementation of the internationalization requirement will allow support of new languages to be added with relative ease. To illustrate what is meant by relative ease consider the following example: if language resource files are used in the implementation, the addition of a new language, say German, should require only that the location of a German language resource file be provided to the OAM software system.
2.6 General Constraints Additional constraints on the system not covered in the sections above. Any restrictions on Call Forwarding? Any restrictions on Internationalization? E.g. Languages? 2.7 Assumptions and Dependencies The section title is clear enough Any questions? I had 2 things here, but its possible you wont come up with any. 3.0 Specific Requirements 3.1 External Interface Requirements 3.1.1 User interface VoIP: Id be nice if you could enable/disable call forwarding on an account but this is not required. CU: nothing here OAM/VoIP: Most forms will be easy to convert to French but some will require that you reposition the widgets or even add new widgets <==big hint. -Include an English picture of forms with new widgets -Include an English before picture and a French after picture for forms that require rearranging -Include a few representative examples of forms that are easy to convert.

There may be more types of conversionsdont miss them. Overall, you should aim for clarityif that means including 10 pictures then do it. 3.1.2 Software Interface 3.1.3 Hardware Interface 3.2 Behavior Requirements A use case diagram for all new use cases and a table describing the use case (just like you did in 451/445) 3.2.1 3.2.2 3.2.3 Object and/or Process Structure Requirements What new objects need to be added to your model? Dynamic Requirements Cut Functional Requirements New and modified State machines New and modified Scenarios And an English description of these diagrams.

3.3 Performance Requirements What effect should you enhancements have on performance? 3.4 Accuracy Requirements What effect should you enhancements have on performance? 3.5 Non-behavioral Requirements Refer to SRS 4.0 Data Dictionary Look at the sections in the DD of your SRS. What needs to be added to the SRS in order to make it complete. Focus will be put on section 3. In section 3.2, you will have to present the changes in your UML and SDL diagrams. This will include new objects, their attributes, new processes, new state diagrams, etc.

B. Software Detailed Design

1.0 Introduction & Overview 1.1 Purpose 1.2 Document Overview 2.0 Overall Design 2.1 Modules 2.2 Data structure/DB scheme 3.0 Data Dictionary 4.0 Conventions 4.1 Naming Conventions 4.2 Programming Conventions

The focus will be on section 2. You will need to describe all your new modules and changes to modules for each subsystem. A developer must be able to implement the enhancements once he or she reads your SDD. It would be wise to describe any (important) new procedures, their purpose, parameters and so on. Additional notes: Some sections may not be applicable to your project. In that case, you may omit them. Feel free to add sections to improve the accuracy or clarity of your documents. The SRS and the SDD are complete documents on their own. Therefore, you will need the following sections as well: Abstract, Table of Contents, Table of Figures, and References.