Software Requirements Specification
CSA348, Spring 2007
Your first assignment (really first few assignments since part of it contains analysis information) is to work on the Software Requirements Specification (SRS). This is arguably the most important step you will be taking since if the requirements are wrong none of the rest of the steps matter.
A good place to learn about the SRS is the IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. You can find it in the Course Documents section of myMiami. You'll be working with a variant of the SRS format described in that document.
The first step in writing an SRS is determining what your customer (who, for the purposes of this project would be your instructor) wants. In some projects, like big defense contracts, the customer will provide a detailed document providing all their requirements. If such a document is available, you would then elaborate on those requirements in your SRS. The requirements in your SRS would trace back to the customer's requirements.
In other projects, you might start with something much more vague and you would need to elicit information from the customer to fill in the gaps and find out what it is they really want.
On this project, you'll be working with a partial set of requirements given in the Project Description linked to on the course home page.
An outline for the SRS for this project has been posted under Course Documents on MyMiami. Part of this document will be developed as your Analysis deliverable.
The SRS will be broken up into three assignments:
Due September 12, 3pm: Software Requirements
The requirements for the system. This will include the use cases as well as a numbered list of requirements. This will include the following sections of the outline:
Section 1 - all
Section 2: 2.1, 2.2, 2.3.1 (and 2.3.1.x ...)
This is not a trivial task. One recommendation is that you start with the Use Case Model - the reason you would build use cases in the first place is to tease out the requirements. Then, after you think you've captured the major functionality of the system, extract out the individual requirements into Section 2.1. Keep referring to the Project Description to make sure that you have everything covered. You will want to go through it multiple times. There may be requirements that are unclear or incomplete - part of your mission (assignment) is to work with your client (Dr. Burge) to fill in those gaps and to clarify anything that is not clear. Mind reading is not a recommended strategy. Remember - your goal is to work with the client to determine what they want your system to do.
How do you know if you found all the requirements? Talk to your client! Show her what you have and ask what is missing! This is a collaborative process.
A grading rubric will also be posted on myMiami along with the SRS outline. That may also provide some additional information about what is going to be expected. It does NOT say what the requirements are that you should have or how many use cases there are - figuring those things out is part of the assignment!
Due September 21, 3pm: User Interface Prototype
This will be Section 2.4. More details will be provided on this assignment after the first one is complete.
This will complete the document. For this assignment, you will be creating the Object Model (an analysis level class diagram), a statechart diagram for one class of your choice (choose one with state behavior), and sequence diagrams for the following use cases (there will be one sequence diagram per use case): 1. View Schedule; 2. Schedule Activity (this should include computing if the schedule they entered meets their fitness goals) 3. View Trainee Statistics; 4. Add Exerciser.
See the SRS outline for more details.