19-Soft-B6 Software Project Management, May 2018, Q7

Question 7 (10 marks)

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.

Fig. Q7 — system context: unauthenticated and logged-in users reach the adventure web application, which is backed by listing/details, map, ratings/safety, and authentication services.

Part (a) — process model choice. An incremental process model (Question 2b) is the best fit. The requirement narrative already separates a clear priority order — "the first of which will be" unauthenticated viewing of adventures and the map, "as this is the main point of the system," with login accommodated afterward — which maps directly onto a natural first increment (public listing + map, delivering the core value with no authentication complexity) followed by a second increment (user accounts/login and any features that depend on being logged in). Building the public-viewing core first and shipping it lets real users and real adventure data start validating the listing/map/ratings features immediately, while the smaller, better-understood login increment is added without having blocked the higher-value core feature on it. A pure Waterfall approach would instead force the team to fully specify the (currently vaguer) authenticated-user features before any of the system could be released, delaying the system's main point unnecessarily.

Part (b) — functional requirements. Functional requirements state what the system must DO, derived directly from the scenario:

Display a consolidated list of adventures to any visitor, without requiring login.
Display adventure details — name, description, trail features, pictures, trail status, peer ratings, and safety information — for a selected adventure.
Display all adventures with location data on a master map giving an overall view.
Allow a user to log in (and, implicitly, register/authenticate) to access account-specific functionality.
Store and serve adventure data (name, description, features, pictures, status, ratings, safety info, location) from a backing data store to the listing, detail, and map views.
Allow authenticated users to submit or update information about adventures (peer ratings at minimum, since the system's stated purpose is collecting adventure data, and ratings are explicitly listed as data the system displays).

Part (c) — non-functional requirements.

NFR category	How it applies to this system
Accessibility	The core viewing functionality must be usable by "any user with internet access," implying broad browser/device compatibility and no mandatory plugin or account for the main use case.
Performance	The adventure list, detail pages, and especially the master map (rendering potentially many location markers at once) must load and respond within an acceptable time for a public-facing web application.
Scalability	The system must handle a growing catalog of adventures and a growing number of concurrent unauthenticated visitors without the listing/map views degrading.
Security	Login/authentication must protect user credentials and account data, and must not expose any authenticated-only capability (e.g., editing ratings) to unauthenticated users.
Usability	Since the "main point of the system" is unauthenticated browsing, the list/detail/map views must be immediately usable with zero account setup — any friction here directly undermines the system's stated primary purpose.
Data integrity/reliability	Safety information in particular must be accurate and reliably available, since it is used by trail-goers for real-world decisions — a stale or unavailable safety-info service is a higher-consequence failure than a stale ratings count.

As in the requirements-derivation approach established in this subject, each NFR here is anchored to a specific phrase in the narrative (any user with internet access → accessibility; general users viewing without necessarily logging in → usability of the unauthenticated path; safety information → reliability) rather than asserted generically.

Topic: Choosing a process model that matches a narrative's own stated priority order, and deriving functional/non-functional requirements from a project scenario.

Key relations: Process model choice should match how the requirements themselves are structured — a scenario with an explicit "build this core first, add this afterward" priority is evidence for an incremental (or agile) model over Waterfall. Functional requirement = a specific, testable behaviour. Non-functional requirement = a quality attribute or constraint that applies across functions.

Why this works: the scenario itself supplies the justification for part (a) — "the first of which will be... as this is the main point of the system" is a textual signal of priority that a Waterfall model has no mechanism to exploit (it delivers everything at once, at the end), while an incremental model can turn that stated priority directly into the content of increment 1.

Common pitfall: picking a process model in part (a) based on generic reasoning ("agile is popular") rather than tying the choice back to a specific feature of the scenario given — graders reward the justification, not the label.

Source: Sommerville, Software Engineering, 10th ed., Ch. 2 (Process Models) & Ch. 4 (Requirements Engineering); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2.

Question 7 of 8

Question 7 (10 marks)