{"id":316,"date":"2022-01-26T18:44:41","date_gmt":"2022-01-26T18:44:41","guid":{"rendered":"https:\/\/pressbooks.ulib.csuohio.edu\/project-management-navigating-the-complexity\/?post_type=chapter&p=316"},"modified":"2022-03-11T14:54:33","modified_gmt":"2022-03-11T14:54:33","slug":"4-2-eliciting-requirements","status":"publish","type":"chapter","link":"https:\/\/pressbooks.ulib.csuohio.edu\/project-management-navigating-the-complexity\/chapter\/4-2-eliciting-requirements\/","title":{"rendered":"4.2 Eliciting Requirements"},"content":{"raw":"After all the deliverables are identified, the project manager needs to document all the requirements of the project. While PMBOK Guide 6th Edition refers to this process as \u201cCollect Requirements\u201d, BABOK Guide v3 refers to elicitation[footnote]International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide), version 3.0. Toronto, Ont: International Institute of Business Analysis.[\/footnote]. Elicitation is more than just collecting. As BABOK Guide states \u201cIt is the drawing forth or receiving of information from stakeholders or other sources. It is the main path to discovering requirements and design information, and might involve talking with stakeholders directly, researching topics, experimenting, or simply being handed information.\u201d BABOK Guide defines a requirement as a usable representation of a need. The nature of the representation may be a document (or set of documents) but can vary widely depending on the circumstances.\r\n\r\nThe requirement is defined by the PMI Guide to Business Analysis as \u201ca condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.\u201d The responsibility for defining requirements should be assigned to resources that have sufficient business subject matter expertise and decision-making authority[footnote]Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute.[\/footnote]. Project teams consist of business analysts who are involved in the elicitation of requirements. There may be other job titles that perform business analysis. These titles were enumerated by BABOK Guide as business architect, business systems analyst, data analyst, enterprise analyst, management consultant, process analyst, product manager, product owner, requirements engineer, and systems analyst.\r\n\r\nA project manager must assure that requirements are defined in a way that project activities can be determined and sequenced, and hence, a schedule and budget can be created. As quoted by the Business Analysis for Practitioners: A Practice Guide, \u201cinaccurate requirements gathering\u201d was reported by 37% of organizations as a primary cause of project failure. Poor requirements management practices were identified as the second leading cause of project failure, second only to changing organizational priorities[footnote]Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute.[\/footnote]. Therefore, project managers need to ensure that all the stakeholders have been identified so that requirements can be elicited thoroughly from all of them, and all the expectations and concerns can be addressed.\r\n\r\nA requirement represents something that can be met by a product, service, or process, and can address a need of the business, person, or group of people. A requirement should be independent of the design of the solution that addresses it. A requirement may explain a feature that is to be met by a product or software component. The project\u2019s requirements, defined in the scope management plan, describe what a project is supposed to accomplish and how the project is supposed to be created and implemented. Requirements may include attributes like dimensions, ease of use, color, specific ingredients, and so on.\r\n\r\nWhen a specific type of requirement is under discussion, the term requirement is preceded by a qualifier such as stakeholder, business, or solution. The hierarchical relationship among requirements can be illustrated in Figure 4.1.\r\n
\r\n\r\n[caption id=\"attachment_109\" align=\"aligncenter\" width=\"814\"]\"Figure Figure 4.1: Relationships between Requirements
(Adapted from \u201cRequirements Classification Schema\u201d in \u201cA Guide to the Business Analysis Body of Knowledge\u00ae - BABOK\u00ae guide\u201d, version 3.0)[\/caption]\r\n\r\n<\/div>\r\n
\r\n\r\nAs illustrated in Figure 4.1, business requirements are developed based on the business needs (problems or opportunities) that an organization is striving to find a solution to overcome the problem or exploit the opportunity. As discussed with examples in Chapter 2, objectives should be SMART (Specific, Measurable, Achievable, Relevant, Time-based). Project Managers should also consider this SMART protocol while creating requirements, especially when getting into greater detail about business requirements. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Moving down, as illustrated in Figure 4.1, means that requirements are determined in a hierarchy starting from the business requirement at the top, and elaborating on them with stakeholder requirements, and solution requirements[footnote]International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide), version 3.0. Toronto, Ont: International Institute of Business Analysis.[\/footnote]. Besides these three requirement types which are structured in a hierarchy, there is a fourth type called transition requirements.\r\n\r\nBusiness requirements are the needs of the internal or external client, always from a management perspective. They are the statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative[footnote]International Institute of Business Analysis. (2015). A guide to the Business Analysis Body of Knowledge (BABOK guide), version 3.0. Toronto, Ont: International Institute of Business Analysis.[\/footnote]. Business requirements are statements of the business rationale for the project. They are usually expressed in broad outcomes, satisfying the business needs, rather than specific functions the system must\u00a0perform. These requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals and objectives. We can define our business requirements as below:\r\n