A U Business Analysis ITEC 630 Fall 2010

A U Business Analysis ITEC 630 Fall 2010 Introduction, Requirements Analysis & Business Process Modeling Prof. J. Alberto Espinosa A U

My Background • Started as New faculty at AU in Fall’ 02 • Previously at Carnegie Mellon University • Ph. D 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: A U • IT support for global & geographically distributed collaboration • Most recently: team coordination across time zones 2

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/itec 630/syllabus. html • Class Schedule also available at: http: //auapps. american. edu/~alberto/itec 630/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 A U 3

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 (ii. BA) A U 4

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. A U 5

Our Approach: A U Understand the business: current processes, improvements, etc. Figure out what the application will to do to support these processes (and the system qualities) Business Process Analysis Functional and Non-Functional Requirements Analysis Figure out the information and data needs Information Analysis 6

ITEC 630: Business Analysis Course Roadmap • Business application development: the context • Business analysis overview • Requirements analysis • Business process analysis • Requirements analysis and use cases • Data/information analysis • Interface analysis A U • Project analysis 7

The Context of Business Analysis: “Business Application Development” A U 8

ITEC 630 Information Technology (IT) and Business Applications Business World Transactions Transaction Processing ERP, SCM, CRM, etc. Decision Support Distributed Collaboration Enterprise Collaboration Financial Management etc. Information Server Appl Client Appl IT Infrastructure Microcomputers A U Mainframes Database Routers Client/Server Computing DB DB Ubiquitous Computing Security, (Local/Wide area) Networks Firewalls Inter-Networking (Internet, Intranets) Virtual Private Networks Distributed Computing “The Cloud & Web 2. 0” 9

What is Information Technology (IT) for Business? = 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) A U 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!! A U 11

Information Systems IT for Business IT Infrastructure (HW, System SW, database, telecom) + Business Applications (ERP, CRM, SCM, Financial Appl, etc. ) + People, Processes & Business Functions Information System = Business Value !! A U 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 2 nd floor above with 1 st floor windows • 2 small windows above garage on extra room A U

A Cool House: A Sketch (a visual representation to discuss w/client) A U 14

A Cool House: A Scale Drawing (a more detailed representation to discuss w/client) A U 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) A U

SYSTEM DEVELOPMENT All the activities that go into producing and IS solution: 0. Vision 1. 2. 3. 4. 5. 6. Analysis ITEC Design 630 Implementation Testing Conversion Production & Maintenance Degree of ceremony or formality? Depends on size, risk, etc. A U 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: o A U 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: o A U 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: o A U o Can’t purchase off-the-shelf software 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: o A U 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: o A U 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: o A U o Requirements are not static, they evolve over time Features are always added and discontinued 23

EFFORT DISTRIBUTION Maintenance Testing & Integration A U Systems Analysis & Design Implementation 24

Systems Development Models • Linear Sequential Models System development progresses in a straight line fashion • Evolutionary Models System development is done in iterations A U 25

System Development Life Cycle (SDLC) or the “Waterfall” Model (Linear Sequential) Analysis True Waterfall Design Implementation Testing and Conversion In reality A U Production & Maintenance 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 A U 27

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

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

The Spiral Model (Bohem) (Evolutionary) Construction (Implementation) A U Testing & Release (Conversion) Engineering (Analysis & Design) Customer Communication & Evaluation (Business Requirements) Risk Analysis 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) A U 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 A U 32

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 U • 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) notations See 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. 2 For more info on UML and versions, see: http: //www. kobryn. com/ A U 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 A U Other important UML models/artifacts not covered in this class: • Domain models, interaction diagrams, class-responsibilitycollaboration (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/ A U 36

Key Aspects of the UP A U • 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 A U Source: Larman book ch. 2, p. 21 Elab 2 etc. 38

Development Case (illustration) 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: Discipline Business Modeling Analysis Design Implementation A U UP Artifact Inception I 1 Domain Model Elaboration E 1. . En Construction C 1. . Cn Transition T 1. . Tn S Vision S R Use Case Model S R Supplementary Spec S R Glossary S R Design Model S SW Architecture Doc S Data Model S R Implementation Model S R R R SW Development Plan Testing Test Model Dev Environment Development Case S S R R S – Start; R – Refine UP Phases 39

Important Things to Keep in Mind • Ceremony or Formality: o o • • • 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 A U 40

First, the big picture: Enterprise Analysis A U 41

Information Systems and Application “Silos”: The Old Way Silos or Stovepipes A U 42

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 A U 43

A Process May Cut Across Multiple Departments A U 44

Enterprise Architecture and Business Process Orientation: The New Way ITEC 630 Business Domain Business Application Business Process Diagrams Business Process Model Data Models Information Model Use Case Models Application Model Organization Goals Technology Model A U Enterprise Model 45

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 Individual System Implementations A U p. 46

Business Analysis A U 47

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 (ii. BA) A U 48

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 validate requirements for changes to business processes, policies and information systems (ii. BA) A U • 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 (ii. BA) 49

Business Analysis Skills Ability to develop a thorough understanding of: • the requirements to 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 A U • the business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc. 50

Business Analysis Body of Knowledge (BABo. K) See ii. BA (BABo. K is available for a fee (selected sections on Blackboard http: //download. theiiba. org): • Business analysis planning and monitoring • Requirements elicitation • Requirements management and communication • Enterprise analysis • Requirements analysis • Solution assessment and validation A U • Underlying competencies 51

Requirements Planning and Monitoring It involves: • Identifying team roles: project manager, business analysts, developers, quality assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc. • Identifying stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc. • Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes • Define risk monitoring and management approach for each identified risk • Define the requirements and system development method (e. g. , traditional, object oriented, unified modeling language—UML, etc. ) • Define the requirements and system development process (e. g. , system development life cycle, iterative, unified process—UP) • Manage requirements change and scope: requirements creep is a big problem • Define and collect project metrics and reporting mechanisms • A U Other project planning and project management activities 52

Requirements Elicitation A “key” BA task – it provides the foundation for solutions to business needs – it helps develop a thorough understanding of the business process that will be automated and the essential needs of the system. It involves: • Eliciting these essential needs from stakeholders – dependent on the knowledge and willingness of stakeholders to share information • “Trawl” for knowledge: business processes, baseline system, target system • Methods: interviews, surveys, focus groups, requirements workshops, observations, prototyping, written documents, etc. • Analyze all interfaces – human and external systems • Document (i. e. , record) all requirements identified (and the source) – requirements notes, cards, etc. • Establish priorities and verification (measurement) parameters A U • Beware of “scope creep” 53

Requirements Management and Communication The objective is to develop an accurate understanding of the business problem and clearly articulate the solution. It involves: • Communication skills are critical – two ways: not only clearly articulating things verbally and in writing, but also listening effectively • Selecting the appropriate models, artifacts and other requirements documents formats. • Describing models and text artifacts clearly, accurately and concisely • Key deliverable: “requirements specification” representing the BA’s “demonstrated understanding” of the business and processes that need to be handled by the system and its necessary capabilities. • These specs will serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc. • Preparing effective presentations for clients and stakeholders. A U 54

Enterprise Analysis • Enterprise architecture: o “The explicit description and documentation of the current and desired relationships among business and management processes and information technology. ” – U. S. Office of Management and Budget, Circular A-130 o The blueprint for creating enterprise-wide systems in alignment with business needs o It involves preparing all diagram, models and descriptions of: all business processes, functions, information and technology infrastructure o It often involves analyzing the current architecture, conducting gap analysis and developing a target architecture along with a transition plan • The business analyst needs to understand the enterprise strategies, which provides “the context” in which enterprise analysis is conducted • In modern, complex, dynamic and fast-paced business environments, the enterprise strategy and information technology are tightly aligned, but the strategy evolves rapidly, presenting substantial challenges for business analysts. • In large complex organizations, senior business analysts are key participants in the strategic planning process. A U 55

Requirements Analysis “The objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it” (ii. BA) It involves: • Developing analysis models and artifacts • Can be textual or diagrams – beware of over-diagramming • And “transitional artifacts” that connect the multiple models – e. g. CRUD and other matrices • Methods: business process analysis, object-oriented (OO) analysis, structured analysis • Requirements: functional, non-functional, project, assumptions, constraints, etc. A U 56

Solution Assessment & Validation Two key aspects: (1) evaluation if the proposed solution meets business needs (and the architecture analysis) and (2) if the solution was implemented correctly (per requirements) Evaluate proposed solution, it involves: • Requirements reviews to evaluate if they are accurate, complete, clear, non-redundant, consistent (with architecture and business needs), feasible, correctly prioritized, etc. • Obtaining signoff from clients and stakeholders – helps buy in and reduce “feature churn” Evaluate correct implementation, it involves: • Working with Quality Assurance teams • Mapping analysis artifacts to design artifacts • Mapping implemented system features to requirements artifacts • Black box testing of the system implemented – e. g. , using test cases • Evaluating non-functional requirements and technologies used • Evaluating usability and interfaces (human and system) A U 57

Underlying Competencies Behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis, including: • Analytical Thinking and Problem Solving: creative thinking, decision making, learning, problem solving, systems thinking • Behavioral Characteristics: ethics, personal organization, trustworthiness • Business Knowledge: business principles and practices, industry knowledge, organization knowledge, solution knowledge • Communication Skills: oral communications, teaching, written communications • Interaction Skills: facilitation and negotiation, leadership and influencing, teamwork • Software Applications: general purpose applications, specialized A U applications 58

Introduction to Requirements Analysis A U 59

Why are accurate requirements so important? The cost of fixing and error in requirements is: Times larger If discovered during 5 Design 10 Implementation 20 Testing 100 Operations Bohem, Barry R. 1981. Software engineering economics. Englewood Cliffs, N. J. : Prentice-Hall. A U 60

Errors Propagate and Grow problem correct wrong requirements correct design correct code A U wrong design based on wrong requirements wrong code based on wrong designs code based on wrong requirements

Requirements Analysis is Key to Successful Development n Several studies have documented that requirements errors cost the most and that poor requirements are the main cause of software failure GAO’ 92; Faulk’ 92; Bohem’ 81; Curtis’ 88 “The hardest single part of building a software system is deciding what to build. . No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. ” Fred Brooks (1987) No Silver Bullet: Essence and Accidents of SW Engineering A U 62

Sources of Requirements • Users, Customers, other Stakeholders (e. g. , employees, management, selected customers) • Standards (e. g. , GAAP) • Policy/Legal (e. g. government regulations) • System Documentation (e. g. current system being replaced, could be manual) • Business Process Documentation (e. g. current business memos, manuals, practices) • Subject Matter Experts (e. g. experts on the business domain) A U 63

Role That Good Requirements Play • For clients: requirements describe what will be developed and perhaps provide a contractual basis for the development • For project manager: provide a basis for project planning and measuring progress • For the developers: provide the functionality to be designed and coded • For testers: provide the basis on which test • For users: documentation and training A U 64

Capturing Requirements is Difficult Need to: • Find out what is required by/from the system • Understand these requirements and their implications • Communicate (text and models) this understanding to users, customers, designers and other stakeholders • Manage them – i. e. , record them in a traceable manner and ensure that as requirements change, they are updated and the impact of the change is understood • Quality and fit – i. e. , ensure that system meets the requirements A U 65

Interviews • Interviews should be carefully planned • Interview Process model o o o A U Determine who to be interviewed Prepare for, plan & schedule each interview Open the interview: introduction, purpose, permissions (to tape, etc. ) Conduct the interview: semi-structured, open ended questions, mail questions in advance, let users digress, don’t agree or disagree on anything (just capture) Close the interview: summarize things, confirm facts Follow up: resolve conflicts; close-ended questions 66

Requirements Workshops A U • Approx 2 days before each UP iteration • Multiple stakeholders participate: multiple perspectives of the system • It fosters clear communications between Requirement Analysts, users and other stakeholders • Fosters sense of participation and project ownership • Helps accelerate requirements elicitation process • Facilitators are often used • Need a scribe to document the discussion • Need rules for participation and problem resolution • Need a process that fosters preparation • Pre-specify expected deliverables • Use artifacts that foster communication with the client: A Business Process Model (or Map) is an excellent tool for this 67

“Trawling” for Knowledge: Eliciting Requirements n n n A U “Running a net through the organization to catch every possible requirement source” (Robertson & Robertson) With experience, you learn where to fish to find what you want Start with documents from the project “blastoff” meeting with your client Elicit further requirements through: interviews, requirements workshops, questionnaires, observations, job protocol analysis, prototyping, review of existing documents Systematically “catch” and record all requirements Document anything that sounds like a requirement using an organized form or template like: the Volere Requirement Shell 68

Volere Requirements Shell A U Examples: • Functional • Non-functional • Project constraints • Design constraints • Business issues • Project issues

Requirements Defined A U n In simple terms, requirements are things the product needs to do (i. e. , useful functionality for its user) and the capabilities and qualities that it must have (i. e. , non-functional) n IEEE definition: 1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents 3. A documented representation of a condition or capability as in (1) or (2) 70

Requirements Analysis Find, understand, record and communicate: • Functional Requirements (behavioral) ü What the system needs to do • Non-functional Requirements (non-behavioral) ü The qualities of the system (e. g. , speed, reliability, capacity) • Other Requirements ü Project requirements, risk, costs, deliverables, deadlines, etc. • Prepared using a “System Requirements Process” • Articulated in a “System Requirements Specification” A U 71

Functional Requirements • • Are descriptions of “the work” the system needs to do Articulated with text and/or models/diagrams When you think of functional requirements think of verbs The functional requirements define the “functional scope” of the application – i. e. , where its responsibility begins and ends • We will use “use case” analysis to define the functional scope of applications in this course • Your articulation of functional requirements becomes your “demonstrated understanding” of the business processes your system needs to automate – Eric Bristow, Deloitte Consulting • Generally, functional requirements will take the largest share of time to gather – you must understand quite well what the system needs to do. A U 72

Non-Functional Requirements A U • Are “the properties that your product must have … they are not part of the fundamental reason for the product’s existence, but are needed to make the product perform in the desired manner … they describe the experience that the user has while doing the work” – Robertson & Robertson • Functional requirements think of verbs • Non-functional requirements think of adjectives • Non-functional requirements generally are better known by clients and will not take as long to determine – but have huge implications on system cost. 73

Examples of Non-Functional Requirements • Look and Feel – interface, style • Usability – ease of use/learning, personalization, access considerations, interface features • Performance – speed, latency, reliability, availability, capacity, scalability, etc. Operational – technical/physical environment • • A U • • • Maintainability and Portability – ability to fix, support, and port the system Security – access, integrity, privacy, etc. Cultural and Political Legal 74

Non-Functional Requirements Conclusion • Critical to successful development of the system • Misunderstanding of these requirements can significantly impact cost and feasibility of system • Difficult to represent in object models and use cases. • Typically represented using some form of text in the requirements, then realized in the architecture. • Can be hard to validate, unless they are quantified – i. e. , fit criteria A U 75

General Qualities of Good Requirements A U • • • Correct Unambiguous Complete Verifiable (i. e. , fit criteria) Consistent Understandable Modifiable Traceable Design independent Concise Organized Prioritized 76

Other Requirements Issues • Mandated constraints: are indistinguishable from design decisions, except that they are requirements mandated by the client – e. g. use Oracle platform for all databases; develop a web based application • Facts: are conditions about the system’s external environment (e. g. , actors, systems, organizations) known to be true – they are different than mandated constraints in that they are about the application context, but not mandated by the client the system– e. g. , visually and hearing impaired users will need to use • Assumptions: are conditions about the system’s external environment (e. g. , actors, systems, organizations) believed, but not confirmed to be true – A U e. g. , all users speak English 77

The Requirements Specifications Robertson & Robertson’s “Volere Specifications Template (on Blackboard)” n n n A U Project Drivers: purpose, stakeholders, actors Project Constraints: constraints, glossary, assumptions Functional Requirements: use cases, class diagrams Non-functional Requirements: “ilities” & other qualities Project Issues: off-the-shelf, costs, risks, etc. Template for this course’s project: we use an adaptation (simplified version) of the Volere Template 78

Business Process Modeling A U 79

A (simplified) Deloitte BPM Example A U 80

Business Process Model • The system you are gathering requirements for will automate one or more business processes • Therefore, it is very important that the requirements analysts and clients develop common ground on what these business processes are • The best way to achieve this is to develop a business process model and get the client to sign off on it • The idea is to develop a vision of “the work” that needs to be done, looking ONLY at the business aspects of the process • A business process model or map (BPM) fosters communication between the requirements team and the client; and within the team • It provides an excellent starting base to begin to articulate the system requirements A U 81

BPM Symbols • Terminator: start and end points in a process – it only has one input or one output, not both. • Process step: a specific step in the process – it MUST have one input and one or more outputs • Pre-defined process: like a process steps but it actually incorporates multiple steps. They are useful to simplify the diagramming of complex processes • Decision: a question or a branching in the process flow it MUST have one input and one output for each possible decision outcome • Process flow: a directed arrow that specifies the process sequence • Functional bands or swim lanes: show which departments, units or functional roles are associated with different parts of the process • Phase or separators: use to differentiate different phases of the process A U 82

BPM Symbols (Cont’d. ) • Parallel Processing: use these to branch out into multiple parallel flows or to merge them into a single flow. • Off-Page Reference: use it to link to another page • On-Page Reference: use it to link to other parts of the diagram within the page to avoid line crossings and complex flows • These are older legacy symbols frequently used in flowcharts, which you can also use in BPM’s, but I suggest adding notations for these symbols for a nontechnical or younger audience : • More BPM symbols: A U http: //www. breezetree. com/article-excel-flowchart-shapes. htm 83

“Cross Functional Flowchart” (non-UML) BPM Symbols A U 84

Some Guidelines for Good BPM Modeling • Process steps: o o Can have more than one input but only have one output – if you think you need two outputs you probably need a decision symbol that evaluates which output path to follow Must have at least one input and one output – unconnected process step boxes without input and output are incorrect!! • Pre-Defined Process: o o Same as process steps, but can have more than one output In their detail diagrams, use connector symbols to show where the pre-defined process connects to other sub-processes. • Decision (diamond): o o o Have one input and at least two possible outcomes It may have more than two outcomes but this may point to more complex process steps that are better described in a “pre-defined process” All outcomes MUST be labeled (e. g. , “yes”, “no”, “option 1”) • Process flows: o Must connect two symbols (process box, decision, start, end, etc. ) – unconnected flows are incorrect. • You can add other symbols to add clarity (e. g. , page references, connectors, database, printout, etc. ); label these symbols as needed for clarity A U 85

Some BPM Guidelines • BPMs are used to document business processes, NOT systems actions – focus on understanding and documenting what people do and what the key processes are, rather than what the system solution will do. • In other words, you need to understand the business processes before you can suggest a solution. • It often helps to distinguish the baseline BPM (what the client does) from the target BPM (what the client wants or your proposed solution). You can add notations and other symbols to distinguish baseline from target processes • It may also help to distinguish processes that are carried out manually from those that are handled by applications A U • More importantly, this is NOT hard science – if you can do anything to add descriptive clarity to your BPM, by all means 86

More BPM Diagramming Rules • All BPM diagrams have one start and one end symbols. • If there are two or more distinct sub-processes, it is OK to break up the BPM into two sub-models, but each must have a start and end symbols. • If you have many sub-processes you can create one master BPM that includes “Pre-Defined Process” symbols and then create a separate BPMs for each of these predefined sub-processes. • You can include many symbols in the diagram to add clarity to your process descriptions. Some symbols just add clarity (e. g. , comment, database store, printout), whereas others have very specific rules on how to use them. A U • More BPM guidelines: http: //www. edrawsoft. com/flowchart-symbols. php 87

BPM Example - Current Cross-Functional Flowchart A U 88

More Guidelines (see vehicle prior rental example) • If there is a process already in place (i. e. , baseline) and you are proposing process improvements (i. e. , target) Ø Differentiate the two in your diagram or have two separate diagrams • If your solution includes building a system but there are process steps that will not be handled by the system, your diagram(s) should distinguish the manual steps from those to be handled by the system • It is important to number or label all the process steps (P 1, P 2, etc. ) and the decision steps (D 1, D 2, etc. ) to: o o A U Facilitate reference to specific parts of the process To cross reference with other models using “transitional artifacts” (more on this later) 89

BPM Example – Proposed A U 90

Some BPM Diagramming Guidelines for Complex BPMs • If the BPM is complex and there are two or more distinct sub-processes, it is recommended to break up the BPM into two sub-models, and then: o o A U Prepare a high level or master diagram that shows all the sub-processes using pre-defined process symbols Prepare a separate detail diagram for each subprocess 91