Great Question.
It is important to distinguish between 'Development' and 'R&D.'
R&D = experimenting with ideas/technology that may never actually
become a product.
Software Development = working on a product/service desired by a real
customer.
R&D is all about developing new solutions for a specific problem
domain. The end result of this endeavor is something that I call
"research toys".
To be a software product, the research toy has to be completely
re-implemented. Failure to do so will result in a product that
appeals to an increasingly elite and erudite user base. The problem
here is that this elite and erudite user base typically has no money
to spend.
To be a successful, the software product must be a faithful
re-implementation of the research toy, accessible and loved by the
commodity user. To be truely remarkable, the software product must
simultaneously appeal to the elite and erudite user.
Research implies scholarly or scientific inquiry and tends to be aimed
at the greater good of an industry or society at large. Product
development has different motivations and outcomes: it is driven by
the potential for profit. The state of product development is healthy.
The state of lighting research is not.
We need a collective commitment to the greater good to answer such
questions. But this is not just philanthropy; the answer would address
a practical goal. Light sources that are spectrally tuned to the
visual system will be more sustainable. They will use less energy by
generating their output in regions of the spectrum where the visual
system responds most strongly, resulting in better seeing for building
users. This example reinforces the difference between research and
product development.
All development of new products to be R&D. I think some of you are
confusing pure, abstract science with R&D. They aren't the same. R&D
can be very product oriented. Scientists may be looking for a vaccine
to cure AIDs. That is a very specific task to create a product to sell
and it is certainly R&D and not just guys sitting around messing
about with whatever they feel like.
R&D in the technical world = finding ways to do something interesting
or important, using known techniques and technology as a starting point.
Software development = finding ways to do something interesting or
important, using known techniques and technology as a starting point.
Virtually all software development is the D part of R&D. Some times,
there are very little R in Software 'R&D'. Some times, there are pretty
large R in Software 'R&D'.
It depends on several measurement. For example,
Managing software development for various sized companies, R&D takes
on different meanings depending on the size of the company, customer
base, etc.
In a small software company, with only a hand full of employees, the
line between R&D software and Production software is usually very
small. What one day is a software R&D project, may the next day be
shipping as production software to customers.
As software companies grow, and they have one or more production
software lines, they tend to create greater separation between R&D
software projects and Production software products (for obvious
reasons). This R&D gap is typically created to create greater
diversification in their software products for tomorrow, while
allowing the production software development to continue to produce
today.
This is not to say that the production software products won't get
innovative new features. The production software developers are
typically just as "sharp" as the R&D developers. In fact, at one
company, we had an enrichment program that allowed production software
developers to rotate in and out of R&D projects. This not only added
fresh brain power to the R&D teams, but in many cases, the production
developers came back with new ideas on producing better production
level software.
D = "knowing where you want to be at the end", and R is because "at
the beginning of the project, you don't know what will be required to
get there"
R&D are the lucky folks who get to do anything they want without
accountability.
Good research/resource on this topic :
Q: Do QA teams focus and Functional Requirements whereas development team focus primarily on functional specification though they need to have an understanding of functional requirements?
The two are closely related. For small efforts, the requirements can be developed to a level of detail where they can also be used as the specification. In general, Functional Requirements are the customer-centric statement of what a system should do. Functional Specifications are a more detailed description of the Functional Requirements. For example:
- Rqmt: The customer shall be able to change the upper alarm limit temperature
- Spec: Selecting the parameter::alarms::temperature menu item shall bring up a pop-up form that allows the user to enter a value between 50 and 100 for the alarm limit.
Functional specifications are still in the realm of describing what a system does, not how it does it. Because of this, QA teams should be interested in the Functional Specifications for several reasons, among them are:
- The QA team needs to ensure that proper reviews have been covered to determine that the Functional Specifications are consistent with the requirements, and that they are complete.
- Each of the Functional Specifications are testable, so the QA team needs to make sure the tests are defined and the software product passes those tests.
Q: I assume QA would sign off the product as long as the functional requirements are met irrespective of whether the functional specification is followed or not. Is my assumption correct?
Whether or not QA signs off on a product that deviated from the specification depends in part on what process was followed when decisions were made to make changes. If the development team followed the change processes, QA would not have any problems. (Note -- these processes should insure that proper communications about these changes occur). However if a development team goes off and decides on their own there are a lot of risks that even though their efforts satisfy the requirements, their efforts may be rejected by QA, other business units in their organization, and even the end users.
That is not to say that a development team is bound by the specifications. It is OK for a development team to deliver something that deviates from the original specifications. However making decisions to implements something different that what is in the specifications should be made unilaterally. Mature organizations will have some defined change control processes to accommodate changes. QA will be making sure such processes are followed.
Best Answer
Functional requirements: What the system is supposed to do, process orders, send bills, regulate the temperature etc. etc.
Operational requirements: These are about how to run the system. Logging, startup/shutdown controls, monitoring, resource consumption, back up, availability etc.etc.
Technical requirements: These are about how the system is built. Which language, which OS, standards to be adhered to etc.
These days "operational' and "technical" requirements are usually bundled together as "non-functional requirements"—mainly to stop silly arguments as to whether "system will respond to a user request within 1 second" is an operational or technical requirement.