Tribhuvan University

Institute of Engineering
Pulchowk Campus
Department of Electronics and Computer Engineering

Software Engineering
[Subject Code: CT 601]

by
Santosh Giri
Lecturer, IOE, Pulchowk Campus.

1
 Overall Course Outline:
SOFTWARE ENGINEERING
CT 601
Lecture : 3 Year : III
Tutorial : 1 Part : I
Practical : 1.5
Course Objectives:
This course provides a systematic approach towards planning,
development, implementation and maintenance of system, also
help developing software projects.

2
1. Software Process and requirements (12 hr, 20 mrk)
1.1. Software crisis
1.2. Software characteristics
1.3. Software quality attributes
1.4. Software process model
1.5. Process iteration
1.6. process activities
1.7. Computer‐aided software engineering
1.8. Functional and non –functional requirements
1.9. User requirements
1.10. System requirement
1.11. Interface specification
1.12. The software requirements documents
1.13. Feasibility study

3
 1.14. Requirements elicitation and analysis
1.15. Requirements validation and management

2. System models (3 hrs, 5 mrks)

2.1. Context models
2.2. Behavioral models
2.3. Data and object models

3. Architectural design (6 hrs, 10 mrks)

3.1. Architectural design decisions
3.2. System organization
3.3. Modular decomposition styles
3.4. Control styles
3.5. Reference architectures

4
 3.6. Multiprocessor architecture
3.7. Client –server architectures
3.8. Distributed object architectures
3.9. Inter‐organizational distributed computing

4. Real –time software design (3 hrs, 5 mrks)

4.1. System design
4.2. Real‐time operating systems
4.3. Monitoring and control systems
4.4. Data acquisition systems

5
5. Software Reuse (3 hrs, 5 mrks)
5.1. The reuse landscape
5.2. Design patterns
5.3. Generator –based reuse
5.4. Application frameworks
5.5. Application system reuse

6. Component‐based software engineering (2 hours, 3

mrks)
6.1. Components and components models
6.2. The CBSE process
6.3. Component composition

6
7. Verification and validation (3 hrs, 5 mrks)
7.1. Planning verification and validation
7.2. Software inspections
7.3. Verification and formal methods
7.4. Critical System verification and validation

8. Software Testing and cost Estimation (4 hrs, 8

mks)
8.1. System testing
8.2. Component testing
8.3. Test case design
8.4. Test automation
8.5. Metrics for testing
8.6. Software productivity
7
 8.7. Estimation techniques
8.8. Algorithmic cost modeling
8.9. Project duration and staffing

9. Quality management (5 hrs, 10 mrks)

9.1. Quality concepts
9.2. Software quality assurance
9.3. Software reviews
9.4. Formal technical reviews
9.5. Formal approaches to SQA
9.6. Statistical software quality assurance
9.7. Software reliability
9.8. A framework for software metrics

8
 9.9. Matrices for analysis and design model
9.10. ISO standards
9.11. CMMI
9.12. SQA plan
9.13. Software certification

10. Configuration Management (2 hrs, 4 mrks)

10.1. Configuration management planning
10.2. Change management
10.3. Version and release management
10.4. System building
10.5. CASE tools for configuration management

9
Practical
The laboratory exercises shall include projects on
requirements, analysis and designing of software system.
Choice of project depend upon teacher and student, case
studies shall be included too. Guest lecture from software
industry in the practical session.

References:
 Ian Sommerville, Software Engineering
 Roger S. Pressman, Software Engineering –A Practitioner’s
Approach
 Pankaj Jalote, Software Engineering‐A precise approach
 Rajib Mall, Fundamental of Software Engineering

10
 Evaluation Scheme
The questions will cover all the chapters in syllabus. The evaluation scheme will
be as indicated in the table below:

*There may be minor deviation in marks distribution

11
 Tribhuvan University
Institute of Engineering
Pulchowk Campus
Department of Electronics and Computer Engineering

Software Engineering
Chapter One
Software Process and requirements

by
Santosh Giri
Lecturer, IOE, Pulchowk Campus.

12
 Chapter One: Software Process and requirements
Course Outline: 12 hours, 20
Marks
1.1. Software crisis
1.2. Software characteristics
1.3. Software quality attributes
1.4. Software process model
1.5. Process iteration
1.6. process activities
1.7. Computer‐aided software engineering
1.8. Functional and non –functional requirements
1.9. User requirements
1.10. System requirement
1.11. Interface specification
1.12. The software requirements documents
1.13. Feasibility study
1.14. Requirements elicitation and analysis
1.15. Requirements validation and management

13
Software and its types
 Computer software is a collection of programs or computer
instructions that tell the computer how to work- Wikipedia
 It is the product that software professionals build and then
support over the long term.

14
1. Application Software
It can be divided into Generic and Specific
a. Generic (or Packaged) Software
 The application software which is designed to fulfill the
needs of large group of users is known as generic or
packaged software.
Example: MS-Word, Adobe Reader, MS-Excel.
b. Tailored (or Specific) Software
The application software which is designed to fulfill the
needs of a particular user/company/organization is known
as tailored or specific software.
Example: Software used in department stores, hospitals,
schools etc.

15
2. System Software:-
The software which can directly control the hardware of the
computer are known as system software.
Example: Video driver, audio driver.

3. Utility Software:-
Small software that usually performs some useful tasks is
known as utility software.
Example: Win Zip, JPEG Compressor, PDF Merger, PDF to
Word Converter etc.

16
Software Characteristics

 Software is developed or engineered, not manufactured in

the classical sense

 Software doesn‘t ―wear out‖

 Software is custom-built, rather than being assembled

from existing components

17
 (H/W failure)

failures due to design

/manufacturing defects

cumulative affects
of dust, vibration,
abuse, temperature
extremes etc.

Figure 1 : Bathtub Curve

18
Figure 1 depicts failure rate vs time for hardware called bath tub
curve
The relationship, often called the ―bathtub curve―
It indicates that hardware exhibits relatively high failure
rates early in its life (failures due to design /manufacturing
defects);
defects are corrected and the failure rate drops to a steady-
state level (ideally, quite low) for some period of time.
As time passes, the failure rate rises again as hardware
components suffer from the cumulative affects of dust,
vibration, abuse, temperature extremes, and many other
environmental maladies.

Stated simply, the hardware begins to wear out.

19
high failure rates in the
beginning due to
Undiscovered defects.

outdated and
no longer
used.

Undergo changes

20
Software is not susceptible to environmental maladies
In theory, s/w should take the form of ―idealized curve‖
However, Undiscovered defects in the beginning will cause
high failure rates
These are corrected (ideally, without introducing other
errors) and the curve flattens as shown
During the life time it undergo changes, it is likely that
some new defects will be introduced, causing the failure rate
curve to spike as shown before the curve can return to the
original steady-state failure rate, another change is
requested, causing the curve to spike again
 Slowly, the minimum failure rate level begins to rise- due to
change.

21
 Another aspect of wear illustrates the difference between hardware
and software.
 When a hardware component wears out, it is replaced by a spare
part.
 There are no software spare parts.
 Every software failure indicates an error in design or in the process
through which design was translated into machine executable code.
 Therefore, software maintenance involves considerably more
complexity than hardware maintenance.

22
2. Software is developed or engineered, not
manufactured in the classical sense
Although some similarities exists between software
development and hardware manufacturing, the two activities
are fundamentally different.
Similarities
 High quality needs to be achieved
 Both depend on people & Requires construction of product
Software is a design of strategies, instruction which finally
perform the designed, instructed tasks. And a design can
only be developed, not manufactured.
Software is virtual. That is, software can be used using
proper hardware. we can only use it, but we cannot touch
and see hardware. Thus software never gets manufactured,
they are developed.
23
3. Software is custom-built, rather than being assembled
from existing components
Consider the manner in which the control hardware for a
computer-based product is designed and built.
The design engineer draws a simple schematic of the digital
circuitry, does some fundamental analysis to assure that
proper function will be achieved, and then goes to the shelf
where catalogs of digital components exist.
Each integrated circuit (called an IC or a chip) has a part
number, a defined and validated function, a well-defined
interface, and a standard set of integration guidelines.
 After each component is selected, it can be ordered off the
shelf.

24
Standard screws and off-the-shelf integrated circuits are
only two of thousands of standard components that are used
by mechanical and electrical engineers as they design new
systems.
In the hardware world, component assemble and reuse is a
natural part of the engineering process.
 In the software world, it is something that has only begun
to be achieved on a broad scale.

25
1.3. Software quality attributes
 Functionality
All the features & their functionality should works as
expected.
There should not be any deviation in the actual result and
expected result.

 Reliability
An s/w is said to be reliable if it delivers all features without
any failure & that it is error free.
e.g.:
an application of saving student records without any error
and should not fail after entering 100 records.

26
 Correctness:
A software product is correct, if different requirements as
specified in the software requirements specification(SRS)
document have been correctly implemented.

 Usability
An s/w product is said to be usable of it is easy to use
without any specific training.
An s/w must be user friendly (i.e. easy to use).

 Reusability
An s/w product has good reusability if different modules of
the product can be reused to develop new product.

27
 Efficiency
A product should not waste resource.

 Portability
An s/w product is said to be portable if it can be easily made
to work in different operating system.

 Maintainability
An s/w product is said to be maintainable if
 Errors can be corrected easily.
 New functions can be added easily.
 Functionality can be modified easily

 Durable
An s/w product is said to be durable if it can be in use for
long period of time.
28
Software Crisis (assignment 1)
 The difficulty of writing the code for a computer program
which is correct and understandable is referred to as software
crisis.
 Software crisis is also referred to as inability to hire enough
qualified programmers.

29
 Software market today has a turnover of more than millions of
rupees.

 Out of this, approximately 30% of software is used for

personal computers and the remaining software is developed
for specific users or organizations.

 Application areas, such as the banking sector are completely

dependent on software application for their working. Software
failures in these technology-oriented areas have led to
considerable loss in terms of time, money, and even human
lives.

30
 History has seen many such failures. Some of these are listed
below:
1) 1991 during Gulf War:

The USA use patriot missiles as a defense against Iraqi scud

missile. However, patriot failed to hit the scud many times
which cost life of 28 USA soldiers. In an inquiry it is found
that a small bug had resulted in miscalculation of missile
path.

2) Arian- 5 Space Rocket:

In 1996, developed at cost of $7000 Million Dollars over a
period of 10 years was destroyed within less than 1 minutes
after its launch. As there was software bugs in rocket
guidance system.

31
3) Dollar 924 lakhs:
In 1996, US bank credit accounts of nearly 800 customer with
dollar 924 lakhs. This problem was due to main programming
bug in the banking system.
4) The North East blackout in 2003:
It has been major power system failures in the history of north
which involves 100 power plants, 50 million customer faced
problem, $ 6 million dollar financial loss.
5) In June 1980, the North American Aerospace Defense
Command (NORAD) reported that the US was under missile
attack. The report was traced to a faulty computer circuit that
generated incorrect signals. If the developers of the software
responsible for processing these signals had taken into account
the possibility that the circuit could fail, the false alert might
not have occurred.
32
 1.3. Software Process Model
 Since the prime objective of software engineering is to
develop methods for large systems, which produce high
quality software at low cost and in reasonable time.
 So it is essential to perform software development in phases.
This phased development of software is often referred to as
software development life cycle (SDLC) or software life cycle.
 And the models used to achieve these goals are termed as
Software Process Models.

33
Fig 1 software development process
34
 In fig 1,
 These phases work in top to bottom approach.

 The phases take inputs from the previous phases, add features,
and then produce outputs.

1. Preliminary investigation/ feasibility study:

 Feasibility study decides whether the new system should be developed
or not.
 There are three constraints, which decides the go or no-go decision.
a. Technical:
 determines whether technology needed for proposed system is available
or not.
 determines whether the existing system can be upgraded to use new
technology
 whether the organization has the expertise to use it or not.

35
 b. Time:
 determines the time needed to complete a project.
 Time is an important issue as cost increases with an increase in the
time period of a project.
c. Budget:
 This evaluation looks at the financial aspect of the project.
 determines whether the investment needed to implement the system
will be recovered at later stages or not.

2. Software Analysis/Requirement Analysis:

 Studies the problem or requirements of software in detail.
 After analyzing and elicitations of the requirements of the
user, a requirement statement known as software
requirement specification (SRS) is developed.

36
3. Software Design:
 Most crucial phase in the development of a system. The
SDLC process continues to move from the what questions
of the analysis phase to the how.
 Logical design is turned into a physical design.
 Based on the user requirements and the detailed analysis
the system must be designed.
 Input, output, databases, forms, processing specifications
etc. are drawn up in detail.
 Tools and techniques used for describing the system
design are: Flowchart, ERD, Data flow diagram (DFD),
UML diagrams like Use case, Activity, Sequence etc.

37
4. Software Coding:
 Physical design into software code.

 Writing a software code requires a prior knowledge of

programming language and its tools. Therefore, it is
important to choose the appropriate programming
language according to the user requirements.

 A program code is efficient if it makes optimal use of

resources and contains minimum errors.

38
5. Software Testing:
 Software testing is performed to ensure that software
produces the correct outputs i.e. free from errors. This
implies that outputs produced should be according to user
requirements.

 Efficient testing improves the quality of software.

 Test plan is created to test software in a planned and

systematic manner.

39
6. Software Maintenance:
 This phase comprises of a set of software engineering
activities that occur after software is delivered to the user.

 After the software is developed and delivered, it may

require changes. Sometimes, changes are made in software
system when user requirements are not completely met.

 To make changes in software system, software

maintenance process evaluates, controls, and implements
changes.

40
 Class Work

Mention different phases of Software Development life

cycle(SDLC), if you are under the project of Library
Management system.

41
 Software
Process Model
(Continue…)
42
What is Software process?
When you work to build a product or system, it‘s important to
go through a series of predictable steps—a road map that helps
you to create a timely, high-quality result. The road map that
you follow is called a ―software process.‖

Who does it?

Software engineers and their
managers adapt the process to their needs and then follow it. In
addition, the people who have requested the software have in the
process of defining, building, and testing it.

Why is it important?
Because it provides path, stability, control over your project.

43
What are the steps?
At a detailed level, the process that you adopt depends on the
software that you‘re building. One process might be
appropriate for creating software for an aircraft avionics
system, while an entirely different process would be indicated
for the creation of a website.

from a technical point of view:

A software process is a framework for the activities, actions,
and tasks that are required to build high-quality software-
Roger S. Pressman

44
Waterfall Model

45
 a. Waterfall model
i. Feasibility study
√ Technical
√ Financial
√ Time etc.

ii. Requirement specification

To specify the requirements‘ users specification should be
clearly understood and the requirements should be analyzed.
This phase involves interaction between user and software
engineer, and produces a document known as software
requirement specification (SRS).

46
 iii. Design
Determines the detailed process of developing software after
the requirements are analyzed. It utilizes software
requirements defined by the user and translates them into a
software representation. In this phase, the emphasis is on
finding a solution to the problems defined in the requirement
analysis phase. The software engineer, in this phase is mainly
concerned with the data structure, algorithmic detail, and
interface representations.
iv. Coding
Emphasizes on translation of design into a programming
language using the coding style and guidelines. The programs
created should be easy to read and understand. All the
programs written are documented according to the
specification.

47
v. Testing:
Ensures that the product is developed according to the
requirements of the user. Testing is performed to verify that
the product is functioning efficiently with minimum errors. It
focuses on the internal logics and external functions of the
software
vi. Implementation and maintenance
Delivers fully functioning operational software to the user.
Once the software is accepted and deployed at the user‘s end,
various changes occur due to changes in external environment
(these include upgrading new operating system or addition of
a new peripheral device). The changes also occur due to
changing requirements of the user and the changes occurring
in the field of technology. This phase focuses on modifying
software, correcting errors, and improving the performance of
the software.

48
Waterfall model (Summary)

49
Waterfall model

50
 b. prototype model
 The prototyping model is applied when there is an absence of
detailed information regarding input and output requirements
in the software.

 It is used if the requirements are not preciously specified.

 Prototyping model increases flexibility of the development

process by allowing the user to interact and experiment with a
working representation of the product known as prototype. A
prototype gives the user an actual feel of the system.

51
Prototype model

52
i. Requirements gathering and analysis
Prototyping model begins with requirements analysis, and
the requirements of the system are defined in detail. The user
is interviewed to know the requirements of the system.

ii. Quick design

When requirements are known, a preliminary design or a
quick design for the system is created. It is not a detailed
design, however, it includes the important aspects of the
system, which gives an idea of the system to the user. Quick
design helps in developing the prototype.

53
iii. Build prototype
Information gathered from quick design is modified to form
a prototype. The first prototype of the required system is
developed from quick design. It represents a ‗rough‘ design
of the required system.

iv. User evaluation

Next, the proposed system is presented to the user for
consideration as a part of development process. The users
thoroughly evaluate the prototype and recognize its strengths
and weaknesses, such as what is to be added or
removed.Comments and suggestions are collected from the
users and are provided to the developer.

54
v. Prototype refinement
Once the user evaluates the prototype, it is refined according
to the requirements. The developer revises the prototype to
make it more effective and efficient according to the user
requirement. If the user is not satisfied with the developed
prototype, a new prototype is developed with the additional
information provided by the user. The new prototype is
evaluated in the same manner as the previous prototype,
process continues until all the requirements specified by the
user are met. Once the user is satisfied a final system is
developed.

55
vi. Engineer product
Once the requirements are completely known, user accepts
the final prototype. The final system is thoroughly evaluated
and tested followed by routine maintenance on continuing
basis to prevent large-scale failures and to minimize
downtime.

56
57
 C. Spiral Model

In 1980‘s Boehm introduced a process model known as spiral

model. The spiral model comprises of activities organized in a
spiral, which has many cycles. This model combines the
features of prototyping model and waterfall model and is
advantageous for large, complex and expensive projects which
involves high risk.

58
C. Spiral Model

59
1. Each cycle of the first quadrant commences with
identifying the goals for that cycle. In addition, it determines
other alternatives, which are possible in accomplishing those
goals.

2. Next step in the cycle evaluates alternatives based on

objectives and constraints. This process identifies the project
risks. Risk signifies that there is a possibility that the
objectives of the project cannot be accomplished. If so the
formulation of a cost effective strategy for resolving risks is
followed. the strategy, which includes prototyping,
simulation, benchmarking..

60
3. The development of the software depends on remaining risks.
The third quadrant develops the final software while
considering the risks that can occur. Risk management
considers the time and effort to be devoted to each project
activity, such as planning, configuration management, quality
assurance, verification, and testing.

4. The last quadrant plans the next step, and includes planning
for the next prototype and thus,comprises of requirements
plan, development plan, integration plan, and test plan

61
62
 d. Evolutionary model
 An Evolutionary model breaks up an overall solution into
increments of functionality and develops each increment
individually.

 The evolution model divides the development cycle

into smaller, "Incremental Waterfall Model" in which users
are able to get access to the product at the end of each cycle.

 The users provide feedback on the product for planning stage

of the next cycle and the development team responds, often by
changing the product, plans or process.

63
64
65
RAD model

66
V model

67
 Software
Requirements

68
 What is requirement?

 Requirements describe how a system should act, appear, or

perform.

 For this, when users request for software, they possess an

approximation of what the new system should be capable of
doing.

 Requirements differ from one user to another user and from

one business process to another business process.

69
 What is software requirement?

IEEE defines requirement as:

―(1) A condition or capability needed by a user to solve a

problem or achieve an objective. (2) 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. 3) A documented
representation of a condition or capability as in (1)or (2)‖

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

71
Types of Requirements

72
 A functional requirement describes what a software system
should do, while non-functional requirements place constraints
on how the system will do so.

 Functional requirements specifies a function that a system or

system component must be able to perform. Whereas, non-
functional requirements (also known as quality
requirements) relate to system attributes, such as reliability,
response time etc.

73
Functional requirement
 A banking system must send perform requested transaction,
whenever a certain condition is met (i.e. account no, password,
etc).

Non-functional requirement
 Those transaction should be completed with a latency of no
greater than 6 hours from such an activity.

 Example of functional and non-functional is on the “Case

study example”.

74
 Requirements Engineering Process

 The requirements engineering (RE) process is a series of

activities that are performed in requirements phase in order to
express requirements in software requirements specification
(SRS) document.

 These steps include feasibility study, requirements elicitation,

requirements analysis, requirements specification,
requirements validation, and requirement management.

75
 What is software requirement?

IEEE defines requirement as:

Fig: Requirement engineering process

76
 STEP 1: FEASIBILITY STUDY
Objectives of feasibility study:

 To determine whether the software can be implemented using

current technology and within the specified budget and
schedule or not.

 To determine whether the software can be integrated with

other existing software or not.

 To minimizes project failure.

77
 Types of feasibility study
Technical
 technical skills and capabilities of development team.

 Assure that the technology chosen, has large number of users

so that they can be consulted when problems arise.
Operational
 solution suggested by software development team is
acceptable or not.
 whether users will adapt to new software or not.

78
Economic feasibility/ Budget
 whether the required software is capable of generating
financial gains for an organization or not.
 cost incurred on software development team
 estimated cost of hardware and software.
 cost of performing feasibility study.

Time
Whether the project will be completed on pre-specified time
or not.

79
 Feasibility Study Process
1.Information assessment:
 verifies that the system can be implemented using new
technology and within the budget.

2. Information collection:
 Specifies the sources from where information about software
can be obtained.
 Sources:
 users (who will operate the software)
 organization (where the software will be used).
 software development team (who understands user requirements and
knows how to fulfill them in software).

80
3. Report writing:
 Information about changes in software scope, budget,
schedule, and suggestion of any requirements in the system.

81
 Step 2: Requirements Elicitation
 Process of collecting information about software requirements
from different stakeholders (users, developer, project manager
etc.)
Issues in Requirement Elicitation
1. Problems of understanding
 Users are not certain about their requirements and thus are unable to
express what they require in software and which requirements are
feasible.
 This problem also arises when users have no or little knowledge of the
problem domain and are unable to understand the limitations of
computing environment of software.
2. Problems of volatility
 This problem arises when requirements change over time.

82
 Elicitation Techniques
The commonly followed elicitation techniques are listed below:
1.Interviews:
 Ways for eliciting requirements, it helps software engineer,
users, & development team to understand the problem and
suggest solution for the problem.
 An effective interview should have characteristics listed
below:
 Individuals involved in interviews should be able to accept new ideas,
focus on listening to the views of stakeholders & avoid biased views. ƒ
 Interviews should be conducted in defined context to requirements rather
than in general terms. E.g. a set of a questions or a requirements
proposal.

83
2.Scenarios:
 Helps to determine possible future outcome before implementation.
 In Generally, a scenario comprises of:
 Description of what users expect when scenario starts.
 Description of how to handle the situation when software is not
operating correctly.
 Description of the state of software when scenario ends.

3.Prototypes:
helps to clarify unclear requirements.
helps users to understand the information they need to provide to
software development team.

4.Quality function deployment (QFD) Assignment (3)

84
 Step 3: Requirement Analysis
It is the process of studying and refining requirements

Tasks performed in requirements analysis are:

 Understand the problem for which software is to be developed.

 Develop analysis model to analyze the requirements in the

software.
 Detect and resolve conflicts that arise due to unclear and unstated
requirements.
 Determine operational characteristics of software and how it
interacts with its environment.

85
 Step 4: Requirements Specification

Development of SRS document (software requirement

specification document.

Characteristics of SRS
1. Correct:
SRS is correct when
 all user requirements are stated in the requirements document.
 The stated requirements should be according to the desired system.

2. Unambiguous:
 SRS is unambiguous when every stated requirement has only one
interpretation i.e. each requirement is uniquely interpreted.

86
3. Complete:
 SRS is complete when the requirements clearly define what the software is
required to do.

4. Modifiable:
 The requirements of the user can change, hence, requirements document
should be created in such a manner where those changes can be modified
easily.

5. Ranked for importance and stability:

 All requirements are not equally important.

6. Verifiable:
 SRS is verifiable when the specified requirements can be verified with a
cost-effective process to check whether the final software meets those
requirements or not.

87
7. Consistent:
 SRS is consistent when the individual requirements defined does not conflict
with each other.
 e.g., a requirement states that an event ‗a‘ is to occur before another event
‗b‘. But then another set of requirements states that event ‗b‘ should occur
before event ‗a‘.

8. Traceable:
 SRS is traceable when the source of each requirement is clear and it
facilitates the reference of each requirement in future.

88
Fig : SRS Document template
89
 Step 5 : Requirements Validation
Why Validation ?
 Errors present in the SRS will adversely affect the cost if they are
detected later in the development process or when the software is
delivered to the user.

Fig: Requirement Validation

90
 Step 6: Requirements Management
Why ??
 To understand and control changes to system requirements.

Advantages of requirements management

Better control of complex projects:
 Provides overview to development team with a clear understanding of what,
when and why software is to be delivered.
Improves software quality:
 Ensures that the software performs according to requirements to enhance
software quality.
Reduced project costs and delays:
 Minimizes errors early in the development cycle, as it is expensive to ‗fix‘
errors at the later stages of the development cycle. As a result, the project
costs also reduced.
Improved team communications:
 Facilitates early involvement of users to ensure that their needs are achieved.
91
 Requirements Management Process
 Requirements management starts with planning,

 Then, each requirement is assigned a unique ‗identifier‘ so that it

can be crosschecked by other requirements. Once requirements
are identified, requirements tracing is performed.

 The objective of requirement tracing is to

ensure that all the requirements are well understood and are
included in test plans and test cases.

 Traceability information is stored in a traceability matrix, which

relates requirements to stakeholders or design module.
Traceability matrix refers to a table that correlates requirements.

92
 U  dependency
R  weaker Relationship

93
 Requirements change management

 It is used when there is a request or proposal for a change to the

requirements.

Fig: Requirement change management

94
Thank You!!!

95