For each project in this course you'll use a different development process. Waterfall, iterative prototyping, unified software process or test driven development. But it'll your team's job to specify the exact form, by defining appropriate process activities. However for each project you will be responsible for producing at least the following documents. Process plan. Requirements document, design document, test plan, user documentation, code and process assessment document.
Over the course of this lesson, you'll complete several tasks related to designing and creating a small Java program. The goal of this project is to learn how to collect and record detailed requirements, and implement a solid piece of software that meets those requirements. For this project you should construct your program using a Waterfall method or a slight variation. This is a group project with the same group and using the same GIT Hub repository as assignment three. This time you should definitely collaborate and coordinate with your group members.
Gathering requirements is one of the most difficult tasks a software engineer faces. In industry, you may gather requirements from end users, external clients, or from co-workers in other areas of your own company. Occasionally, you may receive a well documented set of requirements. However, in most cases, you will need to glean the requirements from conversations with the prospective clients, and distill them down into something actionable on your own. Suppose a teacher came to you with a request for a piece of software their students could use to find out the average length of the sentences in their essays. What questions come into mind to help you figure out the full requirements for this project. Write down a list of at least ten questions that might help you determine them. Please take the time to do this before moving on. There's no penalty for looking ahead, but if you skip this exercise you'll cheat yourself out of the benefits of brainstorming and getting your mind around the project before being bombarded by more information.
Now that you've written some of your own questions, consider the following three. Which is the most likely to be useful for determining the detailed requirements? Maybe, what OSes should it run on? Or maybe, how will the user specify input? Or finally, how many lines of code should it take?
The last question is almost never a reasonable one. For one thing, the client should not need to know or care about how many lines of code make up the program's source code. In forming requirements, you should avoid implementation specific questions that do not directly interface with the user. The first question is very relevant in some situations. For example, a graphic sentence with video game or performance is key. However, you should not write any operating system specific code unless absolutely needed, and should strive to make your code platform independent whenever possible. The second question, however, is very relevant. Now that you've thought a bit about what you might ask of the client requesting this program, let's watch Alvin, one of Udasea's engineers, asking his own questions. He'll be speaking with Lauren, the client.
Hi, I'm Lauren.
You've heard Alvin come up with several conclusions for how to set up the program. And we're going to ask that you follow his instincts. We'll spell that out here in a little more technical details so that everyone is working from the same basic starting point. The program must be written in Java and must not make use of any nonstandard Java libraries. You will be tested on a machine with the vanilla installation of Java 1.6. Your program must compile on the command line using the Java C command without any additional options. All code required to execute the program that is not part of the standard JDK, must be included as source code with your program. Your program should be an application. That is, it should have a main method and should be executable from the command line using the Java command. The user should be able to provide a file path to the file they wish to be analyzed as a command line argument. User should be able to specify which delimiters count as sentence separators, using the flag -d, defaulting to Lauren's initial thoughts on what should be used as delimiters. The user should be able to specify a lower limit for word length, using the flag -l, defaulting to Lauren's guess at what value might be good. Finally, the program's output should be the average sentence length. Rounded down to the nearest integer.