Visualization through a live demonstration

Challenge    As a manager of a software development team, it is critical that I ensure that business

requirements are developed into functioning software that meet or exceed the expectations of  business users. This is critical for the company to continue to deliver products that will help the  company grow revenue and market share. One particular challenge with software development  is making sure that the developers have a very good idea of both the functional requirements  (push this button for this action) as well as the non-functional requirements (flexibility for  frequent change, particular font or styling for aesthetic reasons). Often times business users  cannot convey non-functional requirements without first seeing the results of their functional  requests. Visualization enables that communication.       Selection    Visualization is a helpful tool to allow business users to communicate to developers, and

also for the developers to communicate to the business users. One of the most common ways  that visualization can enable this two-way communication, is through a live demonstration. A  demonstration entails both developers and business users coming together to review and  experience the work of the developer. Often times this is an in-person meeting, typically a  conference type setting with a screen sharing session or white board session. A demonstration  can also be virtual, with only the developer and the business user. A good demonstration  provides valuable feedback to both business users and developers. First, it gives the business  user confidence in the ability of the developer to meet the business needs by showing a  prototype. Second, the developer gains confidence in their ability to understand the needs of  the business (both functional and non-functional requirements), when they receive feedback in  the demonstration after the business user has tested the prototype.      Application    After the business user has provided functional requirements, and the developer has

had a chance to produce a working prototype, a product demonstration should occur. This  demonstration allows the user to interact with the prototype to determine if the functional  requirements are understood (does the correct action occur when the button is pushed). The  demonstration allows for real-time feedback from the business user. The developer can get  answers to any outstanding questions, insight into the business value of the request, and also  valuable confirmations to continue the work. The demonstration also provides insight into the  non-functional expectations of the user (How does the product look?). A demonstration  enables the team to observe the business user interact with the product, and pick up on the  non-verbal cues (Are they happy with the work, are they confused with the work, or are they  unhappy with the work).     Insight    One of the most useful qualities of a demonstration is being able to obtain real-time

feedback from the business user. This is an opportunity for the business user to experience the  prototype, and determine if the business needs are being achieved. This is an opportunity to

validate the business request, and ‘see it in action’. A demonstration also can provide feedback  in the form of non-verbal cues, and provide the developer more insight into what the business  user is feeling about the product.  This particular insight cannot be communicated via a  requirements document, but only by person to person engagement.     Approach

Our development team has a demonstration every two weeks with our business

partners that range from 15 to 60 minutes. This regular cadence is critical to keeping progress  moving forward in producing important products for the company. There are times when a  demonstration is not an option for business user feedback. Another option available to the  team is to create a user acceptance document for the business user to complete. This allows  the business user to still interact with the prototype (on a schedule they can determine), and  also provides a method to give feedback back to the development team. As the development  team is responsible for creating the document, they can ask specific questions to help get the  right focus of feedback on critical areas. This is not as effective as a face to face meeting, but  will allow for constraints for teams that are not in the same location or perhaps not even the  same time zone.


Visualization through a live demonstration Challenge As a manager of a software development team , it is critical that I ensure that business requirements are developed into functioning software that meet or exceed the expectations of business users . This is critical for the company to continue to deliver products that will help the company grow revenue and market share . One particular challenge with software development is making sure that the developers have a very good idea of both the functional requirements ( push this button for this action ) as well as the non - functional requirements ( flexibility for frequent change , particular font or styling for aesthetic reasons ) . Often times business users can not convey non - functional requirements without first seeing the results of their functional requests . Visualization enables that communication . Selection Visualization is a helpful tool to allow business users to communicate to developers , and also for the developers to communicate to the business users . One of the most common ways that visualization can enable this two - way communication , is through a live demonstration . A demonstration entails both developers and business users coming together to review and experience the work of the developer . Often times this is an in - person meeting , typically a conference type setting with a screen sharing session or white board session . A demonstration can also be virtual , with only the developer and the business user . A good demonstration provides valuable feedback to both business users and developers . First , it gives the business user confidence in the ability of the developer to meet the business needs by showing a prototype . Second , the developer gains confidence in their ability to understand the needs of the business ( both functional and non - functional requirements ) , when they receive feedback in the demonstration after the business user has tested the prototype . Application After the business user has provided functional requirements , and the developer has had a chance to produce a working prototype , a product demonstration should occur . This demonstration allows the user to interact with the prototype to determine if the functional requirements are understood ( does the correct action occur when the button is pushed ) . The demonstration allows for real - time feedback from the business user . The developer can get answers to any outstanding questions , insight into the business value of the request , and also valuable confirmations to continue the work . The demonstration also provides insight into the non - functional expectations of the user ( How does the product look ? ) . A demonstration enables the team to observe the business user interact with the product , and pick up on the non - verbal cues ( Are they happy with the work , are they confused with the work , or are they unhappy with the work ) . Insight One of the most useful qualities of a demonstration is being able to obtain real - time feedback from the business user . This is an opportunity for the business user to experience the prototype , and determine if the business needs are being achieved . This is an opportunity to validate the business request , and ‘ see it in action ’ . A demonstration also can provide feedback in the form of non - verbal cues , and provide the developer more insight into what the business user is feeling about the product . This particular insight can not be communicated via a requirements document , but only by person to person engagement . Approach Our development team has a demonstration every two weeks with our business partners that range from 15 to 60 minutes . This regular cadence is critical to keeping progress moving forward in producing important products for the company . There are times when a demonstration is not an option for business user feedback . Another option available to the team is to create a user acceptance document for the business user to complete . This allows the business user to still interact with the prototype ( on a schedule they can determine ) , and also provides a method to give feedback back to the development team . As the development team is responsible for creating the document , they can ask specific questions to help get the right focus of feedback on critical areas . This is not as effective as a face to face meeting , but will allow for constraints for teams that are not in the same location or perhaps not even the same time zone .