The first assignment is to write a software requirements document for the Schocr system. The details of the requirements should be elicited by interviews with Yang Wang in section meetings on October 12, 15, 17, 19, and 22 (subject to change, listen for announcements in section meetings). He will act as customer and user.

The deliverables are an electronic file and a printed copy of your requirements specification. The two must match exactly. The electronic file must be in Microsoft Word format (from Word 97 or later, but not .docx), named Requirements.doc, and submitted via Checkmate before 12:55 pm on Monday, October 29. The final printed version must be turned in at the start of lecture (1:00 pm) on Monday, October 29. The report should be between fifteen and thirty pages long. The pages must be stapled or otherwise bound together.

You will also turn in through Checkmate an electronic copy of a draft of your requirements specification. It is due by Monday, October 22, at 6:00 p.m. Follow the same formating rules as above, but name the draft RequirementsDraft.doc. The draft will not be scored, but it must contain a reasonable first draft of the Introduction, User Requirements Definition, Implementation Phases, and Future Directions sections. If the draft is not turned in on time or does not indicate significant effort, up to 10 points will be taken off your homework 1 score.

Your requirements specification should contain the following sections, in the order given:
           Scoring Sheet.
           Title Page.
           Table of Contents, with page numbers.

1. Introduction. Introduce both the system and the document. The Introduction describes the need for the system, gives a concise overview of its functions, and explains the role it plays in the organization. The Introduction also outlines the document's organization.
2. User Requirements Definition. This section's audience is the non-technical customer and user. It should address the goals of the system and why it is needed. Describe the major features of the system and the rationale for each. Identify and describe other software, processes, hardware, people, and policies that the system may or will affect. List in this section any assumptions made about the existing world. (Assumptions that may be revised in the future should also be addressed in the "Expected Changes" section.)
3. System Requirements Specification. Describe the functional requirements of the system in precise detail. When possible, identify the entities (components, sections, areas of functionality) that make up the system. Characterize the properties, states, functions, and interrelationships of each entity. Since this section is the core of the requirements document, it warrants its own brief introduction. Make sure this section is carefully organized.
4. Constraints and Non-functional Requirements. Discuss constraints pertaining to speed, space, safety, portability, robustness, implementation bias, operating environment, etc. Your audience here are the system designers and programmers, who will probably not be in direct communication with the users. This section will help them assess trade-offs in the system's implementation.
5. Implementation Phases. If applicable, and following the request of the customer, identify one or more subsets of the system's functionality which can or will be implemented first.
6. Future Directions and Expected Changes. If applicable, identify other goals or features which are not addressed elsewhere in the requirements document. Again, you are providing insight and guidance to the system designers and programmers.
7. Acceptance Test Plan. Describe a procedure for testing the system to determine whether it adheres to the requirements, both functional and non-functional. Define several scenarios and sequences of tests. You do not need to provide a test case for every item of functionality, but you should provide a completely worked out instance or two.
8. Glossary. Define all terms or jargon used in the document which have a special meaning in the AutoMenu system.

Grading

• Adherence to the stated structure. Carefully follow the structure defined above.
• Clarity of writing. You should write your document in clear, precise, business-like English prose, avoiding jargon, humor, and wordiness. Correct spelling and correct grammar are essential. Avoid acronyms; common ones should be defined when first used and should appear in the Glossary.
• Fidelity to customer's desires. It is important that your document be true to the requirements stated by the customer. Don't add or remove requirements without the customer's OK. When in doubt, ask Arijit!
• Completeness. Your document should address all aspect of system functionality and constraints which are important to the user.
• Consistency. Your document will contain many detailed requirements. Careful thought is necessary to ensure that no subtle contradictions are introduced.
• Testability. State detailed requirements in a manner that facilitates determining whether they are met in the final implementation.
• Avoiding implementation bias. Focus on "what" not "how".
• Modularity and separation of concerns. Try to divide each section into subsections or paragraphs which are largely independent of each other. Ideally, each requirement or feature is discussed in its entirety in one place. Separate UI elements from the functionality to which they pertain.