Here’s an even more detailed breakdown of each topic, providing comprehensive

explanations for both the Process of System Development and Documentation of

Systems.

Process of System Development

1. Systems Development Life Cycle (SDLC):

o Definition and Purpose: SDLC is a structured framework used for software

development, consisting of sequential stages that cover the full lifecycle of a
system, from initial concept to maintenance. Its goal is to ensure quality,
meet user needs, and deliver a system that is functional, reliable, and
maintainable.

o Common Models of SDLC:

▪ Waterfall Model: Linear and sequential, ideal for well-defined

projects with clear requirements.

▪ Agile Model: Iterative, flexible, and highly collaborative, suitable for

projects where requirements may evolve.

▪ Spiral Model: Combines iterative and waterfall models, focusing on

risk assessment, ideal for complex and high-risk projects.

▪ V-Model: Similar to Waterfall but includes testing phases parallel to

each development stage, enhancing quality through continuous
validation.

2. Phases of SDLC:

o Planning:

▪ Objective: Define the project’s scope, goals, deliverables, and

constraints. Identify the business needs, potential users, budget,
timeline, and resources required.

▪ Activities: Conduct feasibility studies, cost-benefit analysis, and

resource allocation. Develop a project management plan that outlines
project structure, milestones, and deliverables.

o Analysis:
 ▪ Objective: Understand and document the detailed requirements of
the system to address user needs.

▪ Activities: Requirements gathering through interviews, surveys, and

observations. Document functional (tasks the system should
perform) and non-functional requirements (system qualities like
performance, security).

▪ Outputs: Business Requirements Document (BRD) or System

Requirements Specification (SRS).

o Design:

▪ Logical Design: Focus on abstract aspects such as data flow,

business rules, and entities without specifying technology.

▪ Physical Design: Define the specific software, hardware, and network

infrastructure. Create a detailed system architecture, database
schema, and data structure.

▪ Outputs: System architecture diagrams, data models, and user

interface mock-ups.

o Implementation:

▪ Objective: Translate design documents into actual software through

coding and configuration.

▪ Activities: Developers write, compile, and debug code following

coding standards. Unit testing is conducted to validate individual
components.

▪ Tools Used: Integrated Development Environments (IDEs) like

Eclipse, version control systems like Git.

▪ Output: Fully functional software that aligns with the design

specifications.

o Testing:

▪ Objective: Ensure the system meets requirements and is free of

defects before release.

▪ Types of Testing:
 ▪ Unit Testing: Tests individual components for expected
functionality.

▪ Integration Testing: Verifies that components work together as

intended.

▪ System Testing: Tests the entire system’s functionality end-to-

end.

▪ User Acceptance Testing (UAT): Ensures that the system

meets user expectations and requirements.

▪ Output: Test reports and defect logs.

o Deployment:

▪ Objective: Release the software to the production environment,

making it available to users.

▪ Types of Deployment:

▪ Big Bang: The entire system is deployed in one go, suitable for
smaller systems.

▪ Phased: Deploy the system in stages, often module by

module.

▪ Parallel: Run new and old systems simultaneously, reducing

risks but increasing cost.

▪ Pilot: Deploy to a small user group before full-scale release.

▪ Output: Deployed system with user training and support materials.

o Maintenance:

▪ Objective: Ensure system reliability, adaptability, and performance

over time.

▪ Types of Maintenance:

▪ Corrective: Fixing bugs and errors reported after deployment.

▪ Adaptive: Adjusting the system to accommodate changes in

the environment (e.g., new OS versions).
 ▪ Perfective: Improving system functionality based on user
feedback.

▪ Preventive: Updating components to avoid future issues.

▪ Output: Regular patches, updates, and system documentation.

3. Project Identification and Selection:

o This involves assessing project ideas based on alignment with strategic

goals, feasibility, cost-benefit analysis, and anticipated ROI. Projects are
selected to maximize benefits and resource utilization.

4. Project Initiation and Planning:

o Objective: Develop a foundation for the project by defining objectives,

scope, and resources.

o Key Outputs:

▪ Project Charter: Outlines the purpose, objectives, and stakeholders.

▪ Risk Management Plan: Identifies potential risks, their impact, and

mitigation strategies.

▪ Stakeholder Analysis: Identifies who is affected by the project and

how they will be engaged.

o Tools: Gantt charts, work breakdown structures (WBS), and resource

allocation tools.

5. Approaches to Development:

o Prototyping: A working model is built quickly to gather user feedback.

Iterative improvement occurs until user satisfaction is achieved.

o Joint Application Design (JAD): Facilitates intensive workshops with users

and developers to design system requirements together, minimizing
misunderstandings and aligning expectations.

o Participatory Design: Users are directly involved in the development

process, contributing to decision-making. This approach improves usability
and acceptance as it aligns with real user needs.

6. Product of SDLC Phases:

o Each phase produces artifacts:

 ▪ Planning: Project plan, feasibility report.

▪ Analysis: Requirements documents (BRD, SRS).

▪ Design: Design documents, database schema, and interface designs.

▪ Implementation: Source code and technical documentation.

▪ Testing: Test cases, test results, and defect reports.

▪ Deployment: Deployment plan and user manuals.

▪ Maintenance: Maintenance logs and change requests.

7. Case Study:

o Case studies help illustrate the practical application of SDLC phases in real-
world scenarios, detailing how challenges were addressed. For example, a
hospital management system case study may explore issues with user
requirements in clinical workflows and solutions such as role-based access
control.

Introduction to Documentation of Systems

1. Concepts and Process of Documentation:

o Purpose: Documentation serves as the written record of a system’s design,

functionality, and usage, providing clarity for developers, users, and
administrators.

o Documentation Lifecycle: It evolves with each SDLC phase, from capturing

requirements in the analysis phase to recording updates during
maintenance.

2. Types of Documentation:

o User Documentation: Guides end-users, covering installation, operation,

troubleshooting, and FAQ. Often includes step-by-step instructions and
screenshots.

o System Documentation: Technical documents for developers detailing

code, APIs, database structures, and system architecture.

o Project Documentation: Administrative documents like project proposals,

planning documents, progress reports, and final project closure reports.
3. System Requirements:

o Functional Requirements: Describe specific behaviors of the system, like

“The system must validate user credentials before granting access.”

o Non-Functional Requirements: Address performance, usability, reliability,

and other attributes, such as “The system must process transactions within
3 seconds.”

4. System Design Specification:

o Objective: Provide a blueprint for development, including detailed design of

each system component.

o Key Sections: Data models, entity-relationship diagrams (ERDs), interface

specifications, process flow diagrams, and interaction models.

5. Test Design Document:

o Objective: Plan and structure the testing process to ensure all

functionalities work as intended.

o Components:

▪ Test Cases: Detail each test scenario with inputs, expected outputs,
and actual results.

▪ Acceptance Criteria: Define the conditions for system acceptance

by the end-users or clients.

▪ Tools: Testing frameworks like Selenium, JUnit, or TestNG, depending

on the environment.

6. User Manual:

o Purpose: Guide users on system use, covering login procedures, basic

navigation, features, troubleshooting, and contacts for support. Includes
visual aids like screenshots and flow diagrams.

7. Different Specification Standards:

o Standards like IEEE 830 (Requirements Specification), IEEE 1016 (Software

Design Descriptions), and ISO/IEC standards ensure clarity and consistency
in documentation, essential for large and distributed teams.

8. Documentation and Quality of Software:

 o Proper documentation improves software quality by standardizing
procedures, aiding in knowledge transfer, and reducing the time required to
understand and maintain the system.

9. Good Practices for Documentation:

o Consistency: Use uniform terminology, templates, and formatting.

o Accuracy: Keep documents updated to reflect changes.

o Clarity and Brevity: Avoid jargon, use concise language, and ensure
readability.

o Use of Visuals: Flowcharts, diagrams, and infographics help explain

complex information.

Planning and Designing Systems

1. Process of System Planning:

o Purpose: The system planning process is where the project's scope,

feasibility, and requirements are established. This step is crucial for ensuring
the project aligns with business goals and is practical within resource
constraints.

o Fact-Finding Techniques:

▪ Interviews: Direct one-on-one or group interviews with key

stakeholders (such as managers, end-users, and IT staff) are essential
for understanding their needs and expectations. For example,
interviewing the HR team to understand their requirements for a
payroll management system.

▪ Group Discussions: Facilitating group discussions encourages

stakeholders to share ideas collectively, which often reveals diverse
requirements and builds consensus. For example, a group discussion
with sales and marketing teams may help in defining the features for a
CRM system.

▪ Site Visits: Observing workflows in the actual work environment

provides valuable insights into real-world challenges. For instance, a
site visit to a warehouse can reveal operational needs for an inventory
management system.
 ▪ Presentations and Demonstrations: By presenting preliminary ideas
or demonstrating similar systems, stakeholders can visualize
possibilities and provide targeted feedback.

▪ Questionnaires and Surveys: Effective for gathering data from a

larger audience, such as employees across different departments. A
survey to gauge preferred functionalities in a self-service portal can
help tailor the system to end-user needs.

2. Issues Involved in Feasibility Study:

o Purpose: The feasibility study evaluates whether the project is viable from
technical, operational, economic, and legal perspectives. It helps
stakeholders decide whether to proceed, modify, or abandon the project.

o Types of Feasibility:

▪ Technical Feasibility: Assesses if the required technology and

expertise are available. For example, determining if an organization
has the infrastructure to support a new cloud-based ERP system.

▪ Operational Feasibility: Checks if the proposed system can integrate

smoothly with existing operations. For instance, ensuring a CRM
system doesn’t disrupt established sales processes.

▪ Economic Feasibility: Evaluates cost vs. benefit. If a new inventory

system will reduce stock wastage by 20%, the potential savings can
justify the system cost.

▪ Legal Feasibility: Ensures compliance with laws and regulations,

such as GDPR for data privacy or HIPAA for healthcare.

▪ Cost-Benefit Analysis: Compares estimated costs to expected

benefits (e.g., increased productivity or reduced errors), helping
justify the project’s budget.

▪ Preparing a Schedule: Detailed scheduling involves setting deadlines

for each development phase, helping keep the project on track.
Project management software like Microsoft Project or Asana can be
used to track milestones.

o Gathering Requirements of System: Based on fact-finding results, this step

consolidates all functional and non-functional requirements, such as speed,
scalability, and security.
 o Joint Application Development (JAD): JAD sessions facilitate collaboration
between developers and stakeholders to gather and refine requirements.

o Prototyping: Building a small-scale version of the system, or prototype,

allows stakeholders to visualize and test functionalities, providing early
feedback.

Modular and Structured Design

1. Design Principles:

o Purpose: Design principles guide the structure and organization of the

system, aiming for efficiency, modularity, and maintainability.

o Modularity: Breaking down the system into distinct modules, each

responsible for specific functionalities. For example, a payroll system can
have separate modules for attendance tracking, salary calculations, and tax
deductions.

o Top-Down Design: Starting with an overall system outline and breaking it

down. For example, designing a hospital management system may start by
defining major functions (patient registration, billing, medical records), then
detailing each function.

o Bottom-Up Design: The reverse approach, where individual modules are

created first and then integrated. This can be useful when some modules are
complex and need focused attention early on.

o Structure Charts: Visual representations showing the hierarchy of modules

and their relationships, making it easier to see how data flows between
them.

2. Modularity, Goals of Design, Coupling, and Cohesion:

o Modularity: Allows independent development and testing, so one module’s

changes won’t impact others unnecessarily. For instance, an HR module’s
update shouldn’t affect payroll calculations.

o Goals of Design: Creating a system that is:

▪ Reliable: Ensures consistent, accurate operation.

▪ Maintainable: Allows easy updates or bug fixes.

 ▪ Scalable: Can handle increased workloads or data volume.

▪ User-Friendly: Intuitive interfaces for all users.

o Coupling: Refers to the degree of interdependency between modules. Low

coupling means changes in one module don’t heavily impact others,
promoting system flexibility.

o Cohesion: Indicates how focused a module is on its designated task. High

cohesion is preferred as it simplifies module functionality and increases
clarity.

System Design and Modelling

1. Logical and Physical Design:

o Logical Design: Defines the high-level system structure and flow of data
without specific technologies. For example, defining the workflow from order
entry to delivery in a sales system.

o Physical Design: Transforms logical designs into technical specifications for

implementation. This includes hardware, software, and detailed
programming requirements.

2. Process Modeling:

o Purpose: Process models visually represent workflows, helping developers

understand the sequence of tasks and interactions.

o Common Tools: Flowcharts, activity diagrams, and sequence diagrams

show task sequences, decision points, and interactions within a process.

3. Data Flow Diagrams (DFDs):

o Purpose: DFDs illustrate how data moves through a system, identifying key
processes and data stores.

o Components:

▪ External Entities: Sources or destinations of data, like a customer or

external supplier.

▪ Processes: Show transformations of data (e.g., “Process Order”).

 ▪ Data Stores: Represent databases or files where information is
stored.

▪ Data Flows: Arrows indicate data movement between entities,

processes, and stores.

4. Data Modeling and E-R Diagrams:

o Data Modeling: Defines data structure, attributes, and relationships.

o Entity-Relationship (E-R) Diagrams: Graphically represent the data entities

and relationships within the system, useful for structuring databases. In a
library system, entities like “Book,” “Member,” and “Loan” would have defined
relationships.

5. Process Specification Tools:

o These tools provide detailed specifications for processes, helping ensure

consistency across the system.

o Decision Tables: Represent business rules in a structured table format,

aiding decision-making consistency.

o Decision Trees: Visual representations of decision rules and outcomes,

useful for processes with branching paths.

6. Notation Structured English:

o Combines plain English with logical expressions for describing complex

processes in an easily understandable way, avoiding ambiguity.

7. Data Dictionary:

o Purpose: A data dictionary serves as a comprehensive reference for data

elements within the system, including names, types, formats, and
descriptions.

o Example: In a sales system, a data dictionary entry for "Customer_ID" might

specify it as a 10-character alphanumeric identifier.