CCSW 223: Principles of Software Engineering

GPA Manual

Department of Software Engineering

1
Objectives:
✔ Learn what the requirement are?
✔ Characteristics of good user requirements.
✔ 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
guessing (For how long?, 50 % of what?), and includes measurement units (inches or
centimeters?).

3
⮚ 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
 Annex:
Exampl es o f Fun ctional Requi rem ents

Use case model:

Create an Log in
account

Company Select the

Extend Insert an Security
place empty place staff

Place request
Review an
agreement

Extend

Log in
Extend

Fill agreement
form IMS staff

Review
companies orders

Control
activities

6
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.

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

7
 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.
• Software Interface
SI1: The Investment management system shall communicate with the data base of
KAU 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.