International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),

ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
48











A CONSTRUCTIVE AND DYNAMIC FRAME WORK FOR REQUIREMENT
ENGINEERING PROCESS MODEL BEE HIVE MODEL


Swarnalatha K S
1
, G.N Srinivasan
2
, Pooja S Bhandary
3

R V College of Engineering
Mysore Road, R V Vidyanikethan Post, Bangalore, Karnataka 560059



ABSTRACT

Despite of many advances in design of complex software development there remains the
problem of highly inadequately specifying the requirements form the stakeholders for any real time
application. This paper mainly focuses on BEE-HIVE model based process for requirement process
model. BEE-HIVE MODEL driven development fits in any evolutionary and conventional
prototyping because design and analysis key parts of any software development process. A BEE-
HIVE model is applied to increase speed up and also to check the time required to gather the data
from the stake holders in designing the prototype. The BEEHIVE model may ensure the correctness
of the timely generated code, which is another important factor in enabling the software development
designing the prototype. The BEEHIVE model may ensure the correctness of the timely generated
code, which is another important factor in enabling the software development.

Keywords: Bee-Hive Model, Requirement Specification, Security, Prototyping, Elicitation and
Analysis.

1. INTRODUCTION

The Success of any software system is the level of degree to which it meets the purpose of the
customers or stake holders. Therefore, requirements engineering plays a vital role for successful
completion of any projects. Requirements engineering commonly defined as a part of software
engineering which is mainly concerned with real world entities, constraints from stake holders on a
complex software systems. Requirements engineering facilitates the converts the informal
requirements to formal specifications, which serve stakeholders for any real time application. This
paper mainly focuses on BEE-HIVE model based process for requirement process model. BEE-
HIVE MODEL driven development fits in any evolutionary and conventional prototyping because
design and analysis key parts of any software development process. A BEE-HIVE model is applied
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
TECHNOLOGY (IJCET)



ISSN 0976 6367(Print)
ISSN 0976 6375(Online)
Volume 5, Issue 7, July (2014), pp. 48-54
IAEME: www.iaeme.com/IJCET.asp
Journal Impact Factor (2014): 8.5328 (Calculated by GISI)
www.jifactor.com

IJCET
I A E M E
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
49

to increase speed up and also to check the time required to gather the data from the stake holders inas
the basis for design and development of the software [1]. The proposed The Bee-Hive model
attempts to find a compromise between two conventional and tested models of requirements
engineering which are waterfall model and evolutionary development model in such a way that the
advantages of both the models are effectively incorporated into the system and at the same time
trying to reduce and overcome the shortcomings and disadvantages [2]. In other words it tries to
maximise the gains while minimizing the disadvantages.

2. CONVENTIONAL APPROACH

Requirements Engineering is the process of understanding and defining what services are
required from the system and identifying the constraints on the systems operation and development
[3]. It is an extremely important phase as the success of the subsequent phases directly and indirectly
depend on the efficiency with which requirements engineering is carried out.
A strong and robust building needs a sound foundation [4]. This analogy can be extended to
the softwareengineering process where the Requirements engineering process can be considered as
the foundation [5]. Hence, it is imperative that novel and efficient techniques of requirements
engineering should be developed.

The conventional requirements engineering processes have the following disadvantages:

1) Time consuming [7].

2) Too orthodox i.e. either follow the waterfall or iterative development model.

3) Too much documentation [8].

No clear segregation into system, user and domain requirements.

3. BEE-HIVE MODEL -APPROACH

We have tried to overcome the disadvantages of conventional approach by using a novel and
innovative model called the bee-hive model. It is called a bee-hive model because the structure at the
centre is in the shape of a bee-hive. The fig 1 below shows the overview of BEE-hive model.

4 PHASES OF BEE-HIVE MODEL

4.1 Background Research
This is the first phase in the requirements engineering model. This can be compared to the
feasibility step in the conventional models. But unlike feasibility study which is one dimensional and
only focuses on whether the proposed system is cost-effective or not and if it lies within the required
budget the background research is carried out in specific areas related to the project [9] . The areas of
background research considered here are generic and can be applied to most of the project
undertaking.The areas of background research are:
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
50


Fig 1: BEE-Hive model

1. Application Domain
Determines the feasibility of the application platform proposed to implement the project.
Research is done based on considering the current platforms and facilities available and analysing
whether they are good enough to support the project[ 10]. If the current resources are found
inadequate then it is determined whether developing new and application specific resources and
facilities are feasible or not. Criteria for choosing the application domain are listed below.

Available technology.
The platform to be selected.
Required software and hardware.
Decision whether new technology is to be developed or not.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
51

2. Scope of evolution
This phase is used to predict the kind of future the product or the service developed has. This
phase is used to predict the changes it might be subjected to in the future. Depending on the level and
the rate of changes it might be subjected either time or quality is set as the critical factor. For
example, if a software is changed every 3 months then time is the critical factor here. If on the other
hand the software is to be used for a longer lifetime quality is the critical factor.Criteria for choosing
the scope of the product are listed below.

The novelty of the product.
Shelf-life of the product.
The kind of acceptance garnered by the product (More popular technologies have a better
scope of evolution).
Future need of such aproduct/technology. (Try and produce a reliable prediction).

3. Organisational factors
Constitutes the organisational policies, laws, staff, growth plan and resources available in the
company in terms of capital and technology owned by it.
Criteria for choosing the Organisational factors are listed below.

Management hierarchy.
Company policy.
Proprietary products available to support research and technology.
The financial condition of the company that affects the budget.

4. Market
This phase used to determine the current competition in the market, the need and aspiration
for the product or service being developed.Criteria for choosing market for the product are listed
below.

Current Competition in the market.
Previous response to similar products/technologies.
The demand and the need of the product/technology to be released.
The market trends and conditions.

5. Scale check
This basically determines the scale on which the product or service is to be released. Based
on the estimated profit margin the scale is determined and correspondingly the amount of money to
be invested into it is determined.Criteria to check scalability of the product are listed below.

The budget for marketing and distribution.
The investment on the product.
The expectations out of the product/technology.
The brand name and the reputation of the company.

Advantages
Feasibility study can be carried out parallel in each of the above specified areas.
It does not hold up the requirement elicitation and analysis of other unrelated areas.
Talent and skills of people can be mobilized. People who are good at a particular area can be
allotted work in that particular area.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
52

Based on the application, different areas are given different precedences or importance
depending on how critical that aspect is to the application.
Based on the importance of the different areas of feasibility study a rank is given to each area
and the area with the higher rank is given more importance and more time and effort is spent
on its feasibility study. If in a high grade area of say 1 or 2, project is found unfeasible it is
scrapped. Between 3 and 4 grade if found unfeasible then it is manageable but advisable to
work on and improve the feasibility. Between 5 and 6 grades if risk involved is not too high
then the problems in this area are avoided.

6. Safety and Security
Whether the product to be developed is safe to use and whether it can assure security against data
theft and loss [11]. .Criteria for choosing the safety and security of product are listed below.

Vulnerability to loss of data or other damages.
Preserving data integrity.
Data backup and back up plans for the facility if an accident occurs.
Recovery mechanisms if something should go wrong.

4.2 Requirements Elicitation and Analysis
This phase is carried out as a continuation to the feasibility study carried out in different
areas. Because the Feasibility study was very specific the requirement elicitation and analysis is
simplified to a great extent. As mentioned above requirement elicitation and analysis process is sped
up because of greater clarity and non-dependence on areas that do not affect it [12]. This phase
generates the want requirements which are the requirements that the customer or user expects and
requires.

4.3Prototyping
A prototype is developed to evaluate the performance of the current system and find out the
requirements that are satisfied by the system. This constitutes the have requirements.

4.4 Requirement Verification and validation
Here a Venn diagram is drawn between the have and the want requirements as specified
above. Based on the level of intersection the success of that particular area of research is determined.
The level of intersection indicates the extent to which the prototype satisfies the users needs and
expectations [13].
To indicate a successful model a certain ideal percentage of intersection is assigned to each
area based on its grade. If the ideal percentage criteria is met in all the areas then it can be considered
a complete model.

Advantages

If a particular area falls back on the intersection criteria and does not meet it then work needs to
be done only in that particular area and the entire process need not be repeated.
Based on the grade of a particular area the intersection criteria is allotted. Hence too much time
need not be invested in areas where too much efficiency is not required.

4.5 Requirement Specification
Only those requirements that lie in the intersection region are documented. Hence the
documentation cost and time is greatly reduced as requirements that are irrelevant are not
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
53

documented [14]. Also as each area generates its own requirements itsmanagement is simpler
because the volume of data generated is greatly reduced. Each area of background research generated
requirements specific to that area [16]. The application domain produces the domain requirements.
The market research produces the user requirements. Safety and security produces critical system
requirements. Scope and organisation produces system requirements. Hence an easy segregation of
requirements is achieved.

5. BEE-HIVE MODEL ADVANTAGES

The advantage of the Bee-hive model is listed below:

1. It is a combination of both parallel and serial model. While the phases of feasibility study are
carried out parallel, the flow of control within a particular area is sequential.
2. It is a good combination of waterfall and evolutionary development model.
3. Each phase in the feasibility study is largely independent of other areas and if one area fails
the negative effects on other areas are reduced to a great extent.
4. Helps us to identify the critical requirements and helps us to focus on the important
requirements and not waste time on the others.
5. There is a scope for compromise and imperfections in the system as a few non critical errors
cannot directly affect the system.
6. Once the feasibility study is complete the rest of the processes can be completed with relative
ease.

Future Enhancement
Critics may argue that feasibility study in the requirements engineering process should be
quick and easy. But if the added complexity and time consumption can ensure the efficiency of the
subsequent processes at large and reduce the time taken by them then the trade-off is acceptable.

CONCLUSION

It is roughly calculate that to fix an any kind of defect found during requirements engineering
process model cost twice the modelling and delivering the new product .This asserts the important
role of requirements engineering in any software development process. Requirement prototyping
plays vital role in requirements elicitation technique that can help identify any defects at an initial
stage and make the project more successful. We have proposed a BEE-Hive model based for
requirements engineering.

REFERENCES

[1]. Pandey, D., Suman, U. & Ramani, A.K., 2013. An Effective Requirement Engineering
Process Model for Software Development and Requirements Management. 2013
International Conference on Advances in Recent Technologies in Communication and
Computing, 0, p.287-291.
[2]. Arif.S., Khan. Q. & Gahyyur. S.A.K., (2012-2012). Requirement Engineering Processes,
Tools/Technologies, & Methodologies, International Journal of Reviews in Computing
(IJRIC), ISSN: 2076-3328, Vol.2.
[3]. Paetsch, F., Eberlein, A. & Maurer, F., (2013). Requirements engineering and agile software
development. WET ICE 2013 Proceedings Twelfth IEEE International Workshops on
Enabling Technologies Infrastructure for Collaborative Enterprises 2013, 2(3), p.308-313.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 48-54 IAEME
54

[4]. Pandey, S. K. and Batra, Mona 2013. Formal Methods in Requirements Phase of SDLC.
International Journal of Computer Applications. Published by Foundation of Computer
Science. New York. USA.pp.7-14.
[5]. Pandey, S. K. and Mustafa, K. 2010. Risk Assessment Framework (RAF). International
Journal of Advanced Research in Computer Science. Vol. 01. pp. 423-432.
[6]. Social Innovator: Ethnography research techniques, Last Retrieved on July 20, 2013
http://www.socialinnovator.info/process-social-innovation/prompts-and-inspirations/research-
and-mapping/ethnographic-research-techniques.
[7]. http://www.cs.toronto.edu/~sme/CSC2106S/slides/04-elicitation-techniques.pdf,
Last Retrieved on July 13, 2013.
[8]. AzlenaHaron and ShamsulSahibuddin, "The Strength and Weakness of Requirement
Engineering (RE) Process," presented at the ICCTD 2012: 2012 the 2nd International
Conference on Computer Technology and Development, Cairo, Egypt, 2012.
[9]. B. Mutschler, M. Reichert, and J. Bumiller, "Unleashing the Effectiveness of Process-
Oriented Information Systems: Problem Analysis, Critical Success Factors, and
Implications," IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications
and Reviews, vol. 38, no. 3, pp. 280-291, 2008.
[10]. Jiang-Ping, W., H. De-Yi and D. Wan, 2009. Knowledge conversion in software
requirement elicitation. Proceeding of the 1st International Conference on Information
Science and Engineering (ICISE), Sch. of Bus. Adm., SCUT, Guangzhou, China,
pp: 2328-2331.
[11]. Liu, L. and L. Lin, 2012. ARED-CK: An automated requirements elicitation approach based
on decision-making with complete knowledge. Proceeding of the 1st IEEE International
Workshop on Managing Requirements Knowledge, Sch. of Software, Tsinghua Univ.,
Beijing, pp: 47-52.
[12]. Mishra, D., A. Mishra and A. Yazici, 2012. Successful requirement elicitation by combining
requirement engineering techniques. Proceeding of the 1st IEEE International Conference on
the Applications of Digital Information and Web Technologies, Dept. of Comput. Eng.,
Atilim Uni., Ankara, pp: 258-263.
[13]. Ramsin, R. and R.F. Paige, 2011. Iterative criteria-based approach to engineering the
requirements of software development methodologies. IET Software, 4(2): 91-104.
[14]. Sharp, H., C.W.A. Finkelstein and H. Galal, 1999. Stakeholder identification in the
requirements engineering process. Proceeding of the 10th IEEE International Workshop on
Database and Expert Systems Applications, Centre for HCI Design, City Univ., London,
UK, pp: 387-391.
[15]. Singh, Y., P.K. Bhatia and O. Sangwan, 2007. A review of studies on machine learning
Techniques. Int. J. Comp. Sci. Secur., 1(1): 70-84.
[16]. Wongthongtham, P., E. Chang, T.S. Dillon and I. Sommerville, 2009. Development of a
software engineering ontology for multisite software development. IEEE Trans. Knowl.
Data Eng., 21(8): 1205-1217.
[17]. N. Sivakumar, Dr. P. Sivaraman, N. Tamilselvan and Dr. R. Sevukan, User Expectations
and Requirements in the Knowledge Society in Digital Era, International Journal of
Computer Engineering & Technology (IJCET), Volume 3, Issue 1, 2012, pp. 38 - 43,
ISSN Print: 0976 6367, ISSN Online: 0976 6375.
[18]. P.Salini and S.Kanmani, A Model Based Security Requirements Engineering Framework,
International Journal of Computer Engineering & Technology (IJCET), Volume 1, Issue 1,
2010, pp. 180 - 195, ISSN Print: 0976 6367, ISSN Online: 0976 6375.