UNIT-3

Requirement Analysis & Specification:

Software Requirement Analysis simply means complete study, analyzing, describing software
requirements so that requirements that are genuine and needed can be fulfilled to solve problem.
There are several activities involved in analyzing Software requirements. Some of them are given
below:

Requirements Gathering
Requirements gathering is a crucial phase in the software development life cycle (SDLC) and project
management. It involves collecting, documenting, and managing the requirements that define the
features and functionalities of a system or application. The success of a project often depends on the
accuracy and completeness of the gathered requirements in software.

Software Requirement Specification

Software Requirement Specification (SRS) Format as the name suggests, is a complete
specification and description of requirements of the software that need to be fulfilled for the
successful development of the software system. These requirements can be functional as well as
non-functional depending upon the type of requirement.

Uses of SRS document

 Development team require it for developing product according to the need.

 Test plans are generated by testing group based on the describe external behaviour.

 Maintenance and support sta need it to understand what the software product is supposed to
do.

 Project manager base their plans and estimates of schedule, e ort and resources on it.

 customer rely on it to know that product they can expect.

1
  As a contract between developer and customer.

 in documentation purpose.

Formal System Specification:

Formal system specification is the use of mathematically precise language and notation to define a
software system's behaviour, properties, and requirements. It aims to eliminate ambiguity, improve
clarity, and enable formal analysis, verification, and even automated code generation. This is a part of
the broader field of formal methods, and approaches include model-based, algebraic, and state-
based specifications.

Key Aspects:

 Precision and ambiguity: Formal specifications use mathematical notation to ensure that
descriptions are precise and unambiguous, removing areas of doubt that can exist in natural
language.
 Mathematical foundations: They are grounded in formal logic and discrete mathematics, using
concepts like sets, relations, and functions to describe states and operations.
 Early error detection: Performing formal analysis early in the development lifecycle allows for
the detection and correction of errors when they are cheapest to fix, rather than after the
system is built.
 Verification and analysis: The mathematical nature allows for rigorous analysis and verification
of system properties. It is possible to prove that an implementation meets its specification
without running the system.
 Facilitates communication: It provides a clear, shared understanding of the system's
requirements for all stakeholders, including developers, testers, and project managers.
 Enables automated tasks: In some cases, formal specifications can be used to automatically
generate code or test cases.

Axiomatic Specification:
In the Axiomatic Specification of a system, first-order logic used to write the pre-and post-conditions
to specify the operations of the system in the form of axioms. The pre-conditions capture the
conditions that must be satisfied before an operation can successfully be invoked.

In essence, the pre-conditions capture the requirements on the input parameters of a

function. The post-conditions are the conditions that must be satisfied when a function post-
conditions are essentially constraints on the results produced for the function execution to be
considered successful.

Algebraic Specification:
In the Algebraic Specification technique, an object class or type is specified in terms of relationships
existing between the operations defined on that type. It was first brought into prominence
by Guttag (1980-1985) in the specification of abstract data types. Various notations of algebraic
specifications have evolved, including those based on OBJ and Larch languages.

2
Essentially, algebraic specifications define a system as a heterogeneous algebra. A heterogeneous
algebra is a collection of different sets on which several operations are defined. Traditional algebras
are homogeneous. A
homogeneous algebra consists of a single set and several operations defined in this set such as – { +,
-, *, / }.

Executable Specification:

An executable specification in software engineering is a written specification that can be executed

by a machine to validate a system's implementation, serving as a form of automated, high-level
testing. It bridges the gap between a software's requirements and its implementation by acting as a
test oracle, ensuring that the final product behaves as intended, and can even be used to generate
other artifacts like documentation or test data.

Key Aspects and Benefits:

 Validation: They are used to validate the software against requirements and acceptance
criteria, ensuring the system delivers on business needs.
 Automated testing: They function as automated acceptance and regression tests that can be
run as part of the build process to check new features and ensure existing ones haven't been
broken.
 High-level abstraction: They are executed at a higher level of abstraction than the final code,
which makes them useful for validating the system's behavior without getting bogged down in
implementation details.
 Communication and collaboration: Written in a common, often plain-language format like
Gherkin (used by tools like Cucumber), they improve communication among stakeholders,
including developers, testers, and business analysts.
4GL:
A Fourth Generation (Programming) Language (4GL) is a grouping of programming languages that
attempt to get closer than 3GLs to human language, a form of thinking, and conceptualization and are
easier to use than 3GLs. It is a non-procedural language which means that the programmer defines
what has to be done instead of how the task is to be completed. 4GL is more familiar and similar to
human language. A compiler translates the whole program once i.e. it generates the object code for
the program along with the list of errors. The execution is very fast. It allows users to develop software.
These languages are usually designed for specific purposes and are commonly used in database
programming and scripts such as PHP, PYTHON, SQL and many more. 4GLs make programming
easier, more e icient, and more e ective for users with less programming skills.

4th generation language is also known as a domain-specific language or a high-productivity language.

SOFTWARE DESIGN
Software Design Process is the phase where developers plan how to turn a set of requirements into a
working system. Like a blueprint for the software. Instead of going straight into writing code,
developers break down complex requirements into smaller, manageable pieces, design the system
architecture, and decide how everything will fit together and work.

The software design process can be divided into the following three levels or phases of design:

3
1. Interface Design

Interface Design is the specification of the interaction between a system and its environment. This
phase proceeds at a high level of abstraction with respect to the inner workings of the system i.e,
during interface design, the internal of the systems are completely ignored, and the system is treated
as a black box. Attention is focused on the dialogue between the target system and the users, devices,
and other systems with which it interacts. The design problem statement produced during the
problem analysis step should identify the people, other systems, and devices which are collectively
called agents.

Interface design should include the following details:

1. Precise description of events in the environment, or messages from agents to which the
system must respond.

2. Precise description of the events or messages that the system must produce.

3. Specification of the data, and the formats of the data coming into and going out of the system.

4. Specification of the ordering and timing relationships between incoming events or messages,
and outgoing events or outputs.

2. Architectural Design

Architectural design is the specification of the major components of a system, their responsibilities,
properties, interfaces, and the relationships and interactions between them. In architectural design,
the overall structure of the system is chosen, but the internal details of major components are
ignored. Issues in architectural design includes:

1. Gross decomposition of the systems into major components.

2. Allocation of functional responsibilities to components.

3. Component Interfaces.

4. Component scaling and performance properties, resource consumption properties, reliability

properties, and so forth.

5. Communication and interaction between components.

4
The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.

3. Detailed Design

Detailed design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures. The detailed
design may include:

1. Decomposition of major system components into program units.

2. Allocation of functional responsibilities to units.

3. User interfaces.

4. Unit states and state changes.

5. Data and control interaction between units.

6. Data packaging and implementation, including issues of scope and visibility of program
elements.

7. Algorithms and data structures.

CHARACTERIZE GOOD SOFTWARE DESIGN

Good software design is characterized by functionality, reliability, and usability, ensuring it meets
requirements, operates correctly, and is easy to use. Other key characteristics include maintainability
(ease of modification and bug fixing), scalability (ability to handle growth), security (protection against
attacks), and performance (e iciency and responsiveness). Additionally, designs should be modular,
cohesive, and have low coupling to promote maintainability and flexibility.

Core attributes:

 Functionality: The software performs its core functions as specified in the design.
 Reliability: The software consistently and correctly carries out its operations.
 Usability: The software is simple, easy to use, and intuitive for the user.
 Maintainability: The software can be easily updated, modified, and fixed with minimal e ort.
 Scalability: The software can handle a growing volume of work or users.
 Security: The software is protected against unauthorized access, data breaches, and attacks.
 Performance: The software operates e iciently in terms of speed, response time, and resource
usage.

Cohesion & Coupling:

Coupling refers to the degree of interdependence between software modules. High coupling means
that modules are closely connected and changes in one module may a ect other modules. Low
coupling means that modules are independent, and changes in one module have little impact on
other modules.

5
Cohesion refers to the degree to which elements within a module work together to fulfill a single,
well-defined purpose. High cohesion means that elements are closely related and focused on a single
purpose, while low cohesion means that elements are loosely related and serve multiple purposes.

Both coupling and cohesion are important factors in determining the maintainability, scalability, and
reliability of a software system. High coupling and low cohesion can make a system di icult to change
and test, while low coupling and high cohesion make a system easier to maintain and improve.

Layered arrangements of Modules:

A layered arrangement of modules in software engineering organizes a system into distinct,
hierarchical layers based on functionality, where each layer provides services to the one above it and
uses services from the one below it. This design pattern promotes modularity and separation of
concerns, making the system easier to maintain, update, and scale. A typical arrangement includes a
Presentation (UI) layer, a Business Logic layer, a Persistence layer, and a Data layer.

6
How it works:

 Hierarchical structure: Modules are divided into layers, arranged from top to bottom (e.g.,
Presentation, Business, Data).
 Service interaction: A module in a higher layer can only call modules in a lower layer, and it can
only call modules in the layer immediately below it.
 Encapsulation: Each layer is responsible for a specific set of functions, and it hides the internal
implementation details from other layers.
 Benefits: This separation of concerns leads to increased maintainability, scalability, and
reusability of the code. It also makes the codebase easier to manage over time.

Function Oriented Software Design

Function Oriented Design is an approach to software design where the design is decomposed into a
set of interacting units where each unit has a clearly defined function.

Generic Procedure

Start with a high-level description of what the software/program does. Refine each part of the
description by specifying in greater detail the functionality of each part. These points lead to a Top-
Down Structure.

Problem in Top-Down Design Method

Mostly each module is used by at most one other module and that module is called its Parent module.

Solution to the Problem

Designing of reusable module. It means modules use several modules to do their required functions.

7
Function Oriented Design Strategies

Function Oriented Design Strategies are as follows:

1. Data Flow Diagram (DFD): A Data Flow Diagram maps out the flow of information for any
process or system. It uses defined symbols like rectangles, circles and arrows, plus short text
labels, to show data inputs, outputs, storage points and the routes between each destination.

2. Data Dictionaries: Data Dictionaries are simply repositories to store information about all
data items defined in DFDs. At the requirement stage, data dictionaries contains data items.
Data dictionaries include Name of the item, Aliases (Other names for items), Description /
purpose, Related data items, Range of values, Data structure definition / form.

3. Structure Charts: Structure Chart is the hierarchical representation of system which partitions
the system into black boxes (functionality is known to users, but inner details are unknown).
Components are read from top to bottom and left to right. When a module calls another, it
views the called module as a black box, passing required parameters and receiving results.

4. Pseudo Code: Pseudo Code is system description in short English like phrases describing the
function. It uses keyword and indentation. Pseudocodes are used as replacement for flow
charts. It decreases the amount of documentation required.

Object Oriented Software Design

A crucial method for system design is object-oriented design (OOD), which places an intense focus
on scalability, modularity, and reusability. OOD resembles real-world systems by encapsulating data
and behavior into objects, which facilitates understanding programs and maintenance. By utilizing
concepts like inheritance, polymorphism, and encapsulation, this approach promotes resilient and
adaptable architectures.

Object-oriented design (OOD) is a programming technique that solves software problems by building
a system of interrelated objects. It makes use of the concepts of classes and objects, encapsulation,
inheritance, and polymorphism to model real-world entities and their interactions. A system
architecture that is modular, adaptable, and simple to understand and maintain is produced using
OOD.
8
Importance of Object-Oriented Design (OOD) in System Design

Object-Oriented Design (OOD) is important in system design due to several key reasons:

 Modularity: OOD simplifies development and maintenance by decomposing complicated

structures into smaller, more manageable components.

 Reusability: Objects and classes can be reused across di erent projects, reducing
redundancy and saving time.

 Scalability: OOD facilitates system growth by making it simple to incorporate new objects
without interfering with already-existing functionality.

 Maintainability: Encapsulation of data and behavior within objects simplifies troubleshooting

and updates, enhancing system reliability.

 Clear Mapping to Real-World Problems: By modeling software after real-world entities and
their interactions, OOD makes systems more intuitive and easier to understand.

 Flexibility and Extensibility: Through inheritance and polymorphism, OOD allows for
extending and adapting systems with minimal changes, accommodating future requirements
e iciently.