6 Ways to Propagate Non-Functional Requirements

Name: 6 Ways to Propagate Non-Functional Requirements
Type: Rules
Status: final
Version: 2008-05-30

Gist: Most BAs and a lot of other project people would immediatly agree to "nonfunctional requirements (NFR) are important in almost any software development." However, most often these people also would agree to sentences like "but it is hard to do", "we have a special sitiuation here, we can't do it", "I haven't managed to convince the others", or the exceptionally honest "I don't really know where to start", or "Why should we invest in NFRs?". I want to show how to convince others to REALLY do nonfunctional requirements, and how to REALLY start with it yourself, if that is your concern.

R1: Don't do it alone. At least get some like-minded chap to talk to regularly. Who are the opinion leaders? Who are early / quick adopters in your area? Does it help to get somebody elso on board? How about somebody from higher up the food chain? From my own experience I'd say it's likely that you know what goes wrong and what to do about it, but that someone else is better at marketing ideas.
Note: I saw people hype an unimpressive topic so much that everybody started talking about it. (I'm not talking about 'offshoring' or 'SOA' here, but smaller, company-internal things.) However, there is a certain risk you then cannot control it anymore :-)

R2: Use all available official means, e. g corporate idea management, any SPI programme, your regular talk with your superior, the chair you own on any related board. Which department is responsible?
Note: You don't want to fight department borders here, especially in large organizations. Maybe it's better to get a job at this other department.

R3: Get outside help. "A Prophet Hath No Honour in His Own Country". Maybe some external expert can spark the fire within your organization. These people specialize in quick conviction! Get them in and find a way to make more senior management listen to them.
Note: I could recommend the Gilb family, but that would be surreptitious advertising. However, Tom Gilb's book 'Competitive Engineering' is full of examples, his website full of papers that could help you out.

R4: Do baby steps (ok, that one shows up in nearly all how to-guides nowadays). Can you "just do a pilot" on some project? Or start with a few requirements you really feel comfortable about. Advance with the one most commonly used, like customer satisfaction, availability, maintainability.
Note: While there are good maintainability metrics to apply on systems, it seems nobody can show a measurable relationship between these metrics and, say, the future cost of maintenance. Maybe that is because the metrics focus on the code too much (analyzability), and maintenance has to be seen as a more holistic process.

R5: Let (bad) examples speak for you. Where are the bad examples? I'm sure you will find some quickly. Can you show missing or bad NFRs being a root cause for some problem? Does anyone else think so (see R1)? Really get into a few examples so you know them inside-out.

Note: I suggest you use examples that show that it does not help the user a single bit if these requirements are met. Example: Some detailed requirement saying it should take x seconds from the button-click until something is persistenty saved. I bet the user is not really interested in saving in 8 out of 10 cases. He cares about the time he needs to accomplish some task greater than saving, or about some way to reuse work.

R6: Talk about it. Once you started your endeavor to push NFRs, maybe with a pilot, make a public commitment towards your goal and keep updating an audience about your progress. Talk about your proceedings at the coffee machine, in the cafeteria or the casino, in order to keep you focused and the audience listening.

How to Personally Get the Most Out of Finished Projects

Name: How to Personally Get the Most Out of Finished Projects
Type: Process
Status: final
Version: 2008-05-19

Gist: Dustin Wax wrote an awesome article at the Lifehack web log. Topic: Getting Past Done: What to Do After You've Finished a Big Project
As it is significantly more stuff than fluff I will essentially post a link only, for once. However, you might like the following definition.

reflective thinking DEFINED AS active, persistent, and careful consideration of any belief or supposed form of knowledge in the light of the grounds that support it and the further conclusions to which it tends [that] includes a conscious and voluntary effort to establish belief upon a firm basis of evidence and rationality <- Dewey, J. 1933. How We Think: A Restatement of the Relation of Reflective Thinking to the Educative Process. Lexington, MA: Heath.

S1: Read: Getting Past Done: What to Do After You've Finished a Big Project <http://www.lifehack.org/articles/productivity/getting-past-done-what-to-do-after-youve-finished-a-big-project.html> and extract the questions.

S2: Answer the questions in a quiet moment. You could also use them for a guideline in a lessons learned meeting.
Note: Reflection is method of learning with scientific proof of its effectiveness.

S3: Prepare a checklist for future use on finished projects (or link here).

8 Useful Tips to Pick an Analyst

Name: 8 Useful Tips to Pick an Analyst
Type: Rules
Status: final
Version: 2008-05-16

Gist: Every now and then I run into the task to pick a business analyst or systems analyst for a project or customer. Sometimes this starts with writing a job offer, sometimes with a colleague asking if I could take part in a job interview with some prospect. What should you look for?

R1: Clarify what tasks the candidate will have. 'Ok, this is a no-brainer

R2: Clarify what the challenge in this particular project or this particular job will be.

R3: Clarify what (analyst-specific) professional skills will be needed, now, and in the future, in this particular job.

R4: Clarify what soft skills will be needed, now, and in the future, in this particular job.

R5: Make sure the candidate knows these things (and has a sound approach to dealing with them):

• Stakeholders seem to change their mind on a regular basis. 'I think they don't, it just looks like a change
  
• Goals are seldom properly understood.
  
• Demand and Supply speak two different sociolects.
  
• Stakeholders (among other people...) have trouble communicating about future, i.e. the benefits, or the system-to-be.
  
• Other team members, including fellow analysts, architects, and QA-folk, deserve proper appreciation.
  
• A problem is a solution to a problem is a solution to... (also see the means-and-ands post)
  
• Many people (the prospect, too? Would be a bad sign for an analyst.) have a well developed answer reflex, so finding out what the problem really is can be quite a challenge.
  
• Any required product quality can be described in a meaningful, quantified way. (Refer to Tom Gilb's extensive and highly useful wokr on the subject.)
  

R6: Clarify what testing skills will be needed. 'An analyst that does not know how to design acceptance criteria?

R7: Look for someone who uses words like 'now and then', 'generally', 'frequently', 'some', 'somewhat', 'arguable', 'among other', 'on the other hand', 'also', 'able', 'allow'.

Note: The language gives you hints on the prospect's experience level. Experts tend to have many answers.

R8: Avoid people who use words like 'steady', 'always', 'every', 'all', 'absolute', 'totally', 'without doubt', 'nothing', 'only', 'entirely', 'without exception', 'must', 'have to'.

Update on Being Agile on Offshore Projects

I updated

Being Agile on Offshore Projects,

with some information advocating NOT to do offshoring. Research shows that team productivity could be doubled if the team is in one room. While this seems like an argument often heard, the point is that there's proof.

Why Managing Too Many Risks is Too Risky

I wrote a guest post over at the Raven's Brain weblog. The topic is 'Heaps of Risks - Why Managing Too Many Risks is Too Risky'.

Risk management is a source of unusual human behavior: euphoria or excessive gambling when risk is underestimated, and panic attacks or depression when we predict that things are riskier than they really are. Both are risks by themselves.
In the post I'll address a risk that is also closely related to human behavior and presents a risk: Overly extensive risk registers, i.e. a list of several dozends of risks for a given project.

Read more

If it feels too troublesome to leave a comment there, why not leave it here?

A year ago in May on Clear Conceptual Thinking

Use cases

• Prioritizing Use Cases
• Finding the right size for a use case
• Naming Use Cases

Stuff

• Finding key Stakeholders
• Principles of Modelling Static OO-Models
• BUFR (big up-front requirements)
• User-Centered Development / Personas
• How to Determine if a Requirement is Atomic
• Change and Software are Twins
• Effort Needed for Product Enhancements
• Testcase Numbers based on Function Points

Calculate / Measure

• Calculating Success
• Estimating ROI
• Changing Requirements with Fixed Price Contracts

Citations

• Hume on Ambiguity
• Eisenhower on Plans

9 Rules for Requirements as Means of Communication

Name: 9 Rules for Requirements as Means of Communication
Type: Rules
Status: final
Version: 2008-05-05

Gist: What are the requirements for? From time to time I run into a project where the business analyst in charge (or requirements manager, or what ever they call him) does not know the answer. These projects do requirements because some governing company rule says they should. To my mind, requirements as all about transferring ideas from one person to another, or one group of people to another group. Here's what a BA should think about concerning communication.

R1) Always identify the readers. Make sure you sort out primary and secondary readership. Go for the group that benefits from the requirements NOW, if in doubt.

R2) Don't forget to ask your primary readers how they want to read requirements. Spoken or written prose, pictures, tables? Do they know UML? What's the common language of all your readers? Go check the SOPHIST's material on language and requirements if 'plain natural language' is the answer to the latter question.

R3) Always check if you can reduce the need to write things down by including people in requirement workshops with your stakeholders.

R4) Challenge arguments like 'we need the requirements after the project's finished, for maintenance'. Will there be an organization maintaining the system? Will they use your requirements?
Note: I know this rule hurts. However, I haven't seen a single specification that is still useful years (or even months) after the project's end, if this spec isn't maintained as well.

R5) Don't overestimate your memory. If you will be on a project for several months you yourself will need some aid for remembering that darn detail.

R6) Adjust your requirements style to what you're specifying. Is your system user interface-heavy? Database-strong? Functions? Constraints? Highly interactive? Real-time? Product family?

R7) Think of it: can the team (of designers, programmers, testers, users) be allowed to ask for the information they need, in contrast to you providing them 'one-size-fits-all' requirements.

R8) make sure everybody understands that perfect communication is not possible. The best thing you can do is speak with everybody a lot. The worst thing you can do is write a specification from beginning to end and throw that piece of paper over the fence (also see BUFR)

R9) You don't need requirements at all? You cannot not communicate! (Watzlawick)