Problem Frames - Semantic Scholar

AWRE’04 9th Australian Workshop on Requirements Engineering

Connecting Role Activity Diagrams to the Problem Frames Approach Karl Cox1, Keith Phalp2, Aybüke Aurum4, Steven J. Bleistein1 3, June Verner1 1

National ICT Australia, Sydney, karl.cox, steven.bleistein, [email protected] 2 ESERG, Bournemouth University, UK, [email protected] 3 School of Computer Science and Engineering 4 School of Information, Systems and Management, [email protected] University of New South Wales, Sydney, Australia

In this paper therefore, we attempt to show how process models might be used to inform the derivation of Problem Frames. This would then allow process knowledge to be used within the requirements phase, and this will aid the non-trivial, process of ‘framing’ problems. The objective of this paper is two-fold: 1) to demonstrate a means of capturing business process knowledge in the requirements engineering phase and to show traceability from business process models through to problem diagrams and Problem Frames. In other words, we attempt to explain how process models might be used to inform the derivation of Problem Frames. This would then allow process knowledge to be used within the requirements phase, and, as noted earlier, would aid the process of ‘framing’ problems. 2) to assess whether problem frames can be readily identified in an industrial application, providing the authors with a means to discuss real world application of the approach. This article is organized in the following way. Section 2 presents a general discussion of role activity diagrams and Problem Frames. Section 3 introduces the methodology. Section 4 describes the case study and its process models. The context diagram is discussed in section 5. Section 6 presents an extended problem diagram and shows its connections to the context diagram. Section 7 presents two examples of the Problem Frames approach. Section 8 evaluates the approach and section 9 offers some conclusions.

Abstract Capturing process information in requirements is not a simple task. To alleviate this difficulty, we propose a Problem Frames approach that takes elements of process models and maps them to Problem Frames. To show where requirements have an effect on particular contextual entities, we use an extended problem diagram. From here we attempt to derive appropriate Problem Frames. The paper reports on an industrial study for a major online brokerage and financial system that describes the approach.

1. Introduction As an up-stream software development phase [1] in recent years many software developers have produced models of client business processes [2]. Although it is generally agreed that such process models are valuable in informing requirements, the exact nature of how the process model maps to subsequent requirements activities is less clear. Some authors have suggested what might be termed ‘process approaches’ [3] to development methods for this mapping, but these tend to adopt particular design tactics, where the process model replaces more ‘popular’ design notations. Other researchers have investigated how process models might relate to existing approaches, for example, mapping process models to formal approaches [4] or more latterly, to use cases [5]. Although there is merit in this research, in methodological terms they are implementation methodology dependent, which is problematic. They assume a particular design approach, whether a process-driven one or more a conventional one such as UML [6]. We assert that it would be particularly useful if process models could be used to help partition and inform requirements, without assuming any subsequent approach to design. This leads on to the idea of a combination of process models with Problem Frames [7]. Indeed, one of the premises of the Problem Frames approach is that the proper ‘framing’ of the problem should suggest appropriate notations for requirements analysis and specification [8]. In addition, it is also clear that whilst simple single frame problems may often be correctly identified, the framing of real-world problems is often far from trivial [9], implying that today’s increasingly complex systems are more difficult to frame.

2. Background 2.1 Role Activity Diagrams As an exemplar notation, we use Role Activity Diagrams [10] a well-regarded process modelling notation. A role activity diagram (RAD) is used to describe business processes that can involve actions and interactions among roles. Roles can be humans as well as software and hardware systems. A RAD provides an excellent means of describing dependencies between roles in organizations that work discretely and in unison to achieve a goal. A RAD has various components, the most common of which are illustrated in Fig. 1. All roles start in an initial state. For example, role A starts in some initial state and then has an event, an action, ‘do work’, (an action is denoted by the dark box)

2.1


which is independent of other roles. On completion of the work, the role would be said to have moved to a new state of work completed. Although states are often omitted (as in Fig. 1), a formal view would be that the event, and action of role A, has a pre-state of ‘initial’ and post state of ‘work completed’. (We have kept the states intact in our case study process model.)

problem pattern that has a known solution method. However, Problem Frames differ from design patterns since they represent real world phenomena, as opposed to solution phenomena.

Role A Do work

Fig. 2. Elements of Problem Frames Role B

Fig. 2 illustrates some essential elements of the Problem Frames model. The Real World Problem Context provides us with information about the structure, processes and tasks that are already true of the problem domain. The Requirement states which properties we wish to be true given a built software solution, the Machine, that will work within its real world context. The connection between the real world problem context and the machine is represented by the shared phenomena at the boundary between the problem and the solution. Shared phenomena can be data, events, commands and states. Domains responsible for shared phenomena between domains are described through a syntax [7],

Send work to Colleague Do work Return work to Colleague

Fig. 1. Elements of a Role Activity Diagram Some work is then delegated to a colleague. This is a shared event. Although the mechanism of delegation is immaterial, the result is that both roles involved move to the state of work delegated. These shared events are termed interactions. Although there is no sender and receiver as such, role A is said to initiate (be the active role) whilst role B is passive in this interaction (the initiator interaction is denoted by the hatched box and the recipient by the clear box). Role B is then in a state to independently ‘do work’. Role B then ‘returns work to colleague’, role A, who is in a state to receive it and so on until the process is completed. Thus, a Role Activity Diagram captures activities, such as actions a role takes on its own and interactions that multiple roles participate in, which combined present a process within a department, across an organisation and beyond out into the marketplace. Each process must achieve a business goal or requirement.

a. DO ! {x} such that, at interface ‘a’, domain DO is responsible ‘!’ for {x} phenomena. A problem diagram, containing the same elements as in Fig. 2, describes a software problem showing the problem parts consisting of problem context and the requirement. A problem diagram is a representation of a unique requirement in a unique context, a problem frame is a representation of a recurring requirement in a recurring context. Problem Frames are derived through decomposition of problem diagrams. Even though the software/hardware system may consist of multiple devices or computers, for the purpose of a problem and its context diagram these are represented as a single machine. Decomposing problem diagrams reveals a greater level of detail, including separate distinct machines, many of which will be part of recognised problem frames. Much research on Problem Frames has tended to focus on what the requirements engineer does when he or she has determined a Problem Frame and wants to engineer a solution from there [8, 13-15]; however, this research does not to address issues of higher-level problem analysis and decomposition. Other Problem Frames research in contrast has focused on higher-level problem analysis specifically in the context of e-business systems [16-19]. The research presented in this paper extends this latter category of Problem Frames research. Our research builds specifically on the work of Cox and Phalp, who presented a position paper that included ideas for connecting process models to Problem Frames [16] and then developed a full paper, using an industrial case study for validation [19]. The same case study is used here though we use a very different approach to Problem

2.2 The Problem Frames Approach Problem Frames capture and classify software development problems [7, 11]. A Problem Frame structures the analysis of the problem within its problem space. It describes what is in the Real World and how the software is intended to change or guarantee real-world conditions in accordance with the requirements. With its emphasis on problems rather than solutions, the Problem Frames approach uses an understanding of a problem class to allow the “problem owner” with his or her specific domain knowledge to drive the requirements engineering process. Problem Frames are a means of understanding and describing the problem context when software will provide (some part of) the solution. As such they are akin to design patterns [12] in that they provide a recognised

2.2


Frame derivation here; aspects of the case not covered in [16, 19] are addressed here.

understand different aspects of the application and possibly scope the requirements into relevant chunks. From here, it should then be possible to select appropriate approaches to software development that are known best fits for the types of frames identified [8, 13]. In this paper, however, we attempt only to describe how to get to problem diagrams and frames.

3. Methodology Our research objective is to find a connection from process models to Problem Frames so that we can reason about requirements more effectively. This means that business process knowledge will not be lost to the requirements engineering team and thus real world relevance is captured. It is also the case that there is no pre-defined starting point to conduct a Problem Frames analysis. As such, we chose practically since the Company under discussion in the case study bounded their problem with business process models. Thus we bound our Problem Frames analysis at the business process. This does not mean that process modelling is the definitive boundary for software problem analysis. Indeed, Bleistein et al. [17, 18] bound their e-business Problem Frames analysis problem at the business strategy level since this is where the company in their case study bounded their problem. The approach adopted here was developed during the case study, in an action research setting, and primarily as a means of addressing rapidly the Company’s problem in an appropriate manner. We thus take a simple approach in connecting processes to requirements, as described in Table 1.

4. Case Study and Process Models The case study took place in a global financial services organisation, named henceforth as the ‘Company’, who wish to remain anonymous for reasons of confidentiality. The authors carried out a consultation exercise for a specific software problem that the company faced. It needed to re-engineer its customer application and form printing processes for an online stock trading system. The system allows online applications for trading and government bond accounts. A Customer completes forms online and has to enter specific banking and personal information, dependent upon the account type required. If credit clearance is given then an account is activated and the Customer can start to trade. A high street Bank houses the Customer’s physical account, and provides cheque books, bank cards and other services, so long as the Customer passes the Bank’s own credit checks.

4.1. Business Process Model

Table 1. Mapping RAD to Domains and Requirements RAD

Context Diagram

Role

Domain of Interest / Machine

Interaction

Interface

Action

-

The Role Activity Diagram (Figs. 3a and 3b) describes how the envisioned process for Customer Application will work. The complex process of application begins with the Customer applying. A credit check is performed and the Customer informed of the success of the application. A new account is created. The relevant Pack code is generated – a reference number for the type of application applied for and what forms to print. (There are 21 pack types, though it was predicted this might rise to nearly 50 with new products; the goal was to reduce this number dramatically by re-engineering the application-print process.) The Print Room Staff proceed to print the application forms and documents. The Customer must return signed documents for the trading account to be activated within 10 working days of application. The Customer is informed of account activation when the Company Admin receives the Customer’s signed forms. At this point the high street Bank is informed of the account details. The Bank validates the account and can reject it if necessary. If accepted, the Bank will send account materials (cheque book etc) to the Customer.

Domain Reqts Diagram Domain of Interest / Machine Interface / Requirement Requirement

As can be seen in Table 1, there are three columns, Role Activity Diagram and its core elements of Role, Interaction and Action. The next column describes the Context Diagram and where elements map from the RAD. A Context Diagram depicts domains of interest, the machine and the interfaces capturing shared phenomena between them. The requirements (ovals) are only depicted when added to the Context Diagram, creating an extended problem diagram. A Role in a RAD has a one-to-one mapping to a Domain of Interest or Machine in both the Context Diagram and Problem Diagram. An Interaction in a RAD can be mapped to an Interface in both the Context Diagram and the Problem Diagram. An Action in a RAD cannot be described in a Context Diagram but can be captured as a requirement in a Problem Diagram. Interactions in a RAD can also be Requirements in a problem diagram. Our idea is to understand how interactions and actions in RADs can be mapped, projected, decomposed or described as requirements. From the problem diagram we can then hopefully describe problem diagrams, and if possible, Problem Frames, which will allow us to

4.1.1 Roles Customer. The Customer applies for an account. Web Machine. This is the machine to be built. It provides the interface for the Customer to register and to apply for an account.

2.3


Credit Checker. This role represents another system that checks the credit worthiness of the applicant Customer. Print Room Staff. The Print Room Staff directly access the Web Machine to get applications ready for printing. Printed materials are given to the Post Office for postage to the Customer. Word. The Company flagged Microsoft Word as an important role since it was the only means by which Customer information could be translated onto application forms in a reliable way.

Printer. There are 3 different printers. The Print Room Staff prepares the specific Printer for printing. Post Office. The Post Office posts the packs once a day, at 6pm. Bank. The Bank receives details of a new account and runs its own credit check. The Bank informs the Web Machine of the results of the credit check it has run. If the Bank accepts the account then it will send bank details to the Customer direct. Company Admin. The Company Admin receives the signed Customer application form and updates the status of the Customer’s account.

2.4


Web Machine

Customer initial

initial

register initial/ registrant

initial

registrant

initial Credit Checker

apply for account

initial

account received

transient [possible applicant]

check credit received credit check

waiting

check status

status checked send credit status

initial

status received credit status y OK?

n status rejected

status good

alternative procedure acceptance notification ? possible applicant

applicant

Customer notified

Customer notified generate new Account

account generated

dedupe dedupe completed

generate Pack code

Print Room Staff

Pack code generated

initial

access Pack Codes (in CSV file format)

CSV file accessed

Pack Codes accessed

prepare for Word Printer

Word

CSV file ready for Word transfer

Staff ready to transfer CSV file to Word

initial

initial

transfer to Word CSV file transferred

printer material organised

mail merge

organise printer material CSV file received

printer material organised

merge complete

print

print

received print job

sent print job

sent print job

print job printed

collect printed materials materials collected

materials collected

collate materials

materials collated

Post Office

stuff envelopes

initial

envelopes prepared send for posting application papers posted

post received

Fig. 3a. Page 1 of Role Activity Diagram for Envisioned Process

2.5


Post Office

Customer

post received

applicant send Trading forms/Bank forms to Customer

post sent

post received Company Admin

sign application forms forms signed

initial Return forms

Web machine

received forms

initial Update machine

waiting Web machine updated

updated activate account account activated

email / SMS new Trader

Bank email/SMS sent

initial Inform Bank of account details received A/C details

active Bank informed

validate A/C A/C validated n validation failed

y

validation OK? validation successful

reject A/C message message received

? alternative active

message sent accept A/C

Inform Customer of Bank rejection Customer notified

message received

message sent

Inform Customer of Bank acceptance message received

Customer notified send account material to Customer

A/C material received

A/C material sent

Fig. 3b. Page 2 of Role Activity Diagram Note that the context diagram is not a typical structured analysis context diagram, e.g. [20]. It is a Jackson context diagram [7, 11]. This is not solely a description of data flow to and from the machine to external entities, as found in structured analysis context diagrams. It is also a description of the common interfaces that represent shared phenomena between the domains of interest that interact among themselves as well as with the machine. The shared phenomena, events and interfaces that connect the domains of interest are:

5. Context Diagram The context diagram in Fig 4 describes the domains from the RAD and describes how those domains interact. The Web Machine domain is the machine to be built – it is denoted by the double vertical stripe. The domains Address Searcher, Bank Wizard and National Insurance Wizard do not appear in the process model since a RAD typically does not describe in detail the complexity of interactions. The single vertical stripe indicates that these domains are designed domains contained within the Web Machine.

2.6


Credit Checker

Post Of f ice

e

d

c b

Company Admin

Web Machine

Customer

f

Print Room Staf f

consideration of how the requirements affect the domains of interest, we have added requirements sets in Fig. 5. The requirements sets are represented by the ovals. The text in the ovals represents a summary of the requirements and domains those requirements effect. For example, the requirement set Customer ~ Search Findings connects the domain Customer to the domains Address Searcher, Bank Wizard and National Insurance Number with various requirements. The Customer requirement (18) is that they enter a postcode for the Address Searcher – which the Address Searcher must use to locate the streets with this exact postcode and return these to the Customer through the Web Machine (interfaces a, m). The same idea holds for the Customer and the Bank Wizard: the Bank Wizard must locate and return the address of the bank (reqt. 16) as represented by the account details entered by the Customer (18). The Web Machine has to represent this at the interface (a, l). The same goes for the National Insurance Wizard. This domain must return a validation (15) of the number entered by the Customer (18). The Web Machine represents this at the interface visible to the Customer (a, k). Please note that though we denote the lines and arrows from ovals to domains with numbers that refer to requirements, we do not claim that these are the requirements themselves. The annotation provides us with a means of identifying which domain is constrained or referenced explicitly. After all, requirements effects are in a sense intangible until implemented – we would like to know where those effects should occur.

Printer

g

h

i

Word

j

a

Bank

m Address Searcher

l Bank Wizard

k National Insurance Wizard

Fig. 4. Context Diagram a. b. c. d. e. f. g. h. i. j. k. l.

Online Application Notify of completed application Customer Bank Details Print Directory to Customer Application Packs Application forms to mail Printing materials (paper, documents, forms) Pack Type to print; Printer information Print job CSV file for merging New bank account details National Insurance number Bank account details (address, A/C number, sort code) m. Postcode, address

PRStaf f~ Post

5

6 Credit Checker

4

e

Post Of f ice

Credit ~ Customer

The domains of interest not described as roles in Section 4.1.1 are,

Company Admin

3 Customer~ 2 Complete 1 Form

Address Searcher. This is a database housed within Web Machine. Its sole role is to identify and present addresses to the Customer from the postcode they enter in the application procedure. Bank Wizard. This domain has a similar role to that of Address Searcher. Bank Wizard is housed within the Web Machine and determines the location of the Customer’s bank based upon bank details entered. National Insurance Wizard. This domain is similar to Address Searcher and Bank Wizard. It determines the validity of the Customer’s national insurance number, which is a legal requirement in the U.K. for purchasing/transferring a government bond.

Customer

Web Machine

a

18

17 Customer~ Search Findings

Print Room Staf f

Bank Wizard

l

f

PRStaf f ~ Word Mail Merge

9

8

7

d

c b

m Address Searcher

PRStaf f ~ Printer Materials

Printer

g

h

i

Word

10 11 Printer ~ Word Doc

12

j k

National Insurance Wizard

n

Bank

Customer Account

13

A/C checking rules

14

16 15

Fig. 5. Extended Problem Diagram A new domain is introduced in Fig 5: Customer Account. This is a lexical representation of the account created by the Web Machine on completion of the application. Its interface to the Web Machine is n: new bank account details. It is considered a design domain (denoted by the single stripe), as it is created entirely in the machine. Table 2 in the Appendix shows the

6. Extended Problem Diagram It is necessary to understand where requirements fit into the problem context. Without this understanding, the problem will never be fully understood [7, 11]. In order to go beyond the context diagram in Fig. 4 and to enable

2.7


The requirement constraint 13 is on the Bank (BK). The Bank is obliged to house the Customer Account dependent upon its own credit check. The Customer Account is only a reference requirement, 14, since the Bank is only interested in some phenomena of this domain, namely the information provided about the Customer.

repeating and new domains from process models to problem diagrams/frames for the complete case. We label fig. 5 an ‘extended’ problem diagram because it is an atypical problem diagram, if one observes those presented by Jackson [7]. The difference between extended and non-extended is the placement of a number of requirement ovals including annotations on the requirement references and constraints. Jackson has commented upon the possibility of multiple ovals but noted that there is a risk of missing a projection of a particular subproblem [7]. We found this not be a major problem at this phase, nor on this project, though section 7 notes that different views or projections of a problem can be taken and some are more accurate than others.

Web Machine interfaces: j. WM ! { CU A/C details } BK ! { Validation notification } n. WM ! { CU A/C details; set status } The interfaces describe which domain is responsible or interested in the shared phenomena. Interface ‘j’ shows that the Web Machine (WM) is responsible for providing the Customer account details (CU A/C details) to the Bank. The Bank is responsible for notification of their own credit check to the Web Machine. The Web Machine also has responsibility for populating the Customer account with the correct information and for activating or otherwise, the Customer’s account, interface ‘n’.

6.1 Domain Characteristics Biddable Domains [B]. Biddable domains [7] are those that cannot entirely control or guarantee behaviours and are usually humans. The biddable domains in this diagram are: Customer, Company Admin, Print Room Staff and Post Office. Causal Domains [C]. Causal domains [7] are those have a control or behaviour on the machine domain that can be exactly described and constrained. The causal domains in this diagram are: Credit Checker, Printer, National Insurance Wizard, Bank Wizard, Address Searcher, Word and Bank. Lexical Domains [X]. Lexical domains [7] are those that represent data or information about the Real World and do not affect behaviours but are representations of what is being controlled. The lexical domain in this diagram is: Customer Account.

6.2.2 Customer ~ Search Findings This requirement set connects a biddable domain and three causal domains contained within the Web Machine domain: Customer [B], Address Searcher [C], Bank Wizard [C] and National Insurance Wizard [C]. It might be argued that the Address Searcher, Bank Wizard and National Insurance Wizard domains are really lexical. We are, after all, only interested in the data found in these domains. However, we are really interested in more than this, as the requirement set indicates. We are concerned with the interaction between the Web Machine and these design domains in terms of the retrieval of the correct data, not just how that data is represented. As such, the domains are described here as causal. The requirement states:

6.2 The Requirements Sets The requirements describe the desired effects and behaviours that the machine is to achieve in the environment. There are eight requirement sets in the diagram, represented by the ovals with dotted lines. Each requirement set connects a number of domains in two ways. An arrowhead indicates that the domain is constrained by the requirement. That is, the machine must guarantee that the state or behaviour of that domain satisfies the requirement. A requirement reference, with no arrowhead from requirement to domain, indicates that the requirement refers to some phenomena in that domain [7]. Due to space restrictions only two examples are shown here.

15. 16. 17. 18.

NI ! { Validate } BW ! { Return bank } AS ! { Return streets } CU ! { National Insurance number; bank details; post code }

In requirement 15, the National Insurance Wizard validates the National Insurance number entered by the Customer (reqt 18). This is for government bond accounts only. In requirement 16 the Bank Wizard must return the exact address of the bank from the bank details (account holder, account number, branch sort code, date account opened) entered by the Customer (reqt 18). Requirement 17 states that the Address Searcher must return a list of street addresses that correspond to the postcode entered by the Customer (reqt 18).

6.2.1 Bank ~ Customer A/C This requirement set connects a causal domain and a lexical domain: Bank [C] and Customer Account [X]. The requirement states that the Bank must either accept or reject the new account for the Customer created by the Web Machine.

Web Machine interfaces:

13. BK ! { A/C validation; notification } 14. CA ! { Account }

2.8


something that is very relevant to the e-business domain where this particular problem lies. Does this then fit an Information Display frame? This too is unlikely since the concern is about notification, a transference of information, not how the Bank displays it, which is not our problem to solve. Perhaps we need to turn this problem diagram on its head. The machine domain needs redefining. We are feeding the requirements of the Bank. As such, the Bank now becomes the machine domain. The Bank demands that it validates Customer Accounts so the Web Machine is obliged to forward account details to the Bank. The Web Machine is represented as a domain of interest, not a machine. The Customer Account is contained within the Web Machine (single vertical stripe). The problem diagram now might look like Fig. 7. The Customer Account domain has no direct connection to the Bank machine domain. The interface ‘j’ is probably an API that sends packets of data. One type of packet would be a Customer Account. The requirements and interfaces are redefined as:

a. WM ! { Entry Cmnds; selection options } CU ! { Post code; bank details; NINO – National Insurance number } m. WM ! { Post code } AS ! { Street(s) & Houses } l. WM ! { bank details } BW ! { bank address } k. WM ! { NINO } NI ! { Validation } Table 3, in the appendix, shows the interactions and interfaces from the process models to the Problem Frames for the complete case.

7. The Problem Frames The Problem Frames depicted below are derived from the problem diagram (Fig. 5).

7.1 Account Affirmation with the Bank If we examine the relevant problem diagram from the problem diagram, corresponding to Section 6.2.1 above, we have Figure 6. The first thing to note is that the mechanism by which the Bank checks the credit status of the new active Customer is out of problem scope; it is the Bank’s task to do this, not ours. This is why there is no connection to a Credit Checking domain. The second point to make is that the requirement 13 appears to be constraining the Bank. This is because the Company requires that the Bank return specific information that will have an impact upon the status of the Customer Account. Although the Bank might be a biddable domain, we consider it causal in the context of its having an impact of the future of the Customer’s trading Account.

14. CA ! { Account details } 19. WM ! { Account details; account status } j. WM ! { Customer Account } BK ! { Credit status } n. WM ! { Account status }

j

Web Machine

19 Account Checking Rules

Bank

n Customer Account

14

Fig. 7. Alternative Problem Diagram

j

Bank

There could be serious doubt whether this is the correct frame diagram or not. Let’s rethink this again and say that the Web Machine should remain the machine domain. There is nothing wrong with this and it helps us recognise that we are not building the Bank machine. The Bank is just another domain in the problem. Let’s return to the original problem diagram in Fig. 6 since it is clear we cannot easily determine the frame type.

13 Account Checking Rules

Web Machine

n

Customer Account

14

Fig 6. Problem Diagram for Bank-Customer Account

7.2 Interrogating the information directories

The Customer Account domain is a design domain in that it is something created by the Web Machine. We might argue the point that in actual fact we do not need to show the Customer Account in the Problem Frame because it is in essence a packet of data. It is uncertain what type of Problem Frame this is. A realised domain would fit a Transformation frame or a Workpiece, but this is not an exact fit. The problem is about information passing,

Figure 8 shows the Problem Frame diagram for the Customer / Machine requirement of interrogating housed directories within the Machine, described in Section 6.2.2 above,

2.9


8. Evaluation Customer

18

a Address Searcher

Customer~ Search Findings

17 16

m Web Machine

l Bank Wizard

k 15

National Insurance Wizard

Fig. 8. Problem Frame for Customer ~ Search Findings This is an Information Display Problem Frame, though we would decompose further to show the Customer’s display as a domain. The Customer knows certain information about their address, bank account and national insurance number. 18. CU ! { post code; bank details; national insurance number } (This is the requirement.) a. CU ! { post code; bank details; national insurance number } (This is also what the Customer has to enter into the machine for it to conduct its searches.) The Web Machine has to pass the postcode to the Address Searcher (AS) (interface ‘m’). The Address Searcher has to locate the street(s) and house numbers that match the post code entered (requirement 17). This information is returned to the Web Machine via the interface ‘m’. The list of street numbers is then returned to the human interface via the connection ‘a’ and the Customer has to select the house number of the street of their abode from the list presented. 17. AS ! { locate street(s) } m. AS ! { return street(s) } a. WM ! { present street options } CU ! { select street } The same principles apply for the Bank Wizard and the National Insurance Wizard. 16. BW ! { locate bank } l. BW ! { bank details } a. WM ! { present bank details } CU ! { select bank } 15. NI ! { validate NINO } k. NI ! { validation } a. WM ! { present NINO } CU ! { enter NINO }

There is an obvious link from the Role Activity Diagram to the Context Diagram and to the problem diagram. This is shown in table 1, section 3, as a simple heuristic set. A RAD contains many of the same characteristics of the problem frames framework. A RAD can be decomposed and recomposed, as can a context diagram and problem diagram, and, indeed a problem frame. A RAD allows for different projections of a problem, dependent upon a particular point of view, as can elements of the problem frames framework. These combined characteristics counter the weakness of a simple decompositional analysis that can occur, and provide a much richer problem description. Though the mapping presented in table 1 may appear naïve, it was useful in helping our understanding of this problem in the context of a live project. The tables in the appendix verify this by presenting the richness of information about our customer’s problem that might not otherwise have been elicited if we had taken a different approach, such as a UML analysis. The next Problem Frames step is less straightforward but it is a necessary step in decomposing the problem into its constituent parts. However, the tables described in the Appendix go some way to clarifying the connections. Table 2 lists the related roles and domains – this corresponds to the first row of table 1. Table 3 describes interactions, interfaces, requirements and Problem Frames, corresponding to the second and third steps in table 3. Tables 2 and 3 provide a document that captures the relevant elements of the problem analysis across diagrams, thus presenting a traceable record from process model to requirement. It can be seen that we are not always entirely sure about the Problem Frame. However, this does not necessarily detract from the overall result of a deep understanding of the problem domain and requirements. It might be argued that we should move directly from the Context Diagram to the Problem Frames. However, identification of the domains of interest in the problem does not necessarily mean identification of all possible domains in Problem Frames since there may be undiscovered design domains, those contained within the machine that are nonetheless part of the problem. Also, adding requirement sets and extra domains where necessary (or even removing domains not relevant) to create the problem diagram and seeing where they fit in the wider problem space, shows that the transition to Problem Frames might be easier with this intermediary step in place. The risk of producing an overcomplicated extended problem diagram (fig. 5) is clear and indeed there is another recognised potential problem, that of not capturing all necessary projections due to the ‘flatness’ of the diagram [7]. However, in our study this initial complexity allowed us to have an easier decomposition of the problem and provided a means of ensuring the requirements are addressing their intended domains.

2.10


We then found that decomposing the Company’s problem into more manageable chunks made it easier for us to understand the problem and provided definite boundaries for scoping the iterative development undertaken by the developers. Whether we should have taken a standard problem frames approach and gone from a context diagram to individual problem diagrams (as opposed to the combined, extended one in fig. 5) is academic. We found it useful to show the requirements in figure 5 and this provided a much better understanding of the problem. It was also a natural step to take to annotate the context diagram with requirements ovals; to move directly to single problem diagrams meant introducing a degree of uncertainty in the progression of problems. The extended problem diagram removed this uncertainty. We were able to communicate in the same domain language with our clients. The system was built and released as a live product – our analysis paid some part in this success. We view this as validation.

9. Conclusions This paper presents a means of tracing from a business process model to a Problem Frame through the intermediary of a context diagram and a problem diagram. This allows us to locate requirements together with the domains they affect. From here we decompose into individual problem diagrams and eventually to Problem Frames, if possible. We found that Problem Frames could not always be identified implying there are more frames to be discovered. The benefit of this approach is in providing deep understanding of the problem domain, of the requirements and of the responsibilities of the machine to be built to ensure those domains behave according to the specified requirements. We intend to apply the approach to other cases in the same kind of domain and also to develop related Problem Frames approaches further, such as those described in [16-19] through industrial application.

References [1] K.T. Phalp, “The CAP Framework for Business Process Modelling”, Information and Software Technology, 40 (13) 1998, pp. 731-744. [2] P. Henderson, “Software Processes are Business Processes Too”, Third Int. Conf. on the Software Process, Reston, Virginia, October 1994, pp.181-182.

[3] Warboys, B, Kawalek, P, Robertson, I. and M Greenwood, Business Information Systems, McGraw Hill, 1999. [4] G. Abeysinghe and K.T. Phalp, “Combining Process Modelling Methods”, Information and Software Technology, vol. 39, num. 2, 1997, pp. 107-124. [5] K.T. Phalp and K. Cox, “Guiding Use Case Driven Requirements and Analysis”, 7th Int. Conf. on Object-Oriented Information Systems, Springer, LNCS, Calgary, August 27th29th 2001, pp.329-332. [6] Jacobson, I., Booch, G., and J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999. [7] Jackson, M., Problem Frames, Addison-Welsey, 2001. [8] Kovitz, B., Practical Software Requirements, Manning, 1999. [9] K. Phalp, and K. Cox, “Picking the Right Problem Frame An Empirical Study”, Empirical Software Engineering Journal, 2000, 5(3), pp. 215-228. [10] Ould, M., Business Processes, Wiley, Chichester, 1995. [11] Jackson, M., Software Requirements and Specifications, Addison-Wesley, 1995. [12] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns, Addison-Wesley, 1995. [13] Bray, I., An Introduction to Requirements Engineering, Addison-Wesley, 2002. [14] J. G. Hall, M. Jackson, R. Laney, B. Nuseibeh, and L. Rapanotti, “Relating Software Requirements and Architectures using Problem Frames”, 10th Int. Conf. on Requirements Engineering, Essen, Germany, September 2002, pp137-144. [15] L. Rapanotti, J. G. Hall, M. Jackson, and B. Nuseibeh, “Architecture Driven Problem Decomposition”, 12th Int. Conf. on Requirements Engineering, Kyoto, Japan, September 6-10th, 2004. [16] K. Cox and K. Phalp, “From Process Model to Problem Frame – A Position Paper”, 9th Int. Workshop on Requirements Engineering (REFSQ’03), Austria, June 2003, pp.113-6. [17] S. Bleistein, K. Cox and J. Verner, “Problem Frames Approach for e-Business Systems”, Proc. The 1st International Workshop on Advances and Applications of Problem Frames (IWAAPF), Edinburgh, May 24th 2004, pp.7-15 [18] S. Bleistein, K. Cox and J. Verner, “Requirements Engineering Approach for e-Business Advantage,” 10th Int. Workshop on Requirements Engineering (REFSQ’04), Riga, Latvia, June 2004. [19] K. Cox, K. Phalp, S. Bleistein, J. Verner, “Deriving Requirements from Process Models via Problem Frames for an e-Business System”, accepted for Information and Software Technology, 2004. [20] DeMarco, T., Structured Analysis and System Specification, Prentice Hall, 1979.

Copyright © 2004 Karl Cox, Keith Phalp, Aybüke Aurum, Steven J. Bleistein and June Verner The author(s) assign to AWRE and educational non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author(s) also grant a non-exclusive licence to AWRE to publish this document on the AWRE web site (including any mirror or archival sites that may be developed) and in printed form within the AWRE 2004 Proceedings. Any other usage is prohibited without the express permission of the author(s).

2.11


Appendix Table 2. Roles to Domains Connecting RADs to Problem Diagrams Role Activity Diagram Customer (R) Web Machine (R) Credit Checker (R) Print Room Staff (R) Word (R) Printer (R) Post Office (R) Customer Admin (R) Bank (R)

Context Diagram Customer (D) Web Machine (M) Credit Checker (D) Print Room Staff (D) Word (D) Printer (D) Post Office (D) Customer Admin (D) Bank (D) Address Searcher (DD) Bank Wizard (DD) National Insurance Wizard (DD)

Problem Diagram Customer (D) Web Machine (M) Credit Checker (D) Print Room Staff (D) Word (D) Printer (D) Post Office (D) Customer Admin (D) Bank (D) Address Searcher (DD) Bank Wizard (DD) National Insurance Wizard (DD) Customer Account (DD)

Problem Frame Customer (D) Web Machine (M) Credit Checker (D) Print Room Staff (D) Word (D) Printer (D) + (M) None Customer Admin (D) Bank (D) Address Searcher (DD) Bank Wizard (DD) National Insurance Wizard (DD) Customer Account (DD) Customer Record (DD) Word File (D) Application Form (D)

Table 3. Interactions to Interfaces and Requirements Interactions, interfaces, requirements Role Activity Diagram

Context Diagram

CU->register->WM

Interface a

CU->apply for account->WM

interface a

WM->credit check->CC CC->send credit status ->WM WM->alternative procedure->CU WM->acceptance->CU

Interface c Interface a

PRS->access Packs -> WM

Interface d

PRS->prepare for Word->WM

Interface g

WM->transfer to Word-> WD

Interface I

PRS->organise printer material>Printer PRS->print->WD WD->print->Printer PRS->collect printed materials>PR PRS->Send for posting ->Post Office PO->Send forms to Customer>CU

Interface f Interface g, h Interface f Interface e None

Problem Diagram As Context Diagram (CD) Customer ~ Complete Form Reqt 1, Interface a Credit ~ Customer Reqt 3, 4, interface a, c Credit ~ Customer Reqt 3, 4, Interface a, c PRStaff ~ Word Mail Merge Reqt 9, interface e PRStaff ~ Word Mail Merge Reqt 9, 10, interface g PRStaff ~ Word Mail Merge Reqt 9, 10, interface d, i PRStaff ~ Printer Materials Reqt 7, 8 interface f PRStaff ~ Word Reqt 9, 10 Printer ~ Word Doc Reqt 11, 12 PRStaff ~ Printer Materials PRStaff ~ Post Reqt 5, 6 PRStaff ~ Post Reqt 6

CU->return forms to Company Admin->CA

Domains present but no interface?

Customer ~ Complete Form Reqt 1, 2

CA->update WM->WM

Interface b

Customer ~ Complete Form Reqt 2, interface b

WM->email/SMS account activation->CU

Interface a

Reqt? Interface a

2.12

Software Requirement / Possible Problem Frame Workpiece Problem Frame Workpiece Problem Frame Information Display Frame Information Display Frame As Problem Diagram (PD) As PD As PD As PD Application Printing Rules Transformation Problem Frame None None None Account Activation Rules Reqt 1, interface not documented. Problem Frame? Problem Frame? Account Activation Rules Req 1, interface b Should it be part of Account Activation Rules? Connection Frame? / Information Display Frame?


Interactions, interfaces, requirements Role Activity Diagram

Context Diagram

Problem Diagram

Software Requirement / Possible Problem Frame Connection Frame? / Information Display Frame? / Transformation Frame? Account Checking Rules Reqt 13, 14 interface j Connection Frame? / Information Display Frame? / Transformation Frame? Account Checking Rules Req 15, interface k Account Checking Rules Interface a, n?

WM->inform BK of A/C details>BK

Interface j

BK ~ Customer A/C Reqt 13, 14 interface j

BK->A/C reject message->WM BK->accept A/C->WM

Interface j

BK ~ Customer A/C Req 13, 14, interface j

Interface a

Unknown?

None

None

None

Interfaces k, l, m

Customer ~ FOReturn Search Findings Reqts 15, 16, 17, 18 Interfaces a, k, l, m

Information Display Frame

WM->inform of rejection ->CU WM->inform of accept ->CU BK->send A/C material to Customer ->WM None

2.13