Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: bas от 05 Марта 2007, 00:47:13
-
В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?
Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.
Плюсы такого подхода:
1. Учитываются все требования
2. Наиболее понятны и детализированы для программиста
3. Наиболее понятны для заказчика, можно дать почитать
Хотелось услышать другие мнения и минусы моего подхода, если они есть.
-
Самым "сложным" случаем с т.з. процесса документирования требований будет такой, когда есть заказчик который трубует документацию требований в определенном формате (например по ГОСТ 34.602) а у компании-разработчика свои стаднарты (например те же UC и иже с ним). В этом случае нужно формировать документацию требований по ГОСТ из тех требований, которые создаются самими аналитиками компании-разработчика. Тут вариантов 2 либо делать требования в классическом иерархическом виде, что маппится 1 в 1 на ТЗ по ГОСТ, либо впихывать в ТЗ по ГОСТ (или в разные наборы документов по ГОСТ) юзкейсы и иже с ним. При всем при этом крайне желательно пользоваться каким-либо инструментарием и поддерживать синхронизацию изменений в обоих артефактах. Идеальный случай, когда требования ведуться в неком репозитории и документация создается автоматически.
Что касается использования юзкейсов -- то формально говоря, это пользовательские требования (по тому же Вигерсу). С другой стороны, в них содержится и собственно информация о том, какая функциональность должна быть в системе. Но формально говоря, (с т.з. формального определения из глоссария IEEE что есть требование) это <> функциональным требования. Т.е. UC это контейнер для функц. требований по большому счету. Да, можно описать достаточно подробно юзкейсы с дополнительными слотами, где учесть и некоторые нефункциональные требования, которые "привязаны" к данному UC. И для целого ряда систем этого будет достаточно для проектирования системы. Но следует помнить и тот факт, что не всегда удается описать юзкейсами всю нужную ФУНКЦИОАЛЬНОСТЬ системы. И это одна из причин почему их относят таки к ПОЛЬЗОВАТЕЛЬСКИМ требованиям. И даже если взглянуть на RUP, то там в Supplementary Spec. есть отдельные слоты для описания ФУНКЦИОНАЛЬНЫХ требований, которые не были охвачены юзкейсамы.
-
В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?
Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.
Саша, "мы добавляем к сценариям ВИ нефункциональные требования и бизнес-правила" - это не ответ на вопрос КАК мы описываем требования и с КАКОЙ детализациией :)
Мы стараемся выделять фунциональные требования, нефункциональные и ограничения.
Стремимся к такой модели по функциональным требованиям - 1-5 бизнес-задач, из них 10-20 бизнес-требований, из них 50-100 пользовательских требований. Проработка каждого следующего уровня выполняется при наличии ресурсов/критичности системы. Бизнес-задачи формулируются в виде утверждений, привязанных к целям системы. Бизнес-требования - как условия выполнимости этих бизнес-задач. Пользовательские требования, нефункциональные и ограничения начинают формулироваться примерно одновременно. Первоначально пользовательские требования формулируются в виде утверждений-целей пользователя. Затем по возможности описываются одним абзацем текста в виде краткого описания основного сценария прецедента. По возможности детализируются пошагово и снабжаются описаниями исключений.
Требования к структурам данных формулируются в виде диаграмм предметной области. Требования к интерфейсу - в виде макетов. Прочие нефункциональные требования - в виде утверждений + приложений со спецификациями форматов, программных интерфейсов, ссылок на стандарты.
-
Денис, согласен, описал как-то скомкано, но было поздно, а хотелось дать пищу для размышления.
И так, требования именно к ПО мы описываем в виде единого документа (шаблон взят из SRS) :
1. Функциональные требования - в виде ВИ, т.е. пользовательских требований. На первом этапе только сами ВИ и их краткое описание, далее заполняем всю спецификацию
2. Не функциональные требования и ограничения описываем в виде одного-двух предложений
3. Дополняем диаграммой ВИ, которая называется "функциональная модель Системы"
4. Дополняем диаграммой бизнес сущностей - "Структурная модель Системы"
5. Каждый ВИ может быть дополнителнен макетом формы
6. БПравила описываем либо отдельно в каждом ВИ, либо (и) в отдельной секции.
7. После рекомендации Юрия, добавлю еще секцию - "Доп. функц. требования"
-
Саша, нужно смотреть конкретно что за проект и что за юзкейсы, чтобы можно было действительно рекмендовать добавить дополнительную секцию. Вполне разумный подход -- не описанные требования (функц. и нефункц.) описывать в другом артефакте (как это в RUP сделано) и трассировать на UC, в случае связки.
-
Саша, нужно смотреть конкретно что за проект и что за юзкейсы, чтобы можно было действительно рекмендовать добавить дополнительную секцию.
Это понятно, что если надо, то добавляем, если нет, то не добавляем. В принципе, у меня все функц. требования укладываются в ВИ и БПравила. Просто взял твою рекомендацию на заметку.
Вполне разумный подход -- не описанные требования (функц. и нефункц.) описывать в другом артефакте (как это в RUP сделано) и трассировать на UC, в случае связки.
Это да, но не прижилось у нас как-то использование RMS (requirements management system), т.к. бОльшая часть людей пишут спеки как попало ...
-
Если нет контрактных ограничений на формат документации требований, то я предпочитаю для нового проекта сначала написать Vision, где явно сформулировать какие бизнес-проблемы будут решены этим проектом (суть бизнес-требования), описать стейкхолдеров и софрмулировать основные фичи системы. При "идеальном" проекте, провязываются фичи с бизнес-требованиями. Рисуем контекстную диаграмму, чтобы определить опять-таки общие границы. И озвучиваем предположения которые делаем, вместе с ограничениями и обещаниями (по срокам, например)
Далее -- юзкейсы (если они применимы). Степень детализации зависит от конкретного проекта. Когда очень поверхностно, просто чтобы зафиксировать concept of operations, но тогда в SRS делаем более детальную проработку на уровне функциональных требований. А когда и достаточно детально, тогда имеет смысл использовать Supplementary Spec. а не SRS. А иногда, если и так все понятно ;-), ограничиваемся только юзкейсами. Повторюсь, что зависит от конкретного проекта.
-
А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...
-
А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...
anastazya, а Вы в какой области работаете? Адаптируете и внедряете какие-то бизнес-системы других производителей, или работаете аналитиком в компании, разрабатывающей собственный софт?
-
greesha, разрабатывающей собственный софт
-
ida, а как спец по функ. дизайну поймет какие реквизиты на форму надо помещать, если я их не укажу? Если для заполнения определенных реквизитов нужны определенные правила заполнения? Вот что мне хотелось бы знать
-
А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...
Можно описать не поля форм, а структуры данных в виде словаря данных (по Вигерсу), где описывается некая сущность и ее "информационный состав" - суть ее свойства (в терминах OOP). Например:
Клиент = ФИО {текст; required}
+ Адрес {текст; required}
+ Год рождения {текст; required}
+ Паспорт {текст; required}
+ Девичья фамилия матери {текст;}
+ Кличка собаки {текст;}
+ ...
тем самым вы четко даете понять на раннем этапе, какая информация о Клиенте в контексте вашего домена важна ...
-
Видел разные ТЗ. В том числе со скриншотами форм и текстом примерно таким: "Поля формы такой-то должны быть как на рисунке N". Допускаю, что для каких-то ситуаций это вполне приемлемо.
Вообще, считается, что чем больше деталей технической реализации прописать в ТЗ, тем проще будет потом разработчикам. Т.е. в основном тут идет компромисс со сроками и с желанием заказчика. Если заказчик не против и сроки позволяют, то почему бы не написать ТЗ с детальным описанием всех форм, полей, правил проверки и т.п.
В более типовой ситуации дизайн форм является все-таки предметом какого-то отдельного внутреннего документа разработки, а в согласуемом с заказчиком ТЗ эти сведения даются в более общем виде.
-
Можно в ТЗ описывать и данные, как сказал Юра, и формы, как Михаил, главное их разнести по разным документам или хотя бы по разделам, и из основных ФТ ссылаться на них
-
Можно в ТЗ описывать и данные, как сказал Юра, и формы, как Михаил, главное их разнести по разным документам или хотя бы по разделам, и из основных ФТ ссылаться на них
Мы на проекте пишем ВИ, далее все сущности описываем как сказал Юрий, с атрибутами и ограничениями, выдирая сущности из бизнеса или ВИ.
Далее на основе все тех же ВИ рисуем прототипы GUI - в описании полей даем ссылки на атрибуты сущностей.
+ трассировка от ВИ к сущностям и от ВИ к гуям.
-
Всем доброго дня. Все чаще сталкиваюсь с проектами, где необходимо создать некоторое решение используя готовые продукты MS, Oracle и т.д. Подскажите, как в этом случае можно подойти к описанию функциональных требований? Описывать требования к существующим функциям продукта? Описывать требования к контенту? Что посоветуете?
-
Всем доброго дня. Все чаще сталкиваюсь с проектами, где необходимо создать некоторое решение используя готовые продукты MS, Oracle и т.д. Подскажите, как в этом случае можно подойти к описанию функциональных требований? Описывать требования к существующим функциям продукта? Описывать требования к контенту? Что посоветуете?
Попробуем разобрать по частям.
Вам нужно описать функциональные требования в некотором проекте (ограничимся пока одним).
Этот проект предполагает создание некоторого решения. (Что такое "решение"? Решение проблемы? Или под "созданием решения" понимается разработка программы или нескольких программ? А может быть, "решение" создаётся путём выбора уже готовых компонентов?)
Это решение должно использовать какие-то готовые продукты MS, Oracle и т. д. (Какие конкретно продукты? Каким образом использовать? Почему должно?)
Среди прочего, вам нужно описать требования к контенту. (Что такое "контент"?)
anastazya, вы очень компактно излагаете свои вопросы, не передавая при этом контекста. Изящные формулировки - это не самый эффективный способ обмена информацией. Или вы очень боитесь случайно раскрыть какие-то конфиденциальные сведения?
Например, по некоторым ключевым словам (MS, Oracle и в первую очередь "контент") кто-то можно сделать вывод, что вы разрабатываете веб-сайты.
А кто-то другой по тем же ключевым словам может понять, что вы адаптируете и внедряете какие-то тяжеловесные ERP системы.
А кто-то третий (я, например), может воспринимать Oracle и MS как ограничения заказчика, который какой-то из этих продуктов уже давно купил, и не собирается докупать новую СУБД и нанимать администратора исключительно для сопровождения вашего решения.
В результате эти три человека начнут отвечать на вопросы, которых вы не задавали.
-
anastazya, у нас в одном проекте файл атрибутов (ФА) был чуть ли не главным документом, на пару с UI. У нас был набор UI, созданный иерархично при помощи Axure на одном из языков системы.
После чего в ФА (в Excel) указывается конкретный интерфейс, путём прописывания маршрута "Раздел 1" "Подраздел 2" "Карточка 3". Далее следуют названия полей (на каждом из языков системы), ответственные пользователи, формулы расчётов, параметры отображения и прочее.
Если нужны подробности, то я могу подробнее написать. Могу сказать, что даже при написании ЧТЗ всё это актуализировать достатчно утомительно.
-
greesha, пойдем по порядку...
Попробуем разобрать по частям.
"Вам нужно описать функциональные требования в некотором проекте (ограничимся пока одним)."
Пусть так.
"Этот проект предполагает создание некоторого решения. (Что такое "решение"? Решение проблемы? Или под "созданием решения" понимается разработка программы или нескольких программ? А может быть, "решение" создаётся путём выбора уже готовых компонентов?)"
В данном случае под "решением" понимается совокупность программного кода, написанного разработчиками Поставщика, готовых компонентов того инструмента, на базе которого осуществляется разработка и его настроечных механизмов. Хотя может случиться и так, что возможности продукта в целом способны будут реализовать необходимую функциональность, то тогда решением будет являться скажем ввод данных и настройка продукта (это я назвала контентом, хотя может и не очень корректно, потому как кроме данных реализуется логика работы и т.д). В качестве примера можно привести следующее: Задача состоит в автоматизации Системы Сбалансированных показателей (...как то я о ней упоминала на форуме). Берем готовый продукт MS PPS 2007, производим ввод данных по показателям, формируем необходимые карты и т.д. (не буду полностью описывать процесс, не имеет смысла). Решение построено. Построено на основе инструмента с некими функциональными возможностями. Если бы разработка осуществлялась "с нуля", то вопрос не возник бы и требования звучали примерно так: Система должна позволять вводить данные о показателях, Система должна позволять строить стратегические карты и т.д., но в данном случае это возможности продукта MS PPS 2007 и мы используя эти возможности решаем свою задачу по автоматизации ССП или иначе строим решение.
Это решение должно использовать какие-то готовые продукты MS, Oracle и т. д. (Какие конкретно продукты? Каким образом использовать? Почему должно?)
Выше привела пример. Ниже почему должно.
Среди прочего, вам нужно описать требования к контенту. (Что такое "контент"?)
Выше пояснила.
anastazya, вы очень компактно излагаете свои вопросы, не передавая при этом контекста. Изящные формулировки - это не самый эффективный способ обмена информацией. Или вы очень боитесь случайно раскрыть какие-то конфиденциальные сведения?
)) не все так плохо в смысле конфиденциальности. Да, каюсь, времени мало на общение.
Например, по некоторым ключевым словам (MS, Oracle и в первую очередь "контент") кто-то можно сделать вывод, что вы разрабатываете веб-сайты.
В том числе, но не только.
"А кто-то другой по тем же ключевым словам может понять, что вы адаптируете и внедряете какие-то тяжеловесные ERP системы."
И их тоже.
"А кто-то третий (я, например), может воспринимать Oracle и MS как ограничения заказчика, который какой-то из этих продуктов уже давно купил, и не собирается докупать новую СУБД и нанимать администратора исключительно для сопровождения вашего решения."
И такое бывает. А чаше мотивируя это тем, что завязываться на что то самописное опасается, так как это завязка на конкретного поставщика, который в скором времени может не подойти по ценовой политике или по другим причинам. Брендовые продукты проще сопровождать и выбор в поставщиках не так ограничен. Да это уже другая тема, почему Заказчик выбирает тот или иной продукт. Меня больше интересует постпериод, когда выбор сделан и необходимо решать задачу.
Надеюсь информации будет достаточно )
-
anastazya, да, этот проект не разрабатывался по ГОСТУ - использовался шаблон компании, похожий на SRS в IEEE, но несколько модифицированный. Увы, главное в этом доке было то, что его должен подписать заказчик и он должен был написан предельно простым языком и с представлением интерфейсов. То есть было достаточно перечислить все названия страниц (проект .aspx), привести интерфейс и кратко описать - зачем вообще эта стриница нужна.
Основной функционал был прописан в упомянутых мною UI и ФА (их мы составляли с представителями бизнеса - именно эти документы были основынми). ВИ мы вообще не составляли или составляли для себя.
Примерно год в итоге ушёл на рисование UI и приписывания ФА. Для справки - всего в системе 5 разделов, среднее кол-во полей для одного раздела 1300..
Алгоритм составления достаточно прост и шёл от заказчика:
На этой странице я бы хотел видеть величину уставного капитала..Хм.. Он формируется как сумма таких-то акций такого-то номинала.. Алексей, посмотрите, у нас есть эти поля в разделе Эмиссия - пропишите формулу на основании этих полей и добавте данную карточку в режиме просмотра. Возможно мы где-то в другом месте уже считали величину уставного капитала - проверьте. Ну и далее предоставлялись переводы, требования к формату, ограничения и прочая информация.
Проблемы составляют те поля, в которых очень сложная формула, или, ещё хуже, если эту формулу, завязанную на полей 20 (например, расчёт доступных акций) начинают менять - нужно перепроверять все поля, да ещё и проверять расчёты по формулам.
Зато разработчики довольны :)
-
Попался интересный документ - ТЗ, выполненное Карлом Вигерсом (приложил). За достоверность ответственность на себя не беру..
Может кому-нибудь будет интересно
-
Попался интересный документ - ТЗ, выполненное Карлом Вигерсом (приложил). За достоверность ответственность на себя не беру..
Может кому-нибудь будет интересно
Что-то есть некие сомнения по поводу того, что именно Вигерс сформировал данное ТЗ. Например, сразу бросилась в глаза контекстная диаграмма IDEF, которая выполнена непонятно каким образом...
Но всё равно есть что взять из данного ТЗ на заметку!
-
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved. Adapted by Edward Galiaskarov
на мой взгляд с такой подписью не должно быть сомнения. Потому как в противном случае - это камень в огород как Karl E. Wiegers, так и Edward Galiaskarov
-
Камень в огород можно кидать и великим, если по делу :)
spv139,
Про контекстную диаграмму, кот. использует Вигерс, можно почитать здесь (http://en.wikipedia.org/wiki/Context_diagram). На самом деле - очень мощная вещь на начальном этапе выявления требований.
-
Камень в огород можно кидать и великим, если по делу :)
spv139, про контекстную диаграмму, кот. использует Вигерс, можно почитать здесь (http://en.wikipedia.org/wiki/Context_diagram). На самом деле - очень мощная вещь на начальном этапе выявления требований.
Спасибо! Прошу прощения, Вигерса до конца ещё не дочитал. Приму во внимание данное ТЗ )
-
Так лихо сменили тему, что сразу и не поймешь что к чему.
-
spv139, если будите читать Карла Вигерса, то данную спецификацию требований можно найти в конце его книги "Разработка требований к программному обеспечению". В ней же подробное описание каждого раздела ТЗ, разъяснения и пример концепции по Вигерсу, вариантов использования.
-
Пожалуйста, покажите свой пример требований к ПО.