The first step of the project is to produce a software requirements specification (SRS) for the software system that you described in your project propsoal. In this document, recall that your perspective is squarely in the problem domain (aka application domain).
Requirements
Your SRS must contain at least two sections: an "introduction" that describes your application domain and the problems that your system will address once it is implemented and a "requirements section" that documents the features of your proposed system using a number of the techniques discussed in class.
For the introduction section, you may follow the outline for an SRS that is given on page 197 in software engineering textbook, or use it only as a checklist for the types of issues that you should address when creating your SRS. (In other words, I'm not mandating a specific format that you must follow when creating your SRS other than it having the two sections listed above.) Think of this section as your “project proposal on steroids.” Finally in this section, be sure to include a subsection that identifies your team members and how your team divided the work of creating the SRS among themselves.
The requirements section should contain at a minimum, the following items:
- a textual list of functional requirements and/or use cases
- a data flow diagram that identifies the prominent types of information used by your system and how that information is produced, manipulated, and stored.
- a UML class diagram that documents the core concepts of your application domain and the relationships between those concepts.
- a set of FSP specifications and structure diagrams that document the concurrent behaviors expected of your final system. If the finite state machines associated with your FSP specifications are small enough to be graphed by the LTSA tool, please include their diagrams in your document. If LTSA indicates a problem with any of your specifications (deadlock, progress, etc.) be sure to highlight this and discuss how you plan to address those problems as you move forward with the design and implementation of your system.
- a list of any non-functional concerns you intend to address while designing and/or implementing your system.
A team is free to use any of the notations / specification techniques covered in class, if needed, in addition to the ones specifically requested above.
Individual Participation
25 points of this assignment is based on an evaluation of your work and participation by your other team members. Once the SRS has been submitted, each team member should mail Professor Anderson an evaluation of the participation and work performed by the other team members. If all of your team members give you a “thumbs up,” you will receive all 25 points for this portion of the assignment. Otherwise, you will receive a percentage of the 25 points based on the positive/negative reviews that you received.
Note: If team members indicate that a student did nothing for this portion of the project, that student is in danger of losing more than just the 25 points allocated to individual participation.
Points and Due Dates
This assignment is worth up to 150 points, depending on the score you receive for individual participation.
Please submit your SRS as a PDF document to the moodle by 11:55 PM on Tuesday, April 1st. (Note: Since some CAETE students are working with in-class students on this project, I am not intending on having a separate due date for CAETE students on this assignment. CAETE students working on their own, please contact me if you'd like to have your due date extended by one week as usual.)
You may also create your SRS as a set of HTML pages. If so, you should submit a small text file to the moodle that contains the URL of the "home page" of your SRS.
Contact Professor Anderson if you have any questions or concerns about this assignment.