Комментарии 5
Наверно, надо бы еще определится со стеком. Если это no- low- code - это одно. Если отдельно готовится бэк, отдельно фронт - другое. А если еще есть дизайнер?
Получается, аналитик проектирует БД? Ну или имеет доступ к БД на живом проекте?
Здесь приведен пример «классического» ТЗ, когда указаны требования, а методы реализации на стороне разработки. По поводу БД, если аналитик может ее спроектировать это вообще отлично. Если не может, то было бы хорошо если у него есть доступ к БД на просмотр или хотя бы к интерактивной схеме, например, в PowerDesigner. Потому, что без описания полей в БД потом очень тяжело в дальнейшем если поля часто переименовываются и сопровождению будет очень сложно, например, подготовить скрипт по изменению данных по такой документации.
В общем все зависит от того в какой роли вам приходится это все исполнять.
Если вы просто исполнитель то вам всучили в зубы эту бумажку и пойдете вы ее реализовывать как есть, пофиг на ошибки.
Если вы системный аналитик вы выкините нафиг эту фитюльку и для начала пойдете разбираться с бизнес-процессами клиента, после чего собрав полноценные требования, включая бизнес-требования (которые и дадут ответ на вопрос с часовыми поясами - а важны ли они вообще), вы начнете проектирование этого всего с нуля, и в зависимости от собранных требований вы реализуете проект таким образом, что и ЭЦП давшего разрешение будет, и ФИО агента будет выбрано из списка, и очередь проверки валидности сделок там возникнет так что отпадет потребность считать сколько и какие разрешения и кем выданы, отпадет.
Если вы начальник всего этого балагана то вы задумаетесь о том кто и зачем это все наваял и что с ним делать.
Если вы новый сотрудник фирмы то вы начнете с изучения того что контора уже делала по таким поводам чтобы быть в контексте и не лепить излишние сущности которые удорожают проект.
А форма... ну что форма... форма как форма.... точнее рыба.
Качественный шаблон спецификации нужен как раз для того, чтобы избежать всех проблем, приведенных в статье. Если вы исполнитель, то при передаче спецификации в разработку можете указать на требования и поведение системы, которые не описаны, чтобы итоговая реализация не разошлась с тем, что ожидал заказчик.
Если вы аналитик, то хороший чек лист с требованиями, как раз позволит вам качественно собрать бизнес-требования. Часовой пояс может быть важен, а может и не важен, но этого не узнать если не задать этот вопрос. В своей практике очень часто сталкивался с тем, что требования к часовому поясу в дате не были указаны, и потом вследствие этого были конфликты с датами.
Вторую ошибку можно расширить от количества введенных символов до формата введенных значений и источника данных.
Сразу возникают вопросы: "что будет если пользователь укажет не в порядке ФИО, а например ИОФ", "важен ли регистр", "надо ли убирать пробелы", "писать ли серию и номер слитно или через пробел". А если копнуть еще дальше, то что вообще будет ключом в связи сотрудник-разрешение и по какому параметру мы будем делать соответствие?
Субъективный рейтинг: 10 самых часто встречающихся ошибок аналитика при написании требований