Что такое бизнес идея требования
Бизнес-требования — это спецификации, которые после предоставления обеспечивают ценность и описывают характеристики предлагаемой системы, с точки зрения конечного пользователя. И также называются перечислением заявок заинтересованных сторон. Продукты, программное обеспечение и процессы являются способами, как поставить и удовлетворить потребности предприятия. Следовательно, бизнес-требования часто обсуждаются в контексте разработки или приобретения программного обеспечения или других систем.
Определение
Путаница в терминологии возникает по трем основным причинам:
- Обычной практикой является обозначение целей или ожидаемых выгод как бизнес-требований.
- Люди, как правило, используют данный термин для обозначения характеристик продукта, системы, программного обеспечения, которые предполагается создать.
- Широко распространенная модель утверждает, что эти два типа заявок отличаются только уровнем детализации или абстракции — где бизнес-требования являются высокоуровневыми, часто расплывчатыми и разлагаются на подробные заявки к компоненту.
Такого недоразумения можно избежать, если признать, что данное понятие не является целями, а скорее отвечает им (то есть обеспечивает ценность) при их удовлетворении. Бизнес-требования не разлагаются в продукт, системы и программное обеспечение. Скорее, все происходит наоборот. Продукты и их заявки представляют собой ответ на бизнес-требования — предположительно, чтобы удовлетворить их. Данное понятие существует в производственной среде и должно быть обнаружено, тогда как спросы к продукту определены человеком. Требования к бизнес-плану не ограничиваются существованием высокого уровня, а должны быть сведены к деталям. Независимо от величины детализации, заявки всегда обеспечивают ценность, когда удовлетворены.
Обновление продукта
В проектах разработки систем или программного обеспечения для требований малого бизнеса обычно необходимы полномочия заинтересованных сторон. Именно они приводят к созданию или обновлению продукта. Бизнес-требования к системе и программному обеспечению обычно состоят из функциональных и нефункциональных заявок. Конечно же, обычно они определяются в сочетании с первым вариантом возможностей продукта. Второй часто фактически отражает оформления бизнес-требований, которые иногда рассматриваются как ограничения. Они могут включать необходимые аспекты производительности или безопасности, применимые на производственном уровне.
Акценты процесса
Заявки часто перечислены в официальных документах. Акцент в них делается на процессе или деятельности точного планирования и разработки бизнес-требований, а не на том, как этого достичь. Этот параметр обычно делегируется спецификацией или документом системных заявок или другому варианту. Может возникнуть путаница между ними, если не учитывать все различия. Следовательно, многие официальные документы фактически описывают требования к продукту, системе или программному обеспечению.
Обзор
Бизнес-требования в контексте разработки программного обеспечения или его жизненного цикла — это концепция выявления и документирования любых пользователей. Например, таких как клиенты, сотрудники и поставщики, на ранних этапах цикла создания системы для руководства проектированием будущего. Заявки часто фиксируются аналитиками. Именно они анализируют требования бизнес-процесса и часто изучают его «как есть» для определения целевого «будущего».
Состав заявок
Требования бизнес-процесса часто включают в себя:
- Контекст, область и фон, в том числе и причины изменений.
- Ключевые заинтересованные стороны, у которых есть требования.
- Факторы успеха для будущего или целевого состояния.
- Ограничения, налагаемые бизнесом или другими системами.
- Модели и анализ процессов, часто использующие блок-схемы для представления всего «как есть».
- Логическая модель данных и ссылки на словарь.
- Глоссарии деловых терминов и местный жаргон.
- Диаграммы потоков данных для иллюстрации того, как они проходят через информационные системы (в отличие от блок-схем, изображающих алгоритмический поток бизнес-операций).
Роли
Самый популярный формат для записи бизнес-требований — это документ. Цель их состоит в том, чтобы определить, какие результаты будут необходимы от системы, однако, она может быть в конечном итоге разработана без дополнительных условий. Следовательно, документы дополняются справочным материалом, который детализирует производительность технологии и ожидания инфраструктуры, включая любые профессиональные требования, относящиеся к качеству обслуживания.Это, например, производительность, ремонтопригодность, адаптивность, надежность, доступность, безопасность и масштабируемость.
Полнота
Прототипирование на ранней стадии тестирования позволяет оценить полноту и точность выявленных бизнес-требований. Заинтересованные стороны проходят процедуру первыми, чтобы помочь определить структуру. И результат направляется командам разработчиков бизнес-требований проекта, которые строят систему. Другие заинтересованные стороны тестируют и оценивают окончательно развернутую проекцию. Ясность требует отслеживания заявок и их решения с формальным процессом определения соответствующего шаблона.
Объем бизнес-требований не обязательно ограничен стадией дефиниции того, что должно быть построено как система. Это выходит за рамки того, чтобы предусмотреть, как управлять и поддерживать действующую стратегию. И обеспечивать ее постоянное соответствие бизнес-целям. Документ требований должен постоянно пересматриваться контролируемым образом. Наличие стандартизированного формата или шаблонов, разработанных для конкретных бизнес-функций и доменов, может обеспечить полноту запросов, помимо сохранения сфокусированности области.
Прообраз
Несмотря на то что обычно считается средством оценки требований, прототипирование обычно переключает внимание на создаваемый продукт или систему. Прототипы — это работающее программное обеспечение, что означает, что они состоят из трех этапов (заявки, инженерное или техническое проектирование и реализация), удаленных от бизнес-требований. И также это предварительные версии, которые разработчик намеревается внедрить.
Поскольку прототипы являются довольно конкретными, заинтересованные стороны, которые опробуют их, могут дать более значимые отзывы о некоторых аспектах того, что создает разработчик, что является интерпретацией способа удовлетворения. Более того, графический интерфейс пользователя подчеркивается, а внутренняя часть — это ярлыки. Они составляют основную часть программной логики, и именно там будут удовлетворены большинство бизнес-требований. Другими словами, проблемы, которые обнаруживают прототипы, вряд ли связаны с запросами.
Разработка
Важно распознавать изменения в заявках, документировать их и обновлять. Однако деловые запросы, как правило, меняются не так сильно, как осознание их. Бизнес-требование может присутствовать, но не быть признано или понято заинтересованными сторонами, аналитиками и командой проекта.
Изменения, как правило, отражают предполагаемые способы удовлетворения неадекватно определенных материалов. Большая часть трудностей, связанных с выполнением бизнес-требований, на самом деле отражает общую практику, направленную почти на все усилия, связанные с ними, на то, что на самом деле представляет собой высокоуровневый дизайн продукта, системы или программного обеспечения. Это связано с неспособностью сначала адекватно определить бизнес-требования, чтобы обеспечить ценность.
Практики разработки обычно продолжают пересматривать продукт до тех пор, пока они в конечном итоге не «вернутся» к решению, которое, кажется, выполняет то, что необходимо, то есть, по-видимому, отвечает запросам производства. Косвенные методы проб и ошибок для определения бизнес-требований являются основой для большей части «итеративной разработки», включая популярные методы, которые рекламируются как «лучшие практики».
Примеры оформления
Шаблоны помогают оперативно запрашивать конкретные темы, которые часто могут иметь отношение к запросам. Они могут создавать стандартизированную документацию, касающуюся требований бизнеса, что может облегчить понимание. Шаблоны не гарантируют точность или полноту запросов. Часто неправильно используемые примеры негативно влияют на исследования, поскольку они имеют тенденцию содействовать поверхностности и главным образом механическому определению без осмысленного анализа.
Трудности
Бизнес-требования часто преждевременно ужесточаются из-за большой базы заинтересованных сторон, участвующих в их определении, где существует вероятность конфликта интересов. Процесс управления и достижения консенсуса может быть деликатным и даже политическим по своей природе. Менее сложная, хотя и распространенная задача — это распределенные группы с заинтересованными сторонами в разных географических точках. Естественно, что торговый персонал ближе к своим клиентам, а производственный – к соответственным единицам. Финансы и управление сотрудниками, включая высшее руководство, ближе к зарегистрированной штаб-квартире.
Бизнес-требования, к примеру, нужны для системы, в которой участвуют пользователи, занимающиеся продажами и производством. Она может столкнуться с конфликтом целей — одна сторона заинтересована в предоставлении максимального количества функций, а другая сосредоточится на самой низкой стоимости производства. Такие ситуации часто заканчиваются консенсусом с максимальными возможностями для разумной, выгодной цены и распределения.
Чтобы решить эти проблемы, участие заинтересованных сторон на ранней стадии достигается путем демонстрации прототипов и совместной работы. Практические семинары как в виде организованных сессий, так и простых дискуссий, помогают достичь консенсуса, особенно в отношении деликатных требований бизнеса и там, где существует потенциальный конфликт интересов. Сложность процесса является важным фактором. Это может потребовать специальных знаний, необходимых для понимания правовых или нормативных требований, внутренних руководящих принципов, таких как брендинг или корпоративные обязательства в отношении социальной ответственности. Анализ заключается не только в том, чтобы уловить «что» из бизнес-процесса, но также «как» представить его контекст.
timonissimo
13 апреля 2012 в 13:05
Вступление
Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall).
Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт
.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.
Классификация требований
В нашей компании принята следующая терминология в отношении требований:
- Бизнес-требования
Требования самого высокого уровня, которые определяют цель создания сайта и задачи, которые необходимо выполнить для достижения цели. Бизнес-требования определяются следующей метафорой: «Сайт как инструмент бизнеса, как его часть. Сайт – как лицо компании, как инструмент продаж и развития бизнеса». - Требования участников проекта
Требования, которые определяют, как представители компании-заказчика будут взаимодействовать с сайтом, что им нужно от сайта. Метафора: «Сайт как неотъемлемая часть бизнес-процессов в компании. Сайт как помощник сотрудникам». - Требования внешних пользователей
Требования, которые определяют, как внешние пользователи будут взаимодействовать с сайтом, и что им может потребоваться как посетителям ресурса и потенциальным клиентам компании. Метафора: «Сайт как инструмент продаж товаров и услуг компании через Интернет».
Бизнес-процесс по созданию клиентского сайта
Базовый бизнес-процесс по созданию клиентского сайта в нашей компании выглядит следующим образом:
- После получения заявки на разработку сайта, менеджер связывается с клиентом, уточняет его ценовые ожидания и, если они соответствуют нашим, договаривается о встрече.
- Перед встречей менеджер подготавливается к сбору бизнес-требований: читает информацию о компании заказчика, анализирует действующий сайт (если он существует), анализирует сайты конкурентов; создает примерное представление о том, какой сайт можно предложить клиенту.
- Далее следует очная встреча с клиентом, на которой менеджер занимается сбором бизнес-требований и требований участников проекта. На данном этапе главная задача менеджера состоит в том, чтобы максимально подробно расспросить клиента о бизнес-процессах внутри компании, понять их суть, чтобы затем предложить такой функционал на сайте, который бы позволил увеличить эффективность работы сотрудников компании клиента.
- После очной встречи с клиентом менеджер осуществляет оценку собранных требований на полноту и непротиворечивость.
- Оценка сделана, и менеджер трансформирует требования в описание примерного функционала сайта как совокупности ряда модулей: «Каталог товаров», «Корзина», «Форум» и т. д.
- Функционал будущего сайта согласовывается с клиентом как по содержанию, так и по стоимости. Возможны варианты, когда клиент выбирает для реализации лишь часть функционала.
- Если предварительное соглашение о функционале будущего сайта достигнуто, то менеджер приступает к описанию целевых групп посетителей и описанию сценариев использования сайта посетителями. Данное описание также согласовывается с клиентом.
- На основании согласованных сценариев использования сайта и функциональных модулей менеджер формирует техническое задание, в которое разработчик добавляет техническую информацию (требования к хостингу, например).
- Техническое задание подписывается двумя сторонами, прикладывается к договору, договор оплачивается, и начинается работа.
Схематично бизнес-процесс выглядит следующим образом:
Теперь более подробно рассмотрим, как осуществляет сбор требований на всех этапах работы.
Бизнес-требования
При сборе бизнес-требований определяется окружение сайта (см. рисунок) и анализируется, как данное окружение может использовать сайт и соответственно, какой функционал и информация должны быть представлены на сайте.
Например, бизнес заказчика крупный и постоянно привлекаются инвесторы для финансирования проектов. Соответственно, должен быть раздел на сайте с информацией о проектах компании, о формате возможного участия инвесторов и т.п.
Случай из жизни. В ходе сбора бизнес-требований для сайта клиники красоты мы задумались, а что может быть нужно органам власти от сайта. Ответ не заставил себя долго ждать – необходимым оказалось размещение на сайте лицензий на оказываемые услуги.
Заметим, что требования сотрудников компании к сайту – это требования участников проекта, они будут рассмотрены в отдельной главе.
При проектировании с учетом бизнес-требований:
- Заказчик начинает фокусироваться на важных вопросах, касающихся целей и задач сайта, а не на том, «что на сайте будет в левом меню». Повышается мотивация и желание сделать хороший продукт.
- Большинство важных требований, которые не лежат на поверхности, выявляются в ходе последовательного прохода по внешнему окружению будущего сайта. Например: «…да, партнерам было бы хорошо предоставить личный кабинет…», «…далее сайт будет продвигаться и seo-специалистам необходимо следующее…», «…компания крупная и нужен хороший раздел с вакансиями…» и т.д.
Требования участников проекта
— это требования сотрудников компании к сайту.
После сбора бизнес-требований необходимо уделить время анализу требований сотрудников компании к сайту. Если клиент уже на встрече может предоставить список таких требований – это замечательно, однако не стоит останавливаться на этом. Важно продолжить диалог и попросить клиента рассказать о бизнес-процессах внутри организации, которой мы делаем сайт.
Важно на встрече не столько придумать все варианты использования сайта сотрудниками, а сколько понять и запомнить бизнес-процессы, а также функциональные обязанности работников, чтобы потом в офисе, в спокойной обстановке поразмыслить над тем, каким образом сайт может помочь сотрудникам.
Основной момент, который стоит подробнее изучить на встрече, – взаимодействие менеджера по продажам с клиентом и какую роль в этом взаимодействии должен играть сайт. Рассмотрим некоторые варианты практического применения сайта менеджером:
- Сайт может помогать менеджеру при непосредственном общении с клиентом – например, менеджер с экрана компьютера демонстрирует клиенту продукцию или услуги компании.
- Менеджер «конструирует» что-то на сайте, например, выбирает для клиента тур в Турцию или рассчитывает стоимость полиса ОСАГО. Частный пример – «конструктор кухонь» на сайте компании Ikea.
- Менеджер часто выезжает на встречу с клиентом на местах и с планшетного компьютера демонстрирует продукцию, представленную на сайте – (для себя мы сразу делаем пометку, что будет важна мобильная версия сайта и интерфейс работы с устройствами с сенсорным экраном).
- Сайт служит для сопровождения клиентов в процессе продажи товара и после. Это такие действия как: всевозможные консультации, отслеживание статуса заявки на покупку товара, обмен файлами, техническая поддержка.
- Во многих случаях менеджеру приходится давать подробные консультации клиентам, и в этом случае на помощь может прийти сайт, где в специальном разделе можно будет разместить справочную информацию. Частный случай: раздел FAQ, где можно посмотреть ответы на основные вопросы и задать свой.
В целом, вариантов использования сайта менеджером по продажам великое множество – ведь товаров и услуг, которые реализуют данные менеджеры, также очень много и в каждом случае – свои особенности процесса продажи. Поэтому, как уже было сказано выше, на встрече с клиентом очень важно получить подробную информацию о том, какие функции выполняют сотрудники, и как они взаимодействуют между собой и – что особенно важно — с клиентами компании.
Пример из жизни.
В нашу компанию обратился клиент, занимающий оптовой продажей мебельных комплектующих: гайки, стяжки, винты и т.п. Как правило, обычный человек не понимает всей специфики данного вида бизнеса. Поэтому в ходе диалога наш менеджер попросил клиента описать процесс продажи товара подробнее.
Как оказалось, этот процесс очень прост: сначала потенциальный покупатель выбирает через электронные каталоги в формате .pdf товары нужного артикула и в определенном количестве. Далее он звонит в компанию и озвучивает свой заказ менеджеру. Менеджер принимает заявку и ищет требуемый товар у поставщиков. После того, как с поставщиками достигнута договоренность, менеджер связывается с клиентом и озвучивает ему общую стоимость заказа. Как правило, далее следует торг и согласование финальной стоимости.
В данной ситуации, как мы видим, основная работа лежит на менеджере и его действия нельзя заменить каким-либо функционалом на сайте. В связи с эти было принято простое решение: на сайте организуется витрина товаров (все товары переносятся из электронных каталогов на сайт), покупатель выбирает требуемые товары, точно задает их параметры (размеры, материал покрытия, цвет) и количество и далее простым нажатие кнопки отправляет заявку менеджеру.
Вывод из этого примера достаточно простой: не домысливайте за клиента, а просто просите его подробно рассказать о своей работе.
В том случае, если клиент на встрече затрудняется или просто не желает подробно расписывать бизнес-процессы в компании, можно попытаться разговорить его, предлагая те или иные решения на сайте, которые будут полезны сотрудникам.
Например, можно взглянуть на сайт глазами бухгалтера и выдвинуть следующее требование: «Необходим функционал автоматического выставления счета на оплату».
Варианты потенциальных требований со стороны участников могут быть такими:
- Требования директора по персоналу:
a. «Управление вакансиями на сайте сделать по аналогии с сайтом SuperJob».
b. «Создать внутрикорпоративный портал и базу знаний».
c. «Создать личные странички сотрудников».
d. «Создать возможность проведения вебинаров для сотрудников через сайт». - Требования директора по рекламе, маркетолога:
a. «Создать удобное управление баннерной системой – как для показа своих баннеров, так и чужих».
b. «Сделать возможность выгрузки данных о товарах и услугах».
c. «Создать функционал проведения опросов через сайт».
d. «Создать возможность комментирования и обсуждения товара на сайте».
e. «Организовать кросспостинг материала в социальные сети».
f. «Создать рейтинги товаров». - Требования администратора сайта:
a. «Создать возможность одновременной работы нескольких человек в административном разделе».
b. «Создать функционал автоматического архивирования сайта».
c. «Создать возможность разграничения прав доступа для редакторов сайта». - Пиар-менеджер:
a. «Необходимо использовать фирменный стиль в дизайне, подчеркивать бренд».
b. «Создать функционал «рассылки», «форум», разместить виджеты социальных сетей».
c. «Создать определённые промо-страницы, промо-блоки, аудио-видео, flash». - Бизнес-аналитик:
«Осуществить специальную настройку процесса формирования и отправки заказа, чтобы появилась возможность оценивать конверсию посетителей в покупателей». - Юрист:
«Создать раздел для публикации документов, требующих публичного оглашения». - Представитель службы логистики:
«Создать раздел с подробными картами складов».
Определение целевых групп посетителей и сценарии использования
После того, как были определены бизнес-требования и требования участников проекта, начиная с базовых: «Я как собственник бизнеса хочу начать реализацию товаров и услуг компании через интернет» и заканчивая второстепенными, менеджер нашей компании упорядочивает всю информацию и формирует на ее основе описание основных функциональных модулей будущего сайта.
После согласования с клиентом функционала сайта и бюджета проекта менеджер определяет целевые группы посетителей сайта.
Типичными целевыми группами являются:
- Покупатели
a. Первичные.
b. Вторичные.
c. Не определившиеся.
d. Постоянные. - Соискатели работы.
- СМИ.
- Партнеры.
- Инвесторы.
Далее определяются сценарии использования сайта посетителями. Такими сценариями могут быть:
- Для покупателей:
a. Для первичных: покупка товара, ознакомление с ценами, сравнение товара, получений консультаций.
b. Для вторичных: повторный заказ товара, получение скидки.
c. Для не определившихся: поиск товара, участие в акциях, связь с компанией.
d. Для постоянных: покупка одних и тех же товаров, использование скидок, техподдержка. - Соискатели работы: поиск вакансий, отправка резюме.
- СМИ: импорт новостей, импорт графической информации.
- Партнеры: авторизация на сайте, загрузка прайс-листа, чат с персональным менеджером.
- Инвесторы: информация об акциях компании, графики котировок.
Каждый из этих базовых сценариев подробно расписывается и далее согласовывается с клиентом. Например, сценарий «Отправка резюме» в расширенном виде выглядит следующим образом:
«Для того чтобы отправить резюме, соискатель должен заполнить форму, расположенную на странице с вакансией, и прикрепить к ней сам файл резюме. Описание полей формы приведено в техническом задании».
Даже такие, казалось бы, банальные вещи необходимо описывать, чтобы потом не было претензий со стороны клиента: «А я думал, вы расположите данную форму на всех страницах сайта справа…».
Техническое задание
Техническое задание является конечным документом в процессе подписания договора по созданию сайта. Оно состоит из двух блоков: описание внешней части (дизайн, функционал, варианты использования сайта в т.ч. его функционала) и внутренней (сценарии использования административной части сайта).
Техническое задание состоит из следующих блоков:
- Подробные сценарии использования со стороны заказчика (как представители заказчика взаимодействует с сайтом, например, как менеджер обслуживает через сайт заявки, как менеджер по персоналу публикует вакансии и прочее).
- Описание структуры элементов и набор полей в административной части сайта.
- Структура сайта и навигация по нему (разделы сайта, порядок расположения элементов на типовых страницах).
- Сценарии использования основного функционала (как пользователь может отправить заявку, что получит в ответ, как пользователь использует поиск по сайту и прочее).
- Описание функционала основных модулей
- Компоновка элементов, дизайн (описываются все требования к дизайну)
- Описание работы отдельных сервисов (например, использование калькулятора ОСАГО)
Более подробно останавливаться на написании технического задания я не буду, однако приведу пример того, как требование заказчика в итоге было отражено в техническом задании.
- Представитель клиента озвучил следующее требование: «Хочу удобную систему публикации и представления вакансий на сайте, чтобы было удобно создавать новые вакансии, доставать из архива и активировать старые».
- После беседы с клиентом помимо прочего менеджер выделил функционал «Вакансии», который учел при оценке общей стоимости создания сайта.
- Далее менеджер определил целевые группы: «Соискатели работы» — со стороны посетителей сайта и «HR-менеджер» со стороны участников проекта.
- В итоговом техническом задании изначальное требование приобрело следующий вид:
a. В административном разделе сайта имеется возможность создавать новые вакансии на основе шаблонов, содержащих следующий набор полей: должность/требования/обязанности/зарплата/…
b. Администратор сайта имеет возможность изменить базовый шаблон или создать новый. Соответственно при публикации вакансии имеется возможность выбрать соответствующий шаблон из имеющихся и создать на его основе вакансию.
c. Раздел «Вакансии» расположен в основном разделе «О компании».
d. Список вакансий на странице «Вакансии» имеет табличный вид. Используются поля: «Должность», «Зарплата».
e. При переходе на конкретную вакансию пользователь видит следующее (см. эскиз дизайна).
f. На странице конкретной вакансии пользователь может отправить резюме, которое придет на определенный электронный адрес, а также сохранится в базе данных.
g. Форма отправки резюме имеет следующий вид…
Заключение
После того, как менеджеры нашей компании были обучены вести сбор требований по данной технологии, эффективность реализованных в компании сайтов стала выше. Сайты стали приносить больше пользы как сотрудникам компании клиента, так и посетителям.
А все от того, что мы сами начали лучше понимать заказчика, мы начали строить с ним более содержательные диалоги и более полно собирать требования и учитывать их при проектировании сайта.
Раньше менеджер в основном лишь слушал сумбурную речь заказчика о том, как тот видит главную страницу сайта, и что «нужно звездочками показывать рейтинг товара». Сейчас же менеджер целенаправленно обсуждает с клиентом все аспекты создания сайта, начиная с цели, ради которой создается сайт, и заканчивая описанием использования сайта потенциальными посетителями, а также сотрудниками компании.
Надеюсь, и вам данный материал поможет в процессе работы с заказчиком при разработке сайта.
Теги:
- сбор требований
- техническое задание
- техзадание
- водопад
- waterfall model
- работа с заказчиком
- выявление требований
- пользовательские сценарии
Хабы:
Разработка веб-сайтов