Use case and Functional requirements
How do you deal with the relationship between use case and functional requirements? do you repeat the system funciton in functional requiremetns section with more details or just leave the system functions in the use case description?
for example, in use case it says:
user selects account type
system presents a list of transactions
appreciate it if you could shed some light
Regards,
Simon

Use Cases, Functional Requirements, and Interaction Design
Roger, I have to disagree with you on two seperate issues:
1. Use cases are not (necessarily) interaction design.
2. Interaction design is a functional requirement.
First of all, an "essential" use case doesn't include any "interaction design" other than necessary to actually describe the requirement. To use your example, an essential use case for purchasing an item would look like:
1. Customer selects items to purchase.
2. System calculates total cost of purchase.
3. Customer provides payment.
4. System records payment.
5. System issues reciept.
Note that this use case says nothing about interaction design other than what is, in fact, absolutely necessary to buy something. I could probably flesh it out in more detail and still not say anything about the UI or what is being interacted with, and I'd still contend that this use case has value.
I'd also contend that most of the steps performed by the system in the essential use case are in fact functional requirements.
2. I think it's fair to say that interaction design may well be a functional requirement. Functional requirements are generally defined as the behaviour that a system needs to have in order to meet a customer need. There are a lot of cases I can think of where the UI can fall into that category.
I know you personally feel that requirements should be as broadly defined as it's possible for them to be, but I don't think that's appropriate for all circumstances. You're coming at this from the perspective of a product manager, with the goal of coming up with a solution that will stand out in the marketplace. From that perspective, it's reasonable to take the requirement as far back as you possibly can in order to ensure that you consider the widest range of possible solutions.
However, my experience is somewhat different--I've always been a BA working in a corporate environment, trying to juggle multiple stakeholders with competing needs and deal with development teams who typically don't have a deep understanding of the business. In general, I'm also enhancing existing capabilities rather than trying to create something new from scratch.
Because of this, I have a need to ensure that all stakeholders are in agreement, that there is a shared understanding of what is to be built, and that we know what impact the proposed solution will have on the daily work of users. From my perspective, anything visible to the users is a requirement.
---------------------------------------
Kevin Brennan, PMP
Sr. Consultant, blue sands Inc.
Vice-President, Body of Knowledge, IIBA