Performing system design is a critical phase in the role of an ICT Technician in Kenya, as it translates user requirements into a blueprint for system construction. This chapter focuses on applying the Software Requirements Specification (SRS) document during design and understanding key components that influence system quality, timely delivery, and cost-effectiveness. Mastery of these aspects ensures that ICT professionals deliver robust solutions aligned with client expectations and organizational constraints.

4.1 Design with Software Specification Requirements (SRS) Document

The Software Requirements Specification document is foundational in guiding system design. It captures detailed functional and non-functional requirements, serving as a contract between stakeholders and developers. In Kenya’s ICT sector, adherence to a well-structured SRS document minimizes miscommunication and rework, especially in projects for institutions such as county government offices or financial cooperatives where precision is paramount.

4.1.1 Purpose and Role of SRS in System Design

The SRS document defines what the system must do and sets boundaries for design and development. It acts as a reference point throughout the project lifecycle to ensure alignment with user needs.

Purpose of SRS

• Clarifies Requirements: It provides a clear, unambiguous description of system functionalities, reducing assumptions during design.
• Facilitates Communication: The document bridges the gap between clients, users, and developers, fostering mutual understanding.
• Basis for Planning: It informs project scheduling, resource allocation, and risk assessment by detailing system scope.
• Guides Testing: Test cases are derived from the SRS to verify that the system meets specified requirements.
• Contractual Agreement: It serves as a formal agreement that can be referenced to resolve disputes or changes.

Role of SRS in System Design

• Foundation for Architecture: Designers use SRS to determine system components and their interactions.
• Scope Control: Prevents scope creep by explicitly listing functionalities to be implemented.
• Design Constraints Identification: Specifies hardware, software, and performance constraints to guide technical decisions.
• Documentation of Assumptions: Records assumptions and dependencies that impact design choices.
• Facilitates Maintenance: Provides a baseline for future system modifications or enhancements.

4.1.2 Structure and Contents of an SRS Document

A comprehensive SRS document is organized systematically to provide detailed insights into system requirements. Kenyan ICT technicians often adapt international standards like IEEE 830 to local contexts, especially when working with public sector clients.

Key Sections of an SRS Document

• Introduction: Describes purpose, scope, definitions, and references for the system.
• Overall Description: Outlines product perspective, user characteristics, constraints, and assumptions.
• Specific Requirements: Details functional requirements, including inputs, outputs, behavior, and interfaces.
• Non-Functional Requirements: Specifies performance, security, usability, reliability, and compliance standards.
• Appendices and Glossary: Contains supporting information and term definitions for clarity.

Importance of Each Section

• Introduction sets expectations and context for all stakeholders.
• Overall Description gives a high-level view that informs design boundaries.
• Specific Requirements are critical for detailed design and coding.
• Non-Functional Requirements ensure the system meets quality attributes crucial in environments like hospitals or banks.
• Appendices support understanding of technical jargon and additional constraints.

4.1.3 Using the SRS Document to Inform Design Decisions

The SRS document guides decisions on system architecture, user interface, database design, and integration points. ICT technicians in Kenya use this document to align design choices with client needs and regulatory requirements such as the Data Protection Act.

Design Decision Areas Influenced by SRS

• Functional Decomposition: Breaking down system functions as specified in the SRS into manageable modules.
• Technology Selection: Choosing platforms and tools that meet specified performance and compatibility requirements.
• User Interface Design: Creating interfaces that satisfy usability requirements outlined in the document.
• Data Modeling: Designing databases that accommodate data requirements and integrity constraints.
• Security Measures: Implementing controls to comply with security specifications.

4.1.4 Challenges in Using the SRS Document and Mitigation Strategies

Despite its importance, challenges arise in interpreting and applying the SRS document effectively, particularly in dynamic environments with evolving user needs.

Common Challenges

• Ambiguity in Requirements: Vague or incomplete specifications can lead to design errors.
• Changing Requirements: User needs may evolve mid-project, causing design revisions.
• Technical Constraints Overlooked: Failure to account for infrastructure limitations can affect feasibility.
• Stakeholder Misalignment: Disagreements among users and developers may delay design approval.
• Documentation Quality: Poorly written SRS documents hinder clear understanding.

Mitigation Strategies

• Requirement Validation Workshops: Engage stakeholders early to clarify and confirm requirements.
• Change Management Procedures: Implement formal processes to handle requirement changes.
• Feasibility Analysis: Assess technical and operational constraints before finalizing design.
• Regular Communication: Maintain continuous dialogue between developers and users.
• Use of Templates and Standards: Adopt proven SRS templates to enhance clarity and completeness.

Chapter Summary

This chapter focused on performing system design guided by the Software Specification Requirements (SRS) document, which ensures that the design aligns with clearly defined needs. It examined crucial components of system design including quality, timeliness, and cost-effectiveness, highlighting how these factors influence successful project delivery. The chapter detailed the inputs required for system design such as the statement of work, requirement determination plan, current situation analysis, and proposed system requirements including data models and metadata. It also covered the outputs of system design, which encompass infrastructure changes, data schemas, metadata definitions, program structure diagrams, pseudocode, prototypes, user interfaces, and modularization. Various types of system design were explored, including logical, physical, architectural, and detailed designs, each addressing different aspects of system development. The stages of system design were outlined from requirements determination through feasibility analysis to hardware study and final specifications. Finally, the chapter introduced data modelling techniques such as conceptual, relational, object-oriented, logical, and dataflow diagrams, which are essential tools for representing system data and processes effectively.