When it comes to requirements classifications there are many things a Business Analyst is supposed to be concerned about. As we dive deeper the elaboration and exploration reaches to a new level which in turn arises any of the requirements classification area listed below:

1. FUNCTIONAL REQUIREMENTS

• In Software engineering and systems engineering, a functional requirement defines a function of a system or its component. A function is described as a set of inputs, the behavior, and outputs.
• Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases.
• A typical Functional Requirement can be anything arising out of below list:
  Business Rules
  Transaction corrections, adjustments and cancellations
  Administrative functions
  Authentication
  Authorization levels
  Audit Tracking
  External Interfaces
  Certification Requirements
  Reporting Requirements
  Historical Data
  Legal or Regulatory Requirements

2. NON FUNCTIONAL REQUIREMENTS (NFR)

• In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors
• Non Functional Requirements(NFR) typically defines the attributes or the quality of the System.
• A typical Non Functional Requirements can be anything arising out of below list:
  Performance
  Scalability
  Capacity
  Availability
  Reliability
  Recoverability
  Maintainability
  Serviceability
  Security
  Regulatory
  Manageability
  Environmental
  Data Integrity
  Usability
  Interoperability

3. TRANSITIONAL REQUIREMENTS

• A transitional requirement is a classification of requirements that facilitate transition from the current state to the desired future state, but that will not be needed once that transition is complete.
• Mostly Environmental or Software Systems Infrastructure set up requirements are part of transitional requirements.
• The transitional requirements can also be used in the context of User Interface Analysis and System to System Integration Analysis.

4. IMPLICIT REQUIREMENTS

• These are all the things that users are going to expect that were not captured explicitly.
• These requirements are part of the QA requirements testing strategy.
• Most of the Implicit requirements are not clearly documented yet the final software solution need them.
• Most of the implicit requirements are assumed based on the industry experience and do not need any formal approval before they are implemented.

5. EXPLICIT REQUIREMENTS

• Explicit requirements are most commonly found in documents communicated by stakeholders to the development team. They might take the form of an elaborate design specification, a set of acceptance criteria, or a set of wire frames.
• These requirements are part of the Qa requirements testing strategy.
• All the explicit requirements are defined with a set of Evaluation and Acceptance criteria to ensure its 100% correct when its is validated by the QA team.
• These Acceptance and Evaluation criteria can be based on both Positive and Negative scenarios.

6. LATENT REQUIREMENTS

• Latent requirements represent behaviors that users do not expect based on their previous experiences but which will make them like the software more.
• These requirements are influenced by the User Experience and User Interfaces.

7. SOLUTION REQUIREMENTS

• Both Functional and Non Functional Requirements (NFR) are part of solution requirements.

8. BUSINESS REQUIREMENTS

• The Business Requirement is a high level statement describing what is required from the business’s perspective.
• These requirements are listed in the high level project documents or artifacts from a business perspective and not at all from an implementation perspective.

9. STAKEHOLDERS REQUIREMENTS

• Since there are multiple stakeholders in a given project their views and perspectives around a requirement would be unique.
• It is important to understand here that this type of requirement, the stakeholder requirement is not stating how they want these requirements to be implemented, they are simply stating what is required.

10. DOMAIN REQUIREMENTS

• Domain requirement is the Requirement that comes from the application domain of the system that reflects the characteristics of that domain.
• All the domain specific Compliance, Regulatory, Calculation Algorithms would be part of these domain requirements.

11. USER INTERFACE (UI) REQUIREMENTS

• A user interface specification (UI specification) is a document that captures the details of the software user interface into a written document.
• The specification covers all possible actions that an end user may perform and all visual, auditory and other interaction elements.

---

Hope you enjoyed this article.
A learning initiative by sunilkumarmajhi.com

---