Return to Answer

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. Example: "The system shall allow only valid contract types to be entered".
• A feature is something that the system offers: it's part of the solution, regardless of the underlying needs it adresses. Example: "A drop-down list provides a choice between possible contract types". May be this feature addresses one or several requirements, maybe none.
• 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. But in practice, it's often difficult to distinguish the requirement from the feature. It's often easier for a user to think of a feature rather than to abstract the requirement:

• It has the advantage of a clear understanding of the expectations, and quick agreement on the target solution.
• It has the drawback that potential alternative solutions (other features that would better address the same underlying requirement) are ignored (I'm thinking now for the reason of all these calendar picker that force me to use the mouse to scroll 50 years backwards, when I could just have entered the birth year in four keystrokes ;-))

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

About the terminology:

• A requirement expresses a need that the system has to fulfil, in principle independently of the solution that will be chosen. Example: "The system shall allow only valid contract types to be entered".
• A feature is something that the system offers: it's part of the solution, regardless of the underlying needs. Example: "A drop-down list provides a choice between possible contract types". May be this feature addresses a requirement, 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. But in practice, it's often difficult to distinguish the requirement from the feature. It's often easier for a user to think of a feature rather than to abstract the requirement:

• It has the advantage of a clear understanding of the expectations, and quick agreement on the target solution.
• It has the drawback that potential alternative solutions (other features that would better address the same underlying requirement) are ignored (I'm thinking now for the reason of all these calendar picker that force me to use the mouse to scroll 50 years backwards, when I could just have entered the birth year in four keystrokes ;-))

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. Example: "The system shall allow only valid contract types to be entered".
• A feature is something that the system offers: it's part of the solution, regardless of the underlying needs it adresses. Example: "A drop-down list provides a choice between possible contract types". May be this feature addresses one or several requirements, maybe none.
• 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. But in practice, it's often difficult to distinguish the requirement from the feature. It's often easier for a user to think of a feature rather than to abstract the requirement:

• It has the advantage of a clear understanding of the expectations, and quick agreement on the target solution.
• It has the drawback that potential alternative solutions (other features that would better address the same underlying requirement) are ignored (I'm thinking now for the reason of all these calendar picker that force me to use the mouse to scroll 50 years backwards, when I could just have entered the birth year in four keystrokes ;-))

About the terminology:

• A requirement expresses a need that the system has to fulfil, in principle independently of the solution that will be chosen. Example: "The system shall allow only valid contract types to be entered".
• A feature is something that the system offers: it's part of the solution, regardless of the underlying needs. Example: "A drop-down list provides a choice between possible contract types". May be this feature addresses a requirement, 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.

About the terminology:

• A requirement expresses a need that the system has to fulfil, in principle independently of the solution that will be chosen. Example: "The system shall allow only valid contract types to be entered".
• A feature is something that the system offers: it's part of the solution, regardless of the underlying needs. Example: "A drop-down list provides a choice between possible contract types". May be this feature addresses a requirement, 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. But in practice, it's often difficult to distinguish the requirement from the feature. It's often easier for a user to think of a feature rather than to abstract the requirement:

• It has the advantage of a clear understanding of the expectations, and quick agreement on the target solution.
• It has the drawback that potential alternative solutions (other features that would better address the same underlying requirement) are ignored (I'm thinking now for the reason of all these calendar picker that force me to use the mouse to scroll 50 years backwards, when I could just have entered the birth year in four keystrokes ;-))