Synchronize for Second Week

1
Synchronize for Second Week
You have read Chaos, Student Survival
Guide Gause Weinberg Ch. 1,2,3 Jackson on
Descriptions and Machines Wiegers Ch.
1 Now go read Gause Weinberg Ch. 4, and Part
II Wiegers Ch. 6, 7 Jackson on Procrustes
Rough Sketches Application domain Prepare
to meet with the client and develop a Vision and
Scope document
2
Requirements Analysis and Specification
informal statement of need for system
Problem Definition
natural language statement of what system is
to provide
Requirements Definition
notational and/or formal description of a
software system
Requirements Specification
3
Why do requirements?

• Develop a contract between customer and developer
• Enables both sides to be clear about what is to
  be done
• Understand and specify requirements based on
  customers needs
• Not on what the developer thinks the customer
  needs
• Provide basis for definitive testing and
  verification
• System is acceptable if its passes the
  acceptance test

4
Goals for a requirements specification

• Identify the functional capabilities of the
  system
• Identify desired responses to undesired events
• Identify non-functional and environmental
  constraints to be satisfied
• My users will submit input in the form of
  Microsoft Word documents
• It has to run on a 386 under Win 3.1!
• Avoid specifying how focus simply on what
• but recall Michael Jacksons thoughts about
  machines
• Serve as a guide to the development team

5
Desirable Characteristics of a Requirements
Specification

• Abstract
• one model, many realizations
• Complete
• to the extent required
• Consistent
• no contradictions
• Unambiguous
• concrete acceptance test
• Precise
• uniquely interpretable
• Testable

• Concise
• no extraneous details
• Feasible
• realistic constraints
• Even
• consistent level of detail
• Modifiable
• living document
• Reference Tool
• readable by all stakeholders
• No implementation bias

6
Common Problems

• Incompleteness
• customer may be unavailable or inaccessible
• customer asks for too little
• customer doesnt think of everything
• the world changes
• (sometimes incompleteness is okay (as long as its
  noted!))
• Inconsistency
• customer may be a group that disagrees
• different people may negotiate different parts
• Ambiguity
• customer may be a group where noone sees the
  whole picture
• difficult to spot ambiguity in large, complex
  applications

7
Common Problems - 2

• Imprecision
• customer may be a group with a different
  vocabulary
• precision easiest in mature application areas
  (e.g. accounting)
• precision difficult in new disciplines
• Infeasibility
• customer asks for too much
• no conceivable algorithm
• unrealistic requests
• Unevenness
• different sources of information
• different people write different parts
• different parts of specification are more
  difficult than others

8
Basic Techniques

• Customer teaches developer learns and organizes
• Developer applies discipline to process and helps
  discover ambiguity, inconsistency, and
  incompleteness
• Interviews, investigations, questionnaires
• Develop glossaries to aid communication
• Describe in a (semi-)formal notation
• Hierarchical decomposition
• System modeling
• Dataflow diagrams, E-R Diagrams, Finite state
  machines, Petri nets, UML diagrams

9
Informal Requirements Specification

• Typical method
• useful first attempts during problem definition
• Structured Natural Language
• Extended, more detailed form of requirements
  definition
• Advantage
• Uses expressiveness and understandability of
  natural language
• Problems
• Inherent ambiguity of natural language
• Requirements are not partitioned effectively by
  the language itself (difficult to find related
  requirements)

10
Typical contents of a textual Req. Spec. (check
the many templates available!)

• Description
• restatement of problem definition
• Functionality
• what the system does
• Data
• what the system processes
• Environment
• where the system operates
• Robustness
• what is expected of the system when an error
  occurs

• Security
• who has access to what
• Safety
• Can this system harm anyone
• Performance
• what constraints are placed on the systems
  performance
• Resources
• what information/other systems is/are available
  to help the system accomplish its job

11
Rapid Prototyping

• A means to understand and acquire requirements
• Most often
• a mockup of (some aspect of) a software product
• serves as a communication device with the user
• I dont know what I want, but I dont want
  THAT!
• facilitates technical exploration
• Is this possible?
• aids the development and assessment of
  specifications
• I want that...

12
Rapid Prototyping - See Schach, pg. 71
Req. Change
Operations
Retirement
13
Understanding user needs...

• A prototype can help understand user needs
• Is the proposed service/system adequate?
• Is the user-interface usable?
• Are the requirements complete?
• Which alternative should we take?
• e.g. present the user with multiple throw-away
  prototypes

14
Rapid is key!

• The prototype must be constructed quickly!
• Thus, inconsequential problems are minor as long
  as main aspect of the prototype functions
  correctly
• A prototype should be designed to be rapidly
  changed
• This supports iteration in the process
• If the user doesnt like it, incorporate the
  feedback and try again!
• To support these requirements, fourth-generation
  languages or interpreted languages are often used
  to generate prototypes

15
Rapid Prototypes as specifications...

• Instead of discarding the prototype, use it to
  serve as the specification
• Saves time having to write a specification
  document!
• Generally considered a bad idea...
• because
• a rapid prototype cant serve as a legal contract
• a rapid prototype does not make for good
  documentation
• It cant serve as a reference tool for
  maintenance, for example.
• Prototypes should be used to elicit requirements
  and then discarded, next comes design...

16
Rapid Prototypes as the finished product!

• Also considered a bad idea...
• Same problems as previous slide...
• Plus
• Its too easy to slip into the build-and-fix
  lifecycle!

17
Training the client...

• Customer and/or users may confuse a prototype
  with the operational system
• Why do we have to wait so long for the system,
  didnt you have it working three months ago?
• Customer may request more features than
  originally intended
• Hey thats great! Can you add this...and this?
• Thus...client should be informed as to the
  purpose of the prototype and be aware of the
  position of requirements in the life-cycle...