Prioritizing Use Cases

Name: Prioritizing Use Cases
Type: Principles
Status: final
Version 2007-08-23
Gist: using a smart way of finding out the use cases to start with
Note: You are not supposed to use all principles at once. Focus on 1-3 principles. Discuss with your sponsor, which principles you should use. Proposal: use 2 principles to find the initial order. Use a third principle to move use cases forth and back in this order.
Note: You may want to replace 'use case' with 'feature'.

P1: a key stakeholder is an actor to the use case
P2: the actor has been determined as 'primary'
P3: the use case's development is particularly risky or it's attainability is uncertain (due to technical or organizational issues, for example)
P4: it is a use cases within a core business process
P5: the use cases yields high business value
P6: the use cases yields high ratio of business value to costs
P7: there is a business related dependency to another use case wich uses the business results of the first
P8: the use case is part of a business process and it makes sense - from a business point of view - to first complete all use cases for this process
P9: the team can gain knowledge (about the domain, the project, the product) from implementing a use case

Finding key stakeholders

Name: Finding key stakeholders
Type: Process
Status: Draft
Version: 2007-05-24
Gist: How to find the stakeholders who should be treated special.

S1: Brainstorm all possible stakeholders
S2: Find the stakeholders who will be the greatest in number.
S3: Determine the 1-5 stakeholders who will impose the highest risk of rejecting the product.
Note: The product may be good, but stakeholders can still make your product development a failure. See this formula.

Principles of Modelling Static OO-Models

Name:Principles of Modelling Static OO-Models
Type: Principles
Status: Draft
Version 2007-05-24
Gist: good practice guidelines in case you want to model the static view of a system, on business level

P1: Only model what you think is really important to say. There are a thousand ways of modelling some part of reality.
P2: Don't put more than 5-9 important elements on a page. Go to a hardware store if you need new wall papers.
P3: Each model should not exceed one physical DIN A4 page (US: letter format; some say DIN A3, which is twice the US letter format). Use multiple models of you really need them.
P4: Model cohesive parts as one unit (class). Parts are cohesive if they are (almost) always together, like user first name and user family name
P5: Loosely couple non-cohesive parts
P6: Every class, every association and every generalization has a business requirement that makes it necessary
Note: Careful here, you have to decide whether you want to model "the world" in general, or with the specific system in mind. Don't mix up things you know about the world with something you need because you have requirements stated for it. If you feel you really need a relationship, go and find that requirement. This is called the art of leaving things out of the model. (<- Guido Zokoll of www.OOSE.de)

P7: Think twice before using aggregation and composition. As Rumbaugh put it, aggregation is a way of saying something about your personal point of view

P8: Think twice before using a generalization if you cannot come up with a discrimminator for it within 30 seconds.
P9: Be extra careful with multiple inheritance.
P10: A lot of <<include>>s are a symptom of functional decomposition (<- Ivar Jacobson)

Finding the right size for a use case

Name: Finding the right size for a use case
Type: Rules
Status: finished
Version: 2008-03-28
Source: www.oose.de
Gist: find out whether a given system use case isn't too large and not too small.

R1: Each use case has a business trigger
R2: Each use case yields an externally observable result that is useful for the business
R3: Each use case is coherent by time
Note: R3 means the use case passes the lunch break test: the primary actor wouldn't take her lunch break while in the middle of the execution of the use case steps.

Calculating Success

Name: Calculating Success
Type: Principles
Status: finished
Version: 2007-05-24
Source: Guido Zokoll, www.oose.de
Gist: how to find out, whether a product is a success.

P1: success = inner quality * stakeholder acceptance
Note: Agile developments specifically adress the stakeholder part of the equation.

Estimating ROI

Name: Estimating ROI
Type: Principles
Owner: RGZ
Status: Draft
Version: 2007-05-24
Gist How to estimate the return of investment for a product/project

P1: If you don't have to express value in dollars and cents there's no sense in expressing costs in dollars and cents. <- Tom DeMarco, "If the value is 'we need it', then costs are irrelevant."

BUFR (big up-front requirements)

Name:BUFR (big up-front requirements)
Type: Principles
Status: Final
Version: 2008-03-27
Gist: How to use the BUFR approach in order to hinder change, to avoid focus on business value, to create thrashing, to facilitate no longer valid requirements and to create high risk.

P1: Try to find, document and analyse all requirements for a non-trivial system development before you do anything else

Changing Requirements with Fixed Price Contracts

Name: Changing Requirements with Fixed Price Contracts
Type: Rules
Status. Finished
Version: 2007-05-23

Gist: A way of changing requirements even if a fixed price contract has beed agreed upon.

R1: The total effort does not change.
R2: The customer has to specify each change to a level of detail which is suitable for being estimated
R3: The supplier estimates the change, yielding an effort of X.
R4: The customer has to exclude not yet developed requirements from the contract with the same value X.
Note: This is based on mutaul trust. If you need an extrodinary complicated or hard to agree to contract, you should probably don't try this.

Naming Use Cases

Name: Naming Use Cases
Type: Rules
Status: Draft
Version 2007-05-23
Gist: Finding a good name for a use case

R1: use the form "<verb> <subject>", e.g. "change reservation"
R2: use <subject> in the correct number (singular/plural): if the actor typically processes several subjects without interruption (due to lunch break, due to end of the day, etc.), then the subject should be in plural. E. g. "insert reports"

User-Centered Development / Personas

Name: User-Centered Development / Personas
Type: Rules
Status: finished
Version: 2007-05-07
Source:
www.disambiguity.com/yes-you-should-be-using-personas/
www.evolt.org/article/Practical_Persona_Creation/4090/56111/index.html

Gist: support the concept of user personas for requirements definition and for getting rid of the elastic user
Note: You can also use your personas {for prioritizing tests, to evaluate new ideas for features, for requirements triage, for writing the user manual] (not a complete list).

R1: User personas should be created to find the "edge cases", use cases that make a difference within the product. Wipe out featuritis with your personas.
R2: Personas should be created with the help of stakeholders.
R3: Don't overdo it (1-3 sentences). Don't define too many (2-6).
R4: You need a complete buy-in on the personas from people who are supposed to use them
R5: Do *some* creative writing when creating personas. Small details matter.
R6: It helps putting a name and a face to the personas. Go out and take photos or cut out magazine pictures.
R7: Group personas as 'primary' (the majority, the most important) and secondary (very different from the primary personas but still very important)

Hume on Ambiguity

Name: Hume on Ambiguity
Type: Citation
Status: finished
Version: 2007-05-04

"From this circumstance alone, that a controversy has been long kept on foot, and remains still undecided, we may presume that there is some ambiguity in the expression, and that the disputants affix different ideas to the terms employed in the controversy."

Source: David Hume, An Enquiry Concerning Human Understanding, Section VIII, Part 1

How to Determine if a Requirement is Atomic

Name: How to Determine if a Requirement is Atomic
Type: Rules
Status: finished
Version: 2007-05-07

Gist: Atomic requirements are a prerequisite for specs of product lines, of concurrent product releases, and of developments, in which requirements are likely to change during one release of the product.

R1: A requirement is likely to be atomic if you cannot say "this requirement is partially implemented".
R2: A requirement is likely to be atomic if it decomposes a higher-level requirement AND you can justify it by saying "if I don't write it like this, the higher-level requirement wouldn't make sense" (not: is incomplete, or is unspecific).

Note: R2 also tests that the requirement isn't specifying a superfluous solution to the higher-level requirement.

Eisenhower on Plans

Name: Eisenhower on Plans
Type: Citation
Status: Draft
Version: 2007-05-07
Source: <?>

"In preparing for battle I have always found that plans are useless, but planning is indispensable." - Dwight D. Eisenhower

Change and Software are Twins

Name: Change and Software are Twins
Type: Principle
Status: finished
Version: 2007-05-07
Source: Tom and Mary Poppendieck, Implementing Lean Software Development, Addison Wesley 2007

From the word 'software' alone can be deducted that this part of an IT system is likely to change. Otherwise it would be implemented in hardware.
Note: Thus, change is nothing that is new, be it due to shorter time-to-market, due to increased market pressure or due to quickly fluctuating stakeholder opinions. It's always been characteristic to software. And that's way the ever popular comparison of designing software systems with architecting a house is not at all appropriate.

Effort Needed for Product Enhancements

Name: Effort Needed for Product Enhancements
Type: RuleSet
Status: finished
Version: 2007-05-04

Gist: Calculate Effort from # of Function Points, for Enhancements

R1: The Capers Jones Formula for Effort E of new Products (in person months): E = (# Adjusted Function Points)^1,4 / 150
R2: Enhancements of products cannot be calculated with the same formula, as you need to take into account that you add complexity to an existing product.
R3: Formula for the needed EnhancementEffort EE for an Enhancement of y function points to a a base product of y function points:
EE = E(x+y) - E(x)
Note: Obviously you need to know y and x. The greater x is, the more significant is the difference between E and EE.

Testcase Numbers based on Function Points

Name: Testcase Numbers based on Function Points
Type: RuleSet
Status: finished
Version: 2007-05-04
Source: Internet, IFPUG-Website, Capers Jones

Gist: Calculate the number of test cases for a reasonably tested product.

R1: # of test cases = (# adjusted function points)^1,2
R2: # of acceptance tests = (# adjusted function points) * 1.2