Monday, December 24, 2007

December 24, 2007 - Twas the Night before Christmas

Technically it is the extremely early hours at the beginning of the day before Christmas. I've just spent the last several hours wrapping presents with my wife and listening to music. Rather than making a half hearted attempt at writing something intelligent I will simply wish you a Merry Christmas.

"And there were shepherds living out in the fields nearby, keeping watch over their flocks at night. An angel of the Lord appeared to them, and the glory of the Lord shone around them, and they were terrified. But the angel said to them, 'Do not be afraid. I bring you good news of great joy that will be for all the people. Today in the town of David a Savior has been born to you; he is Christ the Lord. This will be a sign to you: You will find a baby wrapped in cloths and lying in a manger.'

Suddenly a great company of the heavenly hosts appeared with the angel, praising God and saying,

'Glory to God in the highest, and on earth peace to men on whom his favor rests.'"

Luke 2:8-14

May you seek that great joy and know true peace.

Merry Christmas from the Cutting's Edge.

Sunday, December 16, 2007

December 17, 2007 - Use Case Diagrams: A PM's View


Last week I attended a class on managing requirements with Use Cases. It was aimed at training business analysts and programmers to use Unified Modeling Language (UML) to understand and communicate business requirements . As a project manager I found it both enlightening and encouraging.
Enlightenment. Bottom line, modeling requirements is the quickest way to work with the end users and agree upon of what the system should be designed and developed to do. Because our focus was requirements, the class used Use Case diagrams as the basis for the training.

The three main components of a Use Case diagrams are the Actors, Use Cases and Scenarios. Actors are represented by stick figures, Use Cases by ovals and Scenarios by text boxes. An Actor is a role played by either humans or other systems that interact with the system being built. A Use Cases is a complete series of events handled by the system to help the actor achieve a goal. Scenarios detail how the Use Case will achieve those goals.

In one of my training sessions I use the eXtreme Insurance company as the basis for the exercises. The company is creating a new system to support the sale of life insurance policies to extreme sports nuts. These policies will be sold by cashiers of D&L Sporting Goods stores. The diagram above details the Purchase Policy use case. Other use cases that would be added to this diagram include Process Claim and Reconcile Transactions.

These quick, graphical representations are developed from information gathered through interviewing the users, observing system usage, researching similar systems and other means. The diagrams are then reviewed with the business to verify understanding, accuracy and completeness of the system. Gaining this clarity early in the process is cheap. Waiting for feedback until a prototype or, even worse, User Acceptance Testing may result in costly rework.
Encouraging. The encouraging part of this class was the way the instructor used Use Cases as a means to establish a requirements baseline and discuss change management. Remember, this was a class designed for analysts and programmers. By moving the discussion to their level, the Project Manager wins powerful allies for managing scope. Analysts can better identify the required functionality and processes, lower future surprises and rework. Programmers start to recognize gold plating as anything that isn’t specified in the use cases. When the business begins to ask for additions or changes, clarification begins with revisiting the diagrams and understanding what is different. Those differences become change requests to be processed by the Project Manager.