Software

Software = Program + Data + Documentation Software is not just code; it also includes the
data the program uses and the documentation that explains it.

📌 Program

Program: A set of instructions (code) that tells the computer what tasks to perform.

📌 Data

Data: The information or input on which the program operates to produce results.

📌 Documentation

Documentation: Written materials that describe the design, usage, and functionality of the
software.

📌 Engineering (Definition)

Engineering: The productive use of scientific knowledge. It means applying science to create
useful systems, machines, or structures.

📌 Difference between Computer Science and Software Engineering

 Computer Science: The study of theoretical foundations, algorithms, and principles of

computing.
 Software Engineering: The practical application of computer science knowledge to
design, develop, and maintain software systems.

📌 Analogy with Physics

 Physics itself is pure science.

 Using physics to build bridges = Civil Engineering
 Using physics to build engines/cars = Mechanical Engineering
 Using physics to build electronic devices = Electrical Engineering
 Similarly, using computer science to build software systems = Software Engineering

📌 Short Definition for Exams

Software Engineering: It is the process of applying computer science knowledge to the effective
production of software systems.

👉 Ultra-short recall line: Computer Science = Theory Software Engineering = Practical

application of that theory to build software
Software Crisis: It refers to the difficulties faced in the 1960s when traditional methods failed to develop
large and complex software systems. Projects were often incomplete, late, over budget, and unreliable,
which led to the birth of Software Engineering as a disciplined approach to software development.

Software Engineering (IEEE Definition): “It is the application of a systematic, disciplined, and
measurable approach to the development, operation, and maintenance of software — in other
words, applying engineering principles to software.”

👉 Ultra-short version for MCQs: Software Engineering = Applying engineering principles to

software development and maintenance.

Software Engineering: It is the set of processes, tools, and techniques used to design, develop,
test, and maintain software systems.

📌 Key Components of Software Engineering

 Programming Languages (e.g., Java, C++)

 Programming Language Design
 Software Design Techniques
 Tools (CASE tools, IDEs)
 Testing (unit, integration, system testing)
 Maintenance (bug fixing, updates)
 Development (coding, implementation)

📌 Well-Engineered Software

Definition: Well-engineered software is software that is reliable, user-friendly, performs

acceptably, maintains good quality, and is cost-effective.

📌 Key Characteristics

 Reliable → Works correctly and consistently.

 Good User Interface → Easy and intuitive for users.
 Acceptable Performance → Runs efficiently without delays.
 Quality → Meets standards and expectations.
 Cost-effective → Achieves goals within limited resources.

Therefore well-engineered software has the following characteristics.

 Provides the required functionality

 Maintainable

 Reliable
 Efficient

 User-friendly

 Cost-effective

📌 The Balancing Act in Software Engineering

Definition: Software Engineering is a balancing act where the engineer must deliver software
that is functional, maintainable, reliable, efficient, user-friendly, and cost-effective — all within
limited time and budget.

Because these goals often conflict (e.g., cost vs. efficiency, cost vs. reliability, efficiency vs.
user-interface), the software engineer must analyze trade-offs and strike the right balance
depending on the project’s priorities.

📌 Caper Jones’ Contribution

 Caper Jones was a famous researcher in Software Engineering.

 He studied software team productivity, quality, cost factors, and related fields.
 He founded a company called Software Productivity Research, where they analyzed
about 10,000 projects.
 He categorized software activities into 25 categories (but we usually focus on 9 main
ones):
o Project Management
o Requirement Engineering
o Design
o Coding
o Testing
o Software Quality Assurance
o Software Configuration Management
o Software Integration
o Other activities

👉 Important Point: Coding is only 13–14% of the total effort in software development. The rest
of the effort goes into management, design, testing, and other activities.

📌 Fred Brooks – “No Silver Bullet”

 Fred Brooks, another renowned software engineer, wrote the book “The Mythical Man-
Month.”
 In it, he included the famous article “No Silver Bullet.”
 Key idea:
o There is no magical solution (“silver bullet”) to instantly solve software
problems like cost overruns, delays, or bugs.
 o The only way to improve software development is through a disciplined,
systematic engineering approach.
o Progress will be step by step, not through sudden breakthroughs.

📌 Short Exam Definition

Caper Jones: Researched software productivity and showed that coding is only a small part (13–
14%) of software effort. Fred Brooks – No Silver Bullet: There is no magical solution to
software problems; only disciplined engineering can improve development.

LECTURE2

Software Development

Software development is a disciplined approach that involves two major categories of

activities:

1. Construction Activities (direct development tasks)

 Requirement Gathering → Collecting user needs.

 Design Development → Creating system design.
 Coding → Writing the actual program.
 Testing → Checking and fixing errors.

2. Management Activities (supporting/umbrella tasks)

 Project Planning & Management → Scheduling, budgeting, monitoring.

 Configuration Management → Handling versions and changes.
 Software Quality Assurance → Ensuring standards and reliability.
 Installation & Training → Deploying software and training users.

📌 Key Point

 Construction = Core development work

 Management = Umbrella activities that ensure construction runs smoothly.
 Together, they make the software development process effective and organized.

👉 Ultra-short exam definition: Software Development = Construction (requirements,

design, coding, testing) + Management (planning, QA, configuration, training).

A software engineering framework is built on an organization’s commitment to quality. It

ensures that software is developed in a systematic, timely, and cost-effective way.

📌 Major Components

1. Quality Focus
 oFoundation of the framework.
oEmphasizes defining processes and maintaining quality at every stage.
2. Processes
o Set of Key Process Areas (KPAs).
o Define tasks, their order, deliverables, and milestones for effective management.
3. Methods
o Provide the technical “how-to” for performing tasks.
o Different techniques can be applied depending on the situation.
4. Tools
o Automated or semi-automated support.
o Help in processes, methods, and quality control (e.g., CASE tools, testing tools).

📌 Short Exam Definition

Software Engineering Framework: It is a structured approach based on quality focus,

processes, methods, and tools to ensure cost-effective and reliable software development.

👉 Ultra-short recall line: Framework = Quality Focus + Processes + Methods + Tools

📌 Software Development Loop

The Software Development Loop shows that software development is a cyclic process. After
deployment, new requirements may arise, and the cycle repeats.

📌 Major Stages

1. Problem Definition
o Identify and understand the problem.
o Gather requirements of the system to be built.
2. Technical Development
o Find a technical solution.
o Design and implement the new system.
3. Solution Integration
o Integrate the new system with already existing systems.
o Ensure compatibility and smooth interaction.
4. Status Quo
o Deploy the system at the user site.
o This becomes the current working state until new requirements arise.
o Once new requirements come, the cycle starts again.

📌 Key Point

 The loop ensures continuous evolution of software.

 Software can be easily updated and integrated with existing systems.
👉 Ultra-short exam definition: Software Development Loop = Cyclic process: Problem
Definition → Technical Development → Solution Integration → Status Quo → Repeat with
new requirements.

📌 Software Engineering Phases

Software development is divided into four basic phases:

1. Vision
o Define why the software is being developed.
o Identify business objectives and goals.
2. Definition
o Translate the vision into clear requirements.
o Determine activities and scope of the system.
3. Development
o Design the system architecture.
o Implement (coding) and test the software.
4. Maintenance
o Control changes after deployment.
o Handle enhancements and bug fixes.
o Note: For long-lifetime systems, maintenance cost often exceeds development
cost (2–3 times higher).

📌 Short Exam Definition

Software Engineering Phases = Vision (why) → Definition (what) → Development (how) →

Maintenance (support & change).

👉 Ultra-short recall line: Phases = Vision + Definition + Development + Maintenance

Software Requirements – Key Definitions

 Jones: A software requirement is a statement of needs by a user that triggers the

development of a program or system.
 Alan Davis: A requirement is a user need or necessary feature, function, or attribute of a
system that can be observed externally.
 Ian Sommerville: Requirements are a specification of what should be implemented —
describing system behavior, properties, or constraints.


IEEE:

1. A condition or capability needed by a user to solve a problem or achieve an objective.

2. A condition or capability that must be met by a system or component to satisfy a contract,
standard, or specification.
3. A documented representation of such a condition or capability.
  Poor requirements = major cause of defects.
o Studies show 40–60% of software defects come from weak requirement
gathering/documentation.
 Fred Brooks (Mythical Man-Month):
o The hardest part of building software is deciding exactly what to build.
o Wrong requirements cripple the system and are very costly to fix later.
 Analogy:
o Like building a house: changing rooms after construction is expensive, but easy if
caught at the map stage.
 Cost Impact:
o Fixing errors after development can cost 68–200 times more than fixing them
early (Boehm, 1981).
 Conclusion:
o Sound requirements are the most critical success factor for any project.

📌 Role of Requirements

 Central role in software development.

 Used in:
o Project Planning & Feasibility: Estimate time, resources, and scope.
o Design & Coding: Acts as the base reference document.
o User Documentation & Testing: Guides deliverables.
o Project Management: Helps monitor progress and manage scope changes.
 Key Point:
o The requirement document is the foundation for all phases of development.

📌 Ultra-short exam definition

Importance: Poor requirements cause most defects; fixing late is very costly. Role:
Requirement document guides planning, design, coding, testing, and project management.

Levels of Software Requirements

1. Business Requirements
o High-level objectives of the organization or customer.
o Define why the system is needed and its main features.
o Captured in the vision and scope document.
2. User Requirements
o Written from the user’s perspective.
o Describe tasks the user must be able to perform.
o Captured in the requirement definition document.
3. Functional Requirements
o System’s perspective.
o Define the software functionality developers must build to satisfy user needs.
o Example: Spell checker finds errors, shows suggestions, allows replacements.
 4. Non-Functional Requirements
o Constraints and quality attributes.
o Define performance, reliability, platform, standards, and external interfaces.
o Example: Spell checker must run on Windows platform.

📌 Example (Spell Checker)

 Business Requirement: User should be able to correct spelling errors efficiently.

 User Requirement: User can find errors and choose replacements from suggestions.
 Functional Requirement: System highlights errors, shows dialog box with suggestions,
allows replacements.
 Non-Functional Requirement: Must integrate into existing word processor on
Windows.

📌 Ultra-short exam definition

Levels of Requirements = Business (why) → User (tasks) → Functional (system

functionality) → Non-functional (constraints & quality).

Stakeholders

Stakeholders are different people who would be interested in the software. It is important to recognize
that management carries a lot of weight, but they usually are not the actual users of the system.

📌 Requirement Statement Characteristics

A good Requirement Statement must be:

 Complete → Fully describes the functionality to be delivered.

 Correct → Accurately describes what is to be built.
 Feasible → Possible to implement within system/environment limits.
 Necessary → Documents only what the customer truly needs or what standards require.
 Prioritized → Each requirement has an assigned importance for release planning.
 Unambiguous → Clear, with only one interpretation for all readers.
 Verifiable → Can be tested, inspected, or demonstrated to confirm implementation.

📌 Requirement Specification Characteristics

A good Requirement Specification Document must be:

 Complete → No requirement or necessary information missing.

 Consistent → No conflicts among requirements or with higher-level system/business
needs.
 Modifiable → Can be revised when necessary, with change history maintained.
 Traceable → Each requirement can be linked to its origin, design, code, and test cases.
📌 Key Point – Conflicts & Abstraction

 Example of conflict (non-functional):

o “All programs must be written in Ada” vs. “Program must fit in micro-controller
memory” → Ada compiler output too large.
 Example of conflict (functional):
o “System must monitor all temperatures” vs. “System should only monitor below -
200°C and above 4000°C.”
 Mixed Abstraction Problem:
o Requirements must be at a uniform level of detail.
o Example: “System tracks warehouse stock” (high-level) vs. “Loading clerk enters
withdraw command” (too detailed).

📌 Ultra-short exam definition

Requirement Statement: Clear, complete, feasible, necessary, prioritized, unambiguous, and

verifiable. Requirement Specification: Complete, consistent, modifiable, and traceable.

📌 Relationship of Requirements and Documents in Software Engineering

During the Requirement Engineering phase, several documents are produced. These
documents are interconnected and show how requirements evolve from high-level goals to
detailed specifications.

📌 Key Components & Their Relationships

1. Business Requirements Document (Vision & Scope)

o States the high-level objectives of the organization.
o Forms the foundation for all other requirement documents.
2. User Requirements Document (Requirement Definition)
o Derived from business requirements.
o Written from the user’s perspective (tasks users must perform).
3. Functional Requirements Specification
o Derived from user requirements.
o Defines the system’s functionality developers must implement.
4. Non-Functional Requirements Specification
o Defines constraints, quality attributes, performance, standards, and external
interfaces.
o Works alongside functional requirements to shape system architecture.
5. Software Requirement Specification (SRS)
o Consolidates functional + non-functional requirements into one formal
document.
o Serves as the central reference for design, coding, testing, and project
management.
📌 Relationship Flow (Simplified)

Business Requirements → User Requirements → Functional Requirements → Non-

Functional Requirements → SRS

Each level refines the previous one, ensuring alignment from business goals down to technical
implementation.

👉 Ultra-short exam definition: The relationship among requirement documents shows how
business needs evolve into user requirements, then into functional and non-functional
requirements, all consolidated in the SRS.

Scope in Software Engineering

Definition: Project scope defines the concept and boundaries of the proposed solution. It
specifies what the system will include and what it will not include.

 Scope: Explains the range of features, functions, and objectives of the software.
 Limitations: Identify the capabilities or features that are excluded from the product.

📌 Context Diagram

 Definition: A context diagram is a top-level abstraction that shows the boundary

between the system being developed and the external world.
 Key Points:
o Identifies external entities (terminators) that interact with the system.
o Shows data flow between the system and these external entities.
o Used as the top-level view in a Data Flow Diagram (DFD).
o Can be included in the Vision & Scope document, SRS, or dataflow models.

👉 Ultra-short exam definition: Context Diagram = Graphical boundary of system +

external entities + data flow.

📌 Use Cases & Customer-Developer Relationship

 Good requirements = good communication between customer and developer.

 Software engineers must understand the business domain, not just computer science.
 Documents should use domain terminology so customers can easily understand.
 Use Case Modeling:
o Developed by Ivar Jacobson.
o Describes what a new system should do or what an existing system already does.
o Part of UML (Unified Modeling Language).
o Intuitive and easy to discuss with customers (even if they don’t know UML).
o Helps create a requirement specification agreed by both customer and
developer.
📌 Use Case Model Components

A Use Case Model has two main components:

1. Actors
oExternal entities that interact with the system.
oCan be humans, devices, or other systems.
oRepresent roles, not individuals (e.g., Book Borrower, Librarian).
2. Use Cases
o Functionalities provided by the system.
o Each use case represents a complete interaction from initiation by an actor until
the requested functionality is delivered.
o Must always deliver value to the actor.

👉 The system is treated as a black box: only external interfaces and interactions are shown, not
internal details.

📌 Example – Library Management System

 Actors: Book Borrower, Librarian, Browser, Journal Borrower.

 Use Cases: Reserve Book, Borrow Book, Return Book, Extend Loan, etc.
 Each actor interacts with specific use cases inside the system boundary.

📌 Creating a Use Case Model

 Iterative process:
1. Identify actors.
2. Define use cases for each actor.
3. Establish relationships among use cases.
 Activities are parallel and evolving until no new actors/use cases are discovered.
 Finally, the model is validated.

📌 Relationship Among Use Cases (UML)

1. Uses Relationship
o One use case invokes steps of another during execution.
o Similar to a function call.
o Example: Delete Information use case uses Record Transaction and Cancel
Transaction.
2. Extends Relationship
o A new use case is a specialization of an existing one.
o Inherits properties and actors of the base use case.
o Example: Place Conference Call extends Place Phone Call.
📌 Reusability of Actors

 Actors can also be extended into subclasses.

 Example:
o Customer actor extended into Individual Customer and Corporate Customer.
o Both inherit all use cases available to the base Customer.

📌 Ultra-short exam definition

Use Case Model = Actors (external entities) + Use Cases (system functionalities).
Relationships: Uses (invokes another use case), Extends (specialization of existing use case).

📌 Elaborated Use Case Components

When a use case model is derived, each use case is elaborated with detailed interaction between
the actor and the system. An elaborated use case includes:

1. Use Case Name → Title of the functionality.

2. Implementation Priority → Relative importance/order of implementation.
3. Actors → Entities (human/system) interacting with the use case.
4. Summary → Brief description of the functionality.
5. Precondition → Conditions that must be true before execution.
6. Post-condition → System state after successful completion.
7. Extend → Any use case it extends.
8. Uses → Other use cases it invokes.
9. Normal Course of Events → Step-by-step sequence of actions.
10. Alternative Path → Deviations from the normal flow.
11. Exception → Actions when errors or exceptional conditions occur.
12. Assumptions → Assumptions made for this use case.

📌 Example – Delete Information Use Case

 Name: Delete Information

 Priority: 3
 Actors: User
 Summary: Allows permanent deletion of information not in use.
 Precondition: Information must exist in the system.
 Post-condition: Information is permanently removed.
 Uses: Record Transaction, Cancel Action
 Extends: None
 Normal Flow: User selects → System asks confirmation → User confirms → System
deletes → Records transaction.
 Alternative Path: User cancels deletion → Cancel Action invoked.
 Exceptions:
o Cannot delete information currently in use.
o Cannot delete a user with subordinates.
  Assumptions:
o Deletion = permanent removal of entire data sets.
o Deleted info is not retained.
o Only unused information can be deleted.

📌 Alternative Documentation Style

 Some organizations prefer two-column format:

o User Action vs. System Reaction (step-by-step).
o Example: User requests deletion → System asks confirmation → User confirms
→ System deletes.

📌 Activity Diagrams

 Provide a pictorial flow of the use case (like a flowchart).

 Show transitions: Choose Object → Initiate Deletion → Confirm/Delete Allowed/Cancel
→ Record Action → Object Deleted/Maintained.
 Express the dynamic aspect of the system.

📌 Limitations of Use Cases

 Use cases describe the system as a black box (external perspective only).
 They do not capture non-functional requirements such as:
o Usability: e.g., color-blind accessibility.
o Reliability: 24/7 operation.
o Performance: Authorization within 1 minute, average ≤ 30 seconds.
o Portability: Must run on Windows & Solaris.
o Access/Security: Internet accessibility with secure login.

👉 Therefore, use cases must be augmented with additional documentation for non-functional
requirements, business rules, and legal constraints.

📌 Ultra-short exam definition

Elaborated Use Case = Name + Priority + Actors + Summary + Preconditions + Post-

conditions + Uses/Extends + Normal Flow + Alternatives + Exceptions + Assumptions.
Limitation: Use cases don’t cover non-functional requirements (usability, reliability,
performance, portability, security).

📌 Source and Sink Analysis

1. Source

 Origin of a requirement.
 Could be a stakeholder, organization, or external entity that initiates an action.
  Example: A person entering data into the system → source of that requirement.

2. Sink

 Consumer of information.
 Logical end of a business process.
 Example: A user reviewing a report generated by the system → sink of that requirement.

📌 Why Source & Sink Analysis is Important

 Ensures completeness and consistency of requirements.

 Helps identify:
o Redundant inputs (sources with no outputs).
o Missing outputs (sinks not initially recorded).
 Example:
o If a report is required (sink) but no source of data is defined → requirement is
incomplete.
o If inputs exist but no outputs → either redundant or missing requirements.

📌 Role in Requirement Engineering

 Analyst traces requirements end-to-end (from source to sink).

 Guarantees that every input has a meaningful output and every output has a valid input.
 Supports better understanding of the business domain.

📌 Key Point

Source = Where requirement originates. Sink = Where requirement is consumed. Analysis

= Match sources to sinks to ensure complete, non-redundant requirements.

State Transition Diagrams

State transition diagrams (STDs) are another technique to document domain knowledge. In many cases,
information flows from one place to the other and at each place certain action is taken on that piece of
information before it moves to the next place

A Trouble report and its life cycle – and introduction

A “trouble” in a communications network is a problem that has an adverse effect on the quality of
service perceived by network users.

Trouble report states and status

Following is a description of states of a trouble report.

Queued
A trouble report is in a queued state when it has been instantiated but the trouble resolution process
has not yet been initiated

📌 Open/Active Trouble Report

 A trouble report becomes open/active when actions to resolve the issue are initiated.
 At this stage, the report is not yet closed because the problem is still being worked on.
 An open/active report can be:
o Referred → Sent to another Hand-off Person for handling.
o Transferred → Assigned to another Responsible Person for further processing.

Deferred

This state indicates that corrective action to resolve the trouble has been postponed.

Cleared

A trouble report is moved by the agent to the “cleared” state when it determines that the trouble has
been resolved.

Closed

This state indicates that the trouble resolution process is complete

Disabled

A “disabled” value is exhibited when a trouble report’s information cannot be updated due to local
conditions. In the “disabled” condition only read operations can be performed.

DFD

 Processes on a data flow can operate in parallel.

 Looping and branching are typically not shown.

 Each process path may have a very different timing.

Flow Chart

 Processes on flowcharts are sequential.

 Show the sequence of steps as an algorithm and hence looping and branching are part of flowcharts

CRUD Operations

These are four operations as describes below

 Create: creates data and stores it.

 Read: retrieves the stored data for viewing.

 Update: makes changes in an stored data.

 Delete: deletes an already stored data permanently

Motivation for GUI

 System users often judge a system by its interface rather than its functionality  A poorly designed
interface can cause a user to make catastrophic errors  Poor user interface design is the reason why so
many software systems are never used