7'1 Supplementary Specification Document

1
Chapter 07 Other Requirements

• 7.1 Supplementary Specification Document
• See separate document this is only a sample
  document
• Any specific functional requirement specific to a
  use case should really be detailed in the
  concerned use case, but all non-functional
  requirements should be in the supplementary
  specification document.
• The supplementary specification is concerned with
  FURPS
• Functional, Usability, Reliability, Performance,
  Supportability
• and the

2

• Take care to review carefully the wording of the
  non-functional requirements
• Permission connectors therefore, clearly,
  it follows that etc.
• Watch out for vagueness sometimes, often,
  mostly etc.
• Lookout for ambiguity processed, eliminated,
  rejected etc.
• Statements that imply certainty always,
  every, all, none, never etc.
• etc.

3

• 7.1.1 Functionalities
• GUI screenshots
• Functionalities that are not easily expressed in
  a use case or cut across many use cases (e.g.
  many complex systems tend to have minimal human
  interfaces or even other device interfaces, but
  that doesn't mean they don't do a lot of work on
  behalf of someone or something)
• Systems that are primarily algorithmic and
  computational in nature (such as
  satellite-tracking, or telecommunication-switching
  ) achieve their results by implementing a variety
  of scientific and other algorithms. In these
  cases you may choose to use mathematical
  expressions, statistical algorithms, and so on to
  represent the majority of the requirements.
• Many applications work behind the scenes, for
  example, in industrial automation and robotics.
  Since these embedded-controls systems primarily
  execute sophisticated logical and control
  algorithms, you may wish to augment the use-case
  model with state machines, sequential logic
  expressions, or other techniques.
• Applications that parse input strings, compile
  code, or translate from one language to another
  may have significant functional requirements that
  are better expressed in other ways.

4

• In these specific cases the supplementary
  specification can contain functional requirements
  not captured by the use cases.
• 7.1.2 Usability
• May include consideration of
• The required training time for the users
• Specify the existence and required features of
  online help systems, wizards, tool tips,
  context-sensitive help, user manuals, and other
  forms of documentation and assistance
• Anything that will made the application more
  usable for all its intended users.
• 7.1.3 Reliability
• Must consider the necessary reliability level
  required for the application e.g. Mean Time
  Between Failures (MTBF) specified in hours.
• Also recovery from failures must be considered
  (e.g. automatic back-up)

5

• 7.1.4 Performance
• To include considerations of
• Response time average, maximum
• Throughput transactions per second
• Capacity the number of customers or transactions
  the system can accommodate
• Degradation modes the acceptable mode of
  operation when the system is overloaded
• 7.1.5 Supportability
• Supportability is the ability of the software to
  be easily modified to accommodate enhancements
  and repairs (i.e. how to facilitate future
  maintenance).
• E.g. Being able to customize the application
  (e.g. new tax rate) without having to write new
  code

6

• 7.1.6
• Other constraints (technical), legal issues,
  localisations, purchased components, licensing,
  interfaces (other than main GUI), installation
  and deployment matters etc.

7

• 7.2 Vision Document
• Can be broken up into, for example
• Introduction
• Business Case
• Stakeholders Descriptions and Goals
• Software Overview
• Summary of Software Features
• The vision document should not be long.
• Example See Separate Vision Document
• A very short introduction.
• Making the business case in important (as is
  evaluating alternatives e.g. other similar
  applications).
• Identifying the end users and researching their
  abilities and needs is important.
• Note the use of a basic, but very useful, System
  Context Diagram

8

• It should summarise some of the information from
  use cases and supplementary specification.
• The Summary of Features is complementary (to use
  cases), terse, way of summarising what will the
  software offer to all users. Not too much details
  is required just a summary of the main
  functionalities as detailed in the use cases
• Note the very terse list of features.

9

• 7.3 Business Rules
• aka Domain rules.
• This section of the specification may contain
  rules (or link to external documents) that are
  specific to the application domain such as
  long-living and spanning rules or policies E.g.
• Rules for a game application (chess, poker rules
  etc.)
• Accounting regulations
• Security regulations
• network protocol specification.

10

• 7.4 Evolutionary Requirements in Iterative
  Processes
• Remember that all the requirements (use cases as
  well) are not fully analysed and written near the
  start of the project they are allowed to evolve
  after feedback
• During inception for example one goal is to
  decide whether the project is worth of further
  investment (carried out during the elaboration
  phase) so most use cases will not be detailed,
  the supplementary specification could be only
  lightly developed (only trying to identify risk
  areas for example). The same applies to the
  vision document.
• During Elaboration the vision can be refined, use
  cases can be detailed, and the supplementary
  specification completed.

11

• During construction, only minor changes should be
  entertained in all the requirements documents.
• 7.5 Conclusion
• As we use an agile evolutionary process, we must
  keep in mind that the specification documents are
  never really frozen (changes are to be welcomed),
  and that we do not expect a full detailed
  specification after the inception phase.
• Nevertheless, we must avoid the trap of having to
  redo (or change significantly) completely the
  requirement documents
• While we accept that the documents are likely to
  be changed and can be incomplete initially we
  must be able to identify the most important
  requirements during inception.
• The subsequent phases should only complete and
  refine these documents.
• A complete rewrite later in the project may have
  disastrous consequences for the project

12

• Discovering, documenting and refining
  requirements is mostly a people activity all
  stakeholders must be involved in their
  elicitation
• Team building is necessary
• Communication techniques, workshops,
  brainstorming are all parts of this process.