Как разработать техническое задание для автоматизированной системы

Как разработать техническое задание для автоматизированной системы

Александр Чавалах Исполнительный директор, Петербург

Любой проект по внедрению автоматизированной совокупности начинается с разработки технического задания. Какую часть работ нужно согласовать с клиентом, какие конкретно нюансы учесть, какова структура данного документа? Об этом в статье Александра Чавалаха.

Как верно создать техническое задание для автоматизированной совокупности? Данный вопрос такой широкий, что ответить кратко никак запрещено. Исходя из этого я решил написать громадную статью на данную тему. В ходе работы я осознал, что уложить все в одной статье не выйдет и решил разбить ее на две части:

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

Для начала нужно разобраться, какой в конечном итоге вопрос интересует тех, кто задаёт вопросы «Как создать техническое задание?». Дело в том, что от того, для каких целей это делается, и кем будет употребляться, будет очень сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:

  • Коммерческая структура решила внедрить у себя автоматизированную совокупность. Она не имеет собственной IT-работы и решили поступить так: заинтересованное лицо должно создать ТЗ и дать его на разработку сторонней организации;
  • Коммерческая структура решила внедрить у себя автоматизированную совокупность. Она имеет собственную IT-работу. Решили поступить так: создать техническое задание, после этого согласовать его между IT-заинтересованными лицами и службой, и реализовать сомостоятельно;
  • Государственная структура решила затеять IT-проект. Тут все так мутно, куча формальностей, откатов, распилов и пр. Я не буду разглядывать таковой вариант в данной статье.
  • IT-компания занимается одолжениями по разработке и/либо внедрению автоматизированных совокупностей. Это самый сложный случай, поскольку приходится трудиться в самых разных условиях:

1) Клиент имеет собственных экспертов со собственными взорами, и они предъявляют конкретные требования к техническому заданию.
2) Техническое задание разрабатывается для собственных разработчиков (клиенту все равно).
3) Техническое задание разрабатывается для передачи подрядчику (группе программистов, находящихся за штатом компании, либо отдельному эксперту).
4) Между компаний и клиентом появляется непонимание в вопросе взятого результата, и компания снова и снова задается вопросом: «Как нужно разрабатывать техническое задание?». Быть может, последний случай думается парадоксом, но это правда.

  • Вероятны и другие, реже видящиеся варианты;

Думаю, на данный момент у читателя должны появиться вопросы:

  • А из-за чего нельзя разрабатывать техническое задание неизменно одинаково?
  • Существуют ли какие-то стандарты, методики, советы? Где их забрать?
  • Кто обязан разрабатывать техническое задание? Обязан ли данный человек владеть какими-то особыми знаниями?
  • Как осознать, прекрасно составлено техническое задание либо нет?
  • За чей счет должно оно разрабатываться, да и необходимо ли оно по большому счету?

Данный перечень возможно нескончаемым. Говорю так с уверенностью от того, что уже 15 лет в опытной разработке ПО, а вопрос о технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться трудиться. Обстоятельства тому различные.

Поднимая тему разработки технического задания, я замечательно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попытаюсь, как говорится «разложить все по полочкам».

Те, кто уже знаком с моими статьями, знают, что я не пользуюсь «копипастом» труда вторых людей, не перепечатываю чужие книги, не цитирую прочие документы и многостраничные стандарты, каковые вы и сами сможете отыскать в сети, выдавая их за собственные очень способные мысли. Достаточно собрать в поисковике «Как создать техническое задание» и вы сможете прочесть большое количество занимательного, но многократно повторяющегося. В большинстве случаев, те, кто обожает умничать на форумах (попытайтесь все-таки поискать!), сами ни при каких обстоятельствах не делали толкового ТЗ, и непрерывно цитируют советы ГОСТов по этому вопросу. А тем, кто вправду без шуток занимается вопросом, в большинстве случаев некогда сидеть на форумах.

Про ГОСТЫ, кстати, мы также поболтаем.

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

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

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

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

Что такое техническое задание?

Первое, что мы на данный момент сделаем, так это разберемся – что за зверь таковой – «Техзадание».

Да, вправду существуют стандарты и Госты, в которых предприняты попытки регламентировать эту часть деятельности (разработки ПО). Когда-то все эти ГОСТы были актуальны и активно использовались. на данный момент существуют различные точки зрения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были созданы весьма предусмотрительными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели.

Быть может, кто-то на данный момент поразмыслил, что правда где-то посередине. Я бы ответил словами Иоганна Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни за что! Между ними лежит неприятность».

Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических неприятностей современной разработки, а те, кто их осуждает, альтернативы (конкретной и системной) не предлагают.

Увидим, что в ГОСТе очевидно не дано кроме того определения, сообщено только: «ТЗ на АС есть главным документом, определяющим требования и порядок создания (развития либо модернизации – потом создания) автоматизированной совокупности, в соответствии с которым проводится разработка ее приёмка и АС при вводе в воздействие».

В случае если кому-то весьма интересно, о каких ГОСТах я говорю, то вот они:

  • ГОСТ 2.114-95 «Единая совокупность конструкторской документации. Технические условия»;
  • ГОСТ 19.201-78 «Единая совокупность программной документации. Техническое задание. Требования к оформлению и содержанию»;
  • ГОСТ 34.602-89 «Информационная разработка. Комплекс стандартов на автоматизированные совокупности. Техническое задание на создание автоматизированной совокупности».

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

Хорошее определение, всецело раскрывающее сущность. Но, требования ГОСТа направлены именно на раскрытие этого определения. Я ни за что не осуждаю требования ГОСТа, я , что их в том месте очевидно не хватает, дабы создать действенное техническое задание. И это естественно, поскольку имеется ГОСТ, к примеру, на изготовление хлеба, и это вовсе не означает, что любой человек может выпечь хлеб по ГОСТу. Не считая ГОСТа требуется практик и знание методик, как в любом деле.

Этот факт лежит в корне неприятности, которая лежит посередине. А многие эксперты почему-то при необходимости создать техническое задание, обращаются лишь к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что окажется!

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

Очень многое в собственной практике я применял оттуда, а в то время, когда трудился над данной статьей, то также отыскал большое количество увлекательных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не требуется, но имеется потребность систематизировать эти знания. Кстати, интересный факт, ни одного отечественного автора в этих трудах нет.

Вся литература в переводе с западных авторов, но каких! Среди них имеется легко виртуозы собственного дела, у которых имеется чему поучиться и необходимо это делать. В противном случае, споры о том «Как создать техническое задание» будут длиться вечно. Но я увлекся лирикой…

Итак, как направляться из определения, главное назначение техзадания – сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной совокупности. Настало время взяться за основное: разложить все «по полочкам», как и давал слово.

Что нужно знать о требованиях? Нужно четко осознавать, что все требования необходимо разделять по видам и по особенностям. на данный момент мы обучимся это делать.

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

  • Требования в функциональности;
  • Требования к правам и безопасности доступа;
  • Требования к квалификации персонала и т.д.

Вы имеете возможность прочесть о них в упомянутом ГОСТе (ниже я их также разгляжу подробнее).

Думаю, вам разумеется, что главным причиной успешного технического задания являются как раз прекрасно сформулированные требования к функциональности. Как раз этим требованиям посвящено большая часть методик и работ, о которых я сказал. Требования к функциональности – это 90% сложности работ по разработке технического задания. Все другое обычно есть «камуфляжем», что надет на эти требования. В случае если требования сформулированы не хорошо, то какой прекрасный камуфляж на них не натягивай, успешного проекта не выйдет.

Да, формально все требования будут соблюдены (по ГОСТу), ТЗ создано, утверждено и подписано, деньги за него взяты. И что? А дальше начнется самое занимательное: что делать-то? В случае если это проект на Госзаказе, то неприятностей нет – в том месте бюджет таковой, что ни в какой карман не влезет, в ходе реализации (если она будет) все и будет выясняться.

Как раз так и пилится большая часть бюджетов проектов на Госзаказах. (Накалякали «ТЗ», слили дюжина миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто около дома. Красота!).

Но так как мы говорим о коммерческих структурах, где деньги вычисляют, да и итог нужен второй. Исходя из этого позволяйте разбираться с главным, как разрабатывать нужные и трудящиеся ТЗ.

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

1. Требование должно быть понятным;
2. Требование должно быть конкретным;
3. Требование должно быть тестируемым;

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

В то время, когда разберешься.

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

  • На каком языке (в смысле сложности понимания) должно быть написано техническое задание?
  • Должны ли быть обрисованы в нем спецификации разных функций, методы, типы данных и другие технические штуки?
  • А что такое техническое проектирование, о котором, кстати, сообщено и в ГОСТах, и как оно связано с техническим заданием?

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

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

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

Данный человек обязан сказать с клиентом на языке его бизнеса.

Технический проект – это документ, что рекомендован для технической реализации требований, сформулированных в техническом задании. Именно в этом документе описываются структуры данных, триггеры и хранимые процедуры, прочие штуки и алгоритмы, каковые потребуются техническим экспертам. Клиенту в это вникать вовсе необязательно (ему и термины такие смогут быть непонятны). Технический проект делает архитектор совокупности (вот совмещение данной роли с программистом в полной мере нормально). А правильнее несколько экспертов АО в главе с архитектором.

Чем больше проект, тем больше людей трудится над техническим заданием.

Что мы имеем на практике? Забавно замечать, в то время, когда директору приносят на согласование техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, само собой разумеется, пробует вникнуть, раз нужно утверждать, пробуя отыскать между строчков привычные слова и не утратить цепочку бизнес-требований. Что, знакомая обстановка? И чем это заканчивается?

В большинстве случаев, такое ТЗ утверждается, после этого реализуется, а в 80% случаев позже совсем не соответствует факту выполненных работ – большое количество чего решили поменять, переделать, неправильно осознали, не так думали и т.д. А позже начинается сериал про сдачу работ. «А вот тут не так как нам нужно», а «это у нас трудиться не будет», «это через чур сложно», «это некомфортно» и т.д. Знакомо?!

Вот и мне знакомо, было нужно набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между техническим проектом и техническим заданием. Она плавает между ТЗ и ТП в самых различных проявлениях.

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

Имеется и еще один серьёзный фактор, воздействующий на применение технического проекта как отдельного документа: стремительное развитие средств стремительной разработки, и методик разработки. Но это отдельная история, чуть ниже пара слов об этом сообщу.

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

Но используется не на громадных проектах, а на небольших доработках. Я бы сообщил, это ближе к сопровождению программного продукта. В этом случае в техническом задании возможно обрисовано и конкретное техническое ответ реализации требования.

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

А необходимо ли по большому счету техническое задание? А технический проект?

Не перегрелся ли я? Разве такое быть может, по большому счету без технического задания? Представьте себе вероятно (правильнее, видится), и у для того чтобы подхода имеется большое количество последователей, и их число возрастает. В большинстве случаев, по окончании того, как юные эксперты начитаются книг про Scrum, Agile и другие технологии стремительной разработки.

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

Именно в том месте требования и фиксируются исходя из трех превосходных особенностей, о которых я сказал выше. Легко у некоторых людей так устроено сознание, что в случае если возможно что-то упростить, так давайте это упростим до полного отсутствия. Как сообщил Альберт Эйнштейн: «Сделай так легко, как быть может, но не несложнее этого». Золотые так как слова, ко всему подходят.

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

В принципе, я с этим согласен.

А что же с техническим проектом? Этот документ очень нужный и не потерял актуальность . Более того, довольно часто без него просто не обойтись. Особенно, в случае если речь заходит о передаче работ по разработке на сторону, по принципу аутсорсинга. В случае если этого не сделать, имеется риск определить большое количество нового о том, как обязана смотреться совокупность, которую вы задумали.

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

Кстати, все они базируются на хорошем XP-подходе (экстремальном программировании), которому уже порядка 20 лет. Так что сделайте качественное ТЗ, понятное клиенту, а технический проект применяйте как внутренний документ, для взаимоотношений между программистами и архитектором системы.

Увлекательная подробность по поводу технического проектирования: кое-какие средства разработки, устроенные по принципу предметной ориентированности (типа 1С и подобных) предполагают, что проектирование (имеется в виду процесс документирования) требуется лишь на вправду сложных участках, где требуется сотрудничество между собой целых систем. В несложном случае, к примеру, создать справочник, документ, достаточно только верно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса данной платформы в части подготовки экспертов. В случае если взглянуть на экзаменационный билет эксперта (как раз так он именуется, а не «программиста»), то заметите, что в том месте присутствуют только бизнес-требования, а как их реализовать на программном языке это и имеется задача эксперта.

Ту часть задачи, которую призван решать технический проект, эксперт обязан решить «в голове» (речь заходит о задачах средней сложности), причем тут и по сей день, следуя определенным стандартам проектирования и разработки, каковые формирует снова же компания 1С для собственной платформы. Так, из двух экспертов, итог работы которых снаружи выглядит одинаково, один может экзамен сдать, а второй нет, поскольку грубо нарушил стандарты разработки. Заведомо предполагается, что эксперты должны владеть таковой квалификацией, дабы обычные задачи проектировать самостоятельно, без привлечения архитекторов совокупности.

И таковой подход трудится.

Продолжим изучение вопроса: «Какие конкретно требования включать в техническое задание?»

Формулирование требований к информационной совокупности. Структура ТЗ

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

Это теорема. Почему-то кое-какие начальники пробуют ее опровергнуть, считая, что в случае если приобретут программу, то наступит порядок в хаотичном бизнесе. Но так как теорема на то и теорема, что доказательств не требует.

Как и любую деятельность, формулирование требований возможно (и необходимо) поделить на этапы. Всему собственный время. Это тяжелый интеллектуальный труд. И, в случае если относится к нему с недостаточным вниманием, то итог будет соответствующий.

По экспертным оценкам, цена затрат на разработку технического задания может составлять 30-50%. Я придерживаюсь для того чтобы же мнения. Не смотря на то, что 50 – пожалуй, перебор. Так как техническое задание – это еще не последний документ, что должен быть создан.

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

В случае если речь заходит о внедрении совокупности на платформе 1С, то тут с проектированием обстановка пара другая, как мы видели выше (не смотря на то, что, при разработке совокупности «с нуля», она проектируется по классической схеме).

Не обращая внимания на то, что формулировка требований есть главной частью технического задания, в некоторых случая она делается единственным разделом ТЗ, направляться обратить внимание на то, что это серьёзный документ, и оформлять его направляться соответственно. С чего начать? Прежде всего начать нужно с содержания. Составьте содержание, а после этого начните его разворачивать. Я делаю так: сперва набрасываю содержание, обрисовываю цели, всю вводную данные, а после этого принимаюсь за главную часть – формулировку требований. Из-за чего не наоборот?

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

Для начала советую в качестве содержания забрать как раз тот, что обрисован в ГОСТ. Для содержания он подходит превосходно! После этого берем и начинаем обрисовывать любой раздел, не забывая про советы следования трем особенностям: понятности, конкретности и тестируемости. Из-за чего я на этом так настаиваю? Об этом в следующем разделе.

А на данный момент предлагаю все-таки прогуляться по тем пунктам ТЗ, каковые рекомендуются в ГОСТе.

Итак, ГОСТ рекомендует следующие разделы:

1. Неспециализированные сведения.

2. цели и Назначение создания (развития) совокупности.

3. Черта объектов автоматизации.

4. Требования к совокупности.

5. содержание и Состав работ по созданию совокупности.

6. приёмки системы и Порядок контроля.

7. Требования к содержанию и составу работ по подготовке объекта автоматизации к вводу совокупности в воздействие.

8. Требования к документированию.

9. Источники разработки.

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

Раздел 1. Неспециализированные сведения

Советы по ГОСТ

Что с этим делать на практике

Полное наименование совокупности и ее условное обозначение;

Тут все ясно: пишем, как будет именоваться совокупность, ее краткое наименование

Шифр темы либо шифр (номер) соглашения;

Это не актуально, но возможно и указать, в случае если требуется

Наименование заказчика (объединений) пользователя и предприятий (разработчика) совокупности и их реквизиты;

Показывают, кто (какие конкретно организации) будет трудиться над проектом. Возможно указать и их роли.

Возможно по большому счету удалить данный раздел (достаточно формальный).

Список документов, на основании которых создается совокупность, кем и в то время, когда утверждены эти документы;

Нужная информация. Тут стоит указать ту нормативно-справочную документацию, которую вам предоставили для ознакомления с определенной частью требований

Плановые сроки начала и окончания работы по созданию совокупности;

Пожелания по срокам. Время от времени в ТЗ об этом пишут, но чаще такие вещи описываются в соглашениях на работы

Сведения об порядке и источниках финансирования работ;

Подобно, как и в прошлом пункте про сроки. Более актуально для госзаказов (для бюджетников)

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

Не вижу необходимости в этом пункте, требования к документированию вынесены раздельно, а также имеется целый приёмки раздел «системы и отдельный Порядок» контроля.

Раздел 2. цели и Назначение создания (развития) совокупности

Советы по ГОСТ

Что с этим делать на практике

Назначение совокупности

С одной стороны с назначением все легко. Но нужно формулировать конкретно. В случае если написать что-то наподобие «как следует автоматизировать складской учет в компании Х», то позже возможно продолжительно обсуждать итог при его завершении, кроме того независимо от хорошей формулировки требований. Клиент неизменно может сказать, что под качеством он имел в виду что-то иное. В общем, нервов возможно попортить друг другу большое количество, а для чего? Лучше сходу написать приблизительно так: «Совокупность предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном техническом задании».

Цели создания совокупности

Цели – это, непременно, ответственный раздел. В случае если уж его включать, то нужно мочь эти цели формулировать. В случае если у вас проблемы с формулировкой целей, то лучше по большому счету исключить этот раздел. Пример неудачной цели: «Обеспечить стремительное оформление документов менеджером». Что такое стремительное? Это возможно позже обосновывать вечно. В случае если это принципиально важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строчков за 10 мин.». Подобная цель может показаться, в случае если, к примеру, на данный момент менеджер тратит на это около часа, что через чур много для данной компании и для них это принципиально важно. В таковой формулировке цель уже пересекается с требованиями, что в полной мере конечно, при разворачивании дерева целей (дробя их на более небольшие связанные цели), мы и без того будем приближаться к требованиям. Исходя из этого, увлекаться не следует.

По большому счету, умение выделять цели, формулировать их, строить дерево целей – это тема совсем отдельная. Запомните основное: можете – пишите, не уверены – по большому счету не пишите. А что будет, если не сформулировать цели? Станете трудиться по требованиям, такое довольно часто практикуется.

Раздел 3. Черта объектов автоматизации

Советы по ГОСТ

Что с этим делать на практике

Краткие сведения об объекте автоматизации либо ссы

spacer