The University of Queensland Homepage
School of ITEE ITEE Main Website

 Untitled

As you hopefully should be aware from having reviewed it, Group Assignment 2's SRS is not a good example to follow.

Here is a list of some of the defects we would like to make sure you have seen.  (This list is not a comprehensive "Inspection Report" – it is a list of defects that if you didn't see them in your own inspections, then we want to point them out to you.)

 

Page No.

Location within page

Para

Defect Description

All

All Use Case Diagrams

 

Use case diagrams are all incorrect:
1. unidirectional arrow to use case
2. diagram does not specify the actor ( the use case descriptions say "Course Coordinator" etc, but diagrams just say "User")
3. diagram shows each step as a use case (effectively looks like it has been sequentially decomposed)
4. system actors are not shown
5. use case label should be infinitive case (eg "modify user constraints" not "modifies the user constraints")

38, 39

Activity diagrams

 

Branches and guards have been shown as activities (eg "time period available && allocation not exceeded")

4

Class Diagram

 

Class diagram is incorrect:
1. Cardinality problems (between TeamSpace and Room)
2. Circular aggregation relationship (TeamSpace, Room, Non-Interactive Terminal)
3. Reverse aggregation between CardReader and TeamSpace
4. Directionality of associations are not necessary between Booking and Room, and Allocation and Room
5. Unclear whether this is a design or an analysis diagram:  Terminals are shown as part of the class diagram for the software system, but no software requirements are given for them in the document.  (Unclear whether these are in our out of scope of the booking system)
6. Uses <<interface>> and <<implements>> which implies that it is a design diagram, even though it is in an SRS

27-30

2.2.4.4 to 2.2.4.6

 

Use cases for "Groups" in courses are gold plating.  The proposal does not actually require groups to be managed as an entity in the system, and the groups that are created in these use cases are not used in any of the other use cases – eg, in Create Private Booking the only way of selecting group members is by entering them manually.

6, 36

1.5.6, 2.2.5.5

 

XML requirement is gold plating

6

1.5.5

 

ANSI SQL is gold plating

41

2.2.8

 

1,500,000,000 record requirement is unrealistically excessive

9

2.2.10.2

 

Required uptime of 170 hrs/week is more hours than there are in a week!

42

2.2.9

1

99.999% uptime is gold plating

4

1.8

 

Paragraph 7 is gold plating (remote auditing, metrics, historical performance data)

43

2.2.13.1

 

Requirement of a virtual machine is gold plating

41

1.4

 

Requires terminal to be OLED, requires pedestal – both of these are gold plating

41

2.2.9

4

Automatic window tinting system is gold plating

26

2.2.4.3

 

Delete allocation use case has "main flow" of Modify allocation use case

29

2.2.4.6

 

"Remove Group from Course" but step 3 deletes the course not the group

34

2.2.5.3

 

Main flow is missing a step to archive the data!  Alternate flow 4b does not correlate to 4 in main flow.

5

1.5.1

 

MySINet is not listed in the System interfaces, but is required from a constraint in 1.8

21

2.2.3.4

 

Users can delete any booking in the system (including other people's, course coordinators, etc.)

42

2.2.10.1

 

Specifies minimum system downtime in case of failure ("no less than 3 days")

 

 

 

Deliverables/products/outcomes of the project are not described anywhere in the document.  (ie, the software to be installed.)  Scope section describes scope of document, not scope of project.

3

1.3

 

Refers to information in an appendix that doesn't exist

8,9

1.8

3

Paragraphs 1 to 4 do not belong in an SRS -- they are constraining the developer not the system, and saying "where conflicts occur, ITEE policy takes precedence" (so can the developer believe the SRS?  It's definitely not self-contained)

22

2.2.3.5 or 2.2.4.1

 

There is a requirement in 1.3 (Overview) that admin staff can book the entire TeamSpace for regular slots, but it is not clear that either 2.2.3.5 or 2.2.4.1 allow this (regular repeating timeslot)

7

1.6

 

Roles and privileges are ill-defined: lacks a concrete description such as a table; inconsistent in that sometimes talks about conferring roles sometimes about confering privileges.  Vague text such as "In some resepects, Course Administrators function as a ..." but in WHAT respects?

39

Activity diagram

 

There is no activity described where "group booking" (condition on a guard) can be set

40

Activity diagram

 

There is no path for if the modified duration cannot be accepted (room's not available that long)

40

Activity diagram

 

There is no path for if the modified number of rooms cannot be accepted (the other rooms are not available)