S1: Meeting 2
- Administrative Issues
- Attendance, Waiting list issues
- Note: HW1 due today
- Today's Topics for Discussion + Readings
- Requirements Phase: Chapter 7 (pp. 197-221)
- 7.1 Techniques: Interview, Scenario, etc.
- 7.2-8 Rapid Prototyping
- 7.9 Joint Application Development (JAD)
- 7.10 Comparison
- 7.11-13 Testing, CASE Tools, Metrics
- 7.14-15 MSG Case Study
- Requirement Analysis: Determine client's real needs
- Avoid:
- It's just what I asked for, but it's not what I want!
- Or It's not what I asked for!
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,
- 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)