3. Requirement Analysis and Specification(3rd Chapter)

1.0  Requirement Analysis & Specification

1.1  Requirements gathering and analysis

1.2  Software Requirement specification(SRS)

3.2.1 Contents of the SRS document

1.3  Functional Requirements

1.4  How to identify the functional requirements

1.5  How to Document the functional requirements Traceability

1.6  Characteristics of a good SRS document

1.7  Examples of Bad SRS Document

1.8  Organization of the SRS Document

1.9  Technique for Representing Complex Logic

Requirements Analysis and Specification

Many projects fail: because they start  implementing the system: without determining whether they are building what the customer  really wants. It is important to learn: requirements analysis and specification techniques thoroughly.
Goals of requirements analysis and specification phase:

fully understand the user requirements remove inconsistencies, anomalies, etc. from requirements

document requirements properly in an SRS document Consists of two distinct activities:

********************************************************************************
Assume that we got one project in a company we are the developers(programmers). We know that projects are of two types basically they are (i) implementation projects (ii) enhancement projects (iii) maintenance project. Suppose now we are going to develop implementation project( from scratch(begining) onwards we need to write)

• A company(client side) has come to our organisation (our) to give the project
• Clients asks us about his project
• Once the deal is ok with the Client
• SDLC(Software development Life Cycle) comes to the picture
• Now the Project Manager(PM) involves, and he explains the project, and he identifies the Project Leaders(PL)
• Once the Project Leaders(PLs) are identified by the Project Manager
• Now the Project Leaders(PL) identifies the Team Leaders(TLs)
• And Team Leader identifies the Developers (programmers)
• Team Leaders(TLs) Reports to Project Leaders (PL)
• Project Leaders (PLs) Reports to Project Manager(PM)
• Now everything is ready i.e staffing has been structured
• To start a project we know that there are phases, what are they? They are: 
• 
  

• Software Engineers should follows the phases
• If we want to start a project first Project Leader should identify the Clients Requirements
• Project Leaders takes the requirements from the Clients
• To gather the client requirements, PL/TL visits the Clients place to understand the project needs (this is also called as ONSITE visit)
• PL/TL is the responsible to gather the clients requirements
• Once the Requirements has been gathered, the PL/TL prepares a Document based on which he gathered
• This document is known as SRS (Software Requirement and Specification) Document.
• After preparation of the SRS document, PL /TL shows / sends the SRS document to the Client
• Once the client approves the SRS Document, Designing phase starts
• Now PL / TL gets the an idea on Project
• Now the Designing Phase starts

Now you got the idea about the SRS Document I hope.
/* Let us we see priority for the phases

Requirement             may take                  25 days
Analysis                   may take                  10 days
Design                     may take                  30 days
Coding                    may take                  10 days
Testing                    may take                   25 days

You can understand that Design is the very important, which is done by the Experience persons like TL/ PL s only thus they draws the more salary (example 2 lakhs to 4 laksh per month)
Developers draws only 40k to 60 k per month, so once we get good experience programming , our goal should be Design means we have to achieve Team Leaders position  */

*******************************************************************************

Requirements Gathering and Analysis

Specification

The person who undertakes requirements analysis and specification:

known as  systems analyst:

collects data pertaining to the product

analyzes collected data:

to understand what exactly needs to be done.

writes the Software Requirements Specification (SRS) document.

Final output of this phase:

Software Requirements Specification (SRS) Document.

The SRS document is reviewed by the customer.

reviewed SRS document forms the basis of all future development activities.

Requirements Analysis

Requirements analysis consists of two main activities:

Requirements gathering

Analysis of the gathered requirements

Analyst gathers requirements through:

observation of existing systems,

studying existing procedures,

discussion with the customer and  end-users,

analysis of what needs to be done, etc.

Requirements Gathering

If the project is to automate some existing procedures

e.g., automating existing manual accounting activities, 

the task of the system analyst is a little easier

analyst can immediately obtain:

 input and output formats

 accurate details of the operational procedures

In the absence of a working system, 

lot of imagination and creativity  are required.

Interacting with the customer to gather relevant data:

requires a lot of experience.

Some desirable attributes of a good system analyst:

Good interaction skills,

imagination and creativity,

experience.

Analysis of the Gathered Requirements

After gathering all the requirements:

analyze it:

Clearly understand the user requirements, Detect inconsistencies, ambiguities, and incompleteness. Incompleteness and inconsistencies: resolved through further discussions with the end-users and the customers. 

Inconsistent requirement

Some part of the  requirement:

 contradicts with some other part.

Example:

One customer says  turn off  heater and open water shower  when   temperature > 100  C

Another customer says  turn off  heater and turn ON cooler when  temperature > 100   C

                                 

Incomplete requirement

Some requirements have been omitted:

due to oversight.

Example:

The analyst has not recorded:
when temperature falls below 90  C

heater should be turned ON

water shower turned OFF.

Requirements analysis involves:

obtaining a clear, in-depth understanding of the product to be developed, 

remove all ambiguities and inconsistencies from  the initial customer perception of the problem.

It is quite difficult to obtain:

a clear, in-depth understanding of the problem:

especially if there is no working model of the problem.

Experienced analysts take considerable time:

to understand the exact requirements the customer has in his mind.

Experienced systems analysts know -
often as a result of painful experiences ---

without a clear understanding of the problem, it is impossible to develop a satisfactory system.

Several things about the project should be clearly understood by the analyst:

What is the problem?

Why is it important to solve the problem?

What are the possible solutions to the problem?

What complexities might arise while solving the problem?

Some anomalies and inconsistencies can be very subtle:

escape even most experienced eyes.

If a formal model of the system is constructed,

many of the subtle anomalies and inconsistencies get detected.

After collecting all data regarding the system to be developed,

remove all inconsistencies and anomalies from the requirements,

systematically organize requirements into  a Software Requirements Specification (SRS) document.

Software Requirements Specification

Main aim of requirements specification:

systematically organize the requirements arrived during requirements analysis

document requirements properly.

The SRS document is useful in various contexts:

statement of user needs

contract document

reference document

definition for implementation

1. What is  SRS document?

Ans: SRS document is basically an organization’s
understanding (in writing) of potential system
requirements and dependencies at a
particular point in time (usually) prior to any
actual design or development work.

2. Need for SRS ?

• There may not be clear understanding of what a system is
  expected to do and its limitations.
•  System development process might lose focus over time.
•  Many people with variety of backgrounds are involved.
•  Different people might have different interpretations.
•  No clear communication between stakeholders and the
  development team.
•  Requirements of the system might change.

3. Main goals of the SRS document

• 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.

4. What does SRS contain?

• It contains functional and non-functional requirements only.
• It states in precise and explicit language required functions and capabilities of a proposed software system (i.e., a software application, an eCommerce Web site, and so on) must provide.
• It states any required constraints by which the proposed system must abide.
• It doesn’t specify project requirements such as cost, delivery schedules, staffing, reporting procedures, etc.
• It doesn't offer design suggestions/solutions such as choosing data structure, partition into modules, etc.
• It doesn't offer possible solutions to technology or business issues.
• It doesn’t contain any type of Product Assurance plans such as Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures, etc.
• It doesn't offer any other information other than what the development team understands the customer's system requirements to be.

5. Benefits of the SRS Document

• Provides communication between the (clients)stakeholders and the development team.
• Provides a good foundation for the system design phase.
• Enables planning of future phases such as validation,verification, and acceptance procedures.
• Provides cross-check while conducting user-acceptance testing.
• Helps in project planning eg. estimates of cost and time, resource scheduling.
• Usable during maintenance phase.

6. Who Prepares the SRS or Who involved in SRS?

•  Almost everyone
• Requirement team interview the clients
• Requirements verification team ensure consistency in the document
• Designers review the document to determine adequacy(satisfactory) for design and feasibility
• Programmers look for technical challenges and feasibility(means possible or not?)
• Testers look for traceability and testability
• Project Managers/Sponsors look for risk
• Clients/ End users

7. What kind of information should SRS
Include?

Several standards organizations (including the IEEE) have
identified nine topics that must be addressed when designing and
writing an SRS:

•  Interfaces
• Functional Capabilities
• Performance Levels
• Data Structures/Elements
• Safety
• Reliability
• Security/Privacy
• Quality
• Constraints and Limitations

8. Characteristics of a good SRS (short question)

Ans:

• Complete
• Consistent
• Correct
• Modifiable
• Traceable
• Unambiguous
• Valid
• Verifiable

9. Expalin about good srs document (long question)

Characteristics of a Good SRS

A good SRS document has certain characteristics that must be present. The

characteristics are:

1.C o r r e c t n e s s . An SRS is correct if every requirement included in the SRS

represents something required in the final system.

2.C o m p l e t e n e s s . An SRS is complete when it is documented after:

(i) The involvement of all types of concerned personnel.

(ii) Focusing on all problems, goals, and objectives, and not only on functions

and features.

(iii) Correct definition of scope and boundaries of the software and system.

3.U n a m b i g u o u s . An SRS is unambiguous if and only if every requirement

stated has one and only one interpretation. Requirements are often written in

a natural language. The SRS writer has to be especially careful to ensure that

there are no ambiguities. One way to avoid ambiguities is to use some formal

requirements specification language. The major disadvantage of using formal

languages is the large effort required to write an SRS, the high cost of doing

so, and the increased difficulty of reading and understanding formally stated

requirements (particularly by the users and clients).

4.V e r i f i a b l e . An SRS is verifiable if and only if there exists some cost-effective

process that can check whether the final product meets the requirements.

5.M o d i f i a b l e . An SRS is modifiable if its structure and style are such that any

necessary change can be made easily while preserving completeness and

consistency. The presence of redundancy is a major hindrance to modifiability,

as it can easily lead to errors. For example, assume that a requirement is

stated in two places and that the requirement later needs to be changed. If

only one occurrence of the requirement is modified, the resulting SRS will be

inconsistent.

6.T r a c e a b l e . The SRS is traceable if the origin of each of the requirements is clear

and if it facilitates the referencing of each requirement in future development

or enhancement documentation. Two types of traceability are recommended:

(i) Backward traceability. This depends upon each requirement explicitly

referencing its source in earlier documents.

(ii) Forward traceability. This depends upon each requirement in the SRS

having a unique name or reference number.

7.C o n s i s t e n c y . Consistency in the SRS is essential to achieve correct results

across the system. This is achieved by:

(i) The use of standard terms and definitions.

(ii) The consistent application of business rules in all functionality.

(iii) The use of a data dictionary.

INTRODUC

10. Characteristics of a bad SRS

• Unstructured Specifications: Narrative essay- one of the worst types of specification document:, incompleteness, ambiguity.

• Noise:         Whatever presence of text containing information is not relates to the problem.
• Silence:          Aspects important to proper solution of the problem are omitted.
• Over specification   :Overspecification restricts the solution space for the designer. (overspecification:  is well known in all industries: developing features that are not needed by the   customer causes excess development efforts, missed due dates, terminated projects and higher lifecycle costs.)
• Contradictions :If the same thing described at several places in different ways
• Ambiguity :Literal expressions
• Forward references :References to aspects of problem    Defined only later on in the text.

• Wishful / Unrealistic thinking

          Descriptions of aspects, for which realistic solutions will be hard to find

11. Types of requirements included in the SRS

Types of requirements included in the SRS

1. Functional requirements
2. Non-functional requirements
3. constraints on the system.
4. Other requirements

12. What is Functional Requirements?

Functional Requirements: It is desirable  to consider every system: performing a set of functions {fi}.Each function fi considered as: transforming a set of input data to corresponding  output data.

Functional requirements describe:

A set of high-level requirements Each high-level requirement: takes in some data from the user outputs some data to the user Each high-level requirement: might consist of a set of identifiable functions For each high-level requirement: every function is described in terms of input data set output data set processing required to obtain the output data set from the input data set 

Transformations (inputs, processing, outputs)

• Requirements for sequencing and parallelism (dynamic requirements)
• Data                                                                                                                                                  – Inputs and Outputs                                                                                                                          – Stored data                                                                                                                                     – Transient data
• Exception handling( error handling i.e we learn in java as we have a seperate chapter in java)
• Nature of function: Mandatory/ Desirable/ Optional 

/* just read the example for understandable purpus (no need to write the in the exam)
Example: Functional Requirement

F1: Search Book

Input:  an author’s name:

Output: details of the author’s books and the locations of these books in the library.

List all functional requirements with proper numbering.

Req. 1:

Once the user selects the “search” option,

he is asked to enter the key words.

The system should output details of all books

whose title or author name matches any of the key words entered.

Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number, Catalog Number, Location in the Library.

Req. 2:

When the “renew” option is selected, the user is asked to enter his membership number and password. After password validation,   the list of the books borrowed by him are displayed. The user can renew any of the books:  by clicking in the corresponding renew box.

Req. 1:

R.1.1:

Input: “search” option,

Output: user prompted to enter the key words.

R1.2:

Input: key words

Output: Details of all books  whose title or author name matches any of the key words.

Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number, Catalog Number, Location in the Library.

Processing: Search the book list for the keywords

Req. 2:

R2.1:

Input: “renew” option selected,

Output:  user prompted to enter his membership number and password.

R2.2:

Input: membership number and password

Output:

list of the books borrowed by user are displayed. User prompted to enter books to be renewed or

user informed about bad password

Processing: Password validation, search books issued to the user from borrower list and display. 

R2.3:

Input: user choice for renewal of the books issued to him through mouse clicks in the corresponding renew box.

Output: Confirmation of the books renewed

Processing: Renew the books selected by the in the borrower list.

Note:
What is the difference between 

Functional and Nonfunctional Requirements

Many of the difficulties encountered in defining requirements relate to the functional-nonfunctional distinction.  As so often happens, some of those difficulties are things of which people are aware, largely realizing after-the-fact that nonfunctional requirements were missed.  However, perhaps more, and certainly the more insidious difficulties, involve other issues of which people may not be aware and often may be incurring intentionally due to mistaken understandings.

Functional Requirements

Most requirements definition focuses mainly on functional requirements, which are based upon the expected functioning of the product or system to be created.  Functioning, typically is equated with product/system features for which you might have a menu or button choice, such as:  identify a customer, select an item to order, and calculate the amount due.  

All things considered, requirements definers probably are best at identifying functional requirements, although they often

13 What is Constaints?

Ans:

Constraints Constraints describe things that the system should or should not do.

For example, standards compliance how fast the system can produce results so that it does not overload another system to which it supplies data, etc.

Examples of constraints

Hardware to be used, Operating system or DBMS to be used Capabilities of I/O devices Standards compliance Data representations  by the interfaced system

14. What Non-functional requirements?

• Performance
• Safety
• Security
• Software quality  
• Project documentation
• User documentation
• Design Constraints

(or)

Characteristics of the system which can not be expressed as functions: maintainability, portability,  usability, etc. Nonfunctional requirements include: reliability issues, performance issues, human-computer interface issues, Interface with other external systems,  security, maintainability, etc.

14. What is Other Non-Functional Requirements?

• Performance requirements
• Safety requirements
• Security requirements
• Software quality attributes
• Business rules
• Project documentation
• User documentation

15. What is the Difference between Functional Requirements and Non Functional Requirements?

Functional requirement	non functional requirement
(1.)in simple requirements for activities such as insertion, deletion updation are known as functional requirements, and requirements for gui reuiremnts such	1)It's nothing only GUI(Graphical User Interface) testing
(2.)If we will go to the SRS (S/W Requirement Specification) document then we can see some "Functionality" like 1.Add 2.Edit 3.Save 4.Close 5.TEXT Field ......etc. For those functionality here it is written the event action for that particular field or Functionality.	means colour/Allignment/Shape/Size/DB size those things will be there in the Non-Functional requirement.
(3) When ever need to give the data for to get the output is always a functional requirement .(which makes seriousness to the customer or technical person ).	(3)font, color ,size comes under non functional requirements

15. Explain about Software Requirements Document (SRS)? (long question)

ANS:

Software Requirement document is also called SRS Document. It is the official statement of what the software engineers (development tem)should implement(develop) the project or product.

It comprises (contains) of exact (precise) from of customers requirements and a detailed specification of the systems requirement.

As Software Requirements is a combination of customer as well as system requirements specifications.

This combination can be achieved in the following ways:

Both clients (customers) as well as system requirements specifications can be integrated to form one document

                                          (or)

If there are a large number of requirements (system requirements) may be presented in a separate document.

Features of SRS:

Ø      SRS Document should specify external system behaviour

Ø      SRS Document specify constraints on the implementation

Ø      SRS Document be easy to change

Ø      SRS Document serve as reference tool(material) for maintenance project

Ø      SRS Document should record motivation on the system life cycle

Ø      SRS Document characterize acceptable behavior for undesired events.

Ø       

Structure of SRS Doucment

1.   Introduction

1.1   Purpose of the requirements document

1.2   Intended Audience and Reading Suggestions:

            project managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.

1.4   Project Scope:

            It's functions and how it interacts with other systems.

2.   System Models:

·        one or more models clearly showing the relationship between the system components, and the relationship between the system and its environment.

·        A model is an abstract system view. Complementary types of model provide different system information.

·        The models include the following:

(a) Object Models: dividing the problems (issues) into objects and the services they provide.

( for understanding purpose only don’t write in exam:

Object models describe the system in terms of object classes and their associations.

An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object.

Various object models may be produced

•          Inheritance models;

•          Aggregation models;

•         Interaction models

Object models describe logical system entities, their classification and aggregation.)

(b.) Dataflow Models: Showing the movement of the data and manipulation of information through the system.

(c) Semantic Models:

     Describing the system as entities and the relationships between them.

 (just read it:     Used to describe the logical structure of data processed by the system.

      An entity-relation-attribute  model sets out the entities in the system, the     relationships between these entities and the entity attributes

Widely used in database design. Can readily be implemented using relational databases.

Semantic data models explains the logical structure of data which is imported to or exported by the systems.

    (d.) Data Dictionaries:

      Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included.

(Advantages

•         Support name management and avoid duplication;

•         Store of organisational knowledge linking analysis, design and implementation;

3.   Functional Requirements:

            The services provided for the user may be in multiple format(e.g: filled in forms, diagrams, plain text, etc) to provide complete and concise(brief) information of everyone associated with the project

5.   Other Nonfunctional Requirements

     Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

5.1   Performance Requirements

5.2   Safety Requirements

5.3   Security Requirements

5.4 Software Quality Attributes

4.   Motivation and assumptions:

            assumptions about the system and its environment, anticipated future changes, the reasons for decisions, etc.

5.   Detailed Requirements Specifications:

            For every task/function required for the system, might include interfaces for many parts of the process.

6.   Other Requirements (Glossary):

            Defining all technical terms used in the document. No assumption should be made about the reader having expertise or experience either in the problem domain or in aspects of computer design./ development.

                                                               Sample SRS Document Format
                                      (Real Time SRS document)

Software Requirements Specification

for

<Project Name>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Table of Contents

Table of Contents........................................................................................................................... ii

Revision History............................................................................................................................. ii

1.   Introduction.............................................................................................................................. 1

1.1   Purpose................................................................................................................................. 1

1.2   Document Conventions........................................................................................................ 1

1.3   Intended Audience and Reading Suggestions........................................................................ 1

1.4   Project Scope........................................................................................................................ 1

1.5   References............................................................................................................................ 1

2.   Overall Description.................................................................................................................. 2

2.1   Product Perspective.............................................................................................................. 2

2.2   Product Features................................................................................................................... 2

2.3   User Classes and Characteristics........................................................................................... 2

2.4   Operating Environment......................................................................................................... 2

2.5   Design and Implementation Constraints................................................................................ 2

2.6   User Documentation............................................................................................................. 2

2.7   Assumptions and Dependencies........................................................................................... 3

3.   System Features....................................................................................................................... 3

3.1   System Feature 1.................................................................................................................. 3

3.2   System Feature 2 (and so on)................................................................................................ 4

4.   External Interface Requirements........................................................................................... 4

4.1   User Interfaces..................................................................................................................... 4

4.2   Hardware Interfaces............................................................................................................. 4

4.3   Software Interfaces............................................................................................................... 4

4.4   Communications Interfaces.................................................................................................. 4

5.   Other Nonfunctional Requirements....................................................................................... 5

5.1   Performance Requirements................................................................................................... 5

5.2   Safety Requirements............................................................................................................. 5

5.3   Security Requirements.......................................................................................................... 5

5.4   Software Quality Attributes.................................................................................................. 5

6.   Other Requirements................................................................................................................ 5

Appendix A: Glossary................................................................................................................... 5

Appendix B: Analysis Models....................................................................................................... 6

Appendix C: Issues List................................................................................................................. 6

Revision History

Name	Date	Reason For Changes	Version

1.     Introduction

1.1     Main 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     Document Conventions

<Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance. For example, state whether priorities  for higher-level requirements are assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own priority.>

1.3     Intended Audience and Reading Suggestions

<Describe the different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.>

1.4     Project Objective

<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.5     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.>

2.     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.>

2.3     User 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.4     Operating 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.5     Design 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).>

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.7     Assumptions 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).>

3.     System Features

<This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.>

3.1     System Feature 1

<Don’t really say “System Feature 1.” State the feature name in just a few words.>

3.1.1      Description and Priority

<Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

3.1.2      Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.>

3.1.3      Functional Requirements

<Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available.>

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.>

REQ-1:   

REQ-2:   

3.2     System Feature 2 (and so on)

4.     External Interface Requirements

4.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     Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.>

4.3     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.>

4.4     Communications Interfaces

<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.>

5.     Other Nonfunctional Requirements

5.1     Performance Requirements

<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>

5.2     Safety Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the product’s design or use. Define any safety certifications that must be satisfied.>

5.3     Security Requirements

<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>

5.4     Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

6.     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.>

Appendix A: Glossary

<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>