Requirements Template
Transcript: This section describes User and System Interface requirements for the proposed system. There will be links to these Development dociuments. In this section you will identify if any of the requirements are out of scope. For example if you are writing requirements for a multi-phase project, there may be some requirements documented that will not come into play until later but it was important to document them now so that "Final Big Vision" is not lost. This is the section you call out what is in scope NOW. The first step to writing requirements is to perform discovery to learn as much as possible about the source and reason for the request. After you have compiled notes and completed the discovery phase and checked off the items on the checklist, it is time to begin writing the business requirements. Please be sure to begin with the BRD template. Business Requirements Document (BRD) Another very important part of keeping track of the version you are working with in addition to the cover page is the Revision Log. Be sure to update any changes made after the first draft review. Interface Requirements User Acceptance Testing Be sure to include the date and the stakeholders involved. If someone abstains that is counted as approval, only stakeholders against the requirements are documented as such with their reasoning. QA Testing In this section document any assumptions you have made when writing the requirements. For example, you are designing a screen with the assumption that all of its users will be power users. You should document that assumption. This is the section we have been waiting for. In Scope Assumptions In this section you will document the business requirements. Remember, these are the "WHAT" not the how. The last section to be completed on the BRD is the Approval section. This section addresses the functionality desired.What capabilities are expected as a result of this project. Again as with the Business Requirements, focus on "WHAT" functions not "how" they will. Requirements Template System Interface Requirements Cover Page Requirements Scope Business Requirements Unit Testing This section describes the risks that were identified prior to or during the Business Requirements gathering and documentation. Goals/ Objectives/ Benefits Functional Testing Test Plan The BRD This section will be addressed in the Development documents. The link to the documents will be placed in this section for reference for all documentation in one place. This is how the System interacts with o ther systems. These are both WHAT and HOW.. Other Considerations There will be links in these sections to the testing documentation. Risks User Interface Requirements This presentation will review the current BRD template and the steps to complete it. The checklist Project Background The Details This section describes the dependencies between the Application for which these Business Requirements are written and the other existing applications/systems. The first section of the BRD is Project Background. This is where you will use the discovery information you documented. The purpose fo this section is to understand the reason for the request. What is the result the customer / user is looking for and why? What is the problem they are trying to solve? One of the tools to perform discovery and elicit the business requirements is the checklist. Constraints Revision Log Hardware/Software Requirements Constraints are needed so that you restrict the scope to something that is true and manageable. When I say true, I mean that the customer or user can’t come back later saying that you need to add 100 more requirements. An example: The proposed system will only be used by Company X’s employees Replace any section with <Brackets and Blue Text> with the appropriate information. <Purple Text> is updated when submitted for sign off. <Red Text> is updated when any revisions are made after first draft is reviewed. In this section, write an overview of the objective or gaol of the requirements. What is the end product expected to be? Dependencies on Existing Systems Technical Requirements Checklist This is how the USERs interact wiht the system. These are both WHAT and HOW. Discovery Out of Scope Functional Requirements