Waterfall Methodology

Requirements document

  • Analysis: User needs → specifications
  • Design: Decomposition into elements that can be developed separately → specifications of each element
  • Coding: Programming of each element separately (+ isolated tests)
  • Integration: The elements are put together and the complete system is tested
  • Maintenance: Occasional changes (errors or improvements).


Rapid prototypes

  • Just to gain experience
  • The code does not reject
  • They are used for the design analysis phases

Evolutionary prototypes

  • The code is rejected
  • Cyclic process of cascade model
  • In each round the prototype is improved until reaching a complete system.

Software Specification

System model concept

  • The model specifies WHAT the system does without specifying HOW it does it
  • Different techniques can be used
    • Decomposition in subsystems
    • Modification of an existing model
    • Domain analysis → study environment, terminology, similar systems.

Requirements analysis

  • Objective → obtain the software specifications (build the model)
  • Phases
    • Study of the system in context: SW system is part of a complex system (SW + HW + mechanics + …..) → study of all other systems + study of the domain
    • Identification of needs: interaction with the client → real needs
    • Establishment of the system model
      • Hierarchical development → division into subsystems + development of each subsystem
      • Ends with a requirements specification document

Different possible notations for the specification

  • Natural language → for very simple systems or as a complement to others
  • Data flow diagrams (DFD) → model the processing of data in the system
  • State transition diagrams (DTE) → model system dynamics
  • Data dictionary → model the data

Software Design


  • Tell how the system will do what it has to do.
  • Ends with an architectural design document and a detailed design document.


  • Architectural design
    • Structure and organization of the system.
    • Division into subsystems or modules + interfaces between them.
  • Detailed design → development of each module
    • New modules appear, others are grouped or disappear.
    • Define the structure of each module, with its data and associated services.
    • Design the algorithms for the development of each module → it is detailed in pseudocode without reaching a very detailed level (it would be almost coding).
  • Data design → design of the databases associated with the system (if necessary)

Structure diagrams

  • It is one of the many tools for design
  • Proposed by E. Yourdon as a tool for structured design
  • Describe the hierarchy of modules and sub-modules (architectural design)
  • The Yourdon module concept fits into what is a C function

Characteristics that a Module Must Fulfill

Coupling (it must be weak) → it is the interrelation that it has with other modules

  • (Very Strong) By content → access to local data and code (between modules).
  • (Strong) Common → data area common to several modules.
  • (Medium) Control → the modules are passed control signals.
  • (Weak) By reference → the modules are passed data by reference (eg: C struct).
  • (Very Weak) By value → passing data from one module to another (only the ones you need).

Cohesion (must be medium / high) → group related elements in a module

  • (Very Low) casual → no relationship (eg: I take a program of 1000 lines of code, I break it into blocks of 100 lines and I make a module with each block).
  • (Low) Logic → the module contains operations whose execution depends on a parameter (eg: a Calculation function (operation, data) that can make sums or products).
  • (Medium-Low) temporary → the module contains operations that are executed at the same time (eg: system initialization routines).
  • (Media) communication → the module performs different operations that run in “parallel” and that they all operate on the same data set.
  • (Medium-High) sequential → the module performs different operations that are carried out sequentially on the data, so that the output data of an operation is input data for the next.
  • (High) functional → the module performs only one function.

Comprehensibility → simple and understandable functioning (for those who have not designed it).

Adaptability (very difficult) → possibility to change it easily.

Design Document (In the case of modular design)

1. Introduction → overview of the document

  • 1.1. objective
  • 1.2. Ambit
  • 1.3. Definitions, acronyms and abbreviations
  • 1.4. References

2. Overview of the system → overview of the requirements + reference to the requirements specification document.

3. System context → connections with other systems.

  • 3.n. Definition of external interface,

4. System design → description of the upper level of design (architectural design)

  • 4.1. High-level design methodology → description of the methodology used
  • 4.2. Decomposition of the system → system components (modules) and the relationship between them.

5. Design of the components → design of each module.

  • 5.n.0. Identifier of the component.
  • 5.n.1. Type → module.
  • 5.n.2. Objective → justification of the need to exist.
  • 5.n.3. Function → what does it do?
  • 5.n.4. Subordinates → components (modules) what do you use.
  • 5.n.5. Dependencies → components (modules) for which it is used.
  • 5.n.6. Interfaces → rules of interaction with other elements (modules).
  • 5.n.7. Resources.
  • 5.n.8. References.
  • 5.n.9. Process → algorithms (defined with pseudocode).
  • N 5.n.10. Data → internal data used by the component (module).

6. Feasibility and estimated resources → to carry out the system.

7. Matrix requirements / components.

Development Proposal for Small Systems

Specification (Analysis)

  • Very briefly say what the system does without saying how.
  • In natural language or structured natural language,
  • No software specification document → included in the design document


  • Architectural design
    • Division into modules and the interfaces between them.
    • Reflected in a structure diagram.
  • Detailed design
    • Design of each of the modules.
    • Specified as pseudocode (best) or flowchart.
    • Is reflected in the design document.
  • Coding.
  • Tests.

Design document

  • Brief introduction and overview of the system.
  • Detailed development of system design and components.

Previous post:

Next post: