Project 1 - Questions and Answers

A. Hornof - January, 2020

This document includes questions from students, and answers from the instructor. New entries are added at the top.


January 17, 2020


Where can I find the IEEE standards that are referenced in the SRS and SDS template documents?

See the references provided at the end of those documents. To access those links, you might need to be on a UO network (or tunneling in using the Cisco AnyConnect VPN Software)


My group wanted a clarification on the requirements for the SRS.

In the SRS requirements, it says: "Both functional and non-functional requirements should be split between absolutely required and not absolutely required requirements."

Does this mean that we can chose which requirements we think are absolutely required?

For example, in your SRS example you list 5 use cases: A B C D and E. Do we chose a subset of these to implement?

I.E. if we think A B and D are essential to implement, can we list C and E as "not absolutely required?"

In short, the answers to your questions regarding the SRS are "yes". The SRS provided to you for Project 1 is intended as an initial SRS from a client, a sort of request-for-proposals, that you can respond to with revisions, including specifying which use-cases you intend to support.

I want to say a little more, something like this: Please keep in mind that these Use Cases (and the entire SRS) are written based on real-world experience, and a rationale for excluding some of the proposed requirements should not be simply that that the developers somehow those requirements were less important, or not needed. In general, when writing a proposal, you want to be "responsive to the solicitation".


We could use a little clarity on the differences between the "Build Plan", "Work Breakdown" and" Project Schedule" as needed for the Initial Project Plan. We keep making things that are very similar. What's the key feature for each of those to focus on?

I believe that this is how these terms are being used:

The Build Plan is the intended schedule for integrating code, such as code for different modules written by different team members.

The Work Breakdown Schedule identifies major project activities that need to be accomplished, and when each will be conducted.

The Project Schedule builds on the Work Breakdown Schedule, and gets into more detail, such as with assignments to team members. It might also decompose the major project activities into smaller subtasks.

A note: You should try to keep the last two of these up-to-date based on the current project situation as the project progresses, and to save a copy of each plan (with the date it was created) before you update it. This permits everyone to review how the project progressed, and also helps you to learn things so that the next time you create a project schedule, you can "call the shot"more accurately.


I have a question about the "usability requirements" section of the SRS.

Are these the minimum requirements for the program to be usable? Or the requirements on the user's end (such as software downloaded, etc...) to run the program?

Usability requirements would likely include both of what you list, as well as anything else that relates directly to whether real users can successfully use the system to accomplish real-world tasks in real-world situations. One challenge in writing such usability (and other kinds of) requirements is that requirements should be objectively verifiable and precise. That is to say, a human tester with a certain skill level could objectively determine whether the system meets each requirement. And a majority of such testers would readily agree whether each requirement was met.

For usability, this means that ideal requirements will define things like how, with a specified set of preparation and training, a certain class of users would be able to accomplish well-defined specified tasks with a specified level of speed and a specified level of accuracy.


For citing sources, what is the standard we should follow? Looking at your examples under the References section of the SRS Template, I am unsure what standard you using to cite your sources. Is it APA? Would you like us to follow the citing standard you utilize or is it acceptable to use a citation standard I am more familiar with (such as MLA 8)?

You can use any established standard that you want. I use APA, even though it is not typically used in computer science, because an inline reference that reads "Card, Moran, and Newell (1983)" is infinitely more informative than "[21]".


I had some questions about requirement analysis and writing the SRS for project 1. We were a bit unsure and there weren't any project specifications or instructions beyond the SRS and evaluation criteria as far as I could tell.

My group's understanding of the project is that we should, by this Friday, create an SRS (along with a project plan and SDS) that is based directly on but not necessarily equivalent to the one provided by you. In detail, we would select and categorize requirements from the provided SRS, then write our own SRS from scratch.

Did we understand this correctly, or are we to directly use/adapt the provided SRS and its text?

I think your group's understanding is correct except that there is no need to write the SRS from scratch. You can take lots of text directly from the SRS provided, but just be sure to provide clear attribution.

I understand that the mechanics of providing the attribution can get messy if you have lots and lots of quoted text, but it would nonetheless be useful to a client (such as me) to be able to clearly see what text was derived from the solicitation. By solicitation, I mean a document that a company distributes to potential vendors describing a project to be completed. It is also known as an RFP, or request for a proposal. This is sort of the role of the SRS that I provided. It would be useful to a client to see how a potential vendor is directly including, versus modifying, aspects of the RFP.


I'm curious how expectations might differ for evaluation of our Cold-Call System project depending on the language we choose for implementation? Last Friday you visited our group and encouraged/suggested we choose C given that we all evaluated ourselves as strong in C. If it were up to me alone -- which it obviously is not, as our group is making the decision collectively -- I would not choose C for this project due to the burden of manually implementing basic elements such as lists and hash maps and managing memory without any obvious reason to do it other than if we were incapable or otherwise restricted from using a higher-level language such as Python. It seems like an unnecessary burden to take that on without any obvious/noticeable benefit in terms of performance or user-experience. Can you share any thoughts on this?

I would be impressed if any group were to do this project in C. It would require a slightly different way of thinking about things, not just how the final system would work, but how to divide the work and manage risks (such as the potential for memory management problems).

I do not at all just grade projects based on how slick of a product was produced. I fully understand that some software tools make it relatively easy to produce slick products.

Please note that C is largely under-rated language among novices. For example, in terms of "obvious/noticeable benefit in terms of performance or user-experience", a program in C would be many, such as the code would much more likely run in 10 years. (This is because the ISO standards for C are locked down, pretty much permanently. Python libraries change monthly.) Many students do not appreciate this because they have yet not tried to run software they wrote 10 years ago.

If your group chooses to use C, please actively pursue highly reputable resources for honing your C skills. For example, you should all have copies of Kernighan & Ritchie (1988) C Programming Language.

(BTW, I would recommend C++ over C, but experience with just C would be great.)



Upon reviewing the "Template-SRS" on the class webpage, our group noticed a few sections that we were unsure about. Namely, section 3.2 is a summary of "Functions", and we were wondering if touching on this was a requirement for our own SRS. Since we haven't written the majority of our code yet, we found it difficult to begin tackling this portion.

I recall in class you mentioning that our SRS does not need to follow the template exactly, but I wanted to reach out and clarify. Our primary effort is to make sure we touch on each bullet-point in the grading rubric for the project.

No, it is not essential that you write something for Section 3.2 Functions. Though I don't think this is necessarily asking for the specific functions you would write in your code, such as
     retrieve_data()
          {...}
but rather asking for a more abstract description of distinguishable sets of services that the system would provide. Such as
     A means of retrieving data that
          1. confirms all data are in ASCII format.
          2. loads and checks one file at a time, in alphabetical order.
          ...


My group was discussing which language to use today. We noticed that you allow the import of Cocoa when using the C/C++ languages. When looking into the capabilities of Cocoa, we discovered a Python library called PyCocoa. This appears to have similar capabilities as the objective-c version of Cocoa.

In 8.3 Programming restraints, you mention that we can use Cocoa in C/C++, but we can only use pyHook in Python. Due to the similarities between Cocoa and PyCocoa, would it be possible for our group to use PyCocoa as an additional library for a python implementation?

We're interested if this would satisfy your requirements.

Please do not import packages into Python beyond what is in the official python documentation. Part of the reason for asking you to do this is that script programming (such as in python) has largely become a process of just searching the internet for some package that some random person has written to do some random thing. I am trying to encourage students to establish mastery, in this case mastery of the core python language and packages.