10
ORIGINAL ARTICLE Peter Merrick Patrick Barrow Testing the predictive ability of a requirements pattern language Received: 3 October 2003 / Accepted: 5 February 2004 / Published online: 28 April 2004 Ó Springer-Verlag London Limited 2004 Abstract This paper looks at a case study in the com- mercial procurement of an IT system to support learners on short educational courses. It compares the use case model created before the system was built with the use case model after the system was delivered. The original use case model was created through the application of a requirements pattern language designed to be employed during the procurement phase of an IT system. The final use case model was reverse engineered from the working application. The objective was to discover how accu- rately the original model represented the final applica- tion to provide a measure of the potential usefulness of the pattern language during procurement. Keywords Procurement Use case modelling Requirements patterns 1 Introduction Use case modelling is a popular technique for repre- senting requirements and is normally employed in the analysis phase of the software engineering lifecycle. UML [1] specifies Use case modelling as the basis of a development approach where use cases act as the input to design and as the basis of verification, validation and testing. Use cases were first introduced by Jacobson et al. [2] and have been accepted as part of the UML standard. A use case is comprised of two elements, a graphical element and a textual element that serves as a natural language elaboration. In this paper, where modelling is undertaken for the purpose of procurement, only the graphical representation is presented. This subset of a complete use case is what Kulak and Guiney [3] refers to as a ‘‘fac¸ade’’ which can be thought of as a graphical table of contents [4]. A complete description of use case modelling is beyond the scope of this paper; the interested reader is directed towards [3, 5, 6]. In addi- tion, consideration is limited to functional requirements, the ‘‘what does it do’’ question of system specification that must invariably be answered before considering the question of ‘‘how it is done’’. The scope of the enquiry is limited to a comparison of functional requirements be- fore and after the system is built. Use case modelling is not the only possible approach that might have been employed to construct a more formal requirements representation to address the per- ceived shortcomings of natural language [7]. For some practitioners the objective of requirements engineering (RE) is to translate informal observations of the real world into mathematical models [8] through the use of a specialised calculus such as that employed in the speci- fication language Z [9] or Kaos [10]. This approach may lead to models that can be proven but which many stakeholders find difficult to verify. It can be argued that the effectiveness and value of a notation is determined by how well its users are able to work with it. Use cases are easy to understand [4] where Z may inhibit requirements understanding [11] as it is acknowledged that a formal approach to requirements specification requires appro- priate training [12] which customers generally do not have. Use cases have become a popular choice for requirements expression because they allow wider stakeholder participation in the analysis, primarily be- cause they are expressed in familiar terms [13]. The first step in the process of specification is the identification of high-level goals which are refined until a set of requirements can be identified likely to satisfy those original goals [12]. The UML specification foresees use cases as an artefact of the analysis stage within a ‘‘use case driven’’ [14] approach to software engineering. This paper seeks to suggest that use cases may also have a role to play in procurement [15], a stage of the P. Merrick (&) P. Barrow School of Computer Science, Universtiy of East Anglia, NR4 7TJ Norwich, UK E-mail: [email protected] Tel.: +44-1603-592847 Requirements Eng (2005) 10: 85–94 DOI 10.1007/s00766-004-0193-5

Testing the predictive ability of a requirements pattern language

Embed Size (px)

Citation preview

ORIGINAL ARTICLE

Peter Merrick Æ Patrick Barrow

Testing the predictive ability of a requirements pattern language

Received: 3 October 2003 / Accepted: 5 February 2004 / Published online: 28 April 2004� Springer-Verlag London Limited 2004

Abstract This paper looks at a case study in the com-mercial procurement of an IT system to support learnerson short educational courses. It compares the use casemodel created before the system was built with the usecase model after the system was delivered. The originaluse case model was created through the application of arequirements pattern language designed to be employedduring the procurement phase of an IT system. The finaluse case model was reverse engineered from the workingapplication. The objective was to discover how accu-rately the original model represented the final applica-tion to provide a measure of the potential usefulness ofthe pattern language during procurement.

Keywords Procurement Æ Use case modelling ÆRequirements patterns

1 Introduction

Use case modelling is a popular technique for repre-senting requirements and is normally employed in theanalysis phase of the software engineering lifecycle.UML [1] specifies Use case modelling as the basis of adevelopment approach where use cases act as the inputto design and as the basis of verification, validation andtesting. Use cases were first introduced by Jacobsonet al. [2] and have been accepted as part of the UMLstandard. A use case is comprised of two elements, agraphical element and a textual element that serves as anatural language elaboration. In this paper, wheremodelling is undertaken for the purpose of procurement,

only the graphical representation is presented. Thissubset of a complete use case is what Kulak and Guiney[3] refers to as a ‘‘facade’’ which can be thought of as agraphical table of contents [4]. A complete description ofuse case modelling is beyond the scope of this paper; theinterested reader is directed towards [3, 5, 6]. In addi-tion, consideration is limited to functional requirements,the ‘‘what does it do’’ question of system specificationthat must invariably be answered before considering thequestion of ‘‘how it is done’’. The scope of the enquiry islimited to a comparison of functional requirements be-fore and after the system is built.

Use case modelling is not the only possible approachthat might have been employed to construct a moreformal requirements representation to address the per-ceived shortcomings of natural language [7]. For somepractitioners the objective of requirements engineering(RE) is to translate informal observations of the realworld into mathematical models [8] through the use of aspecialised calculus such as that employed in the speci-fication language Z [9] or Kaos [10]. This approach maylead to models that can be proven but which manystakeholders find difficult to verify. It can be argued thatthe effectiveness and value of a notation is determined byhow well its users are able to work with it. Use cases areeasy to understand [4] where Z may inhibit requirementsunderstanding [11] as it is acknowledged that a formalapproach to requirements specification requires appro-priate training [12] which customers generally do nothave. Use cases have become a popular choice forrequirements expression because they allow widerstakeholder participation in the analysis, primarily be-cause they are expressed in familiar terms [13].

The first step in the process of specification is theidentification of high-level goals which are refined until aset of requirements can be identified likely to satisfythose original goals [12]. The UML specification foreseesuse cases as an artefact of the analysis stage within a‘‘use case driven’’ [14] approach to software engineering.This paper seeks to suggest that use cases may alsohave a role to play in procurement [15], a stage of the

P. Merrick (&) Æ P. BarrowSchool of Computer Science,Universtiy of East Anglia,NR4 7TJ Norwich, UKE-mail: [email protected].: +44-1603-592847

Requirements Eng (2005) 10: 85–94DOI 10.1007/s00766-004-0193-5

developmental lifecycle to which they have not typicallybeen put. Although there is some precedence for pat-terns that describe well-formed use cases [16], and pat-terns of fundamental use cases [17, 18], the workpresented here, to the authors’ knowledge, represents anew perspective on the formation of use cases based onthe application of requirements patterns.

This case study was undertaken during procurementor ‘‘pre-analysis’’; the informal software engineeringlifecycle phase for which a specific requirements patternlanguage (RPL) has been developed. The burden oncommercial organisations responding to tenders is an actof weighing the likelihood of success against the cost ofproducing a comprehensive proposal. The objective ofemploying patterns to create use cases can be charac-terised as a ‘‘lightweight’’ approach that recognises theconstraints inherent in commercial tendering.

The principal question under investigation is whetheran accurate use case representation can be constructedfrom a loosely defined customer requirements statement.To this end the customer requirements statement wastransformed into a set of pre-implementation use casemodels through the application of the RPL. After thesystem was built and delivered, the completed applica-tion was captured again in a set of post-implementationuse case models. The models are compared in this paperto test the efficacy of the pattern language in creatingmodels that accurately predict the form of the finaldelivered system. It is argued that the degree to whichthe final models correspond to the initial models willprovide some evidence as to the usefulness of the patternlanguage. The research began with an analysis of thehigh level requirements contained in the supplier’s ten-der document.

The remainder of this paper is divided into adescription of the project being investigated followed byan overview and application of the pattern languageincluding all resulting diagrams both before and afterthe application was built. Results follow, along with asection on lessons that were learned and suggestions forfurther work.

2 A description of the project under examination

The project under consideration in this case study wasundertaken in Norfolk, England, where the local learn-ing and skills council (LSC) went out to tender for thesupply of a Web-enabled database with end user and callcentre operator interfaces. The request for proposal(RFP) was advertised widely in the regional press. Therewere three separate tender documents in total for thesupply of an IT system, the provision of a call centrefacility and the undertaking of a marketing exercise. Thecustomer adapted an earlier document which had pre-viously served to secure funding from the national bodyto produce their requirements statement. Potential bid-ders were invited to respond to the tender within thedeadline with proposals and costs for undertaking the

work. One potential supplier, Accent Design, a Webdesign and programming company, approached theauthors to enquire whether a response could be writtenemploying UML and use cases without entering intodetailed analysis. Historically, when invited to tender forIT projects, Accent had relied on building what theytermed a ‘‘site skeleton’’ which is a map of the screenswith which the customer would interface to the system.Although this had been successful for smaller projects,the limitations of this approach were identified as beingtime consuming to produce and difficult to verify asrepresenting a functionally coherent system. To repre-sent the customer’s requirements without detailed anal-ysis it was suggested that the RPL, already underdevelopment, could be employed. The customer’s origi-nal requirements, as described in their RFP, were takenas inputs to the pattern language. The customer received38 responses offering to construct the Website anddatabase. The Accent submission, featuring the appli-cation of the RPL won the tender and they were ap-pointed the supplier.

This paper presents the use case models created bothbefore the construction of the system and after the sys-tem was delivered.

2.1 The customer requirements

According to the RFP the proposed system should allowlearners to search for and book short courses being runin their area. The LSC sponsors one day ‘‘taster’’ coursesin a wide range of subjects that are open to the generalpublic. The objective of the LSC is to attract as manyattendees as possible with a view of supporting the UKgovernment’s stated aim of encouraging the goal of‘‘lifelong learning’’ within the wider community. Cour-ses are run by a range of providers who may themselveshave a vested interest in ‘‘showcasing’’ the educationalopportunities they provide. The objective of the courseproviders is primarily to encourage students who attendthe one day event to sign-up to a longer period ofinstruction which may lead to the achievement of arecognised qualification. Special attention is paid tofostering the involvement of individuals who may nothave achieved widely in the past, and who may thereforehave a negative association with learning.

Accordingly, the RFP specified that the system wouldhold course information to include the content of thecourse, the level of instruction and equipment necessary.A course would be described by the maximum andminimum numbers that could attend along with thecurrent number booked on the course to derive thenumber of available places. A course is described by thetime and date it will run and the location at which it willbe held. Course provider details will be represented inthe system. The system will be delivered over the Inter-net and will be connected to an email and text messagingengine. Letters will be produced giving course details,for those without internet access, confirming attendance.

86

The system must provide a comprehensive range ofreporting. Reporting should include information ontargeting and attendance by attributes such as postcode,course provider, course type, gender and previouslearning experience. Reports should be available thatrepresent bookings over different periods of time (a day,a week, a month). Current course numbers should bereported. Information on student personal detailsshould be held for use either by the individual them-selves or via a call centre operator.

The abovementioned description of the customer’srequirements is a precis of the original documentationcontained in the RFP and has been written in summarywith the intention of preserving its essential meaning.

2.2 An application of the pattern language

Patterns capture best practice and facilitate reuse. Thehistory of the patternmovement in software can be tracedfrom Alexander [1] where it was applied originally in thearchitecture of buildings. According to Alexander, apattern describes a reoccuring problem in an environmentto which a core solution has been proposed which may beapplied repeatedly without resulting in the same outcome.

Although the association between non-functionalrequirements [19] and design patterns [20, 21] is estab-lished, that between functional requirements and pat-terns is less so. The distinction has been made betweensoftware patterns that are used for implementation andbusiness patterns employed in specification. Applyingbusiness patterns capable of capturing requirements in anotation that is accessible to users yet rich enough to beinterpreted by developers offers a potential way forward[22]. As use cases have found favour to express specificrequirements, there is reason to believe they will beeffective in expressing generalised requirements such asthose captured by the pattern language employed in thiscase study.

A pattern language (or catalogue) is a collection ofrelated patterns that can be used in a non-prescriptiveway to achieve some given process.

Use cases created through the application of thepattern language are constrained to represent user goalsat different levels of hierarchical abstraction. A hierar-chical approach to the requirements modelling process isfound elsewhere in the literature such as in [23]. Theprocess of moving from goal to requirement is describedin [10] through the recognition that there exists a metalevel of domain specific higher goals that are decom-posed into lower level goals which themselves aredecomposed into sub-goals. By this approach, a goalthat cannot be sub-divided is a candidate requirement(or an assumption) that can be assigned as the respon-sibility of an individual agent. Equally, the accurateapplication of the RPL depends on the complexities ofuse case abstraction being understood as they are de-scribed according to different axes of both detail andgoal [3, 6, 24].

This RPL is comprised of the following patterns:Minimal Representation, the Usual Suspects, New-SearchModify (NSM), Informed Management, RoleBased Assignment, and Coherent Whole to produce aninitial use case model. The constituent patterns of theRPL are not presented in their entirety due to spacerestrictions; however an overview is given that intro-duces the principles governing the construction of eachmodel. A prerequisite to using this pattern language isthat a sufficient requirements specification exists. Thismust state the intended purpose of the system, althoughhow well requirements are captured, written andunderstood will vary from document to document. Thequality of the original specification statement will havean impact on the quality of the results, an issue to whichthe pattern Coherent Whole is devoted. The mostimportant prerequisite for success is that the originalspecification should include a description that includesthe nouns that will form the basis of an analysis that willlead to the identification of entities as described byAbbott [25]. The first pattern is Minimal Representationwhich requires the construction of a logical minimalmodel sufficient to support the business (Fig. 1). Theprocess of applying the pattern language relies on theexpertise of the practitioner in being able to constructsuch a minimal data model. To accomplish this task,noun analysis was applied, with the intent of identifyingcandidate nouns as entities (potential database tables).Care was taken to select only nouns that would repre-sent entities as opposed to nouns that representedattributes of entities [26]. From this analysis the fol-lowing nouns were identified as candidates for persistentrepresentation; course provider, course, student andbooking. One additional entity, course_instance, wasincluded in the representation. This was done toaccommodate the fact that a course may run on manyoccasions and on each occasion it has a unique time,date and location.

Fig. 1 The output from the Minimal Representation pattern is aset of logical entities for the storage of data sufficient to support thebusiness

87

Once a candidate data model had been constructed,the next pattern of the RPL can be applied, known asthe Usual Suspects. The objective of this pattern is toallow for quick identification of roles (known as actors[1, 2]) that have a high likelihood of occurring in a‘‘transactionally-driven’’ software application that offersa service to an end user whose needs are supported by acall centre. The customer’s tender conformed to thisprerequisite. After the application of the Usual Suspects,it is appropriate to apply the Informed Managementpattern which generates reporting use cases, oftenthought of as providing the functionality associated witha management information system (MIS).The patternRole Based Assignment provides a way of grouping usecases and representing them in a manner that is logicallycoherent from the perspective of presentation.The finalpattern, Coherent Whole provides a check to ensure thatthe system model generated represents a logical unitwhose sum provides recognisable value to its cast ofusers (actors).

Figures 2, 4, 6, 8 and 10 represent a before model ofthe system prior to its development. Figures 3, 5, 7, 9and 11 represent an after model of the system capturedvia an application inspection once the system was built.The models are presented together for ease of compar-ison. A discussion of the models follows their presenta-tion. The aggregation stereotype is used in somediagrams rather than the standard <<include>> or<<extend>> stereotypes. This is a convention em-ployed to associate abstract use cases.

The complete results of applying the requirementspattern language were presented in the preceding pagesin Figs. 4, 5, 6, 7, 8, 9, 10 and 11. All the actors identifiedin Fig. 2 also appear in Fig. 3. In Fig. 3 the primaryactor Call Centre Supervisor has been added, and moredetail is available with respect to the CommunicationsEngine. Figure 3 shows the Communications Engine asan abstract actor implemented by a small messagingservice (SMS) and email engine. The Call Centre

Supervisor is an actor that appears in the Usual Suspectspattern, and should have been accounted for in Fig. 2but was omitted due to uncertainty in the originalspecification as to the sophistication required in the callcentre handling functionality.

The RPL specifies that after the application of theUsual Suspects pattern, the NSM requirements patternis applied. This pattern is based on the Create, Read,Update, Delete functionality more commonly known asCRUD [17]. In NSM, the concept of ‘‘Delete’’ func-tionality is subsumed within the concept of modification.According to this pattern, NSM functionality is definedover every logical data entity specified in Fig. 1. Thecomplete available set of use cases generated by thispattern is given in Table 1.

The fourth pattern, Informed Management, is de-signed to generate management information use casesthat allow for reporting to take place. According to thispattern, reporting will be based on the entities identifiedby Minimal Representation (see Fig. 1). The bulk of thereports will centre around entities that resolve many:-many [26] relationships, in this instance, bookings.

With the application of the first four constituentpatterns specified by the RPL, the fifth pattern can beutilised to draw relationships between the identified ac-tors and the identified use cases. This pattern is termedRole Based Assignment. It defines use cases on the basisof identified roles. To facilitate this, an abstract actor,User is introduced to aid the representation. The patternis completed by assigning the use cases identified byNSM and Informed Management to the actors identifiedand specialised by the Usual Suspects.

The differences between Figs. 4 and 5 are, apart fromthe representation of the Call Centre Supervisor (ac-counted for in Fig. 3), the loss of the use cases Searchcourse_ providers and Search courses. These use cases arestill available in the implemented system confined toLearners and Call Centre Operators (see Figs. 7 and 9).All the functionality identified in Fig. 4 was implemented

Fig. 2 A diagram illustratingan application of the UsualSuspects pattern and the actorspredicted before the system wasbuilt

Fig. 3 A diagram of actorswho appeared in the finalsystem shows a strong similarityto those predicted in Fig. 2

88

in the final system, however the functionality to Login_Logoff was the only functionality shared by all users.

All the use cases defined in Fig. 6 appear in Fig. 7apart from the ability of a Learner to Evaluate course,which now appears in Fig. 11. The delivered function-ality of a ‘Learner’ came to include the provision ofbeing able to make reservations which necessitated the

addition of New reservation and Convert reservation tobooking. Additionally, Call Centre Operator gained theability to respond to enquiries.

All of the use cases in Fig. 8 appear in Fig. 9 howeverthey are not necessarily triggered by the same actor.Assumptions were made as to who would trigger certainuse cases that were later shown to be incorrect. Thefunctionality itself is the same, but the ‘‘owner’’ of thefunctionality differs. Much more responsibility is asso-ciated with the Management Administrator than wasoriginally thought. Figure 9 is a more detailed diagramthat also introduces new user-goal use cases. Whereoriginally it was assumed that either Learners wouldinput their course evaluations directly into the system, orCourse Providers would input details on the Learner’sbehalf, in the event both these assumptions were provedfalse. In the implemented system Course Providers arerequired to send completed paper evaluation forms backto the Management administrator who enters the detailsonto the system instead. This was a business rule re-quired to ensure attendance and calculate funding.

The use cases identified in Fig. 10 are all contained inFig. 11 apart from Send mail shot which was notimplemented after further consideration by the client.Figure 11 demonstrates that the task of performing theinput of course evaluation forms falls to the Manage-ment Administrator. Additionally, Fig. 11 introduces usecases that the pattern language did not foresee; ManageMedia, Report Callbacks, Calculate Provider FundingReport, and Report Search Statistics. The use caseManage Media is an aggregate that represents the col-

Fig. 4 ‘General’ functionality is one of the categories forrepresenting use cases according to the Role Based Assignmentpattern

Fig. 5 General functionality after the system was built. No SystemAdministrator was required as this functionality was performedwithout an end user interface

Fig. 6 ‘Learner’ functionality is one of the categories for collectinguse cases according to the Role Based Assignment pattern

89

lective functionality of new, search and modify over theMedia entity. Media became a table in the physicaldatabase over which the Administrator required directcontrol (as opposed to an essentially static list). ReportCallbacks hints at enhanced call centre functionality thatescaped representation by the pattern language. Unlikeany of the other use case models, Fig. 11 was furtherdecomposed to reveal sub-goal use cases aggregated byReport Bookings and Report Attendance and Evaluation.

These use cases, at the level of user goals, decomposed torepresent available reports that conform to the generaldescription but which offer many specific variations,such as reporting bookings by date range, or by courseprovider, etc.

3 Results

The results of this case study are based on a comparisonof the use case models produced before and after thebuilding of the application. It is reasonable to assumethat as a project progresses more user requirements willbe discovered and those that have been identified willgain more detail. On first inspection of the diagrams it isevident that the ‘‘after’’ diagrams contain a largernumber of use cases which might lead the observer to aconclusion that the patterns employed to generate theinitial diagrams were of only marginal benefit. Instead,before any conclusion is drawn, it is necessary to definethe basis of the comparison more rigourously.

Use cases can be represented at different levels ofabstracted goals; therefore, it is necessary to agree on thelevels being employed to enable the comparison of likewith like. According to Cockburn [6], use cases exist on agoal centred scale, ranging from ‘‘very high level’’ to ‘‘toolow’’ (very high summary, summary, user-goal, sub-function, too low). The choice of sub-function as a pos-sible classification option might better be termed sub-goal

Fig. 7 Learner functionalityafter the system was built. Thediagram features three newuser-goal use cases (Newenquiry, New reservation,Convert reservation tobooking)

Fig. 8 ‘Provider’ functionality is one of the categories forrepresenting use cases according to the Role Based Assignmentpattern

90

[24]. All of the use cases defined in the first modellingiteration feature use cases at the level of user-goal. In thesecond modelling iteration, where there are differences,Use cases have been introduced at both the user-goal andthe sub-goal level. The comparison of the models between

the first iteration and the second confines itself to acomparison of user-goal use cases and omits sub-goal usecases which are treated as an example of greater detail

Fig. 9 Provider functionalityafter the system was built.Compared to Fig. 8 thisdiagram features five new usergoal use cases (New venue,Modify venue, New subject,Modify subject, SearchProvider_courses) alongsidesome additional sub-goal usecases that add detail

Fig. 10 The use cases that appear in this diagram were generatedthrough the application of the Informed Management pattern.Management Administration is one of the categories for collectinguse cases according to the Role Based Assignment pattern. The usecase ‘Send mail shot’ was not implemented

Fig. 11 Management administration functionality after the systemwas built. Compared with Fig. 10 this diagram features four newuser-goal use cases (Manage Media, Report Callbacks, CalculateProvider Funding Report, Report Search Statistics). ‘New Evalu-ation’ was originally thought to be an action associated with adifferent actor (Learner or Management Administrator)

91

being added to a parent use case, as evidenced by theirassociation via an aggregation relationship.

According to Jacobson et al. [2], use cases are ex-pressed in the language of the user. One way of inter-preting this premise is in the sense that there is onedominant level, and that level is the user goal level. Otherlevels are greater or lesser abstractions of the same usecase which should contain the degree of detail consistentwith the current level of abstraction. Therefore, thecomparison presented in this case study is made on twoaccounts. The first comparison is on the basis of whetheruse cases defined in the first iteration remain in thesecond iteration. The second comparison looks at themodels from the perspective of the built system, andcompares the number of new user-goal use cases thatwere not predicted in the initial model.

The use case models generated before the system wasbuilt are a good reflection of the final use case models asmeasured by their ability to predict functionality thatwould be implemented in the final system. A comparisonof use cases at the user-goal level of abstraction indicatesthat only one use case predicted from the initial dia-grams was not implemented in the final system (SendMail Shot, Fig. 10). The final system contained more usecases than those predicted by the output from the pat-tern language. In the final system, there were 30 usecases delivered, of which 21 were predicted, or 70%.

Assumptions led to the mis-assignment of use cases toparticular actors in the first modelling iteration. Thiswas due to ignorance of business rules that were laterclarified. The assignment of functionality to the wrongactors was a relatively minor problem to rectify becauseof the flexibility inherent in the software architecturewhich kept permissions isolated from functionality. Ofall identified use cases, fully 23% were assigned to thewrong actor in the first modelling iteration.

4 Lessons learned

The application of the RPL is an effective procedure forgenerating a model quickly, at an early stage in theprocess, from a non-structured requirements statement.In this case study the resulting models were useful inclarifying assumptions made in the procurement processwith respect to business rules, being the subject of con-versation and informal negotiation between the supplierand the customer prior to the award of the contract.There was nothing extraordinary about this case studyto suggest the method is not more generally applicable.

Although the authors applied the patterns to theoriginal requirements specification on behalf of theprospective supplier, he reported finding the processclear and understandable and expressed the intention ofusing it again should the occasion arise.

When interviewed, the individual responsible for theselection of the successful supplier volunteered that shebelieved the models contained in the bid demonstratedthe supplier had a firm grasp of the problem to hand,had done a large amount of work in preparation andwould therefore make faster progress if chosen to do thework. The winning bid was not selected on the basis ofoffering the lowest price and was, in fact, the secondmost expensive bid from a field of 38 who competed forthe contract. The reasons the customer cited for selectingthe supplier demonstrated an application of value formoney principles such as those recommended by theoffice of government commerce (OGC) for the evalua-tion of competitive bids [27, 28].

Certain use cases, such as those that representreporting functionality, may be too coarsely grained intheir current representation at the abstraction level ofuser-goal and may be capable of prediction at the lowerlevel of sub user-goal.

Although use cases are strongly associated with therational unified method (RUP) [29] and object-orientedmethods, this project suggests use cases are usefulwithout adopting these technologies as the project wasbuilt by the supplier without any prior experience ofUML.

The use cases that were not predicted by the patternlanguage point to the opportunity for the constituentpatterns to be improved, although how and where thatimprovement should be made will not become clear untilthey have been used more often.

5 Threats to validity

This case study can do no more than suggest the methodpresented has merit. The size of the project undertaken issmall compared with many. The programming team wasalso small, made up of two programmers, which madethe need for extensive modelling beyond facade use casesunnecessary. The method is dependent on the initialconstruction of a minimal logical data representationwhich is dependent on the skill of the practitioner. Also,the entire method has been applied by the authors, and itremains to be seen if other practitioners will find it sosuccessful. The modelling depends on use cases being

Table 1 An application of theNSM pattern over the identifiedcandidate tables generated fromthe prior application of theMinimal Representationpattern

Data entity New <<entity>> Search <<entity>> Modify <<entity>>

Course_provider New course_provider Search course_provider Modify course_providerCourse New course Search course Modify courseCourse_instance New course_instance Search course_instance Modify course_instanceBooking New booking Search booking Modify bookingCustomer New customer Search customer Modify customer

92

captured at the same level of abstraction. If a use case isdecomposed to a level that is closer to implementation,and then included in a comparison, the results will bemisleading.

At present too much ambiguity exists with respect tothe management of requirements change. The distinctionbetween adding a new use case that describes additionalfunctionality or simply adding detail to an existing usecase is captured in the hierarchy of use case abstractionbut is capable of misinterpretation.

6 Directions for future work

Encouraged by the results to date, work has beenundertaken to employ the RPL in a reverse engineeringexercise for the Health and Safety Executive (HSE)whereby a model is created from a specification that re-fers to a recently built application. The model was con-structed from patterns in isolation from the existingsoftware and then compared with the final product. Theresults of this research were similar to those presentedhere. It would be desirable to assemble a body of evi-dence where the RPL had been applied to qualify theresults that have been reported so far. As many oppor-tunities as possible for the application of the RPL shouldbe pursued to add to the body of evidence. To facilitatethis it is necessary that the RPL be sufficiently wellarticulated to allow other practitioners the opportunityof applying it. In this way the usefulness of the RPL to awider user base can be tested. Work is ongoing withsuppliers to the HSE, on a new project’s specificationemploying the RPL which will go some way to satisfy theobjective of testing the method when applied by others.

It is generally agreed that requirements change as aproject progresses [30]. It is instructive to study the roleof use cases in wider project management, such as thereporting of progress, and the management of require-ments that change.

An interesting enquiry will be the exploration of therelationship between the ability to predict the model of afinished application and the estimation of effort. Thiswork will follow on from that explored in applications ofthe use case Points Method [31–34], an emerging effortestimation algorithm that takes use cases as an input.This is an area of top–down effort estimation that couldbe very useful as existing algorithms for effort estimation[35, 36] are not widely employed [30, 37].

An instructive application of the approachwould be toemploy the RPL to express functional requirements in arequest for proposal that was sent out to a range of pro-spective suppliers, to understand how supplier organisa-tions respond to a specification expressed through anapplication of the RPL, with its attendant effect onassumptions, ambiguity and cost over-runs. The questionof whether requirements can be expressed finely enoughto avoid ambiguity, yet coarsely enough to allow forevolving detail to be added as the development process

proceeds is intriguing. The purpose of attempting to put inplace a complete requirements ‘‘table of contents’’ is toaddress the problem of scope creep used to justify costincreases and schedule delays. Berry [38] describes thisphenomenon as being commonplace in other industriesand alludes to the practice taking place in softwaredevelopment whereby a contractor depends on require-ments changes to make a profit against an otherwiseunrealistic bid.

References

1. Fowler M, Scott K (1999) UML distilled: a brief guide to thestandard object modeling language. Addison-Wesley Longman,Upper Saddle River, NJ

2. Jacobson I, Jonsson P, Christerson M, Overgaard G (1992)Object-oriented software engineering: a use case driven ap-proach. Addison-Wesley Longman, Upper Saddle River, NJ

3. Kulak D, Guiney E (2000) Use cases: requirements in context.Addison-Wesley Longman, Upper Saddle River, NJ

4. Fantechi A, Gnesi S, Lami G, Maccari A (2003) Applicationsof linguistic techniques for use case analysis. Requirements Eng8(3):161–170

5. Pooley R, Stevens P (1999) Using UML: software engineeringwith objects and components. In: Booch GJ, Rumbaugh J (eds)Object technology series. Addison-Wesley Longman, Harlow

6. Cockburn A (2001) Writing effective use cases. Addison-WesleyLongman, Upper Saddle River, NJ

7. Fenton N, Pfleeger SL (1996) Software metrics: a rigorous &practical approach. Thomson Computer Press, London

8. Zave P (1997) Classification of research efforts in requirementsengineering. ACM Comput Surv 29(4):315–321

9. Spivey JM (1989) The Z notation: a reference manual. Prentice-Hall, Upper Saddle River, NJ

10. Dardenne A, van Lamsweerde A, Fickas S (1993) Goal-direc-ted requirements acquisition. Sci Comput Programming 20(1–2):3–50

11. Khazaei B, Roast C (2003) The influence of formal represen-tation on solution specification. Requirements Eng 8(1):69–77

12. van Lamsweerde A (2000) Formal specification: a roadmap. In:Finkelstein A (ed) The future of software engineering, ACMPress, New York

13. Regnell B, Andersson M, Bergstrand J (1996) A hierarchicaluse case model with graphical representation. In: Proceedingsof the IEEE international symposium and workshop on engi-neering of computer-based systems. IEEE Computer Society,Friedrichshafen, Germany

14. Various (2003) OMG unified modeling language specification,vol 1.5. Object Management Group

15. Alexander I, Farncombe A, Mohammed S (2002) Towardsbetter railway system specifications through scenarios. In: Therailway technology conference (RailTex), Birmingham. http://easyweb.easynet.co.uk/ iany/consultancy/railway_scenarios/railway_scenarios.htm

16. Adolph S, Bramble P, Cockburn A, Pols A (2002) Patterns foreffective use cases. In: Agile software development. Addison-Wesley Longman, Upper Saddle River, NJ

17. Biddle R, Noble J, Tempero E (2001) Patterns for essential usecases. In: KoalaPLoP, Melbourne

18. Biddle R, Noble J, Tempero E (2002) Essential use cases andresponsibility in object-oriented development. In: Proceedingsof the Twenty-fifth Australasian Computer Science Conference(ACSC2002). Australian Computer Society Inc., MonashUniversity, Melbourne. http://crpit.com/Vol4.html

19. Mylopoulos J, Chung L, Nixon B (1992) Representingand using nonfunctional requirements: a process-orientedapproach. IEEE Trans Software Eng 18(6):483–497

93

20. Beck K, Cunningham W (1987) Using pattern languages forobject-oriented programs. In: Proceedings of the Object-ori-ented Programming, Systems, Languages, and ApplicationsConference (OOPSLA87). ACM Press, Orlando, FL

21. Gamma E, Helm R, Johnson R, Vlissides J (1995) Designpatterns: elements of reusable object-oriented software. Addi-son-Wesley Longman, Upper Saddle River, NJ

22. Gzara L, Rieu D, Tollenaere M (2000) Patterns approach toproduct information systems engineering. Requirements Eng5:157–179

23. de Farias G, Ferreira C, van Sinderen P (2000) A component-based groupware development methodology. In: Proceedings ofthe 4th International Enterprise Distributed Object ComputingConference, Makuhari. http://citeseer.nj.nec.com/302797.html

24. Merrick P, Barrow P (2003) Towards a requirements formalismin procurement. In: Proceedings ot the 8th annual Conferenceof the United Kingdom Academy of Information Systems,Warwick, England, June 2003

25. Abbott RJ (1983) Program design by informal Englishdescriptions. Commun ACM 26:882–894

26. Connolly T, Strachan A, Begg C (1995) Database systems: apractical approach to design, implementation and manage-ment. Addison-Wesley Longman, Harlow

27. Staff writers (2002) Value for money evaluation in complexprocurements. Office of government commerce (OGC), Nor-wich, UK

28. Staff_writers (2003) The green book: appraisal and evaluationin central government. HM Treasury, London, The StationaryOffice. http://www.ogc.gov.uk/sdtoolkit/reference/ogc_library/related/Green_Book_03. pdf

29. Kruchten P (2000) The rational unified process: an introduc-tion. Addison-Wesley Longman, Upper Saddle River, NJ

30. Taylor A (2001) IT projects sink or swim. Comput Bull42(1):24–26

31. Anda B, D. H, S. D, J. M (2001) Estimating software devel-opment effort based on use cases: experiences from industry. In:4th international conference on the unified modeling language.Springer, Toronto. http://www.idi.ntnu.no/emner/sif8080/docs/faglig/uml2001-anda.pdf

32. Anda B, Angelvik E, Ribu K (2002) Improving estimationpractices by applying use case models. In: Proceedings of the4th International Conference on Product Focused SoftwareProcess Improvement, Rovaniemi, December 2002, LNCS, vol2559, Springer, Berlin Heidelberg, New York http://www.sim-ula.no/publication_one.php?publication_id=500

33. Anda B (2003) Empirical studies of construction and applica-tion of use case models. University of Oslo, Norway

34. Ribu K (2001) Estimating object-oriented software projectswith use cases. Master’s thesis, University of Oslo. http://www.stud.ifi.uio.no/ kribu/oppgave.pdf

35. Boehm B, Horowitz E (2000) Software cost estimation withCOCOMO II. Pearson Education

36. Albrecht AJ (1979) Measuring application development pro-ductivity. In: IBM applications development symposium,Monterey, CA

37. Kitchenham B (1991) Estimation. In: Fenton N (ed) Softwaremetrics: rigourous and practical approach. Chapman and Hall,London, p 132

38. Berry DM (1998) Software and house requriements engineer-ing: lessons learned in combating requirements creep.Requirements Eng 3:242–244

94