Talk:Requirement/Archives/2020
 | This is an archive of past discussions about Requirement. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Notes on Externally Observable
Regarding the following text:
"To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present geocoded information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture."
This text doesn't provide any references and it looks like a personal opinion, including certain amount of arrogance ("To the above some add [...]", "Such advocates[...]"). It also fails to notice basic system requirements principles.
- Requirements are not only observable or experienced by "users", but also by external systems. The system context, key part of a requirements specification, defines what external entities (user classes and systems) interact with the system under study, and the specification must include the interface requirements with those external systems, in addition to user observed behavior.
- The given example fails to notice that the "interface with an external third party business partner" is a case of an external entity interacting with the system. The fact that "The interface will be imperceptible to the user" doesn't mean that this is not observed behavior, since the behavior will be observed through the interface with the external system.
- The remark "a constraint limits design alternatives, whereas a requirement specifies design characteristics." may require a more extended and generic explanation rather than the limited example "a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture". This example is both quite non-generic (as an example) and abundant in technology specific jargon (as a requirement). A counter example, in this case, would be a single requirement specifying that "the system shall request an id and password to users only once in a session" seems to properly address the single sign-on architecture constraint and the web service interface requirement in a more neutral way (although is implicitly prescribing a specific way to identify and authenticate users).
- References to "Such advocates" would be much welcome as well. A quick web search gave this reference Donald G. Firesmith: “Common Requirements Problems, Their Negative Consequences, and Industry Best Practices to Help Solve Them”, in Journal of Object Technology, vol. 6, no. 1, January-February 2007, pp. 17-33 http://www.jot.fm/issues/issue_2007_01/column2, p18 in which the author writes By poor requirements quality , I specifically mean that far too many ‘requirements’ specified in real requirements specifications are [...] not restricted to externally-visible behavior or properties of the system [...]
In short, I think the paragraph above should be either deleted (to avoid propagating misconceptions, half truths and confusing readers), or rewritten to properly address the "Externally Observable" quality of a requirement debate (if any, and including references on both sides if so).