How to Create Business Requirements
Business requirements are often times confused with use cases. Although the two are used interchangeably and often times successfully, the best business requirements will be based upon a separate use case document. Utilizing these two tools on a project deliverable will almost assure success.
Other People Are Reading
Instructions
-
-
1
Review your use case document. If you do not have a use case document, you will need to meet with each end-user of the system, the business area leader and the administrators in IT to capture the functionality and then the system specifications. Without use cases, your requirements are almost guaranteed to not be 100 percent complete the first round.
-
2
Transcribe each step of your use case into a specific business requirement. You are now taking the functionality and describing not only how it works, but what has to happen to make it work. For example, your use case will state that the order processing employee will click the "Order Complete" button. The corresponding business requirement will state that when the "Order Complete" trigger is activated, the system will populate the order fulfillment tables with the customer name, ID and products ordered.
-
-
3
Complete the functional requirements and then list all the database, servers and software systems that are involved in the process. You need not go into detail at this point, of what specific components of each of these systems are involved in the process. That will come later in your software requirements specification (SRS) documentation.
-
4
Complete the business requirements document listing other items that are not necessarily requirements, but have a direct impact on the particular process. These items include the people involved in the process (their name, description and title), what role or function they do in this process, and then rank each requirement with a priority and leave room for any questions that come up in regard to that particular requirement.
-
5
List the business rules within the requirements document. There are some requirements that may seem like they do not belong or can be scrapped. There may be legitimate reasons to keep these requirements in place. These reasons are collectively known as the business rules. These rules should be cataloged with the date identified, given an ID, title and description, who has authority over the rule and what part it plays in the current process. This allows for requirements to be reconsidered and who to contact for ultimate approval.
-
1
Tips & Warnings
Each requirement must have a unique ID to facilitate traceability from the testing phase and back.
Each requirement must describe a particular piece of functionality or process.
Each requirement must be unambiguous.
Each requirement must be written at a level that anyone can pick up and understand. Do not use overly technical or industry specific jargon.
Each requirement must be specific in what it describes.
Do not forget to get sign off from the project manager and sponsor after you have captured all of the requirements. At some point, they will need to be locked down and any new ones will need to become part of a later release.
