2.5 The Use Cases in Detail

advertisement
Evaluation of Specifications
Deliverable III
October 18, 2001
Project Group 22
Authors:
Belete Ayele Asfaw
beletea@student.matnat.uio.no
Mihail Korabelnikov
mihailk@student.matnat.uio.no
Juma Hermed Lungo
jumal@ifi.uio.no
Miria Grisot
miriag@ifi.uio.no
Jose L. Nhampossa
leopoldo@ifi.uio.no
Ou Weiqing
ouw@student.matnat.uio.no
Johnny Nordvik
johnnyno@student.matnat.uio.no
Project Group 22
Deliverable III
CONTENTS
CONTENTS ..................................................................................................................... I
1 EVALUATION DOCUMENT AS CUSTOMERS FOR DUTS .............................................1
1.1 ACTORS .....................................................................................................................1
1.2 OVERALL EVALUATION OF THE USE CASE MODEL ...................................................1
1.3 THE USE CASES IN DETAIL........................................................................................1
1.4 THE CONNECTION BETWEEN THE USE CASES ............................................................2
2 EVALUATION DOCUMENT AS CONSULTANTS FOR SCATS .......................................3
2.1 MINUTES OF MEETING WITH CUSTOMERS .................................................................3
2.2 OTHER PROBLEMS .....................................................................................................3
2.3 ACTORS .....................................................................................................................3
2.4 OVERALL EVALUATION OF THE USE CASE MODEL ...................................................3
2.5 THE USE CASES IN DETAIL........................................................................................3
2.5.1 Use Case 1, EmployeeRegistration ........................................................................... 3
2.5.2 Use Case 2, ProductRegistration .............................................................................. 4
2.5.3 Use Case 3, SalesRegistration................................................................................... 4
2.5.4 Use Case 4, CustomerRegistration............................................................................ 4
2.5.5 Use Case 5, SalesStatistics ........................................................................................ 4
2.5.6 Use Case 6, UpdateInformation ................................................................................ 4
2.5.7 Use Case 6, SystemOutput ......................................................................................... 4
2.6 CONNECTION BETWEEN THE USE CASES ...................................................................4
533580317
(in219p22)
Page i
Project Group 22
Deliverable III
1Evaluation Document as Customers for DUTS
We found that the consultants have understood the requirements, regardless the absence of
definition of priority of functionality in the system.
1.1 Actors
We did not find any missing actors relevant to the User Requirements for DUTS. The actors
are clearly defined.
By comparing the Use Case Model to the Use Case description we found that there is a
logical linkage between the actors involved in the specific Use Cases and the descriptions of
the Use Cases.
The expected input and output is defined in an appropriate level of details.
1.2 Overall Evaluation of the Use Case Model
No behaviors of the system described in the User Requirements of DUTS are missing in the
Use Case Diagram presented by consultants in the document Software Requirements
Specification of DUTS. We found no missing Use Cases as well.
Basically there is no need for extending any of the Use Cases defined.
1.3 The Use Cases in Detail
Use Case
description
It is clear which
activities the
actor must
perform to
accomplish his
objective.
The alternatives
to normal event
flow are
documented.
Trigger is
described in a
necessary level of
detail.
Logon the system
(Nurse)
Yes
Yes
Yes
Delete the request for
duty.
Yes
Yes
Yes
Display all
unconfirmed duties.
No
No
Yes
Change the request
for duty.
Yes
Yes
Yes
Register new request
for duty
Yes
Yes
Yes
Check the status of
Yes
Yes
Yes
Evaluation Document
Page 1
Project Group 22
Deliverable III
the duty
Display all
information of
applies.
No
No
No
Logon the system
(Manager)
Yes
Yes
Yes
Enter user
information
Yes
Yes
Yes
Access user
information
Yes
Yes
Yes
Remove user
information
Yes
Yes
Yes
Check statistic
information of
employee
Yes
Yes
Yes
Request a report of
status of all nurses
Yes
Yes
Yes
Access the request
No
No
No
Analyze the request
for duty
No
No
Yes
Reject request
Yes
No
Yes
Add message to
request
No
No
No
Accept request
Yes
No
Yes
Store data in text
format
No
No
No
Logon the system
(system adm.)
Yes
Yes
Yes
Register a new user
Yes
Yes
Yes
1.4 The connection between the Use Cases
All Use Cases are described in a low level of detail, thus difficult to identify any conflicts
between the behaviors described in the different Use Cases. In terms of descriptions of the
Use Cases they have almost the same level of detail, which is quite abstract.
Evaluation Document
Page 2
Project Group 22
Deliverable III
2 Evaluation Document as Consultants for SCATS
2.1 Minutes of Meeting with Customers
Minutes 18.October. Participants:
Developers: Leopoldo, Johnnyno
Customers: Patrickr, Gertrum, Culpa
Walk trough of the Software Requirements Specification (SRS) document. Comments from
this walk trough: Use Case for login into the system is missing. To be included in next
version of the SRS document.
2.2 Other Problems
When designing the UCD we were not sure about the system architecture. This resulted in a
wrong Use Case identification, (SystemStatistics).
2.3 Actors
Every actors involved in the Use Case Model are defined, and is it clear for us which actors
that acts in the different Use Cases.
The descriptions of how the system interacts with the actors are not consistent with the
description of the actor. I.e. in the description of the Sales Manager, it is not described that
this person is able to register new customers or get a system output. The description of the
Sales Person are missing actions on update information in the system, customer registration
and system output.
Not all the expected input and output described in the Use Cases is clearly defined.
2.4 Overall Evaluation of the Use Case Model
After a detailed analysis of the two models we found that changes should be introduced in
both. The changes are related to the need of removing the Sales Statistics Use Case from
UCD and the corresponding class from DM.
2.5 The Use Cases in Detail
2.5.1 Use Case 1, EmployeeRegistration
The description of this Use Case is clear. Both legal and illegal event flow are defined. There
are no Non-verifiable words in this Use Case. The event flow is described in a measurable
concrete language. The pre- and post conditions can be tested.
Evaluation Document
Page 3
Project Group 22
Deliverable III
2.5.2Use Case 2, ProductRegistration
The description of this Use Case is not clear and must be changed. Both legal and illegal
event flow are defined. There are no Non-verifiable words in this Use Case. The event flow is
not described in a measurable concrete language. The pre- and post conditions can be tested.
2.5.3 Use Case 3, SalesRegistration
The description of this Use Case is not complete. The Sales Manager is also an actor in this
Use Case. Both legal and illegal event flow are defined. There are no Non-verifiable words in
this Use Case. The event flow is described in a measurable concrete language. The pre- and
post conditions can be tested.
2.5.4 Use Case 4, CustomerRegistration
The description of this Use Case is clear. Both legal and illegal event flow are defined. There
are no Non-verifiable words in this Use Case. The event flow is described in a measurable
concrete language. The pre- and post conditions can be tested.
2.5.5 Use Case 5, SalesStatistics
To be removed.
2.5.6 Use Case 6, UpdateInformation
The description of this Use Case is clear. The illegal event flow is not clear defined. There are
no Non-verifiable words in this Use Case. The event flow is described in a measurable
concrete language. The pre- and post conditions can be tested.
2.5.7 Use Case 6, SystemOutput
The description of this Use Case is clear. Both legal and illegal event flow are defined. There
are no Non-verifiable words in this Use Case. The event flow is described in a measurable
concrete language. The pre- and post conditions can be tested.
2.6 Connection between the Use Cases
Include relation are not in use between the Use Cases. The pre- and post condition do not
match for all of them. The conditions mach for example between the Use Cases
ProductRegistration and SalesRegistration.
Evaluation Document
Page 4
Download