SOFTWARE ENGINEERING-BSE53

CLASS : III B.Sc. CS

1. Desirable properties
Six of the most important quality characteristics are maintainability, correctness,
reusability, reliability, portability, and efficiency. Maintainability is "the ease with which
changes can be made to satisfy new requirements or to correct deficiencies" .

2. Structure of A Data Dictionary Entry.

A data dictionary contains metadata i.e data about the database. The data
dictionary is very important as it contains information such as what is in the database, who
is allowed to access it, where is the database physically stored etc. ... Table constraints such
as primary key attributes, foreign key information etc.

3. List out the major benefits of design techniques.

 Understand system development process as a life cycle

 Take Requirements and formulate a problem statement.
 Learn that an algorithm is a formal way to describe a solution
 Define an algorithm with pseudo code or visually as a flowchart
 Translate flowchart to code
 Test in simulator (Test → Write code → Test → Write code … cycle)
 Run on real board

4. Languages and processors for Requirements Specification .

When specifying software requirements, several languages and tools (often called
requirements specification languages or specification processors) can be used, depending on
the level of formality and the goals of the specification. These languages fall on a spectrum
from informal (natural language) to formal (mathematically precise). Here's a categorized
overview:

Informal and Semi-Formal Languages

These are easier to understand but can be ambiguous.

1. Natural Language

 Used in documents like Software Requirements Specifications (SRS).

 Pros: Easy to understand.
 Cons: Ambiguity, inconsistency, and lack of precision.

2. Structured Language / Templates

 Use constrained natural language with templates like EARS (Easy Approach to
Requirements Syntax) or Planguage.
 Example template: "The system shall [do something] when [condition]."

3. Use Case and User Story Formats

 UML (Unified Modeling Language): Includes Use Case diagrams, Activity

Diagrams.
  SysML (Systems Modeling Language): For systems engineering.
 User Stories: Common in Agile (e.g., “As a user, I want...”).

Semi-Formal Specification Languages

More structured than natural language, but not fully formal.

4. UML/OCL

 UML: For modeling system structure and behavior.

 OCL (Object Constraint Language): Adds precision to UML models.

5. Statecharts and Finite State Machines

 Graphical tools used for behavior modeling (e.g., in embedded systems).

6. Petri Nets

 Used to model concurrency and workflows in distributed systems.

Formal Specification Languages

Mathematically rigorous and often machine-processable.

7. Z Notation

 Set-theoretic language for precise functional specifications.

8. VDM (Vienna Development Method)

 Model-based formal method used in critical systems.

9. B-Method / Event-B

 Used in systems requiring proof of correctness (e.g., railway systems).

10. Alloy

 Lightweight formal language for modeling and checking software designs.

11. TLA+ (Temporal Logic of Actions)

 Developed by Leslie Lamport for specifying concurrent and distributed systems.

Tools and Processors

These help parse, verify, or simulate requirements written in the above languages:

 SPARK Ada – Formal method + programming.

 Rodin – IDE for Event-B.
 Alloy Analyzer – Analyzer for Alloy models.
 ProB – Animator and model checker for B and Event-B.
 TLA+ Toolbox – IDE for TLA+.
Summary Table

Language/Tool Type Use Case

Natural Language Informal General documentation

UML + OCL Semi-formal Visual + constraints modeling

Z, VDM, B Formal Mission-critical systems

Alloy, TLA+ Formal Model checking, concurrency

5. Staffing-Level Estimation.

Staffing Level Estimation: Putnam's Work

Putnam analyzed that characteristic of software development and staffing has some
characteristics of R and D projects studied by Norden and Rayleigh Norden Curve can be
used to Relate the Number of delivered lines of code to the effort and the time required to
develop the project.

L=CkK1/3td4/3
k= total effort expended in PM in product development.
L= the product size in KLOC
td= time required to develop the software
Ck = state of Technology constraints
like Ck=2(poor development environment)
Ck=8 (good software development environment)
Ck=11 (Excellent environment)
6. Estimating Software Maintenance Costs.
Software maintenance typically requires 40 to 60 percent, and in some cases as much as
90 percent, of the total lifecycle effort devoted to a a software product.
The major concerns about maintenance during the planning phases of a software projects
are estimating the number of maintenance programmers that will be needed and specifying the
facilities required for maintenance.
A widely used rule of thumb for the distribution of maintenance activities is
60% - Enhancement
20% - Adaptation
20% - Corrections
In survey 487 business data processing installations,Lientz and swanson determined that
typical level of effort devoted to software maintenance was around

50% of total lifestyle effort

The distribution of maintenance activities was
 51.3% for enhancement,
23.6% for adaptation,
21.7% for repair and 3.4% for others

7. Write a short notes about Formal Specification Techniques.

Formal specification techniques are mathematical approaches used to define the behavior,
functions, and constraints of a software system precisely and unambiguously. These
techniques use formal logic, set theory, and algebra to create models of system requirements,
which help in early detection of errors, improved documentation, and better system
verification.

Key Points:

1. Purpose:
o Specify what a system should do without describing how it should do it.
o Enhance the clarity and consistency of requirements.
o Enable rigorous verification and validation.
2. Benefits:
o Reduces ambiguity and misunderstandings.
o Facilitates early error detection and correction.
o Supports automated verification and test case generation.
3. Common Formal Specification Techniques:
o Z Notation: Based on set theory and first-order predicate logic; widely used
for specifying data and operations.
o VDM (Vienna Development Method): Focuses on data types and functions;
used for modeling and verification.
o B Method: Used in software development with formal proofs for correctness.
o Alloy: A lightweight modeling language that uses relational logic and allows
simulation and checking.
4. Challenges:
o Requires expertise in formal methods and mathematical logic.
o Can be time-consuming and expensive for small projects.
o Tool support and scalability may be limited for large systems.

Formal specifications are especially valuable in safety-critical systems (like avionics, medical
devices, and nuclear systems) where precision and correctness are crucial.

8. Software Requirements Specification.

A Software Requirements Specification (SRS) is a comprehensive document that defines

the intended functionality, performance, constraints, and interfaces of a software system. It
acts as a bridge between the customer’s needs and the developer’s implementation.

Key Points:
1. Purpose:
o Clearly describe what the software will do.
o Serve as a reference for developers, testers, and stakeholders.
o Provide a basis for validation, verification, and future maintenance.
2. Contents of an SRS Document:
o Introduction: Purpose, scope, definitions, and overview.
o Overall Description: Product perspective, user needs, assumptions.
 o Functional Requirements: Detailed description of system behaviors and
features.
o Non-Functional Requirements: Performance, reliability, security, usability.
o External Interface Requirements: Interactions with hardware, software, and
users.

Functional Requirements

These describe the core functions or features the system must perform. Each requirement
typically includes:

 Input: What the user or system provides.

 Behavior: The processing or logic the system must apply.
 Output: The result or response.
 Example:
FR-1: The system shall allow users to log in using a username and password.

Non-Functional Requirements

These define how the system performs its functions, covering quality attributes such as:

 Performance: e.g., response time, throughput.

 Reliability: e.g., uptime, fault tolerance.
 Security: e.g., data encryption, user authentication.
 Usability: e.g., user interface design, accessibility.
 Maintainability and Portability: e.g., ease of updates, compatibility.

External Interface Requirements

These specify interactions with:

 User interfaces: Screens, buttons, forms.

 Hardware interfaces: Devices like sensors, printers.
 Software interfaces: APIs, databases, third-party tools.
 Communication interfaces: Network protocols, data formats.

This section ensures that developers, testers, and stakeholders have a clear and testable set
of criteria for building and validating the software system.

3. Characteristics of a Good SRS:

o Correct: Accurately reflects customer requirements.
o Unambiguous: Clear and precise language with no confusion.
o Complete: Includes all necessary requirements and scenarios.
o Consistent: No conflicting requirements.
o Verifiable: Each requirement can be tested.
o Modifiable: Easy to update when changes occur.
o Traceable: Each requirement can be tracked through development.
4. Benefits:
o Improves communication among stakeholders.
o Helps in project planning, design, and testing.
o Reduces development time and cost by preventing rework.