I believe the definition of a requirement has been defined by many in the requirements engineering field. A good definition that I like is from: Scenarios, Stories, and Use Cases, by Ian F. Alexander and Neil Maiden (Wiley publishing 2004) – Page 509 of the Glossary (Requirement)
“A statement that a System is to satisfy, whether
a) By providing a desired Functional result such as may be delivered by Scenario or Scenario Step;
b) By having a desired quality such as a given measure of performance or reliability (a Non-Functional Requirement or ‘-ility”;
c) Satisfying some external Constraint such as an interface definition or a physical size, power consumption, and so on.”
There are many other good definitions of a requirement, and identify what makes a requirement “good.”
“Software Requirements”, 2nd Edition, by Karl E. Wiegers. The following is a list of the paragraph headings that occur under a section titled “Requirement Statement Characteristics” (page 22 – 25):
Complete, Correct, Feasible, Necessary, Prioritized, Unambiguous, and Verifiable.
He goes on with a section titled “Requirement Specification Characteristics” specific to “sets of requirements that are collected into a specification…”:
Complete, Consistent, Modifiable, and Traceable.
A scenario is a specific set of steps to describe one interaction with the system (e.g. a specific pathway through an activity diagram) used to both elicite, verify, and validate requirements for the goal of that use case.
If an activity diagram is being created for a use case, then following good practices, their should not be more than 3 - 10 steps. So the scenarios of a use case should NOT be inordiately complex. If they are it may be indication of a need to re-factor the use case into one or more additional use cases. The steps are NOT requirements for the design, but merely a way to discuss a conceptual interaction with the system as part of the analysis process.
The scenarios of a use case can also be a great way to review requirements within a business context, limited by the chosen scenario (this helps keep the scope of the review small and precise) and by the stakeholders of the system (users, developers, customer, etc.) with the goal of getting agreement that the requirements specified are both correct and robust enough to meet the needs of the users and the design/development team.
Remember that the scenario steps DO NOT and SHOULD NOT be constraints on the design (unless they have been and are intended to be constraints), but the scenario goals MUST be able to be attained by the solution and verified through testing that the requirements have been met.
A UseCase, an Activity Diagram, a Scenario are NOT requirements, they do not meet the definition of a requirement. They are analysis artifacts used to elicite and verify the requirements of the system.
I'm sure you can find many other good sources on the web, in books, etc. that clearly specify what a requirement is and the characteristics of “excellent” requirements.
On a side note:” Please try to keep a civil tone. In trying to make our point we should not name drop, brag about our experience or background. But try to answer the questions of comments with examples, clarifications, suggestions, etc. It is easy when reading a post to mistake enthusiasm for a point-of-view or opinion for something else which may have the affect of limiting the discussion or keeping other forum members from posting their comments.
Thanks, David
