Silvia Preston

Ph. D. Candidate

Dissertation Proposal

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

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

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

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

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

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

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

Portfolio

E.P. O.

W.O.

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. 263-272). Hanoi, Vietnam: IEEE.

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. 1017-1022).

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. 189-195)

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

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

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:

PersonOntology

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

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

Neural Network

Research Approach (5)

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)

Ontology/KBSQL KB HTML KB

Mapping KB

Reports KB Creation (Portfolio)

Scripted Process (1)

Example:W.O. Requirement – “Students will enter their name”

Rough Requirement:

Student Name:

Scripted process: step by step instructions for hand drawing a rough form for the W.O. requirements.

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:

Elicitation Process (Scripted Process 2)

Scripted Process (3)

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.

Scripted process: step by step process between novice and experienced developers on how to write the final functional requirements for the W.O.

Elicitation Process (Scripted Process 3)

Training Example

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

Req. 1: Application will contain Child’s name.Req. 2: Application will contain Parents’ name.Req. 3: Application will contain Employee ID.

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.

After

Before

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

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

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.

Questions

Thanks for you presence and patience!