Problem
Generally, we write requirements in use case structure. Use case structure gives us all elements required but by design , it is a vague format which are devised around use case diagrams. Every software professional has its own flavor of writing use cases. Even the sections of use case structure varies person to person.The intrinsic details of the parts of use case specially use case description, preconditions and post conditions etc] are vaguely defined. Writing use cases in clear format is also a skill and that depends upon the person who is responsible for collecting requirements.Use case are still useful in mature kind of organization but it is not so much effective way when we do not want to have upfront big designs. So dilemma here is how to collect the requirements and the new approach should be better than standard use case structures and should be fairly objective.
There is also a second angle to this use case discussion. Requirements have bigger impact on business and cost part of IT projects. Many times, due to not so clear communication between IT vendor and client over the requirements, this cost of lot of rework and hence the cost to client.From client’s viewpoint ,it is difficult to understand use case type of language and there is a chance to miss out or assume requirements/scenarios ,which becomes cost(in terms of money or time) for them afterword. Situation becomes bad in fixed cost projects. I had experienced this bitter pill many times.
Solution
So the solution I am proposing here is , Behavior Driven Development [BDD] kind of requirements collection for even the people who are not practicing BDD. From past few months,I am sort of wandering in TDD,BDD forest. Now I am going ahead with nBehave and Specflow and Gherkin which has changed whole lot of things for me on coding front.
I totally understand that BDD can’t be fully rolled out in some scenarios/in some organizations[no silver bullet!, lack of expertise, no enthusiasm to learn, cost of learning curve and transformation etc] but I am sure that, we can at least move to BDD style of requirement writing which is kind of closer to silver bullet:). See the following example. I had directly taken this example from Dan North's blog. BTW, Dan is pioneer in BDD and I guess, he is the first who coined the term "BDD". He has also compared use case format with BDD style. Here I think, interesting angle from my side is merge both of them to take advantage from both styles of requirements collection.
In BDD, The requirements are collected in story form like:
Title (one line describing the story)
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context] And [some more context]...
When [event]
Then [outcome] And [another outcome]...
Scenario 2: ...
ACTUAL EXAMPLE:
Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed
Scenario 1: Account has sufficient funds
Given the account balance is $100 And the card is valid And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned
Scenario 2: Account has insufficient funds
Given the account balance is $10 And the card is valid And the machine contains enough money
When the Account Holder requests $20
Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be $20 And the card should be returned
Scenario 3: Card has been disabled
Given the card is disabled
When the Account Holder requests $20
Then the ATM should retain the card
And the ATM should say the card has been retained
Scenario 4: The ATM has insufficient funds
...
I think Along with story, if we have mockup/screenshot[off course with Balsamiq mockups! ] of proposed screen and control, data type range chart we used to have with our existing UML format, we can move towards clear requirements.
Benefits
This will benefit in following ways:
- It will help to gain common understanding between client and IT Vendor,about what has been covered as requirements and what has not.
- Client will find easy to go through requirements since requirements are written in very structured fashion and in plain English.
- Organization wide, requirements will be captured in same fashion and we can really estimate based on stories and find how simple or complex the story is based upon no. and complexity of scenarios it had. Hence its really easy for going with statistical process control for estimation.
- Change Requests are dealt with adding/removing/updating the feature/story/scenarios.My observation here is they only change the scenarios. In very rare cases, features or stories are changed.
- Testing team will reap the greater benefits here since they can write these stories as per their understanding and take part in RE process in very active way like finding out the missing/not clear scenarios etc.
- Testing team do not have to write any other test cases, This can serve as live requirements as well as test cases for them.
- Unit Testing for Developers will be easy since now they clearly know what kind of scenarios they have to cover which is bit difficult and time consuming in Use case format.
Let me know your thoughts, specially BDD and UML experts...
Many good points are noted as what should be in story by BDD pioneer Dan north in his post (http://dannorth.net/whats-in-a-story).
It's really refreshing for me to see the BDD light.
