Elicitation I Some Slides were Based on presentations

Elicitation I Some Slides were Based on presentations

Elicitation I Some Slides were Based on presentations from Eric Yu, Alexei Lapouchnian and Steve Easterbrook 1 Requirements Challenge Complex HCI : Always complicate and complex Eliciting Requirements Need to be always exploring Many possible solutions No right or wrong

What is the problem again ? 2 Once more What is RE ? A systematic process of developing requirements through an iterative and cooperative process of analyzing the problem, documenting the resulting observations in a I'm not sure why you need to defer variety of representation formats, and but I'm not sure why you need to checking thebutaccuracy of the understanding

defer gained. [MaCaulay Requirements Engineering (applied Computing)] 3 What are Requirements? Requirements capture the purpose of a software-intensive system Purpose in the human activities that the system supports Requirements are about problems (or opportunities) How can a system support human activities? It can make them more efficient It can make them more effective It can enable new activities that are not possible/feasible now

4 Software Myths (From Easterbrook Lectures) Cost of Software is Lower than cost of physical devices Software is easy to change Computers are more reliable than physical devices Software can be formally proved to be correct Software reuse increases safety and reliability Computers reduce risk over mechanical systems 5 Creating Problem Statements Study the real world Ask questions about the activities the system

should support (i.e., perform requirements elicitation) Decide a suitable scope for the system Write precise description of the problem 6 6 Benefits of Problem Statements An explicit problem description is useful: Helps the designer to understand the problem before considering ways to solve it Helps reveal complexities/subtleties of the situation Most obvious problem might not be the right one to solve Problem statement can be discussed with stakeholders Problem statement can be used to evaluate design choices

Problem statement is a source of good test cases 7 7 Ok. How Elicitation fits ? First part of Requirements Process But it goes throughout the whole software Never stops 8 Another Definition for Requirements: An externally Observable Characteristic of a Desired System

2 Buttons in a mouse If the user needs 2 buttons this is a requirement If the user only need a way of moving slides back and forth, this is too detailed to be a requirement 9 Tackling the problem not the solution My Elevator is slow My Elevator is too slow You have a throughput problem not a speed problem !

10 Tackling the problem not the solution My Elevator is slow Well its a problem because people complaint about the lines As better as needed for stopping complaints Why is that a problem ? How better should it be? Solution ?

11 Separating Problems from Solutions Need to check Solution correctly solves the stated problem Problem statement corresponds to the real-world needs of the stakeholders 12 12 13

The Machine and The World Shared Phenomena Application domain the world in which the machine (system) will be introduced In particular a part of the world in which the machines actions will be observed and evaluated Machine domain the set of phenomena the machine (system) has access to (data, algorithms, devices, etc.) Shared phenomena things observable to both domains 14 14

Example 15 15 Problem Statement Description Domain Properties (Assumptions) things in the application domain that are true whether or not we ever build the proposed system Requirements things in the application domain that we wish to be made true by delivering the proposed system Many of which will involve phenomena the machine has no access to

Specification is a description of the behaviours that the program must have in order to meet the requirements Can only be written in terms of shared phenomena! 16 16 Boundaries Can Be Moved: E.g., Elevator Control System The nature of the problem to be solved can be changed Add sensors to detect when people are waiting/in the cabin Requirements analyst is responsible for the boundary! 17

17 System vs. Software Engineering [The 4 variable model D. Parnas, adapted by S. Easterbook] 18 18 Example: Train Control [Axel van Lamsweerde] System and software interface for a control system with embedded software

Software interface: through IN/OUT variables E.g., measuredSpeed (is read by program) and doorState (is set by program) System interface: The system includes the software and I/O devices. Therefore, the interface of the system with the environment are the monitored and controlled variables of the real world, for instance trainSpeed and doorsClosed [Generic Architecture of a control system including embedded software, van Lamsweerde]

19 19 Example: Train Control [Axel van Lamsweerde] The software (model) normally contains objects that represent objects in the system environment E.g. the doorState variable represents the state of the doors in the train Whether they represent the situation in the environment correctly, is another question For doorState, this may depend on the correct functioning of the door state sensing device

better: Problem domain requirements (if one considers the train to be the environment of the control system) 20 20 Dealing With The Tension: The Extremes One extreme: Freeze the requirements early Proceed in a bubble isolated from the real worlds changes Great degree of control for the development process Risk of developing a useless product

The other extreme: Dont document requirements at all Documenting requirements is a useless activity (?) Agility in responding to new ideas, changes Risk of chaotic development 21 21 Pragmatic RE RE is not a sequential process: Dont have to write the problem statement before the solution statement (Re-)writing a problem statement can be useful at any stage of development Captures the current understanding of the problem

RE activities continue throughout the development process The problem statement will be imperfect RE models are approximations of the world Will contain inaccuracies, inconsistencies, and omissions Analyst should perform enough analysis to reduce the risk that these will cause serious problems This risk can never be reduced to zero! 22 22 Pragmatic RE Perfecting a specification may not be cost-effective Requirements analysis has a cost For different projects, the cost-benefit balance will be

different Safety-critical, large systems vs. others Problem statement should never be treated as fixed Change is inevitable, and therefore must be planned for There should be a way of incorporating changes periodically 23 23 The Requirements Process

Elicit Model Analyse Manage Not Waterfall, Nor spiral 24 An SADT Model for the Definition of Requirements UofD Requirements Requirements Enception Enception

Select Select Personel Personel UofD Soft. Eng. Viewpoints clients Elicit Elicit method facts

requirements Model Model model UofD Select Select Method Method Analyse Analyse tools

Management 25 Requirements Inception Start the process Identification of business need New market opportunity Great idea Involves Building a business case Preliminary feasibility assessment Preliminary definition of project scope Stakeholders Business managers, marketing people, product managers,

etc. Examples of techniques Brainstorming, Joint Application Development (JAD) meeting, etc. 26 26 Requirements Elicitation Gathering of information About problem domain About problems (or opportunities) requiring a solution About constraints related to the problem or solution Questions that need to be answered

What is the system? What are the goals of the system? How is the work done now? What are the problems? How will the system solve these problems? How will the system be used on a day-to-day basis? Will performance issues or other constraints affect the way the solution is approached?

How the System is likely to EVOLVE ? 27 Requirements Elicitation Overview of different sources Customers and other stakeholders Existing systems Documentation Domain experts Etc.

Overview of different techniques Brainstorming Interviews Task observations Scenarios (Use Cases) Prototyping Etc. 28

28 Requirements Elicitation The process of studying and analyzing the needs of stakeholders (E.g., customer, user) in view of coming up with a solution. Such a solution may involve: A new organization of the processes/workflow in the company A new system (system-to-be) that will be used in the existing or modified workflow A new software to be developed that is to run within the existing computer system or involving modified and/or additional hardware. Objectives Detect and resolve conflicts between requirements (e.g., through

negotiation) Discover the boundaries of the system/software and how it must interact with its environment Elaborate system requirements to derive software requirements 29 29 Analysis Validation and Verification Both help ensure delivery of what the client needs Need to be performed at every stage during the process Validation: checks that the right product is being built (refers back to stakeholders main concern during RE)

Verification: checks that the product is being built right During design phase: refers back to the specification of the system or software requirements During RE: mainly checking consistency between different requirements, detecting conflicts Techniques used during RE Simple checks Formal Review Logical analysis

Prototypes and enactments Design of functional tests 30 30 Requirements Modelling The invention and definition of the behaviour of a new system (solution domain) such that it will produce the required effects in the problem domain. At the end it will produce the Requirements Specification Requirements Elicitation has defined the problem domain and the required effects Specification Document A document that clearly and precisely describes, each of the

essential requirements (functions, performance, design constraints, and quality attributes) of the software and the external interfaces Each requirement being defined in such a way that its achievement is capable of being objectively verified by a prescribed method (e.g., inspection, demonstration, analysis, or test) Different guidelines and templates exist for requirements specification 31 31 Requirements Management Necessary to cope with changes to requirements Requirements change is caused by:

Business process (or business context) changes Technology changes Better understanding of the problem [qamindset.blogspot.ca] Traceability is very important for effective requirements management 32 32 Is There a Correct RE Process? Many early RE books assume that RE was done for a specific customer

In a particular phase of the SDLC The customer would sign off on a requirements specification However, RE is done on a variety of projects, with many different characteristics Frequently, no customer is initially identifiable! Thus, no single correct RE process exists 33 33 Project Types

Reasons for initiating a software development project Problem-driven: competition, crisis, Change-driven: new needs, growth, change in business or environment, Opportunity-driven: exploit a new technology, Legacy-driven: part of a previous plan, unfinished work, Relationship with Customer(s): Customer-specific one customer with specific problem

May be another company, with contractual arrangement May be a division within the same company Market-based system to be sold to a general market In some cases the product must generate customers Marketing team may act as substitute customer Community-based intended as a general benefit to some community

E.g., open source tools, tools for scientific research Funder customer (if funder has no stake in the outcome) Hybrid (a mix of the above) 34 34 Project Context Existing System brownfield situation There is nearly always an existing system May just be a set of ad hoc workarounds for the problem Studying it is important: If we want to avoid the weaknesses of the old system while preserving what the stakeholders like about it

But we need to go beyond . Pre-Existing Components Benefits: Can dramatically reduce development cost Easier to decompose the problem if some subproblems are already solved Tension: Solving the real problem vs. solving a known problem (with ready solution) 35 35 Process improvement

Process improvement is concerned with modifying processes in order to meet some improvement objectives Improvement objectives Quality improvement Schedule reduction Resource reduction 36 Planning process improvement What are the problems with current processes? What are the improvement goals? How can process improvement be introduced to achieve these goals? How should process improvements be

controlled and managed? 37 Process maturity Process maturity can be thought of as the extent that an organization has defined its processes, actively controls these processes and provides systematic human and computer-based support for them. The SEIs Capability Maturity Model is a framework for assessing software process maturity in development organizations 38 Capability maturity model Level 5

Optimizing Le vel 4 Managed Level 3 Defined Le vel 2 Repeatable Level 1 Initial 39 RE process maturity levels Initial level No defined RE process. Suffer from requirements problems such as requirements volatility, unsatisfied stakeholders and high rework costs. Dependent on individual skills and experience.

Repeatable level Defined standards for requirements documents and policies and procedures for requirements management. Defined level Defined RE process based on good practices and techniques. Active process improvement process in place. 40 Maturity levels Managed level Detailed measurements of both process and product quality are collected and used to control the process.

Optimizing level The organization has a continuous process improvement strategy, based on objective measurements in place. 41 Good practice for RE process improvement RE processes can be improved by the systematic introduction of good requirements engineering practice Each improvement cycle identifies good practice guidelines and works to introduce them in an organization 42

Project Management + Mature Process Metrics ! A critical tool If you dont have metrics you can not manage it Milestones People Productivity

Mistakes Time to fix mistakes Etc. 43 2015 44 Elicitation Elicit [Var. elicit + make it clearer + extract] 1.discover, make explicit, get as much information as possible to understand the object being studied. 45

Basic Needs for Elicitation (Questions from Polya) What is unknown? Do you know any related problem? Can you reinvent the problem? 46 Separating Problems from Solutions Separation of problem and solution statements is impossible! One of the key insights of requirements engineering The world is complex; any attempt to understand it imperfect The world is changing continually Software opens up new possibilities for how the work is

organized > the process of design will change the problem! Show a prototype to a user and hell find new things hed like it to do Frequently, only by trying to design a new system we start to understand the problem (and WHETHER there is really a problem to solve) 47 47 Elicitation Identify sources of information Gather facts Communication 48

Elicitation Gathering information may be hard Communication can be difficult (different languages and knowledge) Stakeholder may be (often are) hard to meet They may have conflicting objectives Stakeholder often have different viewpoints regarding the same thing Knowledge is usually distributed among many different sources The mere presence of an outsider may change the process Hidden agendas Fear of change 49

Elicitation Problems According to Leffingwell & Widrig [Leffingwell & Widrig, Managing Software Requirements: A Use Case Approach, 2nd Ed., 2003] The Yes, But syndrome stems from human nature and the users inability to experience software as they might a physical device Undiscovered Ruins: the more you find, the more you realize still remains The User and Developer syndrome reflects the profound differences between the two, making communication difficult The sins of your predecessors syndrome where marketing (user) and developers do not trust each other

based on previous interactions, so marketing wants everything and developers commit to nothing 50 Elicitation Problems Other Factors [1] Social and organizational factors "No system is an island unto itself" All software systems exist and are used within a particular context both technical AND social Social and organizational factors often dominate system requirements Determining what these are can be difficult and timeconsuming Analysts/Architects/Developers/Etc. are (usually) outsiders People don't always tell the truth (everybody lies Dr. Gregory House)

Awareness of one's own "culture" can be hard 51 51 Elicitation Problems Other Factors [2] These factors tend to cut across all aspects of the system: E.g., a system that allows senior managers to access information directly without going through middle managers Interface must be simple enough for senior managers to be able to use Middle managers may feel threatened or encroached upon, be resistant to new system Lower-level users may concentrate on activities that impress senior managers, which is not necessarily what they ought to be

doing Users may not like "random spot checks"; may devise ways of hiding what they're doing 52 Identifying Sources of Information Actors in the Universe of Discourse Clients Users Developers

Documents Books Software Systems COTS 53 Who is related to the software? Non-clients users customer interested clients clients

Third party clients Investor Owner Specialist Partner developers Quality Control (QC) Technical writers Software Engineer 54 Criteria for Identifying Stakeholders

Experience Knowledge about the domain Volume of investment What the stakeholder does daily Need Diversity have representatives from all stakeholder types Appropriate level of agreement 55 Sources of Information UofD

UofD Source of Information = { a,b,c,d,e,f} U {g,h} 56 Heuristics to identify sources of information

Who is the client? Who owns the system? Is there any customized system available? What are the books related to the application? Is it possible to reuse software artefacts? What are the documents most cited by the actors of UofD? 57 Facts gathering

Document Reading Observation Interviews Reunions Questionnaires Anthropology Active participation from actors Protocol Analysis Reverse Engineering Reuse

58 Tacit Knowledge The kind of knowledge that is trivial for the actor being interviewed but not for the interviewer Because it is trivial, people almost never remembers to mention it. The interviewer in his/her turn, not knowing about the tacit knowledge can not ask about it. Review the slide for interview 59

Recently Viewed Presentations

  • Herb WB5PHM - 7290 Traffic net

    Herb WB5PHM - 7290 Traffic net

    7290 picnic 2009 by herb wb5phm entrance to rv park sign at entrance restrooms and showers the almost hidden rv of rodney w5dy herbs (wb5phm) 5th wheel herb & joanies 5th wheel (ka5crl's vertical) looking from the bridge toward the...
  • Roach: Nonopioid Analgesics: Salicylates and Nonsalicylates

    Roach: Nonopioid Analgesics: Salicylates and Nonsalicylates

    Nonsalicylates: Contraindications and Precautions . Contraindicated in patients with hypersensitivity. Used cautiously in patients: With severe or recurrent pain or high or continued fever. Acetaminophen used cautiously during pregnancy and lactation
  • Fahrenheit 451 The temperature at which book paper

    Fahrenheit 451 The temperature at which book paper

    When they're gone, he grabs the phone and dials whatever is the messed-up future-world version of 9-1-1. Two guys show up to help with the emergency. They're more like plumbers than doctors, much to Guy's dismay. They use two machines...
  • A Decidable Logic for Tree Data-Structures with Measurements

    A Decidable Logic for Tree Data-Structures with Measurements

    Dryad [POPL'12, PLDI'13, PLDI'14, OOPSLA'17] can but undecidable "An . AVL tree . is a self-balancing . binary search . treeā€¦In an AVL tree, the . heights. of the two child subtrees of any node . differ.
  • Health Care Vocab

    Health Care Vocab

    Susan has her yearly mammogram and discovers she has breast cancer. The doctors recommend a mastectomy along with chemotherapy. Right or Privilege. ... James is morbidly obese. He would like to receive gastric bypass surgery to help him lose weight.
  • NRC Review Panel on High Performance Computing 11 March 1994 ...

    NRC Review Panel on High Performance Computing 11 March 1994 ...

    NRC-CSTB Future of Supercomputing Committee 22 May 2003 NRC Brooks-Sutherland Committee 11 March 1994 NRC OSTP Report 18 August 1984 Gordon Bell Microsoft Bay Area Research Center San Francisco Outline Community re-Centric Computing vs. Computer Centers Background: Where we are...
  • Design I

    Design I

    Observer Pattern: Multiple displays UML model of the Observer pattern Using Design Patterns Is a design process develop a design experiencing a problem recognizing that an existing pattern can be used most difficult step is the need for a taxonomy...
  • Spanish 1 Summer Review # of Activities I

    Spanish 1 Summer Review # of Activities I

    These are common combinations: Gustar + infinitive = to like to Encantar + infinitive = to love to Necesitar + infinitive = to need to Pensar + infinitive = to plan to Preferir + infinitive = to prefer to Querer...