Use cases form a technique for specifying functional requirements: use cases are helpful to specify what the system should do. A use case captures a contract with the stakeholders of a system about its behavior. A use case describes the system’s behavior under various conditions, as the system responds to a request from one of the stakeholders, called the primary actor.
A good architect should lead by example, he (or she) should be able to fulfill any of the positions within his team from wiring the network, and configuring the build process to writing the unit tests and running benchmarks. Without a good understanding of the full range of technology an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology.
All too often software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below. More often than not this leads to dissension in the ranks, quickly followed by a revolt by the masses, finally resulting in a software product that doesn't even come close to resembling the original requirements. Every software architect should know how to communicate the goals and objectives of a software project. The key to effective communication is clarity and leadership.