Sie sind auf Seite 1von 6

Instructions for the Software Requirements Specification Document

Team Project
CSCI 3250 (Software Engineering I)
I.

Introduction
A.
Purpose
B.
Scope of the System Specified
C.
Definitions, Acronyms, and Abbreviations
D.
References to Supporting Documents
F.
Overview of rest of SRS
II.
General Description
A.
Product Perspective
B.
Product Functions
C.
User Characteristics
D.
General Constraints
E.
Assumptions and Dependencies
III.
Functional Requirements
IV.
Non-functional Requirements
V.
System Architecture
VI.
System Models
VII. Appendices
===========================================
I.

Introduction
A.
Purpose - identify the purpose of this SRS and its intended audience
B.
Scope of the System Specified - describe the origin of the need for this
system; explain what the software product(s) will, and, if necessary, will
not do; describe the customers goals for the proposed system.
C.
Definitions, Acronyms, and Abbreviations - Provide the definitions of
all terms, acronyms, and abbreviations required to properly interpret the
SRS. This information may be provided by reference to an appendix or
other document(s).
D.
References to Supporting Documents
E.
Overview of rest of SRS - describe the rest of the SRS and how it is
organized.

II.

General Description
A.
Product Perspective - describe the relationship of software to its
environment (i.e., the softwares interface). For example, if the product is
independent and totally self-contained, it should be stated here. If the SRS
defines a product that is a component of a larger system or project,
describe how it interacts with rest of system.

B.

C.
D.

E.

Product Functions - provide a summary of all the functions of the software. The
functions should be organized in a way that makes the list of functions
understandable to the customer or to anyone else reading the document for the
first time.
User Characteristics - provide general characteristics of eventual users (for
example, educational background, amount of product training)
General Constraints - express such things as host hardware limitations,
interfaces, and implementation language requirements. Provide a general
description of any other items that will limit the developer's options for
designing the system.
Assumptions and Dependencies - List and describe each of the factors
that affect the requirements stated in the SRS. These factors are not
design constraints on the software but any changes to them can affect the
requirements in the SRS. For example, an assumption might be that a
specific operating system will be available on the hardware designated for
the software product. If, in fact, the operating system is not available, the
SRS would then have to change.

III.
Functional Requirements
The functional requirements are going to be written in narrative form identified with numbers.
Each requirement is something that the system SHALL do. Thus, it has a common name of a
shall list. You may provide a brief design rationale for any requirement which you feel requires
explanation for how and/or why the requirement was derived.
IV.
Non-functional Requirements
The same format as the functional requirements is to be used for the non-functional
requirements. You may provide a brief design rationale for any requirement which you feel
requires explanation for how and/or why the requirement was derived.
V.
System Architecture
This section presents a high-level overview of the anticipated system architecture using a class
diagram. It shows the fundamental objects/classes that must be modeled with the system to
satisfy its requirements. Each class on the diagram must include the attributes related to the class.
All the relationships between classes and their multiplicity must be shown on the class diagram.
The classes specified in this document only are those directly derived from the application
domain. The class diagram must be developed using the Jude software.
VI. System Model
This section presents the use case diagram for the system under development. The use case
diagram should be a complete version containing all the use cases needed to describe the
functionality to be developed..
VII.

Appendices

Appendix A. Data dictionary


Completely defined entries for all of the actors and use cases in the use case diagram.

Partially defined entries for all the classes in the class diagram. The fields for the name,
description, attributes, and relationships must be completed on the data dictionary form of
each class in the class diagram for the SRS document. The data dictionary forms for the
classes in the class diagram will be completed for the design document (i.e., the field for the
methods).
Completely defined entries for all of the attributes in the class diagram.
Appendix B. Raw use case point analysis
This appendix contains the actor summary table and use case summary table for the raw use case
point analysis for use case diagram. The templates for the summary tables are provided.
Appendix C. Screens and reports with navigation matrix
This appendix contains the screens and reports with their navigation matrix for each use case in
the use case diagram. An example of the screens/reports with their navigation matrix is provided.
Appendix D. Scenario analysis tables
This appendix contains the scenario analysis table for each use case in the use case diagram. The
template for scenario analysis table is provided.
Appendix E. Screens/reports list
This appendix contains the screens/reports list for all the use cases in the use case diagram. The
template for the screens/reports list is provided.
Appendix F (and following). Anything that is needed by the reader of this document for
understanding or further explanation.

Grading Criteria
Software Requirements Specification Document
1. Lateness of deliverable:
1 day late 20 points
2 days late 40 points
3 days late 80 points
After 3 days late a zero grade is recorded.
2. Correctness and Format (100 points total):
The SRS is graded using the following point distribution. The grading criteria for each
section of the SRS has been previously defined in the grading criteria for the individual
SRS homework assignments.
a. Cover Page, Revision History, and Table of Contents 5 points
b. Section I Introduction 5 points
c. Section II General Description 10 points
d. Section III Functional Requirements 20 points
e. Section IV Non-Functional Requirements 5 points
f. Section V System Architecture 5 points
g. Section VI System Model 10 points
h. Appendices (40 points)
i. A Data Dictionary (20 points)
ii. B Raw Use Case Point Analysis (5 points)
iii. C Screens and Reports with Navigation Matrix (10 points)
iv. D. Scenario Analysis Tables (5 points)
i. E. Screen and Reports Lists (5 points)
ii.

3.

Section I, II, III, and IV are grading using the writing criteria for the points possible in
those sections.

WRITTEN DOCUMENT ASSESSMENT RUBRIC

CONTENT/RESEARCH

Does Not
Meet
Expectations

Meets
Expectations

Exceeds
Expectations

Breadth/Scope
Student use of domain specific information.
Student uses complete and specific requirements.

Quality
Student uses legitimate requirement descriptions.
Student uses well formed requirement descriptions.

Documentation
All sources cited (if needed).
All documentation included.

ANALYSIS
Analyzes quality/relevance of data/sources.
Is able to identify key information/data from sources to include in
document.
Builds an adequate description (evidence of inductive thinking).
Student identifies audience/groups.
Student appropriately targets level and needs of audience.

ORGANIZATION

Introduction
Introduces structure of document to reader via appropriate mechanism
(e.g., abstract, table of contents, outline).
Introduces topic of document.
Addresses/explains significance of topic.
Introduces content/structure of document.

Body/Content
Relevance inclusion of key information/data.
Correctness adequate presentation of current and correct
information/data.
Appropriate use of graphical information/data (e.g., charts).
Succinct presentation of information.

Synthesis
Makes connections between ideas/facts/data to definition of
requirements.
Develops theme of requirements specification.
Demonstrates appropriate/logical sequence of ideas/facts/data.
Clarity of requirements ideas/arguments.
Derives logical conclusions based on information/data gathered
(evidence of deductive thinking).
Conclusion
Summarizes key points/facts/data.

Das könnte Ihnen auch gefallen