as we described, The narrative should include a role, a feature and a benefit

“As a [role]
I want [feature]
so that [benefit]”

This template has a number of advantages.
By specifying the role within the narrative, you know who to talk to about the feature.
By specifying the benefit, you cause the story writer to consider why they want a feature.
It gets interesting if you find the feature won’t actually deliver the benefit attributed to it.
This usually means you have a missing story.
if there is one story with the current feature, which delivers a different benefit (and is therefore still useful), then there is a hidden story whereby you will need a different feature to deliver the benefit described.

The scenario title should say what’s different- You should be able to line up the scenarios side by side, and describe how they differ using only the title. It should be obvious from the title whether this is the scenario you care about, compared to the others.

The scenario should be described in terms of Givens, Events and Outcomes
This is the single most powerful behavioral shift in the adopting BDD process.
Simply by getting the business users, the analysts, the testers and the developers to adopt this vocabulary of “given/when/then”, they discover that a world of ambiguity falls away.
Not all scenarios are this simple.
Some are best represented as a sequence of events, described as:

given [some context]
 when [I do something]
then [this happens]
when [I do another thing]
then [this new thing happens]

And so on.

An example is a wizard-style website, where you step through a sequence of screens to build up a complex data model.
It is perfectly appropriate to intermingle sequences of events and outcomes, as long as you get into the habit of thinking in these terms.
One interesting emergent behavior is that the quality of the conversation changes.
You will quickly discover that you have missed out an assumed given, or forgotten to verify an outcome.
By introducing the given/when/then vocabulary, we can dramatically improve the quality of the group interaction.

The givens should define all of, and no more than, the required context:
Any additional givens are distracting, which makes it hard for someone looking at the story for the first time – whether from the technical or business side – to understand what they need to know.
Similarly any missing givens are really assumptions. If you can get a different outcome from the givens provided, then there must be something missing.

The event should describe the feature :
The event itself should be very simple, typically only a single call into the production code. As discussed above, some scenarios are more complicated than this, but mostly the scenarios for a story will revolve around a single event. They will differ only in the context (the givens) and the corresponding expected outcomes.

The story should be small enough to fit in an iteration :
There are no hard and fast rules about how you do this, as long as you break it down into demonstrable chunks.
In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together.
 

When we need to understand what a computer system is supposed to do so that it can best serve some business need, questions like:
• What is the most important thing the system should do?
• What is the next most important thing the system doesn't yet do?
• If we were to switch off the system, where and what would be the biggest impact?

These Powerful questions can be tough to answer.
But following these will guide us to insights that we hadn't though of.

the Acceptance Criteria consist of a collection of Scenario allow us to determine when we are done, The most important aspect of a story is the language in which it is written.
The golden rule is that the Story should be written in the language of the Role, that is to say the beneficiary of the feature.
If the Story represents a business feature, it should be written in business terms with the aid of a business analyst.
If the story describes a technical requirement, such as resilience or scalability (sometimes called “non-functional” requirements), it should be presented in the appropriate technical language.
Acceptance Criteria specify, as a collection of Scenario, what needs to be achieved if the Behavior of the Feature is to be considered finished.

A Scenario:
Some Behavior that can be automatically verified once the Story (or some part of it) is delivered.
The Scenario sets up the world in a known state (or in a way that will behave deterministically) and executes a sequence of one or more Events resulting in one or more verifiable Outcomes.
We commonly implement these scenarios, as FIT fixtures, Selenium tests or programmatically as code, but the technology is less important than the concept here, the aim of these verifiable scenarios is to define what a successful outcome looks like.

This use of Scenarios gives us two immediate returns.

• They form the basis for our estimates, leading to more consistent estimates than story-level estimations.
• They show when a story is trying to do “too much”.
  If there are more than a handful of scenarios (five or six), it suggests that the story should be split into several smaller stories, each providing independent benefit, and each consisting of a subset of the scenarios.
  Boundary or exception cases are good examples of this: sets of boundary scenarios might clump together to describe common business cases, and some of these clusters will be deemed more important than others. Smaller stories means finer-grained control over prioritization, finer grained visibility of progress and reduced exposure to technical risk.

Scenario structure:

Scenario 1: Title
Given [context]
And [some more context]…
When  [event]
Then  [outcome]
And [another outcome]…

the nerrative Gives us a brief description of what to deliver,
and why we should deliver it (in the form of Features and Benefits).

we shall define few terms:

A Role:
Is an aspect that describes the person, or thing, that will benefit from the Feature.
It is essentially the same as an Actor in a UseCase.

A Feature:
It describes something that the system should do (the behavior, as it were).
An important aspect of a Feature is that it is described solely in business terms and not in terms of technology or technologists,
unless of course the business is technology or technologists!!

A Benefit:
This is the reason we are delivering a particular Feature– it describes the business value accrued from this Feature.
Initially the Benefit is usually qualitative,
but we usually expect to see some quantitative business value assigned to the Story before it is chosen for development.
This is to help keep us honest and to ensure that we are focusing our development efforts on Features that have real business value.

To ensure that we don't forget any of these critical components we often use a template for the narrative like this:

As a <Role>
I want <Feature>
So that <Benefit>

A concrete example may be something like:

As a Developer
I want to be able to rename classes
So that I don’t spend too much time worrying about getting the name right first time

The reason for this degree of formality is that it helps us avoid some common analysis anti-patterns.

Two in particular are worth mentioning: 

• Feature = Benefit.
  This is where the “benefit” is simply a restatement of the feature, this is a common failing in technical or semi-technical customers,
  who wish to promote a particular technical solution.
  These requirements can often be (diplomatically) eliminated, reducing complexity, risk and the associated cost.
• Feature ≠> Benefit. (“Feature does not imply benefit”)
  The feature described will not deliver the benefit described.
  When this occurs it often reveals hidden requirements.
  It may be that the Feature delivers a completely different benefit which we hadn't identified.
  Conversely, we may need to introduce some new Feature to actually achieve the specified Benefit,
  a previously hidden, and thus unplanned, feature.

if you haven't read the introduction yet, please read the introduction to BDD

What is this story all about ?
The idea is that the words you use influence the way you think about something.
To smooth its path through the development process, We say that it must fulfill certain additional criteria.

A story should have a Title, a Narrative and AcceptanceCriteria:

Title:

Gives us a label to describe this piece of function throughout the life of the project.
It is important to choose good titles to describe the story,
Since the story is an atom of development and as such is referred to in all sorts of conversations throughout the life of the project.

Poor titles for stories are things like: 
   • Implement Performance Enhancements 
   • Move Data 
   • Create Persistence Layer

Titles should describe the story in business terms, and should make sense when,
For example, considered as a unit of value for the system.

Some examples of better titles may be: 
   • Accept Credit Card Payment 
   • Confirm Exchange Rate 
   • Accept Product Updates

The last two weeks I'm doing a deep dive into development automation process, which should save allot of time.
a big part of a development process is testing, and as of that many methodologies emerged such as TDD(Test driven development) and so.
The main purpose of these test driven methodologies is to produce a better quality code by creating a set of tests and then write a testable code.

What is BDD?
Behavior-driven development (BDD) is an evolution of test-driven development (TDD) and acceptance-test driven design,
and is intended to make these practices more accessible and intuitive to newcomers and experts alike.
It shifts the vocabulary from being test-based to behavior-based, and positions itself as a design philosophy.

let me explain it in a more explicit way:
as a newcomer to the TDD like process, I found myself asking questions like :
How vastly my tests should me?
Where do I start?
How do i integrate the TDD process with the rest of the development process?
How to write a testable code?
What would be the impact of it?
How do I justify it to the stakeholders?

often stakeholders aren't eager for process changes especially if they are unfamiliar with the new techniques,
cons seems to be having a greater impact on a decision process rather than the major advantages, even if they are insignificant comparing to the advantages.

In what way does the BDD elevate the TDD process?
To answer that question, let's put aside the code writing and the testing process and focus on the entire development process.
Often technical person and a business person speak in "different languages", even analysts and developers sometimes suffer from misunderstandings.
Behavior driven development is a technique that designed to eliminate ambiguity and miscommunication between people on different roles.

this technique comes to solve one basic thing : how do i write a process requirement in a way that would be understandable to all the development personnel, and ensure that the implementation covers the requirements.

To answer the question "where do I start?" ask yourself "what is the next most important thing that the system does not do?"
This question should get you started.

Lets define our requirements in the following template :
As a [role]
I want [Feature]
So that [Benefit].

Defining requirment in this way answers a few important questions:

• Who is the stakeholder for the given request (this is the person that should care about the wanted feature)
• What is the needed functionality?
• What would be the benefit from this specific feature?

Note that when these specific questions answered, you can see which features are more important (and which are not relevant at all).
this way interaction with all the development related personnel will be in "the same language".

Developing scenarios that could happen due to given requirement!
i find the word "scenarios" or even "specifications" more pleasant than "Test" for some reason,
no matter how you look at it, success of these "scenarios", which are situations or a set of rules that must be handled in a specific way, are viable to the success of your project/product/feature development.

Ok, this is all great, but how all this relates to TDD ?
glad you asked this question, i see it in a very simple way:
If the system fulfills all the acceptance criteria, it's behaving correctly.

To summarize all this,
i would say that BDD is a way to produce an idea for a requirement into an implemented, tested production ready code.

stay tuned for the second part about writing scenarios, development tools and more.