{"id":105,"date":"2022-01-26T18:44:41","date_gmt":"2022-01-26T18:44:41","guid":{"rendered":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/chapter\/4-2-eliciting-requirements\/"},"modified":"2025-01-06T03:15:28","modified_gmt":"2025-01-06T03:15:28","slug":"4-2-eliciting-requirements","status":"publish","type":"chapter","link":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/chapter\/4-2-eliciting-requirements\/","title":{"rendered":"4.2 Eliciting Requirements"},"content":{"raw":"After all the deliverables are identified, the project manager must document all the requirements. 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. The 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 <em>BABOK Guide defines a requirement as a usable representation of a need.<\/em> 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 <em>\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<\/em> 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 the 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 ensure that requirements are defined so that project activities can be determined and sequenced, and hence, a schedule and budget can be created. As the Business Analysis for Practitioners: A Practice Guide quoted, \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 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 such as dimensions, ease of use, color, and specific ingredients.\r\n\r\nWhen a specific 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.2.1.\r\n<div>\r\n\r\n[caption id=\"attachment_104\" align=\"aligncenter\" width=\"498\"]<img src=\"https:\/\/pressbooks.ulib.csuohio.edu\/project-management-navigating-the-complexity\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1.jpg\" alt=\"The image illustrates the hierarchical relationships between various types of requirements in a project or system:Business Needs:\r\nRepresents the high-level objectives or problems that the organization aims to address.\r\n\r\nBusiness Requirements:\r\nDerived from business needs and define what the organization wants to achieve.\r\n\r\nStakeholder Requirements:\r\nSpecify the needs and expectations of stakeholders related to the business requirements.\r\n\r\nSolution Requirements:\r\nDerived from stakeholder requirements and split into two categories:\r\nFunctional Requirements: Define what the solution must do.\r\nNon-Functional Requirements: Define the quality, performance, or constraints of the solution.\r\n\r\nTransition Requirements:\r\nAddress the needs for moving from the current state to the desired future state, such as data migration or user training.\r\n\r\nThis diagram emphasizes the flow from abstract business needs to detailed requirements, ensuring alignment at each level.\" width=\"498\" height=\"501\" class=\"wp-image-104\" \/> Figure 4.2.1: Relationships between Requirements<br \/>(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<div>\r\n\r\nAs illustrated in Figure 4.2.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 when creating requirements, especially when discussing 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 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 perform. 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<ul>\r\n \t<li>A mobile application shall be used by customers of our grocery stores.<\/li>\r\n \t<li>Customers should access the mobile website and applications on their smartphones and tablets and complete the purchase.<\/li>\r\n<\/ul>\r\nIn our Project Charter example in Chapter 3, the high-level requirements were as follows. They can be considered either business requirements or stakeholder requirements.\r\n<div class=\"textbox shaded\">\r\n\r\nThe mobile website and smartphone application shall:\r\n<ul>\r\n \t<li>Include all the functions that a desktop website possesses.<\/li>\r\n \t<li>Be accessed with the same login username and password.<\/li>\r\n \t<li>Synchronize the customer profile and the cart with the desktop website.<\/li>\r\n<\/ul>\r\n<\/div>\r\nIn order to elicit the requirements, a team should dig deep by implementing various techniques such as interviews, surveys, focus group meetings, observations, and document analysis. In organizations, business analysts or other positions performing the tasks of a business analyst perform these techniques to ensure that they can address the need from the perspective of stakeholders (e.g., customers, end-users). Stakeholder requirements serve as a bridge between business and solution requirements. In our m-commerce project initiated by Grocery LLC, we can write some of the stakeholder requirements as below:\r\n<div class=\"textbox textbox--examples\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>Stakeholder Requirements<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<strong>Business Requirement:<\/strong> A mobile application shall be used by customers of our grocery stores.\r\n\r\n<strong>Stakeholder Requirements:<\/strong>\r\n<ul>\r\n \t<li>Customers shall log in to the application by using their usernames and passwords.<\/li>\r\n \t<li>Customers shall also log in to the application through biometrics identification.<\/li>\r\n \t<li>Customers shall use their usernames and passwords across all interfaces (mobile application, mobile website, and desktop website).<\/li>\r\n \t<li>Customer profile information, including the name, shipping and billing addresses, and payment accounts, shall synchronize across all interfaces (mobile application, mobile website, and desktop website).<\/li>\r\n \t<li>Customers shall browse the items of their choice after selecting the categories or typing in a search box.<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\nAfter stakeholder requirements are developed, solution requirements can be derived from these stakeholder requirements. They describe the capabilities and qualities of a solution that meets the stakeholder 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]. Thus, they can provide appropriate details for developing and implementing the solution. These requirements are divided into two subcategories: functional and non-functional requirements.\r\n\r\nFunctional requirements describe the characteristics of the final deliverable in ordinary non-technical language. They should be understandable to the customers, and the customers should play a direct role in their development. Functional requirements are what you want the deliverable to do. They describe the capabilities that a solution must have in terms of the behavior and information the solution will manage.\r\n<div class=\"textbox textbox--examples\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>Functional Solution Requirements<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<span style=\"text-decoration: underline\"><strong>Stakeholder Requirement:<\/strong><\/span> Customers shall log in to the application using their usernames and passwords.\r\n<ul>\r\n \t<li><span style=\"text-decoration: underline\"><strong>Functional Solution Requirement:<\/strong><\/span> Customers shall receive a one-time password to their mobile phones as a text message or to their email addresses so that they can type this one-time password on the mobile application, or the mobile application can recognize the text message and automatically transfer it to the mobile application.<\/li>\r\n<\/ul>\r\n<strong>Stakeholder Requirement:<\/strong> Customer profile information, including the name, shipping and billing addresses, and payment accounts, shall synchronize across all interfaces (mobile application, mobile website, and desktop website).\r\n<ul>\r\n \t<li><span style=\"text-decoration: underline\"><strong>Functional Solution Requirements:<\/strong><\/span>\r\n<ol>\r\n \t<li>The profile page consists of the fields \u201cFirst Name,\u201d \u201cMiddle Name,\u201d \u201cLast Name,\u201d \u201cGender,\u201d \u201cStreet Address,\u201d \u201cApartment\/Suite Number,\u201d \u201cCity,\u201d \u201cState,\u201d \u201cZip Code,\u201d \u201cMobile Phone Number,\u201d \u201cOther Phone Number,\u201d \u201cDebit\/Credit Card Number,\u201d \u201cDebit\/Credit Card Expiration Date,\u201d and \u201cDebit\/Credit Card Security Code.\u201d<\/li>\r\n \t<li>When customers type new information or edit existing information in their profile pages on only one of the interfaces, this information will be updated immediately on other interfaces.<\/li>\r\n<\/ol>\r\n<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\nNon-functional requirements or quality of service requirements do not relate directly to the behavior or functionality of the solution but rather describe conditions under which a solution must remain effective or qualities that a solution must have[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]. Some non-functional requirements, such as performance or usability, may be directly perceptible to end users on the mobile application. Others, such as security or compliance, are not typically visible but contribute to the application's overall effectiveness and quality.\r\n\r\nNon-functional requirements specify the quality attributes, environmental conditions, or constraints the solution must satisfy to be effective. They do not describe the solution's functionality but its qualities or performance. Examples include:\r\n<ul>\r\n \t<li><strong>Performance<\/strong>: Response time, throughput, or processing speed.<\/li>\r\n \t<li><strong>Security<\/strong>: Measures to protect data and system integrity.<\/li>\r\n \t<li><strong>Usability<\/strong>: Accessibility, user interface design, or ease of use.<\/li>\r\n \t<li><strong>Reliability<\/strong>: Availability, fault tolerance, or disaster recovery.<\/li>\r\n \t<li><strong>Compliance<\/strong>: Adherence to legal, regulatory, or industry standards.<\/li>\r\n<\/ul>\r\nNon-functional requirements define how well the solution performs or operates, emphasizing quality and operational characteristics.\r\n<div class=\"textbox textbox--examples\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>Non-functional Solution Requirements<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<span style=\"text-decoration: underline\"><strong>Stakeholder Requirement:<\/strong><\/span> Customers shall view the total price of the items they added to their cart and shall checkout by entering their addresses and payment information.\r\n<ul>\r\n \t<li><span style=\"text-decoration: underline\"><strong>Non-Functional Solution Requirements:<\/strong><\/span>\r\n<ol>\r\n \t<li>The system shall ensure secure payment processing by encrypting all transaction data and preventing unauthorized access through robust security protocols.<\/li>\r\n \t<li>The system shall provide a user-friendly checkout interface that allows customers to view their total price and complete the checkout process with a maximum of three clicks.<\/li>\r\n \t<li>The system shall comply with Web Content Accessibility Guidelines (WCAG) 2.1 Level AA to ensure customers with disabilities can view their cart and complete the checkout process without barriers.<\/li>\r\n<\/ol>\r\n<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\nThe last requirement type is the transition requirement (Figure 4.1). These requirements describe the capabilities the solution must have and the conditions the solution must meet to facilitate the transition from the current state to the future state, but are not needed once the change is complete[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]. They describe temporary capabilities such as data conversion, training, and business continuity requirements. They are essential for the organizational readiness to make the project outcomes and deliverables operational. In our m-commerce project, some transition requirement examples can be outlined below:\r\n<div class=\"textbox textbox--examples\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>Transition Requirements<\/strong><\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<span style=\"text-decoration: underline\"><strong>Functional solution requirement: <\/strong><\/span>Customers shall be able to chat with and have a phone call with call center agents and customer service representatives when they need to contact due to any issues or demands related to the mobile application.\r\n\r\n<span style=\"text-decoration: underline\"><strong>Transition requirements: <\/strong><\/span>Before the mobile application becomes operational, it shall be ensured that:\r\n<ul>\r\n \t<li>Employees in call centers shall be trained to effectively find solutions to the customers\u2019 requests through the mobile application.<\/li>\r\n \t<li>Call centers shall be equipped with the necessary hardware and software tools to support customers who shop on the mobile application.<\/li>\r\n \t<li>Call centers shall be supported via a stable and fast network connection.<\/li>\r\n \t<li>The call center database shall be hosted in a cloud server with a backup option.<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\nThe effective specification of requirements is one of the most challenging undertakings project managers face. Inadequately specified requirements will usually lead to poor project results.\r\n\r\nDocumenting requirements is much more than just writing down the requirements as the user sees them; it should cover not only what decisions have been made but also why they have been made. Understanding the reasoning used to arrive at a decision is critical in avoiding repetition. For example, the fact that a particular feature has been excluded because it is simply not feasible needs to be recorded. If not, the project risks wasted work and repetition when a stakeholder requests the feature to be reinstated during development or testing.\r\n\r\nOnce the project requirements are documented, the next step is for key stakeholders to sign off on the requirements to confirm that everyone is operating with the same set of expectations. While the project manager is responsible for documenting the requirements, it does not mean that the project manager performs this task. The project manager enlists the help of all the stakehold\u00aders (business analysts, requirement analysts, business process owners, customers, and other team members) to conduct the discussions, brainstorming, and interviews and to document and sign off the requirements. As with many aspects of project management, the project manager is responsible only for enabling the process and facilitating it. If the project manager feels the document's quality is questionable, they must stop the development process.\r\n\r\nThe project manager reviews the requirements, incorporates them into the project documentation library, and uses them as input for the project plan.\r\n\r\n<\/div>","rendered":"<p>After all the deliverables are identified, the project manager must document all the requirements. While PMBOK Guide 6th Edition refers to this process as \u201cCollect Requirements,\u201d BABOK Guide v3 refers to elicitation<a class=\"footnote\" title=\"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.\" id=\"return-footnote-105-1\" href=\"#footnote-105-1\" aria-label=\"Footnote 1\"><sup class=\"footnote\">[1]<\/sup><\/a>. Elicitation is more than just collecting. The 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 <em>BABOK Guide defines a requirement as a usable representation of a need.<\/em> The nature of the representation may be a document (or set of documents) but can vary widely depending on the circumstances.<\/p>\n<p>The requirement is defined by the PMI Guide to Business Analysis as <em>\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<\/em> The responsibility for defining requirements should be assigned to resources that have sufficient business subject matter expertise and decision-making authority<a class=\"footnote\" title=\"Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute.\" id=\"return-footnote-105-2\" href=\"#footnote-105-2\" aria-label=\"Footnote 2\"><sup class=\"footnote\">[2]<\/sup><\/a>. 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 the 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.<\/p>\n<p>A project manager must ensure that requirements are defined so that project activities can be determined and sequenced, and hence, a schedule and budget can be created. As the Business Analysis for Practitioners: A Practice Guide quoted, \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<a class=\"footnote\" title=\"Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute.\" id=\"return-footnote-105-3\" href=\"#footnote-105-3\" aria-label=\"Footnote 3\"><sup class=\"footnote\">[3]<\/sup><\/a>. 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.<\/p>\n<p>A 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 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 such as dimensions, ease of use, color, and specific ingredients.<\/p>\n<p>When a specific requirement is under discussion, the term &#8220;requirement&#8221; is preceded by a qualifier such as stakeholder, business, or solution. The hierarchical relationship among requirements can be illustrated in Figure 4.2.1.<\/p>\n<div>\n<figure id=\"attachment_104\" aria-describedby=\"caption-attachment-104\" style=\"width: 498px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/pressbooks.ulib.csuohio.edu\/project-management-navigating-the-complexity\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1.jpg\" alt=\"The image illustrates the hierarchical relationships between various types of requirements in a project or system:Business Needs:  Represents the high-level objectives or problems that the organization aims to address.    Business Requirements:  Derived from business needs and define what the organization wants to achieve.    Stakeholder Requirements:  Specify the needs and expectations of stakeholders related to the business requirements.    Solution Requirements:  Derived from stakeholder requirements and split into two categories:  Functional Requirements: Define what the solution must do.  Non-Functional Requirements: Define the quality, performance, or constraints of the solution.    Transition Requirements:  Address the needs for moving from the current state to the desired future state, such as data migration or user training.    This diagram emphasizes the flow from abstract business needs to detailed requirements, ensuring alignment at each level.\" width=\"498\" height=\"501\" class=\"wp-image-104\" srcset=\"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1.jpg 814w, https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1-298x300.jpg 298w, https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1-150x150.jpg 150w, https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1-768x773.jpg 768w, https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1-65x65.jpg 65w, https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1-225x226.jpg 225w, https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-content\/uploads\/sites\/183\/2022\/01\/Figure-4.1-350x352.jpg 350w\" sizes=\"auto, (max-width: 498px) 100vw, 498px\" \/><figcaption id=\"caption-attachment-104\" class=\"wp-caption-text\">Figure 4.2.1: Relationships between Requirements<br \/>(Adapted from \u201cRequirements Classification Schema\u201d in \u201cA Guide to the Business Analysis Body of Knowledge\u00ae &#8211; BABOK\u00ae guide\u201d, version 3.0)<\/figcaption><\/figure>\n<\/div>\n<div>\n<p>As illustrated in Figure 4.2.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 when creating requirements, especially when discussing 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<a class=\"footnote\" title=\"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.\" id=\"return-footnote-105-4\" href=\"#footnote-105-4\" aria-label=\"Footnote 4\"><sup class=\"footnote\">[4]<\/sup><\/a>. Besides these three requirement types, which are structured in a hierarchy, there is a fourth type called transition requirements.<\/p>\n<p>Business 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 an enterprise, a business area, or a specific initiative<a class=\"footnote\" title=\"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.\" id=\"return-footnote-105-5\" href=\"#footnote-105-5\" aria-label=\"Footnote 5\"><sup class=\"footnote\">[5]<\/sup><\/a>. 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 perform. 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:<\/p>\n<ul>\n<li>A mobile application shall be used by customers of our grocery stores.<\/li>\n<li>Customers should access the mobile website and applications on their smartphones and tablets and complete the purchase.<\/li>\n<\/ul>\n<p>In our Project Charter example in Chapter 3, the high-level requirements were as follows. They can be considered either business requirements or stakeholder requirements.<\/p>\n<div class=\"textbox shaded\">\n<p>The mobile website and smartphone application shall:<\/p>\n<ul>\n<li>Include all the functions that a desktop website possesses.<\/li>\n<li>Be accessed with the same login username and password.<\/li>\n<li>Synchronize the customer profile and the cart with the desktop website.<\/li>\n<\/ul>\n<\/div>\n<p>In order to elicit the requirements, a team should dig deep by implementing various techniques such as interviews, surveys, focus group meetings, observations, and document analysis. In organizations, business analysts or other positions performing the tasks of a business analyst perform these techniques to ensure that they can address the need from the perspective of stakeholders (e.g., customers, end-users). Stakeholder requirements serve as a bridge between business and solution requirements. In our m-commerce project initiated by Grocery LLC, we can write some of the stakeholder requirements as below:<\/p>\n<div class=\"textbox textbox--examples\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>Stakeholder Requirements<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p><strong>Business Requirement:<\/strong> A mobile application shall be used by customers of our grocery stores.<\/p>\n<p><strong>Stakeholder Requirements:<\/strong><\/p>\n<ul>\n<li>Customers shall log in to the application by using their usernames and passwords.<\/li>\n<li>Customers shall also log in to the application through biometrics identification.<\/li>\n<li>Customers shall use their usernames and passwords across all interfaces (mobile application, mobile website, and desktop website).<\/li>\n<li>Customer profile information, including the name, shipping and billing addresses, and payment accounts, shall synchronize across all interfaces (mobile application, mobile website, and desktop website).<\/li>\n<li>Customers shall browse the items of their choice after selecting the categories or typing in a search box.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<p>After stakeholder requirements are developed, solution requirements can be derived from these stakeholder requirements. They describe the capabilities and qualities of a solution that meets the stakeholder requirements<a class=\"footnote\" title=\"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.\" id=\"return-footnote-105-6\" href=\"#footnote-105-6\" aria-label=\"Footnote 6\"><sup class=\"footnote\">[6]<\/sup><\/a>. Thus, they can provide appropriate details for developing and implementing the solution. These requirements are divided into two subcategories: functional and non-functional requirements.<\/p>\n<p>Functional requirements describe the characteristics of the final deliverable in ordinary non-technical language. They should be understandable to the customers, and the customers should play a direct role in their development. Functional requirements are what you want the deliverable to do. They describe the capabilities that a solution must have in terms of the behavior and information the solution will manage.<\/p>\n<div class=\"textbox textbox--examples\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>Functional Solution Requirements<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p><span style=\"text-decoration: underline\"><strong>Stakeholder Requirement:<\/strong><\/span> Customers shall log in to the application using their usernames and passwords.<\/p>\n<ul>\n<li><span style=\"text-decoration: underline\"><strong>Functional Solution Requirement:<\/strong><\/span> Customers shall receive a one-time password to their mobile phones as a text message or to their email addresses so that they can type this one-time password on the mobile application, or the mobile application can recognize the text message and automatically transfer it to the mobile application.<\/li>\n<\/ul>\n<p><strong>Stakeholder Requirement:<\/strong> Customer profile information, including the name, shipping and billing addresses, and payment accounts, shall synchronize across all interfaces (mobile application, mobile website, and desktop website).<\/p>\n<ul>\n<li><span style=\"text-decoration: underline\"><strong>Functional Solution Requirements:<\/strong><\/span>\n<ol>\n<li>The profile page consists of the fields \u201cFirst Name,\u201d \u201cMiddle Name,\u201d \u201cLast Name,\u201d \u201cGender,\u201d \u201cStreet Address,\u201d \u201cApartment\/Suite Number,\u201d \u201cCity,\u201d \u201cState,\u201d \u201cZip Code,\u201d \u201cMobile Phone Number,\u201d \u201cOther Phone Number,\u201d \u201cDebit\/Credit Card Number,\u201d \u201cDebit\/Credit Card Expiration Date,\u201d and \u201cDebit\/Credit Card Security Code.\u201d<\/li>\n<li>When customers type new information or edit existing information in their profile pages on only one of the interfaces, this information will be updated immediately on other interfaces.<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<p>Non-functional requirements or quality of service requirements do not relate directly to the behavior or functionality of the solution but rather describe conditions under which a solution must remain effective or qualities that a solution must have<a class=\"footnote\" title=\"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.\" id=\"return-footnote-105-7\" href=\"#footnote-105-7\" aria-label=\"Footnote 7\"><sup class=\"footnote\">[7]<\/sup><\/a>. Some non-functional requirements, such as performance or usability, may be directly perceptible to end users on the mobile application. Others, such as security or compliance, are not typically visible but contribute to the application&#8217;s overall effectiveness and quality.<\/p>\n<p>Non-functional requirements specify the quality attributes, environmental conditions, or constraints the solution must satisfy to be effective. They do not describe the solution&#8217;s functionality but its qualities or performance. Examples include:<\/p>\n<ul>\n<li><strong>Performance<\/strong>: Response time, throughput, or processing speed.<\/li>\n<li><strong>Security<\/strong>: Measures to protect data and system integrity.<\/li>\n<li><strong>Usability<\/strong>: Accessibility, user interface design, or ease of use.<\/li>\n<li><strong>Reliability<\/strong>: Availability, fault tolerance, or disaster recovery.<\/li>\n<li><strong>Compliance<\/strong>: Adherence to legal, regulatory, or industry standards.<\/li>\n<\/ul>\n<p>Non-functional requirements define how well the solution performs or operates, emphasizing quality and operational characteristics.<\/p>\n<div class=\"textbox textbox--examples\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>Non-functional Solution Requirements<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p><span style=\"text-decoration: underline\"><strong>Stakeholder Requirement:<\/strong><\/span> Customers shall view the total price of the items they added to their cart and shall checkout by entering their addresses and payment information.<\/p>\n<ul>\n<li><span style=\"text-decoration: underline\"><strong>Non-Functional Solution Requirements:<\/strong><\/span>\n<ol>\n<li>The system shall ensure secure payment processing by encrypting all transaction data and preventing unauthorized access through robust security protocols.<\/li>\n<li>The system shall provide a user-friendly checkout interface that allows customers to view their total price and complete the checkout process with a maximum of three clicks.<\/li>\n<li>The system shall comply with Web Content Accessibility Guidelines (WCAG) 2.1 Level AA to ensure customers with disabilities can view their cart and complete the checkout process without barriers.<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<p>The last requirement type is the transition requirement (Figure 4.1). These requirements describe the capabilities the solution must have and the conditions the solution must meet to facilitate the transition from the current state to the future state, but are not needed once the change is complete<a class=\"footnote\" title=\"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.\" id=\"return-footnote-105-8\" href=\"#footnote-105-8\" aria-label=\"Footnote 8\"><sup class=\"footnote\">[8]<\/sup><\/a>. They describe temporary capabilities such as data conversion, training, and business continuity requirements. They are essential for the organizational readiness to make the project outcomes and deliverables operational. In our m-commerce project, some transition requirement examples can be outlined below:<\/p>\n<div class=\"textbox textbox--examples\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>Transition Requirements<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p><span style=\"text-decoration: underline\"><strong>Functional solution requirement: <\/strong><\/span>Customers shall be able to chat with and have a phone call with call center agents and customer service representatives when they need to contact due to any issues or demands related to the mobile application.<\/p>\n<p><span style=\"text-decoration: underline\"><strong>Transition requirements: <\/strong><\/span>Before the mobile application becomes operational, it shall be ensured that:<\/p>\n<ul>\n<li>Employees in call centers shall be trained to effectively find solutions to the customers\u2019 requests through the mobile application.<\/li>\n<li>Call centers shall be equipped with the necessary hardware and software tools to support customers who shop on the mobile application.<\/li>\n<li>Call centers shall be supported via a stable and fast network connection.<\/li>\n<li>The call center database shall be hosted in a cloud server with a backup option.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<p>The effective specification of requirements is one of the most challenging undertakings project managers face. Inadequately specified requirements will usually lead to poor project results.<\/p>\n<p>Documenting requirements is much more than just writing down the requirements as the user sees them; it should cover not only what decisions have been made but also why they have been made. Understanding the reasoning used to arrive at a decision is critical in avoiding repetition. For example, the fact that a particular feature has been excluded because it is simply not feasible needs to be recorded. If not, the project risks wasted work and repetition when a stakeholder requests the feature to be reinstated during development or testing.<\/p>\n<p>Once the project requirements are documented, the next step is for key stakeholders to sign off on the requirements to confirm that everyone is operating with the same set of expectations. While the project manager is responsible for documenting the requirements, it does not mean that the project manager performs this task. The project manager enlists the help of all the stakehold\u00aders (business analysts, requirement analysts, business process owners, customers, and other team members) to conduct the discussions, brainstorming, and interviews and to document and sign off the requirements. As with many aspects of project management, the project manager is responsible only for enabling the process and facilitating it. If the project manager feels the document&#8217;s quality is questionable, they must stop the development process.<\/p>\n<p>The project manager reviews the requirements, incorporates them into the project documentation library, and uses them as input for the project plan.<\/p>\n<\/div>\n<hr class=\"before-footnotes clear\" \/><div class=\"footnotes\"><ol><li id=\"footnote-105-1\">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. <a href=\"#return-footnote-105-1\" class=\"return-footnote\" aria-label=\"Return to footnote 1\">&crarr;<\/a><\/li><li id=\"footnote-105-2\">Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute. <a href=\"#return-footnote-105-2\" class=\"return-footnote\" aria-label=\"Return to footnote 2\">&crarr;<\/a><\/li><li id=\"footnote-105-3\">Business Analysis for Practitioners: A Practice Guide (2015). Project Management Institute. <a href=\"#return-footnote-105-3\" class=\"return-footnote\" aria-label=\"Return to footnote 3\">&crarr;<\/a><\/li><li id=\"footnote-105-4\">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. <a href=\"#return-footnote-105-4\" class=\"return-footnote\" aria-label=\"Return to footnote 4\">&crarr;<\/a><\/li><li id=\"footnote-105-5\">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. <a href=\"#return-footnote-105-5\" class=\"return-footnote\" aria-label=\"Return to footnote 5\">&crarr;<\/a><\/li><li id=\"footnote-105-6\">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. <a href=\"#return-footnote-105-6\" class=\"return-footnote\" aria-label=\"Return to footnote 6\">&crarr;<\/a><\/li><li id=\"footnote-105-7\">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. <a href=\"#return-footnote-105-7\" class=\"return-footnote\" aria-label=\"Return to footnote 7\">&crarr;<\/a><\/li><li id=\"footnote-105-8\">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. <a href=\"#return-footnote-105-8\" class=\"return-footnote\" aria-label=\"Return to footnote 8\">&crarr;<\/a><\/li><\/ol><\/div>","protected":false},"author":3,"menu_order":3,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"class_list":["post-105","chapter","type-chapter","status-publish","hentry"],"part":99,"_links":{"self":[{"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/chapters\/105","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/wp\/v2\/users\/3"}],"version-history":[{"count":10,"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/chapters\/105\/revisions"}],"predecessor-version":[{"id":1142,"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/chapters\/105\/revisions\/1142"}],"part":[{"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/parts\/99"}],"metadata":[{"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/chapters\/105\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/wp\/v2\/media?parent=105"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/pressbooks\/v2\/chapter-type?post=105"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/wp\/v2\/contributor?post=105"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/wp-json\/wp\/v2\/license?post=105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}