Software proposal

Software Requirements: <Name of Software>

<Your Name>

*Notes Section (Please Remove from your final paper)

With the progression through each unit, students have worked on the all of the sections of their software requirements document. So, if the student has completed each drop box assignment, all that needs to be done is incorporate instructor feedback, polish the diagrams, ensure diagrams are in the correct format, ensure diagrams use a consistent style (i.e. same color palette), paste the diagrams into the appropriate section, add details to certain sections as needed, and triple check spelling/gramma.

This paper should be 20 pages in length. Please subtract one page for any diagram that is not included in this document – but attached separately in the drop box.

Business Case

*Notes: (please remove from final paper) In this section: Explain the business. Explain the business problems that have necessitated the development of this software. Why is this software needed? What niche will this software fill? Explain how the product will address each of the business problems.

System Development Approach

*Notes: (please remove from final paper). Refer to Chapter 1. There are six development approaches explained in that chapter. Refer to Appendix B as well to learn about the agile approach. Choose the best approach, explain why you chose the approach and explain the other approaches and why you did not choose the other approaches.

System Acquisition Approach

*Notes: (please remove from final paper). Refer to Chapter 2. While a systems analyst might need a unique solution for their particular organization, there are many sources where the analyst can acquire already existing pieces that can be brought together to build their unique solution. There are many acquisition approaches explained in that chapter. Choose the best approach, explain why you chose the approach and explain the other approaches and why you did not choose the other approaches.

Project Plan

*Notes: (please remove from final paper). Refer to Chapter 3. Use MS Project to create a Gantt chart (like the one in Figure 3-11 or the one in Figure 4-19) and a Network Diagram (similar to the diagram in Figure 3-14). If the chart/diagram will fit on the page clearly, paste the chart/diagram in this document. If the chart/diagram is too large to be seen clearly, then write “See attachment <attachment name>”. If the chart/diagram is not included in this document – then assume that these take up two pages. The Gantt chart should contain at least seven main tasks with several tasks listed underneath. Your grade on this section will depend on how the tasks are organized, related, and how dependencies and co-requisites are shown. MS Project is the best way to illustrate the plan. The instructor is looking to see that the student displays a keen understanding of all the tasks in the project and the interdependencies/relationships among those tasks.

Project Scope

*Notes: (please remove from final paper). Refer to Chapter 4, Figure 4-13. The project scope should be similar to the example in figure 4-13.

Feasibility Analysis

*Notes: (please remove from final paper). Refer to Chapter 4. All of the items below should be shown in this section. Chapter 4 provides the details on what should be populated in each Feasibility Analysis section including (Economic, Operational, Technical, Schedule, Legal & Contractual and Political).

Economic

*Notes: (please remove from final paper). See Chapter 4 beginning on page 94. You may use a table to show this information. Be sure to include the: Tangible Benefits, Costs (one-time), Costs (recurring), Intangible Benefits and Costs. The spreadsheet in Figure 4-10 is a good example of what should be included in the Economics area.

Operational

*Notes: (please remove from final paper). See Chapter 4 beginning on page 102

Technical

Schedule

Legal & Contractual

Political

Requirements Gathering

*Notes: (please remove from final paper). Refer to Chapter 5. Requirements gathering techniques include interviews, observations, and obtaining information from organizational documents, as well as Joint Application Design (JAD) and prototyping. Requirements gathering is one of the most important and sometimes overlooked aspects of software development. For this assignment list four techniques along with why the technique was chosen and how the technique will be used Tables 5-1 and 5-2 will be helpful with this. Use Table 5-3 to help define how the Interview technique will be used. Use a high-level of detail in this section as requirements gathering is one of the most important planning tasks, for example if you plan to use the interview method, include the interview questions and the associated audience.

Technique 1:

*Notes: (please remove from final paper).why the technique was chosen and how the technique will be used

Technique 2:

*Notes: (please remove from final paper).why the technique was chosen and how the technique will be used

Technique 3:

*Notes: (please remove from final paper).why the technique was chosen and how the technique will be used

Technique 4:

*Notes: (please remove from final paper).why the technique was chosen and how the technique will be used

Context Diagrams

*Notes: (please remove from final paper). Refer to Chapter 6. Draw two diagrams: a simple context diagram, like the one in Figure 6-5 and then another that expands on the processes, like Figure 6-6 . Please paste the models here.

Use Case

*Notes: (please remove the notes from final paper). Refer to Appendix A. Include at least 4 use case (actions) within your diagram as seen in Figure A-1 and Figure A-2. Please paste the use cases in this section and separate with a heading explaining what the task represents. Please use Visio to create the Use-case diagram.

Dialogue Diagram

*Notes: (please remove the notes from final paper). Refer to Chapter 8. Figure 8-20 illustrates a dialogue diagram. Dialogue diagramming is a formal method for designing and representing human-computer dialogues using box and line diagrams. Only one symbol appears on a dialogue diagram, a box with three sections. Each box corresponds to one display. A dialogue diagram can represent sequence, selection, and iteration; Figure 8–19 illustrates these three concepts. Graphical development environments speed prototype development. Please paste your dialogue diagram in this section. There should be a box in the dialogue diagram to represent every screen, report, form, etc. in your system.

Prototypes

*Notes: (please remove the notes from final paper). Refer to Chapter 8. Prototypes are sometimes referred to as line drawings or wireframes. Paste or draw in this section prototypes of all of the reports, forms, and dialogues. For this section it is very important that the guidelines in chapter 8 for forms, reports and dialogues are incorporated into your prototypes. Refer to Table 8-2 for guidelines on developing forms and reports. Refer to Table 8-14 for guidelines on creating dialogues. See these links for examples of prototypes: