Итоги лекции 3

Записаться

Сегодня мы рассмотрим последний, четвертый модуль лекции 3 курса «Анализ требований к информационным системам». В этом модуле мы подведем итоги лекции 3 и наметим план лекции 4. Лекция 3 была посвящена требованиям, их атрибутам и активностям по работе над ними. Эта лекция является одной из самых важных в нашем курсе. Именно в ней мы постарались раскрыть основные понятия курса и суть понятия «требование», дали все необходимое для формирования общего представления о том, что такое требования, для чего они нужны, как с ними работать, как извлечь из них наибольшую ценность. Теперь вы можете  использовать эту информацию в своих целях.

Итак, сделаем выводы, которые позволят вам запомнить наиболее ценную информацию, а детали при необходимости вы сможете найти, просмотрев прошлые лекции или найдя более полное описание конкретных интересующих вас аспектов. Аналитик – инженер, а инженер не должен знать и помнить все, но должен уметь найти наиболее удачный инструмент для решения своей задачи.

Назначение требований – удовлетворить конкретные нужды пользователей. Для их удовлетворения нужно знать цели и разбираться в них. Достижение целей происходит за счет следования выбранному пути, но каждый путь уникален и представляет собой набор сочетающихся вариантов решения конкретных задач. Для решения задач нужно формализовывать варианты, которые наиболее удачным образом подходят для решения конкретной задачи. При реализации требований происходит преобразование исходной ситуации. Мы выходим из стартового состояния, находимся в пути, трансформируемся и приходим в конечное состояние, которое должно приносить наибольшее удовлетворение. Требование – это подход к автоматизации существующих идей, мыслей, процессов. Для того чтобы преобразование было выполнено наиболее удачным образом, следует классифицировать требования. Каждая классификация очерчивает рамки и границы работ.

Работа с требованиями востребована тогда, когда нам необходимо построить базис, на котором станет возможным развивать конкретную идею – с самого начала, с момента ее зарождения до момента, когда она станет реальностью и будет приносить пользу. Это очень долгий путь. На любом долгом пути возникает множество проблем – проблемы с передачей информации, со следованием выбранным маршрутом, с формализацией сказанного и услышанного, с представлением необходимой информации, с реализацией требований, а также с верификацией и валидацией разработанного продукта. Это лишь малый список проблем. Да, все они носят вероятностный характер, и, если мы реализуем небольшой проект, то есть вероятность, что какие-то из этих проблем для нас некритичны и могут носить низкий приоритет в общем объеме проблем. Но если так случится, то это будет удачей, а профессионал не может полагаться на удачу – он должен следовать своему профессиональному пути и делать то, что, по его мнению, наиболее нужно для решения конкретной задачи. За конечный результат отвечает каждый профессионал, вовлеченный в рабочий проект. Аналитик отвечает за требования. Именно он осуществляет работы и ведет артефакты, которые необходимы для того, чтобы результат оправдал вложенные в него средства. Результат может быть выражен не только в виде конкретной информационной системы, но и в виде дополнительных артефактов, которые упростят сопровождаемость и развитие создаваемой информационной системы. Словом, аспектов много и нужно фокусироваться на главных.

Будет логичным воспринимать любые требования как способ преобразования из целевого состояния в какое-то желаемое состояние. Для аналитика важно ясно понимать целевое состояние во всех его нюансах, деталях и проявлениях. Это понимание дает ему план преобразований и конкретные шаги, которые необходимо воплотить в виде организационных или технических решений. Эти шаги затем будут преобразовываться в части требований или в полноценные требования, которые будут реализованы и станут приносить ценность. Требования преобразуются вместе с проектом автоматизации. Это не статичный артефакт, он развивается вместе с развитием самой деятельности. Аналитик должен отслеживать ситуацию и вносить в требования изменения, соотнося их с изменением ситуации в целом. Так, постепенно, шаг за шагом, иногда кардинально изменяясь, требования начинают приносить ценность своим владельцам и заказчикам.

В своей основе требование – это комплексное понятие, которое должно учитывать организационную, культурную и техническую составляющую. Работая над требованиями, аналитик должен помнить о том, что он делает информационную систему для пользователей, которые будут работать в определенных условиях. Эти факторы составляют полный рабочий контекст, но главное внимание уделяется факторам автоматизации. Требования фиксируют и формируют картину автоматизации. Эта картина будущего. Эта картина всегда недостижима. Эта картина изменений. Эта картина, в которой всегда много неизвестных и нет точных ответов на эти неизвестные. Попробовать заполнить эти неизвестные – работа аналитика. От того, какими будут ответы, зависит красочность картины. Это всегда неопределенность. Аналитик снимает эту неопределенность за счет принятия конкретных профессиональных решений. Да, конечно, эти решения потом обсуждаются и согласуются, но обсуждение и согласование происходит на основе той информации, которую предлагает аналитик. И обсуждение, и согласование будут идти трендом, заданным аналитиком. При определенных условиях это может быть манипуляция, при других это может быть наиболее простым организационным решением. Вариантов много. И те, кто говорят, что работа с требованиями – это скучная область, не понимают ее сути. Аналитик рисует картину будущей системы заказчика с помощью технических шаблонов, своего опыта и своих профессиональных качеств.

Как мы с вами поняли, инженерия требований – это инструмент, который используется для того, чтобы работать над прояснением и детализацией идей до уровня, понятного специалистам, воплощающим эти идей на практике. Это высокоуровневое определение, но оно задает контекст использования инженерии требований. Поэтому давайте вернемся в русло нашего курса и поговорим о способах приложения этой дисциплины. Анализ требований применим во всех сферах IT-анализа. Следующим шагом логично будет рассмотреть эти виды анализа, понять сферу их применения и ценность, которую они дают. Это системный анализ, анализ данных, бизнес-анализ, продуктовый анализ и процессный анализ. Каждый из этих типов анализа уделяет внимание определенному аспекту создаваемой системы и по-своему работает над ее аспектами. В совокупности они нужны для того, чтобы создавать эффективные, востребованные и качественные информационные системы. Об этих типах анализа мы и поговорим далее.

Мы заканчиваем лекцию 3. Настал момент подвести ее итоги. Важно запомнить, что требование – это комплексное, многосоставное понятие, создавать которое необходимо на основе анализа рабочего контекста. Работа над требованиями – во многом стандартизированный вид деятельности, который содержит много направлений работ. Инженерия требований имеет и постоянно развивает инструментарий и типы активностей, который помогают в осуществлении этого вида деятельности. На сегодня все. До следующей встречи!