gchuba,

There about as many business analysis documents out there as there are ways to describe them. Are you a member of the IIBA? As a business analyst your big pay-off comes when you deliver the BRD otherwise known as the Business Requirements Document. It is not a single document but rather a collection of all your efforts. The BRD will include all of you requirements and traceability. You've mentioned 'matrix' a couple of times. Since a matrix is just a data array of two or more dimensions it's a really useful way to associate things to each other. I like to use a matrix to associate my stakeholders to the functionality that they require. Stakeholders along the top and abilities (requirements) along the side. You have also mentioned change matrix - by this do you mean an association between a change request and a requirement?

BRD - by outlining to you what is typically put into a Business Requirements Document I hope that I am answering your question.

• Background/History
• Scope and Objectives
• Regulatory Requirements
• Business Level Requirements
  • Strategic
  • Tactical (Interoperability)
  • Operational (Process related mostly)
• Stakeholder/User Analysis (stakeholders define all of their needs)
• User Level Requirements (the abilities that the users need - you can matrix this to the above bullet)
• Functional Level User Requirements (the discrete bits of functions that will make up a user level requirement)
• Non-functional Level User Requirements (generally all the "ilities" of the system from a user's point of view)
• Assumptions/Constraints
• Risks and Dependencies
• Solution Options
• Link to Requirements Traceability Plan
• Link to Change Requests
• Link to Single Source Business Glossary (the nouns and noun-verb phrases of the business)
• Link to Single Source Business Rules (not requirements themselves but linked to them)
• Link to Functional and Non-Functional Specifications and Design
• Link to Business Case/Vision
• Link to Use Case Model if Requirements are being gathered in this way
• Link to Class Model or Logical Model, Physical Model
• Link to State Machine if using object oriented analysis

Hey there

"Change Management" is an ambiguous term in the world projects.

Techncially change management refers broadly to any change activity that faciliates transition from one state to another. 

In my experience this phrase usually means changing business processs or organisational structure, and the change is focused n the impact on the people.  It is often a part of automation, workflow or outsourcing projects.

Change control is also often referred to as change management.  CHange control is where a request is made to a project to change something hey are doing; eg add new features to an IT system being built, or to include the new sales team in the rollout of the CRM systems, etc.  Change control is about applying structured decicion making and analysis to these requests so that projects are able to manage their workload poperly.