larimar,

BABOK 1.6 does make a distinction between business requirements and functional requirements. Version 2.0 does clarify this a little. We may consider that 'functional requirements' a subset of User Requirements and therefore a type of business requirement even though there is a slight distinction if you go by the text of the BABOK.

Everything a BA does focuses on the WHAT of the system. Here is my personal requirement breakdown. I have attached a PDF of an example traceability model which may help.

Business Requirements according to Perry McLeod

• Strategic Requirements
  • All business requirements are at the management level
  • The highest of which are strategic in nature
  • Usually long-term goal oriented
  • Any project must be able to be traced back to a strategic goal
  • These requirements are hard to quantify and are usually written with qualitative words like ‘superior service’, super-fast performance’ and so on
  • Strategic requirements can often be part of a business transformation initiative
    • business transformations tend to be long multi-million dollar projects that are focused to changing almost all aspects of the business
    • a single sentence spoken at a board meeting can translate into a business transformation
    • “The company will provide a superior 360 degree view of our customers to all CSR representatives, across all business domains”
    • is this a new CRM system? New processes? Enhanced RDBMS and seamless interoperability?

  click here for my example : http://www.pjmlimited.com/downloads/RequirementsTraceabilityModel.ppt

• Tactical Requirements
  • Tactical requirements deal mostly with the ability of different types systems, and their applications to work together effectively, without prior communication, in order to exchange information in a useful and meaningful manner
  • This is known to as interoperability
  • Interoperability testing is especially important to ensure the seamless communication between systems
  • This is often important to banks – example banking with CIBC and PC Financial – a tactical requirement may be the ability for customers to access both sets of accounts as though it were one bank
• Operational Requirements
  • Operational requirements are, as you might expect, operational in nature
  • These requirements are very process focused and usually of large concern to managers
  • Process steps, and real time updates are examples of abilities that might trace back to operational requirements
  • Events related to staff and system activities tend to fall under operational requirements
    • User Requirements
      • User requirements focus on the needs of the user community
      • The experience the user needs to have with no concern with how the system will work
      • User requirements trace directly back to benefits, results of value, process improvements, automation needs and so on
      • User requirements are at the heart of requirements analysis
      • In use case analysis a user requirement is something that the user needs to do within the system
      • Functional User Requirements
        • Taking user requirements a step deeper, functional requirements focus on what the system needs to do by way of discrete bits of functionality that will provide a business result or some other deliverable
        • In use case analysis the functional user requirements become the steps within the use case itself
      • Non-Functional User Requirements
        • Any discrete bits of the system that are not related to functionality can be called non-functional requirements
        • These requirements tend to focus on the “ilities” of the system
        • Security, availability, connect-ability, concurrent users, and so on

Specifications according to Perry McLeod

• Specifications are not requirements and requirements are not specifications
• There is however a dependency between specifications and requirements
• Requirements tells us what specifications are needed, while supporting the business case
  • Functional Specifications
    • describe in detail the characteristics of the system
    • describe the systems physical model, how the system will actually function
    • what type face will actually be used on the screen, a combo-box, an actual list-box and so on
  • Non-functional specifications
    • the actual characteristics as related to the operational environment needs
    • the user interface, security, access levels, recovery specifications, integration, data migration and so on

  I hope this is of help. Please see the attached models. I use them all the time to show how it all fits together.

Craig, I see where you're coming from and agree that all requirements should service the business problem, although I'm not sure I like the idea of a hierarchy of requirements from a clarity perspective.  If a requirement can be several categories at once I think that can lead to confusion when discussing requirements with the business and operational stakeholders.  From my interpretation of the V1.6 BABOK requirement definitions, each category is purposely distinct so that there is no confusion about what type of requirement a given statement is.

Again, I understand your viewpoint but think from a practical perspective it makes more sense to keep each category of requirements separate via their definitions.

Perry, thanks for your clarification and detailed response.

Could anybody please let me know where I can still download a PDF of BABOK V2.0?

I just started reading BABOK V1.6. Since everybody says V2.0 is a good improvement, I want to go directly from there and avoid some possible confusion.

Thanks,

Irene