У якому граматичному часі я повинен писати свої специфікації?

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

Однак я бореться з тим, якою напругою писати це:

З минулим часом, як ніби робота виконана, я намагаюся показати яскраві розширення виходу з роботи. Майбутнє напруження, як це потрібно зробити, X починає звучати як список справ або нейтральний напруга дуже важко, як це буде або буде зроблено, або зроблено.

Для додаткової плутанини цю специфікацію можуть прочитати люди, які не володіють англійською мовою як першою.

У нас цього багато в моєму останньому місці роботи.

Керівники продуктів вирішили використати даний час, щоб описати, що потрібно зробити , як-от:

Користувач надсилає замовлення. Система надсилає повідомлення про підтвердження.

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

Користувач вводить товар у кошик і вказує кількість.

Це викликало багато плутанини для мене, оскільки не ясно, що вже є і що ще належить. Я намагався змусити їх використовувати будь-який майбутній час, але вони ніколи не змінювалися. Особисто я не міг звикнути до цього протягом усіх своїх двох років там. Це просто не має сенсу, звучить так, ніби хтось не володіє мовними напрямками.

Тому:

• Використовуйте теперішній час для того, що вже існує

• Використовуйте майбутнє час для того, що треба зробити. Зайняти світи "повинен", "повинен", "буде".

Теперішній час мені здається гарним.

1. Передумова: Foo знаходиться в стані X
2. Операція: це і те трапляється
3. Післяумова: Foo знаходиться в стані Y

все це в теперішньому часі.

Або якщо це "стан проекту"

1. Версія 10: має функції A, B, C і D

2. Версія 10.1: містить вдосконалення A. Виправляє помилку 1049 у B. Додає нову функцію E.

Можливо, ви захочете дізнатися, яка практика написання RFC.

Це RFC 2119: Ключові слова для використання в RFC для вказівки рівнів вимог .

технічні характеристики - це інструкції. запишіть їх у теперішньому відмінку. подобається це.

Коли я створюю проекти для програмного забезпечення, я віддаю перевагу справжньому часу, навіть якщо я створюю проекти до того, як програмне забезпечення існує. Навіть після того, як програмне забезпечення застосовано до розробки, дизайн все ще є актуальним і важливим документом. Цілком можливо, що проектний документ може залишатися актуальним довший час після впровадження програмного забезпечення, ніж до його впровадження.