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

Тест-кейсы из функциональных требований

Пользовательское требование описывает, что нужно пользователю. Критерии приёмки — фиксируют, как это проверить. Но между «что нужно» и задачей в Jira — пропасть. Чтобы её закрыть, я пишу функциональные требования — с use case'ами, из которых тестировщик может собрать тест-кейсы, а разработчик — понять ожидаемое поведение системы.

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

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

Тест-кейсы из функциональных требований

Пользовательское требование описывает, что нужно пользователю. Критерии приёмки — фиксируют, как это проверить. Но между «что нужно» и задачей в Jira — пропасть. Чтобы её закрыть, я пишу функциональные требования — с use case'ами, из которых тестировщик может собрать тест-кейсы, а разработчик — понять ожидаемое поведение системы.

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

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

Тест-кейсы из функциональных требований

Пользовательское требование описывает, что нужно пользователю. Критерии приёмки — фиксируют, как это проверить. Но между «что нужно» и задачей в Jira — пропасть. Чтобы её закрыть, я пишу функциональные требования — с use case'ами, из которых тестировщик может собрать тест-кейсы, а разработчик — понять ожидаемое поведение системы.

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

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

Тест-кейсы из функциональных требований

Пользовательское требование описывает, что нужно пользователю. Критерии приёмки — фиксируют, как это проверить. Но между «что нужно» и задачей в Jira — пропасть. Чтобы её закрыть, я пишу функциональные требования — с use case'ами, из которых тестировщик может собрать тест-кейсы, а разработчик — понять ожидаемое поведение системы.

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

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

Пользовательское требование — точка входа в документацию

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

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

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

Пользовательское требование — точка входа в документацию

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

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

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

Пользовательское требование — точка входа в документацию

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

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

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

Пользовательское требование — точка входа в документацию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Неотправленное Тестовое, или Как я перестал бояться и полюбил системный анализ

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

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

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

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

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

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

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

Сторителлинг

Агрессивная, навязчивая реклама товаров, работ, услуг, продвижения бренда в PR-технологиях и маркетинге компаний сегодня начинает давать «обратный» эффект и со временем в таком формате уйдет в прошлое. Новой технологией подачи информации становится сторителлинг, который активно используется как коммуникационный метод продвижения бренда. Сегодня выделиться в огромном количестве информации в информационном потоке стало намного сложнее, поэтому сторителлинг – один из способов это сделать. Сторителлинг (Storytelling) – термин, употребляемый маркетологами, журналистами, психологами, преподавателями и понимаемый как коммуникативная технология, позволяющая посредством нарратива сделать информацию интересной и запоминающейся для адресата. Технология сторителлинга, или рассказывания историй, за последние несколько лет приобрела заметную популярность; она используется в различных профессиональных средах. Изначально сторителлинг был успешно внедрен и апробирован Дэвидом Армстронгом как инструмент управления персоналом. Затем этот метод начал активно использоваться в маркетинге, PR, журналистике, образовании. В маркетинге и в PR-технологиях он помогает брендам выстроить прочные взаимоотношения, как с внешней, так и с внутренней аудиторией, эффективно сочетая рациональный и эмоциональный контекст. Это такой маркетинговый приём, использующий медиа-средства с целью передачи информации и транслирование смыслов посредством рассказывание историй с целью обеспечения эффективной мотивации к требуемому от субъекта действию. Он позволяет сохранить, систематизировать и донести информацию об основных достижениях, обосновать право считаться лучшим, важным и заслуживающим доверия, мотивировать, вызвать стремление к продолжению общения и сформировать лояльность субъекта. Этот рассказ захватывает внимание с первой секунды и держит его на протяжении всей истории, вызывая у читателя или зрителя симпатию к главному герою истории и, таким образом, доносит до него основную мысль. Сторителлинг оказывает воздействие путем понятного и простого намека. Воздействует на сознание людей, внушает им требуемые мысли, формирует сопричастность, вызывает запланированную реакцию и последующее поведение. Он становится всё более популярным форматом для коммуникации брендов с потребителями благодаря большой вовлечённости аудитории и укрепления доверия к спикеру.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования проверяются на соответствие критериям качества . Часто этот процесс описывают как отдельный вид тестирования — тестирование требований. Понятие критериев качества требований скорее относится к бизнес-анализу, чем к QA. В разных источниках можно встретить разные наборы критериев. При написании этой статьи я руководствовалась своим опытом и тремя хорошими книгами. В этой статье рассказывается про 7 самых часто встречающихся критериев качества c с примерами.

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

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

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

Требования проверяются на соответствие критериям качества . Часто этот процесс описывают как отдельный вид тестирования — тестирование требований. Понятие критериев качества требований скорее относится к бизнес-анализу, чем к QA. В разных источниках можно встретить разные наборы критериев. При написании этой статьи я руководствовалась своим опытом и тремя хорошими книгами. В этой статье рассказывается про 7 самых часто встречающихся критериев качества c с примерами.

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

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

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

Требования проверяются на соответствие критериям качества . Часто этот процесс описывают как отдельный вид тестирования — тестирование требований. Понятие критериев качества требований скорее относится к бизнес-анализу, чем к QA. В разных источниках можно встретить разные наборы критериев. При написании этой статьи я руководствовалась своим опытом и тремя хорошими книгами. В этой статье рассказывается про 7 самых часто встречающихся критериев качества c с примерами.

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

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

Как тестировать без требований? Или как убедить разраба и себя, что это баг

Всем привет, это моя первая статья по тестированию. До этого я писал от лица Scrum-мастера, а теперь уже и от лица QA. В тестировании я уже более 2-х лет. Работал на двух проектах одновременно, и было супер весело менять проект на протяжении дня: утром ты тестируешь веб-сервис, а вечером со студентами делаешь тест-план по мобильному приложению. Не жизнь, а сказка! Из названия мы с вами понимаем, что тема статьи интересна и, как воздух, необходима. Для кого-то покажется тестирование без требований пустяком, и он, как вызов, примет этот поединок. Но я хочу заметить, что тестировать сервис-продукт, который ты понимаешь от того, что видел аналоги, пользовался этим сервисом с пелёнок и понимаешь его за счет косвенных требований - дело одно. Когда нет аналогов или сервис выполняет роль франкенштейна из функционала от разных продуктов - тут ситуация другая. Не будем петь серенады, как это сложно, и приступим к делу. Вас посвящают в суть проекта, и главный шаг - уточнить у аналитика или того героя, кто выполняет эту роль, "Есть какая-нить дока?" (далее - спецификация). Какая может быть спецификация на проекте? Будьте внимательны, я не использую термин документация, потому-что дока - это текстовый формат, а в виде спецификации может выступать: 1) документация; обновленная в последний раз в 90-х 2) макеты; вообще не похожи на прод 3) тикеты в Jira; обычно там один заголовок, но верим в чудо 4) user-story; 5) тест-кейсы, чек-листы; если был тестировщик до 6) звонок с владельцем продукта; Product owner

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

#тестирование_itсистем #тестирование #тестирование_без_боли #требования_к_системе #требования_к_по #ручное_тестирование #qa_testing #testing #manual