Requirement Engineering. L3 The requirement study. Change is constant. Communication problem? People are hard to understand!

Transcription

1 Requirement Engineering L3 The requirement study Fang Chen Requirement are ubiquitous part of our lives Understand the requirement through communication Requirement Creation Communication problem? People are hard to understand! Design Human nature: never satisfy Change is constant What makes the change? Human nature Society Organization Competitors Design: shooting at a moving target! 1

2 Why requirement study? Limitation of the designers Motivation Reduce the total costs How far shall we make the requirement analysis? Failure of requirement analysis London Ambulance service s computer Aided dispatch system The penalty of getting RE (requirement engineering) wrong is high Even the system did not fail, user is sub-optimal, design costs are wasted Cases of Failure of RE How much library function do you use? How much band system is in use? (less than 30%) New software development (less than 30% in the market) Did computer system increase the work efficiency? How much mobile phone functions did you use?... 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 2

3 Three dimensions Four Worlds Framework Specification: discovery, Refining and validating of requirement. Specification Agreement Usage world User s goals, Tasks behaviour Why Representation: express of Requirement, model, data flow Agreement: Trade-offs between R and stakeholders s view Representation what Subject world Modeling of User behaviour Transformed information System world Development world Interoperability, Maintainability Reliability, System How Constraints User framwork User context and early design Prototype and user test User documention 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 (?) Requirements types and pathway High level functions, towards the final goal Detail functions How functions should work Constraint on system operation Statement about performance Implementation constraints Functional The goals Non functional (NFR) Quality Performance Environment issue Cost time 3

4 Constraints Constraints are conditions or laws that the system will have to obey during operation or during design. Human cognitive Physical Environmental Costs legal User documentation General system characteristics Organizational structure Task scenarios and interaction steps Technical environment System functiions and features User interface design User support Physical environment Social and organizational environment Standard and styleguides to apply Test plan Documentation Natural language? technical language? Long, dense text? 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 User context and early design Identify users and stakeholders and their characteristics Describe technical/physical/social and organization environment Review: current process, similar systems and products Perform expert review of design 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 4

5 User requirement methods Functionality matrix Storyboarding Task analysis Task allocation Task A User A Task B Task C Task D Task A User B Task B Task C Task D Functionality matrix This method is useful for systems where the number of possible functions is high 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 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 Different methods Semantic model Conceptual model Process/information flows Data flow diagram Data structure Entity relationship i* family of model Agent: people who are responsible for the tasks And goals Goal dependency Task dependency Resource dependency The model can be traced to see who depends on whom (agents) for what (tasks, goals achieved) and with what (resources, objects). 5

6 Validation User s understanding of the requirement specification User agree that it accurately reflect their wishes Different prototypes and scenarios are normally used 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 Different stakeholders have different Trade-off analysis methods, decision making table, models, relationship maps, etc 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 6

7 Trade-off between NFR Quality vs Delivery time Cost vs development time Security vs access Functional complexity vs usability, reliability and maintainability Functional allocation Automated or manual Management level level Some guidelines: Machine: repetitive processing, high volume data processing, monitoring, deterministic tasks, Human: recognition, reasoning, flexible, problem solving, non-deterministic tasks, unpredicted events. Initial pathways and scoping for Requirements Policy, or business driven Problem initiated Technical driven External environment Policy, or business driven Business, social-economical theories Williamson 1981 theory: predict the type of organizational relationship according to the goods that a customer wants to acquire from a supplier Top-down decomposition Problem initiated Existing system has problem Even-based analysis Event tree analysis Failure model-event analysis Cause-effect net Model-based analysis Technical driven User s immediate goals is often to acquire new technology User s work goal analysis Fit the new technology with existing systems Demon the functions of the new technical. 7

8 Technical factors Technical features Technical Technical assessment Technical capabilities assessment capabilities benefits Suitability Current & future Applications factors External environment NFR Safety Security Accessibility Usability Market Current & future technology conversation conversation Rasmussen s framework (1986): Communication is generally an automatic and hence skilled process so it is prone to slip- and lapse- errors in failure to listen and poor generation. Discourse theory (Clark 1996): People communicate to establish and achieve shared goals Motivated by purpose Cycle of exchanges Common ground of understanding Discourse: is the branch of linguistics that investigates how meaning is derived in context. Conversation and context Meaning is often constructed by the context of conversation Role of speakers Place Time Shared belief Shared externally perceivable entities 8