Терминология – вот камень преткновения, когда начинается обсуждение требований к программному обеспечению. Подчас количество названий одного и того же документа начинает приближаться к числу экспертов, которые работают над данной задачей. Стоит ли удивляться, что в скором времени такое многообразие приведёт к сумятице, а последняя плавно перерастёт в серьёзные проблемы коммуникации?
Эксперты могут называть документ по-разному:
– требование к проекту;
– системное требование;
– бизнес-требование;
– функциональное требование;
– пользовательская точка зрения;
– требование к программному обеспечению;
– требование к продукту;
– пользовательская функция;
– пользовательское ограничение.
Мало того. Вышеперечисленные «рабочие названия» часто наполнены совершенно разным смыслом. Он зависит от того, является эксперт заказчиком или представляет сторону разработчиков. Первые часто считают, например, то же бизнес-требование полноценной высокоуровневой концепцией продукта, ориентируясь на который, исполнители вполне смогут создать желаемое. Программисты же со своей стороны видят в нём всего лишь «разработку интерфейса пользователя». Правда – достаточно детализированную.
Важное уточнение. Слово «документ» в данном контексте вовсе не означает «бумажный документ». Более того, оно даже не – «электронный документ». Здесь «документ» – своего рода «контейнер», где хранится информация о требованиях.
Такой «контейнер» может представлять из себя:
– набор диаграмм;
– электронную таблицу;
– базу данных;
– стандартный (традиционный) документ;
– сочетание всего вышеперечисленного.
Само же требование к ПО состоит из трёх уровней: бизнес-требования, пользовательские и функциональные.
Легко догадаться: первые представляют из себя цели, ради которых собралась команда; вторые – пожелания клиентов. А вот последние обращены исключительно к разработчикам. Они «увязывают» между собой первый и второй уровень. То есть делают так, что пользователь, работая с готовым ПО, автоматически движется в сторону выполнения задачи, ради которой, данный продукт, собственно, и был создан. В случае сомнений, к какому именно уровню относится то или иное требование, есть смысл задать «ключевой» вопрос. Если он будет начинаться со слова «хочу», то мы имеем дело с уровнем пользователя, а если «должен» – речь идет о функциональном.
Несколько иной подход к терминологии позволяет разбить подготовку к созданию ПО на этапы и тем самым значительно улучшить качество продукта. В данном случае процесс носит название «разработка технических условий». Он делится на две части: разработка требований и управление требованиями.
Разработка требований в свою очередь включает в себя:
– выявление;
– анализ;
– документирование;
– утверждение.
Каждый из пунктов требует к себе особого внимания. И насколько тщательно они будут проработаны на совместных обсуждениях проекта с участием всех заинтересованных сторон – пользователей-клиентов, бизнес-аналитиков, программистов – тем больше шансов, что готовый продукт будет содержать лишь допустимый минимум ошибок.
К тому же, что просчёты обязательно будут, лучше заранее морально подготовиться. Идеальных требований к программному обеспечению просто не существует.
А раз задача настолько сложна, есть смысл сделать её хотя бы немного проще. Для начала – условиться о единой терминологии.
Ведь говорить на одном языке – главное условие, чтобы понять друг друга?
