16
Вакансии / Re: Требуется ведущий аналитик, Москва kkosti1973@yandex.ru
« : 20 Декабря 2016, 02:59:49 »
это в раздел «Вакансии»
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Почитал, что такое user story и use case. Use case очень похож на то описательное объяснение работы, что я хотел бы разработать.Не обязательно. Сам формат очень простой и не накладывает ограничений на то, будет ли описана автоматическая функция, автоматизированная функция или просто свойство предмета.
А user story для железа, не имеющего пользовательского интерфейса, наверное, не подходит.
В прочем, теперь я дезориентирован и думаю, является ли мое ТЗ бизнес-требованиями или чем-то еще.А вы покажите примеры.
Или, может быть, оно должно чем-то являться, но я написал что-то другое
По традиции нашей организации в ТЗ оказались и требуемые функции, и требовния к точности, и то, какая структура будет у системы, и какие технические решения должны обеспечивать выполнение функций. Наверное, это должны быть несколько документов: в ТЗ только требуемые функции и требования к точности, времени исполнения, а на его основе уже документ со структурой системы, взаимосвязями частей.Это обычная ситуация, когда мешают ТЗ и техпроект. В половине случаев она вполне оправдана.
Здравствуйте.2. Есть форматы описания поведения ИТ-систем и продуктов, которые в себя включают:
Укажите, пожалуйста, нужные ориентиры начинающему.
Пришлось выступать в роли представителя заказчика и писать ТЗ на систему, состоящую из нескольких устройств и ПО к ним.
ТЗ вышло монстром (объем чуть более 100 страниц), хотя сначала все казалось управляемым.
В связи с этим появилось желание написать другой документ, повествовательный, объясняющий, как система должна работать в форме каких-то случаев использования, и на этот документ, назовем его "Программа функционирования", протрассировать свое ТЗ, чтобы было понятно, откуда взялись требования и зачем они нужны. Далее подумал, что не плохо и исполнителям свои требования к составным частям системы протрассировать на мое ТЗ, чтобы легче было их проверять, и можно было увидеть неохваченные требования. И, конечно же, программу и методику испытаний протрассировать на ТЗ. И чтобы все это можно было редактировать, не теряя трассировки.
Подскажите, пожалуйста:
1. Есть ли в описанном пожелании то, чего не надо / не возможно делать или стоит делать совсем не так.
2. Если для описанных мною документов или действий есть другие, правильные названия, подскажите их.
3. Есть ли freeware (или платное с триалом на срок, позволяющий успеть разобраться и продемонстрировать всем), чтобы воплотить описанное в жизнь и заинтересовать начальство в автоматизации разработки требований в принципе? Желательно, с возможностью создать репозиторий в сетевой папке и поработать с нескольких учетных записей.
Спасибо.
• понимание относительной важности атрибутов качества;"Друг относительно друг друга. И не функциональных требований, а атрибутов качества.
…
Вопрос 4. Э-э-э.... А "понимание относительной важности" - это что-то вроде - вес важности атрибутов качества по отношению к весу важности (и тут снова вопрос - важности чего? важности функциональных требований?)?
Слово "относительный" говорит мне о том, что подразумевается сравнение, но не указано - сравнением с чем.
Вопрос 2. Когда написано про "ожидания в отношении качества", то имеются ввиду нефункциональные требования или бывают "ожидания в отношении качества", которые могут бытьКогда пишут про ожидания в отношении качества, то имеют в виду именно ожидания в отношении качества.