Src Cards

I am an eager enthusiast (is that redundant?) of CrcCards as an analysis tool. I am interested in whether anyone has applied the concept to the next level UP (or the next activity PRIOR) to CRC.

Has anyone tried Subsystem-Responsibilities-Collaborators Cards? We have a set of use cases that detail the functionality required for a distributed system. We need to establish more detailed requirements for each of the subsystems so that we can apportion work and get started on more detailed design.

Has anyone attempted to use SrcCards in this manner? Are there any gotchas involved in applying this practice at a higher level of abstraction? Across distributed system boundaries? -- BillBarnett

I've used CrcCards to define the responsibilities of components. It was just like defining classes. The technical details of which things are in which address space, time slice or physical hardware should usually be ignored at the CrcCard level of abstraction. Try it out and see. Cards are cheap. -- EricHodges

Using this approach at an even higher system level is described as Fortress-Ally-Responsibility cards in Software Fortresses: Modelling Enterprise Architectures by Roger Sessions and Janet Van Sickler. The "Fortresses" you are modelling here represent whole applications (or clusters of them) that operate as sort of an atomic unit of processing focus and trust. -- bb

Class-Responsibility-Collaboration, Component-Responsibility-Collaboration, Subsystem-Responsibility-Collaboration, etc... do I smell a pattern? Maybe we should just start calling them XrcCards?? -- MikeSmith

CategoryCrcCards