Every year about 50% of a company's spending, on average, is directed toward information communication technologies. Despite this willingness to invest in technology, 68% of information technologies projects fail, costing the global economy about $6.2-trillion a year. "We are wasting a massive amount of money on failed information systems projects. We haven't figured out how to do this well," says Derrick Neufeld, associate professor of Information Systems at the Richard Ivey School of Business.
Typically, an organization's processes span multiple systems, channels, applications, departments, and external partners. In this case, how do we monitor such processes? What is the current state of the organizational processes? What is the benchmark for poorly-performing processes and exceptional processes? Most of the time, organizations are unable to answer such questions, or only have a vague idea for various reasons. Either they are monitoring the process with a very limited scope, or the mechanisms for monitoring the process are not in place to allow such details to be available. We rarely find organizations with process owners having an end-to-end view of a process. The big picture of a process is not available to the decision makers on a real-time basis.
Every project has requirements. It doesn't matter if it's building hardware solutions, developing software solutions, installing networks, protecting data, or training users. For the project to be a success, knowing what the requirements are is an absolute must. Requirements exist for virtually any components of a project or task. For example, a project may require specific methods, expertise levels of personnel, or the format of deliverables. This whitepaper will discuss the various kinds of information technology requirements, their importance, the different requirement types, the concept of requirements engineering, and the process for gathering requirements.
This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these quality criteria.