1 2379 - BUSINESS ANALYSIS IN A DIGITAL TRANSFORMATION CONTEXT Module 6: Requirements Analysis and Design Definition III
2 Module Titles Module 1 – Introduction to Business Analysis Module 2 – Elicitation and Collaboration Module 3 – Strategy Analysis Module 4 – Requirements Analysis and Design Definition I Module 5 – Requirements Analysis and Design Definition II Current Focus: Module 6 – Requirements Analysis and Design Definition III Course Plan Module 7 – Requirements Analysis and Design Definition IV Module 8 – Requirements Life Cycle Management Module 9 – Business Analysis Planning and Monitoring Module 10 – Solution Evaluation Module 11 – Business Analysis and Analytics Module 12 – Business Analysis and Digital Transformation
3 Module 6: Learning Outcomes • Select appropriate techniques for RADD • Classify requirements as functional or non-functional • Choose examples and definitions for select RADD techniques • Create Data Dictionary • Interpret Entity Relationship Diagrams
4 Module 6: Topics and Required Readings • 6.1 Requirements Analysis & Design Definition Techniques (Chapter 10) • Data Dictionary (p 247) • Data Modelling (p 256) • Non-Functional Requirements Analysis (p 302) • Sequence Diagrams (p 341) • State Modelling (p 348) • Interface Analysis (p 287) • Prototyping (p 323) BABOK® Guide v3
5 Module 6 – Section 1 Requirements Analysis and Design Definition Techniques
6 RADD Overview • Review the requirements to ensure that they are complete, comprehensive, and add value • Ensure that any conflicting requirements are resolved between the stakeholders • Define and assess solution options and alternatives 6 Specify & Model Requirements Verify Requirements Validate Requirements Define Requirements Architecture Define Design Options Analyze Potential Value & Recommend Solution BABOK® Guide Chapter 7 pages 133- 162
7 Data Dictionary • Standardize a definition of a data element • Documents details about data involved in the change including definitions, relationships, origin, format, usage Page 247 ID Business Data Object Field Name Unique Values Data Type Length Valid Values A1 Test Lab Test Lab name Y Alphanumeric <100 characters Structured text A2 Test Lab Test lab number Y Integer 6 numeric characters Valid store number
8 Data Dictionary: Exercise The University of Toronto Bookstore is undertaking a project to implement a new POS-Inventory Management solution. A Data Dictionary has been drafted. Can you match the entries? Name Description Aliase s Allowable Values Example Item Something stocked for sale in the Bookstore Article, Product Free format alphanumeric up to 40 characters 1 2 International Standard Book Number. A number assigned to every book before publication recording such details as language, provenance and publisher. Book Number. Code. 3 978-1-927584-02-6 Publisher A company or person that prepares and issues books, journals or music for sale 4 Alphanumeric up to 60 characters with spaces International Institute of Business Analysis Subject A branch of knowledge studied or taught in a University Area, Topic, Category, Course Alphanumeric, Category, subcategory up to 100 characters 5 StockCount 6 Inventory, In-Stock Whole number between 0 and 100 10 copies a. ISBN b. 13 digits c. Business Analysis d. The number of specific items currently kept on premises or in a warehouse and available for sale or distribution e. Publishing House, Vendor f. Book-A Guide to the Business Analysis Body of Knowledge Version 3
9 Data Dictionary: How Is It Used in RADD? • Used to record details about the data involved • Standardize meanings of data elements between solutions and between stakeholders. Specify and Model Requirements Verify Requirements Validate Requirements Define Requirements Architecture Define Design Options Analyze Potential Value and Recommend Solution
10 Data Modelling A data model describes – the entities, classes or data objects relevant to a domain – the attributes that are used to describe them – the relationships among them Page 256 Entity-Relationship Diagram Notation
11 Data Modelling: How Is It Used in RADD • Used to model data structure to show how data will be used to meet stakeholder information needs. Specify Requirements http://www.cs.uregina.ca/Links/class-info/215/erd/
12 Non-Functional Requirements Analysis • Examines the criteria that can used to judge the operation of a system, such as its usability and performance characteristics; define how well the solution will behave • Functionality – What is the product supposed to do? • External Interfaces – Interaction with people, systems, hardware, software • Characteristics – Speed, availability, response time, recovery time – Maintainability, security • Design Constraints – Required standards, operating environment Functional Requirements Nonfunctional Requirements Page 302
13 Non-Functional Requirements: Categories Availability Compatibility Maintainability Performance Efficiency Portability Reliability Scalability Security Usability Certification Compliance Localization 13
14 Non-Functional Requirements Performance Examples: • 600 terminals are supported • 500 simultaneous users supported • 80 transactions processed with 10 seconds Security Examples: • Terminate a session after 3 incorrect passwords • Passwords must have one letter, one number, and be longer than 8 characters • Users require to change passwords every 6 weeks Availability Examples: • System can be accessed 22 hours per day 7 days per week, 365 days a year with no more than 2 hours per day offline for maintenance. Compatibility Examples: • Website should operate within the current and previous two versions of Google Chrome and Firefox 14
15 Sequence Diagrams • Model the logic of usage scenarios • Demonstrates how processes operate and interact with one another, and in what order. • Shows – Information passed between objects in the system – Actor interaction with system – Sequence of interactions as messages during activity flow Page 341
16 Sequence Diagrams: How is it Used in RADD QA Order System Order Notification Test Lab Order Entered Add sample requirements Request Lab Booking Confirmation Specify and Model Requirements
17 State Modelling Demonstrates how the behavior of a concept, entity, or object changes in response to events. • State Table – Two dimensional matrix – Used in conjunction or in place of State Diagram • State Diagram – Models object states and transitions – Describe the behavior of system – Describes the possible states of an object as events occur Page 348
18 State Modelling: How Is It Used in RADD Shows how the product or service evolves throughout its life cycle, in terms of the activities performed by the organization and external entities CLAIM PAYMENT STATES STATES Specify and Model Requirements
19 State Diagram: Exercise Here are the requirements BA elicited for different states of courses for registration system: • A new BA course can be proposed and if approved it is scheduled for the next semester. If it is not approved, it will not be scheduled. • Once the course is scheduled, and registration period arrives, it will become Open for enrollment. • Students can enroll in the course as long as there are available seats. When the course reaches its capacity then course is Full and is no more registrations are allowed. • When the registration period is over, the course status will be changed to Closed • The course could be Cancelled if enrollment does not reach the minimum Complete the missing entries in the diagram below. Course Proposed Course __1.__ Course Cancelled Course Open Course Full Course __2__ Course Not Scheduled [4] [3] a. Scheduled b. Approved c. Not Approved d. Closed [7] [5] [6] [8] e. Below Min Students f. Capacity reached g. Registration Period Start h. Registration Period End
20 Interface Analysis • Identify interfaces between solutions and/or solution components and define requirements that describe how they will interact • Interface models – System Interface table – Use cases – User interface flow – Wireframes – Display-Action-response Page 287
21 Interface Analysis: How Is It Used RADD Model requirements for inputs and outputs and interaction between entities System Users Other Systems Hardware Networks Specify and Model Requirements
22 Prototyping • Provides an early model of a final design • Can be used to elicit and validate stakeholder needs, optimize user experience, evaluate design options • Can be throw-away or evolutionary (functional) • Storyboards • Wireframes • Screen and report mockups • Engineering drawings • Renderings • Floor Plans • Sketches
23 Prototyping: How is it Used in RADD Visualize the appearance and capabilities of a planned solution 23 Page 323 Specify and Model Requirements Verify Requirements Validate Requirements Define Requirements Architecture Define Design Options Analyze Potential Value and Recommend Solution
24 RADD Additional Techniques Overview Technique Description Example Data Flow Diagram A diagram showing the inputs to, and outputs from, a solution and the functions within it, implicitly or explicitly. BA Sitka is creating a diagram to show how the new solution will exchange information with various business entities, and its functions and data stores Concept Modelling A way to identify and organize terminology in a business domain. BA Devlin has created a sketch showing the important terms for the solution. Glossary A standardized list of terms with definitions, for a business domain BA Krystal has documented the meanings of acronyms featured in the new UofT grade system.
25 RADD Techniques Quiz Technique Description Example A diagram showing how a transaction is completed in a given timeframe via messages sent between actors and systems BA David’s diagram shows how a customer performs a stock purchase via the bank’s portal linking to an investment application and through it to the stock exchange system 2 A diagram showing the meaningful states of an object of importance and the ways in which the object changes its status BA Chris has created a diagram for UofT SCs to show how courses are created, scheduled, cancelled, and completed. 3 Defines the usability and performance characteristics of a solution BA Gisella has documented the security features that the solution must possess. 4 Shows the characteristics of, and relationships between, items of information BA Simon has documented that a Customer can belong to one or many Buying Groups 5 Documents standard definitions of data elements, their meanings, and allowable values. BA John has created a document defining that the Customer Name field cannot be more than 25 characters 6 Building a representation of a solution to learn more about user experience requirements and design options BA Diana has created a screen mock-up for the new sales tracking solution in order to show it to sales staff and get their reactions. 7 Defines details of all interactions between a solution and other systems and users BA Calvin has analyzed how back-office legacy systems interact with the Bank’s ATMs a. Interface Analysis b. Prototyping c. Non-Functional Requirements Analysis d. State Modelling e. Sequence Diagram f. Data Modelling g. Data Dictionary
26 Any questions?
27 Thank you for choosing the University of Toronto School of Continuing Studies Thank You
28 Join the conversation with us online: facebook.com/uoftscs @uoftscs linkedin.com/company/university-of-toronto-school-of-continuing-studies @uoftscs Follow us on social