Difference between revisions of "Business or Mission Analysis"

From SEBoK
Jump to: navigation, search
(4.1 Introduction, Definition and Purpose of Stakeholder Requirements)
(Article Discussion)
Line 32: Line 32:
  
  
====Article Discussion====
+
==Article Discussion==
  
 
[[{{TALKPAGENAME}}|[Go to discussion page]]]
 
[[{{TALKPAGENAME}}|[Go to discussion page]]]
  
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]

Revision as of 19:38, 4 June 2011

4.1. Introduction, Definition and Purpose of Stakeholder Requirements

Introduction - The starting point of engineering a system is the definition of the problem to be solved. The stakeholders’ requirements represent the view of the users, acquirers, and customers of the problem. An important set of activities has to be performed to establish a set of stakeholders’ requirements for a system that can provide the services needed by the acquirer, the users, and the other stakeholders in a defined environment. This section provides knowledge about the notions of needs, expectations, stakeholders’ requirements, concept of operations, and the related systems engineering activities and methods. The set of Stakeholder Requirements represents one of the major outcomes of these activities. For better understanding of this chapter, it is recommended that you read sections 3.3.3.1 and 3.3.3.2 first.

Definition and Purpose - An initial presentation of stakeholders’ intention is not necessarily a requirement, since it has not been defined, analyzed, or determined to be feasible. This intention is distinguished from a requirement as being (stakeholder) needs, goals or objectives. The distinction between requirements and needs is related to which system is concerned; for example, a requirement for a system may be allocated to a software element of the system, viewed as needs by the supplier of this software element, and further elaborated as (a) requirement(s) for this software element.

An important aspect of engineering is “requirements engineering.” Some activities gathered under this term include:

  • the capture of the needs, goals, and objectives of the various stakeholders;
  • the preliminary identification of the engineering elements of this system-of-interest in terms of purpose, expected mission, services or operations, objectives, exchanges, and physical links with the objects of its context of use;
  • the enrichment of the needs through the analysis of these first engineering elements of the system, in particular what is called the “mission analysis”;
  • the transformation of these needs into clear, concise, and verifiable Stakeholders’ Requirements applicable to the system-of-interest;
  • the analysis and translation of the Stakeholders’ Requirements into a set of System Requirements (see section 3.3.5).

Requirements engineering is performed in an iterative manner with the other life cycle processes and recursively through the system design hierarchy.

4.2. Principles about Stakeholder Requirements

4.2.1. From capture of needs to the Stakeholders’ Requirements definition

Several steps are necessary to state the maturity of the needs, from "real needs" to reaching a realized solution (that could be called "realized needs"). Figure 4 presents the “Cycle of Needs” as it can be deduced from Professor Shoji Shiba and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering purposes.

FIGURE 4

This figure shows these steps and the position of the Stakeholder Requirements and System Requirements in the engineering cycle:

  1. Real needs are those that lie behind any perception, and indeed may not be perceived at all; they are conditioned by the context in which people live. As an example, a generic need could be “identify infectious diseases easily”. It often looks like a simple action.
  2. Perceived needs are based on a person’s awareness (possibly imperfect) that something is wrong, that there is a lack of something, or that there is something that could improve a situation. Perceived needs are often presented as a list of disorganized expectations, often resulting from an analysis of the usage conditions for the considered action. Following on from the example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, point of care, hospital, human dispensary)". Since the real need is seldom expressed, the richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.
  3. Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. For example, if safety is the top concern, the expressed need “Protect the operator against contamination” may take priority over other expressed needs, such as “Assist in the execution of tests.” Here the analysis of the expected mission or services in terms of operational scenarios takes place.
  4. Retained needs use the prioritization of expressed needs in order to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions. The retained needs are generally called "Stakeholder Requirements,” and exploration of potential solutions must start from this step. The various solutions suggested at this step are not yet products but describe means of satisfying the Stakeholder Requirements. Each potential solution imposes constraints on the future system-of-interest.
  5. Specified needs, generally called “System Requirements”, are the translation of the stakeholders’ requirements to represent the view and expression of the supplier of the problem. The expression of the System Requirements means that potential solutions exist or can be developed, manufactured, or bought.
  6. Realized needs are the system, product, or service realized, taking into account every System Requirement (and hence Stakeholder Requirement).

ADD ACTION RELATED TO COMMENTS 379, 826, 1180



Article Discussion

[Go to discussion page]