Inf 43: Introduction to Software Engineering

Fall Quarter, 2015
Homework 1: Requirements Specification

Due Date: Thursday, October 22, 2015, 11:55pm (via EEE)

For your homework 1 you will specify the requirements for PrivatePractice, an Electronic Medical Record (EMR) system for maintaining the patient records of a small, privately owned hospital. Irvine General, a startup based in Irvine, CA, is commissioning you to develop this system. PrivatePractice will store information about a patient’s visit to the hospital, including details like symptoms/ailments, procedures/tests ordered, prescriptions, etc. It should also be able to generate invoices for each patient visit.

The purpose of this assignment is to learn how to write a fairly complete and precise requirements specification, which is a critical step in developing a large software system. Completing this assignment will give you experience in one of the most interesting and difficult software engineering tasks.

This assignment is to write a software requirements document for the PrivatePractice system. The details of the requirements should be elicited by client interviews with your Teaching Assistant in meetings on October 8, 13, and 15 (subject to change). He will act as customer.

The deliverable is an electronic copy due via EEE by Thursday, October 22, 2015, at 11:55pm. Submit it to the dropbox titled “Homework 1 F15.” NO LATE SUBMISSIONS WILL BE ACCEPTED. As a rough guideline, the final document should be between 5 and 15 pages long.

We provide a template Word document with which you should start. Your requirements specification should contain all of the sections contained in this template.

Scoring

The scoring criteria are outlined on the scoring sheet, which should be the first page of the document you turn in. Throughout the document we will be looking for:

• 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. Bulleted and numbered lists can be used, with restraint, and not as a substitute for complete sentences and readable prose.
• 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 approval. When in doubt, ask the Teaching Assistant – but only for clarification purposes (no new requirements).
• 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.
• Verifiability. 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.