Как вы решаете двусмысленности в спецификации?

Question

Мне нужен совет, как устранить неоднозначности в спецификациях приложений. В качестве одного простого примера,

Если пользователю не удается пройти проверку подлинности через несколько раз, отправьте уведомление в ИТ-службу.

В вышеприведенном примере не ясно, сколько раз "количество раз". Это не ясно, и я не могу просто установить случайный предел, например, 1000 раз.

Как бы вы решили разрешать неясные части в каких-либо спецификациях? (не только тот, который я упомянул)

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

Буду признателен за любые полезные ноу-хау и советы.

Answer 1

Если вы формально отслеживаете свои требования, вы можете сделать свои предположения и задокументировать их как производные требования:

Пример:

Требование пользователя:

Треб. 1: Если пользователь не проходит аутентификацию через несколько раз, отправьте уведомление в ИТ.

Производные требования:

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

Треб. 1.1.1 В электронном письме о приостановлении действия аккаунта будет указано следующее:

• Имя учетной записи пользователя.
• IP-адрес компьютера, с которого были сделаны попытки аутентификации.

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

Для получения дополнительной информации, Google "управление требованиями" или "разработка требований". Сектор оборонной промышленности загружен с примерами и шаблонами, возможно, слишком много;)

Некоторые из них я отметил:

• Руководство по написанию спецификаций
• Написание программного обеспечения Требования Технические характеристики

Answer 2

Ответьте клиенту точными вопросами, которые у вас могут возникнуть. Это лучший вариант, если есть. Если нет, то сделайте его настраиваемым для конечного пользователя (клиента).

Answer 3

Постройте или создайте прототип, а затем покажите его людям, написавшим спецификацию.

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

Answer 4

Общайтесь с (желательно в таком порядке):

• Бизнес-аналитики
• Клиент (человек (а), оплачивающий конечный продукт)
• Конечные пользователи

Answer 5

Ты слишком много думаешь об этом.

1. Значение 'количество раз' может быть легко помещено в web.config
2. Установите соответствующее предполагаемое значение. (не беспокойся о том, что ошибаешься)
3. Отправьте электронное письмо своему менеджеру с вашим предположением, и как они могут изменить его, если ваше предположение неверно.

Часть уведомления спецификации может быть принята, если любое другое уведомление приложения является электронным письмом (что не является нереальным). В противном случае спросите, прежде чем что-то делать.

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

И как ни странно; Вы, вероятно, обнаружите, что большинство ваших предположений в любом случае будет верным.

Answer 6

Для этого вы можете создать фокус-группу, или вы можете общаться с клиентом / соответствующим заинтересованным лицом.

Answer 7

Что ж, на корпоративном предприятии это означает, что оно следует Общей корпоративной политике.

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

Answer 8

Если спецификация не точная, может, это просто не имеет значения? Не важно, чтобы что-то еще работало? Сделайте вызов, пусть это будет 1000. Убедитесь, что это не жестко запрограммировано. Хорошая идея - поместить его в какой-нибудь файл конфигурации (но не показывать интерфейсу конечного пользователя, потому что пользователь обычно имеет даже меньше идей, чем вы).

Если это вопрос взаимодействия, то что делают другие парни? это 200 в Windows? Чем сделать это 200. Теперь вы подходите и Windows, и spec - неплохо: -)

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

Answer 9

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

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

Answer 10

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

1) Руководитель проекта / бизнес-аналитик -> Вероятно, они ближе всего к проекту и могут помочь быстро решить проблемы со спецификациями. Это может включать в себя опрос других людей и перезвонить вам позже, но это должно быть приемлемо.

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

3) Владелец продукта -> Кто отвечает за определение приложения. Обратите внимание, что это не технический специалист, поэтому быть конкретным и иметь рекомендации могут быть полезны, если вы встретите ответ «Вы знаете, я не думал об этом ...».

4) Менеджер группы / Руководитель группы -> Если ничего не помогает, обратитесь к начальнику и попросите разъяснений.

«Сбор требований» или «Анализ требований» являются общими терминами для этой части «Жизненного цикла разработки программного обеспечения» или «Жизненного цикла разработки систем», чтобы отбросить еще несколько терминов, которые вы можете найти, и найдете множество статей.