IEEE 830 University of Maryland Software Requirements Specification Paper
Description
Having Trouble Meeting Your Deadline?
Get your assignment on IEEE 830 University of Maryland Software Requirements Specification Paper completed on time. avoid delay and – ORDER NOW
Normally you gather requirements through interviews and reviews with stakeholders. From these interviews and reviews you gain an understanding of what the software needs to do. Then you clearly, unambiguously document it in a requirements format. It is a little hard in a classroom setting to provide stakeholders. So in this exercise you will be provided a finished software product. You can learn how the software works. This will allow you to gain an understanding of what the software does.
In this assignment you will use the same software you selected for your Use Case Project, however you will use a different set of features to document. Select a different 8 features to document. These must be high-level features like those in the example shown in §3. For example, 3.1 in the example, “Order Meals” is a high-level requirement.
Typically the IEEE 830 format uses a functional decomposition approach to requirements. Read the IEEE 830 Recommended Practice for SRS document to get more information.
Rubric is as discussed in the Syllabus & Additions
Note that the example document is incomplete. You’re just being shown enough of the document to get an idea. If you’re going to copy something, copy the template.
Also note that “Process Impact”, “Cafeteria”, and “corporate approved” pertain specifically to this sample. These terms had better not appear in any of your work for this project or for project 4 unless (a) you’re dealing with the Process Impact company, (b) doing something involved with a cafeteria, or (c) are dealing with a large corporation with an approval process.
And another example:
Here’s how I’d do IEEE 830 requirements for a light-switch:
| 5.1 | Lightswitch | ||
| 5.1.1 | Narrative | ||
| This function allows the user to turn a light on and off using a switch. | |||
| 5.1.2 | Stimulus/Response pairs | ||
| Stimulus: | The user flips the lightswitch to the Up position. | ||
| Response: | The light illuminates. | ||
| Stimulus: | The user flips the lightswitch to the Down position. | ||
| Response: | The light goes out. | ||
| 5.1.3 | Functional Requirements | ||
| REQ-1.1 | Upon the user flipping the lightswitch to the Up position, the light shall illuminate. | ||
| REQ-1.2 | Upon the user flipping the lightswitch to the Down position, the light shall go out. | ||
| REQ-1.3 | The light shall run on 115VAC, and is permitted to draw up to 50W of power. | ||
| REQ-1.4 | The light socket shall permit rapid replacement of the bulb, without the need for tools. | ||
Note that in the functional requirements, the first 2 requirements match the 2 stimulus/response pairs. There is a 1:1 correspondence between the stimulus/response pairs. I did not say “the system allows the user to control the light.”. I instead described how the system allows the user to control the light. Following those requirements, I added some additional requirements. Not all such sections will have such additional requirements, but some may.
