Project 2

CIS 422 Software Methodologies - A. Hornof - February 7, 2022

Due Dates

The 3-Page Proposal

The 3-Page Proposal should include (a) an SRS Concept of Operations (see the SRS template) and a discussion of the real-world users that you could work with to establish the requirements, (b) an SDS system overview, software architecture, and list of technology intended to be used, and (c) a project timeline. Each of these three items must be on a separate page of the proposal. You are not committing to what is in the Proposal. It can (and should) be further developed. The project should evolve. The 3-page proposal should identify a clear initial idea of what your group would like to do.

All writing for this project must follow "Good Writing" as discussed in the course handouts.

Overview

The initial 3-page SRS/SDS/Project Plan should identify a project that is appropriate for the given resources (time and personnel), and that can be decomposed into multiple modules for parallel development. The project should also be one for which realistic requirements can be established by interacting with real potential users of the system who are not CIS students.

Your Requirements Analysis Must be Valid and Sound: Don't Make Stuff Up

Build systems that address real human needs. Do not build systems that rely on your guesses regarding (a) human needs and (b) technology that might help address human needs. Don't make stuff up. Your Concept of Operations, Use Cases, and all other aspects of your SRS must be based on correct and real facts about the world, human needs, and technology.

Assertions require support. There are few ideas that you can state as assertions without providing support. Support usually comes in the form of (a) empirical data (such as through direct observation or user interviews) or (b) citations from reputable newspapers, peer-reviewed journal and conference papers, and technical documentation. But please don't make stuff up.

The "Motivation" section in the Project 1 handout provides an example of how to support the need for a system using peer-reviewed journal articles. (It also uses a reference to popular culture to illustrate a possible use case.)

You Should Build a System for Someone Who is Not You

Please build systems that address real human needs that are not your immediate needs, but are the needs of other people. You can start with the idea that your group arrived a , but then develop it so that the system is intended for different population, not you or your friends.

For example, rather than building a system for what is in your refrigerator and pantry, build a system that could be used to help some users stock, and other  accept food from, a free food pantry, such as discussed in A Fridge for Every Neighborhood, which appeared in the UO Daily Emerald. (If members of your group already uses such food pantries, then find yet another variation on the idea.)  

You should build a system for someone who is not you partly so you can get comfortable talking to users who are not you, and to learn how to "elicit" requirements from those users. We will discuss requirements elicitation in class.

This project requirement probably means that you need to evolve the initial project idea that your group arrived at. I am happy to help you with this.

You Should Build a System that You Cannot Just Download from the Internet

A lot of source code is available on the internet for a lot of projects. Please build something that cannot be downloaded. It is surprisingly easy to generate a new new idea. For example, perhaps you can just take your initial idea and and the phrase "for the disenfranchised" to the end of it, and you have an idea for a system that cannot be downloaded from github.

Design for Installation

Requirements and Design can focus on ease-of-installation by designing for continuous monitoring and reporting of the status of (a) individual components and (b) inter-module connections. For example, you could generate requirements that:

  1. minimize black-box dependencies (don't rely on opaque systems),
  2. require components to continuously report component status and failures,
  3. dictate aspects of the installation process,
  4. specify and plan for testing the installation process,
  5. provide extensive realistic sample data, and
  6. make it easy to see the machine working using all of its functionality.

Technical Requirements

This section presents a minimum set of technical requirements. Your projects should generate many more than just these.

  1. The delivered system should be complete. For example, the system cannot use external servers. If the system will needs a server, the system must include full instructions on how to set up the server locally. The steps involved, and the instructions must be at least as simple as this: MySQL - Using mysqlctl
  2. Systems should use standard libraries to the extent possible. For example, if written in Python, the systems should primarily use the Python Standard Library. Written permission must be obtained to use any libraries or packages beyond the standard libraries for a language.
  3. Installing and running the system should require little or no software to be installed. To this end, no virtual environments, and no gaming engines such as Unity, should need to be installed.
  4. Instructions must be provided to compile, run, and install all of the code necessary to use the system.
  5. Deviations from these requirements should be requested in writing. Cite the approvals in the final submission, such as "Approved in email from Anthony Hornof to Chi Zhu on 10-27-2022."

Project Handouts

How to Comment Your Code
Evaluation Criteria
How to Present
How to Submit
Initial Group Meetings
Instructor Meetings
Peer Evaluation Form (PDF)
SRS & SDS Templates

Miscellaneous Links

NRL Dual Task SRS
System Documentation
UML Notation (Kieras) (PDF)
UML Notation (Fowler) (PDF)