At the end of the day, software development is about delivering working software that meets the customers’ needs. In my last blog I mentioned the concept of a customer team (a term from Agile development) that is staffed with business people who understand the business and understand what they want to get out of the software.
Those on the customer team have a couple of jobs: One is to answer questions as they arise, and the other is to participate in creating and prioritizing of “user stories.” What are user stories? Simply put, they are another way of defining what are commonly called business requirements.
Pause for a moment and ask yourself: What is a business requirement? While the following observation is not original with me, I find that there are three, broad categories of business requirements that hold true in software projects that are larger than anything above trivial in size:
· High-level business objectives, generally geared towards meeting executive management or over-arching organizational goals, stated like “By implementing this software, we plan reduce headcount by 25%, reduce errors by 50%, realizing significant productivity gains through reduced manual workflow in our (insert departments here).”
· A class of technical requirements that need to be met. A technical requirement expresses things like performance expectations (“we need sub-second rating to be competitive”), constraints (“we’re an Oracle-only shop”), reliability (“we need 7x24 availability”), and security (“clients should only be able to view their own policy information and not any other information”).
· A larger collection of more specific, user-oriented requirements, based upon an individual’s role in the organization. For example, Tim in accounting may want to see on-line reports of all business activity from the prior day, formatted to his preferences, while Gina may need to process complex payments, moving money between accounts efficiently.
The over-arching requirements tend be crystal clear and in reality, and measured once the software is implemented. Development-oriented people certainly understand the technical set of requirements, so those end up in the realm of challenging, but very understandable. Where development teams are the weakest lie with the specific details of actual business use; after all, they aren’t actual business users, are they?
Not only are developers not business people, but at AMS Services, we deal with insurance software, not an easy subject! You would think that in a regulated environment, with standards available (ACORD, ISO) that business objectives and software should be easy to define. No so! I’ve been at Phoenix User Group Conferences in the past where I’ve heard C-level executives comment that as a whole, insurance companies cannot agree on what written premium is! In the insurance industry, it is the variations and the large amount of data that lead to almost infinite possibilities in terms of defining “the business.”
The larger the project, the greater the likelihood that a variety of perspectives and needs will need to be met, and naturally enough what is deemed important and necessary to each person using the software will vary depending upon the role that each person plays in the business. This requires input from various users who will be expected to use and interact with the software, not just a select few representatives from the business.
How do we capture needs of different users in the software development process? One way is to bury all of the requirements together in a comprehensive, large, bland document. OK, “Bland” is being a little facetious on my part. In reality, a single document that captures the requirements works just fine in many cases. On larger projects where there are likely multiple user-oriented requirements, at AMS Services we’ve found a technique that works quite well: Personas.
A persona is a fictitious person, but assigned a picture and background information so that the development team can understand how real world users expect to interact with the software. Building a persona is an interesting exercise as well as a fun one, and it does pay off in the software development cycle.
Personas represent the goals, knowledge, skill s, and even the attitudes of what could be a real user. Personas are preferably developed through interviews with real-world users. The idea is to make the persona as real as possible to the development team so that they have an understanding and appreciation for how a user wants and needs to interact with the software as they design the software. Personas become one measure of just how usable the software is, and can help guide decisions with visual design and workflow within software products,
Of course, personas do not eliminate the need for interaction with the teams, but use of personas will help reduce some of the time required of business users. Personas themselves cannot sign off on the software, nor will they be so complete that referring to them will answer every question that a development team will have. Personas are one tool in the arsenal to help construct working software that meets the customers’ needs. The other big weapon is active participation and availability of the business community to answer questions.