Smarter ideas worth writing about.

What Did We Forget to Ask? Requirements Jargon Explained

Whenever I start a new software project, I wrack my brain to think of all the questions the developers would need to have answered to build an awesome product for our customer. We need to know not only what we are building, but how it must behave, and where, when, and how it will be used. We also need to know if the business has any special constraints on its use. Skip any one of these concerns, and we can spend a lot of time and effort building a useless system. Business Analysts like me use specific terms to refer to groups of these questions, so that we can remember to ask them all.

Suppose that the ACME Company has recently put its catalog on its website, and wants customers to be able to order items online. When I gather requirements to build this capability, I want to speak to stakeholders in broad terms such as features, functional and non-functional requirements, and business rules. I review a quick reference guide, such as the one below, to ask all the appropriate questions to ensure a quality product.

  • Features: A feature is defined by business analysts as “a distinguishing characteristic of a solution which implements a cohesive set of requirements and which delivers value for a set of stakeholders.1” Features for the ACME Company’s online ordering capability might include a shopping cart and order fulfillment, and would probably interface with the inventory system.

    A feature may support more than one event. In the ACME Company example, the online shopping cart feature would support adding an item to the cart, viewing the contents of the cart, removing an item from the cart, and modifying the quantity of items in the cart. I need to know which events are or are not included in the feature. The ability to initiate an order for the contents of the cart could be included either as part of the shopping cart feature or in the order fulfillment feature, but shouldn’t be built in both. I’d also want to know about the desired handoffs between features.

  • Functional Requirement: A functional requirement is defined as “A capability that a solution must have in terms of the behavior and information the solution will manage2” and describes the solution’s functionality and behavior. A functional requirement of the event “Modify the Shopping Cart” might be “The user must be able to change the quantity of an item in the shopping cart before the order is initiated.” I’d ask whether the Cart must recalculate extended prices every time a quantity is changed, or only when the user selects to recalculate.

  • Missed functional requirements can make a solution unusable. Imagine what a mess an order would be if the shopping cart did not require – or worse, did not permit – recalculation of the extended price for a changed quantity.

  • Non-functional Requirement: A non-functional requirement is defined as “A type of requirement that describes the performance or quality attributes a solution must meet.3” These are often described informally as the “-abilities” of the solution (compatibility, availability, usability, extensibility, etc.), and define some of the constraints of the solution. For example, some non-functional requirements of the Shopping Cart might be “The Shopping Cart must be available between 2:00 a.m. and midnight EST every day” or “The Shopping Cart must be able to recalculate an order of 35 items in less than 1.5 seconds.”

  • A non-functional requirement might drive additional functional requirements (What does the user see between midnight and 2:00 a.m. if the system is not available?) or it could limit the selection of architecture or hardware to handle performance needs. Missing non-functional requirements can cause problems when the solution moves to production and fails to meet customer expectations for quality or performance.

  • Business rules: A business rule is defined as “A specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.4” Some of the business rules related to the Shopping Cart might be “Ambassador Club customer discounts will apply only to orders of $200 or more” or “A customer whose shipping address is in California or New York will not be permitted to order Item XYZ.” Business rules may provide the motivation for a functional or non-functional requirement, but are rooted in business concerns such as risk or market share rather than in architectural solutions or user interaction.

Additionally, I need to remember that other constraints outside of business requirements may apply as well, such as hardware or architectural limitations, interfaces with other systems, or a maximum budget. All these attributes must work together to define the solution which can provide the business value the ACME Company needs. Using a reference guide such as the one above helps me ensure that I have asked all the appropriate questions to ensure that my team and I will deliver a quality, usable product to our customer.

1 International Institute of Business Analysis, A Guide to the Business Analysis Body of KnowledgeTM, version 3 (BABOK v3), 2015, page 446.
2 BABOK v3, ibid.
3 BABOK v3, page 448.
4 BABOK v3, page 443.


About The Author

Business Analyst and Scrum Master
Nan is a Senior Consultant in Cardinal’s Cincinnati office, working as a business analyst and scrum master.  She has worked in an agile environment for the last 7 years and loves collaborating to provide top-quality products that meet the customer’s needs.