Несколько месяцев (!!!) назад я прочитала весьма информативную и любопытную книжку Software & System Requirements Engineering in Practice. Любопытна она была мне изначально, т.к. с одним из ее авторов посчастливилось пообщаться на конференции в Австралии. А информативна она оказалась из-за обилия примеров и небольших практических подсказок, которые, хоть и не претендуют на полноту, но гораздо полезнее обобщенных рассуждений, на мой взгляд.
По почти сложившейся традиции я начала набрасывать mindmap книги... и на этом дело заступорилось. До сих пор мне не удалось завершить эту работу. Схема разрослась, детали прочитанного стали забываться, поэтому при каждой попытке дорисовать схему начинаешь книжкой зачитываться вместо того, чтобы схему рисовать :)
Посему слона будем есть по частям. Начинаем с главы Requirements Engeneering Artifact Modeling, посвященной вопросам методологического характера, с которых начинается работа над требованиями. То, что предлагается в книге, сопоставимо с артефактом, часто именуемым планом управления требованиями, однако дает собственное видение.
По почти сложившейся традиции я начала набрасывать mindmap книги... и на этом дело заступорилось. До сих пор мне не удалось завершить эту работу. Схема разрослась, детали прочитанного стали забываться, поэтому при каждой попытке дорисовать схему начинаешь книжкой зачитываться вместо того, чтобы схему рисовать :)
Посему слона будем есть по частям. Начинаем с главы Requirements Engeneering Artifact Modeling, посвященной вопросам методологического характера, с которых начинается работа над требованиями. То, что предлагается в книге, сопоставимо с артефактом, часто именуемым планом управления требованиями, однако дает собственное видение.
Отличием хорошей книги является еще и то, что при ее прочтении появляются мысли и вопросы, лежащие за пределами материала изложения. Такие вопросы на схеме отмечены, надеюсь вернуться к ним в более развернутом виде впоследствии.
Комментариев нет:
Отправить комментарий