Привет всем. Подскажите , пожалуйста, где можно прочесть о том , что является функцией программного обеспечения ?
Проблема в том , что когда нужно перечислить функции , то они совпадают с названиями вариантов использования. а если детализировать очень , то уж очень много функций получается , например : предоставление возможности ввода и сохранения такой-то информации , отображение такой-то информации и т. д.
Может в ГОСТе в каком есть точное определение ? В гугле ничего подробного по этому поводу не нашёл. Заранее благодарю за помощь.

вероятно, можно прочесть у Липаева - что-то рядом у него точно есть, но сформулировано ли именно четко в таком виде - не уверен. зато он очень близок к ГОСТам ранних серий
Если нет желания мельчить функции, то можно их сформулировать на более высоком уровне "способности". Например, не способность ПО (или ПС - по ГОСТ ИСО 12207) ввода такой-то информации, а
способность ПО ввода информации. тогда такая функция будет использоваться в нескольких ВИ - придется делать трассировки.

Функция – это, во-первых, роль, которая выполняется субъектом или объектом в определенной сфере деятельности. Можно сказать, что функция – это то, за что отвечает субъект или объект в данном случае. В ряде точных наук функцией называются отношения между объектами, когда изменение одного из них ведет к изменению другого.

IMHO функции программного продукта должны быть связаны с результатом, который достигается при использовании продукта. В этом контексте возможности ввода и сохранения информации особой роли не играют, но вот какое-нибудь "ведение учета" такой-то информации - вполне.

Что за функции реализованы в продукте - есть короткий ответ на короткий же вопрос: Что делает продукт?

а мне вот как кажется (связываю с соседней темой "Бизнес-требования и бизнес-цели") :
Бизнес-цели : стратегические цели организации. например - увеличить производительность работы центра социологических исследований на 20%.
Бизнес-требования : возможность системы , благодаря которой будет достигнуты бизнес-цели. например - автоматизация проведения кластерного анализа и вывод сответствующей статистики , диаграмм (вот это уже и функцией , в принципе можно назвать).
Функции : те возможности , которые в совокупности реализуют бизнес-требование. в данном случае можно разложить на части кластерный анализ и назвать каждую часть отдельной функцией. Но как разлаживать ? можно вот так (но наверное это не правильно , с позиции эстетической привлекательности и здравого смысла) : разбиение опрошенных на подмножества (это тонкости кластерного анализа) ; подсчёт и вывод статистики по каждому подмножеству ; вывод таких-то диаграмм.
По-моему функция и бизнес-требование и вариант использования могут быть одним и тем же. Вобщем по-моему вопрос открыт...

Вроде бы Юра говорил, и мне понравилось. Features (именно это Вы под функцией понимаете?) - это 5-10 пунктов, которые Вы бы написали на на коробке своего продукта, чтобы продать клиентам.

Вроде бы Юра говорил, и мне понравилось. Features (именно это Вы под функцией понимаете?) - это 5-10 пунктов, которые Вы бы написали на на коробке своего продукта, чтобы продать клиентам.

а если продукт не "коробочный"?

Я бы сказал что функция ИС - это решение какой - то проблемы пользователя.
Например формирование отчетов - это функция.  А ввод информации и ее отражение - это какие-то мелкие фичи.

Коллеги, вопрос сподвиг меня на небольшую заметку в моем блоге по этой теме (юзкейсы и функции) - http://yurybuluy.blogspot.com/2010/12/use-cases.html. Welcome .... можно обсуждать как в блоге, так и тут ...

Особенно понравилось в статье : " "Система должна иметь возможность ..." и "Пользователь должен иметь возможность..."  " . Это улучшает понимание  сути. Действительно, если поддать этим вопросам , то лучше понимаешь где пользовательское требование , а где функция.

Еще хотел бы заметить - функция системы - это как правило существительное. Use Case как правило глагол

Features - это 5-10 пунктов, которые Вы бы написали на на коробке своего продукта

Именно!

Коллеги, вопрос сподвиг меня на небольшую заметку в моем блоге по этой теме (юзкейсы и функции) - http://yurybuluy.blogspot.com/2010/12/use-cases.html. Welcome .... можно обсуждать как в блоге, так и тут ...

В дополнение к вышесказанному и ранее написанному обсуждаю :о))) (не в целях сказать что-то против высказанных мыслей, а развития темы для) Признаться, часть, содержащая описание двух подходов и сама состоящая из трех частей, сделала попытку меня запутать :о)))
IMHO:
Use cases - это фактически описание интерфейса "пользователь-система" (или какие-то другие варианты взаимодействия с системой): как пользователь будет оперировать с системой, грубо говоря: какие кнопки нажимать, в какие поля и что вводить, и что при этом будет происходить с системой...
Функция - это некая, пардон за тавтологию, функционально законченная и реализованная возможность системы, то же "управление корпоративной печатью", которая(-ое ?) может детализироваться далее и далее на всё более мелкие функции, типа: "настройка устройства печати", "печать документа в различных форматах" и т.д. и т.п. пока не дойдет до уровня операций, выраженных с помощью Use Case "Настроить принтер"
Т.е. в конечном счете - это больше похоже на (мне больше нравится) третий подход (насколько я эти подходы понял из приведенного описания). Причем это действительно помогает "мэппить" требования на функции системы практически напрямую (хотя конечно так происходит не всегда).

P.S. и личное... Юрий (и другие коллеги), я Вас очень прошу: Не ставьте мягкий знак в глаголах третьего лица. Пожалуйста.

Именно!
В дополнение к вышесказанному и ранее написанному обсуждаю :о))) (не в целях сказать что-то против высказанных мыслей, а развития темы для) Признаться, часть, содержащая описание двух подходов и сама состоящая из трех частей, сделала попытку меня запутать :о)))
IMHO:
Use cases - это фактически описание интерфейса "пользователь-система" (или какие-то другие варианты взаимодействия с системой): как пользователь будет оперировать с системой, грубо говоря: какие кнопки нажимать, в какие поля и что вводить, и что при этом будет происходить с системой...
Функция - это некая, пардон за тавтологию, функционально законченная и реализованная возможность системы, то же "управление корпоративной печатью", которая(-ое ?) может детализироваться далее и далее на всё более мелкие функции, типа: "настройка устройства печати", "печать документа в различных форматах" и т.д. и т.п. пока не дойдет до уровня операций, выраженных с помощью Use Case "Настроить принтер"
Т.е. в конечном счете - это больше похоже на (мне больше нравится) третий подход (насколько я эти подходы понял из приведенного описания). Причем это действительно помогает "мэппить" требования на функции системы практически напрямую (хотя конечно так происходит не всегда).

P.S. и личное... Юрий (и другие коллеги), я Вас очень прошу: Не ставьте мягкий знак в глаголах третьего лица. Пожалуйста.

1. Не вполне понял что понимается под интерфейсом "пользователь-система", коими предлагается считать UC (вариант использования). Если это интерпретировать как "в какие поля что вводить" и в "какие кнопки нажимать" - то боюсь, что это не вполне отражает изначальное назначение UC. Если посмотреть того же Коберна, так он настойчиво предлагает не указывать в UC про нажатия кнопок и т.п. Более того, считается одной из распространенных ошибок описание деталей пользовательского интерфейса в UC.
2. Совершенно не факт, что UC и функции соотносятся таким образом. Если я правильно понял, то предлагается считать, что варианты использования будут "встроены" в иерархию функций системы. Хотя совершенно не факт, т.к. собственно варианты использования в большей части могут не найти прямого отражения в списке функций. Другой вопрос, что UC будет включать в себя "дергание" одной или более функций.
3. Проблема написания мягкого знака в глаголах 3 лица - известная проблема, присущая не только мне одному. Кстати у меня есть еще один "паразит", если кто заметил - это произношение слова "звонит", я часто говорю "звОнит", и "созвОнимся" :-).  Как сказала одна знакомая психолог - следует соотнести усилия направленные на контроль этого, с результатом :-).

не в целях спорить:
1. От себя сошлюсь на Фаулера, который определяет UseCase (вариант использования) как множество сценариев, объединенных вместе некоторой общей целью пользователя (например "Настроить принтер" - пример мой).
Описание сценариев же выполняется в стиле "Пользователь делает это" - "Система делает то", отсюда и термин "интерфейс "пользователь-система".

Поясню также термин "грубо говоря" -  в данном случае он не означает, что UseCase определяется до уровня кнопок (несмотря на написанное выше :о))) - действительно UseCases ведь разрабатываются, когда система еще не существует, о каких конкретно элементах управления может идти речь. Но тем не менее те или иные (назовем их - стандартные или типовые) абстрактные элементы все-таки подразумеваются: элементы выбора - списки, меню, справочники и тп.; элементы продолжения - типа кнопки, элементы для ввода значений и т.д. и т.п. Кстати, с их использованием был разработан стандарт CUA и поныне используемый в Windows, MacOs, Linux и других системах.

Согласен, что ссылаться на "кнопки" не совсем верно, но иногда приходится. Тем более, что потребители (будущие пользователи) далеко не всегда могут держать в голове несколько уровней абстракции: свою предметную область, уровень требований, уровень проектирования, уровень реализации и т.д. Поэтому часто спрашивают - это будет кнопка. Обычно я на отвечаю - элемент управления. В общем, если угодно считайте это отменятиной :о)))

2. Вообще-то я написал выше IMHO, и оно (это самое IMHO) распространяется на все три пункта. Извините, если это неочевидно.
Действительно, UseCase "Настроить принтер" может попасться под руку и при печати документа, и при печати форм, и при настройке устройства печати, и при переформатировании документа Портрет/Альбом, и ... да когда угодно! Поэтому наверняка не существует жесткой и однозначной связи между функциями системы (или может лучше Функциями Системы), которые пишут на коробке, и какими-то там UseCases. Однако существует ряд UseCase, которые связаны ТОЛЬКО с Функциями Системы - это те, которые относятся к основной ее функциональности (опять пардон за тавтологию), т.е. содержат то, для чего система создавалась (пример - "набор сообщения" в клиенте почтовой системы, каждый может по своим системам мноооого таких примеров насобирать). Их, кстати, можно (и нужно!) использовать при сравнении систем сходной функциональности.

всё вышенаписанное - IMHO.

Все зависит от целей документа, для которого надо описать или перечислить функции. На верхнем уровне функции - это блоки бизнес-функционала обеспечиваемые системой, типа "ведение заказов клиентов" или "ведение потребительских кредитов". Строгого определения тут нет, птишем то. что нужно читателю документа. Можно, кстати, считать это прецедентами уровня воздушного змея (kite usecase), если хочется работать в терминах прецедентов.

А что ниже - вопрос применяемых методологий, Юрий на эту тему много написал в блоге.