Software Requirements : Analysis and Specifications

Software requirements analysis and specification are critical activities in the software
development process, helping to ensure that the final product meets the needs and
expectations of its users.

1. Definition of Requirements:
- Requirements Analysis: This phase involves gathering, documenting, and analyzing
information about the software to be developed. It includes understanding user needs,
system functionality, and any constraints or limitations.
- Requirements Specification: Once the requirements are analyzed, they need to be
documented in a clear and concise manner. This documentation serves as a contract
between the development team and the stakeholders.

2. Types of Requirements:
- Functional Requirements: These specify the functions the software must
perform. They describe what the system should do and are often written as user
stories or use cases.
- Non-functional Requirements: These define the quality attributes of the system,
such as performance, reliability, scalability, and usability.
- User Requirements : User requirements, also known as business requirements,
represent the needs and expectations of the end-users or stakeholders who will
interact with the software.
- System Requirements: System requirements are more technical and detailed
specifications that describe the functionalities and constraints of the software
system from a technical perspective.
3. Feasibility Study : It involves evaluating the practicality and viability of a proposed
software project before significant resources are allocated.
The purpose of a feasibility study is to determine whether the project is worth pursuing,
considering various factors such as technical, operational, economic, legal, and
scheduling aspects.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies,

which are needed to accomplish customer requirements within the time and
budget.
 2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and
customer requirements.

3. Economic Feasibility - Economic feasibility decides whether the necessary

software can generate financial profits for an organization.

Requirement Engineering
Requirement engineering is a fundamental process in software engineering that focuses
on identifying, documenting, analyzing, and managing the requirements for a software
system. It encompasses activities such as gathering requirements from stakeholders,
prioritizing them, documenting them in a formal manner, validating them for accuracy
and completeness, and managing changes to them throughout the software
development lifecycle.

Activities involved in requirement engineering:

1. Requirement Elicitation: This involves gathering requirements from various

stakeholders including end-users, customers, domain experts, and other relevant
parties. Techniques such as interviews, surveys, workshops, and observations are
commonly used for eliciting requirements.

2. Requirement Analysis: Once requirements are gathered, they need to be analyzed to

ensure they are clear, complete, consistent, and feasible. This may involve identifying
conflicts or ambiguities in requirements and resolving them.

3. Specification: Requirements are documented in a formal and structured manner

using techniques such as use cases, DFD, Data dictionaries, E-R diagrams and SRS. The
documentation should be understandable to all stakeholders and serve as a basis for
the development team to build the software system.

4. Validation: This involves ensuring that the documented requirements accurately

reflect the needs and expectations of the stakeholders. Techniques such as reviews,
prototyping, and simulations may be used to validate requirements.
5. Verification: Verification ensures that the implemented system meets the specified
requirements. This is typically done through testing and inspection processes to check
whether the system behaves as expected based on the documented requirements.

6. Management: Requirements may change throughout the software development

lifecycle due to evolving business needs, technology advancements, or other factors.
Requirement management involves tracking changes to requirements, assessing their
impact, and ensuring that the necessary adjustments are made while maintaining
traceability and consistency.

Requirements Elicitation/gathering Techniques:

1. Interviews: Interviews are a direct and interactive requirement elicitation

technique where a facilitator engages in face-to-face or remote conversations
with stakeholders to gather information, opinions, and perspectives related to the
software project.
Key Elements of Interviews:
a) Participants:
- Stakeholders: Individuals directly involved or affected by the
project, including end-users, customers, subject matter experts, and
developers.
- Facilitator/Interviewer: The person responsible for conducting the
interview, guiding the conversation, and asking relevant questions.
b) Types of Interviews:
- Structured Interviews: Follow a predefined set of questions to
gather specific information.
- Unstructured Interviews: Allow for more open-ended discussions,
enabling stakeholders to express their thoughts freely.
- Semi-Structured Interviews: Combine elements of both structured
and unstructured approaches, providing a balance between
flexibility and focus.

Benefits of Interviews in Requirement Elicitation:

a) In-Depth Understanding:Interviews allow for in-depth exploration of stakeholders'

views, experiences, and expectations, providing a holistic understanding of their
needs.
 b) Clarification of Ambiguities: Participants can seek clarification or elaboration on
questions, helping to address any ambiguities and ensuring a clear
understanding of requirements.
c) Real-Time Adaptation: Interviewers can adapt their approach in real-time based
on stakeholders' responses, allowing for dynamic and responsive information
gathering.
d) Rich Qualitative Data:Interviews provide rich qualitative data, including
stakeholders' opinions, preferences, and contextual information that may not be
easily captured through quantitative methods.
e) Immediate Feedback: Stakeholders can provide immediate feedback on certain
ideas or concepts, allowing for quick adjustments and refinements in real-time.
f) Uncovering Implicit Requirements: Through open-ended questions and active
probing, interviews help uncover implicit requirements that stakeholders might
not explicitly state.
g) User-Centered Design: Interviews contribute to user-centered design by focusing
on the perspectives and experiences of end-users, ensuring that the system
aligns with their needs.
2. Brainstorming : Brainstorming is a creative and collaborative technique used in
requirement elicitation to generate a wide range of ideas, concepts, and requirements
from a group of stakeholders. It encourages open communication, idea sharing, and
exploration of various perspectives.

Benefits of brainstorming in Requirement Elicitation:

a) Diverse Perspectives: Brainstorming involves a diverse group of stakeholders,
including end-users, subject matter experts, and developers. This diversity
ensures that a wide range of perspectives, experiences, and knowledge are
considered during the requirement elicitation process.
b) Creative Idea Generation: The open and non-judgmental atmosphere of
brainstorming encourages creative thinking. Participants are free to suggest
innovative ideas, leading to the discovery of unique and novel requirements.
c) Collaboration and Team Building: Brainstorming fosters collaboration and
teamwork among stakeholders. It creates a sense of shared ownership of ideas
and requirements, promoting a collaborative spirit among participants.
d) Increased Stakeholder Engagement: Involving stakeholders in brainstorming
sessions increases their engagement in the project. When stakeholders actively
contribute to generating ideas and requirements, they are more likely to be
invested in the success of the project.
 e) Rapid Idea Generation: Brainstorming allows for the quick generation of a large
number of ideas in a relatively short period. This rapid idea generation is
beneficial for capturing a broad range of requirements efficiently.

3. FAST (Facilitated Application Specification Technique) : FAST is a requirement

elicitation technique that focuses on collaborative workshops to quickly and efficiently
gather and define functional requirements for a software system.

Benefits :

a) Collaborative Approach : FAST promotes collaboration among key stakeholders,

including end-users, subject matter experts, and developers. The facilitated
workshops encourage active participation and engagement, leading to a shared
understanding of the requirements.
b) Efficient Use of Time: FAST sessions are designed to be time-efficient. By
bringing stakeholders together in a structured and facilitated environment, it
allows for the rapid exploration and identification of key requirements without
lengthy delays.
c) Rapid Requirement Identification: The technique emphasizes the quick
identification and definition of functional requirements. The structured approach,
including the creation of context diagrams and decomposition of objectives,
helps in rapidly breaking down high-level goals into detailed requirements.
d) Visual Representation: FAST incorporates visual representations, such as
context diagrams and models, to help stakeholders visualize the system's
structure and interactions. Visual aids enhance communication and
understanding among participants.
e) Reduction of Ambiguity: By using a structured process of functional
decomposition and leveling, FAST helps in reducing ambiguity in requirements.
Clear specifications and rules are developed, leading to a more precise
understanding of the system's functionality.

4. QFD (Quality Function Deployment) : QFD is a structured method used in requirement

elicitation that focuses on translating customer needs and expectations into specific
engineering characteristics and requirements. QFD is particularly valuable in product
and service development to ensure that the end result aligns closely with customer
requirements.

Benefits of Quality Function Deployment (QFD) in Requirement Elicitation:

 a) Customer-Centric Approach: QFD ensures a customer-centric approach by
directly incorporating customer needs into the development process. This leads
to products or services that better meet customer expectations.
b) Systematic Requirement Prioritization: The prioritization mechanism in QFD
helps in systematically identifying and prioritizing customer requirements and
engineering characteristics, allowing for efficient allocation of resources.
c) Improved Communication: QFD encourages communication and collaboration
among cross-functional teams. It provides a structured framework for discussing
and aligning different perspectives within the organization.
d) Reduced Ambiguity: By translating qualitative customer needs into measurable
engineering characteristics, QFD reduces ambiguity in requirements. This clarity
helps in avoiding misinterpretations during the development process.
e) Early Identification of Design Conflicts: QFD helps in identifying potential
conflicts between different engineering characteristics early in the process. This
allows teams to address and resolve issues before they become more
challenging to manage.
Requirement Specifications
Use Case
The Use Case approach is a popular and effective technique for requirement analysis in
software engineering. It focuses on capturing and documenting interactions between
users and a system by describing the system's behavior from the user's perspective.

Definition of Use Case:

- A Use Case represents a specific way a system interacts with an external entity
(user or another system) to accomplish a particular goal. It describes a sequence
of actions or interactions between the system and external entities.

Key Elements of Use Cases:

- Actor: An external entity (user or system) interacting with the system.
- Use Case Name: Descriptive name indicating the purpose of the interaction.
- Description: A brief narrative outlining the main goals and objectives of the Use
Case.
- Preconditions: Conditions that must be true before the Use Case is executed.
- Postconditions: Outcomes or conditions expected after the successful execution
of the Use Case.
- Main Flow: A step-by-step description of the primary path of interaction.
- Alternate Flows: Descriptions of alternative paths or exceptional scenarios.
Steps in Use Case Analysis:
- Identify Actors: Identify and categorize all external entities (actors) that will interact
with the system.
- Identify Use Cases: Identify and document the various ways each actor interacts with
the system to achieve specific goals.
- Describe Use Cases: Provide detailed descriptions for each Use Case, including
preconditions, postconditions, and alternative flows.
- Prioritize Use Cases: Prioritize Use Cases based on their importance and impact on
system functionality.
- Validate and Refine: Validate Use Cases with stakeholders and refine them based on
feedback and additional requirements.

Benefits of the Use Case Approach:

- User-Centric Design: Use Cases focus on the user's perspective, ensuring that
system functionality aligns with user needs and goals.
- Clear Communication: Use Cases provide a clear and understandable way to
communicate system behavior to both technical and non-technical stakeholders.
- Requirements Traceability: Each Use Case is traceable back to specific user needs,
helping in requirements management and change control.
- Identification of System Boundaries: Use Cases help in defining the boundaries of
the system by specifying external entities that interact with it.
- Flexibility and Adaptability: Use Cases are flexible and can adapt to changes, making
them suitable for iterative development processes.

Types of Use Cases:

- Primary Use Cases: Represent the main goals or functions of the system.
- Supporting Use Cases: Provide additional functionalities that support the primary
Use Cases.
- Exceptional Use Cases: Describe how the system handles exceptional or error
conditions.

Use Case Diagrams:

- Visualization: Use Case diagrams provide a visual representation of actors, Use
Cases, and their relationships.
- System Context: Illustrate the context in which the system operates, depicting
external entities and their interactions.

Challenges in Use Case Analysis:

 - Scope Management: Defining the appropriate scope for each Use Case can be
challenging.
- Complexity: Managing a large number of Use Cases can become complex, requiring
careful organization and documentation.
- Ambiguity: Ambiguous or incomplete requirements may lead to unclear Use Case
descriptions.

DATA FLOW DIAGRAM

A Data Flow Diagram (DFD) is a graphical representation of how data flows within a
system, illustrating the processes, data stores, data sources, and data destinations. It is
a valuable tool in software engineering, especially during the requirement analysis
phase.
Purpose:DFD helps in visualizing the system's functionality, identifying data
transformations, and understanding how information moves within the system.

Use in Requirement Analysis:

- Understanding System Scope: DFD helps in defining the boundaries of the
system and understanding its scope by identifying external entities and data
interactions.
- Identifying Processes: It assists in identifying the major processes or functions
that the system must perform to meet user requirements.
- Data Identification: DFD aids in recognizing the types of data used by the system
and how data flows between processes.
- Clarifying Requirements: Visualization through DFD helps stakeholders, including
analysts and clients, to clarify and refine their requirements.

Managing Complexity:
- Simplification: DFD simplifies the complexity of the system by breaking it down
into manageable components. This helps in addressing one aspect at a time
during the requirement analysis.
- Modularization: The modular representation of processes in DFD allows for a
modular approach to understanding and analyzing the system.

Communication Tool:
- Stakeholder Communication: DFD serves as a communication tool between
stakeholders, providing a common visual language for discussing and refining
system requirements.
 - Documentation: DFDs can be used to document and communicate system
specifications to various project stakeholders.
Evolution and Iteration:
- Iterative Refinement: DFDs can evolve and be refined iteratively as the
understanding of the system requirements improves over time.
- Feedback Mechanism: Stakeholder feedback on DFDs can drive iterative
improvements, ensuring that the evolving requirements are accurately represented.
Symbols and Components:
- Processes: Represented by circles or ovals and represent activities or
transformations applied to data.
- Data Flows: Represented by arrows and show the movement of data between
processes, data stores, and external entities.
- Data Stores: Represented by rectangles and depict where data is stored within
the system.
- External Entities: Represented by squares and symbolize sources or destinations
of data outside the system.

Levels of DFD:
- Context Diagram: Provides an overall view of the system, showing external
entities and the high-level flow of data in and out of the system.
- Level 0 DFD: Represents the main processes within the system and their
interactions with external entities.
- Lower-Level DFDs: Break down processes into more detail, revealing
subprocesses and data flows at a more granular level.

DATA DICTIONARIES

1. Definition:
- Data Dictionary: A data dictionary is a centralized repository that provides a
comprehensive description of data used in a system. It contains metadata about data
elements, including their definitions, characteristics, relationships, and usage within the
software application.

2. Key Components of a Data Dictionary:

- Data Element Name: Unique identifier for a data element.
- Data Type: The type of data the element can hold (e.g., integer, string, date).
- Length: The maximum number of characters or digits allowed for the data
element.
 - Format: The specific format or pattern the data should adhere to.
- Description: A detailed description of the purpose and usage of the data element.
- Constraints: Any rules or restrictions on the data element, such as range limits or
required values.
- Aliases/Synonyms: Alternative names or terms used to refer to the data element.
- Related Data Elements: Links to other data elements that share relationships.
- Example: Data dictionary element for a "Student" in an educational system. This
data dictionary element includes various attributes that provide information
about the data associated with a student:
:
- Data Element: Student
- Attributes:
1. Student ID:
- Data Type: Alphanumeric
- Length: 10 characters
- Format: SXXXXXXX (where 'S' denotes student, and 'X' is a digit)
- Description: Unique identifier assigned to each student.
- Constraint: Primary Key

2. First Name:
- Data Type: String
- Length: 50 characters
- Format: Alphabetic characters
- Description: Legal first name of the student.
3. Date of Birth:
- Data Type: Date
- Format: YYYY-MM-DD
- Description: The date when the student was born.
4. Contact Email:
- Data Type: Email Address
- Length: 100 characters
- Description: Email address for communication purposes.

3. Purposes of Data Dictionaries:

- Documentation: Serve as a documentation tool, providing a structured and
centralized source of information about data elements.
- Standardization: Facilitate standardization by defining and enforcing consistent
naming conventions, data types, and formats.
 - Communication: Enhance communication among stakeholders, including analysts,
designers, developers, and database administrators.
- Analysis and Design: Aid in the analysis and design phases of software development
by providing a clear understanding of the data requirements.

5. Benefits of Using Data Dictionaries:

- Consistency: Promote consistency in data definitions and usage across the software
application.
- Efficiency: Save time and effort by providing a centralized resource for accessing
data-related information.
- Clarity: Enhance clarity and understanding of data elements, reducing ambiguity.
- Data Quality: Contribute to improved data quality by enforcing standards and
constraints.
- Collaboration: Facilitate collaboration among team members involved in data
analysis, design, and development.

6. Integration with Database Management Systems (DBMS):

- Metadata Management: DBMS often includes features for managing metadata, and
data dictionaries can be integrated into these systems.
- Impact Analysis: Changes to data elements can be tracked, and their impact on the
database can be analyzed using integrated data dictionaries.

7. Usage Across Software Development Phases:

- Requirements Analysis: Data dictionaries assist in defining and clarifying data
requirements during the requirements analysis phase.
- System Design: They play a crucial role in designing the structure and relationships
of data elements in the system.
- Implementation: Developers refer to data dictionaries for coding and implementing
data-related functionalities.
- Testing: Testers use data dictionaries to understand data specifications and design
test cases.
- Maintenance: Data dictionaries support ongoing maintenance efforts by providing a
reference for updates or modifications.

8. Challenges and Considerations:

- Maintenance Overhead: Keeping the data dictionary updated requires ongoing effort.
- User Adoption: Ensuring that team members consistently refer to and update the
data dictionary.
 - Integration Complexity: Integrating data dictionaries with various tools and systems
used in the development environment.

9. Tools and Technologies:

- Database Management Systems (DBMS): Many DBMS include built-in features for
managing metadata, which can function as data dictionaries.
- Specialized Tools: There are specialized data dictionary tools that focus specifically
on managing and documenting data-related information.

E-R DIAGRAMS
An Entity-Relationship (E-R) diagram is a visual representation used in software
engineering to model the structure of a database. It depicts the entities, attributes, and
relationships between entities in a system. Here are some key points and notes on E-R
diagrams:

1. Entities: Entities are objects or concepts that are relevant to the system being
modeled. Each entity is typically represented by a rectangle in the diagram. Examples of
entities could be "Student," "Employee," "Product," etc.

2. Attributes: Attributes describe properties or characteristics of entities. They are

depicted within ovals connected to their respective entities. For example, attributes of a
"Student" entity could be "StudentID," "Name," "Age," etc.

3. Relationships: Relationships represent associations between entities. They show

how entities are related to each other. Relationships are typically represented by
diamond shapes connecting the related entities. Examples of relationships could be
"Enrolls In" between "Student" and "Course," "Works For" between "Employee" and
"Department," etc.

4. Cardinality: Cardinality specifies the number of instances of one entity that can be
associated with another entity through a relationship. Common cardinality notations
include "1" (one), "N" (many), "0..1" (zero or one), "0..N" (zero or many), etc.

5. Degree of Relationship: The degree of a relationship refers to the number of entities

participating in the relationship. Relationships can be unary (involving a single entity),
binary (involving two entities), ternary (involving three entities), etc.
6. Weak Entities: Weak entities are entities that do not have a primary key attribute of
their own. They depend on a related strong entity for their existence. Weak entities are
depicted with a double-bordered rectangle.

7. Composite Attributes: Composite attributes are attributes that can be further divided
into smaller sub-parts. They are represented by ovals within ovals in the diagram.

8. Aggregation: Aggregation is a relationship where one entity represents a collection of

other entities. It is represented by a diamond shape with a line connecting it to the
aggregate entity.

9. Generalization/Specialization: Generalization/Specialization is a modeling technique

used to represent inheritance relationships between entities. It indicates that one entity
is a specialized form of another entity. It is depicted by a triangle connecting the
specialized entity to the parent entity.

10. Normalization: E-R diagrams are often designed with normalization principles in
mind to ensure that the database schema is well-structured and free from redundancy.
Normalization helps in optimizing the database for efficiency and reducing data
anomalies.

Benefits of E-R diagram

Entity-Relationship (E-R) diagrams offer several benefits in software engineering and
database design:

1. Visual Representation: E-R diagrams provide a visual representation of the database

structure, making it easier for stakeholders, including developers, designers, and clients,
to understand the relationships between various entities in the system.

2. Clarity and Communication: By using standardized symbols and notations, E-R

diagrams facilitate clear and concise communication among team members. They
serve as a common language for discussing and documenting database designs.

3. Database Design: E-R diagrams help in designing the database schema by identifying
entities, attributes, and relationships between entities. They aid in defining the structure
of the database tables, primary and foreign keys, and constraints.
4. Normalization: E-R diagrams support the process of normalization by identifying
dependencies between attributes and entities. Normalization ensures that the database
schema is well-structured, reducing redundancy and minimizing data anomalies.

5. Identifying Requirements: E-R diagrams help in capturing and documenting the

requirements of the system. By visualizing entities and their relationships, stakeholders
can identify missing entities, attributes, or relationships, leading to a more
comprehensive understanding of the system's requirements.

6. Data Integrity: E-R diagrams assist in maintaining data integrity by representing

relationships between entities accurately. They ensure that data is stored and managed
consistently, reducing the risk of data inconsistencies or errors.

7. Database Maintenance: E-R diagrams serve as a reference for database maintenance

tasks such as adding new entities, modifying attributes, or refining relationships. They
provide a roadmap for making changes to the database schema while preserving its
overall integrity.

8. Tool Integration: Many database management systems (DBMS) provide tools that
allow developers to generate database schemas directly from E-R diagrams. This
integration streamlines the process of database development and ensures consistency
between the diagram and the actual database implementation.

9. Documentation: E-R diagrams serve as valuable documentation artifacts for the

database design. They capture important aspects of the system's data model, including
entity definitions, attribute descriptions, and relationship semantics, which can be
referenced during system maintenance or upgrades.

10. Analysis and Optimization: E-R diagrams enable analysis and optimization of the
database design. By visually inspecting the diagram, designers can identify
opportunities for improving performance, enhancing data retrieval efficiency, or
optimizing storage requirements.

Overall, E-R diagrams play a crucial role in the software engineering process, facilitating
effective database design, communication, and maintenance throughout the lifecycle of
a system.

Software Requirements Specification

Software Requirements Specification (SRS) is a crucial document in software
engineering that serves as a blueprint for the development team, providing a detailed
description of what the software should accomplish and how it should function. Here
are some key points about SRS:

1. Purpose: The primary purpose of an SRS is to document the software requirements

comprehensively. It acts as a communication bridge between the stakeholders and the
development team, ensuring everyone is aligned on the goals and functionalities of the
software.

2. Contents: An SRS typically includes sections such as an introduction, scope,

functional requirements, non-functional requirements, system interfaces, user
interfaces, system features, data requirements, constraints, assumptions, and
dependencies.

3. Scope: The scope section defines what functionalities and features are within the
boundaries of the project and what are not. It helps in managing expectations and
preventing scope creep.

4. Functional Requirements: These describe what the software should do. They outline
the specific tasks, operations, and functionalities the system must perform, often
described in the form of use cases or user stories.

5. Non-Functional Requirements: These specify the quality attributes of the software

such as performance, reliability, usability, scalability, and security. They describe how
the system should behave rather than what it should do.

6. User Interfaces: This section describes the interfaces through which users interact
with the software, including GUI elements, navigation flow, input methods, etc.

7. System Interfaces: Describes how the software interacts with other systems,
including APIs, databases, hardware components, and external services.

8. Data Requirements: Describes the data handled by the system, including data
sources, data formats, data storage, and data processing requirements.

9. Constraints: Any limitations or restrictions imposed on the software development

process or the resulting system, such as technical constraints, budget constraints, or
regulatory constraints.
10. Assumptions and Dependencies: Assumptions are statements presumed to be true
but not explicitly stated, while dependencies are external factors that may impact the
software or its development.

11. Format and Documentation Standards: SRS documents should adhere to specific
formatting and documentation standards to ensure clarity, consistency, and readability.
This may include using templates, following a specific writing style, and incorporating
diagrams or illustrations where necessary.

12. Version Control and Change Management: SRS documents should be

version-controlled to track changes and revisions. Changes should be carefully
managed and documented to maintain the integrity of the requirements.

13. Review and Approval Process: SRS documents typically undergo review and
approval by stakeholders, including clients, users, and development team members, to
ensure accuracy, completeness, and alignment with project objectives.

Features Of SRS
Here are some key characteristics:

1. Clarity: The SRS should be written in clear and concise language, avoiding ambiguity
or confusion. It should be easily understandable by all stakeholders, including
developers, testers, and clients.

2. Completeness: The SRS should capture all necessary requirements for the software
system. It should address both functional and non-functional requirements, ensuring
nothing essential is overlooked.

3. Consistency: The requirements stated in the SRS should be consistent throughout the
document. There should be no conflicting or contradictory statements.

4. Correctness: The requirements specified in the SRS should accurately reflect the
needs and expectations of the stakeholders. They should be validated with stakeholders
to ensure accuracy.
5. Traceability: The SRS should provide traceability between requirements and their
sources, such as stakeholder requests, business objectives, or regulatory standards.
This helps in understanding the rationale behind each requirement.

6. Feasibility: The requirements specified in the SRS should be technically feasible

within the constraints of the project, including budget, time, and technology limitations.

7. Adaptability: The SRS should be adaptable to different audiences, including technical

and non-technical stakeholders. It should provide varying levels of detail to cater to the
needs of different readers.