I'm working on my first ever software project. Being the only one working on it, I'm making the work breakdown structure and I know requirement gathering is an important phase in the development process. What I can't wrap my head around is how exactly is a software requirement different from a feature that the system needs to have. Also, what sets a feature and a requirement apart from an objective or an aim of the project.

  • How can I classify something as a requirement, feature or objective?

  • Is requirement just the technical term? Because I see them classified further into functional, non-functional and more, but a feature is always a feature and I've not come across any classifications.

  • For instance, I'm doing this project alone and as a developer, I have to familiarize myself with some technologies; in my case, I'm planning to learn ASP.NET Core MVC, does it count as one of the requirements of my project?

I see the term requirements used in a very broad sense, wherein when talking about say, system and hardware requirements, it is quite obvious that they are not features or objectives. The ambiguity stems when requirements are said to be what a user wants to see in a system, which exactly as per my understanding, is what a feature is.

3 Answers 3


About the terminology:

  • A requirement expresses a need or a constraint that the system has to fulfil, in principle independently of the solution that will be chosen. Examples: "The system shall allow only valid contract types to be entered", "The system shall facilitate the analysis of contractual trends".
  • A feature is about something that the system offers: it's a part of the solution, expressed independently of the underlying user needs it adresses. Examples: "Configurable drop-down list of contract types", "A trend report provides an overview of the monthly evolution of contracts by type" . Hopefully a feature addresses one or several needs, but maybe not.
  • An objective, is something that business actors are expected to achieve. It's "why" people are doing things and have requirements. An objective of a clerk in a law firm, could for example be to prepare contracts. If the software shall help in this objective, it will have to fulfill a requirement, and it can provide some features to facilitate the tasks needed to fulfill the objective.

This is the theory. In practice, requirements are often expressed as a desired feature. It's often easier for a user to think of a feature rather than to abstract the underlying needs:

  • It has the advantage of facilitating the understanding of the expectations, and the quick agreement on the target solution.
  • It has the drawback that potential alternative solutions are ignored, in particular those features that could better address the same underlying requirement (in our examples an interactive "trend analyser" with graphical trends and drill-down could better address the analysis needs than a simple "trend report") (btw I'm still wondering why there are so many calendar pickers around there: it's a nice feature to ensure a valid date, but it forces me to use the mouse to scroll 50 years backwards, when I could just have entered the birth year in four keystrokes ;-))

It will be easier for you to understand it with an example:

  • Feature:

        * Online Shopping Cart
  • Requirements:

        * User shall be able to add things to online shopping cart
        * User shall be able to remove things from online shopping cart
        * User shall be able to view their items in the online shopping cart at any time
        * User shall be able to start his checkout from the shopping cart
  • 5
    Objective: Sell more goods.
    – gnasher729
    Commented Sep 29, 2020 at 10:02

Requirements, features, objectives. Functional/non-functional.

In the round, I would see them as almost synonyms, and their meanings and usage (and perhaps the faint distinctions) are really no different from plain English.

Some may attempt to give highly detailed definitions, but I would warn that these are often particular to individuals or small groups rather than general to the field, and there may be significant difficulties in applying these definitions in practice.

The apparent binary distinction between "functional/non-functional" is a particular bugbear of mine.

If "non-functional" means anything, it means a requirement which is so broadly stated that it is impossible to measure whether a system meets this requirement by any mechanical means. They are often either human factors requirements, or they are a complex sea of competing requirements, which cannot all be satisfied absolutely, and the resolution of which requires a great deal of judgment and business common sense to find a happy medium or a good integration.

These kinds of requirements are often the most vexatious for outsourced models of software production, as the entire outsourced staff may lack the "businese common sense" of the client business, and (in the absence of mechanical measures) conflict is likely to arise later over whether the requirements are met, or whether the cost of meeting them is incorporated into an existing charge or is charged additionally.

A large amount of judgment and experience also tends to go into the prior question of whether a requirement is "functional" (i.e. relatively unambiguous, well-analysed and understood, and specific in its implementation and measurement, and thus not likely to be a source of significant financial risk or likely conflict with the client), or "non-functional" (i.e. relatively ambiguous and a source of high risk).

In keeping with my warning above though, other opinions may differ, and I would avoid using these terms myself unless also providing a definition.

  • Whilst non-functional requirements can become overly broad, to me that is not how they should be used. I make a distinction between functional requirements, which relate directly to the outcomes a feature aims to add, and non-functional requirements which relate more to expectations (often of the overall product) which need to be maintained. Examples of non-functionals to me (extending the shopping cart example used in another answer here): user data in transit must be encrypted, total request time should not exceed 200ms 95% of the time and should not exceed 2000ms 99.99% of the time. Commented Aug 8, 2022 at 21:18
  • @JesseBugden, but there always are a set of "overly broad requirements", some of which require a harmonious settlement to be devised between competing individual requirements, some of which might not even reveal themselves until there is about to be a gross violation of them, at which point all involved can suddenly see the existence of the possibility, and the importance of the unexpected requirements being met. As I say, mostly the distinction is between mechanically measurable and non-mechanically measurable, and the latter category often contains the most important criteria.
    – Steve
    Commented Aug 9, 2022 at 6:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.