It sounds like you have pretty good handle on the features and business rules given where you started. My main piece of advice is to map the features and business rules back to a requirement. All features originate from a need. Feature conflicts arise when a feature conflicts with a requirement or when it isn't the best way to satisfy that requirement.
This process doesn't have to be too fancy or complex. I would take a somewhat agile approach to start. Create 1-3 sentence user stories representing each requirement. Then map each feature to one or more user stories. And of course features can also have sub-features (your fishbone diagram). I've written about a common method for creating user stories in our interview questions.
Using this technique, you capture the requirement in 1-3 sentences and then you document the acceptance tests on the back of the "card". The back of the card is also a great place to capture specific business rules too! Of course, here I'm discussing physical index cards for the sake of an example, but you can represent all of this in a database with fields for each or in a word document.
The main takeaway...map to requirements. Hope this helps.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: