Search Project Mgmt
Search FileMaker Blogs

Hello everyone! I decided that I wanted to actively blog again and share some insights around the business analysis domain. Topics here won't be just requirements but will include project management, agile, data intelligence and just about anything a fully functioning business analyst may come across in their day job!

Thursday
Jun042015

Is A User Story An Acceptable Requirement Deliverable?

Dwayne Wright PMP, PMI-PBA, PMI-ACP, CSM
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

Most seasoned business analyst will say that a user story is not the same thing as a requirement and recommend that the organization be aware of the difference between them. Many of the members of software development teams such as project managers, developers, agile coaches and even software testers may say that user stories are the only requirements they use.

A user story does one thing pretty well and that is to communicate one stakeholder need in a clear, consistent and concise manner. A comprehensive set of user stories that are presented in logical groupings can be a very powerful requirements package and help create great products.

The real problem can occur if the project or product has uncommunicated or unknown business, transition, functional or non-functional requirements. This may be a hard thing for some business professionals to understand but some projects are not ALL ABOUT THE STAKEHOLDER NEEDS.

In particular, 1.0 releases of software products, used internally within an organization, can potentially have a greater need to identify, document and communicate business, transition, functional or non-functional requirements. The 5.0 release of the product has the benefit of four other releases in which business, transition, functional or non-functional requirements have been defined and fulfilled. As long as the 5.0 release doesn't break one of those requirements, you probably don't need to invest a lot of effort in them. That 5.0 release can definitely get by with being top heavy on stakeholder requirements.

Tuesday
May262015

Personas And Attributes For Your User Roles

Dwayne Wright PMP, PMI-PBA, PMI-ACP, CSM
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

If you have ever had the desire to write fiction, creating a persona for your actors could be your gateway. Adding background stories, motivations, attitudes and other personality attributes to your actors can help flavor how they are documented in your requirements package. Although there is a natural desire to detailed information about the actors job description, these really isn't the focus of persona creation. The content is focused on a more personal level, after all jobs represented by actors are performed by people. Keeping the whole thing fictional in nature will help mitigate the risk that anyone will take this documentation as an insult or swipe at them personally.


Let's face it, you probably have more than one typical user that will be wanting or needing the benefits provided by the software product you want to produce. By creating a list of user types, let's say 10 different ones, you can create a more encompassing experience for your software requirements package. Later on matching these user types to defined scenarios, can give you a better idea of some of the intended and perhaps not intended interactions they may have with your software system.

I find that adding a persona to a user role makes leveraging it more interesting and more helpful in the long term. A persona is a imaginary representation of a particular user role. Many times it takes the form of a resume that will state the different attributes appropriate to the software project that your building.

If there are defined personas are embraced by the team, you may find that it drives a lot of your conversations. You may encounter something like a team member saying, "Bob wouldn't use it that way and I'll tell you why ...". You will then look around the room, and see that the entire team "gets it ". They understand what that team member was talking about in reference to Bob's persona.

In many instances you can get more mileage out of comparing personas then you can with two typically written user roles. This may sound silly but I have seen examples where the person documenting the persona goes out and does a Google search for a different faces. They find a face that looks adventurous and then apply that phase to the persona that they've written for the software project. So the idea is to humanize the persona that as much as possible. This can help in the visualization techniques for the accompanying scenarios.

Knowing the subtle and not-so-subtle differences between two roles, can go a long way to see how the scenarios will differ when those personas are applied to them.

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded.

Wednesday
May202015

The Software Product Expectation Gap

Dwayne Wright PMP, PMI-PBA, PMI-ACP, CSM
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

The expectation gap describes the difference between what a consumer of a work product expected and what they received. You can normally anticipate a larger expectation gap in situations where there was insufficient collaboration on requirement design between BA and stakeholders. If you look at the classic requirements decomposition model, you can clearly see where the expectation gap can be controlled.

Business Requirements  (not that relevant)
Stakeholder Requirements (highly relevant)
Solution Requirements
    Functional Requirements (not that relevant)
    Nonfunctional Requirements (can be very relevant)
Transition Requirements (normally not that relevant)

Although you would think business requirements would be highly relevant because they are the top of the model, they really are not. These requirements are so high level, the expectation gap discussion rarely occurs. On the other end of the spectrum, functional requirements are so "in the weeds", they also rarely become part of the expectation gap discussion directly.

Nonfunctional requirements are never an issue unless they become "THE ISSUE". Usually there is no gray area here and related manifested issues can be exceptionally difficult to overcome. If you document and communicate nonfunctional requirements correctly, you have covered your back. You can get extra points if you have communicated this to your testing teams as something you want to have tested.

Issues centered around transition requirements can normally be fixed. This may delay full implementation and raise costs but normally not a deal breaker. In some cases, the expectation gap for transition requirements comes from a mistake in believing they are not needed (training needs for example).

If you adequately document, communicate and get sign off approval regarding stakeholder requirements, you can assume you a fairly well protected from expectation gap damage. If you don't perform these fundamental steps in your requirements package, you can expect some expectation gap issues to arise shortly before, during or shortly after deployment.

In my experience, the best protection from stakeholder expectation gaps can be obtained by ...

• structured walkthroughs of requirements
• prototyping with monitored feedback
• diagrams, models, wireframes and storyboards
• stakeholder engagement in the testing process

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded.

Wednesday
May132015

Defined Actors And The Lean SIPOC Method

Dwayne Wright PMP, PMI-PBA, PMI-ACP, CSM
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

At the time in which I'm drafting the first few words of this narrative, I'm dealing with impressions of experiencing my first professionally presented Lean SIPOC JAD session. This was a two day workshop session with about 10 hours of it devoted to mapping existing requirements to a SIPOC model. The SIPOC model is a column based worksheet broken into

Suppliers - those adding something to a workflow
Inputs - into the workflow
Process - illustrating a workflow in a diagram or text method
Outputs - from the process using the inputs by the supplier
Customers - consumers of the workflow product produced

In most traditional requirements documentation, the supplier information comes very early in the process. Although this is the first letter in the SIPOC acronym, it is one of the last areas tackled in SIPOC design. In our session, we started with the Process, then the Input and then the Output. We never actually made it to defining the Suppliers and Customers.

One thing that stood out in this workshop was that the consumer of the content in this case was the technical teams. It largely ignores the stakeholder and the concept of a walkthrough of the content with stakeholders seemed odd to the team conducting our workshop.

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded.

Tuesday
Apr282015

That Little Decision Diamond And How To Leverage It

From Dwayne Wright PMP, PMI-PBA, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

One of the key elements in a process flow diagram is the diamond shape of a decision branch. When you map out a decision branch without swim lanes, you don't have to identify who makes that decision. You are simply showing that a decision is made at this point, its potential choices and how a choice affects the process. With swim lanes, you have to put that decision object into someone's lane.

When you are in a presentation regarding a swim lane process flow diagram, where that decision object is placed can cause conflict. More often than not, that conflict discussion is of the positive nature (although it may not feel like it at the time). As the stakeholders are debating who gets to make the decision, they are openly discussing aspects about that decision. This is often an explosion of information that many of those stakeholders wouldn't divulge otherwise.

I realize now that I made it sound like this discussion is centered around a power grab. This does happen but I have to say that I often see the opposite. The swim lane owner is more likely trying to shed the responsibility of that decision to someone else and they are trying to avoid it. As they are making their individual cases, they often provide a monolog on why they cannot make that decision. Here you can uncover critical information that would affect that decision point such as ...

• previously unknown stakeholders
• previously unknown internal / external process
• previously unknown regulations
• assumptions, now proved to be false
• constraints you hadn't encountered before
• how a stakeholder really feels about ... well ... a lot of things

For these reasons, I always try to present swim lane process flows in meetings and seldom share them to stakeholders blindly via e-mail or digital drop boxes.

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded.