Importance of building a prototype

It is important to build a prototype to:

  • Clarify and confirm the desired requirements for the system
  • Obtain feedback from potential users
    • What they like
    • What they don’t like
    • Any additional features they may desire
  • Check that the proposed system is feasible
  • Explore options for optimising the qualitative requirements

Approaches to prototyping

Throwaway approach

  • Quick and dirty
  • Often uses mockups rather than fully functional programs

Evolutionary Approach

  • Good for experimentation but also use in the final product
  • “meet potential prototype”
    • Has the potential to meet the quality of the final product
    • Just one more iteration and it’ll be perfect
    • Give me fire, Give me liberty, Give me runaway prototype, or I retire

Prototyping is good for answering questions about the interface, wheras modelling is good for answering questions regarding the constraints on what order events should occur or activity synchronisation.

Validation and Verification

Requirement validation is important to ensure that the requirements definition accurately reflects the customer’s needs.

Verification ensures that a system is built well, wheras validation ensures the correct systme was built.

Techniques

  • Prototypes
  • Enacting scenarios
  • Inspecting documentation
  • Reviewing and comparing stated goals and system objectives
  • Reviewing the environment
  • Assesing the risks
  • Checking how requirements will be tested
  • Quality checks
  • Formal proofs
  • Ensure each requirement in the definition document is traceable to the specification
  • Computer-aided verification methods such as model checking or using a theorem prover

Measuring Requirements

Measurements can focus on the product, process and resources.
The number of requirements can give an indicator to the size of the developed system
If the requirmeents are changing often or have changed a lot then it can be an indication to a lack of understanding of the system.

1/5

  • You understand this requirement completely
  • Have designed systems for similar requirements
  • Have no trouble developing a design for this system

2/5

  • Some elements of this requirement are new
  • However, these are not radically different from others that have been successfully designed in the past

3/5

  • Some parts of this requirement differ greatly from previous requirements
  • However, you understand it and can develop a good design from it

4/5

  • You cannot understand some parts of the requirement
  • You aren’t sure a good design can be developed

5/5

  • You do not understand this requirement at all
  • Cannot develop a design

The majority of requirements should score 1/5 or be revised.

Criteria for evaluating specification methods

  • Applicability
  • Implementability
  • Testability/Simulation
  • Checkability
  • Maintainability
  • Modularity
  • Level of abstraction
  • Soundness
  • Verifiability
  • Run time safety
  • Tool maturity
  • Looseness
  • Learning curve
  • Technique maturity
  • Data modelling
  • Discipline