Use Case best practices

Use case is a powerful tool for capturing functional requirements of the system. Its primary use is to capture the contract between the stake holders of the system about its behavior. Note, however, that use cases may be used by some teams to capture the requirements in the traditional ‘shall’ based format. Or the use cases themselves can be used as requirements by some teams.

A use case is almost always started by an agent called an actor. A primary actor is a stake holder of the system and initiates an interaction with the system to achieve some goal. As the system interacts with the system its behavior, alternate behaviors, constraints etc are captured as part of that use case. Deciding who is an actor for a given use case is, some times, not trivial. Discovering use cases for a system is not simple. Capturing the use cases effectively requires some skill and an understanding of best practices immensely helps teams/individuals. Use Case is not object-oriented. It has nothing do with object-orientation. Simple text can be used to capture use cases. Refer to Alistair Cockburn’s excellent book “Writing Effective Use Cases” for more information. This post owes much to his excellent book.

The style of description of use cases might vary depending on how the use case is being put to use. Use cases can be used as white box use cases (ex: a business process or internal working of a system) or also as black-box use cases (ex: system requirements etc). Even the level of detail might vary from project to project or from team to team. For example, projects with safety, regulatory issues might decide to use detailed use cases, where as a project team with experienced developers might decide to use only brief use case descriptions for the system development. Projects following agile development philosophy tend not to generate detailed use case descriptions and instead rely on the good internal communication instead. They tend to keep the rest of the requirements in prototypes, continual communications and frequent incremental releases.

The use case description style can be chosen on a project-by-project basis. It makes sense to tailor the template depending on the project needs. Since use cases are easy to understand even for the non-technical persons, it is the single most important tool for identifying, clarifying, deciding system scope and its requirements.

If use cases are used as requirements, then it need not be converted to traditional ‘shall’ based requirements. Another thing to note here is that, use cases do not capture all the requirements of the system. They do not capture other important aspects of the system – non-functional requirements, quality requirements, external interfaces, rules etc. These requirements have to be captured using the traditional ‘shall’ based requirements.

Following are some of the best practices in designing use cases.

• Write the main success scenario as part of the main scenario. Identify, in each step, things that can go wrong and how the system should respond to them.
• Use discretion while detailing requirements. The mistake is getting too much caught up in precision and rigor when it is not required. If the system to be built is simple and easy to understand the use cases need not be captured with much detail.
• The best way to identify the use cases is through brainstorming. An experienced user can guide the team in identifying them. The idea to keep in mind during the identification stage is to focus on use case identification and not its expansion. Once the use cases are identified, they can be divided among team members for expansion. While detailing individual use cases, team members can take the help of domain experts, stake holders, and business experts etc to cover all the alternative scenarios of the use case. This procedure of identifying the use cases first and detailing them later provides the opportunity for the stake holders to correct any of the wrong assumptions made during the identification process. The thing to remember – once the use case is accurate, you can add precision during its expansion.
• It makes sense to include narratives or concept of operation before writing use cases. They provide context to the requirements and help clarify the environment in which the use case runs.
• Identifying an Actor – An actor is anyone one or anything with behavior. It is external to the system under consideration and its behavior can not be controlled. Note that the actors need not be humans always. It could be an external system, a timer or state based invocation.
• Primary Actor – An actor who initiates the dialogue with the system for achieving goal. The use case starts at the triggering point (initiated by the primary actor) and ends when the goal is fulfilled or abandoned.
• A use case can succeed in a number of ways. A use case can fail in a number of ways. The detailed use case description should enumerate all the possible scenarios. Note however that it is not needed to write all the sequences from start to end. Only those steps that can fail and the alternative steps for them need to be enumerated. In short, use cases contain scenarios and a scenario contains sub use case as its steps.
• The use case as a contract for behavior captures all and only behaviors related to satisfy the stake holder’s interests. It should satisfy all stake holders’ interests including the primary actor. For example: keeping a log will protect the stake holders in the case of any disputes. For a use case to be complete, all the stake holders (that are affected by the use case directly or indirectly) must agree on the success criteria and also the guarantees they want from the system. Listing the stake holders and their interests ensures that none of the required steps are left out in the use case description.
• The name of the use case is best described with primary actor’s goal. Most of the time it’s the primary actor who triggers the use case. It is possible to initiate the use case with the help of an intermediary or it could be time or state based initiation.
• Scope can be added to each use case if the use case context is not clear from its description. The scope could be – for example: enterprise, system, sub system etc. Graphical icons can be added to highlight use case applicability.
• Use cases can be applied even to describe the architecture or design. Many people find it easier to understand the design, architecture this way.
• Use cases can be written at different levels and this can be indicated as the scope to which the use case applies. At the outermost level the use case is said to be a ‘summary’ level use case. Similarly use cases can be written that are applicable to subsystems etc. Note that there are very few outermost level use cases. And these use cases provide context for other use cases.
• Having a clearly defined vision for the system helps in deciding whether some of the features should be part of the system or not. Similarly, having context diagrams, actor-goal list and in/out scope list helps in defining the system scope and helps in arriving at use cases at different levels.
• Use cases need to protect all the stakeholders’ interests even though they are not the primary users of the system.
• Finding the actors and goals is an iterative process. New actors may arise when the use case is being described – for ex: while writing a failure case. Start first with identifying the actors that interact with the system and list their goals. Then as you start detailing each use case, you may discover new actors. Add them to the list of actors and identify their goals. Iterate through this procedure till you can not find new test cases or actors. It is important not to miss any actors and their goals otherwise the system will not meet the expectation of all the stake holders.
• Writing down the backgrounds, skills and job descriptions of each actor would be useful. User interface designers can use this information for designing appropriate user interfaces.
• Use cases can be partitioned into different packages based on the actors and can be handed over to different teams for development.
• It is best to avoid naming actors based on their job titles for ex: dispatch clerk etc. It is best to name them according to the role they play with respect to a goal. Note however that, initially actors names can be identified based on their specific jobs and later can be replaced with more generic roles. The reason behind this is that – an actor may play different roles as part of his job responsibility. Or many actors can play the same role. It may so happen if we name the actors based on their job titles that if one or more of his roles are moved to another person it may pose difficulty in maintaining the use case document and also in the software design. Keeping a table of actor to role list might help in user interface and design phases.
• The system may use other systems to achieve the goal of primary actors. These systems are called secondary actors or supporting actors. When the system uses other systems to realize the goal, the interface between the systems, the data format, protocols etc needs to be captured.

 

Monte Carlo simulation: Predict how certain is uncertainty..

Uncertainty is a fact of life. Uncertainty arises because of many reasons – incomplete knowledge about the reality, complexity, our limitation to predict future events, unforeseen major events etc. We still need to plan, execute and compete in the face of uncertainty. How can we say, then, the probability of success, the best case, worst case, average case estimates of our projects based on the current uncertainties? One of the things we can do is calculate the estimates separately for each of these cases. This is not only tedious, this does not allow asking questions like – what is the probability that the project will be completed within 2 years, 2.5 years, 3 years etc. You can think that a project can take many different paths due to the inherent uncertainties present. Due to this, it can take different time, cost( effort) etc for completion. We may be interested in knowing the spectrum of these time, cost etc variations to make better decisions. This is where the Monte Carlo simulation comes handy. It can walk through the different paths and generate nice graphs that show the time, cost etc distributions with probabilities.

Monte Carlo simulation models can simulate ‘reality’, help make predictions about the future outcome and help in making better decisions. It helps teams cope with uncertainties better. Monte Carlo models can walk through thousands of scenarios and generate predictions by taking randomness into account. Compare this with the difficult mathematical equations which are difficult to solve; some are even intractable. It does not require the users to be very proficient in mathematics. There are many commercial Monte Carlo simulation tools available.

The Monte Carlo simulation models require the inputs to posses a distribution rather than a single number. Generally, normal distribution, triangular distribution etc(also called parametric distributions) are quite popular. If you have historical data( also called non-parametric distributions), the tools will accept them instead of the parametric distributions. By providing the distributions instead if single point estimates we are incorporating randomness into our models. This approach is close to reality than the single-point estimates. How do you interpret the some of the properties of distributions? The mean ( also called the first moment) represents the most expected value. The variance ( also called the second moment) represents the risk associated, the third moment represents the distribution’s skewness and fourth moment measures the peakedness. The accuracy of the model depends on the level to which you have modeled and also the correctness of the data.

If you have data that are correlated you can also include them in the model and make the model know about it. Make sure you include the assumptions as part of the model. You can do sensitiveness analysis of the results on the assumptions. If the results are highly sensitive to one or more assumptions, you need to track the assumptions more closely. You can move them to risks if need be or spend some time to get more clarity on those assumptions.

Monte Carlo simulations can are also used in the robust design techniques. It uses the simulations to carry out the sensitivity analysis, robustness of the design etc. It helps in making the designs robust that can tolerate variations in the process, materials etc and ensures very high quality products.

Monte Carlo simulation tools are also used heavily in finance. It is used for risk analysis, forecasting, sensitivity analysis etc. It is also used by marketing, sales and other disciplines.

Monte Carlo simulation has a wide variety of application than the ones listed above. It is easy to use at the same highly useful.

As always, comments, different views etc are welcome!

Architecture Selection using Pugh Matrix

One of the useful yet very powerful tools that can be used for selecting among alternate architectures is – Pugh Matrix. Pugh Matrix is one of the popular Design For Six Sigma (DFSS) tools used for selecting among different concepts, tools, ideas etc. It is a recommended practice in Software Architecture that alternate architectures be identified and then compared against a set of criteria during the architecture phase. These criteria are usually derived from the Quality Deployment Function (QFD) matrix. From the QFD, the factors that are important for the success of the product are identified. These factors are called – Critical To Quality (CTQ).

Once the CTQs are identified using the high-level QFD, these can be flowed down to the architecture level QFD and the factors that are important for the architectural phase are identified. Typically, an architect comes up with more than one architecture for a given product. Most of the times than not, the process of selecting the best among the candidate architectures is ad-hoc. Usually, the selection is based on experience, intuition and heuristics. The Pugh Matrix provides a method for systematically comparing among different alternatives. Pugh Matrix is very simple to use. As the name suggests, it is a matrix that comprises of rows and columns. The rows are the CTQs derived from the Architecture Level QFD and the columns are the different candidate architectures. The CTQs can be assigned different weights depending on their importance. The alternates are compared against these criteria and the best among them is selected. The process can be iterative.

The Pugh Matrix looks like below:

What is the recommended process of using the tool to get best results? For getting better results, it can be performed with the team so that the results are not biased. The other approach is – each team member performs this process independently and the results are compared. If there are differences in the results among different team members, then they should be discussed with the team and a common consensus should be arrived at.