University of Jeddah

College of Computer Science and Engineering

Department of Software Engineering

CCSW 223: Software Engineering

Lab Manual

1
Objectives:
✔
✔
Learn what the requirement are?
Characteristics of good user requirements.
6
✔ What is Software Requirement Specification Document?
✔ Explain how to conduct the function requirement.
✔ Explain how to conduct the Non-function requirement.

2
1. Software requirement specification Document:
Before developing a project the system has to be studied carefully. From the day one we
take notes and write everything regarding the system from scratch this is called SRS
Document. SRS includes the scope, purpose, authors, functional requirements, software,
tools, nonfunctional requirements etc.

Requirements:

Something required, something wanted or needed

✔ Need- something you have to have
✔ Want -something you would like to have

Software Requirement:
A complete description of what the software system will do without describing how it will
do it is represented by the software requirements

Requirement Engineering:

Requirements engineering is composed of four key activities – requirements elicitation,

requirements analysis and negotiation, requirements specification or documentation and
requirements validation.

Software Requirement Engineering:

✔ What: The various levels and types of requirements that need to be defined
✔ Why: The benefits of having the right software requirements
✔ Who: The stakeholders of the software requirements and getting them involved in
the process
✔ When: Requirements activities throughout the software development life cycle
✔ How: Techniques for eliciting, analyzing, specifying, and validating software
Requirements

Characteristics of Good User Requirements

⮚ COMPLETE:

They include all of the necessary elements; functionality, external interfaces, internal
interfaces, design constraint, and quality attributes, Complete requirement leaves no one

3
guessing (For how long?, 50 % of what?), and includes measurement units (inches or
centimeters?).

⮚ CORRECT:

They accurately reflect the real needs of users and business stakeholders.

⮚ CLEAR :

They are understood by all stakeholders without the need for extensive explanation.

⮚ CONSISTENT:

They do not conflict with other requirements (conflicting requirements should be

addressed ASAP in the requirements elicitation process).

⮚ RELEVANT:

This may seem obvious, but it is sometimes easy to get off-track and you can end up with
requirements that are not necessary for that particular project. To avoid this, make sure the
requirements meet a business need, goal, or objective.

⮚ VERIFIABLE :

There must be way to verify if the requirement is satisfied. Verifiable requirement is stated
in such a way that it can be tested by: - inspection, - analysis, or - demonstration. Makes it
possible to evaluate whether the system met the requirement

⮚ FEASIBLE (Realistic, Possible):

The requirement should be doable within existing constraints such as time, money, and
available resources:

⮚ AMBIGUOUS:

Requirements that:
✔ have any kind of ambiguity.
✔ have more than one type of interpretation.
Any task in requirements that can have more than one correct output that is contingent on
a different understanding of the task is ambiguous.

4
2. Functional Requirements:
Functional requirements
– Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.

Statements describing what the system does

– Functionality of the system

Statements of services the system should provide

– Reaction to particular inputs
– Behavior in particular situations

Example of Functional Requirements:

The LIBRAIRYSYS System

• The users can search for, download and print articles for personal study.
• The user shall be able to search either all of the initial set of databases or select a
subset from it.
• The system shall provide appropriate viewers for the user to read documents in
the document store.
• The users order shall be allocated a unique identifier (ORDER_ID) which the user
shall be able to copy to the account’s permanent storage area.

3. Non Functional Requirements:

A non-functional requirement is a statement of how a system must behave, it is a
constraint upon the systems behavior.

• Most non-functional requirements relate to the system as a whole.

– They include constraints on timing, performance, reliability, security,
maintainability, accuracy, the development process, standards, etc.

Example of Non Functional Requirements:

● "Display of the patient's vital signs must respond to a change in the
patient's status within 2 seconds."

5
4. Lab activities
TASK 1 :
Do you find any requirement errors in given statements. If yes:
Identify the type of error and write corrected version of these statements.

🡺 REQ1: On loss of power, the battery backup must support normal operations.
🡺 REQ2: The system shall not accept passwords longer than 15 characters.
🡺 REQ3: The system shall have a natural language interface that will understand
commands given in English language.
🡺 REQ4: The replacement control system shall be installed with no disturbance
to production.
🡺 REQ5: The system shall resist concurrent usage by many users

TASK 2:
A requirement that says “Users should be able to move more quickly between screens” is
not verifiable. Why?

TASK 3:

What will you end up with when you are asked “to divide 8 in a half”.

TASK4 :

Write down Functional and NonFunctional Requirements of ATM (Automated teller

Machine)?

3. Project activities

1. Write down the Functional and Non Functional Requirements of your project?

6
 Annex:
Examples of Functional Requirements

Use case model:

Create an Log in
account

Company Select the Security

Extend Insert an
place empty place staff

Place request
Review
an
agreemen
Extend t

Log in
Extend

Fill
agreement IMS staff
form

Review
companies
orders

Control
activities

7
Functional requirement:
ID Requirement Definition
FR1 Create an account
FR1.1 The system shall enable a user to create an account
FR2 Select the places for rent
FR2.1 The system shall identify the possible places to the investor to allow him to
choose one of the available places
FR3 Place request
FR3.1 The system shall allow the investor to send a require place throw the system
FR4 View request status
FR4.1 The system shall allow user to show his place request status.
FR5 Login
FR5.1 The system shall allow to the all actors to gain the system throw supposed user
name and password.
FR6 Insert an empty place
FR6.1 The system shall allow the security staff to insert an empty places.
FR7 Review an agreement
FR7.1 The system shall allow security staff to reviewing the final approval
agreement.
FR8 Fill agreement form
FR8.1 The system shall allow the IMS staff to enter the agreement information after
the manually approval.
FR9 Reviewing companies orders
FR9.1 The system shall allow the IMS staff to response about the companies
requests.
FR10 Control activity
FR10.1 The system shall allow the IMS staff to control all the actors who has an
account in IMS website.

8
 Interface requirements

 Field accepts numeric data entry

 Field only accepts dates before the current date
 Screen can print on-screen data to the printer

Business Requirements

 Data must be entered before a request can approved

 Clicking the Approve Button moves the request to the Approval Workflow

Regulatory/Compliance Requirements

 The database will have a functional audit trail

 The system will limit access to authorized users
 The spreadsheet can secure data with electronic signatures

Security Requirements

 Members of the Data Entry group can enter requests but not approve or delete
requests
 Members of the Managers group can enter or approve a request, but not delete
requests
 Members of the Administrators group cannot enter or approve requests, but can
delete requests

Non-Functional requirement:
User Interface
UI1: The system shall provide certain functionalities in the user interface according
to the user authorization
UI2: The system shall provide user friendly interface
UI2: The user interface shall be as GUI
 Hardware Interface
HI1: The system shall be implemented in a hardware-independent fashion and should
not rely on any particular hardware interfaces.

9
 Software Interface
SI1: The Investment management system shall communicate with the data base of UJ
system to extract the needed information including user name and password to
validate the user access to Investment management system.
 Security Requirements
SE1: The system shall provide log in page
SE2: The system shall allow user to access only the services which he/she authorize
to access
SE2.1: The system shall allow only authorized user to make and edit, delete.

10