S1: Meeting 2
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S2: 7.14 MSG Case Study (pp. 214-216)
  • What are requirements?
    • approximately what the program will do
      • specification is a contract, exact functionality
    • describe the needs of the client
      • not only what clients say they want,
      • but also what they need (not obvvious in MSG!)
    • What are not requirements? (Specification or Design)
    • Specifications: - exactly what it will do, what we will provide
    • Design - how it will do it, how it works
  • Identify the properties of requirements from the following:
    • Here is the structure of the system
    • What is needed?
    • Here is what we propose to do
    • Q? Identify specification/design statements in 7.14.
    • Ch. 7: no sharp distinction between Requirements and Specifications
    • Some book talk about "Requirements Specifications"!
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S3: Three Types of Requirements
  • Functional requirements - deals with application domain
    • observable to the user.
    • easily "testable" using (input, output) pairs
    • Ex. deny mortgage if mortgage amount > $1 Million
  • Non-functional requirements (constraints)
    • not observable in the output,
      • but can be determined
    • Ex. program will run on a Unix operating system.
  • Design objectives
    • cannot be measured
    • Can not be objectively determined
      • whether they exist in the system or not.
    • Ex. The system will be reliable..
    • Should be considered goals to work toward.
  • Read the Requirement Analysis Result in Ch. 7.14
    • Q. Identify 3 statements in each of above 3 classes:
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S4: 7.1 Techniques:
  • Q? How do you do Requirements Analysis?
    • MSG: How does a Computer Sc. person understand mortgages?
  • Techniques
    • Passive
      • Research and site visits, observation of work environment
      • Sampling existing documentation, forms, files, info. system
    • Active
      • Interviews (structures & unstructured)
      • Market Survey via Questionnaires
      • Scenarios (story boards, possibility trees)
      • Rapid Prototype (drawing on paper, computer code)
    • Goals:
    • Understand clients' goals and objectives
    • Identify critical success factors (priorities)
    • Constraints (e.g. budget, deadlines, etc.)
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S5: Interviews and Questionnaires
  • the PRIMARY requirements analysis technique (p. 211)
    • Structured interview: Ask questions with specific answers
    • Unstructured interview: Ask open-ended questions
    • Structured interviews might miss things.
    • Unstructured interviews might skew results by a few responses.
  • Questionnaires: like interviews, but in writing
    • Can be structured or unstructured
    • Can have multiple rounds (e.g. high-level, then detailed)
    • gives a chance for more thoughtful answers
  • Example: Consider the task of customizing this course to audience.
    • Background survey (HW. 1): is it structured or unstructured?
    • List 2 follow on questions based on the survey response.
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S6: Scenarios
  • Story boards:
    • On paper presentation of various screens
      • in the sequence that the user sees them
    • Example: proposed new "Birthday Card Maker"
    • story board shows welcome screen, compose screen,
      • & save, print & email screens
    • Trees: Give the responses of the system at each branch point
    • Example: Envisaging "Windows 2000" via trying
      • all possible user screens (actions tree)
    • Compare storyboards and trees: advantages and disadvantages?
    • Q? Which is useful in dealing with casual users?
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S7: 7.2-8 Rapid Prototyping
  • most ACCURATE requirements analysis technique (p. 212)
  • A prototype is an actual program
    • on-paper equivalent is a tree of scenarios
    • Simulates look and feel of the real target system
      • the aspects visible to user-- e.g. GUI/menu
    • Rapid prototype: written rapidly ignoring non-critical aspects.
    • Should good programming style be used?
    • Can it be allowed to crash frequently?
    • Should it run as fast as the final product?
    • Can it be used as specification (legal contract)? (ch. 7.4)
    • throw it away or refined into the final product? (Ch. 7.5)
    • Role of clients - reactive or active (Ch. 7.9, pp. 211)
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S8: 7.9 Joint Application Development (JAD)
  • Encourages clients to play a more active role
    • Not only respond to suggestions of developers
    • Be part of the joint team
      • Discuss needs of the client
      • Design screens, reports, build the rapid prototype
      • Draw the specification document
    • Also take responsibility for the outcome
  • Reduces risk of client falling asleep or playing games
  • Example: Participative Government
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S9: 7.11-13 Testing, CASE Tools, Metrics
  • Testing Requirements
    • If users are different from clients, then
    • Ensure all stakeholders participate
  • CASE Tools
    • Rapid Prototype may use "4GL" systems
      • Interpreted languages: Smalltalk, Lisp
      • Scripting language: perl, tcl/Tk
    • 4GL: Powerbuilder, Visual Basic, Focus
    • Hypertext: HTML,
  • Metrics
    • Focus on requirement volatility now and in future phases
    • Usually ignore response time, crash frequency
      • unless that's the key requirement
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S10: 7.15 MSG Case Study
  • Read the Requirement Analysis Result in Ch. 7.14
    • Q. Identify 3 statements in each of following classes:
      • Functional Requirements,
      • Non-Functional Requirements (Constraints)
      • or Design Objectives (Goals)
    • Prototype (App. C)
    • array "portfolio" of "investment_records"
      • functions for add, modify, delete "investments"
    • Unfinished - several stubs
      • "mortgage" function-stubs similar to "investment" functions
    • User interface is menu driven
    • main_menu(pp. 494) & 3 sub-menus
  • Q? Would it faster to prototype it in another language?
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S11: Summary
  • Requirements Analysis in Context
    • life cycle context (Schach, Figure 3.2)
    • effort percentage (Schach, Figure 1.2)
  • Q. Classify following phrases from a requirements document as:
    • (b)Non-Functional Requirements (Constraints)
    • (c) Design Objectives (Goals).
    • Note that a Design Decision should be classified as a Constraint:
  • Phrases:
    • system shall respond to queries in not more than two seconds ...
    • system will compute depreciation using the straight-line method ...
    • All data will be sorted using a quicksort algorithm ...
    • system shall provide real-time responses to queries ...
    • reports will be exportable to all popular spreadsheet programs ...
    • Source code will contain a comment/statement ration of at least 50% ...
Copyright: S. Shekhar, C. S. Dept., University of Minnesota, Minneapolis, MN 55455. ,,.(home)