I provided some business analysis training a while ago, and recently caught up with one of the attendees of the training; a lovely lady whom, for the purposes of this post, we’ll call Pat. I was inquiring how things were going and whether or not she was able to incorporate anything that she learned into her day-to-day job.
To my joy, Pat said, “Of course!” then related how she has used a number of the models on her current project. It was a great conversation, and I was thrilled that she was not only excited about her job, but found value from our course and our models.
Pat then related a story to me that was even more awesome. She has a friend, “Samantha”, who is also a business analyst in a different organization. They met up for coffee and were talking about their respective projects and how things were going at work in general. Samantha told Pat about her newest project, how it was large with lots of information and data, and Samantha was struggling a bit to be able to wrap her head around all of the information that she was collecting. As Samantha was telling her story, Pat pulled out a sheet of paper, and started to jot down all of the various features that Samantha was describing. Once Samantha was done with her description, Pat took the information and created a Feature Tree, and showed it to Samantha…”Is this your system?”
Samantha was amazed. “Why, yes, it is!” As Samantha looked at the various features on the tree, Pat then said that it looked like an interesting system, but she noticed that there were no administrative sort of features listed. Would the system need something like that?
Samantha was speechless. Yes, of course the new system needed administrative functions, and she couldn’t believe that those features had been forgotten. She was even more impressed that Pat was able to figure out the missing functionality after a short discussion and one model.
How awesome is that? One simple model, a short conversation, and a whole bunch of requirements found! So let’s review the Feature Tree.
A Feature Tree is an RML objectives model that shows the organization of the features in logical groups, displaying the full scope of a solution in a single page. There are three possible levels of features that might be useful for organizing the requirements: Level 1 (L1), Level 2 (L2), and Level 3 (L3). Below L3 are individual requirements themselves. Feature diagrams show all of the features at once, giving a quick view of the solution’s breadth of functionality.
I find that many end users love Feature Trees, for it gives them their system on one page. I’ve seen many a user take a Feature Tree and put it into their “project folder”, and when someone asks them about their project, they pull it out to show what functionality their system will have.
It’s also a great model to tie to the Requirements Mapping Matrix (RMM). On a project that I am working on, I recently created a RMM and I tied all of the requirements to the process flows. The next thing I did was mapped all of the requirements to the Feature Tree. I was able to then make a list of all of the features from the Feature Tree that had no requirements associated with it. It’s a great way to help ensure that you have all of your requirements.
