Software

Engineering
V1.8

Feb 2025
Agenda
• Software Engineering Overview
• Software Project Methodologies
• Object Oriented System Development
• Software Requirement Analysis
• Software Architecture and Component based Design
• Software Testing and Quality Assurance
• Cost Estimation and Measurement
• References

2
Software Engineering
 Software
Software
• Instructions (Computer Programs) that when executed provide desired features,
function and performance

4
 What is a Project?
What is a Project?
• A project is defined as a “temporary endeavour with a beginning and an end and it
must be used to create a unique product, service or result”
• End results have specific goals – Time, Cost, Performance & Quality

5
 Software Characteristics
• Software is a logical rather than a physical system element
• Software doesn’t wear-out
• Software is not susceptible to the environment maladies
• Software however deteriorates with time mainly due to change
• Software failure rate is high at the beginning but tapers out due to defect fixing

V/S

• Hardware wears out with time due to the effects of environment (dust, vibration, temp….)
• Hardware failure rate shows a bathtub curve
• Hardware failure can be corrected by spare part replacement

6
 Software Application Domains
• System Software – A collection of programs written to serve other programs (compilers, editors,
Operating system components, drivers, networking softwares…..)

• Application Software – Stand alone programs that solve a specific business need

• Engineering/scientific Software – number crunching programs, astronomy, CAD, Meteorology)

• Embedded Software – Resides within a product or system (Automobile, Medical Equipment, Industrial
Automation……)

• Product Line Software – Designed to provide specific capability for use of many different
consumers

• Web/Mobile Applications – Browser based apps and mobile devices

• Artificial Intelligence Software – Applications include Robotics, Expert Systems, Artificial neural
networks, gaming

7
 Changing Nature of Software
• WebApps – Sophisticated computing tools that not only provide stand alone function to the end
user but have now integrated with corporate databases and business applications

• Mobile Applications – Specifically designed to reside on a mobile platform (IOS, Android) with
persistent storage capabilities within the platform

• Cloud Computing – Encompasses an infrastructure or ecosystem that enables any user, anywhere,
to use a computing device to share computing resources on a broad scale

• Product Line Software – A set of software –intensive systems that share a common managed set of
features satisfying the specific needs of a particular market segment

8
 Software Engineering
Software Engineering:
• Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software
• Software Engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently on real machines

9
 Software Engineering – A layered Technology

Tools

Methods

Process

A Quality Focus

➢ Software Engineering rests on a commitment to Quality

➢ Process Layer is the foundation
➢ Engineering methods provide the “how to’s”
➢ Tools provide automated or semi automated support for the process and the methods

10
 Software Engineering Process
• The Software Process:
• A collection of activities , actions , and tasks that are performed when some work product is to be
created with a broad objective
• Is applied irrespective of the application domain, size, complexity, efforts
• Not a rigid prescription but an adaptable approach

• The Process Framework:

• Communication – Process of understanding Customer requirements, needs, pain areas
• Planning – A map that guides the team – Project Plan
• Modeling – The design of how to implement the requirements
• Construction –Execution or building the product
• Deployment – Delivery to the Customer

11
 Process Framework – Umbrella Activities
• Monitoring and Control – Allows the team to assess progress against plan and take corrective
actions wherever required

• Risk Management – Assess risks that may affect the outcome of the project

• Quality Assurance – Define and conduct activities to ensure quality

• Technical reviews – Assess engineering work products to uncover and remove errors

• Measurement – Defines and collects process, project, and product measures that assists the team
to deliver software that meets stakeholders needs

• Software Configuration Management – Manages the effects of change throughout the life cycle

• Reusability Management – Defines criteria for work product reuse

• Work product preparation and production – Encompasses the activities required to creat work
products such as models, documents, logs, forms and lists
12
 Software Engineering Practice
• Understand the problem:
• Who are the stakeholders?
• What are the unknowns? What data functions and features are required to solve the problem
• Can the problem be compartmentalized? Is it possible to represent smaller problems that may
be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?

• Plan the Solution:

• Have you seen similar problems before? Have we done a similar project before?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined?
• Can you represent a solution in a manner that leads to effective implementation? Can a design
model be created?

13
 Software Engineering Practice
• Carry out the Plan:
• Does the solution conform to the plan? Is source code traceable to the design model?
• Is each component part of the solution provable correct? Has the design code been reviewed?

• Examine the Result:

• Is it possible to test each component part of the solution? Has a reasonable testing strategy
been implemented?
• Does the solution produce results that conform to the data, functions, and features that are
required?

The overall approach is commonsense. In fact, it is reasonable to state that a commonsense

approach to software engineering will never lead you astray!

14
 General Principles
• The reason it all exists – To provide value to users – To address a pain area

• Keep it Simple Stupid (KISS) – All design should be as simple as possible. The payoff is software that
is more maintainable and less error-prone

• Maintain the Vision – A clear vision is essential to the success of a software project

• What you produce others will consume – Always specify design, and implement knowing someone
else will have to understand what you are doing. Specify with an eye to the users

• Be open to the future – A system with a long lifetime will add more value. Easy to adapt to change

• Plan ahead for Reuse – Reuse saves time and effort. Planning ahead for reuse reduces cost and
increases the value

• Think – Placing clear complete thought before action almost always produces better results

15
 Software Development Myths
Management Myths:
• We already have a book of standards and procedures……Is it being used?
• If we get behind schedule, we can add more programmers and catch up……Adding people to a late software
makes it later (Brooks)
• If we decide to outsource the software project to a third party, I can relax……If we cannot understand how to
manage and control projects internally, outsourcing will not help

Customer Myths:
• A general statement of objectives is sufficient to begin writing programs – we can fill in the details later……An
ambiguous statement of objectives is a recipe for disaster
• Software requirements continually change, but change can be easily accommodated because software is
flexible……Impact of change varies with time. Later the changes in the life cycle, the more it costs

Practitioner’s Myths:
• Once we write a program and get it to work, our job is done……The sooner you will begin writing code, the longer
it will take
• Until I get the program running, I have no way of assessing its quality……Software reviews are one of the most
effective ways for assessing the quality
• The only deliverable work product for a successful project is the working program……A working program is only
one part of a software configuration. A variety of work products such as models, documents, plans are included
• Software Engineering will make us create voluminous and unnecessary documentation and will slow us
down……Software Engineering is not about creating documents. It is about creating a quality product. Better
quality leads to reduced rework and thereby faster delivery times 16
 Software Process Structure
Software Process:
Process Framework:
Umbrella Activities:

Framework Activity # 1:
Software engineering action # 1.1

Work Tasks
Tasks Sets
Work Products
Quality Assurance points
Project Milestones

Software engineering action # 1.k

Work Tasks
Tasks Sets
Work Products
Quality Assurance points
Project Milestones

Framework Activity # n:
Software engineering action # n.1

Tasks Sets Work Tasks

Work Products
Quality Assurance points
Project Milestones

Software engineering action # n.m

Work Tasks
Tasks Sets
Work Products
Quality Assurance points
Project Milestones

17
 Software Process Flows
Linear Process Flow:

Communication Planning Modeling Construction Deployment

Iterative Process Flow:

Communication Planning Modeling Construction Deployment

18
 Software Process Flows
Evolutionary Process Flow:
Planning Modeling

Communication

Increment Released: Deployment Construction

Parallel Process Flow:

Communication Planning

Modeling

Construction Deployment
19
Software Process Models
• The word ‘Process’ emphasizes the idea of a system in action. In order to achieve an
outcome, the system will have to execute one or more activities: This is its process
• These activities can be organized in different ways – ‘Process Models’
•A classical Model also known as one-shot or once-through model

Waterfall •A sequence of activities working from Top to Bottom

•Best suited where the Requirements are well defined & development methods well
understood

•A Feasibility Study is carried out at the beginning of the project

Spiral •Greater level of detail is considered at every stage of the project

•Portrayed as a loop or a Spiral where the system to be developed is considered in more
detail in every step

•The approach is more incremental and iterative

Atern/DSDM •Also called as Dynamic Systems Development Method

•8 Core principles: Focus on Business Need, OTD, Collaborate with user, Quality, Iterative
Development, Incremental Build, Communicate & Control

•Also referred to as Rapid Prototyping Model

RAD •The major aim is to reduce costs and cycle time and improved Change Management
•Increased Customer involvement as feedback is sought on successive developed
prototypes which are refined

•Designed to overcome important disadvantages of the Traditional Methodologies

Agile •The approach involves development of one feature at a time and released to the
Customer for their use and feedback
•Includes various sub methods: Scrum, XP, Kanban

20
 Waterfall
Waterfall

Requirements Acceptance
Concept Analysis Testing

Design Architectural System

Design Testing

Develop Component Integration

Design Testing

Code Unit
Test Design Testing

Deliver
Executable Software
21
 Incremental Process
Incremental Process Model

Communication
Increment # n
Software Functionality and Features

Planning
Delivery of nth Increment

Modeling (Analysis,
Design)

Construction (Code, Increment # 2

Test)

Deployment
(Delivery, Feedback) Delivery of 2nd Increment

Increment # 1

Delivery of 1st Increment

Project Calendar Time 22

 Evolutionary Process Models
Prototyping
Communication Quick Plan

Deployment
Modeling Quick
Delivery &
Design
Feedback

Construction of
Prototype

• Best suited when the Customer defines a set of general objectives but does not identify detailed requirements for
functions and features
• The developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system or the
form that human-machine interaction should take place
23
 Spiral Model – Different Phases

• An evolutionary software process that couples the iterative nature of prototyping with the controlled and
systematic aspects of Waterfall model
• The software is developed in a series of evolutionary releases. Early iterations release might be a prototype and
later iterations would be more complete versions of the system 24
The Unified Process
•Encompasses both Customer communication & Planning activities
Inception •Business requirements (Use Cases) are identified and a rough architecture is proposed
•A plan for the iterative, incremental nature of the project is developed

•Use cases that were developed as part of the inception phase are refined and expanded
•Expands the architecture to include Use Case Model, Analysis Model, Design Model, Implementation
Elaboration Model, and Deployment Model
•A first cut executable system representation is done

•Using the architectural model as input, the construction phase develops or acquires the components to
make the Use case operational
Construction •Analysis and design models are completed to reflect the final version of the software increment
•All necessary and required functions and features are implemented
•Unit tests are designed and executed and integration activities are conducted

•Encompasses the delivery and feedback activity

Transation •Software is given to end users for beta testing for defects and feedback
•The team creates the necessary support information (User manuals, troubleshooting guides, and
installation procedures

•Ongoing use of the software is monitored

Production •Support for the operating environment (infrastructure)is provided
•Defect reports and requests for changes are submitted and evaluated

25
 Agile Development
What is Agility?
• Software development today is driven by change. The pervasiveness of change is the primary driver for Agility
• Agility is more than an effective response to change
• It encourages team structures and attitudes that make communication between stakeholders more facile
• It emphasizes rapid delivery of operational software
Agility and the cost of change
• The cost of change increases nonlinearly as the project progresses
• It is easy to accommodate a change during the upper life cycle especially requirements phase
• Changes later in the life cycle require changes across the phases (Requirements, Design, Coding, Testing)
• A well defined Agile process flattens the cost of change curve

Cost of change using conventional software processes

Development Costs

Cost of change using Agile processes

Idealized Cost of change using Agile processes

Development Schedule progress

 Agile Process
Key Assumptions
• It is difficult to predict in advance which software requirements will persists and which will change
• It is difficult to predict how Customer priorities will change as the project proceeds
• For many types of software, the design and construction are interleaved. Both activities should be
performed in tandem so that the design models are proven as they are created
• Analysis, Design, Construction, and Testing are not as predictable (from a planning point of view) as
we might like

How do we create a process that can manage unpredictability?

• An incremental development strategy should be instituted!

• Adaptation keeps pace with change (unpredictability)
• This iterative approach enables the Customer to evaluate the software increments
regularly, provide necessary feedback to the development team, and influence the process
adaptations that are made to accommodate the feedback

27
 Agile Principles
1. Highest priority is to satisfy the Customer through early and continuous delivery of valuable
software
2. Welcome changing requirements even late in development. Agile processes harness change for the
Customers competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months with a
preference to the shorter time scale
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals, Give them the environment and support they need,
and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity – the art of maximizing the amount of work done – is essential
11. The best architecture, requirements, and design emerge from self organizing teams
12. At regular intervals the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly
28
 Agile – Extreme Programing
XP Process: Simple Design
CRC Cards
Spike solutions
User Stories Prototypes
Values
Acceptance test criteria
Iteration plan

Refactoring

Pair programming

Continuous integration

Unit test

Acceptance testing
Release – Software increment
29
 Agile Scrum Model

Develop Develop

Test Reiterate

Design Design

1. The Project is divided into sprints of 2 to 4 weeks where incremental functionality is completed and delivered
2. Key Role holders – Product Owner, Scrum Master, Team Member
3. Key Artefacts – Product Backlog, Sprint Backlog, Sprint Burn Down and Burn Up Charts
4. Scrum Ceremonies – Sprint Planning, Daily Scrum, Sprint Review Meeting
30
 Agile – Scrum
Release Planning Meeting
Daily Scrum:
Daily standup meetings
to Share status and
potential issues
Initial Funding
Initial Architectural Release into
Vision Production

P P
o r Sprint Review Meeting: -
t Highest Priority Demo for stakeholders
o Initiate
e User Stories -Gain approval for next iteration
j Project
n Sprint Retrospective
e
t Meeting- learn from
c Sprint Backlog experience
i t
a s 2-4 weeks Sprint
l Operate and
Sprint Planning Meeting: Funding & Support in
Product Backlog -select work items for the iteration Feedback Production
- Effort estimation and
identification of work items Enhancement
Requests and
Defect Reports

• Brainstorm
Sprint Execution: • What went well
Legend Scrum Master Scrum Team
-Test Driven Development • What went wrong
-Continuous Build & Integration • Time-boxed issue identification
Product Owner -Test script Generation • Vote / Team Temperature
-Automated Testing • Discuss action items
Stakeholders = 1 User Story
• Follow-up

Rather than doing all of one thing at a time...

…Scrum teams do a little of everything all the time 31
 Agile – Dynamic Systems Development Method
• Provides a framework for building and maintaining systems through the use of incremental prototyping in a
controlled environment
• An iterative software process in which each iteration follows the 80% rule. Only enough work is required for each
increment to facilitate movement to the next increment

•Produces a set of incremental prototypes that demonstrate functionality to the Customer

Functional •All DSDM prototypes are intended to evolve into deliverable applications
Model iteration •Intent is to gather additional requirements through feedback from users as they exercise
the prototype

Design and Build •Revisit and review prototypes that were built during the functional model iteration
•In some cases the functional model iteration and the design and build iteration occur
Iteration concurrently

•Places the latest software increment (An operational prototype) into the operational
environment
Implementation •The increment may be 100% complete or changes may be requested as the increment is put
into place

32
 Agile Unified Process
• AUP adopts a “serial in the large” and “iterative in the small” philosophy for building computer based systems
• By adopting the classic UP phased activities (Inception, Elaboration, Construction, and Transition) – AUP provides a serial overlay
(linear sequence of software engineering activities)
Each AUP iteration addresses the following activities:

•UML representations of the business and problem domains are created

Modeling •These models should be just barely good enough to allow the team to proceed

Imlementation •Models are translated into source code

Testing •Like XP, the team designs and executes a series of tests to uncover defects

Deployment •Delivery of software increment and acquisition of feedback from the end users

Configuration •Configuration management addresses change management, Risk Management and control
of any persistent work products
and Project •Project Management tracks and controls the progress of the team and coordinates team
Management activities

33
 Agile Methods – Basic Principles
• Incremental Delivery after each time box
• Features are decomposed into small parts that can be incrementally developed
• Each incremental part is developed over an iteration
• The Time to develop an iteration is called a time box
• Face-to-Face communication
• Emphasis on Face-to-Face communication over written documents
• Daily contact through communication channels
• Customer Interactions
• Includes Customer representative in the team
• Customer participates in review meetings and provide feedback
• Minimal Documentation
• Documents are created on a need to know basis
• Documentation is light so easy to keep up-to-date and consistent
• Pair Programming
• In this approach two programmers work together at one station
• The programmers switch roles every hour or so
• Lesser defects are expected

34
Waterfall V/S Agile

Strengths Weaknesses Type of projects

Waterfall: 1. Requirements frozen early 1. Projects with very clear
requirements
1. Simple projects 2. Does not encourage changes
2. Short duration projects
2. Clear Requirements 3. Cycle time is too long
3. Automation of existing manual
3. Past projects experience 4. Late user feedback
systems
4. Intuitive and logical

Agile: 1. Requirements spillover from 1. For projects where time is of

sprints essence
1. Regular deliveries
2. Backlog bloating 2. Risk of long projects cannot be
2. Reduces risks
taken
3. Possibility of rework and
3. Accommodates changes
defects 3. Requirements are not known
4. Quick user feedback and will be known only with
4. System architecture and
5. Prioritizing requirements time
structure may suffer as
frequent changes are made

35
Agile Methods – Sub Methods

Extreme • Based on Four Core Values: Communication and Feedback, Simplicity,

Responsibility, Courage
• Code is developed in iterations of 1 to 4 weeks during which specific features
Programming are created. Pair programming is followed
• Small Releases – Time between Releases must be as short as possible

(XP) • Simple Design and Testing is done at the same time as coding using
automation tools

• The Project is divided into sprints of 2 to 4 weeks where incremental

functionality is completed and delivered

Scrum • Key Role holders – Product Owner, Scrum Master, Team Member
• Key Artefacts – Product Backlog, Sprint Backlog, Sprint Burn Down and Burn Up
Charts
• Scrum Ceremonies – Sprint Planning, Daily Scrum, Sprint Review Meeting

• Main Objective is to provide visibility to the workflow. This is expected to

debottleneck congestions in the process and minimize delays
• Kanban Board and Kanban Card – Typically a white board on which Kanban
Kanban Cards are attached to represent the work items. A card is moved on the board
as the corresponding work is completed at a stage
• Visibility – It shows work assigned to each developer at any time and the work
flow. Bottlenecks get highlighted. Cycle time is tracked and optimized

36
Agile Methods – Kanban Boards example

37
Agile -- Metrics
Burn Down Chart

38
Agile -- Metrics
Burn Up Chart

39
Agile -- Metrics
Velocity

40
 Agile – Metrics & Challenges
What to measure?
Efforts (Cost), Schedule, Quality of Deliverables, Customer Satisfaction
Traditional Methodology: Agile Methodology:

Measurements done at phase level Measurements done at Sprint and Iteration level

➢ Size : Function Points, LOC, Use-case Points ➢ Size : Story Points

➢ Efforts / Cost – Effort Variance / Cost Variance ➢ Efforts / Cost – Effort Variance / Cost Variance

➢ Schedule – Schedule Variance ➢ Schedule – Schedule Variance

➢ Quality – ➢ Quality –
➢ Defect Density, Review Effectiveness, Defect ➢ Defect Density – Defects/Story Point, Review
Removal Efficiency Effectiveness, Defect Removal Efficiency
➢ Efficiency, Test Case Effectiveness ➢ Efficiency, Test Case Effectiveness
➢ Defect Density – Defects / FP, Defects / KLoc ➢ Defect Density – Defects / Story Points
➢ Defect Age, Defect Acceptance Rate ➢ Defect Age, Defect Acceptance Rate

➢ Critical Chain Concept can be used for effective Buffer ➢ Critical Chain Concept can be used for effective Buffer
Management Management

➢ Earned Value can be used for prediction / Forecasts to ➢ Earned Value can be used for prediction / Forecasts to
facilitate Proactive Project Management facilitate Proactive Project Management

➢ Customer Satisfaction – Customer Satisfaction Survey / ➢ Customer Satisfaction – Customer Satisfaction Survey /
Feedback Feedback

Challenges?
▪ Inconsistencies in Size measurements across projects and inadequate baselines
▪ Short Turn around time in a sprint leading to process gaps
41
▪ Aggressive schedule and stringent deadlines
 Agile Methods – Challenges
• Reluctance to Change
• Difficult to break work habits as teams are used to work with a traditional approach. Need
to implement Agile in a phased manner with pilot projects
• Quality, Cost, Time and Scope
• Agile being flexible allows frequent changes in scope which means that Cost, Quality or Time
has to change. In practice, majority of projects have fixed budget and a mandatory deadline
• Establishing when the scope changes to cease is difficult and hence leads to overruns
• Ready to Use Product
• An application under agile development process is always evolving and may have functional
defects. Hence, performance testing can only be performed after substantial number of
deliveries
• Inability to ‘design’ for future requirements
• Irrespective of best design models and most experienced design personnel on a project
team, it is very hard to design a system on the basis of unseen requirements. This often
leads to ‘rework’ at various stages in development and testing
• External and Internal Dependencies
• Majority of projects have external dependencies which are out of control of core project
team and they are discovered only during development
• The selection of work items is dependent on internal teams, hence planning each iteration
becomes tough and needs huge coordination efforts

42
Requirements Analysis and Specification
“I know you think you understand what I said, but what you don’t understand is what I said is not
what I meant”
For large Software systems, requirements analysis is perhaps the most difficult and intractable
activity and is it is error-prone

Why is Requirements Analysis difficult?

• The needs of the system are in the minds of the Customer organization
• The analyst has to identify the requirements by interacting with the Customer and
understanding their needs……visualize
• As the information which is visualized, is not formally stated or organized, the input of the
requirements phase is inherently informal and imprecise, and is likely to be incomplete
• When inputs from multiple people are to be gathered, these inputs are likely to be
inconsistent as well
• User needs keep changing as the environment in which the system is to function changes
with time
The requirement process
• The requirements phase translates the ideas in the minds of the Customer (the input) into a
formal document (the output)
• The output is hopefully complete and consistent, while the input has non of these properties
• Any formal translation process producing a formal output must have a precise and unambiguous
input
43
 Software Requirements
Requirement

• A condition of capability needed by a user to solve a problem or achieve an objective

• A condition or capability that must be met or proposed by a system…… to satisfy a contract,

standard, specification, or other formal imposed document

• Requirements of the proposed system, that is the capabilities that the system, which is yet to be
developed should have

• Even while accepting that some requirement change requests are inevitable, it is imperative to
have a high quality and stable SRS (Software Requirement Specification)

44
Why do we need a high quality and stable SRS?

• An SRS establishes the basis for agreement between the Customer and the Supplier on what the
software product will do

• An SRS provides a reference for validation of the final product

• A defect in the SRS will most likely manifest itself as a defect in the final system implementing
the SRS

• A high quality SRS is a prerequisite to high quality software

• Cost of fixing a defect increases almost exponentially as time progresses

• A high quality SRS reduces the development costs

45
High quality SRS – High quality & Reduced costs

• Invest an additional 100 person-hours in the requirements phase, an

Phase Cost (Person-hours) average of 50 new requirement defects will be detected and
removed

Requirements 2 • Distribution of defects that remain after the requirements phase:

• 65% in design, 2% in coding, 30% in Testing, 3% in maintenance
Design 5
• Assuming that the 50 defects are detected in the later phases after
requirements, the cost of fixing the defects will be:
Coding 15
• (32.5*5) + 1*15) + (15*50) + (1.5*150) = 1152 person hours!!
Acceptance Test 50
• By investing additional 100 person hours in the requirements phase,
Maintenance 150 the development costs could be reduced by 1152 person hours – a
net reduction in cost of 1052 person hours

• It is estimated that 20% to 40% of the total development effort in a software project is due to rework (mainly due to change
in requirements

• Cost of requirements phase is roughly 6% of the total project cost. Consider a project with 50 person months of total effort

• Requirements phase consume 3 person months

• If by spending an additional 33% effort in the requirements phase, we reduce the total requirement change requests by
33%

• Total effort due to rework will reduce from 10 to 20 person months resulting a total saving of 5 to 11 person months i.e a
saving of 10% to 22% of the total cost!!
46
Requirements process

Customer /
User Needs

Problem • The problem domain and the environment are modelled in an effort
Analysis to understand the system behaviour, constraints, inputs & outputs

• Focus is on clearly specifying the requirements in a document

Product • Issues such as representation, specification languages, and tools are
Description addressed to organize and describe the requirements

• Focusses on ensuring that what has been specified in the SRS are
Validation indeed all the requirements of the software
• Making sure that the SRS is of a good quality

Validated SRS
47
 Problem Analysis
• The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired
from the software and what the constraints on the solution are

• The basic principle used in analysis is the same as in any complex task: divide and conquer!

• Partition the problem into subproblems and then try to understand each subproblem and its relationship to other subproblems in
an effort to understand the total problem
Methods of Analysis:
Informal • An approach where no defined methodology is used
• The information about the system is obtained by interaction with the client, end users, surveys,
Approach study of existing documents, brainstorming

• Also referred to as the structured analysis technique uses function based decomposition while
Data Flow modeling the problem
Modeling • Data Flow diagrams (DFD) and Data Dictionary are created. The system is viewed as a function
that transforms the inputs into desired outputs

• The system is viewed as a set of objects (Object Classes). The objects interact with each other
Object Oriented through the services they provide
• Define the classes by specifying what state information they encapsulate and what services they
Modeling provide
• Identify relationships that exist between objects of different classes

• A partial system is constructed which is used by the clients, users , and developers to gain a
Prototyping better understanding of the problem and the needs
• Two approaches – throwaway and evolutionary prototypes
48
 Data Flow Diagram (DFD)
Restaurant Automation System:
Supplier Register

Supply
Check Make
Record
Payment Sale Register

Receive Make
Supplier Supplies Dishes
Supplies Supplies
Order Supplies
Supplies

Record
Sale
Sales

Order Order
Payment
Take Process Produce
Order Order Bill
Bill
Served Meal Bill Money Receipt

Customer
49
 Data Dictionary

• Supplies_file = [date + [item_no + quantity + cost]*

• Order_file = [date + [menu+item_no + quantity + status]*]*

• Status = satisfied | unsatisfied

• Order = [menu_item_no + quantity]*

• Menu = [menu_item_no + name + price + supplies_used]*

• Supplies_used = [supply_item_no + quantity]*

• Bill = [name + quantity + price]* + total_price + sales_tax + service_charge + grand_total

• Discrepancy_report = [supply_item_no + amt_ordered + amt_left + amt_consumed + desr]*

50
Object Oriented Modeling

Drug-Store
Name
Location

Compute Sales( )
Sale
Amount

Chemist Medicine GetAmount( )

Name Name
Registration No. Quantity
Address Expiry Date
Compute Sales( ) Expired ( )
OutofStock ( )

Off-the-shelf Prescription
Qty-on-shelf Refrigeration
Needs
Warnings
GetAmount( )
51
 Software Requirements Specifications (SRS)
Characteristics of an SRS:

Correct • An SRS is correct if every requirement in the SRS represents something required in the final system

• An SRS is complete if everything the software is supposed to do and the response of the software to
Complete all classes of input data are specified in the SRS

Unambiguous • An SRS is unambiguous if and only if every requirement stated has one and only one interpretation

• An SRS is verifiable if and only if every stated requirement is verifiable. The requirements should have
Verifiable as little subjectivity as possible

Consistent • An SRS is consistent if there is no requirement that conflicts with another

Ranked for • Some requirements are core requirements which are not likely to change as time passes while others
are more dependent on time
importance and • SRS is ranked for importance and /or stability. Stability of a requirement reflects the chances of it
/or stability changing in future

• An SRS should be easy to modify. This is possible if the structure and style are such that any necessary
Modifiable changes can be made easily while preserving completeness and consistency

• An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of
Traceable each requirement in future development

52
Components of an SRS

Functionality

• Functionality requirements specify which outputs should be produced from the given
inputs

• They describe the relationship between the input and output of the system

• For each functional requirement, a detailed description of all the data inputs and their
source, the units of measure, and the range of valid inputs must be specified

• All operations to be performed on the input data to obtain the output should be specified.

• Specifying the validity checks on the input and output data, parameters affected by the
operation, and equations or other logical operations that must be used to transform the
inputs into corresponding outputs

• The functional specifications must clearly state the system behavior for invalid inputs and
invalid outputs
53
Components of an SRS

Performance

• This part of the SRS specifies the performance constraints on the software system

• All the requirements relating to the performance characteristics of the system must be
clearly specified

• There are two types of performance requirements – Static and Dynamic

• Static requirements are those that do not impose constraints on the execution
characteristics of the system. These are also called capacity requirements (No. of
terminals to be supported, No. of simultaneous users……)

• Dynamic requirements specify constraints on the execution behavior of the system

(Response time and throughput……)

54
Components of an SRS
Design
Constraints

• Standards Compliance – This specifies the requirements for the standards the system must
follow. For e.g. report format, accounting procedure, audit tracing requirements

• Hardware Limitations – The software may have to operate on some existing or

predetermined hardware, thus imposing restrictions on the design

• Reliability and Fault Tolerance – Requirements about system behavior in the face of certain
kinds of faults is specified

• Security – Security requirements place restrictions on the use of certain commands, control
access to data, different kinds of access requirements for different users, maintain log of
activities.

55
Components of an SRS
External
Interface
Requirements

• All the interactions of the software with people, hardware, and other software should be
clearly specified

• For the user interface, the characteristics of each user interface of the software product
should be specified

• For hardware interface requirements, the SRS should specify the logical characteristics of
each interface between the software product and the hardware components. For e.g.
memory restrictions, load characteristics……

• The interface requirement should specify the interface with other software the system will
use or that will use the system

56
Structure of an SRS

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Overall 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

57
Functional Specifications with Use Cases
• A use case is a written description of how users will perform tasks on the system
• It outlines, from a user's point of view, a system's behavior as it responds to a request
• Each use case is represented as a sequence of simple steps, beginning with a user's goal and
ending when that goal is fulfilled.
Term Definition
Actors A person or a system which uses the system being built
for achieving some goal
Primary Actor The main actor for whom a use case is initiated and
whose goal satisfaction is the main objective of the use
case
Scenario A set of actions that are performed to achieve a goal
under some specified conditions
Main success scenario Describes the interaction if nothing fails and all steps in
the scenario succeed
Extension scenario Describe the system behavior if some steps in the main
scenario do not complete successfully

58
Use Case Example

* Use Case 1: Put an item for auction

Primary Actor: Seller

Precondition: Seller has logged in

Main Success Scenario:

1. Seller posts an item (its category, description, picture, etc.) for auction
2. System shows past prices of similar items to seller
3. Seller specifies the starting bid price and a date when auction will close
4. System accepts the item and posts it

Exception Scenarios:
- 2 a) There are no past items of this category
* System tells the seller this situation

* Use Case 2: Make a bid

59
Validation of the SRS
• The basic objective of Validating the SRS is to ensure that the SRS reflects the actual requirements
accurately and clearly

• The SRS is of a good quality

Types of errors:

• Omission : Some user requirement is simple not included in the SRS

• Inconsistency : Contradictions within the SRS or incompatibility of the stated requirements with
the actual requirements

• Incorrect fact : Some fact recorded in the SRS is not correct

• Ambiguity : Some requirements have multiple meanings i.e. their interpretation is not unique

60
 SRS – Case Study
Scenario:
You are given an excerpt from a Software Requirements Specification (SRS) document for a new mobile application
designed to facilitate online learning for university students. This SRS includes details about user roles, system
functionality, and non-functional requirements. However, there are several ambiguities and errors in the document.

Provided SRS Excerpt:

1. User Requirements:
• Students can access course materials anytime and from any device.
• Professors shall have the ability to upload course materials and assignments.
• The application should provide forums for each course.

1. System Features:
• Feature 1: Upload Course Material
• Description: Professors can upload documents and videos.
• Users: Professors
• Feature 2: Access Course Material
• Description: Allows students to download and view course materials.
• Users: Students
•
2. Non-functional Requirements:
• The system must support large number of concurrent users.
• All user interactions with the platform must be secure.
• The system should have a good uptime.

Review the provided SRS excerpt and identify five issues related to clarity, completeness, and potential
misunderstandings and provide suggestions for improvement 61
Object Oriented System Development
 Object Oriented Systems development

A software system is a set of mechanisms for performing certain actions on certain data

Traditional Development v/s Object Oriented Systems Development:

Traditional OOSD
A collection of programs (Functions) and A collection of objects which combines data and
Isolated Data functionality
Algorithms + Data Structures Functions + procedures
Focuses on the functions of the system – What Focuses on the object
is it doing?

Object oriented systems development is a way to develop software by building self-contained modules
or objects that can be easily replaced, modified, and reused

A system of cooperative and collaborating objects

63
 Why Object Orientation?

• Complexity Management: OOP provides a structured approach to organize code, making

complex systems more manageable

• Reusability: Through inheritance and polymorphism, OOP promotes code reuse, reducing
redundancy and development effort

• Modularity: Encapsulation allows for modular code, where internal changes to objects don't
affect other parts of the program

• Scalability: Object-oriented systems are more scalable, simplifying the process of managing
larger projects

• Real-world Modeling: OOP concepts mirror real-world entities, making the design and
understanding of software systems more intuitive

64
 Why Object Orientation?
• Object-oriented methods enable us to create sets of objects that work together in synergy to
produce software that effectively models their problem domains

• The systems are easier to adapt to changing requirements, easier to maintain, more robust, and
promote greater design and code reuse

• Allows us to create modules of functionality and they perform their desired functions

• Attention as a programmer shifts to what they do rather than how they do it

65
 Why Object Orientation?
• Higher level of abstraction – abstraction at the object level and the development can proceed at the
object level and ignore the rest of the system for as long as necessary

• This makes designing, coding, testing, and maintaining the system much simpler

• Seamless transition among different software phases – Uses the same language to talk about
analysis, design, programming, and database design

• This reduces the level of complexity and redundancy and makes for clearer, more robust system
development

• Promotion of reusability – Objects are reusable because they are modelled directly out of a real
world problem domain. Each object stands by itself or within a small circle of peers(other objects)

• Inheritance – A powerful technique that allows classes to be built from each other – Only differences
and enhancements between the classes need to be designed and coded. All the previous
functionality remains and can be used without change

66
 Object Oriented Systems Development

• In an object oriented system, everything is an object and each object is responsible for itself

• Each object has attributes (data) and methods (functions) and tasks can be allocated among the
objects

• Objects work together synergistically to produce software that better model their problem domain
than systems produced by traditional techniques

• Objects are grouped into classes

67
 What is an Object?
The term object is a combination of data and logic that represents some real world entity

When developing an object –oriented application, there are two basic questions:
What objects does the application need?
What functionality should those objects have?

Example:
A windows application
• Windows objects that can open themselves on screen and either display something or accept
inputs
• A windows object is responsible for things like opening, sizing, and closing itself
• When a window displays something, that something also is an object (a chart….input box)
• A chart object is responsible for things like maintaining its data and labels and even drawing itself

68
 Object – Properties and Methods
• Properties or attributes describe the state (data) of an object

• Methods or procedures define its behavior

• An object is whatever an application wants to talk about

Example:
A Car is an object or a real world entity
• A car has a well defined set of attributes in relation to other object such as Colour, Manufacturer,
Cost, and Owner
• A well defined set of things you normally do with it such as Drive it, Lock it, Tow it, and Carry
passengers in it

69
 What is a Class?
• A set of objects which share a common structure and a common behavior

• Classes are used to distinguish one type of object from another

• A single object is simply an instance of a class

• Classes are an important mechanism for classifying objects

• The Class defines the properties and procedures (the state and behavior) and applicability of its
instances

• The method or behavior of an object is defined by its class

Example:
An Employee Class
• Employees such as Shyam, Bill, Sanjay, Tom, Rohit are all instances of a given class Employee
• The instructions responded to by each of those instances of employee are managed by the class
• The data associated with a particular object is managed by the object itself such as Aadhaar Card
no, address, Salary
• Objects we use in the programs are instances of classes
70
 Object Behavior and Methods
• A method implements the behavior of an object

• Behavior denotes the collection of methods that abstractly describes what an object is capable of
doing

• A method is a function or procedure that is defined for a class and typically can access the internal
state of an object of that class to perform some operation

• Each procedure defines and describes a particular behavior of an object. The object, called the
receiver is that on which the method operates

• Methods encapsulates the behavior of the object, provide interfaces to the object, and hides any of
the internal structures and states maintained by the object

• Procedures provide us the means to communicate with an object and access its properties

Example:
• We can drive a car, we can ride a horse (description of the objects behavior)

71
 Objects and Messages
• An objects capabilities are determined by the methods defined for it

• To do any operation, a message is sent to an object. Objects perform operations in response to

messages

• Messages essentially are nonspecific function calls. It is the receivers responsibility to respond to a
message in an appropriate manner

Examples:
• When we press on the brake peddle of the car, we send a “stop” message to the car object
• A “compute payroll” message sent to the employee object

72
 Encapsulation and Information Hiding
• Encapsulation bundles data (attributes) and methods (behaviors) into a single unit insulating the internal format of
an object from other objects

• Encapsulation in is an object-oriented procedure of combining the data members and data methods of the class
inside the user-defined class

• Information hiding is the principle of concealing the internal data and procedures of an object and providing an
interface to each object tin such a way as to reveal as little as possible about its inner working

• The object is said to encapsulate the data and a program. The user cannot see the inside of the object capsule, but
can use the object by calling the object’s methods

• Rather than allowing an object direct access to another object’s data, a message is sent to the target object
requesting information. This ensures not only that instructions are operating on the proper data but also that no
object can operate directly on another object’s data

• An important factor in achieving encapsulation is the design of different classes of objects that operate using a
common protocol, or object’s user interface. This means that many objects will respond to the same message, but
each will perform the message using operations tailored to its class

Example:
• A car engine. Although engines may differ in implementation, the interface between the driver and the car is
through a common protocol: step on the petrol to increase power and let up on the petrol to decrease power.
Since all drivers know this protocol, all drivers can use this method in all cars, no matter what engine is in the car
73
 Class Hierarchy
• An object-oriented system organizes classes into a subclass- superclass hierarchy

• Different properties and behaviors are used as the basis for making distinctions between classes and subclasses

• At the top of the class hierarchy are the most general classes and at the bottom are the most specific

• A subclass inherits all the properties and methods (procedures) defined in its superclass

• Subclasses generally add methods and properties specific to that class. They may refine or constrain the state and
behavior inherited from its superclass
Vehicle

Vehicle
Car

Bus Truck Car

Honda

Civic City Amaze

74
 Inheritance
• Inheritance is the property of object-oriented systems that allows objects to be built from other
objects

• Inheritance allows explicitly taking advantage of the commonality of objects when constructing new
classes

• Inheritance is a relationship between classes where one class is the parent class of another (derived)
class. The parent class is also known as the base class or superclass

• Inheritance provides programming by extension as opposed to reinvention. We can build on what we

already have and more importantly reuse what we already have

• Inheritance allows classes to share and reuse behaviors and attributes. Where the behavior of a class
instance is defined in that class’s methods, a class also inherits the behaviors and attributes of all of
its superclasses

Example:
• The car class defines the general behavior of cars. The Honda class inherits the general behavior
from the Car class and adds behavior specific to Honda. It is not necessary to redefine the
behavior of the Car class; this is inherited
 Polymorphism
• Poly – Many and Morph – form. Objects that can take on or assume many different forms

• The same operation may behave differently on different classes – Relationship of objects of many
different classes by some common superclass; thus any of the objects designated by this name is
able to respond to some common set of operations in a different way

• Polymorphism allows us to write generic, reusable code more easily, because we can specify general
instructions and delegate the implementation details to the objects involved

Example:
• A car with a manual transmission and another with automatic transmission. The manual
transmission requires you to operate the clutch and the gear shift, so in addition to all other
mechanical controls, you will also need information on when to shift gears.
• Driving is a behavior we perform on all cars, the specific behavior can be different depending on
the kind of car we are driving. The method is the same for both cars but the implementation
invoked depends on the type of car (class of the object)
Thank You