Требования и технический дизайн как одно усилие?

Question

Я работал над большим многолетним проектом в качестве веб-архитектора.

До сих пор моя обязанность заключалась в том, чтобы взять документацию с требованиями, предоставленную аналитиком заказчика, и перевести ее в техническую проектную документацию.

«Силы, которые есть» предполагают, что я возьму на себя документацию с требованиями и объединю ее с моими усилиями по техническому проектированию.

Есть ли конкретная проблема, которую вы видите, когда объединяете требования и технический дизайн в один шаг?

Обратите внимание, что мы уже хорошо занимаемся разработкой, поэтому многие технические решения (ОС, инфраструктура приложений, база данных, серверы и т. Д.) Уже были заложены в камень.

Answer 1

«Есть ли конкретная проблема, которую вы видите, когда объединяете требования и технический дизайн в один шаг?»

Да.

Требования почти не имеют ничего общего с техническим дизайном.

Требования определяют, «что» должно произойти. Дизайн объясняет, «как» он будет построен, чтобы это произошло.

Например, я хочу пива - это мое требование.

Технический проект может быть

1. Встань со стула и спустись вниз. Бюджетный. Здесь есть риск. Там может не быть пива.

2. Встань со стула и иди в паб. Более высокая стоимость. Здесь мало риска. За исключением воскресенья, когда он закрыт.

3. Спроси мою жену. Огромный риск здесь. Возможные непреднамеренные последствия. Тем не менее, я делегировал проблему, и теперь ей нужно либо найти пиво в доме, либо бежать в магазин, либо сказать мне, чтобы я купил свое. Если она все равно выйдет, мы вернемся к низкой цене и без риска.

Одно требование. Несколько проектов для решений. Вы не можете работать над обоими вещами за один шаг.

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

Затем вы должны разработать решение. Решение может включать или не включать создание нового программного обеспечения.

При изучении требований вы часто сталкиваетесь с ситуациями, когда пользователям необходимо изменить способ работы. Требования могут быть выполнены несколькими способами.

Один человек может одновременно задокументировать требования и сделать проект. Но вы должны сделать их отдельно. Вы должны задокументировать требования так, чтобы пользователи понимали и соглашались с характером проблемы и с тем, что требуется для объявления проблемы решенной.

Затем - отдельно - вы решаете, как наилучшим образом оптимизировать затраты, риски, время доставки, навыки, доступные технологии для решения некоторых проблем.

Answer 2

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

Хотя есть определенное преимущество в отделении разработки от роли «защиты интересов клиентов», у профессионального разработчика не должно возникнуть проблем с отслеживанием требований без возникновения каких-либо конфликтов интересов. Есть ли другая проблема, которая вас беспокоит? Является ли документация по требованиям даже большой задачей на данный момент? Сокращение количества слоев между заказчиком и разработчиком на самом деле звучит довольно неплохо.

Answer 3

Да. Сочетание требований и технического дизайна затуманивает ваше мышление - оно не позволяет вам в дальнейшем придумывать новые идеи о том, как улучшить систему с помощью другого технического подхода / оптимизации.

Особенно в области новых технологий, вы можете начать с неправильного подхода. Сочетание технического дизайна и требований побуждает вас думать о своем техническом подходе как о требовании, когда его вполне можно отменить и сделать по-другому.

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

Answer 4

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

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

Answer 5

Требования относятся к , что необходимо сделать. Технический проект относится к как требования могут быть выполнены.

Недостатки:

• Одним из недостатков их объединения является что, если вы технический парень, вы попытаетесь повлиять на требования, чтобы сделать технический задача проще, ориентируясь на как . В конец, вы могли бы разработать систему это на самом деле не относится (все) проблемы пользователя (ов) этого система .
• Еще одним недостатком является то, что, хотя уточнение требований, техническое решение должно быть адаптированы для выполнения нового особенности / детали, которые были уточнены или обнаружены во время требований выявление. Это означает изменение / переосмысление технического решения несколько раз в течение уточнение требований .

Возможное преимущество:

• Имея обзор технического решения при обсуждении требований, вы можете «согнуть» или обсудить требования, чтобы избежать последующего обнаружения технических проблем (например, проблем с производительностью, невозможных или дорогостоящих функций с добавлением стоимость не пропорциональна стоимости их реализации). Но вы должны быть осторожны, чтобы не вкладывать слишком много средств в техническое проектирование, прежде чем требования действительно прояснятся.

Answer 6

У меня нет возможности работать в гибкой команде или команде разработчиков, и у меня нет возможности их применить. Я делаю много разовых разработок для клиентов от 1 до 3 месяцев. Но одна вещь, которую я узнал, находясь в такой среде:

Подписывайтесь с заказчиком на каждом этапе проекта.

Который ответит на ваш вопрос как: Никогда не смешивайте требования с проектной документацией.

На самом деле, это выходит за рамки этого.

1. Прежде всего, подпишите Объем работ (SoW).
2. Затем отпишите требования.

Мы много раз видели необоснованных клиентов, которые постоянно меняли требования. Однако они не рассчитывают платить за эти изменения. При неправильном управлении стоимость проекта значительно перевесит и превысит доход проекта.

Наличие подписанного SoW защищает вас от внеплановых требований, например. «Поставщик установит приложение xxx» и внезапно «клиент хочет установить целую инфраструктуру PKI для защиты связи с приложением xxx».

Наличие подписанных требований защищает вас от внезапных и необоснованных требований, следуя приведенному выше аналогичному случаю, «нет необходимости защищать и шифровать связь с приложением xxx».

Обратите внимание, что это правовая защита. Вам все еще предстоит решить, следует ли выполнить новое требование от клиента. Однако по-прежнему полезно подчеркнуть, что они не соответствуют требованиям и сделаны исключительно по доброй воле.

Объединение проектной документации с основным документом требований не позволяет подписать документ с требованиями. Заказчик будет очень доволен этим, но я думаю, что ваша команда разработчиков будет ненавидеть возможное время кризиса.

Я видел альтернативный подход, который есть у людей (но не при объединении дизайна с требованиями).

Разделите документ с требованиями в основной файл с отдельными файлами приложений. Храните важные и конкретные вещи в документе с требованиями. Это позволяет вам подписать документ с требованиями, в то же время позволяя вносить изменения в приложение на более позднем этапе. Мы в основном используем этот подход для вспомогательных документов в качестве приложения. Он может работать с дизайн документа в качестве приложения, но я не видел дизайн документа в качестве приложения.

Кроме того, в некоторых проектах вы можете даже подписать документацию до начала разработки. Или эти дизайн / требования / SoW - доставка или промежуточный платеж.

Действительно, старайтесь не объединять их.

Answer 7

Я думаю, что очень важно, чтобы требования и дизайн делали одни и те же люди.

Если вы получаете требования, вы на самом деле будете разговаривать с бизнесом. Это даст вам возможность изучить бизнес и услышать, что им действительно нужно, без прикрас и без фильтра. У вас будет возможность убедить их рассказать о проблеме в деловых терминах, вместо того, чтобы принять техническое решение и перейти к разработке (например, «Добавьте этот столбец в эту таблицу и привяжите его к этому текстовому полю на этой странице»). ) Возможно, вы сможете увидеть способы решения проблемы, о которой они даже не подозревали.