#требования — Public Fediverse posts

Что не так с требованиями у вас на проекте и как это связано с мотивацией команды

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

https://habr.com/ru/companies/otus/articles/1030100/

#требования #бизнесанализ #системный_анализ #команда_разработки #мотивация_команды #заказчик #коммуникация #управление_требованиями #приоритизация #проектный_хаос

Как устроена разработка ПО: разбираем Waterfall и Agile

Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.

https://habr.com/ru/companies/otus/articles/1022180/

#Waterfall #Agile #Scrum #методологии_разработки #процесс_разработки_ПО #системный_анализ #требования #проектирование #обратная_связь #гибридный_подход

Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%

Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.

https://habr.com/ru/articles/1032000/

#управление_проектами #agile #scrum #бэклог #выгорание #метрики #уточнение_задач #планирование_итерации #требования #команда

Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%

Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.

https://habr.com/ru/articles/1032000/

#управление_проектами #agile #scrum #бэклог #выгорание #метрики #уточнение_задач #планирование_итерации #требования #команда

Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%

Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.

https://habr.com/ru/articles/1032000/

#управление_проектами #agile #scrum #бэклог #выгорание #метрики #уточнение_задач #планирование_итерации #требования #команда

Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%

Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.

https://habr.com/ru/articles/1032000/

#управление_проектами #agile #scrum #бэклог #выгорание #метрики #уточнение_задач #планирование_итерации #требования #команда

User Story: полный гайд по написанию без ошибок

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

https://habr.com/ru/companies/otus/articles/1022178/

#User_Story #пользовательские_истории #системный_аналитик #требования #критерии_приёмки #Acceptance_Criteria #INVEST #бэклог #декомпозиция

User Story: полный гайд по написанию без ошибок

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

https://habr.com/ru/companies/otus/articles/1022178/

#User_Story #пользовательские_истории #системный_аналитик #требования #критерии_приёмки #Acceptance_Criteria #INVEST #бэклог #декомпозиция

User Story: полный гайд по написанию без ошибок

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

https://habr.com/ru/companies/otus/articles/1022178/

#User_Story #пользовательские_истории #системный_аналитик #требования #критерии_приёмки #Acceptance_Criteria #INVEST #бэклог #декомпозиция

User Story: полный гайд по написанию без ошибок

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

https://habr.com/ru/companies/otus/articles/1022178/

#User_Story #пользовательские_истории #системный_аналитик #требования #критерии_приёмки #Acceptance_Criteria #INVEST #бэклог #декомпозиция

От хаоса к системе: как мы выстроили процесс Discovery (часть 1)

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

https://habr.com/ru/articles/1028176/

#discovery #процессы_разработки #системный_анализ #бизнесанализ #требования #kanban #backlog #user_story_mapping #upstream #аналитика

Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось

AIналитик (AInalyst) — это AI-ассистент, который работает рядом с вами как опытный коллега бизнес-аналитик. Он прекрасно знает методологию BABOK v3 , умеет строить карты стейкхолдеров, планировать интервью и обрабатывать его результаты: собирать требования, трассировать и приоритизировать их, оформлять артефакты. Вы описываете задачу своими словами — AIналитик предлагает следующий шаг, задаёт уточняющие вопросы и делает работу. BABOK guide , которое является руководством, регламентирующим работу бизнес аналитиков — это более 500 страниц структурированной экспертизы. AIналитик встроил её в свой процесс: он не даст вам пропустить важный шаг, предупредит о рисках и подскажет следующее действие. BA, который плохо ориентируется в методологии, с платформой начинает работать по методологии BABOK так же уверенно, как опытный специалист.

https://habr.com/ru/articles/1024844/

#Babok #требования #Claude #Вигерс #change_request #стейкхолдеры #бизнес_анализ #системный_анализ #управление_требованиями #AIналитик

Требования в Agile: полный гайд с работающими практиками

Почему «собрать требования» невозможно, а итеративный подход — единственный рабочий вариант и чем Agile-требования на самом деле отличаются от классических. А также: ▫️ Почему фраза «создайте мне систему» — это красный флаг. ▫️ Как постепенное уточнение спасает от «аналитического паралича» и переписывания кода. ▫️ User Story vs Use Case: в чём настоящая разница и что выбрать. ▫️ Схемы итеративного процесса и ролей в Agile-проекте.

https://habr.com/ru/companies/otus/articles/1022184/

#аналитика #требования #agile #системный_аналитик #бизнесанализ #разработка_по #user_stories #управление_требованиями

Разработка программного обеспечения для систем, критичных к безопасности, на основе требований

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

https://habr.com/ru/companies/atom/articles/1017048/

#системы #безопасность #трассируемость #требования

Мифы о тестировании, в которые я верила в начале карьеры

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

https://habr.com/ru/companies/naumen/articles/1016700/

#тестирование #QA #ручное_тестирование #автотесты #баги #требования #начинающий_тестировщик #качество_по

Дело о ненужной рекомендательной системе, сделанной с помощью AI

О проблемах найма я узнал не из аналитических отчётов — а потому что сам оказался внутри рынка труда. С одной стороны — как кандидат, с другой — как человек, работавший с HR и процессами найма. Так же читая новости и статьи, в том числе на Хабре, как стремительно развивается AI в разработке, решил реализовать инженерный эксперимент и создать MVP рекомендательной системы для HR. В этой статье делаю разбор того что получилось в итоге: • как архитектура и BDD стали “ограничителями” для агента • как я формировал и тестировал требования с помощью AI • как сформировал RAG/контекст для AI агента • с какими проблемами столкнулся и что сработало • где мое место в процессе разработки • какие skills потребовались мне и какие в итоге сформировал для AI агента

https://habr.com/ru/articles/993568/

#rag_ai #aiагенты #требования #тестирование_требований #vibe_coding #skills

Требования к программному обеспечению

Первое упоминание компьютерной программе было сделано практически век назад и датировано еще далеким 1833 годом. С тем пор были изобретены множество языков программирования, начиная от машинных и до современных C++, Java, Python. Постепенно понимание и сложность компьютерных программ менялось: если ранее максимальное внимание уделялось алгоритму, то сейчас в комплексных программных приложениях, акцент смещается в сторону данных. Изобретены множество прикладных методов внедрения информационных систем, которые по существу являются производными от трех классических моделей имплементации. Однако, неоспоримым является тот факт, что любая программа в первую очередь должна покрывать исходные потребности пользователей. Данная истина зачастую теряется рутинных активностях разработки приложений и их внедрения. Множество литературных источников описывают подходы и методы анализа бизнес-требований [1-3], забывая то, что они не могут «жить» независимо. Требования являются важным элементом жизненного цикла программного обеспечения, именно с их формулирования начинается проработка концепции будущего программного продукта. Механизмы теории дизайн-мышления помогают сформулировать требования, если изначально пользователи не могут их озвучить. Получается, что требования – отправная точка разработки любого софтверного продукта, чем качественнее ведется их обработка, тем более управляемым становится проект реализации приложения. Цель данной работы состоит в анализе жизненного цикла требований к программным продуктам для обеспечения эффективного внедрения коробочных ERP-решений в приемлемые сроки, с заданным уровнем качества и фиксированными затратами. Достижение указанной цели потребует реализации следующих задач:

https://habr.com/ru/articles/992602/

#требования #требования_к_системе #требования_к_по #требования_заказчика #требования_к_разработке #требования_законодательства #erp_система #erp_системы #внедрение_erp #разработка_требований

[Перевод] Внедрение гибких методологий в сложные системы. Фреймворк пользовательских историй, дополненный принципом JTBD

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

https://habr.com/ru/companies/otus/articles/988408/

#пользовательские_истории #jtbd #требования #инженерия_требований #управление_требованиями #бэклог_продукта #декомпозиция_требований #нефункциональные_требования

Округление как зеркало корпоративной культуры в IT-продуктах

Представление чисел в IT сфере - одна из самых простых вещей, которую интуитивно знает каждый разработчик, аналитик, тестировщик, админ (нужное подчеркнуть). Еще из школы мы помним: Округление — замена числа на его приближённое значение (с определённой точностью), записанное с меньшим количеством значащих цифр. Точные определения и механизмы легко гуглятся. Элементарные математические операции производятся в уме, мы даже не замечаем, как в разговорной речи мы округляем любые числа.

https://habr.com/ru/articles/981444/

#округление #требования #требования_к_разработке #менеджмент

[Перевод] Немного про управление объемом проекта

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

https://habr.com/ru/companies/otus/articles/978792/

#границы_проекта #объем_проекта #управление_проектами #требования #управление_изменениями

Автоматизация лабораторных процессов: почему внедрение ЛИМС превращается в проблему еще на старте

В эпоху цифровой трансформации лаборатории сталкиваются с парадоксальной ситуацией: несмотря на обилие готовых решений для автоматизации, внедрение ЛИМС остается недосягаемой мечтой. Причина кроется не в технологических ограничениях, а в уникальной специфике лабораторной деятельности, регламентированной стандартом ГОСТ ISO/IEC 17025-2019. Этот документ, насчитывающий 216 прямых требований вида «лаборатория должна», требует систему взаимосвязанных процессов, каждое изменение в которой влияет на десятки других компонентов системы. Необходимость следования всем требованиям стандарта заложена в критериях аккредитации, игнорировать эти требования нельзя. Ожидаемый результат внедрения ЛИМС - автоматизация через цифровизацию, которая должна быть не просто инструментом, а живым отражением всей системы менеджмента качества.

https://habr.com/ru/articles/974696/

#гост #требования #процессы

От 4/10 до 8.5/10: как я за 5 итераций научил GigaChat извлекать требования из интервью

В прошлой статье я запустил GigaChat под Roo Code и погонял на задачах аналитика. Результаты в сравнении с Qwen оказались так себе. Улучшим их! Показываю пошаговый процесс улучшения промта для извлечения требований из интервью с заказчиком. Каждая итерация — конкретная проблема и её решение. В конце — готовый промт, который можно использовать.

https://habr.com/ru/articles/973464/

#gigachat #roocode #analytics #аналитика #промтинг #требования

Матрица трассировки: от хаоса к системности, или как мы искали универсальную модель

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

https://habr.com/ru/companies/rgs_it/articles/964794/

#матрица_трассировки #тестирование #qa_testing #требования

Подход к анализу требований в проектах внедрения ERP-систем

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

https://habr.com/ru/articles/954836/

#требования #анализ_требований #требования_к_по #требования_по #требования_по_иб #функциональные_требования #нефункциональные_требования #категории_требований

3 ключевые проблемы из-за которых управляемость проектов идет под откос

Всем привет! Я уже больше 15 лет в IT, в роли РП 7 лет, до этого долго был в смежных ролях релиз-менеджера и сервисного-менеджера. Долго мне не давали переходить в РП, но я формировал теоретическую базу и ворвался потом сразу в большие проекты. Сейчас являюсь играющим тренером, люблю сложные проекты/фичи большого масштаба. По запросу занимаюсь менторством, радуюсь когда вижу развитие и рост коллег. Хочу поделиться на мой взгляд ключевыми проблемам которым мало уделяется внимание. Надеюсь кому-то будет полезно. Cразу расскажу предложения по решению

https://habr.com/ru/articles/949052/

#управление_проектами #сроки_реализации #риски_проектов #стейкхолдеры #требования

ГОСТ 57580 без головной боли: инструкция по автоматической оценке и отчетности

ГОСТ Р 57580.1-2017, как и любой другой стандарт на территории Российской Федерации, не является обязательным для применения. Однако Банком России выпущены нормативные акты, устанавливающие необходимость применения ГОСТ Р 57580.1-2017. В статье мы расскажем, как можно автоматизировать и упросить процесс проведения оценки соответствия требованиям ГОСТ Р 57580, используя SECURITM. Под ГОСТом 57580 подразумевается набор критериев, благодаря которым определяется уровень защиты информации в соответствии с требованиями. Проверка на соответствие требованиям ГОСТ 57580 в финансовых организациях основывается на том, насколько организация придерживается мер для защиты данных. Из значимых особенностей ГОСТ 57580, следует отметить выделение стандартом трех направлений оценки:

https://habr.com/ru/companies/securitm/articles/941124/

#гост_57580 #требования #банк #требования_регуляторов #security

System design — проектируем брокер сообщений

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

https://habr.com/ru/articles/927982/

#system_design #интервью #собеседование #архитектура #проектирование #highload #подготовка_к_собеседованию #разработка #требования #расчет

Дизайним сокращатель ссылок

В этой статье я хочу показать, что из себя представляет System Design. На примере простого и очень популярного на собеседованиях сервиса "Сокращатель ссылок", мы рассмотрим стадии System Design и в конце у нас будет готова схема системы со всеми расчетами. Вперед!

https://habr.com/ru/articles/927056/

#проектрирование #api #system_design #система #сокращатель_ссылок #собеседование #требования #Разбор_системы #проектирование_систем #нагрузка

Как провалить собеседование по System Design: ошибки, которые допускают даже опытные разработчики

Собеседование по System Design — это не просто проверка технических знаний, а настоящее испытание вашего инженерного мышления. В отличие от алгоритмических задач, где есть чёткие правильные и неправильные ответы, здесь всё строится на умении анализировать, взвешивать компромиссы и предвидеть проблемы до их появления. Ирония в том, что даже опытные разработчики часто проваливают эти собеседования, потому что сосредотачиваются не на том. Они могут идеально знать, как работает Kafka или Cassandra, но если не умеют структурировать свои мысли и задавать правильные вопросы, их шансы резко падают.

https://habr.com/ru/articles/925106/

#system_design #собеседование #ошибки #подготовка_к_собеседованию #требования #система #проектирование #работа_в_it #собеседование_в_it #архитектура

System Design: Как бизнес влияет на финальный вид ИТ-Системы и выбор технологий

В System Design нет «правильных» решений — только компромиссы. Бюджет, сроки, команда и законы диктуют, какие технологии выбрать, как масштабироваться и когда идти на жертвы. Разберём, почему определение бизнес-ограничений это важный этап System Design и почему они диктуют Айтишникам как и с чем работать.

https://habr.com/ru/articles/924830/

#Бизнесограничения #system_design #Компромиссы #проектирование #требования #бюджет #сроки #собеседование #защита_персональных_данных #функциональные_требования

System Design: Чек-лист по сбору и фиксации требований все случае жизни

Если на собеседовании по System Design не уделить внимание требованиям, это почти гарантированно приведёт к провалу — даже если ваше техническое решение идеально. Игнорирование требований — главная причина провала на собеседовании. Уделите этому 5-10 минут, и ваше решение сразу станет в разы сильнее. Расскажем, как собрать и зафиксировать требования чтобы повысить свои шансы при прохождении собеседования в IT-компанию.

https://habr.com/ru/articles/924570/

#system_design #проектирование #требования #собеседование #система #архитектура #успешная_карьера #повышение #приложение #разработка

Как выстроить работу с фичами в мобильной разработке — и не плакать

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

https://habr.com/ru/articles/917614/

#Фичи #аналитика #мобильное_приложение #процессы_в_it #Требования #продуктовый_подход #разработка_приложений

Диаграмма последовательности на практике в реальном кейсе

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

https://habr.com/ru/articles/916730/

#системный_анализ #системный_аналитик #моделирование #uml #umlпроектирование #plantuml #sequence_diagram #требования #требования_к_системе #требования_к_по

Компрессия требований, распад бизнес-логики. Разбираемся, почему архитектура не спасает от эрозии смыслов

А вы никогда не задумывались, почему, с одной стороны, у нас появляются всё более крутые и мощные инструменты для разработки? На бэкенде мы можем делать микросервисы, писать офигительные SPA-приложения — но при этом будто бы сама программа становится всё хуже и хуже. Каждый раз происходит одна и та же история: мы хотим сделать как лучше, но код в итоге всё равно превращается во что-то странное и не поддерживаемое. Откуда берётся эта эрозия программного обеспечения? Почему так выходит, что новые технологии не только не помогают, но иногда даже мешают нам писать качественные программы? Почему, когда мы стараемся делать хорошо — получается плохо? И главное — что с этим делать?

https://habr.com/ru/articles/914780/

#требования #ddd #архитектура_приложений #монолитное_приложение #бизнеслогика #модель_предметной_области #spa #микросервисная_архитектура

Use Case: как описывать эффективные сценарии использования. Part 1

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

https://habr.com/ru/articles/902884/

#use_case #uml #диаграмма_прецедентов #диаграмма_вариантов_использования #требования #сценарии_использования #документирование_требований #пользовательские_сценарии #бизнес_аналитик #системный_анализ

Гайд для системного аналитика: как управлять требованиями на разных этапах проекта. Часть 4: Завершение

Этот материал — заключительная часть гайда для

https://habr.com/ru/companies/yandex_praktikum/articles/894132/

#бизнесцели #scrum #mvp #итерация #epic #user_story #api #требования #аналитик

Как использовать интеллектуальные карты в тестировании ПО

В современном мире разработки программного обеспечения эффективность команды зависит от ее способности четко понимать требования и тщательно документировать тестовые случаи. Одним из полезных инструментов для упрощения этих процессов является интеллектуальная карта (интеллект-, маинд карты, ментальные карты, mind map). Интеллект-карты применимы для любых команд. Они помогают проанализировать документацию, дать по ней оценку, расписать все возможные сценарии пользователя, учесть все функциональные и нефункциональные требования. Составляя тест-кейсы для определенной фичи, вы точно ничего не забудете. Однако такой подход требует дополнительного времени, а иногда и подключения к проекту отдельного специалиста — тест-дизайнера. Интеллектуальная карта выполняет те же функции, что и матрица трассировки, только в ней все расписано более подробно, а главное — наглядно, поэтому любой специалист из команды поймет о чем речь. Там же можно указать, какие проверки учли при написании тест кейсов, чек-листов, а какие оказались низкоприоритетными. Привет, Хабр, я Дарья, QA-специалист в IT-компании SimbirSoft. В этой статье расскажу, как использование интеллектуальных карт может существенно повысить качество анализа требований и тестовой документации.

https://habr.com/ru/companies/simbirsoft/articles/884230/

#тестирование #тестирование_по #тестирование_мобильных_приложений #тестирование_вебприложений #mind_map #интеллекткарты #требования #qa

Reverse Engineering бизнес требований советы для Senior Business Analyst

Итак, что же такое Reverse Engineering ? RE – это процесс, в ходе которого мы извлекаем информацию из уже имеющегося решения и представляем ее в нужном формате. В данном контексте бизнес-аналитику необходима информация, которая станет основой для формулировки требований. Эта методика не представлена в своде знаний IIBA – BABOK, она находится в технике Document Analysis. Задача Reverse Engineering возникает всегда в контексте какой-то другой задачи. Бизнес не заинтересован в самом процессе RE, так как это может быть дорогостоящей операцией, требующей участия различных заинтересованных сторон и высокой квалификации самого бизнес-аналитика. При этом часто акцент делается именно на его hard skills. Поэтому прежде чем приступать к выполнению RE, важно четко определить границы этой задачи и ее цель.

https://habr.com/ru/articles/878648/

#reverseengineering #reverse_engineering #reverse #бизнестребования #бизнесанализ #требования #сбор_требований #реверсинжиниринг #реверсинжиниринг_оборудования #обратный_инжиниринг

Исполнение требований Центробанка с помощью ПК Efros Defence Operations

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

https://habr.com/ru/companies/gaz-is/articles/865464/

#информационная_безопасность #требования #защита_итинфраструктуры #гост #законодательство_и_ит

«Хотели как лучше, а получилось как обычно»: почему заказчик получает не то, что хотел?

Почему ожидания заказчика от продукта не оправдываются в 99% процентах случаев? Как понять, чего же хочет заказчик на самом деле? Рассказываю о рабочих методиках выявления и управления требованиями. Далее читать

https://habr.com/ru/articles/866632/

#требования #требования_к_системе #управление_ожиданиями #бизнесанализ #системный_анализ #техническое_задание #аналитика

Гайд для системного аналитика: как управлять требованиями на разных этапах проекта. Часть 3: Контроль

Этот материал — третья часть гайда для

https://habr.com/ru/companies/yandex_praktikum/articles/858670/

#классы_эквивалентности #граничные_значение #прототип #api #контроль #требования #вариант_использования #план_тестирования

ИТ-шники: разновидности, отличительные черты

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

https://habr.com/ru/articles/860386/

#должностные_инструкции #профессии #навыки #требования

Транзакции PostgreSQL, Требования ACID, примеры. Подготовка к собеседованию, изучение

Приветствую тебя читатель, я решил написать про ACID и Транзакции PostgreSQL своим языком, с понятными примерами, эта статья ориентирована на людей готовящихся к собеседованию, кто захотел узнать нюансы транзакций в PostgreSQL или про ACID, а также для людей которые знают теорию, но сами ещё ни разу не писали транзакции. Я не ставил перед собой цели рассмотреть и объяснить работу транзакций на очень глубоком уровне. Была цель привести понятные примеры, дать макет работы с транзакциями, а также пощупать основные возможные проблемы при работе с транзакциями в PostgreSQL.

https://habr.com/ru/articles/843794/

#транзакции #транзакция #требования #Что_такое_транзакции #что_такое_ACID #ACID #базы_данных #postgresql #Принципы_ACID

Критерии качества требований с примерами (Часть 2)

Продолжение первой части статьи ( ссылка ) про критерии качества требований. Будут разобраны: - Атомарность - Необходимость - Прослеживаемость (трассируемость) - Модифицируемость - Понятность

https://habr.com/ru/articles/843220/

#требования_к_по #критерии_качества #требования_к_системе #требования_к_разработке #качество_по #требования

Почему котику лучше в коробке, или Как мы сокращаем этап ревью и согласования документации

Привет! Меня зовут Елена Павлова, и более 10 лет я работаю в сфере IT. В этой статье расскажу, что помогает мне и моей команде создавать документацию, которую легко читать и понимать. Многим аналитикам знакома ситуация: пишешь требования, отдаешь коллегам на ревью и согласование, а дальше отвечаешь на вопросы, что-то уточняешь, добавляешь то, что упустил и не предусмотрел. И в оценке трудоемкости задач вынужден закладывать еще и время для ответов на вопросы. Можно ли написать такую спецификацию, по которой вопросов не будет вообще? Снизить их число уж точно можно, тем самым сэкономив свое время и время команды. Составляем требования грамотно →

https://habr.com/ru/companies/pt/articles/841072/

#процесс_разработки #цикл_разработки #документация #написание_документации #требования #лайфхак #разработка_продукта

Требования безопасности: пособие для аналитика

Привет, Хабр! Меня зовут Александра, я ведущий системный аналитик отдела криптографии ИнфоТеКС. При разработке системы, важной с точки зрения безопасности, сталкиваешься с тем, как много усилий нужно потратить на учет всех требований безопасности, которые должны в ней быть. Соблазн бросить эту задачу и переключиться на более приятные пользовательские фичи очень высок :) Требования безопасности – не самая интуитивно понятная вещь, работать с ними первое время может быть непривычно и сложно. Моя статья будет полезна аналитикам и другим специалистам, разрабатывающим систему, для которой важна безопасность. Я поделюсь рабочими подходами из общепринятой в нашей компании практики, которые помогут справиться с требованиями безопасности и ускорить освоение этой непростой темы.

https://habr.com/ru/articles/836656/

#требования #информационная_безопасность #системный_анализ #нефункциональные_требования #стандарты #модель_угроз

Гайд для системного аналитика: как управлять требованиями на разных этапах проекта. Часть 2: планирование и исполнение

Этот материал — вторая часть гайда для

https://habr.com/ru/companies/yandex_praktikum/articles/830044/

#требования #user_story #epic #gantt_chart #проект #use_case #uml #задачи #системный_анализ #системный_аналитик

Оно вам надо: про цели и ценность задач по разработке

Вы когда-нибудь задумывались — как член команды разработки — почему некоторые функции в приложениях не используются? Возможно, вам доводилось испытывать ощущение бессилия или бессмысленности своей работы? Либо, напротив — у вас возникало желание сделать лучше? Или, может быть, вам приходилось выполнять задачи, в которых вы сами не видели ценности для пользователя? Возможно ли в принципе избежать подобных ситуаций? Непонимание ценности выполняемых задач — одна из частых проблем, которые встречаются при разработке ПО. Как следствие, команда начинает бездумно внедрять новые процессы, не понимая, как они связаны с уже существующими. Все это может закончиться тем, что будет создана функциональность, которая не принесет выгоды пользователям и не будет соответствовать ожиданиям заказчика. Всем привет! Я Гузель Хамидуллина, системный аналитик в Positive Technologies. Хочу поделиться с вами мыслями о том, насколько важно для команды разработки понимать ценность входящих задач. Заценить

https://habr.com/ru/companies/pt/articles/829052/

#разработка_продукта #требования #постановка_задач #постановка_целей #функциональность #системный_анализ #пользователь #критическое_мышление

Как в IT-проектах работать с возражением Заказчика «Почему так дорого?»

В предыдущих постах я писал о том, что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта ( клац ), и что делать, если он просит эти работы сделать бесплатно ( клац ). В этом посте поговорим о том, что делать в ситуации, когда вы убедили Заказчика, что его новая хотелка стоит денег, но он не согласен со стоимостью. Вводные: Вы находитесь в проекте, у вас есть ограниченный объем работ, бюджет и срок. Заказчик приходит и озвучивает какую-то хотелку. Вы собираете требования, описываете их (ТЗ, ФТ, ТР, что угодно), согласовываете их с Заказчкиом и считаете стоимость этих работ. Но в ответ получаете возражение «а чего так дорого, там же программист за день сделает». Ещё в конце может добавить любимое: «Вы же эксперты». То есть в этом посте речь пойдет не про техники продаж. Мы не рассматриваем вариант, когда нужно именно что-то с нуля продать Заказчику. Там работают совсем другие инструменты, о них рассказывают совсем другие люди, да и надо это не проектной команде, а сейлам. Поэтому этот пост будет полезен тем, кто может столкнуться с такой ситуацией в проекте. А это любой сотрудник, взаимодействующих с Заказчиком. Обычно это менеджер проекта, реже архитектор, еще реже бизнес-аналитик. Мои рекомендации основываются на собственном опыте в больших и сложных IT-проектах с внешними корпоративными Заказчиками. На фрилансе, в госах, на небольших проектах и в другой сфере могут быть свои нюансы, тут у меня опыта немного. И последнее: речь идёт о том, что вы для Заказчика – безальтернативный Исполнитель. Если новые работы будут вынесены на ЧЕСТНЫЙ открытый конкурс, где выбирать будут ТОЛЬКО по цене, то абсолютное большинство пунктов ниже будет неприменимо.

https://habr.com/ru/articles/824898/

#проект #требования #скидка #бесплатно #работы #change_request #заказчик #совет #рекомендации

Что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта

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

https://habr.com/ru/articles/821035/

#требования #проектное_управление #заказчики #совет #рекомендации