1 / 25

ステーキホルダーの非機能要求を充足するための振る舞い仕様の段階的改訂法

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

jatin
Download Presentation

ステーキホルダーの非機能要求を充足するための振る舞い仕様の段階的改訂法

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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. 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. 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. Sub goals of our Work • Develop a notationforSH’s Evaluation. • Develop a procedurefor causing a chain of IT introduction. • IT introduction => CT change => SH eval. change = >Specification refinement • Develop a procedure for merging such chains safely for concurrent RE.

  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. 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. 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. A notation for SH’s EvaluationEvaluation Table Quantitative Evaluation can be accomplished!

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

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

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

  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. 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. Overview of Merge Proc. initial spec. Chain of A refined spec. A0 refined spec. B0 Chain of B eval. tablea eval. table I refined spec. A1 refined spec. B1 Inputs eval. table eval. table A B refined spec. A refined spec. B generate diagram IB IA eval. table eval. table Hori. Check use the diagram for the check Vert. Check Collaboration diagram Outputs refined Spec. A+B eval. table A+B

  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. Example of Horizontal Check Contributor Initial Spec. legend: paper ack. of abst. CFP abst. ack. of abst. cut path. add path. Chair refinement A, B, C, D abst. list Reviewer Candidate refinement X, Y Committee Spec. D Spec. Y Contributor Contributor Chair Chair abst. list’ Committee Committee

  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. • Messages in both initial spec. and spec. A, but modified in spec. B. • Messages only in spec. B. Check this by replacing A and B. Init. Spec RE chain RE chain Spec. A Spec. B

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

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

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

  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. Appendix

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

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

More Related