Analysis and Design: Requirements, DFD, ER and Screens

Design is thinking on paper, where mistakes cost minutes instead of weeks.

This unit takes the scope of Unit 1 and produces the four documents that every Project I report needs: the requirements list, a use-case diagram, data-flow diagrams (DFD) and an entity-relationship (ER) diagram with a database schema, plus screen sketches.

3.1 Requirements: what the system must do

A functional requirement states something the system does ("the system shall calculate a fine"). A non-functional requirement states how well it does it (speed, security, usability). Each must be testable: a tester should be able to say pass or fail.

ID	Type	Requirement	How it is tested
F1	functional	The librarian logs in with a user name and password.	wrong password is rejected
F2	functional	The librarian adds, edits and searches books and members.	add a book, find it by title
F3	functional	The system issues a book for 14 days if a copy is available.	issue the last copy, next issue refused
F4	functional	On return, fine = Rs 2 × days beyond the due date.	return 5 days late, fine is Rs 10
F5	functional	The system lists all overdue books.	one overdue loan appears
N1	non-functional	Issue or return completes in under 30 seconds.	stopwatch on 20 transactions
N2	non-functional	Passwords are stored only as salted hashes.	inspect the database file
N3	non-functional	A new librarian can learn the screens in 15 minutes.	trial with one user

User stories are a friendly form: "As a librarian, I want to see overdue books, so that I can remind students." Write one per functional requirement and tick them off at the demo.

3.2 Use-case diagram

A use-case diagram shows who (the actors) uses which functions of the system (the use cases), inside a boundary box. It is the cleanest way to show the examiner the whole system on one page.

3.3 Data-flow diagrams: how data moves

A DFD shows how data flows between external entities (people or systems outside), processes (circles that transform data), data stores (open boxes where data rests) and flows (labelled arrows). It never shows loops, decisions or code; only data.

• Level 0 (context diagram): the whole system is one process, with every external entity and the flows in and out.
• Level 1: the single process is exploded into three to seven main processes and the data stores.
• Rules: every flow has a name; a process has at least one input and one output; data stores connect only to processes; a level 1 diagram must have the same external flows as level 0 (balancing).

3.4 The ER diagram and the database schema

An entity-relationship (ER) diagram shows the things the system stores (entities), their properties (attributes) and how they relate (cardinality: 1 to many, many to many).

A many-to-many relationship, such as "a student borrows many books and a book is borrowed by many students over time", becomes its own table (here issue), which also holds facts about the event: dates and fine.

The schema is created and checked by the next script: it lists the tables, shows the foreign keys and proves that the database refuses a loan for a member who does not exist.

import sqlite3
db = sqlite3.connect(":memory:")
db.execute("PRAGMA foreign_keys = ON")
db.executescript("""
CREATE TABLE member (member_id INTEGER PRIMARY KEY, name TEXT NOT NULL, program TEXT, phone TEXT);
CREATE TABLE book   (book_id INTEGER PRIMARY KEY, title TEXT NOT NULL, author TEXT, copies INTEGER CHECK (copies >= 0));
CREATE TABLE issue  (issue_id INTEGER PRIMARY KEY,
    member_id INTEGER NOT NULL REFERENCES member(member_id),
    book_id   INTEGER NOT NULL REFERENCES book(book_id),
    issue_date TEXT NOT NULL, due_date TEXT NOT NULL, return_date TEXT, fine INTEGER DEFAULT 0);
""")
for (t,) in db.execute("SELECT name FROM sqlite_master WHERE type='table' ORDER BY name"):
    cols = [c[1] for c in db.execute(f"PRAGMA table_info({t})")]
    print(f"{t:7s}", ", ".join(cols))
print("foreign keys of issue:", [(r[2], r[3]) for r in db.execute("PRAGMA foreign_key_list(issue)")])
try:
    db.execute("INSERT INTO issue (member_id, book_id, issue_date, due_date) VALUES (99, 1, '2082-01-01', '2082-01-15')")
except sqlite3.IntegrityError as e:
    print("rejected:", e)

book    book_id, title, author, copies
issue   issue_id, member_id, book_id, issue_date, due_date, return_date, fine
member  member_id, name, program, phone
foreign keys of issue: [('book', 'book_id'), ('member', 'member_id')]
rejected: FOREIGN KEY constraint failed

Normalisation check. Every table has a primary key and each non-key column depends on the whole key and nothing else (third normal form): a book's title lives only in book, a member's name only in member. That is why the loan table stores IDs, not names.

3.5 Screen design: wireframes

A wireframe is a boxes-and-labels sketch of a screen. Draw it before coding; it takes ten minutes and prevents a week of changed layouts. Show it to the librarian and ask "can you do your job with this?".

(a) Login screen

(b) Issue book screen

(c) Overdue report

3.6 Eight benefits of designing before coding

1. Cheaper mistakes. Changing a box on a diagram takes a minute; changing a finished database takes days. Studies of software projects repeatedly show that errors found late cost many times more to fix. Draw first, code second.
2. A shared picture for the team. The DFD and ER diagram show every member the same system. Arguments end when the diagram is clear. This is vital when three students code three modules.
3. Better questions to the user. A wireframe shown to the librarian brings real feedback: "we also record the shelf number". It is far easier to add a field to a sketch than to a running program.
4. Cleaner database. The ER step removes repeated data, such as typing a student's name in every loan. Fewer copies mean fewer spelling mistakes. The data stays consistent for years.
5. Easier testing. Every requirement with a clear ID becomes a test case with a clear expected result. The tester can prepare test cases while the developers still code. Nothing is left to memory.
6. Smoother report writing. The design chapter of the TU report is the diagrams themselves, with a paragraph each. You do not have to reconstruct them from code afterwards. Examiners usually read this chapter first.
7. Fair division of work. Modules and tables are visible, so the leader can assign them without overlap. Each developer knows the interface to the others. Integration week then holds fewer surprises.
8. Confidence in the viva. A student who drew the diagram can explain the system from the whole to the part. Questions such as "why this table?" or "where does this data go?" are then easy. Memorised code answers cannot do this.

(a) A card catalogue: one drawer per letter

(b) Scan vs index: SQLite steps for one ISBN

Formula and fact sheet

• Functional = what; non-functional = how well; both must be testable.
• DFD symbols: entity (rectangle), process (circle), store (open box), flow (arrow). Level 0 = one process.
• ER cardinality: 1:1, 1:N, M:N (M:N becomes an associative table with two foreign keys).
• PK identifies a row; FK points to a PK in another table. 3NF: no repeated or indirectly dependent data.

Chapter summary

• Requirements are written as testable functional and non-functional statements.
• Use-case diagrams show actors and functions; DFDs show data movement at level 0 and level 1.
• The ER diagram becomes the schema; foreign keys protect the data (a real script proved it).
• Wireframes and a design-first habit save weeks of rework and help in the viva.

Practice

1. Differentiate functional and non-functional requirements with two examples each.
2. Rewrite "the system should be fast" as a testable requirement.
3. Draw the use-case diagram for an online bus-ticket system with two actors.
4. State four rules for drawing DFDs.
5. What is a context diagram? What does balancing mean?
6. Convert the many-to-many relationship between STUDENT and COURSE into tables.
7. What does the script in Section 3.4 prove with the "rejected" line?
8. Why should the loan table store member_id instead of the member's name?
9. List the controls a login screen needs to be secure.
10. A library has 1,200 members and each borrows on average 15 books a year. How many rows does the issue table gain per year, and per day (365 days)?

Answers and worked solutions

1. Functional: "issue a book", "calculate fine". Non-functional: "respond in 30 s", "store hashed passwords".

2. "Every search over 5,000 books returns in under 2 seconds on the college PC."

3. Actors: passenger (search, book, cancel), operator (add bus, view sales); boundary box around the use cases.

4. Name each flow; a process needs an input and an output; stores connect only to processes; no entity-to-entity or store-to-store flows.

5. A level 0 DFD with one process. Balancing: the external flows in level 1 equal those in level 0.

6. STUDENT(student_id, ...), COURSE(course_id, ...), ENROLMENT(student_id FK, course_id FK, grade).

7. The foreign key stops a loan for member 99, who does not exist, so no orphan records enter the database.

8. Names repeat, change and can be misspelt; an ID is unique and stable, and the name is stored only once.

9. Hashed and salted passwords, lock-out after repeated failures, masked input, no password in logs or source code.

10. 1,200 × 15 = 18,000 rows per year; 18,000 / 365 ≈ 49 per day.

Model answers: medium (5 marks) and long (10 marks) questions

Q1 (5 marks). Differentiate functional and non-functional requirements, with examples.

Introduction. Requirements describe what users need from the system. Writing them clearly before design prevents misunderstanding and gives the tester something to check.

Point	Functional	Non-functional
Meaning	what the system does	how well it does it
Example (CampusShelf)	F4: fine = Rs 2 × late days	N1: issue in under 30 seconds
Described by	features, inputs, outputs	speed, security, usability, reliability
Test	does the feature give the right result?	is the measured quality within the limit?
If missing	the system lacks a function	the system works but is slow, unsafe or hard to use

Writing rules. Each requirement has an ID, one sentence, the word "shall" and a test (see the table in Section 3.1). Vague words such as "fast" or "user-friendly" are replaced by numbers.

Conclusion. Both kinds are needed: a system with every function but a 3-minute response fails N1, and a fast system without fines fails F4.

Q2 (5 marks). Explain level 0 and level 1 DFD with the symbols used.

Introduction. A data-flow diagram models how data moves through a system, ignoring control logic and code.

Symbols. External entity (rectangle): person or system outside, such as the librarian. Process (circle): transforms data, numbered such as 2.0. Data store (open box): data at rest, such as D3 Issues. Data flow (arrow): named data in motion.

Level 0. The context diagram shows the whole system as one process with its external entities and flows (Figure 3.2): book, member and issue data in; receipts, fines and overdue lists out.

Level 1. The one process splits into three: 1.0 Manage catalogue, 2.0 Issue and return, 3.0 Overdue reports, connected to stores D1, D2 and D3 (Figure 3.3).

Rules. Name every flow; every process has input and output; stores connect only to processes; levels must balance.

Conclusion. The two levels let the examiner see the system first as a whole, then in parts.

Q3 (10 marks). Prepare the analysis and design of a library book-issue system: requirements, use cases, DFD, ER diagram and screens.

Introduction. The design phase turns the scope of the project into documents that the team can code from and the examiner can read. For a college library with 1,200 members the work is as follows.

1. Requirements. Functional: login (F1), manage books and members (F2), issue for 14 days if a copy exists (F3), fine of Rs 2 per day late on return (F4), overdue list (F5).

Non-functional: under 30 seconds per transaction (N1), salted-hash passwords (N2), learnable in 15 minutes (N3). Each has a test (Section 3.1).

2. Use cases. Actors: librarian and student. The librarian uses login, manage books, manage members, issue, return and fine, and overdue report; the student searches and views own loans (Figure 3.1).

3. DFD. Level 0 has one process with the librarian and student as entities (Figure 3.2). Level 1 has three processes and three data stores (Figure 3.3) and is balanced with level 0.

4. ER diagram and schema. Entities MEMBER, BOOK and ISSUE; MEMBER 1:N ISSUE and BOOK 1:N ISSUE, which resolves the many-to-many relationship (Figure 3.4). Primary keys are member_id, book_id and issue_id; ISSUE carries the foreign keys.

The tables are in third normal form, and the script of Section 3.4 showed the foreign key rejecting an invalid member.

5. Screens. Login, issue and overdue wireframes (Plate 3.1) were reviewed by the librarian before coding.

6. Traceability. Each requirement maps to a use case, a process, a table and a screen:

Requirement	Use case	DFD process	Table	Screen
F1 login	Log in	(entry)	librarian (added in Unit 4)	Login
F3 issue	Issue book	2.0	issue, book	Issue book
F4 fine	Return and fine	2.0	issue	Issue book
F5 overdue	Overdue report	3.0	issue, member	Overdue report

7. Validation. Data checks: copies cannot be negative, a loan needs an existing member and book, dates must be valid.

Conclusion. With requirements, diagrams, schema and screens agreed with the librarian, coding becomes translation rather than invention. The same documents form the design chapter of the project report.