Steps and principles in requirement specification

Principles:

• Vision - share the same vision
• Users - must participate
• Work practice - must be experienced
• Anchor - desicions

4 phases:

• Creation - of project
• Strategy - to implement
• Depth - to dig for needs
• Vision - to renew

6 elements of a decision-process:

• It is a generic problem and can only be solved by establishing a rule, a principle
• What are the boundary conditions, which must be satisfied
• What is right (not just acceptable)
• What compromises must be made
• What action must be taken to carry it out
• What feedback can test the validity of the decision

These are just some reminders of important artefacts during requirements digging.

User centric development

"All a computer can handle are abstractions. And abstractions can be relied on only if they are constantly checked against the concrete. Otherwise, they are certain to fail", Peter F. Drucker.

I think this quote says all about why you should constantly research the user.

Kafka - TDD - And a course in TDD with Roy Osherove

I just finished a 3-day TDD course with Roy Osherove. Here are some of my lessons.

"The right understanding of any matter and a misunderstanding of the same matter do not wholly exclude each other", Kafka. That is one of the ultimate issues with software development, and TDD helps addressing it. How?

The simple rules for TDD are:

1. Write a test that fails.
2. Make the test pass.
3. Refactor.

By following these rules I will also do:

• Investigate the problem domain, but not more than necessary, and make sure the assumptions are right.
• Implement code that works.
• Implement the right code.
• Start with a simple thing, that can be finished within short time, at least within a sprint.
• The development cycle will have small incremental changes, rather than larger code chunks which is harder to test.
• Decide when to do state-based testing and when to do interaction-testing.
• Do test reviews.

Other things I will do:

• Address legacy code with TDD.
• Consider not doing TDD, but right now TDD feels simpler than not doing TDD. Even though TDD is hard.
• Separate unit tests and integration tests.
• Do pair programming.
• Write more integration tests.
• Start learning code contracts (C# 4.0).
• Start learning specification by example and write acceptance tests.
• When I have made a new system, or learned a legacy system, I will make a video describing it
• Write down the coding conventions.

Other things I learned from Roy:

• How to learn things, and what ravines and plateaus are. (This is a part I feel need even more investigation, but not now.)
• Go mouse-less.
• Do coding katas for training. (I have already been doing this after the course, and will continue).

So TDD addresses the understanding/misunderstanding of issues by forcing you to make assumptions and implement the right code. Make it your choice to do it!

Before the TDD-course with Roy Osherove (10.08.2011)

I have done some TDD, but I am not satisfied with the experience so here are some questions and confusion I have before starting the course:

• TDD and state based testing using stubs -
  How can I write the test first if I don't know something about the data being worked on?
  So you should prototype before writing tests?
  But what about TDD then?
  Wouldn't it be better to model up some domain first?
  Then you might get better off writing an acceptance test first, using an example provided by some business specialist?
  
  
• Why do I ever need Mocks? -
  I can write acceptance tests or integration tests instead?
  Can interaction testing be replaced by code contracts in C# 4? - There is a new concept "Code Contracts" which let you apply pre conditions, post conditions, assertions and invariants. This lets you express requirements and promises between APIs. The contracts can be used to check your code for correctness at compile time.
  
  
• Why would I use mocks to verify multiple method calls?
  ....if I do not know what data and objects these method calls would return?
  
  
• Arrange, Act Assert is the same pattern used in acceptance tests? E.g. -
  Given, When, Then
  As a "user", I want "something", so that "benefit"
  
  
• Regarding bugs: Write a test that fails, then change the code to get the test to pass? -
  Hard to do in a legacy world?
  
  
• Refactor before introducing tests in legacy code systems?
  
  
• How to handle large amount of test data?
  
  
• How to handle tests and changing requirements?
  Especially during project start up when requirements are not "set"?
  
  
• Using IOC to get stubs?

I hope Roy can clarify and guide me into being a better developer!

From The Code Alpinist