Quick – when I say “interface analysis”, what’s the first thing that pops into your mind?
If I had to guess, I’d guess that you pictured a screen prototype. So many of the interfaces we work with are just that – screens used by humans to interact with a software solution. However, there are lots of other types of interfaces. Each of those interfaces need to be identified and its requirements should be defined. Let’s start with some terminology (yes, I do love the glossary!). Then we’ll explore different types of interfaces we need to analyze and learn key questions that must be asked and answered to clearly define our interface requirements.
Some glossary entries…
The BABOK® defines an interface as “a connection between two components or solutions.” Interface analysis “…is used to identify where, what, why, when, how, and for whom information is exchanged between solution components or across solution boundaries.”
Now that we’re speaking the same language…
The purpose of an interface is to exchange data (information) between two solution components. Referring back to the BABOK® again, it says “Most solutions require one or more interfaces..” I thought about that for a minute, trying to visualize a solution that would not have an interface. I can’t think of an example. Seriously, what would a solution with no interfaces actually do?
In my experience, a solution will include at least one interface, and many solutions involve a large number of interfaces. Here are six common types:
- User interfaces for internal user and external users – describe the way a human interacts with hardware or software
- Data interfaces between systems – identify how data is exchanged between hardware or software systems
- Interfaces between business processes – provide detail on handoffs between business processes or activities
- Application programming interfaces (APIs) – allow software programs to communicate following defined protocols
- Interfaces with hardware devices – defines how hardware devices (such as sensors, thermostats, and GPS devices) transfer data to and from other systems
A context diagram can help us identify many of the interfaces involved in a solution:
A swimlane is a great way to identify interfaces between business processes:
On to the analysis… 6 essential questions
Tools like context diagrams and swimlanes can help us identify interfaces. Just identifying the interfaces isn’t enough, though. We need to ask and answer 6 key questions to ensure we’ve fully described our needs.
Question #1:
Why is the interface needed?
The first question I (almost) always like to start with is “Why?”
Why do we need an interface?
What is the root cause of the problem or need?
Why is the information not currently available?
How is the work being done right now?
Users often bring proposed solutions instead of describing their real needs. Before digging in any further, make sure the real underlying problem or opportunity is understood. Maybe a new or updated interface isn’t really the right solution.
Question #2:
Who will use the interface?
You must understand who will be using an interface to design an effective one for them. A great tool for performing this type of stakeholder analysis is the persona. We explored this tool and shared a sample Persona Template in an earlier blog: 6 Steps to Creating and Using a Persona. Developing personas will help you gain insights into your users so you can design an interface that meets their needs and addresses their concerns.
Usability plays a large role in the effectiveness of a user interface. Our Usability Heuristics Quick Tips outlines Jakob Nielsen’s 10 general principles for interface design. They’re a great starting point for reviewing your interface design.
Question #3:
What information will be exchanged?
Detailed analysis should be performed to identify:
The specific data that will be exchanged between the two components
Any rules for transforming the data as it is exchanged
The volume of information that involved
Question #4:
Where will the information exchange occur?
In electronic information exchanges, “where” typically refers to the source and target for the data. Where is it coming from – what system or data repository – and where is it going to?
Keep in mind that not all information exchanges will be digital. Just this last week I filled in a paper application form to rent a storage space. We still need to where the data is captured – on a form — and where it will be stored – in this case, a three ring binder (yup – seriously).
Question #5:
When will information be exchanged?
Determine the timing and frequency of data exchanges. Will it be done each time a triggering event occurs? Hourly? Every night at 2am? Once a month? There is often a balance that must be struck between the “freshness” of the data and the expense involved in creating real-time data exchanges. As an analyst, we play an important role in understanding the real need and proposing an appropriate solution.
Question #6:
How will the interface be implemented?
Once we have answers to all the other questions, we can focus on the best way to implement a needed interface. There are many options, all of which have advantages and disadvantages.
Interested in learning more about designing user and system interfaces? Our Use Case Modeling and Solution Requirements addresses these in detail. You’ll also receive User Interface and System Interface templates to help you ask all the right questions before you design an interface.
Don’t put it off!
Early identification of interfaces provides key contextual information for a solution. It can uncover stakeholders whose requirements might otherwise be missed – some interfaces, such as an audit function, may be infrequently used and less obvious without detailed analysis.
Next time you receive a request for a new or updated interface, remember to ask all these questions before moving ahead. They’ll help you design an interface that truly meets the need – if, in fact, a change is even needed.
Happy designing!
–K.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
