5.

Other Nonfunctional Requirements

 System should Automatically Update After Every Transcation

 No of daily system downs Should not more than 10.
 Response Time Should be minimum.
 More than three attempts at login and failure will produce a red flag to system administrator.
 Input errors will be returned in red with appropriate message box.
 The software interface must follow design conventions which allow for familiar location of
menus,etc.

5.1 Performance Requirements

 Encryption will Enable Security

 System should be operable 24 hours a day and accessible in real-time.
 Power supply should have a back up and a disaster recovery plan.
 Data should be secured and backed up every quarter hour.
 95% of the transactions shall be processed in less than one second.
 The Physician software should be able to support at least three simultaneous users.

5.2 Safety Requirements

 Staff can just see the products

 System will use secure Database
 The Database may get crashed or damaged due to some viruses or operating system
requirements. Therefore Its is mandatory to have backup for your data .Ups/inverter
facility should be there in case of power failure.
 There should be separate account for Admin
 Proper user Authentication Will be provided. mark their attendance .They Cannot edit
or ,modify anything except their personal information. &user. So that no one else can
access the database except Admin.

5.3 Security Requirements

unauthorized malicious programs do not infect the application or component – communications

and data are not intentionally corrupted – parties to interactions with the application or
component cannot later repudiate those interactions – confidential communications and data
are kept private – applications survive attack – system (people and application) are protected
against destruction, damage, theft, or surreptitious replacement – system maintenance does
not unintentionally disrupt the security mechanisms

5.4 Software Quality Attributes

The system must be:

 Easy to use for input preparation, operation, and interpretation of the output.
 Provide consistent user interface standards or conventions with our other frequently used
systems.
 Easy for new or infrequent users to learn to use the system.

Portability
This can be measured in terms of Costing issues related to porting, Technical issues related to
porting, Behavioral issues related to porting.

Correctness
The application should be correct in terms of its functionality, calculations used internally and the
navigation should be correct. This means the application should adhere to functional requirements.

Efficiency
Major system quality attribute. Measured in terms of time required to complete any task given to
the system. For example, the system should utilize processor capacity, disk space and memory
efficiently.
If system is using all the available resources then the user will get degraded performance failing
the system for efficiency. If system is not efficient then it can not be used in real-time applications.

Integrity or Security
Integrity comes with security. System integrity or security should be sufficient to prevent
unauthorized access to system functions, preventing information loss, ensure that the software is
protected from virus infection, and protecting the privacy of data entered into the system.

Testability
The system should be easy to test and find defects. If required should be easy to divide into
different modules for testing.

Flexibility
Should be flexible enough to modify. Adaptable to other products with which it needs interaction.
Should be easy to interface with other standard 3rd party components.

Reusability
Software reuse is a good cost-efficient and time-saving development way. Different code libraries
classes should be generic enough to use easily in different application modules. Dividing
application into different modules so that modules can be reused across the application.

Interoperability
Interoperability of one system to another should be easy for the product to exchange data or
services with other systems. Different system modules should work on different operating system
platforms, different databases, and protocols conditions.

5.5 Business Rules

 The software must allow input of products data from Administrator& The project must allow
browsing by the Director
 The project must require high levels of error correction and input validation.
 The project must request username and password for access to data, only after
authentication will allow access to the system.
 secured access at , and from the data streaming real-time monitoring equipment &Staff of
Cms To Acces And update information products & The project must identify the Products
 ,Customers ,vendors. Customer by a unique numeric identifier derived from a function
performed on the Customer’s birth date or product Id;

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

Appendices may be used to provide additional (and hopefully helpful) information. If present, the
SRS should explicitly state whether the information contained within an appendix is to be
considered as a part of the SRS’s overall set of requirements.

Example Appendices could include (initial) conceptual documents for the software project,
marketing materials, minutes of meetings with the customer(s), etc.

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: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>