Change is constant. Obstacle to RE: Why requirement study? Limitation of the designers Different knowledge domains Not expertise Ubiquitous nature

Transcription

1 Design the right thing! Fang Chen Change is constant Requirement Design Creation What makes the change? Human nature Society Organization i Competitors Human nature: never satisfy ) 4 Why requirement study? Limitation of the designers Different knowledge domains Not expertise Ubiquitous nature Obstacle to RE: Tacit knowledge Ambiguity Attitude and opinions Motivation Understand what people wants, in terms of design Design the right thing (vs. design the things right) Human error, accidents Reduce the total costs 5 ) 6 1

2 Type of requirements Functional requirements The goals tasks Non functional requirements (NFR) Quality Performance Environment issue Cost time 7 Four Worlds Framework what Subject world Modeling of User behaviour Usage world User s goals, Tasks behaviour Transformed information Why System world Development world Interoperability, Maintainability Reliability, System requirements How Constraints 8 Two aspects in RE Specifying system behaviour Goals Functions Constraints Solutions: Research results Case application RE tasks and processes No cook book, but road map Dynamically: pre design and within design process. Common methods: Interview Observation Questionnaires Text and document analysis Set scope Brainstorming 9 10 Goal Analysis Goal hierarchy and decomposition Example: Final goal: increase customers satisfaction Reduce processing time for complaints Improve personal service in ordering Reduce lead time for delivery Function analysis High level functions towards the final goal Detail functions How functions should work Constraint on system operation Statement about performance Implementation constraints

3 Constraints analysis Constraints are conditions or laws that the system will have to obey during operation or during design. Human cognitive Physical Environmental Costs legal Events Analysis Outcome in terms of its input, output and major functions where does the output from the process go to? what process or function is responsible for responding to this even? Who or what is the destination of this even and why do they want it? Input process output (IPO) charts User requirements analysis User context and early design Prototype and user test User requirements documention How? Communication with people People are hard to understand! Requirement are ubiquitous part of our lives Users limitation Users do not have clear vision of what they want Goal can be fuzzy Do not know what is technical possibility But, once they get, they can see how it can be improved or they don t like it (?) 4. Eliciting Requirements Requirements to Elicit Boundaries Identify the high level boundaries of the system Stakeholders and Use Cases depend on boundaries Stakeholders Customer or Clients Developers Users Goals Eliciting High level goals early in development Tasks When it is difficult to articulate user requirements 17 3

4 4. Eliciting Requirements (contd.) Elicitation Techniques Traditional Techniques Questionnaires and Surveys Interviews Analysis of existing documentation Group Elicitation Group brainstorming sessions RAD (Rapid Application Development) JAD (Joint Application Design) Prototyping Where there is great deal of uncertainty Early feedback from stakeholders is needed 4. Eliciting Requirements (contd.) Elicitation Techniques Model Driven Goal Based Methods KAOS & I Scenario Based Methods CREWS Cognitive Protocol Analysis Laddering Card Sorting Repertory Grids Contextual Alternative to Tradition and Cognitive techniques Ethnographic Technique Participant Observation 5. Modeling and Analysis Requirements The construction of abstract descriptions that are amenable to interpretation Enterprise Modeling Understanding organization's structure Business rules Goals, tasks and responsibilities Data Data Modeling Understand, manipulate and manage large volume of information How to represent real world phenomenon into system information 5. Modeling and Analysis Requirements (contd.) Behavioral Modeling Dynamic or Functional behavior of stakeholders and system, both existing and required Domain Modeling Abstract description of the world in which the system will operate Requirements reuse within a domain Modeling Non Functional Requirements Difficult to express in a measurable way Difficult to analyze Properties of a system as a whole Documentation Structure standards (IEEE 830, Mazza et al 1994) Natural language, but short, avoid ambiguity Structured, defined items Management tools for diagrams Categorize stakeholders and different requirements Modeling Analysis + modeling = elaborate requirements Different methods Semantic model Conceptual model Process/information flows Data flow diagram Data structure Entity relationship

5 Balance the requirements Different stakeholders have different requirements Trade off 7. Agreeing Requirements Maintaining agreement with the stakeholders can be a problem Validation Validation is the process of establishing that the requirements and models elicited provide an accurate account of stakeholder requirements Validation is difficult for two reasons: Question of truth and what is knowable Reaching agreement among different stakeholders 25 Conduct a negotiation Structure options and choices Establish judgment criteria Explain the options Vote? Diagnose the cause of disagreement. conflicts Conflict: probably lack of shared understanding. Handling personal attach: steering sensitive topics away from them Blocking: Challenge those who said it won t work, can t be done Trade off between NFR Test assumptions Benefit analysis Three dimensions Trade off between NFR Specification: discovery, Refining and validating of requirement. Representation: express of Requirement, model, data flow Specification Agreement Quality vs Delivery time Cost vs development time Security vs access Functional complexity vs usability, reliability and maintainability Agreement: Trade-offs between R and stakeholders s view Representation

6 Conclusion Type of requirements Two aspects in RE Three dimensions Four Worlds Framework Process chart Understand user and communicate with user 31 Gantt charts Link Chart GOMS Goal operated methods of selection roles GOMS analysis is a description, or model, of the knowledge how to do it. GOMS Goals what the user wants to achieve Operators basic actions user performs Methods The way to decompose a goal into subgoals/operators Selection means of choosing between competing methods Page

7 GOMS example GOAL: CLOSE-WINDOW. [select GOAL: USE-MENU-METHOD. MOVE-MOUSE-TO-FILE-MENU. PULL-DOWN-FILE-MENU. CLICK-OVER-CLOSE-OPTION GOAL: USE-CTRL-W-METHOD. PRESS-CONTROL-W-KEYS] For a particular user: Limitations GOMS Prespecified goals Routine tasks Discription i i of high h level l Individuals Rule 1: Select USE-MENU-METHOD unless another rule applies Rule 2: If the application is GAME, select CTRL-W-METHOD Variants of GOMS Keystroke Level Model (KLM) Natural GOMS Language (NGOMSL) CMN-GOMS KLM CMN-GOMS NGOMSL 7