В теме 19 ответов, и 6 участников, последнее обновление сделано пользователем 
Андрей В. 13 г, 6 мес. назад.
-
Сообщения
-
На самом деле немного странная постановка вопроса.
Если речь о самом начале проекта, то проект (если это не собственный продукт) должен базироваться на контракте. В контракте (в той или иной мере, помимо остальных вещей, которые присутствуют в контракте) должно быть описание проекта (бизнес цели). А еще лучше подписанное приложение к контракту с более детальным списком того, что является предметом контакта (список фич или что-то вроде того). Вот берете этот контакт / приложение и развиваете дополнительными вопросами то, что там написано.Если речь о предпродажных активностях (например, участие в тендоре), то тут поможет стандартный опросник + уточняющие митинги/звонки. Детально собирать требования тут не получится, поэтому надо будет собирать не "вглубь", а "вширь" (чтобы не забыть ненароком 4 модуля). При всем при этом, при оформлении коммерческого предложения надо писать максимально конкретно, чтобы фразу "отчеты" нельзя было воспринять как "разработка системы документооборота предприятия".
Помимо этого я бы обязательно постаралась оценить степень технической подготовленности контактного лица. Потому что иначе на вопрос "что системе надо подавать на вход" — можно получить в ответ что-нибудь нехорошее).
Лично я стараюсь начинать сбор требований с пользователей (кто будут будущие пользователи, что они будут делать в системе и т.д.).
Часто оказывается полезно спросить про аналоги и изучить их.Может их лучше сгруппировать-классифицировать?
— Выявление, классификация и описание stakeholder-ов, всех заинтересованных лиц. —
Кто является пользователем системы?
Кем это будет использоваться?
Кто является заказчиком (экономическим покупателем) системы?
Кто будет оценивать и принимать систему, когда она будет представлена и развернута?
Существую другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?
Кто будет заниматься сопровождением новой системы?
Не забыли ли мы кого-нибудь?
Для чего, для кого и в какие сроки должна быть разработано ПО?
Кто и что должен делать?
На кого ещё окажут влияния результаты работы системы?— Основные цели создания продукта —
Зачем вам нужно это ПО?
Почему вам это надо делать?
Для чего вы это делаете?
Что вы хотите достичь?
Что делается неэффективно?
Что должно быть улучшено?
Что будет, если этого не сделать?— Описание общей функциональности системы, конкретных ВИ —
Какие задачи должна решать необходимое вам ПО?
Что вы хотите, чтобы вы могли делать?
Что должно делать ПО?
Без чего нельзя обойтись?
Что мы подаём на вход?
Откуда вы возьмете эти данные?
Что мы должны получить на выходе?А вообще вы идете от частного к общему, начните сначало с общего описания системы, постарайтесь понять, что должно быть разработано, как это должно работать и т.д. Если хотите список вопросов, чтобы ничего не забыть, создайте свой чеклист, он будет изменяться от проекта к проекту, от года к году, от организации к организации.
Вот, например, парочка вопросов из моего чеклиста:
User classes and privileges
• Describe behavior and representations for logged and non-logged users.
• Describe behavior and representations for registered and non-registered users.
• etc.
Web-interfaces and representations
• Define order by for lists.
• Define required fields.
• etc.Список может быть бесконечным.
На самом деле немного странная постановка вопроса.
Если речь о самом начале проекта, то проект (если это не собственный продукт) должен базироваться на контракте. В контракте (в той или иной мере, помимо остальных вещей, которые присутствуют в контракте) должно быть описание проекта (бизнес цели). А еще лучше подписанное приложение к контракту с более детальным списком того, что является предметом контакта (список фич или что-то вроде того). Вот берете этот контакт / приложение и развиваете дополнительными вопросами то, что там написано.У меня такого не было ещё.
Если речь о предпродажных активностях (например, участие в тендоре), то тут [b]поможет стандартный опросник[/b] + уточняющие митинги/звонки. Детально собирать требования тут не получится, поэтому надо будет собирать не "вглубь", а "вширь" (чтобы не забыть ненароком 4 модуля). При всем при этом, при оформлении коммерческого предложения надо писать максимально конкретно, чтобы фразу "отчеты" нельзя было воспринять как "разработка системы документооборота предприятия".
"поможет стандартный опросник" — о том и данная тема
Помимо этого я бы обязательно постаралась оценить степень технической подготовленности контактного лица. Потому что иначе на вопрос "что системе надо подавать на вход" — можно получить в ответ что-нибудь нехорошее).
А как делаете оценку подготовленности?
Лично я стараюсь начинать сбор требований с пользователей (кто будут будущие пользователи, что они будут делать в системе и т.д.).
Бывает так, что есть только один представитель заказчика и он далеко. Под боком нет таких пользователей.
Часто оказывается полезно спросить про аналоги и изучить их.
Да. Если есть аналоги, то это очень сильно поможет.
skan201 благодарю за вашу классификацию!
Вот и сделали общими усилиями хороший начальный и универсальный вопросник. По-моему очень полезная штука! У кого-нибудь будут правки в классификации и вопросах? Замечания, исправления и дополнения только приветствуются.А вообще вы идете от частного к общему, начните сначало с общего описания системы, постарайтесь понять, что должно быть разработано, как это должно работать и т.д.
Почему частное? С помощью данного вопросника хочу получить общее представление о будущей системе.
Если хотите список вопросов, чтобы ничего не забыть, создайте свой чеклист, он будет изменяться от проекта к проекту, от года к году, от организации к организации.
Я думаю, что лучше иметь вопросник чем не иметь.
Вот, например, парочка вопросов из моего чеклиста:
User classes and privileges
• Describe behavior and representations for logged and non-logged users.
• Describe behavior and representations for registered and non-registered users.
• etc.
Web-interfaces and representations
• Define order by for lists.
• Define required fields.
• etc.Список может быть бесконечным.
Я думаю, что ваши вопросы уже более детализированы. Скорее всего они для уточнения деталей. А я делаю упор на "универсальные первые вопросы для любого будущего продукта".
Я правильно новые дополнительные вопросы классифицировал?— Основные цели создания продукта —
Что Вы хотите от системы?
Как вы узнаете, что проект был успешен?— Описание общей функциональности системы, конкретных ВИ —
Как Вы планируете проверять достижения того, что вы хотели от системы?
Как вы делаете сейчас (руками или сущ. ПО) и что вам в этом не нравится?
Вы должны авторизироваться для ответа в этой теме.
