Question 1 of 7: Stakeholders and Eliciting Detailed Requirements

Question 1: Stakeholders and Eliciting Detailed Requirements (15%)

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 1.1 — main stakeholders. A stakeholder is anyone whose interests are materially affected by the system or who can materially affect it (Sommerville Ch. 4). For IseeFin these fall into five classes. Direct end users: ordinary club members who buy/sell units and view their holdings; the trading officer who executes the actual securities trades; and the treasurer who manages the club's cash and bank/brokerage reconciliation. Club administrators, who configure a new club's name, appearance, access rules and initial unit price, and onboard/offboard members. The business sponsor — the product owner who is funding IseeFin's development and whose commercial goals (winning share from the $270 US federation tool, ShareScope in the UK, and the manual/Excel incumbents) drive the roadmap. Regulatory / compliance stakeholders, indirect but essential: national and provincial/state tax authorities (since correct T5/Form-1065 flow-through reporting is described as the product's main selling point), and, more loosely, the securities regulators whose rules govern how a pooled investment vehicle may be operated. External system stakeholders: the online brokerages (e.g. ETrade) and banks whose data IseeFin will eventually synchronise with, and the hosting/cloud operator whose availability and security posture the product inherits.

Part 1.2 — elicitation approach. No single technique surfaces every stakeholder's needs, so elicitation should combine several, matched to each class from 1.1. Interviews (structured and semi-structured) with a small number of real investment-club officers — treasurers and trading officers in particular — are the primary source for the transactional workflow (buying units, recording a trade, running month-end reconciliation), because these are domain experts whose tacit knowledge is not written down anywhere. Contextual inquiry / observation of an existing club doing its books manually (paper register or Excel, per the competitive-landscape note) exposes workarounds and pain points that a pure interview would not think to mention. Questionnaires/surveys sent to a wider population of the 4,700 US and 390 Canadian clubs quantify how common each need is (e.g. how many clubs already operate in two currencies) before committing scarce development budget to it. Focus groups with a handful of clubs together let members debate trade-offs (e.g. simplicity vs. configurability of the unit-price scheme) and reveal disagreements a one-on-one interview would hide. Document analysis of the competing products' user manuals and of the actual T5/Form-1065 tax forms grounds the tax-reporting requirement in the real regulatory artifact it must produce. Finally, prototyping a thin vertical slice (unit purchase → valuation screen) and walking it past a few clubs converts vague "make it easy to use" statements into concrete, arguable feedback — essential here because several stakeholders (ordinary members) are not technical and cannot articulate requirements in the abstract.

Part 1.3 — main concern per stakeholder class. Club members care most about trust and transparency: can I see, at any time, exactly how many units I own and what they are worth, and is my money safe. The trading officer's main concern is accuracy and auditability of the trade-recording workflow, since a mis-recorded trade misstates every member's valuation. The treasurer's main concern is reconciliation correctness between the club's bank/brokerage statements and IseeFin's internal ledger, plus year-end tax-reporting accuracy, because errors here create personal liability as the officer who signs the return. The club administrator's main concern is configurability without complexity — being able to set the club up correctly (currency, unit price, access rules) without needing IT skills. The business sponsor's main concern is differentiation and adoption cost: IseeFin must beat the antiquated $270 incumbent and the $119.99/member alternative clearly enough, on ease of use and multi-currency/tax support, to convert clubs that currently manage "manually." Tax authorities' implicit concern is correct flow-through calculation per jurisdiction. The hosting/cloud operator's concern is security and availability, since the system holds financial data for many clubs at once (a multi-tenant SaaS, in the paper's own words).