Книги, научные публикации
Pages: | 1 | ... | 6 | 7 | 8 | 9 | Разработка требований к программному обеспечению Практические приемы сбора требований и ими при разработке программного продукта Карл И. Вигерс Дважды лауреат Software Development Productivity Award ...
-- [ Страница 8 ] --Трассирование требований также включено в уровень Действие 10 ключевой области Конструирование ПО сформулировано так: Поддерживается соответствие между различными продуктами ра боты над ПО, включающими планы разработки ПО, описания технологи ческих процессов, размещение требований, программные требования, программные конструкции, код, планы и процедуры тестирования.
Подразделы этого действия включают конкретные указания о том, как следует выполнять трассирование требований в организации.
464 Приложение Б Даже если вы не используете в качестве руководства действий по совершенствованию, принципы и приемы, приведенные в ключевых областях процессов управления требованиями и рования продукта ПО, весьма разумны. Каждая ботчик ПО может выиграть от их продуманного применения.
Модель интеграции СММ сочетает технологические процессы для сис тем и конструирования ПО. имеет две формы.
тое представление staged representation) аналогично SW-CMM и включает пять уровней содержащих технологических процессов, показанных в табл. Б- Другая форма Ч это непрерывное представление sentation) (подобное устаревшей группирующей же ласти технологических процессов по четырем категориям:
процессами, управление проектами, конструирование и (CMU/SEI, 2000b). В непрерывном представлении общие уровни лости не определяются. Вместо них определяются шесть уровней собностей (capability levels) для каждой области технологических цессов. Непрерывное представление CMMI-SE/SW позволяет каждой организации решать, какой уровень способностей ей соответствует каждой из 22 областей технологических процессов. вы мо жете решить, что должно быть на уровне 4 (количественно управляе мый) для разработки требований и на уровне 3 (определенный) для управления требованиями. Содержимое областей процессов одинако во в обоих представлениях.
Как и the Capability Maturity Model for Software, в CMMI-SE/SW на уровне 2 имеется область, именуемая Управление требованиями, но также в ней на уровне 3 есть и отдельная область Разработка требо Размещение этой области на уровне 3 не что требования для проектов организации, не достигших уровня 2, соби рать и документировать не нужно. Конечно же, это следует делать для каждого проекта. Управление требованиями рассматривается как спо соб, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организа ция может больше внимания уделять разработке высококачественных требований.
Приложение Б Это разумный аргумент, но с другой стороны, не важно, насколько эффективно вы управляете плохими, ошибочными или несуществую щими требованиями. Организации Ч разработчики ПО, озабоченные повышением эффективности, будут работать теми аспектами раз работки и управления требованиями, которые доставляют им больше всего проблем, вне зависимости от структуры the Capability Model.
Таблица ступенчатое представление Области процессов Уровень Название зрелости Начальный Управляемый Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и Обеспечение процессов и продуктов Управление Определенный Разработка требований Техническое Интеграция Проверка Утверждение Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление Анализ и разрешение вопросов Количественно организационных процессов управляемый Количественное управление Оптимизирующий Организационные их развертывание Случайный анализ и 466 Приложение Б Область процессов Управление требованиями В эта область подобна соответствующей области в Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от трассирование тре бований включено в область процессов Управление Один из пяти практических приемов, имеющих отношение к управле нию таков: Поддерживайте двустороннее трассирова ние требований. Здесь обсуждаются три особенности трассиро вания:
1 обеспечение записи источников или вторичных трассирование каждого требования вниз, к вторичным требовани ям, и его размещение по функциям, объектам, процессам и испол нителям;
I установка горизонтальных связей между требованиями, жащими к одному типу.
2. Область процессов Разработка требований В описаны три набора приемов разработки требований 1 приемы, определяющие полный набор требований клиентов, рые затем используются для разработки требований для продукта (выявить нужды заинтересованных в проекте лиц;
преобразовать нужды и ограничения в требования 1 приемы, определяющие полный набор требований для (установить компоненты продукта;
разместить требования по понентам продукта;
определить требования к интерфейсу);
1 приемы получения вторичных требований, понимания требований их подтверждения оперативные концепции и сценарии;
определить требуемую функциональность системы;
вать вторичные требования;
оценить стоимость, сроки и риск соз дания продукта;
требования), Во всех формулируются цели, к которым проект или зация по разработке ПО должны стремиться в различных областях Приложение Б процессов. В них также рекомендуются технические приемы, помо гающие достичь этих целей. Хорошие описанные в этой ра боте по конструированию требований для ПО, позволяют любой орга низации достигать целей СММ в областях процессов управления тре бованиями и разработки требований. Каждая организация должна выбрать соответствующие приемы и реализовать их в эффективные процессы конструирования требований для ее проектов.
Цель совершенствования процессов заключается не просто в нако плении процессов для рекомендуемой такой, как СММ. Цель Ч уменьшить стоимость создания и сопровождения ПО посредством внедрения лучших способов работы в повседневную практику работающей над проектом команды. Сотрудники должны превратить новые, улучшенные приемы работы в привычку, то есть вы полнять эти действия, не обдумывая подробно каждый шаг. Для этого необходима заинтересованность руководства, наличие ресурсов, пла нов, обучение и чтобы ли новые техноло гические как задумано, и приносят ли они желаемые ре зультаты. Для этого в обе СММ включены приемы, помогающие встро ить новые процессы в структуру работы организации.
На рис. Б-1 показаны некоторые взаимосвязи между управлением разработкой требований и другими областями процес сов в Эта диаграмма ясно что требования существуют не в вакууме, но тесно связаны с другими процессами и действиями проекта.
Рис. Взаимосвязи между разработкой требований, управлением требованиями и другими областями процессов 468 Приложение Б в Руководство по поиску и решению связанных с требованиями Действуя настойчиво, при взаимодействии различных заинтересован ных в проекте лиц, вы можете успешно реализовать усовершенство ванные приемы разработки и управления в своей организации.
ет выбрать приемы, которые решат или предотвратят те или иные про блемы, связанные с требованиями, возникающими в ваших проектах.
После определения наиболее срочных проблем важно выявить основ ные причины каждой такой проблемы. Эффективные решения обра щены к основным причинам, а не только к видимым на поверхности симптомам.
В табл. которая занимает почти все это приложение, перечис лено множество сгруппированных по нескольким категориям мов проблем конструирования требований, с которыми вы можете столкнуться. Симптомы дополнены описаниями соответствующих можных основных причин и предложениями по решению каждой про блемы. Конечно, это не единственные которые могут быть связаны с требованиями, так что дополняйте эту таблицу своими соб ственными примерами, которые будут появляться у вас по мере тою, как вы будете обнаруживать симптомы, не указанные здесь, Ч и раз решать их.
К сожалению, нет гарантии, что предложенные решения излечат ши конкретные симптомы, особенно если вызывающие их связаны с политикой или культурой корпорации или если основные причины лежат вне сферы действия команды разработчиков. И ни од но из этих решений не поможет, если вы имеете дело с людьми.
Чтобы использовать эту таблицу, выявите симптомы, которые указы что действия, связанные с требованиями, идут в вашем не так хорошо, как хотелось бы. Найдите в колонке Симптомы похожее на обнаруженное вами. Затем изучите колонку Возможные основные причины, чтобы понять, какие факторы могут вызывать про блемы в вашей среде. Далее выберите и подходы из колонки решения, по вашему мнению, эффективно по действуют на основные причины если все пойдет хорошо, позволят решить проблему.
Анализ основных причин Цель анализа основных причин case analysis) Ч определить вы зывающие эти симптомы факторы трассирования сим птомов к первоначальным условиям, которые вы должны чтобы решить проблему. Анализ основных подразумевает по следовательность вопросов Почему существует наблюдаемая про в которой каждый последующий вопрос задается в поисках причины, стоящей за ответом на предыдущий, Иногда не ясно, где проблема, а где основная причина. Некоторые симптомы и основные причины так что один симптом служит основной причиной для другого. Например, одна из возмож ных основных причин в области выявления требований, лотсутствуют необходимые требования, в табл. Ч это ланалитик требований не задал правильных вопросов. Эта основная причина сама представля ет собой один из аспектов процесса выявления симптома люди, ис полняющие роль аналитиков, не знают, как делать это хорошо.
Диаграмма причин и следствий (cause effect diagram) Ч также называемая схемой рыбьего скелета или диаграммой по имени ее автора, Каору Ишикавы (Kaoru Ч это эффективный способ описания результатов анализа основных причин. На рис. В- показана диаграмма причин и следствий, которая частично анализи рует проблему постоянного нарушения графика командами одной ор ганизации. Кости, отходящие от позвоночника, показывают на диа грамме ответы на вопрос: Почему команды не заканчивают проекты вовремя? Дополнительные кости показывают ответы на последую щие В конечном итоге этот анализ раскрывает основные причины на самых дальних ответвлениях костей.
Вам не придется возиться с каждой основной причиной, которую вы найдете с помощью подобного анализа. Принцип Парето (Pareto) фор мулирует известное правило утверждающее, что около 20% важных основных причин ведут к появлению примерно 80% проблем и 1996). Даже простой анализ основных про 470 Приложение В скорее всего, раскроет причины, вызывающие крупные послед ствия, на которые должны быть нацелены ваши действия по ствованию Требования пропущены во время Программисты поздними изменениями в требованиях предыдущего проекта Проекты не Не получены дачные от отобранных людей Плохо определен рынок Изменения в законодательстве 7/ Не отработан контроля Рис. Диафамма причин и следствий определяет основные причины выявленных симптомов Общие симптомы связанных с требованиями Проблемы Ч это условия, которые ведут к негативным последствиям для вашего продукта. Начните анализ основных причин с одного из симптомов какого-либо полученного вами в прошлом нежелательного результата и нарисуйте диаграмму причин и следствий, чтобы понять основные вопросы и оценить их решение. Вот некоторые типичные симптомы, проистекающие из проблем с требованиями:
1 нарушение графика и перерасход бюджета;
продукт не удовлетворяет нужд пользователей или не соответству ет их ожиданиям;
1 продукт требует исправлений и заплат сразу после выпуска;
Приложение В I разочарование членов команды, деморализация, утрата мотивации и текучка кадров;
1 масса переделок;
I дублирование действий;
I упущенный сектор рынка или задержанное преимущество в биз несе;
I потеря доли на рынке или доходов;
i возврат продукта или неприятие продукта рынком;
1 выпуск продукта с уменьшенным набором функций;
ПО, не поддающееся тестированию.
Общие препятствия для реализации решений Любая попытка изменить способы работы людей или орга низаций встречает сопротивление. Определив, как исправить основ ные причины ваших проблем с требованиями, подумайте также о пре пятствиях, которые могут затруднить реализацию этих действий, и о возможных путях их обхода. Вот некоторые препятствия ра лизации изменений в требованиях:
1 нехватка времени (все и так слишком заняты);
давление рынка, дик тующее быстрейший выпуск продукта;
недостаточная заинтересованность руководства в процессе конст руирования требований и непонимание необходимых инвестиций;
1 общее сопротивление изменениям;
I скептицизм относительно ценности требований;
1 нежелание принимать новый или более упорядоченный процесс;
1 трения между заинтересованными в проекте лицами;
политика и устоявшаяся корпоративная культура;
I недостаточная подготовка и обучение персонала;
I неясное распределение ролей и обязанностей в проекте;
1 недостаточное число ответственных лиц и плохая отчетность за действия, связанные с требованиями;
1 недоступность квалифицированных продуктов;
1 недостаточное признание или понимание проблем, вызываемых те кущими приемами работы с требованиями.
Обратите внимание, что эти вопросы с людьми или переда чей информации, а не технические вия. Большинство препят ствий такого рода не удается преодолеть легко и быстро, но первый шаг Ч признать их наличие.
472 Приложение В Таблица по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные решения основные причины Проблемы, с процессами Процессы работы Отсутствие общего пони- Документируйте текущий с требованиями и мания процессов работы с процесс работы с требова шаблоны докумен- требованиями. ниями и создайте описание тов в различных предложение желаемого Отсутствие у руководства проектах процесса.
заинтересованности в на несовместимы личии эффективных про- Обучите всех членов команды между собой.
цессов работы с требова- конструированию требовании, Используемые Примите один или несколькс процессы работы с Отсутствие механизма стандартных шаблонов требованиями совместного использования документа образа и границ шаблонов и документации примеров использо процессов. и спецификации ваний к ПО. Обеспечьте Отсутствие хороших при помощь для необходимой меров шаблонов и доку подгонки шаблонов к кон ментации требований.
кретному проекту.
Соберите и обеспечьте к хорошим примерам документации требований.
Используйте метрику исправ ления дефектов, чтобы помочь команде понять цену плохих требований.
Используйте ретроспективу проектов, чтобы зафикси ровать текущих проблем и их последствий.
Люди, исполняю- Недостаток знаний о кон- Обучите будущих аналитиков щие роли анали- струировании требований и конструированию тиков, не знают, как роли аналитика требований, требований, так и соответ ствующим особенностям делать это хорошо.
Руководство считает, что работы с ПО.
любой разработчик авто матически может стать Напишите должностную инс хорошим аналитиком. трукцию и список необходимых навыков для аналитиков требований.
программу обу чения новых аналитиков.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Возможные решения Симптомы основные причины связанные с процессами Инструментальные 1 Недопонимание Отправьте нескольких анали средства управле- инструментального тиков на тренинг, органи ния требованиями средства. зованный производителем используются инструментального средства.
Процессы и культура работы недостаточно.
не изменены для 1! Определите сторонника полной выгоды инструментального средства инструментальных средств. для обеспечения его и помощи другим 1 Нет ответственных за внедрение инстру ментального средства, ! Выявите и измените особен ности процессов и препятствующие зованию инструментального средства в полной мере.
Проблемы, связанные с продуктами Недовольные Недостаточное вовлечение Соберите клиенты. пользователей в разработку классы требований.
Клиенты отвергают пользователей.
продукт, как только Нереалистичные ожидания Определите сторонников увидели его. клиентов.
продукта.
Плохой анализ Разработчики создавали Приведите ожидания клиентов продукта. продукт на основе своих в соответствие с бизнес догадок о желаниях Низкие продажи, клиентов.
потеря доли рынка.
Создавайте прототипы и не знает о возмож пользователей ностях и ограничениях оценивать их.
разработчиков и технологий.
Используйте совместные Несоответствие между семинары для выявления пониманием требований клиентами и разработ чиками. Привлеките представителей клиентов к участию в экспер Недостаточное исследо тизе документации вание рынка.
требований.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы Возможные решения основные причины Проблемы, связанные с планированием Недостаточное вовлечение Не принимайте решений в разработку о сроках выпуска до того, требований. как требования станут понят Требования ными в достаточной мере.
недостаточно Разработке требований уде детализированы. ленно недостаточное время, На ранних стадиях стадиях проекта привлеките техни Конструирование Установка даты выпуска вер ческий персонал, чтобы он следующего выпус- сии до определения требо понимал требования.
начинается до то- ваний, возможно, в связи со го, как требования спешкой, вызванной юриди- образ для него поняты в ческими причинами или реа- и границы продукта.
достаточной мере. лиями рынка.
Объясните заинтересованным Маркетологи или бизнес- в проекте лицам риски, заинтересованные ные с поспешным конструиро в продукте, не вовлечены ванием.
в процесс работы над сотрудничества требованиями.
между и Аналитики не достаточными навыками чтобы те ставили реалистич и опытом. ные цели.
Команда думает, что начать Усильте полномочия программировать более требований в команде.
продуктивно, чем понять Используйте метрику исправ требования.
ления дефектов, чтобы Руководство или клиенты не команде понять цену плохих понимают необходимости в требований.
требованиях.
Используйте подходы инкре У аналитиков и разработ- ментального моделирования, чиков нет единого мнения чтобы быстро начать продукт, имеющий ценность о содержании требований, клиента.
Разработчики должны оце нивать качество требований прежде, чем реализовать их.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с Симптомы Возможные Возможные решения основные причины связанные с планированием Серьезные изме- Заинтересованные в проекте Стройте нения сроках пос- лица не понимают влияния сотрудничества между ана ле начала проекта, сокращения сроков литиками, разработчиками но без сокращения на реализацию проекта бизнес-партнерами, чтобы масштабов. в полном объеме. ставить реалистичные цели.
Договаривайтесь о компро миссах при изменении ограничений проекта, Пробелы в работе Нечеткое определение ролей Определите роли и распреде над и обязанностей при кон- лите обязанности по разработ струировании требований. ке требований и управлению Несколько человек ими в каждом проекте.
совершают одни и Нет ответственного за управ те же манипуляции ление требованиями. Выделите необходимый над требованиями. нал для эффективной разра ботки и управления требова ниями.
действия, связанные с требованиями, в планы и гра фики работы по проектам.
Планируется График устанавливается Прежде чем принимать обяза больше требова- до того, как определены по проекту, докумен ний, чем требования. тируйте образ и границы про сроки и ресурсы. дукта в соответствии с бизнес Плохо определены целями.
бы проекта.
График разработки составляй Неконтролируемый рост те на основе требований, воз масштабов проекта.
на стадии первоначаль Не учитывается кривая ного исследования требований, чения при обучении незнако Включите время на подготовку мым технологиям или при и кривую обучения в график работе с новыми инструмен работы.
тальными средствами.
Отделите исследование Для участия в проекте технологий и продукта недостаточно персонала.
от разработки продукта.
Требованиям не Определите приоритеты приоритеты.
требований.
Факторы риска преврати Используйте инициативное лись в управление риском.
Обязательства по проекту приняты до проведения точной оценки масштабов.
Приложение В Таблица Руководство по поиску и решению проблем, с требованиями Симптомы Возможные Возможные решения основные причины Проблемы, связанные с планированием I Энтузиазм по поводу заме- Динамически чательных новых технологий штабы проекта, насколько или возможностей берет требует ситуация с верх над реалистичными оценками возможностей.
Недокументиро- Недостаток управления I Расскажите менеджерам ванный или плохо финансовой об объеме и определенный проекта. поддержке проекта.
объем.
Спешка с началом Задокументируйте образ конструирования. и границы проекта и те их с ключевыми Отсутствие понимания важ сованными в проекте ности определения объема проекта. i He начинайте проект с определенным объемом.
Отсутствие единства мнений у заинтересованных лиц 1 Отменяйте проект, если об объеме проекта. не определена финансовая поддержка и объем проекта условия рынка или быстро изменяющиеся бизнес-нужды.
Проблемы, связанные с взаимодействием Проблемы, i Обязанности по реализации i Определите ясные роли и требований не расписаны занности для реализации ПО, связанные с взаимодействием;
подробно.
1 Обеспечьте видимый контре ль дублирование ! Недостаточная коммуника- статуса каждого требования ция между подгруппами, несколько человек работающими над частями занимаются одними проекта.
и теми же требова ! Географическое разделение ниями.
групп разработчиков или разработчиков и клиентов.
1 Определите, кто должен Пересмотр приня- \ Отсутствие ясного призна- тых ранее решений, ния и наделения полномо- принимать решения по к данному проекту чиями людей, принимающих соответствующие решения. процедуру принятия решений.
Определите продукта.
Запишите, почему в решения отвергались, дывались или отменялись.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Возможные решения Симптомы Возможные основные причины Проблемы, с взаимодействием Участники проекта Предположение, что Определите значения используют разную толкуют ключевые термины терминов в словаре.
терминологию. одинаково и верно.
Определите термины, касаю щиеся данных, в словаре.
Организуйте обучение коман разработчиков особеннос тям области бизнеса.
Обучите представителей поль зователей конструированию требований.
Проблемы, связанные с выявлением требований Недостаточное У представителей клиентов Объясните клиентам и менед вовлечение недостаточно времени для жерам особенностям разра в разработке ботки требований и объясните требований. необходимость их участия.
Разработчики Клиенты не понимают делают большое Опишите клиентам и необходимости своего количество допу- рам факторы риска недоста участия.
щений о реали- точного вовлечения пользова зуемых функциях. телей.
Клиенты не знают, что аналитикам от них нужно, Создайте атмосферу сотруд Клиенты ничества между разработчи в проекте. ками и деловыми партнерами.
Клиенты считают, что раз Определите классы пользо работчики и так знают, что вателей или сегменты рынка.
нужно клиентам.
Определите сторонников про Аналитики не свою дукта (пользователей или клиентскую подходящих заместителей).
У аналитиков нет доступа Готовьте квалифицированных к действительным клиентам, аналитиков требований.
Аналитики не знают, как Заинтересуйте руководителей сотрудничать с клиентами.
разработчиков и клиентов Сопротивление выполнению в эффективности процесса процесса разработки разработки требований Приложение В Таблица по поиску и решению проблем, связанных с требованиями (продолжение) Симптомы Возможные решения основные причины Проблемы, связанные с требований 1 Вовлечены не те Менеджеры, маркетологи, 1 Определите классы представители или другие лица пытаются пользователей.
говорить за конечных S Определите сторонников пользователей.
продукта.
Менеджеры не обеспечили Привлеките других доступность пользователей ресованных в проекте лиц, аналитикам.
помимо непосредственных пользователей.
Пользователи не Пользователи не понимают Проясните, какие результаты уверены в своих или не описать ожидают заинтересованные потребностях. в проекте лица, которых это затрагивает, в случае успеха Система создается проекта.
для поддержки нового, не полностью определенного Постройте модель бизнес-процесса. цесса пользователя.
сторонников продукта.
Пользователи не заинтере- Разработайте варианты сованы в проекте, может использования.
быть, боятся его.
Создайте и пере Ожидается, что систе- дайте для ма будет использоваться оценки.
разработки нового бизнес Используйте инкрементальный процесса.
подход к разработке, чтобы прояснять требования поне многу за раз.
Разработчики Плохо определен образ Документируйте образ не знают, кто их продукта. проекта.
пользователи.
Плохо поняты потребности Проведите исследование рынка. рынка.
Определите пользователей текущих или продуктов.
Создайте фокус-группы.
Слишком много Каждая группа хочет быть Определите классы людей вовлечено представлена по полити- пользователей.
в выявление тре- ческим причинам.
Определите сторонников бований.
Нечетко определены классы пользователей.
Приложение В Таблица по поиску и решению проблем, связанных с Возможные решения основные причины Проблемы, с выявлением требований Недостаток представителей Определите полномочия пользователей конкретных принимающих групп. связанные с требованиями.
Действительно большое I Отделите политические количество классов приоритеты от деловых пользователей. и технических.
I Ориентируйте проект на нужд привилегированных пользователей.
I Решения представ- Клиенты запрашивают Несколько раз спросите по ляются как нужды, решения, с которыми уже чтобы понять действи и требования при- знакомы. тельные нужды ходится получать скрывающиеся за представ Требования содержат основе анализа ленными конструктивные представленных обоснование конструктивных ограничения.
решений. ограничений.
I Разработайте варианты тре- Новое ПО должно использования на основном не ствовать существующим прежде чем обсуждать творяют нужды стандартам для приложений детали пользователей. и пользовательского интерфейса.
интерфейса.
Требования Подгоговьте квалифициро слишком Клиенты не какая ванных аналитиков, которые ограничены, информация должна входить умеют ставить в Основное внимание при Обучите клиентов особен обсуждении требований ностям конструирования уделяется дизайну пользо вательского Отсутствуют необ- 1 Пользователи не знают, классы ходимые требо- что им нужно. пользователей.
вания.
не поставил правильные продукта.
вопросы.
квалифи На выявление цированных аналитиков, выделено недостаточно которые умеют ставить времени. правильные вопросы.
Некоторые классы пользо- Разработайте варианты вателей не представлены. использования.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями (продолжение) Симптомы Возможные Возможные решения основные причины связанные с выявлением требований Нужные, знающие предста- Представьте требования в вители пользователей не кольких видах как моде участвовали в выявлении ли требований.
Проверьте документацию Аналитики, разработчики требований. Используйте клиенты делают неверные множество пошаговых предположения не видят проверок.
несоответствий в документа Обучите клиентов основам ции требований.
конструирования Недостаточный обмен Проанализируйте требовании, информацией между используя матрицу CRUD.
разработчиками и Создайте прототипы и клиентами.
дайте их пользователям для оценки.
Используйте подход к созданию пропущенные ния удалось включить в дующую версию продукта.
Вовлечение не тех предста- Определите, что именно Указанные вителей пользователей или неверно в требованиях и требования почему они были указаны, неверны или лиц, их заменяющих.
не подходят.
Представители пользова- Определите классы телей выражают свои точки пользователей, Требования навязаны выше- зрения, а не позиции групп, Определите стоящим руковод- которые они представляют.
сторонников продукта, ством или внешним их и наделите полномочиями.
Аналитики слишком источником.
общаются с менеджерами и Проведите проверку доку слишком мало с пользо ментации требований вателями.
функциональной командой.
Менеджеры не предостав Сообщите о факторах ляют доступ к предста связанных с неточными вителям пользователей, бованиями, заинтересованным в проекте лицам, Недостаток подотчетности полномочиями.
или незаинтересованность внешнего источника требований.
Приложение В Таблица Руководство по поиску и решению проблем, с Симптомы Возможные Возможные решения основные причины Проблемы, связанные с анализом i Указаны ненужные Отсутствие контроля Записывайте источник требования за утверждением и обоснование каждого требований. требования.
1 Во Разработчики включают 1 Применяйте варианты ис функции без консультаций с пользования, чтобы раскрыть обнаруживаются пользователями. бизнес-цели не функции системы. Выводите неожиданные Пользователи запрашивают функции. функциональные требования сложные а не на основе анализа вариантов Функции выражают бизнес-нужды.
определяются и Выявление требований реализуются, но не Определяйте приоритеты тре больше сконцентрировано бований, чтобы реализовать на функциях системы, чем на особенно ценные функции на целях пользователей.
ранних стадиях проекта.
Разработчики и клиенты по Передайте документацию разному трактуют требований требования.
циональной команде для проверки.
Требования Требования двусмысленные, или инженеры что- не полные или отдела поддержки бы составить вари- проверить требования анты тестирования. на возможность тестирования.
Требованиям не на- Опасения, что требования с Разработайте совместный значены приорите- низким приоритетом никогда процесс определения ты. Все требования не будут реализованы.
кажутся одинаково знаний Определяйте приоритеты важными.
о бизнесе и его нуждах, требований на ранних стадиях.
Все требования Разработайте детальные о ценности и имеют спецификации требований стоимости реализации каж пенный приоритет. с высоким приоритетом.
дого требования не извест Аналитики не на, не сообщается или не Используйте инкрементальный принимать обсуждается. подход к разработке или поша говые продукта, чтобы Продукт не пригоден решения о ком- реализовать максимум ценных к использованию, пока не когда функций продукта как можно большой набор новые раньше.
критических функций.
приоритеты Неразумные ожидания Только клиенты могут радикально измениться клиентов или разработчиков.
после выпуска первых версий нием приоритетов.
продукта.
Приложение В Таблица Руководство по поиску и решению связанных с (продолжение) Симптомы Возможные Возможные решения основные причины Проблемы, связанные с анализом Люди, принимающие реше- Документируйте масштабы, приоритеты ния, не назначены или не цели и приоритеты проекта, требований. уполномочены это делать.
Определите Микроцели конфликтуют принимающих решения, с макроцелями. связанные с требованиями.
Внутренняя политическая Обеспечьте ясную оценку стои борьба. мости принятия изменений.
Неясные бизнес-цели, отсут- Ведите учет последствий ствие единства мнений отно- изменений в области расходов, сительно бизнес-целей. доходов и переноса сроков.
Внешние силы, такие, как по- Обеспечивайте соответствие становления правительства требований бизнес-целям.
или законодательная база.
Требования и их приоритеты не утверждены и не внесены в версию уполно моченными сотрудниками, Нет единого У классов поль- Еще раз проанализируйте относительно прио- зователей разные нужды. рынок.
ритетов требований Недостаток Выявите между заинтересо необходимой, чтобы придер- классы пользователей ванными в проекте живаться первоначального или области рынка.
лицами.
образа продукта.
Используйте сторонников Неясные бизнес-цели дукта для представительства или отсутствие единства различных классов мнений о них. пользователей.
Неясно, кто принимает Определяйте приоритеты связанные на образе, масштабах с требованиями. и бизнес-целях.
Определите, кто принимает решения, связанные с Быстрое сокра- Нереалистичный оптимизм Определите приоритеты щение объема относительно производи- на ранних стадиях проекта.
на поздних стадиях тельности труда разработ- На основе приоритетов чиков. решайте, над чем работать проекта.
сейчас, а что отложить.
Слишком раннее и недоста точно периодичное опреде- Корректируйте приоритеты, ление приоритетов. когда вносите новые тре бования.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные основные причины Проблемы, связанные с анализом Нет доверия приоритетам Решения о том, чтобы отло при определении жить реализацию некоторых вательности реализации и функций, принимайте перио внесения контролируемых дически, а не только на объема. поздних стадиях проекта.
счи- Аналитики и клиенты не Учите аналитиков составлять тают требования понимают, какой уровень хорошие требования.
расплывчатыми и детализации требований Избегайте двусмысленными. нужен разработчикам. субъективных, двусмысленных терминов в спецификации.
Разработчикам Клиенты не знают, что им приходится искать нужно, или не могут ясно На ранних стадиях проекта упущенную инфор- это разработчики должны про мацию. смотреть требования, чтобы Ма выявление требований выяснить, достаточно ли те Разработчики отведено недостаточно ясны и детализированы.
неверно толкуют времени.
и им Моделируйте требования, Бизнес-правила не опреде приходится пере- обнаружить пропущенные лены, не переданы или не делывать работу. требования и информацию.
понятны.
Создайте и пе Формулировки требований редайте для содержат много оценки.
расплывчатых и неод нозначных слов. Уточняйте требования с возрастающим уровнем Заинтересованные в проекте детализации.
лица толкуют термины, концепции и определения Документируйте бизнес данных по-разному. правила.
Клиенты предполагают, Определите термины что разработчики уже знают в достаточно об их области Определите элементы данных бизнеса и нуждах.
в Аналитики боятся показаться Поддерживайте эффективное несведущими в данной между всеми области бизнеса и поэтому участниками проекта.
не просят помощи у Используйте знания той представителей области бизнеса, которой пользователей.
владеют представители пользователей.
G Таблица по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные решения основные причины Проблемы, связанные с анализом Некоторые Требования не анализи- Проведите анализ осуществи руются должным образом. мости или вертикальное технически 1 Клиенты не принимают н результаты анализа Проведите отдельное осуществимости. вание или исследовательский мини-проект для оценки I На оценку осуществимости осуществимости.
выделено недостаточно времени, Непонимание новых инстру ментальных средств и логий, а также их ограни чений.
1 Требования из 1 Нет единого образа продук- 1 Разработайте, утвердите личных источников та, о котором руководство и распространите документ или от различных сообщает всем заинтере- о едином образе и границах классов сованным в проекте лицам, проекта.
телей конфликтуют Не определены сотрудники, Изучите сегменты целевого друг с другом.
принимающие решения о рынка и классы 8 Трудно достичь со- требованиях.
Определите главные классы глашения 1 8 разных отделах техно- пользователей, чтобы избе ресованных в про логические процессы жать конфликтов.
екте лиц понимают по-разному.
Определите сторонников тельно требований.
Политика играет большую продукта, чтобы разрешать роль в определении конфликты внутри каждого требований. класса пользователей.
У различных групп 1 Определите телей или сегментов рынка щих решения о требованиях.
различные нужды, ожидания Стремитесь достичь общих и а не Продукт недостаточно защищать эмоциональные ориентирован на конкрет- и политические позиции.
ный сегмент рынка.
i Некоторые группы пользова телей уже применяют систе му, к которой они привяза ны, несмотря на ее недо статки.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями (продолжение) Симптомы Возможные Возможные решения основные причины Проблемы, связанные с анализом \ Исследуйте требования для Требования 1 Не назначен ответственный жат неясности и за разрешение выявления информационных информационные до того, как требования пробелов.
пробелы. передаются разработчикам.
Назначьте ответственных Нет времени на разрешение за разрешение каждой неясностей до начала неясности.
реализации.
Отслеживайте каждую вплоть до ее разрешения.
Проблемы, связанные с документированием 1 Требования не ! Никто не знает, что именно Определите и выполняйте документированы. нужно создать. технологический процесс разработки требований.
Разработчики со- i На выявление и документи требования рование требований ! Определите и утвердите у для клиентов или выделено мало времени. руководства распределение отдела маркетинга. ролей в команде и Бытует мнение, что доку заинтересуйте 1 Клиенты сообщают ментирование требований требования разра- замедляет проект. Подготовьте аналитиков ботчикам устно или требований.
Неясно определено, кто через неформаль I Проведите обучение членов отвечает за документацию, ные каналы.
или эти люди недостаточно команды и клиентов в области Разработчики заинтересованы. технологических процессов, пишут много проб- связанных с требованиями.
1 Люди, исполняющие функц ного пытаясь ии на знают, что 1 Опишите усилия для разра понять, чего им делать. ботки требований, ресурсы и задачи в | He определен технологи и графики работы.
ческий процесс разработки требований или шаблоны.
] В Те, кто управляет разработ кой, не не ценят и не ожидают разработки требований.
i Слишком самоуверенные разработчики думают, что знают нужды клиентов.
В Таблица Руководство по поиску и решению проблем, связанных с требованиями (продолжение) Симптомы Возможные Возможные основные причины связанные с документированием Клиенты или разра- 1 Требования для новой Проведите инженерный анализ предпола- системы указаны в виде существующей системы, чтобы гают, что функцио- отличий от плохо докумен- понять ее полные нальность старой тированной существующей возможности.
системы будет про- системы.
Составьте спецификацию дублирована но требований, включающую всю желаемую функциональность для новой системы.
Проблемы, связанные с документированием Документация S не i Следуйте процессу управления требований неточно в документацию требований. включающему систему. обновление документации требований при принятии новых Проводите все запросы на через совет управлению изменениями.
Встречайтесь с ключевыми заинтересованными в проекте лицами для проверки измененной спецификации требований.
Существуют раз- Плохие приемы управления Определите и исполняйте личные, противо- версиями. хорошие приемы контроля речащие друг другу версий для документации Наличие нескольких глав версии докумен- требований.
ных экземпляров докумен тации требований, тации требований. Храните требования в базе дан ных инструментального сред ства управления требованиями.
Генерируйте документы, содер жащие требования, как отчеты по содержанию базы данных инструментального средства.
Назначьте менеджера по тре бованиям ответственным за внесение изменений в специ фикацию.
Приложение В Таблица по поиску и решению проблем, с требованиями Симптомы Возможные Возможные решения основные причины с утверждением i Продукт не отвечает ! Клиенты неточно выразили Проведите исследование или свои рынка, чтобы понять ожиданиям рынка и их потребности.
Аналитик требований не по вате ставил нужных вопросов. Привлекайте сторонников 1 Клиенты имеют представляющих Недостаточное участие невысказанные, каждый основной класс клиентов в разработке предполагаемые пользователей, к работе над требований.
или скрытые проектом от начала и до конца.
Неверно представлены поль i Научите аналитиков ставить зователи, участвовавшие в не были правильные вопросы.
например мене удовлетворены.
джеры, разработчики или Разработайте варианты ис другие заместители реаль- пользования, которые обеспе ных пользователей не выра- чат понимание бизнес-задач.
жали их действительные Привлеките клиентов к участию нужды.
в проверках документации \ Продукт - с ранних передовой, с неопределен- стадий процесса работы с тре ными требованиями, и руко- бованиями.
водство по маркетингу или ! Создайте прототипы получите по продукту не точно оцени их оценку пользователями.
ло нужды рынка.
i Попросите пользователей Участники проекта сделали создать проверочные тесты неточные допущения.
и критерии приемлемости.
1 Атрибуты качества i Целевая 1 Расскажите аналитикам и и целевая произво- и атрибуты качества не клиентам о нефункциональных дительность не обсуждались во время требованиях и о том, как их указаны. выявления требований. определять.
Продукт не i Заинтересованные в Аналитики должны обсуждать ет произ- лица не понимают нефунк- требования водительности или циональных требований и их во время выявления не удовлетворяет важности. требований.
другим ожиданиям | Используемый шаблон i Используйте шаблон пользователей по требований не фикации требований, вклю имеет разделов для нефунк- чающий разделы для нефунк циональных циональных требований.
Пользователи не выражают ! Используйте своих предположений о про- для точного указания целевой изводительности системы и и качественных характерис- атрибутов качества.
тиках.
Приложение Б Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы решения основные причины Проблемы, связанные с управлением требованиями Целевая производительность и атрибуты качества не были определены достаточно точ но, чтобы все заинтересо ванные в проекте понимали их одинаково.
Некоторые запла- Разработчики не следовали Своевременно обновляйте нированные требо- спецификации требований. спецификацию требований и не были обеспечивайте доступ к ней Со спецификацией требова реализованы. всей команде.
ний не были ознакомлены все разработчики. Позаботьтесь, чтобы в про цесс управления изменениями Спецификация требований входил обмен информацией с не обновлялась по мере заинтересованными в проекте внесения изменений.
лицами.
Об изменениях не сообща Храните требования в лось всем, кого это затра ментальном средстве управ гивало.
ления требованиями.
Требования случайно Отслеживайте статус отдель пропускались во ных требований.
Создайте и Обязанности по реализации матрицу трассирования требований не были требований.
детально расписаны.
Определите ясные роли и обя занности по реализации ПО.
связанные с управлением изменениями Требования часто Клиенты не понимают, Усовершенствуйте приемы выявления требований.
изменяются. что им нужно.
1 Многие изменения или ! Введите и исполняйте вносятся в требо- требования рынка часто технологический процесс вания на поздних меняются. управления изменениями, стадиях процесса Не все нужные люди участ- Создайте совет по управлению изменениями для принятия вовали в определении и проверке требований. решений относительно изменений.
Требования с самого начала 1 Проводите анализ послед недостаточно хорошо определены. ствий изменений до их принятия.
Приложение В Таблица по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные решения основные причины Проблемы, связанные с управлением Основная версия требований Заинтересованные в проекте не определена или несогла- лица должны проверять сована. требования прежде, чем вносить их в основную версию.
Изменились технологии, Проектируйте ПО с максималь факторы, например ными возможностями для вне изменения, диктуемые госу сения и принятия изменений.
дарственными органами.
в график проекта Требования мно резервы на непредви го готовых решений, не удо денных чтобы влетворявших действи иметь возможность вносить некоторые изменения.
Рыночные нужды не очень Используйте подходы инкре хорошо поняты.
ментальной разработки, чтобы За изменениями стоят быстро реагировать на изме политические поблемы.
няющиеся требования.
Узнайте о политической ситуа в компании и старайтесь ее воздействие на требования.
Часто добавляются Выявление требований Усовершенствуйте приемы требования. неполным. выявления требований.
Плохо понимается область Определите и сообщите приложения. масштабы проекта.
Заинтересованные в проекте Нужные люди должны лица не понимают или не принимать точные бизнес ценят определение решения об изменении объема масштабов проекта, проекта.
проекта растет Проведите анализ основных бесконтрольно. причин того, откуда и почему появляются новые требования.
Руководство, отдел маркетинга или клиенты Проанализируйте последствия требуют новых функций без изменений до того, как при учета последствий этого для нимать новые требования, и проекта. ознакомьте с результатами все заинтересованные стороны.
Недостаточное участие клиентов в разработке Подключите руководство требований. к действиям по требований.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные решения основные причины Проблемы, связанные с управлением изменениями Обеспечьте вклад всех классов пользователей.
Включите в график проекта резервы на непредвиденные обстоятельства, чтобы иметь возможность вносить некоторые дополнения, Используйте подходы инкре ментальной быстро реагировать на требования.
Требования выходят Образ и границы неясно Ясно определите бизнес-цели, за границы определены. и границы.
Бизнес-цели нечетко Используйте положение об поняты. объеме проекта для принятия решений о том, входят ли Масштабы постоянно изме предлагаемые изменения в е о няются, возможно, ответ границы.
на переменчивые требова ния рынка. Записывайте объяснения, касающиеся отклонений Приоритеты требований предложенных требований.
плохо совет У членов совета по управле по управлению изменениями нию изменениями нет еди имел единое мнение мнения о масштабах об объеме проекта.
проекта.
Проследите, чтобы совет по изменениями имел должный состав и полномочия.
Используйте методы инкре ментальной гибко учитывать ся границы проекта.
4 И Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы Возможные решения основные причины Проблемы, связанные с изменениями Объем работ изме- Плохо определенные, плохо Определите бизнес-требова няется после начала понимаемые или постоянно ния и приведите образ и гра разработки. меняющиеся бизнес-цели. в соответствие с ними.
Определите заинтересованных Недостаточное понимание сегментов и потребностей в проекте лиц, принимающих рынка. на уровне бизнес требований.
Выпуск конкурирующих продуктов. Лица, принимающие решения, проверить документа заинтересован цию образа и границ.
ные в проекте лица не про верили и не утвердили Применяйте технологический процесс управления изме нениями для изменений.
Включите в график проекта резервы на непредвиденные обстоятельства, чтобы учесть возможность роста масштабов.
Заново определяйте сроки и ресурсы при изменении на правления развития проекта.
Об изменениях Документация требований не Назначьте ответственного в требованиях не при изменении каждого сообщается всем требований.
Определите связи трассируе заинтересованным Клиенты запрашивают между требованиями и в проекте лицам, изменения непосредственно другими другими докумен которых это у тами.
касается.
Не всем обеспечен легкий При обмене информации доступ к документации по требованиям учитывайте требований. все области, которые это затрагивает.
Неформальные, вербальные пути передачи информации Установите процесс управле исключают из процесса не- ния изменениями, включаю участников проекта. щий механизмы обмена информацией.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные решения основные причины Проблемы, связанные с управлением изменениями Неясно, кого нужно мировать об изменениях. средство управления ниями для Отсутствие установленного па в е процесса управления лиц к текущей версии требо изменениями.
ваний через Интернет.
Не понятны между требованиями.
Предложения Неэффективный процесс Примите практичный, об управления изменениями. тивный процесс управления в требованиях изменениями и научите заин Процесс управления изме теряются. тересованных в проекте лиц нениями не соблюдается.
следовать ему.
Статус запросов на изменения Распределите обязанности rai не известен. выполнению этапов процессе управления изменениями.
Позаботьтесь, чтобы процесс управления выполнялся.
Используйте инструменталь ные средства управления требованиями для учета изменений и статуса требования.
Заинтересованные Процесс управления измене- Позаботьтесь, чтобы в проекте лица не практичен и не управления изменениями обходят процесс эффективен.
управления изме- действенным, понятным и Работа совета по управле нениями, доступным для всех нию изменениями не сованных в проекте лиц.
Клиенты эффективна.
Создайте работоспособный шивают изменения Некоторые заинтересован непосредственно совет по управлению ные в проекте лица не пони у разработчиков. ниями.
мают или не принимают про цесс управления измене- Заручитесь поддержкой Х ниями. в исполнении са управления измененями.
Руководство не требует выполнения процесса Установите политику, согласно управления изменениями. которой изменения выполняются только посред ством процесса требований.
Приложение В Таблица Руководство по поиску и решению проблем, связанных с требованиями Симптомы Возможные Возможные решения основные причины Для Недостаточный анализ Утвердите процедуру и кон бований необходи- последствий предлагаемых трольные таблицы анализа мо гораздо больше изменений в требованиях. последствий изменений.
плани Решения по изменениям Внесите анализ последствий ровалось.
принимаются поспешно. в процесс управления Изменения затра- изменениями.
Решения по изменениям гивают больше принимаются не уполномо- Сообщайте об компонентов систе ченными сотрудниками.
всем заинтересованным в мы, чем ожидалось.
екте лицам, которых это затра Члены команды Изменения проти- гивает.
честно оценивать послед воречат другим предлагаемых информацию требованиям.
изменений. о трассировании для оценки Изменения идут последствий в ущерб качеству изменений.
побочных По мере необходимости эффектов.
обязательства и принимайте необходимые ком промиссы, изменения.
Приложение В Примеры документации требований В данном приложении на примере небольшого гипотетического та под названием Cafeteria Ordering System (COS) проиллюстрированы некоторые описанные в этой книге документы и диаграммы, необходи мые при разработке требований. К ним относятся:
1 документ об и границах проекта;
список вариантов использования и несколько описаний использования;
I часть спецификации требований к ПО;
1 некоторые модели анализа;
I часть словаря данных;
несколько бизнес-правил.
Поскольку это лишь пример, элементы документации требований намеренно не приводятся в законченном виде. Я хочу здесь просто по казать в общих чертах, как различные типы информации, необходимой при создании относятся друг к другу и как можно запись вать содержание каждого раздела. Б небольшом проекте зачастую стоит совместить несколько видов такой информации в одном менте, поэтому у вас может не оказаться отдельных образа и границ проекта, вариантов использования и спецификации требований к ПО. Для структурирования данных в этих документах предусмотрена масса способов. Ясность, полнота и простота исполь зования документации требований важнейшие задачи при ее ставлении.
Документы обычно строятся по шаблонам, описанным в предыду щих главах, но здесь из-за малых масштабов этого проекта шаблоны несколько В некоторых случаях несколько разделов объеди нялись во избежание дублирования информации. Для каждого проекта необходимо учитывать, как адаптировать стандартные шаблоны орга низации, чтобы они лучше соответствовали объемам и сути проекта.
Документ об образе и границах проекта Бизнес-требования Исходные данные, возможности бизнеса и нужды клиентов Большинство сотрудников Process Impact в настоящее время тратят в среднем 60 минут в день, чтобы выбрать, оплатить и съесть обед в ка фетерии. Около 20 минут уходит на то, чтобы дойти до кафетерия и вернуться на рабочее место, выбрать еду и оплатить ее наличными или кредитной картой. Таким образом, сотрудники проводят около нут вне рабочих мест. Некоторые звонят в кафетерий заранее, чтобы блюда были готовы к их приходу. Они не всегда что заказа ли, потому что некоторые блюда заканчиваются до их прихода. Кафете рий впустую расходует значительный объем продуктов, которые не реализуются, и их приходится выбрасывать. Те же проблемы возникают утром и вечером, хотя гораздо меньше сотрудников завтракает и ужи нает, чем обедает.
Многие сотрудники хотят заказывать блюда по сети, чтобы их дос тавляли в назначенное место в офисе компании в указанный день в указанное время. Подобная система сэкономит значительное время и позволит получать те блюда, которые хотят клиенты. Это улучшит как качество рабочей среды, так и производительность труда. Кроме того, предоставленные заранее сведения том, какие блюда хотят получить клиенты, позволит уменьшить потери и увеличит эффективность рабо ты персонала кафетерия. Если сотрудники получат в будущем возмож ность заказывать доставку блюд из близлежащих ресторанов, то у них появится больший выбор при меньшей цене, так как фирма сможет за ключать оптовые соглашения с ресторанами. А значит, кафетерию Pro cess Impact придется обслуживать только посетителей в обеденные часы, тогда как рестораны решат вопросы с завтраками, ужинами, обслуживанием особых событий и питанием по выходным дням.
496 Приложение Г Бизнес-цели и критерии успеха Уменьшить потери продуктов в кафетерии на 50% в течение 6 месяцев после первого выпуска системы".
Масштабы: стоимость продуктов, выбрасываемых каждую неделю персоналом кафетерия.
Способ измерения: исследование инвентарных журналов кафетерия, Показатели в прошлом первоначальное исследование): 30% Планируемые показатели: менее 15%.
Обязательные показатели: менее 20%.
Уменьшить оперативные расходы кафетерия на в течение 12 месяцев после первого выпуска системы.
Увеличить среднее эффективное рабочее время каж дого сотрудника на 20 минут в течение трех месяцев после вого выпуска системы.
Критерий 75% сотрудников, в настоящее время кафетерием, должны начать использовать Cafeteria Ordering System в течение 6 месяцев после первого выпуска системы.
Критерий Достичь увеличения среднего рейтинга по квартальному опросу об удовлетворенности работой кафетерия на балла в течение 3 месяцев после первого выпуска системы и на 1, балла в течение месяцев после первого выпуска системы.
Факторы бизнес-риска Факторы Профсоюз работников кафетериев может потребовать пересмотра контрактов сотрудников кафетерия, чтобы они отражали новое распределение обязанностей и график работы ка фетерия. = ущерб =3.) Факторы Слишком мало сотрудников могут принять новую систему, что уменьшит прибыль от инвестиций в ботку системы и изменений в процедурах работы кафетерия.
ность = 0,3;
ущерб = 9.) Факторы Близлежащие рестораны не согла ситься предоставить скидки, оправдывающие использование * Этот пример показывает использование Planguage для точной формулировки бизнес-цели другого требования.
Приложение Г системы, что уменьшит удовлетворенность сотрудников сис темой и возможно, ее 0,4;
ущерб = 3.) 2. Образ решения Положение об образе проекта Для сотрудников, желающих заказывать еду в кафетерии компании или в местных ресторанах через Интернет, Cafeteria Ordering System Ч это Интернет-приложение, которое принимает индивидуальные или групповые заявки на питание, взимает оплату и инициирует доставку готовых блюд к указанному пункту на территории Process Impact. В от личие от имеющихся в настоящее время служб заказа по телефону и вручную, использующим Cafeteria Ordering System, не придется приходить в кафетерий, чтобы получать заказанные блюда, что сэкономит им время, кроме того, увеличится ассортимент доступ ных им блюд.
2.2. Основные функции Основные Заказ блюд из меню кафетерия для получения в кафетерии или с доставкой.
Основные Заказ блюд с доставкой из близлежащих рес торанов.
Основные Создание, просмотр, изменение и удаление заявки на питание.
Основные Регистрация для оплаты блюд одним из воз можных способов.
Основные Запрос на доставку блюд.
Основные Создание, просмотр, изменение и удаление меню кафетерия.
Основные Заявка на приготовление блюд на заказ, кото рых нет в меню кафетерия.
Основные Создание рецептов и списков ингредиентов для блюд на заказ, приготовляемых в кафетерии.
Основные Обеспечение доступа к системе через корпо ративную сеть интранет или через Интернет для авторизованных со трудников.
498 Приложение Г 2.3. Предположения и зависимости Предположения и В кафетерии будут компьютеры и принтеры, подключенные к сети интранет, что позволит сотрудникам кафетерия обрабатывать необходимый объем заказов, не пропуская сроки доставки заказов.
Предположения Персонал кафетерия будут иметь возможность все заказы в пределах минут от указанного в заказах Предположения и Если у какого-либо ресторана есть собственная система заказов через Интернет, Cafeteria Ordering должна получить возможность двустороннего взаимодействия с ней.
3. Масштабы и ограничения Объем первого и последующих выпусков системы Функция Выпуск 1 Выпуск 2 Основные Только стандартные функции Возможность принимать из меню обедов;
зака- казы на завтраки и ужины, а зов только по- не только на обеды;
возмож средством удержания из зар- ность принимать оплату платы рез кредитные и дебетовые карты Основные Не реализована Не реализована Реализована полностью Основные Реализована, если позволит Реализована полностью время (средний приоритет) Регистрация на оплату Основные Только регистрация на оплату посредством из кредитной или дебетовой зарплаты картой Основные Блюда доставляются только Добавить доставку из кафе на территории компании терия к избранным точкам вне территории компании Основные Реализована полностью Приложение Г Функция Выпуск 1 Выпуск 2 Выпуск Основные Не реализована Не реализована Реализована полностью Основные Не реализована Реализована полностью В Основные Реализована полностью 3.2. Ограничения и исключения Ограничения и На некоторые пункты меню кафете рия доставка не распространяется, поэтому меню, доступные клиен там Cafeteria Ordering System, будут подмножеством полных меню ка фетерия.
Ограничения и Cafeteria Ordering System применяет ся только для кафетерия главного офиса Process Impact в штат Орегон.
Бизнес-контекст Профили заинтересованных в проекте лиц Заинтересо- Понимание Отношение Основные ин- Ограничении ванные основной цен в проекте ности проекта лица Управление Увеличение произ- поддерж- Сокращение Не компании водительности тру- вплоть до вы- расходов долж да сотрудников;
пуска 2;
поддерж- но превысить сокращение затрат ка выпуска 3 затраты на раз на кафетерий в зависимости работку и ис от результатов пользование предыдущих выпусков Приложение Г Понимание Отношение Основные Ограничения ванные цен- тересы в проекте ности лица Сотрудники Более эффективное Озабоченность Сохранение использование ра- бочих мест обучения со бочего времени со- ми с профсоюзом трудников трудников в тече- и возможным со- те с ние большее кращением персо- необходимое ь удовлетворение нала;
в остальном в персонале и клиентов - все восприни- транспорте дня мается нормально доставки Лучший Большой энтузи- Простота ис клиенты кафе- выбор блюд;
эконо- азм, но могут ис- пользования;
доступа к корпо терия мия времени;
удоб- пользовать систе- надежность дос- ративной сет ство му меньше, чем тавки;
возмож ожидается, из-за выбора социальной значи- блюд мости обедов в кафетерии и рес торанах Отдел расчета Отсутствие какой- Не особо счастли- Минимум изме- Еще не зарплат либо выгоды;
необ- вы относительно нений в теку- но никаких ходимость предстоящей ра- сурсов на схемы регистра- боты над ПО, но ях расчета зар- ПО ции удержания понимают цен- плат стоимости заказов компа из зарплаты нии и Менеджеры Увеличение про- Минимум новых Могут не иметь технологий;
оза- персонала и ресторанов выход на новые нормально, области рынка для но осторожно боченность возможностей привлечения новых ресурсами и за- для обработки клиентов тратами, необ ходимыми для заказов;
им доставки блюд может потребо ваться 1 к Интернету Приложение Г 4.2. Приоритеты проекта Область сила Ограничения Степень свободы Сроки Выпуск на пуск на до Зх недель опоздания допустимо без пересмотра сроков заказчиками Функции Все функции, заплани рованные к выпуску должны быть полностью Качество 95% проверочных таний, проводимых пользователями, долж ны быть выполнены;
ВСЁ тесты на защищенность должны быть выполне ны;
соответствие корпо ративным стандартам безопасности должно быть показано для всех защищенных транзакций Планируемый размер команды: работающий на полставки менеджер проекта, 2 разработчика, работаю щий на полставки;
при необходимости мо гут быть дополнительно привлечены разработ чик и тестировщик, оба работающие на пол ставки Расходы До 15% процентов перерас по бюджету возможны пересмотра заказчиками Приложение Г Варианты использования Различные классы пользователей определили следующие и основных действующих лиц для Cafeteria System.
Основное лицо Вариант использования Клиент 1. Заказ блюд.
2. Изменение заказа 3. Отмена заказа блюд.
4. Просмотр меню.
5. Регистрация для оплаты посредством удержания из зарплаты.
6. Отмена регистрации для оплаты посредством удер жания из 7. Подписка на стандартные блюда, Изменение подписки.
9. Ручная корректировка подписки.
Менеджер меню 10. Создание меню.
Изменение меню, Определение блюд на заказ.
Персонал кафетерия 13. Приготовление блюд.
14. Генерация запроса на оплату, Запрос на доставку.
16. Генерация отчетов по системы.
Персонал доставки блюд 17. Доставка блюд.
Регистрация доставки блюд.
19. Распечатка инструкций по доставке, № варианта использования: Вариант Название варианта ис пользования: Заказ блюд Автор: Karl Последнее обновление: Jack Дата 21 октября 2002 г. Дата последнего об новления: 7 ноября 2002 г.
Действующие лица: Клиент Приложение Г Клиент входит в Cafeteria Ordering System из корпоративной сети ин Описание:
транет или с домашнего возможно, просматривает ню на определенную выбирает блюда и делает заказ на достав ку в определенный пункт а пределах интервала времени.
Предварительные ус- Клиент загружен в Cafeteria Ordering System.
2. Клиент зарегистрирован для оплаты блюд через удержание ловия:
зарплаты.
Выходные на доставку блюд сохранен в Cafeteria Ordering со статусом 2. Инвентарный список доступных блюд обновлен с учетом элемен тов этого заказа.
3. Остающиеся резервы возможности в указанный интер вал времени обновлены с учетом этого заказа.
Нормальное Заказ одного набора блюд.
направление: Клиент запрашивает просмотр меню за указанную 2. Система выводит меню доступных блюд и спецпредложение дня.
3. Клиент выбирает один или более пунктов меню.
4. Клиент что блюд завершен.
5. Система выводит заказанные пункты стоимость каж дого из них и общую сумму, включая все налоги и стоимость доставки.
6. Клиент подтверждает заказ блюд или делает запрос на изменение заказа (обратно к пункту 7. Система доступные периоды времени доставки на дату 8. Клиент выбирает время доставки и указывает пункт достав 9. Клиент указывает метод оплаты.
Система подтверждает, что заказ принят.
Система посылает клиенту e-mail с подтверждением деталей заказа, цены и указаниями по доставке.
Нормальное Система сохраняет в базе данных, посылает e-mail направление: с уведомлением персонала кафетерия о посылает информацию о заказанных блюдах инвентарной системе ка фетерия и обновляет доступные периоды времени доставки.
Приложение Г Альтернативные Заказ нескольких наборов блюд (ответвление после пункта 4).
направления: Клиент делает запрос на заказ еще одного набора блюд, 2. Возврат к пункту Заказ нескольких одинаковых наборов блюд (после пункта Клиент делает запрос на определенное число одинаковых блюд.
2. Возврат к пункту 4.
Заказ спецпредложения дня (после пункта 2).
Клиент заказывает спецпредложение дня из меню.
2. Возврат к пункту 5.
Исключения: Текущее время - после истечения крайнего срока заказов пункте Система извещает клиента, что уже слишком поздно делать каз на сегодня.
2а. Клиент отменяет заказ.
Система завершает вариант использования.
За. Клиент делает запрос на другое число.
Система начинает вариант использования сначала.
Не осталось резервов времени доставки (в пункте 1).
Система сообщает клиенту, что нет незанятого времени в ки на выбранное число.
2а. Клиент отменяет заказ.
Система завершает вариант использования.
3. Клиент делает запрос, чтобы самому получить заказ в кафетерии (пропустить пункты 7, 8).
Невозможно выполнить заказ на указанное количество наковых блюд (в пункте Система извещает клиента о максимальном числе одинаковых блюд, которое она способна принять.
2. Клиент изменяет количество заказов на одинаковые или отменяет заказ.
Включает:
Приоритет: Высокий Частота Приблизительно 400 пользователей, в среднем по одному в день Бизнес-правила: Бизнес-правило-3;
правило-4;
12;
Приложение Г Особые требования: должен иметь возможность отменить в любой мо мент времени до подтверждения заказа.
2. Клиент должен иметь возможность просматривать все заказы за последние шесть месяцев и повторить один из них в но вого заказа при условии, что все его пункты присутствуют в меню на указанную доставки = Допущения: Предполагается, что 30% клиентов будут жение дня данные кафетерия за предыдущие шесть месяцев).
Замечания Дата заказа по умолчанию - если клиент обращается к системе до истечения срока размещения заказов на этот день. В и противном случае дата по умолчанию - следующий день, когда кафетерий открыт.
2. Если клиент не желает, чтобы заказ был доставлен, тельное условие, требующее регистрации для из зар платы, не применяется.
3. Пиковая загрузка использования этого варианта использования между 8:00 и 22:00 по местному времени.
№ варианта Вариант Название варианта использования: Регистрация на оплату через удержание из зарплаты Автор: Karl Последнее Chris обновление:
Дата создания: 21 октября 2002 г. Дата последнего 31 октября 2002 г.
обновления:
Действующие лица: система расчета зарплат Описание: Клиенты кафетерия, использующие Cafeteria Ordering System и заказывающие блюда с доставкой, должны быть для оплаты посредством удержания из зарплаты. безналичных покупок через Cafeteria Ordering System кафетерий будет выставлять счета на оплату системе расчета зарплат, которая будет удерживать стоимость заказов из той суммы, которую клиент должен в следующий раз чеком или прямым зачислением в депозит в зарплаты.
Предварительные условия: Клиент зарегистрирован в Cafeteria Ordering System.
Приложение Г Выходные Клиент зарегистрирован оплаты посредством удержания из зарплаты.
Нормальное 5.0 Регистрация для оплаты посредством удержания из зарплаты, направление: Клиент делает запрос на регистрацию для оплаты посредством удержания из зарплаты.
2. Система вызывает вариант использования Подтверждение идентичности пользователя.
3. Система запрашивает систему расчета зарплат, имеет ли клиент право на оплату посредством удержания из 4. Система зарплат подтверждает, что клиенту предоставлено это право.
5. Система информирует клиента, что он имеет право на регистрацию для оплаты посредством удержания из зарплаты.
6. Система просит клиента подтвердить желание для оплаты посредством удержания из зарплаты.
7. Клиент подтверждает желание зарегистрироваться для оплаты посредством удержания из зарплаты.
8. Система запрос системе расчета зарплат на установку процедуру оплаты посредством удержания из зарплаты для клиента.
9. Система расчета зарплат подтверждает, что процедура оплаты посредством удержания из зарплаты установлена.
Система уведомляет клиента, что процедура оплаты посредством удержания из зарплаты установлена и выдает номер подтверждения для транзакции регистрации.
Альтернативные направления:
Исключения: Идентичность клиента не подтверждается пункте 2).
Система дает пользователю еще две возможности идентичность.
2а. Если подтверждение успешно, клиент продолжает вариант использования.
26. Если подтверждение не происходит после трех попыток, система извещает об этом клиента, записывает недействительную попытку подтверждения в журнал и завершает вариант использования.
Приложение Г Исключения: Клиент не имеет права на оплату посредством из зарплаты (на Система сообщает что он не имеет права на оплату посредством удержания из и объясняет, почему.
2. Система завершает вариант использования.
5.0.И.З Клиент уже зарегистрирован для оплаты удержания из зарплаты (на шаге 4).
Система извещает клиента, что он уже зарегистрирован для оплаты посредством удержания из зарплаты.
2. Система завершает вариант использования.
Включает: Подтверждение идентичности Приоритет: Высокий Частота использования: В среднем по одному разу на сотрудника Бизнес-правила: и определяют права сотрудника на регистрацию для оплаты через удержания из зарплаты.
Особые требования: Подтверждение идентичности пользователя производится согласно корпоративным стандартам для приложений средней степени защиты.
Допущения:
Замечания и вопросы: Нужно ожидать высокой частоты исполнения этого использования в первые две недели после выпуска № варианта использования: Вариант Название варианта использования: Изменение меню Автор: Wiegers Последнее обновление:
Дата создания: 21 октября 2002 г. Дата обновления:
Действующие лица: Менеджер меню Описание: Менеджер меню кафетерия должен иметь возможность изменять ме ню имеющихся в наличии блюд и цен на указанную дату, чтобы отра жать изменения в наличии или ценах или для определения блюд дня.
Приложение Г Предварительные Меню уже существуют системе.
Выходные условия;
меню сохранено.
Нормальное Редакция существующего направление: Менеджер меню делает запрос на просмотр меню на определенную дату.
2. Система выводит меню.
3. Менеджер меню изменяет меню, добавляя новые блюда, удаляя или изменяя создавая или изменяя спец.
предложения или изменяя 4. меню делает запрос на сохранение меню, 5. Система сохраняет меню.
Альтернативные направления;
Меню на указанную дату не существует пункте 1 сообщает менеджеру меню, что меню на дату не существует.
2. спрашивает менеджера меню, желает ли он создать меню на указанную дату, За. Менеджер меню Система вызывает вариант использования Создание меню.
4а. Менеджер меню отвечает нет.
Система завершает вариант Указанная дата - в прошлом пункте Система сообщает менеджеру меню, что меню на указанную дату не может быть изменено.
2. Система завершает вариант использования.
Включает: Создание меню Приоритет: Высокий Приблизительно 20 раз в неделю, один использования:
Бизнес-правила:
Особые требования: Менеджер меню должен иметь возможность отменить изменение меню в любое время. Если меню было изменено, система запросить подтверждение отмены.
Меню будет создаваться Process Impact на каждый официальный рабочий день, включая те выходные и праздники, когда плани руется присутствие сотрудников на территории компании.
Приложение Г Замечания и вопросы;
Некоторые блюда не пригодны доставки, и поэтому меню клиентов Cafeteria Ordering System, блюда с доставкой, не всегда в точности соответствует меню в кафетерии, В меню будет каше не Система не позволит клиентам доставку этих блюд.
Спецификация требований к ПО Введение Назначение Эта спецификация требований к ПО описывает функциональные и не функциональные требования к выпуску 1.0 Cafeteria Ordering System (COS). Этот документ предназначен для команды, которая будут реа лизовывать и проверять корректность работы системы. Кроме специ ально обозначенных все указанные здесь требования имеют высокий приоритет и приписаны к выпуску Объем проекта и функции продукта Cafeteria Ordering System позволит сотрудникам Process Impact зака зывать блюда в кафетерии компании через Интернет для доставки в указанные пункты на территории компании. Детальное описание про дукта приведено в документе Cafeteria Ordering System Vision and Scope Document [1]. В разделе этого документа под названием Объ емы первого и следующих выпусков системы перечислены функции, полная или частичная реализация которых запланирована в этом вы пуске.
Ссылки 1. Wiegers, Karl. Cafeteria Ordering System Vision and Scope processimpact. doc 2. Wiegers, Karl. Process Impact Intranet Development Standard, Version 1.3, www.processimpact.com/corporate/standards/ 510 Приложение Г Christine. Process Impact Business Rules Zambito, Christine. Process Impact Internet Application User Standard, Version 2.0, PI internet 2. Общее описание Общий взгляд на продукт Cafeteria Ordering System Ч это новая система, которая заменяет текущие процессы заказа и получения обедов в кафетерии Process Im pact. Контекстная диаграмма на рис. показывает внешние и системные интерфейсы для версии 1.0. Предполагается несколько версий системы, чтобы в конечном итоге удалось встроить ее в службу заказов нескольких близлежащих ресторанов, работаю щую через Интернет, а также, в службы авторизации кредитных и товых карт.
Регистрация оплаты посредством удержания о подписке из зарплаты на питание Заказы на питание на питание Запрос на для оплат через удержания из зарплаты Рис. Контекстная диаграмма для версии Cafeteria Ordering System Приложение Г 2.2. Классы и характеристики пользователей Класс Описание Клиент - это сотрудник Process Impact, находящийся на террито (привилегированный) рии компании в Clackamas, штат Орегон, желающий тание с доставкой из кафетерия компании, Всего потенциальных клиентов - 600, из как ожидается, будут Cafeteria Ordering System в среднем 4 в неделю те кущие данные по работе кафетерия). Иногда клиенты будут заказы вать питание на нескольких человек (мероприятия или гости). Ожи дается, что 90% будут поступать через сеть а 10% - с домашних компьютеров. Все клиенты имеют доступ к офисов. Некоторые клиенты пожелают уста подписку на питание либо чтобы один набор блюд достав лялся им каждый день, либо чтобы автоматически доставлялось спецпредложение дня. Клиент должен иметь возможность корректировать подписку на любой день.
Сотрудники В кафетерии Process Impact в настоящее время работает около сотрудников, которые будут получать заказы через Order ing System, готовить блюда, упаковывать их для доставки, печатать инструкции по доставке и доставку. Большинство со трудников кафетерия придется обучать работе с компьютером, Ин тернет-браузером и Cafeteria Ordering System.
Менеджер меню Менеджер меню - сотрудник кафетерия, может быть, жер кафетерия, отвечающий за создание и поддержку меню на каж дый в котором указано, какие блюда имеются в наличии в ка фетерии, и время дня, когда они есть в наличии, Менеджер меню также определяет спецпредложение дня кафетерия. Менеджер ме ню должен периодически редактировать меню, чтобы указывать, ка ких запланированных блюд нет в наличии, или изменение в ценах.
Сотрудник по Готовя заказы к доставке, сотрудники кафетерия будут печатать ин струкции для доставки и передавать запросы на доставку сотрудни ку по доставке - это может быть либо один из сотрудников кафете рия, либо подрядчик. Сотрудник по доставке будет забирать про дукты и инструкции для каждого заказа и доставлять их клиентам.
Главное сотрудника по доставке с системой будет заключаться в подтверждении успеха доставки или периодической повторной распечатке инструкций по доставке.
Г 2.3. Операционная среда Cafeteria Ordering System работает со сле дующими Интернет-браузерами: Microsoft Internet Explorer версии 5. и 6.0, Netscape Communicator версия 4.7, Netscape версии 6 и 7.
Операционная среда-2. Cafeteria Ordering System установлена на сервере, работающем под управлением текущих утвержденных корпо рацией версий Red Hat Linux и Apache HTTP Server.
Операционная среда-3. Cafeteria Ordering System должна допускать доступ пользователей через корпоративную сеть интранет и, если пользователь авторизован для внешнего доступа через корпоративный брандмауэр, через Интернет-соединение из дома пользователя.
2.4. Ограничения дизайна и реализации Ограничения дизайна и системы по конструкции, коду и должна соответствовать Process Impact Intranet Development Standard, версия [2] Ограничения дизайна и Система должна использо вать текущую версию корпоративного стандарта процессора базы данных Oracle.
Ограничения дизайна и реализации-3. Весь код HTML должен со ответствовать Ограничения дизайна и реализации-4. Все сценарии должны быть написаны на Perl.
2.5. Документация для пользователей Документация для Система должна предостав лять иерархическую и перекрестно связанную систему справки в фор мате HTML с доступом по сети, описывающую и иллюстрирующую все функции системы.
Документация для При первом доступе пользо вателя к системе и далее по требованию пользователя система включать интерактивную обучающую программу, позволяющую поль зователям осуществить заказ блюд через обучающее ме ню. Система не должна сохранять блюда, заказанные с помощью этого шаблона, в базе данных или передавать заказы на них в Приложение Г 2.6. и зависимости Предположения и Кафетерий открыт для завтра ков, обедов и ужинов каждый рабочий день компании, когда предпола гается, что на территории компании будут находиться сотрудники.
Предположения и Работа Cafeteria Ordering System зависит от изменений в системе расчета зарплат, позволяющих при нимать запросы на оплату за питание, заказанное через COS.
Предположения и Работа Cafeteria Ordering System зависит от изменений в инвентарной системе кафетерия, позволяю щих обновлять информацию о наличии блюд по мере зака зов Cafeteria Ordering System.
3. 3. Функции системы Заказы питания 3.1.1 Описание и приоритет Клиент кафетерия, идентификация которого подтверждена, может за казывать набор блюд либо с доставкой в указанный пункт на террито рии либо для получения его в кафетерии. Клиент должен иметь возможность отменить или изменить заказ на если блюда еще не приготовлены. Приоритет Ч высокий.
3.1.2 воздействие - реакция Воздействие: Клиент делает запрос на размещение заказа на один или более приемов пищи.
Система о деталях заказа, оплате и инструкциях по доставке.
Воздействие: Клиент делает запрос на заказа.
Реакция: Если имеет статус Принято, система позволяет пользователю изменять сделанный ранее заказ.
Воздействие: делает запрос на заказа.
Реакция: Если воздействие имеет статус Принято, система отменяет 514 Приложение Г Функциональные требования Система должна позволять клиенту, зарегистрированному в Cafeteria Ordering заказ на один или более наборов блюд.
Заказ. Система должна подтвердить, что клиент зарегистрирован оп латы посредством удержания из зарплаты для размещения Если клиент не зарегистрирован для оплаты посредством удержа ния из система должна предложить клиенту варианты: зарегистрироваться сейчас и продолжать размещать заказ, сделать заказ и самому получить его в кафетерии ставки), или выйти из Cafeteria Ordering Система должна спрашивать клиента о дате доставки Дата: правило-8) Если дата доставки заказа Ч текущий день, а крайний срок заказов уже прошел, то система должна известить клиента, что уже слишком поздно размещать заказ на сегодня.
либо изменить дату, либо отменить заказ.
Клиент должен получит ли он заказ в кафетерии, или за каз должен быть доставлен.
Место: Если заказ должен быть доставлен и все еще есть резервы време ни доставки на дату заказа, клиент должен указать место доставки.
Заказ Система должна известить клиента, если на дату заказа нет резер Нетрезервов: вов времени доставки. Клиент должен либо отменить заказ, что получит его в кафетерии.
.Доставка.Время: Система должна показывать свободные интервалы времени тавки на дату заказа. Система должна позволять клиенту один из показанных доставки, сделать заказ без доставки или отменить заказ.
Система должна отображать меню для указанной даты.
Заказ Дата:
Заказ. Меню. Меню на текущую дату должно показывать те блюда, рые хотя бы в одном экземпляре есть в списке терия.
Приложение Г Система должна клиенту указывать количество единиц Заказ. Единицы. Блюда:
каждого которое он хочет заказать.
Заказ. Единицы. Система должна позволять клиенту заказывать несколько одинако Несколько: вых наборов блюд, вплоть до минимального числа любого ука занных блюд в меню, если таковое есть в заказе.
Заказ. Если клиент заказывает большее единиц одного блюда, чем в стоящее время указано в инвентарном списке система много:
должна извещать клиента о максимальном количестве единиц это го блюда, которое он может заказать.
Заказ. Единицы. Если остатка блюд инвентарном списке недостаточно для удов Изменение: летворения клиент должен иметь возможность изменить количество заказанных единиц блюд, изменить количество зака занных наборов блюд или отменить заказ, Подтверждение. Когда клиент указывает, что не хочет больше никакие Вывод: блюда, система должна выводить заказанные цены на дое из них и сумму к оплате, подсчитанную согласно Бизнес-пра Подтверждение. Система должна подсказать клиенту подтвердить заказ.
Приглашение:
Если клиент не подтверждает заказ, он может либо изменить, либо отменить его.
Заказ. Система должна позволять клиенту заказывать дополнительные Еще: наборы блюд на ту же или другие даты. Включение нескольких на боров блюд в один заказ регулируют и правило-4.
Заказ. Оплата. Когда клиент указывает, что закончил размещать заказы, система должна попросить пользователя выбрать метод оплаты.
Доставка: См.
Если клиент сам получит блюда в система должна предложить ему возможность оплаты через удержание из зарпла ты или наличными в кафетерии, Заказ. Оплата Система должна выводить названия заказанных блюд, сумму к оп лате, метод оплаты и инструкции по доставке.
Приложение Г Клиент должен либо подтвердить заказ, либо сделать запрос на Подтверждение;
заказа, либо сделать запрос на отмену Если клиент подтвердил заказ и выбрал оплату через удержание Удержание: зарплаты, система должна выдать запрос на оплату системе расчета Если запрос на оплату принят, система должна вывести сообще ние о подтверждении заказа с номером транзакции удержания из зарплаты, Если запрос на оплату не принят, система должна вывести сооб ждение. Нет: щение с причиной отказа. Клиент либо отменить бо метод оплаты на и сделать запрос на по лучение заказа в кафетерии.
После того как клиент подтвердил заказ, система должна сделать следующее как одну транзакцию:
Заказ. назначить заказу следующий доступный номер и сохранить за каз с начальным статусом Сохранение:
послать сообщение инвентарной системе в котором указано количество единиц каждого блюда в заказе Заказ.Завершение. обновить меню на дату заказа, отражая возможные в наличии блюд в инвентарном списке кафетерия;
Меню:
обновить список остающихся доступными периодов доставки Заказ.Завершение.
Периоды: на дату заказа;
послать e-mail с информацией о заказе и оплате;
Заказ.Завершение.
Клиент:
Заказ.Завершение, послать e-mail сотрудникам кафетерия с информацией Кафетерий: заказе;
Заказ.Завершение. если какой-либо шаг транзакции Заказ.Завершение не ся, система должна провести откат и сообщить пользователю, что Ошибка:
заказ не был принят, с указанием причины неудачи.
Система должна позволять клиенту просматривать любые Период: сделанные им в течение предыдущих шести средний].
Приложение Г Клиент должен иметь возможность повторить любой заказ, кото Повтор: он сделал за предыдущие шесть месяцев, при условии, что блюда в нем есть в наличии на дату нового заказа [Приоритет = средний].
для изменения и отмены заказов не приводятся в этом 3.2. изменение и удаление подписки на питание [В этом детали не 3.3. Регистрация для оплаты заказов различными способами [В этом примере детали не 3.4. Запрос на доставку заказа [В этом примере детали не 3.5. Создание, просмотр, изменение и удаление меню кафетерия [В этом примере детали не 4. Требования к внешнему интерфейсу 4.1. Интерфейсы пользователя Интерфейсы Экраны вывода Cafeteria Ordering Sys tem должны соответствовать Process Internet Application User Interface Standard, Version Интерфейсы Система должна обеспечивать ссыл ку на справку на каждой HTML странице, как пользо ваться этой страницей.
Интерфейсы Интернет-страницы должны предос тавлять полную возможность навигации и выбор блюд только при по мощи клавиатуры, дополнение к использованию мыши и клавиатуры.
Приложение Г 4.2. Интерфейсы оборудования Интерфейсы оборудования не выявлены.
4.3. Программные интерфейсы Программные Инвентарная система кафетерия.
Программные Cafeteria Ordering System передавать количество единиц заказанных блюд инвентарной кафетерия через программный интерфейс.
Программные Cafeteria Ordering System должна опрашивать инвентарную систему кафетерия для определения нали чия запрашиваемого блюда.
Программные Когда инвентарная система кафе терия сообщает Cafeteria Ordering System, что определенного блюда нет в наличии, Cafeteria Ordering System должна убирать это блюдо из меню на текущую дату.
Программные Система расчета зарплат.
Cafeteria Ordering System должна сообщаться с системой расчета зар плат через программный интерфейс, выполняя следующие Программные Позволять клиенту регистриро ваться для оплаты через удержания из зарплаты;
Программные Позволять клиенту отменять страцию для оплаты посредством удержания из зарплаты;
Программные Проверять, зарегистрирован ли клиент для оплаты посредством удержания из зарплаты;
Программные Передавать запрос на оплату при обретенного набора блюд;
Программные Возвращать полностью или но предыдущую оплату, если клиент отменил заказ, или не был творен им, или заказ не был доставлен согласно подтвержденным ин струкциям по доставке.
4.4. Интерфейсы передачи информации Интерфейсы передачи Cafeteria Ordering System должна посылать клиенту e-mail с подтверждением принятия ценой и инструкциями по доставке.
Г Интерфейсы передачи Cafeteria Ordering System должна посылать клиенту e-mail с сообщением о любых проблемах, возникших с заказом или его доставкой после принятия 5. Другие нефункциональные требования Требования к производительности Требования к Система должна 400 пользователей в период пиковой активности с 8:00 до по ме стному времени, со средней продолжительностью сеанса 8 минут.
Требования к Все Интернет-страницы, ге нерируемые системой, должны полностью загружаться не более чем за секунд по модемному соединению со скоростью 40кб/сек.
Требования к Загрузка ответов на запросы на экран должна занимать не более 7 секунд после того, как пользова тель отослал запрос.
Требования к Система должна пользователю сообщение о подтверждении не более чем через 4 се кунды после того, как пользователь отсылает информацию системе.
5.2. Требования к охране труда Требования к охране труда не определены.
5.3. Требования к безопасности Требования к Все сетевые транзакции, включаю щие финансовую или поддающуюся учету личную информацию, долж ны быть зашифрованы согласно Бизнес-правилу-33.
Требования к Пользователи обязательно регист рируются для входа в Cafeteria Ordering System для выполнения всех операций, кроме просмотра меню.
Требования к Клиенты должны регистрироваться для входа в систему согласно политике ограниченного доступа к ком пьютерным системам по Бизнес-правилу-35, Требования к Система должна позволять только со трудникам кафетерия, внесенным в список авторизованных ров меню, создавать или изменять меню, согласно 520 Приложение Г Требования к Только пользователи, авторизован ные для домашнего доступа к корпоративной сети могут ис пользовать Cafeteria Ordering System из пунктов вне территории ком пании.
Требования к Система должна позволять клиентам просматривать только заказы, размещенные ими лично, другими клиентами.
5.4. Атрибуты качества ПО Cafeteria Ordering System должна быть доступна пользователям корпоративной сети интранет и клиентам удаленного доступа по коммутируемой линии 99,9% времени между 5:00 и ночью по местному времени и 95% времени между полуночью и 5: по местному времени.
Если соединение между пользователем и разрывается до того, как заказ подтвержден или отменен, Cafeteria О System должна позволять пользователю восстановить незавер шенный заказ.
Приложение А. Словарь и модель данных e-mail сотрудника * адрес электронной почты сотрудника, заказ;
буквенно-цифровая строка № сотрудника * присваиваемый компанией идентификационный сотрудника, разместившего на набор блюд;
6-знаковая цифровая строка * дата доставки * дата, когда набор блюд быть доставлен или получен в кафетерии;
формат по умолчанию Ч текущая дата, если текущее время до крайнего срока размещения заказа, в противном случае Ч следующий день;
не может предшествовать текущей дате * дата меню * дата, на которую данное меню составлено;
формат * дата размещения заказа * дата, когда клиент разместил заказ;
Приложение Г набора блюд номер заказа дата размещения заказа дата доставки 1 блюдо) инструкции по доставке статус заказа блюдо пункт меню заказанное количество единиц заказанное количество * количество единиц каждого блюда, заказываемого единиц клиентом;
по умолчанию = максимум = количество, имеющееся на текущий момент в инвентарном списке * имя клиента * имя сотрудника, разместившего заказ;
30 знаковая буквенно-цифровая строка * инструкции по доставке имя клиента телефон клиента дата доставки заказа пункт доставки период доставки заказа клиент - имя клиента + № сотрудника + номер телефона сотрудника местоположение сотрудника + e-mail сотрудника крайний срок размещения заказа = * время суток, к которому все заказы на этот день должны быть размещены * меню дата меню дня) местоположение сотрудника = * здание и номера комнат сотрудника, разместившего заказ;
буквенно-цифровая строка * метод оплаты [удержание из зарплаты * остальные должны быть добавлены, начиная с выпуска 2 * номер заказа * уникальное, последовательное целое число, присваиваемое системой каждому принятому заказу;
начальное значение = 1 * номер телефона сотрудника = * номер телефона сотрудника, заказ;
в формате междугородный код, код станции, номер, добавочный номер * Приложение Г номер транзакции * последовательное целое число, которое из зарплаты система расчета зарплат присваивает каждой транзакции удержания из которую принимает описание блюда текстовое описание пункта меню;
максимум оплата заказа размер оплаты + метод оплаты + транзакции удержания из зарплаты) период доставки заказа * 15-минутный период времени, когда должен быть доставлен заказ;
должен начинаться и заканчиваться промежутки часа * пункт доставки заказа * здание и комната, в которую должен быть заказанный набор блюд * пункт меню описание блюда + цена блюда размер * общая сумма стоимость заказа в долларах и центах, подсчитанная соответственно * спецпредложение дня описание спецпредложения дня + цена спецпредложения дня * менеджер меню может определять одно или более блюд дня для каждого меню, в которые входят блюда цена на которые снижена * при статус заказа * см. диаграмму а рис. Г- * стоимость одной единицы пункта меню до уплаты цена блюда налогов, в долларах и центах * цена спец. предложения дня - * стоимость одной единицы спецпредложения дня в долларах и центах * На рис. показан фрагмент модели данных для Cafeteria Ordering System Ч описанные в словаре данных и взаимоот ношения между ними.
Приложение Г Рис. Г-2. модели данных для выпуска Cafeteria Ordering System Приложение Г Приложение Б. Модели анализа На рис. Г-3 показана диаграмма состояний, где отображен возможный статус заказа набора блюд и его возможные изменения.
Клиент не Система принимает | завершенный заказ Клиент отменяет не взимат оплату кафетерия готовит еду Клиент Клиент отменяет отменяет заказ:
оплата взимается не взимать оплату Персонал кафетерия делает запрос на доставку Служба доставки осуществляет доставку Рис. Г-3. Диаграмма состояний статуса заказов на наборы блюд Бизнес-правила (нижеследующее Ч пример отдельного перечня бизнес-правил) № Определение Тип Статическое Источник правила правила или динами ческое Бизнес- Периоды доставки Ч Факт Статическое Менеджер правило- 1 15-минутные каждую четверть часа.
Приложение Г № Определение Тип Статическое Источник правила правила или ческое Доставка всех заказов Ограничение Динамическое Менеджер правил должна быть завершена кафетерия между 10:00 и по местному времени.
Бизнес- Все блюда из одного зака- Ограничение Статическое Менеджер за должны быть кафетерия ны один же Все блюда одного зака- Ограничение Статическое Менеджер правило-4 за должны быть оплачены кафетерия одним и тем же методом.
Блюда должны быть зака- Динамическое Менеджер правило-8 заны не более, чем за кафетерия календарных дней до даты доставки.
Если заказ Ограничение Динамическое Менеджер 1 1 то должен оплатить кафетерия его посредством удержа ния из зарплаты.
Бизнес- Стоимость заказа подсчи- Вычисление Динамическое Политика правило- 12 тывается как сумма цен единиц каждого блюда, налоговые умноженных на количество законы заказанных единиц этого штата блюда, плюс вующий налог с продаж, плата за доставку, если заказ доставляется в пункт, расположенный зоны бесплатной доставки.
Приложение Г № Определение Статическое Источник правила правила или динами ческое Только работники кафете- Ограничение Статическое Политика рия, назначенные менед- кафетерия кафетерия менед жерами меню, могут соз давать, изменять или удалять меню кафетерия.
Бизнес- Передача данных по Ограничение Статическое Политика включающая финансовую безопасно или поддающуюся учету сти корпо личную информацию, рации должна проходить со битным шифрованием, [здесь должны быть дета- Ограничение Статическое Политика 5 ли безопасно го к сти корпо ным Бизнес- Только штатные сотрудни- Ограничение Статическое Финансо правило-86 могут регистрироваться вый для совершения тор корпо бо покупок в компании посредством удержания из Бизнес- Сотрудник может зареги- Ограничение Динамическое Финансо стрироваться для оплаты вый дирек питания в кафетерии по- тор корпо средством удержания рации зарплаты, если не более 40% его начисленной зар платы удерживается в на время по другим причинам, Приложение Г Словарь терминов CRUD matrix Ч таблица, которая позволяет согла совать действия системы с элементами данных, чтобы показать, где каждый элемент создается читается (Read), обновляется (Updated) и удаляется (Deleted).
IEEE (Institute of Electrical and Electronics Engineers) Ч органи зация, которая поддерживает набор стандартов для управления и полнения проектов по конструированию ПО и Planguage Ч основанный на ключевых словах язык, предложенный Tom который позволяет создать точную и количественно ваемую спецификацию требований.
Альтернативное развития alternative course Ч на правление, учитывающее вариант которое ведет к ус пеху (достижение цели действующего но которое подразу мевает отклонение от нормального направления в специфике задач или при взаимодействии объекта с системой.
Анализ основных - root cause analysis действия, рые предпринимаются для поиска основных причин, вызывающих на блюдаемые проблемы.
Анализ требований- requirements Ч процесс класси фикации информации, касающейся требований, по различным категори ям, оценка требований для определения желаемого качества, представ ление требований в различных формах, выделение детальных требова ний из требований более высокого уровня, обсуждение приоритетов требований и т.д.
Аналитик требований requirements analyst Ч роль члена команды по разработке требований. Аналитик отвечает за работу с ванными лицами Ч за извлечение, анализ, определение, требований и за их управление. Эта роль также может называться нес-аналитик, системный аналитик, требований и просто аналитик.
Аналитик - analyst Ч см. аналитик требований.
Архитектура architecture Ч структура системы, включающая ПС и оборудование (они, собственно говоря, и составляют мосвязи между этими компонентами и поведение компонентов, види мое другим компонентам.
Атрибут качества ~ quality attribute Ч разновидность нефункцио нальных требований, которые описывают качество или свойства сис темы: удобство и простота использования, легкость легкость в эксплуатации, целостность, эффективность и устойчивость к сбоям. В требованиях описаны рамки атрибутов до которых продукт демонстрирует желаемые характеристики, но не те, которые продукт создает, Атрибуты требований requirement attribute Ч описательная информация о требованиях, которая обогащает положения о желае мой функциональности продукта. К ней относятся источники данных, логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.
Бизнес-аналитик business analyst Ч см. аналитик требований.
business rule Ч политика, руководящие прин ципы или положения, которые определяют или ограничивают некото рые аспекты бизнеса.
Бизнес-требования business requirement Ч высокоуровневая бизнес-цель организации, которая строит продукт, или клиента, кото рый приобретает продукт.
Блок-схема - flowchart Ч модель, которая показывает этапы про цесса и точки принятия решений в логике процесса или программы.
Аналогична диаграмме взаимодействия.
Словарь терминов Бумажный прототип - paper prototype Ч неработающая модель пользовательского интерфейса ПО с недорогими, несложными в ис полнении эскизами экрана.
Вариант использования use case Ч описание набора логически связанных возможных взаимодействий действующего лица и систе мы, которые дают ценный для действующего лица.
Вертикальный прототип vertical prototype Ч частичная реали зация системы, содержащей ПО, с учетом всех уровней архитектуры.
Используется для оценки технической осуществимости и выполне ния. Также называется структурным прототипом или прототипом кон цепции.
Включенная взаимосвязь includes relationship Ч в которой несколько повторяющихся в разных вариантах использова ния стадий выделяются в отдельный подвариант использования. Когда необходимо, этот подвариант вызывается вариантом использования более уровня Выходные условия - postcondition Ч условия, которые описыва ют состояние системы после успешного завершения варианта исполь зования, Горизонтальный прототип horizontal prototype Ч частичная или возможная реализация пользовательского интерфейса для сис тем ПО. Применяется для оценки легкости и простоты а также завершенности и корректности требований. Также прототипом поведения или имитацией.
Граница проекта scope Ч часть образа конечного продукта, соз даваемого в ходе текущего проекта. Определяет границу между внут ренней и внешней областью проекта, Действующий объект actor Ч лицо, играющее особую роль, система ПО или аппаратное устройство, которое взаимодействует с системой для достижения полезных Также называется ролью пользователя.
Дерево решений - decision tree Ч аналитическая модель, кото рая графически показывает действия системы в ответ на все комбина ции набора факторов, которые влияют на поведение части системы, 530 Словарь терминов Диаграмма сущность Ч связь ~ entity-relationship diagram Ч аналитическая модель, которая показывает логические взаимосвязи между парами Диаграмма варианта использования ~ use-case diagram Ч эта аналитическая модель идентифицирует действующее лицо, взаимо действующее с системой для достижения значимых целей, и различ ные варианты использования, которые действующее лицо будет вы полнять.
Диаграмма взаимодействия - activity diagram Ч модель, которая позволяет динамически представить систему, по средством изображения потока от одной функции к другой. с блок-схемой.
Диаграмма классов>
Диаграмма перехода состояний - state-transition diagram аналитическая модель, показывающая возможные состояния, или ста тусы, системы и разрешенные переходы между ними. Аналогична диа грамме состояний.
Диаграмма последовательностей ~ sequence diagram Ч анали тическая модель, которая показывает порядок прохождения ний между объектами или компонентами в системе для выполнения работы.
Диаграмма потока данных - data flow diagram Ч аналитическая модель, которая описывает процесс, набор оконечные уст ройства и характеризующие поведение бизнес-процессов или систем ПО.
Диаграмма состояний ~ diagram Ч аналитическая мо дель, показывающая последовательность состояний объекта на про тяжении времени его жизни в ответ на происходящие события или воз можные состояния системы в целом. диаграмме перехода состояний.
Документ об образе и границах vision and scope в котором определены бизнс-требования к новой в том числе положения об образе продукта и описания границы Словарь терминов Допущение - assumption Ч положение, которое считается вер ным в отсутствие доказательств или точных знаний.
Зависимость - dependency Ч зависимость проекта от внешних факторов, событий или групп, находящихся вне зоны контроля.
лица - stakeholder Ч активно участвующие в проекте лица, группы или организации, которых затрагивает получен ный результат и которые сами могут влиять на этот результат.
Золочение, украшательство - gold plating Ч на являющаяся необходимой или избыточно сложная функциональность, разработан ная для продукта.
Извлечение elicitation, requirements Ч процесс определения требований к ПО или системе от различных источников посредством семинаров, анализа задач, рабочих потоков и документов и других механизмов.
Карта диалогов dialog map Ч аналитическая модель, которая описывает архитектуру пользовательского интерфейса, показывая ви димые элементы и навигацию между ними.
Класс пользователей - user>
Класс>
Клиент - customer Ч лицо, заинтересованное в проекте, которое запрашивает, оплачивает, выбирает, определяет, использует или полу чает продукт, Количество элементов - cardinality Ч количество элементов дан ных объектов или данных, которые связаны с элементами других объ ектов или данных. Например, лодин к одному, лодин ко или многие ко Коммерческие готовые продукты - COTS (commercial off-the shelf) product Ч готовый набор ПО, приобретаемый у поставщика.
Применяется как готовое решение или интегрируется, настраивается 532 Словарь терминов и расширяется в соответствии с потребностями клиента для удовле творения нужд последнего.
Контекстная диаграмма - Ч аналитическая мо дель, которая описывает абстрактную систему высокого уровня. Кон текстная диаграмма определяет внешние для системы объекты, кото рые взаимодействуют с но ничего не отображает внутренней структуры или поведения системы.
Критерий приемлемости ~ acceptance criteria Ч условия, кот рым продукт должен удовлетворять, чтобы его приняли пользователи, клиенты или другие заинтересованные лица.
Нефункциональные требования - nonfunctional requirement присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна со блюдать, в отличие от наблюдаемого поведения системы.
Нормальное напрвление развития ~ normal course Ч вательность действий, заданная по умолчанию в варианте использова ния, которая ведет к удовлетворению выходных условий этого вариан та использования или достижению целей Образ vision Ч длительная стратегическая концепция конечной цели и формы новой системы.
Образцы документов - process assets Ч документы Ч шаблон >t, формы, списки, политики, процедуры, описание процессов и примеры рабочих продуктов, которые собраны для эффективного в организации с целью улучшить приемы разработки ПО.
Объект entity Ч элемент области бизнеса, данные о котором бу дут собираться и сохраняться.
Объект - отдельный вариант для которого набор атрибутов данных и список возможных операций.
Мэри Джонс Ч отдельный вариант класса Клиент.
Ограничение - constraint Ч налагается на доступные разработчи ку возможности дизайна или конструирования продукта.
Одноразовый прототип ~ prototype Ч прототип, кото рый создается для уточнения и утверждения требований и вариантов дизайна. Такие прототипы не используются после того, как цель дос тигнута.
Словарь терминов Ч условия, которые могут помешать успеш ному завершению варианта использования. Если некоторые возврат ные механизмы не работают, то выходные условия варианта использо вания не достигаются и желаемая цель не достигается.
Оконечное устройство - terminator Ч объект на контекстной диа грамме или диаграмме потока данных, который представляет классы пользователей, действующие лица, системы ПО или внешнее по отношению к описываемой системе, но взаимодействую щее с ней. Также называется внешним объектом.
Оперативный профиль ~ profile Ч комплект сценари ев, который представляет ожидаемые применения ПО.
Организатор мероприятия facilitator Ч лицо, ответственное за планирование и работу группы, например работу семинара по извле чению требований, Основная версия требований - requirements Ч зафик сированный в определенный момент времени, согласованный, про смотренный и одобренный набор требований для указанной версии продукта.
Основная модель - essential Ч лишена характерных черт и огра ничений. Описывает информацию на концептуальном уровне, незави симо от того, как она может быть реализована в системе.
Пилотная версия pilot Ч контролируемое выполнение процесса для оценки его работы в реальных условиях и готовности к развертыванию.
Пользователь - user Ч клиент, который взаимодействует с систе мой непосредственно или косвенно пользуется результа тами работы системы, хотя не генерирует эти Также на зывается конечным Пользовательский сценарий ~ usage scenario Ч см. сценарий.
Правило решения - decision rule Ч согласованный способ выра ботки единого Предварительные условия - precondition Ч условия, которые должны быть удовлетворены, или состояние, в котором система долж на пребывать, чтобы мог начаться вариант использования.
534 Словарь терминов Проверка - verification Ч процесс оценки рабочего продукта, по зволяющий определить, действительно ли он отвечает ям и условиям, определенным в начале разработки.
Прототип ~ prototype Ч частичная, или возмож реализация программы. Применяется для исследования и требований, а также для разработки приемов. Прототипы эволюционные, одноразовые, бумажные, горизонтальные и вер тикальные. Их можно комбинировать, например эволюционный тикальный прототип.
Процедура procedure Ч пошаговое описание направления дей ствий для выполнения и завершения конкретной работы, Процесс - process Ч последовательность действий, выполняемых для реализации данных целей. Описание процесса представляет со бой документированное определение этих действий. Процесс может содержать одну или несколько процедур.
Процесс построения требований ~ requirements engineering область, которая охватывает все стороны жизненного цикла проекта связанные с необходимыми возможностями и атрибутами Состоит из разработки требований и управления требованиями. Счи тается подобластью процессов построения системы и ПО, Разработка требований requirements Ч процесс определения объема проекта, классов и представителей пользовате лей, извлечения, анализа, спецификации и утверждения требований.
Результатом этого процесса считается основная версия требований, в которой указано, что за продукт должен быть построен.
Расползание границ проекта - scope creep Ч при кото рых границы проекта увеличиваются, как правило, на протяжении всего процесса.
Распределение allocation Ч см. распределение требований.
Распределение требований requirements allocation Ч про цесс распределения системных требований по различным архитектур ным и компонентным подсистемам.
Расширенная взаимосвязь extends relationship Ч где альтернативное направление варианта использования ветвляется от нормальной последовательности действий.
Словарь терминов тельность действий альтернативного направления можно как расширенный вариант который выполняется для достижения альтернативного результата. Процесс ко гда альтернативное направление вновь присоединяется к основному для завершения, Ретроспектива retrospective Ч см. спецификация требований к продукту и спецификация требований.
Риск Ч таблица, где показаны логические связи между от дельными функциональными требованиями и другими системными документами и их фрагментами, включая другие функциональные тре бования, варианты использования, элементы дизайна и архитектуры, фрагменты кода, варианты тестирования и бизнес-правила.
Словарь данных data dictionary Ч набор определений элемен тов структуры и атрибутов, которые важны для данной пред метной области.
Событие - event Ч инициирующее или стимулирующее событие, которое происходит в системной среде, например поведение функции или изменение состояния, Совет по управлению change control board группа людей, отвечающая за решение принять или отклонить предла гаемое изменение в требованиях к ПО.
Спецификация требований ~ requirements Ч про цесс документирования системы в структурированном, доступном всем и управляемом формате. Также называется и результат этого процесса. См. также спецификация требований к продукту.
Спецификация требований к продукту - software requirements spe-cification Ч набор функциональных и нефункциональных требо ваний к продукту ПО, Сторонник продукта - product champion Ч назначенный пред ставитель отдельного класса пользователей, который требования им групп пользователей.
Сценарий scenario Ч описание пользователя и системы с целью достижения некоторой цели. Пример работы с систе мой. Один из путей развития варианта использования. Часто ставлен в виде истории.
536 Словарь терминов Таблица событие Ч - event-response table Ч пе речень внешних или зависящих от времени событий, которые могут влиять на систему, и описание как система будет отвечать на каж дое из них.
Таблица решения - decision table таблица, где показаны все комбинации значений для наборов факторов, которые влияют на пове дение части системы, и определены ожидаемые действия системы в ответ на каждую комбинацию.
Трассирование tracing (also Ч процесс определе ния логических связей между одним элементом системы использования, функциональными требованиями, компонентами дизайна, фрагментами кода, вариантами тестирования и и Требования requirement Ч документ, где указаны потребности или цели пользователей либо условия и возможности, которыми дол обладать продукт, чтобы удовлетворить такие возможности или цели, Требования для интерфейса внешнего устройства external interface requirement Ч описание интерфейса между системой ПО и другой системой ПО или оборудованием.
Требования к системе system Ч высокоуровневые требования к продукте, который состоит из множества подсистем, в том числе только ПО или ПО и оборудования.
Требования пользователей - user requirement Ч цели и задачи, которые пользователи должны иметь возможность выполнять с сис темой, или положения об ожиданиях пользователей о качестве сис темы.
Управление требованиями ~ requirements management Ч рабо та с определенным набором требований к продукту Ч начиная от цесса разработки продукта и заканчивая поддержкой продукта. Управление подразумевает трассирование статуса продук та, управление изменениями требований и версиями требований, а также трассирование отдельных требований до других этапов проекта и рабочих продуктов.
Утверждение Ч процесс оценки рабочего продукта, зволяющий определить, действительно ли он отвечает Словарь терминов Функциональная точка function point Ч измерение размера основанное на числе и сложности внутренних логических файлов, фай лов интерфейса внешнего устройства, вводимых данных, ре зультатов и запросов.
Функциональные требования functional requirement Ч поло жение о фрагменте требуемой функциональности или поведения, ко торые система проявляет при определенных условиях.
Функция - feature Ч набор логически связанных функциональных требований, которые обеспечивают возможность для использования и дают возможность удовлетворить Цикл водопадной модели проекта - waterfall development life cycle Ч модель процесса разработки ПО, в которой различные дейст вия с требованиями, дизайном, кодированием, тестированием и раз вертыванием выполняются последовательно, с небольшим наложени ем или итерациями.
Цикл разработки ПО - software development life cycle Ч после довательность в которой ПО определяется, конструируется, строится и проверяется.
Шаблон - template Ч образец, который используется в качестве руководства при создании всеобъемлющей документации или других элементов.
Эволюционный прототип - evolutionary prototype Ч полностью функциональный прототип, построенный как скелет или некая ста дия конечного продукта, которые постепенно будут лобрастать по мере прояснения требований.
Эксперт предметной области ~ subject matter expert Ч лицо, имеющее обширный опыт и знания в предметной области и счи тающееся авторитетным источником информации о предметной об ласти.
Экспертиза - inspection Ч тип экспертной оценки, когда члены специально созданной команды в определенном и строгом порядке исследуют рабочий продукт на предмет выявления дефектов.
Экспертная оценка review Ч действия, предпринимаемые одной или несколькими лицами (не авторами для 538 Словарь терминов вания продукта с целью обнаружить дефекты и улучшить возможности.
Экстремальное программирование - Extreme Programming быстрый метод разработки ПО, который характеризуется взаимодействием разработчиков с находящимися же представите лями клиентов, ограничением документации требований листориями пользователей, а также быстрым и частым выпуском фрагментов функциональности пользователей.
Словарь терминов Библиографический список Abran, Alain и W. eds. Guide the Software Engineer ing Body of Knowledge, Trial Version. CA: So ciety Press.
Alexander, Ian F. и Richard Stevens. 2002. Writing Better Requirements.
London:
Ambler, Scott. Reduce Development Costs with Use-Case Scenar io Testing. Software Development 3(7):53-61.
же авторы. 1999. Your Design. Software 7(4):48-55.
Andriole, Stephen J. Managing Systems Requirements:
Tools, and Cases. York: McGraw-Hill.
Jim. 1998. Use Cases, UML Visual Modeling and the ion of Business Requirements. Requirements Engineering 3(2);
150-152.
Armour, Frank и Granville Miller. 2001. Advanced Use Case Modeling:
Software Systems. Boston, MA: Addison-Wesley.
Arnold, Robert S. и Shawn A. 1996. Software Change Impact Analysis. Los Alamitos, CA: IEEE Computer Society Press.
Bass, Len, Paul Clements и Software Architecture in Practice. Reading, MA: Addison-Wesley.
Beck, Kent. 2000. Extreme Programming Explained: Embrace Change.
Boston, MA: Addison-Wesley.
Beizer, Boris. 1990. Software Testing 2d ed. New York: Van Nostrand Reinhold.
же авторы. 1999. and Worst Testing Practices: A Baker's Dozen.
Cutter IT Journal 12{2):32-38.
Hugh и Karen Contextual Design: Defining Cus tomer-Centered Systems. San Francisco, CA: Morgan Kaufmann Publish ers, Inc.
Blackburn, Joseph D., Gary D. Scudder и Luk N. Van Wassenhove.
Improving Speed and Productivity of Software Development: A Global Sur vey of Software Developers. IEEE Transactions on Software Engineering 22(12):875-885.
Barry W. 1981. Software Engineering Economics.
Cliffs, NJ: Prentice Hall.
Те же авторы. 1988. A Spiral Model of Software Development and hancement. IEEE Computer -72.
Те же авторы. 2000. Requirements that Handle COTS, and Rap id Change. IEEE Computer Boehm, W. и Philip N. Papaccio. Understanding and Control ling Software Costs. IEEE Transactions on Software Engineering 14(10):1462-1476.
Boehm, Barry, J. R. Brown и Lipow. 1976. Quantitative Evaluation of Software Quality. Second IEEE International Conference on Software Engi neering, 592-605. Los Alamitos, CA: IEEE Computer Society Press.
Boehm, Barry 2000. Software Cost Estimation with II.
Upper Saddllnternational Conference on Software Engineering, 592-605.
Los Alamitos, CA: IEEE Computer Society Press.
Boehm, Barry 2000. Software Cost Estimation with Cocomo II.
Upper Saddle River, NJ: Prentice Hall PTR.
Grady, James и Jacobson. 1999. The Unified Modeling Language User Guide. Reading, MA:
Brooks, Frederick P.. Jr. No Silver Bullet: Essence and Accidents Software Engineering. С River, NJ: Prentice Hall PTR.
Booch, Grady, James Rumbaugh и Ivar Jacobson. 1999. The Unified Modeling Language User Guide. Reading, MA: Addison-Wesley. Х Brooks, Frederick P., Jr. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. Computer 20(4):
Norm. 1996. Management Strategies. IEEE Software 13(4}:94~103.
Те же авторы. 1999. High-Leverage Best Practices: What Hot Compa nies Are Doing to Stay Ahead. Cutter Journal 12(9):4-9.
Библиографический список Business Rules Group. 1993. Defining Business Rules: What Are They ttp://www.
Kim. 1998. Implementation Guide: Choreographing Soft ware Process Reading, MA: Addison-Wesley.
Carnegie Mellon Engineering Institute. 2000a.
for Systems Engineering/Software Engineering, Version 1.02: Staged Rep resentation. Technical Pittsburgh, PA: Car negie Mellon University/Software Engineering Institute.
Те же авторы. CMMI for Systems Engineering/Software Engi Version Continuous Representation. Technical Report CMU/ SEI-2000-TR-029. Pittsburgh, PA: Carnegie Mellon University/ Software Engineering Institute, Carr, Marvin J., Suresh L. Konda, Ira Monarch, F. Carol и Clay F.
Walker. 1993. Taxonomy-Based Risk Identification (CMU/ SEI-93-TR-6).
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.
Cavano, J. P. и J. A. McCall. A Framework the Measurement of Software Quality. Software Engineering Notes 3(5):
Robert N. Applications Strategies for Risk Analysis. New York: McGraw-Hill.
Michael G. и Kang. 1992. Issues in Requirements Elicita tion (CMU/SEI-92-TR-12). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.
Alistair. 2001. Writing Effective Use Cases. MA: Addi son-Wesley.
Те же авторы. 2002. Agile Software Development. Boston, MA: Addison Cohen, Lou. Quality Function Deployment: to Work forYou. Reading, MA: Addison-Wesley, Collard;
Ross. 1999. Test Design. Software Testing Quality Engineering 1{4):30-37.
Constantine, Larry. 1998. Prototyping from the User's Viewpoint.
ware Development Constantine, Larry L. и A. D. 1999. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design.
Reading, MA: Addison-Wesley.
542 Библиографический список Cooper, Alan. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore the Sanity. Indianapolis, IN:
Sams.
Covey, Stephen R. 1989. The 7 Habits of Highly Effective People. New York: Simon & Schuster.
Davis, Alan 1993. Software Requirements: and States. Englewood Cliffs, NJ: Prentice Hall PTR.
Те же авторы. 201 Principles of Software Development.
McGraw-Hill.
DeGrace, Peter и Leslie The Imperative:
and the State of Software Engineering Practice. Englewood Cliffs, don Press/Prentice Hall.
Structured Analysis and System En glewood Cliffs, NJ: Prentice Hall.
Tom и Timothy Lister. 1999. Peopleware: Productive and 2d ed. York: Dorset House Publishing.
Drabick, Rodger D. 1999. On-Track Requirements. Software Testing & Quality Engineering Soumitra, Michael Lee и 1999. Software En gineering in Europe: A Study of Best Practices. IEEE Software ESPITI. 1995. European Software Process Improvement Training tive. User Survey Report.
Michael E. 1976. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal Patricia L. 2002. A Requirements Pattern: Succeeding in the Internet Economy. Boston, MA: Addison-Wesley.
Fisher, Roger, William Ury и Bruce Patton. 1991. Getting Yes: Negotiat ing Agreement Without Giving In. York: Penguin USA.
Florence, 2002. Reducing Risks Through Proper of ware Requirements. CrossTalk 15(4}:13-15.
Fowler, Floyd J. 1995. Improving Survey Questions: Design and Evalua tion. Thousand CA: Sage Publications.
Fowler, Martin. 1999. Refactoring: Improving the Design of Existing Code. Boston, MA: Addison-Wesley.
Библиографический список Daniel и Gerald 1990. Handbook of Walk throughs, Inspections, and Technical Reviews: Evaluating Projects, and Products, 3d ed. York: Dorset House Publishing.
Gainer, Jeff. The Cutter IT E-Mail Advisor, August Gause, С. и Brian Lawrence. 1999. User-Driven Design. Software Testing & Quality Engineering Gause, Donald С. и Gerald M. Weinberg. Exploring Requirements:
Before Design. York: Dorset House Publishing.
Tom. 1988. Principles of Software Management. Har England:
Те же авторы. Quantifying the Qualitative: to Avoid Vague Re quirements by Clear Specification Language. Quarterly 12:9-13.
Gilb, Tom и Dorothy Graham. 1993. Software Inspection.
England: Addison-Wesley.
Glass, Robert L. Building Quality Software. Englewood Cliffs, NJ:
Prentice Hall.
Те же авторы. 1999. Surprising Findings, Commu nications of the ACM 42(4):
О. и A. Finkelstein. 1994. An Analysis of the Requirements Trace ability Problem. In Proceedings of the First International Conference on Re quirements Engineering, 94-101. CA: IEEE Computer Society Press.
Gottesdiener, Ellen. Decide to Decide. Software Development 9(1);
65-70.
Те же авторы. Requirements by Collaboration: Workshops for Defining Needs. Boston, MA: Addison-Wesley, Grady, Robert B. 1999. An Economic Release Decision Model: Insights into Software Project Management. In Proceedings of the Applications of Software Measurement Conference, Orange Park, FL: Software Quality Engineering.
Grady, В. Tom Van Slack. 1994. Key Lessons in Achieving Wide spread Inspection Use. Software Graham, Dorothy. 2002. Requirements and Testing: Seven Missing-Link Myths. IEEE Software 544 Библиографический список Ham, Gary A. 1998. Four Roads to Use Case Discovery: There Is a Use (and a Case) for Each One.
Derek, Peter Hruschka и Imtiaz Pirbhai. 2000. Process for System Architecture and Requirements Engineering. York: Dorset House Pub lishing.
James III. 2000. Adaptive Software Development: A Col laborative Approach to Managing Complex Systems. New York: Dorset House Publishing.
Hofmann, Hubert F. и Franz Requirements Engineering as a Success Factor in Software Projects. IEEE Software 18(4):58-66.
Hohmann, Luke. 1997. Managing Highly Usable Graphical User Interface Development Hooks, Ivy F. и Kristin A. Farry. Customer-Centered Products: Cre ating Successful Products Through Smart Requirements Management AMACOM.
Hsia, Pei, David Kung и Sell. 1997. Software Requirements and Ac ceptance Testing. In Annals of Software Engineering, Nancy R. Mead, ed, 3:291-317.
Humphrey, Watts S. 1989. Managing the Software Process. Reading, MA:
же авторы. 1997. Managing Technical People: Innovation, Teamwork, and the Software Process. Reading, MA:
IEEE. 1990. IEEE Standard Glossary of Software Engineering Terminology. Los CA: IEEE Computer Society авторы. 1992, IEEE Std 1061-1992: IEEE Standard Software Quality Metrics Methodology. Los Alamitos, CA: IEEE Computer Press.
же авторы. 1998а. IEEE Std 1362-1998: IEEE Guide for Information of Operations Docu ment. Los Alamitos, CA: IEEE Computer Society Press.
же авторы. 1998b. Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications. Los Alamitos, CA: IEEE Comput er Society Press.
же авторы. 1998с. IEEE Std 1233-1998: IEEE Guide for Developing System Requirements Los Alamitos, CA: IEEE Computer So ciety Press.
Библиографический список International Function Point Users Group. 2002. Function Point Counting Practices Version Princeton Junction, NJ: International Function Point Users Group.
Jackson, Michael. Software Requirements & Specifications: A Lex icon of Practice, Principles, and Prejudices. England:
Jacobson, Magnus Patrik Jonsson и Gunnar gaard. Object-Oriented Software Engineering: Case Driven Ap proach. Harlow, England: Addison-Wesley.
Jacobson, Grady Booch и James Rumbaugh. 1999. The Unified Software Development Process. Reading, MA: Addison-Wesley, Jarke, Matthias. 1998. Requirements Tracing. Communications of the Jeffries, Ron, Ann Anderson и Hendrickson. Extreme Pro gramming Installed. Boston, MA: Addison-Wesley.
Jones, Capers. Assessment and Control of Software Risks.
Cliffs, NJ: Prentice PTR.
Те же авторы. 1996а. Strategies for Managing Requirements Creep.
IEEE Computer 29(6}:92-94.
Те же авторы. 1996b. Applied Software Measurement, York:
McGraw-Hill.
Те же авторы. 1997. Software Quality: Analysis and Guidelines for Suc cess. Boston, MA: International Thomson Computer Press.
Jones, David Donald M.York, John F. и Joseph Simpson. 1995.
Factors Influencing Requirement Management Toolset Selection. In Pro ceedings of the Fifth Annual Symposium of the National Council on Systems Engineering, vol. 33-58. Seattle, WA: Council on Systems Engineering.
Jung, Ho-Won. Optimizing Value and Cost in Requirements Analy sis. IEEE Software 15(4):74-78.
Pages: | 1 | ... | 6 | 7 | 8 | 9 | Книги, научные публикации