- Be certain to include features that cover the following:
1. Log important information.
2. Conduct business.
3. Analyze business results.
4. Interact with other systems.
Str#6a. "Add Features, Inspired by Patterns" Strategy // identifying purpose and features
- Add features inspired by the stereotypical responsibilities of a participant (in Patt#3, Participant-Transaction), transaction (in Patt#6, Transaction - Transaction Line Item), and place (in Patt#4, Place-Transaction).
- Examples: assess the performance of a participant (how many, how much), calculate the total of a transaction, assess the performance of a place (how many, how much).
Str#6b. "Organize and Prioritize Features" Strategy // identifying purpose and features
- Organize the features into "feature categories" (also known as "use cases").
. Example: maintaining employee info; assigning employees; assessing employee performance
- Prioritize the features.
. Identify the prioritization criteria. For example: normal sequence of business usage; greatest risk; customer interest; management interest; ease of implementation.
Str#7. "Calculation Results and Decision Points" Strategy // identifying purpose and features
- Add features that deliver calculation results.
- Add features that support decision points.
Str#8. "Best and Worst Features" Strategy // identifying purpose and features
- Ask users:
- What are the best features of the current system? Of competitive systems?
- What are the worst problems of the current system? Of competitive systems?
- What are the unneeded features of the current system? Of competitive systems?
Str#9. "Top 10" Strategy // identifying purpose and features
- Build a list of features.
- When you face an abundance of features (or classes, attributes, services), go after the top 10.
- Why: avoid being overwhelmed by a sea of low-level details.
Str#10. "Now and Later" Strategy // identifying purpose and features
- Consider current capabilities--and anticipated future capabilities.
- Ask, "How is it done now? How will it be done later, with the new system?"
- Look at things that people do to objects now, and consider features you can add (your automated objects might be able to do those actions to themselves).
Str#11. "Reengineer on the Boundaries" Strategy // identifying purpose and features
- Look at each organization or automated system boundary.
- Look for duplicate efforts on each side of such a boundary.
- Model the capability one time--and encourage some reengineering improvements for the organization.
Str#12. The "Smarter Devices" Strategy // identifying purpose and features
- Look for opportunities to use smarter devices, simplifying your object model and reducing software development schedule and costs.
- When building an object model in a field with rapidly changing data acquisition and control technology, be sure to take a systems perspective, spanning both hardware and software.
A purpose is an overall desired result, the aim of one's actions. Features are specific capabilities for the system under consideration.
This section presents "purpose and features" strategies.
Str#2. "System Purpose" Strategy // identifying purpose and features
- Develop an overall purpose statement in 25 words or less. Why this system? Why now?
- Keep the overall goal, the critical success factor, always before you.
- "To support, to help, to facilitate, . . ."
Str#3. "Field Trips, Pictures, and Examples" Strategy // identifying purpose and features
- Work with domain experts, ones well-versed in the business.
- Ask for a guided tour; ask for a picture; ask for lots of examples.
Str#3a. "Multiple Learning Sources" Strategy // identifying purpose and features
- Read about it; try out software for it; listen to domain experts!
Str#3b. "Build A Glossary" Strategy // identifying purpose and features
- Are you finding that people terms differently? Perhaps using different words to convey the same meaning? Or giving different meanings to the same word? Not a surprise!
- Recommendation: build a glossary using a three-column spreadsheet (term, dictionary definition, project definition).
Str#4. "Identify Major Sources of Stress" Strategy // identifying purpose and features
- Ask people about the most pressing problems that they face each day. "What stresses you out the most? What frightens you the most? What's the worst thing that could happen to you while your boss is watching?"
- Look for ways to eliminate or reduce the impact of those problems.
Str#5. "Develop a Features List" Strategy // identifying purpose and features
- Build a list of features.
- Think through each feature: the feature, who it's for, and why it's important.
- Use qualifiers to narrow the scope of the purpose and features statements.
- Prioritize your features list.
- Use the features list for planning and building frequent, tangible, working results.
- Rather than philosophize endlessly, invest an hour in each of several different ways of modeling a particularly challenging area. Compare your results -- and decide which way to go (based upon actual results, rather than the outcome of a multiweek debate).
Str#1e. "Consider the Domain First, Artifacts After That" Strategy // activities and model components
- Build an object model with a domain expert first. Then add-in content that you can extract from artifacts (existing data models, source code, whatever).
- Reason why: you need the benefit of the former (fresh insights, new ideas) to help you grapple with the latter (what to include, what to exclude).
Str#1f. "Extract Useful Content From An Existing Data Model" Strategy // activities and model components
- Yes, it can be done.
- Best practice: build an initial object model with a domain expert first. Then use that model to help you filter out the classes and attributes (in an previous data model) that are no longer needed. Why: the added domain understanding will help you do a better job leaving unneeded things behind, rather than dragging everything from the past along with you once again.
- For the entities:
. List them. Delete correlation tables. Delete (or revise) names that do not fit the problem domain vocabulary (words that a domain expert uses and understands). Collapse supertypes-subtypes that do not express domain-based generalization-specialization.
- Then, when you work on attributes:
. List them. Delete (or revise) names that do not fit the problem domain vocabulary (words that a domain expert uses and understands). Delete flags, indicators, sequence numbers, and unique keys -- nearly all of which are simply leftover implementation mechanisms from a previous system.
Str#1. "Four Major Activities, Four Major Components" Strategy // activities and model components
- Organize your work around four major activities, within four major components:
- Four major activities:
. Standard: Identify purpose and features, select objects, establish responsibilities, work out dynamics with scenarios.
. Variation 1: You may find it helpful to focus on working out dynamics with scenarios, establishing responsibilities along the way. This is especially suitable for real-time applications.
. Variation 2: You may find it helpful to select transaction, aggregate, and plan objects, then use the corresponding patterns to guide you through selecting additional objects, establishing responsibilities, and working out dynamics with scenarios.
- Four major components:
. Standard: Problem domain, human interaction, data management, system interaction.
. Variation 1: You may find it helpful to begin with human interaction, followed by problem domain, data management, and system interaction. This is especially suitable when your domain experts want to talk in terms of human interaction from the very start.
. Variation 2: You may find it helpful to begin with problem domain and system interaction, followed by human interaction and data management. This is especially suitable for real-time applications, when your domain experts are keenly interested in the data acquisition and control aspects of the system under consideration.
Str#1a. "Build an Initial Object Model, then Proceed Feature-by-Feature" Strategy // activities and model components
- Here is a very helpful path for building object models.
- Identify purpose and features.
. Purpose statement. Prioritized list of features.
- Build an initial object model, working with domain experts.
. Select initial objects (using strategies; include participants, transactions, places, items, specific items).
. Establish initial responsibilities (using strategy #86 and the stereotypical responsibilities expressed by object-model patterns).
- Work out dynamics with scenarios, feature-by-feature.
a. Develop a scenario view for the feature.
b. Add objects and responsibilities that you need for the scenario.
Str#1b. "Use Feature Milestones" Strategy // activities and model components
- Use your prioritized features list to plan, build, and measure.
- Early in the development effort, use your prioritized features list day-by-day, while developing an initial object model and scenario views (one scenario view for each feature).
- For the rest of the development effort, use your prioritized features list to plan, build, and measure what you produce -- namely, the frequent, tangible, working results.
- Some notes:
. How frequent is "frequent"?
. . Each week, each month, or each quarter -- depends upon the size of the project and the amount of added effort required to make working results available to others.
- Why use features milestones -- and measure features completed, using frequent, tangible, working results?
. In two words: risk reduction.
- How do you estimate percent completion?
. Take the features list, assign a weight to each feature (based upon level of difficulty, relative number of lines of code, and level of skill of the person who will do the work), and then make your estimates.
. Your estimates will improve over time, as you deliver more and more tangible results along the way.
Str#1c. "Take Multiple Paths" Strategy // activities and model components
- For each outcome, consider multiple paths for reaching that goal. Travel down one of those paths. When your progress slows somewhat, move to another path, for awhile.
- "All features, all classes, then the top ten classes"
. features -> classes -> top 10 classes -> responsibilities, scenarios for the top 10
- "One feature at a time"
. feature -> small object model -> scenario view
- "Key players first"
. 1-2 participants + 1-2 transactions + line items, items -> responsibilities, scenarios
- "Key transactions first"
. transaction - subsequent transaction - subsequent transaction -> participants, line items, items -> attributes, services