Requirements analysis and definition
A requirement is something the system must do or be. Analysis means finding the requirements by talking to users, watching how they work, and reading old forms. Definition means writing them clearly so everybody agrees.
- Functional requirements: what the system does ("a student can borrow a book").
- Non-functional requirements: how well it does it ("a search answers in under 2 seconds", "works on a phone", "only the librarian can edit books").
Each requirement should be clear, testable and not in conflict with another. The result is a requirements definition document that the users approve before building starts.
Modelling an information system
A model is a simple drawing of the system before we build it. Different drawings show different things.
- Data flow diagram (DFD): shows people (who ask), processes (what is done) and data stores (where data lives), joined by arrows that show how data moves.
- Entity-relationship (ER) diagram: shows the things we keep data about (student, book, loan) and how they link.
- Flowchart or use case: shows the steps of one job, or what each kind of user can do.
Models help us find missing steps early, when mistakes are cheap to fix.
Partitioning an information system
Partitioning means dividing a big system into smaller parts called modules or subsystems. Each module does one clear job and talks to the others through a small, clear interface.
- High cohesion: everything inside a module belongs together.
- Low coupling: modules depend on each other as little as possible.
- Benefits: teams can work in parallel, testing is easier, one module can be replaced or fixed without breaking the rest.
Common splits: by function (members, books, loans), or by layers (screen, logic, database).
Try it
In the 3D (last step): press "Change the Loans module". Which blocks changed? Then press "Add new module" and count the modules.
At home: pick a small system, such as a tuck-shop. Write four requirements on slips of paper. Then group the slips into 2 or 3 modules.
Key formulas and definitions
- Requirements: functional (what it does) and non-functional (how well).
- Modelling tools: data flow diagram, ER diagram, flowchart.
- Partitioning goals: high cohesion, low coupling.
- Design order: ask (requirements) then map (model) then part (modules).
Worked examples
1. For a library app, is "search a book in under 2 seconds" functional or non-functional?
Non-functional. It says how well the search must work, not what the system does.
2. In a data flow diagram of "borrow a book", name the person, the process and the data store.
Person: the student. Process: borrow the book. Data store: the book list.
3. A system is split into Members, Books and Loans. The fine rules change. Which module is edited?
Loans (fines belong to borrowing). Members and Books stay as they are.
4. Group these into modules: add student, search title, issue book, remove book, return book.
Members: add student. Books: search title, remove book. Loans: issue book, return book.
Common mistakes
- Starting to code before the requirements are clear.
- Writing vague requirements such as "the app should be fast". Say how fast.
- Making modules that all depend on each other (high coupling).
- Changing the requirements without telling users, so the finished system is not what they wanted.