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