Topic 2 Requirement and Use Cases

8/12/2019 Topic 2 Requirement and Use Cases

http://slidepdf.com/reader/full/topic-2-requirement-and-use-cases 1/27

INTRODUCTION

This topic is all about finding and then recording and analysing the requirementsfor a system. Badly defined requirements are a major cause of system failures.The requirements for a system cover a large spectrum, from business needs, tospecific technologies, as well as what the system Âmust doÊ, such as calculate tax.This topic starts with a discussion of the different levels and types ofrequirements. We then focus on what the system Âmust doÊ, or its functionalrequirements.

By the end of this topic, you should be able to:

1. Differentiate between different types and levels of requirements;

2. List standard non-functional requirements;

3. Recognize that change in requirements is inevitable, and outlinestrategies for dealing with such change;

4. Identify the actors for a system;

5. Define a use case, levels of use cases and describe how use cases fit

with goals;6. Identify the use cases for a system;

7. Draw a UML use case diagram to show the scope of a system; and

8. Draw a correct UML activity diagram for a set of use cases.

TTooppiicc 22 Requirementand Use Cases

LEARNING OUTCOMES



TOPIC 2 REQUIREMENT AND USE CASES 28

Functional requirements are described by use cases. Use cases are the core ofobject-oriented analysis and design. Consequently the bulk of this topic is aboutwriting use cases, which you were briefly introduced in Topic 1. Use cases look

simple · very simple · until you try to write some. The activities for this topicwill help you practise this skill.

In addition to use cases, you will learn about three UML diagrams that are usedin conjunction with use cases. Use case diagrams give a pictorial view of theactors and use cases. Activity diagrams show how some use cases interact toachieve a business task or process. Use case package diagrams logically groupthe use cases to make it easier to understand the big picture.

Throughout the whole system development process we accept that requirements

will change in response to various needs. The Unified Process addresses this byusing an iterative development methodology. This topic concludes by looking atthe Unified Process requirements documents and artifacts.

2.1 REQUIREMENTS ANALYSIS

As you learned in Topic 1 , there are several disciplines (or workflows) withineach of the four phases of the Unified Process (UP). One of the earliest disciplines· and one of the most important · is requirements analysis. Obviously, beforewe do anything at all, we have to ask ourselves what we want the system to do.

To answer this question, it is necessary to consider:

• business needs

• available resources

• possible technologies

• social and legal implications.

The problem to be solved is discussed among team members, customers, and

typically users. Assumptions are expressed but may be verified or rejected usingÂproof of conceptÊ prototyping techniques.

The requirements for the system are the outcome of this process and represent anagreement between the system development team members, customers andusers. Note that the requirements will tell what the system will do, rather thanhow it will do it. Writing the requirements involves:




• Defining the purpose of the system, prioritizing its functionality, andspecifying its context (i.e. who are its users and what systems does it interactwith?).

• Identifying external interfaces, both human and system-to-system. Thetechnology of an existing system with which the system must interface canconstrain the requirements and design.

• Identifying major functionality that must be provided by the system anddescribing it.

• Documenting assumptions upon which the requirements are based. If theassumptions change, then so might the requirements.

• Communicating with users, clients, business analysts and developers so that

the system that is developed meets the clientsÊ expectations.

The requirements may also involve Âproof of conceptÊ prototypes, which early onin the life cycle of the development process confirm or shape the direction of thesolution. The prototypes can be an implemented mockup of some function in thesystem, or could simply be sketches of the GUI through which scenarios can benavigated and confirmed.

2.1.1 Levels and Types of Requirements

An organization might start a new system development project for a number ofreasons: new business requirements, replacing an old system, the merging of twoexisting systems due to acquisition and merger, etc. In most cases, systemsdevelopment activities are driven by business needs. Hence, you need tounderstand the different levels of requirements for the system you are going todevelop. These are:

• Business requirements · these define the high-level processes that occur inan organization. For example, for a Banking system, what is the purpose ofdeveloping the new banking system? Is it going to replace an old system or is

it going to be used in a new line of business, etc.?• System requirements · what the computer system must do for its users.

These are the functional requirements of the system.

• Internal requirements relating to technology, personnel, hardware platformrequirements, etc. These are the non-functional requirements.

To explain the differences between functional and non-functional requirements,consider the example of building a house. Imagine that you have inherited apiece of land and that want to build a house on it. So you contact an architect and




sit down to discuss your requirements. How many rooms do you require? Doyou want the dining room next to the kitchen? How big should the garden be?We can consider these as the functional requirements of the house. And there are

other requirements too · such as the quality of the bathroom taps, amount ofnatural light, and the total budget for the project. These are non-functional requirements. From the system development perspective, non-functionalrequirements can be further divided into different categories. In the UP context,requirements are categorized according to the FURPS+ model which refers to:f unctional, u sability, r eliability, p erformance, supportability and Â+Ê foreverything else (such as implementation, operations, packages, legal...), asdepicted in Figure 2.1.

Figure 2.1: FURPS+ requirements model

Alistair Cockburn, in Writing Effective Use Cases , suggests that only a third ofrequirements are functional. Some requirements can be regarded as both functionaland non-functional.

Characterize the following requirements as functional, non-functional or both.

(a) Customers receive a special discount on their birthdays.

(b) Use the Java J2EE architecture.

(c)

Each POS terminal is able to process 100 sales items per minute.(d) Produce a report on demand of all transactions greater than $100,000.

(e) Each user is able to see personalised menu options.

EXERCISE 2.1




2.1.2 Challenges of Writing RequirementsExperienced systems developers will tell you that one of the main causes ofproject failure is poorly conducted requirements analysis. Writers ofrequirements face a number of challenges, not all of them technical.Communication, human and business issues also have to be taken into account.The following are possible challenges.

Problem Domain Complexity

The biggest challenge is finding out about the problem domain (the environment

in which the system will operate, e.g. our video shop). This is especially true ifthe domain is a new one. Other domain related challenges include: ascertainingthe systemÊs role within the domain; achieving immersion in the problemdomain; translating what you learn about the domain requirements specificationsand system responsibilities. Obviously, the bigger and more complex the systemrequired, the more challenging your task.

Person-to-person Communication

You need effective communication in order to extract information from clients

and users about the problem domain; to obtain information from clients andusers about the system requirements; to convey your understanding of thesystem back to clients and users for their affirmation; to convey requirementsinformation to developers, managers and testers; and finally to convey the needfor changes to the requirements which may have been established. For successfulrequirements analysis, groups involved need to convey information to oneanother effectively.

VictoriaÊs Videos System

In this topic, we will use VictoriaÊs Videos system, which you wereintroduced to in Topic 1 as the basis for some activities.

Have another look at the case study, which was included in Topic 1 , andlist two functional requirements and two non-functional requirements forthe system.

EXERCISE 2.2




Constant Change

As weÊve said already, changing requirements are an inevitable aspect of thesoftware development life cycle. Even though requirements may be frozen at aparticular point, a system and peopleÊs understanding of it will continue toevolve. This evolution may be due to improved understanding of the problemdomain by analysts and developers; improved understanding of the systemsolution on the part of users, or simply competition, regulators, approvers,technologies or politics. Recognizing that requirements will always change is acore concept of iterative development.

Writing Requirements in UP

As you know, the goal of requirements analysis is to describe what the system

should do (the requirements) and get developers and the customer to agree onthat description. To achieve this, we define the system and its surroundings andthe behaviour it is supposed to perform. Customers and potential users areimportant sources of information.

In the UP development framework, the requirements analysis is progressivelypresented in two key artifacts, the Use Case Model for the functionalrequirements and the supplementary specification for the non-functionalrequirements (refer to Figure 2.2).

Figure 2.2: The key requirements artifacts

As been said in Topic 1 , the Use Case Model is important for both the customer,who needs the model to validate that the system will become what is expected, andfor the developers, who need the model to get a better understanding of therequirements for the system. A Use Case Model is written so that both the

customer and the developers understand it.

The Use Case Model consists of actors and use cases. Actors represent the entitiesexternal to the system, either users or other systems. Use cases represent thefunctional behaviour of the system. Actors help define the system and give you aclearer picture of what it is supposed to do. WeÊll look at actors further in thenext section.




As you know from Topic 1 , a use case represents events triggered by actors anddescribes how the system must respond. Because use cases are developedaccording to the actorsÊ needs, the system is more likely to be relevant to the

users.

Figure 2.3 shows the main steps of the iterative process of building and deliveringsome functionality. Use cases live through the entire system life cycle and act as aunifying thread. The same Use Case Model is used during all subsequentworkflows. This topic covers the first three steps in more detail. Step 4 is coveredin later topics.

Figure 2.3: The main steps

2.2 STAKEHOLDERS, ACTORS AND ROLES

In Topic 1 we noted that stakeholders are all the people or groups, both internaland external to your organization who will affect or be affected by your proposal.Obviously this includes the people who will use the system. In UML the term forusers is actors but this word can lead to confusion. We donÊt say a person is theactor Hamlet; we say that an actor plays the role of Hamlet.

Another way of thinking about roles is wearing different hats. One person canwear different hats, or play many different roles, as they go through a day or a




process. One example is creating a big document or report. Initially a person,letÊs call her Alice, brain dumps ideas onto the page as quickly as possible. Shewants to create a rough structure. She is not interested in spelling, grammar or

fonts. After a few hours of this she moves to another role · a writing role. Hereshe types whole sentences. She includes graphics and headings. She is concernedabout correct spelling, grammar, and fonts. To complete the document, she asksher colleagues Xiaofang and Junying for review. They need to add comments to adocument without affecting the original text. On paper this is scribbling in themargins of a printed copy. Lastly, Alice takes comments from all different peopleto produce one final document (refer to Figure 2.4).

Figure 2.4: People and roles · Âwearing hatsÊ

2.2.1 Types of Roles

There are three kinds of roles or actors:

1. Primary · A person in this role directly uses the system to enter, viewprocess or extract information. Depending on the user interface, thesepeople will use a keyboard, a mouse, buttons on a machine, or talk to a

voice activated system. Examples in the case study are the checkout clerkand backroom stock handler.

2. Secondary · A person in this role does not directly use the system, but usesor generates data for the system. A classic example is a person who receivesreports from a system, particularly in another department in theorganization. This person may or may not access the system to get thereport, but is a user of the information. (Typically, these roles areoverlooked in the requirements analysis.) An example in the case study isthe managers.




3. External · Any system that receives or generates data for the system ·these are external systems, e.g. tax office system, bank, accounts system,etc.

Note that this taxonomy differs slightly from UML and in Larman (2002). Inparticular, in UML users and external systems are treated the same. It is true thatthey are both external to the system, but treating people and computers in the sameway is not conducive to building usable systems. Further, our experience showsthat frequently the needs of the secondary actors are often omitted. Often the needfor reporting is known, but instead of the needs being closely examined, thestandard response is to simply add an end-user reporting tool. Very rarely doesthis simplistic approach satisfy. If senior management does not receive any benefitsfrom a system then the project may be terminated.

2.2.2 Differences in Roles

Questions you need to ask of a person in a role are:

• Do they know how to use a computer? Are they comfortable with a graphicaluser interface?

• Do they understand the domain? (For the video shop domain, does theperson know how videos are borrowed, do they know how the credit cardcharging system works, or are they a member of the public?)

• Will they receive any training in using the new system?• What is their work environment? Is there noise or sufficient light? Are there

many interruptions from other people? Do they need to be able to switch between many applications? How reliable is the network?

• Frequency of use. Will they use the application once a year, once a month orseventy times per day?

• In the course of their work do they refer to paper forms or other data sources?

• Ask them to rank one or more of the following: reliability, correctness,satisfaction, ease of use.




2.2.3 Discovering the Roles

There are two simple ways to start discovering the roles for a system. These are brainstorming an initial list, and looking at existing job titles.

Here are two very different roles for two very different systems.

(a) Clerk for a small investment company. This company has only 30clients and there are only a few transactions per day, but theamount of money in each transaction can be large.

(b) Teenager at a Kylie Minogue fan club website. This website hasphotos, lyrics and samples of KylieÊs songs. There are facilities foronline discussion and chat.

For each, consider what would be important to a person in that role andassign a priority (1, 2, 3 or 4) to each. And you cannot make them all

priority 1!

Objective Clerk for Investment

Company

Teenager at KylieMinogue Fan Club

Website

Reliability of thesystem, e.g. the resultsof searches orcalculations are correct

Efficiency, e.g. that a

minimum number ofsteps is required, thusreducing human error

Satisfaction, e.g. theexperience of using thesystem is enjoyable

Speed, e.g. the rate atwhich information isdisplayed

EXERCISE 2.3




Brainstorm an Initial List

Either by yourself or with other team members, simply write down the namesyou can think of. (When brainstorming do not be concerned with getting the bestnames for the roles · that comes later.)

Look at Existing Job Titles

This is a good place to start, but the role names may end up being quite differentto the existing job titles because:

• A job description normally requires several roles. For example, the job titletechnical writer can be split into the roles:

- document searcher

- document reader- document writer

- document reviewer.

Each of these roles would have a number of use cases.

• Existing job titles are not usually good role names because they already havea lot of meaning to the users · either there is a history as to what that the jobentails, or the job has other components which are unrelated to the newsystem.

• There is a many-to-many relationship between job titles and use cases ortasks. Thus a job title can be misleading.

Warning : If you take the role analysis too far, then you will end up with adifferent role for every use case. This is the opposite of having one role, calledÂuserÊ who does everything. Somewhere between these two extremes is a usefuland workable set of roles. It sometimes takes a little while for this to cometogether. So start with an initial list of roles, and work on identifying their usecases. Then come back and review the role model.




The following table may be useful for collating the actors.

Table 2.1: Sample Table for Collating Actors

Actor NameActor

TypeDescription Current Job Title s)

Importance of

the Actor

This name

needs to be

as

meaningful

as possible.

Primary,

secondary

or external

A sentence or two

to describe the

actor in some

detail

This is helpful in

communicating to

staff. There could be

multiple job titles

per actor, or one job

title can have many

actors.

Low, medium

or high

Lastly assign an importance (high, medium, low) to each actor. This willdetermine the order in which you start looking for use cases. (Of course, as witheverything, once you look more closely at it, the importance may change).

For the NextGen POS case study introduced in Topic 1 an initial list of actorscould be as in Table 2.2.

Table 2.2: NextGen POS Initial List of Actors

Actor NameActorType

DescriptionCurrent job

Title s)Importanceof the Actor

Cashier Primary Sells the goods to thecustomer and collectspayment

Shop assistant

Duty supervisor

High

Barcodescanner

External ** Not sure if this is partof the system, or anexternal actor

Not applicable Medium

Administrator Primary Not much information yet ? Medium

Inventorycontrol

External Not applicable, buttalk to warehouse

manager

Medium

Analyst Secondary ** Further investigationrequired

Store manager Medium

Accountant Primary ** Further investigationrequired

Accountant Medium

Tax calculator External Calculate the tax owing Not applicable Low

⁄




You will notice that this list has questions and indicates where more work isrequired. This is normal.

Subsequent work on the analysis is certain to change some of this information, but itÊs a good starting point. Notice that the barcode scanner has been included, but the description is a question to be resolved. This is fine. Remember thatiterative development is all about starting and continually refining and buildingon previous work.

2.3 WRITING USE CASES

We already have a good understanding of actors (as well as the roles actors willplay) in the Use Case Model. Actors are entities outside of the system that willinteract with the system. What is inside the system is represented by use cases inthe Use Case Model. Use cases are a way to discover and document functional

requirements. They describe system behaviour from the userÊs perspective. Usecases are written in plain language so both the users and the IT staff canunderstand them. Each use case must achieve something useful for the user. Thenext reading gives an example of a brief use case.

Now download Reading 2.1 from myLMS to learn about a brief use case.

Use cases define a promise or contract of how a system will behave (Larman,2002).

Identify possible actors for VictoriaÊs Videos system and categorize them as

primary, secondary or external.

EXERCISE 2.4

1. Write the use case Âborrow videosÊ.

2. Why do you think this is a good use case to begin with?

EXERCISE 2.5




In Exercise 2.5 we gave you the name of a use case, but of course, normally youhave to work out the use cases yourself. Deciding where one use case ends andanother use case begins takes a bit of practice. When you first start writing down

possible use cases do not be too concerned about getting this right. Once you getfurther into writing the use cases you will be able to work out the boundaries.

If all system development activities are business-driven, those writing therequirements must aim for goals that will bring value to the organization. Thismeans that a use case:

• must deliver something of value to an actor

• typically represents a major piece of functionality that is complete from beginning to end

• represents the goal of an interaction between an actor and the system; the goalrepresents a meaningful and measurable objective for the actor

• records a set of paths (scenarios) that take an actor from a trigger event (startof the use case) to the goal (success scenarios)

• records a set of scenarios that traverse an actor from a trigger event toward agoal but fall short of the goal (alternate scenarios).

In Exercise 2.4, you listed the actors for VictoriaÊs Videos. Now you need towork through the list of actors, from most important to least important, andlist their use cases. Do not be too concerned about getting the names of theuse cases perfect. Just write them down. Later you can change the names,

delete use cases or add use cases.

EXERCISE 2.6

Using your list from Exercise 2.6, select the next most important use case ofthe most important actor and write a brief format of the use case.

Now select another use case and also write it in a brief format.

EXERCISE 2.7




Now download Reading 2.2 from myLMS to learn about success scenarios andalternate scenarios for NextGen POS example.

After going through Reading 2.2, you will see that each use case has a mainsuccess and some alternate scenarios. A use case may has a main success scenarioand some alternate scenarios. Sometimes, when we have a large and complicatedsystem to develop, there will be lots of different scenarios. It would be impossibleto discover all the possible scenarios at the very beginning. Remember, in the UP,everything is done in an iterative fashion. Hence, when you first start writing usecases for a system, itÊs best to ignore all the alternate scenarios and only thinkabout everything going well · the Âsunny day scenarioÊ. Alternative scenarioscan be added in future iterations. Of course, successful scenarios can also berevised and changed in later stages.

The main purpose of the UP is to help system developers to build their systems ina systematic manner. Poor system development tends to be done by developerswho cannot judge what they should be doing at each stage of the wholedevelopment cycle. A common mistake is to jump into the system design before agood requirements analysis is available. Hence, in the UP framework, a black-boxuse cases approach is usually adopted to help system developers avoid makingthe same mistake twice. Let us know discuss the term. Something is a black boxif we cannot see the inner workings of it. For example, from a car driverÊsperspective, a car is a black box. The car either moves properly or it does not. Ifthere is a problem, then the car mechanic comes and, with a white-box view, liftsthe car bonnet and looks at the engine and internals. Hence, in the black-box

approach of use cases writing, we donÊt care about how the system will performthe tasks but just focus on what we should expect from the system. In otherwords, we are only focusing on the responsibilities of the system. Example of

black box use case shown below:

The main purpose of the UP is to help system developers to build their systems in asystematic manner. Poor system development tends to be done by developers whocannot judge what they should be doing at each stage of the whole developmentcycle. A common mistake is to jump into the system design before a good

We have written up a main success scenario for the borrow videos use casein Exercise 2.5. Try to think up a few alternate scenarios and present themin a brief format similar to the main success scenario. Compare your answerwith your course mates in myLMS.

EXERCISE 2.8




requirements analysis is available. Hence, in the UP framework, a black-box usecases approach is usually adopted to help system developers avoid making thesame mistake twice. Let us know discuss the term. Something is a black box if we

cannot see the inner workings of it. For example, from a car driverÊs perspective, acar is a black box. The car either moves properly or it does not. If there is aproblem, then the car mechanic comes and, with a white-box view, lifts the car

bonnet and looks at the engine and internals. Hence, in the black-box approach ofuse cases writing, we donÊt care about how the system will perform the tasks but

just focus on what we should expect from the system. In other words, we are onlyfocusing on the responsibilities of the system. Example of black box use case shown

below:

Black Box Style Not Black Box Style

The system updates the studentmarks

The system writes the new marks to a database

The system generates a SQL UPDATE statementfor the task

Sometimes confusion will still arise even if we adopt the black-box approach, because different people have a different understanding of Âwhat the systemdoesÊ. For example, a cashier might think of her goal as Âlogging inÊ, but in factthis is just the mechanism that achieves the higher-level goal of identifying andauthenticating herself.

Now download Reading 2.3 from myLMS to learn of how to write use cases in anessential UI-free style.

Essential style writing (as highlighted in Reading 2.3) is therefore used to furtherclarify the focus of use cases writing: Âkeep the user interface out and focus onactor intentÊ.

Now take the three use cases from Exercises 2.5 and 2.7, and rewrite them inthe essential two-column format. (Yes, writing use cases is hard work, butthe more you write the easier it gets. It is not good enough to just look at theanswers. You must practise). Anyway, the answer could be obtained at theend of the module.

EXERCISE 2.9




2.3.1 Goals and Levels of Use Cases

Now you have an idea of what a use case is and, in general terms, know how it

should be written. Now, letÊs stand back a bit and ask a fundamental question:What should the goal of the use case be? As we noted earlier, different users havedifferent goals. For example, the general manager of the retail store is expectingthe retail system in his company to streamline the whole retailing process. Thecashier, on the other hand, may expect the same system to read the barcodes ofitems correctly and efficiently. Well, which one of these two requirements should

be turned into a use case? In fact, neither of them would make a good use case.The general managerÊs goal is at too high a level while the cashierÊs goal is toolow. So what level of user goals can be transformed into use cases? The generalguideline is to look at elementary business processes EBPs). The following

Reading 2.4 will explain to you the concept of EBP. It also gives a very livelyexample of how a system analyst investigates the user goal of the cashier througha series of questions and identifies the appropriate goal level for writing a usecase.

Now download Reading 2.4 from myLMS to learn about goals and scopes of usecase.

Information systems are rather abstract entities that consist of software, hardwareand applications. However, even though we cannot visualize the whole

information system, for the purpose of use cases we need to define a boundaryfor it. ItÊs similar to building a house, when we need to perform a land survey tofix the boundary of the site on which the house is going to be built. A clearlydefined system boundary helps in the correct identification of the right actors touse cases, which in turn helps the system analyst to obtain the goals. The four-step procedure proposed to define use cases is listed below:

(i) define the right system boundary

(ii) identify the primary actors

(iii) identify the actorsÊ goals

(iv) define and name the use cases.

Now download Reading 2.5 from myLMS to learn about four-step procedure todefine use cases as listed above.




ItÊs important that you understand the Use Case Model as itÊs a crucial element inObject Oriented System Analysis & Design (OOSAD) and it is one of the earliesttasks in the whole system development project. The future success of the projectdepends on getting the use case right. As itÊs sometimes helpful to approach atopic from a different angle, weÊd like you to reinforce your understanding of theUse Case Model by working through the next reading by Cockburn.

http://alistair.cockburn.us/structuring+use+cases+with+goals

2.3.2 Format for Writing Use Cases

There are three types of format for writing use cases. The format to be considered isdepends on the need. The explanation for these three types of use cases format aregiven below:

• brief use case - it has one-paragraph summary and normally used for mainsuccess scenario such as Process Sale example shown in Reading 2.1

For VictoriaÊs Videos, up to now we have tried to identify the actors andsome brief use cases. However, all these were produced by ourimagination. In a real system, the proper way to do requirementsanalysis is to carry out a combination of many activities such as:

• Read any documentation that has been collected.

• Look at any systems that currently exist. Look at screens andreports. See if you can track some real examples all the waythrough. For example, for an insurance system, you could see howa policy is created, and then later how a claim might be processed.

• Talk to the parties concerned. Commonly you begin by conductingsome user requirements workshops. Use the initial actor analysiswork as a guide to who should attend the workshop. For the firstworkshops it is best to have more people rather than less as youneed the broadest possible range of views. Later, you can havemuch smaller workshops to concentrate on particular areas.

Prepare a list of questions that you would like to ask various people fromVictoriaÊs Videos.

EXERCISE 2.10




• casual use case it is an informal paragraph which has multiple paragraphsthat cover various scenarios. The Handle Returns shown in Reading 2.2 wasthe example

• fully dressed

the most comprehensive that shows all the steps andvariations. It has supporting sections, such as preconditions and successguarantees.

Writing a use case is, to a certain extent, is like writing a report, and as you willknow if youÊve ever written a report, itÊs much easier if you can follow some kindof format. Most companies and organizations have report templates for people torefer to. Similarly, for use cases there are templates that system analysts can referto. One of the most popular use case templates was developed by AlistairCockburn. The full version and a detailed description of the template are

available at http://alistair.cockburn.us/Basic+use+case+template. Use casetemplates are not covered in this course.

2.3.3 Use Case Diagrams

ÂA picture paints a thousand wordsÊ: sometimes a visual illustration can representcomplicated ideas in a simple and easy way. A use case diagram can provide astatic view of a system to allow us to have an overview of the system and therelationship between the use cases as well as the actors of the system.

The following Figure 2.5 is the simple UML notation to depict a use case.

Figure 2.5: Use case diagram notation

A collection of use case diagrams will form a context for use case diagrams thatshows the scope of the system, and the relationship between the actors and usecases. It serves as a diagrammatic summary of the behaviour of the system.According to Larman (2002), use case diagrams are only secondary in use casewriting. System developers should not spend too much time drawing use casediagrams. Writing use case text should be the primary focus.




Now download Reading 2.6 from myLMS to learn about use case diagram indetail.

2.3.4 Activity Diagrams

For many applications it is extremely important to see how all the use cases fit

together to achieve something overall. This is particularly true when there aremany different people involved in an overall activity. For example, one of themain challenges to businesses that sell products via the Internet is to work out thewhole fulfilment side. Taking the order and the money is the easy bit! UML has anotation called activity diagrams. These diagrams, in many aspects are quitesimilar to flow diagrams. They can be used at different stages in thedevelopment, from requirements through to detailed programming.

The following diagram shows how the different actors invoke their own use casesto achieve the overall task. The diagram has ÂswimlanesÊ for each of the different

actors.

Each system is different so you have to decide whether or not any activitydiagrams are useful or not.

By using the example of use case diagram shown in Figure 6.2 of Reading 2.6as a guide, draw a use case diagram for VictoriaÊs Videos.

EXERCISE 2.11




Figure 2.6: An example of an activity diagram

Do you think an activity diagram would help explain how a subset of theuse cases for VictoriaÊs Videos system fit together to form a whole? If so,then draw it. Note: We are not trying to draw all the use cases of the wholesystem, but only some of them that make up a process that makes sense tothe users as a whole.

EXERCISE 2.12




2.3.5 Potential Problems with Use Cases

Writing effective use cases is not a simple matter and there are a number of

pitfalls to be avoided. Here are ten, identified by Susan Lilly (1999):(http://www.api.adm.br/GRS/referencias/HowToAvoidUseCasePitfalls.pdf)

1. The system boundary is undefined or inconstant.

2. The use cases are written from the systemÊs point of view.

3. The actor names are inconsistent.

4. There are too many use cases.

5. The actor-to-use case relationships resemble a spiderÊs web.

6.

The use-case specifications are too long.7. The use-case specifications are confusing.

8. The use case doesnÊt correctly describe functional entitlement.

9. The customer doesnÊt understand the use cases.

10. The use cases are never finished.

In writing this list, Susan Lilly (1999) is not arguing against use cases, but tryingto alert newcomers to the potential problems, and suggest ways to avoid them.She advises:

• Explicitly define the systemÊs boundary. This makes clear what is inside thesystem and what is outside the system.

• Make use of a standardized template for documenting your use-casespecifications. If the team uses a template, it will help communications

between team members as well as help newcomers get started.

• When writing use cases, focus on the goals of the actors. This will help youfind use cases from the usersÊ perspective and keep a focus on the primaryfunction of the system.

• DonÊt make use-case specification synonymous with user-interface design.You can use low-fidelity representation of user interfaces, but since userinterface design is particularly subject to design-specific change, it is best notto include it as part of the requirements if you want to get them signed offearlier rather than later.

To help catch potential problems, Lilly suggests that you review your Use CaseModel, the diagrams and specifications, in incremental steps with thedevelopment team, clients, and users. Start by reviewing your use-case diagram




before youÊve defined use case details; check that the system boundary has beenclearly defined, that obvious actors have not been missed and that the use casesfocus on the usersÊ goals.

2.3.6 How to Deal with Hundreds of Use Cases

The case study that you are working on is purposely chosen to be a smallapplication. So you may wondering how this process Âscales upÊ to cater for largersystems which may have 200+ use cases. The key is to organize the use cases sothe team can understand them. One specific technique is to organize the usecases into groups or packages.

A UML package is a mechanism to group anything together. So a use casepackage is a collection of use cases, actors, and even other use case packages, tostructure the use case model by dividing it into smaller parts. Thus instead oftrying to understand 200+ use cases, the team needs to understand perhaps only

20 use case packages. Individual team members then need to understand thedetails of a few use case packages.

Deciding on the packages for a system requires a little experience, and there aregenerally several valid approaches for one system. Some possibilities forpackaging the use case are listed below.

• By functional areas. For example, put everything to do with money in onepackage, and inventory in another.

• By actor. For example, put all the cashierÊs use cases in one package.

• By ÂstyleÊ of use case. For example, put all the simple setup/maintenancestyle use cases in one package.

• By importance or iteration. For example, all the use cases that are going to be built first could be in one package.

Differentiate between use cases and requirement statements. Check youranswer at <http://ootips.org/use-cases-vs-requirements.html>

EXERCISE 2.15




• By physical implementation. For example, all the use cases that are deliveredvia the Web are in one package, and use cases accessed via the head officecomputer are in another package.

Generally a combination of multiple approaches is best. Deciding on the use casepackages is usually a collaborative effort between the users, the requirementsanalysts, the technical architect, perhaps the database designer, and the projectmanager.

The UML notation for a package is a folder. But, as emphasized earlier, the text ofthe use case is more important than the diagrams. So often a use case package issimply a short description of the use case, followed by a list of the use cases thatcomprise the package. Optionally, include a use case diagram of the use cases

(refer to Figure 2.7).

Figure 2.7: Use case package

2.4 CAPTURING REQUIREMENTS ITERATIVELY

As you learned in Topic 1 , all the activities in the unified process, includingrequirements analysis, will be done iteratively. The whole process of preparing

and writing this use case may take several iterations. The working of this use casehas spanned both the inception and elaboration phases of the UP. It will probablynot be completed until we reach the construction phase. The distribution of workfor requirements analysis and use cases writing throughout these iterations andphases in the UP very much depends on the conditions and needs of the systemdevelopment itself as well as the working style of the system development team.However, as a general guideline, most of the requirements analysis work will bedone during the iterations in the elaboration phase.




Particularly with large systems, the key point is to identify all the architecturallysignificant use cases as early as possible, and leave less important use cases forlater. Architecturally significant here means all the essential functionality of the

system. Use cases are vital and central to the Unified Process (Larman, C 2002).

During the requirements analysis, use cases are the main product. However, aswe noted earlier, use cases cater for the functional requirements of the system.As you can recall, there are also non-functional requirements that also need to beidentified. Alongside the use case, there are three more artifacts in therequirements workflow · vision, supplementary specification and glossary.These three artifacts capture other system requirements that cannot be capturedin the use cases. The supplementary specification captures other non-functionalrequirements in the URPS+ category such as documentation, packaging,

supportability, licensing requirements, etc. The vision is probably the highest-level document of the project, providing a broad picture of the purpose and business needs of the project and how the proposed system should look. It setsforth the ultimate goals of the project from the organizationÊs businessperspective. The glossary mainly serves as a data dictionary for the whole systemdevelopment project. It clearly defines all the technical terms in the context of thesystem development in order to avoid problems in communication andambiguity that can possibly arise during the whole development process.

The detail discussion about vision, supplementary specification and glossary arenot in the scope of this course.

• Every system development project starts with requirements analysis. Gettingthe right requirements is critical to the success of system developmentespecially for large and complex systems and in a rapidly changing businessenvironment.

• Unlike the traditional waterfall system development life cycle (in whichrequirements analysis is done and completed before the design andimplementation phases) the unified process model has the requirementsworkflow (discipline) extended throughout the whole system developmentprocess: in other words, the requirements analysis is done iteratively.

• Different types of requirements are categorized as functional or non-functional according to the FURPS+ model. In the UP context, requirementswriting is based on the use case model.




• The use case model includes the identification of actors, their goals and thewriting of use cases. The functional requirements are captured in the usecases. Sometimes, use case diagrams can be used to help to understand the

overall picture of the system, the flow of events and the relationship betweenactors and use cases.

• Other non-functional requirements are presented in other artifacts such as thevision, supplementary specification and glossary. These artifacts togetherwith the use cases form the artifacts in the requirements workflow.

ActorFunctional requirement

Non-functional requirements

Role

Use caseUse case activity diagram

Use case diagram

Use case package

Constantine, L. L. and Lockwood, L. A. D. (1999). Software for Use, Addison-Wesley. (Gives a detailed treatment of using use cases to design the userinterface. See also their website <www.foruse.com>

Cockburn, A. (2002). Writing Effective Use Cases, Addison Wesley.

Eriksson, H. E. and Penkus, M. (2000). Business Modelling with UML · BusinessPatterns at Work, Wiley. (This covers some extensions to use case modelingas presented in this topic.)

Larman, C. (2002). Applying UML and Patterns, Prentice Hall

Robertson, S. and Robertson, J. (1999). Managing Requirements. Mastering theRequirements Process, Addison-Wesley. (See also their website for arequirements template, <http://www.atlsysguild.com/GuildSite/Robs/Template.html>

Zachman, J., The Zachman Framework at <http:// http://www.zachmaninternational.com > (Select ÂFrameworkÊ from the left




menu. The Zachman Framework provides a complete view of requirementsfrom an enterprise perspective.)

Documents

Topic 2 Requirement and Use Cases