Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-B6, Advanced Software Project Management, Life Cycle Methodologies — National Exams, May 2015 (3 hours, open book, non-communicating calculator permitted, 8 questions of equal value; FIVE (5) constitute a complete exam paper and the first five as they appear in the answer book are marked — all eight are solved here as a study resource).
Reference texts: Sommerville, Software Engineering, 10th ed. (process models, requirements engineering); Pressman, Software Engineering: A Practitioner's Approach, 9th ed. (process models, agile, the Four P's, metrics); ISO/IEC 12207:2017, Software life cycle processes; PMI, A Guide to the Project Management Body of Knowledge (PMBOK), 7th ed. (knowledge areas, scope management); SWEBOK v4 (software project management, requirements engineering).
Part (a) — functional requirements. Functional requirements state what the system must DO — the specific behaviours, features, and services it must provide, derived directly from the scenario:
Simulate a library of distinct network protocols (e.g., torrent-like peer-to-peer transfer, streaming-media transfer), each configurable to model a chosen real-world application's traffic pattern against a target router.
Generate a run log file recording the stress-test readings (e.g., throughput, latency, packet loss, connection counts) for each simulated run.
Upload/transmit each run's log file to a central database automatically after the run completes.
Provide an auto-plot function that renders stored readings as charts/graphs.
Provide a search function allowing testers/designers to locate specific runs or readings in the database (e.g., by protocol, date, router model).
Provide access to the raw underlying data for further manipulation/export by the user.
Authenticate users through a secure web front end before granting access to stored results.
Allow multiple testers and service designers to access the central database's results (multi-user access to shared data).
Part (b) — non-functional requirements. Non-functional requirements constrain HOW WELL the system performs its functions, or under what conditions, rather than adding a new capability:
NFR category
How it applies to this system
Portability
Client software must run correctly on OS X and Linux ONLY — an explicit, hard platform constraint stated in the scenario.
Security
The web front end must be "secure" — authenticated, encrypted (TLS) access, and appropriate access control over who can view/search results.
Performance
The protocol simulators must generate realistic, sufficiently high-volume traffic to genuinely stress-test consumer-grade routers, and log ingestion must keep pace with concurrent runs without dropping readings.
Scalability
The central database and log-ingestion service must accommodate a growing number of testers, protocols, and stored historical runs without degrading search/plot response time.
Reliability / availability
The server and database must be available whenever testers/designers need to submit or review results, and must not lose or corrupt log data on ingestion.
Usability
The auto-plot, search, and raw-data views must be usable by testers/service designers who are not necessarily software developers.
Maintainability
The library of protocol simulators must be structured so new protocols can be added over time without redesigning the logging/database/web layers.
The functional/non-functional split matters operationally: functional requirements are individually testable pass/fail (does the search function return the right run?), while most non-functional requirements need a measurable target attached (e.g., "supports N concurrent simulated protocol streams," "search returns results within X seconds") before they can be verified the same way.
