1. 1

2.  A customer walks into your office, sits down, looks you straight in the eye and says, “I know you think you understand what I said, but what you don’t understand is what I said is not what I mean.” And this is said very late in your projects.  Requirement engineering helps you to better understand the problems. 2

3.  Inception — Establish a basic understanding of the problem and the nature of the solution.  Elicitation — Draw out the requirements from stakeholders.  Elaboration — Create an analysis model that represents information, functional, and behavioral aspects of the requirements.  Negotiation — Agree on a deliverable system that is realistic for developers and customers.  Specification — Describe the requirements formally or informally.  Validation — Review the requirement specification for errors, ambiguities, omissions, and conflicts.  Requirements management — Manage changing requirements. 3

4.  Ask “ context-free ” questions Who is behind the request for this work? Who will use the solution (product/system)? What will be the economic benefits? How would you characterize “ good ” output from the system? What problems does this solution address? What environment will the product be used in? Are you the right person to answer these questions? Are these question relevant? Can anyone else provide additional information? Should I be asking you anything else? 4

5.  Why is it so difficult to clearly understand what the customer wants? Scope  The boundary of the system is ill-defined.  Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives. Understanding  Customers are not completely sure of what is needed.  Customers have a poor understanding of the capabilities and limitations of the computing environment.  Customers don ’ t have a full understanding of their problem domain.  Customers have trouble communicating needs to the system engineer.  Customers omit detail that is believed to be obvious.  Customers specify requirements that conflict with other requirements.  Customers specify requirements that are ambiguous or untestable. Volatility  Requirements change over time. 5

6.  Meetings are attended by all interested stakeholders.  Rules established for preparation and participation.  Agenda should be formal enough to cover all important points, but informal enough to encourage the free flow of ideas.  A facilitator controls the meeting.  A definition mechanism (blackboard, flip charts, etc.) is used.  During the meeting: The problem is identified. Elements of the solution are proposed. Different approaches are negotiated. A preliminary set of solution requirements are obtained. The atmosphere is collaborative and non-threatening. 6

7.  Statement of need and feasibility.  Statement of scope.  List of participants in requirements elicitation.  Description of the system ’ s technical environment.  List of requirements and associated domain constraints.  List of usage scenarios.  Any prototypes developed to refine requirements. 7

8.  A use-case scenario is a story about how someone or something external to the software (known as an actor) interacts with the system.  Each scenario answers the following questions:  Who is the primary actor, the secondary actor(s)? What are the actor ’ s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the story is described? What variations in the actor ’ s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? 8

9.  Scenario-based elements Use-case — How external actors interact with the system (use-case diagrams; detailed templates) Functional — How software functions are processed in the system (flow charts; activity diagrams)  Class-based elements The various system objects (obtained from scenarios) including their attributes and functions (class diagram)  Behavioral elements How the system behaves in response to different events (state diagram)  Flow-oriented elements How information is transformed as if flows through the system (data flow diagram) 9

10. 10

11. 11

12. 12

13. 13

14.  Identify the key stakeholders These are the people who will be involved in the negotiation  Determine each of the stakeholders “ win conditions ” Win conditions are not always obvious  Negotiate Work toward a set of requirements that lead to “ win- win ” 14

15.  Can be Written document A set of graphical models A collection of usage scenarios A prototype Or any combination of these 15

16.  Is each requirement consistent with the objective of the system?  Have all requirements been specified at the proper level of abstraction?  Is the requirement really necessary?  Is each requirement bounded and unambiguous?  Does each requirement have attribution?  Do any requirements conflict with other requirements?  Is each requirement achievable in the system ’ s technical environment?  Is each requirement testable, once implemented?  Does the model reflect the system ’ s information, function and behavior?  Has the model been appropriately “ partitioned ” ?  Have appropriate requirements patterns been used? 16

17.  Set of activities to help the project team to Track, Identify and Control the changes in the requirement. 17

18. 18

19. ActivityActionTask Communicatio n Inception Requirements EngineeringReq. Elicitation Req. Analysis & Negotiation Req. Specification Req. Verification and Validation Req. Management Planning ModelingAnalysis Modeling Design Modeling Context Modeling Technical Modeling Construction Deployment 19

20.  A graphical representations of business processes, the problems to be solved, and the new proposed product (software).  Objectives: 1. To describe software requirements. 2. To establish a basis for the creation of a software design. 3. To define a set of requirements that can be validated once the software is built.  Bridges the gap between a software specification and a software design. 20 Software specification Design Model Design Model Analysis Model

21.  Suggested by Arlow and Neustadt : The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Delay consideration of infrastructure and other non-functional models until design. Minimize coupling throughout the system. Be sure that the analysis model provides value to all stakeholders. Keep the model as simple as possible especially if extra diagrams do not provide new information. 21

22.  Principle #1. The information domain of a problem must be represented and understood.  Principle #2. The functions that the software performs must be defined.  Principle #3. The behavior of the software (as a consequence of external events) must be represented.  Principle #4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.  Principle #5. The analysis task should move from essential information toward implementation detail. 22

23.  According to Donald : “ Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain...” “[Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks...” 23

24. 1. Object-oriented Analysis model objects, classes, and the relationships and behavior associated with them. The industry standard for the OO modeling is known as Unified Modelling Language (UML) specification and the current available version is 2.2 (OMG, 2009). E.g.: use-case diagrams, activity diagrams (swim-lane diagram), sequence diagram, class diagram, state diagram, and etc.  Structured Analysis Considers data and the processes that transform the data as separate entities. Includes data models, data flow models and behavioral models E.g.: ERD, DFD, state machine model 24

25. 25 Elements of the analysis model

26.  Write Use-Cases  Develop Activity Diagram  Develop Swim lane Diagram 26

27. 27 Use-case diagram for surveillance function

28. Activity diagram for Access camera surveillance— display camera views function 28

29. Swimlane diagram 29

30. Guidelines  Depict the system as single bubble in level 0.  Carefully note primary input and output.  Label all elements with meaningful names.  Maintain information conformity between levels.  Refine one bubble at a time. 30

31.  Assume that a team working for a consumer products company has provided following product description: Our research indicates that the market for home security systems is growing at a rate of 40 percent per year. We would like to enter this market by building a microprocessor-based home security system that would protect against and/or recognize a variety of undesirable "situations" such as illegal entry, fire, flooding, and others. The product, tentatively called SafeHome, will use appropriate sensors to detect each situation, can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected. 31

32. 32 Context-level DFD for SafeHome security function

33. 33

34. Level 2 DFD that refines the monitor sensors process 34

35. 35 State diagram for SafeHome security function

36. 36

37.  Common technique for identifying classes in the context of a software problem is to perform a grammatical parse on the processing narrative for the system.  All nouns become potential objects. 37

38. E.g.  External entities  Things  Occurrences  Events  Roles  Organizational units  Places  Structures. 38

39. 1. Retained information If information about it must be remembered so that the system can function. 2. Needed services Operations that can change the value of its attributes 3. Multiple attributes During requirements analysis, the focus should be on "major" information An object with a single attribute may be useful during design but is probably better represented as an attribute of another object during the analysis activity. 39

40. 4. Common attributes Attributes should apply to all occurrences of the object. 5. Common operations Operations should apply to all occurrences of the object. 6. Essential requirements External entities that appear in the problem space and produce or consume information that is essential to the operation of any solution for the system will almost always be defined as class in the requirements model. 40

41. Potential classClassificationAccept / Reject homeownerrole; external entityreject: 1, 2 fail sensorexternal entityaccept control panelexternal entityaccept installationoccurrencereject (security) systemthingaccept number, typenot objects, attributesreject: 3 fails master passwordthingreject: 3 fails telephone numberthingreject: 3 fails sensor eventoccurrenceaccept audible alarmexternal entityaccept: 1 fails monitoring serviceorganizational unit; eereject: 1, 2 fail 41

42. 42 Class diagram for the system class

43. 43

44. Guidelines for allocating responsibilities to classes:  System intelligence should be evenly distributed  Each responsibility should be stated as generally as possible Abstraction  Polymorphism  Information and the behavior related to it should reside within the same class. Encapsulation  Information about one thing should be localized with a single class, not distributed across multiple classes  Responsibilities should be shared among related classes, when appropriate. 44

45.  Classes fulfill their responsibilities in one of two ways: A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes  Relationships between classes: is-part-of — used when classes are part of an aggregate class. has-knowledge-of — used when one class must acquire information from another class. depends-on — used in all other cases. 45

46. 46 Top: Multiplicity Bottom: Dependencies

47. 47 Class responsibility collaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.

48. 48 A CRC model index card for FloorPlan class

49. 49

50.  A use-case is examined for points of information exchange. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. 50

51. 51 State diagram for the ControlPanel class

52. 52 Sequence diagram (partial) for the SafeHome security function