What is a requirement?
The American Heritage Dictionary defines a requirement as “Something that is required; a necessity”. PMI defines a project requirement as “the characteristics of the product, service or result that the project was undertaken to deliver”.
The general nature of these definitions is a perfect illustration of the problem. If you ask ten people for the definition of a requirement, you will get ten different answers. It is no surprise that identifying and managing requirements is one of the biggest IT management challenges.
Within the context of IT, a requirement should “identify the purpose, characteristics, features, functions and/or expected outcomes”. Unfortunately, business stakeholders and IT project teams have a different expectation when they discuss requirements. IT Processes must recognize these differences by acknowledging the following types of requirements:
Business Outcomes should be defined using measurements or success criteria. The debate about the value of IT services is directly related to the failure to define measurable outcomes. Examples of business outcomes include:
– Improved efficiency to reduce costs or increase value
– Automation of manual processes to reduce effort
– Risk Reduction Regulatory compliance
Functional requirements define the information processing functions that are needed to achieve the business outcome. Functional requirement include:
– Input – The type of inputs and how they should be received by the system (manual, stored data, interfaces)
– Business Rules … what the system should do with the data?
– Outputs or Results of the functional process as it relates to the desired business outcome
Technical or Architectural requirements standardize technology, control costs/quality, and efficiently respond to business requirements. These requirements are frequently unknown to business. They include:
– Infrastructure capacity and availability (servers, networks, etc.)
– Operational support requirements
– Standards and IT Best Practices
– Approved Development Languages and Operating Systems
Responsibility for defining each type of requirement must be assigned. Additionally, there must be direct linkage between business outcomes and functional requirements in order to manage changes and quality. There must be a role that translates business requirements into functional requirements that comply with technical requirements. In the construction industry, this is the responsibility of the architect.
The IT industry is still evolving and this role has not been clearly defined. Business Analysts are supposed to understand technology and business to facilitate this communication. Unfortunately, few B/A’s have this combination of skills. The Enterprise Architect should define the overall architecture and how it relates to the business but most Enterprise Architects are very technical and lack the business knowledge.
The long-term resolution of these challenges requires that we first understand the different perceptions relating to requirements and improve our definition of roles and responsibilities and communications with the business. Ultimately, a career path needs to be created where individuals can learn the combination of business and technical knowledge required to effectively coordinate the different types of requirements.