Lec2 SRS 1 2014 [Compatibility Mode]

8/13/2019 Lec2 SRS 1 2014 [Compatibility Mode]

1/37


2/37

Phase 1: Project proposal

Weight: 10% of the project weight

Proposal contents:

e pro ec e, names o e eam mem ers - , w ema

addresses)

Task(s) of each member, (as there will be assessment for individual

performance as well as group performance).

The proposal should also provide some information about the business

problems/challenges that business/ company is facing, and how the

proposed system will improve their efficiencies or help them acquiring

compe ve a van age. The proposal should be between 500-800 words, which will be the

first part of the SRS document.

2


3/37

S stems Re uirements S ecification

Table of Contents

.

II. General Description

. unc ona equ remen s

IV. Non Functional Requirements

V. System Architecture

VI. System Models

VII. Appendices3


4/37


I. Introduction

B Scope

e n on, cronyms, or rev a ons

D References

E Overview

4


5/37



A Product Pers ective

B Product Functions

D General Constraints

ssump ons

5


6/37


Data Model

Behavioral

FunctionalModel

The SRS is composed of the outer layer of the behavioral model, the, .

6


7/37

S stems Re uirements S ecificationCorrect Complete

Precise Organized

nam guous er a e

Modifiable Traceable

Design Independent Annotated

onc se7


8/37


9/37

Systems Requirements Specification

Verifiable

is the software built what was specified in the SRSConsistent

conflicting terms, characteristics

Understandable

question: are formal specifications understandable, are

informal specifications understandable

9


10/37


Modifiable

c ang ng requ remen s eas y mo e w en spec y ng,

designing, coding, implementing

Traceable

.

10


11/37


Section One

Overview document for executivesdescribing thesystem from a management perspective

Section Two

General Description describin the ystem from auser and system perspective in general terms.

Section Three

Detailed document for users and developers

describing the system in detailed terms.

11


12/37

S stems Re uirements S ecificationSRS - Section I - Introduction

Definition of section contents

12


13/37


.

A Purpose

C Definition, Acronyms, or Abbreviations

D References

E Overview

13


14/37

S stems Re uirements S ecificationI. Introduction

The purpose of this Software Requirements SpecificationA Purpose

document.

n en e au ence o s ocumen

14


15/37


The purpose of the Software RequirementsA Purpose

Specification document isto clearly define the system

under development, namely the Video Rental System. e n en e au enceo s ocumen

includes theowner of the video store, theclerks of the

, .

intended audience includes thedevelopment team such

as therequirements team,requirements analyst,design

team, and othermembers of the developing

organization. 15


16/37


B. Scope

.

High-level description of the system functionality

16


17/37


B. Scope

Origin of the need

Who and what triggered the request for this softwaredevelopment activity.

ves eve opers an un ers an ng o e goa s or eproposed system.

17


18/37


I. Introduction

.

Thescope of a system defines what arethe boundaries

o a sys em. ese nc u e w a s ns e e sys em -

what will be designed and programmed.

High-level functionality

Usually in list separated by commas

18


19/37


B. Scope

.

fuzzy and non measurable.

A typical goal would be things like

Increase customer satisfaction

a e xyz eas er or t e customerImprove customer relationships

19


20/37


The owner of a local video store wanted to create a new

B. Scope

business plan where everything about renting a video(except the picking up and returning of videos) was done

. ,

functionality online: to search for videos, to become

members, to rent videos, to modify membershipinformation, and to pay overdue fees.

The store personnel may use the VRS to process the rented

stores video inventory and to update video information. The

VRS is intended to increase the owners profit margin by

and by allowing him to reduce the staffing needed in hisstores.20


21/37


C. Definitions, Acronyms..

As you begin to define a system, you will encounter

.

These should be documented for new ersonnel and for

clarity of all concerned parties.

21


22/37


C Definitions, Acronyms..

CS - Computer Science

- asters n o tware ng neer ng c ence

DOE - Department of Education

.

22


23/37


D. References

Many references may be used to define existing systems,

rocedures both new and old , documents and theirrequirements, or previous system endeavors. These

references are listed here for others.

If any of these references are provided in the appendices,

.

23


24/37

ec on o

B. Sco e of the S stem S ecified Para ra h form

C. Definitions, Acronyms, and Table form orAbbreviations bulleted list

D. References to Supporting Bulleted list

DocumentsE. Overview of rest of SRS Paragraph form

24


25/37


E. Overview

This section defines the or anization of the entiredocument. It will lay the framework for reading

the document.

25


26/37


E. Overview

ec on o e escr es e pro uc n more

detail.

requirements of the intended system.

Section 4provides the non-functional requirements.

Section 5shows the class diagram, and Section 6theuse case diagram. The appendices appear next.

26


27/37



A. Product Pers ective

B. Product Functions

C. User Characteristics

D. General Constraints

E. Assumptions

27


28/37

S stems Re uirements S ecificationII General Description

A . Product Perspective

This defines the relationship this product has in the entire

spectrum of products.

It defines who wil l be responsible for the product and

what business purpose it serves.

a so e nes w a n er aces may ave o o er sys ems.

28


29/37

S stems Re uirements S ecificationII General Description

A Product Perspective

The VRS is a web-based system. The system interfaces

with two other systems, theowners email system, the

,

by VRS customers. The system providesa secure

environment or all inancial transactions and or the

storing and retrieving of confidential member

information.

29


30/37

S stems Re uirements S ecificationII. General Description

B Product Functions

This section lists the major functions of the system.

It provides a summary of all the functions of the

software.

The functions should be organized in a way that makes

the list of functions understandable to the customer or

o anyone e se rea ng e ocumen or e rs me.This section should be consistent with the functional

.

30


31/37


The VRSallowscustomersto search the video inventory

rovided b this video store. To rent videos throu h the VRS,one must

register as a member using the VRS. Upon becoming a member and

logging into the VRS, the VRS provides the functionality for renting

, , .

Theclerks of the video store use VRSto process the return of

rented videos. Theowner of the video store uses VRS toadd new videosinto t e system,remove vi eos rom t e system, an mo ify vi eo

information.

The VRSsends emails to members concernin video rentals. One

day before a rented video is due to be returned, VRS emails the membera reminder of the due date for the video(s). For anyoverdue videos,

. -

day limit for outstanding videos, VRS debits the members credit card

with the appropriate charge andnotifies the member of this charge.31


32/37


II. General Description C User Characteristics

st t e users nvo ve w t t e propose system

including thegeneral characteristics of eventual users

, ,

product training).

u ,needed.

32


33/37

S stems Re uirements S ecificationII. General Description C User Characteristics

The three main groups of VRS users are customers,members, andstore personnel. Acustomer is anyone who is not a

member. The customer can only search through the video inventory.

The amount of product training needed for a customer is none since

the level of technical expertise and educational background is.

a website.

Member is someone who has registered with VRS. A member

. ,

activities require no product training since the level of technicalexpertise and educational background of a member is unknown. The

onl skill needed b a member is the abilit to browse a website.

The store personnel are divided into two groups: theclerk-

level personnel and owner-level personnel. Their educational level isunknown and both group needs little to no training.

33


34/37



D General Constraints o tional

.

In this section, the constraints of the system are listed.

, , ,software constraints. It also includes user constraints,

processing constraints, timing constraints, and control

limits.

34


35/37

S stems Re uirements S ecificationII. General Descri tion D General Constraints

This systemprovides web access for all customer and

mem er unc ons. e user n er ace w e n u ve

enough so that no training is required by customers,

.transactions and the storageof confidential member

information will be done in asecure environment.

Persistent storagefor membership, rental, and videoinventory information will bemaintained.

35

II G l D i ti


36/37

II General Description

This includes assum tions made at the be innin of the

development effort as well as those made during the

development.

List and describe each of the factors that affect the requirements

stated in the SRS. These factors are not design constraints on

requirements in the SRS. For example, an assumption might

be that a specific operating system will be available on the

ar ware es gna e or e so ware pro uc . , ,

operating system is not available, the SRS would then have to

change.

36


37/37

ec on o.

II.B Product Functions Para ra h form

II.C User Characteristics Paragraph form

II.D General Constraints Paragraph form

II.E Assumptions and Paragraph form

Depen enc es

37

Date post:	04-Jun-2018
Category:	Documents
Upload:	007wasr
View:	216 times
Download:	0 times