When I get the opportunity to do so, my "go to" business analysis framework consists of the established business requirements, the defined user roles, the scenarios and the user stories. Every framework that I decide to embrace has to be malleable, it needs to be able to expand, reduce or pivot to meet the demands of the project. For example, in a classic waterfall setting I may need to product a requirements traceability matrix, design structure documentation, test plans and test cases.
Business Requirement - enterprise strategic objectives
User Role - an individual or group that would use the system in a different way than other users
Scenarios or Task Analysis - the way a user would use the system to obtain objectives
User Stories - a decomposition of a scenario/task in the form of "as a ___, I need ___, so that I can ____"
Function Requirements - the classic "the system shall"
The business requirements are normally a line item that everything needs to be traced it is often considered the strategic objectives or vision of the company. After that we try to figure out a different user roles that will use a product and it's important of these are distinct bit more in detail later on. Normally I do find scenarios and again session just getting people to give me a list of scenario and trying to put them in the order in which is user may encounter them.
Quite often, the details of these components are first crafted in a JAD (joint application design) session.
©2015 Dwayne Wright