EXPERIMENT_NO_2.pptx realted to software labs

Experiment No-2
Do requirement analysis and develop Software Requirement
Specification Sheet
(SRS) for suggested system.

Description of an SRS
• Software Requirement Specification (SRS) is a document that describes the requirements of
a computer system from the user's point of view.
• An SRS document specifies: The required behaviour of a system in terms of: input data,
required processing, output data, operational scenarios and interfaces. The attributes of a
system including: performance, security, maintainability, reliability, availability, safety
requirements and design constraints.

Major Goals of an SRS
• 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
behaviour necessary to address those problems. Therefore, the SRS should be written in
natural language (versus a formal language, explained later in this article), in an
unambiguous manner that may also include charts, tables, data flow diagrams, decision
tables, and so on.
• 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.

• 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 system
requirements so that a design solution can be devised.
• 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.

IEEE –SRS DOCUMENT TEMPLATE
• 1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References

Overall Description
2.Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies

External Interface Requirements
3. External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces

System Features
4. System Features
4.1 System Feature 1
4.2 System Feature 2 (and so on)

Other Nonfunctional Requirements
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Business Rules

Other Requirements
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: To Be Determined List

1. 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 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 Product Scope

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 Functions
• Summarize the major functions the product must perform or must let the user perform. Details will be provided in Section 3, so only a high
level summary (such as a bullet list) 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 object 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 most important user classes for
this product 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. External Interface Requirements
3.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.
3.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.
3.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.

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

EXPERIMENT_NO_2.pptx realted to software labs

(iv)There will be a screen for capturing and displaying information regarding which
passenger is currently reserved in which train and what is the class of that seat.
(v)There will be a screen that will capture information regarding the discount in
the fare of the ticket. Discount will be given on various basis like senior
citizen, student concession, scheduled cast etc.
(vi)There will be a screen for capturing and displaying information regarding
which all user account exist in the system, thus showing who all can access the
system.
The following reports will be generated:
(i)Reservation Chart: Printable report will be generated to show the list of
the passengers reserved in a particular train along with the class of their travel.
(ii)RAC Chart: Printable report will be generated to show to show the list of
passengers who are getting their seats in RAC in a particular train.
(iii)Waiting List: Printable reports will be generated to show the list of the
passengers who are in the waiting list of the reservation for their seats in a particular train.
(iv)Monthly Report: Monthly report will be generated for the railway department
to show how many passengers have traveled during the particular month.

2.1.3 HARDWARE INTERFACES
(i)Screen resolution of at least 800x600-required for proper and complete viewing of
screen. Higher resolution would not be a problem.
(ii)Support for printer (dot –matrix /DeskJet /inkjet etc –any will do)-that is, appropriate
drivers are installed and printer connected printers will required for printing of reports.
(iii)Standalone system or network based-not a concern, as it will be possible to run the
application on any of these.
2.1.4SOFTWARE INTERFACES
(i) Any window -based operating system (window 95/98/2000/XP/NT).
(ii) MS access 2000 as the DBMS—for database. Future release of the application will
aim at upgrading to oracle 8i as the DBMS.
(iii) Crystal reports 8—for generating and viewing pay slips and discharge slips.
(iv) Visual Basic 6—for coding /developing the software.
• Software mentioned in pts. (iii) and (iv) above will be required only for development of the
application. The final application will be packaged as an independent setup program that will be
delivered to the client (hospital in this case).

2.1.5 COMMUNICATION INTERFACES
• None
2.1.6 MEMORY CONSTRAINTS
• At least 64 MB RAM and 2 GB space on hard disk will be required for running the program.
2.1.7 OPERATIONS
• This product release will not cover any automated housekeeping aspects of the database. The
DBA at the client site (i.e., Railways) will be responsible for manually deleting old/non-
required data. Database backup and recovery will also have to be handled by the DBA.
However, the system will provide a ‘RESET SYSTEM’ function that will delete (upon
conformation from the administrator) all the existing information from the database.
2.1.8 SITE ADAPTATION REQUIREMENTS
• The terminals at client site will have to support the hardware and software interface specified
in above section.

2.2 PRODUCT FUNCTIONS
The system will allow access only to authorized users with specific roles. Depending upon the user’s role
he/she will be able to access only specific modules of the system.
A summary of the major functions that the software will perform:
i. A LOGIN facility for enabling only authorized access to the system.
ii. User (with role Reservation Clerk) will be able to add/modify/delete information about different
passengers that are reserving their ticket in different trains and dates.
iii. User (with role Reservation Clerk) will be able to add/modify/delete information about different seats
that are offered in a train (1AC, 2AC, 3AC, Sleeper). The Reservation list of passengers along with their
class should be displayed.
iv. User (with role Reservation Clerk) will be able to add/modify/delete information about the waiting list
of the passengers and their RAC.
v. User (with role Reservation Clerk) will be able to print the ticket of the passenger.
vi. User (with role Administrator) will be able to generate printable reports.
vii. User (with role Administrator) will be able to ‘Reset’ the system – leading to deletion of all existing
information from the backend database.
viii. User (with a role Administrator) will be able to create/ modify/ delete new/ existing user accounts.

2.3 USER CHARACTERISTICS
(i) Educational Level- At least a graduate should be comfortable with English.
(ii) Experience- Should be well informed about the features concerning railways. Technical
expertise-Should be comfortable with general purpose applications of computer.
(iii) Technical expertise-Should be comfortable with general purpose applications of
computer.
2.4 CONSTRAINTS
(i) Since the DBMS being used in MS access 2000, which is not a very powerful DBMS it
will not be able to store a very huge number of records.
(ii) Due to limited features of DBMS being used performance tuning features will not be
applied to the queries and thus the system may become slow with the increase in the records
being stored.
(iii) Due to limited features of DBMS being used, database auditing will also not be provided.
(iv)Users at Railway Reservation will have to implement a security policy to safeguard the
passenger related information from being modified by unauthorized users (by means of
gaining access to the backend database).

The numbers of seats in a train are fixed. There should be no additions in the number of births.
2.6APPORTIONING OF REQUIREMENTS
None.
3. SPECIFIC REQUIREMENTS
This section contains the software requirements to a level of detail sufficient to enable designers
to design the system, and testers to test that system.
3.1 EXTERNAL INTERFACE REQUIREMENTS
3.1.1 USER INTERFACES
The following screens will be provided:
Login Screen:
This will be the first screen that will be displayed. It will allow user to access different screens
based upon the user’s role. Various fields available on this screen will be:
•User ID: Alphanumeric of length upto 10 characters.
•Password: Alphanumeric of length upto 8 characters.
•Role: Will have the following values: Administrator, Coordinator, Reservation
Clerk.

Train Info Parameters Screen:
This screen will be accessible only to user with role Administrator. It will allow the user to enter the name of train for
which the user wants to access the train information.
Train Information Screen:
This screen will be accessible only to user with role Administrator. It will allow user to add/modify/delete information
about new/existing train(s) for a particular date that was selected in the ‘Train Info Parameters’ screen. The list of
available seats for that train will also be displayed. Various fields available on this screen will be:
(i) Train number: of format T#### (# represent a digit).
(ii)Train Name: Alphanumeric of length upto 50 characters.
(iii) Seats: Number of total seats in each class section of the train.
Passenger Info Parameters Screen:
This screen will be accessible only to user with role Administrator. It will allow the user to enter the train number for
which the user wants to access the passenger information. Passenger Information Screen:
This screen will be available only to role Administrator. It will allow the user to add/modify/delete information about
new/existing student(s) for a particular train number. Train wise list of passenger will also be displayed. Various fields
available on these screens will be:
(i) PNR number: of the format PNR########## (# represent Alphanumeric digits).
(ii) Passenger Name: will have only alphabetic letters and length upto 40 characters.
(iii) Sex: will have only one alphabet either ‘M’ or ‘F’.
(iv) Age: will have only three digits.
(v)Train number: of the format T#### (# represent a digit).

Passenger’s Train Choice Parameters Screen:
This screen will be accessible only to user with role Administrator. It will allow the user to enter the train number and the class of the travel
for which the user wants to access the passenger’s train choice information.
Passenger’s Train Choice Information Screen:
This screen will be accessible only to user with role Administrator. It will allow the user to add/modify/delete passenger’s choices for the
trains selected in ‘Passenger’s Train Choice Parameters’ screen. For the selected train it will display the list of seats available in the choices
of the passenger. The screen will display the list of passengers who have been allotted the seat. The user will be able to
view/add/modify/delete the passenger’s choice in the list.
Passenger Entry Info Screen:
This screen will be accessible only to user with role Reservation Clerk. It will allow the user to enter the train number and the class of the
train for which the user wants to access the passenger information.
Non Availability Info Screen:
This screen will be accessible to the user with the role Administrator. It will display the error message to the user about the non-availability
of the seats in the current train and class. It allows user to enter another choice for the train number and class. It also allows the user if he
wants to continue reserving in the current train and class in the waiting section.
Passenger Entry Screen:
This screen will be accessible only to user with role Reservation Clerk. It will allow user to add/modify/delete information about the seats
reserved by different passengers who have been or are going to be allotted seats in the train number and class selected in the ‘Passenger
Entry Info’ screen. The screen will display the list of passengers currently who have been allocated the seats. The user will be able to
view/add/modify/delete the passenger information in the list. Various fields available on this screen will be:
(i) PNR number: PNR number of all passengers in the current train.
(ii) Passenger Name: will display the name of passenger.
(iii) Sex: will display the sex of the passenger.
(iv) Age: will display the age of the passenger.
(v) Status: will display the status of the reservation i.e. whether the passenger has been allotted the seat and its seat number or is in RAC or
WL.Passenger Parameters Screen:
This screen will be accessible only to user with role Reservation Clerk. It will allow the user to enter the PNR number and the Train number
of the passenger for whom the user wants to view/print the ticket.

Passenger List Report Parameters:
This screen will be accessible only to user with role Coordinator. It will allow the user
to enter the train number for which the user wants to view/print the passenger list
report.
RAC List Parameters Screen:
to enter the train number for which the user wants to view/print the RAC list report.
WL List Parameters Screen:
to enter the train number for which the user wants to view/print the WL report.
Monthly Passenger List Report Parameters:
to enter the month for which the user wants to view/print the passenger list report.

3.1.3 SOFTWARE INTERFACES
As stated in section 2.1.4.
3.1.4 COMMUNICATIONS INTERFACES
None.
3.2 SOFTWARE PRODUCT FEATURES
3.2.1 TRAIN INFORMATION MAINTENANCE Description:
The system will maintain information about various trains being offered to the passengers. The following information
would be maintained for each train:
Train number, train name, train type (superfast, express, passenger, mail etc.), total seats, classes, number of the
station the train will pass through.
The system will allow creation/modification/deletion of new/existing trains.
Validity Checks:
• Only user with role Administrator will be authorized to access the Train information
Maintenance module.
• Each compartment will have a maximum of 72 seats.
• Each train will have atleast two classes.
• Train number will be different for each train.
• Train number cannot be blank.
• PNR number cannot be blank.
• Train name cannot be blank.
• Number of seats cannot be zero.

Sequencing Information:
• Train info will have to be entered in the system before any info regarding passenger is
entered.
Error Handling/ Response to Abnormal Situations:
• If any of the above validations/ sequencing flow does not hold true, appropriate error msg.
will be prompted to user for doing the needful.

3.2.2 PASSENGER INFORMATION MAINTENANCE
Description:
The system will maintain information about various passengers allotted seats or are waiting to be allotted
seats in different trains. The following information would be maintained for each train:
Train number, PNR number, Class, Passenger Info.
The system will allow creation/modification/deletion of new/existing passengers and also have the
ability to list all the passengers allotted or are waiting to be allotted seats in a particular train.
Validity Checks
(i) Only user with role Reservation Clerk will be authorized to access the Passenger Information
Maintenance module.
(ii) Every passenger will have a unique PNR number.
(iii) PNR number cannot be blank.
(iv) Passenger name cannot be blank.
(v) Train number cannot be blank.
Sequencing Information:
Train info will have to be entered in the system before any info regarding passenger is entered.
Error Handling/ Response to Abnormal Situations:
If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be
prompted to user for doing the needful.

TICKET GENERATION
DescriptionAVE THE FOLLOWING FORMAT:

• Validity Checks:
• (i) Only User with role Coordinator will be authorized to access the Ticket Generation module.
• Sequencing Information:
• Ticket for a particular passenger can be generated by the system only after PNR number has been
entered in the system for a given train number, the passenger info for that ticket has been entered
in the system, the choice for the train has been entered in the system, the journey date, and the
amount has been paid to the reservation clerk.
• Error Handling/ Response to Abnormal Situations:
• If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be

Report Generation
• Passenger List and RAC Report:
• For each train a passenger list and a RAC list will be generated containing the list of
passengers who have been allotted seats in the train.
• INDIAN RAILWAYS
• NAME OF TRAIN
• TRAIN NUMBER
• Other types of report may be generated

• USER ACCOUNTS INFORMATION MAINTENANCE
• Description: The system will maintain information about various users who will be able to
access the system. The following information would be maintained:
• User Name, User ID, Password, and Role.
• Validity Checks:
• (i) Only user with role Administrator will be authorized to access the User Accounts
Information Maintenance module.
• (ii) User Name cannot be blank.
• (iii) User ID cannot be blank.
• (iv) User ID should be unique for every user.
• (v) Password cannot be blank.
• (vi) Role cannot be blank

• Sequencing Information:
• User Account for particular user has to be created in order for the system to be accessible to that
user. AT system startup, only a default user account for ‘Administrator’ would be present in the
system.
• Error Handling/ Response to Abnormal Situations:
• If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be
• 3.3 PERFORMANCE REQUIREMENTS
• None
• 3.4 DESIGN CONSTRAINTS
• None

• SOFTWARE SYSTEM ATTRIBUTES
• 3.5.1 SECURITY
• The application will be password protected. Users will have to enter correct username,
password and role in order to access the application.
• 3.5.2 MAINTAINABILITY
• The application will be designed in a maintainable manner. It will be easy to incorporate new
requirements in the individual modules (i.e., new trains, new timings, fare hike).

• 3.5.3 PORTABILITY
• The application will be easily portable on any windows-based system that has MS-Access 2000
installed.
• 3.6 LOGICAL DATABASE REQUIREMENTS
• The following information will be placed in the database:
• (i) Passenger Info.
• (ii) PNR Number.
• (iii) Destination.
• (iv) Train Number.
• 3.7 OTHER REQUIREMENTS
• None.

EXPERIMENT_NO_2.pptx realted to software labs

More Related Content

Similar to EXPERIMENT_NO_2.pptx realted to software labs (20)

Recently uploaded (20)

EXPERIMENT_NO_2.pptx realted to software labs