SE LECTURES Till 9 Feb by Ruchika Pharswan

1
Conducted by Ruchika Pharswan

Department of Information Technology
@Delhi Technical University
Email: ruchikapharswanlectures@gmail.com
Lecture 1 || 02 Jan 2024
02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Brief About Me
Email : ruchikapharswanlectures@gmail.com
B.Tech (CSE) M.Tech (CSE) || Ph.D. coursework graduated
Teaching Assistant IIT Delhi, Assistant Prof. GGSIPU, TA IIHT, GF DTU
Journal, Book Chapters, Conferences papers, Reviewer, TCM
Governance of AI ,Technology Diffusion, Social Media Analysis, User Behavior
2
3
Instructions
NO entry in class after 15 mins , once class the started.
NO proxies attendance. NO back attendances will be given
@Ruchika Pharswan
If there is mass bunk, its all absent and counted individually.
CWS MTE ETE

25 25 50
Also feel free to ask any doubts in class or even after class you can drop your query in SE WhatsApp group.

4
@Ruchika Pharswan
5
Course Outline
Unit 1: Introduction
Introduction to software Engineering, Software characteristics, Software components, Software

applications, Software Engineering Principles, Software metrics and measurement, monitoring and
control.
Software development life-cycle, Water fall model, prototyping model, Incremental model, Iterative
enhancement Model, Spiral model.
Unit 2: Software Requirement Specification

Software Requirement Specification: Requirements Elicitation Techniques, Requirements analysis,
Models for Requirements analysis, requirements specification, requirements validation.

6
Course Outline
Unit 3: System Design
Design Principles: Problem partitioning, abstraction. Top down and bottom up – design, structured
approach. Functional versus object oriented approach of design, design specification, Cohesiveness
and Coupling.
Overview of SA/SD Methodology, structured analysis, data flow diagrams, extending DFD to structure
chart.
Unit 4: Software Project management

Project planning and Project scheduling. Software Metrics: Size Metrics like LOC, Token Count,
Function Count. Cost estimation using models like COCOMO. Risk management activities.

7
Course Outline
Software Reliability and Quality Assurance: Reliability issues, Reliability metrics, reliability models,
Software quality, ISO 9000 certification for software industry, SEI capability maturity model.
Unit 5: Testing
Verification and validation, code inspection, test plan, test case specification. Level of testing: Unit,
Integration Testing, Top down and bottom up integration testing, Alpha and Beta testing, System
testing and debugging. functional testing, structural testing, Software testing strategies.
Unit 6: Software Maintenance

Structured Vs unstructured maintenance, Maintenance Models, Configuration Management,
Reverse Engineering, Software Re-engineering.

8
IT:304 UNIT 1 Part 1
Sources: Textbook, internet, Research papers, SELF
Introduction to software Engineering

@Ruchika Pharswan
9
Software Crisis
Demand Complexity Challenges

increases increases Increases These S/W were unreliable, cost
more than expected, and were
delivered late, maintenance was
high, software harder to change,
Software Crisis s/w did not meet user
requirements.
Same Same Same

Workforce Procedures Tools

10
Software Engineering
Software Crisis
It became clear that individual approaches to program development did not scale up to large and
complex software systems.
Then the notion of “software engineering” was proposed.
Throughout the 1970s and 1980s, a variety of new software engineering techniques and methods
were developed, such as structured programming, information hiding and object-oriented
development. Tools and standard notations were developed and are now extensively used.
IEEE defines software engineering as: The application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance of software.

11
Introduction: Software Engineering(SE)
 What is software Engineering ?
Software
+ Engineering
Developing products, using well-defined,
scientific principles and methods.
Software engineering is an engineering branch associated with the

Collection of program development of software product using well-defined scientific principles,
Data structures methods and procedures. The outcome of software engineering is an
Documentation efficient and reliable software product.

Need of Software Engineering
 To manage Large software Step by Step follow the procedure
 Quality Management Various Quality assurance Tests and Certifications
 Reduces complexity Abstraction and Decomposition
 minimize software cost Various cost estimation models
 Handle big projects SDLC
 Reliable software Reliability models and metrics , testing, maintenance models
 Effectiveness Good Standard s/w are developed: capability maturity model

12
13
Software Characteristics
In software engineering
What are characteristics of Software?
Software is developed or engineered. It is not manufactured in the classical sense. The cost of
developing software lies almost completely in the engineering of the software, and not in the
“manufacturing” of a “product” that customers can behold in their hands.
@Ruchika Pharswan
Unlike Hardware, Software does not ―wear out. However, this does not mean that software does not
degrade over time. A software program is continuously changed over its lifetime. If these changes
occur too frequently, the bugs introduced by each change may slowly degrade the performance
and utility of the software as a whole. Obsolete
Unlike hardware, most software remains custom built, rather than built using “off the shelf”
components.

14
Hardware Failure
Rate over time
Vs.
Software Failure
Rate over time

The General characteristics of the software include:
15
Non- Perishable
Intangible
Not easy to modify ( large s/w)
Easy to Replicate
Highly dependend on User’s
Requirements
Complex/ submodules/
various features
Required proper testing /

debugging for quality assurance.
@Ruchika Pharswan
According to the ISO/IEC 9126 standards Software characteristics are classified into
six major components:
16
Functionality Reliability
Efficiency
Usability
S/W
Characteristics
Portability Robustness
Maintainability Integrity

It refers to the degree of performance of the software against its
intended purpose. It basically means , the required functions.
Functionality 17
a) Suitability: according to the requirement of the client
b) Accuracy: Should be able to give correct outputs.
c) Interoperability: working should be not dependent on the
environment used to develop one.
d) Compliance: As per the industry standards
e) Security: not be accessed by unauthorized people or bugs or virus.
A set of attribute that Bear on the capability of software to maintain its level of
performances understated conditions for a stated period of time.
a) Fault tolerance: The dynamic errors should be handled by the software itself.
Reliability
b) Recoverability: In case of sudden stopping or interrupts the software should
come back to previous state in no time
c) Maturity: Should work for a long time with same efficiency and generate a
reliable client base and market.

It refers to the ability of the software to use System resources in
the most Effective and Efficient Manner.
Efficiency 18
a) In-time: said to be efficient when it generates the output on
time, or in lesser time.
b) In-Resources: The required resources as hardware requirements (RAM,
Cache speed ) should be less so that cost for operating should be less.
It refers to the extent to which the software can be used with ease. Or the
amount of effort or time required to learn how to use the software should be
less.
Usability a) Understandability: Should be easy to understand by the user who is naïve

and non technical.
b) Learnability: The user should be able to learn to operate on the software.
c) Operability: The working should be easy and processing data also should be
user friendly.

It refers to the degree to which the software can keep on
Robustness functioning in spite of being provided with invalid data. 19
Refers to the ease with which the modifications can be made in a software
system to extend its functionality, improvement, performance or correct errors
Maintainability a) Testability: should be tested in advance or with real time data so that while
Or working with real environment there should be no error.
Flexibility b) Stability: should be giving the output and results while handling the abrupt
exceptions and errors on execution.
c) Changeability: It should be able to change according to the new and
upgraded system requirements and other environments.
d) Analyzability: The software should have the property of getting analyzed
by the new team of developers so that the upgradation can become
easy.

Portability refers to the ability to use software in different
environments. This is the ease with which software can be ported
from one platform to another without (or with minimal) changes,
20
while obtaining similar results.
Portability
a) Adaptability: software should change the working according to the new
environment (operating system and other supporting system software).
b) Installability: software should be able to be installed to different machines
while moving it to client side environment.
c) Replacebility: It should have the property to get replaced with a upgraded
one when gets out dated or when not in demand.
Integrity is key for demonstrating the safety, security, and maintainability of

your software. In addition, software that needs to be compliant with industry
Integrity regulations and coding standards requires high code integrity. High integrity
means that the software cannot be modified without authorization. It refers to
the degree to which Unauthorized Access to the software data can be
prevented.

21
Good Software ?

Broader Categories ?
22

23
Software components
Program: Program is a combination of source code & object

code.
PROGRAMS Documentation
Documentation : it is consists of different types of manuals.
Examples of documentation manuals are: Data Flow Diagram,
Flow Charts, ER diagrams, etc.
Operating Procedures: Operating Procedures consist of

Operating instructions to set up and use the software system and
Procedures instructions on how react to the system failure. Example of
operating system procedures manuals is: installation guide,
SOFTWARE Beginner's guide, reference guide, system administration
guide, etc.

24
Software products
Generic products / off the shelf

These are stand-alone systems that are produced by a development organization and sold on the
open market to any customer
Examples of this type of product include software for PCs such as databases, word processors, drawing
packages, and project-management tools. It also includes so-called vertical applications designed for
some specific purpose such as library information systems, accounting systems, or systems for
maintaining dental records.
Customized products
These are systems that are customized for a particular customer. A software contractor develops the
software especially for that customer. Examples of this type of software include control systems for
electronic devices, systems written to support a particular business process, and air traffic control
systems.

25
Product Characteristics
Software vs product ?

26
Fundamentals/Principles of SE
 S/W should be developed using a managed and understood development process. The organization developing
the software should plan the development process and have clear ideas of what will be produced and when it will
be completed. Of course, different processes are used for different types of software.
 Dependability and performance are important for all types of systems. Software should behave as expected,
without failures and should be available for use when it is required. It should be safe in its operation and, as far as
possible, should be secure against external attack. The system should perform efficiently and should not waste
resources.
 Understanding and managing the software specification and requirements (what the software should do) are
important. You have to know what different customers and users of the system expect from it and you have to
manage their expectations so that a useful system can be delivered within budget and to schedule.
 You should make as effective use as possible of existing resources. This means that, where appropriate, you
should reuse software that has already been developed rather than write new software.

27
Application
System software:
System software is a collection of programs written to service other programs. The systems software is
characterized by heavy interaction with computer hardware heavy usage by multiple users concurrent
operation that requires scheduling, resource sharing, and sophisticated process management complex
data structures multiple external interfaces E.g. compilers, editors and file management utilities.
Application software:
Application software consists of standalone programs that solve a specific business need. It facilitates
business operations or management/technical decision making. It is used to control business functions in
real-time E.g. point-of-sale transaction processing, real-time manufacturing process control.
Engineering/Scientific software:
Engineering and scientific applications range -from astronomy to volcanology - from automotive stress
analysis to space shuttle orbital dynamics - from molecular biology to automated manufacturing E.g.
computer aided design, system simulation and other interactive applications.

28
Application
Embedded software:
Embedded software resides within a product or system and is used to implement and control features
and functions for the end-user and for the system itself. It can perform limited and esoteric functions or
provide significant function and control capability, Digital functions in automobile, dashboard displays,
braking systems etc.
Product-line software:
Designed to provide a specific capability for use by many different customers, product-line software
can focus on a limited and esoteric market place or address mass consumer markets E.g. Word
processing, spreadsheets, computer graphics, multimedia, entertainment, database management,
personal and business financial applications.
Web-applications: Web Apps are evolving into sophisticated computing environments that not only
provide standalone features, computing functions, and content to the end user, but also are integrated
with corporate databases and business applications.

29
Application
Artificial intelligence software:
AI software makes use of non numerical algorithms to solve complex problems that are not
amenable to computation or straightforward analysis. Application within this area includes robotics,
expert systems, pattern recognition, artificial neural networks, theorem proving, and game playing.

Guess the type of Software EMBEDDED software
30
WEB – BASED software

APPLICATION
software
AI based software
SYSTEM software
PRODUCT LINE SCIENTIFIC software

software
31
IT:304 UNIT 1 Part 2

Software Development Life Cycle (SDLC)

32
Software Development Life Cycle
(SDLC)
Code and Fix
The “code-and-fix” approach to software development is
Programmer think not a proper life cycle.
requirements are
understood Code-and-fix development occurs when software
engineers come together with a vague set of
requirements and start producing software, fixing it, and
changing it until the correct product appears.
Code part of the system
o There is no way to estimate time-scales or budgets.
o There is no assessment of possible risks and design
flaws.
o exceeded budgets
Fix the error , if occurs ,
o a system that works but is difficult to use
enhance if required

33
SDLC
Recognizing these problems, work was carried out to understand the process of software
development and to transform it into a reliable and robust system.
improved process should produce software that is correct, reliable, usable and maintainable. By
understanding the process, it should be possible to plan projects with more accurate predictions of
cost and time, and provide ways of monitoring intermediate stages of project progress, to be able
to react and re-plan if a project begins to go off budget or timescale.
The software process is the process of engineering and developing software; a process model, or life
cycle model is a descriptive model giving the best practices for carrying out software development

SE layers 34
Software engineering demands a focus on quality.
The process is the framework on which the rest of software

engineering is built. The process defines how management
occurs, what the required input and output products are, what
milestones should be reached, and so on. The process also
describes how quality should be ensured.
Methods describe how the various portions that make up the

software process should be carried out. For instance, how to
communicate with clients, how to test the software, to gather
requirements, and so on.
And above all of this, and in support of the whole discipline, are the tools. The tools support the
software process. Such tools are called computer-aided software engineering tools.

SDLC: Waterfall Model This model is also known as the
“traditional” or “typical” software life 35
cycle.
Each stage, when completed, results in a

deliverable (also called a product).
The input to any particular stage are the

deliverables from the previous stage.
The model presents the stages in a strict, one-

way sequence — a project cannot go back to
repeat a stage once that stage has been
completed.
Any required re-work (as a result, for example, of changing software requirements) is very limited.

36
Stages of Waterfall
1. Requirements analysis and definition : The system’s services, constraints, and goals are established by
consultation with system users. They are then defined in detail and serve as a system specification.
Software Requirement Specification (SRS) : contained a detailed description of what the system
will do in the common language.
2. System and software design : The systems design process allocates the requirements to either
hardware or software systems. It establishes an overall system architecture. Software design involves
identifying and describing the fundamental software system abstractions and their relationships.
Software Design Document (SDD) : It defines the overall software architecture together with
high level and detailed design

37
Stages of Waterfall
3. Implementation and unit testing During this stage: the software design is realized as a set of programs
or program units. Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing: The individual program units or programs are integrated and tested
as a complete system to ensure that the software requirements have been met. in this phase, the
modules are tested for their interactions with each other and with the system.
5. Operation and maintenance The system is installed and put into practical use. Maintenance involves
correcting errors that were not discovered in earlier stages of the life cycle, improving the
implementation of system units, and enhancing the system’s services as new requirements are
discovered.

38
Pros & Cons
• risk factor is higher
• simple to implement • Not suitable for large
When to use SDLC Waterfall • Minimal no. of resources and complex project
Model? • Simple requirement , no • cannot accept the
change , no turbulence changes, once starts
 When the requirements are • start and end points for development.
constant and not changed each phase is fixed, which • No back track
regularly. makes it easy to cover
 A project is short progress
 Where the tools and technology • Cost and release date of
used is consistent and is not product can be
changing determined before
development
 When resources are well
cons
prepared and are available to
use. PROS
• easy to control

39
Prototyping Model
for e.g. early

access on google Basic idea : Prototype is built, tested, and
play
reworked until an acceptable prototype is
achieved. It is an iterative, trial and error
method which takes place between
developer and client.
Best to Use when:
The project’s requirements are not known in

detail. It can also be used if requirements are
changing quickly.

40
Stages of Prototype Model
Step 1: Initial Requirements (Requirements gathering and analysis)

A prototyping model starts with requirement analysis. In this phase, the requirements of the system are defined
in detail. During the process, the users of the system are interviewed to know what is their expectation from the
system.
Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage, a simple design of the system is
created. However, it is not a complete design. It gives a brief idea of the system to the user. The quick design
helps in developing the prototype.
Step 3: Build a Prototype

In this phase, an actual prototype is designed based on the information gathered from quick design. It is a small
working model of the required system.

Stages of Prototype Model 41
Step 4: Initial user evaluation (Assessment or User Evaluation)

In this stage, the proposed system is presented to the client for an initial evaluation. It helps to find out the
strength and weakness of the working model. Comment and suggestion are collected from the customer and
provided to the developer.
Step 5: Refining prototype
If the user is not happy with the current prototype, you need to refine the prototype according to the user’s
feedback and suggestions. This phase will not over until all the requirements specified by the user are met.
Once the user is satisfied with the developed prototype, a final system is developed based on the approved
final prototype.
Step 6: Implement Product and Maintain
Once the final system is developed based on the final prototype, it is thoroughly tested and deployed to
production. The system undergoes routine maintenance for minimizing downtime and prevent large-scale
failures.

42
Types of Prototype model
1. Throwaway Prototyping
Also called rapid or close ended prototyping.
Once the actual requirements are understood, the prototype is discarded.
2. Evolutionary Prototyping
Also called as breadboard prototyping .
Actual functional prototypes with minimal functionality in the beginning.
The prototype developed from the heart of the future prototypes on top of which the
entire system is built.
3. Incremental Prototyping
Build multiple functional prototypes of the various sub-systems and then integrating all the
available prototypes to form a complete system.

43
Pros & Cons
• Reduce the risk of incorrect user • An unstable/badly implemented
requirement prototype often becomes the final
• Good where requirement are product.
changing/uncommitted • Require extensive customer collaboration
• Regular visible process aids management • Difficult to finish if customer withdraw.
• Support early product marketing • May be too customer specific, no broad
• Reduce Maintenance cost. market
• Errors can be detected much earlier • Difficult to know how long the project will
• Low risk Factor last.
• Encourages innovation and flexible • Prototyping tools are expensive.
designing. • Slow and time consuming
• Customer satisfaction exists because the
customer can feel the product at a very
early stage.
CONS.
PROS.
Incremental Model 44
Incremental Model is a process of software
development where requirements divided into
multiple standalone modules of the software
development cycle.
In this model, each module goes through the

requirements, design, implementation and
testing phases.
Every subsequent release of the module adds

function to the previous release. The process
continues until the complete system achieved.
11

45
Stages of incremental model
1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies
the requirements. And the system functional requirements are understood by the requirement analysis team.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system
functionality and the development method are finished with success. When software develops new
practicality, the incremental model uses style and development phase.
3. Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to test
the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the development system.
After completion of this phase, the number of the product working is enhanced and upgraded up to
the final system product

46
Pros and Cons
When we use the Incremental • Lower initial cost delivery • Module should be clearly
Model? • NO one time cost defined
•When full Requirements are not • Identify error easily • Total cost is higher than
known in the beginning. • Manage risk easily waterfall model .
•When Projects have lengthy • High priority functionality can • Need complete
development schedules. be delivered first understanding of the entire
• Error can be find in early stage system.
•When the customer demands a
.
quick release of the product.
• Customer feedback will help
•You can develop prioritized in early stage
requirements first. • Flexible CONS.
•Error Reduction. PROS.
•Team is not highly skilled.
•All Resources are not available.

47
Spiral model
Spiral model is one of the most important Software Development

Life Cycle models, which provides support for Risk Handling. In
its diagrammatic representation, it looks like a spiral with many
loops.
The exact number of loops of the spiral is unknown and can

vary from project to project. Each loop of the spiral is called
a Phase of the software development process.
The Radius of the spiral at any point represents the

expenses(cost) of the project so far, and the angular
dimension represents the progress made so far in the current
phase.

48
Phases of Spiral model
Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The functions of these
four quadrants are discussed below-
1.Objectives determination and identify alternative solutions: Requirements are gathered from the customers
and the objectives are identified, elaborated, and analyzed at the start of every phase. Then alternative solutions
possible for the phase are proposed in this quadrant.
2.Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the
best possible solution. Then the risks associated with that solution are identified and the risks are resolved using
the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution.
3.Develop next version of the Product: During the third quadrant, the identified features are developed and
verified through testing. At the end of the third quadrant, the next version of the software is available.
4.Review and plan for the next Phase: In the fourth quadrant, the Customer’s evaluate the so far developed
version of the software. In the end, planning for the next phase is started.

49
Pros and Cons
Advantages of Spiral Model:

Below are some advantages of the Spiral Model.
1.Risk Handling: The projects with many unknown risks that occur as the development proceeds, in that case,
Spiral Model is the best development model to follow due to the risk analysis and risk handling at every phase.
2.Good for large projects: It is recommended to use the Spiral Model in large and complex projects.
3.Flexibility in Requirements: Change requests in the Requirements at later phase can be incorporated
accurately by using this model.
4.Customer Satisfaction: Customer can see the development of the product at the early phase of the
software development and thus, they habituated with the system by using it before completion of the total
product.

50
Pros and Cons
Disadvantages of Spiral Model:

Below are some main disadvantages of the spiral model.
Complex: The Spiral Model is much more complex than other SDLC models.
Expensive: Spiral Model is not suitable for small projects as it is expensive.
Too much dependability on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced experts, it is going to be a failure to
develop a project using this model.
Difficulty in time management: As the number of phases is unknown at the start of the project, so
time estimation is very difficult.

51
TRY IT Development of COBOL programming language – > waterfall model
Requirements Phase:
•Description: COBOL was designed in the late 1950s by a committee led by Grace Hopper to create a
language for business data processing.
•Example: Define the requirements for a programming language that would be easily understood by
business professionals, support data processing, and be portable across different computer systems.
Design Phase:
• Description: Develop the language specifications, defining syntax, data structures, and processing
capabilities.
• Example: Create a detailed design document specifying how COBOL programs would be written, how data
would be handled, and how the language would support business-oriented tasks.

52
TRY IT Development of COBOL programming language – >
waterfall model
Implementation (Coding) Phase:
•Description: Write the compiler and runtime libraries based on the design specifications.
•Example: Implement the COBOL compiler and associated runtime libraries to translate COBOL programs into
machine-readable code and execute them.
Testing Phase:
•Description: Test the language and its compiler for correctness and adherence to specifications.
•Example: Perform rigorous testing to ensure that COBOL programs execute as expected, handle data
correctly, and meet the requirements of business applications.

53
TRY IT Development of COBOL programming language – >
waterfall model
Deployment Phase:
•Description: Release the COBOL language for use by businesses and computer systems.
•Example: COBOL was introduced for commercial use in the early 1960s and quickly became one of the
most widely used languages for business applications, particularly in the finance and government sectors.
Maintenance and Support Phase:
•Description: Provide ongoing maintenance and support for the COBOL language.
•Example: Over the years, updates and new versions of COBOL have been released to address changing
business needs and to ensure compatibility with evolving computing environments.

54
IT:304 UNIT 2
Software Requirement Specification

@Ruchika Pharswan

55
Software Requirement Specification
The product of the requirements stage of the software development process is Software Requirements
Specifications (SRS) (also called a requirements document).
SRS is a formal report, which acts as a representation of software that enables the customers to
review whether it (SRS) is according to their requirements. Also, it comprises user requirements for a
system as well as detailed specifications of the system requirements.
It serves several goals depending on who is writing it. First, the SRS could be written by the client of a
system. Second, the SRS could be written by a developer of the system. The two methods create
entirely various situations and establish different purposes for the document altogether.
The first case, SRS, is used to define the needs and expectation of the users. The second case, SRS, is
written for various purposes and serves as a contract document between customer and developer.
223
FebJan2023
2024 Lecture
LecturePresentation
Presentation| @Ruchika
| @RuchikaPharswan
Pharswan
Characteristics of SRS 56
Accurate requirements are stated in the SRS.

Every fixed requirement has only one interpretation.
Must be complete All essential requirements, how the software will
Address it, all the figures table and visuals must be referenced.
No subset of individual requirements described in its conflict.
All requirements are not equally important, class: essential,
optional.
Specified requirements can be verified with a cost-effective system
to check whether the final software meets those requirements.
Should be capable of quickly obtain changes to the system to
some extent. Modifications should be perfectly indexed and
cross-referenced.
facilitates the referencing of each condition in future development

Requirements Elicitation 57
"elicit" has its origin in the Latin term "elicio," which means "to draw out," "to call forth," or "to evoke"
Elicitation is the process of discovering the requirements. In particular, elicitation often refers
to engaging with stakeholders/users to understand their needs and expectations when it
comes to the scope and detailed requirements of the project.
The goal of requirements elicitation is to ensure that the software development process is
based on a clear and comprehensive understanding of the customer needs and
requirements.
Requirements elicitation involves the identification, collection, analysis, and refinement of
the requirements for a software system.
The output of the requirements elicitation process is a set of clear, concise, and well-defined
requirements that serve as the basis for the design and development of the software system.

Requirements Elicitation Stages 58
Prepare for Elicitation:
• The purpose here is to understand the elicitation activity scope, select the right
techniques, and plan for appropriate resources.
• If there’s any existing system, Collect the documentation and analyzing the current
system which makes developer to Understand the client’s business and industry, the
practices and solutions used, and the current and desired state of the organization.
• Analyze the stakeholder role : stakeholders affected by the project and decides which of
them should be involved in elicitation.
• RACI matrix (Responsible, Accountable, Consult, Inform) : To Determine which particular
stakeholder is responsible or accountable for an activity, whom consult on it, who should
be informed about changes.
• Prepares use case and process flow diagrams to discuss them with stakeholders.
• Prepare stakeholders for elicitation to make sure all participants understand the goal and
process of elicitation.
623
FebJan2023
2024 Lecture
LecturePresentation
| @RuchikaPharswan
Pharswan
59
Requirements Elicitation Stages
Conduct Elicitation:
• The purpose here is to explore and identify information related to user requirements by
conducting series of meetings with stakeholders.
• Define requirements for the development team and stakeholders.
• Manage the elicitation: (multiple stakeholders, multiple needs, make sure everyone agrees
on same).
• Discussions Document: (Document will be made, with every meeting, to record the
changes n the user requirement for future reference)
• Follow up with participants to

Requirements Elicitation Stages 60
Confirm Elicitation Results:
• In this step, the information gathered in the elicitation session is checked for accuracy.
• Once elicitation is done, go through requirements to make sure that each of these
questions is answered for each requirement:
• What? — What is the exact meaning of the requirement?

• Why? — Why should the requirement be implemented, what problem does it solve, and
what benefits does it provide?
• How? — What are the possible ways to implement the requirement and what are the
possible obstacles (outdated or insecure technologies, network limitations, etc.)?
• When? — How urgent is the requirement and when should it be prioritized and executed?

Requirements Elicitation Techniques 61
• This technique combines text and pictures to provide a better understanding of the
• Group/ Individual SHs
requirements.
• a structured/ unstructured interview.
• The use cases describe the ‘what’, of a system and not • In person/video call/via email
‘how’. Hence, they only give a functional view of the system. INTERVIEW • Before interview : stakeholder’s cultural
background.
• The components of the use case
• Around the table discussion.
design includes three major things – Use Case • Used to generate new ideas and find a
Actor, Use cases, use case diagram.
BRAINSTROM solution for a specific issue.
• Quality Function Deployment • The members  domain experts, subject
• Technique AIM: customer satisfaction is of prime matter experts.
concern. QFD • We get repository of knowledge and you
• Emphasizes on the requirements which are valuable can select from different ideas.
• Plenty of ideas in a short time.
to the customer. FAST
• Identify SHs, list of prioritize req., categorized req. :
• Facilitated Application Specification Technique.
possible to achieve, Deferred and reason,
• AIM: to bridge the expectation gap –what
impossible.
• 3 types of requirements are identified : NORMAL (for
which system is proposed)/ EXPECTED (that are
@Ruchika Pharswan developer expects & customer expects.
obvious not explicitly stated) / EXCITING req.

• Every participant list of objects that are part of the system
(beyond user expectation )
environment, produced by system, used by system.
• List : combined and remove redundancy, then finalize.
2 Feb 2024 Lecture Presentation | @Ruchika Pharswan

62
Elicitation Advantages
 Establishes the precise scope of work and the budget.

 Avoids confusion during development.
 Adds business value.
( what should be done and why, hence and meet the client needs)
 Reveals hidden and assumed requirements.
(Stakeholders (SHs) knows their market best, but developers need to basics needs as well,
which can be obvious to SHs. So, need to know each aspect of requirement).
 Allows for developing only relevant functionality.
(Ignore inefficient features)

63
Elicitation Disadvantages
• Can be time-consuming and expensive.

• Requires specialized skills and expertise.
• May be impacted by changing business needs and requirements.
• Can be impacted by conflicting priorities and competing interests.
• May result in incomplete or inaccurate requirements if not properly managed.
• Can lead to increased development costs and decreased efficiency if requirements are not well-defined.

64
Requirement analysis
Requirement analysis is significant and essential activity

after elicitation.
We analyze, refine, and scrutinize the gathered

requirements to make consistent and unambiguous
requirements.
This activity reviews all requirements and may provide a

graphical view of the entire system.
After the completion of the analysis, it is expected that the

understandability of the project may improve significantly.

Draw the context diagram: 65
The context diagram is a simple model that defines the boundaries and interfaces of the proposed
systems with the external world. It identifies the entities outside the proposed system that interact with the
system.

Development of a Prototype (optional):
66
One effective way to find out what the customer wants is to construct a prototype. We can use their
feedback to modify the prototype until the customer is satisfied continuously. Hence, the prototype helps
the client to visualize the proposed system and increase the understanding of the requirements.
Model the requirements:
This process usually consists of various graphical representations of the functions, data entities, external
entities, and the relationships between them. The graphical view may help to find incorrect, inconsistent,
missing, and superfluous requirements. Such models include the Data Flow diagram, Entity-Relationship
diagram, Data Dictionaries, State-transition diagrams, etc.
Finalize the requirements:
After modeling the requirements, we will have a better understanding of the system behavior. The
inconsistencies and ambiguities have been identified and corrected. The flow of data amongst various
modules has been analyzed. Elicitation and analyze activities have provided better insight into the system.
Now we finalize the analyzed requirements, and the next step is to document these requirements in a
prescribed format.

abstraction view,
single process with its relationship to external 67
entities
entire system as a single bubble with input and
output data
decomposed into multiple

bubbles/processes
highlight the main functions

breakdown the high-level process
of 0-level DFD into sub-processes.
goes one step deeper

used to plan or record the
specific/necessary detail about
the system’s functioning.
68
Functional requirements
Requirements, which are related to functional aspect of software fall into this category. They define functions and
functionality within and from the software system.
These are the requirements that the end user specifically demands as basic facilities that the system should offer.
All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are
represented or stated in the form of input to be given to the system, the operation performed and the output
expected. They are basically the requirements stated by the user which one can see directly in the final product.
(unlike the non-functional requirements)
Examples –
•Search option given to user to search
66Feb
Feb 2023
2024 Lecture
LecturePresentation
Presentation| |@Ruchika
@RuchikaPharswan
Pharswan
69
Non - Functional requirements
Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or
expected characteristics of software, which users make assumption of.
These are basically the quality constraints that the system must satisfy according to the project contract. The
priority or extent to which these factors are implemented varies from one project to other. They are also called
non-behavioral requirements.
Non-functional requirements include -

•Security, Logging , Storage, Configuration
•Performance , Cost, Interoperability
•Flexibility
•Disaster recovery
•Accessibility

70
Requirements
Requirements are categorized logically as:
•Must Have : Software cannot be said operational without them.

•Should have : Enhancing the functionality of software.
•Could have : Software can still properly function with these requirements.
•Wish list : These requirements do not map to any objectives of software.
While developing software, ‘Must have’ must be implemented,

‘Should have’ is a matter of debate with stakeholders and negation,
whereas ‘could have’ and ‘wish list’ can be kept for software updates.

Must-Have: 71
•Real-time Messaging:
• Users must be able to send and receive text messages in real-
time.
•Media Sharing:
• Users must be able to share images, videos, and audio
messages.
•Group Chats:
• The app must support group chats for multiple users.
•End-to-End Encryption:
• Messages must be encrypted for privacy and security.
•Cross-Platform Compatibility:
• The app must be available on multiple platforms (iOS, Android,
web) for seamless communication.

Should-Have:
72
•Voice and Video Calls:
• The app should allow users to make voice and video calls.
•Status Updates:
• Users should have the option to update and share their status.
•Read Receipts:
• The app should provide read receipts to indicate when
messages are read.
•Integration with External Apps:
• Integration with external apps (e.g., Giphy for GIFs) should be
Could-Have: considered.
•Stickers and Emojis:

• The app could include a variety of stickers and emojis for expressive communication.
•File Sharing (Documents, PDFs):
• Users could be given the option to share documents and PDF files.
•Message Editing:
• The app could allow users to edit sent messages.
•Dark Mode:
• A dark mode theme could be implemented for user preference.

Wish List:
73
•Integration with Third-Party Services:
• Integration with external services (e.g., Spotify for music
sharing) could be explored.
•Augmented Reality (AR) Features:
• Implementation of AR features for creative messaging
experiences could be considered.
•Voice Recognition:
• Integration of voice recognition for hands-free messaging could
be a long-term goal.
Features are categorized based on their priority and importance. Must-Have requirements are critical
for the core functionality of a messaging app, Should-Have features enhance the user experience,
Could-Have items add additional functionalities, and Wish List items represent innovative ideas for
future development.
This prioritization helps guide the development team in delivering the most critical features first while
providing flexibility for future enhancements.

74
Requirements Validation
After requirement specifications are developed, the requirements mentioned in this document are validated.
User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly.
This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following
conditions -
•If they can be practically implemented
•If they are valid and as per functionality and domain of software
•If there are any ambiguities
•If they are complete
86Feb
Feb 2023
2024 Lecture
LecturePresentation
Presentation| |@Ruchika
@RuchikaPharswan
Pharswan
Requirements Validation vs. Verification 75
Verification and Validation is the process of investigating whether a software system
satisfies specifications and standards and fulfills the required purpose.
Verification: Are we building the product right? Validation: Are we building the right product?
Verification activities confirm that the product
Validation confirms that the product actually
is built to the stated (documented)
meets the customer’s needs.
specifications
verification ensures the product is built right validation ensures the right product is built.
what comes first ?

76
If the software works

Verification ensures that perfectly but does not
the best practices in the address the customer’s
industry are used to needs, the customer will
create and test the not be satisfied and the
software cost and effort to produce
that software may have
6 Feb 2024 Lecture Presentation | @Ruchika Pharswan been wasted.
Verification is simply known as Static Testing.
Validation is simply known as Dynamic Testing. 77
@Ruchika Pharswan
Quality control

78
Feasibility study Is It feasible to develop the software with given
constraints?
When the client approaches the organization for getting the desired product developed, it comes up with
rough idea about what all functions the software must perform and which all features are expected from the
software. Referencing to this information, the analysts does a detailed study about whether the desired system
and its functionality are feasible to develop.
This study analyzes whether the software product can be practically materialized in terms of implementation,
contribution of project to organization, cost constraints and as per values and objectives of the organization. It
explores technical aspects of the project and product such as usability, maintainability, productivity and
integration ability.
The Output of this phase should be a feasibility study report that should contain adequate comments and
recommendations for management about whether or not the project should be undertaken.
89Feb
Feb2023
2024 Lecture
LecturePresentation
| @RuchikaPharswan
Pharswan
Types of feasibility study 79
Technical Feasibility - Is It technically feasible to develop the software with given constraints?
In Technical Feasibility current resources both hardware software along with required technology are
analyzed/assessed to develop project. This technical feasibility study gives report whether there exists
correct required resources and technologies which will be used for project development. Along with
this, feasibility study also analyzes technical skills and capabilities of technical team, existing
technology can be used or not, maintenance and up-gradation is easy or not for chosen technology
etc.
Schedule Feasibility - Is It feasible to develop the software with given schedule constraints?
In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project which
includes how much time teams will take to complete final project which has a great impact on the
organization as purpose of project may fail if it can’t be completed on time.
209 Feb 2023

Feb 2024 Lecture
LecturePresentation
| @RuchikaPharswan
Pharswan
80
Types of feasibility study
Operational Feasibility – Can we deliver an operational product?
In Operational Feasibility degree of providing service to requirements is analyzed along with how much
easy product will be to operate and maintenance after deployment. Along with this other operational
scopes are determining usability of product, Determining suggested solution by software development
team is acceptable or not etc.

81
UNIT 3
IT:304 Part 1
SYSTEM DESIGN
@Ruchika Pharswan
82
System Design
System design is a critical component of software engineering and involves making decisions about the
architecture, components, modules, interfaces, and data for a software system. Software design is a
mechanism to transform user requirements into some suitable form, which helps the programmer in
software coding and implementation.
A good system design is to organize the program modules in such a way that are easy to develop and
change. Structured design techniques help developers to deal with the size and complexity of programs.
Need / Importance
The choice of system design strategy will depend on the particular requirements of the software system,
the size and complexity of the system, and the development methodology being used. A well-designed
system can simplify the development process, improve the quality of the software, and make the
software easier to maintain.

Design Principles 83
Goal: divide Pros: Benefits Software is easy to understand,

Divide the
the problem simple, easy to test, modify, maintain, and
problems
into expand
and conquer
manageable
the problem Cons: These pieces cannot be entirely
pieces. independent cooperate and communicate
to solve the problem adds complexity.
Type:
Considering a Functional ( method /task) details of the algorithm to

component at an accomplish the functions are not visible to the users. Function
abstract level without oriented design approaches.
bothering about the
internal details of the Data Abstraction: data elements are not visible to the users.
implementation. Object Oriented design approaches.
209 Feb 2023

Feb 2024 Lecture
LecturePresentation
| @RuchikaPharswan
Pharswan
Design Principles 84
Divide the software into separate The desirable properties of a modular system are:
modules which are differently •Each module  well-defined
named and addressed and are •Each module  single specified objectives.
integrated later on in to obtain the •Modules  separately compiled, saved in the library.
completely functional software. •Modules should be easier to use than to build.
•Modules are simpler from outside than inside.
Modular Design:  Functional Independence & Information hiding
Functional independence is achieved by developing functions that perform only one kind of task and do not
excessively interact with other modules. Independence is important because it makes implementation more
accessible and faster. Coupling (interdependence among modules) and cohesion (strength of a module).
Information hiding : modules should be specified that data include within a module is inaccessible to
other modules that do not need for such information.

85
Design Principles
Top-down Approach: This approach starts with the identification of the main
components and then decomposing them into their more detailed sub-
components.
Bottom-up Approach: A bottom-up approach begins with the lower details and
moves towards up the hierarchy. This approach is suitable in case of an existing
system.
Structured design fundamentally refers to breaking down problems into multiple well-organized
elements. The advantage of using this kind of design strategy is that it allows the problems to become
simpler. This enables problem-solving of the smaller elements so that they can fit into the bigger
picture. The solution modules are structured in a hierarchical order and a manner that there is less
cohesion between the modules.

86
Design Principles
The function-oriented design strategy is similar to structured design but instead divides the entire system
into subsystems referred to as functions. The system is considered to be a map or top-view of all the
combined functions. However, there is more information passing between the functions as compared
to structured design while the smaller functions promote abstraction. The function-oriented design also
allows the program to operate on input rather than on state.
Object-oriented Design : This design approach is completely different from the other two and focuses on
objects and classes. This kind of strategy revolves around the objects inside the system and their characteristics.
Further, the characteristics of the attributes of all these objects are encapsulated together and then the data
involved is restricted so that polymorphism can be enabled. The object-oriented design is based on identifying
objects and grouping them into classes based on their attributes. Then, the class hierarchy is determined and the
relationship between these classes is defined.
identifying objects grouping them in classes determining class hierarchy defining relationship

87
Cohesion and coupling
Cohesion Coupling

88
Types of coupling

89
Types of cohesion

SE LECTURES Till 9 Feb by Ruchika Pharswan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE LECTURES Till 9 Feb by Ruchika Pharswan

Uploaded by

Copyright:

Available Formats

1

Conducted by Ruchika Pharswan

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

B.Tech (CSE) M.Tech (CSE) || Ph.D. coursework graduated

Teaching Assistant IIT Delhi, Assistant Prof. GGSIPU, TA IIHT, GF DTU

Journal, Book Chapters, Conferences papers, Reviewer, TCM

Governance of AI ,Technology Diffusion, Social Media Analysis, User Behavior

NO entry in class after 15 mins , once class the started.

NO proxies attendance. NO back attendances will be given

CWS MTE ETE

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Introduction to software Engineering, Software characteristics, Software components, Software

Unit 2: Software Requirement Specification

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Unit 3: System Design

Unit 4: Software Project management

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Unit 6: Software Maintenance

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

IT:304 UNIT 1 Part 1

Sources: Textbook, internet, Research papers, SELF

Introduction to software Engineering

Demand Complexity Challenges

Same Same Same

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Then the notion of “software engineering” was proposed.

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

 What is software Engineering ?

Software engineering is an engineering branch associated with the

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

 To manage Large software Step by Step follow the procedure

 Quality Management Various Quality assurance Tests and Certifications

 Reduces complexity Abstraction and Decomposition

 minimize software cost Various cost estimation models

 Handle big projects SDLC

 Reliable software Reliability models and metrics , testing, maintenance models

 Effectiveness Good Standard s/w are developed: capability maturity model

What are characteristics of Software?

02 Jan 2024 Lecture Presentation | @Ruchika Pharswan

16 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Not easy to modify ( large s/w)

Required proper testing /

16 Jan 2024 Lecture Presentation | @Ruchika Pharswan

16 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Usability a) Understandability: Should be easy to understand by the user who is naïve

b) Learnability: The user should be able to learn to operate on the software.

16 Jan 2024 Lecture Presentation | @Ruchika Pharswan

16 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Integrity is key for demonstrating the safety, security, and maintainability of

16 Jan 2024 Lecture Presentation | @Ruchika Pharswan

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Program: Program is a combination of source code & object

Operating Procedures: Operating Procedures consist of

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Generic products / off the shelf

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan

Artificial intelligence software:

19 Jan 2024 Lecture Presentation | @Ruchika Pharswan