Unit2: Ch1

Introduction to Software Requirements Specification

 REQUIREMENT ENGINEERING
• A requirement is a feature of the system
or a description of something the system
is .
• Requirements describe the “what” of a
system, not the “how.”
• The input to requirements engineering is
the problem statement prepared by the
customer. The output of the
Requirements Engineering (RE) process
is a system requirements specification
called the Requirement Definition and
Description (RDD). The system
requirements specification forms the
basis for designing software solutions.
Types of Requirements
• Functional requirements. They define factors, such as I/O formats,
storage structure, computational capabilities, timing, and
synchronization.
• Non-functional requirements. They define the properties or qualities
of a product including usability, efficiency, performance, space,
reliability, portability, etc
PROCESS OF REQUIREMENTS ENGINEERING
Requirements engineering consists of the following processes:
• Requirements gathering (elicitation).
• Requirements analysis and modeling.
• Requirements documentation.
• Requirements review.
• Requirements management.
Requirement Elicitation and Analysis
• Requirement gathering is a communication process between the parties involved
and affected in the problem situation.
• The requirements are gathered from various sources. The sources are: - Customer
(Initiator) , End Users , Primary Users , Secondary Users, Stakeholders
• Requirement Analysis: In this phase, each requirement is analyzed from the
point-of-view of validity, consistency, and feasibility for firm consideration in the
RDD and then in the SRS. Feasibility ensures that the necessary inputs available
without bias and error, and technology support is possible to execute the
requirement as a solution. The second portion of analysis attempts to find for
each requirement, its functionality, features, and facilities and the need for these
under different conditions and constraints. Functionality states “how to achieve
the requirement goal.” Features describe the attributes of functionality, and
facilities provide its delivery, administration, and communication to other systems.
Process Model of Elicitation and Analysis
The process activities are:
• 1. Domain Understanding. Analysts must develop their understanding of the
application domain. For example, if a system for a supermarket is required, the
analyst must find out how supermarkets operate.
• 2. Requirements Collection. This is the process of interacting with stake holders in
the system to discover their requirements. Obviously, domain understanding
develops further during this activity.
• 3. Classification. This activity takes the unstructured collection of requirements and
organizes them into coherent clusters.
• 4. Conflict Resolution. Inevitably, where multiple stakeholders are involved,
requirements will conflict. This activity is concerned with findings and resolving
these conflicts.
• 5. Prioritization. In any set of requirements some priorities will be more important
than others. This stage involves interaction with stakeholders to discover the most
important requirements.
• 6. Requirements Checking. The requirements are checked to discover if they are
complete, consistent, and in accordance with what stakeholders really want from
the system.
Requirements Documentation
• The Software Requirements Specification (SRS) is a structured
document that defines a software product's functionalities and
environment, serving as a communication tool between customers
and developers.
• It ensures clarity in user needs and expectations while acting as a
contract for development.
Requirements Review
• A requirements review is a manual process to identify anomalies and omissions in
the requirements document, involving both client and contractor staff.
• Informal Review
• Conducted through discussions between contractors and stakeholders.
• Ensures alignment of documented requirements with stakeholder expectations.
• Helps detect issues early by clarifying requirements before formal commitment.
• Formal Review
• The development team explains system requirements to the client.
• Each requirement is checked for:
• Verifiability: Realistic and testable requirements.
• Comprehensibility: Clear understanding for end-users or procurers.
• Traceability: Clearly stated origin to assess change impact.
• Adaptability: Changeable without major system-wide effects.
• Conflicts, contradictions, and errors are recorded for resolution through negotiation.
Requirements Management
• Requirements management is a structured process to elicit, organize,
document, and maintain agreement on system requirements between the
customer and project team.
• Classes of Requirements
• Enduring Requirements
• Stable and linked to the core activities of an organization.
• Derived from domain-specific models, such as entities and relationships.
• Example: A hospital’s requirements related to patients, doctors, and treatments.
• Volatile Requirements
• Likely to change during development or system operation.
• Often influenced by external factors, such as policy changes.
• Example: Requirements impacted by government health-care policies.
INFORMATION MODELING
• The Information Flow Model
(IFM) is a framework used to
analyze and understand the
sources, destinations, and
pathways of information flow
within a system.
• It helps identify how
information is generated,
shared, and utilized.
DATA-FLOW DIAGRAMS
• Definition: DFDs, also known as data-flow graphs or bubble charts, depict
the flow of data through a system, helping clarify requirements and identify
major transformations.
• Purpose: Model system functions as networks of processes manipulating
data.
• Components:
• Data Flows: Movement of data within the system.
• Data Repositories: Storage locations for data.
• External Entities: Sources or destinations of data outside the system.
• Advantages:
• Widely used for specifying information system functions.
• Easy to understand and implement due to intuitive graphical notation.
Symbols Used for Constructing DFDs
• Function symbol. A function is represented using a circle. This symbol
is called a process or a bubble and performs some processing of input
data.
• External entity. A square defines a source or destination of system
data. External entities represent any entity that supplies or receives
information from the system but is not a part of the system.
• Data-flow symbol. A directed arc or arrow is used as a data-flow
symbol. A data-flow symbol represents the data flow occurring
between two processes or between an external entity and a process
in the direction of the data flow arrow.
• Data-store symbol. A data-store symbol is represented using two
parallel lines. A logical file can represent either a data-store symbol,
which can represent either a data structure, or a physical file on disk.
Each data store is connected to a process by means of a data-flow
symbol. The direction of the data-flow arrow shows whether data is
being read from or written into a data store.
• Output Symbol. It is used to represent data acquisition and production
during human-computer interaction.
Levels of a DFD
SRS DOCUMENT
• An SRS document is the outcome of requirements analysis, providing a detailed and clear
understanding of the product to be developed.
• Key Components of SRS
• External Interfaces
• Define the flow of information "from and to" the system.
• Functional Requirements
• Specify each function supported by the system.
• Describe input and output datasets for every function.
• Non-Functional Requirements
• Address system characteristics like:
• Maintainability: Ease of updates and modifications.
• Portability: Ability to operate in different environments.
• Usability: User-friendliness.
• Reliability: System stability and accuracy of results.
• Human-Computer Interface: Interaction quality.
• Constraints: Limitations on system implementation.
• Structure
• The structure of SRS can vary, with formats recommended by standards such as IEEE or the U.S.
Department of Defense.
Uses for SRS Documents
• Project Managers: Use it for planning and estimating schedules, effort, and
resources.
• Development Team: Relies on it for product development.
• Testing Group: Generates test plans based on described external behavior.
• Maintenance and Support Staff: Understands the intended functionality of the
software.
• Publications Group: Creates documents, manuals, and user guides.
• Customers: Refer to it for clarity on the expected product.
• Training Personnel: Develops educational material for the software
IEEE STANDARDS FOR SRS DOCUMENTS
• IEEE standards are developed by IEEE Societies and Standards Coordinating
Committees with voluntary contributions from members.
• They reflect a consensus of expertise both within and outside IEEE,
including those interested in the standard's subject.
• The use of IEEE Standards is voluntary, and alternative methods for related
processes are not excluded.Standards are reviewed at least every five years
for updates, and documents older than five years may not fully reflect
current practices.
• Users should verify they have the latest version of any IEEE Standard.
• Feedback for revisions is welcomed from all parties, with suggestions
submitted as text changes with supporting comments.
IEEE Recommended Approaches for SRS
• This recommended practice provides guidance on specifying software
requirements, aiming to produce a clear and complete specification
document. It is designed to help:
• Software customers accurately describe their needs.
• Software suppliers understand exactly what the customer requires.
• Individuals achieve the following goals:
• Develop a standard software requirements specification (SRS) outline for their
organization.
• Define the format and content of specific software requirements specifications.
• Create additional supporting items, such as an SRS quality checklist or an
SRS writer's
Benefits of SRS
• Establish Agreement
• Reduce Development Effort
• Estimate Costs and Schedules
• Baseline for Validation and Verification
• Facilitate Transfer
• Basis for Enhancement
IEEE Recommended Practice for Software
Requirements Specification
• 1. Overview
• 2. References
• 3. Definitions
• 4. Considerations for producing a good SRS
• 5. The parts of an SRS
SRS VALIDATION
• The major objective of SRS validation is to ensure that the user
requirements are complete, correctly recorded, and free from errors. It also
ensures that the SRS itself is of high quality. Some of the most common
types of errors in the SRS include:
• Omission: Missing user requirements that are not included in the SRS,
affecting the system's external completeness.
• Inconsistency: Contradictory or incompatible requirements within the SRS.
• Incorrect Facts: Inaccurate or incorrect facts recorded in the SRS.
• Ambiguity: Requirements that have multiple meanings, leading to potential
misunderstandings.
• SRS validation aims to uncover and rectify these errors, improving the
overall quality of the document.
COMPONENTS OF SRS
• Functional Requirements: Functional requirements describe the system's behavior in
terms of outputs generated from given inputs. They establish the relationship between
input and output and include:
• Detailed descriptions of data inputs, their sources, units of measurement, and valid
input ranges.
• Operations to be performed on the input data, including validity checks, affected
parameters, and equations or logical operations to transform inputs into outputs.
• Specification of abnormal inputs and the system's behavior for invalid inputs.
• Avoiding the specification of implementation details, such as algorithms, which should
be left to the designer.
• Performance Requirements: Performance requirements specify constraints related to
the system's performance:
Static Requirements: Include constraints that don't affect execution behavior, such as
the number of supported terminals, simultaneous users, and file sizes (capacity
requirements).
Dynamic Requirements: Specify constraints like response time and throughput.
Response time refers to the time taken to complete an operation under specific
circumstances, while throughput defines the number of operations performed per unit
time. Both normal and peak workload conditions should be considered.
• Design Constraints: Design constraints define the restrictions imposed
by the client’s environment, affecting how the system is designed. These
include:
Standards Compliance: Specifies the required standards for the system,
such as reporting formats, accounting procedures, or audit-tracing
requirements.
Hardware Limitations: Restrictions imposed by existing or
predetermined hardware, such as machine types, operating systems,
supported languages, and storage limits.
Reliability and Fault Tolerance: Specifies fault-tolerance requirements
and recovery procedures in case of faults, which can increase system
complexity.
Security: Defines security requirements, including access control, use of
passwords, encryption, logging, and techniques to mitigate security risks
like buffer overflow.
• External Interface Requirements: External interfaces detail how the
system interacts with users, hardware, and other software:
User Interface: Specifies characteristics of user interfaces, such as
commands, screen formats, system appearance, feedback, and error
messages. Requirements should be specific and verifiable, e.g.,
"commands should be no longer than six characters."
Hardware Interface: Specifies the logical characteristics of the interface
between software and hardware components, including memory
restrictions and hardware characteristics.
Software Interface: Describes the interface with other software
systems, including operating systems and applications, detailing
message formats and content.
 CHARACTERISTICS OF SRS
1.Correctness
2.Completeness
3.Unambiguous
4.Verifiable
5.Modifiable
6.Traceable
•Backward Traceability
•Forward Traceability
7.Consistency
8.Testability
9.Clarity
10.Feasibility
• 1. Correctness: The SRS must accurately represent all required elements of the final system.
• 2. Completeness: The SRS should document all aspects of the system, involving all stakeholders and defining
clear boundaries.
• 3. Unambiguous: Each requirement should have a single, clear interpretation, avoiding any ambiguity.
• 4. Verifiable: The SRS must be measurable through a cost-effective process to ensure the product meets the
requirements.
• 5. Modifiable: The SRS should allow easy changes while maintaining its integrity and consistency.
• 6. Traceable: The origin and references of each requirement should be clear for future development or
enhancement.
• - Backward Traceability: Each requirement should reference its source from earlier documentation.
• - Forward Traceability: Each requirement should have a unique identifier for future reference.
• 7. Consistency: The SRS must maintain uniformity in terms, business rules, and functionality across the
system.
• 8. Testability: Requirements must be clear enough to create a test plan confirming whether they can be met.
• 9. Clarity: The SRS should be easily understandable by all stakeholders, with clear and precise language.
• 10. Feasibility: The SRS must be confirmed for both technical and operational feasibility before development.