Lecture 2

Software Design Lec 2

Development process

  • Requirement
  • Design
  • Implement
  • Test
  • Maintain

Software Development process DOES NOT mean programming.

Programming is only one stage of the development process.

Requirements Gathering stages (WHAT)

  • What are you solving?
  • Who is using the product?
  • Talking to people and asking questions.
  • Communication.

Design Stage (HOW)

  • Software design is the process through which problem specifications are transformed into a plan to build the software.
  • This is the stage where choices are made – How are you going to solve the problem.
  • Spending time and producing a quality software design speeds up the implementation and leads to better software.


  • Programming
  • Checking for errors

Testing Stage

  • In this stage you test the requirements
  • Devise Test cases
  • Validate
  • Verify

Installation and Maintenance Stage

  • Installation
  • Boxed production?
  • Installed for the client on their system
  • Maintenance

Course Focus

  • Requirement
  • Design


  • Given a task A set of requirements
  • What are requirements? A set of operations the software must perform; What the client wants the software to do.
  • Only this term?
  • Measured in centimeters or inches?
  • Registered for the course or physically present?
  • Requirements gather is difficult
  • Balance competing requirements
  • Design can not be created without the requirements.

Examples of requirements

  • We need and SQL database
  • We need a system to organize inventory
  • Run under windows OS
  • Must be able to generate daily reports
  • Must be able to handle 100 transactions per second
  • Must run on our existing computer system
  • Make it as cheap as possible.
  • We will want demos during development every two weeks
  • We need some software to solve our problems
  • Must be usable by someone with a grade six education
  • Must implement all current legal expectations for this type of system
  • Must use the most modern security available

Requirements Example

A system analyst was asked to develop a computer system to store different forms in a database. The office that managed the forms was having a lot of trouble keeping track of the different forms. The forms were all similar and were being filed in the wrong places or lost.


  • Build the system they want
  • Colour the forms so they cannot be mistaken (this was the chosen solution)

Requirements Document:

  • An official statement of the system requirements
  • For the clients and users
  • For the developers
  • Other names: functional specifications; requirements definitions; software requirements specifications
  • How should it be written?

The top 10 requirements guidelines:

  • Define a standard documents structure
  • Readers will become familiar with the format and know how to use it
  • Acts as a checklist for the writer so they don’t accidentally omit something
  • Software templates can be developed to help format the document
  • Make the document easy to change
  • Writing, reviewing, and distributing new documents is expensive and time consuming
  • If the cost of making changes is too high, then changes may be collected and applied in a batch. This means the document can be out of date while the changes wait to be applied
  • Online versions of the documents can lessen the effects of these problems.
  • Uniquely identify each requirement
  • Give each requirement a unique number
  • They can be referenced through the number in the document
  • The number can be used to show which requirements have created other requirements.
  • Define policies for requirements management
  • Explicitly tell people what they are expected to do and why it is done
  • Define template for requirements description
  • They make the requirement easier to read once the reader understands the format
  • They make gathering and writing easier because they provide a checklist of things to include.
  • This is similar to a standard document structure but it deals with individual requirements only.
  • Use simple language
  • Simple language is easier to read and understand
  • Be consistent in your description. If you give a name to something, then use the same name all the time
  • Short sentences are easier to understand. Use one idea per sentence.
  • Organize requirements inspections
  • A group of people should meet and systematically check for problems in the requirements document.
  • The requirements engineer (system analyst) presents each requirement.
  • The group comments about the problems or concerns
  • The comments are recorded so the problems can be addressed later
  • Define a validation checklist
  • This helps the people validating the requirements identify if something is incorrect
  • Sample questions included
  • Are the requirements complete
  • Do you understand what the requirements all mean?
  • Are they ambiguous
  • Are there any contradictions
  • User checklist of requirements problems
  • Identify problems which you have experienced in the past and look for them
  • Design choices being listed as required
  • Combining two requirements into one
  • Are there unnecessary requirements
  • Is it an ambiguous requirement?
  • Plan for conflicts and their solutions
  • Requirements – committees
  • If requirements are produced by committee then no one is individually responsible for them
  • They tend to be excessive and impractical
  • The are a whish list instead of a realistic set of objective
  • Requirements bloat – it occurs when too many requirements are specified
  • Requirements creep – it occurs when the users of developers want to add new requirements which appear to be cleaver or useful
  • A few high level objectives must be specified and all later requirements must directly support them.

Note Created by
Is this note helpful?
Give kudos to your peers!
Wanna make this note your own?
Fork this Note