chapter 3 syse

The two objectives of QFD are

1.To convert the users' needs (or customers' demands) for product benefits into substitute quality characteristics at the design stage 2.To deploy the substitute quality characteristics identified at the design stage to the production activities, thereby establishing the necessary control points and checkpoints prior to production start-up

techniques that are commonly used in captur-ing requirements include

1.User interviews: This is one of the most popularly used techniques and sources for collecting requirements concerning product design and quality improvement. Interviews involve asking users a number of questions; each question addresses a certain aspect of the system to be designed. The interview can be conducted face-to-face or in a remote fashion, such as using the telephone or instant messenger (IM). The interview can be broadly classified as structured, unstructured, or semistructured, depending on how well the questions were predefined and organized. The structured interview looks for answers for specific questions of interest, but lacks flexibility to explore other issues that are beyond the scope of the predefined ques-tions. On the other hand, the unstructured interview enables users to express their opinions freely without being limited to a set of prede-termined questions. This can often lead to some issues that have not been thought of by the designers, but the problem with unstructured interviews is that they are time consuming and often inefficient in helping users to think, as some users are better at giving opinion only when specific questions are asked. To help users to provide answers and inputs, sometimes a scenario can be used to aid in the interview session. As interviews are typically conducted one-on-one, focus groups and workshops may be used as an alternative to inter-views to achieve group dynamics and interaction effects on the users. The use of groups can gain many benefits that individual interviews do not have; for example, through discussion and brainstorming, the focus group can help different users to gain a consensus view that certain items are required, solving any disagreement or conflict between different opinions. When controlled and structured well, focus groups and workshops can be very effective in collecting a set of validated user requirements 2.Survey and questionnaire: These are very popularly used in a wide range of applications and fields, such as social studies, behavioral science, and market analysis. Surveys and questionnaires use a series of questions to seek inputs from a large pool of users. A questionnaire may use closed or open questions. Closed questions have limited answers for users to choose, such as multiple-choice questions or a selection from a Likert scale, while open questions do not limit users' answers; users can enter their own words in the answers, like an essay question in an examination. Unlike inter-views, surveys and questionnaires can be done off-line; they can be distributed to the users and completed without being monitored or administered. Compared to interviews, surveys and questionnaires can reach a wider range of people within a short period of time, without committing too many resources; usually mail or email is sufficient. However, since they are conducted in an asynchronized way without the questioner being present, there is no guarantee that the user will respond to the survey. The response rate is the most critical issue for requirement collection via surveys and question-naires. A typical response rate for a survey and questionnaire study is around the 20%-40% range. The design of the questionnaire is the most critical factor impacting the response rate; many techniques have been developed to improve the clarity, flexibility, and friendli-ness of the questionnaire design. Another concern for the question-naire design is its validity; in other words, we have to make sure the users actually take time to read the questions, and think about them, before writing down their answers. Some techniques, such as asking the same questions in different places, have been used to validate users' answers. Nevertheless, the questionnaire has been one of the most popular methods used in gathering users' opinions, despite the disadvantages of low response rates. Questionnaires are often used in combination with other techniques; for example, during an interview session, a short questionnaire is often used at the end of the interview to obtain users' feedback about anything that might have been omitted from the interview session 3.Observation: This involves spending time with users, observing how they do certain functions and how they perform tasks. When asked about their expectations of and preferences regarding systems, users are sometimes not good at telling the complete story about the whole system; the mental model of users is only related to what they do on a daily basis, and based on their experiences, the input given by users will only cover a subset of the whole spectrum of the system requirements. Observation can fill in the gaps in the details of user input, and provide a better understanding of the user's needs more objectively and completely. Sometimes called naturalistic observa-tion, the key to the success of observation is in the users' natural working environment, trying not to disturb them when making the observations. To obtain greater insight into how the users feel, the observers can also take part in users' tasks, participating in users' functions, to get a first-hand experience of system functions. This is called an internal or inside observation. This is in contrast to a typical outside observation, where the observers adopt a passive role just to observe, and no active participation is involved. Since the observer is certainly limited in his/her cognitive resources, multiple observers are sometimes used to avoid missing features and subjec-tivity of personal understanding of the tasks. Technologies such as data logging and video/audio recording are used to aid data collec-tion during observation, if permitted by users. 4.Study of documents and reports: Historical documents and reports are good sources for eliciting requirements. Information on how systems were used and misused through historical sources can provide great insights for items that need to be included or improved in the next version of the system. These documents include, but are not limited to, system manuals, government and industrial standards and regulations, research articles and published guidelines, mar-keting and sales reports, and critical incident and accident reports. Standards, codes, and regulations should be one of the primary sources to be consulted for requirements, as many of the requirement sources, including the RFP and user inputs, do not necessarily include a complete reference to the standards. It is the designers' responsibility to consult these published standards to comply with them, to make the design more efficient, and most importantly, to avoid any product liability lawsuit in the future. For example, in designing cars, the Federal Motor Vehicle Safety Standards and Regulations by the Department of Transportation should be con-sulted to include any important features in the design of the vehicle. There are many standards, and weeding through them can be time consuming, but the impact of ignoring any important standard can be significant. In systems engineering, the typically used standards include Occupational Safety and Health Administration (OSHA) standards, military standards and handbooks (MIL-STD/MIL-HDBK, DoD standards), NASA standards (NASA-STD), American National Standard Institute (ANSI) standards, Institute of Electrical and Electronics Engineers (IEEE) standards, and International Organization for Standardization (ISO) standards. Research findings in the published literature can also serve as an important source for eliciting requirements; these research studies will provide guide-lines for researchers to look at potential variables that are involved in the design and help to design better methods to capture system requirements. Another source for potential requirements are histori-cal reports on critical incident and accident events. Most companies and organizations have an established way of reporting any inci-dents, accidents, and defects when using the system. These events inform us of potential ways that users could make mistakes or errors when interacting with the systems. These mistakes, errors, and acci-dents, which occurred in the past, reveal the situations in which the system causes difficulties. Investigating these situations will reveal to designers what the causes and sources for these difficulties are and, as an important set of the system requirements, investigations of these incidents and accidents, and related factors such as environ-ments and user interactions, will lead to a more reliable system and a better system maintenance design 5.Study of similar systems: At the current time, it is very difficult to think of any system that does not have any sorts of predecessors. On the other hand, there are always competitors with similar systems as well. Looking at predecessor systems or the current similar sys-tems of others will certainly help designers to gain understanding of what should be included in their own design. To study similar systems, a combination of techniques can be used to collect data, including observation, interviews with users who have experience with different systems, questionnaires, user task analysis, and criti-cal incident/accident studies, to look at data and information related to systems functions, operability, maintainability, user types/skills, and usability issues. Besides the main functional factors, some other useful analysis products should also be derived from the analysis of similar systems, including environmental factors for different sys-tems and human factor issues that could be significant in making the systems successful.

During the process of translating require-ments into the final system physical models, we want to make sure that

(1) all the requirements have been addressed at least once by some system elements, functions, or components; and (2) any design deci-sions or components have a reason or origin for that decision. System design usually takes months, even years; during the long transition period, we want to document every single change and evolution for each of the requirements, to ensure that design follows the right track. Maintaining such a traceability relationship also facilitates the verifi-cation process in the later stages. We want to make sure there are no so-called orphan requirements that are not supported by any design components.

why requirements management

.1) Systems engineering is requirement driven; requirements are needed throughout the whole system design process and even the life cycle. System requirements need to be retrievable at any point of the sys-tem design. For a large, complex system, it is not uncommon that the volume of the requirements becomes very large; it is unsurprising to have tens of thousands of requirements collected in multiple levels and categories. It is hard to record and manage these large numbers of requirements simply using paper documents. With large volumes of requirements and complex relationships between requirements—and between requirements and other system elements—it is not possible to depend on simple methods such as paper documents or the human memory to reliably manage the requirements; database-based systems management tools are needed to manage the tremendous amount of information related to requirements, so designers can be released to focus on the design activities. A well-selected systems requirements management tool can significantly increase the efficiency of the sys-tem design project, thus saving time and money for the design 2) From the nature and sources of the requirements, it is not uncommon for a large, complex project for requirements to undergo a constant modification process. Changes may occur at any stage of the system design; as we mentioned in Chapter 2, changes can be frequently initi-ated for a number of reasons—for example, trying to incorporate a new technology, the customers have changed their needs, a new design error is identified, a new environment is required, there are new laws/regulations, and so on. For most of the time, making the changes themselves does not involve too much difficulty; it is the impact of the changes that causes a lot of problems. As we know that system design is driven by requirements, the interrelationships between the design elements are very complicated; making a small change in one can have a significant domino effect: it could cause a series chain reac-tion and have a great impact across the system's hierarchical struc-ture. The process of implementing the inevitable changes must be formalized and strictly controlled. Most of the contemporary require-ments management tools are computer software based in a database structure; thus, they can easily determine the related system elements and their relationships, so that a change proposal will impact within 3. Requirement management provides requirement traceability. Traceability is one of the key characteristics of MBSE. Requirement traceability is concerned with the bidirectional relation-ship between systems requirements, and the evolving relationships between requirements and other system elements, such as system functions and components. Traceability is one of the most important factors to ensure the rationality of the system design; among hundreds or thousands of design activities and efforts, traceability makes sure all these activities are conducted in a well-planned and rational man-ner. Traceability is one of the most important reasons that requirement management is necessary. As mentioned in the requirement collection section (Section 3.3), system requirements come from various sources and in various formats; during the system life cycle, system require-ments will undergo various evolutionary stages, and, eventually, all the requirements will be fulfilled through some kinds of system functions, with some components.

Generally speaking, a good requirement should have the following characteristics:

1.A good requirement is correct. A requirement being correct means that it is technically feasible, legal, achievable (within the organization's capability), and complies with the organization's long-term strategic planning goals. 2.A good requirement is complete in and of itself. In other words, a good requirement statement should contain the complete information that pertains to the requirement itself. 3.A good requirement is clear and precise. The requirement should not contain any ambiguous meanings that cause confusion for the peo-ple who read them. Imprecision arises from a number of reasons in a requirement, including a.The use of undefined terms or unfamiliar acronyms b.The use of imprecise quantifiers and qualifiers c.The use of indefinite sources and incorrect grammar 4.A good requirement is consistent with other requirements. A requirement statement should use the unified language standard, syntax, and glossary across all the requirements for the system, to avoid conflict between requirements. By conflict we mean the writing style and format, not mainly the content. Sometimes, requirements in differ-ent categories have contradicting goals; for example, customers want to cut their costs but also desire more functionality and reliability in the system. These types of contradiction can usually be resolved by conducting a trade study to achieve a break-even point or a balance between the requirements. 5.A good requirement is verifiable. For any requirement we develop, we should always ask this question: Is there any way we can determine that the system meets this requirement or not? If we cannot pro-vide a good answer to this question, then the requirement is consid-ered not to be verifiable. Generally speaking, a requirement can be verified in one of three ways: (1) by inspection for the presence of a feature or function, such as verifying the existence of a functional requirement; (2) by testing for correct functional behavior; for exam-ple, verifying the performance requirements for a certain function; and (3) by testing for correct nonfunctional attributes, such as veri-fying the usability of the system interface. For the requirements to be verifiable, the conditions and states for functional requirements must be clearly specified. For nonfunctional behavior, precise ranges of acceptable quantities must be specified A good requirement is traceable. Any requirement should be upward and downward traceable; we should know where it comes from and where it goes from here. As we mentioned in the system engineer-ing design concepts, systems design is requirement driven, and every requirement has a source, either originating from customers or derived by the design activities based on the customer needs. For this reason, every requirement has a rationale associated with it; that is, we know why there is such a requirement. We can also say that a good requirement is necessary; there are no redundant require-ments, and every requirement can be traced back to its source and is addressed by at least one function, feature, or attribute. If this requirement is not being addressed by any functions, the validity and necessity of this requirement need to be questioned.

The following list provides a general set of guidelines for developing good requirements (Telelogic 2003)

1.Avoid using conjunctions (and/but/or) to make multiple require-ments. Make sure one requirement focuses on one subject at a time. A requirement containing multiple elements might cause confusion and difficulties for verification. 2.Avoid let-out phases, such as "except," "unless," "otherwise," and so on. 3.Use simple sentences. For every requirement that addresses one single aspect of the system, a simple sentence is usually sufficient to express the requirement. Using a simple sentence makes it easier to be understood, thus minimizing any ambiguity. 4.Use limited vocabulary. Ideally, the vocabulary size should be fewer than 500 words. A limited vocabulary is easier for communication and translation into technical language. This is more critical for sys-tems that involve international audiences. 5.Include information about the type of users in the requirements, if possible. 6.A focus on the results is to be provided for the users in the require-ment statement. 7.The desired results/outcomes should be stated in verifiable criteria. 8.Avoid using fuzzy, vague, and general words to minimize confusion and misunderstanding. Examples of such words are "flexible," "fault tolerant," "high fidelity," "adaptable," "rapid" or "fast," "adequate," "user friendly," "support," "maximize," and "minimize." ("The sys-tem design shall be flexible and user friendly" is an example.) Fuzzy words also cause difficulty for verification; for example, if a web page is to be user friendly, what is meant by user friendly? Rather than inserting "user friendly" into the requirement, it is better to rewrite the requirement in a more verifiable way, such as, "the web page shall be completely loaded in less than 7 s for a T1 internet con-nection speed" and "the web page shall enable the user to find the information by exploring no more than 5 levels of categories."

statements of work (SOW) should be developed based on the requirements and structures in the corresponding RFP; usually it includes the following sections:

1.Background of the project 2.Scope of the project 3.Background of the organization 4.Period of performance 5.Technical approach 6.Major milestones and deliverables 7.Evaluation standard and criteria 8.Design team, business personnel, and their qualifications 9.Payment method and schedule

Systems requirements can be categorized into one of the following four major categories:

1.Functional requirements: A system functional requirement usually defines a desired function that the system should provide or a func-tion that the system must carry out. Sometimes, a functional require-ment is also referred as a WHAT requirement; for example, the automated teller machine (ATM) shall enable customers to deposit cash or checks and withdraw up to x dollars at a time from their checking accounts on a 24 h a day and 7 days a week basis. 2.Performance requirements: Unlike functional requirements, perfor-mance requirements specifies HOW WELL the system or systems function shall be performed; for example, the automobile system shall start the engine within 6 s after the driver turns the ignition key under normal weather conditions; the system shall have an operational availability (Ao) of 99.99% .3.Constraint requirements: A constraint requirement provides limitations on the design or construction of the system. Constraint requirements are usually part of the results of system feasibility analysis and stra-tegic planning, regulating the design space and pointing in a certain direction for the design. For example, "The automobile system shall use both grid electricity and B20 biodiesel as the energy source." Verification requirements: Verification requirements are those that define what and how is intended to verify or test the functional requirements or performance requirements for acceptance of the system/components. Verification requirements specify the verifica-tion events, methods, and procedures to prove the satisfaction of the system requirements. Usually, systems functional requirements and performance requirements contain the verification criteria within the requirements themselves. If there is a special need for the veri-fication, or a unique verification method/technology to be applied, the verification requirements need to be defined. Slightly different from the functional requirements and performance requirements, a verification requirement contains four basic elements: a verifica-tion objective, a verification method (inspection, analysis, test, or demonstration), the verification environment, and success crite-ria. For example, system operational availability shall be calcu-lated using the definition given by MIL-STD-721, conducted by a government-certified contractor; the demonstration shall show that the system, under the defined operational environmental condi-tions, shall have an operational availability of at least 99%.

A use case analysis includes three elements: identification of the actors, a list of the system actions, and the interaction relationship between the actors and sys-tem actions; a use case diagram is developed to illustrate these three elements.There is no standard procedure to develop a use case; it varies with differ-ent systems. A commonly used method includes the following steps:

1.Identify the actors and their goals. 2.Define the scenarios to achieve the goals. The scenario is described as a numbered list of steps that involves both actors and system (subsystem or system components) to achieve the goals. Each step is written as a simple straightforward statement of the interaction between the actors and the system .3.Make notes of extension of the use case: extension is the condition that results in different courses of actions or alternatives from the normal course of actions.

Some key points need to be kept in mind for an effective process of require-ment capture and collection. These key points are essentially nontrivial for large, complex system design, as there are hundreds and even thousands of requirements involved in the design. These key points include

1.Identify the stakeholders for the system. 2.Identify the requirement sources with users' involvement. 3.Apply a variety of data collection techniques. 4.Use a computer-based software tool to document and manage the requirements.

Major activities of requirement analysis

1.Rewrite the user original requirements into the correct syntax for-mat, the "shall" statement; make sure all requirements are written in a way that is clear, complete, verifiable, and unambiguous. 2.Organize the requirements into different categories and hierarchies; map the requirements to systems architecture; derive the require-ments that are not included in the original requirements using appropriate design models. 3.Perform trade-off studies to prioritize the requirements, ranking them so that the most critical requirements are given more attention in the design. 4.Document and record requirements using requirements manage-ment tools, establish semantics for relationships, and provide ratio-nality and traceability for each requirement.

shall statement

A SHALL statement is different from should, would, and may statements; it means that it is mandatory and contractually binding for this need; as a requirement, the designed system must comply with it. The other words, such as may or would statements, usually convey options to the designers; the strength of these statements is not as strong as the SHALL statement.

what are debris in core parser

All the requirements recognized are marked and num-bered, and other statements are marked as "debris" to separate them from the requirements. These debris statements may contain text that is appli-cable for refining the requirements. For more details, readers can refer to the CORE user manual (guided tour) and resource library at www.vitechcorp.com.

Request for proposal ( RFP)

An RFP is commonly used for government system acquisition and development.An RFP is a formal document that an organization issues to invite the potential vendors/developers/contractors to bid for the project.

What is a affinity diagram

An affinity diagram is a tool to organize a large set of captured requirements into a hierarchical structure based on their relationships. For thousands of years, people have been grouping different things into a limited set of cat-egories, but it was not until the 1960s that the term was first used and a process was developed by the Japanese anthropologist Jiro Kawakita. The affinity diagram is also called the KJ diagram for that reason. The affinity diagram is a good way to consolidate different ideas into a well-organized structure. It is well suited for RA with large amounts of col-lected data; especially after the interviews, focus groups, and brainstorming sessions, there are usually many difficulties processing the data collected.

One important aspect of SA is to translate users' requirements into quantita-tive technical performance measures (TPMs). Since all requirements are not equally important for the system, it is critical to prioritize the requirements, ranking them in order, so that the most important features are given more attention. Why are they a good tool

An excellent tool to aid in the establishment and prioritization of the TPMs that relate to requirements is quality function deployment (QFD). QFD originated in Japan and was first introduced at the Kobe shipyards of Mitsubishi Heavy Industries in 1972 (Shillito, 1994). The need for QFD was driven by two related objectives (Revelle et al. 1998). These objectives started with the users (or customers) of a product and ended with its producers.

what is use case

Another method used commonly in SA is use case analysis. Unlike the scenario, which focuses more on user tasks, use cases concentrate on the interaction between users and systems. Use cases were originally developed in the software engineering industry, in the object-oriented-design commu-nity. In UML-based software design, the use case diagram is used to model the dynamic part of the system, to describe the system behavior by defining the relationships between the users (actor) and system/subsystem elements. As indicated by its name, a use case in system engineering is a sequence or list of action steps, allowing users and systems to interact. A use case is asso-ciated with actors; actors are the users of the system, through proper interac-tion, and they achieve their goals through use case actions. One use case is usually defined for one system function, this function could be a normal use of the system, or a maintenance function for handling system failure. Besides system functional model development, use case analysis also provides a starting point for deriving requirements for system interface design, as use case specifies the boundary between the users (actors) and the system itself. For more information, please refer to Booch et al. (2005). for a more in-depth introduction to UML design methodology, including use case analysis.

document parser

Document Parser is user friendly and efficient for importing require-ments directly from a document; it will recognize the statements that contain "shall," "will," or "must" from the text and automatically organize them into different requirement elements, which makes it easy for designers to review and edit them. It has also the ability to link to the "Document" elements where the original document is linked, thus facilitating the establishment of traceability among elements. To use "Document Parser", click on "Tools" from the main menu and then choose "Document Parser". Load the document file that you want to import; the file will be loaded into the left-hand pane in the Document Parser, as seen in Figure 3.6.

As one of the most impor-tant functions in the requirements management tool, each requirement is documented and its relationship within the body of requirements and between other system components will be established and recorded. For example,

For example, within the requirement body, high-level original requirements may be refined by detailed lower-level requirements that are most likely derived from design teams or decision-making models (sometimes this is called horizontal traceability, since they occur within the requirement body itself); every requirement is a basis for at least one system function, and documented by some external sources (or vertical traceability). In the next section, we will give an example of how to use CORE by Vitech Corporation to develop this relationship. One has to keep in mind that these traceability relationships are usu-ally bidirectional. For example, high-level requirements are refined by lower-level requirements; at the same time, lower-level requirements refine the high-level requirements. Which term to use is dependent on the perspective in which the traceability relationship is looked at. Traceability is documented using the relationship links within the requirement management tool, and these are attached to each require-ment for the lifetime of the system. Traceability can be presented by means of a traceability matrix, a hierarchical flow chart, reports, and tables, based on the needs of the analysis

chapter 3 summary

In this chapter, we examined systems requirements in greater detail. As mentioned many times in Chapter 2, requirements are the driving forces of systems design; spending time and effort to develop a good complete set of system requirements can save designers time, cost, and effort in the long run. In this chapter, the syntax of the requirement was defined and the nature of system requirements and their categorization were given in greater detail. Commonly used categories for requirements include functional require-ments, performance requirements, constraint requirements, and verification requirements. The characteristics of a good requirement were given to show how to write a good requirement. Generally speaking, a good requirement shall be correct, complete, clear and precise, consistent with other require-ments, verifiable, and traceable. Some general guidelines may be utilized for writing requirements; this was followed by several examples of well-written requirements. In the second section of this chapter, we reviewed the techniques for captur-ing requirements, including the sources of requirements, the RFP structure, user interviews, surveys and questionnaires, observations, study of docu-ments, standards, critical incident/accident reports, and the study of similar systems. Each technique was reviewed in detail, and their advantages and disadvantages were presented, for us to use the right technique for the right set of requirements. A large portion of the chapter was devoted to the methods and models for RA. Major activities in RA were reviewed, and three models that are com-monly used in RA were presented, including affinity diagram, scenarios, and use cases, and finally QFD. For each of the techniques, examples were given to illustrate the application of the technique in RA. In the last section of the chapter, requirement management was briefly introduced. Requirements management is essential for the success of the system design, as it efficiently organizes the large volume of requirements, enables an effective and controlled process for requirement changes, and, most importantly, provides traceability within the system life cycle, which makes design efforts more effective and easy to understand. Examples using CORE were given at the end to show how a software tool can be utilized to implement management of the requirements.

A typical request for proposal (RFP) includes

Introduction. • Organization background: Describe the background of the orga-nization or company who is issuing the RFP .• Statement of purpose: Define the mission for the project; solicit proposals to meet these mission requirements and describe detailed proposal requirements; outline the general process for evaluating proposals and selecting criteria .• Scope of the system and terms/conditions: Define the scope of the system to be developed; specify any terms and conditions that are related to the life cycle and payment for the system. • Other related issues: Communication, coverage and participa-tion, ownership agreement, disclosure and extension, any legal disclaimers, and so on .• Communication information: Point of contact (POC) informa-tion, phone/fax number, email address, and so on. Technical requirements. • This section defines the background of the system to be acquired and the technical objectives that are to be achieved by the system. Information on project deliverables are specified and technical measures are provided to measure system success. If the system is part of a larger system, the preferred technical approach and desired interface with other systems are also specified; these will identify the limitations to the technological approach .• The format of the proposal to bid on the RFP should be explained in detail, including major sections, page limits, and page formatif desired (such as font type, font size, line space, page mar-gins, etc.). Many organizations publish their own standard for proposals, such as the DoD and the National Aeronautics and Space Administration (NASA), which have their own proposal guidelines, with which every proposal to is required to comply. Usually, a link to these guidelines is provided in the RFP for the proposers to follow. Business requirements: This section specifies the major milestones of the deliverables, the expected budget of the project, and the dead-lines for the submission of the proposal. Evaluation criteria: Describe the major criteria that will be used to evaluate the proposal and the number of awards expected for this project. Typical evaluation criteria include technical capabil-ity of the proposer's organization, technical soundness of the pro-posed solution/design, economic feasibility of the proposed budget, overall project management and control, and personnel qualifica-tion. Sometimes a points system is used to compare the competing proposals.

there are many requirements management software commercially avail-able; some of the most popular ones include

Rational DOORS and Rational RequisitPro by IBM (previously DOORS by Telelogics), and CORE by Vitech Corporation. For a complete list of the requirements management tools available, please refer to the INCOSE requirement management tool survey, sponsored by the INCOSE Tools Database Working Group (TDWG). The list is published and constantly updated on the INCOSE website (http://www.incose.org/productspubs/products/rmsurvey.aspx).

what is a scenario

Scenarios and use cases are not mutually exclusive; they are often used in combinations to cap-ture different perspectives of the system's behavior, and are also applied in different stages throughout the system life cycle. A scenario is an informal description about how the system will be used by users. By understanding and compiling the requirements collected, sys-tem designers develop scenarios to tell a story about user task activities and systems functions, to explore and discuss any potential issues with the intended use of the system described. A scenario is usually written in plain narrative language, providing a natural way for system users and stakehold-ers to understand how the system will fulfill their needs. The focus of the scenario is user tasks and system responses, together with information nec-essary to describe the tasks, including environmental conditions, context, and any technological support information. The scenario provides a natural way for explaining to the stakeholders what will be designed and how the systems will be used, facilitating com-munication between the users and designers, providing a good starting point for users to understand, and exploring the intended functions, context, and constraints, identifying any missed requirements and misunderstand-ings between the users and designers.

The procedure of conducting an affinity diagram analysis is quite straight-forward; with all the data collected, all you need are cards or sticky notes, a pen, and a large surface (a board, wall, or table) on which to place the cards. (5 steps)

Step 1: Generate and display ideas. Record each requirement with a marker pen on a separate card. Randomly spread all the cards on the work surface so all cards are visible to everyone. The entire design team gathers around the cards and moves on to Step 2 .• Step 2: Sort and group ideas. It is very important that every indi-vidual member works on his/her own in this step; no collaboration/ conversation/discussion is allowed. Every member takes time to look for the requirements that are related to each other in some way. Put all related cards in the same group and repeat until all cards have been considered. Note that a single-card group is allowed if this par-ticular card does not fit into any other groups; if cards belong to mul-tiple groups, make duplicates for those cards so that a copy can be placed in every group. Any member of the team may move a card to a different group if he/she disagrees with where it is currently placed. After all the members have done the grouping, move on to Step 3. • Step 3: Agree on and create groups. It is now time for the team mem-bers to discuss their grouping results and the structure of the group-ing diagram. By solving any potential conflicts and disagreements between the different members, changes can be made to the final grouping results. Repeat the process until a consensus has been achieved. When all the requirements are grouped, select a heading for each group and place it at the top of the group. • Step 4: Subgrouping. Repeat Steps 1-3 on a large group to develop subgroups, or combine groups into "supergroups" if desired .• Step 5: Document and record the final group structure.

Requirement syntax

System (or subsystem) XYZ+SHALL+verb (action)+desired out-come/performance level+operational/environmental conditions

what is the procedure to develop a scenario

The procedure to develop a scenario is quite straightforward; it requires the designers to understand the requirements and the existing behaviors involved for such a system. Based on their understanding, designers describe a story of the system usage from the users' standpoint, either in a first-person or a third-person perspective. Note that, in the above example, all the verbs have been italicized; as we mentioned earlier, the scenario provides a starting point for requirements to be analyzed, and, eventually, system requirements need to be translated into functions and functional structure.

what is the purpose of requirements management

The purpose of requirements management is to assure a well-documented requirements body, recording the necessary information pertaining to each requirement, including its sources, origins, types, rationale, and TPM, and establishing the integral hierarchical structure among the requirements, to trace, verify, and meet the needs and expectations of its users, customers, and internal or external stakeholders. As part of the project planning efforts, requirements management begins with the analysis and elicitation of the objec-tives, the constraints of the systems, and the missions of the organization. After requirements are collected and initially analyzed, requirements management then provides planning for requirements so that they can be translated and ver-ified in the design, standardizes the format, and records the attributes for each requirement, integrating requirements with the organization and document-ing the relationship with other information delivered against requirements. For example, a lower-level requirement refines the higher-level requirements, an external file documents the original sources of the requirement, and all requirements are the basis for particular system functions.

There are three basic structural techniques used to analyze and structure qualitative data in QFD. These tools are used to build a matrix of customer information and product features/measures.

The voices of customers, are gathered by observations and interviews, which are then organized to con-struct a tree diagram. Then, the same procedure is used to generate product features and mea-sures, also called the voice of the company (VOC). These measures are also arranged into a tree diagram. The two trees are then arrayed at right angles to each other, so that a matrix diagram can be formed in the middle. This matrix provides a structure to systematically evaluate the relationship between the items in both dimensions. The relationship between rows and columns can then be coded by symbols. The intersections of the two trees form a matrix that serves as the basis for constructing the first QFD matrix, termed the house of quality (HOQ).The HOQ is a structured communications device. Obviously, it is design oriented and serves as a valuable resource for designers. Systems engineers may use it as a way to summarize and convert requirements into design specifications. The HOQ, through customer needs and competitive analysis, helps to identify the critical technical components that require change. The critical issues will then be driven through other matrices to identify the most important aspects, manufacturing operations, and quality control measures to produce a product that fulfills both customer and producer needs within a shorter development cycle time. Figure 3.3 shows the structure of this matrix.The next vital step is to complete the relationship matrix of user voices ver-sus design features. The final analysis stage relies heavily on the use of the relationship symbols at the intersections of WHAT and HOW. Specifically, we are looking for direct relationships in which the design features sat-isfy the user voices.

Why is requirement analysis (RA) important and the purpose

There are often huge differences between user-statement requirements and real system requirements; the real system requirements are based on the original user requirements, but user-statement requirements cannot design the system themselves; usually, they are incomplete, vaguely stated, in users' naïve lan-guage, and, sometimes, controversial in nature. These users' requirements need to be organized, filtered, translated, expanded, and formatted into a complete, technically sound, and accurate set of system requirements to be implemented. This translation process, often referred to as the requirements analysis (RA), usually occurring in the early design stages, is most critical for understanding the needs of the customer and forming a foundation for proper communication between designers and customers The purpose of RA is to prepare the requirements for the next step of the system design, which is functional analysis. The results of RA will facilitate the translation from system requirements to system functional structure; they serve as the bridge between users' language and designers' technical language. The most commonly used methods used in RA include affinity diagrams, scenarios, use cases, and QFD.

generally speaking, what is requirements management

is a process of documenting, categorizing, analyzing, tracing, and prioritizing the system requirements into a structured database, enabling effective communication between requirements and other elements of the system design and controlling changes to requirements. Requirements man-agement is a continuous process throughout the design process; its primary concern is to effectively control information integration related to systems requirements and to maintain the integrity of the requirements for the sys-tem life cycle.

In the context of systems engineering, traceability refers to

[the] ability to describe and follow the life of a requirement, in both forward and backward directions (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of ongoing refinement and iteration in any of these phases). (Gotel and Finkelstein 1994)

NTI, individual rating, and maximum individual formula

found on page 99 of chapter 3

There are many ways to rate the importance of the requirements; for example

one can simply have users rank all the requirements in order. For a small number of requirements without many levels of structure involved, the simple ranking method might work well; however, if the volume of the requirements becomes large and involves many hierarchical structures (such as user requirements, usability requirements, functional requirements, envi-ronmental requirements, etc.), it is difficult for users to rank them at the same time across different categories. It is simply beyond human cognitive capa-bility to do so; we need to rely on some kind of mathematical model to aid the decision-making process

There are also some other types of categorization; for example, depending on the sources, requirements can be classified a

s originating requirements (those that come directly from customers), derived requirements (require-ments obtained from RA to further refine the originating requirements), and design decision requirements (not explicitly from customers, but from the design team analysis results, necessary for fulfilling customer require-ments). Based on the group of people involved, requirements may be clas-sified as end-user requirements, management/business requirements, or maintenance/support requirements.

As shown in the above three equations, the individual rating reflects

the overall importance of a design feature after taking into account its relative importance and the user self-stated-importance rate. Critical features can be singled out based on the individual rating obtained. The NTI rating uses the ratios of the individual ratings over the maximum individual ratings to facilitate the identification process.

SDL is built on an element-relationship-attribute (ERA) schema, augmented by graphical structures with semantic meanings that include

• Element: An element in CORE corresponds to the design objects/enti-ties. For example, requirements, functions and components are all elements. An element is defined by using an English-language noun. • Relationship: A relationship defines a link between two elements; it is a binary, two-way relation between two design elements. For example, requirement X is a basis for function Y, and by the same token function Y is based on requirement X. CORE establishes and maintains this two-way communication link automatically once one direction of the relationship is specified by the user .• Attribute: An attribute is associated with an element; it defines the element further by specifying its critical properties. Attributes are like adjectives modifying nouns (elements); they are defined together with the element. For example, a requirement's name, number, and type are all attributes of the requirement element.

QFD is an interdisciplinary team process to plan and design new or improved products or services in a way that (Shillito, 1994)

• Focuses on customer requirements • Uses a competitive environment and marketing potential to priori-tize design goals • Uses and strengthens interfunctional teamwork • Provides flexible, easy-to-assimilate documentation • Translates general customer requirements into measurable goals, so that the right products and services are introduced to market faster and correctly the first time

The final analysis stage relies heavily on the use of the relationship symbols at the intersections of WHAT and HOW. Specifically, we are looking for direct relationships in which the design features sat-isfy the user voices. There are four types of symbols used in coding these relationships:

⦿Very Strong (8) ●Moderate (6) ○Weak (4) △Very weak (2) Based on the relationship identified, the last step of HOQ analysis is cal-culation of the weightings for the design features. A commonly used tra-ditional deterministic model uses normalized technical importance (NTI) ratings to identify critical characteristics