Software Requirements Specification (SRS)

A Software Requirements Specification (SRS) is a comprehensive document that serves as the foundation of a
software development project. It outlines the functional and non-functional requirements of the software, providing a
clear and unambiguous description of what the system should do and how it should perform. Here are the
key characteristics and the nature of an SRS:

1. Detailed and Comprehensive: An SRS is a detailed document that leaves no room for ambiguity. It covers
all aspects of the software's functionality and performance, ensuring that developers have a clear understanding of
what is expected.

2. Functional and Non-Functional Requirements: An SRS includes both functional requirements (what the system
should do) and non-functional requirements (how the system should perform). This encompasses features, user
interactions, performance criteria, security requirements, and more.

3. Clear and Unambiguous: The SRS uses clear and concise language to ensure that there is no room for
misinterpretation. Ambiguities and contradictions are eliminated during the development of the document.

4. User-Centric: The SRS focuses on meeting the needs and expectations of end-users and
stakeholders. It ensures that the software serves its intended purpose effectively.

5. Traceability: The SRS establishes traceability between requirements and their sources, allowing for tracking and
validation. This ensures that each requirement can be linked back to user needs or business goals.

6. Structured Format: SRS documents typically follow a structured format, including sections for the introduction,
scope, functional and non-functional requirements, use cases, data models, and more. This format helps organize and
present the information systematically.

7. Feasibility Analysis: The SRS often includes a feasibility analysis that examines whether the project can be
realistically completed within budget and time constraints. This analysis may assess technical, operational, and
economic feasibility.

8. Dependencies and Interactions: The SRS identifies dependencies and interactions between different requirements
and components of the system. This helps in understanding how changes in one part of the system can affect others.

9. Verification and Validation Criteria: Verification and validation criteria are specified to ensure that each
requirement is testable and that there is a method to verify that it has been met.

10. Change Control: The SRS includes a change control process, describing how changes to requirements will be
managed and assessed for impact.

11. Legal and Regulatory Considerations: In some industries, the SRS may include information related to legal and
regulatory compliance to ensure that the software adheres to relevant standards and guidelines.

12. End-User Involvement: The SRS may involve end-users and stakeholders in its development, ensuring that their
input and feedback are incorporated.

13. Evolutionary Document: The SRS may evolve throughout the project as requirements change or new insights are
gained. It is important to maintain version control and document changes carefully.

14. Alignment with Project Goals: The SRS aligns with the overarching goals and objectives of the project, ensuring
that the software supports the business or organizational strategy.
 IEEE Std 830-1998

This IEEE standard provides guidelines and recommendations for creating software requirements
specifications. It is widely recognized and used in the software engineering industry. Here are some
key aspects of IEEE Std 830-1998:

1. Purpose: The standard aims to establish a common framework for creating high-quality SRS
documents that effectively communicate the software requirements to all project stakeholders.

2. Format and Structure: IEEE Std 830-1998 outlines a specific format and structure for SRS
documents,
including sections and subsections that should be included in the document. This structured
approach helps ensure consistency and completeness.

3. Content Guidelines: The standard provides guidance on what should be included in each section
of the SRS. It covers topics such as system functionality, external interfaces, performance
requirements, design constraints, and more.

4. Language and Style: IEEE Std 830-1998 recommends a clear and unambiguous language and
style to avoid misunderstandings and ambiguities in the requirements.

5. Requirements Attributes: The standard suggests using attributes for each requirement to
provide additional information, such as the source of the requirement, its priority, and its verification
method.

6. Traceability: IEEE Std 830-1998 emphasizes the importance of traceability, indicating that each
requirement should be traceable to its source and to the design and test cases.

7. Appendices: The standard allows for the inclusion of appendices, which can provide
supplementary information, such as data dictionaries, use case descriptions, and diagrams.

8. Review and Verification: IEEE Std 830-1998 recommends that the SRS undergo reviews and
verification to ensure its accuracy and completeness.

9. Change Control: The standard suggests establishing a formal change control process to manage
changes to the requirements throughout the project.

10. Examples: - The standard provides examples and templates to help illustrate how to structure
and format an SRS document effectively.

11. References: - IEEE Std 830-1998 may reference other IEEE standards and guidelines that are
relevant to software requirements engineering.
 Cohesion and Coupling

In software design, cohesion and coupling are two essential principles that play a critical role in creating
maintainable, modular, and efficient software systems. Let's explore these concepts in more detail:

1. Cohesion: Cohesion refers to the degree to which the components (modules, classes, functions) within a
software system are focused on performing a single, well-defined task or responsibility. In other words, it
measures how closely related the elements within a module are. High cohesion is generally a desirable
characteristic of a well-
designed system.
There are several types of cohesion, ordered from the lowest to the highest:
a. Coincidental Cohesion: This is the lowest level of cohesion, where the elements within a module are
not related to each other and appear to be put together coincidentally. Such modules are difficult to
understand and maintain.
b. Logical Cohesion: In this case, the elements within a module are grouped together because they
share a logical relationship. For example, a module that contains file I/O functions may exhibit logical
cohesion.
c. Temporal Cohesion: Elements within a module are grouped together because they are used at the
same time, even though they may perform different functions. For example, a module that contains
initialization and cleanup code may have temporal cohesion.
d. Procedural Cohesion: Elements within a module are grouped together because they are part of a
common procedure or algorithm. While this is better than the previous types, it's still not the highest
form of cohesion.
e. Communicational Cohesion: In this case, elements within a module are grouped together because
they operate on the same data or exchange information. This is better than procedural cohesion but
still has room for improvement.
f. Sequential Cohesion: Elements within a module are grouped together because they must be executed
in a specific order. This is more focused than communicational cohesion.
g. Functional Cohesion: This is the highest level of cohesion. Elements within a module are grouped
together because they collectively perform a single, well-defined function or task. Modules with
functional cohesion are easier to understand, maintain, and reuse.
Aim for achieving functional cohesion in your software design, as it results in more modular and maintainable
code.

2. Coupling: Coupling refers to the degree of interconnectedness between modules or components within a
software system. It measures how one module relies on the functionality of another. Low coupling is generally
preferred as it leads to more flexible and maintainable systems.
There are different levels of coupling:
a. Tight Coupling: In this scenario, modules are highly dependent on each other and are closely
connected. Changes in one module can have a significant impact on others. Tight coupling reduces
the system's flexibility and maintainability.
b. Loose Coupling: In loose coupling, modules are less dependent on each other, and changes in one
module are less likely to affect others. This results in more flexibility and ease of maintenance.
Reducing coupling and achieving loose coupling is a crucial design goal in software development. One way
to achieve this is by using well-defined interfaces and ensuring that modules communicate through those
interfaces rather than directly with each other.
 Function-Oriented Design

Function-oriented design is an approach to software design that emphasizes breaking down a system into
functional components or modules, with each module responsible for performing a specific function or task.
This design paradigm is particularly suitable for systems with well-defined functions, and it is often associated
with procedural programming and structured programming.
Here are the key principles and concepts of function-oriented design:

1. Modularity: Function-oriented design promotes modularity, where the software system is divided into
separate, self-contained modules, each responsible for a specific function. These modules can be designed,
developed, tested, and maintained independently.

2. Functional Decomposition: The software system is decomposed into a hierarchy of functions or

3. Top-Down Design: In function-oriented design, the design process often starts from the top level,
representing the overall system, and proceeds to the lower levels, where functions are further detailed. This
top-down approach helps in
structuring the design and understanding the system's architecture.

4. Abstraction: Abstraction is a key concept in function-oriented design. Functions are designed to abstract
specific operations, data processing, or tasks, which makes the design more understandable and
manageable.

5. Information Hiding: Modules in function-oriented design often encapsulate their internal details, exposing
only necessary interfaces to the rest of the system. This concept of information hiding helps in reducing
complexity and
dependencies.

6. Structured Programming: Function-oriented design aligns well with structured programming practices. It
encourages the use of structured constructs like loops, conditionals, and subroutines (functions or
procedures) to create clear and
maintainable code.

7. Reuse: Modular functions can be reused across the system or in other projects, promoting code reusability
and reducing redundant development efforts.

8. Documentation: Since each module represents a specific function, it's easier to document the purpose,
input, and output of each module, contributing to better system documentation.

9. Testing and Debugging: Smaller, modular functions are easier to test and debug, which simplifies the
software development and maintenance process.

Function-oriented design is often used for systems where the primary focus is on data processing,
algorithmic operations, and structured procedures. It is well-suited for scientific and engineering applications,
data processing systems, and embedded software.
 Object-Oriented Design (OOD)

Object-Oriented Design (OOD) is a widely used and effective software design paradigm that revolves around
the concept of objects. It is a design approach that models real-world entities and their interactions as
objects, which can encapsulate data and behavior. OOD is closely associated with object-oriented
programming (OOP) languages such as Java, C++, and Python.
Here are the key principles and concepts of Object-Oriented Design:

1. Objects: Objects are instances of classes and represent real-world entities, concepts, or data structures.
They encapsulate both data (attributes) and behavior (methods) related to the entity they represent.

2. Classes: Classes serve as blueprints or templates for creating objects. They define the structure and
behavior of objects of a certain type. Classes can inherit attributes and methods from other classes, fostering
reusability and hierarchical organization.

3. Encapsulation: Encapsulation is the practice of bundling data and methods that operate on the data
within a class, making data private and providing controlled access through methods (getters and setters).
This ensures data integrity and modularity.

4. Inheritance: Inheritance allows a class (sub-class or derived class) to inherit attributes and methods from
another class (super-class or base class). This promotes code reuse and enables the creation of hierarchies
of related classes.

5. Polymorphism: Polymorphism allows objects of different classes to be treated as objects of a common

6. Abstraction: Abstraction involves simplifying complex reality by modeling classes based on the essential
characteristics of objects. It focuses on what an object does rather than how it does it.

7. Modularity: OOD encourages modular design, where complex systems are broken down into smaller,
more manageable components (objects and classes). Each module encapsulates a specific piece of
functionality.

8. Reusability: Objects and classes can be reused in different contexts, fostering code reuse and reducing
redundancy. Libraries, frameworks, and design patterns are examples of reusable components in OOD.

9. Association and Composition: OOD supports modeling associations between objects and the
composition of
objects into larger structures. These relationships can be represented through attributes and methods within
classes.

10. Design Patterns: - Design patterns are well-established solutions to common design problems in
software development. OOD encourages the use of design patterns to address recurring design challenges.

11. UML (Unified Modeling Language): - UML is a standardized notation for visualizing, specifying, and
documenting the artifacts of software systems. It includes diagrams like class diagrams, sequence diagrams,
and use case diagrams that facilitate OOD.
 User Interface Design
User interface is the front-end application view to which user interacts in order to use the software. The software
becomes more popular if its user interface is:
● Attractive
● Simple to use
● Responsive in short time
● Clear to understand
● Consistent on all interface screens
There are two types of User Interface:
1. Command Line Interface: Command Line Interface provides a command prompt, where the user types the
command and feeds to the system. The user needs to remember the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides the simple interactive interface to interact with the
system. GUI can be a combination of both hardware and software. Using GUI, the user interprets the software.
User Interface Design Process:

The analysis and design process of a user interface is iterative and can be represented by a spiral model. The analysis
and design process of the user interface consists of four framework activities.
1. User, task, environmental analysis, and modeling: Initially, the focus is based on the profile of users who will
interact with the system, i.e. understanding, skill and knowledge, type of user, etc, based on the user’s profile users are
made into categories. From each category requirements are gathered. Based on the requirements, developers
understand how to develop the interface. Once all the requirements are gathered a detailed analysis is conducted. In
the analysis part, the tasks that the user performs to establish the goals of the system are identified, described and
elaborated. The analysis of the user environment focuses on the physical work environment. Software Engineering 79
2. Interface Design: The goal of this phase is to define the set of interface objects and actions i.e. Control mechanisms
that enable the user to perform desired tasks. Indicate how these control mechanisms affect the system. Specify the
action sequence of tasks and subtasks, also called a user scenario. Indicate the state of the system when the user
performs a particular task. Always follow the three golden rules stated by Theo Mandel. Design issues such as
response time, command and action structure, error handling, and help facilities are considered as the design model is
refined. This phase serves as the foundation for the implementation phase.
3. Interface construction and implementation: The implementation activity begins with the creation of a prototype
(model) that enables usage scenarios to be evaluated. As the iterative design process continues a User Interface toolkit
that allows the creation of windows, menus, device interaction, error messages, commands, and many other elements
of an interactive environment can be used for completing the construction of an interface.
4. Interface Validation: This phase focuses on testing the interface. The interface should be in such a way that it
should be able to perform tasks correctly and it should be able to handle a variety of tasks. It should achieve all the
user’s requirements. It should be easy to use and easy to learn. Users should accept the interface as a useful one in
their work.