Specification by xiuliliaofz



  Chapter 9
    Customers and Their Needs
• There are more than one set of “customers”
  for the requirements/specifications.
• The end-users are one of the obvious
  customers, they need to know if the system
  will suit their needs.
• In addition, the testers need to know that
  they can test it, the designers need know
  that they can design it, and so on.
  Sharpening Requirements into
• Requirements are typically more “fuzzy”
  that specifications.
• Specifications lend themselves to
  systematic analysis.
• Analysis of the requirements can find
  “derived” requirements: requirements that
  are a direct consequence of other
When the end user “doesn't care”
• The end-user doesn’t always care about what the
  software does in certain situations.
• For instance, the end-user won’t care what the
  software does in some error conditions: as long as
  it will eventually lead to them getting what they
  need from the system!
• Specifying what the system will do in these
  situations will prevent the designers from having
  to figure it out during the “11th hour” of the
  development cycle!
     Internal (“system”) errors
• Sometimes the system will have “internal”
  errors: out-of-memory, no disk space left,
  and so on.
• The end-user doesn’t have a clue what to do
  about these problems, but expect the
  engineers to provide code to handle it
   Using a specification as a test
• Specifications provide information to the test
  group about how the software should respond.
• As an oracle, the specification should allow testers
  to “look up” the results of a test to make sure they
  are correct.
• Sometimes, if enough formalism is used, tests can
  be generated automatically from a specification.
  Writing a specification only to
             discard it
• In some instances, the analysis required to
  write a specification can cause exposure of
  errors and inconsistencies in the
• After correction and amplification of the
  requirements document it may be
  sometimes prudent to throw out the
  specification and start over!
          The Uses of Formalism
• Formalism can avoid certain problems such as
  ambiguity, and help enforce correctness,
  conciseness, and preciseness.
• Formalism can be used to allow automation of:
   –   Consistency checking
   –   Test generation
   –   Value checking (inputs and outputs)
   –   Design
             Informal formalism
• There are shades of gray in formalism: it is not a
  black or white issue. Formalism is derived simply
  from “form”.
• Structured english is a formalism that can help,
  but falls short of the rigor of mathematical
  formalism. Nonetheless, it can be useful:
      If the student id is negative, then print an error message on the
         console indicating the student id is in error.
• This requirement is clear, concise, succinct,
  unambiguous all because of the “if input-and-
  value then output-and-value” form, but is still
  quite readable and understandable by end-users.
     The opportunity to verify
• This process of requirements specification
  allows engineers to check the requirements.
  Decomposition and organization of
  requirements into a formal specification can
  help “double check” the requirements.
• In addition, analysis allows engineers to
  look “forward” to the design phase to begin
  identifying design issues.
Formal Specification and Design
• There are major design methods that begin
  with formal specifications, of which three
  will be covered:
  – Finite state-machine design
  – Object-oriented design
  – Structured analysis/Structured design (SA/SD),
    sometimes called “Data-flow Diagrams”.
    Finite-state-machine (FSM)
• FSM design begins with a formal description of:
   – System States (sometimes considered to be “operational
   – Stimuli: the conditions the system must respond to.
   – Responses: the responses the system can make to
• FSM architectures (such as table-driven
  architectures) are almost “off-the-shelf” solutions
  once the states, stimuli and responses are known.
        Object-oriented design
• Object-oriented design begins with formal
  descriptions of:
   – The problem set (“problem domain” or “Use Cases”).
   – Existing frameworks (if any).
   – The user working model (paradigm).
• By working with the frameworks, paradigm and
  use cases, an architecture (Class hierarchies and
  collaborations) can be derived.
 Design with data-flow diagrams
• Data-flow diagrams begin with formal
  descriptions of:
   – Inputs and expected outputs.
   – Transformations that can be applied to data.
   – Relationships between transformations (such as data
     passed into and out of the transforms)
• The translation of data-flow diagrams into an
  architecture is a mechanical (clerical) process.

To top