I don’t know how many articles I’ve read where the author states requirements should be “what” the user/client needs, not “how” to deliver the solution. They say “A requirement should never specify aspects of physical design, implementation decisions or system architecture.” And yet the IIBA Guide to the Business Analysis Body of Knowledge (BABOK Guide) lists multiple tools and techniques related to the design of the solution. What gives?
In my humble opinion, every requirement, even the business level needs, goals and objectives, are just the start of a long march to a solution. Data modeling, process modeling and prototypes; are they not solution defining techniques?
If a business analyst is creating a conceptual data model, but accidentally slips into logical data modeling by mentioning entities, attributes or relationships, are they stepping on the toes of the DBA?
If a business analyst creates a wireframe of a web page, does the user interface (UI) designer get their knickers in a knot and toilet paper the BA’s house? What if a business user provides their own prototype for a screen or report? Can programmers tell their clients how their own product should look and behave? An old colleague of mind would call that a “career limiting move”.
Now I may receive hate mail from some developers and UI designers, but modern business analysts and users are much more tech savvy than their predecessors (you know, the old guys and gals from the ancient past of the 1990s) and can be just as capable of designing a user interface as a programmer who may be biased toward their favorite widgets for displaying and entering information. Users are now exposed to hundreds of different web sites and GUI interfaces. In my organization, it’s our marketing and communications division that designs the overlying theme and much of the content for our web sites, not the development team.
Now don’t get me wrong. It never hurts to include members of the implementation team in design discussions. The business analyst needs to partner with skilled resources and take a collaborative approach to all requirements elicitation. My analysis teams always include implementation subject matter experts as well as business domain SMEs to ensure that user requests are technically possible using the organization’s toolsets and architectural standards. The goal is that the focus of this multi discipline team is on the client/user just as much as on the solution itself. This focus can be defined as “design thinking”.
Design Thinking
Design thinking is about empathy for the user. Considering the client’s needs and experimenting in a safe, low cost environment. It involves divergent thinking from people with different backgrounds and disciplines collaborating to achieve the best result for the customer. In Agile, best practice is for team members to cross functional boundaries when possible to help the team succeed as a whole. Example: A developer who completes their work on a sprint early volunteers to help a tester execute some test cases or a business analyst taking time from writing the next set of user stories to create a paper prototype for a developer.
But be careful not to begin your design too early. It is common for users to only think about the solution in terms of the user interface. Even when doing analysis at the enterprise level, users will talk about requiring a dashboard or a particular report when the analyst is still trying, or should be trying, to understand the business need and the goals and objectives the organization wants to achieve.
In the Zachman Enterprise Architecture Framework, John talks about eliciting information to “an excruciating level of detail”. However, that level of detail should be appropriate to the perspective under analysis. For instance, at the Contextual or Executive level, the analyst should be eliciting high level goals and a corporate vision of the architecture from executive management, not how the lower level components deliver that vision. There is no reason to include the implementation team at this level of analysis since no design should be done.
It is understandable how developers and UI designers are protective of their territory. I used to be a developer before switching to the dark side. But business analysts interact more with the user community, especially on waterfall projects, and it seems silly for a BA to stop a conversation with domain SMEs to bring in a systems analyst to talk about some ideas the user has for the user interface. Some organizations split the business analysis duties between a “corporate” business analyst and IT business systems analysts. My company does this for some areas of the business, but fortunately not the Infrastructure group where I do most of my work.
Corporate business analysts are expected to think strategically. They look for opportunities for process and business improvement, create business cases that evaluate alternatives for solving the business need, justify the cost of the potential project and document the Stakeholder Requirements outlining the major features of the new or revised product or service. They then turn over the project to the IT business systems analysts to elicit the Solution and Transition Requirements. I would hate to work in that environment where, if I’m in a requirement workshop discussing Stakeholder Requirements and the SMEs begin talking design, I would have to shut them down and remind them the BSA will discuss that later. Besides, I love design.
So what are some of the techniques used in design thinking?
1. Data Modeling
“Pssst. Hey buddy. How would you like to get your hands on a model? No, not Heidi Klum, a data model. Yes, I know they’ve been around for a while, but they’re just as sexy today as they were when Peter Chen put the first ERD model on the street in 1976. We’ve even found some new and innovative ways of using them that may get you excited.
For instance, let’s say you are developing a conceptual data model to document the people and things the business wants to store information about. What if you just experimented a little, call it role playing if you like, and started talking about the relationships of those people and things to each other? Yes, I know that’s crosses the line into logical data modeling, but it provides some special perks. A one to one/many cardinality between an employee and a department could translate into the business rule “An employee shall be assigned to at least one department.” Would this business rule have been missed if not for crossing the boundary into design? So come on big boy, expand your horizons. There could be a “happy ending” in it for both you and your client.
Wait, you’re not a DBA are you? Are you on Wired.com? I know my rights! Any business analyst can use data modeling as long as they stay away from a physical data model that most business people don’t understand. (For an explanation of “database third normal form”, please look in Wikipedia under the heading “who cares”.)”
2. Prototyping
“Hey beautiful. What’s a nice business analyst like you doing in a place like this? Oh, you’re looking for a little mock-up. Well you’ve come to the right place! We just got a new supply in from the BABOK. No, not Bangkok, BABOK! We have horizontal and vertical prototypes, throw-away and evolutionary prototypes, and visual and work flow prototypes. The first one’s free because we know after you try one, you’ll be hooked.”
I’ve found that prototypes are the best way to elicit and verify textual design requirements for any user facing component of the system. Many times, especially in Agile, they may be the only form some of the functional requirements are documented in.
Storyboards (horizontal prototypes) are a good way to show the flow of screens or web pages through all or part of a system. Throw-away wireframes (vertical prototypes) written on paper or a whiteboard can give users a feeling for what the user interface will look like without spending a lot of time or running the risk of them thinking the final solution will look exactly like the prototype.
So how detailed should a prototype be? I was on a project where a developer put her head down and created 10 or 12 evolutionary prototype screens in a week for a new customer accounting system after only a brief meeting with a group of Finance division stakeholders. The users were ecstatic! But then we got the dreaded “The program is already done!” comment, followed of course by the natural “What do you mean you still need another six months?”. We had to do a little stakeholder management to explain that the database wasn’t complete, most of the entry defaults weren’t assigned and none of the business rules were being enforced. And of course, nothing had been tested. Once the business users got over their initial disappointment, they still appreciated being able to see detailed screen layouts, screen flows and play with the data entry.
Don’t spend a lot of time on a prototype unless it is evolutionary and will eventually end up in production like ours did above. If throw-away prototypes are used, make it clear whether they are exact definitions of what the business wants or are they just a method for the business analyst to elicit and verify the requirements. The Information Management Plan portion of the Business Analysis Plan should document whether a supplied prototype will be carved in stone or can the developers use their discretion to modify it. This is important to the testers as well, as they’ll know whether to build their test cases against the prototype or dig further into the functional requirements.
Sometimes simpler is better. Most people wouldn’t expect a screen mock-up scribbled on some scrap paper or a whiteboard to end up in production exactly as drawn. Of course, going old school is heartbreaking to us perfectionists who love to spend hours with our fancy modelling tool creating professional looking mock-ups we can’t wait to unveil to our users. In my organization, we have just invested in a new requirements management tool that allows a business analyst to create realistic looking prototypes inside the tool and then link requirements to parts of the interface so the implementation team can better relate their work to the final solution. However, once we have finished configuring the tool, the hard part will be deciding if and when we should use this feature on actual projects. Will the additional time and cost give us a return on investment (ROI) on the project and down the road? After all, once the actual user interface is constructed, why do we need the prototype?
3. Process Modeling
Activity diagrams and use cases. These modelling technics are less controversial as consensus seems to be, they fall within a business analyst’s scope of work, especially when the BA is documenting the “as is” form of a process. Even when documenting the “to be” process that leads to the final solution, there is little opposition if the analysis team stays at the business use case level. Personally, I have trouble differentiating between a “business” use case and a “systems” use case. Use case aficionados would probably call mine a “hybrid” (or something less polite).
Although a use case is a design tool, whenever you are defining the “to be” state, the use case should limit itself to designing the process and not the user interface. For instance, “The user inputs a widget.” is an acceptable step in a use case, but “The user selects a widget from a drop-down list.” is un-necessarily restrictive for a use case step. Of course, based on my whole premise for this article, the BA could create a separate functional requirement stating “The user shall be able to select a widget from a drop-down list box to ensure the accuracy of the entry.”, but talking about the list box in the use case just clutters the use case.
Use cases are great for documenting process flow, but some people are more visual and prefer a graphical display of the flow. Personally, I like to create an activity diagram for the process under review and include it in the same document as the use case. I’m excited about our new requirements management tool which automatically builds the activity diagram/flow chart as you write the use case. If it works as advertised, it will save a lot of work.
So anyway, have I converted you? The next time someone says business analysts shouldn’t be documenting “how” the solution should work, please blow them your best and sloppiest raspberry. You can even say it’s from me.
In summary:
- Business analysts should feel free to cross the imaginary and unnecessary boundary between requirements and design. Users are on our side and the implementation team will learn to live with it, especially if they’re allowed to collaborate in the process.
- Ensure when working with design that you don’t do such a deep dive that you trespass into an area business users are not interested in. (e.g. physical data model.) Remember, business analysts act as a bridge between business and technical stakeholders. Make sure the requirements you produce are understandable to both groups.
- Rather than treating design thinking as competing with the implementation team, make it a collaboration. Include the architects, DBAs, programmers and user interface designers in the requirement elicitation process. Perhaps leverage their abilities to create some of the models for you. Less work for you!
- Keep your prototypes simple. Remember that after the final solution is deployed, none one cares about the prototype anymore unless some features weren’t delivered in the first release and additional work will be required later. As the theme song from Disney’s Frozen says “Let It Go”.
- One of the values of the Agile Manifesto is “Working software over comprehensive documentation”. When it comes to design, this statement should also apply to the waterfall methodology. Don’t create design models or spend additional time perfecting them if they don’t add value to the business and the solution. Time is money.
Author: Les Mathisen, PM & BA, Saskatchewan Crop Insurance Corp.
Les Mathisen is a project manager and business analyst for the Saskatchewan Crop Insurance Corporation. He has a CCBA and CBAP from IIBA, a PMP and PBA from the PMI and a PRINCE2 Practitioner, Agile PM Practitioner and ITIL Foundation certification from APMG. Les has an associates degree in Computer Technology with honours from the Northern Alberta Institute of Technology and a certificate in business analysis from the University of Regina.