We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings.
To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure no-reply@cambridge.org
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
For metrics to be useful, they must be consistent with our intuitions about the real world. As an example, defects can be a useful metric for product quality – the fewer severe defects, the better.
Rather than start each design from scratch, software architects tend to adapt earlier successful designs for similar problems. Even if they do not reuse any code, the solution approach gives them a head start with the current problem. Problems like fault tolerance have been addressed over and over again. (The idea for a solution is to have a live backup system that takes over if the primary system fails due to a hardware or software fault.)
All software projects face the twin questions of what users want and what to build to address those wants. These are related, but logically distinct questions. Requirements elicitation is the process of discovering user wants and writing them down as user requirements. Requirements analysis is the process of prioritizing user requirements from various sources and defining what to build as a product. In practice, elicitation and analysis are entwined: the same user-developer conversation can touch on a user goal, its priority, and acceptance tests for it.
Software testing is the process of running a program in a controlled environment to check whether it behaves as expected. The purpose of testing is to improve software quality. If a test fails – that is, the program does not behave as expected – there must be a fault, either in the program or in the specification of expected behavior. Either way, the test has uncovered a problem that should be resolved.
Once user needs and goals are recorded as user requirements, the emphasis shifts to requirements analysis. User requirements, even specific and measurable ones, correspond to wish lists from the various stakeholders. Requirements analysis prioritizes these wish lists to define precisely what to build as a product; see . To prioritize, we must answer three questions. First, what properties of the product will prioritization be based on? Examples of properties include not only cost and functionality, but usefulness, usability, and desirability. Second, how will the properties be quantified? Quantification involves classification into ranked categories; for example, must-have, should-have, could-have, won’t have. Third, how do we rank order requirements based on a combination of properties, such as benefit, cost, and perhaps risk?