I. What is Software Engineering?

 Software engineering is the establishment and use of

sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines.

 Software engineering is a modeling activity.

 Software engineering is a problem-solving activity.
 Software engineering is a knowledge acquisition activity.
 Software engineering is a rationale- driven activity.

1
Cont..
1. Modeling Activity:
 A model is an abstract representation of a system that
enables us to answer questions about the system.
 Software engineers deal with complexity through
modeling, by focusing at any one time on only the
relevant details and ignoring everything else.
 Models are useful when dealing with systems that are
too large, too small, too complicated, or too expensive
to experience firsthand.

2
Cont…
2. Problem solving
 Engineering is a problem-solving activity. It is not
algorithmic. In its simplest form, the engineering
method includes five steps:
1. formulate the problem
2. analyze the problem
3. search for solutions
4. decide on the appropriate solution
5. specify the solution

3
Cont…
3. Knowledge acquisition
 In modeling the application and solution domain,
software engineers collect data, organize it into
information, and formalize it into knowledge.

 Knowledge acquisition is nonlinear, as a single piece

of data can invalidate complete models.

 A common mistake that software engineers and

managers make is to assume that the acquisition of
knowledge needed to develop a system is linear.

4
Cont…
4. Rationale management
 When acquiring knowledge and making decisions
about the system or its application domain, software
engineers also need to capture the context in which
decisions were made and the rationale behind these
decisions.
 enables software engineers to understand the implication of a
proposed change when revisiting a decision.

5
Software Engineering Body of Knowledge

Source: http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr004.pdf
6
 What is a software process?
SP is a set of activities whose goal is the
development or evolution of software
Fundamental activities in all software processes are:
 Specification - what the system should do
and its development constraints
 Development - production of the software system
(design and implementation)
 Validation - checking that the software is what the
customer wants

7
 What is CASE ?
(Computer-Aided Software Engineering)
Software systems which are intended to provide
automated support for software process activities,
such as requirements analysis, system modelling,
debugging and testing
 Upper-CASE
 Tools to support the early process
activities of requirements and design
 Lower-CASE
 Tools to support later activities such as
programming, debugging and testing

8
What are the attributes of good software?
The software should deliver the required
functionality and performance to the user and should
be maintainable, dependable and usable
 Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be trustworthy/dependable
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 Software must be usable by the users for which it was
designed
9
 What are the key challenges
facing software engineering?
Software engineering in the 21st century faces three
key challenges:
 Legacy systems
 Old, valuable systems must be maintained and updated
 Heterogeneity
 Systems are distributed and include
a mix of hardware and software
 Delivery
 There is increasing pressure
for faster delivery of software

10
What is a Requirement?
 “… a specification of what should be implemented.
Descriptions of how the system should behave, or of a
system property or attribute. May be a constraint on
the development process”.
“A condition or capability:
 Needed by a user to solve a problem or achieve an
objective that must be met by a system or system
component to satisfy a contract, standard,
specification or other formally imposed document
 A documented representation of a condition or
capability”

11
 cont.
 Requirements are descriptions of the services that a
software system must provide and the constraints
under which it must operate
 Requirements Engineering is the process of
establishing the services that the customer requires
from the system and the constraints under which it is
to be developed and operated

12
Characteristics of a Good Requirement
 Clear and Unambiguous
 standard structure
 has only one possible interpretation
 Not more than one requirement in one sentence
 Correct
 A requirement contributes to a real need
 Understandable
 A reader can easily understand the meaning of the
requirement
 Verifiable
 A requirement can be tested
 Complete
 Consistent
 Traceable

13
The Requirement Engineering Process
 The process of establishing what services are required and

the constraints on the system’s operation and development

 Requirements engineering help software engineers to

better understand the problem they will work to solve. It

encompasses the set of tasks that lead to an understanding
of what the business impact of the software will be, what
the customer wants and how end-users will interact with
the software.

14
Requirement Engineering Process
 Feasibility Study

 Requirements elicitation and analysis

 Requirements Specification

 Requirements Validation

15
Importance of requirements engineering
Requirements can:
 Form the basis of project estimates
 Clarify scope
 Reveal more about the problem, the people, the
processes, the business rules
 Rationalise/justify at a task level why the problem
needs addressing
 Take time to uncover
Requirements are often seen as being ‘just’ a
project deliverable; a set of guidelines that drive a
solution
16
Common problems in Requirements Engineering

Requirements are difficult to write well.

The customer, users and developers all think

they know which functionality is to be
included, but their understandings are all
somewhat different, resulting in expectations
that are unlikely to be met.

17
Some common problems are:
 Problem not well defined
 Users unsure what is needed
 Ambiguous expressions
 Conflict between requirements
 Overlapping and duplicate requirements
 Unrealistic requirements
 Not testable
 Missing requirements
 Not linked to the business objective

18
 Types of requirements
 Customer Requirements:
 Operational distribution or deployment:
Where will the system be used?
 Mission profile or scenario: How will the
system accomplish its mission objective?
 Performance and related parameters:
What are the critical system parameters to
accomplish the mission?

19
Cont.
 Utilization environments: how are the various
system components to be used?
 Effectiveness requirements: How effective or
efficient must the system be in performing its
mission?
 Operational life cycle: How long will the system
be in use by the user?
 Environment: what environments will the system
be expected to operate in an effective manner?

20
 Architectural Requirements:

 A formal description and representation of a system,

organized in a way that support reasoning about the
structure of the system which comprises system
components, the externally visible properties of those
components, the relationships and the behavior
between them, and provides a plan from which products
can be procured and systems developed, that will work
together to implement the overall system

21
Functional Requirements:
 Defines functions of a software system or its
components. They may be calculations, technical
details, data manipulation and processing and
other specific functionality that define “what a
system is supposed to accomplish?”

 They describe particular results of a system.

 Functional requirements are supported by Non-

functional requirements.
22
 Non-Functional Requirements
 They are requirements that specify criteria that can be
used to judge the operation of a system, rather than
specific behavior.
 Functional requirements define what the system is
supposed to do, whereas non-functional requirements
define how a system is supposed to be.
 Non-functional requirements can be divided into two main
categories:
 Execution qualities, such as security and usability, which
are observable at runtime.
 Evolution qualities, such as testability, maintainability
and scalability.
23
Requirements Engineering Activities
 Project Creation: Project creation is the activity of
setting up a project to develop a new product or to
modify and existing product.
 Elicitation: Elicitation refers to gathering the
requirements of the system from different
stakeholders. Boundaries, identification of
stakeholders, goals and tasks performed are discovered
in this phase

24
 cont.
 Interpretation and Structuring: Following the
elicitation of the requirements, they are interpreted,
structured and analyzed. The requirements are then
documented. This phase is discussed separately,
however it is often interleaved with requirements
elicitation, as some analysis invariable takes place in
the elicitation process (Kotonya and Sommerville,
1998).
25
 Cont.
 Negotiation: The negotiation phase consists of the
requirements engineers negotiating with the
stakeholders to agree about the requirements
definitions in the requirements documentation
 Verification and Validation: Verification and
validation of requirements aims to check that the
requirements accurately represent the needs of the
system
 Change Management: Change management makes
certain that similar information is gathered for each
change and that the overall costs and benefits of
proposed changes are reviewed
26
 Cont.
 Requirements Tracing: Requirements tracing is used
to track the origins of each requirement, so that if a
change has to be made to a design component, the
original requirement can be located

27
Thank you??

28