Q
Problem solve Get help with specific problems with your technologies, process and projects.

Requirements elicitation: Workshops vs. apprentice-style analysis

When eliciting requirements, workshops are one technique to consider, but you should also be open to other methods such as peer reviews and one-on-one interviews.

My manager believes there is no point in doing "over the shoulder" or "apprentice" style analysis. She thinks it is a waste of time and that everything can be uncovered during requirements workshops, i.e. meetings with lots users and business analysts.

I think the BA needs some foundation in the underlying business process to ensure that quality questions are posed to the users in those meetings and to help everyone remember details about the existing process that they may not otherwise remember when sitting in a conference room. Those details are sometimes the difference between getting the requirements right or delivering a half-baked solution.

What do the experts say?
There are many effective styles of elicitation and analysis of requirements. To place one over another is most likely the results of personal experience and understood as such. Elicitation is accomplished through techniques that are administered most effectively by the individual facilitating the session.

Software requirements elicitation resources:
Requirements gathering, SRS and use cases

Agile development and software requirements documentation

Don't overlook nonfunctional software requirements
In any given business, there are times when a workshop is effective while there are also times when one-on-one interviews work best. It seems worthwhile for the business to try many techniques over time and learn from those experiences. If you have experience with running workshops or seminar-style facilitated sessions, then conduct another with those who have not yet experienced this method. To make these sessions more effective, allow management, analysts, and even the business users to help determine worthwhile techniques.

In past engagements, the personalities of the individuals attending the session will have significant impact on the success of that session. Strong personalities dominate group sessions and can derail the entire session. Some individuals will choose to remain quiet on certain topics as a result. Ineffective control of the session by the facilitator is perhaps the biggest negative to workshops.

In facilitated sessions, tools that help define and manage requirements details are highly recommended. Capture the understanding of the business flow while you have a room full of business experts. Document the flow in a diagram that readily communicates your understanding of the process just described by the users. Storyboard presentation of the documented business flow is a very useful and worthwhile technique.

If your organization has little experience with peer reviews or one-on-one interviews, then it may be worth a bit of time to investigate the effectiveness of this technique within the organization. Experiment and learn from the many possible activities that drive toward a complete set of requirements. Many times throughout the requirements lifecycle, analysts will attempt five or more defined techniques in order to reach a clear understanding of the business need.

For the typical analyst, it is necessary to align with someone knowledgeable about the workings of the business. How this is accomplished varies greatly. The bottom line is the analyst must understand all he can about the activities and flows of the business processes to effectively communicate this to the design and development organization.

Development methodologies affect interaction with users
An agile approach to software development vs. a traditional waterfall approach will alter the techniques of interacting with users.

In the traditional waterfall methods, the business users and the analysts spend countless hours trying to understand every detail of the business process. For this approach, a long-term product roadmap combined with a thorough requirements documentation practice is necessary. The requirements practice and its defined techniques should align the skills of the analysts with the methods of the software organization.

In a more agile approach, details of the product are uncovered as the system develops. Relationships and record of accomplishment builds the confidence of the user community allowing software development to begin even before the system is fully defined. Workshops have a place in an agile approach but are less common practice than in waterfall methods. Product owners define the path to understanding the needs of the business, and they are often the one guiding and directing the interactions with the business users throughout the requirements elicitation and analysis process. The product owner seeks to uncover as many user stories as possible, which add to the product backlog or business/functional requirements.

In an agile environment, the individuals that participate in the definition of the user stories are similar in title to those in a waterfall environment. The subject matter experts (SMEs) exist in each type of development methodology. How business users and IT interact along with who might be the facilitator is what might change.

Many businesses do not formally document all of the practices they will employ in the software lifecycle. For example, in the requirements lifecycle, it may be acceptable to conduct informal and unplanned peer reviews of requirements. While it is normally good practice to plan and document the results of these types of sessions, good quality requirements is the result you seek! The point here is to align the analyst with the business SME. This may be a formal relationship with scheduled meetings, planned deliverables, and complete and polished requirements details. It may also be informal and be conducted as time permits, working more as a friendship that shares every detail about the business rather than a formal business relationship.

From experience, developing informal relationships and purposely aligning with the business SME is a big step in improving the knowledge within the business. Develop relationships that foster trust and confidence between you and the business. This will go a long way in growing your knowledge, business awareness, and management confidence.

Use the workshops when necessary, but do not restrict your elicitation and analysis to one approach. Use your own initiative to grow your knowledge of the business through the relationships within the user community. Gaining the users' trust and the confidence of your management will promote improved communication for the sake of the business and for the attitudes of both business and IT.
This was last published in December 2008

Dig Deeper on Software Requirements Gathering Techniques

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close