Requirements are the Software

What does it really take to convert requirements into working software? I think the trick is getting the requirements right; if you do not understand the requirements, no matter what skill/technology you master, your effort goes to trash. The best way is asking for clarifications and getting a clear picture of what the user or customer really wants the software to do!, do not say ‘yes/ok’ to everything without really understanding. Sometimes this can test your patience but you should at all costs know what the requirements are. The customer asks for apple and you give him oranges, do you still expect him to come back to you?
Always make sure you:-
  • Get the requirements right (not the right requirements!) thats called customer facing.
  • Design for ‘the given’ requirements. Create a Model.
  • Code for ‘the’ design.
  • Test the code ‘within the’ system.
  • And take responsibility for your code!
Remember that quality has to be caused not controlled!
Here are 3 golden questions in software development that should tinkle in our heads all the time, it does in my head for sure :-
  1. Why are we buiding this software?
  2. What should this software do?
  3. How do we develop it?

All about Design


I happened to read following in a blog.

    • The appearance of the device must provide the critical clues required for its proper operation – knowledge has to be both in the head and in the world.
    • What makes design a highly challenging and rewarding discipline is that it grapples with the need  to accommodate apparently conflicting requirements. All great designs have an appropriate balance and harmony of aesthetic beauty, reliability and safety, usability, cost and functionality.
    • Art and beauty play essential roles in our lives.  Technology changes rapidly, people change slowly.
    • Humans do not always err, but they do when the things they use are badly conceived and designed.
    • The psychology of everyday things demonstrate the importance of visibility, appropriate clues and feedback of one’s actions.
    • Affordance refers to the perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used.  For instance, a round object is assumed to have an affordance of a ball.

      Something that happens right after an action appears to be caused by that action.

      Two fundamental principles of designing for people are : 1. provide a good conceptual model and 2. make things visible.

    • Good designs have good mappings between the controls and the things controlled by them. For instance, the "next" button on a screen/wizard should be either on the right or bottom of the screen and not on the top left.
    • Errors should be easy to detect, they should have minimal consequences, and, if possible, their effects should be reversible.  Errors can sometimes be prevented by using forcing functions.
    • Designers can use three methods to prevent users get into an erroneous state:
      1. Intelocks – by forcing operations to occur in a particular order
      2. Lockin – by keeping an operation active, preventing someone from prematurely stopping it
      3. Lockout – by preventing someone from entering an erroneous state
    • Ask the following seven design questions while designing – How easily can one:
      1. Determine the function of the device?
      2. Tell what actions are possible?
      3. Determine mapping from intention to physical movement?
      4. Perform the action?
      5. Tell if system is in desired state?
      6. Determine mapping from system state to interpretation?
      7. Tell what state the system is in?

real good insight for those stuck in design web!

Sounds cool…