11. Usability and Humanity RequirementsThis section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users. 11a. Ease of Use RequirementsContentThis section describes your client's aspirations for how easy it is for the intended users of the product to operate it. The product's usability is derived from the abilities of the expected users of the product and the complexity of its functionality. The usability requirements should cover properties such as these:
MotivationTo guide the product's designers toward building a product that meets the expectations of its eventual users. ExamplesThe product shall be easy for 11-year-old children to use. The product shall help the user to avoid making mistakes. The product shall make the users want to use it. The product shall be used by people with no training, and possibly no understanding of English. Fit CriterionThese examples may seem simplistic, but they do express the intention of the client. To completely specify what is meant by the requirement, you must add a measurement against which it can be testedthat is, a fit criterion. Here are the fit criteria for the preceding examples: Eighty percent of a test panel of 11-year-old children shall be able to successfully complete [list of tasks] within [specified time]. One month's use of the product shall result in a total error rate of less than 1 percent. An anonymous survey shall show that 75 percent of the intended users are regularly using the product after a three-week familiarization period. ConsiderationsRefer to section 3, Users of the Product, to ensure that you have considered the usability requirements from the perspective of all the different types of users. It may be necessary to have special consulting sessions with your users and your client to determine whether any special usability considerations must be built into the product. You could also consider consulting a usability laboratory experienced in testing the usability of products that have a project situation (sections 17 of this template) similar to yours. 11b. Personalization and Internationalization RequirementsContentThis section describes the way in which the product can be altered or configured to take into account the user's personal preferences or choice of language. The personalization requirements should cover issues such as the following:
MotivationTo ensure that the product's users do not have to struggle with, or meekly accept, the builder's cultural conventions. ExamplesThe product shall retain the buyer's buying preferences. The product shall allow the user to select a chosen language. ConsiderationsConsider the country and culture of the potential customers and users of your product. Any out-of-country users will welcome the opportunity to convert to their home spelling and expressions. By allowing users to customize the way in which they use the product, you give them the opportunity to participate more closely with your organization as well as enjoy their own personal user experience. You might also consider the configurability of the product. Configurability allows different users to have different functional variations of the product. 11c. Learning RequirementsContentRequirements specifying how easy it should be to learn to use the product. This learning curve ranges from zero time for products intended for placement in the public domain (e.g., a parking meter or a Web site) to a considerable amount of time for complex, highly technical products. (We know of one product where it was necessary for graduate engineers to spend 18 months in a training program before being qualified to use the product.) MotivationTo quantify the amount of time that your client feels is allowable before a user can successfully use the product. This requirement guides designers to understand how users will learn the product. For example, designers may build elaborate interactive help facilities into the product, or the product may be packaged with a tutorial. Alternatively, the product may have to be constructed so that all of its functionality is apparent upon first encountering it. ExamplesThe product shall be easy for an engineer to learn. A clerk shall be able to be productive within a short time. The product shall be able to be used by members of the public who will receive no training before using it. The product shall be used by engineers who will attend five weeks of training before using the product. Fit CriterionAn engineer shall produce a [specified result] within [specified time] of beginning to use the product, without needing to use the manual. After receiving [number of hours] training a clerk shall be able to produce [quantity of specified outputs] per [unit of time]. [Agreed percentage] of a test panel shall successfully complete [specified task] within [specified time limit]. The engineers shall achieve [agreed percentage] pass rate from the final examination of the training. ConsiderationsRefer to section 3, Users of the Product, to ensure that you have considered the ease of learning requirements from the perspective of all the different types of users. 11d. Understandability and Politeness RequirementsThis section is concerned with discovering requirements related to concepts and metaphors that are familiar to the intended end users. ContentThis specifies the requirement for the product to be understood by its users. While "usability" refers to ease of use, efficiency, and similar characteristics, "understandability" determines whether the users instinctively know what the product will do for them and how it fits into their view of the world. You can think of understandability as the product being polite to its users and not expecting them to know or learn things that have nothing to do with their business problem. MotivationTo avoid forcing users to learn terms and concepts that are part of the product's internal construction and are not relevant to the users' world. To make the product more comprehensible and thus more likely to be adopted by its intended users. ExamplesThe product shall use symbols and words that are naturally understandable by the user community. The product shall hide the details of its construction from the user. ConsiderationsRefer to section 3, Users of the Product, and consider the world from the point of view of each of the different types of users. 11e. Accessibility RequirementsContentThe requirements for how easy it should be for people with common disabilities to access the product. These disabilities might be related to physical disability or visual, hearing, cognitive, or other abilities. MotivationIn many countries it is required that some products be made available to the disabled. In any event, it is self-defeating to exclude this sizable community of potential customers. ExamplesThe product shall be usable by partially sighted users. The product shall conform to the Americans with Disabilities Act. ConsiderationsSome users have disabilities other than the commonly described ones. In addition, some partial disabilities are fairly common. A simple, and not very consequential, example is that approximately 20 percent of males are red-green colorblind. 12. Performance Requirements12a. Speed and Latency RequirementsContentSpecifies the amount of time available to complete specified tasks. These requirements often refer to response times. They can also refer to the product's ability to operate at a speed suitable for the intended environment. MotivationSome productsusually real-time productsmust be able to perform some of their functionality within a given time slot. Failure to do so may mean catastrophic failure (e.g., a ground-sensing radar in an airplane fails to detect an upcoming mountain) or the product will not cope with the required volume of use (e.g., an automated ticket-selling machine). ExamplesAny interface between a user and the automated system shall have a maximum response time of 2 seconds. The response shall be fast enough to avoid interrupting the user's flow of thought. The product shall poll the sensor every 10 seconds. The product shall download the new status parameters within 5 minutes of a change. Fit CriterionFit criteria are needed when the description of the requirement is not quantified. However, we find that most performance requirements are stated in quantified terms. The exception is the second requirement shown above, for which the suggested fit criterion is The product shall respond in less than 1 second for 90 percent of the interrogations. No response shall take longer than 2.5 seconds. ConsiderationsThere is a wide variation in the importance of different types of speed requirements. If you are working on a missile guidance system, then speed is extremely important. By contrast, an inventory control report that is run once every six months has very little need for a lightning-fast response time. Customize this section of the template to give examples of the speed requirements that are important within your environment. 12b. Safety-Critical RequirementsContentQuantification of the perceived risk of damage to people, property, and environment. Different countries have different standards, so the fit criteria must specify precisely which standards the product must meet. MotivationTo understand and highlight the damage that could potentially occur when using the product within the expected operational environment. ExamplesThe product shall not emit noxious gases that damage people's health. The heat exchanger shall be shielded from human contact. Fit CriterionThe product shall be certified to comply wih the Health Department's standard E110-98. It is to be certified by qualified testing engineers. No member of a test panel of [specified size] shall be able to touch the heat exchanger. The heat exchanger must also comply with safety standard [specify which one]. ConsiderationsThe example requirements given here apply to some, but not all, products. It is not possible to give examples of every variation of safety-critical requirement. To make the template work in your environment, you should customize it by adding examples that are specific to your products. Also, be aware that different countries have different safety standards and laws relating to safety. If you plan to sell your product internationally, you must be aware of these laws. A colleague has suggested that for electrical products, if you follow the German standards, the largest number of countries will be supported. If you are building safety-critical systems, then the relevant safety-critical standards are already well specified. You will likely have safety experts on your staff. These experts are the best source of the relevant safety-critical requirements for your type of product. They will almost certainly have copious information that you can use. Consult your legal department. Members of this department will be aware of the kinds of lawsuits that have resulted from product safety failure. This is probably the best starting place for generating relevant safety requirements. 12c. Precision or Accuracy RequirementsContentQuantification of the desired accuracy of the results produced by the product. MotivationTo set the client's and users' expectations for the precision of the product. ExamplesAll monetary amounts shall be accurate to two decimal places. Accuracy of road temperature readings shall be within ±2°C. ConsiderationsIf you have done any detailed work on definitions, then some precision requirements might be adequately defined by definitions in section 5. You might consider which units the product is intended to use. Readers will recall the spacecraft that crashed on Mars when coordinates were sent as metric data rather than imperial data. The product might also need to keep accurate time, be synchronized with a time server, or work in UTC. Also, be aware that some currencies have no decimal places, such as the Japanese yen. 12d. Reliability and Availability RequirementsContentThis section quantifies the necessary reliability of the product. The reliability is usually expressed as the allowable time between failures, or the total allowable failure rate. This section also quantifies the expected availability of the product. MotivationIt is critical for some products not to fail too often. This section allows you to explore the possibility of failure and to specify realistic levels of service. It also gives you the opportunity to set the client's and users' expectations about the amount of time that the product will be available for use. ExamplesThe product shall be available for use 24 hours per day, 365 days per year. The product shall be available for use between the hours of 8:00 A.M. and 5:30 P.M The escalator shall run from 6 A.M.until 10 P.M. or the last flight arrives. The product shall achieve 99 percent uptime. ConsiderationsConsider carefully whether the real requirement for your product is that it is available for use or that it does not fail at any time. Consider also the cost of reliability and availability, and whether it is justified for your product. 12e. Robustness or Fault-Tolerance RequirementsContentRobustness specifies the ability of the product to continue to function under abnormal circumstances. MotivationTo ensure that the product is able to provide some or all of its services after or during some abnormal happening in its environment. ExamplesThe product shall continue to operate in local mode whenever it loses its link to the central server. The product shall provide 10 minutes of emergency operation should it become disconnected from the electricity source. ConsiderationsAbnormal happenings can almost be considered normal. Today's products are so large and complex that there is a good chance that at any given time, one component will not be functioning correctly. Robustness requirements are intended to prevent total failure of the product. You could also consider disaster recovery in this section. This plan describes the ability of the product to reestablish acceptable performance after faults or abnormal happenings. 12f. Capacity RequirementsContentThis section specifies the volumes that the product must be able to deal with and the amount of data stored by the product. MotivationTo ensure that the product is capable of processing the expected volumes. ExamplesThe product shall cater for 300 simultaneous users within the period from 9:00 A.M. to 11:00 A.M. Maximum loading at other periods will be 150 simultaneous users. During a launch period, the product shall cater for a maximum of 20 people to be in the inner chamber. Fit CriterionIn this case, the requirement description is quantified, and thus can be tested. 12g. Scalability or Extensibility RequirementsContentThis specifies the expected increases in size that the product must be able to handle. As a business grows (or is expected to grow), our software products must increase their capacities to cope with the new volumes. MotivationTo ensure that the designers allow for future capacities. ExamplesThe product shall be capable of processing the existing 100,000 customers. This number is expected to grow to 500,000 customers within three years. The product shall be able to process 50,000 transactions per hour within two years of its launch. Longevity RequirementsContentThis specifies the expected lifetime of the product. MotivationTo ensure that the product is built based on an understanding of expected return on investment. ExamplesThe product shall be expected to operate within the maximum maintenance budget for a minimum of five years. 13. Operational and Environmental Requirements13a. Expected Physical EnvironmentContentThis section specifies the physical environment in which the product will operate. MotivationTo highlight conditions that might need special requirements, preparations, or training. These requirements ensure that the product is fit to be used in its intended environment. ExamplesThe product shall be used by a worker, standing up, outside in cold, rainy conditions. The product shall be used in noisy conditions with a lot of dust. The product shall be able to fit in a pocket or purse. The product shall be usable in dim light. The product shall not be louder than the existing noise level in the environment. ConsiderationsThe work environment: Is the product to operate in some unusual environment? Does this lead to special requirements? Also see section 11, Usability and Humanity Requirements. 13b. Requirements for Interfacing with Adjacent SystemsContentThis section describes the requirements to interface with partner applications and/or devices that the product needs to successfully operate. MotivationRequirements for the interfaces to other applications often remain undiscovered until implementation time. Avoid a high degree of rework by discovering these requirements early. ExamplesThe products shall work on the last four releases of the five most popular browsers. The new version of the spreadsheet must be able to access data from the previous two versions. Our product must interface with the applications that run on the remote weather stations. Fit CriterionFor each inter-application interface, specify the following elements:
Productization RequirementsContentAny requirements that are necessary to make the product into a distributable or salable item. It is also appropriate to describe here the operations needed to install a software product successfully. MotivationTo ensure that if work must be done to get the product out the door, then that work becomes part of the requirements. Also, to quantify the client's and users' expectations about the amount of time, money, and resources they will need to allocate to install the product. ExamplesThe product shall be distributed as a ZIP file. The product shall be able to be installed by an untrained user without recourse to separately printed instructions. The product shall be of a size such that it can fit on one CD. ConsiderationsSome products have special needs to turn them into a salable or usable product. You might consider that the product has to be protected such that only paid-up customers can access it. Ask questions of your marketing department to discover unstated assumptions that have been made about the specified environment and the customers' expectations of how long installation will take and how much it will cost. Most commercial products have some needs in this area. 13d. Release RequirementsSpecification of the intended release cycle for the product and the form that the release shall take. MotivationTo make everyone aware of how often you intend to produce new releases of the product. ExamplesThe maintenance releases will be offered to end users once a year. Each release shall not cause previous features to fail. Fit CriterionDescription of the type of maintenance plus the amount of effort budgeted for it. ConsiderationsDo you have any existing contractual commitments or maintenance agreements that might be affected by the new product? 14. Maintainability and Support Requirements14a. Maintenance RequirementsContentA quantification of the time necessary to make specified changes to the product. MotivationTo make everyone aware of the maintenance needs of the product. ExamplesNew MIS reports must be available within one working week of the date when the requirements are agreed upon. A new weather station must be able to be added to the system overnight. ConsiderationsThere may be special requirements for maintainability, such as that the product must be able to be maintained by its end users or by developers who are not the original developers. These requirements have an effect on the way that the product is developed. In addition, there may be requirements for documentation or training. You might also consider writing testability requirements in this section. Supportability RequirementsContentThis specifies the level of support that the product requires. Support is often provided via a help desk. If people will provide support for the product, that service is considered part of the product: Are there any requirements for that support? You might also build support into the product itself, in which case this section is the place to write those requirements. MotivationTo ensure that the support aspect of the product is adequately specified. ConsiderationsConsider the anticipated level of support, and what forms it might take. For example, a constraint might state that there is to be no printed manual. Alternatively, the product might need to be entirely self-supporting. 14c. Adaptability RequirementsContentDescription of other platforms or environments to which the product must be ported. MotivationTo quantify the client's and users' expectations about the platforms on which the product will be able to run. ExamplesThe product is expected to run under Windows XP and Linux. The product might eventually be sold in the Japanese market. The product is designed to run in offices, but we intend to have a version running in restaurant kitchens. Fit Criterion
ConsiderationsQuestion your marketing department to discover unstated assumptions that have been made about the portability of the product. 15. Security Requirements15a. Access RequirementsContentSpecification of who has authorized access to the product (both functionality and data), under what circumstances that access is granted, and to which parts of the product access is allowed. MotivationTo understand the expectations for confidentiality aspects of the system. ExamplesOnly direct managers can see the personnel records of their staff. Only holders of current security clearance can enter the building. Fit Criterion
ConsiderationsIs there any data that management considers to be sensitive? Is there any data that low-level users do not want management to have access to? Are there any processes that might cause damage or might be used for personal gain? Are there any people who should not have access to the system? Avoid stating how you will design a solution to the security requirements. For instance, don't "design a password system." Your aim here is to identify the security requirement; the design will then come from this description. Consider asking for help. Computer security is a highly specialized field, and one where improperly qualified people have no business. If your product has need of more than average security, we advise you to make use of a security consultant. Such consultants are not cheap, but the results of inadequate security can be even more expensive. 15b. Integrity RequirementsContentSpecification of the required integrity of databases and other files, and of the product itself. MotivationTo understand the expectations for the integrity of the product's data. To specify what the product will do to ensure its integrity in the case of an unwanted happening such as attack from the outside or unintentional misuse by an authorized user. ExamplesThe product shall prevent incorrect data from being introduced. The product shall protect itself from intentional abuse. ConsiderationsOrganizations are relying more and more on their stored data. If this data should be come corrupt or incorrector disappearthen it could be a fatal blow to the organization. For example, almost half of small businesses go bankrupt after a fire destroys their computer systems. Integrity requirements are aimed at preventing complete loss, as well as corruption, of data and processes. 15c. Privacy RequirementsContentSpecification of what the product has to do to ensure the privacy of individuals about whom it stores information. The product must also ensure that all laws related to privacy of an individual's data are observed. MotivationTo ensure that the product complies with the law, and to protect the individual privacy of your customers. Few people today look kindly on organizations that do not observe their privacy. ExamplesThe product shall make its users aware of its information practices before collecting data from them. The product shall notify customers of changes to its information policy. The product shall reveal private information only in compliance with the organization's information policy. The product shall protect private information in accordance with the relevant privacy laws and the organization's information policy. ConsiderationsPrivacy issues may well have legal implications, and you are advised to consult with your organization's legal department about the requirements to be written in this section. Consider what notices you must issue to your customers before collecting their personal information. A notice might go so far as to warn customers that you intend to put a cookie in their computer. Also, do you have to do anything to keep customers aware that you hold their personal information? Customers must always be in a position to give or withhold consent when their private data is collected or stored. Similarly, customers should be able to view any private data and, where appropriate, ask for correction of the data. Also consider the integrity and security of private datafor example, when you are storing credit card information. Audit RequirementsContentSpecification of what the product has to do (usually retain records) to permit the required audit checks. MotivationTo build a system that complies with the appropriate audit rules. ConsiderationsThis section may have legal implications. You are advised to seek the approval of your organization's auditors regarding what you write here. You should also consider whether the product should retain information on who has used it. The intention is to provide security such that a user may not later deny having used the product or participated in some form of transaction using the product. Immunity RequirementsContentThe requirements for what the product has to do to protect itself from infection by unauthorized or undesirable software programs, such as viruses, worms, and Trojan horses, among others. MotivationTo build a product that is as secure as possible from malicious interference. ConsiderationsEach day brings more malevolence from the unknown, outside world. People buying software, or any other kind of product, expect that it can protect itself from outside interference. 16. Cultural and Political Requirements16a. Cultural RequirementsContentThis section contains requirements that are specific to the sociological factors that affect the acceptability of the product. If you are developing a product for foreign markets, then these requirements are particularly relevant. MotivationTo bring out in the open requirements that are difficult to discover because they are outside the cultural experience of the developers. ExamplesThe product shall not be offensive to religious or ethnic groups. The product shall be able to distinguish between French, Italian, and British road-numbering systems. The product shall keep a record of public holidays for all countries in the European Union and for all states in the United States. ConsiderationsQuestion whether the product is intended for a culture other than the one with which you are familiar. Ask whether people in other countries or in other types of organizations will use the product. Do these people have different habits, holidays, superstitions, or cultural norms that do not apply to your own culture? Are there colors, icons, or words that have different meanings in another cultural environment? 16b. Political RequirementsContentThis section contains requirements that are specific to the political factors that affect the acceptability of the product. MotivationTo understand requirements that sometimes appear irrational. ExamplesThe product shall be installed using only American-made components. The product shall make all functionality available to the CEO. ConsiderationsDid you intend to develop the product on a Macintosh, when the office manager has laid down an edict that only Windows machines are permitted? Is a director also on the board of a company that manufactures products similar to the one that you intend to build? Whether you agree with these political requirements has little bearing on the outcome. The reality is that the system has to comply with political requirements even if you can find a better, more efficient, or more economical solution. A few probing questions here may save some heartache later. The political requirements might be purely concerned with the politics inside your organization. However, in other situations you may need to consider the politics inside your customers' organizations or the national politics of the country. 17. Legal Requirements17a. Compliance RequirementsContentA statement specifying the legal requirements for this system. MotivationTo comply with the law so as to avoid later delays, lawsuits, and legal fees. ExamplesPersonal information shall be implemented so as to comply with the Data Protection Act. Fit CriterionLawyers' opinion that the product does not break any laws. ConsiderationsConsider consulting lawyers to help identify the legal requirements.
17b. Standards RequirementsContentA statement specifying applicable standards and referencing detailed standards descriptions. This does not refer to the law of the land think of it as an internal law imposed by your company. MotivationTo comply with standards so as to avoid later delays. ExampleThe product shall comply with MilSpec standards. The product shall comply with insurance industry standards. The product shall be developed according to SSADM standard development steps. Fit CriterionConsiderationsIt is not always apparent that there are applicable standards because their existence is often taken for granted. Consider the following:
18. Open IssuesIssues that have been raised and do not yet have a conclusion. ContentA statement of factors that are uncertain and might make significant difference to the product. MotivationTo bring uncertainty out in the open and provide objective input to risk analysis. ExamplesOur investigation into whether the new version of the processor will be suitable for our application is not yet complete. The government is planning to change the rules about who is responsible for gritting the motorways, but we do not know what those changes might be. ConsiderationsAre there any issues that have come up from the requirements gathering that have not yet been resolved? Have you heard of any changes that might occur in the other organizations or systems on your context diagram? Are there any legislative changes that might affect your system? Are there any rumors about your hardware or software suppliers that might have an impact? 19. Off-the-Shelf Solutions19a. Ready-Made ProductsContentList of existing products that should be investigated as potential solutions. Reference any surveys that have been done on these products. MotivationTo give consideration to whether a solution can be bought. ConsiderationsCould you buy something that already exists or is about to become available? It may not be possible at this stage to make this determination with a lot of confidence, but any likely products should be listed here. Also consider whether some products must not be used. 19b. Reusable ComponentsContentDescription of the candidate components, either bought from outside or built by your company, that could be used by this project. List libraries that could be a source of components. MotivationReuse rather than reinvention. 19c. Products That Can Be CopiedContentList of other similar products or parts of products that you can legally copy or easily modify. MotivationReuse rather than reinvention. ExamplesAnother electricity company has built a customer service system. Its hardware is different from ours, but we could buy its specification and cut our analysis effort by approximately 60 percent. ConsiderationsWhile a ready-made solution may not exist, perhaps something, in its essence, is similar enough that you could copy, and possibly modify, it to better effect than starting from scratch. This approach is potentially dangerous because it relies on the base system being of good quality. This question should always be answered. The act of answering it will force you to look at other existing solutions to similar problems. 20. New Problems20a. Effects on the Current EnvironmentContentA description of how the new product will affect the current implementation environment. This section should also cover things that the new product should not do. MotivationThe intention is to discover early any potential conflicts that might otherwise not be realized until implementation time. ExamplesAny change to the scheduling system will affect the work of the engineers in the divisions and the truck drivers. ConsiderationsIs it possible that the new system might damage some existing system? Can people be displaced or otherwise affected by the new system? These issues require a study of the current environment. A model highlighting the effects of the change is a good way to make this information widely understandable. 20b. Effects on the Installed SystemsContentSpecification of the interfaces between new and existing systems. MotivationVery rarely is a new development intended to stand completely alone. Usually the new system must coexist with some older system. This question forces you to look carefully at the existing system, examining it for potential conflicts with the new development. 20c. Potential User ProblemsContentDetails of any adverse reaction that might be suffered by existing users. MotivationSometimes existing users are using a product in such a way that they will suffer ill effects from the new system or feature. Identify any likely adverse user reactions, and determine whether we care about those reactions and what precautions we will take. 20d. Limitations in the Anticipated Implementation Environment That May Inhibit the New ProductContentStatement of any potential problems with the new automated technology or new ways of structuring the organization. MotivationThe intention is to make early discovery of any potential conflicts that might otherwise not be realized until implementation time. ExamplesThe planned new server is not powerful enough to cope with our projected growth pattern. The size and weight of the new product do not fit into the physical environment. The power capabilities will not satisfy the new product's projected consumption. ConsiderationsThis requires a study of the intended implementation environment. 20e. Follow-Up ProblemsContentIdentification of situations that we might not be able to cope with. MotivationTo guard against situations where the product might fail. ConsiderationsWill we create a demand for our product that we are not able to service? Will the new system cause us to run afoul of laws that do not currently apply? Will the existing hardware cope? There are potentially hundreds of unwanted effects. It pays to answer this question very carefully. 21. Tasks21a. Project PlanningContentDetails of the life cycle and approach that will be used to deliver the product. A high-level process diagram showing the tasks and the interfaces between them is a good way to communicate this information. MotivationTo specify the approach that will be taken to deliver the product so that everyone has the same expectations. ConsiderationsDepending on the maturity level of your process, the new product will be developed using your standard approach. However, some circumstances are unique to a particular product and will necessitate changes to your life cycle. While these considerations are not product requirements, they are needed if the product is to be successfully developed. If possible, attach an estimate of the time and resources needed for each task based on the requirements that you have specified. Attach your estimates to the events, use cases, and/or functions that you specified in sections 8 and 9. Do not forget issues related to data conversion, user training, and cutover. These needs are usually ignored when projects set implementation dates. Planning of the Development PhasesContentSpecification of each phase of development and the components in the operating environment. MotivationTo identify the phases necessary to implement the operating environment for the new system so that the implementation can be managed. Fit Criterion
ConsiderationsIdentify which hardware and other devices are necessary for each phase of the new system. This list may not be known at the time of the requirements process, as these devices may be decided at design time. 22. Migration to the New Product22a. Requirements for Migration to the New ProductContentA list of the conversion activities. Timetable for implementation. MotivationTo identify conversion tasks as input to the project planning process. Considerations
22b. Data That Has to Be Modified or Translated for the New SystemContentList of data translation tasks. MotivationTo discover missing tasks that will affect the size and boundaries of the project. Fit Criterion
ConsiderationsEvery time you make an addition to your dictionary (see section 5), ask this question: Where is this data currently held, and will the new system affect that implementation? 23. RisksAll projects involve risknamely, the risk that something will go wrong. Risk is not necessarily a bad thing, as no progress is made without taking some risk. However, there is a difference between unmanaged risksay, shooting dice at a craps tableand managed risk, where the probabilities are well understood and contingency plans are made. Risk is only a bad thing if the risks are ignored and they become problems. Risk management entails assessing which risks are most likely to apply to the project, deciding a course of action if they become problems, and monitoring projects to give early warnings of risks becoming problems. This section of your specification should contain a list of the most likely risks and the most serious risks for your project. For each risk, include the probability of that risk becoming a problem. Capers Jones's Assessment and Control of Software Risks (Prentice Hall, 1994) gives comprehensive lists of risks and their probabilities; you can use these lists as a starting point. For example, Jones cites the following risks as being the most serious:
Use your knowledge of the requirements as input to discover which risks are most relevant to your project. It is also useful input to project management if you include the impact on the schedule, or the cost, if the risk does become a problem. 24. CostsFor details on how to estimate requirements effort and costs, refer to appendix C, Function Point Counting: A Simplified Introduction. The other cost of requirements is the amount of money or effort that you have to spend building them into a product. Once the requirements specification is complete, you can use one of the estimating methods to assess the cost, expressing the result as a monetary amount or time to build. There is no best method to use when estimating. Keep in mind, however, that your estimates should be based on some tangible, countable artifact. If you are using this template, then, as a result of doing the work of requirements specification, you are producing many measurable deliverables. For example:
The more detailed the work you do on your requirements, the more accurate your deliverables will be. Your cost estimate is the amount of resources you estimate each type of deliverable will take to produce within your environment. You can create some very early cost estimates based on the work context. At that stage, your knowledge of the work will be general, and you should reflect this vagueness by making the cost estimate a range rather than a single figure. As you increase your knowledge of the requirements, we suggest you try using function point countingnot because it is an inherently superior method, but because it is so widely accepted. So much is known about function point counting that it is possible to make easy comparisons with other products and other installations' productivity. It is important that your client be told at this stage what the product is likely to cost. You usually express this amount as the total cost to complete the product, but you may also find it advantageous to point out the cost of the requirements effort as a whole, or the costs of individual requirements. Whatever you do, do not leave the costs in the lap of hysterical optimism. Make sure that this section includes meaningful numbers based on tangible deliverables. 25. User Documentation and Training25a. User Documentation RequirementsContentList of the user documentation to be supplied as part of the product. MotivationTo set expectations for the documentation and to identify who will be responsible for creating it. Examples
ConsiderationsWhich documents do you need to deliver, and to whom? Bear in mind that the answer to this questions depends on your organizational procedures and roles. For each document, consider these issues:
What level of documentation is expected? Will the users be involved in the production of the documentation? Who will be responsible for keeping the documentation up-to-date? What form will the documentation take? 25b. Training RequirementsContentA description of the training needed by users of the product. MotivationTo set expectations for the training. To identify who is responsible for creating and providing that training. ConsiderationsWhat training will be necessary? Who will design the training? Who will provide the training? Waiting RoomRequirements that will not be part of the next release. These requirements might be included in future releases of the product. ContentAny type of requirement. MotivationTo allow requirements to be gathered, even though they cannot be part of the current development. To ensure that good ideas are not lost. ConsiderationsThe requirements-gathering process often throws up requirements that are beyond the sophistication of, or time allowed for, the current release of the product. This section holds these requirements in waiting. The intention is to avoid stifling the creativity of your users and clients, by using a repository to retain future requirements. You are also managing expectations by making it clear that you take these requirements seriously, although they will not be part of the agreed-upon product. Many people use the waiting room as a way of planning future versions of the product. Each requirement in the waiting room is tagged with its intended version number. As a requirement progresses closer to implementation, then you can spend more time on it and add details such as the cost and benefit attached to that requirement. You might also prioritize the contents of your waiting room. "Low-hanging fruit"requirements that provide a high benefit at a low cost of implementationare the highest-ranking candidates for the next release. You would also give a high waiting room rank to requirements for which there is a pent-up demand. Ideas for SolutionsWhen you gather requirements, you focus on finding out what the real requirements are and try to avoid coming up with solutions. However, when creative people start to think about a problem, they always generate ideas about potential solutions. This section of the template is a place to put those ideas so that you do not forget them and so that you can separate them from the real business requirements. ContentAny idea for a solution that you think is worth keeping for future consideration. This can take the form of rough notes, sketches, pointers to other documents, pointers to people, pointers to existing products, and so on. The aim is to capture, with the least amount of effort, an idea that you can return to later. MotivationTo make sure that good ideas are not lost. To help you separate requirements from solutions. ConsiderationsWhile you are gathering requirements, you will inevitably have solution ideas; this section offers a way to capture them. Bear in mind that this section will not necessarily be included in every document that you publish. |