CMSC 345

Software Design and Development

 Fall 2004

 

 

System Requirements Specification  (SRS)

Guidelines

 

 

 

 

General Instructions

 

  1. Provide a cover page that includes the document name, product name, customer name, team name, team member names, and date.
  2. Number the pages of the document.
  3. Number and label all figures.  Refer to the figures by number in the text.
  4. All sections should have an introductory sentence or two.
  5. Be direct, do not use vague words and phrases such as may, might, could, possibly, should, assumed to be, some, a little, and a lot. Use strong, definite words and phrases such as shall, will, will not, can, and cannot.
  6. Watch your spelling, punctuation, and grammar.  It does  reflect well on your group to have such errors.

 

Be sure that your document is

 

 

Remember to do a peer review of this document!

 

When you think you are done with the SRS, ask yourself, "Could someone who was not part of the development of this SRS write a  corresponding System Design Document?"

 

Product name here

System Requirements Specification

 

 

 

Table of Contents

 

 

                                                                                                                                    Page

 

1.  Introduction

Rectangular Callout: Never produce a TOC by hand, use Word or whatever other tool you want to make the TOC.
 


1.1    Purpose of This Document

1.2    References

1.3    Purpose of the Product

1.4    Product Scope

 

 

2.  Functional Requirements

 

 

3.  Non-Functional Requirements

 

 

4.  User Interface

 

 

5.  Deliverables

 

 

6.  Open Issues

 

 

 

1.  Introduction

 

1.1  Purpose of This Document

 

            State the purpose of this document and specify the intended readership.

 

1.2   References

 

Provide a list of all applicable and referenced documents and other media (e.g., the Somerville text, UML references, documents provided by the customer, websites).  For each reference, provide the title, author, publisher (if applicable), date, and URL (for websites). This may be omitted

 

1.3  Purpose of the Product

 

This section provides a short description of the user’s work and the situation that triggered the need for the product.  It describes the task(s) that the user wants to accomplish with the delivered product.  It is the product justification.

 

2        Product Scope

 

2.1 Use Case Diagrams

 

2.2  Use Cases

 

This section identifies the boundary between the system under development and the outside world.  That is, it identifies what is included in the system and what is not. Typically, a context diagram best describes the boundary.  However, because the systems in this class are small, we will use a combination top-level use case diagram.   In addition to referring the reader to the diagram, give a brief summary of how it illustrates the system’s scope.  Make sure to number the use cases in the diagram.

 

Use The Unified Modeling Language(UML):  A Standard Graphical Notation presentation, by Eddie Roache, as a reference.  Another reference is UML Distilled, by Martin Fowler. or any of the references I gave you.

 

 

Refer the reader to the top-level use case/context diagram referred to in Section 2.1 -level use cases.

 

Use a format based on the various ones we’ve talked about in class

 

I strongly urge you to use a UML tool like Poseidon (http://www.gentleware.com/) Community Edition

 

2.  Functional Requirements

 

 

Each functional requirement should be culled from   a use case.  A use case can generate more than one functional requirement. This section just lists and assigns a unique identifier to each the functional requirement. Each should be quite brief and in the form: The system shall ….

 

 

 

3.  Non-Functional Requirements

 

Decide on a standard format for the non-functional requirements (NFRs).  Included in the format should be a unique number for each NFR, a priority (1 = lowest, 5 = highest), a clear, concise description, and the test(s) that will be used during system and acceptance testing to verify that the requirement has been met.  Make sure that the test numbers correspond to the NFR numbers.

 

 

4.  User Interface

 

Put a statement such as

 

See “User Interface Design for your product name.”

 

here.  Then, create a second document with that name.  The document should include a title page (same information as for the SRS), a table of contents, and a “walk-through” of the user interface.  The reader should be guided through a series of screen shots.  Give the screen shots figure numbers and labels and refer to the numbers in the walk-through.  Note that the screen shots do not have to be generated using an automated tool (e.g., Visual Basic or a drawing program).  They can be generated using a text editor or even hand drawn (graph paper works well).  At this point in the process, they are a best approximation as to what the user interface will look like in both layout and labeling.

 

In addition, the User Interface Design document should include a section called “Data Validation.”  This section should include a full description of all data items that can be entered into the system by the user or data items that the system may display.  The description should include the item’s basic data type (e.g., integer, string), its limits, and its allowable format(s).  Be sure to uniquely identify each data item.  For example, if you are using a GUI, a data item can be identified by screen name and data item label.  A tabular format will work well for the data validation information.

 

5. Test Plan Summary

 

Write  a table that describes the tests that will be used during system and acceptance testing to verify that each requirement has been met.  Note that a single requirement may require multiple tests, so be thorough.  It is also possible that a single test verifies more than one requirement.  The goal is to come up with the minimum number of test cases that thoroughly test the system.   Asimple table can be used to convey this information:

 

 

Test Name

Description

Functional Req Tested

GUI-Test-1

This is a test of the basic GUI functionality

GUI-Function-Req1

GUI-Function-Req2

GUI-Function-Req3

 

 

 

6.  Deliverables

 

Provide a list of all deliverable items (that is, all artifacts that you will deliver to the customer).  This list will include items such as the product itself (What format? Source code? Executable code? Object code?), documentation, and training resources (if any).  Specify when (date) and in what format (e.g., hard copy, CD) each will be delivered.  A tabular format works well for this section.  For example the deliverable items could be  as follows:

 

Hard copies of each of the following:

 

 

A CD containing the following:

 

 

Use the following tentative schedule for the delivery dates as a guide

 

·        Requirements Document         No latter 10/ 14

·        Design Document                    No latter 11/ 13

·        Prototypes (if Applicable)

·        Implementation  and Manual   Week of finals

 

7.  Open Issues

 

Issues that have been raised and do not yet have a conclusion.  These issues will be addressed later in the development process.

 

 

Appendix A – Agreement Between Customer and Contractor

 

Provide a separate page that describes what the customer and your team are agreeing to when all sign off on this document.  Provide lines for printed names, signatures, and dates.