В теме 21 ответ, и 7 участников, последнее обновление сделано пользователем 
Герман Шестеров 13 г, 9 мес. назад.
-
Сообщения
-
Ну вот только не заглядывая в словари, википедии, книги и т.д. Своими словами.
Мы ведь каждый день работаем с ними. Некоторые даже называют нас "Requirements Analysts" (аналитики требований).
Конечно, речь идет про требование в контексте ИТ, а точнее в контексте бизнес и системного анализа.
И попробуйте не читать (знаю, это сложно) то, что другие напишут, а то это превратиться в серию постов, вроде: "+1", "согласен с предыдущим оратором" и т.д.
Хех… Итак
Требование — условие, критерий, которому должна соответствовать система.
Вот пришла в голову такая аналогия: требование — отрезок на оси характеристики, в который должны попадать характеристики данной системы. А совокупность отрезков на осях всех характеристик и есть требования к системе.Кто согласен/не согласен?
Хорошая аналогия. Для тех, у кого математический склад ума
Позволю себе первым согласиться, но лишь отчасти. Такая аналогия дает как бы статическое описание системе (каким свойством или характеристикой должна обладать система), но не дает представление о том, например, что система должна уметь делать и как она это должна уметь делать..Согласен.Я предполагаю, что однозначное определение для требования вряд ли возможно. Предлагаю взять схему словаря:
Требование — 1) условие, критерий, которому должна соответствовать система;
2) …. следующий вариант…Потом можно будет и сгруппировать, если найдутся группируемые варианты.
В качестве второго варианта предлагаю такой:
Требование — ответы на вопросы "что?" и "как?", касающиеся разрабатываемой системы.
ЗЫ Мы разговор идем в контексте работы БА и СА, или о требованиях вообще?
Честно говоря, сложное ты, Юрий, условие поставил — сказать своими словами, не заглядывая в словарь.
Все мы читали ряд умных книг и в голове уже осели определения.
Но попробую, тем не менее, представить, что я книг умных не читал
Требование — это то, что хочет от системы тот, кто ее заказывает. Соответственно, общая масса всех его хотелок — это совокупность требований к системе.
Я понимаю, что это не совсем корректное определение, но это то, как человек, не знакомый с анализом, описал бы это на мой взгляд.Герыч,Честно говоря, сложное ты, Юрий, условие поставил — сказать своими словами, не заглядывая в словарь.
Все мы читали ряд умных книг и в голове уже осели определения.
Но попробую, тем не менее, представить, что я книг умных не читал
Я ведь попросил не забыть всё, что вы читали, а просто не заглядывать в словарь. Я как раз хотел увидеть, что у кого осело после прочтения книг, и во что оно трансформировалось после работы.. Просто я не хотел, чтобы вы копи-пастили откуда-нибудь, а сказали своими словами то, что помните и уже теперь знаете и думаете о "требованиях"
Требование — это то, что хочет от системы тот, кто ее заказывает. Соответственно, общая масса всех его хотелок — это совокупность требований к системе.
Я понимаю, что это не совсем корректное определение, но это то, как человек, не знакомый с анализом, описал бы это на мой взгляд.А является ли требованием к системе то, что заказчик от неё НЕ ХОЧЕТ (скажем так.. явно / открыто не хочет), но то, что требует от неё законодательство?
Например, обязательно предупреждать на лицевой сранице, что пользователю должно быть более 18 лет, чтобы просматривать сайт и … (далее по тексту)На самом высоком уровне требование — запрос на разработку функциональности системы, которая позволит заказчику решить поставленную задачу, или упростить/ускорить ее выполнение.То, о чем говорит Юра это скорее бизнес-правила, которые накладывают ограничения на систему, поправьте если ошибаюсь.
На самом высоком уровне требование — запрос на разработку функциональности системы, которая позволит заказчику решить поставленную задачу, или упростить/ускорить ее выполнение.
То, о чем говорит Юра это скорее бизнес-правила, которые накладывают ограничения на систему, поправьте если ошибаюсь.
Эмм..
· Требование <> Запрос на разработку (по крайней мере, Требование — это не только Запрос)
· А что, Бизнес-правило (применяемое к системе) <> Требование (к этой системе)?Вот нагуглил 6 страничек на просмотреть / почитать — Requirements and Business Rules: How Do They Relate?. Хотя, конечно, нагуглить можно и больше
Уважаемые коллеги, разрешите мне заметить, что на этот вопрос уже давно ответили "классики жанра", такие, как Гради Буч. Он дает следующее определение для распознавания функциональных требований (именно ими интересуется, и за них отвечает аналитик в первую очередь, а подробное рассмотрение нефункциональных требований можно оставить проектировщикам): "Если имеет место смысловое выражение: "Программная система должна делать "Х", то это "Х" является функциональным требованием". Читайте Г.Буча, Дж. Рамбо и М. Блаха, не забывайте Ф. Крачтена и получите четкие ответы на концептуальные вопросы ООП, анализа и визуального моделирования.На мой взгляд понять, что вопрос выше был задан не из-за незнания термина "требование" не так уж и сложно.
Выскажу явно — цель (жаль нет возможности подчеркнуть тремя линиями) данного топика была узнать, как себе лично представляют и насколько могут сформулировать данное понятие участники форума. И пожалуйста, после этой фразы не стоит закидывать меня постами о том, что "это бессмысленно", "ведь все уже придумано за нас", "есть классики", "спорить с ними нельзя", "все это чушь" и т.д. Лучше живите спокойно и думайте, что местная малышня страдает ерундой от нечего делать…
И на будущее — небольшое пожелание… я бы даже сказал просьба… и я бы даже сказал две просьбы:
1) Не стоит закидывать темы форума теорией, удачно почерпнутой (читайте "скопипастенной") из первоисточников и иных умных книжек. Все мы умеем читать и сюда большинство приходит вооруженными теоретической информацией. Всегда гораздо ценнее личное отношение и опыт.
2) Читайте внимательнее и старайтесь понять, что конкретно хотят и обсуждают в этой теме. Не первый раз ловлю вас на том, что тема вами явно не пропущена через аналитический фильтр.
Высказал все это, потому что уже начинает доставать ваш менторский тон и сухая теория в темах данного форума. Опять же, без обид, я не отрицаю ваш опыт, знания, возраст и что угодно… Но — 3 вещи, которые я бы рекомендовал вам принять, если хотите снискать уважение и симпатию: будьте гораздо более лояльны и вежливы к участникам форума, допускайте существование других истин (кроме вашей) и попытайтесь понять разницу между форумом и университетом (вы здесь не лектор, а мы не студенты).ОК, спасибо за ответ! Но Вы тоже здесь явно не совсем правы: я просто высказал собственное мнение и привел фразу Г.Буча, которой всегда сам следую выполняя практические проекты при лингвистическом анализе текста и не более того. Никого я никак не хотел ущемить или задеть, ни, ни. И я тут прямо пишу, что именно его мысль. Можно, конечно, массу чего придумать, но здесь коротко и точно. Разве не так?
Ну, а менторский тон, так он только на лекциях, там без него никак, здесь обмен мнениями.
И еще вопросик: и где, хоть в одном посте я был не вежлив? Стараюсь всегда придерживаться вежливости, особенно в дискуссиях и не когда не переходить на личности и на возраст тоже, т.к. последнее не является ни достоинством, ни недостатком (если нет энцефалопатии! Как у меня…). Как Вы думаете, чтобы снискать уважение и симпатию, нужно просто быть в рамках mainstream?
По поводу "сухости" теории — она не сухая, она интересная и очень практичная. А по поводу истин — скажите, какие другие истины я отвергаю в своих постах или заменяю их своими? И высказал ли я хоть одно свое собственное теоретическое положение?
Извините, поругал чуть-чуть диаграмму, от которой Вы потом сами отказались, и Вы обиделись, и уже достал… а жаль…И еще, что меня несколько удивляет в форуме, очень много теоретических вопросов, на которые уже есть четкие ответы, либо в концепции ООП, либо в стандарте UML, либо в RUP и т.д. Неужели новых вопросов, еще не затронутых "классиками"? А, например, возможности ситемного подхода к проекту? Можно ли выявить и смоделировать функциональные требования не изучая бизнес-сущности и бизнес-процессы? Можно еще целую кучу интересных вопросов анализа поднять, трассируемость или до какой степени детализация Use Case и т.д., а то, честно читаешь, и как к себе в универ пришел. Извините, я это все опять без всякого "менторства" высказываю. И по процессам разработки ПО тоже хотелось бы пообщаться. От них и набор артефактов зависит. Их много, и из них RUP обладает большой избыточностью, как от этого уходить? Поэтому, возможно я так и отношусь к очевидным вещам, за которые на экзамене оценку ставлю. Еще раз, извините…Уважаемый nousy123!
Прежде всего хочу поблагодарить вас за вашу активность на форуме. Мы искренне рады тому, что форум вызывает интерес и есть люди, готовые обсуждать волнующие аналитиков проблемы. При этом для нас одинаково ценны и те, чей опыт исключительно практический (люди, которые учились методом проб и ошибок и в итоге сформулировали для себя best practices, придерживаясь которых им удается добиваться весьма значительных результатов), и те, кого в большей мере можно назвать теоретиком, нежели практиком. Никто из членов сообщества не претендует на то, что его мнение и его навыки работы в области системного анализа единственно правильны. Мы открыты обсуждать любые вопросы и делиться опытом.
Далее, что касается вашего вопроса:И еще, что меня несколько удивляет в форуме, очень много теоретических вопросов, на которые уже есть четкие ответы, либо в концепции ООП, либо в стандарте UML, либо в RUP и т.д. Неужели новых вопросов, еще не затронутых "классиками"? А, например, возможности ситемного подхода к проекту?
Во-первых, сам факт того, что в каком-либо стандарте УЖЕ есть ответ на вопрос лично для меня не означает, что стоит просто открыть стандарт, перечитать его, кивнуть, принять на веру и всю жизнь пользоваться подходом, сформированным "классиками". Я стараюсь ко всему относиться критически и рассуждать, правомерно ли авторы пришли к тому или иному выводу.
Во-вторых, вы вольны создавать новые темы, которые волнуют лично вас. Я уверена, многие на форуме откликнуться и будут готовы обсудить ваши вопросы. К тому же форум достаточно молод, он развивается, и лично я не вижу ничего удивительного в том, что какие-то темы пока не затронуты.
И последнее. Я присоединяюсь к уже прозвучавшему здесь пожеланию быть лояльнее и вежливее. При чтении ваших постов создается впечатление, что вы относитесь к остальным участникам форума пренебрежительно. Я уважаю ваш опыт и знания, но, пожалуйста, принимайте в расчет, что здесь собрались не мальчишки-студенты, а взрослые аналитики, многие из которых уже успели себя зарекомендовать в данной сфере и работают в ней не один год. Успешность проектов, над которыми они работают, и удовлетворенность заказчиков результатами их деятельности являются, по моему мнению, достаточным подтвержением их профессионализма.
Хех… Итак
Требование — условие, критерий, которому должна соответствовать система.
Вот пришла в голову такая аналогия: требование — отрезок на оси характеристики, в который должны попадать характеристики данной системы. А совокупность отрезков на осях всех характеристик и есть требования к системе.Кто согласен/не согласен?
Категорически согласен.
Чище описать сложней.сам факт того, что в каком-либо стандарте УЖЕ есть ответ на вопрос лично для меня не означает, что стоит просто открыть стандарт, перечитать его, кивнуть, принять на веру и всю жизнь пользоваться подходом, сформированным "классиками". Я стараюсь ко всему относиться критически и рассуждать, правомерно ли авторы пришли к тому или иному выводу
Уважаемая Belle Morte, не сочтите, пожалуйста, мой вопрос за невежливость или за нелояльность, просто очень захотелось узнать, к какому конкретно положению или фразе из классиков-родоначальников визуального моделирования, языка UML и его стандарта, а также и унифицированного процесса разработки (Г.Буч, Д. Рамбо, А.Якобсон, Ф.Кратчен) у Вас возникло критическое отношение и Вы засомневались в его правомерности? Где и в каком источнике Вы нашли это положение, дайте, пожалуйста, ссылку.
Вы должны авторизироваться для ответа в этой теме.
