Requirements Engineering & OOA Tutorial
John Grundy Feb/Mar 2000
This document provides a brief overview of Requirements Engineering using UML. It focuses on: Codifying requirements for systems using UML Use Case diagrams & use case descriptions Codifying conceptual static structure of systems using UML class diagrams Codifying conceptual dynamic system behaviour using UML collaboration and sequence diagrams Codifying non-functional constraints on system operation using Structured English This is not meant, in any way, to be a definitive introduction to what is a complex and ever-important area of systems development. However, it should serve as a basis for understanding basic concepts of Requirements Engineering, and as an aid to beginning to learn about using UML for this purpose. I recommend looking at: UML Distilled, Martin Fowler, Addison-Wesley, 1998. Software Engineering, 5th Edition, Ian Sommerville, Addison-Wesley, 1996. for further information on UML and Requirements Engineering topics.
User Requirements and Use Cases
The basic process we go through to determine the requirements of a system i.e. what it should do are summarised below: Identify & describe stake-holders in system. These are the people that need to use the system, but also may include other systems our system needs to interact with. The Unified Modelling Language represents these as “Actors”. Elicit stake-holder requirements of system. For each stakeholder, what should our system do? We need to consider both functional characteristics i.e. data/functions the stakeholder needs the system to store/do for them, and constraints on these functions e.g. kind of user interface, processing speed needed, security needed etc. Analyse & document these stake-holder “perspectives” on the system. We usually start with a English description of the system, then try and organise this in a more structured way. UML Use Case diagrams and use case descriptions are one of the more common ways. Resolve any conflicts between stake-holders’ perspectives on the system. This is important, as we can’t build a single system to satisfy the requirements of multiple stakeholders if the stakeholders requirements conflict e.g. customers want security but management doesn’t (because of increased cost of system). We have to trade off/prioritise requirements that conflict to remove all conflicts from our system requirements. Video stores typically have an Information System which has two main functions: to support recording information about videos the store owns, which is usually searchable by staff and sometimes customers, and information about which customer is renting which videos. This forms a basic “library” system for supporting finding videos and recording video rentals/returns. We’ll assume customers have on-line access to the video library via the WWW (so they can see what videos are available from home, before turning up at the store), and staff are able to record video rentals and returns by customers. Normally this second function would use bar code scanners. In addition, staff need to maintain customer, video and staff information. Managers of the store need to generate various reports, and some data from the system needs to be exchanged with accounts (e.g. fines revenue) and inventory (video stock held) systems that might already exist. In order to document the requirements of this system, we typically use a variety of notations. These range from a high -level, user perspective of interacting with a system (use cases), to a codification of the functional aspects of the system (objectoriented analysis diagrams), to a description of the non-functional constraints on the system’s operation. These are summarised below: Use case diagrams – high level description of actors and the main ways each actor interacts with the system Use case descriptions – description of each use case in the system Non-functional specification - description of various constraints on system operation. Typically we use categories of nonfunctional constraints and in each category we summarise the important constraints on system operation. Categories typically include user interface, documentation, performance, quality of service, integrity, hardware and networking issues, and so on.
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 1
Functional specification of system structure and behaviour. This typically includes OOA static and dynamic diagrams, such as class diagrams, collaboration and sequence diagrams, state charts and so on.
Use cases describe the main interactions of actors (users and other systems) with a system. The Unified Modelling Language (UML), which has become the de-facto standard modelling language for system development in recent years, uses use cases to capture user requirements. The main components of use case modelling are actors and use cases. Actors are typically people who use a system, or other software and/or hardware systems. For example, typical actors for a video library system would be customers and staff, with some staff characterised as “managers” (as they can do some things other kinds of staff can’t). The system might need to work with other systems e.g. accounts and inventory systems, so we’d characterise these as actors too. Use cases are intended to capture the main interactions with the system of each actor. This includes data input and output the actors ask a system to perform. We also try and identify constraints on the performance of these operations and document them with the use case. Typical use cases for a video library system would include customers searching the video database, and maybe reserving videos and adding on-line reviews (like at Amazon.com for books). Staff would maintain customer, staff and video records, rent videos to customers, and process returned videos. Managers would generate reports. There might be export/import functions to exchange data with external systems. Use case requirements modelling uses a use case diagram (or multiple use case diagrams) to graphically depict actors, use cases and interactions between actors and use cases. Actors are represented as labelled stick figures, and use cases as ovals. We typically draw a line from an actor to a use case (or the other way around!) to indicate interaction of the system and actor via the use case. Its sometimes useful to indicate one use case “uses” another, or must come before/after another. We can do this with arrowed lines with appropriate annotations. The main use case for the video library system are illustrated in the UML Use Case diagram below:
Maintain Customers Search for Videos <> Rent/Return Video Staff Members Login Write on-line Review Inventory System Maintain Videos <>
Customers
Acconts System Reports & Fines
Management
For each use case, we develop a specification of the flow of events that characterises the actors interaction with the system via this use case. Use case descriptions should be detailed enough that system analysts can work out the key data and functions the system should embody, and the key non-functional constraints on how the system works. A brief description of the event flows for the Search for Video, Maintain Customers and Rent/Return video use cases are given below:
Use Case “Search for Video” 1. Used by customers via WWW browser to query for videos by video title, category and/or actor 2. Event flows 2.1. Customer types in their ID and password, then clicks the Login button. If customer ID found & password correct, display custo mer name. If no customer with the ID found, goto 2.5. If password incorrect, goto 2.6. If server error, goto 2.4. 2.2. Repeat until customer leaves Web page: 2.2.1. Customer types in part of title in title text field, category name in category text field (or selects category from combo box). Categories might include “Action”, “Drama”, “Childrens” etc. The system records the following information about each video: a unique ID, name, price to rent, number of days can rent, rating (G, PG, R16 etc.), category and number of copies currently available for rent. 2.2.2. Customer clicks “Find” button and a list of matching videos are returned showing video ID and title. If no videos found, goto step 2.5. If error from server, goto 2.6. 2.2.3. Customer clicks on a video ID/title then on “Details” button. More information is displayed about the video e.g. rating, pric e to rent, days can hire for, and category. 2.3. No videos found – error message displayed. Goto 2.2.1. 2.4. Server error – error message displayed. Goto 2.2.1. 2.5. No customer found – error message displayed. Goto 2.1. 2.6. Incorrect password – error message displayed. Goto 2.1. 3. Related Actors/Use cases: Used by Customer actor 4. Special conditions: Uses WWW applet interface Use Case “Maintain Customers” 1. Used by staff to add, update, delete customer records
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 2
2.
3. 4.
Event flows 2.1. Repeat until Exit Program: 2.1.1. Find Customer – staff member first enters customer ID, then clicks on “Find” button. Customer data includes ID, name, age, password, address and phone number. If a customer with the ID entered is found, all customer data is displayed in text fields . If no customer is found, goto 2.2. If server error, goto 2.3. 2.1.2. New Customer – after “New” button clicked – all fields are blanked. 2.1.3. Add Customer – staff member types in values in ID, name, address and phone number fields. The staff member then clicks on the “Add” button. A new customer record is added. If the customer ID has already been used for another customer, goto 2.4. If server error, goto 2.3. 2.1.4. Update Customer - staff member changes name, address and phone text field values. Staff member then presses “Update” button. Customer record then updated in database. Must have done a Find Customer first. If no customer ID, goto 2.5. If server error, goto 2.3. 2.1.5. Delete Customer – staff member clicks on “Delete” button. Customer record deleted from database. Must have done Find Customer first. If no customer ID, goto 2.5. If server error, goto 2.3. 2.1.6. Exit Program – staff member clicks on “Exit” button and program terminates. Use case ends. 2.2. Couldn’t find customer – error message that couldn’t find customer with this ID. Goto 2.1. 2.3. Server error – error message indicating server error occurred. Goto 2.1. 2.4. ID not unique – error message that this customer ID is already in use. Goto 2.1. 2.5. No Customer ID – error message that no customer ID has been entered – need to do a Find Customer first. Goto 2.1. Related Actors/Use cases: Used by Staff actor Special Conditions: Uses Java Application interface
Use Case “Rent/Return Video”: 1. Used by staff to rent videos and return videos 2. Event flows 2.1. Staff member enters their ID & password. Staff member name & position looked up & displayed. Information abo ut staff includes their ID, name, age, password, position in company and salary. If no staff member found, goto 2.3. If wrong password, goto 2.7. If database server error, goto 2.5. 2.2. Repeat until Exit Program: 2.2.1. Enter customer ID – staff member enters customer ID & customer name looked up & displayed. Running total cost of rentals for this customer set to zero. If no customer found, goto 2.4. If database server error, goto 2.5. 2.2.2. Enter video ID – staff member enters video ID & video title looked up and displayed. If no video found, goto 2.6. 2.2.3. Rent – staff member clicks on “Rent” button and rental record added to database. Rental record indicates staff who rented video, customer who rented video, video rented, current Date/Time, and returned flag, with initial value of “false”. Video record updated to indicate one less video available for rent. Running total of cost of rented videos increased by video rental cost and value redisplayed. If server error, goto 2.5. Goto 2.2.1. or 2.2.2. 2.2.4. Return – staff member clicks on “Return” and rental record returned flag updated to indicate video has been returned by customer. Video record updated to indicate one more video is available for rent. If database error, goto 2.4. Goto 2.2.1. or 2.2.2. 2.2.5. Exit Program – staff member clicks on “Exit” button and program terminates. Use case ends. 2.3. Couldn’t find staff – error message that no staff member with this ID. Goto 2.1. 2.4. Couldn’t find customer – error message that couldn’t find customer with this ID. Goto 2.2.1. 2.5. Server error – error message indicating server error occurred. 2.6. Couldn’t find video – error message that couldn’t find video with this ID. Goto 2.2.2. 2.7. Wrong password – error message that password is incorrect. Goto 2.1. 3. Related Actors/Use cases: Used by Staff actor 4. Special Conditions: Uses Java Application interface
Non-functional Specifications
All software systems have constraints on the way the system behaves. Its often reasonably straightforward to develop a functional specification of the system i.e. OOA diagrams etc., but harder to codify the non-functional constraints. Typically we ground non-functional constraints into various categories, and describe (usually in English, though sometimes diagrams help) various non-functional constraints the system needs to meet. We then need to design our system architecture and programs to meet these specifications. We often focus a lot on checking these constraints are met when testing and evaluating distributed systems. Checking for functional specification conformance is usually much easier. Some example non-functional constraints we might like to specify for a system include: User Interface and Human Factors What type of user will be actually using the system? Will more than one type of user be using the system? What sort of training is required for each type of user? What sort of input/output devices are to be used? Documentation What sort of documentation is required? Who is the documentation designed for? Hardware Considerations Requirements Engineering and OOA Tutorial John Grundy, 2000 Page 3
What hardware is your proposed system to be used on? What are the characteristics of this hardware including memory, hard disk space, network, etc? Performance Characteristics Are there any speed, throughput or time constraints on the system? Are their size or capacity constraints on the data to be processed by the system? Error Handling and Extreme Conditions How should the system report input errors? How should the system respond to extreme conditions? System Interfacing Is input coming from systems outside the proposed system? Is output to go to systems outside the proposed system? Is there any format or medium required for these transfer processes? Quality Issues What are the requirements for reliability (i.e. is this a critical system)? Is there a maximum acceptable time for restarting the system after failure? What is the acceptable system downtime per 24-hour period? Physical Environment Where is the target equipment to be used? Will it be in one or several locations? Will the environmental conditions be out of the ordinary? Security and Integrity Issues Must access to any data or the system itself be controlled? How often will the system be backed up and who will perform the back ups? Resources and Management Issues What materials, personnel, computer time etc. will be required to build, install and maintain the system? What are the proposed and immediate deadlines for system production? What is the budget for hardware, software, personnel etc.? Who is responsible for system installation and maintenance? For our video library system, here are some example constraints we might need to specify in each category: User Interface and Human Factors Type of users: staff are moderately experienced computer users; customers may be novices Types of users: managers (high privileged level; experienced); staff (can change most data); customers (can only read data) Training: staff, managers: training course; customers : on-line tutorial I/O devices: all use PCs in this system; customers have WWW-based interface Documentation Staff: training manual, on-line help Customers: on-line tutorial, email to staff for help Hardware Considerations Company already has bunch of Pentium-II PCs which we want to run system on vs. buy new one. WWW interface should run in any browser IE4 and above; Netscape 4 and above Staff PCs: 64 MB RAM, Pentium-II 266/366, 2GB HDD, central database server machine with 12GB HDD, simple LAN
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 4
Performance Characteristics Customer searches should take < 3 seconds to complete under heavy loading (up to 20 simultaneous customer connections allowed) Up to 2MB video; 4 MB rental data to be kept at any one time Error Handling and Extreme Conditions Error log should be generated by all programs Power failure needs to be handled by UPS for main server machine System Interfacing Accounts system (in MS Access) and inventory system (in Paradox) need to export data to Access format: comma-delimetered text file (could give example of this…) Quality Issues Reporting not critical and can be off line for up to 24 hours Rent/return critical – downtime must be less than 30 minutes On-line access not critical, but should limit down time to 2 hours Physical Environment All PCs in office/home Normal office conditions, but mouse area limited in video shop Security and Integrity Issues Only managers can access and change staff salary details Password needed to access all staff functions Should encrypt customer requests Backups done every night Resources and Management Issues We’ll ignore these for this course . In real life they’re rather important…
Locating Objects
If we are building distributed object-based systems, we need to find some objects/classes with which to build the system with. The key with object-oriented analysis is to determine the BASIC set of objects a system needs i.e. the main data and functions the system should support at a conceptual level. By this I mean we ignore details to do with user interfaces, middleware/comms, data management, algorithms, etc. We want to develop a SMALL number of objects which encapsulate the key data and functions of the system. This is so we don’t get totally overwelmed with detail at this stage that we miss/forget important things, which is easy to do if we try and go straight to identifying design-level objects right away. Your OOA diagrams should thus NOT concern themselves with database/comms/user interface APIs, detailed processing functions and data structures and so on, but focus on conceptual-level problem domain data and function encapsulation and interrelationships. There are various ways to find objects that describe the conceptual level of a system. I find it easiest to work from data and functions that I can identify in use case definitions, then group these into candidate objects. I write out the data/functions, then group them into objects. This often takes several goes!!! You can change the objects, and data and functions within them, if you need to in order to better conceptual the functional aspects of a system. Personally, I find focusing on data aspects of objects (i.e. “entities”), then adding functions, works best for me. But this is probably partly because of my data modelling background… Those of you who have done 636.222 might find this too, as UML class diagrams are a lot like ER diagrams, except with richer inter-class relationships and functions as well as attributes in classes. Another common approach to determine objects from use cases is to identify data based on nouns, i.e. the attributes and perhaps objects that make up a system. Verbs typically indicate possible functions for the objects. I’ve never, myself, found this all that useful an approach, but try it if you like.
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 5
For example, in the video library system, some of the data (attributes) we can decern from looking at the use case event flows above include: Staff ids, names and passwords Customer ids, names, passwords, age, address and phone # Video id, title, category, number of copies, number of nights can rent, rating and cost to hire Rental date and whether returned or not Some operations (functions) we can determine include: Add, update, delete and find customer records Find staff records Find videos by id or title and category, update video number of copies held Add, update and locate rental records We then need to group these attributes and operations into objects i.e. the Idea of “encapsulation” of data & functions. I again find it easiest to work from the data and aggregate attributes into sensible “entities” (222 people will find this straightforward too). I have found these groupings of data almost always form the bulk of the conceptual objects in a system, if not all of them. We end up with a lot more objects at design time, including APIs, data structures, etc., but for now we focus on conceptual data and functions only. Functions (usually) go with object whose attributes they access and/or modify. This includes functions that access and modify the relationships between classes (but more on that in a minute…). Some functions use other object functions/data, in which case its best to put them in an object related to the other objects whose data and functions they use. It can be difficult to decide exactly where some functions go, if they access data and functions from a range of objects. Put them in the object that best makes sense for you. After all, this is a conceptual (analysis) model of the system, and we can move functions during system design to best take account of efficiency and other issues. Some video library conceptual objects are shown in the diagram below. This is how we represent classes and objects using UML: a name, list of typed attributes and list of functions. You can add function arguments if you wish. Note that we can change these objects later if we need to/want to – they are not set in concrete. To get these objects I identified the key attributes/functions from use cases, grouped closely-related attributes to form the basic classes and then grouped functions by the data they act on. I introduced a Person class to hold common information shared by Customer and Staff objects. I put the rentVideo() and returnVideo() functions in the Staff class, but these could also go in the Customer, Video or Rental class! It doesn’t matter WHO uses the functions, but what data they act on as to which object is best to put them in. In this case, these functions access all four objects…
Customer Address : string phone : string findcustomer() addCustomer() updatecustomer() deletecustomer() findVideo() Video ID : int Name : String Category : String Cost : real NumNights : int Rating : String numCopies : integer findVideo() findByName() setNumCopies()
Person ID : int Name : String age : int password : String
Staff Position : String salary : real findStaff() addStaff() updateStaff()
Rental Date : String Returned : boolean addRental() findRental() rentVideo() returnVideo()
Some notes on OO analysis: DON’T get carried away with objects for user/device interfaces, databases, data structures, etc. etc. Remember we’re trying to build a high-level, conceptual model of a system. Ideally your OOA diagrams should be able to be shown to noncomputer experts to help check requirements are met etc. We want to capture the “essence” of the system i.e. important data/functions. Try and not break up functions (and some data) into too many small parts at this stage. Use “address” instead of street number, street name, suburb, city, zip etc. Use “calculateTotals()” instead of beginCalc(), calcAverage(), calcEachItem(), endCalc() etc. We will refine OOA objects/diagrams to more detailed OOD objects/diagrams shortly. This is when all the nitty gritty detail to do with interfaces, data management, data structures, APIs etc etc comes in. Remember that a single OOA specification can be implemented by lots of different OODs! Thus your OOA should not commit itself to one implementation strategy – it’s a specification, not a design.
Class Diagrams (Static System Functional Specification)
Class diagrams represent the static structure of systems. They are made up of classes (or objects) which are inter-related. The main relationships between classes are generalisation and association. For example, Staff and Customer generalise to Person; Staff, Customer and Video are associated with Rental. Similarly, Staff::rentVideo() calls Video::findVideo(), which is a
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 6
different kind of association. Sometimes you’ll see “association” described by aggregation and method calling (or “operation invocation”). I’ll try all relationships between classes that are not generalisation as association for simplicity. UML Class Diagrams represent generalisation by an open arrowed line, and association by a straight line. Generalisation indicates a sub-typing relationship between a child (subclass), which is a specialised form of a parent (superclass). The child typically inherits all the data and behaviour of the parent. Association is where one class (client) uses data/functions belonging to another class (supplier), or has some sort of data relationship with it. For example, a Customer has a set of Rental objects associated with it, and a Staff object’s rentVideo() function needs to call a Video object’s findVideo() function. Often we name associations to make their purpose clearer. We also often give an “arity” to the relationship. For example 0..1 means optional 0 or 1 association; 1..* = at least one, maybe many associations and so on.
Parent Child Client 1..* <> 0..1 Supplier
The diagram below shows the class diagram I have developed for the video library system. The customer and staff classes generalise to the person class, meaning customer and staff are people, and all customer and staff objects inherit all the data and behaviour of a person object. We could have other generalisations in a more complex system e.g. Manager class generalising to Staff and so on. Use generalisation when there is a lot of commonality between two or more classes you want to abstract out into another, common parent class. There are two kinds of association used in the example below. The first is “data” association, where the Customer, Staff and Video objects are associated with a set of Rental objects. Basically the “rents” associations indicate that a customer object has bunch of rentals, a video object has a bunch of rentals and a staff object has a bunch of rentals. Each of these associations has arity annotations indicating that a customer has multiple rental objects, but a rental object is related to only one customer object and so on. The second kind of association is operation invocation i.e. an operation (function) from one object using a function of another. For example the staff object uses a video object e.g. staff::rentVideo() calls video::findVideo(), video::setNumCopies() etc. We usually don’t show an extra association between staff and rental if one already exists (so the rents association also indicates usage e.g. staff::rentVideo() calls rental::findRental() and setReturned().
Person ID : int Name : String age : int password : String Video ID : int Name : String Category : String Cost : real NumNights : int Rating : String numCopies : integer findVideo() findByName() setNumCopies() Staff Position : String salary : real addStaff() 1..1 updateStaff() findStaff(int id) 1..1 uses rents
Rental Date : String
0..* Returned : boolean Customer Address : string phone : string findcustomer() addCustomer() updatecustomer() deletecustomer() findVideo() rents 0..*
1..1
addRental() findRental() rentVideo() returnVideo()
Dynamic System Functional Specifications
Class diagrams capture the static structure of a system. Sometimes we also want to document how things work in terms of dynamic behaviour i.e. calling of object methods state transitions objects go through Requirements Engineering and OOA Tutorial John Grundy, 2000 Page 7
event propagation between objects exception throwing/handling by objects
We’ll look at just the first with UML collaboration and sequence diagrams. UML state transition diagrams are used to represent the second. The third and fourth are rather hard to represent with UML, although annotations of class and collaboration diagrams can be used to some degree. The idea of an object calling a method of another object, or one object’s operation invoking an operation belonging to another object, is a fundamental concept in object-based systems:
Call func XYZ, args A, B, C...
Client
Supplier
Return value D
While object-oriented analysis deals with conceptual-level objects and their data and operations, we still often want to reason about the way these operations interact, without worrying about communication, data management and interface issues (we deal with these at design time). Usually we want to show sequence of operation (function) calls, as well as sometimes the arguments to calls, return values etc. To do this with the UML, we use collaboration & sequence diagrams. The collaboration diagram is a graph that shows representations of objects as nodes, with edges being operation (function calls) between objects. We annotate links between objects with these function call details e.g. name, sequence, arguments and return values:
Self-call
Object1 : Class1 4: func4() 3: func3() Object3 : Class3
Calling sequence #
1: func1(string) Object2 : Class2 2: func2(int,Class2) : boolean
Called function name Arguments
Return value
As an example, the collaboration diagram for the staff::rentVideo() function is given below. This is the most complex interobject collaboration in the video library system. The Staff object first locates the staff member whose ID has been entered, then locates the customer and video specified by calling appropriate functions of the customer and video objects. A new rental record is then created and the number of copies of the selected video updated (decremented by one). I find the use case event flows are very useful when drawing such diagrams, as they (should!) describe the appropriate sequence and flow of events from an interaction point of view.
4. addRental(…) rentVideo()
2: findcustomer(int id)
Rental Object : Rental
1. findStaff(int id)
Customer Object : Customer 3: findVideo(int id)
Staff Object : Staff
5: setNumCopies(int)
Video Object : Video
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 8
Sequence diagrams convey the same sort of information as collaboration diagrams, but in a different form. The objects are arranged in a line at the top of the diagram, with function calls shown in sequence on vertical lines below. This layout better conveys the sequencing of calls between object functions, but can get pretty messy for large collaborations.
Rental Object : Rental Customer Object : Video Object : Video Staff Object : Staff
findStaff(ind id) findcustomer(int id) findVideo(int id) addRental(…) setNumCopies(int)
Other dynamic behaviour diagrams from the UML include state diagrams and activity diagrams. Have a look at Fowler’s UML Distilled book for examples.
Requirements Engineering and OOA Tutorial
John Grundy, 2000
Page 9