Systems Analysis and Design — Week 1 Notes

SYSTEMS ANALYSIS AND DESIGN

Week 1 — Complete Study Notes

Topic 1: Introduction to Systems Analysis and Design

Anna University Syllabus | Undergraduate Curriculum

Covers: System Analysis · System Design · SDLC · Agile Development · Benefits · Activity

Page 1 of 8
 Systems Analysis and Design — Week 1 Notes

Topic 1 Overview: Introduction to Systems Analysis and Design

Systems Analysis and Design (SAD) is the structured process by which analysts study a business problem,
understand the requirements of an organisation, and design an information system that satisfies those
requirements efficiently. It combines analytical thinking (understanding "what" the system must do) with design
thinking (deciding "how" the system will do it).

Every information system that a business depends on — from a simple billing application to a large enterprise
resource planning (ERP) platform — passes through this discipline before it is built, tested, and handed over to
users. The unit begins by separating the overall subject into two broad pillars, which are then expanded into a
complete life cycle.

Key Idea
System Analysis answers "What does the system need to do?" while System Design answers "How will the system
do it?" Both together form the foundation of System Development.

1. System Analysis and Design

This section forms the umbrella topic for the week. System Analysis and Design refers to the complete set of
activities performed to examine an existing (or proposed) business situation, identify problems and
opportunities, and translate them into a well-structured, working information system. It sits between the
identification of a business need and the actual programming/construction of a solution.

● It ensures that the system built actually matches business requirements, not just technical convenience.
● It reduces the risk of costly rework by validating requirements early, before coding begins.
● It provides a common language (diagrams, models, documentation) between business users and technical
developers.
● It is typically carried out by a Systems Analyst, who acts as a bridge between end-users, management, and
the development/programming team.

1.1 System Analysis

System Analysis is the process of studying an existing system or business problem in detail so as to determine
what should be done and how the various parts of the system should work together. It focuses purely on
requirements — not on technology or implementation.

Objectives of System Analysis

● To understand the current system and identify its weaknesses, bottlenecks, and inefficiencies.
● To gather and document functional requirements (what the system must do) and non-functional
requirements (performance, security, usability).
● To define system boundaries — what is inside the scope of the new system and what is outside it.

Page 2 of 8
 Systems Analysis and Design — Week 1 Notes

● To communicate findings clearly to stakeholders using models such as Data Flow Diagrams (DFD), Use
Case Diagrams, and Entity-Relationship (ER) Diagrams.

Key Activities in System Analysis

1. Preliminary Investigation — a quick feasibility check to see whether the problem is worth solving with a
new system.
2. Requirements Gathering — interviews, questionnaires, observation, and document review are used to
collect information from users.
3. Requirements Documentation — the gathered information is organised into a Software Requirements
Specification (SRS) document.
4. Feasibility Study — technical, economic, operational, and schedule feasibility are analysed before
proceeding further.
5. Structured Analysis using Tools — DFDs, decision tables, decision trees, and data dictionaries are used to
model the logical flow of data.

Feasibility Type What It Checks

Technical Feasibility Whether the required technology, hardware, and skills are available.

Whether the benefits of the system outweigh the cost of building it

Economic Feasibility
(Cost-Benefit Analysis).

Whether the system will actually be used and accepted by the people in
Operational Feasibility
the organisation.

Schedule Feasibility Whether the project can be completed within the required time frame.

Page 3 of 8
 Systems Analysis and Design — Week 1 Notes

1.2 System Design

System Design is the phase that follows analysis. Once it is clear what the system must do, design decides how it
will be built — the architecture, data structures, interfaces, modules, and technologies that will be used to
satisfy the requirements captured during analysis.

Types of System Design

● Logical Design: Describes the functions and features of the system independent of any physical/technical
implementation — includes data flow, data structures, and process descriptions.
● Physical Design: Converts the logical design into technical specifications — hardware, software platform,
database schema, file structures, network architecture, and user-interface layouts.

Key Activities in System Design

6. Architectural Design — deciding the overall structure of the system (e.g., client-server, layered,
microservices).
7. Database Design — designing tables, relationships, normalisation, and storage structures.
8. Interface Design — designing how users will interact with the system (UI/UX, forms, reports, menus).
9. Input/Output Design — deciding the format of data entry screens and system-generated reports.
10. Security and Control Design — building in access controls, validation checks, and audit trails.

Remember
Analysis is problem-oriented ("what is needed"), while Design is solution-oriented ("how it will be built"). Good
design always traces back to a requirement identified during analysis.

1.3 The System Development Life Cycle (SDLC)

The System Development Life Cycle (SDLC) is a structured, step-by-step framework that describes the phases
through which an information system passes — from the moment a need is identified until the system is
delivered, used, and eventually retired. It provides a disciplined process so that projects are predictable, well-
documented, and of high quality.

Phases of the SDLC

11. Planning — Identify the business problem/opportunity, define project scope, and perform an initial
feasibility study.
12. Analysis — Gather and document detailed requirements from users; model the logical requirements of the
system.
13. Design — Translate requirements into a technical blueprint: architecture, database, interfaces, and
security design.
14. Implementation (Development) — Write the actual program code, build the database, and integrate all
system components.

Page 4 of 8
 Systems Analysis and Design — Week 1 Notes

15. Testing — Verify that the system works correctly and meets requirements (unit testing, integration
testing, system testing, user acceptance testing).
16. Deployment — Install the system in the live/production environment and migrate data from the old
system, if any.
17. Maintenance — Provide ongoing support, bug fixes, enhancements, and updates after the system goes
live.

SDLC Model Best Suited For

Waterfall Model Projects with clear, fixed, and well-understood requirements.

Iterative Model Projects where requirements are refined gradually across repeated cycles.

Spiral Model Large, high-risk projects that need continuous risk assessment.

Projects that need flexibility and fast delivery of working software in small
Agile Model
increments.

Projects where testing must be planned in parallel with every development

V-Model
phase.

Each SDLC model arranges the same seven phases differently — in strict sequence (Waterfall), in repeating
loops (Iterative/Spiral), or in short, incremental bursts (Agile) — depending on how much the requirements are
expected to change during the project.

Page 5 of 8
 Systems Analysis and Design — Week 1 Notes

1.4 Agile Development

Agile Development is a modern, iterative approach to the SDLC that focuses on delivering small, working pieces
of software quickly and continuously improving them based on feedback, rather than delivering one large
system at the very end of a long project.

Core Values of Agile (Agile Manifesto)

● Individuals and interactions are valued over rigid processes and tools.
● Working software is valued over comprehensive documentation.
● Customer collaboration is valued over strict contract negotiation.
● Responding to change is valued over following a fixed plan.

Key Characteristics
● Development happens in short cycles called Sprints (typically 1–4 weeks long).
● Requirements are captured as small, manageable units called User Stories.
● Cross-functional teams work closely together, often with daily stand-up meetings.
● Each sprint produces a potentially shippable increment of the product.
● Continuous customer feedback drives the direction of the next sprint.

Common Agile Frameworks

18. Scrum — organises work into fixed-length sprints with defined roles: Product Owner, Scrum Master, and
Development Team.
19. Kanban — visualises work on a board (To-Do, In-Progress, Done) and limits work-in-progress to improve
flow.
20. Extreme Programming (XP) — emphasises technical practices such as pair programming, test-driven
development, and continuous integration.

Exam Tip
Agile is not a single fixed process — it is a mindset guided by the Agile Manifesto, implemented through
frameworks such as Scrum, Kanban, or XP.

1.5 Benefits
Adopting a disciplined System Development Life Cycle — especially when combined with Agile practices —
brings measurable advantages to both the development team and the business that commissions the system.

Benefits of Following the SDLC

● Provides a clear roadmap, so every team member understands what phase the project is in.
● Improves quality through structured testing at every stage rather than only at the end.

Page 6 of 8
 Systems Analysis and Design — Week 1 Notes

● Reduces project risk by catching requirement errors early, when they are cheapest to fix.
● Improves documentation, making the system easier to maintain and hand over to new staff.
● Improves communication between business stakeholders and the technical team.

Benefits of Agile Development Specifically

● Faster delivery of usable software, since working increments are released every sprint.
● Greater flexibility to accommodate changing requirements without restarting the project.
● Continuous stakeholder involvement reduces the chance of building the wrong product.
● Early and frequent testing improves overall software quality.
● Higher team morale and ownership, since teams are self-organising and see regular progress.

Activity: Agile Development and SDLC Benefits

This activity is designed to help you connect the theory of the SDLC with the practical benefits Agile brings to
real software projects.

Instructions
21. Choose any small software idea (e.g., a library management app, an online food-ordering app, or a student
attendance tracker).
22. Map the idea onto the seven SDLC phases: Planning, Analysis, Design, Implementation, Testing,
Deployment, and Maintenance — write one or two lines describing what would happen in each phase for
your chosen idea.
23. Break the Analysis and Design phases into 3–4 short User Stories, written in the format: "As a [user], I
want [feature], so that [benefit]."
24. Organise these user stories into two short Sprints (Sprint 1 and Sprint 2), assuming each sprint lasts two
weeks.
25. List at least three specific benefits your project would gain from using Agile instead of a strict Waterfall
approach.

Discussion Questions
● Why is it risky to skip the Analysis phase and move directly to coding?
● How does breaking work into sprints reduce the overall risk of the project?
● In what situation might Waterfall still be a better choice than Agile?

Learning Outcome
By completing this activity, you should be able to explain each SDLC phase in your own words and justify why Agile
development improves flexibility, quality, and stakeholder satisfaction compared to traditional models.

Page 7 of 8
 Systems Analysis and Design — Week 1 Notes

— End of Week 1 Notes —

Prepared for structured, exam-oriented revision.

Page 8 of 8