Рассмотрим, как может выглядеть работа по созданию ТЗ на несложную программу.
Возьмём калькулятор, который будет выполнять базовые арифметические операции (+, -, *, /).
Работу можно построить в 2 этапа:
Поиск позитивных фактов о том, что именно мы хотим от калькулятора;
Поиск негативных фактов, что может пойти не так (в широком смысле слова) при работе как с программой, так и с ТЗ — и формулирование требований, им препятствующим.
Используя наше понимание предметной области, можно сформулировать такие позитивные факты:
Калькулятор должен выполнять арифметические операции.
По большому счёту, позитивные факты на этом кончаются, так как дальше почти все относится к сфере «очевидно, что… — да? а мне не совсем очевидно».
Уровень сложности: I'm too young to die
Что может пойти не так:
Как насчёт тетрации?
Подстрахуемся и проверим, что правильно понимаем себе количество арифметических операций. Ан нет, их не 4 штуки, а минимум 10. Суперкорень нам вряд ли завтра пригодится, да и логарифм с простыми корнями, если мы про простую программу, тоже. Так что давайте явно укажем, о каких 4-х операциях речь:
Калькулятор должен выполнять 4 базовые арифметические операции: сложение, вычитание, умножение, деление.
(с точки зрения классики инженерии требований тут 4 требования в одном, но на данном этапе это не так важно)
Мы не указали интерфейс пользователя
Как мы понимаем сейчас, интерфейс вполне может быть как минимум голосовым, если не тактильным по Брайлю.
Поскольку мы пишем ТЗ на простую (и для разработки, и для пользователя) программу, то выберем именно графический интерфейс.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
Сколько будет MCMXII + VII?
Далее, если копнуть чуть глубже — римские цифры по-своему хороши, но нам точно будет проще с привычными.
Калькулятор должен оперировать в пользовательском интерфейсе арабскими цифрами.
Направление чтения чисел
Как ни странно, но в современном мире есть люди, которые читают слова не только слева направо, но и в других направлениях. Числа обычно читают слева направо, но поскольку затевать этнографическое исследование по каждому вопросу мы не готовы, лучше подстраховаться:
Калькулятор должен оперировать в пользовательском интерфейсе числами, которые читаются слева направо.
Польская нотация
Те, кто учился на программиста, могут знать, что есть разные формы записей арифметических и логических выражений, и привычная нам школьно-вузовская математическая инфиксная форма не единственная.
Калькулятор должен позволять вводить и обрабатывать арифметические выражения в инфиксной записи.
So far, so good
Что у нас пока получилось:
Калькулятор должен выполнять 4 базовые арифметические операции: сложение, вычитание, умножение, деление.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
Калькулятор должен оперировать в графическом пользовательском интерфейсе арабскими числами.
Калькулятор должен оперировать в графическом пользовательском интерфейсе числами, которые читаются слева направо.
Калькулятор должен позволять вводить и обрабатывать арифметические выражения в инфиксной записи.
Классифицируйте это немедленно
У любого хоть немного системного — … аналитика, … программиста или … администратора наверняка возникнет желание классифицировать этот перечень для удобства анализа и работы с ним. Как минимум мы чётко видим подмножество требований про пользовательский интерфейс:
Функциональные требования
Калькулятор должен выполнять 4 базовые арифметические операции: сложение, вычитание, умножение, деление.
Требования к интерфейсам
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
Калькулятор должен оперировать в пользовательском интерфейсе арабскими числами.
Калькулятор должен оперировать в пользовательском интерфейсе числами, которые читаются слева направо.
Калькулятор должен позволять вводить и обрабатывать арифметические выражения в инфиксной записи.
Хм, последнее требование содержит в себе и функции тоже, что вроде как делает его и функциональным требованием, так и требованием к интерфейсу. И это называется ТЗ на простую программу? Запутались в 3-х соснах, то бишь в 5 требованиях — захотели упростить себе дальнейшую жизнь классификацией, но стало только хуже — ну, типичное горе от ума! :)
Ладно, давайте вернёмся на классический вид структуры, который мы проскочили — иерархический, в духе функциональной декомпозиции. В нём можно под каждую функцию запихнуть как функциональное подтребование, так и любое другое. Любое другое можно для удобства и обобщения назвать «ограничение» (constraint), т.к. они только и делают, что ограничивают поведение функции и ничего более!
Заодно можно поправить порядок записи требований на более хронологический, похожий на сеанс работы с программой, если не её тестирование:
Калькулятор должен позволять вводить арифметические выражения.
> Калькулятор должен позволять вводить арифметические выражения в инфиксной записи.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
> Калькулятор должен оперировать в пользовательском интерфейсе арабскими числами.
> Калькулятор должен оперировать в пользовательском интерфейсе числами, которые читаются слева направо.
Калькулятор должен выполнять 4 базовые арифметические операции: сложение, вычитание, умножение, деление.
> Калькулятор должен выполнять арифметические выражения в инфиксной записи.
Про инфиксную запись получилось 2 раза, что опять-таки не комильфо с точки зрения DRY, внесения изменений в программу, модульности и проч. Но тут уж как обычно с архитектурой (в нашем случае, со структурой требований) — приходится идти на компромиссы, т.к. не существует форм, одинаково подходящих для всего. Ну, и как ни странно, вводить выражения действительно можно в одном виде, хранить в другом, а выполнять в третьем — это было бы глупо, но технически возможно.
А вот это уже сценарий!
Поскольку у нас получился практически сценарий, а не просто иерархия, уже можно проверить его на замкнутость-полноту — позволит ли такой набор операций, выраженный функциями, получать нужный нам результат?
Как будто бы да, но человек со взглядом тестировщика легко подскажет, что позволять вводить, демонстрировать вводимое и вычислять результаты операций — это ещё не значит показывать результаты вычислений!
Поэтому давайте добавим последнюю явную функцию:
Калькулятор должен показывать результаты вычисления арифметических операций.
Отдельно заметим, как у нас тут плавает лексика. То мы пишем книжное «демонстрировать», то переходим на более неформальное «показывать». То «выполнять арифметические выражения» (м, а так можно вообще? выполняют вроде команды и запросы, а выражения, наверное, можно только обрабатывать), то «вычисления». В ходе разработки ТЗ такое полностью допустимо, т.к. мы хотим выражать смысл кратко, ясно и однозначно и для этого ищем и пробуем разные слова. Но при финализации требований будет полезно утрясти словарь и сделать его более однородным.
Фактически у нас получился типичный минимальный прото-юскейс из 4-х шагов:
Программа предоставляет возможности ввода исходных данных и выдачи команды
Пользователь вводит исходные данные и даёт команду
Программа выполняет запрошенную команду над данными
Программа сообщает пользователю результат выполнения команды
А интерфейс ввода?
Так, кажется мы что-то забыли. Пользователький графический интерфейс показывает цифры и операции, это ок. Но ведь для ввода чисел и команд тоже нужен интерфейс. И тоже не голосовой, но есть как минимум 2 варианта:
Клавиатурный ввод
Ввод мышью….
Можно затребовать оба интерфейса сразу, по крайней мере такой вариант мы видим в типичном десктопном калькуляторе. Стоп, а почему мы решили, что у нас десктоп, а не мобилка? Неужели для простейшей программы надо учитывать контекст применения? Получается, да. Или нет?
Калькулятор должен позволять вводить арифметические выражения посредством графического интерфейса.
Можно ли 7 шапок?
И вот так из вопроса про интерфейс ввода мы возвращаемся к более общему вопросу — а для какой категории устройств нужен калькулятор? И кстати, что насчёт планшетов? (Слона-то мы и не заметили)
Кажется, тут можно схитрить и потребовать, чтобы программа была кроссплатформенной и адаптивной. Фух, гора с плеч…
Но стоп, постойте, на каких именно категориях устройств разработчик будет демонстрировать и сдавать программу? У Андроид-устройств, например, есть множество версий устройств, да ещё на разных поколениях ОС.
Если требовать абстрактной кроссплатформенности и адаптивности, то нельзя сказать, что мы делаем простую программу, т.к. в общем случае добиться таких качеств без ограничений на версии устройств и операционных систем нельзя.
Поэтому приходится оговаривать конкретные подклассы устройств и операционных систем. Если мы хотим простоты для разработчика и пользователя, разумно выбирать наиболее популярные конфигурации устройств на рынке.
Учитывая, что у настольного компьютера практически всегда минимум 2 интерфейса ввода (клавиатура и мышь), а на смартфоне всё-таки доминирует тачскрин, решаем делать программу именно для смартфона.
Итого, можно взять самое популярное устройство по итогам продаж за последний год в нашем регионе, например, Redmi 9A (32 ГБ).
Как будет выглядеть требование-ограничение для этого случая:
Калькулятор должен работать на устройствах Redmi 9A (32 Гб).
Шеф, всё сломалось
Вещи ломаются, софт тоже может сломаться или не сработать. Ожидать 100%-ной надёжности не приходится, важно выбрать какой-то разумный компромисс. В общем случае полезно делать надёжность, соответствующей ожиданиям пользователей. В случае сложной и дорогой программы стоит изучить показатели конкурентов и сделать расчёты стоимости отказа для пользователей и бизнеса.
В нашем же случае хватит простой прикидки — в скольки случаев из 100 программа может позволить себе сбой? У нас нет никакой дополнительной информации о контексте использования, поэтому можно заложить 1-2 сбоя на 100 команд.
Калькулятор должен выполнять вычисления над выражениями с надёжностью не меньше, чем 98%.
Поговорим о габаритах…
В физическом мире габариты и форм-фактор продукта, устройства сильно влияют на его потребительские качества.
В цифровом мире аналогом габаритов можно с некоторой натяжкой считать размер программы в памяти и на диске.
Представьте себе, что наша программа при скачивании весит 1 Гб. Допустимо ли такое? Вряд ли.
Тут можно опираться на benchmarking, т.е. измерение характеристик типичных программ такого класса на рынке. Или учитывать, в какой стране, с каким интернетом и на каких телефонах она будет применяться.
Однако например у Google Play есть собственные рекомендации и ограничения, которые можно напрямую использовать:
Калькулятор должен поставляться в виде дистрибутива размером не более 200 Мб.
… и эффективности
Следующий вопрос — нормально ли, что программа занимает 2 Гб оперативной памяти в телефоне в ходе применения? Для нашей программки тоже выглядит чересчур.
Если поискать информацию о лучших практиках, можно выйти на рекомендации, чтобы программа занимала в памяти не более 50 Мб. На этом и остановимся:
Калькулятор должен использовать не более 50 Мб оперативной памяти телефона.
Не тормози!
Рассмотрим ещё один не совсем очевидный, но вполне возможный случай негативного события — представим, что вводим в калькулятор 2 + 2 и калькулятор думает 14 часов. Ну или хотя бы 7 минут. Ладно, пусть будет 15 секунд. Что вы скажете о таком калькуляторе? Нужно ограничить это безумие!
И в вопросах скорости вычислений нам на помощь может прийти не только вездесущий бенчмаркинг, но и когнитивные эвристики Якоба Нильсена — например, про то, что реакция менее 0,1 секунды воспринимается большинством людей как мгновенная. Ну что же, так и запишем:
Калькулятор должен проводить вычисление арифметического выражения не более чем за 0,1 секунду.
Сколько вешать в граммах?
Если вернуться к вопросу вычислений, то можно вспомнить, что они проводятся с определённой точностью, не всегда абсолютной.
Опять-таки ищем лучшие практики для бытовых калькуляторов и выходим на уровень:
Калькулятор должен производить вычисления с точностью не хуже 8 знаков после запятой.
Знак бесконечности
С другой стороны, можно пытаться оперировать в вычислениях очень большими или очень маленькими числами. Сделать универсальное устройство не очень просто и скорей всего не нужно. Надо выбрать разумный диапазон пределов расчётов.
Поиск говорит, что типичный диапазон большинства бытовых калькуляторов составляет от 10^-99 до 10^99, однако для ввода чисел со степенью нужна возможность указывать степень отдельной командой, чего для простого калькулятора хочется избежать.
Кроме того, тут мы возвращаемся к вопросу про интерфейс — а сколько цифр мы хотим одновременно видеть на экране? У обычного карманного калькулятора 8-10 цифр на экране. Тогда можно ограничиться диапазоном в 10 цифр — т.е. 10 млрд как максимальное число. Но этого не хватит даже, чтобы показать годовой бюджет России (18 трлн в 2024-м году).
Однако программный калькулятор отличается от физического тем, что он может управлять размером отображаемых чисел и вообще делать перенос строк. После некоторых экспериментов можно установить, что достаточно читаемыми могут быть числа, представленные в виде 5 строк по x 3 разряда x 7 троек нулей, те ~= 100 разрядов.
Таким образом, можно вернуться к диапазону типового калькулятора парой абзацев выше:
Калькулятор должен производить вычисления с числами от 10^-99 до 10^99.
Наши пальчики устали
Так, что у нас ещё осталось, какие риски, что может пойти не так?
Представим, что мы вводим выражение в виде длинной цепочки с большим количеством различных операций. Какое количество операций имеет смысл поддерживать?
Для компьютерной программы можно сказать, что всё равно — пока человек не устал вводить цифры и знаки, программа всё может обработать. Но значит ли это, что длина выражения может быть бесконечной? С практической точки зрения смысла в этом мало, поэтому и тут стоит договориться о точке, когда ваша программа наконец скажет ERROR….
Ой, кстати, а что насчёт ошибок, которые не являются сбоем? Например, деление на 0? Надо же как-то реагировать на это:
Калькулятор должен сообщать о невозможности выполнить операцию, если она математически невозможна.
Вот так добавление одной только операции «разделить» нам усложняет поведение программы.
Ну и заодно давайте опишем, что же делать со сбоями:
Калькулятор должен сообщать о сбое в ходе выполнения операции.
И так до самого конца сплошные черепахи
Я предполагаю, что прочитав до этого места, вы как минимум ужаснулись количеству вещей и аспектов, о которых стоит подумать при создании, казалось бы, простейшего программного калькулятора. И это мы ещё не касались вопросов:
— графического дизайна,
— какие кнопки будут у калькулятора, кроме цифровых и операций,
— скорости реакции калькулятора на нажатие кнопок :)
Хорошая новость в том, что в больших программах этих аспектов больше (например + информационная безопасность), но ненамного. Плюс о некоторых аспектах, которые я называю макро-ограничениями, нужно подумать и разобраться один раз на всю программу (ок — на подсистему, сервис, микросервис), а не для каждой её функции заново.
Кроме того, по мере накопления опыта вы можете сами себе сделать «калькуляторы» различных перечисленных выше характеристик программы, т.к. математика таких расчётов такая же элементарная, как и у нашего калькулятора тут.
Смотрим итоговую сборку требований
Давайте соберём и посмотрим, что же у нас в итоге получилось:
Функции и их микро-ограничения
Калькулятор должен позволять вводить арифметические выражения.
Калькулятор должен позволять вводить арифметические выражения посредством графического интерфейса.
Калькулятор должен позволять вводить арифметические выражения в инфиксной записи.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
Калькулятор должен оперировать в пользовательском интерфейсе арабскими числами.
Калькулятор должен оперировать в пользовательском интерфейсе числами, которые читаются слева направо.
Калькулятор должен выполнять 4 базовые арифметические операции: сложение, вычитание, умножение, деление.
Калькулятор должен выполнять арифметические выражения в инфиксной записи.
Калькулятор должен показывать результаты вычисления арифметических операций.
Калькулятор должен сообщать о невозможности выполнить операцию, если она математически невозможна.
Калькулятор должен сообщать о сбое в ходе выполнения операции.
Макро-ограничения
Совместимость
Калькулятор должен работать на устройствах Redmi 9A (32 Гб).
Надёжность
Калькулятор должен выполнять вычисления над выражениями с надёжностью не меньше, чем 98%.
Эффективность
Калькулятор должен поставляться в виде дистрибутива размером не более 200 Мб.
Калькулятор должен использовать не более 50 Мб оперативной памяти телефона.
Производительность
Калькулятор должен проводить вычисление выражения не более чем за 0,1 секунду.
Точность
Калькулятор должен производить вычисления с точностью не хуже 8 знаков после запятой.
Границы вычислений
Калькулятор должен производить вычисления с числами от 10^-99 до 10^99.
Какие ещё дыры вы видите в такой спецификации требований? :)
За картинки спасибо нейрохудожнику Алине Богачёвой.
Комментарии (83)
rukhi7
29.09.2024 07:56Какие ещё дыры вы видите в такой спецификации требований? :)
у меня противоричивые чуства: с одной стороны к выводу о том что написать калькулятор на четыре действия невозможно, можно прийти гораздо быстрее,
с другой стороны кто-то может всетаки попытаться начать действительно что-то делать в направлении решения задачи, поскольку в требованиях не достаточно маразма.
GospodinKolhoznik
29.09.2024 07:56С чего это вдруг калькулятор стал простой программой? Арифметические действия изучаются в школе на протяжении 4 лет! Никак нельзя назвать простым то, что выполняет действия, на освоение которых надо потратить аж 4 года.
OlegZH
29.09.2024 07:56Рассмотрим, как может выглядеть работа по созданию ТЗ на несложную программу.
О_о! Очень хорошее начинание! Чрезвычайно интересно посмотреть, можно ли раскрутить эту тему до конца. Будет ли этот конец достигнут. За какие сроки. И т. д. И т. п.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
А почему не рассматривается такая возможность, как реализация некоторого внутреннего для ОС компонента и организации соответствующего пользовательского интерфейса?
Калькулятор должен уметь считать. Это суть главное. У него на входе — строка (содержащая набор операций над числами) и на выходе — строка (содержащая результат выполнения операций). То есть, калькулятор — это компонент, который производит преобразование одних строк в другие. (Понятно дело, что мы говорим пока только об обыкновенных численных калькуляторах. В принципе, много чего можно интерпретировать, как калькулятор.) И это должен быть некий компонент без какой-либо привязки к пользовательскому интерфейсу. Другое дело, что пользователю этот самый пользовательский интерфейс очень нужен. Это всё надо понимать и отдавать себе отчёт в том, что, смешение двух различных сущностей в рамках одного приложения породит постоянно действующие проблемы в реализации.
Таким образом, первейший вопрос создания калькулятора — это вопрос о том, что именно делается: приложение или компонент. Понятное дело, что создаётся и то, и другое. Но ТЗ на приложение и ТЗ на компонент будут, очевидно, различаться.
beskov Автор
29.09.2024 07:56написать компонент ОС — это задача для условно системных программистов, а не прикладных
она встречается гораздо реже и у неё своя специфика
частным случаям — частные решения
unbalanced
29.09.2024 07:56+4Итак, это воскресенье и это время пофлудить, потому что никто не читает воскресный хабр.
Во-первых, не дыры, а отверстия.
Я все листал и все ждал, что в какой-то момент автор напишет - "видите, если все делать задом наперед - то будет трэш и угар, давайте уже сделаем передом назад". Но так и не дождался. В конце я увидел только "Микро-ограничения функций" и "Макро-ограничения". Предполагаю, что в данном случае "ограничения среднего размера" не понадобились. И я ведь так весь день ерничать могу.
Все описанное ниже - строго на основании текста статьи ТОЛЬКО.
Автор говорит как бы правильно, но потому что он старается и вертит головой во все стороны, чтоб не упустить ничего. А не потому, что он знает, что делает. И это не ремесло получается, а искусство, а так жыть нельзя. И автору об этом в первом же комменте указали кстати.
Передом назад - это вот так, как я дальше пишу.
АБСОЛЮТНО ЛЮБАЯ система - это костыль, который помогает сделать что-то. И если не понять, чему этот костыль помогает, то его все еще можно имплементировать. Просто им не будут пользоваться, потому что "а зачем мне эта штука"? А если понять, зачем он делается, то вот мы и получили бизнес-требования (ака БТ) - ответы на вопросы "что", "зачем" и "сколько". И только из них становится ясно, кто по итогу будет пользоваться этим костылем. И узнать у этих людей (порой (но очень редко) это будут не люди, кстати) случаи, в которых этот костыль поможет - и зафиксировать их. В б-гомерзких сторях или в православных юз-кейсах или еще как-то. И назвать их "пользовательские требования" (ПТ). И они всегда и это вообще неочевидно - следствие БП. И только поняв, сценарии юзания этого костыля (это все те же ПТ) - писать уже крнкретно требования к способу воплощения костыля в жизнь так, чтоб он под эти сценарии по итогу подпал. И это называется "требования к решению" (ТР). И они - прямое следствие ПЕ, которые сами - следствие БТ. А ТР могут быть про то, а) что костыль должен уметь (функциональные требования, ФТ) и б) как он должен это уметь (нефункциональные требования, НФТ). ФТ + НФТ = ТР.
Т.е., в сути своей предыдущий абзац звучит так:
БТ -> ПТ -> ТР. И это без шуток часто открытие для юниоров и неосведомленных
ТР = ФТ + НФТ. Это, в принципе, минимальный набор, формирующий ТЗ. Но это ТЗ без возможости доработки. Потому что доработка потребует ПТ, а их тут нет, как видно. И вот так - правильно. И этот подход всегда один и тот же. И это именно то самое ремесленничество. Новый проект? Пришел на дискавери, вызнал БТ, сформировал пул будущих юзеров, узнал у них ПТ, сочинил ФТ. Потом у всех поспрашивал и сформировал НФТ. Конец. Все всегда одинаково.
Ну и с высоты сказанного, о чем написал автор. По всему тексту размазаны ПТ, причем пользователь - это автор ("Суперкорень нам вряд ли завтра пригодится", "Как мы понимаем сейчас, интерфейс вполне может быть как минимум голосовым, если не тактильным по Брайлю" и т.п.) и НФТ, и у них то как раз нормальный источник - все подряд ("Калькулятор должен работать на устройствах Redmi 9A (32 Гб)", "Калькулятор должен выполнять вычисления над выражениями с надёжностью не меньше, чем 98%", "у Google Play есть собственные рекомендации и ограничения"). А в резюмирующей главе - ФТ (это которые функции с микро-ограничениями) и НФТ (которые макроограничения). БТ в статье нет. По итогу автор выдал-таки ТЗ, но потому что старался, а не потому знал как надо.
И я бы написал, почему автор тут ни в чем не виноват, но этот коммент и так уже больше страницы высотой. Но если кто захочет - говорите, напишу)
beskov Автор
29.09.2024 07:56+1По итогу автор выдал-таки ТЗ, но потому что старался, а не потому знал как надо.
Обожаю догадки. Я практикую разработку требований с 2004-го года, применяю сценарии использования с 2006-го, подход с разделением бизнес-требований, пользовательских требований и требования к ПО где-то с того же года. С 2013 года мы с коллегами обучили пару тысяч человек такому подходу.
Кмк статья хорошо показывает ограниченность подхода к разработке требований как к заполнению шаблона SRS, как любят делать в некоторых госпроектах и ее только.
unbalanced
29.09.2024 07:56+1Обожаю догадки.
Рад, что сумел доставить Вам удовольствие)
Только небольшой вопросик. После двух тысяч людей, которым Вы лично рассказали про разработку требований в целом, плюс бизнес- и пользовательские требования в частности, Вы пишете явно обучающую (ну или хотя бы показывающую пример) статью, в которой эти требования не упоминаются, зато есть "микро-ограничения функций". Какого эффекта должна была достичь эта статья?
beskov Автор
29.09.2024 07:56не рассказали, а научили. не надо подменять обучение получением знаний.
повторюсь, показать ограниченность подхода к разработке требований, как заполнению шаблона ТЗ
unbalanced
29.09.2024 07:56+3Ок, приношу глубочайшие извинения
Я писал длинный коммент, но решил написать покороче. Ваша статья не про то, что писать ТЗ по шаблону - неудобно (ограниченно). Вы про шаблон там вообще не пишите. Ваша статья про то, как Вы прорабатываете требования к каким-то аспектам несложной системы, взятым из воздуха. И именно к взятию из воздуха у меня и претензии. Особенно к человеку, который "не рассказал, а обучил" 2 тыщи людей бизнес-требованиям и всему такому. Но если Вы считаете, что так - верно, то ок, это Ваше право)
beskov Автор
29.09.2024 07:56да, моя статья про то, как можно доставать требования из воздуха и к чему это приводит
и да, первая реакция на такие размышления у новичков будет — дайте шаблон
OlegZH
29.09.2024 07:56Но если кто захочет - говорите, напишу
Пишите обязательно. Я то же буду думать над ТЗ. Надо добить хотя бы один рабочий пример до конца. Если, конечно, это возможно.
OlegZH
29.09.2024 07:56Фактически у нас получился типичный минимальный прото-юскейс из 4-х шагов:
Программа предоставляет возможности ввода исходных данных и выдачи команды
Пользователь вводит исходные данные и даёт команду
Программа выполняет запрошенную команду над данными
Программа сообщает пользователю результат выполнения команды
Любопытно, что, при таком неожиданном обобщении, мы получили описание, под которое подпадает практически любое приложение.
Например, я захожу и интернет-магазин, выбираю нужные мне товары и нажимаю кнопочку "Заказать", а программа на выходе сообщила мне (на выбор из трёх вариантов):
Заказ оформлен и оплачен.
Заказ не может быть оформлен, потому что кончились такие-то товары.
Заказ не был оплачен, потому что на Вашей карте не имеется достаточно средств.
OlegZH
29.09.2024 07:56Можно затребовать оба интерфейса сразу, по крайней мере такой вариант мы видим в типичном десктопном калькуляторе. Стоп, а почему мы решили, что у нас десктоп, а не мобилка? Неужели для простейшей программы надо учитывать контекст применения? Получается, да. Или нет?
Если мы создаём приложение, то нас, конечно, будут волновать эти вопросы. Но, если мы создаём компонент Калькулятор, то мы должны описать некий протокол, в соответствии с которым на вход будут поступать одни команды (Вы же должны понимать, что сами числа — это один тип команд, а, собственно, команды для операций — это другие команды), а на выходе формируются другие.
(Здесь, о сути, происходит разделение на front-end и back-end.)
А уже другие разработчики, руководствуясь Вашим протоколом будут отдельно делать конечное приложение для каждой платформы.
vadimr
29.09.2024 07:56+2Я бы поспорил с тем, что ваш калькулятор позволяет ВВОДИТЬ АРИФМЕТИЧЕСКИЕ ВЫРАЖЕНИЯ. Он вводит отдельные числа и операции, а с такой сущностью, как арифметическое выражение, вообще не работает. Программа не соответствует ТЗ.
beskov Автор
29.09.2024 07:56в литературе по программированию такие конструкции называются арифметическими выражениями
https://dit.isuct.ru/IVT/sitanov/Literatura/InformLes/Pages/Glava7_3_1.htm
https://devmark.ru/article/java-calculator-example
в статье не указана «библиотека», пространство понятий, из которой используются термины:
а) прикладная предметная область — арифметика или
б) область предмета разработки — разработка компьютерных программvadimr
29.09.2024 07:56+1Не понял, к чему ваши ссылки. Я знаю, что такое арифметические выражения, но в вашем калькуляторе с кнопками они не вводятся. У вас нет никакого оператора ввода, который читал бы значение " 20 * (10 - 5) " , как в вашей статье. И арифметическое выражение (общего вида, а не частный случай выражения, представляющий одно число) вообще не представляется в вашей программе ни в какой момент.
Я бы не принял такую программу, как на иллюстрациях в вашей статье, на соответствие такому требованию. Программу на джаве, на которую вы ссылаетесь выше, принял бы, а эту - нет.
beskov Автор
29.09.2024 07:56иллюстрации уже совсем шуточные, о чём вы?
и да, частный случай арифметического выражения — это тоже арифметическое выражение
vadimr
29.09.2024 07:56Ну в ваших требованиях нет других указаний на общий интерфейс калькулятора, приходится ориентироваться на иллюстрации и намёки.
и да, частный случай арифметического выражения — это тоже арифметическое выражение
Давайте тогда, может, только ноль вводить? Как частный случай выражения.
OlegZH
29.09.2024 07:56Так и вводят. Есть ещё форма Бэкуса-Науэра для описания грамматики всего этого дела.
OlegZH
29.09.2024 07:56Калькулятор должен производить вычисления с точностью не хуже 8 знаков после запятой.
Следует напомнить, что у каждого вида вычислений своя точность. Чтобы обеспечить определённую точность результата, нужно требовать соответствующую точность у операндов. Не всегда точность можно гарантировать. Не всегда высокая точность имеет смысл.
OlegZH
29.09.2024 07:56Калькулятор должен производить вычисления с числами от 10^-99 до 10^99.
Не думаю, что выбор некоторого фиксированного предела на все случаи жизни полезен. Всё-таки, калькулятор используется в конкретных обстоятельствах. Иногда нужно включать и "научный режим". (Конечно, если у пользователя есть GPU, то можно будет просто здорово извернуться.)))
vadimr
29.09.2024 07:56Не очень понятно, зачем в программе размером целых 50 мегабайт вообще ограничивать диапазон чисел.
OlegZH
29.09.2024 07:56А мне не понятно, почему, вообще, здесь возникает вопрос о размере программы? 50 Мб — это что, исполняемый файл? Можно в Кб засунуть. Диапазон чисел определяется задачей. А про задачи у Вас ничего не сказано.
Разные задачи — разные калькуляторы — разные ТЗ.
Как-то так. ;-)
vadimr
29.09.2024 07:56Размер программы – это объективное техническое требование, из которого растёт всё остальное. Форма классического настольного калькулятора, бездумно копируемая многими современными поделиями, продиктована техническими возможностями 4-разрядного микропроцессора с десятком ячеек паряти. Никакого иного объективного основания она не имеет.
Современная молодёжь уже никогда не видела железного калькулятора. Пора уж опомниться, зачем рисовать 20 кнопок и жамкать на них мышкой?!
OlegZH
29.09.2024 07:56Размер программы – это объективное техническое требование, из которого растёт всё остальное.
Вот это я никак не могу понять. Размер программы определяется исключительно реализацией. Какие библиотеки, какие алгоритмы.
Пора уж опомниться, зачем рисовать 20 кнопок и жамкать на них мышкой?!
Вообще-то, ещё бывают и обыкновенные настольные компьютеры, а у ноутбуков может не быть отдельной цифровой клавиатуры. Иногда можно и "жамкнуть". Всё-равно, в ОС должен быть калькулятор. Вот и вопрос в том, как его делать.
vadimr
29.09.2024 07:56Непредвзятому человеку понятно, что вот так:
2+2*sin(0.5)/3 =2,32
Между прочим, это работает даже в поле ввода хабра. Хотя насчёт разрядности я бы тут поспорил.
OlegZH
29.09.2024 07:56А причём здесь размер программы?
vadimr
29.09.2024 07:56Потому что в 1970 году такой калькулятор было не сделать из-за размера его программы, и исключительно по этой причине мы должны сейчас смотреть на нарисованные на экране кнопки.
a3aquB
29.09.2024 07:56на чем основано ваше предположение? есть ссылки на исследования?
vadimr
29.09.2024 07:56Предположение о чём? О том, что в 1970 году в калькуляторах были маленькие программы, или о том, что современные калькуляторы воспроизводят старые? Это общеизвестные факты.
a3aquB
29.09.2024 07:56О том, что дело именно в воспроизведении. С таким же успехом можно утверждать, что колеса круглые, потому что люди увидели луну и по её подобию создали.
Почему, например, дело не в наиболее удобном формате для большинства пользователей.
vadimr
29.09.2024 07:56Наиболее удобный формат для большинства пользователей придумали за много сотен лет до калькулятора, это собственно запись арифметических выражений на бумаге. И он продолжает использоваться, не имея никакой тенденции к вытеснению интерфейсом калькулятора, а вот обратная тенденция есть.
OlegZH
29.09.2024 07:56А вот это уже довольно интересно. То самое, недостающее замечание. Спасибо. Можно будет от этого хорошо оттолкнуться.
codecity
29.09.2024 07:56Когда есть готовое изделие - Т.З. написать не составляет труда. В случае с калькулятором уже есть от Google или MS и еще 100500 разных. Так и говорите - должно быть как то, только вместо А сделайте Б... И указываете разницу что должно быть иначе.
Намного сложнее если вы задумали сделать не клон чего-либо (с небольшими изменениями), а совершенно новый продукт, который нельзя открыть в готовом виде и потыкать.
beskov Автор
29.09.2024 07:56как видно из статьи, даже у простой программы есть множество аспектов, которые можно учитывать
чтобы делать требования по аналогии, надо уметь исследовать поведение объекта и иметь кругозор как в предметной области, так и в ПО
например представим, что разработчик написал такой калькулятор, который при каждом запросе операции ходит в интернет за каким-то API
и программа ведёт себя формально аналогично уже существующим, чтобы проверить, что это не так, надо догадаться отключать интернет
или допустим новая программа зачем-то кэширует в памяти результаты вычислений в не самом компактном формате
и когда вы её гоняете на одних и тех же примерах и потом отключаете интернет, она формально его не требует и проходит тесты
или например исходный код программы окажется написан вашим разработчиком на языках brainfuck, whitespace, visual prolog с последующей трансляцией в технический не читаемый kotlin
или вообще калькулятор сделан на no code платформе типа adalo
или с фрагментами ворованного нелицензированного кода
codecity
29.09.2024 07:56например представим, что разработчик написал такой калькулятор, который при каждом запросе операции ходит в интернет за каким-то API
Чтобы такого не было, достаточно чтобы человек был просто адекватен. В здравом уме такого никто делать не будет.
Боюсь, что если чел. не адекватен, то все-равно придумает как сделать глупость при любом детально описанном т.з. и формально будет прав.
OlegZH
29.09.2024 07:56А мы-то думаем, зачем софтверным гигантам такие мощные дата-центры? Может быть, там тщательно затабулированы таблицы Брадиса и статистические таблицы Большева (Большев Л.Н., Смирнов Н.В, "Таблицы математической статистики")? Тогда понятно, зачем программа будет ходить в интенет. ;-)
beskov Автор
29.09.2024 07:56+1адекватность — это математический термин, означающий «соответствующий». соответствующий чему? вы скорей всего используете его как эвфемизм-замену слову «нормальный»
мне интересно разбирать тему правильной постановки задачи, которая содержит как целевое поведение, так и ограничивает нецелевое.
иначе можно в вашей логике опустить бОльшую часть требований, сославшись на «нормального» разработчика. но понятие нормальности и не определено и сложно проверяемо и тест существенно сокращает количество потенциальных разработчиков и тд
VladD-exrabbit
29.09.2024 07:56+1Из требований, которые неплохо было бы уточнить: раз нам позволяется вводить выражения большой длины, то нужно установить приоритет операций (2 + 2 × 2 — это 6 или 8?), а также, очевидно, разрешить скобочные выражения.
Также следует определить реакцию на синтаксические ошибки (как интерпретировать ввод "1 + ="?). Со скобками количество различных синтаксических ошибок увеличивается.
Далее, у нас есть возможность переполнения рабочего диапазона даже при вводе, ну и при сложении тоже, как её обрабатывать? А что если при промежуточных вычислениях случается переполнение рабчего диапазона, но ответ может быть вычислен всё равно? (MAX + 1 − 1)
Далее, десятичные разделители и разделители тысяч, нужны? Должны ли зависеть от локали? И что такое локаль — системный язык или задаётся юзером в настройках?
Требования можно улучшать до бесконечности.
beskov Автор
29.09.2024 07:56а в какой-то культуре приоритет операций другой? интересно
скобочные выражения я вводить не стал, интересна аргументация за них
переполнения рабочего диапазона чего? в статье таких слов нет
да, про разделители я писал выше
до бесконечности не надо же
я предлагаю ещё подумать про исходный код и его устройство
VladD-exrabbit
29.09.2024 07:56+2Нет, зависимость не от культуры. Встроенный калькулятор Windows, например, в ранних версиях вычислял выражения сразу при вводе. В результате 2 + 2 × 2 вычислялось так: 2 + 2 даёт сразу 4, пользователь дописывал × 2 и получал 8. Так работали многие старые, «железные» калькуляторы. Более свежие версии учитывают приоритет операций, и откладывают вычисление и показ промежуточного результата до момента, когда этот промежуточный результат более не сможет измениться дальнейшим вводом пользователя.
По поводу скобок, если вы вводите длинное выражение (например, 1 + 2 / 3 + 4), скобки были бы полезны для случая, если вам на самом деле надо (1 + 2) / (3 + 4).
Под рабочим диапазоном я понимаю диапазон [−10⁹⁹, 10⁹⁹], как указано в статье.
AbitLogic
29.09.2024 07:56+1Посмотрев некоторые калькуляторы из store могу добавить
Калькулятор не должен собирать статистику и иную информацию о пользователе)))
Ну хотя бы без его ведома...
Roshalsky
29.09.2024 07:56+2"Арабские числа"... Например, 1054 - это число. На вашем калькуляторе будет любое возможное число, или только самые используемые? Где требования к набору чисел или я могу сам выбрать нужные? Арабских цифр всего 10, а записываемых ими чисел...
a3aquB
29.09.2024 07:56Денис, отличная статья! Показан пример, что даже для примитивной и давно известной программы в ТЗ нужно подумать о различных аспектах в различных направлениях.
Придирки к аудитории, БТ/ПТ интересны, конечно, но как будто оторваны от реальности. Мне подход с ТЗ кажется понятным и как учебный пример довольно хорошо показывает, что бы я отдавал разработчикам. Вряд ли токарь на заводе, вытачивая деталь, будет метаться в сомнениях насчет аудитории, для которой эта датель нужна. Знание могло бы быть ему полезно, но важнее размеры детали на чертеже. Другие люди зарнее об этом подумали, вероятно.
Рассуждения про интерфейс и кнопки из 1970х касаются лишь одного раздела из ТЗ и достаточно легко абстрагироваться, что в реальной задаче в этом разделе могли быть другие требования.
Статью добавляю в закладки на два случая:
Подскажи, как мне писать ТЗ разработчику, когда не знаю, с чего начать
Ой, что там писать, делать надо, по ходу разберемся...
Spelling
Самая большая дыра - это отсутствие описания целевой аудитории, которая будет использовать калькулятор. И в каких условиях они будут это делать. В результате половина требований может измениться, а половина быть нерелевантной. Возможно, что мы делаем калькулятор для детей, а может быть мы делаем калькулятор для прорабов на стройку. Я бы предпочла тут аджайл подход - можно сделать за минимальное количество человекодней прототип, проверить на фокус-группе, и вносить новые требования по результатам реальной обратной связи
beskov Автор
аудитория не является требованием к калькулятору)
Spelling
Без аудитории или хотя бы предполагаемой ценности это всё сферические требования в вакууме. Можно придумать ещё пару десятков. Только зачем?
beskov Автор
чтобы показать, как много аспектов есть у казалось бы простой программы, чтобы её можно было разрабатывать и сдавать
допустим, вы определились с аудиторией
вспомните ли вы обо всём том, что написано в статье?
вспомните ли про то, какой символ использовать для отделения дробной части от целой?
вспомните ли про то, какой символ использовать для разделения разрядов?
подумаете ли о том, как должен вести себя калькулятор при удержании пальца на кнопке?
Spelling
Тогда я бы назвала это не требованиями, а гипотезами.
"Мы предполагаем, что нашему пользователю важно явно различать целое число и дробь
Мы предполагаем, что пользователям нужно различать разряды чисел
и т.д."
Во время исследования гипотеза либо подтвердится, либо не подтвердится. Либо будут получены более значимые инсайты, на которые следует сделать акцент в дальнейшем проектировании
beskov Автор
я исхожу из контекста, что разработчику даётся задание на разработку через требования
если это не требование к поставке, а что-то другое — значит ли, что он может этого не делать?
Kahelman
Вообще-то то вы тут не правы, а предыдущий автор вполне прав.
Символ разделения дробной и целой части на калькуляторе не имеет значения. Как и символ разделения разрядов. Достояно не использовать для разделения разрядов . Или , и у вас нет проблем с в 99.9 случаев.
Даже если вы используете . И , то через 2 минуты пользования калькулятором пользователь поймёт что к чему.
Далее моя целевая аудитория - космонавты на МКС.
Соответственно 99% ваших требований летит в корзину так как они очевидны.
Более того, поскольку МКС - международная станция, вам прямой путь к скинию ISO норм по отображению цифр, разрядности системы
В ы в своих требованиях допустили ошибку/ у вас только 4 арифметических оператора. В то время как на обычном калькуляторе есть ещё операция смены знака (*-1) которая сильно упрощает расчеты.
Ещё одним вариантом постановки ТЗ на разработку калькулятора - вы делаете улучшенный аналог а не принципиально новое устройство, было бы привести ссылки на существующие образцы, сказать что сделано не так и что надо улучшить.
В результате пользы будет больше а бесполезного текста меньше.
Кроме того, если. Включить «дурочку» то под ваше ТЗ подходит калькулятор работающий в любой система счисления с основанием меньше или равным 10.
Так что не удивляйтесь, что когда ваш QA введёт пример 1+1 он получит 10 в качестве ответа.
beskov Автор
как говорил Джек Воробей — но вы про него слышали! в статье вообще нет упоминания про него. как представляются дробные числа — не указано
beskov Автор
Так если его не будет, это существенно увеличивает число человеческих ошибок при вводе чисел.
beskov Автор
я ниже постил скриншот моего дефолтного калькулятора на xiaomi — там такой операции нет
beskov Автор
в общеинженерном случае приведение аналога означает выдачу разработчику или аналитику чёрного ящика, который надо отдельно исследовать
например китайцы хорошо владеют реверс-инжинирингом, но это не значит, что определить по микросхеме, как она работает — это дёшево и быстро
beskov Автор
да, это хороший пример упущенного «очевидного» требования!
beskov Автор
я больше скажу — на самом деле для разработки требований к ПО нужно не просто уточнить контекст и аудиторию, а ещё спроектировать использование, а если точнее — спроектировать надсистему, а для этого например сначала разработать требования к человеку, который будет применять калькулятор — в каком процессе, для чего, с какими ограничениями
если вам просто сказать «строитель», у вас же автоматически требований к ПО не появится, тк вы в общем случае не знаете того, что описано выше
Spelling
Тогда об этом и стоило сказать в статье. Иначе неофиты посчитают, что так требования и должны разрабатываться: придумываться из собственной головы, без привязки к реальным людям и насущным потребностям. Тем более, что на вас равняются очень многие аналитики
beskov Автор
я пропустил момент, где я просил давать мне советы
методы, рекомендуемые к применению, я так и называю, а не «давайте попробуем написать какое-то ТЗ»
Spelling
В моей голове это не звучало как совет. Но видимо я не оценила как это читается со стороны. Приношу свои извинения за переход границы
vadimr
По госту это называется "область применения" и относится к основным требованиям.
beskov Автор
в ГОСТ 19.201-78 слова «область применения» упоминаются только в пункте
> 2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
раздел «Введение» сложно назвать основными требованиями, это что угодно, только не требования
vadimr
Вашими бы устами да мёд пить. Лично я видел множество случаев, когда приёмка программы заканчивалась отказом на разделе “Введение” или “Основания для разработки”.
А если подходить к вопросу более формально, то из “Области применения” в ТЗ во многом получаются разделы “Назначение программы” и “Условия применения” в Описании программы.
beskov Автор
мы же понимаем, что можно в назначении программы написать "вычислять арифметические выражения" и в условиях "температура от +5 до +30" и это нас никак не приблизит к настоящим сценариям применения и контексту
Daddy_Cool
Еще как является!
Помню у нас студент какой-то пожаловался, что у него калькулятор не возводит в степени (а нужны были дробные показатели) - преподаватель сказал ему, что ну... если у вас калькулятор для домохозяек, то сами виноваты.
WASD1
Так в том и дело, что требования бестолковы - не отражают сути того, что нужно.
Если "общего здравого смысла" нет - то они бесполезны.
Если же общий здравый смысл присутствует - то гораздо проще и полезнее избавиться от ТЗ и сразу писать "что нужно".
Именно поэтому эти недоформализмы и заменяются (где не приколочены законодательными гвоздями) - на "use case / user story", конкретные примеры.
beskov Автор
Расскажите пожалуйста, какая аудитория у встроенного калькулятора Андроида
beskov Автор
и какие конкретно требования вы определите исходя из этой аудитории
vadimr
Допустим, для меня это большая загадка (ну, про айфон), и в том числе именно поэтому я не пользуюсь встроенным калькулятором.
Ребята в Apple в 18-й версии iOS наконец, подумали над этим вопросом и реализовали нормальный калькулятор в Заметках, почти как это было в редакторе Слово и Дело 30 лет назад.
klimkinMD
И краткого анализа геополитического контекста!
Как-то было здесь обсуждение задачи, которую дали Фермана на устный счëт: тангенс гугола... Так в процессе обсуждения выяснилось, что разные программные (да и хардверные) калькуляторы дают разный результат...
И, конечно, кто-нибудь должен следить чтобы ТЗ не превратилось во фрактал!