Подскажите, стОящая ли это идея, и если да, то с чего начать? (меня интересует подходящий для такого рода проекта стандарт документации).

Отличная идея! Можно изучить кучу нотаций, но теоретические знания никогда не заменит самостоятельный опыт написания документов. Блог лучше документировать в 19 серии. Западные стандарты документов это хорошо, но если брать нынешнюю ситуацию на рынке, то правят бал госзаказчики с 19 и 34 сериями, банки и страховые с российским IT менеджментом тоже частенько предпочитают их. Так что начните с ТЗ

http://www.rugost.com/index.php?option=com_content&view=article&id=54:19201-78&catid=19&Itemid=50

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

Удачи



 

Не надо разрабатывать по ГОСТам ТЗ на блог. Блог – это не программное изделие (тьфу, слово-то какое). Технико-экономическое обоснование, требования к макировке и упаковке – вам это всё надо?

И тем более блог не автоматизированная система, прости господи.

ГОСТ умер, не надо тащить этот труп в интернет-проекты.

Всем привет!
Меня зовут Настя. Я только учусь азам системного аналитика. Хожу на курсы, много читаю с перспективой на работу младшим аналитиком. И перед тем как попробовать свои силы на собеседовании решила создать ТЗ и прочую прилагающуюся документацию на разработку блога.

А что за курсы такие, что ТЗ вы там не пишете и его надо писать отдельно? У нас например такие, что можно брать ТЗ, разработанное на курсе и показывать работодателю.

И проект будет не про блог, а про нечто более бизнесовое — CRM там, система финансового учёта и т.д.

Не надо разрабатывать по ГОСТам ТЗ на блог. Блог – это не программное изделие (тьфу, слово-то какое). Технико-экономическое обоснование, требования к макировке и упаковке – вам это всё надо?

И тем более блог не автоматизированная система, прости господи.

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

ГОСТ умер, не надо тащить этот труп в интернет-проекты.

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

А что за курсы такие, что ТЗ вы там не пишете и его надо писать отдельно? У нас например такие, что можно брать ТЗ, разработанное на курсе и показывать работодателю.

И проект будет не про блог, а про нечто более бизнесовое — CRM там, система финансового учёта и т.д.

На курсах, конечно, пишем ТЗ. За основу берем то, с чем работаем на реальной работе (на своей нынешней работе я частично участвую в проекте по разработки ПО, но на собеседование хочу принести что-то только свое, созданное именно мной, а не скопированное. Хочу быть честной перед самой собой)

Согласна, что блог не самый серьезный проект для разработки, условно говоря думаете на собеседовании не зачтут его?

Не надо разрабатывать по ГОСТам ТЗ на блог. Блог – это не программное изделие (тьфу, слово-то какое). Технико-экономическое обоснование, требования к макировке и упаковке – вам это всё надо?

И тем более блог не автоматизированная система, прости господи.

ГОСТ умер, не надо тащить этот труп в интернет-проекты.

Григорий, а что по вашему мнению стоит использовать в данном случае?

Григорий, а что по вашему мнению стоит использовать в данном случае?

Если нужно описать требования от целей создания продукта до уровня ролей пользователей и функций, то я бы начал с Концепции. Вот здесь есть неплохой набор шаблонов, можно взять шаблон концепции из него. http://michaelsmirnov.blogspot.ru/2011/02/blog-post.html

На более низком уровне можно попрактиковаться в разработке SRS по стандарту IEEE 830 или по рекомендациям Вигерса (это практически одно и то же): https://ru.wikipedia.org/wiki/Спецификация_программного_обеспечения

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

ГОСТы дают шаблоны, но ничего не говорят о том, как нужно работать с информацией для их заполнения. Многие термины устарели, и люди пишут туда всякий бред из-за того, что не понимают значения этих терминов. Вот здесь примеры наиболее распространённых ловушек: https://www.webursitet.ru/article/terminologicheskie-lovushki-gost-34.html

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

Ниже пример структуры реального ТЗ без воды.

ТЗ с такой структурой прекрасно пишется и по 19 и по 34 серии. Все страхи ГОСТ связаны с тем есть категория заказчиков и аналитиков , которые не имеют опыта их применения. Там, где есть культура использования ГОСТ и заказчиком, и исполнителем подобных проблем не существуют. Проблемы появляются там, где заказчик пытается использовать ГОСТы не как язык взаимодействия с исполнителем, а только из страха перед проверками. 

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

Терминологические отличия необходимо исследовать при освоении любой нотации или методологии - например при изучении UML приходится соотносить Actor и User, Концепции по ГОСТ в большей мере соответствует BRD, а не Vision, Vision при этом реализуется  в форме НИР, требования к безопасности определяются в 34 ГОСТ, который предусматривает материальную составляющую, причем совершенно необязательно в форме серверной и рабочей станции.

Если руководствоваться здравым смыслом, то его просто не нужно включать в ТЗ.

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




 

Humbert, вы путаете уровни профессионального развития новичок — опытный — мастер.

Тут в теме вопросы задают новички, которые не знают, как адаптировать шаблоны и стандарты под задачу.

Хендрикс вам и на фанерной щепке Purple haze сыграет.

Тут в теме вопросы задают новички, которые не знают, как адаптировать шаблоны и стандарты под задачу.

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

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

Требование знания 19 и 34 серий - это реалии рынка. Эти требования отражаются в большинстве тендерной и конкурсной документации.

Это не требования к начинающему аналитику. Это требования к компании-подрядчику.
Не говоря уже о том, что кроме:
1) заказной разработки с пиететом к ГОСТам,

есть

2) заказная разработка без пиетета к ГОСТам,
3) внутренняя разработка
4) продуктовая разработка

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

Давайте проверим. Идем на HH.ru, смотрим вакансии системных аналитиков — 219 штук в москве.
Смотрим, в каком количестве вакансий системных аналитиков упоминается слово "гост" — 35.

Это 16%, одна шестая рынка.

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

При необходимости с этим справляются 1) обычные 2) старшие и 3) ведущие ИТ-аналитики, а не младшие.

Давайте проверим. Идем на HH.ru, смотрим вакансии системных аналитиков — 219 штук в москве.
Смотрим, в каком количестве вакансий системных аналитиков упоминается слово "гост" — 35.

Это 16%, одна шестая рынка.

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

Буду рада получить любые советы и рассказы из личного опыта. Заранее благодарю!

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

1. Вы только учитесь азам, с ваших же слов. То есть, что-то знаете, но ничего не умеете. Это нормально в вашей ситуации, стесняться этого не надо.
2. Вы хотите сделать то, чего делать не умеете, чтобы похвастаться результатами перед тем кто, скорее всего, умеет. Это неплохой способ заработать себе репутацию милого дитя, или (если настроение будет похуже) дурака с инициативой. Оно, конечно, может быть оценено и как "ну надо же, все террибль инфанты несут ахинею из статеек "6 правильных ответов на собеседовании", а эта чего-то там попыталась накарябать, ну-ка, заценим". Но первый вариант, на мой вкус, вероятнее.
3. Я бы пошел собеседоваться с тем, чем реально располагаю. Во-первых, желанием работать. Во-вторых, с внятным обоснованием, зачем мне это нужно (почему интересно). В-третьих, реальными делами на этом поприще: чем-то изученным самостоятельно, какими-то пройденными курсами. Да, теория. Но все равно, силы и время на нее потрачены вполне практические.

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

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

P.S. про отделы все совершенно верно, я пожалуй этим и займусь (про общение с отделом BA)

Очень интересно, чем сейчас занимается автор темы: вот прошло 9 лет, тогда он был студентом 4-го курса и перся от программирования.
Где он сейчас?))

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

Нужно просто рассылать по 200 резюме в неделю, потому что стандартный отклик 3-4%. И он не зависит от вашего опыта. Проверено лично)