Software Engineering Final Project
a template for
Software Requirement Specification

Eliezer Kaplansky¹
Dept. of Computer Science
Ben-Gurion University
Beer-Sheva 84105, Israel
kaplan_e@cs.bgu.ac.il

Date: 25-31 Dec 2002

Last submission: 1 Jan 2003 10:00

Location: My office, sign by your supervisor

Description:

This document describes the understanding, in writing, between you and your client's about the client's system requirements and dependencies at this particular point in time: prior to any actual design or development work.

The SRS is a two-way insurance policy that assures that both the client and you understand each other's requirements from each other's perspective at this point in time. From your side, make sure that all the resources that you need are specified. Specify in section , for example, the minimum meeting time for each week, and the maximum time between the time you ask for additional information, to the time the client response (even, by just acknowledge that there is a problem to be solved.) In other words - prepare, ahead, your excuses for not doing all the functionalities you agree in this documents - this is very important in real world. Remember: Anything that is not in the SRS the you shouldn't be working on it. And if it is in the SRS YOU are accountable to deliver that functionality.

The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. A good SRS will be the basis for your next task: the software design.

Guide lines:

While the Application Requirement Specification (ARS) concentrate on

• The description of the problem domain (PD)
• The list of requirement to be met (problems to be solved)
• What the CLIENT wants.

in the Software Requirements Specification (SRS) you should concentrate on:

• The definition of the behavior of the solution system.
• What the product (the software) that YOU would produce will do.

The focus here is on what YOU can and agree to do until the middle of next semester (V1.0). Please remember, that in addition to the working version (V1.0) you will be asked, in the next semester, to design the improvements for the next version (V2.0). Please allow enough time for this - In other words, here, commit for less.

I expect to see in V1.0 all the functionalities define in this SRS. Any functionality that will be missing will need an agreement in writing from your client. Therefore take this document seriously.

In this course, we try to simulate a real world (RW) development situation. In the RW, your company will not get paid if not all the functionalities are working, unless your client agree. In this course, your payment is your grad, and client agreement will not be sufficient for any missing functionality - I will understand that you were carelessly writing this document.

Later, you will choose from this document what has to be done for the prototype - due in the beginning of the next semester.

the SRS should be written in natural language (versus a formal language), in an unambiguous manner and also include charts, tables, data flow diagrams, decision tables, and so on.

Keep sentences and paragraphs short. Use the active voice. Use proper grammar, spelling, and punctuation. Use terms consistently and always define new terms in the data dictionary.

Do not use weak phrases like: be able to, easy, be capable of, effective, timely, as applicable, but not limited to, if possible, as appropriate, if practical, capability to, normally.

The following template is as close as possible to the ARS template. Simply take the ARS, and edit it to create the SRS. Please note that there's not a "standard specification template" for all projects in all industries because that the individual requirements that populate a SRS are unique not only from company to company, but also from project to project within any one company. The key here is to start with this template and then adapt it to meet your needs. Use this template as guide for developing your own. However, your SRS must be based on use case model.

It's important to note that a SRS contains functional and nonfunctional requirements ONLY. The SRS doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than the understanding of development team about the customer's system requirements. So cut the above information from the ARS before you start to adding anything to it.

The SRS documents topics will include:

0 The front page sign by your supervisor (include his grad)

Please down-load template form the course site.