Difference between a Software Requirement, a Feature and an Objective

Question

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.

Answer 1

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 ;-))

Answer 2

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
  

Answer 3

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.