To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
If I'm understanding the question, it's referring to organizational requirements about the prescribed processes and procedures one must follow when performing any project in that organization. Ordinarily, such types of requirements would be maintained in a central manner for reference by participants on all projects. In this instance, it appears that the audit department is serving such a central role.
It doesn't hurt to note those project process requirements in the project documentation, but I think such note should be very brief and mainly refer back to the central posting. If use of particular project management tools is prescribed, then those tools should be used for capturing and updating relevant information about planned and actual tasks, resources and schedules involved in the business analysis. Statements of work (SOWs) are project management descriptions of the work to be carried out, such as to perform the business analysis and to implement a solution to meet the requirements identified in the business analysis. SOWs typically would not be included in the documents produced by a business analyst.
Typically, the bulk of the requirements a business analyst is charged with identifying relate to the project's content. Hopefully the organization understands that chances of project success are improved dramatically by first adequately identifying the REAL business requirements. Identifying clear quantifiable business objectives is a necessary start. It's important that the objectives be accurate, which too often is not the case and unfortunately is seldom recognized.
Realize that the objectives alone are not the REAL business requirements and are not sufficient for designing a product/system/software solution. Rather, REAL business requirements are business deliverable whats that provide value by achieving the objectives when delivered by a product/system/software solution how.
Such whats include business functionality, business rules and quality factors (which often are referred to, inappropriately I believe, as "nonfunctional") such as usability, security and performance. The whats need to be driven selectively down to further detail where they are sufficiently clear and complete. No matter how far down in detail they go, they continue to be business deliverable whats and never turn into hows. The hows are a response to the whats, which is why it's so important to first identify and detail those business requirements.
|
