Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Определение и поддержание требований в системной инженерии
Defining and maintaining requirements in systems engineering
Инженерия требований (RE) – это процесс определения, документирования и сопровождения требований в процессе проектирования. Это распространенная роль в системной и программной инженерии. Термин "инженерия требований" впервые, вероятно, был использован в 1964 году в докладе на конференции "Обслуживание, поддерживаемость и системная инженерия требований", однако широкое распространение он получил лишь в конце 1990-х годов с публикацией учебного пособия IEEE Computer Society в марте 1997 года и учреждением серии конференций по инженерии требований, которая впоследствии развилась в Международную конференцию по инженерии требований. В каскадной модели (waterfall model) инженерия требований представлена как первый этап процесса разработки. Более поздние методологии разработки, включая Унифицированный процесс Rational (RUP) для программного обеспечения, предполагают, что инженерия требований продолжается на протяжении всего жизненного цикла системы. Управление требованиями, являющееся подфункцией практик системной инженерии, также отражено в руководствах Международного совета по системной инженерии (INCOSE).
Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering. The first use of the term requirements engineering was probably in 1964 in the conference paper "Maintenance, Maintainability, and System Requirements Engineering", but it did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial in March 1997 and the establishment of a conference series on requirements engineering that has evolved into the International Requirements Engineering Conference. In the waterfall model, requirements engineering is presented as the first phase of the development process. Later development methods, including the Rational Unified Process (RUP) for software, assume that requirements engineering continues through a system's lifetime. Requirements management, which is a sub function of Systems Engineering practices, is also indexed in the International Council on Systems Engineering (INCOSE) manuals.
Деятельность
Деятельность, связанная с разработкой требований, значительно варьируется в зависимости от типа разрабатываемой системы и конкретных практик, применяемых в организации. Она может включать в себя:
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the organization's specific practice(s) involved. These may include:
Инициирование или выявление требований – Разработчики и заинтересованные стороны встречаются, последние отвечают на вопросы об их потребностях и ожиданиях относительно программного продукта. Анализ и согласование требований – Определяются требования (включая новые, если разработка итеративная), и разрешаются конфликты с заинтересованными сторонами. Для этого успешно используются как письменные, так и графические инструменты (последние чаще применяются на этапе проектирования, но некоторые считают их полезными и на этом этапе). Примеры инструментов письменного анализа: варианты использования и пользовательские истории. Примеры графических инструментов: UML и LML. Системное моделирование – В некоторых областях инженерии (или в конкретных ситуациях) требуется полностью спроектировать и смоделировать продукт до начала его создания или изготовления. Следовательно, этап проектирования должен быть выполнен заранее. Например, чертежи здания должны быть разработаны до утверждения и подписания любого контракта. Многие области могут создавать модели системы с использованием языка моделирования жизненного цикла, в то время как другие могут использовать UML. Примечание: во многих областях, таких как разработка программного обеспечения, большая часть работы по моделированию классифицируется как проектирование, а не как разработка требований. Спецификация требований – Требования документируются в формальном документе, называемом Спецификацией требований (СР), которая становится официальной только после валидации. СР может содержать как текстовую, так и графическую (модельную) информацию, если это необходимо. Пример: Спецификация требований к программному обеспечению (SRS). Валидация требований – Проверка соответствия задокументированных требований и моделей согласованности и потребностям заинтересованных сторон. Только после успешного прохождения валидации СР становится официальной. Управление требованиями – Управление всеми видами деятельности, связанными с требованиями, начиная с момента их инициирования, отслеживание хода разработки системы и даже после ее ввода в эксплуатацию (например, внесение изменений, расширение функциональности и т.д.). Эти этапы иногда представляются в хронологическом порядке, хотя на практике наблюдается значительное их переплетение. Разработка требований, как было показано, вносит существенный вклад в успех программных проектов.
Requirements inception or requirements elicitation – Developers and stakeholders meet; the latter are inquired concerning their needs and wants regarding the software product. Requirements analysis and negotiation – Requirements are identified (including new ones if the development is iterative), and conflicts with stakeholders are solved. Both written and graphical tools (the latter commonly used in the design phase, but some find them helpful at this stage, too) are successfully used as aids. Examples of written analysis tools: use cases and user stories. Examples of graphical tools: UML and LML. System modeling – Some engineering fields (or specific situations) require the product to be completely designed and modeled before its construction or fabrication starts. Therefore, the design phase must be performed in advance. For instance, blueprints for a building must be elaborated before any contract can be approved and signed. Many fields might derive models of the system with the Lifecycle Modeling Language, whereas others, might use UML. Note: In many fields, such as software engineering, most modeling activities are classified as design activities and not as requirement engineering activities. Requirements specification – Requirements are documented in a formal artifact called a Requirements Specification (RS), which will become official only after validation. A RS can contain both written and graphical (models) information if necessary. Example: Software requirements specification (SRS). Requirements validation – Checking that the documented requirements and models are consistent and meet the stakeholder's needs. Only if the final draft passes the validation process, the RS becomes official. Requirements management – Managing all the activities related to the requirements since inception, supervising as the system is developed, and even until after it is put into use (e. g., changes, extensions, etc.) These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities. Requirements engineering has been shown to clearly contribute to software project successes.
Проблемы
В одном небольшом исследовании, проведенном в Германии, были выявлены потенциальные трудности при реализации инженерных требований, и респондентам предложили оценить, насколько они согласны с тем, что эти трудности действительно существуют. Результаты не претендовали на обобщение, однако показали, что основными проблемами участники исследования считали неполноту требований, их постоянное изменение и жесткие временные рамки, а менее значимыми – недостатки в коммуникации, отсутствие отслеживаемости, терминологические несоответствия и нечеткое распределение ответственности.
One limited study in Germany presented possible problems in implementing requirements engineering and asked respondents whether they agreed that they were actual problems. The results were not presented as being generalizable but suggested that the principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities.
Критика
Структурирование проблем, являясь ключевым аспектом инженерного обеспечения требований, предположительно может снижать эффективность проектирования. Некоторые исследования показывают, что это возможно, если в процессе разработки требований имеются недостатки, приводящие к ситуации, когда реальные требования отсутствуют, а требования к программному обеспечению создаются искусственно, представляя собой иллюзию, маскирующую дизайнерские решения под требования.
Problem structuring, a key aspect of requirements engineering, has been speculated to reduce design performance. Some research suggests that it is possible if there are deficiencies in the requirements engineering process resulting in a situation where requirements do not exist, software requirements may be created regardless as an illusion misrepresenting design decisions as requirements