Requirements Elicitation Techniques Part 1 – Overview

Planning

In the previous series of posts I introduced my favorite requirements elicitation technique, “Business Event/Response”. Of course there are many other techniques which can act either as complementary to or in place of “Business Event/Response”. The techniques you choose depend on many factors including the type of project, knowledge depth of the Subject Matter Experts (SME), the availability of documentation, time constraints, etc.

A skilled Project Manager that is also a seasoned Business Analyst (BA) is a very valuable commodity. I encourage all PM’s to increase their BA ability by reading books, attending webinars and seminars, and putting their new knowledge to practice. There is no substitute for actual work experience in this realm.

Here are the topics I will address in this series of upcoming posts:

  • Part 1 – Overview
  • Part 2 – Acceptance Criteria
  • Part 3 – Benchmarking
  • Part 4 – Business Rules Analysis
  • Part 5 – Data Modeling
  • Part 6 – Document Analysis
  • Part 7 – Interviews
  • Part 8 – Non-functional Requirements
  • Part 9 – Observation
  • Part 10 – Prototyping
  • Part 11 – Root Cause Analysis
  • Part 12 – Surveys and Questionnaires
  • Part 13 – SWOT Analysis
  • Part 14 – Summary

A reminder that my book “Project Management For The Real World” is available in paperback and Kindle formats at

http://www.amazon.com/dp/B089KRDDVN

It’s OK To Not Have A Five Year Plan

Have you ever encountered the dreaded “Where do you see yourself in five years?” question during a job interview? I would guess most of us have. There are not many great answers to this question. Many will sound like either you are already plotting to leave the job for which you are currently interviewing or you lack ambition.

I admire those who, at an early age, already know what they want to do and plot a course of action. I was not one of them. Even after college graduation, I wondered what I was good at and what type of work I could be happy with. Ultimately I settled on an approach of being ready for opportunity.

For those of you who don’t have a ready answer to the “Where do you see yourself in five years?” question, I offer the following guidance: Be the type of person that is ready for opportunity when it presents itself.

So how do you do that? Here is a blueprint:

  1. Do your current job, even one you don’t like, with diligence. Trust me, people will notice.
  2. Go beyond your current job description and take on some of the tasks associated with the next level which you wish to be promoted. Promotion becomes easy when you have already demonstrated your competence at that level.
  3. Make learning a lifetime habit. Take evening courses at your local community college. Read books. Search the internet for current best practices in your areas of interest. Listen to relevant career-oriented podcasts. Attend seminars. Work towards a certification. Spend your spare time wisely. Invest in yourself.
  4. Never be satisfied with how good of a job you are doing. Always be looking for better ways to accomplish your tasks. Document your processes and evolve them over time with new information. Share them with others.

So back to the original question “Where do you see yourself in five years?” I will leave the exact phrasing of the answer to you, but incorporate the concept of “I’m always ready for opportunity” with the blueprint steps noted above. If I were interviewing someone, that would be an answer that would impress me.

A reminder that my book “Project Management For The Real World” is available in paperback and Kindle formats at

http://www.amazon.com/dp/B089KRDDVN

Requirements Analysis Using Event/Response And Use Cases – Final Summary

Planning

In the preceding posts, I gave you some guidance on how to execute the Event/Response methodology for scope and requirements analysis. In this last of the series of posts on this topic, I will take the 5,000 foot view and put it all together in a summary of steps.

  • Step 1 – Define the Business Objectives (the measurable benefits realized after implementation). These will be used to verify the scope and requirements.
  • Step 2 – Define the Project Objectives (the products, services and/or results delivered at project implementation). These will also be used to verify scope and requirements.
  • Step 3 – The Context Diagram. Look at the area under study as an outsourced business, with Suppliers (of data) and Customers (recipients of data/information/results).
  • Step 4 – The Event List. This represents your “business model”. You define all of the events that “wake up” your business and require a planned response. In the prior posts, I presented a variety of techniques for fleshing out these events. Included in the Event List are your business processes and stakeholders.
  • Step 5 – Validate the Event Model. Compare your event scope with the Business and Project Objectives and verify with the Project Sponsor that all objectives are covered by this scope.
  • Step 6 – Construct Use Cases. Use the defined business processes in the Event Model as the starting point for creating Use Cases. Some steps in the Use Cases can be extracted as “Functional Requirements”.
  • Step 7 – Test Planning and Execution. The Event Model is a wonderful framework in which to define your test scenarios and cases. Take advantage of all the work you did in the requirements phase to make your test planning and execution easier.

That’s it for this topic. I hope you found it informative and useful. I have used this technique successfully in many real-world projects.

A reminder that my book “Project Management For The Real World” is available in paperback and Kindle formats at

http://www.amazon.com/dp/B089KRDDVN

Requirements Analysis Using Event/Response And Use Cases – Test Planning And Execution

Planning

In addition to being a great way to elicit the complete scope of a project, the Event/Response methodology delivers a comprehensive framework for test planning and execution. When using this methodology, what many call “User Acceptance Testing” can be replaced by the term “Event Testing”.

In my prior posts on this topic, I identified the primary deliverables of the Event/Response methodology as:

  1. The Event List (containing the event that triggers the response, the origin and data content of the information flow into your “business”, the named processes, the outputs of the processes and the destinations of the outputs), and
  2. The Use Cases. You can plan to test by simulating the actual Events, creating the data flows, executing the processes and examining the outputs. The Use Cases give you a good start on creating the data and usage variations for each Event. Doing this yields a direct mapping of the scope and requirements to the test cases and execution.

Note that since the Event List also contains the roles of the actors initiating the events and processes, as well as the roles receiving the outputs, security testing can also be built into this framework.

Another major plus of planning and executing the tests this way is that you are testing the system as it will actually be used in context, as opposed to functional testing which tests bits of functionality in isolation.

A recent project of mine used this methodology and yielded 180 Events and over 1,600 test cases. Because of this comprehensive approach, this complex system was very well tested and only experienced few minor problems after implementation.

A reminder that my book “Project Management For The Real World” is available in paperback and Kindle formats at

http://www.amazon.com/dp/B089KRDDVN