1. An aspect of the preferred process for almost all formal software development approaches is to do some design before coding. One of the design artifacts you are asked to use in this course is a flow chart. What challenges have you (and / or your learning team) encountered in going from an English statement of the problem to a flow chart (or some
other design tool, like pseudo code)? What challenges have you encountered in going from your chosen design artifact to C source code?
2. While writing source code may be the activity that first comes to mind when people think about software development, it's only a piece of what goes on. While there are IT jokes about this (e.g., "You go figure out what the users want while I start coding"), mature software
organizations realize this is better humor than practice. Requirements definition and design are two activities that are logically prior to implementation. What do you think goes into a good requirements document?
1. Sometimes a business process is simple. You can sit down at your PC and knock the whole flowchart out in a single sitting. But often flow charts are more complex than that, and they require collaboration with colleagues - spanning organizations, departments, and process expertise levels. The typical way to collaborate on a flowchart is to map out the processes on a white board. This is OK, but can be messy and time consuming as you erase and re-draw to fine-tune the process flow diagram. After you are ready to develop your code in C, you may start questioning yourself by looking at flowchart, When 2 connection arrows cross over each other, it can be very difficult to tell what the intention is. Can the reader safety assume that each connection arrow continues ...
Traits of a good requirements document are featured.