0% found this document useful (0 votes)
89 views5 pages

Object Oriented Software Engineering Assignment # 02: Instructions

The document provides a template for a Software Requirements Specification (SRS) assignment for a class. The template outlines the required sections for the SRS, including revision history, document approval, specific requirements, use cases, classes/objects, non-functional requirements, and more. Instructions are provided on how to populate each section with project-specific details.

Uploaded by

issisiss
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
89 views5 pages

Object Oriented Software Engineering Assignment # 02: Instructions

The document provides a template for a Software Requirements Specification (SRS) assignment for a class. The template outlines the required sections for the SRS, including revision history, document approval, specific requirements, use cases, classes/objects, non-functional requirements, and more. Instructions are provided on how to populate each section with project-specific details.

Uploaded by

issisiss
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 5

Object Oriented Software Engineering

Assignment # 02

Due Date: -03-2020 Section: Total Marks: 100


Program: BS(SE)
Instructions
I can take either quiz or in class viva for this assignment by calling any one on the white board
to solve any question of the assignment. Copied assignment will be getting zero marks and
further action will be taken as per university policy.

Software Requirements Specification Template


CptS 322—Software Engineering
25 Feb, 2020

The following annotated template shall be used to complete the Software Requirements
Specification (SRS) assignment of WSU-TC CptS 322. The instructor must approve any
modifications to the overall structure of this document.

Template Usage:
Text contained within angle brackets (‘<’, ‘>’) shall be replaced by your project-specific
information and/or details. For example, <Project Name> will be replaced with either ‘Smart
Home’ or ‘Sensor Network’.

Italicized text is included to briefly annotate the purpose of each section within this template.
This text should not appear in the final version of your submitted SRS.

This cover page is not a part of the final template and should be removed before your SRS is
submitted.

Acknowledgements:
Sections of this document are based upon the IEEE Guide to Software Requirements
Specification (ANSI/IEEE Std. 830-1984). The SRS templates of Dr. Orest Pilskalns (WSU,
Vancover) and Jack Hagemeister (WSU, Pullman) have also be used as guides in developing this
template for the WSU-TC Spring 2005 CptS 322 course.
<Project Name>

Table of Contents

REVISION HISTORY................................................................................................................................................II
DOCUMENT APPROVAL........................................................................................................................................II
3. SPECIFIC REQUIREMENTS................................................................................................................................2
3.1 EXTERNAL INTERFACE REQUIREMENTS...............................................................................................................3
3.1.1 User Interfaces.............................................................................................................................................3
3.1.2 Hardware Interfaces....................................................................................................................................3
3.1.3 Software Interfaces......................................................................................................................................3
3.1.4 Communications Interfaces.........................................................................................................................3
3.2 FUNCTIONAL REQUIREMENTS...............................................................................................................................3
3.2.1 <Functional Requirement or Feature #1>..................................................................................................3
3.2.2 <Functional Requirement or Feature #2>..................................................................................................3
3.3 USE CASES............................................................................................................................................................3
3.3.1 Use Case #1.................................................................................................................................................3
3.3.2 Use Case #2.................................................................................................................................................3
3.4 CLASSES / OBJECTS..............................................................................................................................................3
3.4.1 <Class / Object #1>....................................................................................................................................3
3.4.2 <Class / Object #2>....................................................................................................................................3
3.5 NON-FUNCTIONAL REQUIREMENTS......................................................................................................................4
3.5.1 Performance.................................................................................................................................................4
3.5.2 Reliability.....................................................................................................................................................4
3.5.3 Availability...................................................................................................................................................4
3.5.4 Security........................................................................................................................................................4
3.5.5 Maintainability.............................................................................................................................................4
3.5.6 Portability....................................................................................................................................................4
3.6 INVERSE REQUIREMENTS......................................................................................................................................4
3.7 DESIGN CONSTRAINTS..........................................................................................................................................4
3.8 LOGICAL DATABASE REQUIREMENTS..................................................................................................................4
3.9 Other Requirements.............................................................................................................................................4

Software Requirements Specification Page ii


<Project Name>

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

3.1 External Interface Requirements


3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces

3.2 Functional Requirements


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>

Software Requirements Specification Page 1


<Project Name>

3.3 Use Cases


3.3.1 Use Case #1
Use Case ID: 1
Use Case Name: Sign up
Date Created: Feb 25, 2020
Actors: Customer
Description: Customer needs to be registered to be able to purchase any medicine. A
customer will need to be registered only once. He will provide basic
some basic information like name, NIC number, mailing address, contact
number etc. and set a password for his account. Only one account will be
created against each NIC number.
Preconditions: 1. Customer should have opened the website
2. The customer should have requested for sign up
Post conditions: 1. System must have added the record of the customer in the database

Normal Flow:
Customer System
1. System will prompt the
customer to enter basic
information
2. Customer will enter the basic
information
3. System will verify that the
entered CNIC number is not
in the database
4. System will prompt the
customer to set a new
password and verify
5. The customer will enter a new
password and will re-enter it
6. If both entered passwords
match and satisfy password
requirements then create an
account for the customer
Alternative Flows:
Exceptions:
CNIC Number already registered
Ask the user to login or recover password

Passwords do not match


Ask the user to retype passwords

Password does not satisfy password requirements


Ask the user to modify password as per requirements

Software Requirements Specification Page 2


<Project Name>

3.3.2 Use Case #2


3.4 Classes / Objects


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


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).
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 Requirements


State any *useful* inverse requirements.

3.7 Design Constraints


Specify design constrains imposed by other standards, company policies, hardware limitation,
etc. that will impact this software project.

3.8 Logical Database Requirements


Will a database be used? If so, what logical requirements exist for data formats, storage
capabilities, data retention, data integrity, etc.

3.9 Other Requirements


Catchall section for any additional requirements.

Software Requirements Specification Page 3

You might also like