Wolkite University

College of Computing and Informatics

Software Engineering Department

Fundamental of software Engineering

Chapter-Four: Software Engineering

By: M.G
 CONTENTS

What is requirements Engineering?

Software Requirements

Requirement Engineering Process

System Models

2
What is requirements Engineering?
Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering design
process.
Requirements Engineering (RE) is a set of activities concerned with
identifying and communicating the purpose of a software-intensive
system, and the contexts in which it will be used.
Requirement engineering is the process of establishing the services
that the customer requires from a system and the constraints under
which it operates and is developed.

3
What is requirements Engineering? …
Requirement engineering is the process of collecting, validating and
managing the requirements essential for the development of the software,
specified by the clients or the end-users.
Requirements engineering is the process of conforming engineering
designs to a set of core software requirements.
Requirement engineering provides the appropriate mechanism to
understand what the customer desires, analyzing the need, and assessing
feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they
are transformed into a working system.
4
What is requirements Engineering? …
Thus, requirement engineering is the disciplined application of proven
principles, methods, tools, and notation to describe a proposed
system's intended behavior and its associated constraints.
Hence, RE acts as the bridge between the real-world needs of users,
customers, and other constituencies affected by a software system, and
the capabilities and opportunities afforded by software-intensive
technologies.
This is critically important for creating accurate results in software
engineering.

5
What is requirements Engineering? …
Requirements engineering is also known as requirements analysis.
The requirements themselves are the descriptions of the system services
and constraints that are generated during the requirements engineering
process.
This task is performed at the initial stages of software development.
Requirement engineering provides the basic idea to the software
developer of what the client or the end-user wants the software to do.
The requirement engineering process involves a team of software
developers or engineers, business analysts, customers and end-users.
6
Software Requirements
Requirement is a condition or capability possessed by the software or system
component in order to solve a real-world problem.
The problems can be to automate a part of a system, to correct shortcomings
of an existing system, to control a device, and so on.
IEEE defines requirement as:
 A condition or capability needed by a user to solve a problem or achieve an objective.
 A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
documents.
 A documented representation of a condition or capability as in (1) or (2).’

7
Software Requirements …
Requirements describe how a system should act, appear or perform.
For this, when users request for software, they provide an
approximation of what the new system should be capable of doing.
Requirements differ from one user to another and from one business
process to another.

8
Guidelines for Expressing Requirements
The purpose of the requirements document is to provide a basis for
the mutual understanding between the users and the designers of the
initial definition of the software development life cycle (SDLC)
including the requirements, operating environment and development
plan.
The requirements document should include the overview, the
proposed methods and procedures, a summary of improvements, a
summary of impacts, security, privacy, internal control considerations,
cost considerations, and alternatives.

9
Guidelines for Expressing Requirements …
The requirements section should state the functions required in the
software in quantitative and qualitative terms and how these functions
will satisfy the performance objectives.
The requirements document should also specify the performance
requirements such as accuracy, validation, timing, and flexibility.
Inputs, outputs, and data characteristics need to be explained.
Finally, the requirements document needs to describe the operating
environment and provide (or make reference to) a development plan.

10
Guidelines for Expressing Requirements …
There is no standard method to express and document requirements.
Requirements can be stated efficiently by the experience of
knowledgeable individuals, observing past requirements, and by
following guidelines.
Guidelines act as an efficient method of expressing requirements,
which also provide a basis for software development, system testing,
and user satisfaction.
The guidelines that are commonly followed to document requirements
are listed below:
11
Guidelines for Expressing Requirements …
 Sentences and paragraphs should be short and written in active voice. Also,
proper grammar, spelling, and punctuation should be used.
 Conjunctions such as ‘and’ and ‘or’ should be avoided as they indicate the
combination of several requirements in one requirement.
 Each requirement should be stated only once so that it does not create
redundancy in the requirements specification document.

12
Types of Requirements
Requirements help to understand the behavior of a system, which is
described by various tasks of the system.
For example, some of the tasks of a system are to provide a response
to input values, determine the state of data objects, and so on.
Note that requirements are considered prior to the development of the
software.
The requirements, which are commonly considered, are classified into
three categories, namely, functional requirements, non-functional
requirements, and domain requirements.
13
Types of Requirements …
IEEE defines functional requirements as ‘a function that a system or
component must be able to perform.’
These requirements describe the interaction of software with its
environment and specify the inputs, outputs, external interfaces, and
the functions that should be included in the software.
Also, the services provided by functional requirements specify the
procedure by which the software should react to particular inputs or
behave in particular situations.

14
Types of Requirements …
To understand functional requirements properly, let us consider the
following example of an online banking system.
 The user of the bank should be able to search the desired services from the
available ones.
 There should be appropriate documents’ for users to read. This implies that
when a user wants to open an account in the bank, the forms must be available
so that the user can open an account.
 After registration, the user should be provided with a unique
acknowledgement number so that he can later be given an account number.

15
Types of Requirements …
The functional requirements should be complete and consistent. Completeness implies
that all the user requirements are defined.
Consistency implies that all requirements are specified clearly without any
contradictory definition.
Generally, it is observed that completeness and consistency cannot be achieved in large
software or in a complex system due to the problems that arise while defining the
functional requirements of these systems.
The different needs of stakeholders also prevent the achievement of completeness and
consistency.
Due to these reasons, requirements may not be obvious when they are, ‘first specified
and may further lead to inconsistencies in the requirements specification.

16
Types of Requirements …
The non-functional requirements (also known as quality
requirements) are related to system attributes such as reliability and
response time.
Non-functional requirements arise due to user requirements, budget
constraints, organizational policies, and so on.
These requirements are not related directly to any particular function
provided by the system.
Non-functional requirements should be accomplished in software to
make it perform efficiently.
17
Types of Requirements …
The description of different types of non-functional requirements is
listed below:
 Product requirements: These requirements specify how software product
performs. Product requirements comprise the following.
 Efficiency requirements: Describe the extent to which the software makes
optimal use of resources, the speed with which the system executes, and the
memory it consumes for its operation. For example, the system should be able
to operate at least three times faster than the existing system.
 Reliability requirements: Describe the acceptable failure rate of the software.
For example, the software should be able to operate even if a hazard occurs.

18
Types of Requirements …
 Portability requirements: Describe the ease with which the software can be
transferred from one platform to another. For example, it should be easy to
port the software to a different operating system without the need to redesign
the entire software.
 Usability requirements: Describe the ease with which users are able to operate
the software. For example, the software should be able to provide access to
functionality with fewer keystrokes and mouse clicks.
 Organizational requirements: These requirements are derived from the policies
and procedures of an organization. Organizational requirements comprise the
following.

19
Types of Requirements …
 Delivery requirements: Specify when the software and its documentation are
to be delivered to the user.
 Implementation requirements: Describe requirements such as programming
language and design method.
 Standards requirements: Describe the process standards to be used during
software development. For example, the software should be developed using
standards specified by the ISO and IEEE standards.
 External requirements: These requirements include all the requirements that
affect the software or its development process externally. External
requirements comprise the following.

20
Types of Requirements …
 Interoperability requirements: Define the way in which different computer-
based systems will interact with each other in one or more organizations.
 Ethical requirements: Specify the rules and regulations of the software so that
they are acceptable to users.
 Legislative requirements: Ensure that the software operates within the legal
jurisdiction. For example, pirated software should not be sold.
Non-functional requirements are difficult to verify. Hence, it is
essential to write non-functional requirements quantitatively, so that
they can be tested. For this, non-functional requirements metrics are
used. These metrics are listed in Table.
21
Types of Requirements …
Features Measures
Speed  Processed transaction/ second
 User/event response time
 Screen refresh rate

Size  Amount of memory (KB)

 Number of RAM chips.

Ease of use  Training time

 Number of help windows
22
Types of Requirements …
Reliability  Mean time to failure (MTTF)
 Portability of unavailability
 Rate of failure occurrence
Robustness  Time to restart after failure
 Percentage of events causing failure
 Probability of data corruption on
failure
Portability  Percentage of target-dependent
statements
 Number of target systems

23
Types of Requirements …
Requirements which are derived from the application domain of the
system instead from the needs of the users are known as domain
requirements.
These requirements may be new functional requirements or specify a
method to perform some particular computations.
In addition, these requirements include any constraint that may be
present in the existing functional requirements.
As domain requirements reflect the fundamentals of the application
domain, it is important to understand these requirements.
24
Types of Requirements …
Also, if these requirements are not fulfilled, it may be difficult to
make the system work as desired.
A system can include a number of domain requirements.
For example, it may comprise a design constraint that describes the
user interface, which is capable of accessing all the databases used in a
system.
It is important for a development team to create databases and
interface designs as per established standards.

25
Types of Requirements …
Similarly, the requirements of the user such as copyright restrictions
and security mechanism for the files and documents used in the system
are also domain requirements.
When domain requirements are not expressed clearly, it can result in
the following difficulties.
Problem of understandability: When domain requirements are
specified in the language of application domain (such as mathematical
expressions), it becomes difficult for software engineers to understand
them.

26
Types of Requirements …
Problem of implicitness: When domain experts understand the
domain requirements but do not express these requirements clearly, it
may create a problem (due to incomplete information) for the
development team to understand and implement the requirements in
the system.

27
Requirement Engineering Process
This process is a series of activities that are performed in the
requirements phase to express requirements in the Software
Requirements Specification (SRS)document.
It focuses on understanding the requirements and its type so that an
appropriate technique is determined to carry out the Requirements
Engineering (RE) process.
The new software developed after collecting requirements either
replaces the existing software or enhances its features and
functionality.

28
Requirement Engineering Process …
For example, the payment mode of the existing software can be
changed from payment through hand-written cheques to electronic
payment of bills.
Requirement engineering processes includes:
 Feasibility Study
 Requirement Elicitation and Analysis
 Software Requirement Specification
 Software Requirement Validation
 Software Requirement Management

29
Requirement Engineering Process …

30
Feasibility Study
The objective behind the feasibility study is to create the reasons for developing
the software that is acceptable to users, flexible to change and conformable to
established standards.
Technical Feasibility: Technical feasibility evaluates the current technologies,
which are needed to accomplish customer requirements within the time and budget.
Operational Feasibility: Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and
customer requirements.
Economic Feasibility: Economic feasibility decides whether the necessary software
can generate financial profits for an organization

31
Requirement Elicitation and Analysis
This is also known as the gathering of requirements.
Here, requirements are identified with the help of customers and
existing systems processes, if available.
Analysis of requirements starts with requirement elicitation.
The requirements are analyzed to identify inconsistencies, defects,
omission, etc.
We describe requirements in terms of relationships and also resolve
conflicts if any.

32
Requirement Elicitation and Analysis …

33
Requirement Elicitation and Analysis …
Problems of Elicitation and Analysis
 Getting all, and only, the right people involved.
 Stakeholders often don't know what they want
 Stakeholders express requirements in their terms.
 Stakeholders may have conflicting requirements.
 Requirement change during the analysis process.
 Organizational and political factors may influence system requirements.

34
Software Requirement Specification
Software requirement specification is a kind of document which is
created by a software analyst after the requirements collected from the
various sources - the requirement received by the customer written in
ordinary language.
It is the job of the analyst to write the requirement in technical language
so that they can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams
(DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.

35
Software Requirement Specification …
Data Flow Diagrams:
 Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows
the flow of data through a system.
 The system may be a company, an organization, a set of procedures, a computer
hardware system, a software system, or any combination of the preceding.
 The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries:
 Data Dictionaries are simply repositories to store information about all data items defined
in DFDs.
 At the requirements stage, the data dictionary should at least define customer data items,
to ensure that the customer and developers use the same definition and terminologies.

36
Software Requirement Specification …
Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.

37
Software Requirement Validation
After requirement specifications developed, the requirements discussed
in this document are validated.
The user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the
following conditions:
 If they can practically implement
 If they are correct and as per the functionality and specially of software
 If there are any ambiguities
 If they are full
 If they can describe
38
Software Requirement Validation …
Requirements Validation Techniques
 Requirements reviews/inspections: systematic manual analysis of the
requirements.
 Prototyping: Using an executable model of the system to check requirements.
 Test-case generation: Developing tests for requirements to check testability.
 Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

39
Software Requirement Management
Requirement management is the process of managing changing
requirements during the requirements engineering process and system
development.
New requirements emerge during the process as business needs a
change, and a better understanding of the system is developed.
The priority of requirements from different viewpoints changes
during development process.
The business and technical environment of the system changes during
the development.
40
Software Requirement Management …
Collection of software requirements is the basis of the entire software
development project.
Hence, they should be clear, correct, and well-defined.
A complete Software Requirement Specifications should be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
41
Software Requirement Management …
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
Software Requirements: Largely software requirements must be categorized
into two categories:
 Functional Requirements: Functional requirements define a function that a system or
system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.

42
Software Requirement Management …
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
Software Requirements: Largely software requirements must be categorized
into two categories:
 Functional Requirements: Functional requirements define a function that a system or
system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.

43
Software Requirement Management …
Non-functional Requirements: This can be the necessities that specify
the criteria that can be used to decide the operation instead of specific
behaviors of the system.
Non-functional requirements are divided into two main categories:
 Execution qualities like security and usability, which are observable at run
time.
 Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.

44
System Models
System modeling is the process of developing abstract models of a
system, with each model presenting a different view or perspective of
that system.
It is about representing a system using some kind of graphical
notation, which is now almost always based on notations in the
Unified Modeling Language (UML).
Models help the analyst to understand the functionality of the system;
they are used to communicate with customers.
Models can explain the system from different perspectives:
45
System Models …
 An external perspective, where you model the context or environment of the
system.
 An interaction perspective, where you model the interactions between a
system and its environment, or between the components of a system.
 A structural perspective, where you model the organization of a system or the
structure of the data that is processed by the system.
 A behavioral perspective, where you model the dynamic behavior of the
system and how it responds to events.
Five types of UML diagrams that are the most useful for system
modeling:
46
System Models …
 Activity diagrams, which show the activities involved in a process or in data
processing.
 Use case diagrams, which show the interactions between a system and its
environment.
 Sequence diagrams, which show interactions between actors and the system
and between system components.
 Class diagrams, which show the object classes in the system and the
associations between these classes.
 State diagrams, which show how the system reacts to internal and external
events.

47
System Models …
Models of both new and existing system are used during requirements
engineering.
Models of the existing systems help clarify what the existing system does
and can be used as a basis for discussing its strengths and weaknesses.
These then lead to requirements for the new system.
Models of the new system are used during requirements engineering to
help explain the proposed requirements to other system stakeholders.
Engineers use these models to discuss design proposals and to document
the system for implementation.
48
Context and process models
Context models are used to illustrate the operational context of a system -
they show what lies outside the system boundaries.
Social and organizational concerns may affect the decision on where to
position system boundaries.
Architectural models show the system and its relationship with other systems.
System boundaries are established to define what is inside and what is
outside the system.
They show other systems that are used or depend on the system being
developed.

49
Context and process models …
The position of the system boundary has a profound effect on the system
requirements.
Defining a system boundary is a political judgment since there may be
pressures to develop system boundaries that increase/decrease the influence or
workload of different parts of an organization.
Context models simply show the other systems in the environment, not how
the system being developed is used in that environment.
Process models reveal how the system being developed is used in broader
business processes.
UML activity diagrams may be used to define business process models.
50
Context and process models …
The example below shows a UML activity diagram describing the
process of involuntary detention and the role of MHC-PMS (mental
healthcare patient management system) in it.

51
Context and process models …

52
Interaction models
Types of interactions that can be represented in a model:
 Modeling user interaction is important as it helps to identify user
requirements.
 Modeling system-to-system interaction highlights the communication
problems that may arise.
 Modeling component interaction helps us understand if a proposed system
structure is likely to deliver the required system performance and
dependability.
Use cases were developed originally to support requirements
elicitation and now incorporated into the UML.
53
Interaction models …
Each use case represents a discrete task that involves external
interaction with a system.
Actors in a use case may be people or other systems.
Use cases can be represented using a UML use case diagram and in a
more detailed textual/tabular format.

54
Interaction models …
Use case title Transfer data
A receptionist may transfer data from the MHC-PMS to a general
patient record database that is maintained by a health authority. The
Description information transferred may either be updated personal information
(address, phone number, etc.) or a summary of the patient's diagnosis
and treatment.
Actor(s) Medical receptionist, patient records system (PRS)

55
Interaction models …
Patient data has been collected (personal information, treatment
summary);
Preconditions
The receptionist must have appropriate security permissions to access
the patient information and the PRS.
Postconditions PRS has been updated
1. Receptionist selects the "Transfer data" option from the menu.
Main success 2. PRS verifies the security credentials of the receptionist.
scenario 3. Data is transferred.
4. PRS has been updated.
56
Interaction models …

2a. The receptionist does not have the necessary security

credentials.
Extensions
2a.1. An error message is displayed.
2a.2. The receptionist backs out of the use case.

57
Interaction models …
UML sequence diagrams are used to model the interactions between
the actors and the objects within a system.
A sequence diagram shows the sequence of interactions that take
place during a particular use case or use case instance.
The objects and actors involved are listed along the top of the
diagram, with a dotted line drawn vertically from these.
Interactions between objects are indicated by annotated arrows.

58
Interaction models …

59
Structural models
Structural models of software display the organization of a system in
terms of the components that make up that system and their
relationships.
Structural models may be static models, which show the structure of
the system design, or dynamic models, which show the organization of
the system when it is executing.
You create structural models of a system when you are discussing and
designing the system architecture.

60
Structural models …
UML class diagrams are used when developing an object-oriented system
model to show the classes in a system and the associations between these
classes.
An object class can be thought of as a general definition of one kind of
system object.
An association is a link between classes that indicates that there is some
relationship between these classes.
When you are developing models during the early stages of the software
engineering process, objects represent something in the real world, such as a
patient, a prescription, doctor, etc.
61
Structural models …
Generalization is an everyday technique that we use to manage complexity.
In modeling systems, it is often useful to examine the classes in a system to see if
there is scope for generalization.
In object-oriented languages, such as Java, generalization is implemented using
the class inheritance mechanisms built into the language.
In a generalization, the attributes and operations associated with higher-level
classes are also associated with the lower-level classes.
The lower-level classes are subclasses inherit the attributes and operations from
their super-classes.
These lower-level classes then add more specific attributes and operations.
62
Structural models …
An aggregation model shows how classes that are collections are
composed of other classes.
Aggregation models are similar to the part-of relationship in semantic
data models.

63
Structural models …

64
Structural models …

65
Structural models …

66
Structural models …

Aggregation class

67
Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is
executing.
They show what happens or what is supposed to happen when a system
responds to a stimulus from its environment.
Two types of stimuli:
 Some data arrives that has to be processed by the system.
 Some event happens that triggers system processing. Events may have associated
data, although this is not always the case.
Many business systems are data-processing systems that are primarily driven
by data.
68
Behavioral models …
They are controlled by the data input to the system, with relatively
little external event processing.
Data-driven models show the sequence of actions involved in
processing input data and generating an associated output.
They are particularly useful during the analysis of requirements as
they can be used to show end-to-end processing in a system.
Data-driven models can be created using UML activity diagrams:

69
Behavioral models …

Activity diagram
70
Behavioral models …

Data-driven models can also be created using UML sequence diagrams:

71
Behavioral models …
Real-time systems are often event-driven, with minimal data processing.
For example, a landline phone switching system responds to events such
as 'receiver off hook' by generating a dial tone.
Event-driven models shows how a system responds to external and
internal events.
It is based on the assumption that a system has a finite number of states
and that events (stimuli) may cause a transition from one state to another.
Event-driven models can be created using UML state diagrams:

72
Behavioral models …

73
Thank you!

Any questions?

Good day!