2

SOFTWARE ENGINEERING
Course Code: 22CSE141

Module 2: Software Requirements

Functional and nonfunctional requirements, User

requirements – Software requirements Document –
Requirement Engineering Process – Feasibility
studies, Requirements elicitation and analysis,
Requirements validation – System models: Context
Models, Behavioral models, Data models, Object
models, structured methods.
4
 Requirements
• Requirements = services the system is expected to
provide + constraints placed on the system.

• Requirements engineering = gathering, negotiating,

analyzing, and documenting requirements.

• The requirements could be expressed at various levels of

abstraction.

• The way requirements are defined has a major impact on

the development of the software product.
REQUIREMENTS ENGINEERING

• The process of establishing the services that the

customer requires from a system and the constraints
under which it operates and is developed.

• The requirements themselves are the descriptions of the

system services and constraints that are generated during
the requirements engineering process.
 REQUIREMENT ENGG.

• It may range from a high-level abstract statement of a service or of a

system constraint to a detailed mathematical functional specification

• Types of requirement
• User requirements :Statements in natural language plus
diagrams of the services the system provides and its operational
constraints. Written for customers.
• System requirements : A structured document setting out
detailed - descriptions of the system services. Written as a
contract between client and contractor.
• Software specification : A detailed software description which
can serve as a basis for a design or implementation. Written for
developers.

7
8
9
 Contents

• Requirements
• Functional
• Non-Functional
• User Requirements
• The Software Requirements Document

10 / 26
 Functional and Non functional Requirements

Functional Requirements:
• These are the requirements that the end user specifically demands as basic
facilities that the system should offer.
• All these functionalities need to be necessarily incorporated into the system as
a part of the contract.
• describe the requested functionality/behaviour of the system: services
(functions), reactions to inputs, exceptions, modes of operations

Non Functional Requirements

• These are basically the quality constraints that the system must satisfy
according to the project contract.
• The priority or extent to which these factors are implemented varies from one
project to other. They are also called non-behavioral requirements.
• represent constraints on the system and its functionality: performance
constraints, compliance with standards, constraints on the development
process.

11
 FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS

1. A functional requirement defines a system or its A non-functional requirement defines the quality
component. attribute of a software system.

2. It specifies “What should the software system It places constraints on “How should the software
do?” system fulfill the functional requirements?”

Non-functional requirement is specified by

3. Functional requirement is specified by User. technical peoples e.g. Architect, Technical leaders
and software developers.

4. It is mandatory. It is not mandatory.

5. It is captured in use case. It is captured as a quality attribute.

6. Defined at a component level. Applied to a system as a whole.

7. Helps you verify the functionality of the Helps you to verify the performance of the
software. software.

8. Functional Testing like System, Integration, Non-Functional Testing like Performance, Stress,
End to End, API testing, etc are done. Usability, Security testing, etc are done.

9. Usually easy to define. Usually more difficult to define. 12

 Non-functional Requirements
• A classification of non-functional requirements [Fig. 6.3, SE-7]:
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
 Non-functional Requirements..
• Metrics that can be used to quantitatively specify and verify non-
functional requirements.
Property Measure
Sp eed Pro ces sed tran sactions /s econ d
User/Event res pon se time
Screen refres h time
Size K By tes
Numb er o f RAM chips
Eas e o f u se Training time
Numb er o f h elp frames
Reliability Mean time to failu re
Pro bability of u navailability
Rate of failure occurrence
Availability
Rob us tness Time to restart after failu re
Percen tag e o f events cau sing failure
Pro bability of d ata corru ption on failure
Po rtab ility Percen tag e o f target d ep en dent s tat ements
Numb er o f target s ys tems

Jain University
14 / 26
 User Requirements

• User requirements:
• Should be understood by the user, and should not address
design and implementation aspects
• Should focus on the key facilities required
• Problems with requirements written in natural language:
• Lack of clarity, ambiguity, various interpretations possible
• Confusion, lack of separation between different types of
requirements
• Mixture of several requirements in the same statement
• Hard to modularize and thus hard to find connections between
requirements

15 / 26
Jain University
 User Requirements …
• Guidelines for writing requirements:
• Create and use a standard format for the entire software requirements specification
• Highlight important parts of the requirement statements
• Use consistently the language (difference between “should” and “shall”)
• Avoid computer jargon

16 / 26
Jain University
The Software Requirements Document
• This document, also called Software Requirements Specification
(SRS), is the official description of the system’s requirements
(includes user and system reqs.)

• Heninger (1980) recommends that an SRS should:

• Specify only external system behaviour
• Specify constraints on implementation
• Be easy to change
• Serve as a reference for maintainers
• Record forethought about the software life cycle
• Describe acceptable responses to undesired events

17 / 26
Jain University
 Software Requirements Document
• SRS structure according IEEE/ANSI 830-1993 standard (overview
only, many more details are given in the standard):
• Introduction
• General description
• Specific requirements
• Appendices
• Index
• This structure needs to be tailored for each particular
organization

18 / 26
 Software Requirements Specification
• A software requirements specification (SRS) is a document that is
created when a detailed description of all aspects of the software to be
built must be specified before the project is to commence.
• It is important to note that a formal SRS is not always written
1. Introduction
• 1.1 Purpose
• 1.2 Document Conventions
• 1.3 Intended Audience and Reading Suggestions
• 1.4 Project Scope
• 1.5 References
2. Overall Description
• 2.1 Product Perspective
• 2.2 Product Features
• 2.3 User Classes and Characteristics
• 2.4 Operating Environment

19
• 2.5 Design and Implementation Constraints
• 2.6 User Documentation
• 2.7 Assumptions and Dependencies
3. System Features
• 3.1 System Feature 1
• 3.2 System Feature 2 (and so on)
4. External Interface Requirements
• 4.1 User Interfaces
• 4.2 Hardware Interfaces
• 4.3 Software Interfaces
• 4.4 Communications Interfaces
5. Other Nonfunctional Requirements
• 5.1 Performance Requirements
• 5.2 Safety Requirements
• 5.3 Security Requirements
• 5.4 Software Quality Attributes
6. Other Requirements 20
REQUIREMENTS ENGINEERING PROCESS

21
 Validating Requirements
 Is each requirement consistent with the overall
objective for the system/product?
 Have all requirements been specified at the proper
level of abstraction? That is, do some requirements
provide a level of technical detail that is inappropriate
at this stage?
 Is the requirement really necessary or does it represent
an add-on feature that may not be essential to the
objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a
source (generally, a specific individual) noted for each
requirement?
 Do any requirements conflict with other requirements?
22
 Validating Requirements
 Is each requirement achievable in the technical
environment that will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the
information, function and behavior of the system to be
built.
 Has the requirements model been “partitioned” in a way
that exposes progressively more detailed information
about the system.
 Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly
validated? Are all patterns consistent with customer
requirements?
23
 Eliciting Requirements
1 Collaborative Requirements Gathering
 meetings are conducted and attended by both software engineers
and customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual
forum) is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements
24
 2. Quality Function Deployment
Normal requirements: Requirements which are stated
during the meeting with the customer
Example:) normal requirements might be requested types
of graphical displays, specific system functions
Expected requirements: Requirements are implicit to the
product or system that are not explicitly stated by the
customer.
Exciting requirements: features go beyond the
customer’s expectations and prove to be very satisfying
when present.
Example:) software for a new mobile phone comes with
standard features, but is coupled with a set of unexpected
capabilities (e.g., multitouch screen, visual voice mail)
that delight every user of the product.

25
 3. Usage Scenarios
• A usage scenario, or scenario for short, describes a real-
world example of how one or more people or
organizations interact with a system.

• They describe the steps, events, and/or actions which

occur during the interaction.

• Usage scenarios can be very detailed, indicating exactly

how someone works with the user interface, or
reasonably high-level describing the critical business
actions but not the indicating how they're performed.

26
 3. Usage Scenarios
•Usage scenarios are applied in several
development processes, often in different ways.

•In derivatives of the Unified Process (UP) they are

used the help move from use cases to sequence
diagrams.

•The basic strategy is to identify a path though a

use case, or through a portion of a use case, and
then write the scenario as an instance of that
path. 27
 3. Usage Scenarios …
• For example, the text of the "Withdraw Funds" use case would
indicate what should happens when everything goes right, in this
case the funds exist in the account and the ATM has the funds.
• This would be referred to as the "happy path" or basic course of
action.
• The use case would include alternate paths describing what
happens when mistakes occur, such as there being insufficient
funds in the account or the ATM being short of cash to disburse to
customers.
• You would write usage scenarios that would explore the happy
path, such as the first scenario above, as well as each of the
alternate courses. You would then develop a sequence diagram
exploring the implementation logic for each scenario.

28
Attributes of a Good Software Exhibit

Jain University 29
The System Engineering Process
 System Design Problems
• Requirements partitioning to hardware,
software and human components may involve a lot of
negotiation

• Difficult design problems are often assumed to be readily

solved using software

• Hardware platforms may be inappropriate for

software requirements so software must compensate for
this
31
 Understanding the Classification of Requirements
Functional requirements :
• Describe functionality or system services, how the system should react to particular inputs and how the system
should behave in particular situations.
• 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 but functional system
requirements should describe the system services in detail.

Non-functional requirements :
• Defines system properties and constraints e.g. reliability, response time and storage requirements. Constraints
are I/O device capability, system representations, etc.
• Can be constraints on the process too
• Use a particular CASE system, programming language or development method
• System maybe unusable if non-functional requirements are not satisfied (Critical)
• Non-functional classifications
Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g. execution speed,
reliability, etc.
• Organizational requirements
• Requirements which are a consequence of organizational policies and procedures e.g. process standards used,
implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are external to the system and its development process e.g.
interoperability requirements, legislative requirements, etc.
Jain University 32
 Objectives of Modular Software Design
• Functional partitioning into discrete scalable , reusable
modules.
• Rigorous use of well-defined modular interface.
• Ease of change to achieve technology transparency and to the
extent possible make use of industry standards for key
interfaces.
• Modularity is the principle of keeping separate the various unrelated
aspects of a system, so that each aspect can be studied in isolation
(also called separation of concerns).
• If the principle is applied well, each resulting module will have a
single purpose and will be relatively independent of the others.
• Each module will be easy to understand and develop easier to locate
faults (because there are fewer suspect modules per fault).
• Easier to change the system (because a change to one module affects
relatively few other modules)
Jain University 33
Layered Architectural style.

Jain University 34
 What is Requirement Analysis?
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system
elements
 establishes constraints that software must meet
 Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during
earlier requirement engineering tasks
 build models that depict user scenarios, functional
activities, problem classes and their relationships,
system and class behavior, and the flow of data as it
is transformed. 35
Elements of Requirement Analysis

36
 Scenario-Based Models

 “[Use-cases] a“[Use-cases] are simply an aid to

defining what exists outside the system (actors) and
what should be performed by the system (use-cases).”
- Ivar Jacobson
 Represented via use cases
1 Creating Preliminary use case
 What to write about? – Inception and elicitation will
provide the information for begin with use cases.
2 Refining Preliminary use case
3 Writing a formal use case
37
 Scenario-Based Models

Use Case Diagram of Safe Home System 38

 Class-Based Modeling
Class-based Modeling includes:
1. Identifying classes (often from use cases as a starting
point)
2. Identifying associations between classes
3. Identifying general attributes and responsibilities of
classes
4. Modeling interactions between classes
5. Modeling how individual objects change state -- helps
identify operations
6. Checking the model against requirements, making
adjustments, iterating through the process more than
once.
39
40
 Context Model – Microwave oven model
Full
power Full power
do: set power
= 600

Timer
Waiting
Number
do: display Operation
time Full Set time
power do: get number do: operate
exit: set time oven
Half
Half power
Door
power Cancel
Timer closed
Door Start
open Door
Half power Enabled open Waiting
do: set power Door do: display do: display
= 300 closed 'Ready' time

Disabled
do: display
'Waiting' 41
 Microwave oven state description
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half
power’.
Full power The oven power is set to 600 watts. The display shows ‘Full
power’.
Set time The cooking time is set to the user’s input value. The display
shows the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
Display shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display
shows ‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the
timer countdown. On completion of cooking, the buzzer is
sounded for 5 seconds. Oven light is on. Display shows ‘Cooking
complete’ while buzzer is sounding.
42
 Microwave oven stimulus
Stimulus Description
Half power The user has pressed the half power button
Full power The user has pressed the full power button
Timer The user has pressed one of the timer buttons
Number The user has pressed a numeric key
Door open The oven door switch is not closed
Door closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button
43
 Behavioural Models
• Behavioural models are used to describe the overall
behaviour of a system
• Two types of behavioural model are shown here
• Data processing models that show how data is
processed as it moves through the system
• State machine models that show the systems response
to events
• Both of these models are required for a description of the
system’s behaviour
Explanation of Data processing models, State machine
models required. Jain University 44
Behavioural Model – State Diagram

45
Data models

46
 Data Flow Models

• Data flow diagrams are used to model the system’s

data processing

• These show the processing steps as data flows

through a system

• Intrinsic part of many analysis methods

• Simple and intuitive notation that customers can

understand

• Show end-to-end processing of data.

47
 Data Flow Diagrams (DFD)

• DFDs model the system from a functional perspective.

• Tracking and documenting how the data associated with

a process is helpful to develop an overall understanding
of the system

• Data flow diagrams may also be used in showing the

data exchange between a system and other systems in its
environment

48
 Elements of a DFD
• Processes
• Change the data. Each process has one or more inputs
and outputs
• Data stores
used by processes to store and retrieve data (files,
DBs)
• Data flows
-movement of data among processes and data
stores
• External entities
- outside things which are sources or
destinations of data to the system

49
 DFD for Order Processing
Checked and
Completed Signed Signed Send to signed order
order form order form order form supplier + order
Order
notification
details + Complete Validate Record
blank order form order order
order form Adjust
Order available
Signed budget
details order form
Order
amount
+ account
details
Orders Budget
file file

50
 What is Object Oriented Data Modeling?
•Centers around objects and classes
•Involves inheritance
•Encapsulates both data and behavior
•Benefits of Object-Oriented Modeling
• Ability to tackle challenging problems
• Improved communication between users, analysts, designer,
and programmers
• Increased consistency in analysis and design
• Explicit representation of commonality among system
components
• System robustness
• Reusability of analysis, design, and programming results
51
 OO vs EER Data Modeling
Object Oriented ER

Class Entity type

Object Entity Instance
Association Relationship
Inheritance of attributes Inheritance of attributes
Inheritance of behavior No representation of
behavior

Object-oriented modeling is frequently accomplished using the

Unified Modeling Language (UML)
52
 Classes and Objects
•Class: An entity that has a well-defined role
in the application domain, as well as state,
behavior, and identity
• Tangible: person, place or thing
• Concept or Event: department, performance, marriage,
registration
• Artifact of the Design Process: user interface, controller,
scheduler
•Object: a particular instance of a class

Objects exhibit BEHAVIOR as well as attributes

 Different from entities
53
 State, Behavior, Identity

•State: attribute types and values

•Behavior: how an object acts and reacts
• Behavior is expressed through operations that can
be performed on it
•Identity: every object has a unique identity,
even if all of its attribute values are the same

54
 UML class and object diagram
Class diagram showing two classes

Class diagram shows the static structure of an object-oriented

55
model: object classes, internal structure, relationships.
 UML class and object diagram …
Object diagram with two instances

Object diagram shows instances that are compatible with a

56 given class diagram.
 Object diagram for customer order

57
 STRUCTURED ANALYSIS

• It considers data and the processes that transform

the data as separate entities.

• Data objects are modeled in a way that defines

their attributes and relationships.

• Processes that manipulate data objects are

modeled in a manner that shows how they
transform data as data objects flow through the
system.

58
 STRUCTURED ANALYSIS
1. Source traceability information links the requirements to the stakeholders who
proposed the requirements and to the rationale for these requirements. When a
change is proposed, you use this information to find and consult the stakeholders
about the change.

2. Requirements traceability information links dependent requirements within the

requirements document. You use this information to assess how many
requirements are likely to be affected by a proposed change and the extent of
consequential requirements changes that may be necessary.

3. Design traceability information links the requirements to the design modules

where these requirements are implemented. You use this information to assess the
impact of proposed requirements changes on the system design and
implementation.
59
 SUMMARY
Module 2: Software Requirements
In Module 2 we discussed the following topics,
Functional and nonfunctional requirements,
User requirements,
Software requirements Document
Requirement Engineering Process
Feasibility studies,
Requirements elicitation and analysis,
Requirements validation
System models:
Context Models,
Behavioral models,
Data models,
Object models,
Structured methods. 60