Злые волшебники
Никто не может отрицать – создавать приложения становится все сложнее и сложнее. В частности, пользовательские интерфейсы становятся все более утонченными. Двадцать лет назад приложение среднего масштаба обошлось бы интерфейсом «стеклянного телетайпа» (а может быть, интерфейса не было бы и вовсе). Асинхронные терминалы обеспечивали интерактивное отображение символов, а устройства ввода (наподобие вездесущей IBM 3270) позволяли набирать целую экранную страницу перед нажатием клавиши SEND. Теперь пользователи требуют графический интерфейс с контекстно-зависимой справкой, средствами типа «вырезать и вставить», «перетащить и отпустить», средством OLE, много- или однодокументным интерфейсом. Пользователям потребна интеграция с web-браузером и поддержка архитектуры с тонким клиентом.
Усложняются и сами приложения. В настоящее время большинство разработок использует многозвенную модель, возможно, с промежуточным программным обеспечением или монитором транзакций. Эти программы отличаются динамичностью, гибкостью и способностью работать во взаимодействии с приложениями, написанными сторонними фирмами.
Кажется, мы не сказали о том, что нам это было нужно на прошлой неделе – вес и сразу!
Разработчики стараются быть в форме. Если бы мы использовали те же самые инструментальные средства, которые применялись для терминалов ввода-вывода двадцатилетней давности, то ничего бы не добились.
Поэтому производители инструментальных средств и поставщики средств инфраструктуры придумали палочку выручалочку – функцию-мастера. Это замечательное средство. Вам нужно приложение с многодокументным интерфейсом и поддержкой контейнера OLE? Один щелчок мыши, ответ на пару простых вопросов – и функция-мастер автоматически сгенерирует для вас скелет программы. При выполнении данного сценария среда Microsoft Visual С++ автоматически создает программу, содержащую свыше 1200 строк. Функции-мастера хорошо справляются и с другими заданиями. Вы можете воспользоваться мастерами при создании серверных компонентов, реализации Java beans, работе с сетевыми интерфейсами – все это достаточно сложные области, где не обойтись без помощи эксперта.
Но применение функции-мастера, спроектированной неким компьютерным гуру, не делает автоматически из разработчика Джо компьютерного эксперта. Джо чувствует себя недурно – он ведь сгенерировал большое количество исходного текста и довольно элегантную на вид программу. Ему нужно лишь добавить функциональную возможность, характерную для данного приложения, и программу можно отправлять заказчику. Но покуда Джо реально не осознает сути программы, сгенерированной от его имени, он вводит самого себя в заблуждение. Он программирует в расчете на стечение обстоятельств. Функция-мастер подобна улице с односторонним движением – она лишь «вырезает» программу и затем движется далее. Если сгенерированная программа не совсем правильна (или обстоятельства изменились), а вам необходимо адаптировать ее, вы остаетесь с ней один на один.
Мы не выступаем против функций-мастеров. Напротив, их созданию в книге посвящен целый раздел «Генераторы исходных текстов». Но если вы все же используете функцию-мастера и не понимаете всей создаваемой ею программы, то не сможете управлять вашим собственным приложением. Вы не сможете сопровождать его и будете затрачивать неимоверные усилия при отладке.
Подсказка 50: Не пользуйтесь программой функции-мастера, которую не понимаете
Некоторые полагают, что это совсем уж экстремистская позиция. Они говорят, что разработчики всегда основывают свою работу на предметах, которые до конца им непонятны, – на квантовой механике в интегральных схемах, схеме прерываний в процессоре, алгоритмах, используемых при диспетчеризации процессов, программах из имеющихся библиотек и т. д. Мы согласны. И мы придерживались бы того же мнения о функциях-мастерах, если бы они представляли собой просто набор библиотечных вызовов или стандартные службы операционной системы, на которые могли положиться разработчики. Но это не так. Функции-мастера генерируют программу, которая становится неотъемлемой частью приложения, написанного разработчиком Джо. Сгенерированная программа не выносится за скобки, прячась за опрятным интерфейсом, она переплетена, строчка за строчкой, с теми функциональными возможностями, которые созданы самим Джо [40]. В конечном итоге она перестает быть программой функции-мастера и становится программой самого Джо. Никто не должен генерировать программу, не понимая ее до конца.
• Ортогональность
• Генераторы исходных текстов
• Если в вашем распоряжении имеется функция-мастер построения графического интерфейса, воспользуйтесь ей для генерирования «скелета» приложения. Внимательно изучите каждую строку сгенерированной программы. Всели в ней вам понятно? Могли бы написать ее сами? Лучше написать ее самому, или же она делает то, что вам не нужно?
Глава 7Перед тем, как начать проект
У вас никогда не возникало ощущения, что ваш проект обречен еще до его начала? Иногда так и происходит, если вначале вы не установите некоторые основополагающие правила. В противном случае вы можете объявить проект закрытым и сэкономить спонсору некоторую сумму.
В самом начале проекта вам придется определить требования. Недостаточно лишь выслушать пользователей, необходимо прочесть раздел «Карьер для добычи требований».
Житейская мудрость и управление сдерживающими факторами являются основными темами раздела «Разгадка невероятных головоломок». Неважно, какую операцию вы осуществляете – анализ, составление текста программы или тестирование, проблемы возникают все равно. Чаще они не будут настолько сложными, какими показались вначале.
Даже когда вы подумаете, что решили все проблемы, то все равно будете чувствовать неудобства, начав работать над проектом. Является ли это простым промедлением или чем-то большим? В разделе «Пока вы не готовы» предлагается совет – в какой момент благоразумно прислушаться к предостережению внутреннего голоса.
Слишком раннее начало – это проблема, но слишком долгое ожидание еще хуже. В разделе «Западня со стороны требований» обсуждаются преимущества создания спецификаций по образцу.
В разделе «Круги и стрелки» рассматриваются некоторые ловушки, в которые можно попасть при использовании формальных процессов и методологий. Неважно, насколько хорошо он продуман, и какие «лучшие случаи из практики» в нем использованы, – никакой метод не заменит мышления.
Если вы устраните эти критические аспекты до того, как проект будет запущен, вы лучше справитесь с «аналитическим параличом» и начнете выполнять реальный успешный проект.
36Карьер для добычи требований
Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.
Многие книги и учебные пособия относят процедуру сбора исходных требований к начальной фазе проекта. Термин «сбор» напоминает о племени счастливых аналитиков, занимающихся собирательством камней-самородков мудрости, разбросанных по земле на фоне приглушенного звучания «Пасторальной симфонии». Этот термин напоминает о том, что все требования уже имеются в наличии, нужно лишь отыскать их, положить в корзину и весело шагать дальше.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Подсказка 51: Не собирайте требования – выискивайте их
В поисках требований
Как распознать истинное требование, пробиваясь к нему сквозь толшу грязевых наносов? Ответ на этот вопрос и прост, и сложен одновременно.
Простой ответ состоит в том, что требование формулирует необходимость осуществления чего-либо. Грамотно составленное требование выглядит следующим образом:
• Доступ к личному делу сотрудника ограничен группой уполномоченных на то лиц.
• Температура головки блока цилиндров не должна превышать определенного критического значения, зависящего от марки двигателя.
• Редактор выделяет ключевые слова, выбор которых зависит от типа редактируемого файла.
Однако подобной четкостью могут похвастаться лишь немногие требования, что и делает их анализ весьма сложной задачей.
Первая формулировка в списке, приведенном выше, вероятно, была составлена пользователями следующим образом: «Доступ к личному делу сотрудника ограничен его руководителями и работниками отдела кадров». Является ли эта формулировка требованием? Возможно, что сегодня и является, но она воплощает бизнес-политику в абсолютной формулировке. Политика же регулярно меняется, поэтому, скорее всего, мы не захотим жестко встраивать ее в наши требования. Мы рекомендуем документировать положения политики отдельно от требований и связывать их посредством гиперссылки. Сделайте требование общей формулировкой и снабдите разработчиков информацией о политике в качестве примера того, что им придется поддерживать в реализации. В конечном счете политика конечна, как и метаданные в приложении.
Это весьма тонкое различие, но именно оно окажет серьезное воздействие на разработчиков. Если требование сформулировано как «Доступ к личному делу сотрудника ограничен персоналом фирмы», то разработчик может прекратить составление программы проверки на том месте, где приложение обращается к этим файлам. Однако если эта формулировка звучит как «Доступ к личному делу сотрудника ограничен уполномоченными на то пользователями», то разработчик, по всей вероятности, спроектирует и реализует нечто вроде системы управления доступом. При изменении политики (а оно обязательно произойдет) потребуется лишь обновление метаданных системы. На самом деле подобный метод сбора требований приведет к созданию системы, четко структурированной для поддержки метаданных.
Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова «Система должна давать возможность выбора срока предоставления ссуды» представляют собой формулировку требования. Выражение «Для выбора срока предоставления ссуды необходимо окно списка» может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже «Когда интерфейс становится системой» описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.
Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41]. Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба «Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?» способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!
Подсказка 52: Работайте с пользователем, чтобы мыслить категориями пользователя
Добыча полезных требований важна – в это время начинают складываться связи с вашим пользовательским ядром, изучаются их ожидания и надежды на создаваемую вами систему. Более подробно это обсуждается в разделе «Большие надежды».
Документация требований
Итак, вы садитесь за стол с пользователями и начинаете выпытывать у них, что же им нужно на самом деле. Вы столкнетесь с несколькими вероятными сценариями, описывающими, что должно делать ваше приложение. Поскольку вы остаетесь профессионалом во всем, то вам хочется опубликовать такой документ, которым все смогут пользоваться в качестве основы при обсуждении, – разработчики, конечные пользователи и спонсоры проекта. Это весьма широкая аудитория.
Ивар Джекобсон [Jac94] предложил концепцию «сценариев использования системы» для фиксирования требований. Они позволяют описывать частные случаи использования системы не с точки зрения пользовательского интерфейса, а в более абстрактном виде. К сожалению, книга И. Джекобсона несколько расплывчата в деталях, поэтому в настоящее время не существует единого мнения о том, что же считать «сценарием использования системы». Что это – формальный или неформальный термин, прозаический или структурированный документ (подобный канцелярской форме)? Каким должен быть уровень детализации (помните, что у нас весьма широкая аудитория)?
В своей статье (журнал «Wired», январь 1999, с. 176) продюсер и музыкант Брайан Иноу описал чудо техники – новейший микшерный пульт. Этот пульт заставляет звучать все, что в принципе может звучать. И все же, вместо того, чтобы помочь музыкантам в создании лучших произведений или ускорить (или удешевить) процесс записи, он «путается под ногами», нарушая творческий процесс.
Чтобы понять, почему это происходит, необходимо взглянуть на работу инженеров студии звукозаписи. Они сводят звук интуитивно. За годы работы в студии у них вырабатывается врожденный цикл обратной связи между ушами и кончиками пальцев, управляющих плавно движущимися регуляторами, вращающимися ручками и т. д. Однако компьютерный интерфейс нового микшерного пульта не усиливал их способностей. Вместо этого он заставлял пользователей набирать текст на клавиатуре и/или щелкать мышью. Функции, обеспечиваемые этим интерфейсом, были универсальными, но они были скомпонованы неизвестными и экзотическими способами. Функции, необходимые инженерам в их работе, иногда скрывались за невразумительными названиями или же достигались за счет неестественных сочетаний базовых средств.
Эта среда характеризовалась требованием – усилить существующие навыки работы. Вместо того, чтобы раболепно дублировать то, что уже существует, нужно было обеспечить переход на новую ступень развития.
Например, хорошим подспорьем в работе инженеров звукозаписи мог бы оказаться сенсорный интерфейс, смонтированный в виде классического микшерного пульта, но при этом позволяющий программам выходить за границы, определенные фиксированными ручками и переключателями. Единственным способом завоевать рынок является обеспечение удобства во время перехода на новую ступень за счет уже известных метафор.
Этот пример также иллюстрирует нашу уверенность в том, что удачные инструменты всегда привыкают к рукам, их держащим. В данном случае речь идет о привыкании инструментов, которые создаются вами для других людей.
При рассмотрении сценариев использования системы стоит отметить их целенаправленную природу. Алистер Кокбэрн опубликовал статью, в которой описывается этот подход, а также шаблоны, используемые (строго или нестрого) при этом в качестве отправной точки ([Сос97а]; имеется Интернет-версия этой статьи [URL 46]). На рисунке 7.1. показан (в сокращении) пример подобного шаблона, на рис. 7.2 представлен пример сценария его использования.
Рис. 7.1. Шаблон сценария использования системы по А. Кокбэрну
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
– Цель в контексте
– Область действия
– Уровень
– Предусловия
– Условие успешного завершения
– Условие неудачного завершения
– Первичный действующий субъект
– Условие начала действия
B. ОСНОВНОЙ СЦЕНАРИЙ ПРИ УСПЕШНОМ ЗАВЕРШЕНИИ
C. РАСШИРЕНИЯ
D. ВАРИАНТЫ
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
– Приоритет
– Рабочая характеристика
– Частота
– Превосходящий прецедент использования
– Подчиненный прецедент использования
– Канал связи с первичным действующим субъектом
– Вторичные действующие субъекты
– Канал связи со вторичными действующими субъектами
F. РАСПИСАНИЕ
G. ОТКРЫТЫЕ ПРОБЛЕМЫ
Используя формальный шаблон в качестве шпаргалки, вы можете быть уверены в том, что включили всю необходимую информацию в сценарий использования системы: характеристики производительности, другие стороны-участники, приоритет, частоту использования и разнообразные ошибки и исключения, которые могут появляться неожиданно («нефункциональные требования»). Шаблон удобен для записи комментариев пользователей, наподобие «если мы получим условие ххх, тогда нам придется сделать ууу». Шаблон может послужить в качестве готовой повестки дня при встрече с пользователями ваших программ.
Рис. 7.2. Пример сценария использования системы
ПРЕЦЕДЕНТ ИСПОЛЬЗОВАНИЯ № 5: ПРИОБРЕТЕНИЕ ТОВАРА
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
• Цель в контексте: Покупатель напрямую направляет коммерческий запрос в нашу фирму и ожидает отгрузки товаров и выставления счета за указанные товары.
• Область действия: Фирма
• Уровень: Итоговая информация
• Предусловия: Нам известен покупатель, его адрес, и т. д.
• Условие успешного завершения: Покупатель получает товары, мы получаем оплату.
• Условие неуспешного завершения: Мы не производим отгрузку товаров, покупатель не производит оплату.
• Первичный действующий субъект: Покупатель, любой агент (или компьютер), действующий от имени заказчика
• Условие начала действия: Получение запроса на приобретение товара.
B. ОСНОВНОЙ СЦЕНАРИЙ С УСПЕШНЫМ ЗАВЕРШЕНИЕМ
1. Покупатель обращается в фирму с запросом на приобретение товара.
2. Фирма фиксирует имя покупателя. его адрес, требуемые товары. и т. д.
3. Фирма предоставляет покупателю информацию о товарах, ценах, сроках поставки, и т. д.
4. Покупатель подтверждает заказ.
5. Фирма компонует заказ, отправляет заказ покупателю.
6. Фирма высылает покупателю счет-фактуру.
7. Покупатель оплачивает счет-фактуру.
C. РАСШИРЕНИЯ
3а. Один из пунктов заказа отсутствует у данной фирмы: Заказ переоформляется.
4а. Покупатель производит оплату непосредственно кредитной картой: Прием оплаты кредитной картой (прецедент использования № 44).
7а. Покупатель возвращает товар: Оформление возвращенного товара (прецедент использования № 105).
D. ВАРИАНТЫ
1. Покупатель может осуществить заказ по телефону, факсу, при помощи Интернет-формы (на странице), по другим сетям электронного обмена информацией.
7. Покупатель может оплатить заказ наличными денежным переводом, чеком, или кредитной картой.
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
• Приоритет: Высший
• Производительность: 5 минут на оформление заказа, оплата в течение 45 дней
• Частота: 200 заказов в день
• Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).
• Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)
• Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).
• Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.
• Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.
F. РАСПИСАНИЕ
• Должная дата: Выпуск 1.0
G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ
• Что происходит, если имеется лишь часть заказа?
• Что происходит, если кредитная карта похищена?
Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.
Последовательность операций может быть зафиксирована при помощи диаграмм на языке UML, а схемы концептуального представления иногда могут быть полезны для оперативного моделирования бизнес-процессов. На самом деле сценарии использования представляют собой текстовые описания с иерархией и перекрестными ссылками. Сценарии использования могут содержать гиперссылки на другие сценарии и могут вкладываться друг в друга.
Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!
Кажется невероятным, что кто-нибудь может всерьез воспринимать документирование информации, используя примитивные символы, подобные изображенным на рисунке 7.3. Не будьте рабом системы обозначений: используйте любой метод общения, с помощью которого можно обмениваться требованиями с вашей аудиторией.
Чрезмерная спецификация
При генерации документов, содержащих требования, возникает серьезная опасность чрезмерной спецификации. Хорошие документы остаются абстрактными. Там, где думают о требованиях, простейшая формулировка, точно отражающая суть потребности, является наилучшей. Это не означает, что вы можете допустить неопределенность, нужно зафиксировать основополагающие семантические инварианты в качестве требований и задокументировать конкретную или же существующую на данный момент практику в качестве политики.
Требования не являются архитектурой. Требования – это не конструкция, и не пользовательский интерфейс. Это потребность.
Видеть перспективу
Вина за возникновение «проблемы 2000 года» часто возлагается на близоруких программистов, пытавшихся сэкономить несколько байтов в те дни, когда объем памяти мэйнфреймов был меньше, чем у современных пультов дистанционного управления телевизорами.
Но это не зависело от программистов и не являлось вопросом использования памяти. Если уж быть честным до конца, вина за это лежит на системных аналитиках и проектировщиках. «Проблема 2000 года» возникла по двум основным причинам: нежелание выйти за пределы существующей бизнес-практики и нарушение принципа DRY.
Двухразрядное обозначение года использовалось в деловой практике задолго до появления компьютеров. Это было обычной практикой. В то время приложения, предназначенные для обработки данных, в основном занимались автоматизацией существующих бизнес-процессов и просто повторили ошибку. Даже в том случае, когда архитектура требовала двухразрядного обозначения при вводе данных, создании отчетов и хранении данных, должна была бы появиться абстракция DATE, которая «знала» о том, что две цифры представляли собой усеченную форму реальной календарной даты.
Подсказка 53: Абстракции живут дольше, чем подробности
Требует ли от вас фраза «Видеть перспективу», чтобы вы занялись предсказанием будущего? Нет. Это означает создание формулировок типа:
Система активно извлекает пользу из абстракции DATE. Система последовательно и универсально осуществит реализацию служб DATE наподобие форматирования, хранения данных и математических операций.
В требованиях указывается лишь то, что даты используются в принципе. Это может навести на мысль, что с датами можно производить некоторые математические действия и что даты будут храниться на различных устройствах внешней памяти. Это и есть истинные требования для модуля или класса DATE.
Еще одна мелочь…
Вина за неудачи многих проектов возлагается на увеличение области их применения – это также называется раздуванием одной их характеристик, мелким улучшательством или размыванием требований. Это аспект синдрома лягушки из раздела «Суп из камней и сварившиеся лягушки» Что можно сделать для того, чтобы требования не поглотили нас?
В литературе описаны многие метрики: количество обнаруженных и устраненных дефектов, плотность дефектов, сцепление, связывание, функциональные точки, строки программы и т. д. Эти метрики могут отслеживаться вручную или с помощью программы.
К сожалению, немногие проекты могут похвастаться активным отслеживанием требований. Это означает, что они не имеют возможности сообщать об изменении в области действия – кто затребовал средство, кто утвердил его, каково общее число утвержденных запросов и т. д.
Указание спонсорам на воздействие, оказываемое всяким новым средством на график проекта, помогает сдерживать рост количества требований. Если проект запаздывает на год по сравнению с начальными оценками, а в адрес исполнителей летят обвинения, всегда полезно иметь точную и полную картину того, как и когда происходит рост числа требований.
Легко быть втянутым в водоворот под названием «всего лишь еще одно средство», но с помощью отслеживания требований вы получите более четкое представление о том, что это «всего лишь еще одно средство» на самом деле является пятнадцатым по счету, добавленным в этом месяце.
Поддержка глоссария
Как только вы начинаете обсуждать требования, пользователи и специалисты в предметной области будут использовать определенные термины, имеющие для них специфическое значение. Например, они проводят различие между «клиентом» и «заказчиком». Было бы неуместно допустить небрежность, используя в системе то один, то другой термин.
Создайте и поддерживайте «глоссарий проекта», где будут определены все специфические термины и словарь, используемый в проекте. Все участники проекта, от конечных пользователей до специалистов службы поддержки, обязаны использовать глоссарий для обеспечения согласованности. Это подразумевает доступность глоссария для широкого круга – хороший аргумент для размещения документации на web-сайтах (об этом буквально через минуту).
Подсказка 54: Используйте глоссарий проекта
Очень сложно создать успешный проект, в котором пользователи и разработчики обращаются к одному и тому же предмету под разными именами или, что еще хуже, обращаются к разным предметам, используя одно и тоже имя.
Прошу слова…
В разделе «Все эти сочинения» обсуждается публикация проектных документов на внутренних сайтах, обеспечивающих легкость доступа к ним со стороны всех участников. Этот способ распространения особенно полезен для документации, относящейся к требованиям.
Представляя требования в виде гипертекстового документа, мы можем обращаться к нуждам различной аудитории – дать каждому читателю, то что он хочет. Спонсоры проекта могут действовать на высоком уровне абстракции, чтобы удостовериться в том, нет что отклонений от цели бизнеса. Программисты могут использовать гиперссылки, чтобы «врубиться» в возросшие уровни детализации (даже в те, которые ссылаются на соответствующие определения или технические характеристики).
Распространение с помощью сети Интернет также позволит избежать создания толстенных отчетов под названием «Анализ требований», которые никто никогда не прочтет и которые устаревают в тот момент, когда первая капля чернил смачивает лист бумаги.
Если этот материал есть в Сети, то программисты даже могут его прочесть.
• Суп из камней и сварившиеся лягушки
• Довольно приличные программы
• Круги и стрелки
• Все эти сочинения
• Большие надежды
• Можете ли вы использовать программы, которые сами пишете? Можно ли обладать хорошим чутьем на требования, будучи неспособным использовать программы самостоятельно?
• Выберите проблему (не связанную с информатикой), которую вам необходимо решить в данный момент. Сгенерируйте требования для решения, не требующего наличия компьютера.
42. Какие из нижеследующих примеров, по всей вероятности, являются требованиями? Переформулируйте те, которые таковыми не являются, для придания им большей пользы (если это возможно). (Ответ см. в Приложении В.)
1. Время отклика не должно превышать 500 мс.
2. Цвет фона диалогового окна будет серым.
3. Приложение будет организовано в виде нескольких внешних процессов и внутреннего сервера.
4. Если пользователь вводит нечисловые символы в числовое поле, система будет выдавать звуковой сигнал и не примет их.
5. Приложение и данные должны умещаться в пределах 256 Кбайт.