Sachin Sir SRSVersion1.Doc

7/26/2019 Sachin Sir SRSVersion1.Doc

1/21

SRS For ESTI (EonVertex)

( EonVertex )

( Team Edugird )

Software Requirements Specification Document

RoleType

Name Role Date

Prepared By Amit !as"e # Pa$an Pati% &e' De$e%oper *+,*+

Re$iewed By Vi"rant -!an Vip%o$e Day Pro.ect /ead

Appro$ed By S!riram 0!aud!ari De$e%opment 1ead

Infogird Informatics Private Limited SRSv1.1 Page 1 of 210!11!1 f


2/21


Revision History

Sr 2o Date Version Page 2o 0!ange Type 0!anges

) *+,*+ 3* A Bac" end use casesadded

,)

A4Added5 4odified5 D4De%eted



3/21


Table of Contents

Introduction

Purpose of t!is documentScope of t!is Document

Acronyms

References6ntended Audience and Reading Suggestions

Document Overview

7$era%% description

Product Perspecti$eProduct 8unctions

9ser 0%asses and 0!aracteristics7perating En$ironment

Design and 6mp%ementation 0onstraints9ser Documentation

Assumptions and Dependencies

External Interface Requirements

9ser 6nterfaces1ardware 6nterfaces

Software 6nterfaces0ommunication 6nterfaces

unctional Requirement !pecifications "R!#

System 8eatures

8unctiona% Requirements

8ront end (Store front) RequirementsBac" end (Administrati$e Too%s) Requirements

9se 0ases

8ront end (Store front)Bac" end (Administrati$e Too%s)

Non untional Requirements

9sa'i%ity Requirements

Performance Requirements0ompati'i%ity Requirements

Ot$er Requirements

%lossary

Infogird Informatics Private Limited SRSv1.1 Page " of 210!11!1 f


4/21


&ac' end "(dmin )odule#

) Das!'ord,)

:) Admission;) 8inance

) ar"eting

?) 8o%%ow4up*) @ua%ity

),) Setting

*!ER

Infogird Informatics Private Limited SRSv1.1 Page # of 210!11!1 f


5/21


Infogird Informatics Private Limited SRSv1.1 Page $ of 210!11!1 f


6/21


Infogird Informatics Private Limited SRSv1.1 Page of 210!11!1 f


7/21


1. Introduction

The following subsections of the Software Requirements Specifications (SRS) document

should provide an overview of the entire SRS. The thing to keep in mind as you writethis document is that you are telling what the system must do so that designers can

ultimately build it. o not use this document for design!!!

Team "dugird is aimed at developing an "ducational #nstitute $anagement System. #t isan internet based online application% which can be used for managing and maintaining

each entity at an institute% which results in hassle free and smooth operations at institutelevel.

The system in turn% forms a centrali&ed knowledge base information system with various

levels of access rights for a given staff% student or management user who can interactwith system for various intended purposes.

1.1 Purpose

#dentify the purpose of this SRS and its intended audience. #n this subsection% describethe purpose of the particular SRS and specify the intended audience for the SRS.

1.2 Scope

#n this subsection'

(1) #dentify the software product(s) to be produced by name

(2) "plain what the software product(s) will% and% if necessary% will not do

(3) escribe the application of the software being specified% includingrelevant benefits% obectives% and goals

(4) *e consistent with similar statements in higher+level specifications if

they eist

This should be an eecutive+level summary. o not enumerate the whole requirements

list here.

1.3 Definitions, Acronyms, and Abbreviations.

Infogird Informatics Private Limited SRSv1.1 Page % of 210!11!1 f


8/21


,rovide the definitions of all terms% acronyms% and abbreviations required to properly

interpret the SRS. This information may be provided by reference to one or more

appendices in the SRS or by reference to documents. This information may be provided

by reference to an -ppendi.

1.4 References

#n this subsection'() ,rovide a complete list of all documents referenced elsewhere in the SRS

(/) #dentify each document by title% report number (if applicable)% date% and

publishing organi&ation(3) Specify the sources from which the references can be obtained.

This information can be provided by reference to an appendi or to another document. #f

your application uses specific protocols or R012s% then reference them here so designers

know where to find them.

1.5 vervie!

#n this subsection'

(1) escribe what the rest of the SRS contains(2) "plain how the SRS is organi&ed

on2t rehash the table of contents here. ,oint people to the parts of the document they

are most concerned with. 1ustomers3potential users care about section /% developerscare about section 4.

2. "#e vera$$ Description

escribe the general factors that affect the product and its requirements. This section

does not state specific requirements. #nstead% it provides a background for those

requirements% which are defined in section 4% and makes them easier to understand.#n asense% this section tells the requirements in plain "nglish for the consumption of the

customer. Section4 will contain a specification written for the developers.

2.1 Product Perspective

,ut the product into perspective with other related products. #f the product is

independent and totally self+contained% it should be so stated here. #f the SRS defines a

product that is a component of a larger system% as frequently occurs% then this subsectionrelates the requirements of the larger system to functionality of the software and identifies

interfaces between that system and the software. #f you are building a real

system%compare its similarity and differences to other systems in the marketplace. #f you

Infogird Informatics Private Limited SRSv1.1 Page & of 210!11!1 f


9/21


are doing a research+oriented proect% what related research compares to the system you

are planning to build.

- block diagram showing the maor components of the larger system% interconnections%and eternal interfaces can be helpful. This is not a design or architecture picture. #t is

more to provide contet% especially if your system will interact with eternal actors. The

system you are building should be shown as a black bo. 5et the design documentpresent the internals.

The following subsections describe how the software operates inside various constraints.

2.1.1 System Interfaces

5ist each system interface and identify the functionality of the software to accomplish thesystem requirement and the interface description to match the system. These are eternal

systems that you have to interact with. 0or instance% if you are building a businessapplication that interfaces with the eisting employee payroll system% what is the -,# tothat system that designer2s will need to use6

2.1.2 Interfaces

Specify'(1) The logical characteristics of each interface between the software product

and its users.

(2) -ll the aspects of optimi&ing the interface with the person who must use

the system

This is a description of how the system will interact with its users. #s there a 78#% a

command line or some other type of interface6 -re there special interface requirements6#f you are designing for the general student population for instance% what is the impact of

-- (-merican with isabilities -ct) on your interface6

2.1.3 %ard!are Interfaces

Specify the logical characteristics of each interface between the software product and the

hardware components of the system. This includes configuration characteristics. #t also

covers such matters as what devices are to be supported% how they are to be supportedand protocols. This is not a description of hardware requirements in the sense that 9This

program must run on a $ac with :;$ of R-$ type home devices% what is the interface to those devices6 esigners

should be able to look at this and know what hardware they need to worry about in the

design. $any business type applications will have no hardware interfaces. #f none% uststate 9The system has no hardware interface requirements< #f you ust delete sections

Infogird Informatics Private Limited SRSv1.1 Page ' of 210!11!1 f


10/21


that are not applicable% then readers do not know if' a. this does not apply or b. you

forgot to include the section in the first place.

2.1.4 Soft!are Interfaces

Specify the use of other required software products and interfaces with other application

systems. 0or each required software product% include'

(1) ?ame(2) $nemonic

(3) Specification number

(4) @ersion number

(5) Source

0or each interface% provide'

(1) iscussion of the purpose of the interfacing software as related to this

software product(2) efinition of the interface in terms of message content and format

Aere we document the -,#s% versions of software that we do not have to write% but that

our system has to use. 0or instance if your customer uses SB5 Server C and you are

required to use that% then you need to specify i.e.

/..;. $icrosoft SB5 Server C. The system must use SB5 Server as its databasecomponent. 1ommunication with the * is through D*1 connections. The system

must provide SB5 data table definintions to be provided to the company *- for setup.

- key point to remember is that you do ?DT want to specify software here that you think

would be good to use. This is only for customer-specified systemsthat you havetointeract with. 1hoosing SB5 Server C as a * without a customer requirement is aesign choice% not a requirement. This is a subtle but important point to writing good

requirements and not over+constraining the design.

2.1.5 &ommunications Interfaces

Specify the various interfaces to communications such as local network protocols% etc.

These are protocols you will need to directly interact with. #f you happen to use web

services transparently to your application then do not list it here. #f you are using acustom protocol to communicate between systems% then document that protocol here so

designers know what to design. #f it is a standard protocol% you can reference an eisting

document or R01.

2.1.' (emory &onstraints

Specify any applicable characteristics and limits on primary and secondary memory .on2t ust make up something here. #f all the customer2s machines have only /EF of



11/21


R-$% then your target design has got to come in under /EF so there is an actual

requirement. Gou could also cite market research here for shrink+wrap type applications

90ocus groups have determined that our target market has between /H:+H/$ of R-$%

therefore the design footprint should not eceed /H:$.< #f there are no memoryconstraints% so state.

2.1.) perations

Specify the normal and special operations required by the user such as'

(1) The various modes of operations in the user organi&ation

(2) ,eriods of interactive operations and periods of unattended operations(3) ata processing support functions

(4) *ackup and recovery operations

(?ote' This is sometimes specified as part of the 8ser #nterfaces section.) #f you

separate this from the 8# stuff earlier% then cover business process type stuff that wouldimpact the design. 0or instance% if the company brings all their systems down atmidnight for data backup that might impact the design. These are all the work tasks that

impact the design of an application% but which might not be located in software.

2.1.* Site Adaptation Re+uirements

#n this section'

(1) efine the requirements for any data or initiali&ation sequences that are

specific to a given site% mission% or operational mode(2) Specify the site or mission+related features that should be modified to

adapt the software to a particular installation

#f any modifications to the customer2s work area would be required by your system% then

document that here. 0or instance% 9- >>Fw backup generator and >>>> *T8 air

conditioning system must be installed at the user site prior to software installation


12/21


0or clarity'

(1) The functions should be organi&ed in a way that makes the list of functions

understandable to the customer or to anyone else reading the document for the first

time.(2) Tetual or graphic methods can be used to show the different functions and their

relationships. Such a diagram is not intended to show a design of a product but

simply shows the logical relationships among variables.

-A% 0inally the real meat of section /. This describes the functionality of the system in

the language of the customer. Ihat specifically does the system that will be designedhave to do6 rawings are good% but remember this is a description of what the system

needs to do% not how you are going to build it. (That comes in the design document).

2.3 -ser aracteristics

escribe those general characteristics of the intended users of the product includingeducational level% eperience% and technical epertise. o not state specific requirements

but rather provide the reasons why certain specific requirements are later specified insection 4.

Ihat is it about your potential user base that will impact the design6 Their eperienceand comfort with technology will drive 8# design. Dther characteristics might actually

influence internal design of the system.

2.4 &onstraints

,rovide a general description of any other items that will limit the developerJs options.

These can include'

() Regulatory policies

(/) Aardware limitations (for eample% signal timing requirements)(4) #nterface to other applications

(;) ,arallel operation

(H) -udit functions(:) 1ontrol functions

(C) Aigher+order language requirements

(8) Signal handshake protocols (for eample% =D?+=D00% -1F+?-1F)

(39704) Reliability requirements(>) 1riticality of the application

() Safety and security considerations

This section captures non+functional requirements in the customers language. - more

formal presentation of these will occur in section 4.



13/21


2.5 Assumptions and Dependencies

5ist each of the factors that affect the requirements stated in the SRS. These factors are

not design constraints on the software but are% rather% any changes to them that can affect

the requirements in the SRS. 0or eample% an assumption might be that a specificoperating system would be available on the hardware designated for the software

product. #f% in fact% the operating system were not available% the SRS would then have tochange accordingly.

This section is catch+all for everything else that might influence the design of the system

and that did not fit in any of the categories above.

2.' Apportionin of Re+uirements.

#dentify requirements that may be delayed until future versions of the system. -fter youlook at the proect plan and hours available% you may reali&e that you ust cannot get

everything done. This section divides the requirements into different sections fordevelopment and delivery. Remember to check with the customer they should prioriti&ethe requirements and decide what does and does not get done. This can also be useful if

you are using an iterative life cycle model to specify which requirements will map to

which interation.

3. Specific Re+uirements

This section contains all the software requirements at a level of detail sufficient to enable

designers to design a system to satisfy those requirements% and testers to test that the

system satisfies those requirements. Throughout this section% every stated requirementshould be eternally perceivable by users% operators% or other eternal systems. These

requirements should include at a minimum a description of every input (stimulus) into thesystem% every output (response) from the system and all functions performed by the

system in response to an input or in support of an output. The following principles apply'

(1) Specific requirements should be stated with all the characteristics of agood SRS

correct

unambiguous

complete

consistent ranked for importance and3or stability

verifiable

modifiable

traceable(2) Specific requirements should be cross+referenced to earlier documents

that relate

Infogird Informatics Private Limited SRSv1.1 Page 1" of 210!11!1 f


14/21


(3) -ll requirements should be uniquely identifiable (usually via numbering

like 4../.4)

(4) 1areful attention should be given to organi&ing the requirements to

maimi&e readability (Several alternative organi&ations are given at end ofdocument)

*efore eamining specific ways of organi&ing the requirements it is helpful to understandthe various items that comprise requirements as described in the following subclasses.

This section reiterates section /% but is for developers not the customer. The customer

buys in with section /% the designers use section 4 to design and build the actualapplication.

Remember this is not design. o not require specific software packages% etc unless thecustomer specifically requires them. -void over+constraining your design. 8se proper

terminology'

The system shallK - required% must have feature

The system shouldK - desired feature% but may be deferred til laterThe system mayK -n optional% nice+to+have feature that may never make it to

implementation.

"ach requirement should be uniquely identified for traceability. 8sually% they are

numbered 4.% 4..% 4../. etc. "ach requirement should also be testable. -void

imprecise statements like% 9The system shall be easy to use< Iell no kidding% what doesthat mean6 -void 9motherhood and apple pie< type statements% 9The system shall be

developed using good software engineering practice>. 5ist every piece ofinformation that is required so the designers can build the right 8# and data tables.

3.1 /0terna$ Interfaces

This contains a detailed description of all inputs into and outputs from the software

system. #t complements the interface descriptions in section / but does not repeat

information there. Remember section / presents information oriented to the

customer3user while section 4 is oriented to the developer.

#t contains both content and format as follows'

?ame of item

escription of purpose

Source of input or destination of output

@alid range% accuracy and3or tolerance

Infogird Informatics Private Limited SRSv1.1 Page 1# of 210!11!1 f


15/21


8nits of measure

Timing

Relationships to other inputs3outputs

Screen formats3organi&ation

Iindow formats3organi&ation ata formats

1ommand formats

"nd messages

3.2 unctions

0unctional requirements define the fundamental actions that must take place in the

software in accepting and processing the inputs and in processing and generating the

outputs. These are generally listed as 9shall< statements starting with LThe systemshallK

These include'

@alidity checks on the inputs

"act sequence of operations

Responses to abnormal situation% including

Dverflow

1ommunication facilities

"rror handling and recovery

"ffect of parameters

Relationship of outputs to inputs% including

#nput3Dutput sequences 0ormulas for input to output conversion

#t may be appropriate to partition the functional requirements into sub+functions or sub+

processes. This does not imply that the software design will also be partitioned that way.

3.3 Performance Re+uirements

This subsection specifies both the static and the dynamic numerical requirements placed

on the software or on human interaction with the software% as a whole. Static numericalrequirements may include'

(a) The number of terminals to be supported

(b) The number of simultaneous users to be supported(c) -mount and type of information to be handled

Static numerical requirements are sometimes identified under a separate section entitled

capacity.

Infogird Informatics Private Limited SRSv1.1 Page 1$ of 210!11!1 f


16/21


ynamic numerical requirements may include% for eample% the numbers of transactions

and tasks and the amount of data to be processed within certain time periods for both

normal and peak workload conditions.

-ll of these requirements should be stated in measurable terms.

0or eample%

MHN of the transactions shall be processed in less than second

rather than%

-n operator shall not have to wait for the transaction to complete.

(?ote' ?umerical limits applied to one specific function are normally specified as part of

the processing subparagraph description of that function.)

3.4 oica$ Database Re+uirements

This section specifies the logical requirements for any information that is to be placedinto a database. This may include'

Types of information used by various functions

0requency of use

-ccessing capabilities

ata entities and their relationships #ntegrity constraints

ata retention requirements

#f the customer provided you with data models% those can be presented here. "R

diagrams (or static class diagrams) can be useful here to show comple datarelationships. Remember a diagram is worth a thousand words of confusing tet.

3.5 Desin &onstraints

Specify design constraints that can be imposed by other standards% hardware limitations%

etc.

3.5.1 Standards &omp$iance

Specify the requirements derived from eisting standards or regulations. They mightinclude'

() Report format



17/21


(/) ata naming

(4) -ccounting procedures

(;) -udit Tracing

0or eample% this could specify the requirement for software to trace processing activity.

Such traces are needed for some applications to meet minimum regulatory or financial

standards. -n audit trace requirement may% for eample% state that all changes to apayroll database must be recorded in a trace file with before and after values.

3.' Soft!are System Attributes

There are a number of attributes of software that can serve as requirements. #t is

important that required attributes by specified so that their achievement can be

obectively verified. The following items provide a partial list of eamples. These are

also known as non+functional requirements or quality attributes.

These are characteristics the system must possess% but that pervade (or cross+cut) the

design. These requirements have to be testable ust like the functional requirements. #tseasy to start philosophi&ing here% but keep it specific.

3.'.1 Re$iabi$ity

Specify the factors required to establish the required reliability of the software system at

time of delivery. #f you have $T*0 requirements% epress them here. This doesn2t refer

to ust having a program that does not crash. This has a specific engineering meaning.

3.'.2 Avai$abi$ity

Specify the factors required to guarantee a defined availability level for the entire system

such as checkpoint% recovery% and restart. This is somewhat related to reliability. Some

systems run only infrequently on+demand (like $S Iord). Some systems have to run /;3C

(like an e+commerce web site). The required availability will greatly impact the design.Ihat are the requirements for system recovery from a failure6 9The system shall allow

users to restart the application after failure with the loss of at most / characters of

input


18/21


-ssign certain functions to different modules

Restrict communications between some areas of the program

1heck data integrity for critical variables

3.'.4 (aintainabi$ity

Specify attributes of software that relate to the ease of maintenance of the software itself.

There may be some requirement for certain modularity% interfaces% compleity% etc.Requirements should not be placed here ust because they are thought to be good design

practices. #f someone else will maintain the system

3.'.5 Portabi$ity

Specify attributes of software that relate to the ease of porting the software to other host

machines and3or operating systems. This may include' ,ercentage of components with host+dependent code

,ercentage of code that is host dependent

8se of a proven portable language

8se of a particular compiler or language subset

8se of a particular operating system

Dnce the relevant characteristics are selected% a subsection should be written for each%eplaining the rationale for including this characteristic and how it will be tested and

measured. - chart like this might be used to identify the key characteristics (rating them

Aigh or $edium)% then identifying which are preferred when trading off design or

implementation decisions (with the # of the preferred one indicated in the chart to theright). The chart below is optional (it can be confusing) and is for demonstrating

tradeoff analysis between different non+functional requirements. A3$35 is the relative

priority of that non+functional requirement.

ID aracteristic %( 1 2 3 4 5 ' ) * 1 11 12

1 Correctness

2 Efficiency

3 Flexibility

4 Integrity!ec"rity

5 Intero#er$bility

% &$int$in$bility7 'ort$bility

8 eli$bility

9 e"s$bility

10 est$bility

11 *s$bility

12 +,$il$bility

Infogird Informatics Private Limited SRSv1.1 Page 1& of 210!11!1 f


19/21


efinitions of the quality characteristics not defined in the paragraphs above follow.

O 1orrectness + etent to which program satisfies specifications% fulfills user2s

mission obectives

O "fficiency + amount of computing resources and code required to perform functionO 0leibility + effort needed to modify operational program

O #nteroperability + effort needed to couple one system with another

O Reliability + etent to which program performs with required precisionO Reusability + etent to which it can be reused in another application

O Testability + effort needed to test to ensure performs as intended

O 8sability + effort required to learn% operate% prepare input% and interpret output

TA" 0D55DI#?7 (4.C) is not really a section% it is talking about how to organi&e

requirements you write in section 4./. -t the end of this template there are a bunch of

alternative organi&ations for section 4./. 1hoose the D?" best for the system you arewriting the requirements for.

3.) raniin t#e Specific Re+uirements

0or anything but trivial systems the detailed requirements tend to be etensive. 0or thisreason% it is recommended that careful consideration be given to organi&ing these in a

manner optimal for understanding. There is no one optimal organi&ation for all systems.

ifferent classes of systems lend themselves to different organi&ations of requirements insection 4. Some of these organi&ations are described in the following subclasses.

3.).1 System (ode

Some systems behave quite differently depending on the mode of operation. Ihen

organi&ing by mode there are two possible outlines. The choice depends on whether

interfaces and performance are dependent on mode.

3.).2 -ser &$ass

Some systems provide different sets of functions to different classes of users.

3.).3 b6ects

Dbects are real+world entities that have a counterpart within the system. -ssociated

with each obect is a set of attributes and functions. These functions are also called

services% methods% or processes. ?ote that sets of obects may share attributes andservices. These are grouped together as classes.

Infogird Informatics Private Limited SRSv1.1 Page 1' of 210!11!1 f


20/21


3.).4 eature

- feature is an eternally desired service by the system that may require a sequence of

inputs to effect the desired result. "ach feature is generally described in as sequence eofstimulus+response pairs.

3.).5 Stimu$us

Some systems can be best organi&ed by describing their functions in terms of stimuli.

3. ).' Response

Some systems can be best organi&ed by describing their functions in support of the

generation of a response.

3.).) unctiona$ %ierarc#y

Ihen none of he above organi&ational schemes prove helpful% the overall functionality

can be organi&ed into a hierarchy of functions organi&ed by either common inputs%common outputs% or common internal data access. ata flow diagrams and data

dictionaries can be use dot show the relationships between and among the functions and

data.

3.* Additiona$ &omments

Ihenever a new SRS is contemplated% more than one of the organi&ational techniquesgiven in 4.C may be appropriate. #n such cases% organi&e the specific requirements formultiple hierarchies tailored to the specific needs of the system under specification.

Three are many notations% methods% and automated support tools available to aid in thedocumentation of requirements. 0or the most part% their usefulness is a function of

organi&ation. 0or eample% when organi&ing by mode% finite state machines or state

charts may prove helpfulP when organi&ing by obect% obect+oriented analysis may provehelpfulP when organi&ing by feature% stimulus+response sequences may prove helpfulP

when organi&ing by functional hierarchy% data flow diagrams and data dictionaries may

prove helpful.

#n any of the outlines below% those sections called 90unctional Requirement i< may be

described in native language% in pseudocode% in a system definition language% or in four

subsections titled' #ntroduction% #nputs% ,rocessing% Dutputs.

4. ane (anaement Process



21/21


#dentify the change management process to be used to identify% log% evaluate% and update

the SRS to reflect changes in proect scope and requirements. Aow are you going to

control changes to the requirements. 1an the customer ust call up and ask for

something new6 oes your team have to reach consensus6 Aow do changes torequirements get submitted to the team6 0ormally in writing% email or phone call6

5. Document Approva$s

#dentify the approvers of the SRS document. -pprover name% signature% and date should

be used.

'. Supportin Information

The supporting information makes the SRS easier to use. #t includes'

Table of 1ontents

#nde

-ppendices

The -ppendices are not always considered part of the actual requirements specification

and are not always necessary. They may include'

(a) Sample #3D formats% descriptions of cost analysis studies% results of user

surveys

(b) Supporting or background information that can help the readers of the SRS(c) - description of the problems to be solved by the software

(d) Special packaging instructions for the code and the media to meet security%

eport% initial loading% or other requirements

Ihen -ppendices are included% the SRS should eplicitly state whether or not the

-ppendices are to be considered part of the requirements.

$bles on t-e folloing #$ges #ro,i/e $ltern$te $ys to str"ct"re section 3 on t-e s#ecific

re"ireents. o" s-o"l/ #ic t-e best one of t-ese to org$nie section 3 re"ireents.

Infogird Informatics Private Limited SRSv1.1 Page 21 of 21

Sachin Sir SRSVersion1.Doc

Documents

Transcript of Sachin Sir SRSVersion1.Doc