Types of Requirement

Requirement Type defines the "type" of requirement it is - for instance, a requirement can be a feature, a design element, an acceptance criteria, or anything you want. These serve to further categorize items within a given type of artifact (Artifacts are requirements, releases, test cases, and so on) for your organizational purposes. The names of these types can be edited by a system admin to be anything you want, and are managed at the Product Template level.

The value in using this feature is so specific types of a given artifact can be reviewed by category. For example, incidents have types as well. A very common incident type that is used  is the "Bug" type. If people at your company are looking to do a bug review, or plan a release that revolves around bug fixes, they would be able to sort a list of incidents to only display those which are bugs, rather than needing to sort through all the incidents in a product and manually figure out which ones are bugs.

What is a Requirement?

At its simplest, a requirement is a service, function or feature that a user needs.
Requirement type can be functions, constraints, business rules or other elements that must be present to meet the need of the intended users.

Requirements can be split to Categories:

  • What it does (functionality, features)- Functional Requirements (FRs) - express function or feature and define what is required, e.g.
  • How well it performs against defined parameters (non-functional attributes, acceptance criteria, service levels) -  Non-functional Requirements (NFRs)

    Non-functional Requirements define to what level a solution needs to behave. They describe solution attributes such as security, reliability, maintainability, availability (and so on), performance and response time, e.g.

The requirements do not state how a solution will be physically achieved.

A User Story is a requirement expressed from the perspective of an end-user goal.
User Stories may also be referred to as Epics, Themes or features but all follow the same format.

Basically, it is just a well-expressed requirement.
The User Story format has become the most popular way of expressing requirements in Agile for a number of reasons:

  • It focuses on the viewpoint of a role who will use or be impacted by the solution
  • It defines the requirement in language that has meaning for that role
  • It helps to clarify the true reason for the requirement
  • It helps to define high level requirements without necessarily going into low level detail too early

Type is 100% user customizable for requirements so it is for you to define the meanings.
The only issue there is what types should steps have.

Requirement Statuses

As for the status property, this property conveys the status of that artifact. For instance, a requirement could be new, rejected, completed, or any other status. This can be used to provide information to users about the status of various artifacts. The value in this is to provide a consistent tracking mechanism for understanding what part of your process an artifact is in, as well as provide a central place for information about what has been done already. The way these different statuses interact is defined by your workflow which is customizable by a system admin.

Please keep in mind that with both of these fields, what a particular value means to you and your company is not set in stone. As long as there is a common understanding of what various status or type values mean, it will be very useful for your team to understand what a requirement or any other artifact is representing more precisely, and what stage of your process a given artifact is in. If the values for types of requirements do not mean anything to your team, it can be useful to change them to terms that will be more broadly understood.