When you write business and stakeholder requirements in your business analysis, you want to capture the problem or opportunity and explain what has to be done (rather than how you’re going to solve the problem or take advantage of the opportunity).
As the person performing the business analysis, you’re generally the main person capturing the business requirements because you have a unique ability to drill into the real problem or opportunity rather than just gather a solution request (which is why your process is called “elicitation” and not “gathering”). Stakeholders are also involved because they’re the people from whom you elicit.
Business requirements exist at many points in the project, but you create them primarily at the beginning. In documenting the business requirements, include the following information:
Project initiation: This category includes the statement of purpose, objectives, and risks of the project. It should capture what the purpose is, what the objectives are (what would make this project a success?), and what the risks are.
Information needs: You can also call this information the data. It’s the description of the information the business area needs in order to accomplish its business. So long as you stick to what the business is, you’re still eliciting business requirements.
Business processes/activities: These processes are the workflows the business performs to get its work done.
Business rules: These rules are the constraints or conditions that govern how the business makes its decisions. They’re the operating principles of the business.
