Handling Requirements Using FlexREQ Model - IEEE Xplore

4 downloads 416 Views 759KB Size Report
software development to agile software development. Research shows that the traditional software development can't handle rapid change in requirements ...
Handling Requirements Using FlexREQ Model

Abstract-

Saad Masood Butt

Wan Fatimah Wan Ahmad

Computer and Information Sciences

Computer and Information Sciences

Department

Department

Universiti Teknologi PETRONAS

Universiti Teknologi PETRONAS

Tronoh, Perak, Malaysia

Tronoh, Perak, Malaysia

[email protected]

[email protected]

Requirements

Engineering

(RE)

is

one

of

Human Centered Software Engineering (HCSE). Then it will present a complete methodology of FlexREQ to handle the requirements. The paper will end with the results and discussion of the proposed model.

the

important disciplines of software development. With the passage of time, software development process changed from traditional approaches to agile approaches. RE techniques also changed from

traditional

development.

software

Research

development

shows

that

the

agile

software

traditional

to

software

II.

development can't handle rapid change in requirements while the

The framework proposed in [5] is a combination of traditional and agile software development approach to handle rapidly change requirements in building large scale systems. The framework consists of two parts: (1) an agile philosophy of soft structured requirements gathering approach and (2) a tailored development process that can be applied to small and large system. The experimental model discussed in [6] shows that adopting one technique for requirement elicitation is not appropriate. An integrated based approach for requirement elicitation is much better and helpful to get correct requirements. The experimental model contains two folds: (1) to encourage business analyst not to restrict themselves to the standard approaches of requirement gathering and (2) getting incomplete requirement is due to adopting one technique for requirement elicitation, the best way is to adopt integrated based approach for requirement elicitation. Formal methods and techniques are developed to resolve RE problems. Davis et al. mentioned in [7] that interviews are one of the techniques in RE use to gather requirements. But interviews are not an effective way of getting requirement also this will not help to get clear requirements. Interviews only help to give a clear understanding of particle topic. In the light of software maintenance, Chua et al. describe [9] user requirements that were not clear during the initial requirement gathering phase leads to rework to change requirements during and maintenance. Due to this rework more effort needs to accommodate those requirements and eventually it will of software maintenance. Gruenbacher stated in [15] that successful collaboration of stakeholder's in requirement gathering increase the quality of software. Stakeholders include users, project, manager; developers, customers and analyst etc. are from different background having different technical skills. Using informal language in order to engage them on one common plate will lead to success of RE. A set of tools supported-view developed by Gruenbacher for software developer to foster the involvement of stakeholders in collaborative requirement negotiations.

agile approach can handle rapid change in requirement during and after the software development. In this paper an overview of RE

followed

reviewed.

by

Also

different a

unique

software model

development

FlexREQ

to

project handle

is RE

approaches though Dynamic Link list (DLL) and an Entity Relation Model (ER Model) is discussed.

Keywords: requirements engineering, software requirements, requirement elicitation, requirements gathering, ER-Model, Dynamic Linklist

I.

LITERATURE REVIEW

INTRODUCTION

Requirements Engineering deals with identifying, modeling, communicating and documenting the requirements of a system that is going to develop. RE describes what is required to be done but not how to implement [1]. Traditional RE is not compatible with agile software development. Because RE use to rely on maintaining documentation for knowledge sharing while agile software development follows different approaches to meet similar goals [2]. In order to avoid from costly rework, RE helps to know what to build before development of system starts. This helps to build two important assumptions based on the fact of costly rework: It will be very costly to correct the mistakes if they discovered later [3] A stable set of requirements is possible to determine before system design and implementation starts [4]. •



Both in traditional and agile software development users and stakeholder are the key elements in RE work, as they own the knowledge about the system going to be developed. The only major difference between traditional software development and agile software development in the light of RE is that, in the traditional software development involvement of user and stakeholder is only at the requirement gathering phase while agile software development involves user and stakeholder throughout the development process. This Paper will first summarize literature review. It will then give a brief overview of related work in the field of 978-1-4673-2008-5/12/$31.00 ©2012 IEEE

661

Incomplete requirements

Incomplete understanding of needs

Incomplete domain knowledge

Poor user collaboration

Overlooking tacit assumptions

Incorrect requirements

III-defined system boundaries

Misunderstanding of system purpose

Ambiguous requirements

Synonymous and homonymous terms

Un-testable terms

Unnecessary design considerations

Inconsistent requirements

Non-solid intention of requesters

Different views of different users

Unfixed requirements

Fluctuating requirements

It is a good small development team can interact with customers only if the problem is small. But for larger scale problem, whole team participation is mandatory as follows by agile approaches. III.

Agile HCSE proposed [26] and contains five phases, the first phase of CRUSIER is an initial requirement up-front IRUP. In this phase real users are considered rather than stakeholders. The needs of users can analyze by Role model and Task Models. A model based technique which is proposed in [26] is to fulfill the true meaning of agile by the help of index cards. The user role is first prioritized and use cases are developed. Similarly task models are also prioritized and analyzed which task is important first to implement. During IRUP phase, users, HCI experts, SE experts and business supports finalize the requirements. This will help to finalize IRUP phase that consists of outline of various mock-ups or prototypes. IRUP phase helps to get the real needs of users that can be described with the help of user needs and task goals.

Continuous acceptance of additional requirements

Excessive requirements

Unorganized bulky information sources

Too many requesters

Over-Commitment by sales staff

Table 1: Problems with Requirements adaped from [16]

Tsumaki & Tamai provide [16] the basis of requirements elicitation problem as mentioned in Table l. Also mentioned other problems like not properly defined user requirements [17], unable to understand users need [18] and missing attributes [19]. All these problems are difficult to understand by software developer that causes unpredicted risks in software project [20]. Standish Group mentioned in their study [20], that most of projects fail because of the requirements issues. His study highlighted some main factors in Table 2. As requirements are the base of all software development process but all development methodologies faces the problem of elicitation, management, and understanding requirements. But requirement variability is challenging Issues m all development methodologies [21]. Problem

%

I ncomplete requirements

13. 1

Low customer involvement

1 2.4

Lack of resources

1 0. 6

Unrealistic expectations

9.9

Lack of management support

9.3

Change in the requirements

8.7

Lack of planning

8.1

Useless requirements

7.5

RE METHODOLODY IN AGILE HCSE

IV.

PROPOSE EXPERMENTAL MODEL

In this section an overview of experimental work is presented Before going into detail, some important notions of FlexREQ need to be remembered. Rl

Link IN ode

I

Space

Figure 1: Structure of Requirement Entity

Figure 1 shows the structure of "Requirement Entity" contains three components. 1. Rl: for requirement and 1 means requirement one. 2. Link Node: To which node Rl will link if the requirements are dependent. 3. Space: A place where future requirements can be handled if dependent on some pervious requirement.

Table 2: Main causes of project failure [20]

Alberto Sillitti et al. [22] provide an insight view of RE techniques followed by Document-Driven and Agile methodology software development. Their study provides empirical data to show how Document-Driven and Agile Methodology can handle changes in requirement. Results from empirical data show Agile Methodology is more flexible and customer-centric than Document-Driven. As mentioned in [23] that groupware needs to be developed that can support distributed RE process activities also other activities like collaborative expression and negotiation of multiple perspectives. As stake holder and users are importance entity in RE process, if these people are located in different countries then there should be some groupware needed to support distributed RE process. On the other hand agile software development process does not rely on these standards. In the agile development process whole team is involved in requirement elicitation and management [27]. While few members of the development team involved in traditional software development approaches.

In this model a unique methodology of getting requirements is followed with the basic concept of the dynamic link list is mixed with the colors of the Entity Relationship model. The methodology is discussed in three sections A. Requirement Engineer Note (RE note) B. ER model of RE Note C. Algorithm along with Flowchart A.

Requirement Engineer Note

The first step in this model is RE note where requirement gathering team will follow agile approaches of requirement gathering from users or stakeholders. The team will write all user requirements on paper. Later team will break up requirements in two parts, one which is unique and other which are not unique and dependent. Both the requirements are then assembled in a form of Requirement Entity.

662

B. ER model ofRE Note Second step needs to draw an ER model of RE Note. This will help to draw the pictorial form of requirements entity. Dependent entity forms relation with depending entity. Those entities which are unique show no relation. e.

Algorithm along with Flowchart

Are Ji:athered Re q u i re ments. Uniq u e ?

Algorithm along with its flowchart needs to be maintained. This will help software developers to accommodate future requirements and back track those entities which showing greater dependency. Algorithm of RE Note l. Get Requirements on RE Note 2. Break the Requirements in two parts Unique and Dependent and develop Requirements Entities 3. Start the development of the system 4. If any new Requirement comes 5. Perform step 2 6. If unique, design it Else check the dependent Requirement Entity by ER Model. Once found, place the new Requirement Entity label in "Space" portion. Soon new Requirement Entity label is written another space dynamically create in Requirement Entity as shown in Figure 2. After that pause development starts again accommodating the new requirement. 7. End

Rl

Link Node R2

Modific;3tion of Requi reme nts Entity?

C

EndofRE

:::>

Figure 3: Flowchart of FlexREQ algorithm

V.

RESULTS AND DICUSSIONS

Evaluation of the FlexREQ model is done practically on three different applications. Applications are segregated in three forms Website, Databases and Desktop applications and their results shown in the form of pie charts.

R (new requirement) Space

Unique RE Note

Figure 2: Structure of Dependent Requirement Entity

• Web:olte$ • Databases •

Figure 3 describes the flow of information in algorithm in the form of Flowchart. The flow chart gives a clear picture of the process mentioned in the algorithm.

DC!sk.top oI!IppllClItlon:s

Results show 60% unique requirements were gathered in website applications where as 70% and 50% were found in databases and desktop applications during the development of RE Note Non Unique

RE

Note

• Website!'

.Optab.-ses •

Desktop applications

Few new requirements were discovered during the development phase and modification in existing requirements was found when discussed with users. Requirements dependency was checked with the help of "ER Model of RE Note" and algorithm mentioned in Section IV. It is found 40 % dependent requirements were found in the case of website applications where as 30% and 50% dependent requirements were found in databases and desktop applications.

663

Various reasons were found when new requirement came or change in eXIsting requirement. Users from different background and fall in different age factor, change in user needs, adding new features to support existing requirements are the few common reasons.

[6]

Chua ed.al, "Understanding the use of Elicitation Approaches for Effective Requirements gathering", Fifth International Conference on Software Engineering Advances, IEEE Computer Society,2010.

[7]

A. Davis, O. Dieste, A Hickey, N. Jurist, and A.M.Moreno. "Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review". In Proceedings of the 14th IEEE International. Requirements Engineering Conference, 2006, pp. 176185.

[8]

H. Frey and S.M. Oishi. How to Conduct Interviews byTelephone and in Person, London: Sage Publications,1995.

[9]

B. B. Chua, D.V. Bernardo, and J. M. Verner, "Criteria for estimating effort for requirements changes", In Proceedings of Software Process Improvement,15th European Conference, EuroSPI,2008,pp. 36-46.

Requirements (Nevv or lVIodi�ied)

_ _

hanse I n th

Unfamiliar-

[10] Gottesdiener E., "Requirements by collaboration: getting itright the first time",Software, IEEE,Yo1.20,Iss.2,Pages: 52-55, Mar/Apr 2003.

needs of User

\Nlth ne ...... t hemes

[II] Beyer H.R., Holtzblatt K., "Apprenticing with Communications of the ACM, 38(5):45-52,1995.

_ Poor unde,..st:andlng

_ Add n _ La

k

Vol Int

of IT

_Ase Fa

ra

ttvo feutures

skills

to,-

VI.

CONCLUSION

[13] McDermid l, Requirements analysis: Orthodoxy, fundamentalism and heresy, Requirements Engineering: Social and Technical Issues, M. Jirotka and J. A Goguen (Eds.), Academic Press Professional, San Diego, CA, 17-40, 1994. [14] Zhang J., Chang C. K., and Chung J., "Mockup-driven Fastprototyping Methodology for Web Requirements Engineering", In Proceedings of the 27th Annual international Conference on Computer Software and Applications, COMPSAC. IEEE Computer Society, Washington, DC, 263,November 03 - 06,2003. [15] Gruenbacher P., "Integrating Groupware and CASE Capabilities For Improving Stakeholder Involvement in Requirements Engineering", euromicro, p. 2232, Proceedings of The 26tl' EUROMICRO Conference (EUROMICRO'OO)-Yolume 2,2000. [16] T. Tsumaki and T. Tarnai. Framework for matching requirements elicitation techniques to project characteristics Software Process Improvement and Practice,2006,Vol. II,No.5,pp. 505-519.

FUTURE WORK

In this paper we have focused on how to handle new requirements and modification in existing requirements with the help of FlexREQ Model. This concept could be further extended and can add as process in software development process. It will help to manage requirements and new requirements without any conflicts between requirements. Another aspect could be to implement on different application to identify the major reason of change in requirements

[17] G. Kotonya and 1. Sommerville. Requirements Engineering Processes and Techniques. New York: John Wiley and Sons,1998. [18] K.Beck. "Extreme Programming Explained: Embrace Change",Reading, MA: Addison-Wesley,2000. [19] A.M. Hickey and AM. Davis, "Requirements elicitation and elicitation technique selection", In Proceedings of the 36tl' Annual Hawaii International Conference on System Sciences (HICSS'03), 2003. [20] The Standish Group, 'The CHAOS Report' http://www.standishgroup.comlsample_research/chaos_19941.php. viewed at March 20IO.

ACKNOWLEDGMENT

[21] Sommerville, 1., Sawyer, P., (2000) Requirements Engineering - A Good Practice Guide,John Wiley & Sons.

Author of the paper would like to thanks to Universiti Teknologi PETRONAS and other staff members for their valuable feedback during the intermediate phase of the methodology presented in this paper.

[22] Alberto Sillitti et ai,Managing Uncertainty in Requirements: a Survey in Documentation-driven and Agile Companies, IIth IEEE International Software Metrics Symposium (METRICS 2005). [23] Daniela Her1ea and Saul Greenberg, "Using a Groupware Space for Distributed Requirements Engineering", Seventh IEEE International Workshops on Enabling Technoligies,1998.

REFERENCES [I]

Alan M. Davis: "Software Requirements Revision Objects,Functions,& States",Prentice Hall PTR, 1994.

[2]

Paetsch, F., Eberlein, A, Maurer, F. (2003) "Requirements Engineering and Agile Software Development", Eighth International Workshop on Enterprise Security,Linz, Austria,9 - II June.

[3]

Kent BeckExtremeProgramming explained,Addison-Wesley,1999.

[4]

Gerald Kotonya and Ian Sommerville: Requirements Engineering, John Wiley & Sons,1997.

[5]

Soundararajan, "A Soft-Structured Agile Framework for Larger Scale Systems Development",16th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, IEEE Computer Society,2009.

Customer",

[12] Boehm B.W., Port D., "Escaping the Software Tar Pit: ModelClashes and How to Avoid Them", Software EngineeringNotes, Association for Computing Machinery,pp. 36-48,January 1999.

Software development process contains many phases but one of the important phases is RE. With the passage of time RE processes is also changed where style of software development also changed from traditional approaches to agile. The research work presented in this paper introduces a new methodology. This new methodology contains two folds; one is to remove requirement conflicts that happened due to requirements dependencies on each other and second fold will helps to handle future requirements at any phase of software development. VII.

the

[24] IEEE Standard 1362 (1998) IEEE Guide for Information Technology System Definition- Concept of Operations Document. [25] Lee, C., Guadagno, L., Jia, X. (2003) "An Agile Approach to Capturing Requirements and Traceability", 2nd International Workshop on Traceability in Emerging Forms of Software Engineering, Montreal, Canada,7 October. [26] Thomas Memmel, Fredrik Gundelsweiler , Harald Reiterer, Agile Human Centered Software Engineering, Published by the British Computer Society,Proceedings of HCl2007 [27] Constantine, L. L., and Lockwood, L. A D., Software forbUse: A Practical Guide to Models and Methods of Usage- Centered Design. Addison-Wesley, Reading,MA,1999

664