Silvia Preston Ph. D. Candidate Dissertation Proposal

Transcription

1 Silvia Preston Ph. D. Candidate Dissertation Proposal

2 Presentation Outline Problem Statement Background of the Problem Importance of the Problem Research Objective Objective of the Study Related Work Research Approach Methodology Timeline Expected Results Impact of Results Limitations of the Study Prospectus Outline

3 Background of the Problem The role of Functional Requirements is critical in Software Engineering Functional Requirements is a section of the Software Requirement Specification describes how the inputs should be transformed into outputs Unambiguous, complete, verifiable, consistent, modifiable, traceable usable Requirements are elicited from customers Techniques are available for requirements elicitation Novice customer is not knowledgeable of techniques

4 Importance of the Problem Ambiguous requirements lead to poor software products Personnel experience affects requirements elicitation Good requirement specifications Produce quality software products Save time and money

5 Problems in Requirements Elicitation Lack of discipline Lack of domain knowledge Knowledge gap between development team and novice customers Knowledge gap between within the development team Insufficient requirement detail Ambiguities exist in requirements during elicitation No training for new customer is available Novice customers do not have the experience of a domain expert. Requirement elicitation process is too complicated for inexperienced stakeholders There is a need for a step by step scripted procedure in combination with a tool for reducing ambiguities

6 Objective of the Study Create a step by step scripted procedure to reduce requirement ambiguities during elicitation process No scripted process exists for reducing requirement ambiguities based on existing software application requirements Create a tool for holding knowledge about new and existing requirements Scripted procedure will aid novice customer and novice developer how to use the tool The cognitive distance between novice and experienced stakeholders will be reduced with the use of the scripted procedure and the tool

7 Research Question (1) How can ambiguities be reduced from customer requirements and converted to clearer set of functional requirements that is understood by all stakeholders? Create a disciplined approach using a step by step procedure to control the behavior of the elicitation process Create a tool to hold knowledge from existing requirements of existing applications

8 Research Question (2) What can be done to bridge the gap between the two groups: 1) the novice users and the domain experts and 2) novice users and the development team during the elicitation process of requirements? Reduce the cognitive distance using a semi-automated smart elicitation process and a tool

9 W.O. Portfolio E.P. O.

10 Related Work: Ontology-based Reasoning in Requirements Elicitation Ontology-based checking tool takes initial requirements and ontology as input in a reasoning cycle until no new mandatory, redundant, or inconsistent requirement is found. Questions are generated to customer when one of the issues are found. Problems: no reusability is proposed; tool requires experienced domain user; does not reason about detailed description of requirements; not reverse engineered; Dzung, D. V., & Ohnishi, A. (2009). Ontology-based Reasoning in Requirements Elicitation. Seventh IEEE International Conference on Software Engineering and Formal Methods (pp ). Hanoi, Vietnam: IEEE.

11 Related Work: Matching Functional Business Requirements to Application Software Approach for describing business requirements and software attributes in terms of ontologies. Used for semi-automated reasoning about the suitability of a certain software product. Problems: Dynamic ontology; no algorithm to support the matching between the ontologies; Kluge, R., Hering, T., Belter, R., & Franczyk, B. (2008). An Approach for Matching Functional Business Requirements to Standard Application Software Packages via Ontology. 32nd Annual IEEE International Computer Software and Applications Conference, COMPSAC'08, (pp ).

12 Related Work: Towards a Multiple Ontology Framework For Requirements Elicitation and Reuse Multiple ontology framework for requirements elicitation and reuse; each of the 4 ontologies are responsible for a task in the framework; domain users use questionnaires directed by the framework to elicit requirements. Problems: no method is provided for reasoning about new requirements; users are assumed to be knowledgeable of the domain under discussion; Zong-yong, L., Zhi-xue, W., Ying-ying, Y., Yue, W., & Ying, L. (2007). Towards a Multiple Ontology Framework for Requirements Elicitation and Reuse. COMPSAC 2007, (pp )

13 Research Approach (1) Overview An approach to reduce functional requirements ambiguities through a smart elicitation process Semi-automated scripted process for functional requirements elicitation Incorporate ontology for classification of attributes and Neural Networks for training Overall Goal Bring together domain and development experts through a process that learns and gain experience on previous and new requirements Provide reusability of functional requirements through historical data Develop a semi-automated scripted process to develop form based functional requirements. Core Techniques Ontology - higher level of abstraction Neural Network - learning and automation reduces effort Scripted process and ontology/neural network combination - generates good functional requirements with little or no ambiguities

14 Research Approach (2) Why do we need Ontology/Neural Network (NN) combination? NN allows for supervised learning and backpropagation for teaching Ontology representation of knowledge as a set of concepts within a domain Similar to an OO Database IS A/HAS A Supports intelligent decision Allows for reusability Allows NN to work as a trigger for data

15 Research Approach (3) What is an Ontology? Similar to a database it allows for objects and concepts to be created and classified by specifying their properties and relations Allows for multiple inheritance Supports expert systems Example:

16 Person Ontology There is a fine line between the concepts that go into the ontology and what goes in the knowledge base.

17 Research Approach (4) What is a NN? Mimics biological nervous system Interconnected processing elements that works together to solve specific problems Ability to learn by example in a specific environment

18 Neural Network

19 Research Approach (5)

20 Methodology Qualitative Case Study The following is a list of people that will be involved in this study: 1 novice software developer 1 experienced software developer 1 expert business analyst 1 novice user The study will be conducted at the IT department of this university. The data to be collected will consist of two current software applications, one new set of user s requirements, and a set of other artifacts related to the case. The result of this study will be a scripted process and a prototype of a tool for semi automating the process of eliciting requirements and reducing ambiguities through training. Tools: Protégé, Jess rules (Clips-based rule engine), Eclipse (for Neural Network implementation in the Java language)

21 Ontology/KB SQL KB HTML KB

22 Mapping KB

23 Reports KB Creation (Portfolio)

24 Scripted Process (1) Scripted process: step by step instructions for hand drawing a rough form for the W.O. requirements. Example: W.O. Requirement Students will enter their name Rough Requirement: Student Name:

25 Scripted Process (2) Scripted process: step by step process on how to eliminate ambiguities from the rough requirements (drawings) using trained data and searching for the best match. Example: Student First Name: Student Middle Name: Student Last Name:

26 Elicitation Process (Scripted Process 2)

27 Scripted Process (3) Scripted process: step by step process between novice and experienced developers on how to write the final functional requirements for the W.O. Example: Application will contain: Input text field of length 20 for Student First Name. Input text field of length 20 for Student Middle Name. Input text field of length 20 for Student Last Name. A table will be created for the application containing a column for each field described above. Each column will be of type varchar of length 20.

28 Elicitation Process (Scripted Process 3)

29 Training Example

30

31 Expected Results A prototype of a tool containing a knowledge base supporting inferences learned for requirement draft A step by step scripted process will aid developers and customers in reducing ambiguities from functional requirements during the elicitation process A process/tool that learns and gains experience on specific university department requirements Cognitive distance will be reduced in the elicitation process as compared to the non-automated elicitation process

32 Req. 1: Application will contain Child s name. Req. 2: Application will contain Parents name. Req. 3: Application will contain Employee ID. Before After Req. 1: Application will contain Child s First Name in a input text box of 20 characters maximum Application will contain Child s Middle Name in a input text box of 20 characters maximum Application will contain Child s Last Name in a input text box of 20 characters maximum Req. 2: Application will contain Mother s First Name in a input text box of 20 characters maximum Application will contain Mother s Middle Name in a input text box of 20 characters maximum Application will contain Mother s Last Name in a input text box of 20 characters maximum Application will contain Father s First Name in a input text box of 20 characters maximum Application will contain Father s Middle Name in a input text box of 20 characters maximum Application will contain Father s Last Name in a input text box of 20 characters maximum Req. 3: Application will contain Faculty or Staff ID in an input text box of 11 characters maximum.

33 Impact of Results Potential combination of an ontology, neural network, and a process for reducing ambiguities in requirements during the elicitation process, imply the production of a better set of functional requirements Benefit the development team and the users who write the functional requirements (Surveys?? Some kind of assessment) Cognitive distance can be reduced between two groups: (1) customer and the development team and (2) the experienced and inexperienced developer

34 Limitations of the Study Limited to focusing on misused and misunderstood parameters between domain and engineering experts from various departments The theory here could be used to map requirements to software design during requirements elicitation

35 Summary Reverse engineer existing applications To build a historical ontology and train the neural network to provide reusability for future application development. Create a scripted process to control the elicitation process which will aid in reducing ambiguity Reduce the cognitive distance between developer and customer so that inexperienced developer works with novice customer to write requirements. Provide inexperienced domain users a way to learn from existing concepts.

36 Questions Thanks for you presence and patience!