Tuesday, May 29, 2007

Name: Prioritizing Use CasesType: PrinciplesStatus: finalVersion 2007-08-23Gist: using a smart way of finding out the use cases to start withNote: 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 caseP2: 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 processP5: the use cases yields high business valueP6: the use cases yields high ratio of business value to costsP7: there is a business related dependency to another use case wich uses the business results of the firstP8: 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 processP9: the team can gain knowledge (about the domain, the project, the product) from implementing a use case

Name: Finding key stakeholdersType: ProcessStatus: DraftVersion: 2007-05-24Gist: How to find the stakeholders who should be treated special.

S1: Brainstorm all possible stakeholdersS2: 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.

Name:Principles of Modelling Static OO-ModelsType: PrinciplesStatus: DraftVersion 2007-05-24Gist: 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 nameP5: Loosely couple non-cohesive partsP6: Every class, every association and every generalization has a business requirement that makes it necessaryNote: 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)

Name: Finding the right size for a use caseType: RulesStatus: finishedVersion: 2008-03-28Source: www.oose.deGist: find out whether a given system use case isn't too large and not too small.

R1: Each use case has a business triggerR2: Each use case yields an externally observable result that is useful for the businessR3: Each use case is coherent by timeNote: 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.

Name:BUFR (big up-front requirements)Type: PrinciplesStatus: FinalVersion: 2008-03-27Gist: 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

Wednesday, May 23, 2007

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 estimatedR3: 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.

Name: Naming Use CasesType: RulesStatus: DraftVersion 2007-05-23Gist: 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"

Gist: support the concept of user personas for requirements definition and for getting rid of the elastic userNote: 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 themR5: 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)

"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."

Name: How to Determine if a Requirement is AtomicType: RulesStatus: finishedVersion: 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.

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.

Friday, May 04, 2007

R1: The Capers Jones Formula for Effort E of new Products (in person months): E = (# Adjusted Function Points)^1,4 / 150R2: 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.