Concept Development:

Concept development is a process driven by a set of customer needs and target product specifications, which are then converted into a set of conceptual designs and potential technological solutions. These solutions represent an approximate description of form, working principles, and product features.

Goals:

The purpose of the Concept Development is to define the project scope and prepare formal funding requests.

Objective:

Successful completion of the Concept Development should comprise:

  • Analysis of the business need
  • Definition of project scope
  • Evaluation of technical alternatives
  • Baseline analysis of risks
  • Approval of project costs and obtaining of project funding
  • Definition of planning roles and responsibilities

Policies:

A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to, that system. Concerns are those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.

A system exists to fulfill one or more missions in its environment. A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives.

Every system has an architecture, in the terms of this recommended practice. An architecture can be recorded by an architectural description (see Figure 1). This recommended practice distinguishes the architecture of a system, which is conceptual, from particular descriptions of that architecture, which are concrete products or artifacts. Architectural descriptions (ADs) are the subject of this recommended practice.

In the conceptual framework of this recommended practice, an architectural description is organized into one or more constituents called (architectural) views . Each view addresses one or more of the concerns of the system stakeholders. The term view is used to refer to the expression of a system’s architecture with respect to a particular viewpoint. Other information, not contained in any constituent view, may appear in an AD , as a result of an organization’s documentation practices. Examples of such information are the system overview, the system context, the system stakeholders and their key concerns, and the architectural rationale.

A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modeling methods or analysis techniques to be applied to these representations of the view. These languages and techniques are used to yield results relevant to the concerns addressed by the viewpoint. An architectural description selects one or more viewpoints for use. The selection of viewpoints typically will be based on consideration of the stakeholders to whom the AD is addressed and their concerns. A viewpoint definition may originate with an AD, or it may have been defined elsewhere. A viewpoint that is defined elsewhere is referred to in this recommended practice as a library viewpoint . A view may consist of one or more architectural models . Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.