- general principles
- requirements engineering principles
principle 1 ：quality is
A customer will not tolerate a product with poor quality, regardless of the definition of quality. Quality must be quantified and mechanisms put into place to motivate and reward its achievement. It may seem politically correct to deliver a product on time, even though its quality is poor, but it is politically correct in the short term only；it is political suicide in the middle and long term. There is no trade-off to be made. The first requirement must be quality. Edward Yourdom suggests that you "Just say no" when you're asked to speed up testing, ignore a few bugs, or code before agreeing on a design or a set of requirements.
principle 2：quality is in the eyes of the beholder
There is no one definition of software quality. To developers, it might be an elegant design or elegant code. To users who work in stress environments, it might be response time or high capacity. For cost-sensitive projects, it might be low development cost. For some customers, it might be satisfying all their perceived and not-yet-perceived needs. The dilemma is that these may not be all compatible. Optimizing one person'quality might be detrimental to another's. (This is Weinberg's Political Dilemma principle) A project must decide on its priorities and articulate them to all parties.
principle 3：productivity and quality are inseparable
There is a clear relationship between productivity(measured by numbers of widgits--whether they be lines of code or function points--per person-month) and quality. The higher the demand for quality, the lower your productivity becomes. The lower the demand for quality, the higher your productivity becomes. The more you emphasize increased productivity, the lower your resulting quality. Bell Labs has found that, to achieve one to two bugs per thousand lines of code, productivities of 150 to 300 lines of code per person-month are common . As attempts are made to drive productivity up, the density of bugs increases.
principle 4 : high-quality software is possible
Although our industry is saturated with examples of software systems that perform poorly, that are full of bugs, or that otherwise fail to satisfy users’ needs, there are counter examples.large-scale software systems can be built with very high quality, but for a steep price tag: on the order of $1000 per line of code. One such example is IBMS on-board flight software for NASAS space shuttle. Totaling approximately three million lines of code,the rigorous software development process resulted in less than one error found per ten thousand lines of code after product release.
As a developer, be aware of the techniques that have been demon-strated to increase quality considerably. These include involving the customer(Principle 8), prototyping(to verify requirements prior to full-scale development; Principles 11 through 13), keeping the design simple (Principle 67), inspections(Principle 98), and hiring the best people ( Principles 130 and 131). As a customer, demand excellence but be aware of the high costs involved
principle 5 : don’t try to retrofit quality
Quality cannot be retrofit into software .This applies to any definition of quality: maintainability, reliability, adaptability, testability, safety, and so on. We have a very difficult time building quality into software during development when we try to. How can we possibly expect to achieve quality when we don’ t try? This is primarily why you must not try to convert a throwaway prototype into a product(Principle 11).
principle 6 : poor reliability is worse than poor efficiency
When software is not efficient, it is generally possible to isolate the sections of the program that consume most of the execution time and redesign or recode them for increased efficiency(Principle 194).Poor reliability is not only more difficult to detect, it is also more difficult to fix.A system’s poor reliability may not become apparent until years after the system is deployed–and it kills somebody.Once the poor reliability manifests itself, it is often difficult to isolate its cause.
principle 7 : give products to customers early
No matter how hard you try to learn users’needs during the requirements phase, the most effective means to ascertain their real needs is to give them a product and let them play with it.If you follow a conventional interpretation of the waterfall model, the first delivery of a product to the customer occurs after 99 percent of the development resources are already expended.Thus, the majority of customer feedback on their needs occurs after the resources are expended.Contrast that with an approach, for example, of constructing a quick and dirty prototype early in the development process.Deliver this to the customer, gather feedback, and then write a requirements specification and proceed with a full-scale development.In this scenario, only 5 to 20 percent of the development resources are expended by the time customers experience their first product.f the appropriate features were built into the prototype, the highest-risk user needs will become better known and the final product is more likely to be user-satisfactory.This helps ensure that the remainder of the resources are spent building the right system.
principle 8 : communicate with customers/users
Never lose sight of why software is being developed:to satisfy real needs,to solve real problems.The only way to solve real needs is to communicate with those who have the needs.The customer or user is the most important person involved with your project.If you are a commercial developer, talk often with the clients.Keep them involved.Sure, it is easier to develop software in a vacuum, but will the customer like the result?If you’re a producer of shrinkwrap software,”customers”are harder to locate during development.So role-play.Designate three or four individuals in your organization as prospective customers and tap them for ideas that will keep them as customers or make them happy.If you’re a government contractor, talk often with the contracting officers, their technical representatives, and, if possible, the users.People and situations change often in the government.the only way to keep up with the change is communication.Ignoring the changes may make life seem easier in the short term, but the final system will not be useful.
principle 9 : align incentives for developer and customer
Projects often fail because customers and developers have different(and perhaps incompatible) goals.For example, take the simple case in which the customer wants features 1, 2, and 3 by a specific date and the developer wants to maximize revenue or profit.To maximize revenue the develper may attempt to build all three features in their entirety even if late.To maximize revenue the develper may attempt to build all three features in their entirety even if late.To help align the two organizations’ goals:
(1)Prioritize requirements (Principle 50)so that developers understand their relative importance,
(2) reward the developer based on the relative priorities(for example, all highpriority requirements must be satisfied, each medium priority requirement earns the developer a small additional bonus of some kind and each low priority requirement satisfied earns a very small bonus),
(3)use strict penalties for late delivery
principle 10 : plan to throw one away
One of the most important critical success factors for a project is whether it is entirely new.Programs that tread on brand new territory(whether it be with respect to application, architecture, interface, or algorithm) rarely work the first time.Fred Brooks, in his Mythical Man Month, makes this perfectly clear with his advice, “Plan to throw one away; you will anyway.”This advice was originally presented by Winston Royce in 1970, when he said one should plan for the first fully deployed system to be the second one created.The first should at least check out the critical design issues and the operational concept.Furthermore Royce recommended that such a prerelease version should be developed with approximately 25 percent of the total system development resources.As a developer of a new custom product, plan to build a series of throwaway prototypes(Principles 11, 12, and 13)before embarking on the full-scale product development.As a commercial high-volume developer expect that your first product version will be able to be modified for a certain period of years, after which it will need to be fully replaced(related Principles 185, 186, 188, and 201).As a maintainer of a product, be aware that you can fiddle with the program just so much before it becomes unstable and must be replaced (see related Principles 186, 191, 195, and 197).
