Business Requirements Analysis Course

1. Business Requirements Analysis ITEC-455 Spring 2010 Introduction, Requirements Analysis& Business Process Modeling Prof. J. Alberto Espinosa

2. My Background • Started as New faculty at AU in Fall’02 • Previously at Carnegie Mellon University • PhD and MS in IS from Carnegie Mellon • Also, BS Mech Engineering & MBA • Over 18 years of working experience • Mostly implementing and managing systems • And in management • Specialty: systems implementation and database • Mostly in international/global contexts • Teach: Intro to IT, web programming, business analysis, database • Research focus: • IT support for global & geographically distributed collaboration • Most recently: team coordination across time zones

3. Class Web Site • Current versions of syllabus, class schedule, lecture notes, and homework assignments will be posted on the Blackboard class web site. • Course Syllabus also available at:http://auapps.american.edu/~alberto/itec455/syllabus.html • Class Schedule also available at:http://auapps.american.edu/~alberto/itec455/schedule.html • All homework assignments, lecture slides, and other class materials will be available via the Class Schedule link above, and also via Blackboard • Class announcements and grades will be available via Blackboard only

4. What is business analysis? “The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.” Source: International Institute of Business Analysis (iiBA)

5. What is requirements analysis? Requirements are conditions that a product, system or component must meet and/or capabilities it must have to solve a business problem, satisfy a contract, or meet a standard, specification or other formally imposed documents - IEEE Requirements analysis is one of several business analysis practices, concerned with identifying requirements for a business application implementation.

6. ITEC 455:Business Requirements Analysis Course Roadmap • Business application development • Business analysis overview • Introduction to requirements analysis • Business process analysis • Requirements analysis and use cases • Data/information analysis • Interface analysis • Project analysis

7. The Context of Business Analysis:“Business Application Development”

8. Business WorldTransactions ERP, SCM, CRM, etc. Decision SupportDistributed CollaborationEnterprise CollaborationFinancial Managementetc. Information BusinessApplications Transaction Processing ServerAppl Client Appl Microcomputers Mainframes Client/Server Computing ITInfrastructure Database DB DB Ubiquitous Computing Routers Security,Firewalls Distributed Computing (Local/Wide area) Networks Inter-Networking (Internet, Intranets)Virtual Private Networks ITEC455 Information Technology (IT) and Business “The Cloud& Web 2.0”

9. = IT Infrastructure:the hardware, system software, telecommunications/networks and data storage supporting all business applications + Business Applications: software used to manage particular business functions or processes (e.g., accounting, supply chain management) What is Information Technology (IT) for Business?

10. What is an Information System (IS) for Business? An arrangement of people, business functions, processes, and IT which interact to collect, store and process, and store data to provide information to support business activities and decisions It is much more than just IT!!

11. Information Systems IT for Business People,Processes& Business Functions IT Infrastructure(HW, System SW, database, telecom) BusinessApplications(ERP, CRM, SCM, Financial Appl, etc.) + + Information System =Business Value !!

12. Requirements for a Cool House:(first meeting with the client: a very high level description of the house) • 3 bedrooms, dinning room, living room, kitchen, laundry room, 2-1/2 bathrooms • Back patio, access from the kitchen • 2-floors + basement • 2-car attached garage w/extra room on top & driveway • Landscaped front yard & small trees in the backyard • 2 windows, one on each side of front door • 2 windows on 2nd floor above with 1st floor windows • 2 small windows above garage on extra room

13. A Cool House: A Sketch(a visual representation to discuss w/client)

14. A Cool House: A Scale Drawing(a more detailed representation to discuss w/client)

15. A Cool House: The Blueprints(very specific dimensions to discuss w/client and then give to builders for construction: i.e., communicating client requirements)

16. SYSTEM DEVELOPMENT All the activities that go into producing and IS solution: 0. Vision • Analysis • Design • Implementation • Testing • Conversion • Production & Maintenance Degree of ceremony or formality? Depends on size, risk, etc. ITEC455

17. 1. Analysis A communication exercise between system users and system developers An analysis of the “problems”to be solved by an information system Developing an understanding of “the work” that the system needs to perform Developing an understanding of “what”the system needs to do Implication: • Understanding the business problem is critical before offering solutions

18. 2. Design An analysis of the “solutions”to the problems identified during systems analysis Developing and understanding of “how”the system needs to do what was identified during systems analysis, per the “requirements specification” Implication: • Can’t design a solution until you’ve analyzed the problem

19. 3. Implementation Selection, acquisition, production and assembly/integration of the necessary components of the system For systems that require software development, translating the conceptual design into specific software instructions to accomplish the work. Implications: • Can’t purchase off-the-shelf software until you’ve until you’ve analyzed the requirements • Can’t build an application until you’ve designed

20. 4. Testing Test Types: • UNIT TESTING:each part of the system works well individually • SYSTEM TESTING:all the parts of the system work well together • REGRESSION TESTING: new parts of the system work well with the existing system • ACCEPTANCE (USER) TESTING: By users and/or clients • BLACK BOX TESTING: Testing if the system does what is supposed to, per requirements specifications, without inspecting the internals of the system • CLEAR BOX TESTING: Inspecting and testing the internals (e.g., code inspections) of the system (opening the black box) Implication: • Analysis artifacts (e.g., use cases) can be used for testing (e.g., acceptance and black box testing with “test cases”)

21. 5. Conversion (i.e., Installation) Important Conversion Issues: • CONVERSION PLAN:Schedule for conversion • DOCUMENTATION:Description of how system works • USER TRAINING Conversion Methods: • PARALLEL:Old & new run simultaneously • DIRECT CUTOVER:Risky conversion to new system • PILOT:Introduce first in one area, domain, location • PHASED:Implement the system in stages Implication: • Analysis artifacts (e.g., use cases) can be used to develop user manuals and other system documentation

22. 6. Production & Maintenance • PRODUCTION:Review by users & operators User support • MAINTENANCE: Upgrades Bug fixes Implication: • Requirements are not static, they evolve over time • Features are always added and discontinued

23. EFFORT DISTRIBUTION Systems Analysis & Design Maintenance Testing & Integration Implementation

24. Systems Development Models • Linear Sequential ModelsSystem development progresses in a straight line fashion • Evolutionary ModelsSystem development is done in iterations

25. Design Production & Maintenance Testing and Conversion Analysis System Development Life Cycle (SDLC)or the “Waterfall” Model (Linear Sequential) True Waterfall Implementation In reality

26. SDLC (“Waterfall”) Model Pros & Cons • Pros: • Oldest and most widely used model • Life cycle concept is very useful • OK when requirements are certain and stable • Cons: • Early errors detected late are very costly • Not very useful when requirements are uncertain • Many real projects rarely follow a sequential flow • Often difficult to know all requirements early on • Programmers have to wait until the whole design is finished

27. The Incremental Model(Linear Sequential) Core Product Analysis Design Programming Increment 1(new feature) Analysis Testing,etc. Design Programming Integration +Regression Testing Increment 2(new feature) Analysis Testing,etc. Design Etc. Programming Testing,etc.

28. Incremental Model Pros & Cons • Pros: • Core functionality can be provided quickly • Increments can be planned to manage technical risks (e.g., increment, evaluate, increment, evaluate, etc.) • Cons: • Takes a long time to finish entire system • Later increments may never get done

29. The Spiral Model (Bohem)(Evolutionary) Construction (Implementation) Testing & Release(Conversion) Engineering (Analysis & Design) Customer Communication & Evaluation(Business Requirements) RiskAnalysis Planning

30. The Spiral Model • Pros: • Each loop allows the team to assess risks and adjust the plan • More realistic approach for large projects • Conceptually sound idea • Cons: • Not many – the basic concept is widely adopted • Is the foundation for the Unified Process (UP)

31. Object-Oriented (OO) Analysis • Most prevalent software system development paradigm today • In which a system is conceptualized by discovering physical objects that the system needs to represent – e.g., customers, locations, students, classrooms, invoices, etc.) • And discovering their attributes (i.e., data elements – e.g., name, SSN, etc.) and behaviors (i.e., programs – e.g., place an order) • More on OO later in the course

32. Standards • Standards are necessary when many people are involved in a system development effort. • There are many types of standards, but two important ones are standards about: (1) notations and (2) processes • A notation (i.e., a language) is necessary to describe the system. Standard notations describe the symbols to use in models and other analysis artifacts. We will use the UML (Unified Modeling Language) • A process is necessary to define the sequence of activities that will be undertaken to gather requirements and then design and implement the system: We will use the UP (Unified Process)

33. Unified Modeling Language (UML) • UML a standard for notations and methods to express OO A/D • UML is the most widely adopted standard diagramming notation to describe systems today • Proposed by Booch, Jacobson & Rambaugh (the “Three Amigos”) to unify their individual (most widely used) notationsSee Object Mgt Group site: http://www.omg.org/ • Main purpose of the UML: communication!! • It is intended for OO Analysis and Design (OO A/D) • You can do OO A/D without UML using other notations • Similarly, you can use aspects of UML for non OO A/D • UML is up to version 2.0, textbook UML 1.3, MS Visio UML 1.2For more info on UML and versions, see: http://www.kobryn.com/

34. Important UML Models/Artifacts • To be covered in class: • Use Cases – a set of scenarios of system uses, each tied together by a common user goal – all use cases collectively describe the functionality of the system – each use case describes a discrete aspect of that functionality • Use Case Diagrams – a visual model that shows how all actors (i.e., users and external systems) interact with all use cases of a system • Activity Diagrams – diagrams that explain use case workflows (sometimes useful, but use case text is often preferred) • Class Diagrams – describes the types of objects in a system and the static relationships among them • Other important UML models/artifacts not covered in this class: • Domain models, interaction diagrams, class-responsibility-collaboration (CRC) cards, state diagrams, etc.

35. The Unified [System Development] Process (UP) • A system development process defines the activities undertaken to build, deploy, and maintain systems • UP: a popular SW development process used with OO methods – a derivative of the spiral method • UP was also developed by the “Three Amigos” • UML and UP are independent – you can use UML without UP, or UP without UML, but they were both conceptualize to work together • Rational UP (RUP): a refinement of the UP formulated by the “Rational Corporation” now owned by IBM, widely adopted today.See: http://www.rational.com/

36. Key Aspects of the UP • Iterations:“timeboxed” – i.e., of fixed time length of 2-6 or more weeks – date slippage is discouraged – removing tasks or requirements from the iteration is preferred • Workshops: each iteration begins with at 1-2 day workshop to discuss the scope of the iteration and plan accordingly. • 4 Phases:inception, elaboration, construction and transition – this course deals with the inception and elaboration phases • Disciplines (originally called “workflows” until 2001): a set of related system development activities (e.g., analysis, design, etc. – note: these are considered “phases” in the Waterfall model) • Artifacts: working products such as code, database schemas, text documents, diagrams, models, etc. • Development Case: articulates upfront which artifacts (not all artifacts need to be employed) will be used in the particular development project

37. Iterations, Disciplines & Workflows in the UP Incep Elab 1 Elab 2 etc. Source: Larman book ch.2, p.21

38. Development Case Not every artifact is used in every project. The development case articulates the specific artifacts that will be used on a specific project. This is the development case we will follow for your projects – marked in bold red: S – Start; R – Refine UP Phases

39. Important Things to Keep in Mind • Ceremony or Formality: • High ceremony: lots of formal deliverables, meetings, etc. • How much? it depends • The right process? it varies for each company • Requirements and Design = communication exercises • No need to use all diagrams or artifacts • No need to note everything, only what is noteworthy • Avoid overdoing requirements (i.e., analysis paralysis): keep it simple, but accurate • Let’s look at the Class Schedule once again • Let’s look at the Final Project

40. ITEC 455:Business Requirements Analysis Course Roadmap • Business application development • Business analysis overview • Introduction to requirements analysis • Business process analysis • Requirements analysis and use cases • Data/information analysis • Interface analysis • Project analysis

41. First, the big picture:Enterprise Analysis

42. Information Systems andApplication “Silos”: The Old Way Silos or Stovepipes

43. The New Way:Focus on Business Processes A process:Manner in which work is organized and coordinated to produce a product or service • Some business processes take place within a function • Some others cut across multiple business functions • Concrete work flows of material, information, and knowledge • Unique ways to coordinate work, information, and knowledge • Example: processing a customer order

44. A Process May Cut Across Multiple Departments

45. Enterprise Architecture and Business Process Orientation: The New Way BusinessDomain BusinessApplication ITEC 455 Business Process Model Information Model OrganizationGoals Application Model Technology Model Enterprise Model

46. EA Process (Armour et al 1999, TOGAF): EA Maturity (Ross et al 2006) Business Silos (i.e., stovepipes) Standardized Technology Optimized Core Business Modularity Baseline EA Transition from Baseline to Target EA Target EA Individual System Implementations

47. Business Analysis

48. What is business analysis? “The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.” Source: International Institute of Business Analysis (iiBA)

49. About the Business Analysis Profession • Business analysts used to be called “systems analysts” • Business analyst is the preferred title today in recognition of the fact that business strategies and system implementations need to be tightly aligned, so the analyst needs to thoroughly understand business goals, functions and processes, more than systems per se (CIO Magazine) • A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validaterequirements for changes to business processes, policies and information systems (iiBA) • The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals (iiBA)

50. Business Analysis Skills Ability to develop a thorough understanding of: • therequirementsto solve a business problem, often with a system implementation • how the proposed system or solution will interoperate or integrate with the existing systems and technology in which the new system will operate. • how the proposed system or solution fits the existing enterprise architecture and business strategies • the business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc.