| Understand that the purpose of the business | | | | requirements meetings |
| requirements document is to ensure that the design | | | | 1. The analyst should summarize the information |
| and development team has a clear and well-defined | | | | gathered at the meeting, prepare a report, and then |
| understanding of the tasks that are going to be | | | | create another question and answer form targeting |
| automated, how those tasks fit into the | | | | the new issues that came to light in the previous |
| organizational context, and who the role players are. | | | | meeting. |
| Ensure that the requirements analyst meets with the | | | | 2. This process should continue until the analyst is |
| major stakeholders in the project for a series of | | | | able to produce a final report that everyone agrees |
| meetings designed to flesh out the requirements of | | | | encompasses all of the business requirements. |
| the system. Subsequent meetings may include | | | | Phase 3: After the business requirements gathering |
| secondary stakeholders and actual end users. This is | | | | phase is completed |
| to make sure that all roles are uncovered and | | | | 1. The analyst prepares the formal business |
| properly documented. | | | | requirements document and presents it to all |
| The business requirements phase of the projects | | | | stakeholders for approval and signoff. |
| consists of these three steps: | | | | 2. If signoff it received, the business analyst's work is |
| Phase 1: Conduct meetings with all stakeholders and | | | | finished unless and until additional requirements are |
| role players. | | | | identified later in the software development cycle. |
| Phase 2: Assimilate all of the information that was | | | | 3. If signoff is not received then it is likely that the |
| gathered at the meetings. | | | | project will go back to Stage 1 for additional business |
| Phase 3: Create the business requirements document. | | | | requirements gathering and analysis. |
| Phase 1: Steps to conducting the business | | | | Because the success of the projects depends upon it |
| requirements meetings | | | | being built to the client's specifications and |
| 1. Prior to the meeting the analyst should create a list | | | | expectations, the business requirements document is |
| of questions that will be asked of each stakeholder | | | | a key deliverable. This stage of the project should |
| and user involved in the business requirements | | | | never be skipped in order to expedite the |
| gathering process. | | | | development cycle. |
| 2. The analyst should note the answers to the | | | | Failure to identify and document all business |
| questions and identify new issues that were not | | | | requirements creates unnecessary project risk that |
| previously identified. | | | | will be very difficult to mitigate later in the software |
| Phase 2: Steps to conducting the business | | | | development project lifecycle. |