Have you ever noticed that the skills you have as a product manager or as a business analyst can transfer to other aspects of your life? I find myself in that exact situation, and having the skills to elicit requirements is proving to be very useful! My mother recently experienced a life changing event, one [...]
Archive for the "Elicitation" category
Just the other week the IIBA had a great demonstration of better requirements elicitation. For those of you not familiar with the IIBA, their mission is to help Business Analysts grow professionally by providing training, networking, and career development opportunities. We are fortunate enough to have a local Austin chapter that hosts meetings in town. [...]
Recently I was working with a junior team member. I realized when we were reviewing the task I had asked him to complete, that the information he had needed to be most successful was the hardest information for me to communicate. The information I had in my head was not what I had passed to [...]
When eliciting software requirements, there are a few major models that I primarily fall back on to help visualize the process, the system and the requirements: cross-functional process flows, use cases, system context diagrams and data-diagrams. I have recently been using more models that I am less familiar with, such as the State Diagram and [...]
Part 3 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.” Want to torpedo your project before it even leaves the dock? I can think of no better way than not listening to your customers. You [...]
Have you ever worked with that one person who just seemed difficult? Perhaps you were in a working session to gather software requirements with a subject matter expert, and they just seemed to bug you. Others may even mention how a certain person is “difficult”. Recently on a project, I’ve gotten praise for dealing with [...]
We use a well established model for looking at the relationship between business requirements and the software requirements that are derived from them. Using the Requirements Object Model (ROM), we typically examine the business problem, the business objective, and the business strategy. We use these to derive a product concept and from there a set [...]
In this global environment, there is rarely a project we work on that doesn’t have some set of customer users in a remote location, inevitably overseas. While we are typically eliciting requirements in English, we are always faced with ESL customers. So here are a few tips I shared with my team this week as [...]
The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a [...]
Paul Graham has a great article on his blog on why meetings feel so disruptive to many of us. He partitions the world into managers and makers. Managers live their working life in 1 hour increments, so slotting a sudden meeting in is no big deal. It is just an issue of where to go. [...]