In some organizations, the terms use case and requirements are used interchangeably. In some respects this is an understandable point as both are ways to define the basic functions that software must accommodate. They are both typically defined early in the project, are used as a basis for estimating the effort involved in a project, are grouped so developers or implementation consultants have some structure during the development or implementation phase of the project, and they are also used as the basis for testing planning and completion. In many ways, they are similar. In terms of usefulness for test case and training material development, they are very different.
At the outset of any project, we project managers look to gain insight into what the solution must do. In many cases, we ask our business users what they would like the new software solution to do for them and we call this list of items, requirements. This approach is well seasoned and has manifested itself in techniques like Joint Application Design (JAD) sessions where groups of business get together and discuss their needs of the new solution. Project team members furiously take notes as the items are identified. Even though this is a well seasoned approach for developing requirements, it is difficult question for business users to answer because they do not think of their business in this manner.
In my experience, business people are well versed in how the business is conducted, what they do on a day to day basis and what information and in what format they need this information to be effective in their varied positions within any company. This business context is a key differentiator between use cases and requirements.
When developing use cases, the project manager asks the business team what they do on a day to day basis, what they do on rare occasions, and finally what they do on a very intermittent basis. These questions have the context of the business activities they perform. In order to be complete, project managers can start with more senior executives or even the project sponsors to get an idea of the breadth of individuals from whom to solicit their day to day activities. These are the use cases. A similar interviewing process can occur with individuals but with much smaller groups so each group can focus on their area of responsibility. The project team can collect the use cases from each team and consolidate them.
By collecting from each group, a natural organization occurs since each group is typically a functional group enabling the project manager to begin to organize the use cases and therefore the development or implementation activities into a structure well known to the people who will both be served by the new solution but who also are likely to determine when the solution is ready to deploy.
Besides functional business people, a prudent project manager will also interview technical staff who will both administer the solution, network, interfaces, and batch processing. These technical use cases are equally as important as the functional ones.
When defining requirements, an interview is typically the well traveled path to definition. Many services companies have defined templates or questionnaires to assist with getting a complete set of requirements. All of these approaches prove difficult as each software solution is unique to the customer. We typically find our requirements sets of incomplete and this realization does not occur until deep into the testing cycles or even as late as the first few days after going live. As consultants, we are very conscientious about doing a good job but we are behind the eight ball.
A natural mechanism for developing use cases is to start with business process flows. Business process re-engineering (BPR) was very popular in the late 90's as companies began to look critically at their internal operation. On many occasions as part of an Enterprise Resource Planning (ERP) implementation, my project teams would start with the business processes, take the opportunity to identify areas of streamlining since the process data was consolidated and became easier to identify these areas. Although BPR is less popular today, the definition of business processes can be a good starting point for use case definition as the use cases are each unique path through the business processes.
In previous posts, I have mentioned the advantages of process flow diagrams as they identify new paths that are not always apparent and provide a mechanism for being more systematic in the approach to define use cases. My best projects have started with using process flows as the starting point for use case definition and then leveraging these use cases further down the line when writing test cases and even training material
Once the project manager has a good set of use cases including the happy and non happy paths through the business processes, these same paths become the basis for the test cases. The difference with test cases is a test case should address each inflection point within the continuum of data that could pass through the use case. For example, we may look at closing the AP books for the month. The use cases will be the same but the test cases include open AP across the boundary as well as open and closed within the month. This different data condition may lead to different handling within the solution. Another example could be a calculation algorithm whereby negative numbers are not permitted such as in a financial example or were a zero is handled differently. All could be the same use case but different test cases so the unique data conditions are exercised.
Finally, the use cases can be the basis for the training material. Given the use cases define all the business activities needed for a good solution, the end users will need to understand the keystrokes to perform each of these business activities within the solution. At a high level, the trainers can take a representative set of test cases including the organization defined during the collection process and build training material off this set. The unique activities are defined within a structure that makes sense to the business and is broken down into functional sets that align to the set of users to be trained. What is remaining for the trainers is to capture screen shots where appropriate, define exercises and pre-stage data into a training environment if so inclined.
Although requirements and use cases are perceived by many organizations to be very similar or synonymous terms, the manner and context in which they are derived as well as the additional value of use cases in the testing and training realms define some separation between the two.
Comments