Requirement Definition

Transcription

1 Requirement Definition 1

2 Objectives Understand the requirements collection Understand requirements and their correspondence to people, process, technology and organisation infrastructure Understand requirements and their correspondence to customers and CRM systems Understanding requirements architecture Understanding business analyst role in requirements collection Understand evolution of technology and requirements Understanding the relationship with OO, UML and requirements Understanding limitation of modeling tools in presenting the requirement 2

3 Introduction Art of collecting requirements People, process, technology and infrastructure CRM Systems Requirements and business analyst Evolution of technology (Technology life cycle) OO and UML Limitation of modelling tools 3

4 Art of Collecting Requirements EFFECTIVE PEOPLE MANAGEMENT Listening Good verbal communication Good presentation Good documentation 4

5 People, Process and Technology 5

6 Requirement Architecture 6

7 Requirement Architecture- Cont Nature of Integration Based Collaboration Organisational Structure Required Technology Architecture of Integration Requirements Required Methodology Implementing Integration Opportunities for the participated parties Social Threats (Contract, t Trust) 7

8 Requirement Phases Exploration phase: Wish list, tools, technology and practices. Planning phase: Agreements, efforts, priorities, and schedules. Release phase: Iterations, architecture and functionality requirements. Production phase: Further testing and non-functionality requirements. Maintenance phase: Production and Support. Death phase: Documentation is finally written as no more changes to the architecture, design, or code are made 8

9 Roles in Problem Spaces (surrounding the BA Role) User User Supports the BA in Explaining requirements; Invaluable in identification of Use Cases; Activity Diagrams Domain Expert Business Analyst Knows fully the Problem Domain. Helps in Package Diagrams; Prioritization; Reuse. End User End-User usually represents the customer community. Helpful in Acceptance Testing. 9

10 Model of the Internet Evolution Collaborative Under Investigation Operative 1995 Transactive 1991 Informative 1991 c-commerce e-business e-commerce e-information 10

11 Needed Efforts for the Success of the Internet Development Model Internet Development Model e-collaboration Value Assessment, Knowledge Distribution, Cost, Mission, Develop &Test, Post transfer Issues, Evaluation of Organizational Response Encouragement, High Costs, La k f Te hni al and Managerial Skills Develop & Test Lack of Technical and Managerial Skills, e-business e-commerce e-information Right Market, Planning Policies, Develop Purchase Process, Globalize, Right Software Satisfy Needs by Providing Right Information, Value Fundamentals 11

12 Possible Opportunities from the Internet Evolution Internet Evolution e-collaboration e-business Advanced Services, Better CRM and Share of Knowledge, Better Access to Required Products and Services, Globalize Collaborative Environment Service Companies, Distance Learning, Telecommunications Opportunities e-commerce Selling Goods and Services Online e-information Information and Content Provider 12

13 Desired future state with an Integrated Platform Design IT structure that is responsive to and in tune with the strategy Strategy Process Well informed Strategy where the executives know the pulse of the enterprise Entity 1 Entity 2 Entity 3 Entity n Data Warehouse e-commerce Common Processes Common Applications Common Architecture Common Infrastructure Analytical tools Business Intelligence Agile Information & Technology structure that will provide One/Enterprise view of the organization to provide competitive advantage 13

14 Inputs to UML Booch Meyer Before and after conditions Rumbaugh Jacobson Fusion Operation descriptions, Message numbering Harel State charts UML Embley Singleton classes, High-level view Gamma, et.al Frameworks, patterns, notes Shlaer - Mellor Object Lifecycles Odell Classification Wirfs-Brock Responsibilities Henderson-Sellers Aggregation;Metamodel 14

15 The Star of OO Fundamentals CLASSIFICATION Fundamentals of Object-Orientation: Orientation: THE OBJECT 15

16 Classification Lithops Lesliei 16

17 Classification Starting point of object orientation Results in Grouping of meaningful objects. However, this grouping is based on the requirements appearing in the problem space. Different requirements will result in different groupings 17

18 Abstraction: 1st Level is from Objects to Class afrog ahat aclock acat FROG HAT CLOCK CAT Note that these are ABSTRACTIONS and not real Objects. Objects are Classified and good Classification leads to creation of good Abstractions. Classes that represent a collection of Objects are Abstract. 18

19 Abstraction: 2nd Level is from Classes to Classes FROG CAT Can be Abstracted to ANIMAL CLOCK HAT Can be Abstracted to THING Classes are abstracted to higher level class 19

20 Classification & Abstraction MAN BOOK Requirements from Problem Space Can be Classified & Abstracted to Arrive at Good Classes CHEST SHOE HAT 20

21 Abstraction (and Classification).. Starts by grouping a given set of (reality) Objects based on certain characteristics From the classification (grouping), most common properties and behavior is abstracted to arrive at a Class Classes can be further abstracted to higher-level classes Any number of objects can then be created (instantiated) from a Class 21

22 Identifying more general groupings to create Inheritance Hierarchy LIVING BIRD and ANIMAL are types of LIVING things BIRD ANIMAL MITHU? (my Bird) PUSPUS? (your Cat) Are Objects; They Don t appear on Class diagrams CRANE FROG CAT 22

23 Inheritance Inheritance is specific OO characteristic Inheritance in OO is the ability of a Class to inherit all details of a higher-level class. This includes: Attributes Operations (behavior) Relationship Good Inheritance hierarchies are optimum Particularly not too deep 23

24 Inheritance Child class inherits from parent class Child class shares the attributes and routines of parent class, plus perhaps adds additional features Child class can change implementation of parent class (operator overloading) Multiple inheritance should be used with caution as resolution for name clashes is required 24

25 Moving on the Inheritance Tree Finding Superclasses Needs abstract thinking Domain knowledge helpful l Essentially FOR Reuse Generalization Finding Subclasses Concrete lower level implementation thinking Essentially WITH Reuse Specialization 25

26 Current Limitation of Modeling Tools Lack of understanding in which tool belong to which space. For example, the activity diagram is part of problem or solution space. Lack of support in defining the non-functionality requirements. Lack of understanding on how these modelling techniques lead to coding. The current modelling techniques do not prioritise the processes. Complexity of the process complicates the situation by producing a confusing model. There are no clear definition as which tool is better for which specific project 26

27 Possible Solutions Create a prototype of the new system (Problem: Complex system) Identify when, and how information get lost or corrupted (Problem: Traceability) Look at implemented mistakes (Problem: Communication modes) Trust within involved parties (Problem: Trust) Identifying the cost and feasibility of the solution (Problem: How to minimise cost and increase feasibility) 27

28 Summary Presented in this lecture: Art of collecting requirements People, process, technology and infrastructure CRM Systems Requirements and business analyst Evolution of technology (Technology life cycle) OO and UML Limitation of modelling tools 28