Engmann, R.G.R.

Sikkel, Nicolaas

Wieringa, Roelf J.

English

We introduce a notion of business problem frames, categorizing the type of IT requirements problems found in organizations, as opposed to Jackson’s problem frames which describe a problem in terms of the solution to that problem. A survey of students’ projects showed that this a viable notion. We intend to build a case base of business problem frames, and their solutions, as a basis for further research and guidance to practitioners

University of Twente Research Information

A Case Base for Requirements Engineering:Problem Categories and Solution TechniquesKlaas Sikkel, Roel Wieringa, Rolf EngmannFaculty of Computer Science, University of TwentePO Box 217, 7500 AE  Enschede, Netherlands{sikkel,roelw,engmann}@cs.utwente.nlAbstract. We introduce a notion of business problem frames, categorizing thetype of IT requirements problems found in organizations, as opposed toJackson’s problem frames which describe a problem in terms of the solution tothat problem. A survey of students’ projects showed that this a viable notion.We intend to build a case base of business problem frames, and their solutions,as a basis for further research and guidance to practitioners.1  IntroductionA problem frame is a way of structuring a problem, of partitioning it into principalparts, such that solutions are easier to find than they would be with a different frame.Software Engineering work in patterns [2] and architectures [1, 5] can be viewed asan attempt to define an inventory of problem frames for programmers and softwarearchitects . Michael Jackson’s problem frames do the same for software requirements[3]. We call these requirements problem frames .Many of our students do a Master’s project involving requirements analysis outsidethe university. We hypothesized that requirements problem frames would be a usefulstarting point for these student projects, but this appeared not to be true. Jackson’sframes feel like solution frames: they describe what a good problem decompositionlooks like, but provide little help in how to decompose a problem. Our students alsotend to think in solutions, but with one important difference. How to analyze, frameand occasionally reframe a problem is a skill they have not yet mastered.In order to guide the analysis process, we investigated whether we could identifybusiness problem frames, describing the IT problems that organizations areconfronted with, as opposed to the solutions that can be applied to these problems.By analyzing several dozen students’ projects, we identified a small number ofoften recurring business problem frames. We conjecture that it is a valid notion worthto be pursued. We intend to further consolidate and refine our taxonomy of framesand develop a case base of project reports structured according to these frames. Withan additional set of guidelines, supported by evidence from the case base, we hope totrain novice requirements engineers to become reflective practitioners, skilled inframing and reframing problems.Proceedings of the Sixth International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'00)Essener Informatik Beiträge 5, pp. 80-85© Abteilung Software and Systems Engineering, Fachbereich 6, Mathematik und Informatik, Universität GH Essencf.: http://sse.informatik.uni-essen.de/conferences/refsq2  Problem categoriesWe started reviewing students’ projects without a particular classification scheme,and found that the problem descriptions clustered into a small number of  categories.An enumeration of problem categoriesThe following problem categories emerged in a bottom-up analysis.1. Unidentified problems. “We know that there is something wrong, but we do notknow what is wrong.”  The real problem has yet to be identified. These are thehardest problems to solve because not even the criteria by which a solutionproposal should be evaluated, are known.2. COTS type. “We  know what our problem is, and we are looking for a system thatcan solve our problem. We do not want to build something. Which type of COTS(commercial off the shelf) system would help us?” For example, would a simpleemail system help us or do we need an advanced groupware system?3. COTS product. “We know what our problem is and we know what kind offunctionality we are looking for. Which particular COTS system should we buy?”For example, we want to buy a workflow management system. Which vendor dowe choose?4. COTS extension.  “We have a COTS system that works satisfactorily, and wewant to do other things with the system as well. Can we extend the functionalityof our system?”  For example, we have an ERP package and we want it toinclude parts of our business.5. New functionality. “We know what our problem is and now we want to obtain asystem that solves it. Which functions should this system have?”6. Extended functionality. “We know what our problem is and our current systemdoes not solve it adequately. How should we change the functionality of thissystem in order to solve our problem?”7. Architecture. “We know what our problem is and our current system does notsolve it adequately.  We also know  which functionality our system should have.Which revised architecture should this system have in order to solve ourproblem?”A systematic classification of problemsHaving identified seven problem categories in bottom-up fashion, the question ariseswhether this is a logical classification, or merely a haphazard partitioning of thesearch space. A more systematic top-down analysis provided a foundation for thesecategories. A problem is assigned to a category by answering a small series ofquestions. A full decision tree is shown in Figure 1.Q1: Is it known what the problem is?If not, the task is to identify the problem.Q2: Is it known what the solution is, i.e., which system functionality could solve theproblem?Requirements analysis typically should identify desired functionality, but someinteresting requirements problems may remain when answered affirmatively. Weconsider both cases.(i)  Problem known, functionality to be determinedWe continue with the next two questions.Q3: Should the current system be continued?That is, should the current system be extended or replaced?Q4: Is it a constraint that the new/extended system should be COTS?A decision to look for COTS constrains the search space and influences the way inwhich the requirements analysis is to be performed: the emphasis is on evaluatingwhich COTS system can contribute to solving the problem. Otherwise, the emphasisis on analyzing which functionality is needed.(ii) Problem and desired functionality knownThis gives rise to two interesting cases.Firstly, when a new COTS system is wanted, the appropriate system has to beselected (category 3). This is rather different from category 2, where it is unknownwhich type of system would solve the problem. Here we know the type of system weare looking for, but a particular vendor has to be selected. It is not uncommon that thefunctionality of competing products is very similar; features that truly distinguishCOTSwantedarchitect-ure OKcontinuecurrentsystemrequestedfunctionalityknownproblemknownCOTSwantedCOTSwanted[4]selectadditionalmodules[6]extendcurrentsystem[3]SelectCOTSproduct[7]improvearchitect-ure[2]selecttype ofCOTS[5]newfunction-ality[1]identifyproblemno req.problem—buy it!no req.problem—build it!continuecurrentsystemCOTSwantedno req.problem—build it!YYY YYYYY NNNNNNNNYNFigure 1: decision tree for business requirements problem classificationthese products are more likely to be nonfunctional [4].Another interesting case arises when the extension of a system implies a nontrivialrestructuring. If you know which custom extension you want, the appropriate questionisQ5. Does the current system architecture support the requested extension of thesystem?Typical nonfunctional problems are performance bottlenecks and maintainability of aheterogeneous collection of subsystems grown over the years. The task is to design abetter system architecture with the same functionality.Applicability of the classificationHaving derived the classification of business problem frames, the question arises howwide the applicability of the framework is. We note the following issues.Requirements problems outside the scope of this classificationIt is assumed that there is a single major requirements issue. However, there aresituations with multiple, interrelated problems. For example: A major bank wants anew architecture for all their IT while at the same time it is not clear whichfunctionality should be supported by this architecture three years from now.  Theseare wicked problems that are very hard to solve well and this is not the type ofproblem you would commission to a Master’s student—but it has to be acknowledgedthat, obviously, such projects cannot be addressed by framing it as a single businessproblem.Borderline casesIn some cases the answer to a question is not a definite yes or not but e.g. “likely” or“probably”.  A typical case is that a COTS solution is the most likely option but not aprecondition.An example: The administration of a city in the Netherlands is establishing anetwork of branch offices in different parts of the city. A pilot study with anexperimental branch office revealed that customer relation management (CRM) is aproblem and the software used is highly inappropriate. A new CRM package isneeded. The problem is known (Q1: yes) but the functionality of a solution systemstill to be determined (Q2: no). The current system should be discarded (Q3: no). Is aCOTS solution sought?  Good question. The IT department of the city could  producea system (they built the current one!), but it is estimated that buying a CRM packagewould be a lot easier and better.In this situation, as outlined above, framing the problem as category 2 (COTS) or 5(custom built, or perhaps COTS) makes a difference for how to address the problem.In the latter case you do a classical requirements analysis, starting with eliciting theparticular needs of the users. In the former case you would evaluate the functionalityof COTS CRM software at an earlier stage and use that to constrain the solutionspace. Ex post we can observe that in this particular case frame category 5 waspreferred for pragmatic reasons (a priori exclusion of the city’s IT department wouldhave had certain disadvantages) but at the time no explicit choice was made.Even though it is hard to classify the problem in the given taxonomy, weconjecture that it would have been helpful to have the taxonomy, so as to bring out theissues involved and make explicit which ways there are to address the problem. In thegiven example it is likely that an earlier study of COTS solutions would haveincreased the effectiveness of the project.The surface problem is not the real problemOne should always keep an open eye for the possibility that the problem was framedwrongly and should be reframed. Any approach in requirements engineering shouldbe sensitive to the fact that it is not uncommon that the problem for which a solutionis sought is but a symptom of a deeper underlying problem.3  Structuring Business ProblemsWe can identify a short list with generic questions that can be asked for each of aboveproblem frames—but the answers are different for different frames.(a) What are the principal parts of the problem?(b) Which questions can we ask to learn more about the problem?(c) Which techniques can we use to obtain answers to these questions?(d) Which solutions patterns—i.e., solutions known to have worked in the past—canbe found?(e) Which techniques can be used to describe those solutions?Questions (a-b) are part of the problem frame, in the sense that they address what theproblem is, whereas questions (c-e) refer to ways of how the problem can be solved.Note that Jackson’s problem frames relate to question (d).The guidance that we can give to a (novice) practitioner takes the form of achecklist of questions that could be relevant and techniques and method fragmentsthat could be used. There is no general method that works in all cases; the practitionerremains responsible for his own judgement as to which parts of the problem frameand the solution techniques are applicable in a given business context.In order to further substantiate this, we intend to build a case base with structuredsummaries of requirements analysis projects. We could fill the case base with roughlya hundred cases from the past and we expect an influx of several dozen new cases peryear. The crucial question is how to structure the case base. We have a first draft of alist of semi-closed questions describing salient aspects of requirements analysisprojects, but we envisage several iterations until we have a stable structure.4  DiscussionAny method for addressing practical problems has to seek a balance betweengenerality and situatedness. Method Engineering (ME) aims to allow practitioners toconfigure a method from existing fragments as they see fit within a given context. Atthis basic level, our approach of business problem frames fits well with ME.The rise of CASE tools has made it more difficult to combine method fragments;much ME research effort in Software Engineering has gone into the development ofappropriate metatools, also known as CAME tools, and empirical research in this areahas been somewhat neglected [6].  We consider it very important that our researchinto business problem frames is grounded on empirical data.ConclusionsMichael Jackson’s problem frames are very useful to organize a problem as acollection of solvable subproblems. However, they provide little help how todecompose a problem.We have attempted to make a categorization of business problem frames , whichaddress an IT requirements problem in terms of what the problem is, not in terms ofthe proposed solution. First findings show that this notion is useful, as it help clarifywhich kind of problem is at stake and gives some guidance about how to address theproblem. This guidance takes the form of checklist of points to consider and possiblyuseful techniques. Most problems quite naturally fit into one of the problemcategories. For borderline cases it does no harm to consider these from multipleperspectives.It should be noted that these are indeed first findings, and a starting point, ratherthan a conclusion,  for a type of research that we consider worthwhile to pursue.To that end we intend to establish a case base of requirements projects. Thepurpose of this case base is threefold: (1) use the gathered empirical material tofurther delineate the idea of business problem frames, (2) improve guidelines in theform of checklists on how to address a problem that suits a given frame, and (3) allowthe case base to be searched for similar cases by students and others working on arequirements problem.References1. Bass, L., Clements, P. and Kazman, R. (1998). Software Architecture in Practice. Addison-Wesley, Reading, MA.2. Gamma, E., Helm R., Johnson, R. and Vlissides J. (1994). Design Patterns – Elements ofReusable Object-Oriented Software. Addison-Wesley, Reading, MA.3. Jackson, M.A. (1995). Software Requirements and Specifications: A lexicon of Practice,Principles and Prejudices. ACM Press, New York.4. Maiden, N.A. and Ncube, C. (1998). Acquiring COTS Software Selection Requirements.IEEE Software, 15(2):46-56.5. Shaw, M. and Garlan D. (1996). Software Architecture – Perspectives on an EmergingDiscipline. Prentice Hall, Englewood Cliffs, NJ.6. Tolvanen, J.P., Rossi, M. and Liu H. (1996). Method Engineering: Current researchdirections and implications for future research. In S. Brinkkemper, K. Lyytinen and R.J.Welke (Eds.) Proceedings IFIP TC8 WG 8.1/8.2 Working Conference on MethodEngineering, Chapman & Hall, London.

A Case Base for Requirements Engineering: Problem Categories and Solution Techniques

https://ris.utwente.nl/ws/files/5408830/refsq00.pdf

A Case Base for Requirements Engineering: Problem Categories and Solution Techniques

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information