1. Requirements Elicitation

2. Requirements (1) _ What are requirements and why are they important? _ Problem frames _ Requirements elicitation _ Strategies –System & actor identification –Use case & scenario analysis _ Requirements refinement and validation

3. What are requirements? _ Properties of a planned system or product that are desired by its customer – What kinds of properties? Functional / non-functional requirements – What is the scope of the system? System / environment; software / process – Are requirements absolute? What if they conflict? Requirements / preferences – Who are the customers? What if they disagree? Stakeholders / viewpoints. Trade-offs / negotiation

4. Engineering and human- oriented approaches _ Requirements occur at boundary between the human and the engineered –“Soft” and “hard” / “Wet” and “dry” _ Human-oriented issues –Understanding the system’s context, reaching consensus, tracking issues, etc. _ Engineering-oriented issues –Analytic methods, documentation quality, modeling, feasibility analysis, etc.

5. Cost of Delay in Fixing Requirements Errors Data: Boehm & Papaccio (1988) IEEE Trans. Software Eng. Nominal unit cost 20-fold increase during devt. 200-fold increase after delivery

6. Requirements and system fitness _ Well-understood requirements _ Poorly understood requirements

7. Requirements faults: (What we’re trying to avoid) _ Vagueness _ Incompleteness _ Gold-plating _ Inconsistency _ Unfeasibility _ Poor writing

8. Software Lifecycle Activities Application Domain Objects SubSystems class... Implementat ion Domain Objects Source Code Test Cases ? Expressed in Terms Of Structured By Implemented By Realized By Verified By System Design Object Design Implemen- tation Testing class.... ? Requirements Elicitation Use Case Model Requirements Analysis Or textual requirements

9. Figure 4-1. Products of requirements elicitation and analysis (UML activity diagram). Requirements Elicitation analysis model :Model system specification :Model Analysis

10. System Specification vs Requirements Analysis Model _ Both focus on the requirements from the user’s view of the system. _ System specification uses natural language (derived from problem statement) _ Requirements analysis model uses formal or semi-formal notation (e.g., UML)

11. Types of Requirements _ Functional requirements: Describe the interactions between the system and its environment independent from implementation – The watch system must display the time based on its location _ Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. –The response time must be less than 1 second –The accuracy must be within a second –The watch must be available 24 hours a day except from 2:00am-2:01am and 3:00am-3:01am _ Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate –The implementation language must be COBOL. –Must interface to the dispatcher system written in 1956.

12. What is usually not in the Requirements? _ System structure, implementation technology _ Development methodology _ Development environment _ Implementation language _ Reusability _ But descriptions of the real-world domains are in the requirements (even though they are not required)

13. Figure 4-2. A System is a collection of real world Phenomena. A Model is a collection of Concepts that represent the System ’s Phenomena. Many Models can represent different aspects of the same System. An unambiguous Model corresponds to only one System. describes * 1 * * Model System ConceptPhenomenon

14. Key concepts: “is” vs. “ought” DomainEnvt. Sys. Now Future Development & delivery The way things are now The way we’re assuming things will be What we’ll make the system do

15. Case Example: Scheduling and Scheduler DomainEnvt. Sys. Now Future Development & delivery How people schedule What meetings are How people will schedule What meetings will now be Spec. of scheduler software

16. The system and the world (Jackson, 2000) This is the “system” (a.k.a. a machine) This is the “real world” How the RW should be Customer Interface phenomena Required phenomena

17. Example of information display problem frame “Know about appts.” feature What they say about appts. Appt. model is “correct” Appt. model Calendar display Time frame Calendar is correct w.r.t. queries “Display a calendar” feature Lexical domains Constructed domain

18. Example of controlled behavior problem frame Appts. with alarms Phone svc. Passage of time Correct & timely call “Wake-up call” feature Controlled domain

19. Requirements Elicitation Activities _ Identify actors _ Identify scenarios _ Identify use cases _ Identify relationships among use cases _ Refine use cases _ Identify nonfunctional requirements _ Identify participating objects

20. Requirements Elicitation _ Challenging activity _ Requires collaboration of people with different backgrounds –User with application domain knowledge –Developer with implementation domain knowledge _ Bridging the gap between user and developer: –Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system –Use cases: Abstraction that describes a class of scenarios

21. Types of Requirements Elicitation _ Greenfield Engineering –Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client –Triggered by user needs _ Re-engineering –Re-design and/or re-implementation of an existing system using newer technology –Triggered by technology enabler _ Interface Engineering –Provide the services of an existing system in a new environment –Triggered by technology enabler or new market needs

22. Key concepts: Use cases and scenarios I’d like it to blah When PQR, the system shall XYZ abstract / general descriptions Blah’ing Suppose a user called a mtg for next week. The system queries everyone’s online calendar and finds that there.... concrete / specific descriptions

23. Case Example: Scheduling scenarios _ Scheduling a meeting without problems _ Someone remembers an appointment and can’t attend _ There’s no convenient time _ There’s no venue available _ The notification mechanism breaks down _ Meeting bumped by CEO

24. Figure 4-12. Activities of JAD (UML activity diagram). The heart of JAD is the Session activity during which all stakeholders design and agree to a system specification. The activities prior to the Session maximizes its efficiency. The production of the Final document ensures that the decisions made during the Session are captured. Management definition guide Project definition Research Preparation Session Session agenda Preliminary specification Working document Session script Scribe forms Final document preparation Final document

25. System Identification _ Development of a system is not just done by taking a snapshot of a scene (domain) _ Definition of the system boundary What is inside, what is outside? _ How can we identify the purpose of a system? _ Requirements Process: –Requirements Elicitation: Definition of the system in terms understood by the customer –Analysis: Technical specification of the system in terms understood by the developer.

26. Use cases _ Most systems have several major input events to which they’re supposed to respond –Ignore the subsidiary directives & additional inputs for now –“Major” does not mean “frequent” _ E.g. calling a meeting, canceling a meeting, becoming a new user of the system, remodeling rooms,... –don’t forget these administrative/configuration use cases

27. Actors _ Actors are – Things that perform actions – Either actors in the world – Or actors in the machine _ For example – Actors in the world User roles Organizations Physical devices External systems Nature – Actors in the machine The system as a whole Architectural components

28. Figure 4-4. Actors of the FRIEND system. FieldOfficers not only have access to different functionality, they use different computers to access the system. FieldOfficerDispatcher FRIEND Q: What is the context diagram for the PA system? Q1: How much is “in” the PA -v- its environment? Q2: Given that, what are the actors?

29. SetTime use case

30. Figure 4-8. Example of communication relationships among actors and use cases in FRIEND (UML use case diagram). The FieldOfficer initiates the ReportEmergency use case and the Dispatcher initiates the OpenIncident and AllocateResources use cases. FieldOfficers cannot directly open an incident or allocate resources on their own. ReportEmergency FieldOfficer Dispatcher OpenIncident AllocateResources >

31. Figure 4-9. Example of use of extend relationship (UML use case diagram). ConnectionDown extends the ReportEmergency use case. The ReportEmergency use case becomes shorter and solely focused on emergency reporting. ReportEmergency FieldOfficer ConnectionDown >

32. Figure 4-10. Example of include relationships among use cases. ViewMap describes the flow of events for viewing a city map (e.g., scrolling, zooming, query by street name) and is used by both OpenIncident and AllocateResources use cases. ViewMap OpenIncident AllocateResources >

33. Scenarios _ “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995] _ A concrete, focused, informal description of a single feature of the system used by a single actor. _ Scenarios can have many different uses during the software lifecycle

34. Types of Scenarios _ As-is scenario –Used in describing a current situation. Usually used during re- engineering. The user describes the system. _ Visionary scenario –Used to describe a future system. Usually described in greenfield engineering or reengineering. –Can often not be done by the user or developer alone _ Evaluation scenario –User tasks against which the system is to be evaluated _ Training scenario –Step by step instructions designed to guide a novice user through a system

35. Why Scenarios? _ Requirements analysis is a form of learning –Examples reinforce principles & help you learn them and their limits _ Providing requirements involves explaining tacit knowledge –Examples are invaluable in articulating processes and problems customers don’t often think about _ Requirements analysis is often a form of design –“How would this work?” is a standard design question

36. Scenario Exploration _ Scenario exploration is the process of understanding planned system behavior by walking through possibilities. – The goal may be just to get an idea of what the system will do and whether it is really needed. – Or it may be a more structured process: to evaluate alternative allocations by considering concrete behaviors that illustrate the interactions in each case. – Or considering the consequences of obstacles, and whether they are severe. – Or considering the consequences of defending against or mitigating obstacles, and whether the costs are worth it.

37. Envisionment through scenarios _ Scenarios are descriptions of actual or imagined sequences of events –esp. good for examining exceptions/graceful degradation Specifications are Abstract General Exhaustive in coverage of situations Authoritative Boring Scenarios are Concrete Particular / Specific Selective with respect to salient situations Illustrative Compelling

38. Case Example: Spec. & scenario fragments When the initiator indicates completion of the definition of the meeting constraints, the system shall complete undefined constraints with default values and shall query the external calendar as follows.... Pointy-haired manager (PHM) wants to organize a meeting to discuss the drone-to-cube ratio and enters the names “Dilbert” and “Wally” as invitees and “tomorrow by 5pm” as latest time. The system queries the...

39. Issues with Scenarios _ What is the appropriate level of detail for scenarios? _ How should scenarios be described and related to other software descriptions? – esp. existing architecture _ Which are the “right” scenarios to explore?

40. Instantiating Actors and Actions _ Many design teams find it useful to give instances of actors, actions and data –“Pointy-haired manager”, not “initiator” –“Dilbert, Wally & PHM”, not “invitees” –“Tomorrow’s cube mtg”, not “the meeting” _ Useful when –Communicating with non-technical customers –Design team has dangerously little domain knowledge –Scenarios are well-chosen, not just cute

41. How do we find scenarios? _ Don’t expect the client to be verbal if the system does not exist (greenfield engineering) _ Don’t wait for information even if the system exists _ Engage in a dialectic approach (evolutionary, incremental) –You help the client to formulate the requirements –The client helps you to understand the requirements –The requirements evolve while the scenarios are being developed

42. Heuristics for finding Scenarios _ Ask yourself or the client the following questions: –What are the primary tasks that the system needs to perform? –What data will the actor create, store, change, remove or add in the system? –What external changes does the system need to know about? –What changes or events will the actor of the system need to be informed about? _ Insist on task observation if the system already exists (interface engineering or reengineering) –Ask to speak to the end user, not just to the software contractor –Expect resistance and try to overcome it

43. Key concept: Requirements refinement Vague, ambiguous Clear, precise I’d like it to blah When PQR, the system shall XYZ refinement (possibly incremental) _ What kinds of refinement are there? – Making a vague statement more precise – Saying what the system should do vs. its users – Dealing with not-yet considered situations

44. Objectives & requirements _ Systems exist to meet goals or objectives – Goals are not final requirements may be ambiguous and inconsistent not absolute (some take priority) idealized rather than implementable not allocated to product – Goals are not business processes processes are implementations of goals

45. Pre-requirements traceability _ Pre-reqts. traceability shows where reqt. traces from thus, objectives are rationale for reqts. 1.1 The system shall blah, blah... 1.2 If the co-worker is blah, blah, the system shall inform the user... 1.2.1... Reqts. IMPROVE blah blah MAINTAIN user awareness of blah Objectives

46. Case Example: Refining a fuzzy requirement The system shall improve the responsiveness to customer complaints The system shall improve the responsiveness to customer complaints The system shall improve the responsiveness to customer complaints …. When the customer-service clerk enters the customer code, the system shall recommend the next customer- service action The system shall improve the responsiveness to customer complaints …. When the customer-service clerk enters the customer code, the system shall recommend the next customer- service action

47. Key concept: Inquiry cycles _ Requirements criticism (challenging documented requirements) is about asking the right questions at the right times Reqts. documentation raise questions analyze, research & decide Annotated reqts. refine reqts. Refined reqts.

48. Case Illustration: Inquiry-driven refinements Project outline Questions of clarification Questions about exceptional cases...etc idealized functional spec. robust functional spec.

49. Requirements Validation _ Critical step in the development process, –Usually after requirements engineering or requirements analysis. Also at delivery _ Requirements validation criteria: –Correctness: The requirements represent the client’s view. –Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system –Consistency: There are functional or nonfunctional requirements that contradict each other –Clarity: There are no ambiguities in the requirements.

50. Requirements Validation Criteria (continued) _ Realism: –Requirements can be implemented and delivered _ Traceability: –Each system function can be traced to a corresponding set of functional requirements

51. Testable performance requirements _ Objectives to accelerate process or minimize delay – Specify in terms of average duration or wait time but convenience (the real objective) often depends on eradicating excessive wait times – Or by specifying ceiling on duration or wait time but often not technically feasible to guarantee – So usually by putting ceiling on 95/99% cases _ Absolute deadlines are functional reqts. – Hard real-time reqts. are substitutes for a response being required before an envt. event

52. Testable usability requirements _ Convenience / usability / familiarity / “friendliness” objectives _ Specification of expected user performance – Ability to do a task without help within X minutes of using system for 1st time – Average performance time for error-free task

53. Case example: Testable quality requirements _ Performance – If there are feasible meeting times, the system should in 95% cases schedule a meeting within 5 seconds of meeting constraints having been entered – Usability – A person should be able to fill in the scheduling constraints for an N-person meeting in fewer than 5*N keystrokes/mouse-clicks

54. Summary _ Requirements Elicitation: –Greenfield Engineering, Reengineering, Interface Engineering _ Scenarios: – Great way to establish communication with client –As-Is Scenarios, Visionary scenarios, Evaluation scenarios Training scenarios –Use cases: Abstraction of scenarios _ Pure functional decomposition is bad: –Leads to unmaintainable code _ Pure object identification is bad: –May lead to wrong objects, wrong attributes, wrong methods _ The key to successful analysis: –Start with use cases and then find the participating objects –If somebody asks “What is this?”, do not answer right away. Return the question or observe: “What is it used for?”