A city signs a predictive SOW with a vendor for a fixed asset-tracking package. What BA contribution best bridges the contract to delivery?
Select an answer to reveal the explanation.
Short Explanation
The SOW is the contract’s promise; BA turns that promise into checkable requirements so testers and vendors aren’t guessing. Otherwise “asset tracking” stays a vague handshake.
Full Explanation
When a city signs a predictive SOW with a vendor for a fixed asset-tracking package, the BA contribution that best bridges contract to delivery is translating SOW statements into testable requirements the team and vendor can verify. SOW language is commercial commitment; testable requirements make that commitment operable for configuration, verification, and acceptance. Civic asset tracking needs that bridge so auditors can see how contract promises became proven system behavior.
Treating the SOW as unofficial and inventing unrelated features freely fails conceptually because the SOW defines the engagement’s authorized scope boundary. Ignoring the SOW and writing only marketing slogans as requirements fails because slogans are not testable delivery criteria. Delaying all requirements work until the vendor’s warranty period starts fails because warranty is after delivery; requirements must guide build and acceptance before go-live.
Exam caveat: In predictive vendor packages, BA work converts SOW commitments into testable requirements—not slogans, silence, or post-warranty discovery. Operational check: extract SOW commitments for the asset-tracking package into requirements with acceptance tests, obtain agreement with the vendor and city stakeholders, and verify those tests before accepting the package.