Systems Analysis and Design

Systems analysis and design

Systems analysis and design is the process of studying a business or organisation's information needs and problems (analysis) and then specifying and building a computer-based system to meet them (design). Analysis determines what the system must do; design determines how it will do it.

Modern approaches

1. Structured (process-oriented) approach: top-down, uses DFDs, ER diagrams, structure charts and the SDLC (waterfall), with processes and data modelled separately.
2. Object-oriented approach: models the system as interacting objects and classes using UML (use-case, class, sequence diagrams); promotes reuse.
3. Rapid application development (RAD) and prototyping: fast delivery by repeated prototypes, user involvement, CASE tools and reusable components.
4. Agile methods (Scrum, XP): short iterations, working software, continuous customer collaboration and adaptation to change.
5. CASE tools and component/commercial packages: automated tools supporting modelling, code generation and documentation, with off-the-shelf software and web/cloud services used where suitable.

Modern approaches stress user participation, iteration, reuse, and speed.

Project planning is the process of defining the scope, work, time, cost, resources and risks of a project, and recording them in a plan that guides the team. A project manager does it at the start of the project. It is refined during the project.

Activities performed during project planning:

1. Describing the project scope, alternatives and feasibility: state the problem, the objectives, the deliverables and what is out of scope. Study the economic, technical, operational, schedule and legal feasibility.
2. Dividing the project into manageable tasks: break the work down into phases and tasks (a work breakdown structure) and identify the dependencies between them.
3. Estimating resources and creating a resource plan: estimate the people, hardware, software and money needed, and assign skills to tasks.
4. Developing a preliminary schedule: set start and end dates and milestones, using Gantt charts or PERT/CPM.
5. Developing a communication plan: decide who is told what, when and how.
6. Determining project standards and procedures: set documentation, coding, testing and change-control standards.
7. Identifying and assessing risks: list the risks, rate their likelihood and impact, and plan how to reduce them.
8. Creating a preliminary budget.
9. Developing a statement of work and a baseline project plan that the client and management approve.

The modern approaches to systems analysis and design are structured, object-oriented and agile methods that support rapid and flexible development. The main ones are:

1. Model-driven development. The system is described through models before it is built. Two forms are:

• Structured analysis and design: a process-oriented approach in which the system is decomposed using DFDs, data dictionary, ER diagrams and structure charts (top-down).
• Object-oriented analysis and design (OOAD): the system is modelled as objects and classes with data and behaviour together, using UML (use case, class, sequence and state diagrams). It encourages reuse, encapsulation and inheritance.

2. Rapid application development (RAD). Prototyping, CASE tools, JAD sessions, reusable components and time-boxed iterations are used to deliver the system quickly. Users take part throughout.

3. Agile methodologies. Development is iterative and incremental, with short cycles, working software at each increment, continuous customer collaboration and quick response to change (for example Scrum, XP).

4. CASE tools and computer-aided modelling. Software tools draw the diagrams, check consistency, store the repository and generate code.

Diagram: iterative modern development

 Requirements --> Analysis & Design --> Build (prototype) --> Test
       ^                                                       |
       |            User feedback / next iteration             |
       +<------------------------------------------------------+
                         (repeat until accepted)

Compared with the traditional waterfall approach, the modern approach lets users see the system early, lowers the risk, accepts changing requirements and shortens the delivery time.

The activities performed during the project planning phase are:

1. Describing the project scope, alternatives and feasibility: define the problem, objectives, deliverables and boundaries, and study the feasibility of the alternatives.
2. Dividing the project into manageable tasks: make a work breakdown structure of phases, tasks and their dependencies.
3. Estimating resources and creating a resource plan: estimate the people, equipment, software, time and money needed.
4. Developing a preliminary schedule: set the dates and milestones with a Gantt chart or PERT/CPM network.
5. Developing a communication plan: decide how and when the team, users and management receive information and reports.
6. Determining project standards and procedures: fix the documentation, coding, testing and change-control standards.
7. Identifying and assessing risks: list the risks, assess them and plan how to reduce them.
8. Creating a preliminary budget: estimate the costs and benefits.
9. Developing a statement of work: write what is to be done, the deliverables and the conditions.
10. Setting a baseline project plan: combine the above into a plan that management approves to guide the project.

System development life cycle (SDLC)

The SDLC is a structured, phased methodology for planning, creating, testing, deploying and maintaining an information system. It gives a standard framework so that the system is built on time, within budget and meets user needs.

Phases of SDLC

1. Planning (project identification and selection, initiation and planning)

   • Identify the need, define the scope, and carry out a feasibility study (technical, economic, operational, schedule, legal).
   • Prepare the project plan, schedule, resources and budget, and form the team.
   • Deliverable: baseline project plan and feasibility report.

2. Analysis

   • Collect requirements by interviews, questionnaires, observation and document study.
   • Model the current system and the needed system using DFDs, ER diagrams, decision tables.
   • Study alternatives and prepare the system requirement specification (SRS).
   • Deliverable: SRS and system proposal.

3. Design

   • Logical design: process, data, and interface models.
   • Physical design: database design, program and module design, input/output forms, screens, reports, hardware and network architecture, security controls.
   • Deliverable: system design specification.

4. Implementation (coding, testing, installation)

   • Coding and unit, integration and system testing.
   • Installation (direct, parallel, phased or pilot), data conversion, user training and documentation.
   • Deliverable: working system, manuals, trained users.

5. Maintenance

   • Corrective (fix errors), adaptive (changes in environment), perfective (new features, performance) and preventive maintenance.
   • Continues until the system is retired and a new SDLC begins.

The phases may be run as waterfall (sequential), iterative, or with prototyping, depending on the project.

Project planning

Project planning is the process of defining the scope, objectives, tasks, resources, schedule, cost and risks of a project and documenting them in a plan that guides execution and control. It answers what will be done, who will do it, when, at what cost, and how quality will be ensured.

Project initiation

Project initiation starts the project and builds a base for planning. Its activities are:

• Establishing the project initiation team (analysts, users, managers).
• Establishing a relationship with the customer (client) and clear communication.
• Establishing the project initiation plan (what is to be done in initiation).
• Establishing management procedures (team roles, communication, reporting, standards, change control).
• Establishing the project management environment and workbook (tools, files, documentation).
• Developing the project charter stating the title, sponsor, objectives, scope, assumptions, high-level schedule and budget.

Project planning (the planning phase proper)

• Describe the project scope, alternatives and feasibility: define the system boundary, business benefits, and check technical, economic, operational, schedule and legal feasibility.
• Divide the project into manageable tasks: work breakdown structure (WBS) with milestones, dependencies and durations.
• Estimate resources and create a resource plan: people, hardware, software, time.
• Develop a preliminary schedule: using Gantt charts and PERT/CPM network diagrams.
• Develop a communication plan for stakeholders.
• Determine project standards and procedures (documentation, coding, testing).
• Identify and assess risk, and plan to reduce it.
• Create a preliminary budget (cost estimate and cost-benefit).
• Develop the project scope statement (SOW) and baseline project plan.
• Set a baseline project plan that is reviewed and approved by the sponsor before moving to analysis.

Online food ordering system

Assumptions: customers browse the menu, place orders and pay online; the restaurant/admin manages menu and processes orders; a payment gateway handles payments; a delivery person delivers.

Context diagram (Level 0)

 Customer  --registration, login, order, payment info-->  +----------------+  --order details-->  Restaurant/Admin
           <--menu, order confirmation, bill-----------   |  Online Food   |  <--menu updates, order status
                                                          |  Ordering      |
 Payment Gateway <--payment request-- ------------------  |  System (0)    |  --delivery details--> Delivery Person
                 --payment status-->                      +----------------+  <--delivery status

External entities: Customer, Restaurant/Admin, Payment Gateway, Delivery Person.

Level 1 DFD

Processes:

1. Manage Accounts: customer registration and login (D1 Customer).
2. Manage Menu: admin adds, updates, removes food items (D2 Menu).
3. Process Order: customer selects items, order saved (D3 Order).
4. Process Payment: sends to gateway, receives status (D4 Payment).
5. Manage Delivery: assigns delivery person, tracks status (D5 Delivery).
6. Generate Reports: sales and order reports for admin.

Main flows:

• Customer $\rightarrow$ 1: registration/login details. 1 $\leftrightarrow$ D1.
• Admin $\rightarrow$ 2: food item details. 2 $\leftrightarrow$ D2; 2 $\rightarrow$ Customer: menu.
• Customer $\rightarrow$ 3: selected items. 3 reads D2, writes D3. 3 $\rightarrow$ 4: order total.
• 4 $\leftrightarrow$ Payment Gateway; 4 writes D4; 4 $\rightarrow$ Customer: bill/receipt.
• 3 $\rightarrow$ Admin: new order. 3 $\rightarrow$ 5: confirmed order. 5 reads D3, writes D5; 5 $\leftrightarrow$ Delivery Person; 5 $\rightarrow$ Customer: delivery status.
• 6 reads D3, D4 $\rightarrow$ Admin: reports.

Level 2 DFD (expanding Process 3: Process Order)

• 3.1 Select Items: Customer $\rightarrow$ item choice; reads D2 Menu; output: cart.
• 3.2 Validate Availability: checks stock/availability in D2; rejects unavailable items.
• 3.3 Calculate Total: applies price, tax, discount; output: order total.
• 3.4 Confirm and Store Order: writes D3 Order; sends order confirmation to Customer and order notice to Admin; passes order total to Process 4.

Level 2 for Process 4: Process Payment

• 4.1 Choose Payment Method (Customer).
• 4.2 Send Payment Request to Payment Gateway.
• 4.3 Verify Payment Status from gateway; writes D4 Payment.
• 4.4 Generate Receipt sent to Customer.

Data stores and processes are balanced: inputs and outputs of each level 2 set match those of the parent process.

Object-oriented development

Object-oriented (OO) development models a system as a collection of interacting objects, each combining data (attributes) and behaviour (operations). It follows the SDLC using OO analysis (OOA), OO design (OOD) and OO programming. Key concepts: object, class, encapsulation, inheritance, polymorphism, abstraction, message passing.

Advantages: reuse of classes, easier maintenance, close fit with the real world, and consistent notation (UML) across phases.

Class diagram

A class diagram (UML) shows the static structure: classes with attributes and operations, and relationships (association, aggregation, composition, generalization/inheritance) with multiplicity.

Each class is a box with three compartments: name, attributes, operations.

Example (library):

+------------------+ 1        0..*  +------------------+
| Member           |----------------| Book             |
|------------------| borrows        |------------------|
| - memberId       |                | - isbn           |
| - name           |                | - title          |
|------------------|                |------------------|
| + borrowBook()   |                | + isAvailable()  |
| + returnBook()   |                +------------------+
+------------------+
        ^
        | (generalization)
+------------------+
| Student          |
|------------------|
| - program        |
+------------------+

Here Student inherits from Member, and a Member may borrow many Books (multiplicity $1$ to $0..*$). Visibility marks: $+$ public, $-$ private.

Importance of project management

• Delivers the system on time, within budget, and with the required quality and scope.
• Plans and coordinates people, tasks, and resources, avoiding conflict and waste.
• Identifies and controls risks and changes early.
• Provides control through monitoring, progress reports and corrective action.
• Improves communication among users, developers and management, and raises customer satisfaction.
• Prevents failure: many IS projects fail due to poor planning, scope creep and weak control.

Using a network diagram for scheduling (PERT/CPM)

A network diagram shows project tasks as nodes (or arrows) with their precedence relations.

Steps:

1. List all activities (from the WBS) and their immediate predecessors.
2. Estimate the duration of each activity (PERT uses optimistic $o$, most likely $m$, pessimistic $p$: $t = \frac{o + 4m + p}{6}$).
3. Draw the network from start to finish.
4. Forward pass: compute earliest start (ES) and earliest finish $EF = ES + t$. At merges, take the largest EF.
5. Backward pass: compute latest finish (LF) and latest start $LS = LF - t$. At branches, take the smallest LS.
6. Slack $= LS - ES$. Activities with zero slack form the critical path, the longest path, which determines the project duration.

Use: the project manager knows the minimum project time, which tasks cannot be delayed, which have slack to reschedule resources, and can estimate the effect of delays. Example: A(3) $\rightarrow$ B(4) and A $\rightarrow$ C(2), both to D(5). Paths A-B-D $= 12$, A-C-D $= 10$; the critical path is A-B-D (12 days), C has 2 days of slack.

Data modeling

Data modeling is the process of identifying, organising and documenting the data a system needs and the relationships among the data, usually shown as a conceptual model such as an entity-relationship (ER) diagram. It captures entities, attributes, relationships and business rules before the database is designed.

ER diagram: students, courses and grades

Entities and attributes:

• STUDENT (<u>student_id</u>, name, address, phone, program)
• COURSE (<u>course_id</u>, title, credit_hours)
• ENROLLMENT/GRADE as the relationship between STUDENT and COURSE, with attributes semester, grade.
• Optionally INSTRUCTOR (<u>instructor_id</u>, name) teaches COURSE.

 [STUDENT] ----< ENROLLS (semester, grade) >---- [COURSE] >---- teaches ---- [INSTRUCTOR]
   M                                                N

Relationships:

• A student enrolls in many courses and a course has many students: many-to-many (M:N), resolved by the associative entity ENROLLMENT with composite key (student_id, course_id, semester) and attribute grade.
• An instructor teaches many courses, a course is taught by one instructor: 1:N.

Relational form: STUDENT(student_id, ...), COURSE(course_id, ..., instructor_id), ENROLLMENT(student_id, course_id, semester, grade).

Identification and selection of system development projects

This is the first phase of the SDLC, in which an organisation decides which potential projects to pursue, as resources are limited.

Identification

Projects are identified by:

• Top management (strategic plan)
• Steering committee
• User departments (needs, problems, opportunities)
• Development group
• Information systems planning (long-term plan using the organisation's goals)

Classification and selection

Proposed projects are evaluated, classified and ranked using criteria such as:

• Value chain analysis (which activities add most value)
• Strategic alignment with organisational goals
• Potential benefits (tangible and intangible)
• Resource availability (people, money, time)
• Project size and duration
• Technical difficulty and risk
• Economic and operational feasibility

A steering committee compares the projects and selects those with the best overall value; others are deferred or rejected.

Outcomes

A decision to accept, reject or defer each request, and a basic problem statement, scope and feasibility summary for the accepted project, which then moves to initiation and planning.

Interviewing for system requirements

Interviewing is the most widely used fact-finding technique: an analyst converses directly with users, managers and other stakeholders to learn how the current system works, what problems exist and what they need from the new one.

Steps

1. Select interviewees: choose people from all levels (managers, operators, clerks) who know the system.
2. Prepare: read background material, decide objectives, prepare a list of questions, and schedule a time and place.
3. Design questions:
   • Open-ended ("How do you process an order?") to get detail and opinions.
   • Closed-ended ("How many orders per day?") for specific facts.
   • Probing follow-ups.
4. Conduct the interview: introduce the purpose, put the person at ease, ask clearly, listen actively, and take notes (or record with permission). Avoid leading or biased questions.
5. Close and review: summarise findings, confirm understanding, and thank the person.
6. Follow-up: write up the interview notes promptly and verify them with the interviewee; resolve conflicts with other sources.

Guidelines: be neutral, keep to the time, use both structured and unstructured formats.

Advantages: rich information, immediate clarification, builds user rapport. Limitations: time consuming, costly, depends on the interviewee's honesty and the analyst's skill.

Designing interfaces and dialogues

A user interface is how a user interacts with the system (inputs, outputs, navigation); a dialogue is the sequence of interaction between user and system.

Process

1. Prepare: identify the users, their tasks, skills and the environment.
2. Structure the interface: choose the interaction style: menus, command language, forms, natural language, object-based or graphical (GUI).
3. Design the layout of forms and reports: logical grouping of fields, consistent positions, clear labels, default values, tab order.
4. Design the dialogue: define the sequence of screens, using a dialogue diagram showing screens/boxes and transitions between them.
5. Prototype screens quickly and evaluate with users (usability testing), then refine.

Guidelines

• Consistency of layout, terms and colours.
• Simplicity and minimum keystrokes.
• Clear, polite feedback and error messages with a way to correct and undo.
• Validate input (type, range, format, mandatory) and give help.
• Visible navigation and system status.
• Consider accessibility and user experience.

Importance of documentation

Documentation is the written record of the system (system and user documentation).

• Describes how the system works for future maintenance and changes, even if the original developers have left.
• Helps users learn and operate the system (user manual, help, FAQ), reducing errors and support calls.
• Provides a record of requirements, design and test results for audit, control and quality assurance.
• Supports communication within the development team and with the client.
• Helps in training, troubleshooting and system upgrades.

Importance of training

• Users gain the skills to use the system effectively and confidently, ensuring the system's benefits are realised.
• Reduces mistakes, resistance to change, and dependence on technical staff.
• Supports administrators and operators in managing, backing up and securing the system.
• Improves acceptance and productivity.

Training can be done by classroom, hands-on, tutorials, online help, or vendor support, and is planned during implementation.

System maintenance

System maintenance is the process of changing and supporting an information system after it has been delivered and installed, so it keeps functioning correctly and meets changing needs. It is the longest and most costly phase of the SDLC.

Types

• Corrective: fixing bugs and errors found in use.
• Adaptive: modifying the system for changes in the environment (law, hardware, OS).
• Perfective: adding features or improving performance and usability.
• Preventive: improving structure and reliability to avoid future problems.

How maintenance is conducted

1. Obtain a maintenance request (error report or change request) from users using a standard form.
2. Analyse the request: determine its type, priority, scope and cost; approve or reject by a change control board.
3. Design the change: study the existing code and documentation and plan the modification.
4. Implement the change: modify the program, database or interface in a controlled environment.
5. Test the changed part and regression test the whole system.
6. Release the new version (installation, data conversion), and update documentation and train users.
7. Control: use configuration and version control, keep a maintenance log and measure effectiveness (number of failures, mean time between failures, response time).

Organisation: a maintenance team or the original developers, with a help desk and a change management process.

(a) Rapid application development (RAD)

RAD is a methodology that speeds up system development by using iterative prototyping, active user involvement, reusable components and powerful tools (CASE, 4GL, code generators) instead of long sequential phases.

Features: small teams, time-boxed iterations (typically 60-90 days), joint application design (JAD) workshops, prototype refined repeatedly with users, reuse of components.

Phases: requirements planning, user design (JAD and prototyping), construction (build and test), cutover (installation and training).

Advantages: fast delivery, early user feedback, lower cost. Limitations: needs skilled people and committed users, not suited to very large or high-risk systems, may sacrifice quality or scalability.

(b) Economic feasibility

Economic feasibility (cost-benefit analysis) checks whether the expected benefits of a proposed system exceed its costs.

• Costs: development (one-time: analysis, hardware, software, training) and operating (recurring: maintenance, staff, supplies).
• Benefits: tangible (cost savings, increased revenue, reduced errors) and intangible (better service, decision-making, morale).
• Techniques: payback period, net present value (NPV), return on investment (ROI), break-even analysis.

If benefits outweigh costs, and payback is acceptable, the project is economically feasible.

Identifying and selecting information system development projects

Organisations have more project requests than they can fund, so a systematic process is used in the first phase of the SDLC (project identification and selection).

1. Identifying potential development projects

Sources of ideas:

• Top management and the strategic plan
• Steering committee
• User departments with problems or new needs
• Development group (technical opportunities)
• Information systems planning, which links IS to organisational goals using the current systems, goals and the future architecture

2. Classifying and ranking projects

Requests are evaluated by a steering committee against criteria such as:

• Value chain analysis (which activities are most valuable to improve)
• Strategic alignment
• Potential benefits (tangible and intangible)
• Resource availability (people, money, time)
• Project size, duration and complexity
• Technical difficulty and risk
• Economic and operational feasibility

3. Selecting projects

Using a decision based on the evaluation, the committee accepts, rejects, defers or sends back each request. Selection considers the overall value and risk, which also depends on factors such as the organisation's priorities.

Deliverables and outcomes

• Deliverable: a schedule of selected and deferred projects (priority list) and a project proposal with the problem statement, scope and preliminary feasibility for each selected project, often a system service request (SSR) and a feasibility study / baseline project plan.
• Outcomes: a decision to commit resources to the selected project(s) (go/no-go), a defined scope and objective, and the approval to proceed to project initiation and planning; the decisions are communicated to those who requested them.

Why analysts use DFDs

A data flow diagram (DFD) shows how data moves through a system: the processes, data stores, external entities and data flows.

• Gives a clear, graphical, easy-to-understand view of the system, for users and analysts alike.
• Focuses on what the system does (logic), not how, so it is independent of implementation.
• Allows top-down decomposition into levels of detail (context, level 0, 1, ...).
• Helps find missing, redundant or unclear processes and data during analysis.
• Is a communication and documentation tool for requirement verification and design.

Retail clothing store: assumptions

Customers choose clothes and pay at the counter; the store orders stock from suppliers; the manager gets sales reports.

Context diagram

 Customer  --purchase request, payment-->  +---------------------+ --purchase order--> Supplier
           <--bill/receipt, clothes------  | Retail Clothing     | <--invoice, goods---
 Manager   --price/product updates------>  | Store System (0)    |
           <--sales and stock reports----  +---------------------+

External entities: Customer, Supplier, Manager.

Level 1 DFD

Processes:

1. Manage Inventory: updates product stock (D1 Product/Inventory); receives goods and invoice from Supplier; reads/writes D1.
2. Process Sale: Customer selects items; checks price and availability from D1; calculates total (with discount); records in D2 Sales; updates D1.
3. Accept Payment and Issue Receipt: takes payment from Customer; sends receipt/bill; updates D2.
4. Order Stock: when stock falls below reorder level (reads D1), sends purchase order to Supplier; stores in D3 Purchase Orders.
5. Generate Reports: reads D1, D2, D3; sends sales and stock reports to Manager.

Flows: Manager $\rightarrow$ 1: price and product details. Customer $\rightarrow$ 2: purchase request. 2 $\rightarrow$ 3: bill amount. Customer $\rightarrow$ 3: payment. 3 $\rightarrow$ Customer: receipt. 4 $\rightarrow$ Supplier: purchase order; Supplier $\rightarrow$ 1: goods received and invoice.

Systems development methodology

A systems development methodology is a standard, documented set of procedures, techniques, tools and documentation aids used to develop information systems. It guides the developers through the work in a consistent, repeatable way.

Systems development life cycle (SDLC)

The SDLC is the series of phases through which an information system passes from conception to retirement: planning, analysis, design, implementation, maintenance.

Diagram

 Planning -> Analysis -> Design -> Implementation -> Maintenance
     ^                                                    |
     +----------------- new system / next cycle ----------+

Phases

1. Planning: identify the need, assess feasibility (technical, economic, operational, schedule), prepare the project plan, schedule and budget. Output: baseline project plan.
2. Analysis: gather requirements (interviews, questionnaires, observation, documents), model data and processes (DFD, ER), generate and compare alternatives. Output: system requirement specification and proposal.
3. Design: logical design (data, process models) then physical design (database, program modules, forms, reports, interfaces, hardware/software, security). Output: design specification.
4. Implementation: coding, testing (unit, integration, system, acceptance), installation (direct, parallel, phased, pilot), conversion, documentation and user training. Output: working system and manuals.
5. Maintenance: corrective, adaptive, perfective and preventive changes after installation until the system is retired.

Each phase has defined deliverables, and the results are reviewed before moving on, though phases may overlap or iterate.

Object-oriented analysis and design (OOAD)

OOAD is a software engineering approach that models a system as a group of interacting objects, each representing an entity with data (attributes) and behaviour (methods), using UML.

Object-oriented analysis (OOA)

Concerned with what the system must do:

• Identify requirements and actors; model with use-case diagrams.
• Identify problem-domain classes, attributes, operations and relationships; model with class diagrams.
• Model behaviour with sequence/collaboration diagrams, and state diagrams for object life cycles.

Object-oriented design (OOD)

Concerned with how:

• Refine analysis classes with implementation details (data types, visibility, interfaces).
• Design the architecture, user interface, database mapping (objects to tables) and control/system classes.
• Apply design patterns and plan components and deployment.

Key concepts: object, class, encapsulation, abstraction, inheritance, polymorphism, message passing.

Advantages: reuse, modularity, easier maintenance, natural mapping to the real world, a consistent model from analysis to code. Disadvantages: steeper learning curve, may be overkill for small systems.

Project evaluation criteria for classifying and ranking projects

Since resources are limited, the steering committee compares candidate projects on several criteria:

1. Value chain analysis: preference for projects that improve activities adding most value (e.g. customer service, operations).
2. Strategic alignment: how closely the project supports the organisation's mission and strategic goals.
3. Potential benefits: tangible (cost reduction, revenue) and intangible (better service, decision making, morale) and the timing of those benefits.
4. Resource availability: people, money, hardware and time needed against what is available.
5. Project size and duration: number of people, time and cost; small, short projects are less risky.
6. Technical difficulty and risk: experience with the technology, complexity, integration with existing systems, probability of failure.
7. Economic feasibility: cost-benefit measures such as payback, ROI and NPV.
8. Operational/organisational feasibility: user acceptance and fit with the organisation.
9. Legal, contractual and schedule feasibility, and the urgency (mandatory or regulatory requirements).

Each project is scored (often by weighted scoring) on these criteria and the ranked list is used for selection.

Economic feasibility

Economic feasibility (cost-benefit analysis) is the study of whether the expected financial benefits of a proposed system exceed its costs, so that the investment is justified. It considers:

• One-time costs: development, hardware, software, training, data conversion.
• Recurring costs: maintenance, operation, staff, supplies, licences.
• Tangible benefits: cost savings, increased sales, reduced errors, faster processing.
• Intangible benefits: better service, customer satisfaction, improved decisions.

Commonly used cost-benefit analysis techniques

1. Net present value (NPV): sum of discounted benefits minus discounted costs, with discount rate $r$: $NPV = \sum_{t=0}^{n} \frac{B_t - C_t}{(1+r)^t}$ Accept if $NPV > 0$.
2. Return on investment (ROI): $\dfrac{\text{total benefits} - \text{total costs}}{\text{total costs}}$.
3. Break-even analysis: the point (time) when cumulative benefits equal cumulative costs.
4. Payback period: time needed for benefits to recover the initial investment.
5. Also: cost-benefit ratio and internal rate of return (IRR).

Interviewing and listening for requirements

Interviewing

Interviewing is a direct, face-to-face fact-finding method in which the analyst questions users, managers and others to learn about the current system and the needs for the new one.

Process:

1. Select interviewees from different levels.
2. Prepare: set objectives, background reading, appointment and a list of questions.
3. Use open-ended questions (opinions, detail) and closed-ended questions (specific facts), with probing follow-ups.
4. Conduct the interview: explain the purpose, be neutral and polite, keep to time, avoid leading questions.
5. Take notes or record with permission, then summarise and confirm.
6. Write up the notes soon after and verify with the interviewee.

Types: structured (fixed questions) and unstructured (free flow).

Listening

Good interviewing depends on good listening:

• Give full attention and keep eye contact.
• Do not interrupt or judge; allow pauses.
• Paraphrase and ask clarifying questions to confirm understanding.
• Watch non-verbal cues (tone, body language).
• Record the key points, separating facts from opinions.

Interviews give detailed information and rapport, but are time consuming and subjective, so they are combined with questionnaires, observation and document study.

Decision table

A decision table is a tabular method for describing the logic of decisions: it lists all the conditions, the condition alternatives (rules), and the actions to take for each combination. It is compact, complete and easy to check for missing or conflicting rules, and is used when many conditions affect the action.

Parts: condition stub, condition entries, action stub, action entries. Entries are Y/N (or specific values); in the actions, X marks the action to be taken. With $n$ binary conditions there are $2^n$ rules.

Example: discount policy

Conditions: C1: Customer is a member? C2: Purchase over Rs 5,000?

Reading R1: if the customer is a member and spends more than Rs 5,000, give a 15% discount. Rules with the same action can be combined, and an ELSE rule can be added to simplify.

Conceptual data model

A conceptual data model is a high-level, technology-independent description of the organisation's data: the entities, their attributes, the relationships between them, and business rules. It is usually shown as an ER diagram, and is used during analysis to communicate the data needs with users.

Logical database design

Logical design converts the conceptual model into a form for a specific type of DBMS (usually relational), without considering physical storage. Steps:

1. Map the ER model to relations: each entity becomes a relation with its primary key; M:N relationships become associative relations; 1:N relationships are implemented by a foreign key on the many side.
2. Normalise the relations (1NF, 2NF, 3NF) to remove redundancy and update anomalies.
3. Merge relations from different user views, resolving synonyms and homonyms.
4. Define integrity constraints: primary keys, foreign keys, domains, referential integrity.

The result is a set of well-structured relations that is then used for physical database design (files, indexes, storage).

Process of designing interfaces and dialogues

1. Gather information: identify the users, their tasks, experience and the environment, and the data to be input and shown.
2. Select the interaction style to match users and tasks: menus, command language, form fill-in, object-based/GUI, natural language.
3. Structure the interface: organise functions into logical groups and decide the navigation among screens.
4. Design the dialogue using a dialogue diagram that shows each screen/form and the transitions caused by user actions. Include normal and error paths and help.
5. Design forms, screens and reports: logical grouping of fields, consistent layout, clear labels, defaults, tab order, colours, and the validation of data (range, type, format, mandatory).
6. Build a prototype of the screens and dialogue.
7. Evaluate with users (usability testing, walk-throughs) and refine the design repeatedly.
8. Document the interface specification for implementation.

Guidelines: consistency, simplicity, feedback, clear error messages, ability to undo, accessibility and minimal user effort.

Approaches to installation

Installation is the process of replacing the old system with the new system. The main approaches are:

1. Direct (abrupt/cutover) installation: the old system is turned off and the new one is turned on at a set time. Quick and cheap, but high risk, since a failure stops the operation.
2. Parallel installation: old and new systems run together for a period, and outputs are compared before the old is retired. Low risk, but it requires double effort and resources.
3. Single location (pilot) installation: the new system is installed in one site/department first, and then extended to others after testing. Limits risk and gives experience.
4. Phased installation: the new system is introduced module by module (or gradually), replacing the old system in stages. Reduces risk but takes longer and needs interfaces between old and new parts.

Most expensive: parallel installation is the most expensive, because the organisation bears the cost of running and staffing two systems at the same time, as well as the effort for comparing outputs. Direct is the cheapest but the riskiest.

Rapid application development (RAD)

RAD is a systems development methodology that shortens development time by combining iterative prototyping, active user participation (such as JAD sessions), reusable components and CASE/4GL tools, rather than long sequential phases.

Phases: requirements planning, user design (JAD, prototypes), construction (build, test), and cutover (installation, training). Projects are time-boxed (often 60-90 days) with small, skilled teams.

Advantages: fast delivery, lower cost, early feedback. Limitations: needs committed users and skilled developers, unsuitable for large or high-risk systems, may compromise scalability and quality.

Agile development

Agile development is a family of iterative, incremental methods (Scrum, Extreme Programming, Kanban) based on the Agile Manifesto, which values:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation;
• responding to change over following a plan.

Key features:

• Work is divided into short iterations (sprints) of 1 to 4 weeks, each producing a working increment.
• Close, continuous customer involvement, with requirements kept as a prioritised backlog (user stories).
• Small, self-organising, cross-functional teams with daily stand-up meetings.
• Continuous testing, integration and refactoring (e.g. pair programming, test-driven development in XP).
• Regular reviews and retrospectives for improvement.

Advantages: adaptability to changing requirements, early and frequent delivery, high customer satisfaction. Limitations: less predictable cost and schedule, light documentation, and it needs experienced, disciplined teams and customer availability.

Need for a feasibility study

A feasibility study is done early in the project (during planning) to determine whether the proposed system is worth building. It is needed to:

• Avoid wasting money and time on projects that cannot succeed.
• Identify risks and obstacles early.
• Compare alternative solutions and choose the best.
• Give management the information for a go/no-go decision.
• Provide a base for the project plan, schedule and budget.

Types of feasibility

1. Technical feasibility: can the system be built with the available or obtainable technology and expertise? Considers hardware, software, networks, the team's skills, project size and compatibility with existing systems.
2. Economic feasibility: do the expected benefits exceed the costs? Uses cost-benefit analysis (payback, ROI, NPV, break-even) comparing development and operating costs with tangible and intangible benefits.
3. Operational feasibility: will the system work in the organisation and be accepted and used by the users? Considers user attitude, fit with business processes, and training needs.
4. Schedule feasibility: can the project be finished within the time available and when the system is needed?
5. Legal and contractual feasibility: does it conform to laws, regulations, licences, data protection and contracts?
6. Political feasibility: support of influential stakeholders and management.

The results are written as a feasibility report which recommends whether to proceed, modify or stop.

Rules for drawing good DFDs

• Every process has a unique name, a number, and at least one input and one output (no "miracles" or "black holes").
• Data flows have names (nouns), show direction, and each flow carries a single data packet.
• Data cannot flow directly between two external entities, two data stores, or between an entity and a data store: a process must be in between.
• Data stores must have at least one input and one output flow overall, and are named as nouns.
• External entities are only at the boundary and are not part of the system.
• Processes are named with a verb phrase; do not connect data flows with crossing lines where avoidable.
• Parent and child diagrams must be balanced: the same inputs and outputs at each level.
• Decompose level by level, keep 3 to 7 processes per diagram, and avoid control flow or decisions.

Managing internal examinations: assumptions

Students register for exams; the exam section prepares the routine and admit cards; teachers submit marks; results are published; the Principal (Administration) approves.

Context diagram

 Student  --exam form/fee-->  +----------------------+ --question request/marks sheet--> Teacher
          <--admit card,result-- | Internal Exam        | <--questions, marks-----------
 Principal --approval-------->  | Management System (0) |
          <--exam reports------  +----------------------+

Entities: Student, Teacher, Principal.

Level 1 DFD

1. Register Students: Student submits exam form and fee; writes D1 Student Exam Record; issues receipt.
2. Prepare Routine and Admit Cards: reads D1; Principal approves the routine; writes D2 Routine; sends admit card to Student.
3. Collect Questions and Conduct Exam: Teacher submits questions; exam is held; attendance stored in D3 Attendance.
4. Record Marks: Teacher submits marks; stored in D4 Marks.
5. Process and Publish Results: reads D1, D4; calculates totals, grade and pass/fail; writes D5 Result; sends result to Student.
6. Generate Reports: reads D3, D4, D5; sends exam reports to Principal.

CASE support across the SDLC

CASE (computer-aided software engineering) tools automate and support the activities of systems development, improving productivity, consistency and quality.

• Planning (project identification and planning): project management tools for scheduling (Gantt, PERT), estimation, costing and resource tracking; a repository holds the project's data.
• Analysis: diagramming tools for DFDs, ER diagrams and use cases; a central repository and data dictionary; automatic consistency checking, requirements tracking and prototyping/screen tools.
• Design: tools for structure charts, class diagrams, database schema design, screen and report prototyping and form generators; checks completeness and consistency of the specification.
• Implementation: code generators that produce code or database scripts from the design, testing tools, documentation generators and help-text generators; reverse engineering and re-engineering tools.
• Maintenance: reverse and re-engineering tools to analyse existing code, impact analysis, version and configuration control, and updating the documentation automatically.

Benefits: speed, accuracy, consistent standards and documentation, easier change. Limitations: cost, learning time, and the need for method discipline.

Project management

Project management is the process of planning, organising, directing and controlling resources (people, time, money, technology) to complete a project successfully within scope, schedule, budget and quality. A project manager is responsible for initiating, planning, executing, monitoring and closing the project.

Common skills of a project manager

• Leadership: motivating and guiding the team, setting direction and making decisions.
• Communication: clear listening, writing and speaking with the team, users and executives; reporting progress.
• Planning and organising: breaking the work into tasks, estimating, scheduling and allocating resources.
• Technical knowledge: understanding the technology and development process to judge feasibility and quality.
• Interpersonal and team-building skills: managing relationships, resolving conflict, negotiation and influence.
• Risk and problem-solving: identifying risks early and acting to reduce them.
• Time and cost management: tracking schedule and budget, and controlling change.
• Management and business skills: understanding the organisation's goals, managing stakeholders and vendors.
• Adaptability, ethics and integrity.

Corporate strategic planning is the long-term process by which top management defines the organisation's mission, objectives and strategies, and decides how resources will be used to reach them. It answers three questions: where are we now, where do we want to be, and how do we get there. Its steps are:

• Define the mission, objectives and values.
• Analyse the internal and external environment (strengths, weaknesses, opportunities, threats).
• Select competitive strategies (low-cost, differentiation, focus).
• Allocate resources and set long-term targets.

Information systems planning (ISP) is an orderly study of the organisation's information needs that produces a plan for the information systems, data and technology that will support the corporate strategy. Its main activities are:

• Describe the current IS portfolio: the organisation's units, functions, processes, data and existing systems.
• Define the target portfolio: the future systems needed to support the strategy.
• Identify and rank the new projects, then set a schedule and budget.

Corporate strategic planning sets the business direction. ISP is derived from it so that IS projects serve the business goals and are not chosen at random.

Prototyping to determine requirements. Users often cannot state what they need until they see something working. In prototyping, the analyst builds a small working model of the system from the initial requirements. The users try it and give feedback. The analyst refines the model and repeats the cycle until the requirements are agreed:

1. Identify the basic requirements (the main inputs and outputs).
2. Build a first prototype quickly.
3. Let users use it and review it.
4. Revise the prototype using their feedback, and repeat steps 3 and 4 until the users accept it.
5. Use the final prototype to write the requirements (or evolve it into the system).

It is useful when the requirements are unclear, the users are unsure, or the interface matters a great deal.

Evolutionary prototype versus throwaway prototype

Pseudocode is a structured, English-like description of the logic of a process or program. It uses the control structures of a programming language (sequence, selection, iteration) but has no strict syntax, so it can be read by both programmers and non-programmers. It is used in the design phase to describe the logic of the processes in a DFD before coding.

Features

• Uses keywords such as IF-THEN-ELSE, WHILE, FOR and DO.
• Indentation shows nesting.
• It is independent of any programming language.
• It is easy to convert into code.

Example: calculating a student's result

READ marks
IF marks >= 40 THEN
    PRINT "Pass"
ELSE
    PRINT "Fail"
END IF

Example: sum of the first n numbers

READ n
SET sum = 0
FOR i = 1 TO n
    sum = sum + i
END FOR
PRINT sum

Advantages: it is easy to write and change, it is language independent, and it helps in reviewing logic before coding. Limitation: there is no standard form, and it cannot be executed or tested directly.

Forms and reports should be easy to read, to fill in and to use. The general formatting guidelines are:

Meaningful titles: each form or report has a clear, specific title, with the system name, date and page number where needed.

Meaningful information: show only the information the user needs, and do not include unnecessary or calculable items.

Balanced layout: arrange the items in a logical sequence (left to right, top to bottom), group related items, and use white space so the page is not crowded.

Easy navigation: show clearly how to move between pages or fields, with page numbers and labelled controls.

Consistency: use the same fonts, colours, terms, field positions and abbreviations across forms and reports.

Clear captions and instructions: label every field clearly and give short help or examples. Use the same terms the user uses.

Appropriate type, colour and emphasis: use a readable font size, and use bold or highlighting only for important items. Use a few colours and keep a good contrast.

Alignment and data format: align text left and numbers right (by decimal point). Use a standard date format and leave the right size for each field.

Provision for page and report headings: repeat column headings on each page and show subtotals and totals clearly.

The methods of interacting with a system (user interface styles) are:

1. Command language interaction: the user types commands with a defined syntax (for example DOS or Unix shell). It is fast and flexible for experts, but needs memorising and is error-prone for beginners.

2. Menu interaction: the user chooses from a list of options (pull-down, pop-up, cascading menus). It is easy to learn and reduces errors, but can be slow for experts when there are many levels.

3. Form interaction: the user fills in the fields of an on-screen form (like a paper form). It is good for data entry, and field validation and defaults reduce errors.

4. Object-based (graphical) interaction: the user manipulates icons and objects with a pointing device (for example in Windows). It is intuitive and easy to learn, but needs more memory and processing power and a graphical display.

5. Natural language interaction: the user types or speaks ordinary sentences, and the system interprets them (for example voice assistants). It is very easy for users, but it can be ambiguous and is difficult to build.

The method chosen depends on the type of user, the task, the hardware and the training available.

Maintainability is the ease with which a system can be understood, corrected, adapted and enhanced after delivery. The factors that influence it are:

1. Number of latent defects: the more errors left in the system at delivery, the more corrective maintenance it needs. Good testing reduces this.
2. Number of customers: more users mean more requests for changes and support, so more effort is needed.
3. Quality of system documentation: poor or outdated documents make it hard to understand the system. Good documentation reduces the effort.
4. Maintenance personnel: the skill, experience and familiarity of the maintainers, and staff turnover, affect how quickly changes can be made.
5. Tools: CASE tools, debuggers and version-control tools make maintenance easier.
6. Structure of the programs and the database: modular, well-structured, loosely coupled and cohesive code, and a well-designed database, are easier to change.
7. Programming language and standards: high-level languages and the use of coding standards improve readability.
8. System age: older systems built on old technology are harder to maintain.
9. Change management and testing practices: a controlled process for requests and regression testing keeps changes safe.

The System Development Life Cycle (SDLC) is the series of phases through which an information system is planned, built, used and finally retired. The phases are:

Planning -> Analysis -> Design -> Implementation -> Maintenance
     ^                                                  |
     |__________________________________________________|

1. Planning: identify the need, study the feasibility (economic, technical, operational), define the scope, and prepare the project plan, schedule and budget. The output is the baseline project plan.
2. Analysis: study the current system and collect the requirements by interviews, questionnaires and observation. Model the processes, data and logic (DFD, ER diagram, decision tables). The output is the requirements specification.
3. Design: convert the requirements into a technical blueprint: the logical and physical design of the database, forms, reports, interfaces, architecture and program specifications. The output is the design specification.
4. Implementation: code the system, test it, install it, convert the data, train the users, and write the documentation.
5. Maintenance: after the system goes live, fix errors (corrective), adapt it to new environments (adaptive), improve it (perfective) and prevent problems (preventive). When maintenance is no longer worthwhile the cycle starts again.

Analysis phase versus design phase

Purpose of the implementation phase: to turn the system design into a working system and put it into use. The code is written, tested and installed, the users are trained, and the system is handed over so that it can be used and maintained by the organisation.

The six major activities

1. Coding: programmers convert the design specifications into programs in the chosen language, following the coding standards.
2. Testing: the programs and the system are tested to find errors. Types include unit, integration, system and acceptance testing, using test plans, test cases and test data.
3. Installation: the old system is replaced by the new one using a changeover strategy such as direct, parallel, pilot or phased. Data is converted and the hardware and software are installed.
4. Documentation: two kinds are prepared: system documentation (design and program details for maintainers) and user documentation (manuals, help and quick-start guides).
5. Training: users, operators and support staff are taught to operate the system through classroom, on-the-job or online training and tutorials.
6. Support: help desks, hotlines and on-site help give users assistance after installation, and requests are recorded for maintenance.

The project is then reviewed, and the system moves into the maintenance phase.

A data flow diagram (DFD) shows how data moves through a system: from external entities, into processes, to data stores and back out. It is known as process modelling because its main purpose is to show the processes (the activities that transform data) and the flows between them.

Reasons:

• Processes are the central element. Each process takes input data flows, transforms them and produces output data flows.
• It shows what the system does (its functions) and not how the data is stored or how the program is coded.
• It decomposes the system into levels: the context diagram (level 0) shows the whole system as one process, and level 1, level 2 and so on break it into subprocesses. This is a functional decomposition, which is the way processes are modelled.
• Each process is later described with a process specification (structured English, decision table or decision tree), which completes the process model.

The components are the process (circle or rounded rectangle), data flow (arrow), data store (open rectangle) and external entity (square).

Benefits of object-oriented development over structured development

• Reusability: classes and components can be reused across projects, which saves time and cost.
• Encapsulation and data hiding: data and operations are kept together, which makes the system more secure and less error-prone.
• Inheritance and polymorphism: new classes extend existing ones, so code is not repeated.
• Closer to the real world: objects model real entities, so the model is easier for users and developers to understand.
• Easier maintenance and change: changes are localised within objects, so they have less effect on the rest of the system.
• A single consistent model (UML) is used from analysis through design to code, with no break between phases.
• Better support for iterative development and large, complex systems.

Class diagram. A class diagram is a UML structural diagram that shows the classes of a system, their attributes and operations, and the relationships between them (association, aggregation, composition, generalisation and dependency). Each class is drawn as a rectangle with three compartments: the class name, the attributes and the operations. For example:

+------------------+
|     Student      |
+------------------+
| - id: int        |
| - name: String   |
+------------------+
| + register()     |
| + getResult()    |
+------------------+

Process of designing interfaces and dialogues

The interface is how users give input to and receive output from the system, and the dialogue is the sequence of interaction between them. The process is:

1. Gather requirements: find out who the users are, their tasks, their skill level and the environment, and what data is input and output.
2. Design the dialogue and interface structure: list the screens or forms and their sequence, and decide how users move between them. A dialogue diagram shows the flow.
3. Choose the interaction style: command language, menu, form, object-based (graphical) or natural language.
4. Design the layout and format: field positions, captions, colour, fonts and controls, following consistency and usability guidelines.
5. Include feedback, help and error handling: system status messages, validation, and clear error and confirmation messages.
6. Prototype it and test it with users: build a prototype, have the users evaluate it, and revise the design until it is accepted.

Deliverables. The process produces:

• Sample (prototype) layouts of the forms, screens and reports, such as mock-ups or storyboards.
• Dialogue diagrams or design specifications that show the sequence of screens.
• Specifications for each interface: fields, formats, validation and help text.

Factors that influence the decision to create an index on a field

An index speeds up the retrieval of records, but it takes storage and slows down inserts, updates and deletes. An index is therefore created when:

1. The field is used often for retrieval: it appears frequently in search conditions (WHERE), so lookups are faster.
2. The field is used for sorting or grouping (ORDER BY, GROUP BY).
3. The field is a primary key or foreign key used for joins between tables, so the joins are faster.
4. The field has many distinct values (high selectivity). An index on a field with few values (for example gender) helps little.
5. The table is large and mostly read: the updates are infrequent, so the cost of maintaining the index is small.
6. The field is used for uniqueness: a unique index enforces a unique value.

An index should be avoided on small tables, on fields that are updated often, and on fields with long values.

Goals of designing physical tables

• To store the data efficiently, so that storage space is used well.
• To make data processing fast: quick retrieval and update.
• To maintain data integrity and security, through the proper choice of data types, constraints and controls.
• To make the data easy to back up, recover and maintain.

I suggest using a combination of methods, with interviews as the main method, together with questionnaires and observation. The choice depends on the project.

Why interviews are the best main method

• They give rich, detailed and direct information from users and managers.
• The analyst can ask follow-up questions, explain unclear points and notice opinions and feelings.
• They build a good relationship and user involvement in the project.

Why combine with other methods

• Questionnaires reach many people cheaply and quickly, so they suit large or scattered user groups such as the staff of many branches.
• Observation shows what people actually do, which can differ from what they say. It reveals problems that users do not mention.
• Document analysis of forms, reports and manuals shows the data and rules of the current system.
• JAD or prototyping is useful for requirements that are unclear, because they let users and developers agree on them quickly.

Using several methods lets the analyst cross-check the facts, cover the weaknesses of each method, and get complete and accurate requirements.

A decision tree is a graphical model of decision logic. It shows conditions (decision points) as nodes, the choices for each condition as branches, and the actions or outcomes at the ends of the branches. It reads left to right, and each path from the root to a leaf is one rule.

Steps to model logic with a decision tree

1. Identify the conditions and the possible actions.
2. Choose the first condition and draw it as the root node.
3. Draw one branch for each possible value of the condition.
4. Repeat for the next condition on each branch until the actions can be decided.
5. Write the action at the end of each path and check that all combinations are covered.

Example: discount policy. If a customer buys more than Rs 10,000 of goods, a member gets a 10% discount and a non-member gets 5%. If the purchase is Rs 10,000 or less, a member gets 2% and a non-member gets none.

Purchase > Rs 10,000?
  |-- Yes --> Member?
  |             |-- Yes --> 10% discount
  |             |-- No  -->  5% discount
  |-- No  --> Member?
                |-- Yes -->  2% discount
                |-- No  -->  No discount

Advantages: it is easy to read, it shows the order in which conditions are tested, and it is good for sequences of decisions. A limitation is that it gets large and untidy when there are many conditions, and a decision table is better in that case.

Potential system development projects are identified by management, steering committees, users (user departments), and the development group (IS staff). The main methods and their characteristics are:

1. Top management: projects come from strategic plans and aim at the organisation's goals. They are large and have a company-wide impact, but may be less closely tied to the daily operations.
2. Steering committee: a cross-functional group of managers who review the requests and select the projects. The selection is balanced and fair across departments, and it is slower and more political.
3. User departments: the users request projects for their own operational problems. They are specific and relevant, but may be narrow in view and may not fit the organisation's overall plan.
4. Development group (IS department): the technical staff propose projects for technology improvements. They are technically feasible, but may not match the business priorities.
5. Senior management with the IS planning process (top-down): a formal study of the whole organisation's needs gives a long-term, integrated list of projects.

Top-down identification tends to be more strategic and comprehensive, while bottom-up requests from users and the development group are more focused on operations.

Comparison of form and report

General formatting guidelines for forms and reports

• Use clear, meaningful titles and headings, and show the date and page numbers.
• Show only the information the user needs and arrange it logically, with related items grouped.
• Keep the layout balanced, with enough white space, and use a consistent design throughout.
• Label every field clearly and give simple instructions.
• Use readable fonts, with colour and emphasis (bold, highlight) used sparingly and consistently.
• Align text to the left and numbers to the right or on the decimal point, and use standard formats for dates and numbers.
• On reports, repeat column headings on each page and show subtotals and totals clearly.
• Make navigation simple, and test the design with users.

Activities in planning, analysis and design

Planning (the project is defined and planned):

• Identify the problem or opportunity and set the scope and objectives.
• Study the feasibility (economic, technical, operational, schedule).
• Estimate the resources, cost and time, and prepare the baseline project plan.

Analysis (the requirements are determined):

• Collect the requirements using interviews, questionnaires, observation, document analysis and JAD.
• Study the current system and model the processes and data (DFD, ER diagram).
• Specify the logic (decision tables, decision trees) and the structure of the proposed system.
• Prepare the requirements specification and the alternatives.

Design (the solution is specified):

• Logical design: the output of the analysis is turned into a technology-independent design.
• Physical design: the database, files, forms, reports, interfaces, dialogues, architecture, and program and module specifications.
• Prepare the design specification for implementation.

Participants in a JAD (Joint Application Design) session

• Session leader (facilitator)
• Users (customers)
• Managers
• Sponsors
• Systems analysts
• Scribe (recorder)
• IS staff such as programmers and database designers

How a JAD session is carried out. The session is held in a specially prepared room, away from the normal work, for one to several days. The facilitator opens the session with the agenda, the goals and the ground rules. The participants discuss the system requirements or design in turn, using whiteboards, flip charts, projected CASE models and prototypes. The scribe records the decisions and open issues, and the group resolves disagreements by discussion. At the end, the results are summarised into a document that the participants review and approve. This saves time compared with many separate interviews, because all the decisions are made together.

External entities: Student, Admin. Data stores: D1 Colleges, D2 Student Requests, D3 Intake/Seats, D4 Ratings.

Context diagram (Level 0)

 Student --(faculty, standard, location)--------> [ 0  Online College
 Student <--(recommended colleges, notifications)--   Recommendation
                                                       System ] <--(add/delete/update colleges)-- Admin
 Admin   <--(status confirmation, ratings report)--

Level 1 DFD

Student --faculty, standard, location--> (1.0 Accept Requirement)
(1.0) --request details--> D2 Student Requests
(1.0) --search criteria--> (2.0 Recommend Colleges)
D1 Colleges --college list--> (2.0)
D4 Ratings --ratings--> (2.0)
(2.0) --recommended colleges--> Student

D3 Intake/Seats --available seats, fee--> (3.0 Track Intake and Notify)
D1 Colleges --fee structure--> (3.0)
D2 Student Requests --student interests--> (3.0)
(3.0) --seat and fee notification--> Student

Admin --new/updated/deleted college data--> (4.0 Manage Colleges)
(4.0) <--> D1 Colleges
D4 Ratings --student ratings--> (4.0)
(4.0) --update status--> Admin
(4.0) --intake data--> D3 Intake/Seats

Processes:

1. Accept Requirement: takes the faculty name, standard and location, and stores the request.
2. Recommend Colleges: matches the criteria against the colleges and ratings and returns the recommendations.
3. Track Intake and Notify: monitors the intake of each college and informs students of the remaining seats and fee structures.
4. Manage Colleges: the admin adds, deletes and updates colleges, guided by the student ratings.

Three steps in designing dialogues

A dialogue is the sequence of interaction between the user and the system. Its design has three steps:

1. Design the dialogue sequence: decide which forms or screens are used, in what order, and what the user can do on each. A dialogue diagram (boxes for forms, arrows for the transitions) is drawn for this. The user's tasks and their usual order guide the sequence.
2. Build a prototype: a working or paper model of the screens and the navigation is made so that the dialogue can be tried out.
3. Assess the usability: users test the prototype and evaluate it for ease of learning, ease of use, speed, error rate and satisfaction. The design is revised using their feedback.

Dialogue design issues in a graphical environment

• Consistency: the same look, menus, icons, shortcuts and terms in every window.
• Feedback: the user gets immediate response (progress bar, cursor change, confirmation messages).
• Use of controls: the correct choice of widgets: buttons, check boxes, radio buttons, list and combo boxes, text boxes.
• Navigation and shortcuts: easy movement between windows and keyboard shortcuts for experts.
• Error prevention and recovery: validation, clear error messages and undo or cancel.
• Help and instructions: tooltips, online help and prompts.
• Layout, colour and font: use them sparingly and readably, and think about accessibility.
• User control: the user can cancel and move freely, and the system does not trap the user in a mode.

Maintenance is the modification of a system after it has been delivered, to correct faults, improve it and keep it useful. The four types are:

1. Corrective maintenance: repairs errors (bugs) found after delivery, such as a wrong calculation or a system crash. It is usually the most urgent.
2. Adaptive maintenance: changes the system to fit a changed environment, such as a new operating system, hardware, law or tax rule.
3. Perfective maintenance: adds new features or improves performance and usability at the users' request, for example a faster search or a new report. It is the most common type.
4. Preventive maintenance: changes the system to prevent future problems and make it easier to maintain, for example restructuring code, updating documentation or improving reliability.

Together, adaptive and perfective maintenance form the largest share of maintenance effort, and corrective maintenance is the smaller part.

Normalization is the process of organising the data in a relational database into well-structured tables, by decomposing relations, in order to remove redundancy and avoid insertion, update and deletion anomalies.

First normal form (1NF). A relation is in 1NF if every attribute holds only atomic (single) values, and there are no repeating groups or multivalued attributes. Each row must be uniquely identified by a primary key.

Example: Student(RollNo, Name, Phone) where Phone holds "9841..., 9851..." is not in 1NF. We make each phone number a separate row: Student(RollNo, Name) and StudentPhone(RollNo, Phone).

Second normal form (2NF). A relation is in 2NF if it is in 1NF and every non-key attribute is fully functionally dependent on the whole primary key. There must be no partial dependency, in which an attribute depends on only a part of a composite key.

Example: Enrolment(StudentID, CourseID, StudentName, Grade) has the key (StudentID, CourseID). StudentName depends on StudentID alone, which is a partial dependency. We split it into:

• Student(StudentID, StudentName)
• Enrolment(StudentID, CourseID, Grade)

A relation with a single-attribute primary key that is in 1NF is automatically in 2NF.

Three information gathering techniques are:

1. Interviews. The analyst asks users and managers questions face to face. They can be structured (fixed questions) or unstructured (open discussion). The advantages are rich detail, immediate follow-up questions and good relationships with users. The disadvantages are that they take time, are costly, and depend on the interviewer's skill.

2. Questionnaires. A set of written questions, open or closed, is sent to many people. It is cheap, fast and reaches many people, and it allows people to answer anonymously. The disadvantages are that the response rate may be low, the answers cannot be explained further, and the questions may be misunderstood.

3. Observation. The analyst watches users do their work in the real setting, either directly or by sampling. It shows what really happens, including steps the users forget to mention, and it gives first-hand evidence. The disadvantages are that people may behave differently when watched, and it is time-consuming.

Other techniques include document analysis (studying forms, reports and manuals), JAD and prototyping. Analysts normally use several techniques together, to check the facts.

Why corporate strategic planning is required. It sets the long-term direction of the organisation, aligns all departments (including information systems) with its mission and objectives, helps use resources well, prepares the organisation for competition and change, and provides a basis for measuring performance.

Generic competitive strategies (Porter) used to achieve objectives:

1. Low-cost leadership: becoming the lowest-cost producer in the industry through efficiency, economies of scale and tight cost control, so that the organisation can sell at lower prices or earn higher margins.
2. Product differentiation: making the product or service different and unique (quality, brand, features, service) so that customers will pay more for it.
3. Focus (niche) strategy: concentrating on a narrow market segment, by cost focus or differentiation focus, and serving it better than the broad competitors do.

Information systems support these strategies, for example by cutting costs with automation, by adding value through personalised service, and by serving a niche with targeted data.

A feasibility study is done before development to judge whether the proposed system is worth building. Two types are:

1. Technical feasibility. It checks whether the system can be built with the available technology, hardware, software and technical skills, and whether the technology is reliable and can be extended. It considers the size and complexity of the project and its technical risk.

Example: for an online banking system, the team checks whether secure servers, encryption, enough network bandwidth and developers skilled in web security are available. If these are not available, or are too risky, the project is technically infeasible.

2. Economic feasibility (cost-benefit analysis). It compares the cost of developing and running the system with its expected benefits. The development costs (hardware, software, people, training) and operating costs are weighed against tangible benefits (saved labour, more sales) and intangible ones. Measures such as payback period, net present value and return on investment are used.

Example: a library automation system costs Rs 500,000 to develop and saves Rs 200,000 a year in staff time and lost books. The payback period is $500{,}000 / 200{,}000 = 2.5$ years, so the college can decide whether this is acceptable.

Other types are operational, schedule and legal feasibility.

A project plan is represented and scheduled with network and chart techniques that show the tasks, their durations, their order and their dependencies.

1. Gantt chart. A horizontal bar chart in which the tasks are listed down the left side and the time runs across. Each bar shows the start and end of a task, and a shaded part shows progress. It is simple and easy to read and is good for progress tracking, but it does not show the dependencies between tasks clearly.

2. Network diagram (PERT and CPM). The tasks are drawn as nodes or arrows joined in the order of dependency.

• PERT (Program Evaluation and Review Technique) uses three time estimates for each task, the optimistic ($a$), most likely ($m$) and pessimistic ($b$), giving an expected time $t_e = \frac{a + 4m + b}{6}$
• CPM (Critical Path Method) finds the critical path, the longest path through the network, which fixes the shortest project duration. Tasks on it have zero slack, and a delay in any of them delays the whole project. Other tasks have slack, which is the time they can be delayed without delaying the project.

Scheduling steps: list the tasks, find their dependencies, estimate the durations, draw the network, calculate the earliest and latest start and finish times, find the slack and the critical path, and then assign the resources and set the dates. Tools such as Microsoft Project support these techniques.

Principles of agile development (from the Agile Manifesto):

1. The highest priority is to satisfy the customer through early and continuous delivery of working software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, in weeks rather than months.
4. Business people and developers work together daily.
5. Build projects around motivated individuals and trust them.
6. Face-to-face conversation is the best way to communicate.
7. Working software is the main measure of progress.
8. Maintain a sustainable pace of work.
9. Give continuous attention to technical excellence and good design.
10. Keep things simple and maximise the work not done.
11. Teams organise themselves.
12. The team regularly reflects and adjusts its way of working.

Advantages

• Customers see working software early and can influence it.
• Changes in requirements are handled easily.
• Risks are lowered and problems are found early because of the short iterations.
• Better teamwork, communication and customer satisfaction.
• Faster delivery of useful features.

Object-oriented analysis and design (OOAD) develops a system as a set of interacting objects. The phases, which are iterative, are:

1. Planning/requirements (system request and feasibility): the problem, scope and needs are identified and the use cases are written to describe how the users interact with the system.
2. Object-oriented analysis: the problem domain is modelled. The classes, attributes, operations and relationships are identified and shown in use case diagrams, class diagrams and sequence/activity/state diagrams. It specifies what the system does.
3. Object-oriented design: the analysis model is refined for the solution. The designers add the design classes, the interfaces, the architecture, the database mapping and the user interface, and decide how objects collaborate. It specifies how the system does it.
4. Implementation (coding): the classes are programmed in an object-oriented language such as Java or C++.
5. Testing: classes (unit), clusters of classes (integration) and the whole system are tested.
6. Deployment and maintenance: the system is installed, used, and then changed as needs change.

The phases overlap and are repeated in iterations, and the same UML models are enriched from one phase to the next.

(a) Single-location installation

In single-location (also called direct or central) installation, the new system is installed at one place or site, such as the head office, and used there. Other locations may use it remotely or later. It is simpler and cheaper to install, train, support and fix problems at one place. It suits organisations with one site, or is used as a pilot before a wider roll-out. The disadvantage is that the other sites must wait, and a failure at the one site affects everyone who depends on it.

(b) Decision tree

A decision tree is a graphical representation of decision logic. The conditions are shown as nodes, the possible values as branches, and the actions at the ends of the paths. It reads from left to right, and each path from the root to a leaf is a rule. For example, "If purchase is above Rs 10,000 and the customer is a member, give a 10% discount." It is easy to understand and shows the sequence of tests, but becomes large when there are many conditions. It is used to specify the logic of a process in analysis.

When the waterfall model is preferred

The waterfall model completes the phases in strict order (planning, analysis, design, implementation, maintenance), and each phase must finish before the next one starts. It is preferred when:

• The requirements are clear, complete and stable.
• The project is small or medium, and the technology is well understood.
• A formal, well-documented process is needed with clear milestones, as in government or contract projects.
• The team is inexperienced, and the manager wants simple control and management.

Drawbacks

• It is inflexible and changes are costly once a phase is complete.
• Users see the system only at the end, so wrong requirements are discovered late.
• Errors made in early phases are found late, which makes them expensive to fix.
• There is no working software until late, and the risk is high.
• It does not handle uncertain or changing requirements well.

Prototyping. A small working model of the system is built early from the initial requirements. The users try it and give feedback, and the prototype is refined repeatedly until it is accepted. It is either evolved into the final system or thrown away after the requirements are understood. It reduces misunderstanding, engages the users and handles unclear requirements. The risks are that users may expect the prototype to be the finished product, and that it may be built with poor quality or documentation.

Rapid Application Development (RAD). RAD is a fast approach that delivers systems in a short time (often 60 to 90 days) by using:

• iterative prototyping with the users,
• JAD workshops to get the requirements quickly,
• CASE tools and reusable components or code generators,
• small teams working to a fixed time box.

It gives faster delivery and better user involvement. It is suited to systems that can be modularised and need fast delivery, and is less suited to large, complex or high-risk systems, or when skilled developers and committed users are not available.

DFD components, symbols and rules

Rules

• A process must have at least one input and one output flow, with no "black holes" or "miracles".
• Data cannot flow directly between two external entities, between two data stores, or between an entity and a data store. A process must be in between.
• Every data flow must be named, and every process must have a unique name and number.
• The inputs and outputs must balance between a parent diagram and its child diagram.

Context diagram: Library Management System

 Member ---membership request, book request, return---> [ Library
 Member <--issue slip, fine notice, search results----    Management  ] <---new books, member data--- Librarian
                                                           System     ----reports, overdue list--->
 Supplier <--purchase order-----  [ same system ] <--- invoice, books ---- Supplier

Level-1 DFD

Member --request--> (1.0 Manage Membership) <--> D1 Members
Member --search query--> (2.0 Search Catalogue) <-- D2 Books --> results to Member
Member --issue/return request--> (3.0 Issue and Return Books) <--> D2 Books, D3 Transactions, D1 Members
(3.0) --issue slip--> Member
D3 Transactions --overdue details--> (4.0 Calculate Fines) --fine notice--> Member
Librarian --book details--> (5.0 Manage Books and Purchase) <--> D2 Books
(5.0) --purchase order--> Supplier ; Supplier --invoice, books--> (5.0)
D3, D1, D2 --data--> (6.0 Generate Reports) --reports--> Librarian

Database design is the process of deciding how data will be organised and stored in a database. It involves conceptual design (ER model), logical design (relations, normalization) and physical design (files, indexes, storage).

RDBMS concept. A relational database management system stores data in relations (tables) of rows (tuples) and columns (attributes). Each row is identified by a primary key, and tables are linked by foreign keys. Integrity is kept by constraints (entity, referential), and the data is processed with SQL. Normalization removes redundancy. Examples: MySQL, Oracle, PostgreSQL.

ER diagram: college course registration

 STUDENT ----< ENROLLMENT >---- COURSE
 (StudentID, Name, Address, Phone)   (Grade, Semester)   (CourseID, Title, CreditHours)

A student enrols in many courses and a course has many students, so it is a many-to-many relationship (M:N). It is resolved by the associative entity ENROLLMENT, so STUDENT 1:M ENROLLMENT and COURSE 1:M ENROLLMENT.

Relational tables

• STUDENT(<u>StudentID</u>, Name, Address, Phone)
• COURSE(<u>CourseID</u>, Title, CreditHours)
• ENROLLMENT(<u>StudentID</u>, <u>CourseID</u>, Semester, Grade)

In ENROLLMENT, the primary key is (StudentID, CourseID, Semester), where StudentID is a foreign key referencing STUDENT and CourseID is a foreign key referencing COURSE.

CREATE TABLE Student(StudentID INT PRIMARY KEY, Name VARCHAR(50), Address VARCHAR(80), Phone VARCHAR(15));
CREATE TABLE Course(CourseID VARCHAR(10) PRIMARY KEY, Title VARCHAR(60), CreditHours INT);
CREATE TABLE Enrollment(
  StudentID INT, CourseID VARCHAR(10), Semester VARCHAR(10), Grade CHAR(2),
  PRIMARY KEY(StudentID, CourseID, Semester),
  FOREIGN KEY(StudentID) REFERENCES Student(StudentID),
  FOREIGN KEY(CourseID) REFERENCES Course(CourseID));

Requirement determination is the process of collecting and analysing what the users need from the new system. It is done by studying the current system and asking the users, and it produces the requirements specification.

Traditional methods: interviews, questionnaires, direct observation and document analysis.

Contemporary methods

1. Joint Application Design (JAD): a structured workshop in which users, managers, analysts and sponsors meet together, led by a facilitator, to define requirements in a few intensive sessions. It saves time and gets agreement quickly.
2. Prototyping: a working model of the system is built early. The users try it and give feedback, and it is refined to define the requirements. It helps when requirements are unclear.
3. CASE tools: software tools that capture requirements, build and check models such as DFDs and ER diagrams, and keep them in a repository.
4. Group Support Systems (GSS): electronic meeting software that lets participants share ideas anonymously and at the same time.
5. Business Process Reengineering (BPR): requirements are found by fundamentally rethinking and redesigning the business processes to achieve large improvements.
6. Agile/user stories and use cases are also used in modern projects.

Definition. A decision table is a tabular representation of decision logic. It lists all the conditions and the actions to be taken for every combination of condition values, so it is a compact and complete way to describe complex rules.

Structure. A decision table has four parts:

• Condition stub: the list of conditions.
• Condition entries: Y/N (or values) for each rule.
• Action stub: the list of possible actions.
• Action entries: the action (X) to take for each rule. Each column is a rule. With $n$ binary conditions there are $2^n$ rules.

Use for complex business rules. It is used in analysis to specify process logic where many conditions combine. It lets the analyst check that all combinations are covered (completeness), that no two rules conflict (consistency) and that there is no redundancy. It is clearer than long text and easy for users and programmers to verify. The rules can be simplified by merging the rules with the same action. The table is then turned into code or test cases.

System implementation is the phase in which the designed system is built (coded), tested, installed and put into use, with the users trained and the documentation and support provided.

Changeover (conversion) strategies are the ways of replacing the old system with the new one:

1. Direct (abrupt/cold-turkey) changeover: the old system is stopped and the new one starts at once. It is cheap and fast, but risky because any failure stops the work, and there is no fallback.
2. Parallel changeover: the old and the new systems run together for a period and their outputs are compared. It is the safest, because the old system is a backup. It is expensive, because the work is done twice.
3. Pilot (location) changeover: the new system is first installed at one site or department. After it succeeds, it is rolled out to the others. It limits the risk and the problems are found on a small scale, but takes longer.
4. Phased (staged) changeover: the new system is introduced module by module or function by function, with the parts of the old system retired gradually. The risk is spread and the users adapt step by step, but the interfaces between old and new parts are needed and the full change takes longer.

Project plans. A project plan is a document that describes the work of a project: its scope, tasks, schedule, resources, cost, risks and the deliverables. It guides the team, and is used to measure progress.

Representing and scheduling with PERT. PERT (Program Evaluation and Review Technique) is a network technique for scheduling projects with uncertain task durations.

Steps

1. List all the tasks and their predecessors.
2. Draw the network diagram: tasks as arrows (or nodes) and events as circles, joined according to the dependencies.
3. Estimate three times for each task: optimistic $a$, most likely $m$, pessimistic $b$.
4. Calculate the expected time of each task: $t_e = \frac{a + 4m + b}{6}$
5. Calculate the earliest and latest start and finish times, going forward and then backward through the network.
6. Calculate the slack = latest start − earliest start.
7. Find the critical path: the longest path, whose tasks have zero slack. Its length is the minimum project duration.

Example: if $a=2$, $m=4$, $b=12$ days, then $t_e=(2+16+12)/6=5$ days.

PERT shows the task dependencies, the critical tasks that need close control, and the flexibility (slack) available in the others.

Definition. A Baseline Project Plan (BPP) is the document, produced at the end of the project planning (initiation and planning) phase, that contains management's estimate of the project's scope, benefits, costs, risks and resource requirements. It is the approved starting point against which the progress of the project is measured and which guides the later phases.

Major components

• Introduction: a brief description of the project, its background, and the main points (scope and goals).
• System description: an outline of the possible alternative solutions.
• Feasibility assessment: the economic, technical, operational, schedule, legal and political feasibility, with the costs and benefits.
• Management issues: the team composition, communication plan, project standards and procedures, the schedule and the risks.
• Work plan and resource estimates: the tasks, time and resources.

Importance

• It gives management and the client a basis on which to approve or reject the project (go/no-go decision).
• It records the agreed scope, so it controls scope creep.
• It lets progress, cost and schedule be compared with the plan and corrected.
• It sets out the responsibilities and expectations, and improves communication.
• It is updated as the project continues, and is the reference for the analysis phase.

Potential systems development projects are identified by looking at the business needs and opportunities. The factors are:

1. Business goals and strategy: a project is more likely to be chosen if it supports the organisation's mission and strategic plan.
2. Problems and opportunities: weaknesses in the current system such as errors, delays, high cost or complaints, and chances to gain competitive advantage.
3. Management and user requests: the demands of managers and user departments for new or improved systems.
4. Technological change: new technology, or the obsolescence of the existing hardware and software, creates the need for projects.
5. Legal and regulatory requirements: new laws, standards and tax rules that force changes.
6. Competition and customer demand: actions of competitors and customer expectations.
7. Cost and benefit and resource availability: the expected value, the budget, the skills and the time available. These influence which projects are practical and are selected.
8. Risk and feasibility: the technical, operational and schedule risk of the project.

Interaction methods and devices are the ways in which a user communicates with a system (input) and the system responds (output). In interface design they decide how natural, fast and error-free the dialogue is. Devices include keyboard, mouse, touch screen, stylus, microphone, camera, monitor and speakers; methods are the interaction styles built on them.

Five common interaction methods

1. Command-line interface (CLI): the user types commands in a prescribed syntax. It is powerful and fast for experts and scriptable, but the commands must be learnt and remembered.
2. Menu selection: the user chooses from a list of options (pull-down, pop-up, cascading menus). It needs little recall and few errors, but it is slow for experts if the menu is deep.
3. Form fill-in: the user fills fields in a screen form (data entry, registration). It is simple and structured, and suitable for data entry and validation.
4. Direct manipulation (GUI, WIMP): users manipulate visible objects with a mouse or touch (drag and drop, icons, windows). It gives immediate feedback and is easy to learn, but it needs graphics resources.
5. Natural language / voice interaction: the user speaks or writes ordinary language (voice assistants, chatbots). It is very easy for novices but ambiguous and error-prone in recognition.

Other methods include question-and-answer dialogue, touch/gesture and virtual reality interaction. The choice depends on the user's experience, the task and the available devices.

Definition: Joint Application Development (JAD) is a requirements-gathering technique, developed by IBM, in which users, managers, analysts and developers meet together in structured workshop sessions led by a facilitator to define and agree the requirements of a system.

When it is useful

• When requirements are unclear or users and developers disagree.
• For complex systems that involve many departments.
• When quick agreement is needed, since it shortens the many rounds of interviews.

Concept

• Key people (sponsor, facilitator, users, analysts, scribe) attend a planned meeting of one to several days.
• The facilitator keeps the discussion on track and the scribe records decisions.
• Prototypes and diagrams are used to build a shared understanding in the session itself.
• The output is an agreed requirements document that all parties sign off.

JAD improves user participation, reduces misunderstandings and saves time, but it needs careful scheduling and a skilled facilitator.

(a) Agile method

Agile is an iterative and incremental approach to software development that values working software, customer collaboration and response to change over rigid plans (Agile Manifesto). Work is divided into short iterations (sprints) of 1-4 weeks, and each delivers a usable increment.

• Features: continuous customer feedback, small cross-functional teams, daily stand-up meetings, adaptive planning, frequent releases.
• Examples: Scrum, Extreme Programming (XP), Kanban.
• Advantages: quick delivery, flexibility to changing requirements, better quality through continuous testing.
• Limitations: less documentation and difficult cost estimation for large fixed-price projects.

(b) UML

The Unified Modeling Language (UML) is a standard graphical language for specifying, visualising and documenting the artefacts of object-oriented software systems.

• Structural diagrams: class, object, component, deployment, package diagrams.
• Behavioural diagrams: use case, sequence, collaboration, activity, state-chart diagrams.
• It is independent of any programming language or method and is widely used in analysis and design to communicate between analysts, designers and users.