Software Requirements (2nd edition) Practical techniques for gathering and managing requirements throughout the product development cycle	Cat: ICT Pub: 2003 #0818
	Karl E. Wiegers	08823u/18122r

Title	Software Rquirements	ソフトウェア要求
Index	Introduction: The Essential Software Requirement: Requirements from the Customers' Perspective: Good Practices for Requirements Engineering: Requirements Analyst: Establishing the Product Vision and Project Scope: Finding the Voice of the Customer: Hearing the Voice of the Customer: Understanding User Requirements: Playing by the Rules: Documenting the Requirements: A Picture is Worth 1024 Words: Beyond Functionality: Software Quality Attributes: Risk Reduction Through Prototyping: Setting Requirement Priorities: Validating the Requirements: Special Requirements Development Challenges: Beyond Requirements Development: Requirements Management Principles and Practices: Change Happens: Links in the Requirements Chain: Tools for Requirements Management: Improving Your Requirements Process: Software Requirements and Risk Management:	序: ソフトウェア要求は必項: 顧客視点からの要求: 要求工学のための良き実践: 要求アナリスト: 製品ビジョンとプロジェクトスコープの確立: 顧客の声を見つける: 顧客の声を傾聴する: ユーザ要求を理解する: ルールを遵守する: 要求を文書化する: 千語は一図にしかず: 機能を超えたソフトウェアの品質特性: プロトタイプによるリスク低減: 優先的欲求を設定する: 要求を検証する: 特別な要求開発への挑戦: 要求を超えた開発: 要求管理の原則と実践: 変化は起こる: 要求チェインでのリンク: 要求管理のためのツール: 要求プロセスを改善する: ソフトウェア要求とリスク管理:
Key	Requirements Engineering BPM (Business Process Management)	要求工学 BPM
Why?	As a member of BPMS (Business Process Management System) Study Group organized in 2008, this is recommended as a reference book, which includes basic concepts and terms about the latest BPM.	2008年に結成されたBPMS研究会のメンバーの一人として本書を参考書として推奨された。本書には、BPMの基礎概念と用語が記載されている。

Résumé

Remarks

>Top 0. Introduction: Lack of user input, incomplete requirements, and changing requirements are the major reasons why so many information technology projects fail to deliver all of their planned functionality on schedule and within budget. Software development involves at least as much communication as computing. Learning about new practices is easy; actually changing the way people work is much harder.

0. 序章: 多くのITプロジェクトが計画通りの機能を期日までに予算内で実現できないかの主要な原因は、ユーザからの入力不足、不完全な要求、変化する要求にある。 ソフトウェア開発では、コミュニケーションはコンピューティングと同じくらい重要である。 新たな実践を学ぶのは易しいが、それを実際に人にやらせるように変えるのは遙かに難しい。

>Top 1. The Essential Software Requirement: Relationship of several types of requirements information: Business requirements: high-level objectives of the organization User requirements: include use cases, scenario descriptions, and event-response tables. System Requirements: include both software and hardware subsystems. People are a part of a system, too. Functional requirements: software functionality; shall statements; documented in a SRS (Software Requirements Specification)	1. ソフトウェア要求は必須: 要求情報のさまざまなタイプ <左図> まず機能的要求と非機能的要求に分ける。 機能的要求 ビジネス要求 ユーザ要求 システム要求 機能要求 非機能的要求 ビジネスルール 品質属性 外部インターフェース 制約条件
Requirement Engineering Domain: Elicitation: Analysis: Specification: Validation	ソフトウェア要求仕様 (SRS) 要求工学のドメイン 要求仕様を作成する要求開発とその要求仕様の管理に分離: 聞き出し 分析 仕様化 検証
The boundary between requirements development and requirements management: Requirement Development: Iteration is a key to requirements development success; refining high-level requirements into details, and confirming corrections with users. This takes time but it's an intrinsic aspect of dealing with the fuzzy uncertainty of defining a new software product. Requirement Management: Customer acceptance is only half the equation needed for requirements approval. The developers also must accept the specifications and agree to build them into a product.	要求開発と要求管理の境界: 要求工学では反復がキーワード。高度な要求はユーザとともに反復的に確認しながら詳細化していく。 分析 文書化 吟味 交渉 反復は肝要 要求管理では、顧客が了解することは要求承認のまだ半分に過ぎない。開発者はその仕様を実際に製品に反してこそ実現される。 仕様変更による手戻りコストは、時期により大きく異なる。手戻りは開発コスト全体の30-50%にもなる。また手戻り開発の70-85%は要求の誤りに依る。
Relative cost to correct a requirement defect depending on when it is discovered. The major consequence of requirements problems is rework. Rework can consume 30 -50% of your total development cost, and requirements errors account for 70-85% of the rework cost. It costs far more to correct a defect that's found late in the project. Most common requirements risks: insufficient use involvement: working with users isn't as much fun as writing code or because they think they already know what the users need. creeping user requirements: users' frequent requests for changes in the requirements and partly in the the way that developers respond to these requests. ambiguous requirements: ambiguity is the great bugaboo of requirements specification. gold plating: often users don't care about this excess functionality. minimal specification: managers are tempted to create a limited specification. overlooked user classes: some user needs won't me met. inaccurate planning: off-the-cuff guess	use <慣習 case <出来事、特定の場合 function <宗教的儀式、肉体的精神的活動 Cf: defunct vision <幻影 attribute <帰属 constraint <拘束 elicit <引き出す <lace 組紐 manage <menage 調教 develop < unwrap 広げる require 頼む < re+seek shall < obliged, owe iterate <繰り返して言う <do again intrinsic <内部の、内因性の accept < take a person or a thing of one's self <captive123 deficate <清める、排便する <de+faeces bugaboo <bug お化け <Cf bugger 異端

>Top 2. Requirements from the Customers's Perspective: Who is the customer? Requirements Bill of Right for software customers: You have the right to: expect analysts to speak you language: use your business vocabulary. You shouldn't have to wade through computer jargon. have analysts learn about your business and objectives: Consider inviting developers to observe what you do on the job. expect analysts to write a software requirements specification: The analyst will sort through all the information that you provide to distinguish use cases from business requirements, business rules, functional requirements, quality goals, solution ideas, etc. receive explanations of requirements work products: Sometimes graphics are a clearer medium for expressing some aspects of system behavior, such as workflow. expect analysts and developers to treat you with respect: Working together can open the eyes of both groups to the problems each group faces. hear ideas and alternatives for requirements and their implementation: A creative analyst also adds value by ;proposing ways that new software can provide capabilities that customers haven't even envisioned. describe characteristics that make the product easy to use: The analysts should inquire about the specific characteristics that mean use-friendly, robust, or efficient to you. be given opportunities to adjust requirements to permit reuse: Some requirements flexibility is essential if you want to incorporate on-the-shelf components (COTS) into your product. receive good-fat estimates of the costs of changes: developers must not inflate the estimate cost of a change just because they don't want to implement it. receive a system that meets your functional and quality needs: Be sure to state all your assumptions or expectations.

2. 顧客視点からの要求: 顧客は誰なのか？ 顧客には以下の権利がある。 ビジネス用語で話す 業務知識を理解 ソフトウェア要求を記載 製品の図での説明 共同制作の理解者 付加価値を提案 使いやすいシステム ソフトウェア部品活用 適性な価格見積 機能を満たすシステムの受注

Requirements Bill of Responsibilities for software customers: You have the responsibility to: educate analysts and developers about your business: Don't expect analysts to grasp the nuances and implicit aspects of your business. spend the time to provide and clarify requirements: Your have a responsibility to invest time in workshops, brainstorming sessions, interviews, and other requiemnts-elicitation activities. be specific and precise about requirements: It's fine to temporarily include TBD (to be determined) markers in the SRM to indicate that additional research, analysis, or information is needed. make timely decisions: The developers often can't proceed with confidence until you render your decision, so time spent waiting for ana answer can delay progress. respect a developers's assessment of cost and feasibility: Some features that yo want included might not be technically feasible or might be surprisingly expensive to implement. set requirement priorities: The decision makers will have to elect whether to reduce project scope based on priorities, extend the schedule, provide additional funds or people,or compromise on quality. review requirements documents and evaluate prototypes: Your feedback on these preliminary, partial, or exploratory implementations provide valuable information. Recognize that a prototype is not a working product. promptly communicate changes to the requirements: Change is inevitable, but he later in the development cycle a change is introduced, the grater its impact. follow the development organization's change process: Follow the project's defined change control process. This ensures that requested changes are not lot. respect the requirements engineering processes the analysis use: Although you might become frustrated with the requirements act ivies, the time spent understanding requirements is an excellent investment. What about sign-off? Many organizations use the concept of signing off on the requirements document as the mark of customer approval of those requirements. Don't use sing-off as a weapon. Use it as a project milestone, with a clear , shared understanding of the activities.

顧客には以下の義務がある。 業務内容を理解させる 明確な要求作成に時間をかける 要求は具体的で精緻であること タイムリーな意思決定を行う 開発者の見積を尊重する 要求に優先度をつける 要求文書を審査し、プロトタイプを評価する 変更は速やかに通知する 組織的な変更プロセスに従う 要求工学プロセスを尊重する 発注者の捺印の意味は？ 顧客による捺印の意味： 捺印文書は武器ではない。それはプロジェクトのマイルストーンであるべき。 Bill of Rights: 権利章典 wade ぬかるみを歩いて渡る; 渉禽 subjective <個人的　<主観的 sign 紋章、兆候、奇跡< mark (with the sign of the Crosss) sign-off = announce the end of communicaiton, esp. a broadcast; stop talking, become silent

>Top 3. Good Practices for Requirements Engineering: The notion of best practices is debatable; who decides what is "best" and on what basis? One approach is to convince a body of industry experts or researchers to analyze projects from many different organizations. These practices aren't suitable of every situation, so use good judgment, common sense, and experience instead of ritualistically following a script.

3. 要求工学のための良き実践: ベストプラクティスというより実践的なチェックリスト

Requirements Engineering Good Practices: Knowledge Requirements Management Project Management Train requirements analysis Educate user reps and managers about requirements Train developers in application domain Create a glossary Define change-control process Establish change control board Perform change impact analysis Baseline and control versions of requirements Maintain change history Track requirements status Measure requirements volatility Use a requirements management tool Create requirements traceability matrix Select appropriate life cycle Base plans on requirements Renegotiate commitments Manage requirements risks Track requirements effort Review past lessons learned Requirements Development Elicitation Analysis Specification Validation Define requirements development process Define vision and scope Identify user classes Select product champions Establish focus groups Identify use cases Identify system events and responses Hold facilitated elicitation workshops Observe users performing their jobs Examine problem reports Reuse requirements Draw context diagram Create prototypes Analyze feasibility Prioritize requirements Model the requirements Create a data dictionary Allocate requirements to subsystems Apply Quality Function Deployment Adopt template Identify sources of requirements Uniquely label each requirement Record business rules Specify quality attributes Inspect requirements documents Test the requirements Define acceptance criteria

>Top 4. The Requirements Analyst: Synonyms for Requirements Analyst: Requirements analyst Requirements engineer Requirements manager Business analyst System analyst Analyst The analyst is a communication middleman, bridging the gap between vague customer notions and the clear specifications that guide the software team's work. with Project Sponsor: business requirements with Project Management: size and complexity information with User Representatives: user requirements with Other Stakeholders: expectations and constraints with Development: functional and nonfunctional requirements with Testing: functional and nonfunctional requirements Information-gathering techniques: Interviews Facilitated requirements workshops document analysis Surveys customer site visits business process analysis Event lists competitive product analysis Reverse engineering of existing systems Retrospectives performed on the previous project Essential analyst skills: Listening skills: active listening involves eliminating distractions, maintaining an attentive posture and eye contact, and restating key points to confirm your understanding. Interviewing and questioning skills: become skilled in the art of asking questions that reveal and clarify uncertainties, disagreements, assumptions, and unstated expectations. Analytical skills: critically evaluate he information gathered from multiple sources to reconcile conflicts, separate user "wants" from the underlying true needs, and distinguish solution ideas from requirements. Facilitation skills: can help a group build trust and improve the sometimes tense relationship between business and information technology staff. Observational skills: Can detect subtleties that the user might not mention. Strong observational skills sometimes expose new areas for elicitation discussions, revealing additional requirements that no one has mentioned yet. Writing skills: needs a solid command of the language and the ability to express complex ideas clearly. Organizational skills: coping with rapidly changing information and structuring all the bits into a coherent whole demands exceptional organization skills and the patience and tenacity to make sense from ambiguity and disarray. Modeling skills: tools ranging from the venerable flowchart through structured analysis models (DFD, ERD) to contemporary UML notations should be part of repertoire. Interpersonal skills: often mentor their new colleagues, and they educate their customer counterparts. Creativity: conceive innovative product capabilities, imagine new markets and business opportunities, and think of ways to surprise and delight their customers.

4. 要求アナリスト: 要求アナリストの同義語 要求アナリストはコミュニケーションの仲介者である。あいまいな顧客の要求を明解なソフトウェア仕様につなげる役目 情報収集技術 インタビュー ファシリテーション 文書分析 調査 顧客サイト訪問 ビジネスプロセス分析 イベントリスト 競合製品分析 リバースエンジニアリング 過去の実績プロセスからの教訓 必要な分析スキル: 聴取スキル 質問スキル 分析スキル 促進スキル 観察スキル 記録スキル 組織スキル モデル化スキル 教育スキル 創造力 retrospect <7　<look back distract <気をそらせる→引き裂かれた <distrait 気が狂った reconcile <和解、調停、調和、黙認させる subtle < 洞察力ある；密かに事を行う command <神のお告げ；命令；言語を自在に駆使する能力 disarray < 乱す<dis + array隊列 repertoire - repertory 上演目録 Mentor <Odysseusの友人で後事を託された。 conceive <妊娠する、心に抱く

>Top 5. Establishing the Product Vision and Project Scope: The user requirements and software functional requirements must align with the context and objectives that the business requirement establish. Vision and scope document template: Business Requirements 1.1 Background 1.2 Business Opportunity 1.3 Business Objectives and Success Criteria 1.4 Customer or Market Needs 1.5 Business Risks Visions of Solution 2.1 Vision Statement 2.2 Major Features 2.3 Assumptions and Dependencies Scope and Limitations 3.1 Scope of Initial Release 3.2 Scope of Subsequent Releases 3.3 Limitation and Exclusions Business Context 4.1 Stakeholder Profiles 4.2 Project Priorities 4.3 Operation Environment Vision Statement: For (target customer) Who (statement of the need or opportunity) The (product name) Is (a product category) That (key benefit, compelling reason to buy or use) Unlike (primary competitive alternative) Our product (statement of primary differentiation)

5. 製品ビジョンとプロジェクトスコープの確立 ユーザ要求とソフトウェア機能要求とは、ビジネス要求が求める状況と目的において一致しなければならない。 ビジョンと展望文書の例 ビジネス要求 1.1 背景 1.2 ビジネスの機会 1.3 ビジネスの目英と成功条件 1.4 顧客および市場ニーズ 1.5 ビジネスリスク ソリューションのビジョン 2.1 ビジョン表 2.2 主な特長 2.3 前提条件 範囲と制限 3.1 初版の範囲 3.2 続版の範囲 3.3 制限および除外範囲 ビジネスの状況 4.1 株主の概要 4.2 プロジェクト優先度 4.3 運用環境 assumption <聖母マリアの昇天→前提 feature <容貌→特長 profile < draw a line 横から見た輪郭

>Top 6. Finding the Voice of the Customer: Customer involvement is a critical factor: Identify the different classes of users for you product. Identify sources of user requirements. Select and work with individuals who represent each user class and other stakeholder groups. Agree on who the requirements decision makers are for your project. A hierarchy of stakeholders and users: Don't overlook indirect or secondary user classes. They might not use your application directly, instead accessing its data or services through other application or through reports. Your customer once removed is still your customer. User class need not be human beings. Other applications interact with your system. Identify and characterize the different user classes for your product early in the project so that you can elicit requirements from representatives of each important class. "Expand Then Contract" technique. Product champions: have a clear vision of the new system and are enthusiastic about it because they see how it will benefit hem and their peers. multiple product champions: each one can spend several hours per week working on the project. Product champion traps: a senior user might nominate a less experienced user as champion because he doesn't have time to do the job himself. This can lead to backseat driving from the senior user who still wishes to strongly influence the project's direction. The voiceless user class: A power user may specify usability requirements that are great for experts, but 90% of users who are not experts may find the system unintuitve and difficult to learn. Who makes the decisions? The customer is not always right. The customer always has a point, though, and the software team must understand and respect that point.

6. 顧客の声を見つける: 顧客を引き込むことは必須要因 ユーザの階層分け ユーザ要求の源を特定する 各ユーザ階層および他のステークホルダ群を代表する個人を選択する 要求の意志決定者と合意する ステークホルダ・ユーザの階層構造: 補完的な階層も無視しない 他アプリとの関係も考慮 対象を広げてから集約する技術 製品チャンピオン: 新システムに対して明解な見解と情熱を持っている理解者のこと 複数の製品チャンピオンがあり得る 製品チャンピオンの落とし穴: シニアユーザが多忙のゆえに代理を立ててリモートで管理するケース 声なきユーザ層: 90%の声なき一般ユーザの声に配慮 誰が意思決定するのか: 顧客はいつも正しいとは限らないが、指摘点は理解して対応すること

>Top 7. Hearing the Voice of the Customer: The heart of requirements engineering is elicitation, the process of identifying the needs and constrains of the various stakeholders for a software system. Skills in conducting elicitation discussions comes with: experience training in interviewing group fasciculation conflict resolution probing beneath the surface of the requirements asking why several times asking open-mind questions inquiring possible variations asking questions that begin with: What else could ... What happens when ... Would you ever need to ... Where do you get ... Why do you (don't you) ... Does anyone ever ... documenting the source of each requirement Establish ground rules*: Stay in scope: the facilitator will have to reel in the elicitation participants periodically too keep them on topic. preliminary sketches can be helpful to illustrate how you might implement the equipments. Use parking lots to capture items for later consideration: an array of random but important information will surface*: quality attributes, business rules, user interface ideas, constraints,.. Organize this information on flipcharts*, or parking lots. Timebox* discussions: allocate a fixed period of time to each discussion topic, say 30 min per use case. timeboxing helps avoid the trap of spending far more time than intended on the first topic. Keep the team small and include the right participants: 5-6 active participants: with knowledge, experience, and authority to make decisions. Keep everyone engaged: read the body language, understand why someone has turned out of the process, and try to bring the person back.

7. 顧客の声を傾聴する: 要求工学の中心はいかに聞き出すかである。 聞き出すためのスキルとしては まず経験 インタビュー訓練 グループファシリテーション 意見衝突解決 要求の言外の意味探査 何回も確認する理由 虚心坦懐に質問する 以下のような質問を行う： 他にできないか こういう場合はどうするか こういう必要はなかったか どこが目標なのか なぜそうするのか、あるいはそうしないのか 誰かそのようにしたのか 各質問に対しては記録残す その場所だけローカルルールの確立 全体を視野に入れる 聞き取り対象者から定期的にヒアリング システム概況スケッチは役立つ 後で検討するため取りあえず未解決項目とする 但し重要事項は浮上 時間を区切って議論する １ケース30分など 少人数チーム、かつ適切メンバを入れる 5-6名 全員を関与させる。 ボディーランゲージ、プロセスから距離を置くものの対策 ground rule: =local rule surface: 浮上させる flipchart: メモ帳 timebox: 時間枠

>Top 8. Understanding User Requirements: Use cases* and Usage Scenarios: A use case is a discrete, stand-alone activity that an actor can perform to archive some outcome of value. A use case is a collection of related usage scenarios, and a scenario is a specific instance of a use case. The essential elements of a use-case description: A unique identifier A name that succinctly states the user task in the form of "verb + object." such as "Place an Order." A short textual description written in natural language. A list of preconditions that must be satisfied before the use case can begin. Post condition that describe the state of the system after the use-case is successfully completed. A numbered list of steps that shows the sequence of dialog steps or interactions between the actor and the system that leads from the preconditions to the postconditions. UML activity diagram illustrating the dialog flow in the normal and alternative courses of a use case. 11	8. ユーザ要求を理解する: ユースケースと利用シナリオ ユースケースは個別の活動実績 利用シナリオはユースケースの特定事例 ユースケース記述の必須要件 ユースケース聞き取りアプローチ: ユースケースの記述から共通理解に至る複数のプロセス
Use-Case Elicitation Approach:	use case: 外部利用者の視点でシステムの外部機能を記述。但し、システムの内部処理 (振る舞いや動作) や非機能要求は含まない 。 通常ユースケース記述として文や図で記述。達成される場合の流れだけでなく、達成されない場合のシナリオ(Event flow)も記述する。
System events and responses: 1) User initiates a use case (business event) 2) A control signal, data reading, or interrupt received from an external hardware device. 3) A time triggered event	ユースケース システム・イベントと反応 1)ユーザがユースケースを開始 2) 外部デバイスによるコントロールシグナル、データ読み取り、中断等 3)時間経過によるイベント開始

>Top 9. Playing by the Rules: Business rule taxonomy: Facts: called invariant - immutable truths about data entities and their attributes. Constraints: restrict the actions that the system or its users may perform. Action Enables: a rule that triggers some activity under specific conditions in an action enabler. Inferences: called inferred knowledge, an inference is a rule that establishes some new knowledge based on the truth of certain conditions. Inferences are often written in the "if/then" patter also found in action-enabing business rules. Computations: Many computations follow rules that are external to the enterprise, such as income tax withholding formulas. Terms: defined words, phrases, and abbreviations Discovering business rules by asking questions from different perspectives: The figure suggests the types of questions the analyst can ask when workshop participants are discussing various issues. The analyst should document the business rules that come out of these elicitation discussions and ask the right people to confirm their correctness and to supply any missing information.

9. 規則を遵守する: ビジネスルールの分類: 不変の事実 制約要因 行動可能性 推測することとは 計算 用語 様々な角度からの質問によってビジネスルールを発見する infer: = to bring in <意味する、推論する immutable: = in+ mutable <変わりやすい

>Top 10. Documenting the Requirements:

10. 要求を文書化する:

>Top 11. A Picture Is Worth 1024 Words: Partial ERD (Entity Relationship Diagram) for the Chemical Tracking System: Diamond in ERD represent relationship, which identify the local and number linkage between pairs of entities. Eg: "A Chemical Request is placed by a Requester" (when you read from left to right) Eg: "Each can place multiple requests. (one-to-many relationship)	11. 千語は一図にしかず: *<注> ERD図 UML表記: 米Rational Softwareが開発。1997年にOMG (Object Management Group が標準として採択。2007 UML2.0に改訂
UML (Unified Modeling Language) notation: in the case of Class diagram for part of the chemical Tracking System: A designer can elaborate these conceptual class diagrams, which are free from implementation specifies, into some detailed class diagrams for object-oriented design and implementation. Interactions among the classes and the messages they exchange can be shown using sequence diagrams and collaboration diagrams. Operations are shown inter he bottom portion of the class box and typical are flowed by empty parentheses. The analysis class model simply has to show that a Requester can request chemicals, query vendor catalogs, and receive chemical container. The number on the lines show the multiplicity of the association; an asterisk indicates a one-to-many association.
Sample Decision Table for the Chemical Tracking System: Conditons 1 2 3 4 5 User is authorized F T T T T Chemical is available - F T T T Chemical is hazardous - - F T T Requester is trained - - - F T Action Accept request x x Reject request x x x

>Top 12. Beyond Functionality: Software Quality Attributes:

12. 機能を超えたソフトウェアの品質特性:

>Top 13. Risk Reduction Through Prototyping: Horizontal Prototypes: is also called a behavioral prototype or a mock-up. It doesn't dive into all the layers of an architecture or into system details but rather primarily depicts a portion of the user interface. Vertical Prototypes: also known as a structural prototype or proof of concept, implements a slice of application functionality from the user interface through the technical services layers. Develop a vertical prototype when you're uncertain whether a proposed architectural approach is feasible and sound, or when you want to optimize algorithms, evaluate a proposed database schema, or test critical timing requirements. Throwaway Prototypes: Before construction a prototype, make an explicit and well-communicated decision as to whether the prototype will be discarded after evaluation or become part of the delivered product. Build a throwaway prototype is answer questions, resolve uncertainties, and improve requirements quality. Don't make a throwaway prototype more elaborate than is necessary to meet the prototyping objectives. Resist the temptation or the pressure from users to keep adding more capabilities to the prototype. Evolutionary Prototypes: provides a solid architectural foundation for building the product incrementally as the requirements become clear over time. It must be built with robust, production-quality code from the outset. It is well suited for Internet development projects.

13. プロトタイプによるリスク低減: 水平的プロトタイプ : 垂直的プロトタイプ: 使い捨てプロトタイプ: 進化的プロトタイプ: インターネット環境に最適 ソフトウェア開発プロセスにおけるプロトタイプ活用の道筋

Several possible ways to incorporate prototyping into the software development process. You can use the knowledge gained from a series of throwaway prototypes to refine the requirements, which you might then implement incrementally through an evolutionary prototyping sequence. an alternative path uses a throwaway horizontal prototype to clarify the requirements prior to finalizing the user interface design, while a concurrent vertical prototyping effort validates the architecture, application components, and core algorithms.

>Top 14. Setting Requirements Priorities:

14. 優先的要求を設定する:

>Top 15. Validating* the Requirements: V-model software development incorporates early test planning and test design: This shows test activities beginning in parallel with the corresponding development activities. This model indicates that acceptance testing is based on the user requirement, system testing is based on the functional requirements, and integration testing is based on the system's architecture.	15. 要求を検証する: Vモデルソフト開発： 早期テスト計画とテストデザイン。 テスト活動はそれぞれの開発活動に対応する。 結局、受領テストはユーザ要求に基づき、システムテストは機能要求に基づき、総合テストはシステムアーキテクチャに基づく。 検査は多段階プロセスから成る。点線は、一部の検査プロセスが繰り返される可能性を示す。 バグの数は検査頻度に依存する。
Inspection is a multistep process. The dotted lines indicate that portions of the inspection process might be repeated.	validate: 有効にする incorporate <取り入れる、一体化する
The number of defects found depends on the inspection rate.

>Top 16. Special Requirements Development Challenges: Software archaeology: In the absence of accurate requirements documentation, maintenances must reverse-engineer an understanding of what the system does from the code. Requirements for Package Solutions: (Commercial Off-the-shelf, COTS）: Weight your requirements on a scale of 0 to 10 to distinguish their importance. Rate each candidate package as to how well it satisfies each requirement. Use a rating of 1 for full satisfaction, 0.5 fro partial satisfaction and 0 for no coverage. Evaluate each package for the nonfunctional requirements that are important, such as performance and usability. Evaluate product cost, vendor viability, vender support, external interfaces that will enable extension and integration and compliance with any technology requirements. On-sight Customer: There's no substitute for having the right customers continuously available to the developers both on-site and on-sight. Beware, though, of too-frequent interruptions that to make it hard for people to refocus their attention on their work.

16. 特別な要求開発への挑戦: ソフトウェア考古学: ドキュメントがない場合、コードから理解することをソフトウェア考古学という。 パッケージに対する要求: 満足度に応じて、評価点を、0 (不満足) から10（満足) つける 非機能要求の評価も重要 拡張性、統合性、コンプライアンスも評価する。 顧客がすく傍にいる場合 顧客が、開発者のサイトの傍にいる場合はこれに勝ることはない。 但し、あまりに頻繁な介入は、開発者の集中力に影響する。

>Top 17. Beyond Requirements Development

17. 要求を超えた開発:

>Top 18. Requirements Management Principles and Practices:

18. 要求管理の原則と実践:

>Top 19. Change Happens: Change-Request Status: A change request passes through a defined life cycle, having a different status at each stage in its life. A valid change request has been received through an approved channel. Originator: someone who submits a new change request. CCB (Change Control Board); the group that decide to approve or reject proposed changes for a specific project. Evaluation: the person whom CCB Chair asks to analyze the impact of a proposed change. Modifier: the person responsible for making changes in a work product. Verifier: the person who determines whether the change was made correctly. Sample of chart of requirement change origins: The project manager could point out that marketing has requested the most requirements changes. Money down the drain: Estimating effort for a requirement change: Update the SRS or requirements database. Develop and evaluate a prototype. Create new design components. Modify existing design components. Develop new use interface components. Modify existing user interface components. Develop new user documentation and help screens. Modify existing user documentation and help screens Develop new source code. Modify existing source code. Purchase and integrated third-party software. Modify build files Develop new unit and integration test. Modify existing unit and integration tests. Perform unit and integration testing after implementation. Write new system and acceptance test cases. Modify existing system and acceptance test cases. Modify automated test drivers. Perform regression testing. Develop new reports. Modify existing reports. Develop new database elements. Modify existing database elements. develop new data files. Modify existing data files. Modify various project plans. Update other documentation. Update the requirements traceability matrix. Review modified work products. Perform rework following review and testing. Other additional task. Requrements change is a reality for all software projecs, but disciplined change-management practices can dreduce the disruption that changes can cause.

19. 変更は起こる: 変更要求ステータス: 変更申請者 変更管理ボード(CCB) 変更評価者 変更実施者 変更検証者 変更の原因 マーケティング マネジメント 顧客 ソフトウェアエンジニアリング ハードウェアエンジニアリング テスト 変更に伴う追加作業: 実に31項目に及ぶ変更作業あり →些細な変更はコスト高を招くだけ 変更はソフトウェア開発には免れない 但し変更原則を守ることによって変更い伴う混乱を減らせる。 evaluate <数値を求める <ex + value modify <変更する <軽減する方向に変える verify <立証 <正確なことを確かめる reject <re + jet <放り出す cancel < Cf. chancel内協会の格子の内陣→ 線を引いて消す disrupt <分裂させる break to pieces <rupture 破裂

>Top 20. Links in the Requirements Chain:

20. 要求チェインでのリンク:

>Top 21. Tools for Requirements Management: .

21. 契約管理のためのツール:

>Top 22. Improving Your Requirements Processes: Process Improvement One-Liners: Take chewable bites. Taka a lot of satifaction from small victories. Use gentle pressure, relentlessly applied. Focus, focus, focus Look for allies. Action plans that don't turn into actions are not useful. The learning curve is an unavoidable part of process: Accept the reality of the learning curve; the productivity drop that takes place as practioners take time to assimilate new ways of working this short-term productivity drop, called "valley of despair" is part of the investment your organization is making in process improvement.

22. 要求プロセスを改善する: プロセス改善の金言 少しずつかじれ 小さな成功からの大きな満足 圧力はやさしく、但し妥協なく適用せよ 集中、集中、集中 支持者を探せ 活動しない活動計画は無意味 プロセスに不可避の学習曲線: 学習曲線の現実を認識せよ。生産性は短期的にはむしろ落ち込む。これを「絶望の谷」と呼ぶ。この谷間もまたプロセス改革の必然である。 relent <溶ける、優しくなる

>Top 23. Software Requirements and Risk Management: Elements of risk management: Risk management provides a standard approach to identify and document risk factors, evaluate their potential severity, and propose strategies for mitigating them.

23. ソフトウェア要求とリスクマネジメント: リスク管理の要因: リスク評価 まずリスクを特定し、分析し、優先づけを行う リスク回避 リスク管理 経営計画の想定内、リスクを決断、リスクを監視

Comment

In June 2008, urged by Mr. Takaaki Seki, Chairman of IT Coordinators Association, serveral specialists of BPM and SCC as well as able IT Coordinators organized BPMS Study Group. The Requirement Engineering seems to be at the center of the core technologies. Many hours spent together with this book during summper holidays in 2008. This group requires members of their intelligent ability and imagination of field implementation; causing tough debate but challengeable activities. WYMIWYR (What You Model Is What You Run)

2008年6月に関会長の呼びかけで、BPMやSCCの専門家、そして強力なITコーディネータが集い、BPMS研究会を立ち上げた。 要求工学はそのコア技術の中心に位置いると思われる。 2008年の夏休みはこの本とともに多くの時間を過ごすことになった。 知的能力と現場への想像力が要求される厳しいけれどやりがいの活動である。 WYMIWYR: モデル化したものが実行される。