Where Does the Enrollment System End?
Northfield University is replacing its 18-year-old enrollment system. The project charter says the new system will 'support admissions, registration, and student records.' Six departments have submitted needs. The payment gateway, identity provider, government reporting service, and legacy student-record system are all described as 'integrations' but no interface owner is named. The admissions office expects the system to score applicants; the registrar expects it to schedule rooms; the finance office expects it to calculate tuition. The vendor's fixed-price proposal covers 'standard enrollment functionality' and excludes 'third-party interfaces'. A context diagram shows only two external entities: 'Student' and 'Bank'. Three assumptions in the requirements document are unlabeled: that the identity provider supports SAML, that the government reporting format is stable, and that the legacy system will be retired in phase 1. The project has 11 months and a change-control board that meets monthly.
1. Redraw the system boundary at a conceptual level. Which external entities and interfaces are missing, and why does the current two-entity context diagram mislead the project?
Read the worked answer
The current diagram misleads because it treats the enrollment system as a consumer app connected only to students and a bank, while the real scope includes identity, payment, government reporting, and legacy records. A defensible boundary for phase 1 is: the system owns admissions application capture, applicant scoring workflow, registration, tuition calculation, and student-record updates; it does not own identity proofing, payment clearing, government reporting policy, or the legacy system's data. External entities should include the identity provider (SAML or OIDC authentication and attributes), payment gateway (authorization, settlement, refunds), government reporting service (submission format, schedule, error handling), legacy student-record system (data migration and coexistence), and at least the registrar's room-scheduling system if scheduling is in scope. For each interface, name an owner on both sides, the data exchanged, direction, frequency, format, error behavior, and security constraints. The two-entity diagram hides these dependencies, which is why the vendor can claim interfaces are excluded while the university assumes they are included. The boundary must be agreed before the fixed-price proposal is treated as complete.
2. Three assumptions are unlabeled. How should the team classify, validate, and document them, and what happens if each is false?
Read the worked answer
An assumption is a statement accepted as true without evidence; it must be documented with an owner, validation action, and consequence if false. For the SAML assumption, classify it as a technical integration assumption, validate it with the identity provider's technical contact or metadata, and if false (for example, only OIDC or a custom protocol is supported), the authentication design and estimate change. For the government reporting format stability, classify it as an external regulatory assumption; validate against the published specification and the reporting agency's change schedule; if false, mapping, testing, and possibly the release date change. For legacy retirement in phase 1, classify it as a scope and migration assumption; validate with the legacy owner and the migration plan; if false, the system needs coexistence, data synchronization, and dual-running requirements. Record each in an assumptions register with date, owner, validation method, status, and impact. Also state the assumption explicitly in the requirements document and trace it to affected requirements. Unlabeled assumptions become hidden change requests; labeled ones become managed risks.
3. The vendor's fixed-price proposal excludes 'third-party interfaces.' What requirements engineering actions should the university take before signing or before the next change board?
Read the worked answer
Before signing, convert the vague phrase into an explicit interface scope. Produce an interface catalog for each external system: name, owner, purpose, data entities, direction, protocol, frequency, volume, security, error handling, and acceptance criteria. Mark each as in scope, out of scope, or university responsibility. Add a context diagram and interface requirements to the requirements baseline. Then ask the vendor to price the in-scope interfaces explicitly or state the assumption that they are excluded; either way, the contract boundary becomes visible. If signing is imminent, a letter of clarification or a contract addendum listing the interfaces is safer than relying on meeting notes. For the next change board, present the boundary decision, the cost and schedule impact of each interface, and the risk of late discovery. The requirements engineering objective is not to win a contract argument; it is to ensure that 'standard enrollment functionality' and 'third-party interfaces' cannot mean different things to the two parties. Trace each interface to a requirement and a test so acceptance is not ambiguous.