Functional Requirements and Use-Case Model: 19-Soft-A5 Requirements and Specifications, May 2014, Q2

Question 2: Functional Requirements and Use-Case Model (25%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part 2.1 — functional requirement. A functional requirement states something the system must do: a specific service, behaviour or transformation of inputs to outputs that the system provides to its users, expressed independently of how it is implemented (Sommerville Ch. 4). It is typically phrased as "the system shall …" — e.g. "the system shall let a member submit a purchase of club units and update that member's unit holding accordingly." Functional requirements are contrasted with non-functional requirements (Question 4), which constrain how well the functions must be delivered (speed, security, usability) rather than describing a new capability.

Part 2.2 — use case and use-case model. A use case is a description of a discrete piece of behaviour that the system provides in response to a request from one of its actors, phrased from the actor's point of view: a named goal (e.g. "Buy Club Units"), typically written as a main success scenario plus alternate/exception flows, that delivers observable value to the actor who invoked it (Sommerville §5.2; Jacobson's original use-case concept). A use-case model is the set of all such use cases for a system together with a use-case diagram showing which actor (a role external to the system — a person or another system — that interacts with it) participates in which use case, and any «include»/«extend» relationships between use cases. Together the model gives a functional, user-centred view of the whole system's scope without committing to an internal design.

Part 2.3 — actors for IseeFin.

Actor	Description
Club Member	An ordinary investor who has bought units of one club; buys/sells units, views their own holdings and valuation.
Trading Officer	A club member designated to execute the club's actual securities trades on its online brokerage account(s).
Treasurer	A club member designated to manage the club's cash, reconcile bank/brokerage statements, and generate the club's tax reporting.
Club Administrator	Configures a new club (name, appearance, access rules, initial unit price) and manages membership (join/leave).
Brokerage / Bank (external system)	The club's online brokerage and bank accounts; a future synchronisation feed for trades and balances.
Tax Reporting Engine (external/internal service)	Produces the country-specific flow-through tax form (T5 in Canada, Form 1065 in the USA) from the club's ledger.

Figure 1 — IseeFin use-case diagram: six actors (three club-facing, two external, one administrative) against the nine use cases identified in 2.4.

Part 2.4 — use cases for IseeFin.

Use case	Description
Buy / Sell Club Units	A member submits a purchase or redemption of IC units at the current unit price; the system validates funds/holdings and updates the member's unit balance and the club's total units outstanding.
View Holdings & Valuation	A member views their current unit count, unit price and dollar valuation, and the club's aggregate portfolio holdings, restricted to that club's members only.
Record Securities Trade	The trading officer logs a buy/sell of a security in the club's brokerage account (symbol, quantity, price, date), which updates the club's portfolio and, through the unit price, every member's valuation.
Reconcile Treasury	The treasurer matches IseeFin's internal cash ledger against the club's bank/brokerage statements and records any adjusting entries needed to bring them into agreement.
Generate Tax Report	The treasurer requests the country-appropriate flow-through tax form (T5 in Canada, Form 1065 in the USA) computed from the year's transactions and each member's share.
Configure Club Setup	The administrator creates a new club or edits its name, appearance, access rules, base currency/currencies and initial unit price.
Join / Leave Club	The administrator (or a self-service flow) admits a new member at the current unit price or processes a departing member's full redemption.
Sync Bank / Brokerage Feed	The system pulls transaction and balance data from the club's linked bank and online-brokerage accounts to pre-populate the ledger (an "advanced feature" per the brief).
Convert Multi-Currency	Amounts held or transacted in a second currency (e.g. CAD alongside USD) are converted to the club's reporting currency for valuation and tax purposes.

Concept & Theory

Topic. Functional-requirement definition; use case / use-case model; actor and use-case identification from a product brief.

Key relations. Functional requirement = a stated system behaviour ("shall …"); Use case = actor-goal-scenario triple; Use-case model = {actors} × {use cases} × participation relation, rendered as a UML use-case diagram.

Why this works. Deriving actors and use cases directly from the brief's "Key Features" bullets (each bullet becomes one or more use cases, each distinct role mentioned becomes an actor) is a systematic, repeatable elicitation-to-model transform that avoids missing a stated capability, and it is exactly the technique examiners are checking for in 2.3/2.4.

Common pitfall. Listing "system features" as actors (e.g. writing "Tax Reporting" as an actor) instead of the external role that triggers the feature; an actor must be outside the system boundary (a person or another system), never a function the system itself performs.

Source. Sommerville, Software Engineering, 10th ed., §4.3 (Functional requirements) & §5.2 (Use cases).

Question 2 of 7: Functional Requirements and Use-Case Model

Question 2: Functional Requirements and Use-Case Model (25%)