Software Requirements

Specification
for

<Project>
Version <X.X>

Prepared by
Group Name: <place your group name here>
<name>
<name>
<name>
<name>
<name>

<student #>
<student #>
<student #>
<student #>
<student #>

Project Guide :
Company Name :
Course:
Teaching guide :
Date:

Content

<e-mail>
<e-mail>
<e-mail>
<e-mail>
<e-mail>

<place your industrial guides name here>

<place your company name here>
<place your course name here>
<place your Teachers name here>
<place the date of submission here>

REVISIONS................................................................................................................................................................III
1

INTRODUCTION................................................................................................................................................1
1.1

DOCUMENT PURPOSE.................................................................................................................................1

1.2

PRODUCT SCOPE........................................................................................................................................1

1.3

INTENDED AUDIENCE AND DOCUMENT OVERVIEW....................................................................................1

1.4

DEFINITIONS, ACRONYMS AND ABBREVIATIONS.........................................................................................1

1.5

DOCUMENT CONVENTIONS.........................................................................................................................1

1.6

REFERENCES AND ACKNOWLEDGMENTS...................................................................................................2

OVERALL DESCRIPTION...............................................................................................................................3
2.1

PRODUCT PERSPECTIVE.............................................................................................................................3

2.2

PRODUCT FUNCTIONALITY..........................................................................................................................3

2.3

USERS AND CHARACTERISTICS..................................................................................................................3

2.4

OPERATING ENVIRONMENT.........................................................................................................................3

2.5

DESIGN AND IMPLEMENTATION CONSTRAINTS...........................................................................................4

2.6

USER DOCUMENTATION..............................................................................................................................4

2.7

ASSUMPTIONS AND DEPENDENCIES...........................................................................................................4

SPECIFIC REQUIREMENTS...........................................................................................................................5
3.1

EXTERNAL INTERFACE REQUIREMENTS.....................................................................................................5

3.2

FUNCTIONAL REQUIREMENTS.....................................................................................................................6

3.3

BEHAVIOUR REQUIREMENTS.......................................................................................................................6

OTHER NON-FUNCTIONAL REQUIREMENTS..........................................................................................7

4.1

PERFORMANCE REQUIREMENTS................................................................................................................7

4.2

SAFETY AND SECURITY REQUIREMENTS...................................................................................................7

4.3

SOFTWARE QUALITY ATTRIBUTES..............................................................................................................7

OTHER REQUIREMENTS................................................................................................................................8

APPENDIX A DATA DICTIONARY........................................................................................................................9

APPENDIX B - GROUP LOG..................................................................................................................................10

Revisions
Version

Primary Author(s)

Description of Version

Draft Type
and
Number

Full Name

Information about the revision. This table does

not need to be filled in whenever a document is
touched, only when the version is being
upgraded.

Date Completed
00/00/00

<In this template you will find text bounded by the <> symbols. This text appears in italics and
is intended to guide you through the template and provide explanations regarding the different
sections in this document. There are two types of comments in this document. These comments
that are in black are intended specifically for that course. These comments that are in blue are
more general and apply to any SRS. Please, make sure to delete all of the comments before
submitting the document.
The explanations provided below, do not cover all of the material, but merely, the general nature
of the information you would usually find in SRS documents. It is based on the IEEE
requirements and was adapted specifically for the needs of Software Engineering 3K04/3M04
courses. Most of the sections in this template are required sections, i.e. you must include them
in your version of the document. Failure to do so will result in marks deductions. Optional
sections will be explicitly marked as optional.

1 Introduction
1.1 Purpose
ThepurposeofthisdocumentistodescribetheMedicalStoreManagementSystem(MSMS)
product.Thisdocumentcontainsthefunctionalandnonfunctionalrequirementsoftheproject.This
documentcontainsdetaildescriptionofproject.

1.2 Product Scope

MSMS product is basically updating the manual medical store system into a internetbased
applicationsothattheuserscanknowthedetailsoftheiraccounts,availabilityofstocksandexpiry
details.TheprojectisspecificallydesignedfortheuseofAdminandemployeeusingthesystem.

MSMSissoftwarethatmanagesalltherecordsofthemedicinesandotherconcernedentitieslike
debtorsandcreditors.Itsavesalotoftime,energy&money.Moreoveritprovidesquick&efficient
services.Themainaimoftheprojectistocreateautomatedsoftwarewhichispurelyusedtoserve
completeMedicalInventoryManagement,ControlStocks,Expiry&Claims,andEffectivePurchase
Management.DevelopingaMSMSwouldbenefitthechemistshopmanagement.SiceitisSoftware
drivenfollowingwellorganizedapproachthequalityofservicescanbeenhancedconsiderably.Each
employeessalesinformationisstoreindatabase.

MedicalStoreSoftwareforIndividualShoporRetailChainisdesignedtohandlealltheneedsin
mostefficient,effective&accurateway.SincethenMedicalBillingSoftwareiscommittedtoprovide
thebestsupportingsystemfortheRetail&DistributionBusinessupgradingitselffromtimetotime
accordingtothemarketneeds.

1.3 Intended Audience and Document Overview

Theintendedreadersofthisdocumentarethe

Developers of the site

Testers

admin

Anysuggestedchangesontherequirementslistedonthisdocumentshouldbeincludedinthe
lastversionofitsoitcanbeareferencetodevelopingandvalidatingteams.

1.4 Definitions, Acronyms and Abbreviations

MSMS

1.5 Document Conventions

<In general this document follows the IEEE formatting requirements. Use Arial font size 11, or 12
throughout the document for text. Use italics for comments. Document text should be single spaced
and maintain the 1 margins found in this template. For Section and Subsection titles please follow
the template.

TO DO: Describe any standards or typographical conventions that were followed when writing this
SRS, such as fonts or highlighting that have special significance. Sometimes, it is useful to divide
this section to several sections, e.g., Formatting Conventions, Naming Conventions, etc.>

1.6 References and Acknowledgments

IEEEstandardforwritingSRSdocument.

I.Sommerville,SoftwareEngineering,8thAddisonWesley,2007.

2 Overall Description
2.1 Product Perspective
MSMSisareplacementfortheordinarymedicalstoremanagementsystemswhichdependonexcel
forrecordingmedicineandcustomersinformation.
MSMSwillprovideanadvancedmedicinesearchmechanismandwillmakeiteasytomaintain
stockandalltheinventoryrelatedtask.

2.2 Product Functionality

2.2.1 Administrators

Admin should be able to insert, modify and delete products ie medicine.

can manage different branches of the store. Also manage employees of all branches.

can manage accounts. That includes balance sheet, profit & loss account and delay-inpayment modules.

can add, delete and update employees of all branches.

manage distributors for the store. Admin receives quotation from different distributors, then
places purchase order, receives invoice and manages payment to distributors.

Add and edit medicine and can get the information where it is store.

Add and edit employees and distributors information.

Can send lateness warnings to customers who have exceeded deadline date for payment.

2.2.2 Normal Users (employees of the store)

Employees can manage customers of the store. Can add, update and delete customers.

Employees can generate bill and manage payment for the customers.

Employees can manage retailor-customers. Can give quotation to them. Receive purchase
order, generate invoice and manage payment and delivery of stock to retailor-customer.

The employees should be provided with the updated information about the products catalog.

Employees can manage stock for the store.

Employees have the ability to search through products by brand and range related to the
product.

Admin should be able to insert, modify and delete products

2.2.1Administrators

Adminshouldbeabletoinsert,modifyanddeletemedicine

Canacceptorrejectaemployeeaccordingtotheneedandsalaryismanaged.

Cangettheinformation(statusreport)ofanyemployeewhohassoldhowmuchproduct
fromwhichshop.

Addandeditmedicinefromthestock.

Addandeditcustomerinformation

SoftwareRequirementsSpecificationforWLMS

Page3

Canseethereportaccordingtobrands,product,doctorwisetochecktheavailability.

2.2.2Employee(operatingthesoftware)

Themembershouldbeprovidedwiththeupdatedinformationaboutthebookscatalog.

Membersaregivenaprovisiontocheckthtwareeiraccountsinformationandchangeit.

Membershavetheabilitytosearchthroughbooksbysubject,title,authorsoranyinformation
relatedtothebook.

Canextendtheperiodofborrowingbooksaccordingtothelibrarypolicy.

Thecustomermaysuggestabooktobebroughttothelibrarybookcollection.

2.3 Users and Characteristics

Usersofthewebsiteare theadministratorsandemployeeswhomaintainthewebsite.
Employeeshouldarehavebasicknowledgeofcomputers.Administratorsofthesystemshould
havemoreknowledgeofinternalmodulesofthesystemandareabletorectifysmallproblems
thatmayariseduetodiskcrashes,powerfailuresandothercatastrophes.Friendlyuserinterface,
helpanduserguidemustbesufficienttoeducatetheusersonhowtousethisproductwithoutany
problemsordifficulties.

2.4 Operating Environment

TheMSMSisanapplicationandshalloperateinallcentralizedstoreofsamebranchwhere
applicationisinstalled.

2.5 Design and Implementation Constraints

Theinformationofallemployees,medicineandstockmustbestoredina
databasethatisaccessiblebytheapplications.

MSSQLServerwillbeusedasSQLengineanddatabase.

Themedicalstoremanagementsystemisrunning24hoursadayaswheneverisrequired.

UsersmayaccessMSMLfromcomputerthathasinstalledapplicationinitandasitisa
centralizedsoftwareanditcannotbefromanywebbrowser.

SoftwareRequirementsSpecificationforWLMS

Page4

Employeesmusthavetheircorrectusernamesandpasswordstoenterintosystemand
doactions.

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.
TO DO: You will not actually develop any user-manuals, but you need to describe what kind of
manuals and what kind of help is needed for the software you will be developing. One paragraph
should be sufficient for this section.>

2.7 Assumptions and Dependencies

Theproductneedsthefollowingthirdpartyproducts.

MicrosoftSQLservertostorethedatabase.

JavatodeveloptheProduct

Thesuccessofthissystemdependson

ExistenceofanInternetserviceisneeded.

Areadministorandemployeescomfortablewithcomputersandhaveenoughconationto
workwiththeproduct?

Applicationinterfacemustbefriendlyandeasytouse.

Thesearchmechanismshouldbesimpleandfast.

Calculationofstockshouldbeappropriateandexpiryinformationsholdouldalsobe
correctandwithpropercalculations

3 Specific Requirements
3.1 External Interface Requirements
3.1.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.,
Cancel) that will appear on every screen, error message display standards, and so on. Define
the software components for which a user interface is needed.
TO DO: The least you can do for this section is to describe in words the different User Interfaces
and the different screens that will be available to the user. Those who will be able to provide
optional Graphical User Interface screenshots, will be rewarded by extra marks.>

3.1.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.
You are not required to specify what protocols you will be using to communicate with the
hardware, but it will be usually included in this part as well.
TO DO: Please provide a short description of the different hardware interfaces. If you will be
using some special libraries to communicate with your software mention them here. In case you
have more than one hardware interface divide this section into subsections.>

3.1.3 Software Interfaces

3.1.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
communicationAdminstandards that will be used, such as FTP or HTTP. Specify any
communication security or encryption issues, data transfer rates, and synchronization
mechanisms.

TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the
major communication standards. For example, if you decide to use encryption there is no need
to specify the exact encryption standards, but rather, specify the fact that the data will be
encrypted and name what standards you consider using. >

forms, and so on. Define any pertinent message formatting. Identify any Functional
Requirements

Prerequisite (admin signed in) for all requirements below

Requirement ID: R1.01.01

Title:insert employee
Description: This action is done to add new employee of the store.
Priority:2

Requirement ID: R1.01.02

Title: delete / modify employee
Description: This event is to delete an existing employee or modify its information.
Priority:2

Requirement ID:R1.01.03
Title:Validate employee account
Description:when a new employee sign up then he should wait for acceptance by Administrator
according to store policies.
Priority:1

Requirement ID:R1.01.04
Title:delete employee
Description:Admin can delete an employee due to some specific rules.
Priority: 2

Requirement ID:R1.01.05
Title:maintain balance sheet
Description:Admin can manage balance sheet.
Priority:1

Requirement ID: R1.01.06

Title:insert distributor
Description: This action is done to add new distributor for the store.
Priority: 2

Requirement ID: R1.01.07

Title: delete / modify distributor
Description: This event is to delete an existing distributor or modify its information.
Priority:2
Requirement ID:R1.01.08
Title:delete distributor
Description:Admin can delete an distributor due to some specific rules.
Priority: 2

Requirement ID:R1.01.09
Title:place a purchase order to distributor
Description:Admin can place a purchase order to distributor.
Priority:1

3.1.2 Normal User(Employee of the store)

Requirement ID:R1.02.01
Title:register
Description:when new user enters WLMS for the first time then he has to register
Priority:3

Requirement ID:R1.02.02

Title: add new stock

Description:employee can add new stock i.e product
Priority:1

Requirement ID:R1.02.03
Title: update or modify the stock information
Description:an employee can update or modify stock information
Priority:1

Requirement ID:R1.02.04
Title:edit personal information
Description:if some customer changes for example his mobile number, an employee can modify
it.
Priority: 2

Requirement ID:R1.02.05
Title:reset password
Description:when a member forgets his password he can claim it back via e-mail.
Priority:1

3.1.3 Common Functions

Requirement ID:R1.03.01
Title:login
Description:both Admin and employee must be logged in before they modify any information
Priority:1

Requirement ID:R1.03.02
Title:search for product i.e musical instrument

Description:when an employee or admin wants to search on some product by name,brand or

range, etc.
Priority:1

3.2 Behaviour Requirements

3.2.1 Use Case View
<A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. Since sometimes we will not be able to specify completely the behaviour of
the system by just State Diagrams, we use use-cases to complete what we have already started
in section 3.3.1.

TO DO: Provide a use case diagram which will encapsulate the entire system and all possible
actors. Do not include detailed use case descriptions (these will be needed when you will be
working on the Test Plan), but make sure to include a short description of what every use-case
is, who are the actors in your diagram. For more information please refer to your UML guide and
the MiniThermostat SRS example file.>

4 Other Non-functional Requirements

4.1 Performance Requirements

Thesystemshallaccommodatehighnumberofmedicineandemployeeswithoutany
fault.

Responsestoviewinformationshalltakenolongerthan5secondstoappearonthe
screen.

4.2 Safety and Security Requirements

System use shall not cause any harm to human users.

Systemwillusesecureddatabase.

Employeescanjustperformtaskforwhichpermissionisgivenbuttheycannoteditor
modifyanythingexceptsellingofmedicine.
Systemwillhavedifferenttypesofusersandeveryuserhasaccessconstraints

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

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
This software shall be maintainable Indicate how you plan to achieve it, & etcDo not forget

to include such attributes as the design for change. Please note that you need to include at least
2 quality attributes, but it is the mere minimum and it will not receive the full marks.>

SoftwareRequirementsSpecificationforMSMS

Page1

5 Other Requirements
<This section is Optional. 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.>

SoftwareRequirementsSpecificationforMSMS

Page2

SoftwareRequirementsSpecificationforMSMS

Page3

Appendix A Data Dictionary

<Data dictionary is used to track all the different variables, states and functional requirements that
you described in your document. Make sure to include the complete list of all constants, state
variables (and their possible states), inputs and outputs in a table. In the table, include the
description of these items as well as all related operations and requirements.>

SoftwareRequirementsSpecificationforMSMS

Page4

SoftwareRequirementsSpecificationforMSMS

Page5

Appendix B - Group Log

<Please include here all the minutes from your group meetings, your group activities, and any
other relevant information that will assist the Teaching Assistant to determine the effort put forth to
produce this document>