Guidance for a Standard Software Project Business Analysis

Entry & Exit Criteria Overview Key Tasks Templates

Entry Criteria
Approved Terms of Reference Project Roles Stakeholder Map and Communications Plan Risk Register

Exit Criteria
Approved Business Requirements Document (BRD) Approved Peer Project Analysis Review (PPAR) Updated Stage Sign Off Log

Overview The purpose of the this stage is to define in detail the requirements for the project. The Business Analyst is responsible for meeting with representatives of the business group to establish details of the current business processes and requirements for desired future processes. This information is used as the basis for the Business Requirements Document (BRD). The completed BRD is circulated to project stakeholders as part of the Peer Project Analysis Review (PPAR) before being presented to the Project Sponsor for final sign off. Key Tasks

Hold meetings to gather requirements Produce process maps for current process Produce process maps for future process Draft BRD Circulate completed BRD to stakeholder distribution list and arrange meeting(s) to discuss, where necessary Obtain sign off from project stakeholders Update PPAR template Update Sign Off log

Templates

Business Requirements Document (BRD) What is the purpose of the template? The Business Requirements Document is used to record the business requirements for the project, using both text and process maps created using Visio or Triaster. User Acceptance Testing (UAT) is introduced in the BRD, with sections relating to UAT Strategy and Acceptance Criteria. The Strategy centres around how the UAT will take place e.g. how long will it last, who should be involved, from where test data will be sourced etc. Specific requirements such as business cycles (e.g. month-end) should also be highlighted. The Acceptance Criteria should list the processes impacted by the project, and this criteria will be used to obtain sign off on the closure of UAT. Who is involved? The Business Analyst is responsible for completing this document, with contribution from the project team and business users. Where relevant, contribution could be invited from the Systems Analyst Designer. When should the template be completed? Work on the BRD should be started once the project moves into Business Analysis. Peer Project Analysis Review (PPAR) What is the purpose of the template? Once the BRD has been completed, the Project Manager should circulate the document to project stakeholders inviting comment/sign off by a specified date and the PPAR template should be used to record any feedback. Based on the feedback received the Project Manager should make a decision as to whether a meeting needs to be held to resolve any issues. Once agreement/sign-off has been reached the BRD should be amended and the documents presented to the Project Sponsor for sign-off. Who is involved? The PPAR template is completed by the Project Manager, who is responsible for all communications. When should the template be completed? The completion of the PPAR template and all associated actions should take place at the end of the Business Analysis stage, once the BRD document has been completed.

Realtion between BRD and FRD your role.

After creating my BRD I started working in the FRD which basically was an extension of the BRDs looking at a functional perspective.

I supplemented these fuctional requirements with the use cases and wired frames. After getting the sign off on the FRD we moved on to the elaboration of the project. (Under writer accountants). This marks the completion of the inception phase. (Tools rational requisite pro, Microsoft word) (The business requirement has attribute and based) BRD contains Business requirement document name Business requirement document number Overview of the business Proposed business problem Proposed business position Purpose Business rules Preconditions Post conditions Assumptions Triggers Conclusion

FRD contains

Product description Product functional capabilities User requirements Data flow diagrams are decomposed Logical data flow diagrams Functionality Boundary values

Validations Error messages Concurrent behavior Real time behavior Localization Internalization Installer requirements Installation directory Checking disk space Installer language Progress bars Configuration documents Assumptions Constraints