Выкладывались только 91, 92, 404 стр. В редакции Ilgr стр. 191, 192 также отсутствуют.
Что действительно отсутствуют?
Стопудово нет. Я пытался сфотить, но не могу найти печатный экземпляр.
Пропало немного
Specify the number of transactions per second to be supported, response times, computational accuracy, and timing relationships for real-time systems. You could also specify memory and disk space requirements, concurrent user loads, or the maximum number of rows stored in database tables. If different functional requirements or features have different performance requirements, it's appropriate to specify those performance goals right with the corresponding functional requirements, rather than collecting them all in this one section.
Quantify the performance requirements as specifically as possible—for example, "95 percent of catalog database queries shall be completed within 3 seconds on a single-user 1.1-GHz Intel Pentium 4 PC running Microsoft Windows XP with at least 60 percent of the system resources free." An excellent method for precisely specifying performance requirements is Tom Gilb's Planguage, described in Chapter 12, "Beyond Functionality: Software Quality Attributes."
5.2 Safety Requirements
Safety and security are examples of quality attributes, which are more fully addressed in section 5.4. I've called these two attributes out in separate sections of the SRS template because if they are important at all, they are usually critical. In this section, specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product (Leveson 1995). Define any safeguards or actions that must be taken, as well as potentially dangerous actions that must be prevented. Identify any safety certifications, policies, or regulations to which the product must conform. Examples of safety requirements are
SA-1 The system shall terminate any operation within 1 second if the measured tank pressure exceeds 95 percent of the specified maximum pressure.
SA-2 The radiation beam shield shall remain open only through continuous computer control. The shield shall automatically fall into place if computer control is lost for any reason.
5.3 Security Requirements
Specify any requirements regarding security, integrity, or privacy issues that affect access to the product, use of the product, and protection of data that the product uses or creates. Security requirements normally originate in business rules, so identify any security or privacy policies or regulations to which the product must conform. Alternatively, you could address these requirements through the quality attribute called integrity. Following are sample security requirements:
SE-1 Every user must change his initially assigned login password immediately after his first successful login. The initial password may never be reused.
SE-2 A door unlock that results from a successful security badge read shall keep the door unlocked for 8.0 seconds.
5.4 Software Quality Attributes
State any additional product quality characteristics that will be important to either customers or developers. (See Chapter 12.) These characteristics should be specific, quantitative, and verifiable. Indicate the relative priorities of various attributes, such as ease of use over ease of learning, or portability over efficiency. A rich specification notation such as Planguage clarifies the needed levels of each quality much better than can simple descriptive statements.
6. Other Requirements
Define any other requirements that are not covered elsewhere in the SRS. Examples include internationalization requirements (currency, date formatting, language, international regulations, and cultural and political issues) and legal requirements. You could also add sections on operations, administration, and maintenance to cover requirements for product installation, configuration, startup and shutdown, recovery and fault tolerance, and logging and monitoring operations. Add any new sections to the template that are pertinent
правда я обнаружил ошибку
the designers to mirror the database in multiple geographical locations or to denormalize relational database tables for faster query responses.
в тексте перевода
разработчики могут зеркализовать базу данных в нескольких географических метаположениях или денормализовать связанные
таблиц баз данных для получения более быстрого ответа на запрос
location переведено (скорее распознано) как метаположениях - очевидно, что следует переводить местаположениях
зеркализовать - это вообще, по-моему, шедевр. Ясно, что так точнее передается смысл использования тут глагола to mirror - отражать или отображать
например, можно было бы перевести, что
разработчики могут сделать зеркало базы данных в нескольких географических местоположениях (а лучше точках), окончательно
разработчики могут сделать зеркало базы данных в нескольких географических точках
К Вигерс, Разработка требований к программному обеспечению--пропущенные страницы