Here is a sample class diagram. I designed for document management system project. It is very clear simple design.

I hope you like it.

Download Image jpg

Download Visio File vsd

The whiteboard.  The dry eraser.  The multi-color pens.  The overbearing meeting participant.  Those four things often come together when thinking of brainstorming.  It’s a technique among multiple management nexus disciplines and at the heart of agile, business analysis and project management. It can produce great results from a team.

The Business Analysis Body of Knowledge (2nd Edition) addresses it in section 9.3. The Guide to the Project Management Body of Knowledge references brainstorming as the tool and technique, Facilitated Workshops, for Collect Requirements (5.1) and Define Scope (5.2).

Brainstorming is also technique, despite years of coaching and training to improve its effectiveness, that can go easily astray.

An innocent enough brainstorming session can quickly turn into a diatribe from a “power figure” or as easily slip into a real life parody of the television show “The Office“.

When effectively facilitated brainstorming sessions can unleash a wealth of ideas, strategies and enthusiasm for a team.  One approach that helps keep the brainstorming in the positive side is nominal group technique (NGT).  And one little tool that makes NGT work is the ubiquitous post-it note (aka sticky note).   Here are some steps for NGT – we’ll use deciding features for a new Twitter interface as an example:

1. Gather group together – preferably less than 12
2. Distribute 10 post-it notes
3. Keep a supply of extra post-its handy
4. Have participants write their ideas for the new Twitter interface, silently, on their post-it.  One idea per post-it (people often forget the 1 per post-it rule, so gently remind them
5. When everyone has a chance to capture their ideas, call for confirmation that “we’re done”
6. Have each team member read 1 idea at a time and go around the table or room
7. Clarification questions are OK, judgment questions are not
8. Continue going around the room until all post-its have been shared – one at a time
9. When all post-its have been shared, ask “what’s missing”?
10. Gather up the post-its and have the group arrange by topic or association – for example #trending topics, social network plugs, etc.  This leads wonderfully into another technique called affinity diagramming!

Several years ago I shared a series of articles in the Rational Edge for IBM that showcased real life applications of use cases and

8 steps to capture your use cases

incremental development.  Two of those articles focused on replacing a legacy unemployment insurance system. The entire article provides a much more thorough introduction from that example – so take a quick read of that as you have time.

Use cases and scenarios that are created from them, allow for capturing a process flow of a business function.  They’re addressed directly in The Business Analysis Body of Knowledge, 2nd Edition (BABOK© 9.26) and indirectly referenced in The Guide to Project Management Body of Knowledge, 4th Edition (PMBOK© 5.2)

The eight basic steps we used to generate use cases for each business process area are described below.

Step 1: Confirm actors and goals.
Have all actors and their goals been identified?
Which actors can be generalized (combined)?
Which goals are potential use cases?

Step 2: Develop an outline of the use case(s).
For the goals identified as potential use cases, what are the key pieces?
For each outline level, what are key data?
Outline all use cases.
Prioritize the use-case flows.
Decide on a final use-case list (for initial pass).

Step 3: Write a brief description of the use case(s).
What two or three sentences describe all actors and the basic flow?
Generate content first, and worry about wordsmithing later.

Step 4: Detail the basic flow.
What event starts the use case?
How does the use case end?
How does the use case repeat some behavior?
What is the “happy” (best case) path?
There is one and only one basic flow.

Step 5: Detail the alternate flows.
Are there optional situations for the use case?
What might go wrong?
What might not happen?
Which resources might be blocked?
Which alternate flows are special — perhaps nonfunctional — requirements (i.e., they apply to this use case only)?

Step 6: Review the use case(s).
Are there more use cases?
Should some use cases be redefined?
Which ones can be combined?

Step 7: Record pre- and post-conditions.
What was the previous state before this use case comes into play?
What happens once the use case is complete?

Step 8: Develop generalizations for all use cases.
Determine shared content and process for the use cases.
What items have been noted for the glossary or as global business rules?
Who has the most recent and accurate source document?
Where is it located?

Polls, surveys, questionnaires are synonymous terms for the same thing – asking people for their opinion on a topic.  Chapter Nine of the Business Analysis Body of Knowledge (BABOK®), Second Edition includes Surveys and Questionnaires as the 31st technique.

Surveys help teams understand what customers want. They will differ depending on whether they will be administered through telephone, mail, or electronic means. A good survey may be  time-consuming to construct, but a bad survey will only provide misleading data. Points to remember when creating a survey:

• Write questions that are short, simple and clear
• If it’s possible to misunderstand, it will be!
• Avoid leading questions
• Phrase sensitive questions carefully
• Use close-ended rather than open-ended
• Keep alternatives short
• Options should be mutually exclusive and exhaustive
• Have  a cover letter or introduction email or script
• Keep the survey short
• Start with interesting questions
• Sensitive questions should be later in survey (such as age or income range)
• Order questions carefully

Tools such as Survey Monkey allow for a creating  a survey quickly and for reporting real-time results.  Those tools can not overcome bad survey design.  So keep those principles in mind and happy surveying and requirements elicitation!

Problems, issues, bugs, defects, action items, punch list, clean up tables – so many synonymous terms for the same underlying concept – tracking known “stuff” and making sure it gets resolved before a product or service is released.   While risk management concerns the known- unknown, management reserves address unknown  -unknown, problem tracking is smack dab in the middle of the here and now.  It’s real!

As there are multiple ways to describe it, there are also dozens of tools to track it.  Over the course of my delivery I’ve used Defect Tracker, Bugzilla, RUP, Spreadsheets (Lotus, Quattro Pro, Excel), Public Folders (Microsoft), Silk, Mercury Tester, Sharepoint, Quick Place and large flowing legal pads with a thing called a pencil.

While using those tools I’ve found a few simple tips help to keep my and my team’s attention focused.  I use the term “AIR”.  It helps breath some fresh air across this stuff and make sure the mildew does not mire your project down!

1. Create a category for Action Items (issues or problems that have been assigned to a single person with a specific date)
2. Create a category for Issues / Problems (issues or problems that are known and may transcend your current project or change order)
3. Create a category for Risks (issues or problems that have not yet occurred but you’ve deemed may occur).
4. For Action Items and Issues / Problems assign an impact rating if it is not addressed.  The probability is equal to “1″ since it’s a known.  The decision support is how much that issue will impact your project.  Higher impact issues rise up in their priority for fast assignment to an Action Item
5. Keep the AIR up-to-date with any project scheduling tools you might use (Project, Clarity, etc) – a project schedule is a collection of Action Items (aka tasks).
6. Review the most pressing, the top 10 action items, issues/problems and risks with your team regularly.  That could mean reviewing those once a week or, if you’re in the midst of an Extreme Programming or SCRUM or similar Agile approach, every day.
7. Use this to help guide your product and service launches.  Transfer any lingering problems/issues to the operational support team.

Equally at home with Use Case creation, or the earlier generation’s  database analysis,  Data Dictionaries and Glossaries provide a common place to store and retrieve definitions.  They’re used by business and technical roles.  The premise is to understand what is needed for a field of data or an entire table or record of data (aka data set) and let that understanding drive solution delivery .

In Use Case generation they form a close relationship with Business Rules.  Where Business Rules include processing logic – a Glossary Definition is simple expression.  For example the Glossary definition of “Ethnicity” may be referenced by a Business Rule on Equal Employment Opportunity validation and then referenced by multiple Use Cases and Scenarios.  Make sense?

In practice, I’ve seen Glossary definitions evolve into Business Rules and Business Rules trim down to Glossary definition.  The benefit of that swapping is when it’s done with a group of users or customers who then, with the information technology team members, gain a greater understanding of what is involved in their system and how it’s connected!