4.2 Eliciting Requirements

As 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^[4]. Besides these three requirement types which are structured in a hierarchy, there is a fourth type called transition requirements.

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 the whole of an enterprise, a business area, or a specific initiative^[5]. 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:

• A mobile application shall be used by customers of our grocery stores.
• Customers should access the mobile website and applications on their smartphones and tablets, and complete the purchase.

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.

• The mobile website and smartphone application shall:
  • Include all the functions that a desktop website possesses.
  • Be accessed with the same login username and password.
  • Synchronize the customer profile and the cart with the desktop website.

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:

• Business Requirement: A mobile application shall be used by customers of our grocery stores.
• Stakeholder Requirements:
  • Customers shall log in to the application by using their usernames and passwords.
  • Customers shall also log in to the application through biometrics identification.
  • Customers shall use their usernames and passwords across all interfaces (mobile application, mobile website, and desktop website).
  • 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).
  • Customers shall browse the items of their choice after selecting the categories or typing on a search box.

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^[6]. Thus, they can provide an appropriate level of detail for the development and implementation of the solution. These requirements are divided into two subcategories as functional and non-functional requirements.

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 that the solution will manage.

• Stakeholder Requirement: Customers shall log in to the application by using their usernames and passwords.
  • Functional Solution Requirement: 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.
• Stakeholder Requirement: 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).
  • Functional Solution Requirement: The profile page consists of the fields “First Name”, “Middle Name”, “Last Name”, “Gender”, “Street Address”, “Apartment/Suite Number”, “City”, “State”, “Zip Code”, “Mobile Phone Number”, “Other Phone Number”, “Debit/Credit Card Number”, “Debit/Credit Card Expiration Date”, and “Debit/Credit Card Security Code”.
  • Functional Solution Requirement: 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.

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^[7]. End users cannot see directly on the mobile application how these requirements are met.

• Stakeholder Requirement: Customers shall view the total price of the items they added to their cart, and shall checkout by entering their addresses and payment information.
  • Non-Functional Solution Requirement: The system shall confirm the validity of the payment tool (debit or credit card), and carry out the transaction securely by blocking any breach from outside the system.

The last requirement type is the transition requirements (Figure 4.1). These requirements describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete^[8]. 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 as below:

• Functional solution requirement: 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.
• Transition requirements: Before mobile application becomes operational, it shall be ensured that:
  • Employees in call centers shall be trained to effectively find solutions to the customers’ requests through the mobile application.
  • Call centers shall be equipped with the necessary hardware and software tools to support customers who do their shopping on the mobile application.
  • Call centers shall be supported via a stable and fast network connection.
  • The call center database shall be hosted in a cloud server with a backup option.

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.

Documenting requirements is much more than just the process of writing down the requirements as the user sees them; it should cover not only what decisions have been made, but why they have been made, as well. Understanding the reasoning that was 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 it is not, then the project risks wasted work and repetition, when a stakeholder requests the feature be reinstated during development or testing.

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 making certain the requirements are documented, it does not mean that the project manager performs this task. The project manager enlists the help of all the stakehold­ers (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 that the quality of the document is questionable, their duty is to stop the development process.

The project manager reviews the requirements, incorporates them into the project documentation library, and uses them as input for the project plan.