Рубрика «разработка требований»

В 2018-м году переиздали книгу «Разработка требований к программному обеспечению». Коллеги прислали мне ссылку на издание. Авторы добавили приёмы для работы в agile-проектах, определение роли аналитика и рекомендации по автоматизации. В Сети ходят крайне противоречивые отзывы. Заказал книгу и разобрался в вопросе.
Читать полностью »

Разработка через тестирование (TDD) – отличный способ повысить качество и надежность кода. Этот же подход может быть распространен и на разработку требований. Он называется "Разработка через приемочные тесты" – acceptance test driven development (ATDD). Сначала я присматривался к этому подходу, потом пробовал применить, потом долго тюнинговал, чтобы приспособить его под мои нужды, и теперь хочу поделиться мыслями. И для себя еще раз разложить все по полочкам.

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

Читать полностью »

REQ Labs 2017. Онлайн-конференция для бизнес- и системных аналитиков - 1Уважаемые коллеги, приглашаем вас принять участие в четвёртой онлайн-конференции посвящённой бизнес- и системному анализу REQ Labs 2017. Формат мероприятия остаётся прежним, мы делимся своим опытом, вы задаёте свои каверзные вопросы.

30 сентября с 11:30 до 18:00 по московскому времени представим на ваш суд четыре презентации:

  • Павел Цытович расскажет о разработке языка описания предметной области на этапе сбора и анализа требований;
  • Вместе с Дмитрием Приймаком разберёмся в вопросе, какие качества важны для современного аналитика с точки зрения BABOK;
  • Ксения Вигандт поделится опытом в области создания автоматизированных тестов для оценки знаний системных аналитиков;
  • Кирилл Барабанов расскажет как разрабатывались требования DWH/BI для Capital Markets IT.

Читать полностью »

Вступление

Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.

Поддерживает и развивает всю систему команда аналитиков. За это время у нас выработались правила, которые, по моему мнению, помогут всем аналитикам (бизнес, требований) и менеджерам, сотрудникам поддержки и даже немного разработчикам в крупном enterprise сегменте.
Читать полностью »

Вступление к переводу

Мы все с вами ежедневно сталкиваемся с нефункциональными требованиями. Мы приходим в мебельный магазин, садимся на кресло и говорим «не удобно» или «это долго не проживет». Мы приходим выбирать автомобиль и не спрашиваем может ли машина разгоняться (функциональное требование), мы спрашиваем за сколько она может разогнаться до 100 км (нефункциональное требование)?
Когда мы проектируем системы, от которых будет зависеть жизнь и здоровье людей, нас интересует их надежность — важное нефункциональное требование.

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

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

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

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

Поэтому предлагаю небольшой crash-тест для тех, кто хочет стать системными аналитиками или для тех, кто хочет взять себе системных аналитиков. Безусловно он не исчерпывающий, но такие точечные «удары», позволяют быстро оценить «глубину проникновения» в процесс проектирования и узнать много нового от собеседника.Читать полностью »

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

1. Предпроектные работы

2. Выявление требований

Читать полностью »

В ноябре 2012 в МГТУ им. Баумана мы провели
открытое событие «Введение в профессию системного аналитика».

Наконец стала доступна первая часть видео, выступление
Сергея Нужненко на тему «В чём заключается работа системного аналитика»:

1. Мифы о задачах и ответственности. Смежные роли (5 минут): vimeo.com/61652862

2. Риски и неопределённость. Место и задачи в проектном цикле (18 минут): vimeo.com/61968936

3. Окружение, предмет и модель работы. Типовые процессы (10 минут): vimeo.com/62449309

Читать полностью »

Ведь, если лампочки зажигают –
значит – это кому-нибудь нужно?

Послушайте!

Кому-нибудь из тех, кто не мыслит жизни без свободы… от наличия на небе естественных светил. А ведь наши далёкие предки, в большинстве своём, безальтернативно посвящали ночное время глубокому сну. Да, чего уж там! Говорят, пока лампа Эдисона не завоевала популярность, люди спали по 10 часов в сутки. Лично я, находясь в потоке, не могу спать больше пяти. Но даже этого слишком много! Часто бывает достаточно трёх. Только без удобного и безопасного искусственного света о подобном оставалось бы лишь мечтать.

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

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

В минувшем году я окончательно пришёл к тому, что ныне склонен называть Advanced Agile Analysis. То, что помогло мне, подобно Эдисону, стать человеком-батарейкой, обеспечивая эффект технологических проектов вместо традиционного поклонения краткосрочным успехам, процессам и инструментам.

Читать полностью »

image

5 Whys — как лекарство против Muda

...«Муда» как любые действия, которые не добавляют ценности, не могут и не должны быть неизбежными, а значит, они должны непрерывно устраняться…
Масааки Имаи «Гемба Кайдзен»

Понаблюдав можно заметить, что в повседневной жизни мы имеем дело с “цепочками создания ценности”, т.е. выполняем различные действия, направленные на достижение целей. Очень часто наши цели являются отправными точками для достижения других целей. Часто мы выполняем действия даже не подразумевая “зачем?”, таким образом тратя время и силы на действия не приносящие ценности (Muda) или тратя силы и время на результаты, которые того и не стоят…
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js