Week 1 software requirements engineeringv2

1. software requirements engineering: WEEK 1

SOFTWARE
REQUIREMENTS
ENGINEERING:
WEEK 1
DR. CHANDRA REKA

2. Course Introduction

COURSE
INTRODUCTION

3. Lecturer Info

CHANDRA REKA RAMACHANDIRAN A1-421
chandrareka.ramachandiran@xmu.edu.my
Office Hours:
Lecturer
Day
Time
Duration
Dr. Chandra Reka
Tuesday.
10-12 p.m.
2 hours
Thursday,
10-12 p.m.
2 hours

4. CLOs

◦ At the end of this course, students will be able to:
1. Critique the basic principles, processes and methodologies of requirements engineering (C5, PLO2).
2. Illustrate requirements using structured requirements model and object-oriented requirements model.
(C4, PLO2)
3. Demonstrate teamwork and follow patterns and processes in requirements works. (A3, PLO4)
4. Create a software requirements specification document for a proposed software application. (C6,
PLO2)

5. Course Assessments

Components
*Tutorials/Lab Report
Assignment (Group SRS)
Presentation (SRS)
Finals Assessment(Written Exam)
Total
Percentage
10%
25%
5%
60%
100%
SRS Group Assignment is carried out in a team of FOUR
*Weekly tutorials are to be completed and submission must be done via
Moodle

6. SWE307 = CA+ FA

7. Continuous Assessments: 40%

◦ All tutorials/lab report submissions = 10%
◦ Group Assignment Report: SRS Project (25%): Case Study you have chosen
◦ Group Presentation Overall 5% : Case Study presentation
Task on Week 1: Form a group of 4 students and pick a Software Development Topic:
Example: An Education Based Application. Mobile Application, Open Source Application
-Submit the Group List via Moodle (WEEK 2)

8. OVERVIEW OF REQUIREMENT ENGINEERING

9. COURSE OUTLINE

• Introduction
• Overview of software requirements
• The concept of software requirements
• The important of the software requirements
• The document of the software requirements
• The classifications of requirements
COURSE
OUTLINE

10. Learning Outcomes

In this lesson, you will:
◦ Describe what is the meaning of Software Requirements
◦ Identify who are the stakeholders of Software Requirements
◦ Describe in brief about the Requirements Engineering process
◦ Explain why software requirements are important in Software Development
◦ Classify the different types of Requirements.

11.

https://2020.icse-conferences.org/getImage/orig/NancyLevesonKeynote.pdf

12.

13. Concept of Software Requirements

- Functionalities that are needed or wanted
in a new software system by stakeholders
- In other words, the software system must be
able TO DO what the stakeholders need
from the system

14. Stakeholders in software requirements

“A stakeholder is an individual or group that a
business analyst is likely to interact with directly or
indirectly.”
(BABOK Guide V3)
- Those who use the system
- Those who benefit from the system
- Those who may be disadvantaged by the
system
- Those who are responsible for the system
- Those who are affected by the system
- The funder of the project
SWE307
14

15. Stakeholders in software requirements

Stakeholders can
include:
• Business analyst
• Customer
• Subject matter
expert (domain
and
implementation)
• End user
• Operational
support
SWE307
• Project manager
• Regulatory bodies
• Sponsor
• Supplier
• Tester
15

16. Definition of Requirements

IEEE-STD-1220-1998 (IEEE 1998) definition:
“A statement that identifies a product or
process operational, functional, or design
characteristic or constraint, which is
unambiguous, testable or measurable, and
necessary for product or process
acceptability (by consumers or internal
quality assurance guidelines).”

17.

18. A requirement ….

• Is made up of short and concise pieces of
information
• Provides an insight into the system
• Must be agreed upon by all stakeholders
• Solves the customer’s problem
• Is an agreement/contract between customer and
the developer
SWE307
18

19. SOFTWARE QUALITY IS IMPORTANT

- Clarity in the final product (software) to be
delivered
- Requirements can be defined in a clear and
logical manner
- Understand the needs of the customer (and
stakeholders)
- To decide if the software should be built or bought
from off-the-shelf
- As reference throughout project/software lifecyle:
design, implementation, project monitoring,
verification and validation, and in training ( IEEE
Std: 1074-1991)
- Provides input for testing the system
SWE307
19

20.

SWE307
20

21. Software Requirements Documents

◦ The software requirements document is the official statement of what is required of the systems.
◦ Should include both a definition of user requirements and a specification of the system requirements
◦ It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than
HOW it should do.

22. Software Requirements Documents

23. 9 types of Requirement Documents

1.
Business Requirements Documents (BRD)
2.
Functional Requirement Documents (FRD)
3.
Market Requirements Document (MRD)
4.
Product Requirement Documents (PRD)
5.
User Interface Requirement Documents (UIRD)
6.
Technical Requirement Document (TRD)
7.
Quality Requirement Documents (QRD)
8.
Software Requirement Documents or Software Requirements Specification (SRS)
9.
Customer Requirement Documents (CRD)
SWE307
23

24. Classification of Requirements

◦ User Requirements: are statements, in a natural language plus diagrams, of what services the system is
expected to provide to system users and the constraints under which it must operate.
◦ System Requirements: are more detailed descriptions of the software system’s functions, services, and
operational constraints. The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented. It may be part of the contract between
the system buyer and the software developers.
(Sommerville2010)

25.

Readers of different types of requirements specification

26. System 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. In some
cases, the functional requirements may also explicitly state what the
system should not do.
◦ Non-Functional Requirements:
◦ constraints on the services or functions offered by the system.
◦ include timing constraints, constraints on the development process,
and constraints imposed by standards.
◦ Non-functional requirements often apply to the system as a whole,
rather than individual system features or services.

27. Functional Requirements

◦ Describe functionality or system services (features).
◦ Depend on the type of software, expected users and the type of system where the
software is used.
◦ Functional user requirements may be high-level statements of what the system
should do.
◦ Functional system requirements should describe the system services in detail.

28. Example

◦ For the pet store POS system, the following might be some functional requirements:
◦ 4.1 When the operator presses the “total” button, the current sale enters the closed-out state.
◦ 4.1.1 When a sale enters the closed-out state, a total for each nonsale item is computed as number of
items times the list price of the item.
◦ 4.1.2 When a sale enters the closed-out state, a total for each sale item is computed

29. Non Functional Requirements

◦ NON-FUNCTIONAL REQUIREMENT (NFR) specifies the quality attribute of a software system.
◦ They judge the software system based on Responsiveness, Usability, Security, Portability and other nonfunctional standards that are critical to the success of the software system.
◦ Example of nonfunctional requirement, “how fast does the website load?” Failing to meet non-functional
requirements can result in systems that fail to satisfy user needs.

30.

Parameters
What is it?
Requirement
Capturing type
Functional Requirement
Non-Functional Requirement
Verb
Attributes
It is mandatory
It is non-mandatory
It is captured in use case.
It is captured as a quality attribute.
Product feature
Product properties
Easy to capture
Hard to capture
Objective
Helps you verify the functionality of the
software.
Helps you to verify the performance of the
software.
Area of focus
Focus on user requirement
Concentrates on the user's expectation.
Documentation
Describe what the product does
Describes how the product works
Type of Testing
Functional Testing like System, Integration, End Non-Functional Testing like Performance,
to End, API testing, etc.
Stress, Usability, Security testing, etc.
Test Execution
Test Execution is done before non-functional
testing.
End-result
Capturing
Product Info
Product Features
After the functional testing
Product Properties

31. SUMMARY

◦ Functional requirements are easy to define because the business idea drives them. They include all the
features of your future project and the ways users engage with it.
◦ Experience drives Non-functional requirements. In order, to identify them, you need to analyze the
product's performance and make it convenient and useful. Such requirements may appear when the
product is being used on a regular basis.
◦ https://theappsolutions.com/blog/development/functional-vs-non-functional-requirements/
Functional requirements are defined with regard to
business processes, non functional ones with regard to
system capabilities.

32. EXERCISE

◦ Elaborate the stakeholders for a project ‘Concert Ticket Booking System’
◦ Identify the NFR for the proposed system

33. Reference Materials

◦ A Guide to the Business Analysis Body of Knowledge v3. (2015). International Institute of Business Analysis.
◦ ISO/IEC/IEEE. (2018). Systems and software engineering — Life cycle processes — Requirements
engineering. ISO/IEC/IEEE 29148:2018(E).
◦ Sommerville, I. (2011). Software Engineering. Ninth Edition. ISBN-13: 978-0-13-703515-1. (Refer Chapter 4:
page 82 onwards)
◦ Ibraigheeth, M., Fazli, S. A. (2019). Core Factors for Software Projects Success. International Journal of
Informatics Visualization. 3(1).
◦ Classification of Requirements. In https://gyires.inf.unideb.hu/GyBITT/07/ch02.html (Last Retrieved
10/4/2020)
◦ https://caminao.blog/how-to-implement-symbolic-representations/requirements/non-functionalrequirements/
SWE307
33

34. Kindly email me if you have any questions

DR. CHANDRA REKA
RAMACHANDIRAN
chandrareka.ramachandiran@xmu.edu.my