Differentiating and Defining Requirements

Published 12/13/2018 10:29 AM   |    Updated 05/16/2019 10:37 AM

The success of a project can be directly related to how well business analysts can elicit and communicate both the business and system requirements. The overwhelming volume of requirements can be inundating and cause some to focus solely on the functions and features to be delivered. As a result, major requirements could be overlooked and impact project time, scope and schedule. 

For these reasons, I’ll try to simplify and put into perspective the different types of requirements that should be taken into consideration when eliciting and documenting requirements for a new solution.

What are requirements?


In general, requirements are statements regarding what a system must do or what characteristics are necessary to achieve a desired functionality. Well-defined requirements are necessary for any solution. Whether a client needs an enhancement or an entirely new application, it’s imperative to define requirements early in the project. Requirements drive the estimation of time and cost for implementation of a system and, ultimately, establish a common vision for the entire project.

Requirements can be further classified as business, functional or nonfunctional. A business requirement is simply focused on the high-level needs of the user (often the business user or nontechnical users). They describe “what” will provide value to the organization. As the requirements phases progress, the business analyst will create functional requirements that detail how the business requirements will be implemented. 
 
Example of business requirements: 

  • Collect customer orders online.
  • Share inventory supply information with distributors.

Functional requirements relate directly to a process the system needs to perform by defining the capabilities the system should possess. During the analysis phase of the lifecycle, functional requirements evolve into use cases, process models and data models. 

Use cases will define system behavior as a sequence of actions related to a specific user role. The use cases will trace back to a previously defined business need or requirement and, thus, allow you to verify the implementation fulfills those requirements.
 
Examples of functional requirements: 

  1. Wine inventory management
    1. The system shall allow managers to view the new wine inventory.
    2. The system shall allow the manager to place orders for new wines.
    3. The system shall record the addition of new wines to inventory when they are received from distributors.
  2. Wine sales management
    1. The system shall enable sales associates to create customer profiles.
    2. The system shall track and maintain all wine sales transactions.
    3. The system shall create records of all wine purchases.
 
Nonfunctional requirements define the operation of the system, such as quality, security, scalability, etc. These influence the design phase and are often used to help make decisions surrounding the User Interface (UI) and the underlying system architecture. 
  
Examples of nonfunctional requirements: 

  1. Operational
    1. The system shall run on tablets used by sales associates.
    2. The system shall connect to wireless printers.
    3. The system shall have offline mode.
  2. Performance
    1. The system shall support the entire sales team of 10 associates concurrently.
    2. The system screens shall load completely within five seconds.

Business rules


Business rules are frequently confused with business requirements. It’s important to understand the two are not synonymous. A business rule is a parameter placed upon the business by laws, regulations or other impositions. The rules enforce the desired behavior of system users and provide guidelines for ensuring compliance to the business requirements. Additionally, business rules are used within data modeling and help define the kinds of relationships different data entities share.  
 
Example of business rule vs. business requirement:

  • Business rule: A sales associate must enter a nine-digit number for the contact phone number.
  • Business requirement: Products must have product ID numbers.

5 best practices to improve your requirements


Eliciting and refining requirements is not innate — it’s a skill that’s worth refining and one that will render you an indispensable team asset.

Let’s look at five best practices you can use to help strengthen the completeness of requirements elicitation and improve the success of the solution delivery process:

  1. Determine if the requirement is related to a process/capability versus operation of a system.  This will help you differentiate between functional and nonfunctional requirements and solidify your communication of the requirements to the development team. 
  2. Start simple. Requirements can always be dissected into further detail. Ensuring you capture the proper strategic objectives or business problems will be key to defining success. 
  3. Review existing requirements. Reviewing existing documentation provided by the current stakeholders will be critical to prevent re-inventing the wheel. Become intimately knowledgeable of what they’ve already captured, and you’ll have an edge on refining their requirements.  
  4. Practice, practice, practice. Your ability to define requirements will be directly related to the number of times you complete this process. Your stakeholders may not always ask you to submit formal documentation of the requirements, but defining them for your own use will be time well spent. 
  5. Learn from a mentor. A senior business analyst or developer could be your greatest resource. Don’t be afraid to solicit feedback on your requirements. Be open to constructive feedback and learn from the best.  


This article originally appeared on June 24, 2015.

Is this answer helpful?