3.1 Обработка документа заказа, выгруженного из системы Magento

В данном случае рассматривается сценарий, при котором заказ оформляется клиентом на сайте, но документация готовится в ИС (см. Рисунок 4 Заказ из системы Magento)

Рисунок 4. Заказ из системы Magento

На основании приведенной диаграммы можно привезти следующие пользовательские и функциональные требования к системе:

1.0 Заказ оформляется физическим лицом на сайте организации ХХХ. Для этого покупатель создает себе профиль на сайте, куда записываются личные данные и привязывается карточка для последующей оплаты. Для покупки одного или нескольких товаров покупатель первоначально добавляет в свою корзину интересующие его товары, в конце он подтверждает свой заказ. В этот момент в системе Magento формируется заказ на продажу. Также в этот момент для оператора интернет-магазина формируется уведомление о наличии нового заказа. Все перечисленные функции уже были реализованы ранее системой Magento. Данный этап предполагается оставить без изменений.

1.1 Оператор интернет-магазина получает уведомление о наличии нового заказа с указанием номера заказа, даты и времени получения, данные о покупателе. Данные функции уже на данный момент реализованы в системе, они останутся без изменений.

1.2 Оператор находит данный заказ в системе Magento, проверяет правильность введенных данных. Оператор смотрит, чтобы в заказе были проставлены правильные артикулы товаров с правильными ценами. Система Magento уже позволяет оператору выполнить данные действия, никаких изменений в текущем бизнес-процессе на данном этапе не будет.

1.3 Если данные введены неверно, оператор связывается по телефону с покупателем, при необходимости вносит исправления в заказ или вовсе его отменяет и подтверждает заказ. Все перечисленные действия данного этапа уже реализованы.

1.4 Если все данные изначально введены корректно, то оператор сразу подтверждает заказ. Заказ переводится в режим «В ожидании». Данная функция уже реализована в системе Magento

1.5 При моем непосредственном участии в совещании с представителями компании, отвечающей за техническую поддержку системы Magento, нами было выяснено, что система может формировать xml файл, содержащий информацию о заказе, а именно основную информацию о заказчике, дате заказа, выбранного способа оплаты, данные о доставке и дополнительную информацию о том, какие именно товары были заказаны, в каком количестве и по какой цене. Соответственно, от ИС требуется, чтобы она имела возможность формировать документ «Заказ» на основании выгружаемого пакета. При этом, все данные документа должны корректно заноситься в соответствующие строки. Выгрузка будет запускаться с помощью специальной службы, которая через равные интервалы времени будет проверять папку-источник на наличие новых пакетов заказов и автоматически выгружать данный документ в ИС (рекомендуемый интервал выгрузки, предложенный со стороны поддержки сотрудников Magento, составляет пять минут).

1.6 После того, как заказ будет выгружен в ИС, бухгалтер проверит корректность выгруженных данных.

1.7 В первую очередь, бухгалтер должен проверить правильность отображения артикулов товаров, их количеств и данных по ценам. Особое внимание при проверке цен нужно будет уделить скидочным товарам. В том случае, если какие-то из перечисленных данных будут отображены неверно, бухгалтер должен отменить заказ, в документе заказа нужно реализовать поле, в котором бухгалтер сможет указать причину отказа. При отмене заказа ИС должна сформировать ответный пакет xml, в котором будет указано, какой именно заказ был отменен и по какой причине. Оператор Magento получит уведомление о том, что один из заказов был отменен с указанием причины отмены, свяжется с клиентом и уточнит детали заказа.

1.8 В том случае, если никаких изменений не требуется, бухгалтер сохраняет документ «Заказ» в информационной системе. При сохранении заказа система должна выполнить проверку, хватает ли в данный момент товара на складах. Выполнить это система должна для всех позиций, указанных в заказе.

1.9 В том случае если хотя бы одного товара не хватает на складе, система должна выдать для бухгалтера предупреждение с указанием, какого именно товара не хватает, в какой строке находится данный товар, сколько единиц товара не хватает.

1.10 При нехватке товара на складе ИС должна автоматически создать заявку на закупку, в которой будет описано, какое количество какого именно товара необходимо закупить, чтобы выполнить заказ.

1.11 Вне зависимости от того, достаточно ли в данный момент всех позиций в заказе на складе ИС должна сформировать счет, в котором будут перечислены данные заказа с указанием всех позиций товара, их количества и стоимости

1.12 Клиент производит оплату заказа, ИС в данном процессе участие не принимает.

1.13 Оператору интернет-магазина в Magento приходят данные об оплате заказа, он проверяет, чтобы заказ был полностью оплачен, т.е. сумма, внесенная пользователем, полностью соответствовала сумме заказа. Данный функционал уже реализован в Magento.

1.14 В том случае, если сумма, внесенная пользователем, отличается от суммы, заявленной по счету, оператор интернет магазина связывается с клиентом и уточняет условия заказа. Если произошла ошибка отменяет в ИС заказ и вся цепочка повторяется заново.

1.15 Если все данные заказа были внесены верно, то бухгалтер создает продажу на основании заказа. От ИС требуется, чтобы была возможность создать продажу копированием из заказа. В противном случае бухгалтеру нужно будет заново вносить все данные заказа, что может вызвать большое количество ошибок. Бухгалтер сохраняет документ продажа в ИС.

1.16 В момент сохранения документа продажа ИС должна выполнить списание всех перечисленных в документе «Продажа» позиций со склада. Количество списываемых позиций товаров должно полностью соответствовать количеству в документе. ИС должна сгенерировать пакет xml с указанием, какие товары и в каком количестве должны быть списаны. Данный пакет будет загружен в систему Magento и изменит в ней остатки по нужным позициям.

1.17 На основании документа Продажа ИС должна сформировать для покупателя письмо, в котором будут перечислены данные об успешном завершении сделки, указанием количества проданного товара, цен проданного товара.

1.18 На основании документа «Продажа» ИС система должна отправить данные на фискальный регистратор для последующей отправки в налоговую службу. Это необходимо в связи с наличием Федерального закона от 03.07.2016 N 290-ФЗ "О внесении изменений в Федеральный закон "О применении контрольно-кассовой техники при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт" и отдельные законодательные акты Российской Федерации"). Для исполнения данного закона организацией ХХХ был приобретён специальный фискальный аппарат, который может отправлять данные о каждой продаже в налоговую службу. Следовательно, внедряемая система должна быть способна отправлять данные о продаже на фискальный аппарат, чтобы он мог формировать отчетность по НДС. Фискальный аппарат, также принимает на вход xml файл. Таким образом, при сохранении документа «Продажа» ИС будет формировать xml пакет данных, содержащий информацию о продаже и НДС.

3.2 Обработка заказа на продажу физическому лицу в магазине

В случае с обработкой заказа в магазине, исполнителем является продавец в магазине, в отличие от первого сценария вся работа будет происходить только в ИС системе, и интеграция будет затрагивать только выверку остатков между ИС системой и системой Magento. Графическое описание данного сценария работы приводится ниже (Рисунок 5 Заказ в магазине)



Рисунок 5. Заказ в магазине

2.0 Сценарий начинается с того, что клиент, пришедший в магазин организации ХХХ рещается сделать заказ на продажу того или иного товара. Продавец уточняет условия заказа, какие именно товары будут продаваться и в каком количестве. Продавец уточняет согласие и возможность клиента оплатить заказ полностью.

2.1 Когда продацец получает от клиента подтверждение заказа, он создает в ИС документ «Заказ» и сохраняет его.

2.2 При сохранении документа «Заказ» система должна выполнить проверку на наличие достаточного колчества товара на складе. ИС должна проверить каждый товар, указанный в документе, при отсутствии хотя бы одного товара в достаточном количестве, ИС должна выдать продавцу предупреждение о нехватке товара, показать информацию о том, в какой строке документа находится данный документ и какого количества не хватает на складе.

2.3 При нехватке товара, система должна автоматически сформировать заявку на закупку товара, в которой будет указано, какого именно товара и сколько позиций не хватает.

2.4 Для предоставления счета клиенту в магазине нужно, чтобы в системе можно было подготовить специальные печатные формы, соответсвующие ГОСТ. Для простых клиентов для документа заказ будут нужны следующие печатные формы:

· Печатная форма (для простых клиентов)

2.5 После печати документа, продавец передают счет клиенту.

2.6 Клиент оплачивает заказ. Оплата заказа производится наличными средствами или через терминал по карточке. Данные функции не будут реализованы в системе.

2.7 После оплаты заказа клиентом продавец создает в ИС документ «Продажа». Нужно, чтобы данный документ можно было создать в системе копированием из документа Заказ, который был создан ранее.

2.8 При сохранении документа «Продажа» информационная система должна автоматически списать перечисленные в документе позиции на указанного количество. ИС должна сгенерировать пакет xml с указанием, какие товары и в каком количестве должны быть списаны. Данный пакет будет загружен в систему Magento и изменит в ней остатки по нужным позициям. Таким образом, остатки между двумя системами будут выравнены.

2.9 Параллельно со списанием товара со склада на основании документа «Продажа» ИС система должна отправить данные на фискальный регистратор для последующей отправки в налоговую службу. Это необходимо в связи с наличием Федерального закона от 03.07.2016 N 290-ФЗ "О внесении изменений в Федеральный закон "О применении контрольно-кассовой техники при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт" и отдельные законодательные акты Российской Федерации"). Для исполнения данного закона организацией ХХХ был приобретён специальный фискальный аппарат, который может отправлять данные о каждой продаже в налоговую службу. Следовательно, внедряемая система должна быть способна отправлять данные о продаже на фискальный аппарат, чтобы он мог формировать отчетность по НДС. Фискальный аппарат, также принимает на вход xml файл. Таким образом, при сохранении документа «Продажа» ИС будет формировать xml пакет данных, содержащий информацию о продаже и НДС.

2.10 На основании документа продажа должна быть создана печатная форма. При продаже физическому лицу в магазине будет использователься специальная печатная форма:

· «Товарная накладная» (для простых клиентов)

Данная печатная форма будет передана клиенту.

3.3 Обработка заказа на продажу юридическому лицу

В данном сценарии осуществляется продажа юридическому лицу, партнеру, с которым организация ХХХ заключила срочный договор на продажу товаров. Большей частью партнеров компании являются большие сетевые магазины, реализующие мебель и мелкую гарнитуру для дома. Как и в предыдущем сценарии при продаже физическому лицу в магазине в данном случае, все операции по обработке заказа на продажу будут осуществляться в информационной системе. Важно отметить, что в случае с продажей мебели юридическим лицам, крупным магазинам, отвечающим за ее реализацию нужно обязательно учесть требования к печатным формам, предъявляемым каждым отдельным клиентом. Графическое описание данного сценария работы приводится ниже (Рисунок 6 Продажа юридическому лицу)



Рисунок 6. Продажа юридическому лицу

3.0 По договоренности между организацией ХХХ и ее партнерами, заявки на продажу приходят в виде excel файла на почту ответственного по работе с юридическими лицами бухгалтера.

3.1Нужно, чтобы полученный Excel файл можно было выгрузить в информационную систему в виде документа «Заказ». Для этого партнеры готовы присылать заявки на продажу в Excel файле, используя только единый шаблон. После создания документа «Заказ», бухгалтер сохраняет документ в системе.

3.2 При сохранении документ «Заказ» информационная система выполняет автоматическую проверку наличия достаточного количества товара по всем позициям, перечисленным в докуменет «Заказ»

3.3 В том случае, если не хватает хотя бы одной позиции, ИС должна выдать бухгалтеру предупреждение о нехватке товара с указанием, какого именно товара не хватает, в какой строке текущего документа он находится и какого именно количество не хватает. После этого ИС должна автоматически создать заявку на закупку недостающего товара.

3.4 Для предоставления счета клиенту нужно, чтобы в системе можно было подготовить специальные печатные формы, соответсвующие ГОСТ. Для юридических лиц будут нужны следующие печатные формы:

* Счет с артикулом, номером и датой реализации (для юр. лиц)

* Счет с артикулом клиента (для юр. лиц)

3.5 Распечатанная печатная форма заказа запечатывается в конверт и отправляется курьером партнеру для оплаты заказа

3.6 Покупатель юридическое лицо оплачивает заказ, оплата заказа производится вне информационной системы.

3.7 После оплаты юридическим лицом заказа, бухгалтер создает в ИС документ «Продажа». Нужно, чтобы данный документ можно было создать в системе копированием из документа «Заказ», который был создан ранее. Бухгалтер сохраняет документ «Продажа».

3.8 При сохранении документа «Продажа» информационная система должна автоматически списать перечисленные в документе позиции на указанного количество. ИС должна сгенерировать пакет xml с указанием, какие товары и в каком количестве должны быть списаны. Данный пакет будет загружен в систему Magento и изменит в ней остатки по нужным позициям. Таким образом, остатки между двумя системами будут выравнены.

3.9 Параллельно со списанием товара со склада на основании документа «Продажа» ИС система должна отправить данные на фискальный регистратор для последующей отправки в налоговую службу. Это необходимо в связи с наличием Федерального закона от 03.07.2016 N 290-ФЗ "О внесении изменений в Федеральный закон "О применении контрольно-кассовой техники при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт" и отдельные законодательные акты Российской Федерации"). Для исполнения данного закона организацией ХХХ был приобретён специальный фискальный аппарат, который может отправлять данные о каждой продаже в налоговую службу. Следовательно, внедряемая система должна быть способна отправлять данные о продаже на фискальный аппарат, чтобы он мог формировать отчетность по НДС. Фискальный аппарат, также принимает на вход xml файл. Таким образом, при сохранении документа «Продажа» ИС будет формировать xml пакет данных, содержащий информацию о продаже и НДС.

3.10 На основании документа «Продажа» должна быть создана печатная форма. При продаже юридическому лицу будут использователься специальные печатные формы:

* «Торг12 с артикулом» (для юр. лиц)

* «Торг12 с артикулом-2» (для юр. лиц)

* «Торг12 с артикулом и договором» (для юр. лиц)

* «Торг12 с артикулом и магазином (факторинг)» (для юр. лиц)

* «ТН Факторинг» (для юр. лиц)

Для того, чтобы ни одно требование по разработке печатных форм не было упущено, с каждым клиентом-юридическим лицом была проведена встреча, где были оговорены требования к каждой печатной форме, которую система должна генерировать. В итоге был получен список печатных форм, которые должны быть реализованы в системе.

3.3 Обработка заказа на закупку товара

В данном случае обрабатывается сценарий по обработке заказа на закупку товара от поставщика. Так как в данном случае рассматривается работа с юридическим лицом, то очень важным аспектом работы является подготовка печатных форм для документов «Заказ на закупку» и «Закупка». Так же, как и при работе с заказом на продажу юридического лица, заказ на закупку полностью реализуется в ИС. Подробнее сценарий рассмотрен на диаграмме, представленной снизу (Рисунок 7 Заказ на закупку):

Рисунок 7. Заказ на закупку

4.0 В ИС должна быть реализована специальная папка, в которую будут попадать заявки на закупку товара. Бухгалтер, отвечающий за закупку товара на склад, будет проверять наличие новых заявок. Как было оговорено ранее, заявки на закупку в большинстве случаев будут формироваться в ИС автоматически. Однако, в некоторых случаях данные заявки будут формироваться планово, по запланированным закупкам в офисе. В обоих случаях заявки будут попадать в данную папку.

4.1 В ИС должна быть реализована возможность создания заказа на закупку копированием из заявки на закупку. Все перечленные товары в заявке с указанием необходимого количества должны быть перенесены в заявку на закупку.

4.2 Требуется, чтобы в ИС была реализована возможность преобразования «Заказа на закупку» в виде excel файла. По договоренности с поставщиками, заказ на закупку будет отсылаться поставщикам именно в таком виде.

4.3 После получения заказа на закупку поставщик должен будет дать ответ о том, может он выполнить заказ или нет. Ответ будет даваться по телефону и функционал ИС не затрагивает

4.4 В случае отрицательного ответа, бухгалтер подберет другого поставщика и повторит ранее описанну цепочку действий.

4.5 В случае положительного ответа поставщик присылает курьером счет на оплату, данная функция в ИС реализована не будет

4.6 Организация ХХХ производит платеж в соответствии с присланным счетом на оплату, в ИС реализовано не будет

4.7 После оплаты заказа на закупку, бухгалтер создает документ «Закупка». В ИС должна быть реализована возможность создания данного документа копированием из «Заказа на закупку», чтобы избежать неправильного ввода информации

4.8 Создание документа «Закупка» должно автоматически корректировать остатки товаров на складе. При сохранении документа должно происходит увеличение остатков товаров на указанное в закупке количество единиц. Кроме этого должна быть реализованы следующие печатные формы:

· Торг-12 (товарная накладная за поставщика с услугами)

· Торг-12 (товарная накладная за поставщика)

· ОС-14 (акт о приемке оборудования)

· Приходная накладная

3.5 Операции по складу

В данном разделе будут построены три вида складских операций, которые должны быть реализованы в системе. По каждому типу приводятся требования. Варианты складских операций перечислены ниже:

· Поступление и списание товара

· Сборка и разборка товара

· Перемещение товара

Поступление и списание товара

Поступление и списание товара будут инициироваться офисом организации при необходимости корректировки остатков на тех или иных складах. Нужны данные операции для выравнивания остатков, представленных в ИС и остатков по данным инвентаризации. Кроме этого, данные функции будут нужны для отражения изменения количеств товаров, поступающих или списывающихся не через, соответственно, документы закупки или продажи. Например, часто нужно списывать товары, пришедшие в негодность, товары, которые уже нельзя будет продать. Для анализа предъявляемых требований, как и в предыдущих случаях, были построены диаграммы последовательности, представленные ниже (Рисунок 8 Поступление и списание товара):



Рисунок 8. Поступление и списание товара

5.0 Офис сообщает по телефону бухгалтеру о необходимости списания товара, реализуется вне ИС

5.1 На основании полученных данных бухгалтер создает в ИС документ «Поступление товара» и сохраняет его

5.2 При сохранении документа ИС должна автоматически менять остатки товара на указанном в документе склад, должно произойти увеличение запаса на указанное в документе количество

6.0 Так же, как и для поступления товара, списание товара инициирует офис. Офис передают бухгалтеру данные о том, какие товары и в каком количестве нужно списать

6.1 Бухгалтер создает документ «Списание товара» в ИС, где он вносит информация о том, с какого склада, какой товар и в каком количестве должен быть списан

6.2 По желанию организации ХХХ, в ИС должна быть реализована проверка наличия достаточного количества списываемого товара на складе. Сделано это должно быть по той причине, что при возникновении ошибки, нехватки товара для списания, можно будет проверить ее причину- или данные по инвентаризации склада являются неверными, или в системе была совершена ошибка при работе с остатками товара. В любом случае, данная проверка должна поможет устранить ошибку.

6.3 Если данная ошибка появилась, ИС должна показать бухгалтеру предупреждение о том, какого именно товара не хватает и в какой строке документа «Списание товара» данный товар находится.

6.4 Если ошибок найдено не было, то документ сохраняется, количество товара на выбранных складах автоматически корректируется в ИС.

Сборка и разборка товара

Организация ХХХ занимается продажей не только простых товаров, таких как стул, стол, крючки и т.д., но и составных, товаров, состоящих из нескольких товаров, например, гарнитуров или готовых кухонь. При оформлении заказа на такой товар, его нужно предварительно собирать из простых составляющих. Для этого в ИС должны быть реализованы функции «Сборка товара» и «Разборка товара». Разборка товара должна быть сделана для того, чтобы при необходимости можно было в системе разобрать неправильно собранный товар или реализовать простые товары по отдельности. Подробное рассмотрение обоих процессов приведено на схемах ниже (Рисунок 9 Сборка товара) и (Рисунок 10 Разборка товара):



Рисунок 9. Сборка товара

7.0 Офис сообщает бухгалтеру о необходимости сборки товара по телефону, указывая какой именно составной товар и в каком количестве нужно собрать. Данные функции в ИС реализованы не будут

7.1 На основании полученных данных бухгалтер создает в ИС документ «Сборка» и сохраняет его

7.2 При сохранении документа ИС проверяет остатки по простым товарам. Если хотя бы одного из простых товаров не хватает, ИС должна выдать предупреждение с указанием, какого из простых товаров не хватает и в какой строчке документа он находится

7.3 ИС автоматически должна создать заявку на закупку простого товара, с указанием количества, которого не хватает для сохранения документа. Документ «Сборка» не сохраняется

7.4 В случае, если количества простых товаров достаточно, документ «Сборка» сохраняется, ИС автоматически списывает простые товары и приходует составные товары с учетом необходимых количеств.



Рисунок 10. Разборка товара

8.0 Офис сообщает бухгалтеру о необходимости разборки товара по телефону, указывая какой именно составной товар и в каком количестве нужно разобрать. Данные функции в ИС реализованы не будут

8.1 На основании полученных данных бухгалтер создает в ИС документ «Разборка товара» и сохраняет его

8.2 При сохранении документа ИС проверяет остатки по составным товарам. Если составных товаров не хватает, ИС должна выдать предупреждение с указанием, что указанного для разборки количества составных товаров на данный момент не хватает на складе.

8.3 ИС в случае ошибки не будет сохранять документ «Разборка товара». Бухгалтер сообщит в офис о появившейся ошибке. Ошибка может означать два возможных варианта, либо остатки по инвентаризации являются неверными, либо остатки в системе неверны, что нужно будет исправлять через поступление или списание товара.

8.4 В случае, если количества составных товаров достаточно, документ «Разборка товара» сохраняется, ИС автоматически списывает составные товары и приходует простые товары с учетом необходимых количеств.

Перемещение товара

Документ перемещение товара будет использоваться для выравнивания количества товара между различными складами. Подробное описание требований, предъявляемых к системе при реализации данной функции, показано на схеме ниже (Рисунок 11 Перемещение товара):

Рисунок 11. Перемещение товара

9.0 Офис сообщает бухгалтеру о необходимости перемещения товара по телефону, указывая какой именно товар и в каком количестве нужно переместить с одного склада на другой. Данные функции в ИС реализованы не будут.

9.1 На основании полученных данных бухгалтер создает в ИС документ «Перемещение» и сохраняет его

9.2 При сохранении документа ИС проверяет остатки товара по складу, с которого списывается товар. Если на данном складе количества товара не хватает, ИС должна выдать предупреждение с указанием, что указанного для перемещения количества товара на данный момент не хватает на складе.

9.3 ИС в случае ошибки не будет сохранять документ «Перемещение». Бухгалтер сообщит в офис о появившейся ошибке. Ошибка может означать два возможных варианта, либо остатки по инвентаризации являются неверными, либо остатки в системе неверны, что нужно будет исправлять через поступление или списание товара.

9.4 В случае, если количества составных товаров достаточно, документ «Перемещение» сохраняется, ИС автоматически делает списание товара с исходного склада и приходует его на конечном складе.

Заключение

В рамках данной работы было проведено теоретическое обоснование необходимости исследования способов по управлению требованиями к информационной системе, дан краткий анализ трех известных подходов, включающих работу Вигерса, методологию RUP, методологию BABOK. На основании анкетирования были описаны основные критерии выбора методологии. Используя метод Подиновского, была выбрана наиболее релевантная методология для организации ХХХ. В заключение на основании выбранной методологии был проведен анализ требований к ИС системе организации по различным уровням, включающим требования высшего уровня, бизнес требования, требования пользователей и, наконец, функциональные требования.

Список литературы

1. https://babokpage.wordpress.com //[Электронный ресурс] //URL: https://babokpage.wordpress.com/techniques/data-flow-diagrams/ (Дата обращения 11.01.2017 )

2. Business Analysis in Russia // [Электронный ресурс] //URL: http://iiba.ru/babok/chapters-of-babok-version-3/ (Дата обращения 10.01.2017 )

3. Business Analysis in Russia // [Электронный ресурс] // http://iiba.ru/

URL: http://iiba.ru/requirements-analysis/requirements-management-methods/ (Дата обращения 10.01.2017 )

4. Ambler, S.W. (2004). «The Object Primer 3rd Edition: Agile Model Driven Development with UML» 2. New York: Cambridge University Press. www.ambysoft.com/theObjectPrimer.html.

5. https://www.ibm.com //[Электронный ресурс] //

URL:https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf (Дата обращения 10.01.2017 )

6. Вигерс Карл «Разработка требований к программному обеспечению -- М.: Издательсш-торговый дом «Русская Редакция», 2004. --576с.: ил

7. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. пособие. - М.: РУДН, 2008. - 202 с.: ил.

8. A. Cockbum, Selecting a projects methodology, IEEE Software, 2000

9. P. Kruchten, The Rational Unified Process An Introduction Second Edition, USA, 2000

10. P. Hruby, Designing customizable methodologies, 2000

11. Wiegers, K.E. Software Requirements, 2nd ed. Redmond, WA: Microsoft Press, 2003

12. Brackett, J. W. Software Requirements, Software Engineering Institute, Carnegie Mellon University, 1990

13. Karlsson, J. & Ryan, K. "A Cost-Value Approach for Prioritizing Requirements." IEEE Software, 1997

14. Leffingwell, D. & Widrig, D., Managing Software Requirements: A Use Case Approach, 2nd ed. Boston, MA: Addison-Wesley, 2003

15. P. Berander and P. JЁonsson, “Hierarchical cumulative voting (hcv) prioritization of requirements in hierarchies,” International Journal of Software Engineering & Knowledge Engineering, vol. 16, 2006

16. J. Karlsson, “Software requirements prioritizing,” in Requirements Engineering, 1996

17. T. Saaty, The Analytic Hierarchy Process, Planning, Piority Setting, Resource Allocation. New york: McGraw-Hill, 1980

18. J. Karlsson, C. Wohlin, and B. Regnell, “An evaluation of methods for prioritizing software requirements,” Information and Software Technology, vol. 39, 1998

19. L. Lehtola and M. Kauppinen, “Empirical evaluation of two requirements prioritization methods in product development projects book series lecture notes in computer science.” Springer Berlin / Heidelberg, 2004

20. T. Bebensee, I. van de Weerd, and S. Brinkkemper, “Binary priority list for prioritizing software requirements,” 2010

21. ПОДИНОВСКИЙ В.В. Количественная важность критериев, Автоматика и телемеханика. - 2000

22. БАРЫШНИКОВ Ю.М. О среднем числе вариантов, недоминируемых по сравнению В.В. Подиновского, Автоматика и телемеханика. - 1990

23. Гафт М.Г. Принятие решений при многих критериях., Знание, 1979

24. Миркин Б.Г. Проблема группового выбора, Физматлит, 1974

25. Layna Fisher “BPM Excellence in Practice 2010: Successful Process Implementation”, 2010

26. Bizagi Suite “BPMN by example”, 2014

27. Michael Blaha, James Rumbaugh “Object-oriented design with UML, second edition”, 2005

28. Bran Selic , Garth Gullekson , and Paul T. Ward . Real-Time Object-Oriented Modeling, 1994

Размещено на Allbest.ru