Software Design Process

Design Steps (Think, Design, Code)

  1. Brainstorm about what the application/system will do

  2. Write down some goals

  3. Develop some requirements
    Requirements are very hard to write. Requirements are "what to do" rather than "how to do" something.

  4. Develop a preliminary design
    Do not code yet. Design on paper. For example:
    • what data is available
    • what data is output
    • what data structures to use

  5. Prototype to make sure you understand how to do things
    This allows you to test ideas about how to do things, especially things that you have never done before. Prototyping may show that you need to change the design or even the requirements.

  6. Code the design
    Do not change the design while coding unless absolutely forced to (You can change the design later). It is better to have something that works rather than something that is constantly changing that never works.

    Do not code the whole thing at once. Break the project down into small tasks that can be coded and tested. This will test your code, and validate your design. This may also cause you to change the design if something is very wrong.

Shall vs Will in Requirements

From the IEEE style manual Section 5, para 13.1.

The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted ("shall" equals "is required to"). The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations. The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).

The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).

The word can is used for statements of possibility and capability, whether material, physical, or causal ("can" equals "is able to").

For example:

  1. The system shall respond to errors by displaying an error message to the user.
  2. The system will have default values for user input where appropriate.

Note: Don't go crazy. Fewer requirements are better than more.