Archive for February, 2011


I have recently revisited the definition of a “Requirement”. Traditionally it is area for almost endless debate and argument, But the categorisation below seems to work for me…

Business Requirements

High-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis.

Stakeholder Requirements

Statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements. They are developed and defined through requirements analysis.

Solution Requirements

Describe the characteristics of the solution. The solution must meet business requirements and stakeholder requirements.

Within Solution Requirements, we have:

    Functional Requirements: Which describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.
    Non-functional Requirements: Capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information
    architecture and presentation of the user interface.

Transition Requirements

As I understand it, transition requirements describe capabilities an organisation must have in order to facilitate transition from the current state of the enterprise to a desired future state. Theoretically, this isn’t long-term. It is only needed to do the transition. They are different from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. Training and development is an obvious example.

There has been something of a debate in the industry in recent years over what a Business Analyst, Systems Analyst, Business Process Analyst, Business Systems Analyst, Data Analyst etc. actually is.

If you ask ten organisations what a business or systems analyst does you are likely to get ten different answers. Job titles and descriptions for analysts vary widely between organisations.

A generic “Modern Analyst” definition seems to be emerging, where one must possess a combination of some or all of the following skills:

  • The analyst works with the business to identify opportunities for improvement in business operations and processes
  • The analyst is involved in the design or modification of business systems or IT systems
  • The analyst interacts with the business stakeholders and subject mater experts in order to understand their problems and needs
  • The analyst gathers, documents, and analyzes business needs and requirements
  • The analyst solved business problems and, as needed, designs technical solutions
  • The analyst documents the functional and, sometimes, technical design of the system
  • The analyst interacts with system architects and developers to ensure system is properly implemented
  • The analyst may help test the system and create system documentation and user manuals

The overarching imperative is to be flexible, adaptable and not get too dogmatic about it all. Though having said that, you must equally defend your position and have an opinion.

Personally, I’ve never been too concerned about job titles.  As the article here explains brilliantly:

“It’s not what you’re called, it’s what you do.”.