System Analysis and Design

Joint Requirements Planning (JRP) is a structured group technique in which system owners, users, analysts and managers meet in facilitated workshops to define and agree on the system requirements and scope. It is a subset of Joint Application Development (JAD).

Participants

• Sponsor (executive who supports the project), facilitator (leads the session, neutral), users and managers (domain knowledge), analysts and IT staff (technical expertise), and a scribe (records decisions).

Process

1. Plan: decide objectives, participants, location, date and agenda; give pre-read material.
2. Conduct the session(s): typically in a special room with whiteboards and projector, discuss requirements and priorities, build models and resolve conflicts.
3. Document: the scribe records requirements and decisions, which are circulated for approval.

Advantages

• Faster than many separate interviews; reduces the time of requirements discovery.
• Users take part, so ownership and satisfaction increase.
• Conflicts are resolved on the spot; requirements are more complete and accurate.

Disadvantages

• Hard to schedule all key people together; costly in staff time.
• Needs a skilled facilitator; a few dominant members may take over.
• Can fail if decision makers do not attend or if participants are unprepared.

Information building blocks are the main components that describe an information system from the viewpoint of different stakeholders: Knowledge (data), Process (activities) and Communication (interfaces and geography) , each seen by the system owner, user, designer and builder.

Use

• They divide a complex system into understandable parts so that data, processes and communication can be modelled and developed separately but consistently.
• They give a common framework for the different stakeholder perspectives (as in the information systems architecture matrix).
• They guide what models and documents are needed in each phase and ensure that no aspect is missed.
• They support reuse, integration and communication between the project team and users.

Communication building blocks The communication blocks describe how and where the system interacts with people and with other systems: the interfaces and the network. Four perspectives:

1. System owner's view (Communication): the geographic scope: the business locations and the people and organisations (e.g. branches, head office, customers) between whom the information flows, drawn as a business location/network diagram (context).
2. System user's view: the user interface requirements: what inputs and outputs, forms, reports and dialogues the users need at each location (e.g. screens for the cashier).
3. System designer's view: the logical and physical network and interface design: the communication network, client-server architecture, protocols, bandwidth, and the design of screen, report and dialogue layouts.
4. System builder's view: the technology implementation: network hardware (routers, switches, cables), communication software and the actual interface programs.

 Branch A  \                                     / Database server
 Branch B  --- LAN/WAN/Internet --- Application server
 Customer (web/ATM) /                            \ Backup site

Communication blocks tie the system together geographically: they define who can access what, from where and how data travels, which affects performance, security and cost.

Use-case modelling is a technique of object-oriented analysis (UML) for capturing the functional requirements of a system by describing the interactions between users (actors) and the system as a set of use cases. It shows what the system does for each actor, not how. It consists of a use case diagram plus textual use case descriptions (narratives).

Components

1. Actor: a person, organisation, device or external system that interacts with the system, drawn as a stick figure. Primary actors start a use case; secondary actors support it. Example: Customer, Bank Teller, Payment gateway.
2. Use case: a complete function the system performs that gives value to an actor, drawn as an oval with a verb phrase name. Example: Withdraw cash, Issue book.
3. System boundary: rectangle enclosing the use cases that make up the system; actors lie outside.
4. Relationships
   • Association: a line between actor and use case, showing communication.
   • Include (<<include>>): the base use case always uses another one (Withdraw cash includes Verify PIN).
   • Extend (<<extend>>): optional or conditional behaviour added to a base use case (Withdraw cash extended by Print receipt).
   • Generalization: a specialised actor or use case inherits from a general one (Savings customer is a Customer).
5. Use case description: name, actors, preconditions, main flow, alternative flows, postconditions.

Example (ATM)

 Customer ----- (Withdraw cash) ----include----> (Verify PIN)
     |              ^ extend
     |              '---- (Print receipt)
     '--------- (Check balance)

Use cases are used to communicate with users, to define scope, and as the basis for design and test cases.

Candidate system matrix. The candidate system matrix is a table used in the analysis and decision phases to compare alternative solutions (candidate systems) against the same set of criteria. Its purpose is to help the analyst and management choose the most suitable solution.

Structure

• Rows: characteristics of the candidates such as scope (portion of the problem solved), functionality, technology used, development approach (in-house, buy, outsource), schedule and cost.
• Columns: the candidates, for example Candidate 1 (minimum), Candidate 2 (moderate), Candidate 3 (full).
• A last block shows the feasibility result (operational, technical, economic, schedule) for each candidate.

Example

Use. After the matrix is filled, the candidates are scored or ranked on feasibility and priority, and the analyst recommends the best candidate in the system proposal. A second matrix, the feasibility analysis matrix, assigns weights to the criteria for a numerical comparison.

(a) System analysis and design

A system is a set of interrelated components working together to achieve a goal. System analysis is the process of studying an existing (or proposed) system to understand how it works, identify its problems and determine what the new system must do. System design is the process of defining how the system will meet those requirements: its architecture, database, inputs, outputs, interfaces and processes.

Together, system analysis and design (SAD) is a structured, step-by-step method to build information systems that meet user needs: analysis answers what the system must do, design answers how it will do it.

(b) Roles and responsibilities of a system analyst

The system analyst is the link between users (business) and the technical team (developers).

1. Investigator / fact finder: studies the current system using interviews, questionnaires, observation and document review.
2. Requirements analyst: identifies, documents and validates functional and non-functional requirements (SRS).
3. Problem solver / consultant: analyses problems, proposes alternatives and recommends solutions, including feasibility (technical, economic, operational, schedule).
4. Designer / architect: prepares models such as DFDs, ERDs, use cases, and designs the database, interface, inputs and outputs.
5. Communicator / coordinator: translates business language into technical language and back, and coordinates between users, managers, programmers and testers.
6. Project manager / planner: plans tasks, schedules, cost and resources, and monitors progress.
7. Tester and quality assurer: prepares test plans and cases, supports system and user acceptance testing.
8. Implementer and trainer: supervises installation and conversion, prepares documentation and trains users.
9. Maintenance supporter: handles change requests and post-implementation review.

Skills needed: technical (programming, databases, networks), analytical, communication, management and ethical skills.

The Software Development Life Cycle (SDLC) is a structured process that describes the phases through which a software system is planned, built, delivered and maintained. The main phases are:

1. Planning (preliminary investigation) The problem or opportunity is identified and a feasibility study (technical, economic, operational, schedule) is carried out. Scope, cost, schedule and resources are estimated and a project plan is prepared.

2. Requirements analysis The analyst gathers requirements through interviews, questionnaires, observation and document study; models them (use cases, DFDs); and documents them in the Software Requirements Specification (SRS), which the users approve.

3. Design The requirements are converted into a blueprint: system architecture, database design (ERD, tables), interface design, input/output formats, and program/module design. Output: design documents (high-level and low-level design).

4. Implementation (coding) Developers write the code in the chosen language following coding standards, usually module by module, with unit testing by the programmers.

5. Testing The software is checked for defects and for conformity to the SRS: unit, integration, system and user acceptance testing. Defects are fixed and re-tested.

6. Deployment (installation) The system is installed in the live environment, data is converted, users are trained, and the system goes live (direct, parallel, pilot or phased changeover).

7. Maintenance After release, errors are corrected (corrective), the system is adapted to new environments (adaptive), improved (perfective) and prevented from future problems (preventive).

Planning -> Analysis -> Design -> Implementation -> Testing -> Deployment -> Maintenance

Models that organise these phases include waterfall, iterative, spiral, V-model and agile.

(a) Project management

A project is a temporary effort with a defined start and end, undertaken to create a unique product or service. Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements within the constraints of scope, time, cost and quality. It involves initiating, planning, executing, monitoring and controlling, and closing the project.

(b) Traditional versus agile methodologies

Traditional (waterfall/predictive) methodology follows sequential phases (requirements, design, implementation, testing, deployment, maintenance). Each phase is completed and approved before the next begins, and the scope is fixed early.

Agile methodology develops the product in short iterations (sprints of 1-4 weeks), delivering a working increment each time and welcoming changing requirements. Examples: Scrum, XP, Kanban.

Agile 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.

Scrum example: product backlog, sprint planning, daily stand-up, sprint review and retrospective, with roles Product Owner, Scrum Master and Development Team.

Time, schedule and cost, together with scope and quality, form the main constraints of a project (the "iron triangle"). Changing one affects the others, so planning must balance them.

        Scope / Quality
           /\
          /  \
         /    \
      Time ---- Cost

Time (duration) Time is the total period available to complete the project. During planning, the work is broken down (WBS), the duration of each activity is estimated (for example by three-point estimation $\frac{O + 4M + P}{6}$), and the overall deadline is set. A short deadline forces more resources or reduced scope; a long one increases cost.

Schedule The schedule sequences activities, their dependencies, start and finish dates and resource assignments, using Gantt charts, PERT and the critical path method (CPM). The critical path is the longest path; any delay in it delays the whole project. Slack (float) shows how much non-critical tasks can slip. A realistic schedule guides resource allocation, milestones and progress tracking.

Cost Cost covers people, hardware, software, training, tools and overheads. Cost planning includes estimation (analogous, parametric, COCOMO, bottom-up), budgeting over time and cost control (earned value management).

How they influence each other

• Compressing the schedule (crashing) by adding people raises cost and may lower quality (Brooks' law: adding people to a late project makes it later).
• Reducing cost (fewer staff or cheaper tools) usually lengthens the schedule or cuts scope.
• Fixed deadline with fixed budget forces reduction in scope or quality.
• Delays increase cost through extended salaries and overhead.

Good planning therefore sets priorities, includes buffers (contingency), identifies the critical path and revisits estimates regularly so that the project meets time, schedule and cost targets together.

(a) Risk management

A risk is an uncertain event that, if it occurs, has a positive or negative effect on project objectives. Risk management is the systematic process of identifying, analysing, responding to and monitoring risks to reduce their probability and impact.

Steps:

1. Risk identification: list possible risks (brainstorming, checklists, past projects, SWOT), e.g. changing requirements, staff turnover, technology failure, cost overrun.
2. Risk analysis: qualitative (probability-impact matrix) and quantitative (exposure $= \text{probability} \times \text{impact}$).
3. Risk response planning: avoid, mitigate, transfer (insurance, outsourcing) or accept.
4. Risk monitoring and control: track triggers, update the risk register and apply contingency plans.

(b) Project management tools

1. Work Breakdown Structure (WBS): divides the project into smaller manageable work packages.
2. Gantt chart: bar chart showing tasks against time, start/finish dates and progress.
3. PERT chart: network diagram with three-point time estimates and dependencies.
4. Critical Path Method (CPM): finds the longest path and slack of activities.
5. Kanban board / Scrum board: visual workflow of tasks (To Do, In Progress, Done), e.g. Trello.
6. Risk register and probability-impact matrix: records and ranks risks.
7. Earned Value Management: measures cost and schedule performance.
8. Software tools: Microsoft Project, Jira, Trello, Asana, Basecamp, Slack/Teams for communication, and Git for version control.

Requirements gathering

Requirements gathering (elicitation) is the process of collecting, from users, customers and other stakeholders, what the system must do (functional requirements) and the qualities it must have (non-functional requirements such as performance, security, usability). It is the first step of analysis and its result is documented in the Software Requirements Specification (SRS). Poor requirements are a major cause of project failure, so several techniques are combined.

Key techniques

1. Interviews: the analyst asks questions of stakeholders face to face (structured, semi-structured or unstructured). They give detailed, in-depth information but are time consuming and depend on the interviewee's honesty.
2. Questionnaires / surveys: written questions sent to many users. They are cheap and reach large groups, but responses can be shallow and follow-up is difficult.
3. Observation (job shadowing): the analyst watches users perform their work in the real setting, revealing tasks users forget to mention or cannot describe.
4. Document analysis: studying existing forms, reports, manuals, policies and the current system's records to understand data and procedures.
5. Brainstorming and focus groups: a group generates ideas freely and discusses them; good for new ideas and consensus.
6. Joint Application Development (JAD) workshops: structured sessions where users, analysts and developers define requirements together, saving time and reducing misunderstanding.
7. Prototyping: a quick working model (wireframe, mock-up) is shown to users to obtain feedback and refine unclear requirements.
8. Use cases and user stories: describe the interaction between actors and the system (or "As a student I want ... so that ..."), clarifying functional needs.
9. Surveys of similar systems (benchmarking): comparing with competing products to find missing features.

Choosing: use interviews and workshops for depth, questionnaires for breadth, observation and document analysis for the real process, and prototyping for unclear or interface-heavy requirements. After gathering, the requirements are reviewed, prioritised, validated with stakeholders and baselined.

Key Performance Indicators (KPIs)

KPIs are measurable values that show how effectively a project is achieving its key objectives. They convert goals into numbers with targets, so that progress can be judged objectively. A good KPI is SMART (specific, measurable, achievable, relevant, time-bound).

Examples of project KPIs

• Schedule: Schedule Performance Index $SPI = \dfrac{EV}{PV}$ (below 1 means behind schedule); milestones met on time.
• Cost: Cost Performance Index $CPI = \dfrac{EV}{AC}$ (below 1 means over budget); budget variance $= EV - AC$.
• Scope/quality: number of defects found and fixed, defect density per KLOC, requirements completed, change requests.
• Productivity: velocity (story points per sprint), tasks completed.
• Customer/stakeholder: satisfaction score, acceptance rate.
• Risk and resource: number of open risks, resource utilisation.

Here $EV$ is earned value, $PV$ planned value and $AC$ actual cost.

Use in monitoring and control

1. Define KPIs and target values during planning and record a baseline.
2. Measure actual values regularly through status reports, time sheets, test reports and dashboards.
3. Compare actual against baseline to find variances.
4. Analyse the causes of deviations and forecast the outcome (for example, Estimate at Completion $EAC = BAC / CPI$).
5. Take corrective action: re-plan, reallocate resources, reduce scope, add testing, or escalate to sponsors; changes pass through change control.
6. Report to stakeholders in dashboards and review meetings, and use lessons for future projects.

For example, if $EV =$ Rs 40,000, $PV =$ Rs 50,000 and $AC =$ Rs 45,000, then $SPI = 0.8$ and $CPI \approx 0.89$: the project is behind schedule and over budget, and the manager must act.

(a) Use case analysis

Use case analysis is a requirements-modelling technique that describes the system from the user's viewpoint. It identifies the actors (people or external systems that interact with the system) and the use cases (goals or functions that the system provides to them), and documents the interaction. The results are shown as a use case diagram (UML) with:

• Actor: stick figure outside the system boundary.
• Use case: oval inside the system boundary.
• Association: line between actor and use case.
• Include (<<include>>): mandatory shared behaviour; extend (<<extend>>): optional behaviour.

Each use case is further described by a flow of events, pre- and post-conditions and alternative flows.

(b) Use case diagram for a university Education Management Information System (EMIS)

Actors: Student, Teacher, Administrator, Accountant, Examination Controller, Librarian (and Parent as an optional actor).

 +-------------------- University EMIS --------------------+
 |                                                         |
 |  (Login) <<include>> in all use cases below              |
 |                                                         |
 Student ---- (Register / Enroll courses)                   |
 Student ---- (View timetable, notice)                      |
 Student ---- (View results / mark sheet)                   |
 Student ---- (Pay fees online) --------------- Accountant  |
 Student ---- (Borrow / search books) --------- Librarian   |
 Teacher ---- (Take attendance)                             |
 Teacher ---- (Enter internal marks)                        |
 Teacher ---- (Upload study material)                       |
 Exam Controller ---- (Schedule exam)                       |
 Exam Controller ---- (Publish results)                     |
 Admin ---- (Manage students, teachers, courses)            |
 Admin ---- (Manage users and roles)                        |
 Admin ---- (Generate reports)                              |
 Accountant ---- (Manage fee records, receipts)             |
 |  (Publish results) <<include>> (Calculate GPA)           |
 |  (Pay fees online) <<extend>> (Apply scholarship)        |
 +---------------------------------------------------------+

Main use cases by actor

Sample description: "Pay fees online"

• Actor: Student; precondition: the student is logged in and has dues.
• Main flow: the student selects the semester, the system shows dues, the student chooses the payment gateway, pays, the system records payment and issues a receipt.
• Alternative flow: payment fails, the system shows an error and allows retry.
• Postcondition: the fee record is updated.

(a) Definitions

• Entity: a real-world object or concept about which data is stored, e.g. Student, Book. Shown as a rectangle.
• Attribute: a property that describes an entity, e.g. name, ISBN. Shown as an oval. Types: simple, composite, derived, multivalued; the key attribute uniquely identifies an entity.
• Relationship: an association between entities, e.g. a user borrows a book. Shown as a diamond, with cardinality (1:1, 1:N, M:N).

(b) ER diagram for the online library management system

Entities and attributes (primary key underlined by PK):

• Institution (PK InstID, name, type [school/college], address)
• User (PK UserID, name, email, password, phone, registration_date, FK InstID)
• Resource (PK ResID, title, publisher, year, subject, type [book/journal], file_url)
• Book (ResID, ISBN, edition, copies)
• Journal (ResID, ISSN, volume, issue)
• Author (PK AuthorID, name)
• Category (PK CatID, name)
• Access/Loan (PK LoanID, UserID, ResID, issue_date, due_date, return_date)
• Admin/Librarian (PK StaffID, name, role)

 [Institution] --1----< belongs to >----N-- [User]
 [User] --N----< borrows / reads >----M-- [Resource]
        (attributes: issue_date, due_date, return_date)
 [Resource] --M----< written by >----N-- [Author]
 [Resource] --N----< classified in >----1-- [Category]
 [Resource] is specialised (ISA) into [Book] and [Journal]
 [Librarian] --1----< manages >----N-- [Resource]

Relationships and cardinalities

Relational mapping: User(UserID, name, email, InstID), Resource(ResID, title, type, CatID), Loan(LoanID, UserID, ResID, issue_date, due_date, return_date), ResourceAuthor(ResID, AuthorID). This supports registration of users from different schools and colleges and online delivery of books and journals.

Effective user interface (UI) design makes software easy, efficient and pleasant to use. The main principles are:

1. Simplicity: keep the interface clean and show only what is necessary. Example: the Google search page has just a search box and button.
2. Consistency: use the same layout, terms, icons and colours throughout, so users can transfer what they learn. Example: the Save icon and Ctrl+S behave the same way in all Microsoft Office applications.
3. Visibility of system status (feedback): tell users what is happening. Example: a progress bar while downloading, or a "Payment successful" message in eSewa.
4. Clarity and clear hierarchy: use size, colour, spacing and alignment so that important items stand out. Example: a prominent "Pay now" button on a checkout page.
5. User control and freedom: let users undo, cancel and go back. Example: Undo in Gmail after sending a message.
6. Error prevention and recovery: design to avoid mistakes and give helpful messages. Example: a confirmation before deleting a file, or "Password must contain 8 characters" shown while typing.
7. Recognition rather than recall: show options instead of making users remember. Example: a browser's drop-down of recently visited sites.
8. Familiarity (use of real-world metaphors): use conventions people already know. Example: a trash-can icon for delete, a shopping cart in an online store.
9. Flexibility and efficiency: shortcuts for experts and simple paths for beginners. Example: keyboard shortcuts and menus in a word processor.
10. Accessibility: support users with disabilities and different devices: adequate contrast, text size, screen-reader support, responsive layout. Example: mobile banking apps that allow large text.
11. Aesthetics: an attractive, uncluttered design builds trust.

Following these principles reduces training time and errors and improves user satisfaction.

Definition

UI (User Interface) design is the design of the visual and interactive elements through which a user works with a system: screens, buttons, menus, icons, colours, typography and layout.

UX (User Experience) design covers the user's whole experience with the product: research, ease of use, usefulness, efficiency, emotions and satisfaction before, during and after use. UI is the look and controls; UX is how well the whole journey works. A good UI is a part of a good UX.

Principles for effective UI design

1. Clarity and simplicity: an uncluttered screen with a clear purpose; one primary action per screen.
2. Consistency: the same patterns, terminology, colours and icons everywhere (internal) and following platform conventions (external).
3. Visual hierarchy: size, contrast, colour and spacing guide the eye to the most important elements first.
4. Feedback: immediate response to every action (button states, loading indicators, confirmation messages).
5. User control and error handling: undo, cancel and back options; prevention of errors; clear, polite error messages that explain how to fix the problem.
6. Recognition over recall: visible options, labels and recent items, so users need not memorise.
7. Flexibility and efficiency of use: shortcuts, defaults and search for experienced users.
8. Accessibility and inclusivity: colour contrast, keyboard navigation, alt text, scalable fonts, support for different languages (e.g. Nepali) and devices (responsive design).
9. Affordance and familiar metaphors: controls that look clickable; standard icons.
10. User-centred approach: know the users through personas, wireframes, prototypes and usability testing, and iterate.

Example (a student portal): a clear dashboard shows results, fees and notices (hierarchy); the same menu appears on every page (consistency); fee payment shows "Processing..." then a receipt (feedback); the page works on a mobile phone (accessibility).

Data Flow Diagram (DFD)

A DFD is a graphical model that shows how data moves through a system: where it comes from, which processes transform it, where it is stored and where it goes. It shows what the system does, not how or in what sequence. Symbols (Yourdon/DeMarco):

• Process: circle or rounded box (transforms data).
• Data flow: arrow with a label.
• Data store: open rectangle or two parallel lines (e.g. D1 Student file).
• External entity: rectangle (source or destination outside the system).

Rules: every process has at least one input and one output; data cannot flow directly between two entities or two stores; names must be consistent across levels.

Assumed system: Online Library Management System (external entities: Member, Librarian)

Context diagram (Level 0 context)

The entire system is shown as a single process with its external entities and main flows.

 Member --- membership request, book request, payment --->
                                                         ( 0 )  Library Management System
 Member <-- book details, issue slip, due notice -------
 Librarian --- book data, issue/return approval --------->
 Librarian <-- reports, overdue list -------------------

Purpose: defines the system boundary and its interfaces; no data stores are shown.

Level 0 DFD (top-level breakdown)

The context process is broken into the major processes:

 Member --registration data--> (1.0 Manage Members) <--> [D1 Member]
 Member --search query------> (2.0 Search Catalogue) <-- [D2 Books]
 Member --issue/return request--> (3.0 Issue and Return) <--> [D3 Transactions]
 (3.0) ----fine amount----> (4.0 Calculate Fines) <--> [D4 Fines]
 Librarian --book details--> (5.0 Manage Books) --> [D2 Books]
 (3.0)/(4.0)/(5.0) -----> (6.0 Generate Reports) --reports--> Librarian

Level 0 shows the main functions, the data stores and how data flows among them. Flows entering/leaving must match the context diagram.

Level 1 DFD (decomposition of process 3.0 Issue and Return)

 Member --request--> (3.1 Verify Member) <-- [D1 Member]
 (3.1) --valid member--> (3.2 Check Book Availability) <-- [D2 Books]
 (3.2) --available--> (3.3 Record Issue) --> [D3 Transactions]
                       (3.3) --issue slip--> Member
 Member --return book--> (3.4 Record Return) <--> [D3 Transactions]
 (3.4) --late return--> (3.5 Compute Fine) --> [D4 Fines]
                       (3.5) --fine notice--> Member

Level 1 gives the detail of one Level 0 process, with numbered sub-processes (3.1, 3.2, ...); data is balanced with the parent process (same inputs and outputs). Further levels (2, 3...) can be drawn until processes are simple enough to code.

(a) Client-server architecture

Client-server architecture is a distributed computing model in which tasks are divided between servers, which provide resources or services (data, files, applications), and clients, which request those services over a network. The client starts the request; the server waits, processes it and returns a response.

 Client 1 --\
 Client 2 ---+--request/response--> Server (web, database, file) 
 Client 3 --/

• Common forms: 2-tier (client and database server), 3-tier (presentation, application/business logic, data), and n-tier.
• Protocols: HTTP, TCP/IP, SQL.
• Examples: web browser and web server, email client and mail server, ATM and bank server.
• Advantages: centralised data and security, easy maintenance and updating, scalable, clients and servers can be upgraded independently.
• Disadvantages: server is a bottleneck or single point of failure, network dependence, server cost.

(b) Three major considerations in designing cloud architecture

1. Scalability and elasticity: the architecture must handle changing load by adding or removing resources automatically. Use horizontal scaling (more instances), load balancers, auto-scaling groups and stateless services, and design the database for growth (replication, sharding). This keeps performance steady in peak periods (for example, exam result day) and saves cost at quiet times.

2. Security and compliance: data and applications are hosted on shared infrastructure, so design must include identity and access management, encryption of data at rest and in transit, network isolation (VPC, firewalls), logging and monitoring, regular patching, and compliance with laws on data protection and location. The shared responsibility model separates the provider's duties from the customer's.

3. Availability, reliability and disaster recovery: the system must stay up despite failures. Use multiple availability zones/regions, redundancy and failover, regular backups and defined recovery objectives (RTO and RPO). Avoid single points of failure.

Other considerations: cost optimisation (pay-as-you-go, right sizing), performance (caching, CDN), vendor lock-in and portability, and manageability (automation and monitoring).

(a) Managing the programming process

Managing the programming (implementation/coding) process means planning, organising and controlling the activity of converting the design into working code so that it is delivered on time, within budget and with good quality. It includes:

• Planning and task allocation: divide the design into modules and assign them to programmers with schedules.
• Coding standards: naming, formatting, commenting and documentation rules so that code is readable and maintainable.
• Version control and configuration management: tools such as Git track changes, allow branching and merging, and avoid conflicts.
• Code reviews and pair programming: peers inspect code for defects and share knowledge.
• Build and integration: frequent builds, continuous integration (CI) to find integration errors early.
• Unit testing by developers and use of debugging tools.
• Progress tracking and communication: daily meetings, issue trackers, reports.
• Quality, risk and productivity management: metrics (defects per KLOC), reuse of libraries, training.

(b) Testing strategies

A testing strategy is the overall approach used to verify that the software meets the requirements and is free of defects. Testing proceeds from small to large units:

1. Unit testing: each module, function or class is tested separately by developers (white-box), often with automated frameworks (JUnit).
2. Integration testing: tests the interfaces between modules. Approaches: top-down (stubs), bottom-up (drivers), sandwich, and big-bang.
3. System testing: the complete integrated system is tested against the SRS, including functional, performance, load/stress, security, usability and recovery testing.
4. Acceptance testing: performed by users/customers to decide whether to accept the system; alpha testing (at developer's site) and beta testing (at users' site).

Testing techniques:

• Black-box testing: tests inputs and outputs without looking at code (equivalence partitioning, boundary-value analysis).
• White-box testing: based on the internal structure (statement, branch and path coverage).
• Regression testing: re-testing after changes to ensure existing features still work.
• Static testing: reviews and walkthroughs without running code; dynamic testing runs the code.

Good strategy: begin testing early, prepare test plans and cases from the requirements, automate repeating tests, record defects and re-test fixes.

Change management is the process of controlling modifications to a project or system so that changes are evaluated, approved, implemented and tracked in an orderly way, without disrupting the project's scope, schedule, cost or quality. Changes arise from new user requirements, errors, new technology, legal changes or business policy.

Steps of the change management process

1. Change request: a formal request (change request form) is raised, describing the change and reason.
2. Impact analysis: the effect on scope, time, cost, quality, risk and other components is assessed.
3. Review and approval: a Change Control Board (CCB) accepts, rejects or defers the request.
4. Implementation: approved changes are planned, carried out, tested and the project baseline is updated.
5. Verification and communication: the result is checked, stakeholders are informed, and documents and training are updated.
6. Tracking and closure: all changes are recorded in a change log for audit.

Importance

• Prevents scope creep and uncontrolled changes.
• Keeps stakeholders informed and in agreement.
• Reduces risk and cost of changes.
• Maintains version consistency (configuration management).

Human side (organisational change management): where a new system changes how people work, users must be prepared through communication, training and support to reduce resistance to change.

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of a project into smaller, manageable components called work packages. It shows what must be delivered, not when or who does it.

Key points

• The project is the top level (level 0). It is split into major deliverables or phases, and each is split again until the lowest level, the work package, can be estimated, assigned and tracked.
• Every level must cover 100% of the work of its parent (the "100% rule"), with no overlap between sibling items.
• Each work package has an owner, a cost and time estimate, and clear completion criteria.

Example (library management system)

1.0 Library Management System
 |- 1.1 Analysis
 |    |- 1.1.1 Requirement gathering
 |    '- 1.1.2 Feasibility study
 |- 1.2 Design
 |    |- 1.2.1 Database design
 |    '- 1.2.2 Interface design
 |- 1.3 Implementation
 |- 1.4 Testing
 '- 1.5 Deployment and training

Uses

• Gives a basis for estimating cost and effort and for scheduling (Gantt/PERT).
• Assigns responsibility clearly and helps monitor progress.
• Reduces the chance that a task is forgotten, and helps control scope creep.

A WBS can be organised by phase (as above) or by deliverable/component, and is usually shown as a tree chart or an indented outline.

Client-server architecture is a distributed computing model in which work is divided between servers, which provide resources or services, and clients, which request them over a network. Clients initiate requests; servers wait, process and reply.

 Client 1 \                    / Database / file / application services
 Client 2 --- Network --- Server
 Client 3 /

Tiers

• Two-tier: the client holds the user interface and business logic and talks directly to the database server. Simple and fast for small systems, but hard to maintain and scale because logic is on every client.
• Three-tier: presentation tier (client/browser), application tier (business logic on an application server) and data tier (database server). Better scalability, security and maintainability.
• n-tier: the application tier is further split (web server, business services, integration), as in modern web applications.

Advantages

• Centralised data and security, easy backup and administration.
• Resources are shared, and servers or clients can be upgraded independently.
• Scales better than file-sharing systems.

Disadvantages

• The server is a single point of failure and a possible bottleneck under heavy load.
• Network dependence, and servers are costly to set up and maintain.

Examples: web browser and web server, email client and mail server, bank ATM and core banking server.

An information system (IS) is an arrangement of people, data, processes, hardware, software and communication technology that work together to collect, process, store and distribute information to support operations, management and decision making in an organisation.

Types of information systems

1. Transaction Processing System (TPS): records and processes day-to-day routine transactions such as sales, payroll and ticket booking.
2. Management Information System (MIS): summarises TPS data into periodic, structured reports (monthly sales, inventory status) for middle managers.
3. Decision Support System (DSS): interactive system with data, models and analysis tools that helps managers make semi-structured or unstructured decisions.
4. Executive Information System (EIS): gives top executives summarised, high-level and often graphical information for strategic decisions.
5. Expert System / Knowledge-based System: captures expert knowledge as rules to give advice on specialised problems.
6. Office Automation / Knowledge Work System: supports documents, email, scheduling and design work.

TPS vs DSS

Information systems architecture (ISA) is a unifying framework or blueprint that defines the data, processes, interfaces (users and systems) and networks (geography) of an information system, and shows how they fit the business needs. It is often drawn as a matrix (for example Zachman's framework) with the perspectives of system owner, system user, designer and builder against the building blocks.

Role in system development

1. Common blueprint: gives owners, users, analysts, designers and programmers a shared picture of the system, so everyone understands how the parts fit.
2. Links business and technology: it ties business goals and requirements to technical choices, so the system supports the organisation.
3. Organises the building blocks: it separates Knowledge (data), Process (activities), Communication (interfaces and networks) so each can be modelled and developed on its own.
4. Supports different perspectives: the owner's scope, the user's requirements, the designer's design and the builder's implementation all fit one framework, which keeps them consistent.
5. Guides planning and scope: helps decide which subsystems to build first, how they integrate, and avoids duplicate or isolated systems.
6. Improves integration and reuse: common data, standards and interfaces let new systems connect to existing ones and reuse components.
7. Eases change and maintenance: well-defined structure makes it easier to find and change affected parts, reducing cost and risk.
8. Supports quality and communication: architecture documents are used for reviews, estimation, training and control of the project.

Without an architecture, systems tend to become fragmented, inconsistent and expensive to maintain; with one, development is more orderly, predictable and aligned with business goals.

The Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, is a framework that measures and improves the maturity of an organisation's software (and system development) process. It describes five levels of increasing process capability so that an organisation can assess itself and plan improvement.

Levels

1. Initial: processes are ad hoc and chaotic. Success depends on individual heroics; schedules and costs are unpredictable.
2. Repeatable (Managed): basic project management is in place (planning, tracking, requirements management, configuration management). Past success can be repeated on similar projects.
3. Defined: the organisation has a standard, documented process that all projects tailor. Training and peer reviews are routine.
4. Managed (Quantitatively managed): processes and products are measured with metrics, and quality and performance are controlled using statistics.
5. Optimising: continuous process improvement driven by quantitative feedback, defect prevention and adoption of new technology.

Comparison with respect to competitiveness and risk

As the level rises, predictability, productivity and quality increase while risk, rework and cost decrease.

System analysis is the process of studying an existing business or system and its problems, opportunities and requirements in order to determine what a new or improved system should do. It answers what is needed (not how to build it) and results in requirement specifications and models.

FAST (Framework for the Application of Systems Thinking) is a methodology of phases, with the system analysis phase using the following approaches.

FAST system analysis approaches

1. Model-Driven Analysis: emphasises drawing system models to document requirements.
   • Structured analysis uses data flow diagrams (process models), entity relationship diagrams (data models) and data dictionaries.
   • Information engineering focuses on data models first, then process models.
   • Object-oriented analysis uses UML models (use case, class, sequence diagrams) to describe objects and their interactions.
2. Accelerated Systems Analysis: shortens the time to build models by using prototyping and joint application development. Requirements are captured through discovery prototypes and rapidly built sessions with users, giving quick feedback.
3. Agile Method: an iterative approach using short development cycles, close user collaboration, minimal documentation and quick delivery of working software (Scrum, XP).
4. Requirements Modelling Approaches: such as business process redesign, which uses analysis to remove or improve inefficient processes before automation.
5. Discovery Prototyping: builds a small working model to discover and validate requirements with users.

Typical activities in analysis: scope definition, problem analysis, requirements analysis, logical design (model building), decision analysis (choose among candidate solutions). Different projects mix these approaches, depending on size, risk and user availability.

Consequences of failure to identify system requirements correctly

• Wrong or unwanted system: the delivered system does not meet user needs, so it is rejected or rarely used.
• Cost overruns: fixing requirement errors late is many times costlier than fixing them early; rework and change requests raise the budget.
• Schedule delays: repeated redesign and retesting push the delivery date back.
• Missing or incomplete functionality and poor quality, with more defects and maintenance.
• Scope creep and disputes between users, analysts and management, with low user satisfaction.
• Project cancellation or wasted investment in extreme cases, and damage to the team's or the company's reputation.

Interview as a fact-finding technique

Advantages

• Gives detailed, first-hand information and allows follow-up questions to clarify answers.
• Flexible: questions can be adapted to the person and the answers.
• Reveals attitudes, feelings, opinions and office politics that documents do not show.
• Builds a personal relationship and user support for the project.
• Allows observation of body language and gives a chance to verify facts directly.

Disadvantages

• Time-consuming and costly to plan, conduct and document.
• Results depend heavily on the interviewer's skill; bias can distort findings.
• Interviewees may be unavailable, uncooperative or give inaccurate or biased information.
• Hard to analyse and summarise open-ended answers.
• Not practical for a very large number of users (a questionnaire is better).

Normalization is the process of organising data in a relational database to remove redundancy and avoid insertion, update and deletion anomalies by splitting tables according to functional dependencies. The stages are called normal forms.

Unnormalized example (Order)

First Normal Form (1NF): every attribute holds only atomic values and there are no repeating groups. Each item gets its own row.

OrderItem(OrderID, Date, CustID, CustName, ItemID, ItemName, Qty), key (OrderID, ItemID).

Second Normal Form (2NF): the table is in 1NF and no non-key attribute depends on only part of a composite key (no partial dependency). Here Date, CustID and CustName depend on OrderID only, and ItemName on ItemID only. Split:

• Order(OrderID, Date, CustID, CustName)
• Item(ItemID, ItemName)
• OrderLine(OrderID, ItemID, Qty)

Third Normal Form (3NF): the table is in 2NF and has no transitive dependency, i.e. no non-key attribute depends on another non-key attribute. In Order, CustName depends on CustID, which depends on OrderID. Split:

• Order(OrderID, Date, CustID)
• Customer(CustID, CustName)

Boyce-Codd Normal Form (BCNF): a stricter 3NF where for every functional dependency $X \rightarrow Y$, $X$ must be a superkey. Used when a table has overlapping candidate keys.

Higher forms (4NF removes multivalued dependencies, 5NF removes join dependencies) are used less often. Normalization reduces redundancy and improves consistency, though too many tables can slow queries, so sometimes controlled denormalization is used.

Making a good data model

1. Understand the requirements: interview users and study forms and reports to learn what data the business uses.
2. Identify entities: find the real-world things about which data is stored (customer, product, order).
3. Define attributes for each entity, choosing a primary key that is unique, stable and not null.
4. Identify relationships and their cardinality (1:1, 1:N, M:N) and participation; resolve many-to-many relationships with an associative entity.
5. Use meaningful, consistent names following one naming standard.
6. Normalize to at least 3NF to remove redundancy and anomalies.
7. Define integrity rules: data types, domains, required fields, foreign keys and business rules.
8. Keep it simple and complete: model exactly what the system needs, avoid unnecessary entities, and allow for future growth.
9. Validate and review with users and walk through typical transactions; revise.

ER diagram for an online shopping system

 CUSTOMER (CustID, Name, Email, Phone, Address)
     | 1
     |  places
     | N
 ORDER (OrderID, OrderDate, Status, TotalAmount)
     | 1                          | 1
     | contains                   | has
     | N                          | 1
 ORDER_ITEM (OrderID, ProductID, Qty, UnitPrice)   PAYMENT (PaymentID, Method, Amount, Date)
     | N
     | refers to
     | 1
 PRODUCT (ProductID, Name, Price, Stock) --- N : 1 --- CATEGORY (CategoryID, CategoryName)
 CUSTOMER 1 ---- N CART_ITEM N ---- 1 PRODUCT
 ORDER 1 ---- 1 SHIPMENT (ShipID, Address, Date, Status)

Relationships

• A customer places many orders; each order belongs to one customer (1:N).
• An order contains many products and a product appears in many orders (M:N), resolved by ORDER_ITEM.
• Each order has one payment and one shipment (1:1).
• A category groups many products (1:N).
• A customer adds products to a cart (M:N via CART_ITEM).

Primary keys are the underlined identifiers (CustID, OrderID, ProductID, CategoryID); foreign keys such as CustID in ORDER and CategoryID in PRODUCT implement the relationships.

Data and process model synchronization means checking that the data model (ERD, which describes stored data) and the process model (DFD, which describes the processing of data) agree with each other and describe the same system without contradiction. Both models are built from the same requirements, so what the processes use or create must exist in the data model, and every stored data item must be created or used by some process.

Why it is needed

• Catches missing entities, attributes or processes early.
• Keeps the models consistent and complete before design.
• Ensures the database can support every process and every entity has a purpose.

Synchronization rules

1. Each data store in the DFD corresponds to one or more entities in the ERD (a data store may hold several entities, or one entity may be spread across stores).
2. Each data flow into or out of a data store must be supported by attributes in the entities.
3. Every entity and attribute must be created, read, updated or deleted by at least one process. This is checked with a CRUD matrix.
4. Every process that reads or writes data must have the corresponding data in the model.
5. Data names should be the same in both models and in the data dictionary.

Example (library)

The matrix shows that the data store Loan in the DFD corresponds to the Loan entity. If an entity such as Fine had no process creating it, the models would be out of sync: either a process "Calculate fine" is missing in the DFD, or the entity is unnecessary. Resolving such gaps synchronizes the models.

Costs are the resources spent to develop, introduce and operate the system. Benefits are the gains the organisation receives from it.

Types of costs

• Development (one-time) costs: analysis, design, hardware, software, training, conversion.
• Operating (recurring) costs: maintenance, supplies, staff, licences, power.
• Tangible costs (can be measured in money) and intangible costs (loss of morale, disruption).
• Fixed and variable costs; direct and indirect costs.

Types of benefits

• Tangible: reduced labour and operating costs, increased sales, faster processing, less error.
• Intangible: better decisions, improved customer satisfaction, better image, higher employee morale.

Cost-benefit analysis techniques

1. Payback analysis: time needed for accumulated benefits to equal the cost.

$\text{Payback period} = \text{years before recovery} + \frac{\text{unrecovered cost at start of year}}{\text{benefit during that year}}$

Example: cost Rs 100,000, yearly net benefit Rs 40,000, so payback = $100000/40000 = 2.5$ years. Simple, but ignores time value of money and later benefits.

2. Return on Investment (ROI):

$\text{ROI} = \frac{\text{Total benefits} - \text{Total costs}}{\text{Total costs}} \times 100\%$

Example: benefits Rs 150,000 and costs Rs 100,000 give ROI $= 50\%$.

3. Net Present Value (NPV): discounts future benefits and costs to today's value at rate $r$.

$NPV = \sum_{t=1}^{n}\frac{B_t - C_t}{(1+r)^t} - C_0$

A project with $NPV > 0$ is acceptable. Example: $C_0 =$ Rs 100,000, yearly benefit Rs 60,000 for 2 years, $r=10\%$: $NPV = 60000/1.1 + 60000/1.21 - 100000 = 54545 + 49587 - 100000 =$ Rs 4,132, so accept.

4. Benefit-cost ratio $= \text{PV of benefits}/\text{PV of costs}$; accept if greater than 1.
5. Break-even analysis: the point at which cumulative benefits equal cumulative costs.

Several techniques are normally used together to judge economic feasibility.

Problem analysis is the study of the existing system to understand its problems, causes and effects, and to find opportunities for improvement. It is the second step of the systems analysis phase and has the following phases (steps).

1. Study the problem domain / current system: learn the business, the people and the current process through interviews, observation and documents. Build models of the existing system (context diagram, DFD).
2. Identify problems, opportunities and constraints: list the problems (and opportunities and directives) in the system, such as slow processing, errors, duplication and high cost, and note constraints (budget, time, technology).
3. Analyse problems and opportunities: find the causes and effects of each problem. Techniques include cause-and-effect (fishbone) diagrams and Pareto analysis. Rank problems by importance and urgency.
4. Analyse business processes (or decide the priorities): examine process flows to find waste, bottlenecks and unnecessary steps.
5. Establish system improvement objectives: state measurable objectives for each problem, e.g. "reduce billing time from 10 minutes to 2 minutes", and any constraints on solutions.
6. Update or refine the project plan: revise scope, cost and schedule in light of the findings.
7. Present findings and recommendations: prepare a system improvement report and a presentation to management, who decide whether to continue to the requirements analysis phase, change the scope or cancel.

Good problem analysis ensures the team solves the right problem rather than just its symptoms, which makes requirements and design more accurate.

System design is the phase of the system development life cycle in which the technical, logical and physical specification of the new system is created from the requirements found in analysis. It answers how the system will work. It includes the design of the database, user interface, inputs and outputs, processes, architecture, hardware/software and network, and security. The outcome is a design document from which programmers build the system.

Buy versus build

• Build (in-house): develop a custom system from scratch. It fits requirements exactly and the organisation owns the code, but it costs more, takes longer and is riskier.
• Buy (packaged/COTS): purchase ready-made software and configure it. It is cheaper, quicker and proven, but may not fit all local rules and depends on the vendor.

Choice for a university registration system: Buy (with customisation)

Justification:

1. Student registration, fee, result and course handling are common across universities, so mature packages (ERP/student information systems) already exist.
2. Faster implementation, important for starting before the next semester registration.
3. Lower initial cost and lower risk than developing a large system with limited in-house staff.
4. Vendor support, updates and documentation are available.
5. Proven reliability and security.

Conditions: the package must be customisable to the university's rules (credit system, fee structure, local language). If no package fits the unique needs adequately, or the cost of customising is high, a hybrid (buy core and build add-ons) or build approach can be chosen. Evaluation should consider cost, functionality fit, vendor reputation, support, scalability and integration with existing systems.

A use case diagram is a UML behavioural diagram that shows the functions (use cases) a system provides, the actors (users or external systems) who interact with it, and the relationships between them. It presents the system from the user's point of view and defines the scope of the system. Elements are actors (stick figures), use cases (ovals), the system boundary (rectangle) and relationships (association, include, extend, generalization).

Use case diagram for an e-Banking system

                +------------------- e-Banking System -------------------+
                |                                                         |
 Customer ------|--- (Login) <<include>> (Authenticate)                   |
    |           |--- (View balance / mini statement)                      |
    |-----------|--- (Transfer funds) <<include>> (Verify OTP)            |
    |           |--- (Pay bills / top up)                                 |
    |           |--- (Request cheque book)                                |
    |           |--- (Change password)                                    |
                |                                                         |
 Bank Staff ----|--- (Manage accounts)                                    |
 (Admin)        |--- (Approve requests)                                   |
                |--- (Generate reports)                                   |
                |                                                         |
 Payment/SMS ---|--- (Send notification)  <<extend>> from (Transfer funds)|
 Gateway        +---------------------------------------------------------+

Actors: Customer (primary), Bank staff/administrator, and external systems such as the payment gateway and SMS/OTP service.

Main use cases and relationships

• Login is included by almost every customer use case (<<include>>), as authentication is always needed.
• Transfer funds includes Verify OTP and may be extended by Send notification (<<extend>>).
• Staff use cases (manage accounts, approve requests, reports) are separate from customer use cases.

The diagram helps customers and developers agree on the services before design.

CASE (Computer-Aided Software Engineering) tools are software applications that support and automate activities of the system development life cycle, such as analysis, design, coding, testing and maintenance. They improve productivity, quality and consistency.

Categories

• Upper CASE: support early phases: requirements, analysis and design (diagram editors for DFD, ERD, UML).
• Lower CASE: support later phases: code generation, testing, debugging and maintenance.
• Integrated CASE (I-CASE): cover the whole life cycle.

Components / features

• Diagramming tools and a central repository (data dictionary) that stores all project information.
• Consistency and completeness checking of models.
• Screen and report generators, code generators, documentation generators.
• Prototyping tools and project management support.

Advantages

• Faster development and higher productivity.
• Better quality through automatic checking and standard notation.
• Easy modification and good, up-to-date documentation.
• Better communication among team members.

Disadvantages

• High cost of purchase and training.
• Learning time, and can be inflexible for unusual designs.
• Benefits depend on the organisation adopting the method the tool supports.

Examples: Rational Rose, Visual Paradigm, Enterprise Architect, Lucidchart, Visible Analyst.

Functional requirements describe what the system must do: its functions, services, inputs, processing and outputs. They state the behaviour that users can observe, e.g. "The system shall let a student register for courses", "calculate the total bill", "generate a monthly report". They are documented with use cases, DFDs and process descriptions.

Non-functional requirements describe how well the system performs its functions, i.e. quality attributes and constraints. Typical categories:

• Performance: response time, throughput (e.g. page loads within 3 seconds).
• Security: authentication, authorisation, encryption.
• Reliability and availability: uptime of 99.9%.
• Usability: ease of learning, language support.
• Scalability and maintainability, portability, compatibility.
• Legal and standards constraints, cost and technology constraints.

Both are needed: a system with all its functions but poor performance or security still fails the users.

An information system (IS) is an arrangement of people, data, processes, hardware, software and communication technology that collects, processes, stores and distributes information to support the operations, management and decision making of an organisation.

Major stakeholders are the people who have an interest in the system or are affected by it.

1. System owners: the people who pay for the system and own it (managers, executives). They are interested in cost, benefit and return, and approve the project and its funding.
2. System users: the people who use the system to perform their work.
   • Internal users: clerical and service staff, technical and professional staff, supervisors, middle and senior managers, executives.
   • External users: customers, suppliers and partners who use the system through the Internet or other interfaces. Users are interested in the functions, usability and speed of the system, and they define the requirements.
3. System designers: technical specialists who translate user requirements into technical designs (database, network, software architects, interface designers).
4. System builders: programmers, database and network administrators, and testers who construct, deliver and maintain the system from the designs.
5. Systems analysts: facilitate the development; they study the business problem, communicate between the stakeholders and users, and make requirements and design.
6. IT vendors and consultants: supply hardware, software and services and advice.
7. Project manager and others: plan, schedule and control the project; also auditors and regulators.

The success of an information system depends on involving all stakeholders, balancing their different interests and communicating well among them.

Cross life-cycle activities are activities that are performed throughout the whole system development life cycle (not within one phase only), and they support all phases. They are:

• Fact finding: continuing collection of information on the problem, requirements and design.
• Documentation and presentation: keeping specifications, models and reports up to date and communicating them.
• Feasibility analysis: repeated checking of operational, technical, economic and schedule feasibility.
• Process and project management: planning, scheduling, staffing, monitoring and controlling the project.

Sequential (waterfall) versus iterative approach

Contrast: the sequential approach is simple to manage and control but inflexible, while the iterative approach is more flexible and reduces risk but needs stronger management of changes and continuous user involvement.

Requirement discovery is the process and set of techniques used by systems analysts to find out, with the stakeholders, what the new system must do (functional and non-functional requirements), by identifying the needs, problems and constraints of the users. It is a main part of the requirements analysis phase and relies on fact-finding.

Fact-finding techniques

1. Sampling of existing documentation, forms and files: study of manuals, reports, forms, policies and sample records to understand the current system. It gives facts quickly but documents may be outdated.
2. Research and site visits: study of similar systems, books, journals, the Internet and visits to other organisations for ideas and benchmarks.
3. Observation of the work environment: the analyst watches users at work to see how tasks are really done. It gives reliable, first-hand data, but people may behave differently when watched and it takes time.
4. Questionnaires: written questions sent to many people. They are cheap and can reach a large group and are easy to tabulate, but response rate is low and no follow-up is possible. Questions may be open or closed.
5. Interviews: face-to-face discussion, structured or unstructured, with individuals. It gives detailed information and allows follow-up, but is time-consuming and depends on the interviewer.
6. Prototyping: building a small working model so that users can react and clarify their needs; good where requirements are vague.
7. Joint Requirements Planning (JRP/JAD): facilitated group workshops where users and analysts agree on requirements together; fast and builds consensus but hard to schedule.
8. Brainstorming / use cases / task analysis: group idea generation and scenario-based discovery.

Normally a mix of techniques is used, because each has strengths and weaknesses, and the facts are cross-checked.

Project management is the application of knowledge, skills, tools and techniques to project activities in order to meet project requirements within the constraints of scope, time, cost and quality. For information systems it includes defining scope, planning and scheduling, estimating cost, staffing, managing risk, monitoring progress and controlling changes until the system is delivered. The main activities are initiating, planning, executing, monitoring and controlling, and closing.

Causes of failed projects

1. Failure to establish upper-management commitment: lack of support, funding and priority.
2. Unclear or changing requirements: poor requirement gathering, user needs not understood and uncontrolled scope creep.
3. Poor planning and estimation: unrealistic schedule and budget, and missing tasks.
4. Lack of user involvement: users are not consulted, so the product does not meet their needs.
5. Inadequate risk management: risks not identified or planned for.
6. Poor project management: weak monitoring, control and communication; a lack of standard methodology.
7. Insufficient or unskilled staff: wrong skills, high turnover, poor team work.
8. Technology problems: immature or unsuitable technology, or poor integration with existing systems.
9. Inadequate testing and quality assurance, leading to defects.
10. Poor communication and unrealistic expectations among stakeholders, with unresolved conflict.
11. Resistance to change from users and the organisation.

Careful planning, strong sponsorship, active user participation, clear scope with change control, and risk management reduce the chance of failure.

A use case diagram is a UML diagram showing the actors that interact with a system and the use cases (functions) that the system provides to them, enclosed in a system boundary. It captures the functional requirements from the user's viewpoint and is used for communication between users and developers.

Use case diagram for a biometric attendance system

              +---------- Biometric Attendance System -----------+
              |                                                  |
 Employee ----|--- (Scan fingerprint) <<include>> (Verify identity)
  /Student    |--- (Mark attendance)  <<include>> (Verify identity)
              |--- (View own attendance)                         |
              |                                                  |
 Admin -------|--- (Enrol / register person and biometrics)      |
              |--- (Manage users and devices)                    |
              |--- (Edit / correct attendance)                   |
              |--- (Generate attendance report)                  |
              |            ^ <<extend>> (Export report)          |
              |--- (Configure shifts and holidays)               |
 Biometric ---|--- (Capture biometric data)                      |
 device       +--------------------------------------------------+
 Manager -----------(View reports, approve leave)

Actors: Employee/Student (marks and views attendance), Administrator (enrols people, manages users, corrects records, configures), Manager/Teacher (views and approves reports), and the Biometric device (secondary actor, captures fingerprint or face data).

Key use cases

• Enrol person: admin registers the person and stores biometric template.
• Mark attendance: the person scans, the system verifies identity against the stored template and records time in or out.
• Generate report: daily, monthly or by person; can be extended to export to PDF or Excel.
• Verify identity is included by marking attendance (<<include>>) and Export report extends Generate report (<<extend>>).

An Entity Relationship (ER) diagram is a conceptual data model that shows the entities (things about which data is stored), their attributes and the relationships among them, with cardinality. Entities are drawn as rectangles, attributes as ovals (the key underlined) and relationships as diamonds. It is used to design the database before implementation.

ER diagram for an online banking system

 BRANCH (BranchID, Name, Address)
    | 1
    | has
    | N
 CUSTOMER (CustID, Name, Address, Phone, Email, DOB)
    | 1                      \ 1
    | owns                    \ has
    | N                        \ 1
 ACCOUNT (AccNo, Type,         ONLINE_USER (UserID, Username, Password, LastLogin)
          Balance, OpenDate)
    | 1                | 1                   | 1
    | has              | linked to           | requests
    | N                | N                   | N
 TRANSACTION           CARD (CardNo,        LOAN (LoanID, Amount, Rate, Term)
 (TxnID, Type, Amount,  Type, Expiry)
  Date, Status)
    | N
    | to/from (beneficiary / bill payee)
    | 1
 PAYEE (PayeeID, Name, AccNo, Bank)

Entities and keys: Customer (CustID), Account (AccNo), Transaction (TxnID), Branch (BranchID), Online_User (UserID), Card (CardNo), Loan (LoanID), Payee (PayeeID).

Relationships and cardinality

• Branch 1 : N Customer (a branch serves many customers).
• Customer 1 : N Account (a customer owns many accounts; joint accounts would be M:N).
• Customer 1 : 1 Online_User (login profile of the customer).
• Account 1 : N Transaction (each transaction belongs to an account).
• Account 1 : N Card, Customer 1 : N Loan.
• Transaction N : 1 Payee for transfers and bill payments.

Foreign keys: BranchID in Customer, CustID in Account, AccNo in Transaction.

Process modelling. Process modelling is a technique for organising and documenting the structure and flow of data through a system's processes, together with the logic, policies and procedures that those processes implement. It shows what the system does with data: where data comes from, how it is transformed, where it is stored and where it goes. The most common process-modelling tool is the Data Flow Diagram (DFD). Process models are used in systems analysis to understand the current system, to specify requirements for the new system and to communicate with users and programmers.

Data Flow Diagram (DFD). A DFD is a graphical tool that depicts the flow of data between external entities, processes and data stores of a system. It shows only data movement, not control or timing, and it is read from the viewpoint of the data.

Components of a DFD

Rules.

• A process must have at least one input and one output (no "black hole" or "miracle").
• 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.
• Every data flow must be labelled, and each process numbered and named.
• Child diagrams must balance with their parent (same inputs and outputs).

Levels of DFD.

• Context diagram (level 0): the whole system as a single process with its external entities.
• Level 1 and lower: the single process is decomposed into major sub-processes, each decomposed further until primitive.

Example: Library Management System (context level).

External entity Member sends "Book request" and "Membership details" to process 0 Library System; the system returns "Issued book / receipt" and "Fine notice" to Member. External entity Librarian sends "New book details" and receives "Reports".

Level 1 decomposition.

1. 1.0 Register member: input Membership details from Member; writes to data store D1 Member file.
2. 2.0 Issue book: input Book request from Member; reads D1 Member file and D2 Book file; writes to D3 Loan file; outputs Issue slip to Member.
3. 3.0 Return book and calculate fine: reads D3 Loan file; updates D2 Book file; outputs Fine notice to Member.
4. 4.0 Generate report: reads D1, D2, D3; outputs Reports to Librarian.

This shows how data is received, processed, stored and delivered, which is exactly what a DFD is designed to document.

Why a feasibility study is needed. A feasibility study is a preliminary investigation done early in a project to decide whether the proposed system is worth building. It is needed because:

• it prevents wasting time and money on projects that are technically impossible, too costly or unwanted by users;
• it identifies risks, constraints and alternatives before heavy commitment is made;
• it gives management a sound, documented basis for a go/no-go or continue/revise decision;
• it helps set priorities among competing projects and clarifies the scope and expected benefits.

Six tests for feasibility (the PIECES-style set commonly used in systems analysis; the six are listed below).

1. Operational feasibility. Will the system work in the organisation and will people use it? It measures how well the solution solves the problems, takes advantage of opportunities and satisfies requirements identified earlier. Questions: do management and users support it, will it fit current work practices, does it improve performance, what resistance to change is expected?

2. Technical feasibility. Is the technology available, and can the team build and operate it? It assesses whether the proposed hardware, software, network and technical skills exist or can be acquired, whether the technology is mature enough, and whether it can be expanded later.

3. Economic feasibility. Are the benefits greater than the costs? It uses cost-benefit analysis, payback period, return on investment (ROI) and net present value (NPV) to judge whether the project is a sound financial investment, including development and operating costs against tangible and intangible benefits.

4. Schedule feasibility. Can the system be completed in the time available? It checks whether the deadlines set by users or management are realistic given the project's size, resources and the time needed for development, training and installation.

5. Legal (and contractual) feasibility. Does the system conform to laws, regulations, licences and contracts? Examples: data-protection and privacy laws, software licensing, copyright, and contractual obligations with vendors or clients.

6. Cultural / political feasibility. Will the system be accepted in the organisation's culture and power structure? It considers how stakeholders, departments and managers will react, internal politics, and the social impact on users (job roles, workload, habits).

Some textbooks also name organisational/management feasibility; the six above are the standard answer. The results of these tests are summarised in the feasibility report that accompanies the system proposal, and a project that fails any critical test is modified or dropped.

Cost-benefit analysis in feasibility. Economic feasibility compares the total costs of a proposed system with the benefits it is expected to bring. The costs and benefits are first identified, then converted to money and compared using a cost-benefit technique. The result is included in the feasibility report and in the system proposal.

Costs and benefits

• Costs: development costs (analysts, programmers, hardware, software, training, conversion) and operating costs (maintenance, supplies, staff, electricity, licences).
• Tangible benefits: quantifiable gains such as reduced staff cost, lower errors, faster processing, increased sales.
• Intangible benefits: hard to quantify, such as better customer service, better decisions, improved morale.

Cost-benefit techniques

1. Payback analysis. Finds how long the system takes to recover its initial investment from net benefits. $\text{Payback period}=\frac{\text{Initial investment}}{\text{Annual net benefit}}$ Example: investment Rs 600,000 and net benefit Rs 200,000 a year gives $600000/200000 = 3$ years. Shorter payback is better. It is simple but ignores the time value of money and benefits after payback.

2. Return on Investment (ROI). $\text{ROI}=\frac{\text{Total benefits}-\text{Total costs}}{\text{Total costs}}\times 100\%$ Example: benefits Rs 900,000, costs Rs 600,000 gives $\frac{300000}{600000}\times100 = 50\%$. A higher ROI means a more attractive project.

3. Net Present Value (NPV). Discounts future cash flows to present value at a discount rate $r$: $\text{NPV}=\sum_{t=1}^{n}\frac{B_t-C_t}{(1+r)^t}-C_0$ where $C_0$ is the initial cost. Example: investment Rs 100,000, net benefit Rs 60,000 per year for 2 years, $r=10\%$: $\frac{60000}{1.1}+\frac{60000}{1.21}-100000 = 54545+49587-100000 \approx \text{Rs } 4,132$. Positive NPV means the project is acceptable.

4. Break-even analysis. Determines the point at which cumulative benefits equal cumulative costs; before it the system is at a loss, after it the system is profitable.

System proposal. After analysis, the analyst presents a system proposal to management. It summarises the problem, the candidate solutions, their technical, operational and economic feasibility, the cost-benefit results, and a recommended solution with schedule and resources. The cost-benefit figures justify the recommendation, so that management can approve, modify or reject the project.

Scope definition. Scope definition is the phase in which the analyst, together with users and management, defines the boundaries of a proposed project: the problems to be solved, the opportunities and directives, the areas of the business involved, the expected deliverables and the constraints (budget, schedule, resources). It answers what is and is not included so that the project can be properly planned, estimated and approved. A clear scope prevents scope creep and sets a basis for the feasibility study.

Phases of scope definition (the survey/preliminary investigation stage of the life cycle)

1. Identify the problems and opportunities. Receive the request (a system request) and identify the problems, opportunities or directives that trigger the project. Problems are existing difficulties, opportunities are chances to improve, and directives are new requirements from management or government. The analyst determines the importance of each.

2. Negotiate baseline scope. Discuss with the sponsor and users the project's size, which functions, data and users are involved, and the objectives. Agree on an initial baseline scope that defines the system's boundary, along with constraints and assumptions.

3. Assess project worth. Estimate roughly whether the project is worthwhile: expected benefits, risks and the cost of the scope. This tells whether it should proceed to detailed study; some requests are rejected or postponed here.

4. Plan the project. Prepare a project plan: tasks, work breakdown, staffing, schedule, budget and the scope for the next phase. Roles for the project team and users are assigned, and a schedule for the remaining phases is prepared.

5. Present the project and plan. Present the findings, the scope statement and the plan to management (steering committee) for approval. Management decides to approve, modify, delay or cancel the project, and may release funds to continue to the next phase, the problem analysis.

Output. The result is a scope statement and a project charter/plan that guide the following study, analysis and design phases.

Logical design phase. Logical design is the stage of the systems development life cycle in which the analyst specifies what the new system must do, in a form independent of any particular technology or implementation. It follows requirements analysis and precedes physical design.

Activities and outputs

• Convert the requirements into logical models of the system: data flow diagrams (process models), entity-relationship diagrams and data dictionary (data models), and models of events and behaviour.
• Specify inputs, outputs, files/data stores, and business rules in terms of their content and logic, not hardware or software.
• Normalise data to produce a clean logical data model.
• Describe the processing logic using decision tables, decision trees or structured English.

Characteristics

• Technology independent: it does not name a specific DBMS, language or device.
• Focuses on business needs and users' view of the system.
• Provides a blueprint that users can review and validate before money is spent on implementation.

Importance. Errors are cheap to correct at this stage, and the logical design remains valid even if the technology changes. It is then transformed into the physical design (screens, reports, database tables, program specifications, hardware and software choices).

Information system. An information system (IS) is an arrangement of people, data, processes, hardware, software and communication technology that work together to collect, process, store and distribute information to support the operations, management and decision-making of an organisation. Examples: transaction processing systems, management information systems, decision support systems and executive information systems.

Technology drivers of today's information systems. These are the technologies that are changing how systems are built and used:

1. Networks and the Internet. High-speed wired and wireless networks, the web and intranets/extranets connect people and organisations, enabling e-commerce, e-government and remote work.

2. Mobile and wireless technologies. Smartphones, tablets and wearable devices, with mobile apps, give users access anywhere; they also enable location-based services and mobile payments.

3. Object technologies. Object-oriented languages, components and reusable libraries allow software to be built from interchangeable objects, increasing reuse and reducing development time.

4. Collaborative technologies. Email, video conferencing, shared documents and groupware let teams work together across places and time.

5. Enterprise applications. ERP, CRM and supply-chain packages integrate business functions in one platform.

6. Cloud computing and virtualisation. Storage, platforms and software are rented over the Internet, which lowers upfront cost and gives scalability.

7. Database and data technologies. Relational and NoSQL databases, data warehouses, data mining and big-data analytics turn large data into information.

8. Artificial intelligence and expert systems. Machine learning, expert systems and automation support decisions and routine work.

9. Web services and service-oriented architecture, APIs. Applications exchange data across platforms through standard interfaces.

10. Security technologies. Encryption, firewalls and authentication protect systems against growing threats.

Together these drivers push organisations to replace old systems, adopt new business models and make analysts consider the technology options during design.

Capability Maturity Model (CMM). The CMM, developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, is a framework that describes the maturity of an organisation's software (or systems) development processes on a scale of five levels. It provides a path for improvement from ad hoc, unpredictable practice to optimised, disciplined processes. (Its successor is CMMI.)

Five levels

1. Initial. Processes are ad hoc and chaotic; success depends on individual heroics.
2. Repeatable (Managed). Basic project management is established: requirements, planning, tracking, configuration management and quality assurance; earlier successes can be repeated on similar projects.
3. Defined. Processes are documented, standardised and integrated across the organisation; all projects use an approved, tailored version.
4. Managed (Quantitatively managed). Detailed process and product metrics are collected; the process is controlled using statistical methods.
5. Optimising. Continuous process improvement is driven by quantitative feedback and by piloting new ideas and technologies; defects are prevented.

How risk is reduced at higher levels

• Predictability: with defined and measured processes, cost and schedule estimates are more accurate, so overruns and late delivery fall.
• Quality: standard reviews, testing and quality assurance find defects earlier and reduce rework, failures and costly maintenance.
• Less dependence on individuals: knowledge is documented in standard processes, so staff turnover does not endanger a project.
• Better requirements and change control: configuration and change management reduce scope creep and misunderstandings.
• Early risk identification: formal risk management, metrics and tracking reveal problems before they become critical.
• Continuous improvement: at level 5, root causes of defects are analysed and removed, so the same risks do not recur.
• Customer confidence: a recognised maturity level reduces the client's risk, helping the organisation win contracts.

Hence, as an organisation climbs from level 1 to 5, the variation in project results shrinks and the likelihood of failure, cost overrun and poor quality is reduced.

Project management competencies. Project management competencies are the knowledge, skills and personal attributes that a project manager needs to plan, lead and deliver a project successfully. They include:

• Technical (knowledge) competence: understanding of project management methods and tools, scheduling, estimation, budgeting, risk and quality management, and the technology involved.
• Leadership and team management: motivating, directing and developing the team and resolving conflicts.
• Communication: clear reporting and negotiation with sponsors, users and team members.
• Planning and organising: defining scope, tasks, resources and schedule.
• Problem solving and decision making: handling issues and change.
• Personal competencies: integrity, adaptability, time management and stress handling.
• Business and customer awareness: aligning the project with organisational goals.

Project management life cycle. The project management life cycle is the set of phases through which every project passes, from idea to closure:

1. Initiation. Define the project's purpose, objectives, scope and the business case; assess feasibility; identify stakeholders; appoint the project manager; obtain approval (project charter).

2. Planning. Develop the detailed plan: work breakdown structure, schedule (Gantt/PERT/CPM), budget, resource and staffing plan, quality plan, risk plan and communication plan. Set the baseline.

3. Execution. Carry out the plan: assemble the team, perform the tasks, produce the deliverables, manage resources and communicate with stakeholders.

4. Monitoring and controlling. Carried out alongside execution: track progress against the plan, measure performance, manage changes and risks, control cost, schedule and quality, and take corrective actions.

5. Closure. Complete all work, get customer acceptance, hand over the deliverables and documents, release resources, prepare the final report and record lessons learned.

Good competencies are needed in each phase, since the manager has to plan carefully, lead the team, and keep the project in control until it is delivered.

System analysis. System analysis is the process of studying an existing system or business problem in detail in order to understand how it works, identify its problems and opportunities, and define the requirements for an improved system. It answers the question "what must the new system do?" and produces a clear statement of requirements for system design.

Phases of system analysis (as in the FAST-style methodology)

1. Scope definition. Determine whether the problem is worth solving, define the project's scope and boundaries, form the project team and prepare a plan. Output: statement of scope and a project plan, approved by management.

2. Problem analysis. Study the existing system in detail to understand its problems, causes and effects. The analyst studies the business, interviews users, observes work, reviews documents, and models the current system (DFDs, ER diagrams). Methods such as cause-and-effect analysis or PIECES framework are used. Output: a list of problems, opportunities and constraints, with improvement objectives.

3. Requirements analysis. Identify and document what users need from the new system: functional requirements (inputs, outputs, processes, data) and non-functional requirements (performance, security, usability). Techniques include interviews, questionnaires, JRP/JAD, observation, prototyping and sampling. Output: a requirements statement, prioritised and agreed with users.

4. Logical design (decision analysis, with feasibility). Convert the requirements into logical models independent of technology; then identify candidate solutions, test them for technical, operational, economic and schedule feasibility, and recommend the best one. Output: logical models and a system proposal.

5. Decision analysis and proposal. Management reviews the proposal and decides to approve, modify or cancel, after which the project moves into the design phase.

Together these phases ensure that the new system is built on a correct understanding of the real problem and the users' needs.

Prototyping. Prototyping is a technique in which a small, working model of the proposed system (or part of it) is built quickly so that users can see, try and comment on it before the full system is developed. The model may be screens, reports or a partially working program. Users' feedback is used to refine the requirements, and the cycle of build, evaluate and refine is repeated until the users accept the design. The prototype may be thrown away (throwaway prototyping) or evolved into the final system (evolutionary prototyping).

Advantages: misunderstandings are found early, users take part actively, requirements become clearer, risk is reduced. Disadvantages: users may think the prototype is the finished product, documentation and design quality may suffer, and it can lead to endless changes.

Interview and JRP.

• An interview is a fact-finding technique in which the analyst asks questions of one person (or a small group) face to face to learn about the system and requirements.
• Joint Requirements Planning (JRP) is a structured group workshop (a subset of JAD) in which analysts, users, managers and a facilitator meet for a planned session to define requirements together, using agenda, visual aids and a scribe.

Comparison

Similarity. Both are fact-finding techniques based on direct communication with users, used to gather requirements. Interviews suit individual details, whereas JRP suits obtaining agreement among many stakeholders quickly.

Normalization. Normalization is the process of organising the data of a relational database into well-structured relations (tables) by decomposing them so as to remove redundancy and avoid insertion, update and deletion anomalies. Each fact is stored once, and relationships are kept through keys. It proceeds in stages called normal forms:

• 1NF: every attribute holds atomic (single) values; no repeating groups.
• 2NF: in 1NF and every non-key attribute depends on the whole primary key (no partial dependency).
• 3NF: in 2NF and no non-key attribute depends on another non-key attribute (no transitive dependency).
• (BCNF: every determinant is a candidate key.)

Example. A relation ORDER(OrderID, ProductID, ProductName, CustomerID, CustomerName, Qty) violates 2NF as ProductName depends only on ProductID and CustomerName only on CustomerID. Decomposing into ORDER(OrderID, CustomerID), ORDER_ITEM(OrderID, ProductID, Qty), PRODUCT(ProductID, ProductName) and CUSTOMER(CustomerID, CustomerName) removes the redundancy.

ER diagram for an Online Shopping System

Entities and attributes (primary key underlined by PK):

• Customer (CustomerID PK, Name, Email, Phone, Address)
• Product (ProductID PK, Name, Price, Stock, CategoryID FK)
• Category (CategoryID PK, Name)
• Order (OrderID PK, OrderDate, Status, TotalAmount, CustomerID FK)
• OrderItem (OrderID PK/FK, ProductID PK/FK, Quantity, UnitPrice)
• Payment (PaymentID PK, Method, Amount, Date, OrderID FK)
• Cart (CartID PK, CustomerID FK)

Relationships:

• Customer places Order: one-to-many (1:N).
• Order contains Product: many-to-many (M:N), resolved by the associative entity OrderItem.
• Category classifies Product: one-to-many.
• Order is paid by Payment: one-to-one (or one-to-many for part payments).
• Customer owns Cart, which holds many Products.

Text form of the diagram:

[Customer] --1----places----N-- [Order] --1----has----N-- [OrderItem] --N----is of----1-- [Product] --N----belongs to----1-- [Category]
                                   |
                                   1 -- paid by -- 1 [Payment]

Entities are drawn as rectangles, attributes as ovals, relationships as diamonds, with cardinalities (1, N) on the connecting lines.

Process model. A process model is a graphical representation of the processes of a system and the flow of data among them. It shows how input data is transformed into output, the sources and destinations of data, and the data stores used. The Data Flow Diagram (DFD) is the commonly used process model, in context, level-1 and lower levels of detail. A logical process model shows what the business does, while a physical process model shows how it is implemented in programs, people and technology. Process models are used to understand the existing system, define requirements, and communicate between users and developers.

Logical versus physical data modelling

A logical data model describes the data and its relationships from the business point of view, while a physical data model describes how the data is actually stored in a particular database.

Example. Logical: entity STUDENT with attributes RollNo, Name, DateOfBirth, related to COURSE. Physical: table student(roll_no INT PRIMARY KEY, name VARCHAR(60) NOT NULL, dob DATE) with an index on name, in MySQL.

Creeping commitment. Creeping commitment is the approach of re-estimating and re-evaluating a project's feasibility, costs and benefits at several checkpoints during the system development life cycle, instead of only once at the beginning. The commitment of the organisation to the project grows gradually ("creeps") as each phase is completed. At every checkpoint (after survey, study, definition, design, and so on) management decides whether to continue as planned, revise the scope or budget, or cancel the project. Costs and benefits are estimated more accurately as more is known, so money is not locked in early on poor information. Its advantages are reduced risk, early cancellation of unworkable projects, and better control.

Tests for feasibility

1. Operational feasibility: whether the system solves the problems and will be accepted and used by users and management, and fits the organisation's procedures.
2. Technical feasibility: whether the necessary technology, hardware, software and technical skills are available or can be acquired, and the system can be built and expanded.
3. Economic feasibility: whether the benefits outweigh the costs, using payback period, ROI and NPV (cost-benefit analysis).
4. Schedule feasibility: whether the system can be developed and delivered within the required time.
5. Legal feasibility: whether the system conforms to laws, regulations, licences and contracts.
6. Cultural/political feasibility: whether the system is compatible with the organisation's culture and politics, and acceptable to stakeholders.

These tests are applied first in the preliminary investigation and re-applied at later checkpoints under creeping commitment, so the project's viability is confirmed repeatedly.

Rapid Application Development (RAD). RAD is a system development methodology that emphasises very fast development through intensive user participation, iterative prototyping, reusable components and the use of automated tools (CASE, 4GL, code generators), with short time-boxed cycles (typically 60 to 90 days). Instead of a long sequential analysis, design and coding sequence, analysts and users work together in workshops (JAD/JRP) to build prototypes that are refined repeatedly until the system is accepted.

Phases: requirements planning, user design (prototyping with feedback), construction (building from prototypes), cutover (testing, training, deployment). Advantages: quick delivery, early user involvement and lower risk of rejection. Disadvantages: needs skilled developers and committed users; unsuitable for very large or highly critical systems; quality and scalability may suffer.

In-house development. The organisation designs, builds and maintains the system with its own staff (or uses its own team with contract help).

• Advantages: system matches the exact requirements, full control over features, schedule and source code, competitive advantage, in-house knowledge for support and change.
• Disadvantages: higher cost and longer time, needs skilled staff, risk of delays and failure, maintenance burden.
• Suitable when the requirement is unique or strategic and no suitable product exists.

"Buy" solution. The organisation purchases a ready-made commercial off-the-shelf (COTS) package, such as accounting or ERP software, and installs and customises it.

• Advantages: faster implementation, lower initial cost, tested and proven product, vendor support and upgrades.
• Disadvantages: may not fit all needs, so customisation or process change is required; dependence on the vendor; licensing and integration costs; limited control over source code.
• Suitable when the need is common (payroll, accounting) and time or skills are limited.

The choice between building and buying is made during the decision analysis phase by comparing cost, time, fit, risk and available skills.

Model-Driven Development (MDD). MDD is a development strategy in which models (data, process and object models) are the primary artefacts, drawn in the analysis and design stages and used, ideally with CASE tools, to generate the database and program code. The process is:

1. Gather requirements and build the logical models (use-case, DFD, ER and class diagrams) of the system.
2. Refine the models into design models (physical data model, interface and program specifications).
3. Use tools to generate database schemas and code from the models.
4. Test, deploy and maintain by changing the model and regenerating.

The approach gives consistency between design and code, better communication and easier change. Its forms include structured analysis, information engineering and object-oriented development (UML).

Real project example: a bank building an internet banking system draws UML use-cases and class diagrams for accounts, transfers and customers, then generates the database tables and class skeletons from the model with a CASE tool, and developers complete the business logic.

COTS (Commercial Off-The-Shelf) strategy. COTS means acquiring a ready-made software package from a vendor and adapting it, instead of writing the system. The process is:

1. Define business requirements and the evaluation criteria.
2. Prepare a request for proposal (RFP) or quotation and send it to vendors.
3. Evaluate packages (features, cost, vendor reputation, support, integration); run demos and pilots.
4. Select the vendor, negotiate the contract and licence.
5. Customise or configure the package, integrate with existing systems, convert data.
6. Train users, install, and obtain vendor maintenance.

Real project example: a college that needs an examination and fee management system buys an existing school/college management package, configures grading and fee rules, imports student data and trains staff. It is ready within weeks at lower cost than building its own, though some local procedures must be adjusted.

Contrast. MDD builds custom software guided by models, giving a precise fit but higher cost and time; COTS buys a ready product, giving speed and lower cost but less flexibility.

Brainstorming. Brainstorming is a group fact-finding and idea-generation technique used in systems analysis to produce as many ideas as possible about a problem, requirement or solution in a short time. A facilitator brings together analysts, users and managers in a session.

Rules and procedure

• State the problem or topic clearly.
• Participants offer ideas freely; quantity is encouraged and wild ideas are welcome.
• No criticism or evaluation is allowed while generating ideas.
• Participants may combine and improve the ideas of others.
• All ideas are recorded on a board or flipchart.
• Afterwards, the ideas are clarified, grouped, evaluated and ranked, and the best ones are chosen for further study.

Advantages: creative, quick, encourages participation and fresh solutions, and surfaces requirements that individual interviews may miss. Disadvantages: dominant members may take over, shy members may stay silent, ideas can be unrealistic, and it needs an experienced facilitator.

It is often used in JRP/JAD sessions during requirements discovery and when finding alternative solutions.

ER diagram. An Entity-Relationship (ER) diagram is a graphical data model, proposed by Peter Chen, that shows the entities of a system, their attributes and the relationships among them. It is used in analysis and logical design to describe the data requirements and as a basis for designing a relational database.

Components

• Entity: a thing about which data is stored (Student, Course); drawn as a rectangle. A weak entity (double rectangle) depends on another entity for identification.
• Attribute: a property of an entity, drawn as an oval; types include key (underlined), composite, multivalued (double oval) and derived (dashed oval).
• Relationship: association between entities, drawn as a diamond (Student enrolls in Course).
• Cardinality: number of instances that may be related: one-to-one (1:1), one-to-many (1:N) and many-to-many (M:N), with participation being total or partial.

Example. STUDENT(RollNo, Name) enrolls in COURSE(CourseID, Title): a student may take many courses and a course has many students (M:N). It is converted to tables STUDENT, COURSE and ENROLLMENT(RollNo, CourseID).

Uses: documenting data requirements, communication between analysts and users, detecting redundancy, and mapping to tables during database design.