Tag: Facilitation

Requirements Inspiration From a Surprising Source

Written by Angela Goldman on April 5, 2016. Posted in Articles. 1 Comment on Requirements Inspiration From a Surprising Source

Last year, while studying for the certification exam, I started to see everything in CBAP terms. Cookbook? Requirements document. IKEA assembly instructions?

Functional requirements with process diagrams and mock-ups. 10 Commandments? High level requirements. And so on.

In my spare time, when I wasn’t trying to learn the 34 commonly used requirements techniques or all the task inputs and outputs, I would relax by knitting. I am a serious knitter who takes classes to improve my skills when time permits. A few years ago, attended a 2-day workshop titled Japanese Pattern Boot Camp (really!) to learn how to read those intricate and innovative Japanese knitting patterns that are rarely translated into English.

I wasn’t sure how the workshop could teach me how to read a pattern written in the logographic system of kanji, but I was utterly delighted to learn that Japanese patterns are among the most ingenious and concisely written requirements documents imaginable.

JAPANESE PATTERNS AS MODEL REQUIREMENTS DOCUMENTS

Here is a sample Japanese sweater pattern from Pierrot Yarns which has kindly permitted the use of their pattern in this article.

Since most of you are most likely neither knitters nor literate in Japanese, let me point out the many admirable characteristics of this requirements document.

HIGHLY VISUAL. As you can see, a Japanese pattern is short on words but long on graphics, unlike English language patterns which tend to be just the opposite. This single page contains the entire pattern. In contrast, this pattern could easily take 3 or even more pages if written in the older style of , English pattern writing.

{module ad 300×100 Large mobile}

So, what do these graphics represent? Anyone who has ever made a garment would recognize that the top 3 diagrams represent the back of the sweater, 1 side of each front, and a sleeve. The bottom 2 charts show the pattern stitches used when actually knitting the garment.

UNIVERSAL MODELING LANGUAGE. How in the world is anyone to know what the squiggles in those charts mean? There is a standard set of symbols (a knitters alphabet, if you will) that are universally understood. Furthermore, there is a common understanding of how to follow a chart. While in English, we read from left to right and then top to bottom, knitting charts are meant to be read bottom to top and tracing from right to left and then back again. That may seem bizarre to you, but this is the standard way that knitters read charts the world over.

Related Article: A Process Approach to Requirements Gathering

IMMEDIATE TRACEABILITY. On the diagrams of the pattern pieces (top row), you’ll see that there are (a) numerical notations, (b) arrows, (c) the letters “A” and “B” and (d) vertical and horizontal bars with lines through them. The arrows indicate whether the section is to be knitted from the top down (↓) or the bottom up (↑). The “A” indicates that the stitches in the chart labelled A (i.e., the one on the left) should be used in that section. The sections with a “B” in them should be knitted with chart B.

The bars at the top and side show the finished measurements in centimeters of each specific section of the garment. The beauty is that the since the requirements are noted next to the relevant area, there’s immediate traceability between the requirement and the relevant portion of the diagram. No need for a traceability matrix!

CONSISTENT USE OF STANDARD NOMENCLATURE. It’s possible to figure almost everything out without tackling the Japanese characters, but they’re not completely avoidable. Fortunately, there is a very well-defined, limited vocabulary of knitting terms that are used consistently across all patterns. Using the single page of terms in this Japanese-English Knitting Dictionary, one can decipher just about everything on a pattern.

STANDARD COMPONENTS OF REQUIREMENTS. Even using the dictionary linked above, it would still require an enormous effort to search through the page for every character on the pattern. Happily, that is not necessary since there are standard components of information presented in a standardized layout. At the beginning of every pattern, there’s always

a list of required materials (i.e., inputs): yarn amounts and fiber, needles of a specific size, possibly buttons or trims
the gauge of the stitches. Gauge is the number of stitches and rows per inch you should achieve
measurements of the finished garment (key indices, so to speak): chest circumference, sleeve length, body length, etc.

Knowing what to look for limits the vocabulary to be searched, and just helps one get oriented

“JUST ENOUGH” DETAIL. Japanese patterns do not provide any more detail than is absolutely necessary, and assume you have a certain base of knowledge with which you can fill in the blanks. All that is provided are the key requirements needed to produce the final product.

KEY TAKEAWAYS

Probably only a few of you are knitters who will be inspired to start using Japanese patterns. However, I think that there are several principles that can adapted to improve our requirements documents.

Use visual models to facilitate understanding . Process flows, context diagrams, data diagrams, and other models can effectively and concisely convey requirements more succinctly than pages of text. This is particularly valuable when working with team members who are not native English speakers. I highly recommend Visual Models for Software Requirements by Joy Beatty and Anthony Chen to learn about different models, how to construct them and where each type of model is most appropriate.
Define your terminology and use it consistently. Do not alternatively refer to a business unit as a “group”, a “team” and a “department.” Those terms may be synonyms to you, but they may mean very different things to your audience. Ideally, maintain a glossary used by different areas, so everyone starts adopting the same nomenclature.
If possible, annotate your diagrams with helpful information or links to the relevant enumerated requirements elsewhere in your document.
Consistently use a standardized format. Many organizations already have a standard template, and that’s because it enables readers to find readily what they need to know
Provide “just enough” requirements at the appropriate level of detail for your audience. You may have to go through several iterations to ensure that everyone has the information they need.

REFERENCES:

1. “98-3 Lace Cardigan,” © Pierrot Yarns (Gosyo Co., Ltd), accessed 23 March 2016, http://www.gosyo.co.jp/img/acrobat/98ss/3.pdf.
2. “Japanese-English Knitting Dictionary”, accessed 23 March 2016, http://www.tata-tatao.to/knit/japanese/e-JapaneseEnglish.html
3. Joy Beatty and Anthony Chen, Visual Models for Software Requirements (Redmond: Microsoft Press, 2012).

A Business Analyst’s Perspective: 7 Reasons for Project Failure

Written by Lavinia Mihaela Dinca on April 4, 2016. Posted in Articles. 1 Comment on A Business Analyst’s Perspective: 7 Reasons for Project Failure

Statistics show that the real figures regarding project success are not at all encouraging. Only 30% of projects are considered successful; the others are challenged oroutright failures.

How does one determine if a project is a success? From a project management perspective the answer is simple, the “Holy Trinity” – time, budget, and quality.

Reality indicates that things are more complicated. A good example is the construction of Sydney Opera House. From a project management perspective, this was one of the biggest planning disasters ever made. Initially budgeted at $7 million, it ended up in costing $100 million.

{module ad 300×100 Large mobile}

On the other hand, when you think of Sydney, the Opera House is an iconic building, immediately recognizable, placed on most tourist advertising leaflets, and certainly a complete architectural success.

The factors of success for IT projects are the same “Holy Trinity”, with a twist: quality should be defined from a business analysis perspective. Specifically, the delivered project must be compliant with both stakeholders and current business requirements. The last part is mostly overlooked because sometimes the stakeholders requirements don’t conform with reality.
Based on my experience as both business analyst and project manager, these are my top seven reasons for project failure from a business analysis perspective:

#1: Business cases are used ONLY to justify the need for the project

I’ve met many project managers and business analysts who don’t understand the importance of the initial project pitch, the justification of why the project is needed. All these people see this as a necessary evil to start the project, and they treat it as such. The practice of the pitch translates to creating business cases that make sense on paper to justify the money and project need. Sometimes it’s worse, the justification and business cases are valid, but the analysts fail to see the importance, and they don’t incorporate the requirements in the project. This is why projects fail to deliver any business value, even if they are considered successful.

Rule of thumb: all business cases must be covered by requirements.

#2: Missing stakeholders

This reason sounds like a rookie mistake and yet is so frequent I’ve stopped counting. Stakeholder analysis is usually disregarded by analysts because theory says the project manager should perform this task. Yes and no. It should be a combined effort for both project manager and business analyst, and more importantly, it should be revised.
Revision should also be the responsibility of the business analyst because they are in the unique position of noticing when stakeholders are missing during the analysis phase. Missing stakeholders translate in only one thing: missing requirements.

Rule of thumb: revise stakeholder list frequently during the project lifecycle.

#3: No user input

This reason is closely related to no #2, and I’ve debated if I should list it separately. Identifying a stakeholder doesn’t mean getting the user input. I’m going to argue this point with an example: a bank notified us, the end users, about their improvement of the internet banking system. No one believed them because they kept saying the same thing for two years.
The bank’s officials knew we were the stakeholders in the project and also the final users. Not once did they tried to see what our problems were, or verify their requirements with us.
The new internet banking system was a complete failure since end users had different expectations of what they wanted. This type of mistake often happens to businesses, and sometimes it’s even worse, when analysts end up gathering requirements from the CFO but never talk to Jenny in Accounts Payable, who is doing something only she knows.epartment managers don’t know everything, especially at the execution level.

Rule of thumb: talk with the stakeholders at all levels.

#4: Poor requirements and communication

Business analysis means mostly paperwork, not only client interactions. The way a requirement is described and detailed is very important. It has happened to all of us to know a topic very well, but when we try describing it to others, we fail miserably, mostly because we assume people should know some basic things.

The top reasons for incomplete requirements are a poor description, poor communication between business analysis and development team, and missing details. By missing I don’t mean they haven’t been collected (covered by points #1), they were, but the analysts failed to fill in the matrix regarding which business case is covered by which requirement.

Rule of thumb: assume nothing, describe and check everything!

#5: Requirements keep changing

There are many reasons why this can happen: the company is not mature enough and doesn’t have an idea of their own procedures or what they want, the business environment changes rapidly and requirements can keep up with it, or the legislation is missing or unclear.

From experience the following approaches help with this problem: detail the project scope accordingly, ask for a decision manager regarding any changes, apply penalties for changes, sign off on requirements more often, and choose the appropriate methodology, such as Agile.

Rule of thumb: less is more!

#6: Requirements not up to date with business environment

Some businesses or CEOs live in their own bubble different than the rest of the world. The business might still be successful due to inertia; they were in the business a long time and their name still has value. By the end of the project, the situation can change drastically and the project might be obsolete because the requirements don’t conform to the business reality.

Rule of thumb: check your information from third party sources.

#7: Project is a complete success, but no one is using it

The project is finished, all the requirements are met, but the application is not used at all. Most people blame the client for not wanting to change. No, the project failed to capture the real needs. Solve the needs/problems your client is facing and your project will be a success.

Rule of thumb: make sure the project is solving a need/problem.

This is my short list and I’m sure there are other several factors for business analysis failure. What do you think about this topic? What items would you add or remove from the list?

The Business Analyst’s Role in Project Closeout

Written by Brad Egeland on March 21, 2016. Posted in Articles. 1 Comment on The Business Analyst’s Role in Project Closeout

I’ve written about project closeout before and the need to plan well in advance for a complete and, hopefully issue-free, project rollout and closure. Planning well does not guarantee success.

If you have dotted all of your “I”s, crossed all of your “T”s, the requirements for the project have been followed and incorporated into the end solution, and user acceptance testing went off successfully, then you should be about as good to go as you possibly can be.

That said, there are some things the project manager, business analyst and entire team should be planning to do and running through especially as the project is winding down.

These are, at a minimum (but not limited to):

Reviewing all project financials
Re-reviewing user acceptance test (UAT) results
Checking all project milestones
Making sure all training has been successfully completed
Conducting and documenting a lessons learned session
Making sure all appropriate deliverable, UAT, and project sign-offs / approvals are in place

Where does the business analyst fit in?

{module ad 300×100 Large mobile}

We have a good list of some high-level project closeout checklist items to use to make sure the project work is complete, approved by the project client, and ready to be rolled out to the customer’s end user community. But what about the business analyst? They have intimate knowledge of the solution, the technical project team, the requirements, the customer and the customer’s end user community. They are that technical team and customer liaison and will be involved in everything associated with the project closeout planning, assurance, and rollout activities.

Let’s examine what roles in specific areas of project closeout activities that will logically be played by the business analyst on a technical project. As you read through these, please be thinking of ones not mentioned here – especially if you have experience with specific issues and concepts not mentioned – and be prepared to comment and share your own thoughts and experiences. For now, mine are:

Early planning for project closeout. This role should fall mainly to the project manager as it is a planning activity and will tie in heavily to the project schedule – which is under the primary charge of the project manager. But in terms of many of the detailed project tasks that must happen and what timing and effort will go into each, much of that input can and should come from the business analyst as their expertise and experience are vital to the proper estimation of the level of efforts for many of these tasks.

User acceptance testing. Here is an area where the business analyst will definitely shine and is crucial to project and client testing success. Don’t do the test cases and test scenarios for the project customer – that is a conflict of interest. But the project customer is nearly always weak in this area, and a poorly tested technical solution means the delivery team has a good chance of rolling out a final solution that doesn’t fully meet the customer’s end user community’s needs. That’s not good. So the good business analyst is critical to successful user acceptance testing. That individual can help the customer develop test cases and test scenarios, help walk them through UAT – figuratively holding their hand along the way as needed and help to gain that crucial UAT sign off / approval from the customer. Essentially, that becomes almost a sign off on the entire solution as the rollout is being prepared for because that is what they are testing. This one role is the key to success.

Milestone and deliverable review. Because the business analyst is involved to a high degree in all project milestones, and likely the production, review, delivery and sign off of all project deliverables, it makes great sense that this individual will be involved in the review and validation of completion and sign off of all project milestones and deliverables. This basically involves running through the project schedule and documentation file with the project manager – and maybe the full team – to ensure that all tasks were completed, all deliverables went to the customer and received signoff, and likely that all deliverables were paid for. Through my experience, however, the financial aspect is usually the sole responsibility of the project manager.

Conducting lessons learned. The lessons learned session is important to gaining insight into what pleased the project customer and what they perceived as not going as well as it should. While the project manager should facilitate this session, the business analyst will probably be the main commentator and communicator with the project customer team when specific tasks and activities of the project are discussed.

Rolling out the solution to the project client and end user community. Finally, the actual project implementation or rollout will be primarily led by the project manager and business analyst. The BA will mainly be a technical liaison – running down any issues, working the project technical team in issue resolution, and solution handoff. The business analyst did this during requirements, design and configuration of the project solution, and most assuredly they will be leading this effort on the ground during project implementation or rollout to the end user community.

Summary / call for input

I’ve said it many times, and I will say it again – some companies want to combine the project manager and business analyst role or the business analyst and tech lead role on technical projects. I think a good business analyst – performing the common duties of the business analyst – is too critical to the project’s success to be combined with any other role. Doing so only for very small projects or for very cash-strapped organizations may be an option, but it is not a good long-term plan on all projects. because the business analyst has usually played such a key role throughout the engagement, and as the project is winding down, their involvement in many aspects of that project close out is critical to the project’s overall successful ending. And, thus, customer and end user satisfaction, both of which are keys to success.

How about your thoughts? What do you consider to be key roles of the business analyst in the close out of the technical project – or any project for that matter? Please share your thoughts on this list and your additions and let’s discuss.

6 High-Value UX Techniques to Boost Your BA Role

Written by Steven LeMay on January 8, 2016. Posted in Articles.

A financial services company came to Usability Matters with a terrible problem. They had just rolled out a new platform for financial advisors and the advisors were furiously refusing to use it. Usability Matters was asked to help figure out what the problem was and how to fix it.

Not surprisingly, financial advisors at this company are on the phone speaking with their clients throughout day. Their clients call, a little chit chat ensues, and then financial matters are discussed. Advisors needed a tool that allows them to quickly pull up client information to support the banter– things like the client’s spouse’s name or the date of their last financial check-up – and then lead seamlessly into details of the client’s investments. The BAs on the project team had thoroughly identified all the needed information but it was so cumbersome to retrieve in the new design that when clients called, advisors found they had to hang up, look up the information they needed and call their clients back several minutes later. They ultimately refused to use the new platform because it failed to support the way they do their jobs. Plenty of grief all around.

In many ways, Business Analysts and User Experience (UX) professionals are two sides of the same coin. We both aim to create better, more successful products and services for our customers and we both liaise with the technical team to bring those aims to life. The difference quite often is simply one of perspective: where the BA typically represents the needs of the business, in UX we steadfastly represent the needs of the people who will use the product or service.

Every successful project needs both viewpoints, but in our example above, the financial services project team missed the user perspective – they missed the real-life needs of the financial advisors.

So let’s look at some typical BA activities and identify ways a UX perspective can add value to your BA role and help you create products and services that people will want to use.

BA ACTIVITY: DEFINE AND SCOPE BUSINESS AREAS

In this step, BA’s and UX professionals alike want to establish a shared understand of why the project is being undertaken – the project’s goals and objectives. Both roles help determine what the business domain is and who the key stakeholders are.

HOW UX CAN ADD VALUE

1. Identify User Goals

Get the project team thinking about your users right from the beginning. Identify, at least at a high level, who the users are and how the project will benefit them. No need to flesh out user profiles or personas at this step, simply document who the project aims to serve and make sure their core goals are recognized alongside the business goals.
Reach out to people who have the most direct contact with your users to gather insights. Often this is marketing, sales and support personnel.

The project model canvas can help you gather all of this on a single page.

BA ACTIVITY: GATHER REQUIREMENTS

This is where most of the BA’s insights and expertise are channelled – gathering accurate and complete requirements. From a UX perspective, we want to ensure that user requirements are included with the business and system requirements. Familiar techniques such as interviews, workshops and surveys are used and we supplement these with techniques that may be less familiar to BAs.

HOW UX CAN ADD VALUE

Try adding one of these to your next project:

2. Contextual Inquiry

Contextual inquiry or observation is a research method that provides rich insights into the context in which a product or service will exist. Spend a few hours watching how your intended users do their job, watching for key influences on their work and how your product or service will fit in to it. This technique may have helped the financial services example to stay firmly on the rails.

3. Card Sorting

Card sorting is an engaging, yet effective activity that reveals how users think about information. It allows the Business Analyst to match your organization structure and labels to the way users think of them. Simply create cards for all of the features or content elements in your project, ask people to sort them into meaningful groups and then provide a name for each of those groups.

BA ACTIVITY: ANALYZE AND DOCUMENT REQUIREMENTS

Business requirements documents are often the key deliverable from both BA’s and UX professionals but we always want to make sure this documentation includes a thorough understanding of our users and their needs.

HOW UX CAN ADD VALUE

4. User Profiles and Personas

Document who your users are. Often that takes the form of either user profiles or personas. User profiles tend to be more generalized and provide insights into groups of people. They are a great place to start but most UX folks prefer to take profiles a step further by creating personas.

Personas are usually a one page summary of a person’s behaviours, characteristics, and overall personal profile including name, age, marriage status favourite brands and technology use. They evoke empathy and they prevent thinking of generic ill-defined users that each project member imagines differently. To be effective, persona development must be firmly grounded in user research techniques.

Personas can also help objectively prioritise your requirements. Each feature can be assigned weighted values indicating how important it is to the business and to each persona. The result is a feature prioritization matrix that takes the guesswork and individual subjectivity out of the prioritization process.

BA ACTIVITY: DEFINE THE SOLUTION

The technical part of the solution is usually captured in process flow diagrams, system maps and data models. From the user perspective, it’s all about workflow, navigation, user interfaces, and interactions. Often a BA is responsible for all of these and may even create annotated wireframes.

HOW UX CAN ADD VALUE

5. Prototype Testing

Begin testing your ideas early in the process. With a little repurposing, wireframes can quite easily be turned into a paper prototype that can be tested with real users long before any code is written. Pick a few key tasks and ask people to try to accomplish them with your prototype. When they “click” on something with their finger, simply present the next screen on paper. If you can’t get real users, test with anyone you can – testing with anyone is far better than not testing. You’ll be amazed how these early insights have a major impact on the solution at little or no cost.

For a more realistic experience, try a prototyping tool and test your ideas as if they were the real system. There are great tools like Axure created specifically for this purpose.

BA ACTIVITY: VERIFY THE SOLUTION MEETS THE REQUIREMENTS

Often this step is the purview of Quality Assurance team with the BA providing support and expertise to the testing efforts.

HOW UX CAN ADD VALUE

6. Usability Testing

Usability testing is a qualitative technique that assesses not only if the solution fulfills the requirements, but also how well it does so. Ask some people – anyone if you can’t get real users – to accomplish a few key tasks and watch where they trip up. Test early, test often and smooth out those cracks in the sidewalk before formal user acceptance testing begins.

BONUS UX VALUE

7. Service Design

To add even further value to the BA and UX roles, we want to make sure that a holistic view is taken of all the user’s touch points with the business so that a harmonious user experience is delivered – you’ll hear this broader perspective referred to as service design or customer experience design.

The broader point is that the BA and UX perspectives are entirely complementary and hopefully we have given you the confidence to inject a little more UX value into your projects.

Dear 007 Why Do I Hate Documenting Requirements

Written by Marcos Ferrer on December 29, 2015. Posted in Articles.

Dear 007:

Why do I hate documentation? Every time I turn around, stakeholder ideas, preferences and decisions change. Now they want to change the name and content of half of the processes already modeled plus the related specs.

This affects over 300 pages of documentation including 17 Visio Use Case Diagrams, 12 Word Smart Art flowcharts AND requires some adjustments to the grouping and order of steps among use cases.

Every change to the model requires me to re-do a dozen drawings and find, search and replace dozens of references, some “acronymized”, some spelled differently, and some in (rats) pdf images, which don’t search. Don’t even talk about “re-tracing” new relations between requirements, that is a separate spreadsheet that I intend to hide so they don’t make me do it over.

How can I un-wreck the reqs docs without becoming a wreck? Change management isn’t the answer here. Most of the changes are important improvements, and quality modeling will weed out the rest. It was the quality of the currently documented model that stimulated the improvements, but success has ruined the model.

Sincerely,

Reed O. Rexorbust

Dear Reed O.

Your experience is quite normal for the document based requirements you describe. Your business stakeholders may not care – they are focused on the latest topic, and don’t read detailed models anyway, and “know what they mean” especially if it isn’t written down. Your implementation and operations stakeholders WILL care – wrong “detail”, wrong solution.

Two recommendations:

1. Follow BABOK requirements categories – don’t mix stakeholder wants with business / strategic requirements and be sure to segregate solution / design requirements from transition requirements (a discussion suitable to self-train a little on this topic can be found at this link).

2. Don’t store requirements in documents, generate documents from requirement stores. Below is a sample (very simple) use case model generated with an extremely affordable tool – Sparx Enterprise Architect. It is like VISIO on mega-steroids, a true database of requirements objects that can be turned into the latest document at the push of a button (and, you know, choose templates, give the document a name, blah blah). There are other requirements tools, but I bought this one because it did not require the whole enterprise to agree; Sparx EA can function as a “personal” BA tool, like VISIO, but it produces high-quality requirements documents on demand with minimal manual intervention. It is also a collaborative requirements work environment, but that is a DIFFERENT discussion.

As proof of concept, I invite (defy, even) my brilliant readers to comment on what is missing or just wrong in the model below. Go big (describe new effects or even new image instruments) or go small (I hate the blue titles).

I will incorporate ALL suggested changes into the model so that ALL may see the impact of the changes AND the ease with which the tool allows me to deal with said changes.

Management, of course, reserves the right to prioritize and evaluate changes for implementation, but we will simply capture them for discussion next month.

1 Imagenator – LightDrum – Use Case Model

Copyrights 1991, 2015 Marcos Ferrer

1.1 Vision

It is up to the Imagineers of the world to develop this tool, whether called LightDrum, Imagenator, C-ROD or whatever finally flies. The idea is inevitable, the implementers are not, so let’s get started thinking.

The primary architecture will be the visual language (see Appendix for specifications). Vusic (its invention) the key abstraction. Without limitations, visual performance may be spectacular (think psychedelia of all kinds or videos playing behind musicians). Such performances typically accompany live music yet typically lack nuance, improvisation, emotion and interaction that ARE characteristics of the music being accompanied (unlike the performance “Hydrogen Jukebox” by Phillip Glass, or the sophisticated uses of lighting in theater and film, or the singer / dancer duo Xia).

Music is typically limited to some scale of sounds with some mathematical relationship. Any sound might be a part of a piece of music (jackhammers, water running); sound, like image, has no trivial limits. AND YET, when music is not TOO inclusive, we often enjoy it most (pieces that have no key are interesting, pieces that move between keys are more interesting, and pieces that do their keys movingly are most beautiful of all. Music has the advantage of limitations – the musician can work with a finite set of auditory signals to create beauty in real-time.

Imagicians in today’s world must select from EVERY POSSIBLE IMAGE (or at least every possible image generator) for a visual performance. This is NOT real time, like music, and requires far more effort, planning, and execution. Imagicians can’t just sit down and “play image” to express beauty in most cases. Even those like myself who have written and used software to perform live imagery, have felt the narrowness of the expression instead of the universality of same.

This hasn’t necessarily hurt image performance. The biggest yell I ever heard for a single, simple “live” image was the crowd’s scream at a Grateful Dead concert for the “dancing bear.” It danced a goose-step march, mostly out of time to the music, but got superstar applause. The appearance prompted the scream, after a little bit it was dumb and boring, and needed to go away. The visual performer at the time could not have been less interested in improving the bear’s performance under live control (hi, Fritz, remember me?).

And I could not have been more interested. Twenty years later, no one is even working on this that I know of, even though image performance is BOUND to become a great art form in the future.

If you are an Imagineer that believes that live, visual, vusical language based performance is an idea whose beginning has come (we will not end it, just like the lute did not end music), this is the life project for you.

Anyone from:

https://design.osu.edu/carlson/history/tree/ani-software.html ?

Or anyone who finds this history interesting:

https://design.osu.edu/carlson/history/timeline.html ?

1.2 Develop / Deliver / Enhance LightDrum Architecture / Software / Hardware – Strategic Approach

It is premature to SPECIFY a specific development process, and yet the idea of continuous integration is hard to ignore. If every code check in every day leaves us with working software, the image instrument can only grow.

The idea is to provide reliable sensor polling “infrastructure” for developers to “plug-in” their contributions to the visual language. This approach allows wide collaboration while maintaining a central source of quality control. If the world helps build this, the world may adopt it as a seed, or even a standard.

2 Primary Use Cases

2.1 Primary Use Cases diagram

Use Case diagram in package ‘Primary Use Cases’

1.1 Configure (Tune) LightDrum

2.3 Configure LightDrum_ActivityGraph

2.4 Play LightDrum_ActivityGraph

3 Appendix – Visual Language Reference

Available on request – trade secret.

So there you have the model – what’s your feedback? Can you break the analyst? I say I am NOT scared of the re-do, of wrecked requs and will not bust. Prove me wrong with your comments below.

Thanks for reading!