The online community for software testing & quality assurance professionals
 
 
Calendar   Today's Topics
Sponsors:




Lost Password?

Home
BetaSoft
Blogs
Jobs
Training
News
Links
Downloads



Quality Engineering >> Requirements and Design

Pages: 1
stevew
Unregistered




What is a "design requirement"?
      #302011 - 12/16/01 11:25 PM

In my past experience, I've learned that a "marketing requirement" is a high level functional or non-functional requirement. It defines the "what". A "functional specification" is a quantified or testable version of the "marketing requirement". It defines the "how". But what is a "design requirement"?

I recently returned from a supplier audit, during which the CEO told me that my company never communicated what ambient temperature range the product should be able to function reliably within. He referred to it as a "design specification", but my boss insists that what we didn't communicate was a "design requirement" not a "design specification". I think my boss means, "Product shall function reliably within a temp range of 0degC to 40degC." is a "designe requirement" whereas "operating temp range = 0degC to 40degC" is a "design specification". Correct?

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
Jeff Nyman
Moderator


Reged: 12/28/99
Posts: 1875
Loc: Chicago,Illinois,USA
Re: What is a "design requirement"?
      #302012 - 12/17/01 03:33 AM

quote:
Originally posted by stevew:
In my past experience, I've learned that a "marketing requirement" is a high level functional or non-functional requirement. It defines the "what". A "functional specification" is a quantified or testable version of the "marketing requirement". It defines the "how". But what is a "design requirement"?

In general, I think you are going to see a "design requirement" be described as something which involves implementation of a solution to a real problem within the given context of technology.

With that, it is already implicitly stated in your other defintions. You have a set of business/marketing requirements that are derived into functional requirements. Then you come up with how you will test those - which is implicit (usually) within the functional specification.

The design is the constraint of the functionality. In other words, the "how" has to be implemented within the context of some design. Obviously, in many cases, you can have more than one possible design to satisfy a set of requirements, although some designs will be more optimal than others.

So, in your example, the ambient temperature range is a statement of a functional requirement and a quality requirement. The product should function within that range. This is because you should break up requirement types as such:

Function: what it does.
Quality: how well it does it.
Cost: resources needed to allow it to do function well.
Constraints: limitations

So the requirements are your "ends." The design is your "means" to the end. The design is a means of providing the functions, with quality and cost attributes, under given constraints. (You can see that design should map to your requirements.)

quote:
"Product shall function reliably within a temp range of 0degC to 40degC." is a "designe requirement"

This is a statement of how the product should function. It also contains the word "reliably" which is bad form for a requirement. That should be quantified. And when it is quantified it will also become a quality requirement ("how well it does it" from my above list).

But this is not a statement of design - it is a statement of function.

Remember: functions are what a system does, independently of how well it does it (benefit, quality) or at what costs (in terms of any resource). In describing a system you need to describe functions, qualities, and resources with respect to time, space, and a set of conditions. functions are often confused with design. Designs are the means by which we achieve desired quality and cost levels. We must be able to distinguish between native functions of a system, and the design ideas we are looking for, in order to improve the quality and cost attributes of these functions.

quote:
"operating temp range = 0degC to 40degC" is a "design specification".

Technically you could say this is a constraint within the requirements, because it still describes how the device should function (within a given range). The overall requirement is that the object must work within a certain temperature range. The constraint is the range "0degC" to "40degC". The means by which the product will work within that temperature range is a design. So if in order to work at the range the product has to be designed a certain way, that is a design requirement. If, further, you want the product to be blue in color with a red light on top, those are design requirements. (By contrast, how the red light functions, is, of course, a functional requirement.) All the design requirements are placed in a design specification.

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
AitenB
Unregistered




Re: What is a "design requirement"?
      #302013 - 12/17/01 08:20 PM

quote:
Originally posted by JeffNyman:
Function: what it does.
Quality: how well it does it.
Cost: resources needed to allow it to do function well.
Constraints: limitations

Jeff - I noticed you use this distinction in a couple of posts. Do you highlight this requirements breakdown as a function of cost when you present that kind of thing? Or do you use ranges for the requirements or just assign numeric values (like priorities) to the requirements?

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
Jeff Nyman
Moderator


Reged: 12/28/99
Posts: 1875
Loc: Chicago,Illinois,USA
Re: What is a "design requirement"?
      #302014 - 12/18/01 06:20 AM

quote:
Originally posted by AitenB:
Do you highlight this requirements breakdown as a function of cost when you present that kind of thing? Or do you use ranges for the requirements or just assign numeric values (like priorities) to the requirements?

This is all just part of doing quantitative requirements. For me, quantitative requirements are crucial because they are the main competitive differentiator for a given functional area, aside from outright cost (which is a bottom-line business concern). However, to answer your direct questions, quantifying requirements is certainly about more than just adding numeric values to requirements statements. In general, I think the following are some of the basic steps that should always be adhered to:

(1.) All the quality concerns for the system have to be identified.
(2.) Scales of measure have to be assigned.
(3.) The required quality levels have to be stated.

We, as an industry, came off of a bad approach to requirements, particularly with things like waterfall models, because it led to this idea of there being some final necessary values for requirements, in terms of relational models of requirements. Evolutioanry delivery schemes have started to differentiate various quality levels for delivery to different stakeholders (customers and users) and, furthermore, it allowed for the division of that delivery under different stated conditions and at different stated times. In other words, it is contextual or situated requirements. Of course, while evolutionary cycles have fostered this approach, you will find many organizations do not adhere to it because the QA group does not push it. QA needs to be the driving force behind this concept.

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1



Extra information
0 registered and 8 anonymous users are browsing this forum.

Moderator:  blueinatl, swt88, AJ, Daniel_S 

Print Topic

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled

Rating:
Topic views: 1310

Rate this topic

Jump to

Contact Us | Privacy statement SQAForums

Powered by UBB.threads™ 6.5.5