Takanori Ugai, Kouji Aoyama Fujitsu Laboratories Limited Domain Knowledge Wiki for Eliciting Requirements
Table of Contents <ul><li>Motivation & Background </li></ul><ul><li>Outline of the system </li></ul><ul><ul><li>Challenges...
Motivation <ul><li>To elicit requirements we need domain knowledge about customers’ businesses. </li></ul><ul><li>Software...
Example of specification change record <ul><li>Outline </li></ul><ul><ul><li>After inputting an instruction for a drip, it...
Outline of the system
Challenges and Approaches <ul><li>Engineers do not know how to describe their domain knowledge </li></ul><ul><ul><li>←  Se...
Characteristics <ul><li>Semi-structured Template </li></ul><ul><ul><li>This system adopts the idea of Alexander’s pattern ...
Template (Input form)
Template (1/2) <ul><li>Title: Name that clearly shows the domain knowledge. </li></ul><ul><li>Author: Name of person who o...
Template (2/2) <ul><li>Outline: The outline gives the main points of the domain knowledge. It is described in short senten...
Problem Domain Guidance <ul><li>This system provides 26 problem categories by extracting analyses of specification change ...
Example from Problem Domain Categories <ul><li>Irregular case: Irregular case such as interruption of  a task. </li></ul><...
Screen shot
Example1 <ul><li>Title: The drip speed </li></ul><ul><li>Outline: Use case that is an irregular business operation in a he...
Example2 <ul><li>Title: Time for automatic log-off </li></ul><ul><li>Outline: The maximum and minimum time required to exe...
User study <ul><li>The system has just started in use. </li></ul><ul><li>80 users </li></ul><ul><li>200 knowledge are stor...
Conclusion <ul><li>We have designed a wiki system to accumulate domain knowledge. </li></ul><ul><li>The domain knowledge a...
 
Upcoming SlideShare
Loading in …5
×

08 Domain KnowledgeWiki for Requirements Elicitation

1,243 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,243
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

08 Domain KnowledgeWiki for Requirements Elicitation

  1. 1. Takanori Ugai, Kouji Aoyama Fujitsu Laboratories Limited Domain Knowledge Wiki for Eliciting Requirements
  2. 2. Table of Contents <ul><li>Motivation & Background </li></ul><ul><li>Outline of the system </li></ul><ul><ul><li>Challenges and Approaches </li></ul></ul><ul><ul><li>Semi-structured Template </li></ul></ul><ul><ul><li>Problem Domain Guidance </li></ul></ul><ul><li>Examples </li></ul><ul><li>Conclusion </li></ul>
  3. 3. Motivation <ul><li>To elicit requirements we need domain knowledge about customers’ businesses. </li></ul><ul><li>Software engineers usually acquire domain knowledge from discussions with customers. </li></ul><ul><li>But customers occasionally neither mention any specifications of tacit assumptions nor any problems that might occur. </li></ul><ul><li>We have to have such domain knowledge in house. </li></ul>
  4. 4. Example of specification change record <ul><li>Outline </li></ul><ul><ul><li>After inputting an instruction for a drip, it needs to change the drip speed. In the current system, once an instruction is input, it cannot be modified. </li></ul></ul><ul><li>Reason </li></ul><ul><ul><li>The drip speed must be modifiable according to patient's condition. </li></ul></ul>
  5. 5. Outline of the system
  6. 6. Challenges and Approaches <ul><li>Engineers do not know how to describe their domain knowledge </li></ul><ul><ul><li>← Semi-structured Template </li></ul></ul><ul><li>Engineers do not know what kind of knowledge other engineers do not know </li></ul><ul><ul><li>← 26 Problem Domain </li></ul></ul>
  7. 7. Characteristics <ul><li>Semi-structured Template </li></ul><ul><ul><li>This system adopts the idea of Alexander’s pattern language. The template is provided as standard to make it easier to describe domain knowledge, and it is possible to easily edit it with the wiki site. </li></ul></ul><ul><li>Problem Domain Guidance </li></ul><ul><ul><li>The system provide 26 problem categories by extracting analyses of specification change records. The problem categories are important viewpoints . </li></ul></ul><ul><li>Mutual Reviewing </li></ul><ul><ul><li>The quality of the stored knowledge is guaranteed with mutual reviewing by engineers. </li></ul></ul>
  8. 8. Template (Input form)
  9. 9. Template (1/2) <ul><li>Title: Name that clearly shows the domain knowledge. </li></ul><ul><li>Author: Name of person who offers it. </li></ul><ul><li>Problem domain: The system provides 26 problem categories which have been extracted from an analysis of specification change records. The author can choose one of them or can add a new problem domain. </li></ul><ul><li>Scene: A particular scene of the domain knowledge is used. This makes it easy to retrieve a similar scene to reuse the knowledge. </li></ul>
  10. 10. Template (2/2) <ul><li>Outline: The outline gives the main points of the domain knowledge. It is described in short sentences. It is listed on the best-hit list and other places. </li></ul><ul><li>Related Knowledge: A link to pages that can be used by combining other knowledge and similar knowledge pages. </li></ul><ul><li>Episode: A story in which the knowledge appears is described and has a factual basis. </li></ul>
  11. 11. Problem Domain Guidance <ul><li>This system provides 26 problem categories by extracting analyses of specification change records. </li></ul><ul><ul><li>We conducted an empirical study of three IT system development cases: a financial system, medical system, and production system. </li></ul></ul><ul><ul><li>We analyzed 135 specification change records overall. </li></ul></ul><ul><ul><li>79 % of the specification change cases could have been covered by the 26 categories. </li></ul></ul>
  12. 12. Example from Problem Domain Categories <ul><li>Irregular case: Irregular case such as interruption of a task. </li></ul><ul><li>Executing time: Time taken to complete a task. </li></ul><ul><li>Combination: Knowledge when a use case is combined and executed in an operation sequence. </li></ul><ul><li>Repetition: Knowledge about whether a use case occurs cyclically or in bulk. </li></ul><ul><li>Actor Group: Knowledge about whether an actor group is defined according to skill level or age of users. </li></ul>
  13. 13. Screen shot
  14. 14. Example1 <ul><li>Title: The drip speed </li></ul><ul><li>Outline: Use case that is an irregular business operation in a health care system. </li></ul><ul><li>Problem domain: Irregular case </li></ul><ul><li>Scene: Health care system </li></ul><ul><li>Episode: After inputting an instruction for a drip, it needs to change the drip speed. In the current system, once an instruction is input, it cannot be modified. This is because the drip speed must be changed according to patient’s condition. </li></ul>
  15. 15. Example2 <ul><li>Title: Time for automatic log-off </li></ul><ul><li>Outline: The maximum and minimum time required to execute the use case in a mission-critical task </li></ul><ul><li>Problem domain: Executing time </li></ul><ul><li>Scene: Web-based system for a mission-critical task </li></ul><ul><li>Episode: In a Web-based system for a mission-critical task, a no-communication time of the automatic logoff function is short for 30 minutes, when the system is unused. Because there is often a case in which a user doesn’t use the system for a long time and the user has to do interrupted work that system is not used. </li></ul>
  16. 16. User study <ul><li>The system has just started in use. </li></ul><ul><li>80 users </li></ul><ul><li>200 knowledge are stored </li></ul><ul><li>The knowledge were described when they wrote their project reports </li></ul><ul><li>The knowledge come from their reflection meetings at the end of the projects. </li></ul>
  17. 17. Conclusion <ul><li>We have designed a wiki system to accumulate domain knowledge. </li></ul><ul><li>The domain knowledge accumulated by this system describes the knowledge obtained when software engineers analyze requirements. </li></ul><ul><li>The system provides 26 problem domain categories which are extracted from specification change records. </li></ul><ul><ul><li>We will evaluate how the knowledge work and how the categories work </li></ul></ul>

×