Chapter 3: From Capabilities to Requirements
Marcus had been looking forward to the first solution design workshop for the student advising platform. Ravi's team had done their homework. The design was technically elegant: self-service appointment booking, appointment history, SIS integration. Then Marcus asked the question that changed the direction of the initiative: "Where is the relationship?" The architecture had identified the advisor-student relationship as the capability gap, not scheduling. Students could already book appointments. The requirements document had asked for a scheduling system, and a scheduling system was what the team built. This chapter is about the gap between what the architecture intends and what the requirements document says, the most dangerous gap in the journey from strategy to solution, because it is where strategic intent most reliably disappears. You will learn to trace the requirements hierarchy, draft a business use case that carries the "why" the specification cannot, and verify that the handoff preserved the purpose the design intended.
What You'll Be Able To Do
By the end of this chapter, you'll be able to:
- Trace exactly where in the requirements handoff strategic intent is most likely to disappear, and intervene before it does.
- Write a business use case that carries the "why" behind a capability gap to the solution team, in terms they can act on.
- Compare a set of solution requirements against the originating architecture and identify where the specification was met but the purpose was lost.
Sign In to Access This Course
Create a free account to access Shaping What Gets Built and start learning.