I’ve got a new project where my main subject matter expert, John, is relatively new in his career.  This is the first “IT” project that John has been involved in, and this is the first time that he has ever worked with a business analyst. And it has been fun educating John on what a business analyst does! When I first started, John was a bit concerned when I said that I would be helping him write the requirements. John looked at me and said how could I, since I don’t know his job and what his department does. I just smiled and said not to worry, he will see how I can learn, and learn fast, and help him along the way. Especially since he has a “day job”, I view myself as helping him as much as possible so he can actually do his day job. The effort is a system replacement, and John had already made an attempt at writing the requirements. Of course, since he has never done this before, John had no idea what he was doing. Having no guidance until I showed up, his approach was to take screen shots of the existing system and start drawing on it the additional features and items that his department wanted. OK…I can still use this, but just not for the purpose that he had in mind. Thus we started out with the Business Objectives Model, and then moved on the Feature Tree. As the development team will be using Scrum for their SDLC (John is the Product Owner), we prioritized the features in the Feature Tree in order to give us our first pass at the Product Backlog. As part of doing that, John started to add a lot of data fields, solution ideas, all of the normal things that I have seen from those who are not familiar with requirements tend to do. I’m working with John now to pull things back into it’s proper place. As part of that effort, we removed all of the data fields out of the product backlog. In an attempt to reassure John that we are not losing that data, I put all of the information into a comments field, and will ultimately transfer the information over to the data dictionary. And this is where the fun began. As John looked at the revised product backlog, he started to ask questions about the data fields, especially as it relates to requirements such as importing information in from other system or uploading existing documents. John: “Do we need to list those fields, if we want to upload documents?” Me: “Well, that depends upon what you want the system to do with this information. If you want the system to just take the document and store it as a blob, then no, we don’t need the field information. However, if you want the system to take the data in the document and do something with it, for example, input it into a form, then yes, we need to detail out all of that information.” John’s eyes got wide. So I continued: “So we will need to think about what you want the system to do. However, realize that if you do not state what you want, Development will take the path of least resistance.   And that will probably not be what you want.” Silence from John as he processed what I had just told him. John: “Wow, we never thought of it that way. So we need to be specific in our requirements?” Me: “Yup. Otherwise the development team does not know what you want. ” I then reassured John that was why I was here, to ask questions like that, to probe the boundaries and to make him think about what his department really needed the system to do. I would help him get the information that was needed and ensure that Development understood what needed to be built. John looked at me with very grateful eyes. Lesson one of “What a BA does” complete.