Assignment Requirements

  1. The normal agreed upon Software Engineering process starts with a Software Requirements Document (SRD) produced by a combination of people from both the business and development sides of the organization. This SRD is then turned over to development where a technical specifications document (Spec) is created, usually by a senior engineer with knowledge of the whole product and the implementation details. This Spec is then turned over to both the developer and the tester at the same time so test plans and test scenarios can be written at the same time the coding is taking place. Of course this is an ideal world scenario and rarely will you find such well defined phases and roles in practice. This is especially true with the programming assignments you are tasked with in the CMIS curriculum. During the beginning CMIS courses you will function mainly as the coder in this process; however, as you progress in the CMIS curriculum you will slowly take on more and more responsibilities throughout the entire process in a single assignment. Hopefully, by the time you finish the CMIS curriculum you will have been exposed to all the phases. In the following paragraphs I try to outline the process I use in developing assignments. Please keep in mind that the detail I place in an assignment is based on both the level of the course and the desired outcome (goals) I am looking for in the assignment. A generalization of the process would be: CMIS 1XX - very detailed and direct with little expectations of creativity; CMIS 2XX - about a 50-50 mix of detail and more general terms that allow for student creativity and application; CMIS 3XX and CMIS 4XX - about a 25-75 mix of detail and more general terms that allow for student creativity and application.
  2. Writing a requirements document for a software program is extremely difficult at best and maybe even impossible. When I write up an assignment what in effect I am doing is writing a requirements document that must be interpreted the same way by every individual in the class. This itself is a daunting task but is compounded in the online class world by the lack of visual and verbal feedback. I have no way of knowing if all of the students or none of the students understand what is being ask of them. Because of these I break the established Software Engineering practices of Requirements to Specifications to Code to Test to Maintenance and actually do a general specification and coding/testing first to determine if the intended requirements fit into the expected or intended abilities of the students. After I have finished the coding and testing then I write the requirements based on the finished product. This way I can ensure none of the requirements must be coded using techniques or skills beyond what is expected of the student.
  3. In the programming for money world, the requirements document is gospel and must be followed as written and agreed upon. In academia the assignment is the requirements document and must be followed. If you are not clear on an item or requirement it is incumbent on you to use the associated Conference to ask for clarification. This is a normal process in the 'agreed upon' phase of the requirements document.
  4. Requirements are written in varying degree of detail which implies varying styles of implementation. For example:
  5. I am grading against fulfillment of the requirements. The criteria I use to grade your assignments are two-fold.