Skip to main content

22.02.21 - Specifications

Specifications (vs Requirements)​

User requirements : Client managers, contractor managers System Specification: Software developments

What specifications are like​

  • Focus on WHAT should be built - but not necessarily how
  • Specifying: What a system will do to meet the user requirements
  • Specifications should be tied to a requirement

Specs - Natural Language​

  • Can be expensive, intuitive and universal, but may be ambiguous, vague and interpreted differently.
  • Guidelines
    1. Use a standard format
    2. Distinguish between mandatory and desirable
    3. Emphasis important elements with bold, italic
    4. Avoid jargon, unless clearly specified in a key words section
    5. make sure the specification is measurable is some form

Specs - Structured​

Go further than natural language specifications, to tabulate specifications, or put them in templates Can be used to specify additional information

Specs - Graphical​

UML Models, diagrams, prototypes. Often easier to see a UML sequence diagram When complex, visualise them

Good specification​

Analysing the quality of specifications is also important Good quality specifications have a few qualities

Specs - Traceability​

All specifications can be traced to user requirements. In reports, should for every specification. To have implemented a single spec, want to know you achieved what is specified

Specification reviews​

Formal review process Each person takes a - to systematically review the specifications:

  • Validity checks
  • Consistency checks
  • Completeness checks
  • Realism checks
  • Verifiability checks

What [else] happens to specs​

Go onto prototypes.

Prototype combines​

  • The graphical specs - UML models
  • Textual spec

To demonstrate how they might work together in a system Like specs help to validate requirements