Posted by tac_admin, February 27, 2013

Categorizing Requirements

To present and maintain requirements, think of them as belonging to categories. Each category of requirement is built on the previous category, starting with business requirements, followed by functional requirements, and ending with technical requirements.

Check out the breakdown of each category for an easy reference on how to categorize your requirements:

Business Requirements

These are detailed descriptions of the information,business activities, business rules, and interactions needed to accomplish the business mission.

A business requirement addresses what the business problem is, what the business needs to accomplish, and/or what are the business goals, including…

  • Project initiation: A statement of purpose, objectives, and risks of the project. The project scope description and diagram are the first source of Business Requirements.
  • Information needs: Descriptions of the business information that is used by the Business Area (entities and attributes).
  • Business processes/activities: Descriptions of the work done by the Business area to accomplish their goals and objectives.
  • Business rules: Constraints or conditions that control when and how an activity is performed, they are operating principles about the business.

Functional Requirements

For each business requirement that is to be automated, describe how it should be automated and what the software will “look like” to the end user. For business requirements that will not be automated, document the manual procedure and employee guidelines.

Functional requirements describe the view from the user’s perspective of how the system or process will work, including…

  • Design area scope: Description of which business requirements will be automated (Use Case diagram).
  • System functionality: How the user will interact with the software.These are often documented with Use Cases.
  • Data definitions: What the business data will look like, allowable values, default values, field lengths, etc.
  • Quality attributes: Descriptions that indicate how well the system performs a behavior or lets the user take some action.
  • User classes: Groups of people who will be using the new application software or process (actors, external agents).
  • User interfaces: Screen layouts, report layouts, and procedural descriptions.
  • Performance standards: Volume of transactions, number of users,speed of response, etc.
  • Security requirements: Levels of access required, password length and type, audits and/or logging required.

Technical Requirements
These are detailed descriptions of database definitions, database triggers, stored procedures, business rule engine logic, program logic, application interfaces, and network components to support the business requirements and the functional requirements.

A technical requirement is a requirement that describes specifically how the business problem will be solved, and reflects the view from the technical world. This includes…

  • Hardware descriptions: Are there specific types or brands of hardware that must be used?
  • Software descriptions: What development tools will be used, and what programming language?
  • Database design and data conversion requirements.
  • Design flowsDiagrams and descriptions that depict how programs and other system components interface with each other.
  • Programming considerations: Creating reusable modules, following standard programming naming conventions, and using consistent call sequences.
  • Interface requirements: Connections between this system and other existing systems. These include interfaces, and communication mechanisms for hardware and other software systems.
  • Any additional technical constraints and standards.

Perfect requirements documentation when you enroll in my online training  course today! 

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.