Module 1: Introduction to Software Engineeering

Software Engineering
Computer Science
Academic Year 2025/2026

Gerard Albà Soler

1
Contents
1. What’s Software Engineering
2. Software Quality
3. The Software Process (Software Development Life Cycle)
4. Modeling techniques and Programming paradigms
5. Software Requirements
1. What’s Software Engineering
• Motivation
• Software Engineering definitions
• What will we learn
• References Module 1
1. What’s software engineering
1. What’s software engineering
1. What’s software engineering

Sundar Pichai

The Future: AI is reworking software engineering

1. What’s software engineering
Importance of software engineering

• More and more, individuals and the society rely on advanced software
Systems. We need to be able to produce reliable and trustworthy systems,
economically and quickly.
• Use software engineering methods and techniques for software systems,
rather than just write the programs as if it was a personal programming
project.
 1. What’s software engineering
Software crisis and the begining of Software Engineering
• Software crisis was a term used in the early days of computer science. It was
was coined by some attendees at the first NATO Software Engineering
Conference in 1968 in Germany.

- Projects running over-budget

- Projects running over-time
- Software was very inefficient
- Software was of low quality
- Software often did not meet requirements
- Projects were unmanageable and code difficult to maintain
1. What’s software engineering

E. Dijkstra in 1972’s Turing award lecture:

“The major cause of the software crisis is that the

machines have become several orders of magnitude
more powerful! To put it quite bluntly: as long as
there were no machines, programming was no
problem at all; when we had a few weak computers,
programming became a mild problem, and now we
have gigantic computers, programming has become
an equally gigantic problem.”
1. What’s software engineering
 1. What’s software engineering
Question Answer

What is software? Computer programs and associated documentation.

Software products may be developed for a particular
customer or may be developed for a general market.
What are the attributes of good software? Good software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What are the fundamental software Software specification, software development, software
engineering activities? validation and software evolution.

What is the difference between software Computer science focuses on theory and fundamentals;
engineering and computer science? software engineering is concerned with the practicalities of
developing and delivering useful software.
 1. What’s software engineering
• Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of System specification
through to maintaining the System after it has gone into use.
• Engineering discipline
✓ Using appropiate theories and methods to solve problems bearing in mind
organizational and financial constraints.
• All aspects of software production
✓ Not just technical process of development. Also project management and
the development of tools, methods...to suport software production.
✓ Includes many aspects, some of them will not be covered in this
introductory course: user interface, usability, database design, security...
 1. What’s software engineering
• Software engineering goes beyond learning a programming Language. It is
more about the full lifecycle of a software product.
• You must have a comprehensive understanding of more than just the syntax
and grammar of a programming Language. You must be well-versed in testing,
architecture, modeling, and more.
• Even in the era of artificial intelligence (AI) and agentic coding tools, you must
have a solid grasp of the fundamentals to wield AI tools properly.
 1. What’s software engineering
• The universe of topics within software engineering also includes:
✓ Reading existing code (and not just Writing code)
✓ Modeling
✓ Testing (and Automated testing)
✓ User Interface design
✓ Working with Data
✓ Software Architecture
✓ Production environaments
✓ AI in software engineering
• In addition to these, soft skills are also very important: learning,
communication, time management, among others
 1. What’s software engineering
• Usually, we are only taught how to write code. We learn programming
languages, and techniques like debugging, eficient algorithm design, data
structures, and other related topics.
• But, in practice, we will also need to know about things like:
✓ How to work and communicate with others
✓ How to read code (and how to write readable code)
✓ How to work effectively with legacy code

✓ ...
• As a practicing software engineer, your code will be in production, where real
people will rely on it to function as designed, delivering business value
1. What’s software engineering
What will we learn?
OOA/D

Further Studies
Reading vs Writing Code;
Testing; User Interface UML notation
Design; Working with Data;
Production-Ready Code

Waterfall, Iterative
Requirement analysis
development, Agile

Principles, guidelines,
patterns
1. What’s software engineering

[Link]
 1. What’s software engineering
• Book References
✓ Fundamentals of Software Engineering. N Schutta et al. Ed O’Reilly
✓ Engineering Software. R Hyde. Ed no starch press
✓ Modern Software Engineering. D Farley. Ed Addison-Wesley
✓ Software Engineering. A Practitioner’s approach. R. Pressman et al. Ed
McGrawHill
✓ Software Engineering. I. Sommerville. Ed Addison-Wesley
✓ Applying UML and Patterns. An Introduction to Object-Oriented Analysis
and Design and Iterative Development. C. Larman. Ed Prentice Hall
✓ Software Engineering at Google. T. Winter. Ed O’Reilly
Contents
1. What’s Software Engineering
2. Software Quality
3. The Software Process
4. Modeling techniques and Programming paradigms
5. Software Requirements
2. Software Quality
• Software crisis. Process, methods and tools
• McCall’s Quality model
• Quality Assurance
2. Software Quality
• Traditionally, a high-quality product is outlined in terms of its fitness of
purpose. That is, a high-quality product will specifically be what the end-
users need.

• For code products (software), fitness of purpose isn’t a completely

satisfactory definition of quality. In the most general sense, software quality
can be defined as:
An effective software process applied in a manner
that creates a useful product that provides measurable value for those who
produce it and those who use it.
2. Software Quality
• Software engineering is a set of processes, methods and tools used for obtaining reliable,
reusable and efficient software that accomplishes specific goals.
• By following established software engineering principles and techniques, the software can
be developed with improved quality: fewer bugs and higher reliability.

• Through this course, we will focus on the foundational (the processes) and technical (the
methods) layers, but software engineering must always rest on an organizational
commitment to quality.
2. Software Quality
PROCESS METHODS TOOLS
• The way we organise • Assist the engineer in • Traditional Computer-
the activities for modelling the software Aided Software
creating, using and design: here we can use Egineering (CASE) tools
maintaining software different diagrams, provide support for
notations… processes and methods.
• It defines a framework
• It guides the engineer • Principles and • Currently, many
through the necessary guidelines for a broad integrated development
array of tasks that environments (IDEs)
tasks to build software
include communication, provide comprehensive
requirements analysis, facilities for software
design modeling, development (ex UML
program construction, from code)
testing, and support.
2. Software Quality
Mc Call’s Quality model
• Software quality factors of this model focus on
three software product aspects: its operation
characteristics, its ability to undergo change,
and its adaptability to new environments.
• When discussing software quality, we are
really talking about the non-functional
requirements of a system—often referred to
as the "-ilities"
• While functional requirements define what a
system does, the "-ilities" define how well it
does it
 2. Software Quality
Quality factor High-quality software includes several quality factors like the following

Correctness Software is correct if completely different needs are properly enforced.

Usability A software has smart usability if completely different users (i.e. knowledgeable and
novice users) will simply invoke the functions of the product.
Portability A software is claimed to be transportable, if it works in several package
environments, in several machines, with other programs, etc.
Maintainability A software is reparable, if errors may be simply corrected as and once they show
up, new functions may be simply added, and therefore the functionalities may be
easily changed, etc.
Efficiency The more efficient software is, the less it uses of CPU-time, memory, disk space,
network bandwidth, and other resources.
Reliability Software is more reliable if it has fewer failures.
Reusability A software has smart reusability if different modules can be smoothly reused to
develop new versions.
 2. Software Quality
• There are several software quality models (qualitative and quantitative) and standards (like
ISO 9001).
• But a Quality Management System is one of the the main methods used by organizations.
Quality systems have increasingly evolved over time:
• Initially, the function was to inspect the finished products to remove defective ones.
• Then, the first product inspection task led to quality control. Thus, quality control aims
at correcting the reasons for bugs and not just rejecting the products.
• The next breakthrough was the development of quality assurance. If an organization's
processes are proper and are followed rigorously, then the products will be of good
quality.
• Total quality management (TQM) advocates that the procedure followed by an
organization must be continuously improved through process measurements. TQM
aims at frequently process improvement.
2. Software Quality
• Evolution: from product inspection to process assurance

• Reference book: Software Engineering at Google, Ed O’Reilly

2. Software Quality

[Link]
Contents
1. What’s Software Engineering
2. Software Quality
3. The Software Process
4. Modeling techniques and Programming paradigms
5. Software Requirements
3. The Software Process
• Software Development Life Cycle
• Predictive and Adaptative methodologies
• Waterfall
• Prototype
• Agile
• Scrum
3. The Software Process
• The Software Process, sometimes also called the Software Development
Life Cycle is a framework for the activities, actions, and tasks required to
build high-quality software.
• A generic process framework:
1. Software specification: the functionality of the software and
constraints on its operation must be defined.
2. Software design and implementation: the software to meet the
specification must be produced.
3. Software validation: the software must be validated to ensure that it
does what the customer wants.
4. Software evolution: must evolve to meet changing customer needs.
3. The Software Process
• Short-term programming differ from producing code with a much longer
expected life span
• Imagine Google Search being stuck on a version of the initial OS from the
1990s..!!
3. The Software Process
• Software development phases

Planning

Maintenance Analysis

Deployment Design

Testing Development
3. The Software Process
• Additionally, those phases can follow a process flow, that describes how the framework
activities and the actions and tasks that occur within each framework activity are
organized with respect to sequence and time. We will discuss it later in more detail

Iterative

Linear

Evolutionary
[Link]
3. The Software Process
Plan-driven vs Agile
• Plan-driven processes are processes where all of the process activities are
planned in advance and progress is measured against this plan.

• In agile processes, planning is incremental and it is easier to change the

process to reflect changing customer requirements.

• In practice, most practical processes include elements of both plan-driven

and agile approaches.

• There are no right or wrong software processes.

 3. The Software Process
Planning
• First stage where the project is initiated
• The team examines key aspects of the project to see if it’s doable or not
• In this stage, it’s important to consider:
✓ Communication: make contact with stakeholder and discuss high-level requirements
✓ Business: the business value of the project. Why this project? Why this way?
✓ Economic: What’s the budget? Is it reasonable?
✓ Schedule: How many time can we work on it? It’s reasonable?
✓ Technical: Can we build it? It’s possible?
✓ Resources: What do we need? (tools, technology, people…)

• At the end of this phase we may have deliverables (depending on the paradigm): cost plan,
working plan, risk assessment plan, etc
 3. The Software Process
Analysis
• First Requirement gathering: relevant information is collected from the client, in order to
know exactly what it needs to be done and start thinking how.
• We are defining all the needs that the project will have to solve and what do we need to do
it. Critical step due to the implications if there is a misunderstanding with the customer.
• We can find two levels of definition here:
• User requirements [close to the client]: “we want the user to buy in a secure manner”
• Specification/Functional requirements [close to the tech team]: “activate login session
once the customer pushes enter after introducing mail and password. If the session
remains inactive for 60 seconds, delete the session”
• The documentation after this phase will depend on the paradigm. For Use Cases driven
development use cases textual definition is an additional deliverable.
 3. The Software Process
Design
• How the system will achieve what is needed?

• Requirements are translated into: “how will it be implemented?”

• We produce plenty of design documents:

✓ Physical design: UI, UX, Data Design, etc
✓ Logical design: abstract representation of the system via modelling

• This documents are usually submitted to be approved by the whole team or higher
stakeholders of the project
 3. The Software Process
Design
• In this phase, we also take decisions about code architecture. Software architecture is about
breaking large systems into sub-systems:
✓ That are Independent with some business logic
✓ That can be integrated with other components
✓ That can be created separately

• At the end of this phase, design system requirements are transformed into a detailed,
software ready description
✓ Graphical mock-ups or wireframes
✓ Formal descriptions including UML diagrams

• During design, we must avoid technology-specific specifications

 3. The Software Process
Development
• This is the longest phase (and way more longer if previous steps are not well defined).

• The team uses the design documents and diagrams to build the project correctly.

• In addition to the working software deliverables, for this phase we generate:

✓ Unit tests for each one of the implemented modules
✓ Build scripts to compile and link software into executable components
✓ Code documentation inside the code
✓ Test cases or testing flow for the application
 3. The Software Process
Testing
• Testing is intended to show that a program does what it is intended to do and to discover
program defects before it is put into use. When you test software, you execute a program
using artificial data. You check the results of the test run for errors, anomalies, or
information about the program’s non-functional attributes.

• Two distinct goals:

1. Validation: To demonstrate to the developer and the customer that the software meets its
requirements. “Are we building the right product?”

2. Verification: or defect testing. To discover situations in which the behavior of the software
is incorrect, undesirable, or does not conform to its specification. These are a consequence
of software defects. “Are we building the product right?”
 3. The Software Process
Testing
• Traditional testing process, as used in plan-driven development. Test cases are specifications
of the inputs to the test and the expected output from the system (the test results), plus a
statement of what is being tested.
 3. The Software Process
Testing
• Typically, a software system has to go through three stages of testing:

1. Development testing, where the system is tested during development to discover bugs
and defects. System designers and programmers are likely to be involved
in the testing process.
2. Release testing, where a separate testing team tests a complete version of the
system before it is released to users. The aim of release testing is to check that
the system meets the requirements of system stakeholders.
3. User testing, where users or potential users of a system test the system in their own
environment. Acceptance testing is one type of user testing where the customer formally
tests a system to decide if it should be accepted from the system supplier or if further
development is required.
3. The Software Process
Testing
• Development testing is primarily a defect testing process, where the aim of testing
is to discover bugs in the software.

• During development, testing may be carried out at three levels of granularity:

1. Unit testing, where individual program units or object classes are tested. Should focus
on testing the functionality of objects or methods.
2. Integration Testing: Testing how different modules or services work together to ensure
they interact correctly.
3. System testing, where some or all of the components in a system are integrated
and the system is tested as a whole. Should focus on testing component interactions.
3. The Software Process
Deployment
• The SDLC deployment phase involves customer acceptance and releasing the software
• Deployment and recovery plan must be ready before starting
• Deployment plan must consider :
✓ Hardware and environment
✓ Database related activities
✓ Documentation for new software
✓ Training activities
✓ Third party software's
3. The Software Process
Maintenance
• The Documentation is key in this phase, to support users and administrators
✓ Manual explaining how to use features and functions
✓ Installation manual or quick start guides

• Development team leads with most knowledge about the system will remain involved to:
✓ Troubleshoot issues found in early deployment
✓ Assist in training and documentation
✓ Help transition to the new support team
 3. The Software Process
Process methodologies (also called models or paradigms)
• How to manage all this phases of the software development process, will depend on the
methodology, and the chosen one is often related with the enterprise culture, way of
working and project needs and goals. We have two big groups:
• Predictive methodologies:
• Customer has clear requirements
• Once approved the requirements do not change
• Development always follows the process: design —> develop —> test
• Software is build in only one shot at the end
• Adaptative methodologies:
• Customer has an idea of what he wants to build
• Development team builds the software by small chunks
• We talk about iterations, and at the end of each one we receive customer feedback
• The final product may not be the first idea, but it’s what the customer really wants
 3. The Software Process
Predictive Adaptative
The predictive method is a Waterfall methodology Adaptive method is an Agile methodology
This is a traditional approach to developing This is an iterative process of development
Changes can not be made easily throughout the The process allows for easy changes during any
development of the project stage of the process
Testing can only be done at the implementation
Testing can be done at any stage
stage
Clients are involved only during selected stages such Clients are involved throughout different
as requirement, scope change, and implementation development stages
Suitable for projects that are fully understood and
Suitable for less certain and complex projects
that are less complex
The methodology is process-oriented The methodology is people-oriented
The Predictive method can be implemented as an The Adaptive method requires partnership or
individual by a team collaboration by all stakeholders
3. The Software Process
3. The Software Process
Waterfall (Predictive methodologies)
 3. The Software Process
Waterfall (Predictive methodologies)
• There are separate identified phases in the waterfall model:
✓ Requirements analysis and definition
✓ System and software design
✓ Implementation and unit testing
✓ Integration and system testing
✓ Operation and maintenance
• The main drawback is the difficulty of accommodating change after the process is underway.
A phase has to be complete before moving onto the next.
• Inflexible partitioning into distinct stages makes it difficult to respond to changing customer
requirements. This model is only appropriate when the requirements are well-understood
and changes will be fairly limited. But few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites. The plan-driven nature of the waterfall model helps coordinate.
3. The Software Process

[Link]
 3. The Software Process
Prototype (Adaptative methodologies)
• In the waterfall model:
• Feedback not obtained until testing pase.
• That implies thinking that no errors were made while producing all design documents.
• This increases dramatically the risk of project failure.

• To overcome this issues, the prototype methodology was proposed.

• The application will be build based on approved prototype.

• A prototype it’s a fast build software that will allow the user to validate and establish
requirements for the final system. A prototype is a working software that only contains the
key features we want to try at a certain moment.
3. The Software Process
Prototype (Adaptative methodologies)
• Although problems can occur, prototyping can
be an effective paradigm.
• The key is to define the rules of the game at
the beginning; that is, all stakeholders should
agree that the prototype is built in part to
serve as a mechanism for defining
requirements.
• It is often desirable to design a prototype so it
can be evolved into the final product. The
reality is developers may need to discard (at
least in part) a prototype to better meet the
evolving needs.
3. The Software Process
Agile (Adaptative methodologies)
• Rapid development and delivery is now often the most important
requirement for software systems
✓ Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements.
✓ Software has to evolve quickly to reflect changing business needs.
• Rapid software development
✓ Specification, design and implementation are inter-leaved.
✓ System is developed as a series of versions with stakeholders
involved in version evaluation.
3. The Software Process
Agile (Adaptative methodologies)
• Dissatisfaction with the overheads involved in software design methods (of
the 1980s and 1990s) led to the creation of agile methods.
• These methods:
✓ Focus on the code rather than the design.
✓ Are based on an iterative approach.
✓ Are intended to deliver working software quickly and evolve to meet
changing requirements.
• The aim of agile methods is to reduce overheads in the software process
(e.g. by limiting documentation) and to be able to respond quickly to
changing requirements without excessive rework.
3. The Software Process

[Link]
 3. The Software Process
Agile
Principle (Adaptative Description
methodologies)
Customer involvement Customers should be closely involved throughout the development process.
• Dissatisfaction Their role is provide and prioritize new system requirements and to evaluate
the iterations of the system.
Incremental delivery The software is developed in increments with the customer specifying the
requirements to be included in each increment.
People not process The skills of the development team should be recognized and exploited. Team
members should be left to develop their own ways of working without
prescriptive processes.
Embrace change Expect the system requirements to change and so design the system to
accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the
development process. Wherever possible, actively work to eliminate
complexity from the system.
3. The Software Process
Agile (Adaptative methodologies)
• Product development where a software company is developing a small or
medium-sized product for sale.

• Custom system development within an organization, where there is a clear

commitment from the customer to become involved in the development
process and where there are not a lot of external rules and regulations that
affect the software.

• Because of their focus on small, tightly-integrated teams, there are

problems in scaling agile methods to large systems.
3. The Software Process
Scrum (Agile)
• Scrum it’s an agile methodology that iterates over sprints.
• This sprints have a fixed duration, between 1 and 4 weeks.
• The tasks for the project are created and added into a list called backlog.
• In this backlog we can find big tasks, that needs to be more defined (epic
stories) and smaller tasks ready to develop.
• This backlog is permanently reviewed and prioritised by the Product Owner
and estimated by the team.
3. The Software Process
3. The Software Process
• And meetings:
• Sprint planning: the entire team gather around and start estimating tasks from the
backlog, and selecting the ones that the team will work on during the sprint. After this
meeting, all the team commits to the sprint backlog.
• Daily meeting: each day, before starting work, the team meets, in a daily standup
meeting, where each one of them answers three questions: what i’ve been working on?
what i’ll be working on? is there any blocking point for me? The maximum duration is 15
minutes, and often a clock is used to not overpass this time.
• Sprint review: the development team demonstrates the completed product increments
to stakeholders, discusses the progress and lessons learned, and collaborates to plan
future improvements and work for the next sprint.
• Sprint retrospective: the development team thinks about the past sprint, identifies
areas for improvement, and collaboratively agrees on actions to make those
improvements, in order to continuously increase effectiveness and efficiency.
3. The Software Process
Scrum (Agile)
• We can find different roles:
• Product Owner: responsible for defining the product backlog, communicating the
product vision, and making decisions about which features should be developed next
to ensure the satisfaction of stakeholders and the success of the project.
• Team: delivering incremental, usable increments of the product, through self-
organization and collaboration, within the constraints of each sprint. In fact, the team
decides what they will be working on on each sprint and they commit to it.
• Scrum Master: helping the development team, removing obstacles to progress, and
ensuring that the Scrum framework and Agile Principles are understood and
followed.
3. The Software Process

[Link]
3. The Software Process
3. The Software Process
Extreme programming XP (Agile)
• Extreme programming (XP) is a well-known agile method that integrates a
range of good programming practices such as frequent releases of the
software, continuous software improvement and customer participation in
the development team.

• Extreme Programming takes an ‘extreme’ approach to iterative

development.
✓ New versions may be built several times per day.
✓ Increments are delivered to customers every 2 weeks.
✓ All tests must be run for every build and the build is only accepted if
tests run successfully.
 3. The Software Process
Extreme programming XP (Agile)
• Incremental development is supported
through small, frequent system releases.
• Customer involvement means full-time
customer engagement with the team.
• People not process through pair
programming, collective ownership and a
process that avoids long working hours.
• Change supported through regular system
releases.
• Maintaining simplicity through constant
refactoring of code.
 3. The Software Process
Principle XP Description
Incremental planning Requirements are recorded on story cards and the stories to be included in a
release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’.
Small releases The minimal useful set of functionality that provides business value is developed
first. Releases of the system are frequent and incrementally add.
Simple design Enough design is carried out to meet the current requirements and no more.

Test-first development An automated unit test framework is used to write tests for a new piece of
functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon as possible
code improvements are found. This keeps the code simple and maintainable.
3. The Software Process
Principle XP Description
Pair programming Developers work in pairs, checking each other’s work and providing the
support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that no islands of
expertise develop and all the developers take responsibility for all of the
code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into the whole
system. After any such integration, all the unit tests in the system must pass.

Sustainable pace Large amounts of overtime are not considered acceptable as the net effect
is often to reduce code quality and medium term productivity.

On-site customer A representative of the end-user of the system (the customer) should be
available full time for the use of the XP team. In an extreme programming
process, the customer is a member of the development team.
Contents
1. What’s Software Engineering
2. Software Quality
3. The Software Process (Software Development Life Cycle)
4. Modeling techniques and Programming paradigms
5. Software Requirements
4. Modeling techniques and Paradigms
• Unified Modelling Language (UML)
• Programming Paradigms: Imperative and Declarative
• Procedural
• Object-Oriented Programming
• Functional
4. Modeling techniques and Programming paradigms
• Models are abstraction that help us to communicate what is important on
the system and help to deal with complexity.
• Modelling techniques are used to represent and visualise different aspects
of software system: requirements, architecture, behaviour and data.
• The goal of modelling is to help understand and communicate the system’s
design and requirements, to facilitate its development and maintenance.
• Techniques used for modeling will also depend on the programming
paradigm. In this course, we will apply those techniques mainly to OOA/D.
• The Unified Modelling Language (UML) is the most popular and
successfull standard for modelling software products.
 4. Modeling techniques and Programming paradigms
• As we will see in the next Modules, some modelling techniques include:
✓ Use case: for functional requirements, interactions between actors and the system
✓ Class modelling: structure and relationships between classes and objects .
✓ State machine: to represent the behaviour of a system in response to events and inputs.
✓ Data modelling: to represent data structures, relationships and constraints of a system.
✓ Architecture: high level structure and relationships between components in a system.

• In the phases of Analysis and Design in OOA/D, models will be build from different perspectives:
✓ Domain modelling: identify key concepts for a specific domain to solve a specific problem.
✓ Specification modelling: elements that compose the solution and high-level description of
the services provided.
✓ Design modelling: describes the software itself, its behaviour to external events and the
different responsibilities for each element of the system .
4. Modeling techniques and Programming paradigms
Programming paradigms
• A programming paradigm is a
style to write computer
programs that defines the
structure, organisation and
nature of the code.
• Sometimes, it is also used as a
classification of programming
languages based on their
features. But most popular
languages support multiple
paradigms (C++, Python etc).
4. Modeling techniques and Programming paradigms
Programming paradigms
Imperative Declarative

How to do things What do do

Statements Expressions
• Statements tell the computer to do something • Expressions evaluate to a value
Changes can not be made easily throughout the The process allows for easy changes during any
development of the project stage of the process

Defining variables and changing their values Evaluate result based on input

Ex: Fortran, C++, Python programming languages

Ex: SQL, HTML programming languages
(C++, Python can be also used in declarative)
4. Modeling techniques and Programming paradigms
Imperative
• In the Imperative style, the programmers instruct the machine How to
perform a task by writing step-by-step instructions including variables,
conditions, loops etc.).
• Algorithms as a sequence of steps .
• Often used synonymously: procedural programming (emphasizing the
concept of using procedure calls(functions) to structure the programing
modular fashion).
• Object-Oriented Programming (OOP) is usually considered a subcategory.
4. Modeling techniques and Programming paradigms
Imperative
• Example: you want to search for an element in an array of numbers, you
write all the instructions to perform the search such as taking input, iterating
the array, checking if the element is found or not, returning the results, etc.
4. Modeling techniques and Programming paradigms
Imperative
• The imperative paradigm is further classified into two types: Procedural and
Object Oriented.
• Procedural oriented: procedural language breaks down a task into a
collection of procedures (subroutines, functions) to perform a task. It
maintains global variables to manage the state of the system. C, BASIC, etc.

• Object-oriented (OOP) breaks down a task into objects that expose

behaviour (method) and data (member or attribute), objects communicate
with each other through message-passing techniques to accomplish a given
task. C++, Java, C#, Kotlin etc belong to the object-oriented paradigm.
4. Modeling techniques and Programming paradigms
Procedural
• Example: linear
search in C
4. Modeling techniques and Programming paradigms
Object-Oriented
• Example: linear
search in Java
4. Modeling techniques and Programming paradigms
Declarative
• The declarative paradigm is classified into two types: Functional and Logical.
• Functional: Functional programming contains only functions without mutating the state or
data. It means that there are no global data/variables. Composing and applying function is
the main driving force in this paradigm. A function can take another as an argument and
return a new function. The first high-level functional programming language, developed in
the 1950s, was LISP. This language laid the foundation for modern functional languages.
• Logical: has its foundations in mathematical logic in which program statements express facts
and rules. Rules are written as logical clauses. The engine infers the answer to the user’s
query by using unification and backtracking techniques. The set of facts and rules forms a
knowledge base, allowing the system to reason. Prolog, Datalog etc are examples of logical
programming. Logical programming helps in major areas such as Natural language
processing, Database management, Pattern matching, and Predictive analysis.
4. Modeling techniques and Programming paradigms
Functional

• Example: factorial
program using
LISP
4. Modeling techniques and Programming paradigms
Logical
• Example: Prolog program to
infer relationship match of
two people from their food
interest knowledge base.

• LP can be made available

with libraries, e.g. For
Python: Pyke (inspired by
Prolog), pyDatalog (inspired
by Datalog)
5. Software Requirements
• GenAI LLMs are changing the paradigm: from coding to prompting, and
its implications
• Developers are shifting from writing syntax to engineering prompts. This
feels more like declarative programming, where you describe the
desired outcome to the LLM, and it generates the implementation
• Examples: Claude Code, Cursor, Windsurf, GitHub Copilot, among others
5. Software Requirements
Paradigm LLM/Agentic role
Declarative This paradigm focuses on what the result should be, rather than the step-by-
Programming step process.
LLM Role: LLMs are exceptional at this. Ex: they can convert natural language
prompts directly into SQL queries or functional code. They thrive in
environments where the logic is math-based or rule-based.
Advantage: LLMs generate declarative code that is often cleaner, more
concise, and less error-prone than imperative equivalents.

Imperative This paradigm focuses on how to achieve a result through explicit steps and
Programming state changes.
LLM Role: LLMs excel at generating boilerplate, translating logic between
languages (e.g., Python to Java), and writing unit tests for imperative code.
Challenge: Because LLMs are probabilistic, they can sometimes generate
imperative code with subtle state-management bugs that are hard to detect
without thorough testing.
Contents
1. What’s Software Engineering
2. Software Quality
3. The Software Process (Software Development Life Cycle)
4. Modeling techniques and Programming paradigms
5. Software Requirements
5. Software Requirements
• Functional and Non-funcional
• Software Requirements Specification
5. Software Requirements
• Software Requirements: the process of establishing the services that the
customer requires from a system and the constraints under which it operates
and is developed.
• The requirements themselves are the descriptions of the system services
and constraints that are generated during the requirements engineering
process.
• It may range from a high-level abstract statement of a service or of a system
constraint to a detailed mathematical functional specification.
 5. Software Requirements
• Functional: expresses the relation between input and output of the system
and its processes
• We answer this questions: what does the software need to do? What’s the
problem we need to solve? What’s the necessary features and capabilities?
• Non functional: defines the quality or restriction that we impose to a system
to realise its function:
✓ Performance: how many users should the app support simultaneously?
✓ Law: what do we need to do in terms of data protection?
✓ Support: how the app should perform when there is an issue?
✓ Security, budget…
 5. Software Requirements
• First, perform a previous analysis or problem comprehension: understand user needs and understand the
associated problematic. How?
✓ Ask users: meetings, surveys…
✓ Compare to other existing systems and select the equal parts
✓ Prototype building
✓ Brainstorming

• And thereater, do an analysis or requirements specification: define what the client wants and generate a
document (Software Requirement Specification or SRS) :

E-Store Project
Software Requirements Specification
Version <4.0>

[Link]

• The software requirements document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the system requirements. It is not a
design document. As far as possible, it should set of What the system should do rather than How it should do it.
 5. Software Requirements
• In order to correctly do the SRS, it must be:
✓ Correct: the requirement are the ones the software must do (not “nice to have” features).
✓ Unambiguous: every statement has only one interpretation, and leaves no room to other.
✓ Complete: contain all significant requirements relating to functionality, performance,
design constraints, attributes and external interfaces.
✓ Modifiable: structure and style may allow any changes done easily and completely while
retaining the structure and style.
✓ Consistent: the document must agree with all other documentation, specially the higher-
level one, usually made before.
✓ Verifiable: all statements must be verifiable by third persons and the team.
✓ Traceable: the origin of each requirement must be clear and facilitates the referencing of
each requirement.
5. Software Requirements
• We can classify requirements according to:

✓ Functionality: features of the system.

✓ Usability: everything that will affect the final user (easy to use,
intuitive…).
✓ Reliability: availability, failure rate, predictability (downtime
accepted, for example).
✓ Performance: speed, efficiency, scalability, resource consumption…
✓ Support: testability, configurability, extensibility…
5. Software Requirements

• Many agile methods argue that producing a requirements document is a

waste of time as requirements change so quickly. The document is
therefore always out of date.

• Methods such as XP use incremental requirements engineering and

express requirements as ‘user stories’ (discussed in Chapter 3).

• This is practical for business systems but problematic for systems that
require a lot of pre-delivery analysis (e.g. critical systems) or systems
developed by several teams.
5. Software Requirements
SRS Chapter (1/2) Description
Preface This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version and
a summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.
Glossary This should define the technical terms used. You should not make
assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The nonfunctional
definition system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that are
understandable to customers. Product and process standards that must be
followed should be specified.
System architecture A high-level overview of the anticipated system architecture, showing the
distribution of functions across system modules.
 5. Software Requirements
SRS Chapter (2/2) Description
System requirements Describe the functional and nonfunctional requirements in more detail.
specification Further detail may also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships
between the system components and the system and its environment.
Examples of possible models are object models, data-flow models, or
semantic data models.
System evolution This should describe the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing
user needs, and so on. This section is useful for system designers as it may
help them avoid design decisions that would constrain likely future changes
to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database
descriptions.