LOGO

SOFTWARE REQUIREMENTS SPECIFICATION(SRS)

Outline

DefinitionWho would use the documentSRS ContentsGood SRSThe benefits and goalsGuidelinesSRS Template

Overview

We have to keep in mind that the goal is not to create great specifications but to create great products and great software.

Can you create a great product without a great specification? Absolutely!

Systems and software these days are so complex that to embark on the design before knowing what you are going to build is foolish and risky.

What is SRS?

DefinitionAn Software Requirements Specification is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work.

What is SRS? (cont’d)

states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide.

functions as a blueprint for completing a project with as little cost growth as possible.

What is SRS (cont’d)

Including: Problem definition (what is the problem) Solution Statement (how to solve the problem)

SRS contains functional and nonfunctional requirements only

It doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be.

Who would use?

Customers To define the software requirements [in

fact, what actually they want/need]Suppliers

To understand what customers want [then to give solutions]

What should the SRS address? From the IEEE standard, the basic issues that the

SRS writers shall address are the following: Functionality.

What is the software supposed to do? External interfaces.

How does the software interact with people, the system’s hardware, other hardware, and other software?

Performance. What is the speed, availability, response time, recovery time of various software functions, so on

Attributes. What are the portability, correctness, maintainability, security, so on..

Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment, so on..

What are the characteristics of a great SRS?An SRS should be

a) Correct b) Unambiguous c) Complete d) Consistent e) Ranked for importance and/or stability f) Verifiable g) Modifiable h) Traceable

Correct

"Correct and Ever Correcting."Of course you want the specification

to be correct. No one writes a specification that

they know is incorrect. The discipline is keeping the

specification up to date when you find things that are not correct.

Unambiguous

An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.

Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them

Complete

Complete means COMPLETE!!A simple judge of this is that

is should be all that is needed by the software designers to create the software.

SRS defines precisely all the go-live situations that will be encountered and the system's capability to successfully address them.

Consistent

The SRS should be consistent within itself and consistent to its reference documents.

Contradiction is a big no no Example:

If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.

Ranked for Importance

Very often a new system has requirements that are really marketing wish lists.

Some may not be achievable. It is useful provide this information in

the SRS.

Verifiable

Don't put in requirements like - "It should provide the user a fast response." or "The system should never crash."

It is much better if you provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."

Modifiable

The logical, hierarchical structure of the SRS should facilitate any necessary modifications

Grouping related issues together and separating them from unrelated issues makes the SRS easier to modify.

Traceable

In most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document.

Each requirement in an SRS must be uniquely identified to a source.

What are the benefits of a Great SRS? Establish the basis for agreement

between the customers and the suppliers on what the software product is to do.

Reduce the development effort. Provide a basis for estimating costs

and schedules. Provide a baseline for validation and

verification. Facilitate transfer. Serve as a basis for enhancement.

Goals

It provides feedback to the customer. It decomposes the problem into

component parts. It serves as an input to the design

specification. It serves as a product validation

check.

Goals (cont’d)

It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems.Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.

Goals (cont’d)

It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

Goals (cont’d)

It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional systemrequirements so that a design solution can be devised.

Goals (cont’d)

It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

Guidelines

Spend time specifying and documenting well software that you plan to keep.

Keep documentation to a minimum when the software will only be used for a short time or has a limited number of users.

Have separate individuals write the specifications (not the individual who will write the code).

The person to write the specification should have good communication skills.

Guidelines (cont’d)

Pretty diagrams can help but often tables and charts are easier to maintain and can communicate the same requirements.

Take your time with complicated requirements. Vagueness in those areas will come back to bite you later.

Conversely, watch out for over-documenting those functions that are well understood by many people but for which you can create some great requirements.

Guidelines (cont’d)

Keep the SRS up to date as you make changes.

Approximately 20-25% of the project time should be allocated to requirements definition.

Keep 5% of the project time for updating the requirements after the design has begun.

Test the requirements document by using it as the basis for writing the test plan. 

SRS Template

Based on the IEEE Standard: IEEE STD 830-1998 (Guide to Software Requirements Specification)

We make a little modification, the simplified one

SRS Template

1. Introduction1.1 Purpose1.2 Document Conventions1.3 Intended Audience and Reading

Suggestions1.4 Project Scope1.5 References2. Overall Description2.1 Product Perspective2.2 Product Features2.3 User Classes and Characteristics2.4 Operating Environment2.5 Design and Implementation Constraints2.6 User Documentation2.7 Assumptions and Dependencies3. System Features3.1 System Feature 13.2 System Feature 2 (and so on)

SRS Template

4. External Interface Requirements4.1 User Interfaces4.2 Hardware Interfaces4.3 Software Interfaces4.4 Communications Interfaces5. Other Nonfunctional Requirements5.1 Performance Requirements5.2 Safety Requirements5.3 Security Requirements5.4 Software Quality Attributes6. Other RequirementsAppendix A: GlossaryAppendix B: Analysis ModelsAppendix C: Issues List

Our SRS Template

1. Introduction2. Overall Description3. Functional Requirement4. External Interface Requirements5. Other Requirements

Introduction

1.1 Purpose <Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.>

1.2 Project Scope<Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a separate vision and scope document is available, refer to it rather than duplicating its contents here. An SRS that specifies the next release of an evolving product should contain its own scope statement as a subset of the long-term strategic product vision.>

1.3 References<List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.>

Overall Description

2.1 Product Perspective<Describe the context and origin of the product being specified in this SRS. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.

2.2 Product Features<Summarize the major features the product contains or the significant functions that it performs or lets the user perform. Details will be provided in Section 3, so only a high level summary is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often effective.>

Overall Description

2.3User Classes and Characteristics <Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.>

2.4Operating Environment<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>

2.5Design and Implementation Constraints<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).>

Overall Description

2.6 User Documentation <List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>

2.7Assumptions and Dependencies<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).>

Functional Requirement

3.1 Data Flow3.1.1 Context Diagram

3.1.1.1 Introduction3.1.1.2 Inputs3.1.1.3 Process3.1.1.4 Outputs

3.1.2 Data Flow Diagram Level 13.1.2.1 Introduction3.1.2.2 Inputs3.1.2.3 Process3.1.2.4 Outputs

3.1.3 Data Flow Diagram Level 23.1.3.1 DFD Level 2 Process x

- Introduction- Inputs- Process- Outputs

3.1.3.2 DFD Level 2 Proses y...

3.1.N Data Flow Diagram Level N….

Functional Requirement

3.2 Process Specification3.2.1 Process Specification Process 1

3.2.1.1 Input3.2.1.2 Algorithm / Formula3.2.1.3 Related data store3.2.1.4 Output

3.2.2 Process Specification Process N….

3.3 Data Dictionary3.3.1 Data Element 1

3.3.1.1Name3.3.1.2 Alias3.3.1.3Where-used/how-used3.3.1.4Content description

3.3.2 Data Element N….

External Interface Requirements4.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.

4.2 Software Interfaces<Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.>

Other Requirements

<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Review

DefinitionWho would use the documentSRS ContentsGood SRSThe benefits and goalsGuidelinesSRS Template