Recomendados
Más contenido relacionado
Destacado
Destacado (13)
Último
Último (20)
Six Blind Men And An Elephant
- 1. Six Blind Men and an Elephant Using Multiple Models to Get a Complete View of Requirements Gary Bellamy http://ca.linkedin.com/in/garybellamy
- 2. The Fable http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 3. An Elephant is like a Wall! http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 4. An Elephant is like a Spear! http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 5. An Elephant is like a Snake! http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 6. An Elephant is like a Tree! http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 7. An Elephant is like a Fan! http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 8. An Elephant is like a Rope! http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 9. Multiple Views http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 10. What is a Model? http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 11. Model Formats BODY EAR TUSK LEG TAIL TRUNK http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 13. Define domainboundaries and components
- 14. Describe thought processes and action flows
- 15. Categorize and create hierarchies
- 16. Show components and their relationships
- 17. Show business logichttp://ca.linkedin.com/in/garybellamy Gary Bellamy
- 18. Model Views Control Source: EBG Consulting http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 19. Behavior View UML: Use Case Diagram (and Specification) ID: UC1 Name: Submit Registration Description: Registrant reviews event information and, based on interest and availability, preregisters for the event. Precondition: Promotional email received Basic Flow: Registrant checks topic Registrant checks speaker Registrant Likes topic and speaker Registrant checks availability at event date and time Registrant is available Registrant notifies registrar of intent to attend event. Post-condition Registrant is pre-registered Exception 1: Registrant does not like topic http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 20. Behavior View UML: Activity Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 21. Behavior View Business Process Modeling Notation (BPMN) http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 22. Behavior View UML: Sequence Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 23. Structure View UML: Class Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 24. Structure View Entity Relationship Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 25. Dynamics View UML: State Machine Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 26. Dynamics View Data Flow Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 27. Control View Structured English http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 28. Control View Decision Table http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 29. Control View Decision Tree http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 30. Model Levels http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 31. Scope Level Context Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 32. Scope Level UML: Business Use Case Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 33. Scope Level UML: Business Use Case Diagram http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 34. Scope Level UML: Domain Model http://ca.linkedin.com/in/garybellamy Gary Bellamy
- 35. Don’t capture requirements blindly http://ca.linkedin.com/in/garybellamy Gary Bellamy
Notas del editor
- WelcomeInvite people to ask questions during the presentation.
- Ancient fable from IndiaPoem by John Godfrey Saxe (19th century English poet)It was six men of IndostanTo learning much inclined,Who went to see the Elephant(Though all of them were blind),That each by observationMight satisfy his mind.I’ll spare you the rest of the poem, suffice it to say…Each blind man touched a different part of the elephant, and never having encountered such a creature before, attempted to describe it to the others…
- First blind man touches the Side (broad and sturdy) = Wall
- Second blind man touches the Tusk (round, smooth and sharp) = Spear
- Third blind man touches the Trunk(squirming) = Snake
- Fourth blind man touches the Knee= Tree
- Fifthblind man touches the Ear= Fan
- Sixth blind man touches the Tail(swinging) = Rope
- And so these men of IndostanDisputed loud and long,Each in his own opinionExceeding stiff and strong,Though each was partly in the right,And all were in the wrong!Like the blind men in the parable, business analysts are at risk of drawing false conclusions about requirements when they rely on a single perspective. To get a complete picture of the problem area undergoing analysis, BAs must use multiple models that capture complementary views of the domainOnly together do these models form a true picture of reality
- What is a model?Models are a representation and simplification of reality developed to convey information to a specific audienceto support analysis, communication and understanding. (BABOKGlossary)Is everyone here familiar with the BABOK?Can anyone guess how many times the word “Model” appears in the BABOK? -- 294 (give or take a few – counted by hand)Task 6.3 of Requirements Analysis knowledge area: Specify and Model Requirements
- Models may be either textual or graphical, or some combination of both.Which is better, textual or graphical?Has anyone ever had to assemble something following text-only directions with no pictures?How about directions that are all pictures with no words (IKEA)?SIMPLE ANSWER: Whichever best creates understanding among stakeholdersBABOK: Whether or not a diagram is used in place of or in addition to a textual description is often determined by the audience for the information, as well as the level of detail in a particular model. BABOK: The use of models following a standardized notation can help overcome language barriers by eliminating the need for many textual descriptions.
- Models can:Describe a situation or define a problemDefine boundaries for business domains and sub-domains, and describe the components within each defined boundaryDescribe thought processes and action flowsCategorize and create hierarchies of itemsShow components and their relationshipsShow business logicModels may be used not only to document requirements in their final form, but also as a tool while performing elicitation activities.
- BABOK: Model Selectionthe objective of developing a model is to simplify reality in a way that is usefulNo single model can be a complete description of reality;It will usually be beneficial to create multiple models of and perspectives on the requirements in order to ensure understanding, although any given requirement should only appear in one model in order to avoid confusion or contradictions. Model ViewsBehaviour: process, action, function, task, procedure Structure: data or objects and how they relate to each otherDynamics: time, lifecycleControl: business rules that constrain the other threeEach model represents a different view into the reality of the business domain. It is usually necessary to develop multiple models using different modeling techniques to completely analyze and document requirements. The business analyst must determine which types of models will be required to describe the solution scope and meet the informational needs of stakeholdersThe choice of which model(s) to use for a particular set of requirements is determined by the type of information to be communicated, as well as the audience who will consume the information. Now I’m going to show you examples of different types of diagrams for each of the model views. Where possible, I will always start with the UML notation since it covers almost every view.Is everyone familiar with UML (Unified Modeling Language)?
- To highlight the differences between model views and techniques, I’ve used the same domain, that of registering for an IIBA Chapter meetingUML: Use Case DiagramA use case diagram visually depicts the use cases supported by a system, the actors who trigger those use cases, and relationships between the use cases.Each use case represents a discrete set of functionality that brings value to an actorUse cases are good at clarifying scope and providing a high-level understanding of user behavioral goals, normal situations, alternatives or exception paths through an activity or business process. Alternates: Scenarios (represents one path through a use case)User Stories (represents one instance of a scenario) -- AgileNote: UML does not define notation for use case specification, but without the text the model doesn’t tell us muchThe way UML captures this information is through Activity Diagrams and Sequence Diagrams
- UML: Activity DiagramBABOK: A model that illustrates the flow of processes and/ or complex use cases by showing each activity along with information flows and concurrent activities. This diagram shows the process for preregistering for an IIBA chapter eventNotation Elements.Activities: The individual steps or pieces of work that must be completed in order to execute the business process. May be a single task or be decomposed into a subprocessDecisions (gateways): Forks where the flow of work proceeds in two or more flows and, optionally, where separate flows merge together. A decision may create mutually exclusive or parallel flows. Events: Events occur outside the scope of a process and may be the result of actions taken, messages received, or the passage of time. Events may create, interrupt, or terminate processes. Flow: Indicate the direction of the step-by-step sequence of the workflow. Terminal Points: Represent the beginning or end of a process or process flow. Alternates: Workflow diagram (classic flowchart)BPMN (Business Process Modeling Notation)
- Business Process Modeling Notation (BPMN) is a popular alternative to Activity DiagramsNotation is very similarBPMN can show messaging while UML cannotBPMN can be machine executed? (verify)Both standards emerged around the same time and both are maintained by the Object Management Group (OMG)Note: Swimlanes can be applied to Activity and BPMN diagrams as well as classic flowcharts
- UML: Sequence DiagramPurposeSequence diagrams are used to model the logic of usage scenarios, by showing the information passed between objects in the system through the execution of the scenario. Description A 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). The sequence diagram shows how objects used in the scenario interact but not how they are related to one another. Sequence diagrams are also often used to show how user interface components or software components interact.Key FeaturesThe sequence diagram shows particular instances of each object with a lifeline beneath each object to indicate when the object is created and destroyed. The earliest events in the scenario are depicted at the top of the lifeline, with later events shown further down. 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. A message is shown as an arrow pointing from the lifeline of the object sending the message to the lifeline of the object receiving it.
- UML: Class DiagramClass ModelA type of data model that depicts information groups as classes (and the relationships among them)ClassA descriptor for a set of system objects that share the same attributes, operations, relationships, and behavior. A class represents a concept in the system under design. When used as an analysis model, a class will generally also correspond to a real-world entity.Alternates: Entity Relationship DiagramData Dictionary
- UML: Class DiagramWhat it shows: Alternate: Entity Relationship DiagramData Dictionary
- State DiagramsA state diagram shows how the behavior of a concept, entity or object changes in response to events.A state diagram specifies a sequence of states that an object goes through during its lifetime, and defines which events cause a transition between those states. There are many titles for the state diagram including State Machine Diagram, State Transition Diagram, and Entity Life Cycle Diagram.
- Data Flow DiagramsPurpose: To show how information is input, processed, stored, and output from a system.Description: The Data Flow Diagram (DFD) provides a visual representation of how information is moved through a system. It shows the:External Entities that provide data to, or receive data from, a systemThe Processes of the system that transform dataThe Data Stores in which data is collected for some period of timeThe Data Flows by which data moves between External Entities, Processes and Data StoresAn asterisk within the process is used to identify data processes that have further decomposition models.
- UML:?????????What it shows: Alternate:Business RulesDecision TablesDecision Trees
- What it shows: Alternate:Business RulesDecision TablesDecision Trees
- UML:?????????What it shows: Alternate:Business RulesDecision TablesDecision Trees
- The previous model types can be used to depict both the high-level and detailed views of the problem or solution.Scope ModelingScope models are used to describe the scope of analysis or the scope of a solution.Scope models serve as a basis for defining and delimiting the scope of business analysis and project work. Scope models allow the definition of a “complete” scope—that is, the boundaries of the scope correspond with the natural boundaries of a business domain.There are many different standards for scope modeling. In general, the scope model selected will depend on the analysis techniques selected to further explore the scope.
- One of the most common is a context diagram top-level data flow diagramIt uses a single data process to describe the scope and shows the external entities and data stores that provide data to and receive data from the system. Context diagrams are still used on many projects that do not otherwise use data flow diagrams.External events happen in an External Entity. They are external to the boundaries of the system being studied (a customer makes a request, a partner sends a message).Temporal events are driven by time (e.g. monthly or annual reports). The time is determined by time-related business rules (e.g. produce this report at the end of every day, or prepare a tax return at the end of each tax period).When events have been identified, the next question asked is “What processes are required to provide a complete response to this event?” The answers to this question identify the processes of the system. These processes may then be documented, and further analyzed, using an appropriate process modeling technique.Alternatives:Features -- a service that the solution provides to fulfill one or more stakeholder needs. Features are high-level abstractions of the solution that must later be expanded into fully described functional and supplemental requirements. They allow for early priority and scope management and for validating the stakeholders’ view of the solution.Business Use Case Diagram -- visually depicts the use cases required by the business and defines those supported by a system, as well as the actors who trigger those use cases, and relationships between the use cases.Business Process -- A high-level business process model may also be used as a scope model.
- One of the most common is a context diagram top-level data flow diagramIt uses a single data process to describe the scope and shows the external entities and data stores that provide data to and receive data from the system. Context diagrams are still used on many projects that do not otherwise use data flow diagrams.External events happen in an External Entity. They are external to the boundaries of the system being studied (a customer makes a request, a partner sends a message).Temporal events are driven by time (e.g. monthly or annual reports). The time is determined by time-related business rules (e.g. produce this report at the end of every day, or prepare a tax return at the end of each tax period).When events have been identified, the next question asked is “What processes are required to provide a complete response to this event?” The answers to this question identify the processes of the system. These processes may then be documented, and further analyzed, using an appropriate process modeling technique.Alternatives:Features -- a service that the solution provides to fulfill one or more stakeholder needs. Features are high-level abstractions of the solution that must later be expanded into fully described functional and supplemental requirements. They allow for early priority and scope management and for validating the stakeholders’ view of the solution.Business Use Case Diagram -- visually depicts the use cases required by the business and defines those supported by a system, as well as the actors who trigger those use cases, and relationships between the use cases.Business Process -- A high-level business process model may also be used as a scope model.
- One of the most common is a context diagram top-level data flow diagramIt uses a single data process to describe the scope and shows the external entities and data stores that provide data to and receive data from the system. Context diagrams are still used on many projects that do not otherwise use data flow diagrams.External events happen in an External Entity. They are external to the boundaries of the system being studied (a customer makes a request, a partner sends a message).Temporal events are driven by time (e.g. monthly or annual reports). The time is determined by time-related business rules (e.g. produce this report at the end of every day, or prepare a tax return at the end of each tax period).When events have been identified, the next question asked is “What processes are required to provide a complete response to this event?” The answers to this question identify the processes of the system. These processes may then be documented, and further analyzed, using an appropriate process modeling technique.Alternatives:Features -- a service that the solution provides to fulfill one or more stakeholder needs. Features are high-level abstractions of the solution that must later be expanded into fully described functional and supplemental requirements. They allow for early priority and scope management and for validating the stakeholders’ view of the solution.Business Use Case Diagram -- visually depicts the use cases required by the business and defines those supported by a system, as well as the actors who trigger those use cases, and relationships between the use cases.Business Process -- A high-level business process model may also be used as a scope model.
- One of the most common is a context diagram top-level data flow diagramIt uses a single data process to describe the scope and shows the external entities and data stores that provide data to and receive data from the system. Context diagrams are still used on many projects that do not otherwise use data flow diagrams.External events happen in an External Entity. They are external to the boundaries of the system being studied (a customer makes a request, a partner sends a message).Temporal events are driven by time (e.g. monthly or annual reports). The time is determined by time-related business rules (e.g. produce this report at the end of every day, or prepare a tax return at the end of each tax period).When events have been identified, the next question asked is “What processes are required to provide a complete response to this event?” The answers to this question identify the processes of the system. These processes may then be documented, and further analyzed, using an appropriate process modeling technique.Alternatives:Features -- a service that the solution provides to fulfill one or more stakeholder needs. Features are high-level abstractions of the solution that must later be expanded into fully described functional and supplemental requirements. They allow for early priority and scope management and for validating the stakeholders’ view of the solution.Business Use Case Diagram -- visually depicts the use cases required by the business and defines those supported by a system, as well as the actors who trigger those use cases, and relationships between the use cases.Business Process -- A high-level business process model may also be used as a scope model.
- Summary and conclusion:Like the blind men in the parable, business analysts are at risk of drawing false conclusions about requirements when they rely on a single perspective. This presentation illustrated the importance of using multiple models views to get a complete understanding of the problem or solution. The different model views each answer a distinct question (who, what, when, why and how) about the problem. Each model view can also be described at varying levels of granularity, from scope to high-level to detailed.Finally, a variety of techniques are available to document each of the model types. UML covers almost all of them all but other types are also possible for certain views.It is only by using these complimentary model views at different levels of detail that the business analyst avoids making blind assumptions about requirements, Failing do so creates a risk of ending up with a “white elephant” as a solution.