В теме 4 ответа, и 4 участника, последнее обновление сделано пользователем 
Vitrimak 14 г, 3 мес. назад.
-
Сообщения
-
У вас новый проект.
Заказчик обладает знаниями.
Вам надо начинать работу с требовтаниями.
Заказчик доступен для извлечения требований.
Допустим, доступен только удаленно (email + skype / ICQ / любой другой ИМ + телефон).С чего вы начнете?
Какими будут ваши шаги, средства, техники, инструменты?Такой слегка обширный вопрос))
Если вкратце, то во-первых пройтись с заказчиком по quick list базовых вопросов дабы оценить скоуп проекта. У каждого этот список свой; у меня лично это authentication and authorization portion (юзера, роли, аутентификация, пермишны), каталог юз кейсов приложения, драфтовые мокапы скринов, интеграция с внешними приложениями и скрытая логика системы. Получив исходные неформализованные требования по всем этим пунктам ваяется скоуп проекта (к примеру в виде юз кейсыкаталог фич -> vision and scope document). После полного согласия между сторонами по скоупу начинается детальное выяснение требований по всем этим пунктам и, соответственно, занесение их в SRS.Это были шаги. Средства коммуникации: IM, mail, телефон. ПОинструменты: MS Visio, Word, EA, Outlook.Я вот, думаю, что всё же начать надо с того, что
1) ознакомиться со всеми имеющимися материалами
2) ознакомиться с тем, кто же ваш заказчик
3) ознакомиться с бизнесом вашего заказчикаСейчас я всё больше и больше замечаю, что эти шаги многими пропускаются. И, что обиднее всего, пропускаются аналитиками.
Причем, это особенно и действительно важно в начале работы конкретного человека с проектом.
Закладывайте это время в работу, планируйте его, погуглите, почитайте вики, у нас теперь столько способов и возможностей. Я уже видел и слышал несколько раз, как вот такие активности спасали проект или позволяли его заполучить / выиграть.Проделав эти 3 базовых шага, потом 4ым шагом, имхо, можно и нужно
4) спланировать дальнейшее "извлечение" требований..Мне тут подкинули хороший вопрос, который должен аналитик задать себе (и заказчику), приступая с извлечению требований. Звучит так: "Где бабло?" (для заказчика естественно можно перефразировать)
Т.е. не просто ознакомиться с бизнесом, а подумать и думать постоянно (при извлечении требований, проектировании системы ее разработке и имплементации и т.д.) о том, какие выгоды получит заказчик от проекта/системы и учитывать их (или не учитывать, но сознательно )
Давайте еще рассмотрим ситуацию работы аналитика onsite и наличия нескольких стейкхолдеров (например 3-7 человек).
С чего бы начала я после знакомства со всеми стейкхолдерами.1. Выделила бизнес потребности и их владельцев (кому что надо).
2. Выделила high-level процессы, их владельцев и 2-3 активных участников каждого процесса.
3. Выделила аналитика со стороны заказчика. Вот тут ИМХО важно пояснить, что у всех этих людей должно быть выделено время на работу над проектом, иначе они ее будут саботировать. Объяснить их руководству.
4. Вначале самостоятельно изучила процессы (google и т.п.), нарисовала бы себе стандартный процесс (по ISO и т.п.), сформировала скоуп вопросов. Часто заранее можно получить всякие внутренние инструкции, памятки и т.п. — в них горы информации.
5. Сформировала коммуникационный план. Оптимально, я думаю делать его еженедельно на неделю вперед. Запланировала встречи согласно плану.
6. И вперед на баррикады: интервью, анкеты, семинары, наблюдение и т.д. Вот тут я для себя заметила некоторую особенность: есть люди, которым лучше писать, чем говорить. Вот таким я стараюсь задавать вопросы письменно.Я считаю, что обследование процессов "как есть " важно при извлечении требований. Потому что на этом этапе выясняется столько интересной инфы, которая может быть имлементирована в системе (регистрация задним числом, параллельное и одновременное выполнение последовательных процедур процесса, регистрация дополнительной информации и т.д.).
7. Нарисовала процессы "как есть" и подтвердила с участниками процессов, что именно так и есть.
8. Приступила к формированию системных сценариев использования на основании бизнес сценариев.Параллельно со всем этим, я бы выясняла доменную модель (сущности, атрибуты, связи), не функциональные требования, права на данные и действия, список желаемых фич и их приоритеты.
Соглашусь с постом essense. Скажу только вот что, многое зависит от того, что аналитик получил на старте. Если ничего, то нужно делать Vision and Scope документ, ну а там во многом и покрываются те моменты, на которые обратила essense.
Вы должны авторизироваться для ответа в этой теме.
