Address the following feedback for the milestone 2 documentation:
Domain requirements are the requirements that we get from the domain concepts. That means in order to represent the concepts from the domain on the system-to-be the system-to-be must have these properties. For example, if we observe in the domain this someone who buys a textbook at one time sells another (or even the same) at another time, then we conclude that people can be sellers and buyers. That's a domain property. We can derive a domain requirement (or even several) from this: "the system-to-be must provide means for people with an account to act as sellers as well as to act as buyers for different transactions."
I've said this many times: requirements need to require! That means they need to be worded in a certain way. "Shall allow" is not strong enough: an adversary developer could not do anything, then just claim they are satisfying the requirement arguing that they are not forbidding e.g. students to register and that therefore they are allowing it and that therefore they are satisfying the requirement. This is just too passive. What you might want to say is that your system-to-be shall provide the means for users to register.
The next one is also flawed: "users must" does not require anything of the system-to-be. It requires something of the users. Again, an adversary developer might say: "you should not have let them become users, if they are not able to..." or put another way and thinking about business process reengineering, this might be understood as a business process reengineering requirement, that is, it might be understood that the people who will use the system-to-be must first have this ability.
Register and login are not domain requirements for another reason: in the domain there's nothing to register or login to, these are not concepts that even exist in the domain.
To state that there is a domain requirement "search and filter" we would have to make it plausible from the domain description that in the domain there are - at least related - concepts. What could be the domain concepts after which our notion of "search" is modeled? What does is mean when we search for something on a market where used items are for sale? Here's a first try: "we say a person searches for an item, if that person already knows that they want to buy that kind of item (at a reasonable price) or at least they know some of the key characteristics of the item they want to buy and they visit the marketplace with the intention of buying an item that has these key characteristics". This may not yet be the actual description that you want to use for the term "search", but it still illustrates how such a description would look: always keep in mind that we're after explaining how the concepts relate to one another in a way that's independent of the way in which it is implemented, whether as an actual market to which people go and shop in person or as an online platform, we're after the common concepts here.
More "allow"s...
Enable communication between seller and buyer, that's a very high level goal or - at the lowest - an objective, but for a requirement it is too high level. Also, how does this derive from the domain? What's the domain property that gives rise to this requirement (if it were a requirement)?
"Should" does not make requirements! What if that which "should" be isn't? Well, since it only should be, things might still be alright, right? A requirement must require beyond doubt (at least beyond such direct doubts). A requirement must answer questions like: do we have to do this? And it can only answer such a question by clearly stating that which must be satisfied. Our requirements are the basis of legal agreements: "did the development team comply with their contractual responsibilities or not?" A "should" has no place here (as well-meaning as the might be).
Address the following feedback for the milestone 2 documentation:
Domain requirements are the requirements that we get from the domain concepts. That means in order to represent the concepts from the domain on the system-to-be the system-to-be must have these properties. For example, if we observe in the domain this someone who buys a textbook at one time sells another (or even the same) at another time, then we conclude that people can be sellers and buyers. That's a domain property. We can derive a domain requirement (or even several) from this: "the system-to-be must provide means for people with an account to act as sellers as well as to act as buyers for different transactions."
I've said this many times: requirements need to require! That means they need to be worded in a certain way. "Shall allow" is not strong enough: an adversary developer could not do anything, then just claim they are satisfying the requirement arguing that they are not forbidding e.g. students to register and that therefore they are allowing it and that therefore they are satisfying the requirement. This is just too passive. What you might want to say is that your system-to-be shall provide the means for users to register.
The next one is also flawed: "users must" does not require anything of the system-to-be. It requires something of the users. Again, an adversary developer might say: "you should not have let them become users, if they are not able to..." or put another way and thinking about business process reengineering, this might be understood as a business process reengineering requirement, that is, it might be understood that the people who will use the system-to-be must first have this ability.
Register and login are not domain requirements for another reason: in the domain there's nothing to register or login to, these are not concepts that even exist in the domain.
To state that there is a domain requirement "search and filter" we would have to make it plausible from the domain description that in the domain there are - at least related - concepts. What could be the domain concepts after which our notion of "search" is modeled? What does is mean when we search for something on a market where used items are for sale? Here's a first try: "we say a person searches for an item, if that person already knows that they want to buy that kind of item (at a reasonable price) or at least they know some of the key characteristics of the item they want to buy and they visit the marketplace with the intention of buying an item that has these key characteristics". This may not yet be the actual description that you want to use for the term "search", but it still illustrates how such a description would look: always keep in mind that we're after explaining how the concepts relate to one another in a way that's independent of the way in which it is implemented, whether as an actual market to which people go and shop in person or as an online platform, we're after the common concepts here.
More "allow"s...
Enable communication between seller and buyer, that's a very high level goal or - at the lowest - an objective, but for a requirement it is too high level. Also, how does this derive from the domain? What's the domain property that gives rise to this requirement (if it were a requirement)?
"Should" does not make requirements! What if that which "should" be isn't? Well, since it only should be, things might still be alright, right? A requirement must require beyond doubt (at least beyond such direct doubts). A requirement must answer questions like: do we have to do this? And it can only answer such a question by clearly stating that which must be satisfied. Our requirements are the basis of legal agreements: "did the development team comply with their contractual responsibilities or not?" A "should" has no place here (as well-meaning as the might be).
Recommended Difficulty: 3 Recommended Urgency: 3