Université du Québec
ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
Software Functional Size with
ISO 19761: 2003
COSMIC-FFP Measurement Method
Proposed Measurement Etalon:
*********
C-Registration System
*********
January 4, 2007
Updated: February 23, 2008
Source of Requirements:
Rational Unified Process 2003 – with permission
 All rights reserved 2006, Software Engineering Research Laboratory, École de Technologie Supérieure (Canada)
Document Control
Date
2004-08-26
2004-09-07
2004-09-16
2005-02-09
2005-05-19
2005-05-22
2006-11-04
2006-12-23
2008-02-23
Reviewers (s)
Adel Khelifi
Alain Abran
Adel Khelifi
Charles Symons
Jean-Marc Desharnais
Adel Khelifi
Alain
Abran,
Charles
Symons,
Adel
Khelifi,
Fernando
Machado,
J.
Jayakumar
Alan Leterthuis, Alain Abran,
Charles Symons
Carole Dekkers, A. Abran
Modifications / Additions
First Draft
Revision
Second Draft
Revision
Revision
Update measurement result
Update to the measurement procedure + measurement
results
Updates based on comments from Metricsgroep from
Netherlands
Negative number in functional process no. 11 corrected.
Small additional corrections to the totals in Tables 4 to
7. New total size = 107 Cfsu instead of 106 Cfsu.
Copyright 2006. All Rights Reserved. Software Engineering Research Laboratory of École de
technologie supérieure - Université du Québec (Canada).
 All rights reserved 2006, Software Engineering Research Laboratory, École de Technologie Supérieure (Canada)
2
Table of Content
1. CONTEXT OF MEASUREMENT OF THIS CASE STUDY............................................................. 4
1.1 INTRODUCTION .............................................................................................................................. 4
1.2 MEASUREMENT PURPOSE, SCOPE AND MEASUREMENT VIEWPOINT .............................. 4
1.3 ASSUMPTIONS MADE ON THE RUP REQUIREMENTS, AND MEASUREMENT STEPS ....... 5
2. C-REGISTRATION SYSTEM REQUIREMENTS............................................................................. 6
2.1 CONTEXT ......................................................................................................................................... 6
2.2 SYSTEM REQUIREMENTS............................................................................................................. 6
2.3 USE CASE DIAGRAM.................................................................................................................... 16
3. COSMIC-FFP MEASUREMENT PROCEDURE - STEP 1............................................................. 17
3.1 IDENTIFICATION OF LAYERS .................................................................................................... 17
3.2 IDENTIFICATION OF USERS ....................................................................................................... 17
3.3 BOUNDARY.................................................................................................................................... 17
3.4 IDENTIFICATION OF TRIGGERING EVENTS – STEP 1 ............................................................. 18
3.5 IDENTIFICATION OF DATA GROUPS – STEP 1 .......................................................................... 18
3.6 IDENTIFICATION OF FUNCTIONAL PROCESSES – STEP 1 ..................................................... 21
3.7 OBSERVATIONS ON THE CLARITY OF THE DOCUMENTED REQUIREMENTS ................ 23
3.8. IDENTIFY DATA MOVEMENTS – CANDIDATE FUNCTIONAL PROCESSES – STEP 1..................... 23
3.9. ANALYSIS OF MEASUREMENT RESULTS............................................................................... 35
3.10. QUESTIONS AND ANSWERS.................................................................................................... 37
4. COSMIC-FFP MEASUREMENT PROCEDURE – STEP 2 ............................................................ 42
4.1 JUSTIFICATION FOR STEP 2........................................................................................................ 42
4.2 CONSEQUENCES OF STEP 2 FOR THE FUNCTIONAL SIZE MEASUREMENT..................... 43
 All rights reserved 2006, Software Engineering Research Laboratory, École de Technologie Supérieure (Canada)
3
1. CONTEXT OF MEASUREMENT OF THIS CASE STUDY
1.1 INTRODUCTION
This Case Study presents the result of applying the COSMIC-FFP Functional Size Measurement
method (eg. ISO 19761: 2003) to the RUP ‘C-Registration’ software system.
The C-Registration System is documented in the Rational Unified Process (RUP Version
2003.06.00.65) document as an example of a Web site project.
The C-Registration System will enable students to register for courses on-line. The CRegistration System also allows professors to select their teaching courses and to maintain
student grades.
General information about the software application to be measured:
Application domain: Business Application
Application type: PC client interacts with server over the www.
Available information about the software system
Document: Requirements in a HTML format, as presented in the Release Notes Version 1.0
and Use-Cases Specification Version 2.0. Together, we refer to these as the ‘C-Registration
System requirements’.
Permission was received from IBM in 2005 to use the C-Registration System requirements’ as
input to this case study..
1.2 MEASUREMENT PURPOSE, SCOPE AND MEASUREMENT VIEWPOINT
Measurement Purpose:
The measurement purpose is to measure all of the software functional user requirements (FUR)
as documented in sections 2.2 ‘Requirements’ and 2.3 ‘Use Case Diagram’ of this case study.
Measurement Scope:
The measurement scope is all of the software functional processes of this C-Registration system,
including the log-in functions which we assume to be added specifically for this on-line system.
The measurement scope is therefore a subset of the system requirements documented in section
2 of this Case Study, that is, only those related to software, and not those related to the hardware.
Measurement Viewpoint:
The measurement viewpoint in this Proposed Measurement Etalon is that of the End User of a
PC.
Given the selected End User Measurement Viewpoint and that the Scope is ‘the whole CRegistration system’, all exchanges between the PC client and the main-frame server are
invisible to the End Users.
4
1.3 ASSUMPTIONS MADE ON THE RUP REQUIREMENTS, AND
MEASUREMENT STEPS
In spite of the simple Purpose as stated in 1.2, it has been necessary to make some assumptions
about the supplied RUP requirements when preparing this Case Study and to adopt a two-step
approach to the measurement.
The initial analysis and measurement of the requirements using COSMIC-FFP to prepare this
Case Study uncovered certain anomalies, such as some inconsistencies in the terminology and
some uncertainties leading to a lack of clarity in a few areas. If these points had not been
addressed, it would have been very challenging to obtain one consistent size measure for the
functional user requirements.
The authors of this Case Study have therefore modified the requirements as given later in
Section 2 in a few places as follows:
•
When something is missing from the requirements in the opinion of the authors of
this Case Study, text is added in italics.
•
When a section of the text is not clear, this text is put in braces [ ], followed by
addition of a clarification text in italics.
Then, with an unambiguous statement of requirements as a starting point, the Case Study
presentation of the analysis and measurement is processed in two steps.
Step 1 (Chapter 3 of this Case Study)
The COSMIC-FFP method is applied to the functional user requirements exactly as they are
written in 2.2, subject to the clarifications introduced as described above and assuming that each
event explicitly identified in the use cases triggers one functional process.
Step 2 (Chapter 4 of this Case Study)
The authors of the Case Study observe that the functional user requirements contain no separate
‘enquiry’ functional processes in relation to Professors, Students and Schedules, a situation that
in practice is implausible.
However, the ‘modify’ and ‘delete’ Use Cases for these three ‘objects of interest’ all include
functionality to retrieve the existing data and to display it before modifying or deleting. But this
retrieval functionality is not specified in such a way that it could be separately invoked at any
time (e.g. from the Menus, as an enquiry functional process), which is also extremely unlikely in
practice.
As stated above, in Step 1 the Case Study shows the measurement of the functional user
requirements literally as written in section 2.2. For Step 2, the Case Study authors have assumed
that this enquiry functionality can be invoked at any time and that each type of enquiry
corresponds to a separate functional process (whether invoked ‘stand-alone’ from the Menu, or
invoked prior to an update or delete functional process).
The difference in size between the solutions given for Steps 1 and 2 is only 6 Cfsu (6% of the
total size), which shows how the COSMIC-FFP method is (happily) insensitive to varying
5
assumptions about splitting requirements into different functional processes (of course, as long
as all the functionality is measured under each set of assumptions). In the authors’ opinion, the
size in units of Cfsu given for Step 2 is much more likely to be the ‘correct’ size if these RUP
requirements had been complete in including the enquiry functions, and entirely free of
uncertainties. The size given for Step 1 is correct for the functional user requirements as given
and with the assumptions made.
2. C-REGISTRATION SYSTEM REQUIREMENTS
The information in section 2 of this Case Study is derived from the vision document of the
Course Registration System – version 1.0 (for more details, please check this link :
http://people.cs.uct.ac.za/~jkr/SoftwareEng/vision_v1.htm. It presents the same document used
for these sections.
2.1 CONTEXT
The functional requirements below describe the behaviour of a project that will replace the entire
front-end of the existing course registration system with a state-of-the-art on-line system that
allows students and professors access through PC clients.
The current registration system has been in use since 1985 and lacks the capacity to handle the
student and course load projected for the year 2000. In addition, the current system is outdated
mainframe technology, which only supports access through the clerks in the Registration Office.
The new system will enable all professors and students to access the system through PCs
connected to the Wylie College computer network and through any personal computer connected
through the Internet.
The new system will bring Wylie College to the leading edge in course registration systems thus
improving the image of the College, attracting more students, and streamlining administrative
functions.
2.2 SYSTEM REQUIREMENTS
Note: The requirements as supplied have been reorganized in the following sequence:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Login (by all users)
Maintain professor information (by the registrar)
Select courses to teach (by professors)
Maintain student information (by the registrar)
Register for courses (by students)
Monitor for course full (by the application)
Close registration (by the registrar)
Submit grades (by professors)
View report card (by students)
1. Login
1.1. Brief Description
This use case describes how a user logs into the Course Registration System.
The actors starting this use case are Student, Professor, and Registrar.
6
1.2. Flow of Events
The use case begins when the actor types his/her name and password on the login form.
1.2.1 Basic Flow - Login
The system validates the actor’s password and logs him/her into the system.
The system displays the Main Form and the use case ends.
1.2.2 Alternative Flows
1.2.2.1 Invalid Name / Password
If in the basic flow the system cannot find the name or the password is invalid, an error message
is displayed. The actor can type in a new name or password or choose to cancel the operation, at
which point the use case ends.
2. Maintain Professor Information
2.1. Brief Description
This use case allows the Registrar to maintain professor information in the registration system.
This includes adding, modifying, and deleting professors from the system.
The actor of this use case is the Registrar.
2.2. Flow of Events
The use case begins when the Registrar selects the "maintain professor" activity from the Main
Form. (We assume that the result of selecting ‘maintain professor’ is that the sub-options to
‘add professor, ‘modify a professor’ and ‘delete a professor’ are displayed for selection.
Similarly, we assume that selecting any of the other options on the Main Form, as described
below, results in displaying corresponding sub-options for selection.)
2.2.1 Basic Flow – Add a Professor
The Registrar selects "add a professor."
The system displays a blank professor form.
The Registrar enters the following information for the professor: name, date of birth, social
security number, status, and department.
The system validates the data to insure the proper data format and searches for an existing
professor with the specified name. If the data is valid the system creates a new professor and
assigns a unique system-generated id number. This number is displayed, so it can be used for
subsequent uses of the system.
Steps 2-4 are repeated for each professor added to the system. When the Registrar is finished
adding professors to the system the use case ends.
2.2.2 Alternative Flows
2.2.2.1 Modify a Professor
The Registrar selects "Modify a professor."
The system displays a blank professor form.
The Registrar types in the professor id number he/she wishes to modify
The system retrieves the professor information and displays it on the screen
The Registrar modifies one or more of the professor information fields: name, date of birth,
social security number, status, and department.
When changes are complete, the Registrar selects "save."
(Note that this step of ‘Save’ is mentioned only in this ‘Modify a Professor’ Use Case, except for
the Use Case 5.2.2.3 ‘Save a Schedule’ which has a specific effect)
The system updates the professor information.
7
Steps 2-7 are repeated for each professor the Registrar wants to modify. When edits are
complete, the use case ends.
2.2.2.2 Delete a Professor
The Registrar selects "Delete a Professor."
The system displays a blank professor form.
The Registrar types in the professor id number for the professor that’s being deleted.
The system retrieves the professor and displays the professor information in the form.
The Registrar selects "delete."
The system displays a delete verification dialog confirming the deletion.
The Registrar selects "yes."
The professor is deleted from the system.
Steps 2-8 are repeated for each professor the Registrar wants to modify. When the Registrar has
finished deleting professors from the system, the use case ends.
2.2.2.3 Professor Already Exists
If in the "Add a Professor" sub-flow, a professor already exists with the specified name, an error
message, "Professor Already Exists", is displayed. The Registrar can either change the name,
choose to create another professor with the same name, or cancel the operation at which point
the use case ends.
2.2.2.4 Professor Not Found
If in the "Modify a Professor" sub-flow or "Delete a Professor" sub-flow, a professor with the
specified id number does not exist, the system displays an error message, "Professor Not
Found". Then the Registrar can type in a different id number or cancel the operation at which
point the use case ends.
3. Select/De-select Courses to Teach
3.1. Brief Description
This use case allows a professor to select the course offerings (date- and time- specific courses
will be given) from the course catalog for the courses that he/she is eligible for and wishes to
teach in the upcoming semester.
The actor starting this use case is the Professor. The Course Catalog System is an actor within
the use case.
3.2. Flow of Events
The use case begins when the professor selects the "select courses to teach" activity from the
Main Form.
3.2.1 Basic Flow – Select Courses to Teach
The system retrieves and displays the list of course offerings the professor is eligible to teach for
the current [upcoming] semester. The system also retrieves and displays [the list of courses the
professor has previously selected to teach.] (This sentence could be interpreted as either the
courses selected over all semesters, or courses selected within the current semester, where we
assume ‘current’ = ‘upcoming’. For this case study, the following clarification is made for
measurement purposes: courses selected to teach for the upcoming semester).
The professor selects and/or de-selects the course offerings that he/she wishes to teach for the
upcoming semester.
The system removes the professor from teaching the de-selected course offerings.
8
The system verifies that the selected offerings do not conflict (i.e., have the same dates and
times) with each other or any offerings the professor has previously signed up to teach. If there is
no conflict, the system updates the course offering information for each offering the professor
selects.
(It is not clear from the specification where the updated course offering information with the
assigned professor is saved – on the Course Catalog or on the CRS.
We assume that it is important for the students to know which professor has signed up for each
course and so the updated course information must be sent back to the Course Catalog so that
the information is available for when a student creates or modifies his/her schedule.
Note that in this Use Case, unlike the others, no clear distinction is made between a Create,
Modify or Delete for the link between a course offering and a professor. Paragraph 3.2.2.3
below implies that a Professor may change the initial selection of courses to teach as long as
registration for the current semester has not closed)
3.2.2 Alternative Flows
3.2.2.1 No Courses Available
If in the basic flow the professor is not eligible to teach any courses in the upcoming semester
the system will display an error message. The professor acknowledges the message and the use
case ends.
3.2.2.2 Schedule Conflict
If the system finds a schedule conflict when trying to establish the course offerings the Professor
should take, the system will display an error message indicating that a schedule conflict has
occurred. The system will also indicate which are the conflicting courses. The professor can
either resolve the schedule conflict (i.e., by cancelling his selection to teach one of the course
offerings) or cancel the operation, in which case any selections will be lost and the use case
ends.
3.2.2.3 Course Registration Closed
If, when the Professor selects "select courses to teach", registration for the current semester has
been closed, a message is displayed to the Professor and the use case terminates. Professors
cannot change the course offerings they teach after registration for the current semester has been
closed. If a professor change is needed after registration has been closed, it is handled outside the
scope of this system.
4. Maintain Student Information
4.1. Brief Description
This use case allows the Registrar to maintain student information in the registration system.
This includes adding, modifying, and deleting students from the system.
The actor for this use case is the Registrar.
4.2. Flow of Events
The use case begins when the Registrar selects the "maintain student" activity from the Main
Form.
4.2.1 Basic Flow – Add Student
The Registrar selects "add student."
9
The system displays a blank student form.
The Registrar enters the following information for the student: name, date of birth, social
security number, status, and graduation date.
The system validates the data to insure the proper format and searches for an existing student
with the specified name. If the data is valid the system creates a new student and assigns a
unique system-generated id number.
(Note that the system-generated student id number is apparently not required to be displayed,
unlike that of the Professor in the use case above.)
Steps 2-4 are repeated for each student added to the system. When the Registrar is finished
adding students to the system the use case ends.
4.2.2 Alternative Flows
4.2.2.1 Modify a Student
The Registrar selects "modify student."
The system displays a blank student form.
The Registrar types in the student id number he/she wishes to modify.
The system retrieves the student information and displays it on the screen.
The Registrar modifies one or more of the student information fields: name, date of birth, social
security number, student id number, status, and graduation date. When changes are complete, the
Registrar selects "save."
The system updates the student information.
Steps 2-7 are repeated for each student the Registrar wants to modify. When edits are complete,
the use case ends.
4.2.2.2 Delete a Student
The Registrar selects "delete student."
The system displays a blank student form.
The Registrar types in the student id number for the student that’s being deleted.
The system retrieves the student and displays the student information in the form.
The Registrar selects "delete."
The system displays a delete verification dialog confirming the deletion.
The Registrar selects "yes."
The student is deleted from the system.
Steps 2-8 are repeated for each student deleted from the system. When the Registrar is finished
deleting students to the system the use case ends.
(Apparently a student can be deleted without any checks on whether he/she has a Student/Course
Registration and without deleting any associated Schedule(s) or Report Card(s)
4.2.2.3 Student Already Exists
If in the "Add a Student" sub-flow the system finds an existing student with the same name an
error message is displayed "Student Already Exists". The Registrar can either change the name,
create a new student with the same name, or cancel the operation at which point the use case
ends.
4.2.2.4 Student Not Found
If in the "Modify a Student" or "Delete a Student" sub-flows the student name is not located, the
system displays an error message, "Student Not Found". The Registrar can then type in a
different id number or cancel the operation at which point the use case ends.
10
5. Register for Courses
5.1. Brief Description
This use case allows a Student to register for course offerings in the current semester. The
Student can also modify or delete course selections if changes are made within the add/drop
period at the beginning of the semester. The Course Catalog System provides a list of all the
course offerings for the current semester.
The main actor of this use case is the Student. The Course Catalog System is an actor within the
use case.
5.2. Flow of Events
The use case begins when the Student selects the "maintain schedule" activity from the Main
Form.
5.2.1 Basic Flow – Create a Schedule
The Student selects "create schedule."
The system displays a blank schedule form.
The system retrieves a list of available course offerings from the Course Catalog System.
The Student selects 4 primary course offerings and 2 alternate course offerings from the list of
available offerings. Once the selections are complete the Student selects "submit."
The "Add Course Offering" sub-flow is performed at this step for each selected course offering.
The system saves the schedule.
5.2.2 Alternative Flows
5.2.2.1 Modify a Schedule
The Student selects "modify schedule."
The system retrieves and displays the Student’s current schedule (e.g., the schedule for the
current semester).
The system retrieves a list of all the course offerings available for the current semester from the
Course Catalog System. The system displays the list to the Student.
The Student can then modify the course selections by deleting and adding new courses. The
Student selects the courses to add from the list of available courses. The Student also selects any
course offerings to delete from the existing schedule. Once the edits are complete the Student
selects "submit".
The "Add Course Offering" sub-flow is performed at this step for each selected course offering.
The system saves the schedule.
5.2.2.2 Delete a Schedule
The Student selects the "delete schedule" activity.
The system retrieves and displays the Student current schedule.
The Student selects "delete."
The system prompts the Student to verify the deletion.
The Student verifies the deletion.
The system deletes the schedule.
5.2.2.3 Save a Schedule
[At any point], the Student may choose to save a schedule without submitting it by selecting
"save". The current schedule is saved, but the student is not added to any of the selected course
offerings. The course offerings are marked as "selected" in the schedule.
11
We assume that (at any point) means that this Save action can occur whilst performing a Create
or Modify functional process. A Save cannot be performed unless a Schedule already exists and
is displayed to the Student. So a Save is not a separate functional process, but an optional step
in a Create or Modify functional process. It makes no sense for a Save to be needed during a
Delete functional process. Note that this Save action by a Student is not the same action as the
Save of a Schedule by the System.
5.2.2.4 Add Course Offering
The system [verifies that the Student has the necessary prerequisites] and that the course offering
is open (The detailed rules, and corresponding data groups for checking that the student has the
necessary prerequisites, are not described in the specifications; for this measurement scope, it is
taken as a given that the rule is simple and involves reading a single data group; we have called
this a ‘Schedule history record’ and assumed it is held in the C-Registration system). The system
then adds the Student to the selected course offering (assuming both tests are passed
successfully). The course offering is marked as "enrolled in" in the schedule.
(Note also that the distinction between when a course is ‘available’ and when it is ‘open’ is not
clear in the Specification. We have assumed for simplicity that these are synonyms)
5.2.2.5 Unfulfilled Prerequisites or Course Full
If in the "Add Course" sub-flow the system determines that the Student has not satisfied the
necessary prerequisites or that the selected course offering is full, an error message is displayed.
The Student can either select a different course offering or cancel the operation, at which point
the use case is restarted.
5.2.2.6 No Schedule Found
If in the "Modify a Schedule" or "Delete a Schedule" sub-flows the system is unable to retrieve
the Student’s schedule, an error message is displayed. The Student acknowledges the error and
the use case is restarted.
5.2.2.7 Course Catalog System Unavailable
If, the system is unable to communicate with the Course Catalog System after a specified
number of tries, the system will display an error message to the Student. The Student
acknowledges the error message and the use case terminates.
5.2.2.8 Course Registration Closed
If, when the student selects "maintain schedule", registration for the current semester has been
closed, a message is displayed to the Student and the use case terminates. Students cannot
register for courses after registration for the current semester has been closed.
6. Monitor for Course Full
[The system shall ensure] that no course is filled beyond the limit of 10 students.
In the specifications it is not clear whether the requirement is to do this once at the closure of
registration, or that this is done every time a student adds a course to his schedule. For this case
study, we have assumed that the requirement is to verify this condition every time a student
adds/modifies a course to his schedule. Otherwise many students could sign up for courses that
were already over-booked, which would not be the best way to proceed.
For this to be possible the C-Registration system must communicate back to the Course
Catalogue every time a student adds, modifies or deletes a course offering on his schedule, so
12
that the Course Catalog record for each course offering always contains the latest data on the
number of students enrolled. We have assumed this requirement.
With these assumptions, this monitoring occurs as part of the create, modify and delete Schedule
functional processes and is not itself a separate functional process.
7. Close Registration
7.1. Brief Description
This use case allows a Registrar to close the registration process. Course offerings that do not
have enough students are cancelled. Course offerings must have a minimum of three students in
them. The billing system is notified for each student in each course offering that is not cancelled,
so the student can be billed for the course offering.
The main actor of this use case is the Registrar. The Billing System is an actor involved within
this use case.
7.2. Flow of Events
The use case begins when the Registrar selects the "close registration" activity from the Main
Form.
7.2.1 Basic Flow – Successful Close Registration
[The system checks to see if a Registration is in progress]. If it is, then a message is displayed to
the Registrar and the use case terminates. The Close Registration processing cannot be
performed if registration is in progress. (It is not clear how the check on whether a registration
is in progress can be carried out. If it is performed by the C-Registration application, then there
must be communication between the ‘Register for Courses’ Use Cases and this ‘Close
Registration’ Use Case. But this functionality is not described, so we have ignored it in this
analysis
For each open course offering, the system [checks if three students have registered] and a
professor has signed up to teach the course offering. If so, the system closes the course offering
and sends a transaction to the billing system for each student enrolled in the course offering.
(As with previous Use Cases, we assume that the count of the number of students signed up for
each course is maintained on the Course Catalog system.)
7.2.2 Alternate Flows
7.2.2.1 Less Than Three Students in the Course Offering
If in the basic flow less than three students signed up for the course offering, the system will
cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.
7.2.2.2 Cancel Course Offering
The system cancels the course offering. For each student enrolled in the cancelled course
offering, the system will modify the student’s schedule. The first available alternate course
selection will be substituted for the cancelled course offering. If no alternates are available, then
no substitution will be made. Control returns to the Main flow to process the next course
offering for the semester.
(The way in which the system deals with students’ alternative course selections is unclear in this
specification. The specification appears to state that courses with less than three students
enrolled are cancelled and only then are alternatives examined – which might reveal that many
students have chosen the course as an alternative but, too late, it has already been cancelled.
13
Fortunately for the functional sizing the sequence of the logic is immaterial.)
Once all schedules have been processed for the current semester, the system will notify all
students, by mail, of any changes to their schedule (e.g., cancellation or substitution).
7.2.2.3 No Professor for the Course Offering
If in the basic flow there is no professor signed up to teach the course offering, the system will
cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.
7.2.2.4 Billing System Unavailable
If the system is unable to communicate with the Billing System, the system will attempt to resend the request after a specified period. The system will continue to attempt to re-send until the
Billing System becomes available.
(There is another functional process implied in 7.2.2.4 which has been ignored in this Step 1 of
the measurement. Logically, the functionality of ‘sending a transaction to the billing system for
each student enrolled in the course offering’ as described in 7.2.1 above cannot take place until
the processing of all selections of all students for all courses has been completed. So the ‘Close
Registration’ process must create a file of billing data and a separate functional process must
send the data to the Billing System, triggered either by the end of the ‘Close Registration’
process or, if previous attempts to transit have failed because the Billing System is unavailable.
by a ‘try again’ time signal in the C-Registration system.)
8. Submit Grades
8.1. Brief Description
This use case allows a Professor to submit student grades for one or more classes completed in
the previous semester. (We assume this means ‘the semester just ended’.)
The actor in this use case is the Professor.
8.2. Flow of Events
The use case begins when the Professor selects the "submit grades" activity from the Main Form.
8.2.1 Basic Flow – Submit Grades
The system displays a list of course offerings the Professor taught in the previous semester.
The Professor selects a course offering.
The system retrieves a list of all students who were registered for the course offering. The
system also retrieves the grade information for each student in the offering (i.e. that was
previously assigned for the offering. Note that the specification for this Use Case does not
distinguish clearly the ‘Add’ and ‘Modify’ cases).
The system displays each student and any grade that was previously assigned for the offering.
For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records
the student’s grade for the course offering. If the Professor wishes to skip a particular student,
the grade information can be left blank and filled in at a later time. The Professor may also
change the grade for a student by entering a new grade.
8.2.2 Alternative Flows
8.2.2.1 No Courses Taught
If in the basic flow, the Professor did not teach any course offerings in the previous semester the
system displays an error message and the use case ends.
14
8.2.2.2 Course Cancelled
If too many students withdrew from the course during the add/drop period and the course was
cancelled after the beginning of the semester, the system displays an error message. If the
Professor chooses to cancel the operation the use case terminates, otherwise is restarted at step 2
of the basic flow.
9. View Report Card
91. Brief Description
This use case allows a Student to view his/her report card for the previously completed semester.
The Student is the actor of this use case.
9.2. Flow of Events
The use case begins when the Student selects the "view report card" activity from the Main Form
9.2.1 Basic Flow – View Report Card
The system retrieves the grade information for each of the courses the Student completed during
the previous semester.
The system prepares, formats, and displays the grade information.
When Student is finished viewing the grade information the Student selects "close."
9.2.2 Alternative Flows
9.2.2.1 No Grade Information Available
If in the basic flow the system cannot find any grade information from the previous semester for
the Student, a message is displayed. Once the Student acknowledges the message the use case
terminates.
15
2.3 USE CASE DIAGRAM
View Report Card
Login
Student
Register for Courses
Course Catalog
Select Courses to Teach
User
Professor
Submit Grades
Registrar
Maintain Professor Information
Maintain Student Information
Close Registration
Billing System
Figure 1. Course Registration System - Use Case Diagram – RUP 2003
16
3. COSMIC-FFP MEASUREMENT PROCEDURE - STEP 1
3.1 IDENTIFICATION OF LAYERS
There is a single software layer for this set of requirements
3.2 IDENTIFICATION OF USERS
The users who interact with this software:
a) Users who send information to the software:
- Wylie College Users:
- Students,
- Professors,
- Course Registrar
- Course Catalog system
b) Users who receive information from the software:
- Wylie College Users:
- Students,
- Professors,
- Course Registrar
- Course Catalog system
- Billing System
- Mail subsystem
3.3 BOUNDARY
This measurement is limited to the software product functionalities; neither quality nor
performance requirements are considered. Based on the written requirements from section 2, the
following software boundary is identified - Figure 2.
Wylie College Users
(Students, Professors,
Course Registar)
Boundary
Mail system
C-Registration
System
Course Catalog
System
Student schedule
Billing system
Figure 2. Application Boundary
17
3.4 IDENTIFICATION OF TRIGGERING EVENTS – Step 1
From the textual descriptions of the requirements, 14 candidate triggering event(s) are identified
as listed in Table 1.
Table 1: List of candidate triggering events – Step 1
Main Form Menu selection
No
1
Actor access the login form
2
3
4
5
6
7
8
14 Triggering events
1- Actor types his/her name and password
on the login form
Registrar selects the "maintain professor" 2- Add a Professor
activity from the Main Form
3- Modify a Professor
4- Delete a Professor
Professor selects the "select courses to 5- Professor selects his/her courses to
teach" activity from the Main Form
teach
Registrar selects the "maintain student" 6- Add a Student
activity from the Main Form
7- Modify a Student
8- Delete a Student
Register for course: Student selects the 9- Create a Schedule
"maintain schedule" activity from the 10- Modify a Schedule
Main Form
11- Delete a Schedule
Registrar selects the "close registration"
activity from the Main Form
The Professor selects the "submit grades"
activity from the Main Form
The Student selects the "view report
card" activity from the Main Form
12- Registrar starts the Close Registration
functional process
13- Professor submit grades
14- Student View Report Card
3.5 IDENTIFICATION OF DATA GROUPS – Step 1
From the documented requirements, seven objects of interest are identified. These are listed in
Table 2 together with their most significant data groups. Note that an accurate data analysis is
not possible given some uncertainties in the documentation of the FUR. No Entity-Relationship
model or Third Normal Form model analysis is available in the available documentation.
Table 2 does not show any data groups corresponding to exchanges between the PC client and
the main-frame server because these exchanges are invisible to End Users when the Scope of the
measurement is defined as ‘the whole C-registration system’.
18
Table 2: List of Objects of Interest and Data Groups – Step 1
Source/
Destination
of data
Users
Object of
Interest
Data
groups
User*
User data
Registrar
Professor*
Professor
data
Registrar
Student*
Student
data
Course
Catalog
System
Course
Catalogue
System
Student
Course
Course
data
Courseoffering
Schedule
item*
Course
offering
data
Schedule
item data
Professor
Schedule
item*
Student
grade
Previous
cycles of the
C-Reg
System?
Schedule
history item*
Schedule
history
record
Mail System
Schedule
item*
Billing
System
Schedule
item*
Student
schedule
changes
message
Invoiceitem
C-Reg
System
’System’
Error
Message
Data attributes
User ID
User Name
Password
Prof. ID, name, date of
birth, social security
number, status, and
department
Student’s ID, name, date
of birth, social security
number, status, and
graduation date.
All information relevant
to a course registered in
the Course Catalog
Course offering ID
No. of students signed-up
Professor ID signed-up
Student ID
Course offering ID
Primary/alternate course
preference indicator
Selected/enrolled status
Student ID.
Course offering ID
Grade
Student ID
Course offering ID
Date of course
Grade
(for previous courses)
Student ID
Course offering ID
(for each change to a
Student’s schedule)
Student ID
Course offering ID
Fee payable
(for each course offering
that the student has been
accepted for)
Comments
See Note 1 below
This data relates to
the current semester
Note that ‘Student
grade’ is another data
group of the object of
interest ‘Schedule
item’
Not all data attributes
are specified in the
documentation
Not all data attributes
are specified in the
documentation
See Note 4
19
* From the requirements, we conclude that data about the five asterisked objects of interest are
stored persistently on the C-Registration system. Data about the ‘Course’ and ‘Course offering’
objects of interest are stored persistently on the Course Catalog system.
Note 1 It might be that the Course Catalog system distinguishes data held about each ‘Course’
from data held about each ‘Course-offered-in-the-current-seminar’, i.e. there are two objects of
interest. The former would have time-independent data about the course, e.g. course description,
pre-requisites, etc. The latter would have, for example, attributes such as the ID of the professor
signed up to teach the course this semester, the total number of students signed up so far, etc.
We have no information in the specification on whether the Course Catalog system makes this
distinction, but it seems more logical that it does than that it does not. So we have assumed that
two objects of interest exist, namely the ‘Course’ and the ‘Course offering’, where the latter has
data about the course for the current semester. But an assumption that there is only one object of
interest (‘course-offering’) would also be valid.
This assumption affects the measured size because we have assumed that some functional
processes need only ‘Course-offering’ data (e.g. when a student creates a ‘Schedule’) whereas
other functional processes need ‘Course’ attributes as well (e.g. to check the pre-requisites for a
particular course). But these assumptions might be wrong. For example, it might be that a
student needs to see the ‘Course’ data as well as ‘Course offering’ data when creating a
Schedule.
Note 2 The ‘Student Schedule’ is not a separate object of interest. There is no data held about a
Student Schedule. It is a collection of up to six occurrences of a data group for each student
showing the course-offerings that he/she has signed up for as ‘primary or alternate’ and as
‘selected or enrolled’. We have named each of these data groups ‘schedule item data’, to
distinguish it from the name of the object of interest (‘schedule item’) of the group.
The complete Student Schedule appears, for example, when a student displays the collection of
up to six courses that he/she has signed up for.
Note 3. The ‘List of professors’ is not a separate object of interest of data group. See Note 2 :
No data are held about the list.
Note 4. The ‘System’ is not really an object of interest. All we know is that the software
produces error messages. There is no need to identify an object of interest, just as there is no
value in identifying the object of interest of a pure command data movement
Definitions of the 7 Objects of interest (in alphabetic order)
Course: A standard series of lectures, etc on a specific subject from the College Course
Catalogue
Key: (Course ID). Other attributes (assumed): Course name, description, Pre-requisite Course
ID
Note: Registration by a Student for a particular Course Offering may depend on successful
attendance at (i.e. passing) a ‘pre-requisite’ course.
Course-offering: A Course that is available for students to enrol during a particular Semester
20
Key: (Course ID, Semester ID). Other attributes: dates, times, locations of the lectures, etc.,
availability indicator (open/closed/cancelled), assigned Professor, number of students enrolled
Professor: A person who may register to deliver a Course-offering in the current Semester, for
a Course which he is eligible to teach.
Key: (Professor ID). Other attributes: name, address, date of birth, SSN, status, Department,
phone, fax, e-mail
Student: A person who can register to attend a Course-offering
Key: (Student ID). Other attributes: name, DOB, status, graduation date
Schedule item: One of the maximum of six entries in a Student Schedule when a Student
selects or enrols in a Course-offering
Key: (Student ID, Course-offering ID). Other attributes: Student preference status (primary,
alternate), registration status (selected, enrolled in), grade awarded, fee payable, etc
Schedule history item: An instance of a specific student having attended a specific Courseoffering during a previous semester
Key: (Student ID, Course-offering ID, Semester date). Other attributes: Grade awarded
User: Any person (Registrar, Professor or Student) that is authorised to use the C-Registration
system
Key: User ID. Other attributes: User name, password
3.6 IDENTIFICATION OF FUNCTIONAL PROCESSES – Step 1
From the documented requirements with each triggering event, there are 14 candidate functional
processes.
14 Candidate Functional Processes – Step 1
1- Actor types his/her name and password on the login form
2- Add a Professor
3- Modify a Professor
4- Delete a Professor
5- Professor selects/de-selects his/her courses to teach
6- Add a Student
7- Modify a Student
8- Delete a Student
9- Create a Schedule
10- Modify a Schedule
11- Delete a Schedule
12- Registrar starts the Close Registration functional process
13- Professor submit grades
14- Student View Report Card
The measurement procedure must assess whether a candidate functional process is a COSMICFFP one or not.
21
Each candidate process must satisfy the following questions in order to be validated as a
COSMIC-FFP functional process:
Does it operate on a unique cohesive and independently executable set of data movements
performing a set of FUR?
Is it triggered by an event (triggering event)?
Does the triggering event occur outside the boundary of the software?
Does the process execute all that is required to be done in response to the triggering event?
These questions are investigated next. Analyses of only 3 functional processes out of 14 are
presented next in order to minimize redundancy and reduce the document’s size.
Functional Process 1 = Logon
Question
Answer
Does it operate on a unique cohesive and independently Yes
executable set of data movements performing a set of
FURs?
Is it triggered by an event?
Yes
Does the triggering event occur outside the boundary of Yes
the software?
Does the process execute all that is required to be done in Yes
response to the triggering event?
Comments
Actor types his/her
name and password on
the login form
Actor is outside the
boundary
The Logon process is therefore a COSMIC-FFP functional process.
Functional Process 2 = Add a professor
Question
Answer
Does it operate on a unique cohesive and independently Yes
executable set of data movements performing a set of
FURs?
Is it triggered by an event?
Yes
Does the triggering event occur outside the boundary of Yes
the software?
Does the process execute all that is required to be done in Yes
response to the triggering event?
Comments
Registrar selects the
"add professor"
Registrar is outside the
boundary
The Add a professor process is therefore a COSMIC-FFP functional process.
Functional Process 3 = Modify a professor
Question
Answer
Does it operate on a unique cohesive and independently Yes
executable set of data movements performing a set of
FURs?
Is it triggered by an event?
Yes
Comments
Registrar selects the
22
Does the triggering event occur outside the boundary of Yes
the software?
Does the process execute all that is required to be done in Yes
response to the triggering event?
"modify professor"
Registrar is outside the
boundary
The Modify a professor process is therefore a COSMIC-FFP functional process.
Note Data groups will be associated with identified functional processes in the next section in a
detailed manner.
3.7 OBSERVATIONS ON THE CLARITY OF THE DOCUMENTED REQUIREMENTS
Even though the documented requirements used for this Case Study are coming from the
Rational Unified Process, there is no mention about the quality of these requirements.
IEEE Std 830-1998 recommends that requirements meet the following quality criteria:
- Correct;
- Unambiguous;
- Complete;
- Consistent;
- Ranked for importance and/or stability;
- Verifiable;
- Modifiable;
- Traceable.
In the RUP documentation, there is no claim that their sets of documented requirements meet the
quality criteria specified in IEEE 830.
The Use Cases diagram has been taken ‘as is’ from the RUP training section on RATIONAL
web site.
In some instances, some text in the Requirements has been added in italics to complement
missing information;
Similarly, when a section of the text of the Requirements was unclear, it was put into brackets,
and complementary text was added in italics.
The measurement results in this section of this document are based taking into account only:
- the written Requirements as in Section 2 of this document
- the assumptions and clarifications documented in italics in Section 2
- the Use Case diagram as in Section 2 of this document.
3.8. IDENTIFY DATA MOVEMENTS – Candidate functional processes – Step 1
For all functional processes in the previous steps, all data movements of a data group must be
identified.
Important: the reader is reminded of paragraph 1.3 where it is stated that in this Step 1, the
requirements are interpreted literally and analysed assuming each explicitly identified event
triggers only one functional process. The detailed analysis in Step 2 identifies, however, that in
some cases there should almost certainly be more than one functional process from what would
23
have initially appeared to be a single triggering event. When this happens, this will be noted in
Table 3 by using a dashed line to indicate where one functional process might end and the next
start. These dashed lines are only relevant to the discussion in Step 2.
In table 3, the numbers in the ID Process column refer to the numbers in the Requirements
section of this document.
24
Table 3. List of COSMIC-FFP data movements – Functional Processes – Step 1
No
1
ID. of
Triggering event
Process
Require descriptions
ments
1.2
Logon
Actor types his/her name
and password on the login
form
Sub-process Description
Actor enters name and password
Read name and password
Display error message
Data Group
Data
movement
Type
Cfsu
ΣCfsu
System
User data
Messages
E
1
R
X
1
1
3
Maintain Professor Information
2
2.2.1
Add a
Registrar selects the "add a Registrar enters information for the
professor
Professor" activity
Professor
2.2.2.3
The system validates the entered data and
checks if a professor of the same name
exists already
The system creates a new Professor
Display the system generated Professor ID
number
Display error message
Professor data
E
1
R
1
Professor data
Professor ID
W
1
X
1
Messages
X
1
Professor data
5
3
2.2.2.1
2.2.2.4
Modify a
professor
Registrar selects the
"modify a Professor"
activity
Registrar enters Professor ID
The system retrieves the Professor
information
The system displays the Professor
information
The Registrar enters the modified
Professor data
Professor ID
Professor data
Professor data
Professor data
E
1
R
1
X
1
E
1
25
When changes are complete, the Registrar This is not a
selects ‘Save’
distinct data
movement. It
only indicates
that the Entry
of the data (see
above) is
completed
The system updates the Professor
Professor data
information
Display error message
Message
This will be
omitted from
now on in all 0
other use
cases
W
1
X
1
6
4
2.2.2.2
Delete a
Professor
2.2.2.4
Registrar selects the
"delete a Professor"
activity
Registrar enters Professor ID
The system retrieves the Professor
information
The system displays the Professor
information
Registrar enters the delete command for
the selected Professor
The system prompts the Registrar to
confirm the deletion
The Registrar confirms the deletion
Professor is deleted from the system
Display error message
Professor ID
Professor data
Professor data
Professor ID
E
1
R
1
X
1
E
1
System prompt n/a (not a
command
data group
movement)
Professor ID
n/a
(repetition of
Delete Entry
above)
Professor data W
Message
X
0
0
1
1
6
5
3.2
Select /De-
Professor selects/de-select Start the ‘select courses to teach’ process
‘Select courses E
1
26
3.2.2.3
select
Courses to
Teach
the "select courses to
teach" activity from the
Main Form
3.2.2.1
3.2.2.2
to teach’
command
The system requests (from the Course
Catalog database) the list of courses the
professor has previously selected to teach
and others that he is eligible to teach
The system receives the requested data
Course
offering data
Course
offering data
The system displays the requested data
Course
offering data
The Professor selects and/or de-selects the Course
course offerings that he/she wishes to
offering data
teach for the upcoming semester
The system sends the Professor’s selected Course
or de-selected course offerings to the
offering data
Course Catalog system
The Course Catalog system verifies that
Course
the selected offerings do not conflict and offering data
returns any conflicting pairs
Conflicting pairs of courses are displayed Course
offering data
Display error message
Messages
X
1
E
1
X
1
E
1
X
1
E
1
X
1
X
1
9
Maintain Student Information
6
4.2.1
Add a
Registrar selects "add
student
student"
4.2.2.3
Registrar enters student data
Student data
The system validates the data and checks
if a student of the same name already
exists
The system creates a new student
Display error message
Student data
Student data
Messages
E
1
R
1
W
X
1
1
27
4
7
4.2.2.1
Modify a
student
Registrar selects "modify
student"
4.2.2.4
Registrar enters student ID
Student ID
The system retrieves the student
information
The system displays student information
Registrar modifies one or more of the
student information fields
The system stores the modified data
Display error message
Student data
E
1
R
1
Student data
Student data
X
1
E
1
Student data
Message
W
X
1
1
6
8
4.2.2.2
Delete a
Student
Registrar selects "delete
student"
4.2.2.4
Registrar enters student ID
Student ID
The system retrieves the student
information
The system displays student information
Registrar enters ‘delete’ command
The system prompts the Registrar to
confirm the deletion
Student data
The Registrar confirms the deletion
Student is deleted from the system
Display error message
Student data
Student id
System prompt
command
Confirmation
message
Student data
Message
E
1
R
1
X
E
n/a (Not a
data group
movement)
n/a
(repetition of
Delete Entry
command
above)
W
X
1
1
0
0
1
1
6
Register for Course
9
5.2.1
Create a
Schedule
Student selects "create a
schedule"
Student enters "create schedule"
Start create
schedule
command
E
1
28
5.2.2.4
6.
5.2.2.3
Request the course offerings from the
Course Catalog System
Receive the available course offerings
from the Course Catalog System for the
current semester
The system displays the list of available
course offerings
The student selects 4 primary courses and
2 alternate courses and submits them (to
this application i.e. C-Reg system)
The system verifies with the Course
Catalog system what pre-requisites are
needed
The system verifies whether the Student
has satisfied the necessary prerequisites
Validated Schedule items are returned to
the Course Catalog system so that it can
maintain the student count for each course
The Course Catalog system verifies that
the course offering is still open and that
less than 10 students are enrolled
Course
offering data
Course
offering data
Schedule items are marked as "enrolled
in" and are made persistent in the
Student’s schedule on the C-Reg system
The system saves the schedule (This
happens when the Schedule items are
made persistent by the Write above)
Student may choose to save a schedule
without submitting it by selecting "save"
The course offerings are marked as
"selected" in the schedule and it is saved
Display error message
Schedule item
data
Course
offering data
Schedule item
data
Course data
Schedule
history record
Schedule item
data
Schedule item
data
Schedule item
data
Messages
X
1
E
1
X
1
E
1
1xX
1xE
1
1
1xR
1
X
1
(N/A – not
part of the
C-Reg
system)
0
W
1
N/A
0
E
1
W
1
X
1
29
13
10
5.2.2.1
5.2.2.6
5.2.2.4
6.
5.2.2.3
Modify a
Schedule
Student selects the
Student enters ‘modify a schedule’
"modify schedule" activity command
from the Main Form
The system retrieves the Student’s current
schedule
The system displays the Student’s current
schedule
The system retrieves all the course
offerings available for the current
semester from the Course Catalog System
The system displays the list of available
course offerings
The student enters the modifications to his
Schedule item(s)
The system verifies with the Course
Catalog system what pre-requisites are
needed
The system verifies whether the Student
has the necessary prerequisites
Validated Schedule items are returned to
the Course Catalog system so that it can
maintain the student count for each course
The Course Catalog system verifies that
there are less than 10 students enrolled
and that the course offering is still open
Schedule items are marked as "enrolled
in" and are made persistent in the
Student’s schedule on the C-Reg system,
when saved by the system
Student may choose to save a schedule
without submitting it by selecting "save"
The course offerings are marked as
Modify a
schedule
command
Schedule item
data
Schedule item
data
Course
offering data
Course
offering data
Schedule item
data
Course data
Schedule
history record
Schedule item
data
Schedule item
data
Schedule item
data
Schedule item
E
1
R
1
X
1
1xX
1xE
2
X
1
E
1
1xX
1xE
1xR
1
1
1
X
1
(N/A)
0
W
1
E
1
W
1
30
"selected" in the schedule and it is saved
Display error message
data
Messages
X
1
15
11
5.2.2.2
5.2.2.6
Delete a
Schedule
Student selects the "delete Student enters ‘delete schedule’ command
schedule" activity from the
Main Form
The system retrieves the student’s current
schedule
The system displays the student’s current
schedule
The student enters the deletion command
for the schedule
The system prompts the Student to verify
the deletion
The student confirms the deletion
6.
Delete
Schedule
command
Schedule item
data
Schedule item
data
Delete
Schedule
command
System Prompt
Command
Schedule item
data
The system updates the student’s schedule Schedule item
data
The system sends the deleted schedule
Schedule item
items to the Course Catalog system so that data
the latter can update the number of
students enrolled for each course
Display error message
Messages
E
1
R
1
X
1
E
1
(N/A)
0
N/A (Repeat
of Entry
0
above)
W
1
X
1
X
1
7
12
7.2
Close
Registrar selects the "close Registrar enters ‘Close Registration’
Registration registration" activity from
the Main Form
Close
registration
command
E
1
31
Read if a Registration is in progress
System
Display error message
Obtain Course offering data (with no. of
students enrolled, etc) from the Course
Catalog
Read Schedule items to obtain the
‘enrolled’ and ‘alternate’ course selections
Check that at least three students signed
up: if not cancel course and examine
student’s alternatives
Send info for a billing transaction for each
student accepted for each course
Update the course offerings on the Course
Catalog
Update each student’s schedule
Message
Course
offering’
Send info on any schedule changes to
students through mail subsystem
Schedule item
data
Data
manipulation
Invoice item
Course
offering data
Schedule item
data
Student
schedule
changes
message
N/A see
7.2.1 in
section 2
(not enough 0
details for
measurement
purposes)
X
1
1xX
1xE
2
R
1
(N/A)
X
1
X
1
W
1
X
1
9
13
8.2
Submit
Grades
The Professor selects the
"submit grades" activity
from the Main Form
The Professor decides to submit grades
The system retrieves the courses the
professor taught from the Course Catalog
Start the
‘submit
grades’
process
Course
offering data
E
1
1xX
1xE
2
32
Course offerings are displayed
Course
offering data
The Professor selects a course offering
Course
offering
selection
For each course offering, selected in turn, Schedule item
the system retrieves the schedule items for data
all students who were registered for each
course offering
The system also retrieves the grade
Grade is the
information for each student in the course second data
offering that had been entered previously group within
(if any)
the Schedule
item data
Object of
Interest
The system displays each schedule item
Schedule item
for each student including any grade that data and Grade
was previously assigned for the offering
The professor enters or changes the
Schedule item
student’s grade for the course offering
data
The system records the student’s grade for Schedule item
the course offering
data
Display error message
Messages
X
1
E
1
R
1
R
1
2X
2
E
1
W
1
X
1
12
14
9.2
View Report The Student selects the
The Student selects the "view report card"
Card
"view report card" activity activity from the Main Form
from the Main Form
The system retrieves the grade
information for each of the courses the
Student completed during the previous
semester
Start ‘view
report card’
process
Schedule item
data
Grade
E
1
2R
2
33
Total functional size in Cfsu =
The system prepares, formats, and
displays the grade information
When Student is finished viewing the
grade information the Student selects
"close"
Schedule item
data & grade
Students
Grades
Display error message
Messages
2X
2
A control
command,
not a
0
separate data
movement
X
1
6
ΣCfsu 107
Important
Note 1: The above measurement results have taken into consideration the assumptions indicated in italics in the requirements of section
2.2. Any change to these assumptions can have an impact to the functional size.
Note 2: The above measurement results are based on the information available at the Requirements level. It is feasible that more
information is added at the Specifications level which would add further data groups; this would most certainly impact the functional size.
It is also plausible that the detailed specifications lead to additional functional processes and/or the addition of sub-processes. Again, this
could lead to changes to the functional size in order to take into account these additions
Note 3: It is the responsibility of the measurer to identify, within the documented requirements, what he considers as ambiguities and
omissions and to document the assumptions he made that led to the measurement results he produced and documented. The comments
documented by the measurer represent value added during the measurement process. These comments should next be reviewed by the
project manager who should then address these comments prior to proceeding further with the project.
34
3.9. ANALYSIS OF MEASUREMENT RESULTS
For this software application, the total functional size is obtained with the addition of all
data movements within its single functional process, that is 106 Cfsu (ISO 19761: 2003),
as indicated at the bottom of Table 4.
Table 4. Distribution of size units - Course Registration application
No
Requirements ID
Functional Processes
E
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1.2
2.2.1
2.2.2.1
2.2.2.2
3.2
4.2.1
4.2.2.1
4.2.2.2
5.2.1
5.2.2.1
5.2.2.2
7.2
8.2
9.2
TOTAL
Logon
Add a professor
Modify a professor
Delete a Professor
Select Courses to Teach
Add a student
Modify a student
Delete a Student
Create a schedule
Modify a schedule
Delete a schedule
Close registration
Submit Grades
View Report Card
14
Data Movements
X
R
W
1
1
2
2
4
1
2
2
5
5
2
2
4
1
33
1
2
2
2
5
1
2
2
5
6
4
6
5
3
43
1
1
1
1
1
1
1
1
2
2
2
2
2
17
1
1
1
1
1
1
2
2
1
1
1
13
Cfsu
3
5
6
6
9
4
6
6
13
15
7
9
12
4
107 Cfsu
The contribution of functional processes to total Cfsu size is presented in Table 5.
Table 5. Contribution of functional process to total size (% rounded to the integer)
No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Requirements ID
1.2
2.2.1
2.2.2.1
2.2.2.2
3.2
4.2.1
4.2.2.1
4.2.2.2
5.2.1
5.2.2.1
5.2.2.2
7.2
8.2
9.2
TOTAL
Functional Processes
Logon
Add a professor
Modify a professor
Delete a Professor
Select Courses to Teach
Add a student
Modify a student
Delete a Student
Create a schedule
Modify a schedule
Delete a schedule
Close registration
Submit Grades
View Report Card
14
Cfsu
%*
3
5
6
6
9
4
6
6
13
15
7
9
12
6
107 Cfsu
3
5
6
6
9
4
6
6
13
15
7
8
8
4
100%
35
The percentages of size by data movement types are presented in Table 4 and Figure11.
Table 6. Percentage of the Cosmic-FFP data movement types
Data Movement Types
Entry (E)
Exit (X)
Read (R)
Write (W)
Total :
Cfsu
34
43
17
13
107 (Cfsu)
%
32
40
16
12
100 (%)
13%
31%
15%
Entry
Exit
Read
Write
41%
Figure 3. Ratio of COSMIC FFP data movement types
36
3.10. QUESTIONS AND ANSWERS
Question 1
Often, the ‘Logon’ process is a functional process provided by the software environment
and is not measured in the software application itself. Why is it included in the
measurement boundary in this case study?
Answer 1:
It is documented in the Requirements that the old system was mainframe based accessed
only by a clerk. The ‘new system’ requires this log-in for access by the students and
professors, for instance. It is also included in the Use Case diagram.
Question 2
Can one triggering event (Registrar selects the “maintain professor” activity from Main
Form) trigger more than one functional process (Add, Modify, Delete and View a
Professor)?
Answer 2:
There is no such event as ‘maintain professor’ in this RUP case study. In the real world
of the Registrar there are events like:
A new professor starts work
Something changes for a professor, so the data to be stored about him must be
changed
A professor leaves or dies or whatever, so we must remove him from the
database.
These three types of event lead to the corresponding types of functional processes (i.e.
add, modify and delete) respectively.
‘Maintain professor’ is a group of functional process types. Selection of this group by
the Registrar is a control command, not measured in the End User Measurement
Viewpoint – see the Business Application Guideline, because it does not start one
functional process.
Question 3
The ‘Maintain Professor’ Use Case alternative flow 2.2.2.3 ‘Professor Already Exists’
says “…The Registrar can… choose to create another professor with the same name…”
Why is this not an Entry data movement?
Answer 3:
Within this functional process, there is already an Entry of this data group. The deduplication rule specifies that a data movement must not be taken into account twice
within the same functional process - it is logically the same data movement.
37
Question 4
The Use Case alternative flow 3.2.2.2 ‘Schedule Conflict’ says that when the Course
Catalog finds a schedule conflict between two courses, they are sent back to the CRegistration system and the Professor may either cancel his selection to teach one of the
courses, or cancel the whole operation. Why doesn’t the solution given show all the data
movements associated with this requirement?
Answer 4.
It appears from the requirements that the data movements to return and display two
conflicting courses from the Course Catalog system to the C-Registration system are
different from other data movements earlier in this functional process. So these two data
movements are identified. (The earlier return and display of courses is a list of courses
that the Professor either has already selected to teach, or that he is eligible to teach. The
latter return and display is of two courses that are linked by a schedule conflict.)
But the following actions by the Professor to select or deselect one of the conflicting
courses and send the choice back to the Course Catalog system appear to be functionally
identical to the earlier cycle of selections and sending back courses. If this interpretation
is correct, according to the ‘de-duplication’ rule, these two data movements (an Entry
and an Exit) should be identified only once.
Cancelling the whole operation is a Control command and should not be identified.
Question 5
The Functional process Delete a Schedule has a requirement: “The system prompts the
Student to verify the deletion” entry data movements. Confirmations like this one appear
on other functional processes like Delete a Professor. Why are these not identified as
data movements?
Answer 5:
In the Business Application Guidelines the rule is given in 5.6.1 that clicking ‘OK’ to
confirm some entered data should be ignored as a Control command. (This is a
reasonable rule. The confirmation involves a repeat of some logic and we do not take
into account repeats of the same logic two or more times in a functional process.) We
have shown this logic in the case of ‘Delete a Schedule’, but not in other cases, since it
should not identified and counted in any of them.
Question 6
Observations and questions sent by a user of this case study: “The requirements for the
Logon functionality are practically useless from a security point of view in that anyone
can log-on by entering ‘a new name and password’, which apparently is not stored.
Further, there is no requirement for an explicit link between any registration (e.g. of a
38
Student by the Registrar) and the Logon procedure. The Logon authorisation also does
not explicitly prevent that any role may carry out the tasks of any other role, eg. a that a
student can enter his own grades.”
Answer 6:
The questions are relevant. However, all these points have not been documented in the
requirements. The purpose of the measurement for the case study being to measure the
requirements as documented, we have not taken this case into account here.
However, should the purpose of measurement be different, an analyst might then correct and
expand the requirements, and these additions should then be added to the size.
Question 7
In 2.2.1, ‘Add a Professor’ it reads ‘The system validates the data …’. When modifying
a professor, this validation is missing in the Requirements at section 2.2.2.1
Answer 7:
The observation is relevant. However, even if this data validation had been specified (which it
should be), it would not result in any more data movements, so no change to the measured
functional size. The ‘data validation’ is already taken into account in the following data
movements included in the measurements: Read (info about the professor), Exit (Display) and
Exit (error message).
Question-Observation 8.
In 2.2.2.2, ‘Delete a Professor’, there is no check whether the Professor has signed to teach a
Course, so deleting the professor would leave a Course with no-one to teach it.
Answer 8 The observation is relevant, but the authors of this measurement case study do not
know how this obvious check should be handled (and it is not specified in the requirements), so
we have chosen not to attempt to account for the omission. The consequences of the check
failing could be quite complicated, e.g. resulting in a need to inform all students signed up for
the affected courses of the change, finding an alternative Professor, cancelling the courses, etc.
All consequences would require additional functionality and hence this would lead to a greater
size
Question 9
In Table 3, section 4 for ‘Delete a Professor’, the Registrar enters a delete command,
which is identified as an Entry. However, the Professor has been selected by a first
Entry (by entering the Professor ID). So why is the delete command identified as an
Entry and not as a control command? The delete command just says ‘delete the present
professor’; it does not convey data about an object of interest. This same comment
applies to several functional processes.
39
Answer 9.
The delete command DOES convey data about a specific object of interest, the alreadyidentified Professor, so this must be identified as an Entry. It may be that no attribute
such as a specific Professor ID must be explicitly entered by the Registrar, but the
specific ID is certainly implied in this command. This is quite different from a real
‘control ‘command’ (as defined in the ‘Guideline for Sizing Business Application
Software’, paragraph 5.6.1), such as ‘page-up’ or ‘page down’.
Question 10
In 5.2.1 ‘Create a schedule’ there are 2 Writes. Why no de-duplication here?
Answer 10:
In practice, this set of requirements includes not 1 but 3 functional processes, which
must be executed in sequence. I will find a way to clarify this, by adding a note in the
‘Functional Process column, and putting a ‘dashed line’ between the two FP.
Therefore, the duplication applies within a Functional Process, not across 2 Functional
Processes, as it is the case here.
Question 11
In 5.2.2.1, what is the difference between the 2 X’s? Why no de-duplication?
Answer 11:
In practice, this set of requirements includes not 1 but 3 functional processes, which
must be executed in sequence. I will find a way to clarify this, by adding a note in the
‘Functional Process column, and putting a ‘dashed line’ between the two FP.
Therefore, the duplication applies within a Functional Process, not across 2 Functional
Processes, as it is the case here.
Question 12
In Functional Process no 4 – Delete a professor, there is a first step to view a professor
(with an Entry, Read and Exit), and then a second step to Delete the professor (with an
Entry, Write and Exit). Why is this considered as only 1 Functional Process and not 2
Functional Processes since the user has to enter again information (Is this a second
triggering event starting a second Functional Process)?
Answer 12:
A functional process is triggered when a functional user detects an event, or makes an
independent decision outside the software.
Examples are:
- there is a new student, and as a userI must enter data about him;
40
- The student needs to enquire on the schedule of courses the student has enrolled for, to
check something.
Once started down that process, there may be decision points which take the student down
different paths in the software, depending on the input data, but the student only starts a new
functional process if he makes a new independent decision.
An example in the C-Reg case where there might be some debate is in the 'Create Schedule'
Functional Process, where the student can decide 'at any point' to 'save' a Schedule, with status
'selected' rather than the 'enrolled' status if the Functional Process is continued to normal
completion. This option is necessary because a student may start to enter his schedule and then
find a course he wants is fully-booked, or he doesn't like the professor, or whatever, so the
option exists to 'park' his entry while he goes away and thinks what to do.
This 'save' as the start of a new fp, but rather an option of the 'create' (or add or delete) fp. If in
any Functional Process, we were to say that if a user decides to take a break, or change his
mind and back out, or make a check-point, he must be starting a new Functional Process, then
this could multiply the size very rapidly. The definition of a Functional Process says something
like that it is 'not complete until it has done all that was needed to respond to the event that
triggered the fp.' Changing your mind part-way through responding to the event does not signify
the start of a new Functional Process. It is what you do after you have finished the current
Functional Process that starts a new one.
The points in this C-Reg case where such decisions are possible are very few, but actually very
common in real-life systems. An example might be in entry of data to a life assurance system
where in a Functional Process to establish a new life assurance policy, having entered the data
about the applicant's sex, different paths must be followed on entering medical history
depending on whether the applicant is male or female. But these different paths do not indicate
the start of a new Functional Process.
41
4. COSMIC-FFP MEASUREMENT PROCEDURE – Step 2
4.1 JUSTIFICATION FOR STEP 2
As outlined in section 1.3, Step 2 of this Case Study shows the measurement results of
Step 1 modified by a further assumption about the requirements of section 2.2, namely
that any practical system would require separate functions to enquire on Professors,
Students and Schedules.
The authors of this Case Study then adopt the viewpoint of an experienced functional
size measurement expert and conclude the following consequences for the effects of
making this assumption about the requirements and of applying a COSMIC-FFP Rule1
given in the ‘Measurement Manual’, v2.2:
a) In the requirements given in section 2.2, each of the Use Cases for modifying
and deleting Professors, Students and Schedules begins with the sub-processes
needed to retrieve the particular data that the user wishes to modify or delete.
Naturally, a user cannot carry out a modify or delete operation unless he/she first
retrieves the data to be modified or deleted (in the latter case at least for sight
validation that the correct record has been selected for deletion).
b) The functionality needed for the retrieval phase is identical for the modify and
delete Use Cases for each of these three objects of interest, so it is identified
twice in measuring the functional size in the Step 1 analysis of the requirements.
An experienced functional size measurer would say ‘you should really include
this functionality only once in the size measurement, not once for every time it
happens to be written down in the requirements’.
c) This same retrieval functionality is basically identical to that which would be
needed for any separate enquiry functions on Professors, Students and Schedules
that could be called independently, e.g. from the menus (if these enquiries had
been specified in the Requirements).
d) Therefore, if a separate functional process (e.g. ‘Enquire on Professor’) is to be
included in the size measurement, the equivalent identical retrieve functionality
should be removed from the ‘Modify Professor’ and ‘Delete Professor’ Use
Cases. Otherwise, the same functionality would be included three times in the
size measurement.
1
The Rule on “Read and Write Data Movements in ‘Update’ Functional Processes” says that ‘most
commonly’ a retrieve-before-update is a separate functional process from the update functional process in
on-line business application software.
42
e) The effect of such a change in the way the Requirements are interpreted is that
there are now three functional processes, each triggered by entirely separate
triggering events. From the user’s viewpoint, these are:
‘I want to retrieve data about a given Professor’ (after which I might
continue to modify or delete the data, or move on to another enquiry, or
stop altogether)’
‘I want to modify the data I have just retrieved’
‘I want to delete the data I have just retrieved’
f) The same arguments apply for a Student and for a Schedule.
4.2 CONSEQUENCES OF STEP 2 FOR THE FUNCTIONAL SIZE
MEASUREMENT
The three functional processes for a Professor, as defined in Section 4.1 e), can be sized
as follows.
No
3
ID
Process
description
2.2.1 Enquire on a
Professor
Triggering
Event
Select the
“enquire on
a Professor"
Sub-process
Description
Registrar enters
Professor ID
Data
Group
Professor
ID
The system
retrieves the
Professor
information
The system
displays the
Professor
information
Display error
message
Professor
data
The Registrar
enters the
modified
Professor data
The system
updates the
Professor
information
Display error
message
Professor
data
Professor
data
Message
Data Mvt.
Tot.
Cfsu
type
Cfsu
E
1
R
1
X
1
X
1
4
Modify a
Professor
Registrar
decides to
“modify a
Professor"
Professor
data
Message
E
1
W
1
X
1
3
Delete a
Professor
Registrar
decides to
“delete a
Professor"
Registrar enters Professor
the delete
ID
command for
the selected
E
1
43
Professor
The system
prompts the
Registrar to
confirm the
deletion
The Registrar
confirms the
deletion
System
prompt
command
Professor
ID
Professor is
Professor
deleted from the data
system
Display error
Message
message
n/a (not a
data group 0
movement)
n/a
(repetition
of Delete
Entry
above)
0
W
1
X
1
3
10
Total functional size in Cfsu of the three functional processes
It can be seen that the two Use Cases to modify and delete a Professor sized in Step 1 as
12 Cfsu have been replaced in Step 2 by three functional processes of total size 10 Cfsu.
The reduction in size is the result of eliminating the retrieval functionality which was
included twice in Step 1.
Similarly, when the two Use Cases of Step 1 to modify and delete a Student are replaced
by the three functional processes to enquire on, modify and delete a Student in Step 2,
the total functional size is also reduced from 12 to 10 Cfsu.
The corresponding change for replacing the two Use Cases ‘Modify Schedule’ and
‘Delete Schedule’ of Step 1 by the three functional processes ‘Enquire on Schedule’,
‘Modify Schedule’ and ‘Delete Schedule’ results in a similar change of functional size in
spite of the greater complexity of these Use Cases. The Step 2 analysis is given below.
No
10
ID
Process
Descripti
on
Triggering
Event
5.2. Enquire Select the
2.1 on a
"enquire
Schedule on a
schedule"
Data movement
Description
Data
Group
Student enters
‘enquire on a
schedule’ command
‘Enquire
on a
schedule’
command
Schedule
item data
The system retrieves
the Student’s current
schedule
The system displays
Schedule
the Student’s current
item data
schedule
Display error message Messages
Data
Mvt.
Type
Cfsu
E
1
R
1
X
1
X
1
Tot.
Cfsu
4
44
Modify a Student
Schedule decides to
‘modify a
schedule’
Student enters ‘modify Start
schedule’
modify
schedule
command
The system requests
Course
and receives available offering
course offerings from data
the Course Catalog for
the current semester
Display the course
Course
offering data
offering
data
The student enters the Schedule
modifications to his
item data
Schedule item(s) and
submits them to the CReg system
The system verifies
Course
with the Course
data
Catalog system what
pre-requisites are
needed
The system verifies
Schedule
that the Student has
history
the necessary
record
prerequisites
Validated Schedule
Schedule
items are returned to
item data
the Course Catalog so
that it can maintain the
student count for each
course
The Course Catalog
system verifies that the
course offering is still
open and that there are
less than 10 students
registered
Schedule items are
Schedule
marked as "enrolled
item data
in" in the Student’s
schedule and are made
persistent in the C-Reg
system
Student may choose to Schedule
save a schedule
item data
without submitting it
by selecting "save"
Schedule items are
Schedule
E
1
1xX
1xE
2
X
1
E
1
1xX
1xE
2
R
1
X
1
(N/A)
0
W
1
E
1
W
1
45
marked as "selected"
item data
in the schedule and it
is saved
Display error message Messages
X
1
13
Delete a Student
Schedule decides to
"delete
schedule"
The student enters the
deletions for selected
item(s)
Schedule
item data
The system prompts
the Student to verify
the deletion
The student confirms
the deletion
System
Prompt
Command
Schedule
item data
The system updates
the student’s schedule
The system sends the
deleted schedule items
to the Course Catalog
system so that the
latter can update the
number of students
enrolled for each
course
Display error message
Schedule
item data
Schedule
item data
Messages
E
1
N/A
0
N/A
(Repeat
0
of Entry
above)
W
1
X
1
X
1
Total functional size in Cfsu of the three functional processes
4
21
It can be seen that the two Use Cases to modify and delete a Schedule sized in Step 1 as
23 Cfsu have been replaced in Step 2 by three functional processes of total size 21 Cfsu.
The reduction in size is the result of eliminating the retrieval functionality which was
included twice in Step 1.
(It could be argued that the ‘Save Schedule’ Use Case in the Requirements which says
that ‘[At any point], the Student may choose to save a schedule without submitting it by
selecting "save", and which must apply to the ‘Create Schedule’ and ‘Modify Schedule’ Use
Cases, should also be included in the size measurement only once. The authors of this Case
Study have assumed that this ‘Save Schedule’ functionality cannot result from a separate
triggering event decision by the Student, and that it occurs as an optional branch in both the
‘Create Schedule’ and ‘Modify Schedule’ functional processes, and should therefore be included
in the functional size of both of these functional processes. The general teaching point is that
functionality that occurs in multiple functional processes should be identified only once if that
functionality can be separately triggered and hence identified as a separate functional process.)
Overall, therefore, the reduction in size from Step 1 to Step 2 through introducing the
separate enquiry functional processes and eliminating the duplicated retrieval
46
functionality in the modify and delete Use Cases for these three objects of interest is 2 +
2 + 2 = 6 Cfsu.
The total size of these requirements following the analysis of Step 2 is therefore 100
Cfsu.
47