L2 The requirement study. Requirement Engineering. Fang Chen

Transcription

1 L2 The requirement study Fang Chen Requirement Engineering Requirement are ubiquitous part of our lives Understand the requirement through communication People are hard to understand! Requirement Creation Design Human nature: never satisfy 1

2 Change is constant What makes the change? Human nature Society Organization Competitors Time to market with the right product! Design: shooting at a moving target! 2

3 Why requirement study? Limitation of the designers Motivation Reduce the total costs Requirements form the basis for Project planning Risk management Acceptance testing Tradeoff Change control Reasons for project failure (old data before 1996) Incomplete requirements (13.1%) Lack of user involvement (12.4%) Lack of resources (10.6%) Unrealistic expectations (9.9%) Lack of executive support (9.3%) Changing requirements/specification (8.7%) Lack of planning (8.1%) Didn t need it any longer (7.5%) 3

4 Analysis methods System analysis top-down decomposition Establish goal/functions representation in data flow diagrams Quick and dirty methods Obstacle to RE: Tacit knowledge Ambiguity Attitude and opinions Three dimensions Specification: discovery, Refining and validating of requirement. Specification Agreement Representation: express of Requirement, model, data flow Agreement: Trade-offs between R and stakeholders s view Representation 4

5 Four Worlds Framework Usage world User s goals, Tasks behaviour Why what Subject world Modeling of User behaviour Transformed information System world How Development world Interoperability, Maintainability Reliability, System requirements Constraints 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 (?) Functional requirements The goals Non functional requirements (NFR) Quality Performance Environment issue Cost time 5

6 Constraints Constraints are conditions or laws that the system will have to obey during operation or during design. Human cognitive Physical Environmental Costs legal Documentation Natural language? technical language? Long, dense text? 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 6

7 User requirement methods Functionality matrix Goal analysis Events analysis Storyboarding Task analysis Task allocation Modeling User A Functionality matrix This method is useful for systems where the number of possible functions is high Task A Task B Task C Task D Task A User B Task B Task C Task D F1 F2 F3 F4 F5 F6 F1 F2 F3 F4 F5 F6 : critical to task : occasional use 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 7

8 Events Analysis Outcome is to scope the system in terms of its input, output and major functions Object-oriented: Focus on event. Event process chains 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 Modeling Analysis + modeling = elaborate requirements Different methods Semantic model Conceptual model Process/information flows Data flow diagram Data structure Entity relationship Validation User s understanding of the requirement specification User agree that it accurately reflect their wishes Different prototypes and scenarios are normally used 8

9 Verification Requirements specification behaves correctly and does not violate any of the laws specified by the users. Boundary Behaviour correctly (verification) Output make sense to the user (validation) Boundary can be blurred Balance the requirements Different stakeholders have different requirements Trade-off analysis methods, decision making table, models, relationship maps, etc 9

10 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 Trade-off between NFR Quality vs Delivery time Cost vs development time Security vs access Functional complexity vs usability, reliability and maintainability 10

11 Initial pathways and scoping for Requirements Policy, or business driven Problem initiated Technical driven External environment External environment NFR Safety Security Accessibility Usability Market Seffah 2001 Comparing and reconciling usabilitycentered and use case-driven requirements engineering processes Different approaches of doing function and non-functional requirement analysis Methods 11

12 Donzelli, 2002 Handling the knowledge acquired during the requirements engineering process a case study- On going project for governmental e-record management system Complicated stakeholders Change from Classic bureaucratic and high paper-dependent structure to paperless knowledge workplace Jokela 2006 Methods for quantitative usability requirements: a case study on the development of the user interface of a mobile phone 12