VANCOUVER Chapter Study Group. BABOK Chapter 9 Techniques

Transcription

1 VANCOUVER Chapter Study Group BABOK Chapter 9 Techniques May 27, 2015 David Ghotbi, CBAP

2 Agenda Chapter 8 Review Pop Quiz Break Chapter 9 Review Pop Quiz Q & A 2

3 Chapter 9 Techniques Techniques: Alter the way a business analysis task is performed Listed in BABOK are only a subset of the techniques used by practitioners of business analysis. Applicable to enough different situations and business domains, and have been adopted by enough business analysis practitioners 3

4 Chapter 9 Techniques Process Modeling Prototyping Sequence Diagrams User Stories 4

5 Chapter 9 Techniques 9.21 Process Modeling describes how multiple people or groups collaborate over a period of time to perform work involves a number of activities that are linked by a sequence flow. is repeatable and may have multiple paths to completion is initiated by an event in the business domain, such as a sale of a product to a customer, is a visual representation of the sequential flow and control logic of a set of related activities or actions 5

6 9.21 Process Modeling 6

7 9.21 Process Modeling 7

8 9.21 Process Modeling Advantages Most stakeholders are comfortable with the basic elements of and concepts behind a process model. Process models are effective at showing how to handle a large number of scenarios and parallel branches. Process models are likely to have value in their own right, as they will be used by business stakeholders for training and co-ordination of activities. 8

9 9.21 Process Modeling Disadvantages Can become extremely complex and unwieldy if not structured carefully. Problems in a process cannot always be identified by looking at the model. It is usually necessary to engage stakeholders directly to find problems they have encountered while working with a process. 9

10 Chapter 9 Techniques 9.22 Prototyping Details user interface requirements and integrates them with other requirements such as use cases, scenarios, data and business rules Functional Scope A horizontal prototype models a shallow, and possibly wide view of the system s functionality; no business logic A vertical prototype models a deep, and usually narrow slice of the entire system s functionality. 10

11 9.22 Prototyping Usage Throughout System Development Lifecycle A Throw-away prototype seeks to quickly uncover and clarify interface requirements using simple tools: The focus is on functionality that is not easily elicited by other techniques, has conflicting viewpoints, or is difficult to understand. Evolutionary or Functional prototype extends the initial interface requirements into a fully functioning system: Requires a specialized prototyping tool or language. This prototype produces a working software application. 11

12 9.22 Prototyping Elements 1. Prepare For Prototyping Determine the prototyping approach. Identify the functionality to be modeled. 2. Prototype Building the prototype is an iterative process. Report: The first iteration may produce a list of report requirements: data attributes, selection criteria and derivation rules for totals. Further analysis may draft a detailed layout of the report. 12

13 9.22 Prototyping 2. Prototype (Contd.) Interface: focus is an end-to-end understanding of the interface flow. Storyboard (aka Dialog Map, Dialog Hierarchy or Navigation Flow) portrays the navigation paths across the interface components. Screen prototypes provide data attributes, selection criteria and supporting business rules. A screen layout or mock-up provides a graphical representation of the elements. Organizational standards or style guides can be applied. 13

14 9.22 Prototyping 3. Evaluate The Prototype Verify the logical interface elements trace to user requirements such as processes, data and business rules. Validate that the prototype represents the user s needs. Scenarios are useful to test the interfaces. 14

15 9.22 Prototyping Advantages Supports users who are more comfortable and effective at articulating their needs by using pictures, as prototyping lets them see the future system s interface. A prototype allows for early user interaction and feedback. A vertical prototype can demonstrate what is feasible with existing technology, and where there may be technology gaps. An evolutionary / functional prototype provides a vehicle for designers and developers to learn about the users interface needs and to evolve system requirements 15

16 9.22 Prototyping Disadvantages How s rather than What s, Assumptions about the underlying technology, Unrealistic expectations: the delivered system s performance, completion date, reliability and usability characteristics Constrain the solution design: focus on the design specifications of the solution rather than the requirements. Developers may believe that they must provide a user interface that precisely matches the prototype, even if superior technology and interface approaches exist 16

17 Chapter 9 Techniques 9.28 Sequence Diagram Shows how classes and objects interact during a scenario. The classes required to execute the scenario are displayed on the diagram, as are the messages they pass to one another (triggered by steps in the use case). Shows how objects used in the scenario interact but not how they are related to one another. Are also often used to show how user interface components or software components interact. 17

18 9.28 Sequence Diagram Instance of a Class Lifeline The sequence diagram only specifies the ordering of events and not the exact timing The sequence diagram shows the stimuli flowing between objects. The stimulus is a message and the arrival of the stimulus at the object is called an event. Procedural Flow (Synchronous Message) transfers to the receiving object. The sender cannot act until a return message is received. Asynchronous Flow (also known as a signal) allows the object to continue with its own processing after sending the signal. The object may send many signals simultaneously, but may only 18 accept one signal at a time.

19 9.28 Sequence Diagram Advantages May be used in object-oriented analysis to validate class diagrams (described in 9.7) against use cases (9.26), or to show the timing of interactions between entities within the system scope. Disadvantages Must be defined for each possible scenario. Strictly speaking, a sequence diagram requires a fully defined class model (see Data Model), although lessformal sequence diagrams are often developed that represent user interface elements or interactions between actors. 19

20 Chapter 9 Techniques 9.33 User Stories A textual description of things that the solution needs to allow users to do. Are typically a sentence or two that describes who uses the story, the goal they are trying to accomplish (from the perspective of the user), and any additional information that may be critical to understanding the scope of the story. 20

21 9.33 User Stories A user story includes: Actor: Stakeholder who benefits from the user story. Description: A high-level overview of what functionality the user story includes. Benefit: The business value the story delivers. Note: A user story should also have defined Acceptance and Evaluation Criteria (9.1). 21

22 9.33 User Stories Advantages Create an environment of customer ownership of features and prioritizations in an incremental, iterative development environment. May eliminate the need to provide functional requirements in some environments. Require that the value delivered by the story be clearly articulated. 22

23 9.33 User Stories Disadvantages May not be the best technique for some environments with regulatory restrictions or when an organization mandates documentation. May not be effective when participants are not colocated. Does not explicitly address how to document nonfunctional requirements. 23

24 How prepared are you? POP QUIZ! 24

25 Quick Quiz Which of the following is NOT an element of Use Cases and Scenarios? a. Relationship b. Actor c. Flow of Events d. Post Conditions e. System 25

26 Quick Quiz As a BA assigned to improve an enterprise process in order to maximize the achievement of its business mission you would most likely start with an analysis technique such as: a. CRUD matrix b. Activity diagrams c. Performance Requirements d. Data mapping 26

27 Quick Quiz Data Modeling is NOT supported by which of the following? a. Business Rules Analysis b. Data Dictionary c. Glossary d. Decisions 27

28 Quick Quiz Which technique is likely to have the least amount of detail? a. Prototyping b. User Story c. Use Case scenarios d. Storyboarding 28

29 Quick Quiz Which of the following is not a type of Data Modelling Diagram? a. ERD b. Class Diagram c. LDM & PDM d. Class Model 29

30 Recommended Readings I/II 30

31 Recommended Readings II/II 31

32 Chapter 5 Enterprise Analysis Q & A 32