Download to read offline
Visualization Requirements Speech
- 1. Visualization to Improve SDLC Efficiency Requirements -Greg Garner Techniques www.RequirementSpec.com
- 2. What I WillCover • Identify a Problem • Considered How We Communicate • Consider Text Based Approaches • A Vision for a Better Way Through Visualization
- 3. Identifying the Problem • StandishGroup CHAOS Report, 2009 • 68% of all projects fail • 44% were challenged • 24% cancelled prior to completion
- 4. Identifying the Problem • Missingthe Mark • Who reads text based items? • Have to wade through the mud to get to what is required
- 5. Identifying the Problem • Missing the Mark • Must See it to Know if it is what I want • Developers Ignore Requirements Documents
- 6.
- 7. How Do We Communicate? •5 Senses • The Visual Medium • Text • Color • Pictures • Video • Spatial Connection
- 8. How Do WeCommunicate? • A Picture Is Worth A Thousand Words
- 9. How Do WeCommunicate? • A Picture Is Worth A Thousand Words
- 10. What are TextBased in Software Reqs? • It’s not just Reams of Word Docs • It’s also Text Based Use Cases
- 11.
- 12. Subject Matter Expert Architect
- 13. Subject Matter Expert Architect Visual Starting Point
- 16. Subject Matter Expert Architect Visual Starting Point Visual Use Case
- 18. Subject Matter Expert Architect Visual Starting Point Visual Use Case Hot Spots and Navigation Links
- 29. Subject Matter Expert Architect Visual Starting Point Visual Use Case Hot Spots and Navigation Links Text Based Requirements
- 31. Subject Matter Expert Architect Visual Starting Point Visual Use Case Hot Spots and Navigation Links Text Based Requirements Iterative Walk-Throughs (SME, Development, Q/A)
- 32. Subject Matter Expert Architect Visual Starting Point Visual Use Case Hot Spots and Navigation Links Text Based Requirements Iterative Walk-Throughs (SME, Development, Q/A)
- 37. Subject Matter Expert Architect Visual Starting Point Visual Use Case Hot Spots and Navigation Links Text Based Requirements Iterative Walk-Throughs (SME, Development, Q/A)
- 38. Subject Matter Expert Architect Visual Starting Point Visual Use Case Hot Spots and Navigation Links Text Based Requirements Iterative Walk-Throughs (SME, Development, Q/A)
- 43. Why Is ThisBetter? • Building Context in the Mind’s Eye
- 44. Why Is ThisBetter? • Building Context in the Mind’s Eye • Visual Model
- 45. Why Is ThisBetter? • Building Context in the Mind’s Eye • Visual Model • To-Be Differentiated from As- Is
- 46. Why Is ThisBetter? • Building Context in the Mind’s Eye • Visual Model • To-Be Differentiated from As- Is • Think Properly With Use Cases
- 47. Why Is ThisBetter? • Building Context in the Mind’s Eye • Visual Model • To-Be Differentiated from As- Is • Think Properly With Use Cases • Text Based BE GONE!!!!!
- 48. Why Is ThisBetter? • Building Context in the Mind’s Eye • Visual Model • To-Be Differentiated from As- Is • Think Properly With Use Cases • Text Based BE GONE!!!!!
- 49. Which Is Better? •68% of all projects fail • Requirements cycle is reduce d by at least 30%. • 44% were challenged • Requirements defects are reduced by at least 80%. • 24% cancelled prior to completion • Project delivery times are 35% faster OR?
- 50. Need For Leadership •No One Likes Change • People Naturally Resist Change • Are your Requirements Valuable? • Are we Producing Items For No One that Cares? • Invest Where it Matters
- 51. What Have We Covered? •Identified a Problem • Considered How We Communicate • Threw Out Text Based Approaches • Gave a Vision for a Better Way Through Visualization
- 52. Questions? Contact Me: www.RequirementSpec.com Visualization to Improve SDLC Efficiency Requirements -Greg Garner Techniques
Editor's Notes
- #2 My name is Greg Garner. I have my PMP, have worked in a .net development lead position and currently am working as a Business Analyst in a web-based Healthcare company.\n\nMy perspective is a bit different than most in that I’ve owned my own business’ for years and thus approach problems from an owner’s-mindset.\n\nThank you for allowing me to talk to you today.\n\nNEXT SLIDE\n
- #3 Back in the 80’s I was enamored by System Analysis and Design. It mainly consisted of data flow diagrams and the web was barely beginning to emerge. That was the first time I saw the power of connected logic in a visual medium.\n\nSince that time I’ve been involved in countless projects and companies that have produced tons and tons of text and boring documents all in the hopes of capturing all the details for our poor over-burdened developers to create something off of.\n\nNow I’m tired of that rat-race and so today I want to revisit what we all know about failed projects, and approach the problem from a simple common-sense - “what works for me in everything else I do” way.\n\nI want to compare that with the text based approach that most software projects are strapped with and then show how I’ve implemented a simple methodology to do it better.\n\nIt is my hope that you’ll find some simple concepts here that can radically change the way you gather requirements for software so that it all falls in place as it did for me with these concepts, on my projects.\n\nIf you remember just one thing as you leave here today remember that the future is about visualization and not text-based requirements.\n
- #4 According to the Standish Group Most Software Projects Fail.\n\nProduct doesn’t get what they envisioned\n\nPMs & Analysts create documents that are rarely used\n\nAnd we get something like what you see here - a haphazard mishmash of a product.\n
- #5 Developers can’t develop because of ambiguity in requirements\n\n& Users don’t use the technology – it misses the mark for them\n\nSome other pain points in requirements development are:\n•That No one has time to read text-based requirements – and hardly anyone really does.\n•Also, What is required is not immediately evident – you have to read everything and then go back to the author to get the picture before making the requirements even partially useable for your development process. - I don’t know how many times I have developers take my functional requirements, cursorily look over them, verbally approve them and then start talking to everyone else to figure out what they need to know to begin coding.\nHow many times have you got a word doc where you have to put your finger on a use case on page 5 and then flip to page 25 to see the user interface and at the same time get your finger on page 15 to see the requirements that support that use case - it’s just crazy and not really in this century anymore to have to fool with paper documents.\n\n\n\n
- #6 What we want may be clearly stated in these documents, but what ends up getting developed comes out in a way that misses the mark. How could that be with so much detail?\n•IT IS BECAUSE, Business Users Don’t know what they want until they see and interact with it. This typically only happens during QA or user acceptance testing when it’s far too late and far too expensive to make any difference at all.\n•Developers tend to ignore carefully developed requirements documents and do their own analysis. How can an analyst become indispensable to the developer versus just being another bureaucracy that developers have to navigate around to get to discrete programming of functionality?\n If we want a different outcome then we need to change the approach. We need to change the way we communicate requirements from the business to the development community.\n\n\n
- #7 So I asked myself the simple question, \nWhat is the best way to communicate anything? How do I learn best?\n•My Premise is that the more we go from a static representation to a dynamic representation the more we will end up in reality.\n•We see this in the maturity of communication mediums as shown here. From the dark ages where we had criers in the street, to written words, to radio, to TV, to digital, now to virtual reality. \n•We all live in real-time, so why not model in real-time?\n\n\n\n
- #8 •We all interact with people through our 5 senses – with touch, sound, taste, smell, and sight. With software we essentially only have sight and maybe a little bit of sound to work with for the most part. So if sight is the main interactive medium I want to capitalize on what communicates to someone in the fastest way using this medium.\n•So what do I have at my disposal to work with in the visual medium? \noWell of course se have Text\noVery few use Color\noThere’s Pictures\noVideo\noand what I call Spatial connection – 3d, seeing what connects to other things in space\n\n\n
- #9 •I would suggest that text based communication is the least useful medium for communicating. It is also the last medium learned by the human child for communicating visually. \n•On the other hand spatial connection is the most useful medium for communicating to human how a system is connected. Video, pictures, & color are some of the first things human children experience and understand, even before understanding anything verbally.\n•They say A picture is worth a thousand words – So I say, communicate visually throughout all parts of the business, and make the development process fun, fast, and financially more cost effective.\n\nStory: PICTURE WORTH A 1000 WORDS: If asked to describe what a person looks like in writing one would have to write a book describing the color of their skin, the length of their hair, how tall they are, etc. This process is expensive and you only get that boring book at the end of it. \n\n\n
- #10 Alternatively one could simply show a picture of the individual and the picture is self describing. After showing a picture one may only need to give a few clarifying details like Height and Weight to be discrete in their requirements, and that’s it.\n\nSo we know that we need to change our approach, and we know that we aren’t communicating optimally with a text-based approach.\n\n
- #11 ♣What are text based, in software development requirements?\n•It is fast becoming known that lists of disparate, non-connected requirements, even if grouped logically, are not the best medium for communicating requirements.\n•Use cases are great in that they visually show actors and goals. However, they break down to the lowest level of communication medium when one goes into the textual based steps of the use case.\nEveryone loves a use case diagram and most people groan at a use case text blob. When reading the typical unspoken word is, “just freaking show me the thing.”\n
- #12 So I’m proposing A BETTER WAY - I want to create requirements real people will use and do away with all the other stuff that doesn’t add real value.\n\nWhat I’m going to do now is illustrate some of the concepts of how I build requirements in a visual manner. Throughout this walk-through I will continue to build a process flow as shown above.\n\nSo First, one should meet with “ONE” primary stakeholder who can best describe the vision, direction, visualization, and system goals in the most complete efficient manner. This really goes against the concept of confusing chaotic JAD sessions with multiple stakeholders. \n\nJAD sessions are typically led by PMs wearing the hat of a BSA. It feels more like a church business meeting than a useful requirements session. The outcome of these sessions is a whole list of ambiguous requirements. The JAD approach is mostly a left-­‐brain exercise. That is not  a bad\nthing of course, but when people talkabout their needs, they visualize it in their mind’s eye. Because everyone visualizes things differently, ambiguity and misunderstanding is introduced. It is long understood in education that people learn more effectively when both the left and right brain are engaged.\n\nLeaders provide order out of chaos - meeting with one person and getting a draft model put together can cut out a ton of confusion.\n\n
- #13 \nFrom this meeting I go to the next step. \n \nI want to place some Caution here that one should be sure to run everything by verbally with your system development architect, up front, before wasting time building something that is not supportable.\n
- #14 I then Start with the most visual element of the Project in mind - say a Website Landing Page. From this I will build context for the functionality. Building Context is a key part of this methodology. \n♣Every system - business or functional is either UI driven or can be illustrated with a visual process of some type.\n♣Probably 90% or more of software development projects revolve around or involve a user interface. So start on the screen where the user will interact with the system for the functionality you are going to build.\n♣If you are dealing with the 10% of software development that doesn’t involve a UI, then use the UML Actor and Use Case Goal visual depictions to create your visual starting point.\n\n
- #15 Keeping my starting point in mind, I want to build my visual use case. So I start doing that with a traditional UML diagram.\n\nIn this particular case I am showing my high level business use case at the top “Provide a Program” and an extend business use case “Provide a Challenge”. Off of that use case I have 3 system use cases that make up the Challenge - One can Join the Challenge, Interact with the challenge and configure the challenge.\n\n\n
- #16 From this model one can hyperlink to the next page using the link at the right where all the lines are pointing to.\n\nNote that hyperlinking from a hotspot is another key concept to this methodology.\n
- #17 So far I’ve met with one SME to get the main concept, run it by my architect, and then found my visual starting point.\n\nI am now going to deviate from typical UML Diagramming to show my Visual Use Case structure.\n
- #18 From the prior UML diagram you’ll recall seeing on the left side of this screen the 3 system uses cases of Join, Interact and Configuring the Challenge.\n\nThose 3 system use cases are now stacked top to bottom on the left, and here I have portioned off my visual Basic Path in the center and Alternate Path Realization Use Cases to the right.\n\nSo this is essentially a visual use case. I have a basic path and several alternate paths.\n \nIt is within these hyperlinked use cases that we will show the visual story board that takes users from screen to screen or activity flow to activity flow using hotspot hyperlinking.\n\nFrom here We are going into the Top Basic Path realization use case for “Join the Challenge” in the center swimlane as pointed to by the black arrow. This will realize my visual starting point for this Basic path.\n\n
- #19 So I’ve met with one SME to get the main concept, run it by my architect, then found my visual starting point and have now structured my visual use case.\n\nIn my process I am moving from beginning to build a visual use case to framing in the hyperlinked hotspots that give my wireframes a sense of prototype for the purpose of building context for navigation.\n
- #20 Immediately we are dropped into mockups that are familiar, visual, and in context with each other.\n\nNote that I am only building the amount of mockup needed to communicate functionality.\n•So now Working with my business definition folks, I now define as much detail as they know they want – ie. drop down boxes versus radio buttons, placement, coloring, etc. \nI always make a point to let my users know that whatever I mockup is only suggestive for design and not meant to dictate design. IT is meant to dictate functionality.\n•In this case I am focusing on changes to the left and right navigation primarily as shown by the black arrows.\n\n
- #21 It is interesting to note here several things:\n Any requirements that are needed beyond what is self-evident in the visual is placed on the mockup with its corresponding screen. As seen here requirement 8054 talked about overall branding needs and was most appropriately placed in my mind at the landing page in the basic path of my visual use case.\n I made a requirement here because the details of branding are not self evident in my visual.\n
- #22 In the top left we have a “back button” navigation to return the user back to the prior screen.\n \n While such a no-brainer simple concept, This maintains context with the visual use case and with the system navigation.\n It is these simple ideas of using click through hot spot navigation to prototype functional mockups that takes us away from that crazy activity of having to keep our fingers on 3 pages of a 100 page word doc to figure out what is required to build.\n
- #23 On this page, Links that take the user to the functionality that I want to focus on in the basic path are provided as shown here with the black arrow. So from a use case perspective we have\n the system shows the landing page, as the first step\n User clicks on the “Join the Challenge” link in the right hand navigation, as the next step\n System shows the Challenge page, next\n Finally, User clicks the “Join Now” button, which would take them to another page.\n We don’t need to dictate this to a text based use case. It has all the elements that we want from a use case. The only difference is that we marry the actual visual experience with the steps of the user and the system.\n \n ISN’T THIS BETTER?????\n
- #24 There are also links – like the center one in the right that can show configuration system user interface details for this screen.\n So if I click on that link - or you could call it an extension path - then I will see that configuration screen in my configuration system UI.\n
- #25 See how this provides so much more in-depth information than one would get in a typical use case text line.\n Now if we use the provided back navigation to go back.\n
- #26 We can see Other useful definition items that can be shown as seen through the left link as follows:\n\n
- #27 Here I placed a table that helps describe the left navgiation links depending on the state that the user is in at the time.\n\nAs mentioned – the real power here is in the identification of the hotspots that pertain to the case you are in and building in click-through functionality – this creates the pseudo-prototype.\n\nSo let’s traverse back up through the navigation hotspots to get back to where we started.\n \n\n
- #28 We’ll hit the back button here.\n
- #29 So from here we had gone down the Basic Path for “Join the Challenge” using the center swimlane. \n\nAs you envision alternate use paths that are not self-evident in the basic path - go ahead and visually build them with their starting points here in the right swim-lane.\n\nIn this case we would build them out in the same fashion of the basic path but use the right hand swimlane alternate path hotspot visual points - you see 5 of them here.\n\nOne thing to note on this screen is the functional requirement 7957 which was declined and is obviously declined in its status since it is in a Red color.\n\nAnother item I want to point out is that if I have functional requirements attached to screens in the basic path that could be repeated in alternate paths, I choose to only put those items in the basic path - this clears up a lot of clutter and keeps the detail on the basic path. Alternate paths show the concept of the alternate and I don’t need to repeat the details on those paths that I showed on the basic path.\n\nNow Since I have built a visual use case, why waste any time building a text-based use case? If you show all the steps in a visual process – why duplicate the wheel to do it again in a text based use case just to check the box to say you did it - it creates no value add for anyone? Alternatively why create activity flows if you have this visual use case - it is just redundant. Now If QA says they need the word doc - then encourage them to visualize and create their test cases from your visuals. They shouldn’t be using your text based use cases as crutches anyways for their process, right?\n\nFor whether or not I should add additional modeling - ie. text based use cases or activity flow in the case of my user interface experience modeling - I ask myself the question, “Does what I have modeled so far communicate what is needed for my audience?” If I have shown all the visual paths then why waste time on a text based use case – does it add value to communicate requirements more than what I’ve already modeled? If not, don’t do it. The goal is to do the least amount of communication and modeling required to completely communicate the requirements and the intended functionality both upstream to the business and downstream to development. REMEMBER - A PICTURE IS WORTH A THOUSANDS WORDS.\n\n
- #30 So far I’ve met with one SME to get the main concept, run it by my architect, then found my visual starting point and have now structured my visual use case. Along the way I’ve added hotspots and navigation links and visuals such as screens, excel tables, and links to other configuration systems to build context.\n\nAs you may have already noticed in the building of the visual use case I was adding text based visual requirements as needed.\n\n
- #31 oAlong the way one may have details that need to be defined to give a developer sufficient information to develop the functionality, beyond just what is self evident in the visuals.\noSo Decide if the visual is “self-evident” and don’t create textual functional requirements for those self-evident pieces. Why waste the time? In this case I don’t need to write a text requirement for describing that there are 6 text boxes and a submit button on this screen - it is self-evident on the mockup screen.\noFor anything else that can’t be readily “seen” as self-evident visually, then go ahead and create a textual functional requirement, but attach it in relation to a hot spot on the mockup or attach it to the screen in play, so there is no ambiguity about the context of the functional requirement. Functional requirements outside of the context of screens, use cases and/or activity flows are in many ways disconnected and non-useful requirements. What good is a listing of -functional requirements when you don’t know the context of the screens or activity flows that they relate to?\noIn this visual we see some text-based requirements on the left hand side. The difference in the way these are used and how most projects use them, is that these requirements will not typically be viewed outside of the context of the screen or use case or activity flow to which they pertain to. Also note that any definition shown on the screen is not described in a requirement – the screen itself, the navigation and hot spots, are themselves requirement elements, and it is self-evident to what is being required throughout the visual. One other thing to note is that one can attach any supporting documentation into the visual use case at the point that it is relevant – in this case at the top I have a link that is not apart of the basic path but again shows a configuration screen for this public facing user interface - providing additional detail and context for the person viewing the requirements.\nI’m not advocating doing away with all functional text requirements. I’m simply expanding the definition of a requirement to include screens, uses cases, links and other artifacts that visually describe functionality in a more robust way.\n
- #32 So far I’ve met with one SME to get the main concept, run it by my architect, then found my visual starting point and have now structured my visual use case. Along the way I’ve added hotspots and navigation links and visuals as well as dropping a few text based requirements visually next to the screens or elements they describe, only if needed - ie - the screen or activity flow was not self describing by itself, so it needed a text based requirement to fill it out and make it complete.\n\nNext, I would want to Conduct iterative user walk-throughs with larger and larger groups of SMEs \n \n
- #33 Seeking approval of every requirement element - \n
- #34 That includes Screens\n
- #35 Links off of those screens\n
- #36 . . . and each functional requirement\n\nAll of these items \n
- #37 . . . including my use case diagram are elemental functional elements that need reviewed as individual elements and approved by my stakeholders - be it product( or the business), then development, and finally Q/A, as individual elements.\n
- #38 oAs soon as a major concept is modeled – I walk my business stakeholders through it and ask “is this what you had in mind?” \nNote that I don’t wait for all concepts to be modeled before doing this - that builds agility into your process.\noYou can Change things on the fly and publish the changes immediately. \noYou can Obtain approval and/or capture issues, comments, new functionality, and changes on the fly.\noOne can Update text based and color based status indicators and communicate to development and the team that anything in the approved green status can be worked on immediately.\noRemember you met with one SME to get the vision. So your first walk-through is with them. \n
- #39 After that meeting, and another revision on your part, meet with all your product SMEs or business stakeholders. Once they all approve, bring development in \n
- #40 Finally, after development and the business are in agreement, bring in Q/A.\n\nNote the last step in this process shows the Mona Lisa being developed from ideation in small parts to the whole - that is agile, right?\n\nThat is the great concept I want you to catch here. We can get approval on any element (screens, links, text requirements) and still have many other elements outstanding in non-approved status. However, that doesn’t stop us from releasing what is approved and allows development to begin their work immediately on those items.\n\nNo more should we hear from a development manager, “well, we cannot provide you a development estimate on your requirements, project manager, until you baseline them all in a waterfall fashion.” \n\nNow we baseline on each element and each path of a use case, and once agreement is obtained from all decision makers we can immediately develop on those elements, while we continue to work to finish all the other requirements and get approval on those in play.\n\n\n
- #41 \nWhile we are here I’d like to open up one of the visual elements - could be a functional requirement, could be a screen, could be a link from one screen to another. In this case its a text based functional requirement and here is a view to the details of that element.\n\nIn the requirement here I want to highlight that change control can be obtained by using coloring and versioning (the numbers in brackets). \n\nIn this case I am at version 2.2 of this requirement, and down in the text comment box I show a date and change control notes at the top and in the text you see anything in blue with [2.2] to the right is added and anything in red is considered deleted with the same [2.2] notation to the right. All within the context of the elemental requirement in play.\n\n\n
- #42 Once approved, the status can be changed to green approved and that element is cleared for development. On this project approval was done by the business and by development lead on this one element.\n\nSo although many other requirements and elements are still unapproved, around this requirement - maybe even on the same user interface page. On this one, development can go ahead and begin their work immediately.\n\n
- #43 ♣Why is this way different – why is it better?\n
- #44 \nIt’s better because, It builds context and never breaks context. \nMuch more important than showing functionality with a long list of text-based requirements, is showing context that the functionality sits within. If we fail to show context we fail to communicate why we are building functionality. \nI don’t question where this functionality sits in the system as I navigated to the functionality either through the User interface, use cases and/or activity flows. I know where the functionality sits. \nNo one on my team - be in business users, end users, UAT testers, or development wonders what I’ve asked them to build.\n
- #45 •This method models the system in the way we best understand it in reality – visually with screens and connected with hot spot navigation. \nThe web has changed the equation for requirements definition in that we now have tools that allow us to model in a visually connected way with hotspots and the ability to publish to a web-site for no-license navigation by our stakeholders. Let’s capitalize on this technology on our projects every time.\n\n
- #46 •This method puts functionality directly into context within the existing system. \n We see all the requirements from the perspective of the activities (in activity flows) or the screens (in UI) in the existing system. \nWe have context because we know how we got to the functionality from the starting point – ie. landing pages of a system or use cases.\nWe can see what is existing and what are new functionalities in the context of the as-is existing system.\nThis method Clearly demarks existing functionality from new functionality.\n
- #47 •With this method, We see all modalities of the functionality using use case methodology, understanding the typical basic path and all alternate paths a user could or should take.\nUsing use case methodology we can assure ourselves that we are thinking properly in the sense of fulfilling user’s goals and not being driven by just the UI elements.\n\n
- #48 •Also, We do away with text based listing of requirements as much as possible by capitalizing on the visual nature of the requirements. We don’t have to describe functionality for a screen that is self-evident in the picture.\nYou’ve heard people talk about chemistry and biology in this way. When asked what is the molecular weight and symbol for Gold, one can throw out a memory item or one can know where to get the information. What I’m doing is connecting everything so that one knows where to “get the information” on the functionality being asked for. Having a text based word doc is like trying to memorize the periodic table and then spit out in code in a user interface. THAT’S CRAZY!\nNo wonder our projects fail so much>>>>>\n
- #49 With this method, We can capture user’s changes dynamically as they make them and turn around approvals faster with as close to “real-time” change as possible. Walkthroughs are unambiguous.\n\n•Agility achieved by \noIdentifying all approved items clearly as they are approved and releasing development onto those items immediately. \noModeling can be done in real-time or in short review cycle sessions. \noWaterfall waiting and huge JAD confusion sessions are kept at a minimum. \noNavigation is clear from the start.\noElement level approval versus document FRS level approval is achieved – we can cut off the waterfall and quit looking all wet on our projects.\n\n
- #50 \nAnd most importantly the results achieved are simply amazing.\n\nWhich would you rather be apart of making - this shelf on the left or the one on the right.\nWhere 68% of all projects fail, 44% are challenged and 24% canceled.\n\nUsing Visualization teams are seeing \norequirements cycles being reduced by 30%.\no defect reduction by 80%.\no& Project delivery times coming in 35% faster\n\n
- #51 •Despite all of the compelling reasons for why we should consider visualization as a better way to define requirements for software development there will be those that will resist.\n•This is where we need to hold to our guns.\n•No one likes change and many people have a lot of time and investment into text-based processes that they aren’t going to want to give up on.\n•STORY: It is like asking people that have been riding bikes for years to consider a car that they have no concept of. They won’t stop using their bike and drive the car until you show them how to use it and give them a ride a few times. Once they catch on they likely will never go back to bike riding. People don’t know what they are missing if they’ve never had it. This methodology is just like that.\n•That is why it takes leadership to say “let’s try it” and then stake a project’s success on it.\n•Most organizations do all kinds of work just because that is the way we’ve always done it. Is having your requirements in a flat 1 dimensional text-based format just like that? We have to get to activities that add real value for those involved. \n•I think this is like my checkbook. STORY: I used to worry about every penny and reconcile every month. I’d spend hours doing this over several personal and business accounts and it really stressed me out. One day I stopped and asked myself – for whom is this activity for and what value does it add to me? When I thought about it I realized that reconciliation for the most part was for me to have proper accounting for the IRS and for tax time. My needs were that I needed to know there was money in there to pay the bills, that I was saving for future goals and to some extent I wanted to know how I was spending for budgeting purposes. Once I realized that the reconciliation process was more for the IRS and banks needs than my own I quit doing it. I don’t care about their needs. I still track my expenses by categories but I don’t care if I’m off by a few hundred dollars – who cares – I don’t. \n•In this same way we need to look at our requirements management processes and really see if the work we are doing is hitting or missing the mark for upstream and downstream stakeholder’s needs. \n•I’d propose that no one looks at old requirements and text based word documents – so don’t invest there. Invest in activities that communicate the requirements in a visual way and hit the mark for getting it right the first time.\n\n
- #52 So in my short time here I think we could all agree that most traditional software approaches are not working to achieve the results we all expect.\n\nInstead of approaching the problem from a SDLC approach I’ve simply considered the audience and how best to communicate to them.\n\nThis lead me to strongly believe that visualization is the common sense approach to all forms of best practice communication.\n\nI built my methodology around that premise and with the dynamic nature of web click through have been able to show you a much better way to gather and communicate your software requirements. Of course there is much more detail to all of this that I haven’t shown, but you get the idea.\n\nThey say A picture is worth a thousand words – So I say, communicate visually throughout all parts of the business, and make the development process fun, fast, and financially more cost effective.\n\nSo, as you leave here today, remember that the future is about visualization and not text-based requirements.\n\n
- #53 Do we have any questions.\n