requirment analysisusingvord

8/3/2019 Requirment AnalysisUsingVord

1/6

105

REQUIREMENT ANALYSIS USING VORDiel jka PoigajUniversity of ZagrebTrg J.F.Kennedy 610000 Zagreb

Croatiae-mail: zpozgaj@efzg .hrABSTRACTThe requirement analysis i s a part of a global regirirenient engineering proc ess. It is used indetecting and collecting the stakeholders requirements important for developing theit form ation system or sofhvare system only. Viewpoint-Or iented Requirement DeJiliition(VOrcO) method is applied in the requirement analysis process. The method supports aservice-oriented approach which is suitable for iiiteractive systems. Using this method theanalysis is based on external viewpoints which interact with the system by receiving servicesfrom it and proceeding data to the system. n e analysis of request fo r Point-ofisale (POS)system in a supermarket is presented in application of this method.Keywo rds: Requirement engineering, requirement analysis, VORD method.

1. INTRODUCTIONThe first activity in the life cycle of d eveloping the w hole information system or a softwaresystem, is a requirement engineering. The role of requirement engineering and requirementanalysis is permanently increasing. In the early years of software development life cycleprocess, the efforts invested in requirement analysis were estimated at lo%, in the processyear at 20%, and today in the production era at 40% of a total invested efforts (Marciniak,1995 ). This information point o ut that the most required part in software development processis not anymore programming, designing or testing, but requirement analysis. Interactivesystems whose operations involved a significant degree of user interaction, have a veryserious problem in identifjring all clients needs. At the same time the analyst has to be surethat all needs are recognized in the valid way. The VOR D method is very useh1 in detectingthe users needs, in fact in recognizing the services, that a user expects from the new sy stem.That is why the VORD method is presented in this paper.

2. REQUIREMENT ENGINEERINGThe requirement engineering proce ss is a structured set of activities which is concerned witheliciting, structuring, analyzing, validating and documenting the system requirements.Sommerville (Sommerville,1995) defines requirement engineering as the process ofestablishing the services the system should provide and the constrains under which it mustoperate. David (Marciniak,1995) considers that the requirement engineering is a morecomplex proces s as it includes a systematic use of proven principles, techniques, languages,and tools for cost-effective analysis, docume ntation, and ongoing evolution of user needs andthe specification of external behavior of system to satisfjr those user needs. In fact, tfierequirements phase translates the ideas in the minds of the clients (the input), into a _ f o r m ldocument (the output of the requirements phase), The transition from analysis to specification

22 Int. Conf. Information Technology interfaces /T/2000, June 13-16, 2000,Pula, Croatia


2/6

can be quite hard. The reasons for this is in different objectives of the two activities:-Thestructure of the problem and its various components need to be clearly understood besidesunderstanding its inputs and outputs. Inputs in this process are: information about existingsystem, stakeholder's' needs, organizational standards, domain information etc. T he expectedoutput is Software requirement specification(SRS). Many outputs of the analysis are not useddirectly in S RS . They are essen tial in modelling the problem that le ads to the properunderstanding of requirements, which is a prerequisite to specification. The SRS completelydescribes what the proposed softw are should do without describing how the s oftwar e will doit.. It is used to communicate the requirements to custom ers, engineers, managers etc.The structure of SRS is proposed in the IEEElANS I 830-1993 standard (Pajkaj, 1997):Introduc tion (purpose of requiremen ts document, scope of p roduct, definitions, acronyms,abbreviations, references, overview of the remainder of the document);general description (product perspective, product functions, user characteristics, general

constraints, assumptions and d ependencies);specific requirements (covering functional, non-functional and interface requiremen ts);appendices;index..

Requirements are written as paragraphs of natural language text supplemented by diagrams.When SR S is com plitely finishe d, it is an initial docum ent in softwa re developing process.

3 . REQUIREMENT A NALYSISThe emphasis in requirements analysis is on identifying what is needed from the system, nothow the system will achieve its goals. This task is complicated by th e fact that th ere ar e oftenat least two parties involved in software development - a client (end-user) and a developer(analyst). The interaction between these two parties causes a communication gap, which hasto be adequately bridged during requirement analysis.

There ar e som e major problems according to:obtaining the necessary information,resolving the contradictions that may exist between the information obtained.organizing the information obtained, - _

Th e activitie s directly involved in the requirement analysis process are (Somenville, 1995):Requirements collectionClassificationConflict resolutionPrioritizationRequirements validation.

The requirements are collected by interacting communication with stakeholders. Theidentified requirements are an unstructured collection that has to be classified in coherentclusters. It is possible that som e of collected requirements should be in conflicts. In tha t ca se'A stakeholder is everyone who may have som e direct or indirect influence on the systemrequirements. E.g. end-users, clients, managers, engineers for related system, domainexperts.. . --

22"' Int. Conf. information Technology interfaces IT/ 2000, June 13-16, 2000,Pula. Croatia


3/6

the analyst has to discover and resolve these conflicts. Also, in interaction with stakeholdersthe analyst has to determine the priority of the requirements. Using validation the stakeho ldersvision of the new product is checked; as well as completeness and consistence' of therequirements.The basic principle used in analysis is "divide and conquer". This is the concept of solvingdificult problems by dividing a problem into a set of smaller, independen t problems that areeasier to un derstand and solve. The partitioning, abstraction, state and projection are also veryusefd concepts in analysis, especially in viewpoint-oriented analysis. The VORD method isan accepted state and projection concepts.

4. THE VORD METHODThe viewpoint approach was first mentioned in 1970's. Since that time the approach has beenincorporated in some methods like Structurea Analysis and Design Technique (SADT),Controlled Requirements Expression (CORE.), etc. Kononya and Sommerville developedVORD in 1992 (Sommenville, 1995). It was proposed as a service-oriented method suitablefor interactive systems where v iewpoints were analogue to clients in a client - server systems.The method is principally indended for requirements discovery and analysis, but also includessteps t o help translate the analysis into an object-oriented system model.VORD as a prototype requirement engineering tool is written in ParcPlace Smalltalk byKotonya and Sommenville too.The V ORD method is used in the phase o f requirement analysis process. It is based on threeiterative steps:Viewpoint2 dentificationViewpoint structuringViewpoint documentationViewpoint-oriented analysis is trying to analyze a system from multiple perspectives, with thegoal of capturing all possible requirements. As the analysis process is going to be highlydependent on the organization, and the analyst has to refined their understanding of theapplication domain, the specific problem to be solved, the organizational needs andcons traints and the specific facilities needed by stakeholders.

. .

The ap plication of VORD m ethod should be presented as a case study of Point-of-sale (POS)system in a supermarket.. .4.1. Viewpo int identificationUsing brainstorming method all potential viewpoints, system services, data inputs, non-fbnctional requirements, control even ts and other entities that interact with the system, shouldbe identified.

A viewpoint is anyone or anything that receives service(s) from the system.

22ndnt. Conf. lnformafion Tech nology lnterfaces /TI 2000, June 13-16, 2000, ula, Croatia


4/6

1 0 8

FReference: Buy ing goods

At the beginning, the stakeholders have to be identified. They a re looking at the POS ystemin their own way. In this case some of stakeholders are: buyer, cashier, head manager,logistics, accountancy, bank etc. (Fig. 1 ).

Figure 1 . Stakeholders in PO S systemViewpoints ( scanner, credit-card, bill, etc.) and services ( buying goods, payment selection,bill printing etc .) should be detected to o.Viewpoints and services may be collected using standard template forms too. Th ere

Reference:Attributes:

Events:

Services:

Sub Vps :

1 1 .uyer

- Cash- C a r dBill receivingLPayment selectionGoods with drawingPaymentBuyinggoodsRet urn packingBill deliveryCash buyerCredit buyer

/JRationale: T o atisfy necessity

for buyingT o pay without cash

Specification: Buyers choose hegoods, couldwi t hd r a w when r e ethe pr ice or a billsum,could select thew ay of payment,could choose themanifold way ofpayment

vps: BuyerNon unctionalrequirenmnts: Quick service

Co rrect sum

Figure 2. Viewpoint and service templateare two typical forms: the viewpoint template (for viewpoint information) and the servicetemplate (for service information). They provide some detailed information about viewpointsand services themselves and about their relationship too. Each service that mentioned within aviewpoint temp late has their belonging service temp late (Fig. 2.).

- -

22"d nt. Conf. information Technology lnterfaces /T I 2000, June 13-16, 2000, ula, Croatia


5/6

F .4.2. Viewpoint structuring

Serv i ce listEar-code readingQuontity typingPayment choseingBill v r f r&n~Bill cancellingCash acceptingCredit-card accepting

All stakeholders, viewpoints and services should be structured. Some services are alwayslinked to som e stakeholders, som e viewpoints or to both o f them. Also, the sam e services maybe allocated to several stakeholders (Fig. 3.).

?%etc .

The same service has different meaning for different stakeholders. The service bill printingmeans for:buyer - more information about prices of the go ods they already bought, and the total sumthey have to pay,cashier- he information about the amount they have to pay up,project manager - the p roblem o f design ing the bill (every bill has four prescribedconditions).

BUYERetum 6uliymodsI i e t u m P W

3UYERService l i s t

P E R S O N N E L

Cash paymentCredit-card pay.Debit paymentCash paymentVoucher paymentDeposit paym entReturn deposit pay.B&?l FiTZiiag

CASHIER HEAD MANA GER LO GIST1 CS A C C O U N T A N C Y

Figure 3 . Services allocated to the stakeholders

caphPlynMt

Using decomposition technique, the basic requirement analysis principle divide andconquer is realized. Tw o types of diagrams are used in the process of deco mposition:a hierarchical diagram (Fig. 4) for v iewpo ints hierarhical presen tation (a buyersviewpoints and services are included), anda data flow diagram (Fig. 5 ) for selling goods process presentation (data and controlanalysis are included).

CREDIT BUYER

Figure 4. A hierarchical decom pisitionsdiagram

22dnt. Conf. lnformafion Technology lnferfaces 1712000, June 13-16, 2000, Pula, C roatia


6/6

1 1 0

Figure 5 . Data flow diagram

4.3. iewpoint documentationAll stages in requirement analysis process are deeply docume nted. Resulted docum ents serveas a basis for SRS document development.

5. CONCLUSIONThe paper is presenting the VORD, a method used in requirement analysis process fordetecting possible requirements especially in interactive systems. It sh ows the way t o identifystaheholders' needs by using brainstorming and standard templates. The identified services arestructured and allocated to the viewpoints through the service list. Viewpoint hierarchystructuring together with data m d control analysis diagrams should help in recognizing therequirements too. All detected requirements are valid through iterative communicationbetween users and analyst. The last step in requirement engineering is SRS docum ent that puttogether all recognized requirements.

6 . REFERENCE1. Jalote, P (1997), A n Integrated Approach to Software Engineering, Springer, NewY ork2. Kotonoya, G., Sommerwille, I (1998), Requirements etigirieeriiig,John W ily& Sons Inc.3 . Sommerwille, I (1996), Software Engineering, Addison-Wesley Publishing, Wokingham4. Marciniak, J (1994), Encyclopedia of SofhYare Engineering, Vol. 1-2. John Wily& SonsInc., Ne w York.

22"' Int. Conf. lnfofmation Technologyinterfaces /TI 2000, une 13-16, 2000, Pula, Croatia

requirment analysisusingvord

Documents