There is a simple solution to your problem if you use tags.

First tag you feature file to indicate that a particular feature needs WatiN like that:

Feature: Save Proportion Of Sample Pool Required
  As an <User> 
  I want to <Configure size of the Sample required> 
  so that <I can advise the deployment team of resourcing requirments>.

  @WatiN
  Scenario: Save valid sample size mid range
  Given the user enters 10 as sample size
  When the user selects save
  Then the value is stored

And then decorate the BeforeScenario binding with an attribute that indicates the tag:

[BeforeScenario("WatiN")]
public void BeforeScenario()
{
  ...
}

This BeforeScenario method will then only be called for the features that use WatiN.

Currently (in SpecFlow 1.3) step-definitions are global and cannot be scoped to particular features.

This is by design to have the same behavior as Cucumber.

I asked the same question on the cucumber group:

http://groups.google.com/group/cukes/browse_thread/thread/20cd7e1db0a4bdaf/fd668f7346984df9#fd668f7346984df9

The baseline is, that the language defined by all the feature files should also be global (one global behavior of the whole application). Therefore scoping definitions to features should be avoided. Personally I am not yet fully convinced about this ...

However your problem with starting WatiN only for scenarios that need UI-Integration can be solved in two different ways:

• Tags and tagged hooks: You can tag your scenarios (i.e with @web) and define ina BeforeScenario-Hook that only should run for scenarios with a certain tag (i.e. [BeforeScenario("web")]). See the Selenium integration in our BookShop example: http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs

• We often completely separate scenarios that are bound to the UI and scenarios that are bound to a programmatic API (i.e controller, view-model ...) into different projects. We tried to illustrate this in our BookShop example: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/ .

Check this out (new feature in SpecFlow 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings

I originally assumed that a step file was associated with a particular feature file. Once I realized this was not true it helped me to improve all my SpecFlow code and feature files. The language of my feature files is now less context depended, which has resulted in more reusable step definitions and less code duplication. Now I organize my step files according to general similarities and not according to which feature they are for. As far as I know there is no way to associate a step with a particular feature, but I am not a SpecFlow expert so don t take my word for it.

If you still would like to associate your step files with a particular feature file, just give them similar names. There is no need for it to be forced to only work for that feature even if the step code only makes sense for that feature. This is because even if you happen to create a duplicate step for a different feature, it will detect this as an ambiguous match. The behavior for ambiguous matches can be specified in an App.config file. See http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf for more details the about App.config file. By default ambiguous matches are detected and reported as an error.

[edit]: Actually there is a problem with working this way (having step files associated with feature files in your mind only). The problem comes when you add or modify a .feature file and use the same wording you have used before, and you forget to add a step for it, but you don t notice this because you already created a step for that wording once before, and it was written in a context sensitive manner. Also I am no longer convinced of the usefulness of not associating step files with feature files. I don t think most clients would be very good at writing the specification in a context independent manner. That is not how we normally write or talk or think.

Solution for this is to implement Tags & Scoped Binding with the test scenario which is related to Web or related to Controller / Core logic in code.

And drill down the scope for each scenario to any of the below mentioned Before / After execution

BeforeTestRunScenario 
    BeforeFeature
        BeforeScenario
            BeforeScenarioBlock
                BeforeStep
                AfterStep
            AfterScenarioBlock
        AfterScenario
    AfterFeature
AfterTestRunScenario 

Also consider using implementation-agnostic DSL along with implementation-specific step definitions. For example, use

When I search for Barbados

instead of

`When I type Barbados in the search field and push the Search button

By implementing multiple step definition assemblies, the same Scenario can execute through different interfaces. We use this approach to test UI s, API s, etc. using the same Scenario.