Hi BR,
Your question is central to how we work as BA's I wrote the following on another post a while back and I've copied it below. There are a number of things you need to do to define a system. What you do will vary with each system. From your question I can see that you've probably learnt a whole lot of techniques and are struggling to know how to put them together to define your system.
This is what I do. Like I said, each system is different and I may only do a subset of this or occasionally add other things.
Kimbo
Business Level
1. Textual requirements (the system shall... type statements)
2. Business process
3. Business use cases
4. Business rules
5. Business domain (main business clases e.g. notification in your example)
6. Non-functional requirements
In an ideal world you get the textual requirements right first and then use the business process to determine the business use cases. Note: there is no definition of screens etc at this point. Business level is the BRD. The business rules are created at the same time as everything else. Put them in a separate document if you wish but cross reference them to the use cases where they apply
Design Level
This is where you define:
1. Screens
2. Reports
3. Data
4. Validation rules
5. Other programs e.g. the one that sends the notifications
6. etc
This should be at sufficient detail for you to give it to a developer. A good developer will probably be able to code from this (also using the companion architecture document developed by your solution architects)
Lots of people seem to use use cases to define screens but I personally think there are more efficient ways. Use cases are not designed for this purpose. I create a prototype layout, define all the fields and where they are loaded from, actions, validation rules, etc. Similarly for reports I do a layout and define the way the report is organised e.g. sections, sub headings, sorting; and where the data comes from.
This is the FRD.