REFS Keynote: "Requirements for Services: Does it Make Sense?"

Summary form only given. Since the dawn of computers, we have struggled with the best ways to record requirements for our software-based systems. Many thousands of papers have been written that describe "new" ways to discover, prune, write, interrelate, test, and manage changes to, software requirements. However, there are two trends (one historic and one future) worth examining more closely: (1) Historic. "Systems" and "products" have been around for many centuries before the advent of computers; requirements have only become important since computers because software has given us so much more flexibility in the features we provide to our customers. Before software, products were constructed of plastic, metal, and wood and little flexibility existed. (2) Future. With the advent of widespread broadband access to the internet, more and more companies are discovering the economies of "delivering" software not as a product but as a service. This relatively new "Software as a Service" (SOS) business model raises the issue of whether the lessons we have learned about discovering, pruning, writing, interrelating, testing, and managing changes to, software requirements still apply. But more importantly, just as software has given us incredible flexibility in the features of our products (no longer built exclusively of physical materials), now software has given us the same kind of flexibility in the features of our services (no longer based solely on human delivery). What lessons still apply? Is the business of requirements engineering unchanged? Or do new principles apply to requirements for services?