software_requirements_specification

8/7/2019 Software_Requirements_Specification

1/16

1 | P a g e

Software Requirements

Specification

For

Enterprise Resource Planning(ICLMS)

(ICL PUBLICATIONS Pvt. Ltd. )


2/16

2 | P a g e

Table of Contents

1. Introduction 3

1.1 Purpose 31.2 Document Convention 3

1.3 Scope 4

1.4 Acronyms and Abbreviations 5

2. The Overall Description 5

2.1 Product Perspective 5

2.2 Product Features 5

2.3 User Classes and Characteristics 7

2.4 Operating Environment 7 2.5 Design and Implementation Constraints 8

2.6 User Documentation 8

2.7 Assumptions and Dependencies 8

3. System Features 8

3.1 Database Storage 8

3.1.1 Description and Priority 8

3.1.2 Stimulus / Response Sequences 9

3.2 Functional Requirements 9

3.3 Non Functional Requirement 13

3.3.1 General Detail 13

3.3.2 Hardware Interfaces 14

3.3.3 Software Interfaces 14

3.3.4 Communication Interfaces 14

3.4 Other Non Functional Requirement 14

3.4.1 Performance Requirements 14

3.4.2 Safety Requirements 15

3.4.3 Security Requirements 15

3.4.4 Software Quality Attributes 15

3.4.5 Hardware Constraints 15

3.4.6 Software Constraints 15

3.4.7 Design Constraints 16


3/16

3 | P a g e

Introduction

1.1. Purpose

The main objective of this document is to illustrate the requirements of theproject ICLMS. This document describes the design decisions, architecturaldesign and the detailed design needed to implement the system. (ICLMS) isintended to help the company to keep the proper record of their Employees,Cases in which they are dealing and maintaining the record of the Judgmentsof cases they are dealing in. This document is meant to delineate the featuresof ICLMS, so as to serve as a guide to the developers on one hand and asoftware validation document for the prospective client on the other.The document gives the detailed description of the both functional and nonfunctional requirements proposed by the client. The final product of the teamwill be meeting the requirements of this document.

1.2. Document Convention

The following are the list of conventions and acronyms used in this document and the project as well:* Administrator : A login id representing a user with user

Administration privileges to the software.

* User : A general login id assigned to users

* Client : Intended users for the software

* SQL: Structured Query Language; used to retrieve information from aDatabase.

* SQL Server : A server used to store data in an organized format.

* ASP (Active Server Pages): A Web Page formatted on the server anddelivered to the browser.

* Layer : Represents a section of the project.

* User Interface Layer : The section of the assignment referring toWhat the user interacts with directly.


4/16

4 | P a g e

* Application Logic Layer : The section of the assignment referring toThe Web Server. This is where all computations are completed.

* Data Storage Layer : The section of the assignment referring to where

all data is recorded.* Data flow diagram : It shows the dataflow between the entities.

* Use Case : A broad level diagram of the project showing a basicOverview.

* Boolean : A true/false notation.

* Interface : Something used to communicate across different mediums.

* Unique Key : Used to differentiate entries in a database.

1.3 Scope:

We describe what features are in the scope of the software and what arenot in the scope of the software to be developed.

In Scope:

a. Managing details of each employee, which would include maintainingClients and their cases and managing the judgments of each Case.

b. Giving alerts to the Lawyers, about the hearing dates of the cases.

c. Lawyers can take the reference from the judgments of the previous casestheir company handled from the database.

d. Manager of the company will be prompted about the lawyer if he had givena notice about his leaving before 2 months.


5/16

5 | P a g e

Out of Scope:

a. Numbers of the wins and loss by the company.b. Any Case related prediction can be made from the record of previous

judgments.1.4 Acronyms and Abbreviations:

a. ILCMS: ICL Management System.b. SRS: Software Requirements Specification.c. DOH: Date of hearing.d. GUI: Graphical User Interface.e. HOC: Head of the Company.f. CH: Case Header (e.g. Appellant Name vs. Respondent Name).

g. IIS: Internet Information Services.h. HA: High Availability mode.

2. Overall Description

2.1 Product Perspective

ICLMS is aimed toward Employee who has different jobs in stock and so needssoftware assistance for managing their tasks and maintaining the records of their job. Let suppose a Lawyer is having many cases under him, by thissoftware he will be able to extract each and every detail of his cases, seniorlawyer and the lawyers working under him in a GUI interface. ICLMS shouldbe user-friendly, quick to learn and reliable software for the above purpose.ICLMS is intended to be a stand-alone product and should not depend on theavailability of other software. It should run on both UNIX and Windows basedplatform.

2.2 Product Features

There are four different users who will be using this product:

* HOC: Who will be acting as the administrator who will give different role tothe employees of the company.

* Lawyer members who are second level users accessing ICLMS.


6/16

6 | P a g e

* Steno members of the company who are having limited access to thesoftware.

The features that are available to the Administrator are:

* The administrator has the full fledged rights over the ICLMS.

* Can create/delete an account.

* Add and delete any Role.

* Can view the accounts.

* Can change the password.

* Can leave Notice to all the members of the organization (notice board).

* Can hide any kind of features from the both of users.

* Insert/delete/edit the information of available on ICLMS.

The features available to the Lawyer members are:

* Have the access to each and every detail of the judgment of the cases that

have been fought by the company.

* Can write the case details as communicated by the Client or modify the

details given by the Steno.

* Can update the next hearing date of his particular case.

The features available to the Steno are:

* Can send the written material as dictated by Lawyer/Client for further

modifications and updations.


7/16

7 | P a g e

2.3 User Classes and Characteristics

There are various kinds of users for the product. Usually product is visited by

various users for different reasons.

The users include: HOC: Who will be acting as the controller and he will have all the

privileges of administrator Layers of the company who will be using the above features by

accessing the ICLMS

Steno who will be using the all his above mentions features

Foremost thing which is requires is:

a) The user should be familiar with the Law related terminology likeAppellant, Respondent, and Hearing etc.

b) The user should know the details of a case.

2.4 Operating Environment

ICLMS is intended to be a stand-alone product and should not depend on theavailability of other software. It should run on both UNIX and Windows basedplatform. Product will be operating in windows environment. It will also becompatible with the IE. Most of the features will be compatible with theMozilla Firefox, Opera 7.0 or higher versions and Google Crome. The only

requirement to use this online product would be the internet connection.


8/16

8 | P a g e

2.5 Design and Implementation Constraints

The Product is developed using ASP. Backend database for this is SQL Server

by Microsoft. The product is accomplished with login facility so that specificfunction is available to specific user. For full working ICLMS requires Internet

connection.

2.6 User Documentation

The product will include user manual. The user manual will include product

overview, complete configuration of the used software (such as SQL server),technical details, backup procedure and contact information which will

include email address. Product will be compatible with the Mozilla Firefox,

Opera 7.0 or higher versions and Google Crome. The databases will be created

in the Microsoft SQL server by Microsoft.

2.7 Assumptions and Dependencies

The product needs following product. Microsoft SQL server to store the database. ASP.NET to develop the Product.

3. System Features

3.1. Database Storage

3.1.1. Description and Priority

Proposed Database is intended to store, retrieve, update, and manipulateinformation related to Company which include


9/16

9 | P a g e

Profile of the 3 users (i.e. Lawyer, Steno, Client).

Staff information.

Case details. Online checking of details by Lawyers.

Online viewing status of cases.

Judgments of the previous cases so as to take reference for another

cases.

3.1.2. Stimulus / Response Sequences

Responses for Administrator : The administrator can Login and Logout. Whenthe administrator logs in the ICLMS. The system will check for validity of login.If the Login and password are valid, the response to this action will be that,the administrator will be able to modify, view, add, deleting and all otherfunctions that can be performed on the database.

3.2. Functional Requirements

We describe the functional requirements by giving various use cases.

Use cases related to system authorization:

Use Case 1 : LoginPrimary Actor : User (Any)Pre Condition : Nil

Main Scenario :

1. Start the application. User prompted for login and password.2. User gives the login and password.3. System does authentication.4. Main screen is displayed taking care of his role in the company.


10/16

10 | P a g e

Alternate Scenario :

5. Authorization fails

5.1. Prompt the user that he has typed the wrong password5.2. Allow him to re-enter the password. Give him 3 chances.

Use Case 2: Change Password

Primary Actor : UserPre Condition : User logged in

Main Scenario :

1. User initiates the password change command.2. User is prompted for old password, new password and confirm newpassword.3. User gives the old password, new password and confirm new password.4. System does authentication.5. New password is registered with the system.

Alternate Scenario :

6. Authorization fails6.1. Prompt the user that he typed the wrong password6.2. Allow him to re-enter the password. Give him 3 chances.6.3. New password and confirm new password do not match.6.3.1. Allow him to re-enter the attributes. Give 3 chances.

Use cases related to other functional requirements:

Use Case 3: Adding a Case.

Primary Actor : HOC, LawyerPre-Condition : logged in.Main Scenario :

1. User selects the Add New Case functionality.


11/16

11 | P a g e

2. User initiates the Add New Case functionality.3. System prompts the user for following details:3.1. Which type of case?3.1.1. Civil?

3.1.2. Criminal? Etc.3.2. Client Name and Details.3.3. Any detail user might want to enter.4. New case is added.

Use Case 4: Updating the Case Details.

Primary Actor : Lawyer, HOCPre-Condition : logged in.

Main Scenario :1. Lawyer selects the Cases functionality.2. Lawyer selects the Specific Case.2. Lawyer selects the Edit Case Details functionality.2. Lawyer initiates the Edit Case Details functionality.4. Lawyer can make changes in the case details, DOH of the case and JudgeDecision at particular date etc.5. Lawyer selects the Update Case Details functionality.

6. Lawyer initiates the Update Case Details functionality.7. Case has been updated.

Use Case 5: Checking the Status of Case.

Primary Actor : Lawyer, HOCPre-Condition : logged in.

Main Scenario :1. User selects the case from his privileged form.2. They can check the Status by viewing the following details:2.1. CH2.2. Lawyer Assigned.2.3. Next Hearing Date.2.4. Judgments by the Judge on particular dates.


12/16

12 | P a g e

Use Case 6: Number of pending Cases.

Primary Actor : Lawyer, HOC

Pre-Condition : logged in.Main Scenario :1. User selects the Pending Cases functionality.2. Lawyer initiates the Pending Cases functionality.3. User can check all the pending cases.

Use Case 7: Setting alerts for the cases 3 days before the hearing date.

Primary Actor : Lawyer, HOCPre-Condition : User logged in.

Main Scenario :1. User initiates the Cases functionality.2. User initiates the Set Alert functionality.3. The system asks the user for the date and details of the alert.4. The alert is set.5. Automatic deleting the alerts after that hearing date.

Use Case 8: Number of Wins by the Company.

Primary Actor : HOCPre-Condition : logged in.

Main Scenario :1. HOC selects the Net Cases Won functionality.2. HOC initiates the Net Cases Won functionality.3. Details of all the cases won and the name of the Lawyers to whom the caseswere assigned come in front of him.


13/16

13 | P a g e

Use Case 9: New Notice.

Primary Actor : HOCPre-Condition : logged in.

Main Scenario :1. HOC selects the Notice functionality.2. HOC selects the Add New Notice functionality.2. HOC initiates the Add New Notice functionality.3. System prompts the user for following details:3.1. Which type of case?3.1.1. Emergency notice.3.1.2. Meeting Notice.3.1.3. General Notice.4. Hoc selects one of particular type and writes the notice which will bedisplayed on the main screens of the rest users except clients5. New Notice is added.

Functionalities may be increased during the course of development.

3.3. Non Functional Requirement

3.3.1 General Detail

Non-Functional presents a systematic and pragmatic approach to buildingquality into' software systems. Systems must exhibit software qualityattributes, such as accuracy, performance, security and modifiability.However, such non-functional requirements (NFRs) are difficult to address inmany projects, even though there are many techniques to meet functionalrequirements in order to provide desired functionality. This is particularly

true since the NFRs for each system typically interact with each other, have abroad impact on the system and may be subjective. To enable developers tosystematically deal with a system's diverse NFRs, this book presents the NFRFramework. Structured graphical facilities are offered for stating NFRs andmanaging them by refining and inter-relating NFRs, justifying decisions, anddetermining their impact. Since NFRs might not be absolutely achieved, they


14/16

14 | P a g e

may simply be satisfied sufficiently. To reflect this, NFRs are represented as`soft goals', whose interdependencies, such as tradeoffs and synergy, arecaptured in graphs. The impact of decisions is qualitatively propagatedthrough the graph to determine how well a chosen target system satisfies its

NFRs. Throughout development, developers direct the process, using theirexpertise while being aided by catalogues of knowledge about NFRs,development techniques and tradeoffs, which can all be explored, reused andcustomized.

3.3.2. Hardware Interfaces

Server Side:

* Operating System: Any* Processor: Pentium3.0 GHz or higher* RAM: 256 Mb or more* Hard Drive: 10 GB or more

Client side:

* Operating System: Any* Processor: Pentium3.0 GHz or higher

* RAM: 256 Mb or more

3.3.3. Software Interfaces

* Database: SQL Server.* Application: ASP (Active Server Pages)* Web Server: IIS (It is a powerful Web server that provides a highly reliable,manageable, and scalable Web application infrastructure)

3.3.4. Communications Interfaces

The Users must connect to the Internet to access the ERP:


15/16

15 | P a g e

* Dialup Modem of 52 kbps

* Broadband Internet

* Dialup or Broadband Connection with a Internet Provider

3.4. Other Non Functional Requirement

3.4.1. Performance Requirements

The proposed system that we are going to develop will be used as the Chief

performance system within the company which makes the work of every

employee so easy. Therefore, it is expected that the database would perform

functionally all the requirements that are specified by the company.

3.4.2. Safety Requirements

The database may get crashed at any certain time due to virus operating

system failure. Therefore, it is required to take the database backup or at HA

mode.

3.4.3. Security Requirements

We are going to develop secured database for the Company. There aredifferent categories of users namely HOC, Lawyer, Steno, and Client etc.Depending upon the category of user the access rights are decided. It means if the user is an administrator then he can be able to modify the data, delete,make an announcement etc. Clients only have the right to check the status of their case from the database.

3.4.4. Software Quality Attributes

The Quality of the database is maintained in such a way so that it can be veryuser friendly to all the users of the database.


16/16

16 | P a g e

3.4.5 Hardware Constraints

The system requires a database in order to store persistent data. The databaseshould have backup capabilities or in HA mode.

3.4.6. Software Constraints

The development of the system will be constrained by the availability of

required software such as web servers, database and development tools.

3.4.7. Design Constraints

The system must be designed to allow web usability. That is, the system must be designed in such a way that will be easy to use and visible on most of thebrowsers.

software_requirements_specification

Documents