Разработка требований к программному обеспечению вигерс кратко
Обновлено: 04.07.2024
За пять лет своего бытия аналитиком и руководителем направления я сформировала определенный список литературы, который может помочь новичку постичь азы профессии.
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности.
Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
Автор рассказывает, как писать просто, понятно, чисто и интересно. Автор объясняет, как обращаться к читателю, как выбирать тему, как сформировать канву повествования. В книге даются плохие и хорошие примеры, как избавляться от словесного мусора. Автор объясняет, почему простота текста важна.
В оригинале название книги звучит как "User Story Mapping". Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
Спасибо, подборка очень заинтересовала, начну со 2 пункта. Может быть вы со своим опытом сможете посоветовать хорошие курсы по аналитике, data science? //бесплатные, платные, но стоящие запрашиваемых денег
Юлия, ваш вопрос поставил меня в тупик немного. Полагаю, вначале следует определиться с направление — бизнес-аналитика, системный анализ и так далее.
Если вопрос о курсах интересен, то попробую провести такое исследование, потом опубликую результаты))
Конечно, помимо курсов и материалов непосредственно об аналитике, анализе данных, анализе требований необходимо прокачивать скиллы и знания в целом о разработке ПО, UX-проектировании, проектном управлении.
И не давать советов/рекоммендаций по доменной области (DS), которой не понимаете, а то нагуглили и выдали список знакомых названий из выдачи.
Верно, это были ссылки навскидку. Вопрос требует более серьезного подхода и подготовки. Возможно, вы сможете дать более корректный список по курсам в указанной доменной области?
С самого начала книги автор доносит мысль о том, что переделки в проекте — это вещь неизбежная. Невозможно, чтобы заказчик и компания-разработчик сразу поняли друг друга в полной мере. Однако выявление необходимости переделок на разных этапах будет стоить совершенно по-разному. Наиболее безболезненно и наименее затратно исправлять ошибки, которые появились в ходе качественной работы квалифицированного аналитика с требованиями. В случае, если ошибка была обнаружена в ходе разработки, то помимо проекта придётся переделывать также и часть уже написанного кода. Если в ходе тестирования, то часть кода, которую потребуется скорректировать, будет еще больше. Теперь представьте, какие затраты будут, если ошибку обнаружит уже после завершения разработки и тестирования сам конечный пользователь и позвонит с жалобой? В книге автор приводит пример из собственного опыта, который был переведен в цифры одним из его клиентов. Трудозатраты на исправление дефекта внутри компании составляли 200 долларов. При этом исправление ошибки, когда она была обнаружена пользователем, уже составляла 4200 долларов, т.е. больше чем в 20 раз дороже. Книга доказывает, что качественная работа с требованиями — это не пустая трата ресурсов, а инвестиция в успех проекта.
И здесь автор прав. После того как получен запрос или бизнес-задача от заказчика и до того момента, как стартовала разработка, то есть непосредственно написание кода, наступает то самое время, когда можно максимально приблизить проект к успеху. В этот момент начинается работа по выявлению, сбору, анализу, классификации, спецификации, документированию и управлению требованиями. Автор подробно описывает каждый из этих этапов, приводит живые (что самое интересное) кейсы, примеры ошибок и варианты исправления. Главное, чему учит книга — это как избежать тех самых ошибок при разработке требований к ПО. Требования представляют собой фундамент проекта, они являются основой для действий команд разработки и тестирования, для инженеров внедрения и для руководителей проектов. Поэтому от их проработки зависит успех всего проекта.
Это одна из ключевых мыслей книги. Хорошие требования не появляются в процессе работы с документами на компьютере или в процессе самостоятельного моделирования прототипов и проектирования систем. Хорошие требования появляются в результате кропотливой и вдумчивой работы с людьми: со стейкхолдерами, пользователями системы, с разработчиками, тестировщиками и менеджерами проектов. Только в ходе общения с заинтересованными сторонами появляется возможность выявить их потребности и сформулировать требования к системе, по-настоящему удовлетворяющей их. В противном случае, есть риск получить понятный, красивый с яркими картинками документ для разработки системы, которая, в конечном счете не отвечает ничьим ожиданиям.
Такие ситуации иногда возникают у аналитиков в процессе работы над проектами, когда слишком много времени уделяется проектированию и документированию, и слишком мало – общению, сбору информации и получению обратной связи.
У меня был такой опыт. Я подготовил проект, отвечающий требованиям, обозначенным заказчиком в запросе. По моему проекту была выполнена разработка и произведено тестирование внутри проектной команды. Однако после отгрузки доработки системы и приёмки заказчиком выяснилось, что бизнес-цель, которая ставилась при создании запроса, не была достигнута. Разобравшись, я понял, что совершил классическую ошибку, о которой пишет Вигерс: увлекся процессами проектирования, уделив основное внимание решению технической задачи, обозначенной заказчиком в блоке требований. При этом я не учел требования бизнеса. Как выяснилось позже, в запросе присутствовали противоречивые требования. Их можно было бы устранить только в ходе общения с представителями бизнес-подразделений заказчика.
Детально расписаны роли участников проектов и их задачи, обоснована необходимость постоянного контроля обратной связи. Представлены методы управления требованиями, контроля внесения изменений, приемы моделирования и подходы к дизайну, а также рекомендации, как правильно фазировать процессы в жизненном цикле ИТ проекта.
В книге даже приведены шаблоны документов, которые, признаться, я по сей день частично использую в проектах. Подробно останавливаться на каждом описанном процессе не буду, их очень много. Понять, что можно узнать из книги легко – достаточно прочитать оглавление, оно очень подробное =).
По содержанию. Очень много воды. Прочитаешь полстраницы, пытаешься осмыслить, что написано, и понимаешь, что смысла на одно предложение. Структура повествования при таком чтении теряется, в голове остается ощущение каши из теории и никаких практических примеров. Иногда возникало ощущение - зачем этот пример здесь. По. Читать полностью
Самое полное описание разработки требований из тех, что доступны в русском переводе. Моя работа связана с разработкой требований и документации косвенно, но книга заставляет анализировать и перекладывать чужой опыт на свои условия.
Соглашусь с предыдущими авторами отзывов - русский перевод ужасен, хотя, мне лично воспринимать информацию ошибки не мешали. Главное ведь - содержание.
Книга подходит только для тех, кому НЕ ЛЕНЬ ДУМАТЬ. Если вы ищете лёгкое универсальное решение для всех своих проектных проблем и чудесную инструкцию для их решения - лучше не тратьте деньги.
Поддерживаю предыдущие комментарии - орфографических ошибок много. Сама книга безусловно важная для начинающего специалиста.
Хотелось бы, чтобы чуть чаще переведенная на русский язык терминология сопровождалась в скобках оригинальным англоязычным вариантом
К сожалению, книгу пока еще не читала, но по отзывам очень хорошая для профессионалов. Сама книга очень качественная.
Помог пройти собеседование при трудоустройстве, рекомендую, как настольную книгу для любого аналитика)))
на фото. для ценника 1000-1500, конечно неприятно получать старый замызганный, порванный журнал. грамматические ошибки, толстовскИе абзацы (когда дочитал до конца мысль, потерял ее начало).
Книга пришла немного порванная снизу. Хотя упакована была плотно и хорошо. Не знаю в чем дело, но жалко, так как книга совсем недешевая.
хорошая классическая базовая книга по теме. систематизировано, всё объясняется на примере разработки конкретной системы
хорошая книга, чтобы разобраться в вопросе, если только начинаешья свой профессиональный путь в ИТ (в качестве аналитика, проджекта, продакта, а то и заказчика), есть хорошие, правильные и полезные. Читать полностью
Ставлю русскому изданию одну звезду за ужасный перевод. Абсолютно уверена, что вся книга переведена через программу "Переводчик". Читаешь текст и деградируешь от несвязных предложений и неправильного написания падежей. Стыд и позор издательству, которое так халатно отнеслось к переводу.
Мягкая обложка. За тысячу рублей бумага в книге настолько тонюсенькая, что можно читать обратную сторону листа. Знал бы, что такая стрёмная бумага лучше бы сам распечатал эту книгу.
1. Для книги такой толщины (718 страниц) мягкий переплет - это верная смерть со временем при более-менее активном чтении. Переплет уже сейчас, после всего нескольких открываний, начал отрываться (видно на фото). Пока дочитаю до конца, книга развалится. 2. Есть опечатки по тексту, немало. Бросается в глаза, отвлекает.
Сама по себе книга - must have для бизнес/системного аналитика, тестировщика, владельца продукта, да и вообще для каждого, кто так или иначе связан с разработкой требований к программному обеспечению. Однако не могу посоветовать именно это издание в качестве настольной книги (хотя у меня именно так, держу под рукой), в первую очередь из-за мягкого. Читать полностью
Разработка требований к программному обеспечению
Разработка и контроль над требованиями
Выявление требований к программному продукту. На этом этапе выполняются различные действия, связанные с выяснением потребностей. Суть в том, чтобы выяснить основные задачи, которые дол жен выполнять будущий продукт.
Анализ требований. На этом этапе анализируются все требования, полученные на первом этапе. Анализ предполагает усовершенствование нужных требований и отсеивание ненужных. Та кж е на этом этапе все требования распределяются по отдельным компонентам и функциям будущей программы. И обязательно расставляются приоритеты их реализации.
Документирование требований. На этом этапе формируется необходимый пакет документов с требованиями, прописанными в письменном виде , и всяческие диаграммы, пригодные для дальнейшей работы.
Утверждение требований. На этой фазе еще раз перепроверяются все требования и подписываются все документы, связанные с требованиями к ПО.
Управление требованиями. Это непрерывный процесс, который начинается с самого старта работы над продуктом и оканчивается, когда ПО будет сдано заказчику. Цель управления требованиями простая — гарантироват ь, что продукт будет выполнен согласно всем подписанным документам.
А нужн а ли разработка требований к программному продукту
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Читайте также: