В каком грамматическом времени я должен написать свои спецификации?

21

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

Однако я борюсь с тем, в каком времени писать это:

С прошедшим временем, как будто работа сделана, я изо всех сил пытаюсь показать основные моменты выходящей работы. Будущее время в том виде, в котором оно должно быть выполнено, X начинает звучать как список дел или нейтральное время очень сильно, так как оно либо должно быть сделано, либо уже сделано.

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

documentation specifications writing Джон
источник

Ответы:

12

У нас много этого на моем последнем месте работы.

Менеджеры по продуктам решили использовать настоящее время для описания того, что должно быть сделано , например:

Пользователь отправляет заказ. Система отправляет подтверждающее сообщение.

К сожалению, описание предварительных условий также было сделано в настоящем времени, как:

Пользователь помещает товар в корзину и указывает количество.

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

Следовательно:

  • Используйте настоящее время для того, что уже существует

  • Используйте будущее время для того, что должно быть сделано. Используйте миры "должен", "должен", "будет".


источник
Важный шаг, который нужно помнить, это пересмотр спецификации. Не забудьте обновить формулировку из будущего в настоящее, когда это будет сделано.
Бен Л
@BenL: нет, это неправильно. Время используется для обеспечения правильной реализации, а не для указания статуса реализации. Здесь будущее время используется для указания будущего состояния приложения, а не будущего состояния реализации. Кроме того, стоит отметить, что предлагаемый здесь подход также используется большинством RFC. См. RFC 2119 для обсуждения терминов «необходимо / обязательно / должно (не)», «должно / рекомендовано (не)» и «может / необязательно».
Брайан
5

Настоящее время кажется мне хорошим.

  1. Условие: Foo находится в состоянии X
  2. Операция: это и то, что происходит
  3. Постусловие: Foo в состоянии Y

все они в настоящем времени.

Или если это «состояние проекта»

  1. Версия 10: имеет функции A, B, C и D

  2. Версия 10.1: содержит улучшения для A. Исправляет ошибку 1049 в B. Добавляет новую функцию E.

Дойная корова
источник
2

технические характеристики являются инструкциями. напишите их в настоящем времени. так.

Стивен А. Лоу
источник
1

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

Дэн Стивенс
источник