When to use which requirement type

When to use which requirement type

• Scott0620

  Yes, I will post a blog entry on this subject by the end of the week. Thanks for the great idea! I talk about this in my MSF presentations all the time.
  
  Randy
  MSF
  
  

• Ashok76

  Thanks, Randy. That would be very helpful!
  
  

• chandrashekar

  Yes and no - potentially. :-)
  
  It is reasonable that customer requirements are broken down directly into tasks (developer, user experience, architecture, user education, and test) in the Analysis workstream while product requirements are generated separately to focus on internal concerns such as the flexibility or longenvity of the architecture or a product line type concern where reusable components are desirable. These are not necessarily concerns of the customer.
  
  Hence, product requirements are most likely to be internally generated and also broken down into tasks in the Analysis work stream. It is these tasks which are are planned as backlog for any given iteration.
  
  However, in some situations and domains, it may be desirable to break customer requirements into functional product requirements. While the CMMI process definition allows for this, it does not prescribe or mandate it.
  
  

• hushtech

  Just a quick search on google, nothing more.
  http://www.google.com/search hl=en&lr=&oi=defmore&defl=en&q=define:functional+requirement
  
  Thanks for the info.
  
  

• Jigs_1979

  Hi Randy
  
  I was waiting for your blog entry on the explanation of various Requirement types. You said you will post it - have you post it already If yes, then please provide me the link. If no, then when you are planning to do that, please let us know.
  
  If you know some other references that can help me on this issue, please let me know.
  
  Thanks,
  Mamun
  
  

• Patrik Schneider

  In CMMI there is a requirement to separate out the difference between customer requirements and product requirements. The former come from the customer (surprise) and the latter are generated internally for business reasons. We've provided 7 types of requirements which can be grouped as
  
  Customer Requirements
  ----------------------
  Scenario
  Quality of Service Req
  
  Product Requirements
  ---------------------
  Functional
  Operational
  Interface
  Safety
  Security
  
  

• Matjaž

  Randy, did you get a chance to blog on this subject yet
  
  

• Glenn87

  I'd love to know where your quote comes from.
  
  Actually none of this is real rocket science, we simply took our cue from the CMMI specification. We're following their lead on what represents a functional specification. A functional spec typicallty doesn't come from the customer. It is the technical sides interpretation of the customers needs. It is for this reason that it is classified as a product requirement.
  
  

• Dave_R

  Do customer requirements get broken down into product requirements which then in turn get broken down into tasks
  
  

• OberCanober

  This is very good info. I'm starting to get my head around what you're saying. I'm a little confused that functional requirements are listed under the product requirement heading and not the customer requirement heading. Isn't the definition of a functional requirement, "A specification contraining the way in which a given task is to be performed, the results to be obtained as well as the elements of the functional entities involved" I would think the customer would be the driver of such a requirement, but I'm sure you can clear up my misunderstanding.
  
  

• TSZ

  Are there any webcasts that you gave on this subject that I should take a look at
  
  
• When to use which requirement type