unit 2.pptx of Software engineering subject

UNIT-2
Process Models, Software Requirements, Requirements
Engineering process

Process Models
 Every s/w organization should describe a unique set of frame
work activities such as communication, planning , modeling,
construction ,and deployment.
 Each process model describes a workflow in which the
process elements are interrelated to one other.
These are the types of process models
 Waterfall model
 Incremental model
 RAD model
 Prototyping
 Spiral
 Concurrent development model
 Unified process model

TheWaterfall Model
 Water fall model is also called as classic life cycle model
 This is oldest paradigm for s/w engineering.
communication
planning
modeling
construction
deployment

 Communication:
Project initiation, requirements gathering .
 Planning:
Estimation, scheduling , tracking
 Modeling:
Analysis & design
 Construction:
Coding and testing
 Deployment:
Delivery, support , feedback

When to use the waterfall model:
 This model is used only when the requirements are very well
known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 The project is short.

Advantages of waterfall model:
 This model is simple and easy to understand and use.
 It is easy to manage due to the rigidity of the model
 In this model phases are processed and completed one at a time. Phases do
not overlap.
Disadvantages of waterfall model:
 Once the process is done, it is very difficult to go back and change something
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high
risk of changing.

Incremental process model
Incremental model
This model combines elements of waterfall model applied in
iterative fashion
Inc 1
Inc 2
Inc n
.. …..
Project calendar time
s/w functionality and features

 The incremental model combines elements of the linear
sequential model with the iterative philosophy of prototyping.
 The incremental model applies linear sequences in a staged
fashion.
 Each linear sequence produces a deliverable “increment” of
the software.
 The first increment is often a core product.
 The core product is evaluated, a plan is developed for the next
increment.
 The plan addresses the modification of the core product to
better meet the needs of the customer and delivery of
supplementary features.
 The process is repeated until the complete product is
produced.

When to use the Incremental model:
This model can be used when the
requirements of the system are clearly defined
and understood.
Major requirements must be defined; however,
some details can evolve with time.
There is a need to get a product to the market
early.
Resources with needed skill set are not
available.

Advantages of Incremental model:
 Generates working software quickly .
 This model is more flexible – less costly to change scope and
requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Easier to manage risk because risky pieces are identified and
handled during it’d iteration.
Disadvantages of Incremental model:
 Needs good planning and design.
 Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally.
 Total cost is higher than waterfall.

The RAD Model
Communication
Planning
Modeling
Construction
Modeling
Construction
Modeling
Construction
Deployment

Rapid application development model is a high speed
adaptation. in which rapid development is achieved by using
a component based construction approach.
This process enables the developer to create a fully functional
system” with in a very short time( e.g., 60 to 90 days)
 Communication is required to understand the business
problems.
 Planning is essential because multiple s/w teams work in
parallel in different system functions.
 Modeling has 3 phases business, data and process
modeling which gives the design representation that serves
as basic for RAD’s Construction phase
 Construction is all about the application of code generation.
 Deployment was done for subsequent iterations if
necessary.

When to use RAD model:
 RAD should be used when there is a need to create a system
that can be modularized in 2-3 months of time.
 It should be used if there’s high availability of designers for
modeling and the budget is high enough to afford their cost.
 RAD should be chosen only if resources with high business
knowledge are available and there is a need to produce the
system in a short span of time (2-3 months).

Advantages of the RAD model:
 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
Disadvantages of RAD model:
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.

Evolutionary Process Models
These models are iterative, they are characterized in a
manner that enables software engineers to develop
increasingly more complete version of the software.
 Prototyping
 Spiral model
 The concurrent development model

Communication
Quick
plane
Quick Plan
Construction
of prototype
Prototyping

Communication
 In this phase, developer and customer meet and discuss the overall objectives of the software.
Quick design
 Quick design is implemented when requirements are known.
 It includes only the important aspects like input and output format of the software.
 It focuses on those aspects which are visible to the user rather than the detailed plan.
 It helps to construct a prototype.
Modeling quick design
 This phase gives the clear idea about the development of software because the software is now built.
 It allows the developer to better understand the exact requirements.
Construction of prototype
The prototype is evaluated by the customer itself.
Deployment, delivery, feedback
 If the user is not satisfied with current prototype then it refines according to the requirements of the user.
 The process of refining the prototype is repeated until all the requirements of users are met.
 When the users are satisfied with the developed prototype then the system is developed on the basis of final
prototype.

When to use Prototype model
 Prototype model should be used when the desired system
needs to have a lot of interaction with the end users.
 Typically, online systems, web interfaces have a very high
amount of interaction with end users, are best suited for
Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for
the end user.
 Prototyping ensures that the end users constantly work with
the system and provide a feedback which is incorporated in
the prototype to result in a useable system.They are excellent
for designing good human computer interface systems.

Advantages of Prototyping Model
 Prototype model need not know the detailed input, output,
processes, adaptability of operating system and full machine
interaction.
 In the development process of this model users are actively
involved.
 The development process is the best platform to understand
the system by the user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies
the confusing or difficult functions.

Disadvantages of Prototyping Model :
 The client involvement is more and it is not always
considered by the developer.
 It is a slow process because it takes more time for
development.
 Many changes can disturb the rhythm of the development
team.
 Users are confused with the prototype given.

When to use Spiral model
 When costs and risk evaluation is important
 For medium to high-risk projects
 Users are not sure of their needs
 Requirements are complex
 New product line
 Significant changes are expected

Advantages of Spiral model
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

Disadvantages of Spiral model
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

The Concurrent development model

 The concurrent development model, some times called
concurrent engineering.
 The concurrent process model can be represented as a series of
major technical activities, tasks, and their associated states.
 Each concurrent activity can be in any one of the following states:
 None
 Awaiting
 Under development
 Done
 The concurrent process model is applicable to all types of s/w
development and provide an accurate picture of the current state
of a project.

When to use concurrent development model
 If stakeholder's want to know the current state of the
project.
 If we want to complete the project in less time.
 If we have more human resources.
 Overall requirements are not needed to start the project.

Advantages of the concurrent development model
 This model is applicable to all types of software development
processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a
project.

Disadvantages of the concurrent development model
 It needs better communication between the team members.
This may not be achieved all the time.
 It requires to remember the status of the different activities.

The Unified Process
 The unified process recognize the customer
communication and steam lined methods for describing
the customer’s view of a system.
 It emphasizes the importance of s/w architecture and helps
the architect focus on the right goals

UML provides the necessary technology to support OO s/w
engineering practices which does not provide the process
frame work to guide project teams in their application of
technology

Inception
 Defines the scope of the system
 Identify critical risk
The goal of the inception phase is to establish a business case
for the system.
You should identify all external entities (people and systems)
that will interact with the system and define their interactions
The out put of inception phase
The major shareholders agree on the scope of the project
It addresses high level requirements
As the business case is produced helps to provide green signal
to continue with the project

Elaboration:
The goals of the elaboration phase are to develop an
understanding of the problem domain.
Establish an architectural framework for the system, develop
the project plan and identify key project risks.

Construction:
 The construction phase is essentially concerned with system ,
programming and testing.
 On completion of this phase, you should have a working software
system and associated documentation that is ready for delivery to
users.
Transition:
 The final phase of the UP is concerned with moving the system from
the development community to the user community and making it
work in a real environment.
 During this phase the team focuses on correcting defects and
modifying the system.
 The goal of this phase to roll out fully functional system to customers

Agile development model
 It is also a type of Incremental model. Software is developed
in incremental, rapid cycles.
 This results in small incremental releases with each release
building on previous functionality.
 Each release is thoroughly tested to ensure software quality is
maintained.
 It is used for time critical applications.
 Extreme Programming (XP) is currently one of the most
well known agile development life cycle model

When to use Agile model
 When new changes are needed to be implemented.The freedom agile gives
to change is very important. New changes can be implemented at very little
cost because of the frequency of new increments that are produced.
 To implement a new feature the developers need to lose only the work of a
few days, or even only hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required
to get started with the project.Agile assumes that the end users’ needs are
ever changing in a dynamic business and IT world. Changes can be discussed
and features can be newly effected or removed based on feedback.This
effectively gives the customer the finished system they want or need.
 Both system developers and stakeholders alike, find they also get more
freedom of time and options than if the software was developed in a more
rigid sequential way. Having options gives them the ability to leave
important decisions until more or better data or even entire hosting
programs are available; meaning the project can continue to move forward
without fear of reaching a sudden standstill.

Advantages of Agile model:
 Customer satisfaction by rapid, continuous delivery of useful
software.
 People and interactions are emphasized rather than process and
tools. Customers, developers and testers constantly interact with
each other.
 Working software is delivered frequently (weeks rather than
months).
 Face-to-face conversation is the best form of communication.
 Close, daily cooperation between business people and
developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages of Agile model:
 In case of some software deliverables, especially the large
ones, it is difficult to assess the effort required at the
beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and
documentation.
 The project can easily get taken off track if the customer
representative is not clear what final outcome that they want.
 Only senior programmers are capable of taking the kind of
decisions required during the development process. Hence it
has no place for newbie programmers, unless combined with
experienced resources.

Introduction
 The requirements for a system are the descriptions of the
services provided by the system and its operational
constraints
 Requirements reflects the need of the customers for
system.
 The process of finding out ,analysis , documentation, and
checking these services and constraints is called
requirements engineering.
 Some problems that arise during the requirements
engineering process are a result of failing to make a clear
separations.
User requirements.
System requirements.

User requirements
 Are the statements in natural language and diagrams, of what
services the system is expected to provide and the
constraints under which it must operate.
System requirements
 It sets the systems, functions, services and operational
constraints in detail.
 The system requirements document(functional specifications)
should be precise.
 It defines what exactly to be implemented.
 It may be a contract b/w system buyer and s/w developer.

Functional and non-functional requirements
s/w system requirements are often classified as
Functional requirements
 These are statements of services the system should
provide, how the system should react to particular inputs
and how the system should behave in particular situations.
Non functional requirements
 These are constraints on the services or functions
offered by the system.
 They include timing constraints, constraints on the
development process and standards.

Domain Requirements:
 These are requirements that come from the application
domain of the system and that reflect characteristics and
constraints of that domain.

Functional requirements
 The functional requirements for a system describe what
the system should do.
 The functional system requirements describe the system
functional in details.
 Eg: Libsys, used by students and faculty to order books
and documents from other library.
1.The system shall provide appropriate viewers fro the user
to read doc in the doc store.
2.Every order shall be allocated a unique identifier (order_id).

 The functional user requirements define specific facilities
to be provided by the system.
 These will be taken from the user requirement documents.
Eg: it allows users to download copies of published articles in
magazines, newspapers and scientific journals.
The functional requirements specification of a system should
be complete and consistent
 Completeness: services required by the user should be
defined.
 Consistency: requirement should not have contradictory
definitions.

Non Functional Requirements
 These requirements are not directly concerned with the
specific functions delivered by the system.
 They specifies system performance, security, availability,
etc called as emergent properties of the system.
 Failing to meet non functional requirements can mean that
the whole system is unusable.
 These requirements arise through user needs, budget
constrains, organizational policies, need for
interoperability, safety regulations, privacy etc.

Classification of non functional requirements

Product requirements
 Specifies product behavior
 E.g.: how fast the system must execute, memory required etc
Organizational requirements
 Derives from policies and procedures in the customers and
developers organization
 E.g.: includes process standards, designed model used,
documentation etc.
External requirement
 Which are derived from factors external to the system and its
development process.
 E.g.: security, privacy, standards etc

Domain Requirements
 Domain requirements are derived from the application domain.
 These requirements are important because they reflect fundamentals of
application domain.
E.g:
 the domain requirement below is included in the requirements specification
for an automated train protection system.
 This system automatically stops a train if it goes through a red signal.
 This requirement states how the train deceleration is computed by the
system.
 It uses domain-specific terminology. To understand it, you need some
understanding of the operation of railway systems and train characteristics.
 The deceleration of the train shall be computed as:
D (train) = D (control) + D (gradient)
D (gradient) is 9.81ms2 * compensated gradient/alpha and
the values of 9.81ms2 /alpha are known for different types of train.

User Requirements
 The user requirements for a system should describe the
functional and non functional requirements so they are
understandable by system users.
 When writing user requirements one should not use
software jargon, structural ,formal notations etc.
 User requirements should be in simple language, with
simple tables and diagrams.

Various problems can arise when requirements are written in
natural language sentences in a text document.
 Lack of clarity
 Requirements confusion
 Requirements amalgamation
It is a good practice to separate user requirements from more
detailed system requirements in a requirement document.
otherwise non technical readers may be overwhelmed by
details.

Guidelines to write user requirements
 Invent a standard format and ensure that all requirements
in a that format.
 Use language consistently. we have to differentiate both
mandatory and desirable requirements.
 Use text highlighters to pick out key part of the
requirements.
 Avoid computer jargon or technical terms.

System Requirements
 System requirements are expanded version of user
requirements.
 They explain how user requirements should be provide
by the system.
 System requirements should simply describe the external
behavior of the system and its operational constraints.
 System requirements are more detailed than user
requirements, natural language specification can be
confusing and hard to understand.

Requirements can be specified in the following
ways.

Finally the system requirements should give precise out put
to the developer in an unambiguous way.

Structured Language Specification
 Structured natural language is a way of writing system
requirement where the freedom of the requirements writer
is limited.
 The advantage of this approach is that it maintains most of
the expressiveness and understandability of natural
language.
 This notations limit the terminology that can be used and
use templates to specify system requirements.
 We can also use form based approach to specify system
requirements.

 Formatted specifications removes some of the
problems of natural language specifications.
 It is difficult to write requirements for complex system
even in formatted forms.
 To address this problem, we can add extra
information such as graphical models of the system.
 Graphical models are most useful when we need to
show the change in states as below.

Interface Specification
 All software systems must operate with existing system that
have been implemented and installed in an environment.
 If a new system and the existing system must work
together, the interfaces of existing system have to be
precisely specified.
Types of interface
Procedural interfaces
Data structures
Representations of data

The Software Requirements Document
 The software requirements document or software
requirements specification (SRS) is the official
statement of what the system developers should
implement.
 It should include both the user requirements for a
system and a detailed specification of the system
requirements

1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements
3.1 functional requirements
3.2 non-functional requirements
3.3 interface requirements
4. Appendices
5. Index

Introduction
The goal of the requirements engineering process is to
create and maintain a system requirements document.
The overall process includes four high-level requirements
engineering sub-processes.
Feasibility Study: These are concerned with
assessing whether the system is useful to the
business.
Elicitation and Analysis: discovering requirements.
Specification: converting these requirements into
some standard form.
Validation: checking that the requirements actually
define the system that the customer wants.

Feasibility study
 For all new systems, the requirements engineering
process should start with a feasibility study.
 The input to the feasibility study is a set of preliminary
business requirements, an outline description of the
system and how the system is intended to support
business processes.
 The results of the feasibility study should be a report
that recommends WHETHER OR NOT IT IS WORTH
CARRYING on with the requirements engineering and
system development process.

A feasibility study is a short, focused study that aims to
answer a number of questions:
Does the system contribute to the overall objectives
of the organization?
Can the system be implemented using current
technology and within given cost and schedule
constraints?
Can the system be integrated with other systems
which are already in place?

Requirements Elicitation and Analysis
In Requirements Elicitation and Analysis, the software
engineers work with customers and system end-users
to find out:
About the application domain.
What services the system should provide.
The required performance of the system.
Hardware constraints

Difficulties in Elicitation
 Stakeholders often don't know what they want from
the computer system except in the most general
terms.
 Stakeholders naturally express requirements in their
own terms and with implicit knowledge of their own
work. Requirements engineers, without experience in
the customer's domain, must understand these
requirements.
 Different stakeholders have different requirements,
which they may express in different ways.

 Political factors may influence the requirements of the
system.
 The economic and business environment in which the
analysis takes place is dynamic

The requirements elicitation and analysis
process

Requirements discovery:
 This is the process of interacting with stakeholders in
the system to collect their requirements.
 Domain requirements from stakeholders and
documentation are also discovered during this activity.
Requirements classification and organization:
 This activity takes the unstructured collection of
requirements, groups related requirements and
organizes them into coherent clusters.

Requirements prioritization and negotiation:
 Inevitably, where multiple stakeholders are involved,
requirements will conflict.
 This activity is concerned with prioritizing
requirements, and finding and resolving requirements
conflicts through negotiation.
Requirements documentation:
 The requirements are documented and input into the
next round of the spiral.
 Formal or informal requirements documents may be
produced.

Requirements discovery
 Requirements discovery is the process of gathering
information about the proposed and existing systems
and distilling the user and system requirements from
this information.
 Sources of information during the requirements
discovery phase include documentation, system
stakeholders and specifications of similar systems.

Techniques of Requirements Discovery:
Interviewing
Scenarios
View point
Use cases
Ethnography

Interviewing
 Formal or informal interviews with system
stakeholders are part of most requirements
engineering processes.
 In these interviews, the requirements engineering
team puts questions to stakeholders about the system
that they use and the system to be developed.
 Requirements are derived from the answers to these
questions.

Interviews may be of two types:
Closed interviews:
where the stakeholder answers a predefined set of
questions.
Open interviews:
where there is no predefined agenda. The
requirements engineering team explores a range of
issues with system stakeholders and hence
develops a better understanding of their needs.

Characteristics of Interviewers
 They are open-minded, avoid preconceived ideas
about the requirements and are willing to listen to
stakeholders. If the stakeholder comes up with
surprising requirements, they are willing to change
their mind about the system.
 They prompt to start discussions with a question, a
requirements proposal or by suggesting working
together on a prototype system.

It is hard to elicit domain knowledge during
interviews for 2 reasons
 All application specialists use jargon that is specific to
a domain. It is impossible for them to discuss domain
requirements without using this terminology. They
normally use terminology in a precise and subtle way
that is easy for requirements engineers to
misunderstand.
 Some domain knowledge is so familiar to
stakeholders that they either find it difficult to explain
or they think it is so fundamental that it isn't worth
mentioning.

Scenarios
 People usually find it easier to relate to real-life
examples than to abstract descriptions.
 They can understand and critique a scenario of how
they might interact with a software system,
Requirements engineers can use the information
gained from this discussion to formulate the actual
system requirements.
 Each scenario covers one or more possible
interactions. The scenario starts with an outline of the
interaction, and, during elicitation, details are added to
create a complete description of that interaction.

View points
 The requirements sources (stakeholders, domain,
systems) can all be represented as system viewpoints,
where each viewpoint presents a sub-set of the
requirements for the system.
 Each viewpoint provides a fresh perspective on the
system.
Viewpoints can be used as a way of classifying
stakeholders and other sources of requirements.
 Interactor viewpoints
 Indirect viewpoints
 Domain viewpoints

 Interactor viewpoints: represent people or other
systems that interact directly with the system.
 Indirect viewpoints: represent stakeholders
who do not use the system themselves but who
influence the requirements in some way.
 Domain viewpoints: represent domain
characteristics and constraints that influence the
system requirements.

Use cases
 Use-cases are a scenario-based technique for
requirements elicitation.
 A use-case identifies the type of interaction and
the actors involved.

Ethnography
 It is an observational technique that can be used to
understand social and organizational requirements.
 Analyst immerse the day work and note them self in
the working environment where the system will be
used.
 We have to observe day to day work and notes made
of actual tasks in which participants are involved.
 People find it difficult to articulate second nature for
them.

 They understand their own work but may not
understand its relationship with their organization.
 Social and organizational factors that affect the work
but that are obvious to individuals may only become
clear when noticed by an unbiased observer.

Ethnography is particularly effective at
discovering two types of requirements:
Requirements that are derived from the way in
which people actually work.
Requirements that are derived from cooperation
and awareness of other people's activities.

Requirement validation
 Requirements validation is concerned with showing
that the requirements actually define the system that
the customer wants.
 Requirements validation is important because errors
in a requirements document can lead to extensive
rework costs when they are discovered during
development or after the system is in service.
 The cost of fixing a requirements problem by making
a system change is much greater than repairing
design or coding errors.

The requirements validation process performs various
checks include:
Validity checks
Consistency checks
Completeness checks
Realism checks
Verifiability checks

Requirements validation techniques
 Requirements reviews: The requirements are
analyzed systematically by a team of reviewers.
 Prototyping: In this approach to validation, an
executable model of the system is demonstrated to
end-users and customers. They can experiment with
this model to see if it meets their real needs.
 Test-case generation: Requirements should be
testable. If the tests for the requirements are devised
as part of the validation process, this often reveals
requirements problems.

Requirements reviews
 A requirements review is a manual process that
involves people from both client and contractor
organizations.
 They check the requirements document for anomalies
and omissions.
 Requirements reviews can be informal or formal.

Reviewers may check for
 Verifiability: Is the requirement as stated realistically
testable?
 Comprehensibility: Do the procurers or end-users of
the system properly understand the requirement?
 Traceability: Is the origin of the requirement clearly
stated? You may have to go back to the source of the
requirement to assess the impact of a change.
Traceability is important as it allows the impact of
change on the rest of the system to be assessed.
 Adaptability: Is the requirement adaptable? That is,
can the requirement be changed without large-scale
effects on other system requirements?

Requirements management
 The requirements for large software systems are always
changing.
 Requirements management is the process of
understanding and controlling changes to system
requirements.
 You need to keep track of individual requirements and
maintain links between dependent requirements so that
you can assess the impact of requirements changes.
 You need to establish a formal process for making
change proposals and linking these to system
requirements.

Enduring & Volatile requirements
Requirements evolution during the RE process and after
a system has gone into service is inevitable.

From an evolution perspective, requirements fall into two
classes:
Enduring requirements: These are relatively stable
requirements that derive from the core activity of the
organization and which relate directly to the domain of the
system.
Volatile requirements: These are requirements that are
likely to change during the system development process or
after the system has been become operational

Requirements management planning
Planning is an essential stage in the requirements
management process.
During the requirements management stage, you have
to decide on:
Requirements identification :each requirement
must be uniquely identified.
A change management process :set of activities
that assess the impact and cost of changes.

Traceability policies: it define the relation between
the requirements and b/w the req’s and the system
design that should be recorded.
CASE tool support: processing of large amount of
information about the req’s

Requirement traceability
Traceability is the property of a requirements specification
that reflects the ease of finding related requirements.
There are three types of traceability information that may
be maintained:
Source traceability information links the requirements
to the stakeholders who proposed the requirements.
Requirements traceability information links dependent
requirements within the requirements document.
Design traceability information links the requirements
to the design modules where these requirements are
implemented

Requirements traceability
Req id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 D R
1.2 D R D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R

Requirement change managements
 Requirements change management should be applied
to all proposed changes to the requirements.
 The formal process for change management brings a
controlled way for changing requirements.
 There are three principal stages to a change
management process:
 Problem analysis and change specification:
 Change analysis and costing
 Change implementation

unit 2.pptx of Software engineering subject

More Related Content

Similar to unit 2.pptx of Software engineering subject

Recently uploaded

unit 2.pptx of Software engineering subject