Comments on: Business Requirements, Project Scope, and Coupling http://tynerblain.com/blog/2007/02/21/business-requirements-project-scope/ Software product success. Thu, 18 Mar 2010 20:39:50 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Scott Sehlhorst http://tynerblain.com/blog/2007/02/21/business-requirements-project-scope/comment-page-1/#comment-72658 Scott Sehlhorst Fri, 23 Feb 2007 02:41:19 +0000 http://tynerblain.com/blog/2007/02/21/business-requirements-project-scope/#comment-72658 Thanks Roger. I was definitely staying "on message" with the value-drives-requirements point. And Robin's presentation of this idea does lend support to your argument (which I'm not trying to cover here :). Thanks, Scott Thanks Roger. I was definitely staying “on message” with the value-drives-requirements point. And Robin’s presentation of this idea does lend support to your argument (which I’m not trying to cover here :).

Thanks,
Scott

]]> By: Roger L. Cauvin http://tynerblain.com/blog/2007/02/21/business-requirements-project-scope/comment-page-1/#comment-72480 Roger L. Cauvin Thu, 22 Feb 2007 04:07:36 +0000 http://tynerblain.com/blog/2007/02/21/business-requirements-project-scope/#comment-72480 I agree completely with the point you're trying to make, and I know you worded things carefully to avoid a debate over semantics that might distract from the underlying point. But I do have to note that Goldsmith implies that "system requirement" is a misnomer: "System requirements represent a human-defined product or system which presumably is one of the possible ways presumably how to accomplish the presumed REAL business requirements. As such, system requirements actually are a form of high-level design." And he also implies that nomenclatures that categorize so-called "system requirements" as requirements are partially to blame for substantive, practical problems: "[T]he primary reason the REAL business requirements are not defined adequately is because conventional requirements models mislead people into believing that system requirements are the requirements and thus warrant all the attention." Again, I agree with your point and believe that your underlying thrust is the same as Goldsmith's. But I do think it's important to recognize that semantics are very relevant (in a substantive way) to the issue, in my view, and apparently in Goldsmith's view. I agree completely with the point you’re trying to make, and I know you worded things carefully to avoid a debate over semantics that might distract from the underlying point.

But I do have to note that Goldsmith implies that “system requirement” is a misnomer:

“System requirements represent a human-defined product or system which presumably is one of the possible ways presumably how to accomplish the presumed REAL business requirements. As such, system requirements actually are a form of high-level design.”

And he also implies that nomenclatures that categorize so-called “system requirements” as requirements are partially to blame for substantive, practical problems:

“[T]he primary reason the REAL business requirements are not defined adequately is because conventional requirements models mislead people into believing that system requirements are the requirements and thus warrant all the attention.”

Again, I agree with your point and believe that your underlying thrust is the same as Goldsmith’s. But I do think it’s important to recognize that semantics are very relevant (in a substantive way) to the issue, in my view, and apparently in Goldsmith’s view.

]]>