A public library board requires visitor BYOD Internet with an acceptable-use captive portal and bandwidth limits so research PCs stay usable. Where should those needs be captured?
Select an answer to reveal the explanation.
Short Explanation
Guest Wi-Fi policy is a design input, not a tweet after launch. Spell out captive portal and bandwidth limits in the specs so the library's research PCs are not starved on opening day.
Full Explanation
Guest and BYOD policy controls belong in the WLAN specifications, not in a post-go-live social post. When a public library board requires visitor BYOD Internet with an acceptable-use captive portal and bandwidth limits so research PCs stay usable, those needs should be captured in the WLAN specifications as guest/BYOD technical and policy requirements, including captive portal and bandwidth controls. Specs drive SSID design, captive platform choice, and rate limiting before install begins.
Capturing needs only in a social-media announcement after go-live fails by concept: late announcements do not engineer portal or rate controls. Treating them solely as an RF heatmap goal with no portal or policy detail fails by concept: RF coverage does not implement acceptable use or bandwidth fairness. Instructing an open guest SSID with no rate limits fails by concept: that contradicts the board's portal and fairness requirements.
Exam caveat: CWNE requirements gathering includes guest policy and technical controls as first-class specification content for civic Wi-Fi.
Operational check: Write captive-portal AUP, authentication or redirect behavior, and bandwidth-limit requirements into the library WLAN spec, verify them in acceptance tests with concurrent BYOD load, and protect research-PC capacity.