1. 1 ステーキホルダーの非機能要 求を充足するための振る舞い 仕様の段階的改訂法 海谷 治彦 信州大学 2001 年 9 月 宇和島にて

2. 2 Outline Goal of our Work. –Constructing a Requirements Elicitation Method. Basic idea for our Goal. Sub goals and their solutions. –Notation for evaluating spec. by multiple stakeholders. –Method for causing a chain of spec. change. –Method for merging several chains. Example

3. 3 Goal of our Work Constructing a Requirements Elicitation (RE) Method. Domain of the method. –Multiple Stakehodlders (SH) –Motivation to introduce Info. Tech. (IT) –Existence of the Current Task (CT) Interactive System: WBS, UIS A case without a computer system support. Another case with a computer system support.

4. 4 Basic Idea Stepwise Introduction of IT(=Change) to CT. –SH’s Evaluation of the Change. –Such Eval. triggers the other Changes. Reasonable Trade-off among the SH’s. –Shared Criteria for SHs to Change Evaluation. Concurrent RE for Efficiency.

5. 5 Sub goals of our Work 1.Develop a notation for SH’s Evaluation. 2.Develop a procedure for causing a chain of IT introduction. IT introduction => CT change => SH eval. change = >Specification refinement 3.Develop a procedure for merging such chains safely for concurrent RE.

6. 6 Notation of Spec. Sequence Diagram for representing Requirements Spec. –Easy to capture the interaction among the SHs. –Easy to Understand ordinary people. –Behavioral Aspect is important for interactive system.

7. 7 NFR for shared Criteria Non-Functional Requirements (NFR) –shared by stakeholders to evaluate a change of CT. Type of NFR –Performance: Time and Space –Cost. –User-Friendliness. –Security: Confidentiality, Integrity, Availability. And additional criteria. –Ease: delegation of a task to systems.

8. 8 Stakeholders Have a stake in the change being considered, those who stand to gain from it, and to lose. Categories of SH in computer systems. –Those who are responsible for its design and development. –... for its sales or for its purchase. –... for its introduction and maintenance. –Those who have an interest in its use.

9. 9 A notation for SH’s Evaluation Evaluation Table Quantitative Evaluation can be accomplished!

10. 10 Chain of Requirements Change (CRC) 1.Write an Initial Specification of CT. 2.A SH states his advantages and disadvantages of the spec. 3.Change the spec. so as to eliminate disadvantages. 4.Other SHs state them in the same way. 5.Change the spec. in the same way. 6.Back to the Step2.

11. 11 Overview of our RE Proc. in Chain Creation Current Task Eval. Table Initial Spec. A Stakeholder Refined Spec. Other Stakeholders - Eval. Table - + - ++ + - cause

12. 12 Example of a part of Chain Spec. X Spec. Y Op. have disadv. in X Elim. the disadv. Evaluation is quantitatively up.

13. 13 Merge Chains for Concurrent RE Multiple SHs: Concurrent RE is efficient. We should safely merge the results of RE. Precondition of our merge procedure. –Sequence Diagram: notation for spec. –The inputs are two chains. –Two chains share the same initial Spec. Postcondition –Merged Spec. and Evaluation Table.

14. 14 Two Step of Merge Method Horizontal Check –Consistency in the topology among the objects. Collaboration Diagram Vertical Check –Consistency in causal relations. Retrying by shortening a chain. –if inconsistency is found. Evaluation score is of course decreased.

15. 15 Overview of Merge Proc. eval. table eval. tablea eval. table initial spec. refined spec. A0 refined spec. A1 refined spec. A refined spec. B refined spec. B0 refined spec. B1 Hori. Check Vert. Check refined Spec. A+B Chain of A Chain of B eval. table A+B Inputs Outputs I AB IA IB use the diagram for the check generate diagram Collaboration diagram

16. 16 Horizontal Check Checking the inconsistency of relationships among the objects. –Convert sequence diagram to collaboration diagram. No relationship in an initial diagrams is changed in the different way in each refined diagrams.

17. 17 Example of Horizontal Check Contributor Committee Chair abst.ack. of abst. paper ack. of abst. CFP abst. list Reviewer Candidate Contributor Committee Chair Contributor Committee Chair Initial Spec. Spec. D Spec. Y abst. list’ cut path. add path. legend: refinement A, B, C, D refinement X, Y

18. 18 Vertical Check Checking the consistency in causal relations among the messages. Not all messages need not be checked, check the following kind of messages. 1.Messages in both initial spec. and spec. A, but modified in spec. B. 2.Messages only in spec. B. Check this by replacing A and B. Init. Spec Spec. ASpec. B RE chain

19. 19 Example of Vertical Check Contributor Committee Chair abst.ack. of abst. paper ack. of abst. CFP abst. list Reviewer Candidate Contributor Committee Chair Contributor Committee Chair Initial Spec. Spec. D Spec. Y abst. list’ refinement A, B, C, D refinement X, Y cut path. add path. legend: Only check the inconsistency in Y

20. 20 Conclusion Stepwise refine the Spec. Quantitative Evaluation of each step based on the stakeholders’ intention. Enable the Concurrent Elicitation by merge step.

21. 21 Q & A 何故，横チェックを先にやるか？ – 横チェックの方が楽なため。 – 横チェックを基に縦チェックをする個所を絞れる。 シーケンス図には SH でないものも出てくるが どうするか？ – シーケンス図のオブジェクトと評価表の列側は一 応別個と考え，オブジェクトは SH に限らず自由に 選んでよいことにする。 – 仕様の変化とステーキホルダの評価の関係が曖昧 となるが，そもそも主観的評価に基づくので問題 ない。

22. 22 Future Work Prioritize stakeholders and/or NFR for evaluation. Quantitative comparison for selecting the reasonable chain of specification change. Building an Estimation Method: estimating the introducing effort. Applying a realistic problem and/or development.

23. 23 Appendix

24. 24 ContributerChairCommitteeReviewer Time Keeper * Send CFP * Request reviewer *take on reviewer *back rev. candidates * Send paper Submission Limit Gather papers Gathering System Gather abst. * Send paper list Write paper Write abst. Ack. * Send abst Ack. Fiter System Spec. D

25. 25 * Send abst ContributerChairCommitteeReviewer Time Keeper * Send CFP * Request reviewer *take on reviewer *back rev. candidates * Send paper Submission Limit Gather papers Gathering System2 Gather abst. * Send paper list Write abst. Ack. Write paper Format Checker Fmt nack. Spec. Y