SRS and Prototype Grading Rubric, Rev1
Team:
Team CAN Do (GWAY)
Project: Generic Ethernet Gateway Project
SRS (100 points): 93.5
Prototype v1 (25 points) : 23
SRS Contents (80 points)
1.
2.
Introduction
Overview of SRS subsections
Introduction of topics
1.1 Purpose
Purpose of SRS
Intended Audience
1.2 Scope
SW products to be produced
Benefits of SW
Objectives of SW
Application domain
What SW will do
What SW will not do
Consistent with Customer Spec
1.3 Definitions, acronyms, and abbreviations
All terms define
1.4 Organization
Describe the rest of the SRS
Give organizational structure of SRS
Overall Description
Overview of this section
2.1 Product Perspective
Context for the product
Pictorial representation of bigger system
Complete description of product specified
Describe how product fits
Constraints
2.2 Product Functions
Major functions
All functionality specified by customer
Diagram high-level goals
2.3 User Characteristics
User expectations
2.4 Constraints
All constraints specified
English descriptions safety critical properties
English descriptions other properties
2.5 Assumptions and Dependencies
All assumptions documented
All dependencies documented
2.6 Approportioning of Requirements
Requirements outside scope of project
80
75
10
SRS is structured well, defines scope,
intended audience, etc.
10
10
10
Good description overall.
SRS and Prototype Grading Rubric, Rev1
3.
4.
Specific requirements
Requirements logically ordered
Hierarchy when appropriate
Hierarchy easy to understand
No conflicting requirements
No ambiguous or implicit requirements
Testable requirements
Clearly, concisely, and unambiguously
stated requirements
No unnecessary design or implementation
detail
Modeling Requirements
4.1 Use case diagrams
Every goal should be addressed
Each goal is satisfied by one or more use
cases
Each use case refers to one or more
requirements
4.2 Class diagram
4.3 Representative scenarios of system
English description
Use instances of class names from class
diagram
Sequence diagram
Objects are instances of classes in class
diagram
4.4 State diagram for key classes that participate
in scenarios
Scenarios validated state diagram
All events, actions modeled in class
diagram
Variables are attributes in class diagram
20
20
Requirements clear and concise. I would suggest if
timer values (and other similar values) are known,
to add them into the next revision.
20
15
Use case model:
- Should the Diagnostics, Awake, and Sleep be
connected to the Gateway use case?
- Awake and Sleep are non-essential? Essential
nodes are non-primary?
- CAN Node use case should be retitled to convey
what the description means (perhaps Flash CAN
Node)
Domain model:
- When inherited classes, don’t need to retype the
methods/parameters (as they are included through
inheritance, unless otherwise noted)
- Use of term ‘db’ without definition (class IO)
- Majority of operations in class diagram missing
parameters and return types as specified in data
dictionary
(Enable/DisableCANPort,OnPowerManagement,
etc.)
- ‘void’ is implied, but the rest are not
- Class IO is missing ‘Dispatcher’ attribute
- Voltage should probably be a float in
PowerManagement, unless if you’re scaling it in
some manner
- ‘Dispatcher’ term in Communications element of
data dictionary not referenced before
- ‘Bridge’ term in CAN element not referenced
Sequence diagram:
- You reference ‘Bridge’ object, however it is not
seen in Figure 4.3.1, 4.3.3
- 4.3.5 – first time IO is referenced as I/O (be
consistent with your terminology)
5.
Prototype
Describe what prototype shows of system
functionality
5.1 How to Run Prototype
Describe what is needed
15
15
SRS and Prototype Grading Rubric, Rev1
6.
System configuration
5.2 Sample Scenarios
Provide a sample scenario with real data
Screen shots
Screen shots explained
References
List of all documents referenced
Sources where references can be obtained
Link to website
SRS Writing (20 points):
Paragraph Structure
Thesis sentence
Body supports thesis sentence
Grammar errors
Terms / acronyms used before definition
Terms and concepts used consistently
5
5
20
18.5
10
10
5
2.5
2.5
3
2.0
2.0
SRS and Prototype Grading Rubric, Rev1
Prototype V1 (25 points):
Convey requirements
Ease of use to
understand intended
behavior
Presentation
(legibility,
organization, etc.)
25
23
Gets the basic functionality across. As this
is all about providing a gateway, one of
your biggest concerns will be message
timing. Ensure that you provide some
method for handling this concern.
Interface makes sense, with a nice graphic
of the overall system.
10
9
5
5
Nice layout of the overall system. One
suggestion that I have is to perhaps turn
your logging section into a fixed-height
box that automatically scrolls (shows the
latest message). Otherwise, if the user
will be required to scroll to the bottom of
the page each time he/she presses a
button.
10
9.5
Also, I would probably center the text in
your green boxes, it looks kind of odd at
present.
-0.5
Spelling error on
‘interaction’ (second
sentence).
SRS Total:
116.5 / 125
Prototype
Accessible via web application
100
Nice layout of the overall system. One suggestion 20
that I have is to perhaps turn your logging section
into a fixed-height box that automatically scrolls
(shows the latest message). Otherwise, if the
user will be required to scroll to the bottom of
the page each time he/she presses a button.
100
20
SRS and Prototype Grading Rubric, Rev1
Also, I would probably center the text in your
green boxes, it looks kind of odd at present.
Demonstrate at least 5 scenarios
of usage
For each scenario:
Support user input
Graphical depiction of system
response
Scenarios are representative of
key requirements
Prototype Total:
50
50
30
30
100