немного исправила.

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

по схеме вроде все понятно. теперь попробуйте детализировать перечисленные бизнес-функции и дополнить документами (детали см выше).

мы и есть организация-заказчик.

аааа, понятно. тогда вопрос контроля несколько упрощается. но странно, что учета нет.

поняла. делаю

сделала примерную детализацию. застряла на контроле.
а где описывать документы?

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

докуенты. не уверена

дубль два

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

На примере заявки попробую пояснить, только не списывайте сразу и напрямую, я ведь мог ошибиться и написать не так как у вас происходит.
 - прораб берет чистый бланк заявки (так ведь?) и заполняет позиции нужными ему материалами (как он материалы записывает? есть какие-то коды/номенклатуры? или просто названия?)
 - главный инженер строительства подписывает (утверждает) заявку
 - прораб несет подписанную заявку снабженцу.
 - что происходит с заявкой дальше? может снабженец с ней что-то делает? номер дает? подписывает? подшивает? что?

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

ну и про контроль исполнения заказа тоже что-то должно быть.

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

понятно. пытаюсь сделать

доработала детализацию

еще файлик

надеюсь, правильно Вас поняла.

да, по картинке в целом заметно, что появилось некое понимание, есть ряд ошибок, связанных с появлением документов (договор, доверенность) "из ниоткуда", но эти документы могут быть внесистемными (бумажными) и существовать априори - это нужно отдельно оговаривать. несколько смущает, что функция контроля не имеет входящих документов. это неправильно, ведь нельзя контролировать не получая информации.
в общем теперь нужно читать вашу же детализацию и устранять несоответствия процесса и описания, за основу берется описание.

по детализации, кстати, очень даже неплохо. если посмотреть внимательно, то можно даже найти много полезного за что зацепиться (в хорошем смысле) при дальнейшем проектировании системы: папочка, куда подшиваются заявки, папочка с прайс-листами поставщиков (кстати, для нового поставщика его прайс-лист тоже подшивается), папочка с прайсами транспортных компаний (а про подшивание их данных - есть).
оплата материала и оплата доставки, как бы ни были они похожи - это разные вещи. я бы порекомендовал разделить, а второе включить в доставку, т.к. доставка у вас будет по сути отдельной функцией со всеми ее прибамбасами, потому что основной акцент системы - на движение материалов.
только не путайте заявки и заказы. лучше намеренно использовать разные термины. один вопрос так и остался неотвеченным: по одной заявке всегда один заказ на одного поставщика на определенный вид продукции? или все-таки происходит какая-то перекомпоновка заказов для увеличения объема в целях снижения цены?

насчет приемки много вопросов, но не к описанию, а к предметной области. что значит доставлен верно? столько сколько заказывали? или столько сколько в ТТН? конечно корректный учет факта важен, но недостаточен для решаемой задачи, нужно будет ориентироваться на обеспечение соответствия нужному количеству, т.е. становятся существенными некоторые контрольные действия, как у вас написано, по работе с поставщиком и транспортной компанией (кстати, сроки не задерживаются, задерживается поставка, а сроки могут нарушаться). это важно, т.к. они точно должны будут выполняться с помощью системы, помимо очной проверки.
как с проверкой наличия при отпуске со склада?

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

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

теперь нужно вычленить из детализации (достаточно распечатать и обвести чем-нить) моменты, которые вы точно должны будете сделать в системе. вы это должны знать из:
 - исходно поставленной задачи
 - понимания предметной области, важности тех или иных элементов, сущностей, операций.
 - понимания каких-то особенности и исходя из удобства работы (в смысле решения задачи, стоящей перед ними)будущих пользователей.
из этого нужно будет сделать usecases системы. потом продумать поведение (что будет после того как пользователь сделает то-то), роли пользователей тоже нужно продумать
нужно придумать как будет "выглядеть" система: с какими формами будут работать пользователи.  и тд и тп.
и не нужно хвататься за все сразу и "засовывать" в систему все ваше описание. определите ядро и сделайте его. остальное добавите позже. лучше получить компактную (пусть даже неполную во второстепенных функциях) и работающую систему, чем сделать огромную и рыхлую хрень, с которой только проблемы.

из всего этого рождаются требования к системе. а дальше реализация. по использованию uml для создания системы могу посоветовать книжку Крэга Лармана (она и в магазинах должна быть, и в интернете есть), неоднократно здесь упоминавшуюся. почитайте также тему по usecase, которая много обсуждалась в последнее время.

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

думаю, что первый урок вполне успешно окончен :о)))




 

Вы невероятную помощь мне оказываете! спасибо Вам огромное!
если Вас не затруднит, то я буду выкладывать свои результаты.
Спасибо еще раз!