3. SRS Document Template (Repaired)

Session: 2014 - 2016 | <Department OF COMPUTER SCIENCE & IT>

17.12.2015

Project Title

Revision History

Date Description Author Comments

<date> <Version 1> <Your Name> <First Revision>

Document Approval

The following Software Requirements Specification has been accepted and approved by the following:

Signature Printed Name Title Date

Salman Qadri Supervisor, CSIT 21306 <date>

ii

Project Title

Table of Contents

1. Introduction 1

1.1 Purpose 1

1.2 Scope 1

1.3 Definitions, Acronyms, and Abbreviations. 2

1.4 References 2

1.5 Overview 3

2. The Overall Description 4

2.1 Product Perspective 42.1.1Operations 52.1.2 Site Adaptation Requirements 5

2.2 Product Functions 6

2.3 User Characteristics 6

2.4 General Constraints 7

2.5 Assumptions and Dependencies 7

3. Specific Requirements 8

3.1 External Interface Requirements 93.1.1 System Interfaces 93.1.2 Interfaces 93.1.3 Hardware Interfaces 93.1.4 Software Interfaces 93.1.5 Communications Interfaces 10

3.2 Functional Requirements 103.2.1 <Functional Requirement or Feature #1> 143.2.2 <Functional Requirement or Feature #2> 14

3.3 Use Cases 143.3.1 Use Case #1 153.3.2 Use Case #2 15

3.4 Classes / Objects 153.4.1 <Class / Object #1> 153.4.2 <Class / Object #2> 15

3.5 Non-Functional Requirements 15

Sr.No. 153.5.1 Performance 163.5.2 Reliability 163.5.3 Availability 163.5.4 Security 163.5.5 Maintainability 163.5.6 Portability 16

3.6 Inverse Requirements 16

iii

Project Title

3.7Logical Database Requirements 16

3.8Design Constraints 163.8.1 Standards Compliance 16

4. Supporting Information 17

Appendix A – Background Research on: 17Appendix B – Data Dictionary 17

iv

Project Title

Chapter 1

1. IntroductionThis SRS of Project management system contains all material that provides the whole description of projects which will helpful for the students to make their projects as best as they can do. In this SRS coordinator will assign the assignments to the students with whole detail so that students will make their projects accordingly. For the help and guidance of the students department is supposed to be assign an internal for the student or the group of the student to make sure them that they are working correctly.

1.1 PurposeThe purpose to make this SRS to get rid of old fashioned documentation related to their projects. As per the direction of HEC it is declared that all old fashioned documentation should be converted to the new versions of the SRS which is necessary for the new era and computer working.

1.2 Scope The Project Management System tells about the management of software projects. It provides a complete software project with defined scope, time and cost constraints with the management of resources.The management system provide a tool of decision making and required functionality it does not go to detail of data storage, change management This document describes only requirements for the whole- system functionality which is defined in the use case model. A use case diagram is a graphic depiction of the interactions among the elements of a system. A use case is a methodology used in system analysis to identify, clarify, and organize system requirements.

In this SRS documentation:

Provide the project list.

Helpful material.

Internal list (for the students to their guidance).

First deliverable (SRS) submission on due date.

Marks obtained in first deliverable.

SRS Document 1.0 Page 1 of 9 04/28/23f

Project Title

Second deliverable (design phase) submission on due date.

Marks obtained in second deliverable.

External viva.

Total marks of project.

1.3 Definitions, Acronyms, and Abbreviations.

Term/Abbreviation Explanation

PMS Project Management SystemCMS Change Management System (Bug tracking tool)CVS Concurrent Versions SystemVSS Microsoft Visual SourceSafePERT Program Evaluation and Review TechniqueGUI Graphical User InterfaceLAMP A server that is running Linux, Apache, My-SQL and PHPDBMS Database Management System

DSS Data Storage SystemRBAC Role Based Access Control

1.4 ReferencesReference & Document Title Applicable Reference and Version

1 Project Description case-study.pdf2 Raw PMS Requirements Raw requirements.doc3 Use Case diagrams Use Case Diagrams.doc4 Official Guidelines for Interface Developers and http://msdn.microsoft.com/library/en-Designers us/dnwue/html/welcome.asp5 Review comments PMS_Requirements_Review.pdf


Project Title

1.5 OverviewIn this SRS documentation:

(1) It contains the whole description of all material provided for the project.(2) How much efforts are being made for the documentation.

In this SRS documentation the detail of the project necessarily provided for the project which understandable for the student. The project description should be in concise and concrete manners so that everyone can understand the whole project and its detail with working.

Chapter 2 defines the general product functions, intended application, constraints to be respected and the assumption made in order to define requirements.

Chapter 3 specifies functional (Section 3.1) and non-functional requirements (all other sections), usability, reliability, security, performance and maintainability considerations and requirements to a level of detail sufficient to enable designers to design a system to satisfy these requirements and testers to test that the system satisfies these requirements.

Chapter 4 contains index, appendices and supporting information.

The document is structured according to the IEEE 830-1998 standard [IEEE-830].


Project Title

Chapter 22. The Overall Description

Describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in section 3, and makes them easier to understand. In a sense, this section tells the requirements in plain English for the consumption of the customer. Section3 will contain a specification written for the developers.

2.1 Product PerspectivePMS it a standalone system that provides functionality described in the Product functions section. It includes all subsystems needed to fulfil these software requirements. In addition, the PMS has interfaces to the external systems, such Version Control System, Change Management and Bug Tracking System and Payroll System. These interfaces shall be implemented according to available industry standards and shall be independent from a specific external system.Any detailed definition of an external system is out of scope of this document.The figure 1 shows the decomposition of PMS on the functionality areas and the supported external systems.

We have to distinguish a Data Storage System (DSS) from all other external systems in that way, that Data Storage System enables normal functioning of PMS and is therefore essential. PMS stores all its data in the DSS and hence has to maintain the connection to it. PMS shall access the data storage system through standard interface (JDBC, ODBS, ADO etc). See Data storage system section for more information.


Project Title

2.1.1OperationsSpecify the normal and special operations required by the user such as:

(1) The various modes of operations in the user organization(2) Periods of interactive operations and periods of unattended operations(3) Data processing support functions(4) Backup and recovery operations (Note: This is sometimes specified as part of the User Interfaces section.) If you separate this from the UI stuff earlier, then cover business process type stuff that would impact the design. For instance, if the company brings all their systems down at midnight 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.2 Site Adaptation RequirementsIn this section:

(1) Define the requirements for any data or initialization 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

If any modifications to the customer’s work area would be required by your system, then document that here. For instance, “A 100Kw backup generator and 10000 BTU air conditioning system must be installed at the user site prior to software installation”.

This could also be software-specific like, “New data tables created for this system must be installed on the company’s existing DB server and populated prior to system activation.” Any equipment the customer would need to buy or any software setup that needs to be done so that your system will install and operate correctly should be documented here.


Project Title

2.2 Product FunctionsProject Management System:

It provides a framework for project management and supports multiple projects. Also supports distributed development, It allows to define fine-grained project step like tasks and subtasks. And also allows to create complex dependencies between tasks Or supports resource management, They provides user and user role management or supports budget controlling and stores all system data in the centralized data storage. It has an interface to an external version management and code storage system. And it has an interface to an external change management and bug tracking system, They can provide data for an external payroll system. It Can have an interface with enterprise-wide user management system.

2.3.2Unsupported functionsThe Project Management System:•does not provide code management or code storage,•does not provide version control,•does not provide bug tracking and change management,•does not provide employee management,

•does not provide work time accounting and payroll.

2.3 User CharacteristicsThe system is intended to be used by various users. We can divide all users into four profiles, each with own responsibility and role in the PMS:

User Functions and Responsibilities Source

Manager Responsible for the batch of the projects and 1 Project

controls overall development flow. Assigns projects Description

to the project team leader and controls fulfilment of

the project team leader’s tasks.

Project Team Leader Responsible for a particular project. Leads a 1 Project

project team of 2 to 20 developers. Assigns tasks Description

to project team members and controls their

fulfilment. Reports to the manager.

Project Team Member Responsible for a particular task or part of a task. 1 Project

Reports to the Project Team Leader. Description

System Administrator Responsible for the installation, maintenance, 1 Project

security and troubleshooting of the productive Description

system. Manage users of the PMS. Reports to the

Manager

Table 1. User Profiles


Project Title

2.4 General ConstraintsThe document represents a study project, not a real-life SRS, and misses detailed description and requirement for many areas. It gives only directions and requirement templates for creating project management system.

2.5 Assumptions and Dependencies

2.6.1Data storage systemThe PMS stores all the operational (portfolios, projects, tasks, subtasks, dependencies, resource assignments) and reference (resources, users, user roles) data in the centralized data storage. There is no requirement for a specific data storage system. We assume that the PMS shall be able to access and store data in any Data Base Management System (DBMS) through the standard interface like JDBC, OBDC, ADO etc. provided by development environment.

The description and requirements for such a DBMS is out-of-scope of this document and is not considered further.

2.6.2Distributed project managementThe PMS shall support distributed project management. Hence PMS shall run on various platforms and be able to communicate with its subsystems via Internet. We will not discuss further the communication protocols and Internet platforms.

2.6.3RepresentationWe assume that the PSM represents the project management data according to the common representation standards and terminology. It also generates usual graphical representation of project tasks and their dependencies like PERT, Gantt, AON (Activity on Node) and AOA (Activity on Arrow) diagrams. The specification of such diagrams is out-of-scope of this document.


Project Title

Chapter 33. Specific Requirements

This will be the largest and most important section of the SRS. The customer requirements will be embodied within Section 2, but this section will give the D-requirements that are used to guide the project’s software design, implementation, and testing.

Each requirement in this section should be:

Correct Traceable (both forward and backward to prior/future artifacts) Unambiguous Verifiable (i.e., testable) Prioritized (with respect to importance and/or stability) Complete Consistent Uniquely identifiable (usually via numbering like 3.4.5.6)Attention should be paid to the carefully organize the requirements presented in this section so that they may easily accessed and understood. Furthermore, this SRS is not the software design document, therefore one should avoid the tendency to over-constrain (and therefore design) the software project within this SRS.


Project Title

3.1 External Interface Requirements

3.1.1 System InterfacesList each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system. These are external systems that you have to interact with. For instance, if you are building a business application that interfaces with the existing employee payroll system, what is the API to that system that designer’s will need to use?

3.1.2 InterfacesSpecify:

(1) The logical characteristics of each interface between the software product and its users.

(2) All the aspects of optimizing the interface with the person who must use the systemThis is a description of how the system will interact with its users. Is there a GUI, a command line or some other type of interface? Are there special interface requirements? If you are designing for the general student population for instance, what is the impact of ADA (American with Disabilities Act) on your interface?

3.1.3 Hardware Interfaces

Specify the logical characteristics of each interface between the software product and the hardware components of the system. This includes configuration characteristics. It also covers such matters as what devices are to be supported, how they are to be supported and protocols. This is not a description of hardware requirements in the sense that “This program must run on a Mac with 64M of RAM”. This section is for detailing the actual hardware devices your application will interact with and control. For instance, if you are controlling X10 type home devices, what is the interface to those devices? Designers should be able to look at this and know what hardware they need to worry about in the design. Many business type applications will have no hardware interfaces. If none, just state “The system has no hardware interface requirements” If you just delete sections 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.

3.1.4 Software Interfaces

Specify the use of other required software products and interfaces with other application systems. For each required software product, include:

(1) Name(2) Mnemonic(3) Specification number(4) Version number(5) SourceFor each interface, provide:


Project Title

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

(2) Definition of the interface in terms of message content and formatHere we document the APIs, versions of software that we do not have to write, but that our system has to use. For instance if your customer uses SQL Server 7 and you are required to use that, then you need to specify i.e.

3.1.4.1 Microsoft SQL Server 7 The system must use SQL Server as its database component. Communication with the DB is through ODBC connections. The system must provide SQL data table definitions to be provided to the company DBA for setup.

A key point to remember is that you do NOT want to specify software here that you think would be good to use. This is only for customer-specified systems that you have to interact with. Choosing SQL Server 7 as a DB without a customer requirement is a Design choice, not a requirement. This is a subtle but important point to writing good requirements and not over-constraining the design.

3.1.5 Communications InterfacesSpecify the various interfaces to communications such as local network protocols, etc. These are protocols you will need to directly interact with. If you happen to use web services transparently to your application then do not list it here. If you are using a custom protocol to communicate between systems, then document that protocol here so designers know what to design. If it is a standard protocol, you can reference an existing document or RFC.

3.2 Functional Requirements

Sr. No. Description

SRS-01 System should be able to provide login facility

SRS-02 System should be able to add User Types.

SRS-03 System should be able to load User Types.

SRS-04 System should be able to update User Types.

SRs-05 System should be able to delete User Types.

SRS-06 System should be able to add Users.

SRS-7 System should be able to load Users.

SRS-8 System should be able to update Users.

SRS-9 System should be able to delete Users.


Project Title

SRS-10 System should be able to add Programs.

SRS-11 System should be able to load Programs.

SRS-12 System should be able to update Programs.

SRS-13 System should be able to delete Programs.

SRS-14 System should be able to add Sessions.

SRS-15 System should be able to load Sessions.

SRS-16 System should be able to update Sessions.

SRS-17 System should be able to delete Sessions.

SRS-18 System should be able to add Timings.

SRS-19 System should be able to load Timings.

SRS-20 System should be able to update Timings.

SRS-21 System should be able to delete Timings.

SRS-22 System should be able to add Departments.

SRS-23 System should be able to load Departments.

SRS-24 System should be able to update Departments.

SRS-25 System should be able to delete Departments.

SRS-26 System should be able to add Classes.

SRS-27 System should be able to load Classes.

SRS-28 System should be able to update Classes.

SRS-29 System should be able to delete Classes.

SRS-30 System should be able to add Statuses

SRS-31 System should be able to load Statuses.

SRS-32 System should be able to update Statuses.

SRS-33 System should be able to delete Statuses.

SRS-34 System should be able to add Categories.

SRS-35 System should be able to load Categories.


Project Title

SRS-36 System should be able to update Categories.

SRS-37 System should be able to delete Categories.

SRS-38 System should be able to add Designations.

SRS-39 System should be able to load Designations.

SRS-40 System should be able to update Designations.

SRS-41 System should be able to delete Designations.

SRS-42 System should be able to add Students.

SRS-43 System should be able to load Students.

SRS-44 System should be able to update Students.

SRS-45 System should be able to delete Students.

SRS-46 System should be able to add Projects.

SRS-47 System should be able to load Projects.

SRS-48 System should be able to update Projects.

SRS-49 System should be able to delete Projects.

SRS-50 System should be able to add Internals.

SRS-51 System should be able to load Internals.

SRS-52 System should be able to update Internals.

SRS-53 System should be able to delete Internals.

SRS-54 System should be able to add Externals.

SRS-55 System should be able to load Externals.

SRS-56 System should be able to update Externals.

SRs-57 System should be able to delete Externals.

SRS-58 System should be able to add Phases.

SRS-59 System should be able to load Phases.

SRS-60 System should be able to Update Phases.

SRS-61 System should be able to Delete Phases.


Project Title

SRS-62 System Should be able to add Enrollments.

SRS-63 System should be able to load Enrollments.

SRS-64 System should be able to Delete Enrollments.

SRS-65 System should be able to update Enrollments.

SRS-66 System should be able to addProject Proposals.

SRS-67 System should be able to load Project Proposals.

SRS-68 System should be able to delete Project Proposals.

SRS-69 System should be able to update Project Proposals.

SRS-70 System should be able to add ProjectProposalMembers.

SRS-71 System should be able to load ProjectProposalMembers...

SRS-72 System should be able to delete ProjectProposalMembers.

SRS-73 System should be able to update ProjectProposalMembers.

SRS-74 System should be able loadProjectProposalPhases.

SRS-75 System should be able to load ProjectProposalphases.

SRS-76 System should be able to delete ProjectProposalPhases.

SRS-77 System should be able to update ProjectProposalPhases.

SRS-78 System should be able to add ProjectStatuses.

SRS-79 System should be able to delete ProjectStatuses.

SRS-80 System should be able to load ProjectStatuses.

SRS-81 System should be able to update ProjectStatuses.

SRS-82 System should be able to add Campuses.

SRS-83 System should be able to load Campuses.

SRS-84 System should be able to delete Campuses.

SRS-85 System should be able to update Campuses

SRS-86 System should be able to add YearlyEvaluationClasses.

SRS-87 System should be able to load YearlyEvaluationClasses.


Project Title

SRS-88 System should be able to delete YearlyEvaluationClasses.

SRS-89 System should be able to update YearlyEvaluationClasses.

SRS-90 System should be able to add YearlyEvaluationNotices.

SRS-91 System should be able to load YearlyEvaluationNotices.

SRS-92 System should be able to delete YearlyEvaluationNotices.

SRS-93 System should be able to update YearlyEvaluationNotices.

SRS-94 System should be able to add YearlyEvaluationResults.

SRS-95 System should be able to load YearlyEvaluationResults.

SRS-96 System should be able to delete YearlyEvaluationResults.

SRS-97 System should be able to update YearlyEvaluationResults.

This section describes specific features of the software project. If desired, some requirements may be specified in the use-case format and listed in the Use Cases Section.

3.2.1 <Functional Requirement or Feature #1>3.2.1.1 Introduction

3.2.1.2 Inputs

3.2.1.3 Processing

3.2.1.4 Outputs

3.2.1.5 Error Handling

3.2.2 <Functional Requirement or Feature #2>…

3.3 Use CasesThis section contains use cases of the ------------------------ system.


Project Title

3.3.1 Use Case #1

3.3.2 Use Case #2…

3.4 Classes / ObjectsThis section contains major classes of the ------------------------ system.

3.4.1 <Class / Object #1>

3.4.1.1 Attributes

3.4.1.2 Functions<Reference to functional requirements and/or use cases>

3.4.2 <Class / Object #2>…

3.5 Non-Functional Requirements

Sr.No.Descriptions

01 It necessary for run the project to install the Asp.net

02 At least the window server pack 2 or 3 are must to install Asp.net tool

03 It necessary to run the project to install the SQL server 2008.

04 System Developed for only two members.

Non-functional requirements may exist for the following attributes. Often these requirements must be achieved at a system-wide level rather than at a unit level. State the requirements in the following sections in measurable terms (e.g., 95% of transaction shall be processed in less than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc.).


Project Title

3.5.1 Performance

3.5.2 Reliability

3.5.3 Availability

3.5.4 Security

3.5.5 Maintainability

3.5.6 Portability

3.6 Inverse RequirementsState any *useful* inverse requirements.

3.7Logical Database RequirementsThis section specifies the logical requirements for any information that is to be placed into a database. This may include:

Types of information used by various functions Frequency of use Accessing capabilities Data entities and their relationships Integrity constraints Data retention requirementsIf the customer provided you with data models, those can be presented here. ER diagrams (or static class diagrams) can be useful here to show complex data relationships. Remember a diagram is worth a thousand words of confusing text.

3.8Design ConstraintsSpecify design constraints that can be imposed by other standards, hardware limitations, etc.

3.8.1 Standards ComplianceSpecify the requirements derived from existing standards or regulations. They might include:

(1) Report format(2) Data naming(3) Accounting procedures(4) Audit TracingFor example, 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. An audit trace requirement may, for example, state that all changes to a payroll database must be recorded in a trace file with before and after values.


Project Title

4. Supporting Information

Appendix A – Background Research on: Topic 1 Topic 2 Topic 3 ……… Topic n

Appendix B – Data Dictionary


3. SRS Document Template (Repaired)

Documents

Transcript of 3. SRS Document Template (Repaired)