A software requirement specifies a need to be fulfilled by the software product.
A software project may be,
In either case, requirements need to be gathered, analyzed, specified, and managed.
Requirements come from stakeholders.
Stakeholder: A party that is potentially affected by the software project. e.g. users, sponsors, developers, interest groups, government agencies, etc.
Identifying requirements is often not easy. For example, stakeholders may not be aware of their precise needs, may not know how to communicate their requirements correctly, may not be willing to spend effort in identifying requirements, etc.
There are two kinds of requirements:
Some examples of non-functional requirement categories:
We may have to spend an extra effort in digging NFRs out as early as possible because,
Given below are some requirements of TEAMMATES (an online peer evaluation system for education). Which one of these are non-functional requirements?
Explanation: (b) are (e) are functions available for a specific user types. Therefore, they are functional requirements. (a), (c), (d), (f) and (g) are either constraints on functionality or constraints on how the project is done, both of which are considered non-functional requirements.
Requirements can be prioritized based the importance and urgency, while keeping in mind the constraints of schedule, budget, staff resources, quality goals, and other constraints.
A common approach is to group requirements into priority categories. Note that all such scales are subjective, and stakeholders define the meaning of each level in the scale for the project at hand.
An example scheme for categorizing requirements:
Essential: The product must have this requirement fulfilled or else it does not get user acceptance
Typical: Most similar systems have this feature although the product can survive without it.
Novel: New features that could differentiate this product from the rest.
Level 2, ...
Some requirements can be discarded if they are considered ‘out of
The requirement given below is for a Calendar application. Stakeholder of the software (e.g. product designers) might decide the following requirement is not in the scope of the software.
The software records the actual time taken by each task and show the difference between the actual and scheduled time for the task.
Here are some characteristics of well-defined requirements
Besides these criteria for individual requirements, the set of requirements as a whole should be
Peter Zielczynski, Requirements Management Using IBM Rational RequisitePro, IBM Press, 2008