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: |
|
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: |
|
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) |
