Recently I received email from a business analyst named Julie who had just been assigned to a project to implement a CRM system. Julie wasn't sure why she was there. She wasn't asked to fill the primary role of leading requirements development as business analysts typically are. Nor was she an actual user of the system being developed or a subject matter expert, so she wasn't a suitable candidate to serve as a product champion to present customer needs. Julie asked me how I thought she might contribute effectively to this project.
One way Julie might be able to participate is to use her analyst skills and experience to help the user representatives understand and communicate their needs more effectively to the project's official requirements analyst. She could work with the users to create process models for their business using notations and languages that the requirements analyst and developers can understand. These modeling notations include the classic data flow diagram, entity-relationship models and a data dictionary to document the data needs, and the various models supported by the Unified Modeling Language (UML).
Many raw requirements that users provide are really solution ideas that can impose unnecessary, inappropriate or premature design constraints. This is one of the biggest complaints I hear from requirements analysts and development teams. Julie could make sure the users are actually presenting their needs, not just their thoughts about possible software solutions.
Based on her knowledge of the business, perhaps Julie could facilitate some business process reengineering to modify the current business processes to best fit with the CRM system. If a commercial CRM system is going to be acquired as a package solution, it's necessary to specify how the CRM system must be adapted, customized or extended to fit the business operations. Julie could use her business analyst experience to perform a gap analysis to help the business and the CRM system mesh together smoothly. That is, she can serve as a true business analyst.
Another high-value activity is for Julie to help identify and document business rules. Business rules include corporate policies, government regulations, industry standards and computational formulas. Often neither the users nor the analysts do a good job of exploring business rules, but that constitutes essential information for the development team.
Julie could also participate in reviews of the requirements specifications, use cases, analysis models and other artifacts that the analyst develops. Customers sometimes find it difficult or tedious to participate in those reviews. They aren't sure what to look for, and they can get lost in the details. Maybe Julie could serve as a customer advocate to help make sure the documented requirements correctly represent the user needs and constraints.
Even without having lead responsibility for the requirements development process, an individual having business analyst skills and thought patterns can help smooth the requirements dialogue. After I suggested some of these possible contributions, Julie was able to devise a plan for how she might contribute to the success of this major CRM project.
-----------------------------------------
About the author: Karl Wiegers is principal consultant with Process Impact in Portland, Ore. He is also the author of More About Software Requirements: Thorny Issues and Practical Advice; Software Requirements, 2nd Edition; Peer Reviews in Software: A Practical Guide; and Creating a Software Engineering Culture.
