Software Requirements

Examples of Bad (Vague and Untestable) Requirements	Examples of Good (at Least Better) Requirements
The system shall be responsive.	The system shall provide the correct response to 99.9% of user inputs. The system shall provide a response within 1 second to 98% of user inputs.
The system shall be user-friendly.	The system user interface shall employ a graphical user interface and permit input with a mouse.
The system shall be reliable.	The system shall run uniterrupted for at least 1,000 hours during normal use.

Requirements define the problem: they tell you what the software needs to do. The rest of the steps in the traditional software development process create the solution. To create requirements, an engineer takes the customer's general statement of need and turns it into a specific description of what the software should do.

If you don't know exactly what the software is supposed to do (that is, if the requirements are wrong or vague), then how can you do the right thing?

Take the examples on this slide. The bad (vague and untestable) requirements can be interpreted differently by different people (and usually are). What, exactly, does "responsive" mean? What the developer thinks is "responsive" is probably not what the customer thinks is responsive.

Wrong or vague requirements are responsible for some of the biggest problems industry has with the traditional process (in fact, problems in requirements are often cited as industry's #1 software problem):

Customers often don't know what they really need.
Customers' actual needs change (even as the software is being developed).
Customers do not communicate their needs to software developers clearly and completely.

Requirements are hard to write down; they need to be complete, cover all of the details, and work together. This becomes nearly impossible when the number of detailed requirements gets up into the thousands. The exercise after this unit will help you understand how hard it is to write detailed, specific requirements.

Megaprogramming helps you in the requirements stage. How does megaprogramming do this?

Review

What have been your requirements for the programs you've been writing in this class? How important have they been to you in writing the right program?
Which of the requirements in the right column are still vague? How can they be improved?
Why is the requirements step the most important step of the software development process?