Smarter ideas worth writing about.

Differentiating and Defining Requirements

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 will 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 is 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 non-functional.  A business requirement is simply focused on the high-level needs of the user (often the business user or non-technical 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 that the system needs to perform by defining the capabilities the system should possess. During the analysis phase of the life cycle, 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 that 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.

Non-Functional 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 UI and the underlying system architecture.  

Examples of Non-Functional 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 5 seconds.

Business Rules
Business rules are frequently confused with business requirements.  It is important to understand that the two are not synonymous.  A business rule is a parameter placed upon the business by laws, regulations or other impositions.  They will 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 to define the kind of relationships that different data entities share.  
Example of Business Rule vs. Business Requirement:

  • Business Rule: A sales associate must enter a nine-digit number for their 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 is a skill that is worth refining and one that will render you an indispensable team asset.

Below are 5 best practices you can utilize 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 vs. operation of a system.  This will help you differentiate between functional and non-functional 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 have already captured and you will have an edge on refining their requirements.  
  4. Practice! Practice! Practice! Your ability to define requirements will be directly correlated 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 BA or developer could be your greatest resource.  Do not be afraid to solicit feedback on you requirements.  Be open to constructive feedback and learn from the best! 


About The Author