Live from BAWorld: What To Do With Interfaces
Mary Gorman from EBG Consulting presented “Integrating Interface Analysis into your project: Just-enough, Just-in-time”. This talk was one of the advanced topics, with the intent of teaching about how to do interfaces – software, hardware, and user interfaces. I’m going to capture some summary points from her talk, either the key points or the ones I found most important:
And she points out that a nice bonus from working on interfaces is that you also will likely improve your user requirements – by finding new users, new stories, incomplete stories (missing interactions), missing data attributes, and missing business rules.
My favorite part of this talk is that Mary used a role playing exercise in which people played different systems or the customer, and they used a ball that was tossed around to represent data passing between systems. She used it today to demonstrate the concept, but I talked with her afterwards and she does in fact use this technique for eliciting interface requirements.
I was excited to attend this talk because I have a lot of respect for Ellen and Mary from EBG, they seem to know a lot about practical things about requirements (as compared to a lot of the speakers who talk so high-level it's not usable material). They have some good books and whitepapers to learn from outside this forum if you haven't read them.
- She talked about just-in-time interfaces, specifically of interest is that idea that you can identify interfaces early in the project (first days even). A lot of projects wait on these, but there is no reason for that and you may miss things if you wait.
- Do just enough. In some cases you can do minimal formal documentation, just enough to build and demonstrate the system, whereas other times you need very formal structured documents.
- Business rules are at the center of all models. They are used by all models, and you will discover them in most models.
And she points out that a nice bonus from working on interfaces is that you also will likely improve your user requirements – by finding new users, new stories, incomplete stories (missing interactions), missing data attributes, and missing business rules.
My favorite part of this talk is that Mary used a role playing exercise in which people played different systems or the customer, and they used a ball that was tossed around to represent data passing between systems. She used it today to demonstrate the concept, but I talked with her afterwards and she does in fact use this technique for eliciting interface requirements.
I was excited to attend this talk because I have a lot of respect for Ellen and Mary from EBG, they seem to know a lot about practical things about requirements (as compared to a lot of the speakers who talk so high-level it's not usable material). They have some good books and whitepapers to learn from outside this forum if you haven't read them.
Labels: BAWorld, software requirements, systems engineering, user interface design
posted by Joy at 10/30/2008 08:32:00 AM
3 Comments:
Thanks Joy, the football idea is a great one. If you're designing a solution 'from the outside in', you actually have to jump through hoops to avoid doing the (user) interfaces first.
This also helps keep you focused on requirements, not implementation - focusing on the interactions (what data has to be exchanged, in what sequence) and not the implementation details.
Of course you have to capture the implicit business rules that sometimes determine steps/sequences in the interactions.
I like the ball analogy too. I've found that interface development (whether user-system or system-system) can be a key area where requirements are missed if you are not diligent. I'd be curious if she recommended any specific types of documentation to capture these requirements? For user interfaces, my preference has always been wire frames or prototypes. For system-system interfaces I've used use cases or excel spreadsheets, depending on the number of data fields and rules guiding the back and forth interactions.
Best,
Laura
www.bridging-the-gap.com
Laura,
Thanks for your thoughts. At EBG Consulting we use a variety of means to capture interface requirements. As you noted, wire frames can provide a powerful visual means to depict the user interface’s flow. We supplement wire frames with specific detail about each window’s data fields (linking to the data dictionary attributes, valid values, defaults, and other presentation details), actions, business rules that are enforced and their accompanying exception messages. And a Style Guide is an effective way to define or apply organizational standards for the UI’s look and feel.
Like you, for system-to-system interfaces, we use spreadsheet templates to list data fields, applicable business rules, selection & sorting criteria, etc. Depending on the type of behavioral model we’re using for a project (stories, use cases, activity diagrams), we cross reference it to the S-S detailed document(s).
Regards,
Mary
www.ebgconsulting.com
Post a Comment
<< Home