Introduction to systems analysis and design: SDLC and methodologies

This course is about the work done before coding the software. You learn to answer the questions “what will we do, why will we do it, how will we do it”. The first week is the skeleton of the whole semester: every later topic (feasibility, use case, class diagram, test) fits into a phase of the SDLC. The midterm usually has definition questions (“which phase…”, “which methodology…”) and a short scenario with the question “which methodology fits, and why”.

Golden rules:

1. The SDLC has four phases: Planning, Analysis, Design, Implementation. Memorize the order and the question of each phase.
2. Each phase produces a deliverable. The deliverable is the input of the next phase.
3. A methodology says how the phases are ordered. The phases are the same; the ordering and the number of repetitions change.
4. The right methodology is chosen according to the project: how clear the requirements are, the schedule, technical risk, and when the user wants to see the system.

What is systems analysis and design?

An information system is hardware, software, data, processes and people together solving a business need. Systems analysis and design (SAD) is the orderly process followed to build this system. A common mistake here is to think of SAD as just “writing documents before programming”. The real goal is to create business value: the system serves the organization to earn money, save money or give better service.

Most projects fail not for technical reasons but because of bad analysis: wrong requirements, unclear scope, users not taking part in the process. That is why this course starts with process, not with code.

SDLC: four phases

The systems development life cycle (SDLC) is the four basic phases every information system goes through.

[Planning]->[Analysis]->[Design]->[Implementation]
    |           |          |            |
 system      system     system      installed
 request     proposal   spec        system

Planning

The project starts with a system request: a business unit reports a need in writing. An approval committee or steering committee evaluates the request. Feasibility analysis looks at “can it be done, is it worth it” from the technical, economic and organizational points of view. If approved, project management starts: the work plan, schedule, team.

Analysis

The analyst studies the current system (as-is) and works out what the new system (to-be) must do. Requirements gathering techniques (interviews, JAD, questionnaires, observation) are used here. Then the requirements are turned into models: the functional model (use case, activity diagram), the structural model (class diagram), the behavioral model (sequence, state machine). Everything is collected in a system proposal document, and the committee decides whether to continue the project.

Design

It is decided how the system will work: will we buy the software, write it ourselves, or have it built outside (design strategy)? The physical architecture (client-server, cloud), user interface, database and file structures, and program modules are designed. The deliverable is the system specification.

Implementation

The system is written, tested and installed. The conversion from the old system to the new one is planned, users are trained, and a support and maintenance plan is prepared. This is the most expensive phase.

PITFALL · testing is not only in implementation. Planning the tests starts in analysis (acceptance criteria) and continues in design. Coding and running tests happen in implementation, but saying “testing is first thought about here” is wrong.

Roles of the systems analyst

In large projects, analysis is not the job of one person; the roles are separated:

The analyst’s basic skills: technical knowledge, business knowledge, analytical thinking, communication and ethics. The analyst is the bridge between the user and the developer; they must be able to speak both the user’s language and the programmer’s language.

Methodologies

A methodology is a formalized way of carrying out the SDLC phases: which steps, in which order, with which deliverables. Methodologies fall into three big groups.

1. Structured design

Waterfall. The phases are done in sequence, and you do not move to the next one until one is finished and approved. Going back is possible but expensive.

Planning
   \--> Analysis
           \--> Design
                   \--> Implementation

Strength: the requirements are clear before coding, and documentation is strong. Weakness: the user sees the working system very late; if the business environment changes, the system may no longer be right when it comes out.

Parallel development. After planning and analysis a general design is made, the system is split into subprojects, and each subproject is designed and written at the same time. Integration is done at the end. The time is shortened; but if the subprojects depend on each other, integration is hard.

V-model. A variant of waterfall: opposite each development phase there is a test level (requirements ↔ acceptance test, architecture ↔ system test, module design ↔ unit test). The test plan is written early.

2. Rapid application development (RAD)

RAD (rapid application development) aims to show the user something working early.

• Iterative (phased) development: The system is divided into versions. Version 1 contains the most important requirements and is installed; later versions are added and it grows. The user sees value early, but the first version is incomplete.
• System prototyping: Analysis, design and implementation are done quickly at the same time, the prototype is shown to the user, and with feedback it grows into the system. Risk: a prototype made in a hurry can turn into a poorly thought-out design.
• Throwaway prototyping: The prototype is made only to understand unclear requirements (often an interface sketch), then discarded. The system is written with a solid design.

3. Agile development

Agile is based on the values of the Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.

Extreme Programming (XP): Short releases, test-first (tests are written first), pair programming, continuous integration, refactoring, collective code ownership, the customer on site with the team.

Scrum: The most widespread agile framework.

The weakness of agile: it struggles in large, distributed teams and in projects that require strict documentation (healthcare, defense).

Unified Process (RUP)

The Unified Process is a methodology used with UML for object-oriented projects. It has three characteristics: use-case driven, architecture-centric, iterative and incremental. It is two-dimensional: four phases over time, and workflows within each phase.

The engineering workflows: business modeling, requirements, analysis, design, implementation, test, deployment. Every workflow exists in all phases but its intensity changes: requirements are heavy in Inception and Elaboration, implementation in Construction.

PITFALL · a UP phase ≠ an SDLC phase. Don’t map them one-to-one like “Elaboration = Analysis”. In UP, several workflows run at the same time in each phase. In Elaboration analysis is heavy, but design and coding also begin.

Choosing a methodology: worked example

Scenario: A gym chain wants a membership system. Management doesn’t know exactly what it wants, saying “we’ll know it when we see it”. The system must open within 4 months together with a new branch. The team is small and experienced.

Look at the criteria one by one:

Result: Scrum or system prototyping. Waterfall does not fit because the requirements are unclear and the user wants to see it early.

Counter-scenario: A bank’s interest calculation module. The rules are precisely defined by law and do not change, the cost of an error is very high, and documentation is required for audit. Here waterfall or the V-model makes sense.

Common mistakes