С чего начинать извлечение требований?




Главная   Форумы   Общие вопросы по работе с требованиями   С чего начинать извлечение требований?

В теме 4 ответа, и 4 участника, последнее обновление сделано пользователем Аватар (Vitrimak) Vitrimak 13 г, 6 мес. назад.

Показано 5 ответов - от 1 до 5 (всего 5)
  • Автор
    Сообщения
  • 15.01.2010 в 02:03 # 5025
    У вас новый проект.
    Заказчик обладает знаниями.
    Вам надо начинать работу с требовтаниями.
    Заказчик доступен для извлечения требований.
    Допустим, доступен только удаленно (email + skype / ICQ / любой другой ИМ + телефон).

    С чего вы начнете?
    Какими будут ваши шаги, средства, техники, инструменты?

    Поделиться:

    Цитировать

    17.01.2010 в 20:20 # 5026
    Такой слегка обширный вопрос))
    Если вкратце, то во-первых пройтись с заказчиком по quick list базовых вопросов дабы оценить скоуп проекта. У каждого этот список свой; у меня лично это authentication and authorization portion (юзера, роли, аутентификация, пермишны), каталог юз кейсов приложения, драфтовые мокапы скринов, интеграция с внешними приложениями и скрытая логика системы. Получив исходные неформализованные требования по всем этим пунктам ваяется скоуп проекта (к примеру в виде юз кейсыкаталог фич -> vision and scope document). После полного согласия между сторонами по скоупу начинается детальное выяснение требований по всем этим пунктам и, соответственно, занесение их в SRS.Это были шаги. Средства коммуникации: IM, mail, телефон. ПОинструменты: MS Visio, Word, EA, Outlook.
    Поделиться:

    Цитировать

    11.04.2010 в 13:37 # 5027
    Я вот, думаю, что всё же начать надо с того, что
    1) ознакомиться со всеми имеющимися материалами
    2) ознакомиться с тем, кто же ваш заказчик
    3) ознакомиться с бизнесом вашего заказчика

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

    Проделав эти 3 базовых шага, потом 4ым шагом, имхо, можно и нужно
    4) спланировать дальнейшее "извлечение" требований..

    Поделиться:

    Цитировать

    12.05.2010 в 11:24 # 5028
    Аватар (Yuliya Shamrei)
    Юлия Шамрей
    Участник
    Мне тут подкинули хороший вопрос, который должен аналитик задать себе (и заказчику), приступая с извлечению требований. Звучит так: "Где бабло?" (для заказчика естественно можно перефразировать) :) Т.е. не просто ознакомиться с бизнесом, а подумать и думать постоянно (при извлечении требований, проектировании системы ее разработке и имплементации и т.д.) о том, какие выгоды получит заказчик от проекта/системы и учитывать их (или не учитывать, но сознательно :) )

    Давайте еще рассмотрим ситуацию работы аналитика onsite и наличия нескольких стейкхолдеров (например 3-7 человек).
    С чего бы начала я после знакомства со всеми стейкхолдерами.

    1. Выделила бизнес потребности и их владельцев (кому что надо).
    2. Выделила high-level процессы, их владельцев и 2-3 активных участников каждого процесса.
    3. Выделила аналитика со стороны заказчика. Вот тут ИМХО важно пояснить, что у всех этих людей должно быть выделено время на работу над проектом, иначе они ее будут саботировать. Объяснить их руководству.
    4. Вначале самостоятельно изучила процессы (google и т.п.), нарисовала бы себе стандартный процесс (по ISO и т.п.), сформировала скоуп вопросов. Часто заранее можно получить всякие внутренние инструкции, памятки и т.п. — в них горы информации.
    5. Сформировала коммуникационный план. Оптимально, я думаю делать его еженедельно на неделю вперед. Запланировала встречи согласно плану.
    6. И вперед на баррикады: интервью, анкеты, семинары, наблюдение и т.д. Вот тут я для себя заметила некоторую особенность: есть люди, которым лучше писать, чем говорить. Вот таким я стараюсь задавать вопросы письменно.

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

    7. Нарисовала процессы "как есть" и подтвердила с участниками процессов, что именно так и есть.
    8. Приступила к формированию системных сценариев использования на основании бизнес сценариев.

    Параллельно со всем этим, я бы выясняла доменную модель (сущности, атрибуты, связи), не функциональные требования, права на данные и действия, список желаемых фич и их приоритеты.

    Поделиться:

    Цитировать

    01.09.2010 в 23:32 # 5029
    Аватар (Vitrimak)
    Vitrimak
    Подписчик
    Соглашусь с постом essense. Скажу только вот что, многое зависит от того, что аналитик получил на старте. Если ничего, то нужно делать Vision and Scope документ, ну а там во многом и покрываются те моменты, на которые обратила essense.
    Поделиться:

    Цитировать

Показано 5 ответов - от 1 до 5 (всего 5)

Вы должны авторизироваться для ответа в этой теме.