Requirements describe in detail what a software or web system is supposed to do, and they are the first step toward a solution. You decide on the scope of the system before you begin programming or web development.

Requirements
--------------------------------
Requirements Prerequisites
--------------------------------
The requirements activity is also known as "requirements development," "requirements analysis," "analysis," "requirements definition," "software requirements," "specification," "functional spec," and "spec."

-------------------------------------------
Why Have Official Requirements?
------------------------------------------
An explicit set of requirements is important for several reasons.
Explicit requirements help to ensure that the user rather than the programmer drives the system's functionality. If the requirements are explicit, the user can review them and agree to them. If they're not, the programmer, developer or designer usually ends up making requirements decisions during coding. Explicit requirements keep you from guessing what the user, i.e client wants.

Explicit requirements also help to avoid arguments. If you have a disagreement with another programmer, designer or customer, about what the web system, program or applications is supposed to do, you can resolve it by looking at the written requirements, specifications and design guidelines.

------------------------------------------------------------
FASTER HORSES or new creative disruptive invention
DISRUPTIVE and REVOLUTIONARY APPLICATIONS
------------------------------------------------------------
You may have heard the Henry Ford quote:
If I'd asked customers what they wanted, they would have said "a faster horse".

His words finely describe customers' ostensible inability to communicate their unmet needs for innovative products. It was clear what people wanted - it wasn't faster horses. It was better, faster, cheaper and more reliable transport solution.
Often true innovation is created by singularly gifted visionaries who ignore customer input and instead manufacture innovation based solely on their prophetic vision for a better future.
Consumers don't demand what they don't understand. That is the reason that adoption of new creative disruptive invention often follows an S-curve. Pre-Ford consumers understood horses, but wished they were faster or cheaper or more resistant.
Consumers are great for improving what they already understand. Now that we understand the Apple iPad, we want it to be faster, lighter and cheaper or whatever, but five years ago, none of us knew we wanted one at all.
Innovation comes not from "consumers", crowd sourcing, or market research, but by an intuitive quantum innovative leap created by a very small group of experts or an individual genius, that has an innate ability to perceive a tacit desire among the "consumers" for something they themselves could not conceive.
An innovator should have understanding of one's customers and their problems via empirical, observational, anecdotal methods or even intuition. Sometimes, they should also feel free to ignore customers' inputs.

But in our conversations with customers, we shouldn't be focusing on features. We should be striving to understand the problems they face.
Regarding customer input, one very large software company trains people to ask customers what final result they want, not what feature they want.
It is the lesson that is worthy of our attention, that few consumers have the vision to predict or articulate beyond their most immediate needs. It takes contextual thinking to be able to identify the artificial constraints that limit our ability see beyond those limitations. The word for that is vision, as in G.B. Shaw's quote:

"You see things; and you say, 'Why?' But I dream things that never were; and I say, "Why not?"

-------------------
Pay ATTENTION
-------------------
Paying attention to requirements helps to minimize changes to a system after development begins. If you find a coding error during coding, you change a few lines of code and work goes on. If you find a requirements error during coding, you have to alter the design to meet the changed requirement. You might have to throw away part of the old design, and because it has to accommodate code that's already written, the new design will take longer than it would have in the first place. You also have to discard code and test cases affected by the requirement change and write new code and test cases. Even code that's otherwise unaffected must be retested so that you can be sure the changes in other areas haven't introduced any new errors.

-------------------
Pay ATTENTION
-------------------
Data from numerous organizations indicates that on large projects an error in requirements detected during the architecture stage is typically 3 times as expensive to correct as it would be if it were detected during the requirements stage.

If detected during coding, it's 5-10 times as expensive; during system test, 10 times;
and post-release, a whopping 10-100 times as expensive as it would be if it were detected during requirements development.

On smaller projects with lower administrative costs, the multiplier post-release is closer to 5-10 than 100 (Boehm and Turner 2004). In either case, it isn't money and precious time you'd want to waste.

---------------------------
Key to project success
---------------------------
Planning and specifying requirements adequately is a key to project success, perhaps even more important than effective construction techniques. Many good books have been written about how to specify requirements well. Consequently, the next few sections don't tell you how to do a good job of specifying requirements, they tell you how to determine whether the requirements have been done well and how to make the best of the requirements you have.
Without good requirements, you can have the right general problem but miss the mark on specific aspects of the problem.

----------------------------------------
The Myth of Stable Requirements
----------------------------------------
Stable requirements are the holy grail of software development. With stable requirements, a project can proceed from architecture to design to coding to testing in a way that's orderly, predictable, and calm. This is software heaven! You have predictable expenses, and you never have to worry about a feature costing 100 times as much to implement as it would otherwise because your user didn't think of it until you were finished debugging.
Requirements are like water. They're easier to build on when they're frozen.
-Anonoymous

It's fine to hope that once your client has accepted a requirements document, no changes will be needed. On a typical project, however, the customer can't reliably describe what is needed before the code is written.
The problem isn't that the customers are vague. Just as the more you work with the project, the better you understand it, the more they work with it, the better they understand it. The development process helps customers better understand their own needs, and this is a major source of requirements changes (Curtis, Krasner, and Iscoe 1988; Jones 1998; Wiegers 2003). A plan to follow the requirements rigidly is actually a plan not to respond to your customer.

How much change is typical? Studies at IBM and other companies have found that the average project experiences about a 25 percent change in requirements during development (Boehm 1981, Jones 1994, Jones 2000), which accounts for 70 to 85 percent of the rework on a typical project (Leffingwell 1997, Wiegers 2003).


----------------------------------------------------------------
Handling Requirements Changes During Construction
----------------------------------------------------------------
Here are several things you can do to make the best of changing requirements during construction:

Use the requirements checklist at the end of the section to assess the quality of your requirements If your requirements aren't good enough, stop work, back up, and make them right before you proceed. Sure, it feels like you're getting behind if you stop coding at this stage. But if you're driving from Chicago to Los Angeles, is it a waste of time to stop and look at a road map when you see signs for New York? No. If you're not heading in the right direction, stop and check your course.
Make sure everyone knows the cost of requirements changes Clients get excited when they think of a new feature. In their excitement, their blood thins and runs to their medulla oblongata and they become giddy, forgetting all the meetings you had to discuss requirements, the signing ceremony, and the completed requirements document. The easiest way to handle such feature-intoxicated people is to say, "Gee, that sounds like a great idea. Since it's not in the requirements document, I'll work up a revised schedule and cost estimate so that you can decide whether you want to do it now or later." The words "schedule" and "cost" are more sobering than coffee and a cold shower, and many "must haves" will quickly turn into "nice to haves."

Historically there are four types of requirement artifacts that we deal with, functional specification:
-1 the text requirements
-2 the use case, and business/domain glossary
-3 the process-flow diagram
-4 the screen-shots with GUI elements and mockup content
Simulation is actually new type of requirement, the 5th type of specification artifact, which has entered recently among the product specification artifacts. Only simulation can give the business customer real awareness that product specification correctly defines all his needs.
Simulation prototype with mockup data should be as realistic as possible, so the business customer can really give all his remarks, pinpoint all his needs, before the developers start to write code. And they can say - Yes this is exactly what I want!
On the other hand for developers is much easier to start to code when they see Simulation prototype with some mockup data or real production data, before the developers start to write code.

The early simulation is revolutionizing the whole process. What that future solution could look like prior to actually entering in the software design and coding stage.
The real difference is that:
- you can make the Walk-through of the future solution
- production scenarios can be tested
- real production data can be used to simulate the workflow step by step
- so the implementation errors can be avoided
- business customer will be confident that the solution will meet his requirements
- faster development cycles
- fewer surprises in end-user testing
- in rework phase there is a significant reduction
- the totality of effort and cost will be reduced
- more than 60% reduction in change orders