System design in Library and Information Management (LIM) is a pivotal phase that translates the requirements gathered during system analysis into a detailed blueprint for implementation. This chapter focuses on performing system design within LIM contexts in Kenya, where libraries and information centers increasingly rely on computerized systems for cataloguing, circulation, and user services. Effective system design ensures that software solutions meet the specific needs of Kenyan libraries, such as managing multilingual resources, integrating with national digital archives, and supporting diverse user communities. The design process must balance quality, timeliness, and cost-effectiveness to deliver systems that are sustainable and scalable.

4.0 Design with Software Specification Requirements (SRS) Document

System design in LIM depends heavily on the software specification requirements (SRS) document, which acts as the foundation for all design activities. The SRS captures what the system must achieve, detailing functional and non-functional requirements that guide designers and developers in creating software tailored to library operations. In Kenyan libraries, an accurate SRS ensures that systems handle tasks such as cataloguing according to international standards (e.g., MARC21), support user authentication via national IDs, and comply with data protection laws. This section dissects the role of the SRS in system design, its components, and how it shapes the design process.

4.0.1 Purpose and Scope of the SRS Document

The purpose of the SRS document is to provide a comprehensive, clear, and unambiguous description of the software to be developed. In Kenyan LIM settings, the SRS guides programmers and stakeholders by outlining what functionalities are essential and the boundaries of the system.

Purpose of the SRS Document

• Define Functional Requirements: Specifies the operations the system must perform, such as book lending, user registration, and overdue fine calculations, ensuring developers understand user needs.
• Set Non-Functional Requirements: Details performance, security, usability, and reliability standards, which are crucial for systems accessed by diverse users in institutions like county libraries.
• Provide a Basis for Validation: Enables librarians and IT staff to verify that the developed system meets agreed requirements before deployment.
• Facilitate Communication: Acts as a contract between stakeholders and developers, reducing misunderstandings during system development.
• Support Maintenance and Upgrades: Documents system specifications that assist future modifications in evolving library environments.

Scope of the SRS Document

• Defines System Boundaries: Clarifies which library functions are automated and which remain manual, such as automated cataloguing but manual archival.
• Identifies Interfaces: Specifies interaction points with external systems like national bibliographic databases or university portals.
• Describes User Classes: Outlines different user categories, including librarians, patrons, and system administrators, tailoring functionalities accordingly.
• Specifies Constraints: Notes hardware limitations, software platforms, or regulatory requirements relevant to Kenyan libraries.
• Highlights Assumptions and Dependencies: Records assumptions about network availability or third-party software reliance that impact system design.

4.0.2 Components of the SRS Document

An SRS document is structured into several key components that together provide a complete description of the system’s intended capabilities and restrictions.

Functional Requirements

These specify the core services the system must deliver, for example, cataloguing new items, managing user accounts, and generating reports on library usage statistics.

Non-Functional Requirements

These include requirements related to system performance, security, usability, and compliance with Kenyan ICT policies such as the Data Protection Act.

System Interfaces

Details how the system interacts with other systems or hardware, such as barcode scanners or digital repositories.

User Interfaces

Describes the design and usability expectations for user interaction points, ensuring accessibility for users with varying levels of digital literacy.

Constraints and Assumptions

Lists factors limiting system design choices, such as budget limits, available network infrastructure, or compatibility with existing library management software.

4.0.4 Challenges in Developing an Effective SRS and Mitigation Strategies

Drafting an effective SRS in the LIM context can be challenging due to evolving user needs and limited technical expertise in some institutions.

Challenges

• Ambiguous Requirements: Users may provide unclear or conflicting needs, complicating specification.
• Changing Scope: Libraries may expand services during development, affecting requirements.
• Limited Stakeholder Involvement: Insufficient input from end-users can lead to irrelevant features.
• Technical Constraints: Infrastructure limitations may restrict feasible solutions.
• Communication Gaps: Language and technical knowledge barriers between librarians and developers.

Mitigation Strategies

• Iterative Requirement Gathering: Engage stakeholders regularly to refine requirements.
• Prototyping: Develop early system models to clarify expectations.
• Training and Capacity Building: Enhance users’ understanding of technical possibilities.
• Clear Documentation: Use simple language and diagrams to improve comprehension.
• Project Management Practices: Implement scope control and change management procedures.

Chapter Summary

This chapter explored the process of performing system design, starting with the critical role of the software specification requirements (SRS) document in guiding design decisions. It examined key components of system design, emphasizing the importance of quality, timeliness, and cost-effectiveness in delivering successful systems. The inputs to system design were detailed, including the statement of work, requirement determination plan, current situation analysis, and proposed system requirements with conceptual data models and metadata. The chapter then described the outputs of system design, such as infrastructure changes, data schemas, metadata definitions, function hierarchy diagrams, program pseudocode, prototypes, user interfaces, and modularization. It outlined the stages of system design from requirement determination through feasibility analysis and hardware study to final system design. Different types of system design were presented, distinguishing between logical and physical designs, with architectural and detailed design as subcategories. Finally, the chapter covered data modelling techniques including conceptual, relational, object-oriented, logical models, and dataflow diagrams, highlighting their roles in representing system data and processes effectively.