Slide #3
As a PM, you’ll carry out interviews with users at various phases of a project. During the Initiation phase, you’ll interview stakeholders in order to establish the business rationale and scope for the project and to collect initial requirements. During the Discovery phase (and, on iterative projects, during the Development phase), you’ll meet with users to discover and document the business requirements for the new (or revised) software system.
As you gather the requirements in these phases, you’ll hold review sessions with stakeholders to verify the correctness and completeness of the requirements documentation. During the Final V&V phase, you’ll meet with stakeholders to validate that the software meets their requirements. Table describes different interview formats and when each type is used during the project lifecycle. Please note that on an iterative project, any interview type associated in the table with the Discovery phase is also used during the Development phase, since requirements analysis continues as the solution is developed.
Slide #4
What Happens During the Initiation Phase? During the Initiation phase, the project grows from an idea in someone’s mind into a bare- bones proposal that outlines the main aspects of the project and describes the main reasons for pursuing it. During this phase, your job as a Product Manager is to identify and analyze the business requirements for the project. You’ll identify high-level business goals as business use cases. You’ll be working with stakeholders to analyze stakeholder participation using business use-case diagrams. And you’ll communicate to stakeholders an emerging consensus regarding workflow using activity diagrams.
How Long Does the Initiation Phase Take? Basically, it “should be a few days’ work to consider if it is worth doing a few months’ work of deeper investigation.” For larger projects, it may take months. Deliverables of the Initiation Step: PRD (Initiation Version) As you work through the B.O.O.M. steps, you’ll use a single document, the business requirements document, or PRD, to describe business requirements throughout the project life- cycle. You begin working on the PRD during the Initiation phase. Different organizations handle this documentation in different ways. The PRD may be a single living document or a requirements package that resides as separate components that are assembled in different ways for different audiences.
Some other names for the documentation produced during the Initiation phase include the following: Opportunity evaluation: Documents the proposed benefits of the project. Project vision and scope: Describes what the project hopes to achieve. Product vision and scope: Describes the objectives for the software product.
Slide #7
In your first meetings with stakeholders, you want to identify the end-to-end business processes that the IT project will affect. These processes are business use cases. A business use case is a business process representing a specific workflow in the business—an interaction that a stakeholder has with the business that achieves a business goal. It may involve both manual and automated processes and may take place over an extended period of time. Any IT project has the potential to change the business environment—how steps (both manual and automated) within a business are performed and the roles and responsibilities of employees. By focusing on business use cases at the outset of the project, you ensure that this business perspective is not forgotten.
Slide #8
Business actor: Someone external to the business, such as a customer or supplier. Worker: Someone who works within the business, such as an employee or a customer-service representative. Association: An association between an actor and a business use case indicates that the actor interacts with the business over the course of the business use case—for example, by initiating the use case or by carrying it out.
Slide #9
Now that you have a business use-case diagram that matches up stakeholders with business processes, you can begin to plan the next stage of the interviews. Each interview should focus on a subset of the business use cases. Be sure to invite all stakeholders associated with the use case (as shown on the diagram) as well as off-stage stakeholders—those who do not directly interact with the process but still have a stake in it, such as regulators and high-level management. The purpose of these interviews is to analyze the workflow of each business use case. Workflow means the sequencing of activities and (optionally) a clear designation of who carries out each activity.
Workflow can be documented in text and/or through the use of a workflow diagram. The business façade—the interaction between the business area and entities outside of it—is best described in text. If you are analyzing business use cases for the broad purpose of improving the business process, you may want to use a formal template for documenting the interaction. If you are analyzing business use cases only as a means to an end—the end being the system use cases—then an informal text description will probably suffice. This is the more common situation we are presuming. In either case, if the workflow for the interaction is too complex to describe clearly in text, append the text with an activity diagram. To document the internal process used to carry out the business use case, use an activity diagram with partitions (swimlanes). Activity diagrams are UML-compliant examples of workflow diagrams.
Slide #10
Objects may be considered to be in various states during their lifetimes. For example, invoices pass through some of the following states: Created, Due, Paid, Past 30 Days, Written Off. To find out what these states are, simply ask the stakeholders to tell you what statuses they consider a business object to be in. Anything they refer to as a status can generally be treated as a UML state. What makes some changes to a business object important enough to be considered changes of state? The business treats the object differently because of the change: For example, there are rules for the sequence in which the object may move in and out of the state, or the objects’ response to external events differs.
Figure a indicates that the Set Gathering Date activity causes a case to move into the Scheduled state. After this, a Prepare Stakeholders activity is performed. This is followed by the Convene Gathering activity, which takes as input a case in the Scheduled state. Once the activity has been completed, the case will be in the Resolved state. The previous example illustrates some of the main features of object flows: Object flow: A dashed line with an open arrowhead. An object flow connects an object to an activity. When the arrow points away from an activity, the object flow indicates that the object (or object state) at the tip of the flow is a result (output) of the activity.
When the arrow points to an activity, it indicates that the object at the source of the flow is required by (input to) an activity. Object: The object that is required, created, or altered by an activity. Name the object according to the format : <[statename]>—for example,a:Case [resolved].You may omit object Name—for example, :Case[resolved]. As well, you may omit the state name—for example, a:Case. An object may be a source or destination of an object flow, or both. One activity diagram may include objects of many classes and different objects of the same class. As well, the same object may appear more than once on an activity diagram, as in Figure a. If an activity produces an object as output, and this same object is the input for the next activity, you may omit the control flows between the two activities. In Figure b, a control flow between the Set Up Interviews and Interview Stakeholders activities is not required.
Slide #11
To indicate who performs each activity, you add partitions (commonly referred to as swimlanes) to the activity diagram. A partition is depicted as a column (or row) on an activity diagram. Allocate one partition for each object that takes an active part in the process flow. Each partition represents a stakeholder (business actor or worker) who carries out some activity. Although you shouldn’t spend too much time focusing on technology at this time, you may also show a computer system as a partition. Position every activity in the partition of the object that performs it. Name each partition at the top of the column, according to the participating object, as shown in Figure You may use an informal, simple name for the partition, identifying the actor who carries out the task—for example, Problem Identifier. A better approach is to use the more formal form : . className is the name of the role—that is, the worker, business actor, or external system that participates in the activities. objectName identifies a specific instance (or example) of the role—for example, Mr. Dudu: Problem Identifier. This format is recommended because it allows you to show the participation of more than one instance of the same actor—for example, two different Problem Identifiers involved in the same business case. The objectName in this format is optional. If you wish to omit it, don’t forget to leave in the colon—for example, :Peace Committee Operations. When using a modeling tool, the formal format has the added advantage of allowing you to conveniently name the partition by dragging actors from the browser to the partition in the diagram window.
Slide #13
Now that you have an understanding of the end-to-end business processes, it’s time to begin thinking about how the proposed IT system might help automate these processes. System use cases help you imagine the IT system from a user perspective, by focusing on the user’s goals. If the project is large, you will need to find a way to break up the work so that a number of analysts can work in parallel. First, you need to standardize common issues so that all team members handle them consistently. One of these issues is the way that users of the IT system will be documented. To address this issue, you create a diagram called a role map. Another issue is how to break up the user requirements into manageable pieces. You address this issue with system use-case diagrams.
Slide #14
In this step, you identify the IT system’s users, or actors. Previously, when we spoke of actors, it was in relation to business use-case modeling. There we spoke of business actors and workers. From this point onward, however, we are doing system use-case modeling and will speak simply of actors. An actor, in this context, is a role played by a person or system that interacts with the IT system. An actor is a type of user or an external system that interacts with the system under design.
Similar Terms: External agent/external entity: Equivalent terms used in structured analysis. Stakeholder: A term more inclusive than actor as it includes anyone who the project will affect even if they do not have direct contact with it. Finding actors To find actors, go through your list of business actors and workers, eliminating any who don’t interact with the IT system. Then add any external systems and human users who are required because of the technology. (Remember that when you performed business use-case modeling, your focus was not on technology, so you may have missed some of these actors.)
THE ROLE MAP: A role map is a diagram used to standardize the treatment of users and external systems throughout the project. A role map is a restricted form of a use-case diagram. Whereas the use-case diagram shows actors and their associations with use cases, the role map shows only actors. Place icons for each of the actors you’ve identified in the role map. The role map then becomes the central diagram team members go back to whenever they want to know how to depict a user in the model. You can also use the role map to show the ways in which user roles overlap.
Slide #16
You document actors with overlapping roles by drawing a generalization relationship between actors. Any time the phrase “a kind of ” comes up in the discussion of actors, think about using the generalization relationship. For example, a Bookkeeper and an Accountant are two kinds of Accounting Staff. Exactly how you draw the generalization depends on how the roles overlap. We’ll look at two types of situations: Actors whose roles partially overlap. An actor whose role completely encompasses another’s.
Slide #17
When two actors have some overlap in their roles, but each actor can do things with the system that the other can’t, model the actors as specialized actors and invent an abstract generalized actor to represent the overlap. The term generalized implies that the specialized actors inherit something from the generalized actor. In this case, the specialized actors inherit the ability to do all the things that the generalized actor can do. (Formally, the specialized actors inherit the associations that the generalized one has with system use cases.) The term abstract means that the invented actor is not real. (In OO-speak, the abstract actor is never instantiated.) The generalized actor is not a true role but an abstract concept meant to represent the shared aspects of other roles. Figure shows how to depict actors with partially overlapping roles.
Slide #18
In other cases, an actor might be able to do everything that another actor can do and more. In this situation, model the actor with the restricted role as the generalized actor, and model the actor with the larger role as the specialized actor. This may look odd at first, since the diagram tends to make the lesser role “more important.” This is due to the common practice of drawing the generalized actor above the specialized actor. The UML, however, does not dictate the placement of symbols on a diagram.
If your users object, just draw the diagram “upside down.” But make sure that the generalization symbol still points from the specialized actor to the generalized actor. Figure shows how to depict such a relationship among actors. Important to note: The generalized actor, in this case, is not an invention but a real role. It is therefore considered to be a concrete (as opposed to abstract) actor. What’s the Point of Defining Generalized Actors? They simplify the drawing of use-case diagrams. Soon, you’ll be creating use-case diagrams that indicate which actors are associated with each use case. If all of the specialized actors of one generalized actor are associated with the same use case, you’ll be able to draw a single association line between the generalized actor and the use case instead of lines from each of the specialized actors.
Slide #19
If your project supports only one business use case, you may proceed directly to the following step, identify system use cases. But if it supports a number of business use cases, consider creating system use-case packages. A system use-case package is a collection of system use cases and the diagrams that describe them. The UML package icon looks like (and acts similarly to) a Windows folder. By defining the packages now, you are, in effect, setting up a filing system that all members of the team will use once the analysis really gets under way. What Criteria Are Used to Group System Use Cases into Packages? The UML does not impose any criteria, but here are some common approaches: Group system use cases by the main actor who uses them.
For example, group together into one package all the system use cases used by general administration. Create a system use-case package for each business use case. For example, in an insurance system, the customer sees the end-to-end process, Make a Claim. To the customer, this represents one business goal; however, to achieve it, the company’s workers require a number of discrete interactions with the computer system: Record claim Validate policy Adjust claim Pay claim Each of these interactions qualifies as a system use case. Since they all contribute to the same high-level goal, a good way to group them is to bundle them all in the use-case package Make a Claim. The second option has the advantage of placing logically related system use cases together. This is the approach you’ll follow as you work through the case study. Look out for system use cases that can be reused in more than one business context. Place any of those system use cases, if you find them, in special packages reserved for system use cases that transcend any one business use case. Documenting commonly used system use cases in one central place promotes reuse and consistency of treatment. Naming Use-Case Packages Formally, because a package is a thing—specifically, a container—it should be named with a noun phrase. On the other hand, because of the way we are using the packages, it makes sense to name each package according to the business use case it supports. This makes tracing easier—from the business use-case model we worked on earlier to the system use-case model we are now developing. Either approach is acceptable.
Slide #20
The diagram used to represent system use-case packages is, formally, a use-case diagram— though it looks a little odd in that it does not depict any actual use cases. Figure shows some of the system use-case packages for a credit-card system and the actors who interact with them. The direction of the arrow from the actor to the package indicates whether an actor initiates system use cases in the package (in which case the arrow points away from the actor) or whether the use cases initiate some action by the actor (the arrow points to the actor). Note that the arrow connecting the actors to the use-case packages is a dashed line with an open arrowhead. The dashed line indicates a dependency—a loose connection between modeling elements that means one element has some awareness of another one—and the arrowhead indicates the direction of the dependency. (Formally, the initiating actor is aware of system use cases in the package; in the case of non-initiating actors, it is the system that is aware of them.) You may avoid using the arrowheads but you must use the dashed line as opposed to a solid line; the UML does not allow a solid line (association) between actors and packages.
Slide #21
Connect the package to the generalized actor. For example, suppose that VERIFY was only one of a number of systems able to verify a person’s credit and that the system under design needed to be able to communicate with all of them. You would indicate that as shown in Figure
Slide #22
The next step is to identify the system use cases that go into the packages. You do this by going back to the business use cases and reviewing the activities they describe. First try to determine, with stakeholders, which of these activities fall within the scope of the IT project. Where things are currently being done manually, you’re looking for activities that could be either fully or partially automated by the IT project. Where things are being done using IT, you’re looking for opportunities for improvement. Once you’ve identified the activities, you’ll need to group them into system use cases. Imagine the system.2 How will someone sitting at a terminal actually use this system? What result is the user trying to achieve from the computer system with each interaction? Each of these results, expressed as a user goal, is a system use case. For example, for a Web banking system, some system use cases are View Transaction History, Transfer Funds, and Pay Bill.
Slide #23
System use cases become the central tool that governs the management of the project. With their user perspective, they keep the team focused on the user throughout the project. Here’s how: The requirements are written from the user’s point of view. Prior to use cases, requirements were often written as a list of capabilities, such as, “The system must be able to….” With system use cases, the documentation is instead written as a narrative describing the user’s experience using the system. System use cases help ensure that the user receives useful functionality with each release when a project is managed iteratively. With iterative project management, the system is analyzed, designed, coded, and often released in several passes. At each pass, one or more system use cases (or selected use-case scenarios) are developed. Because each system use case achieves a meaningful goal for the user, the user is guaranteed useful functionality at the end of each iteration. System use cases lead to user interfaces that are organized from a user perspective. Most people have had experience with systems that require the user to bounce around screens or a site just to get one unit of work done. This happens because the developers have organized the user interface from their own point of view. When the interface is organized around system use cases, each option presented to the user represents a complete activity from the user’s perspective. System use cases yield a set of test cases that encompass the ways users use the system. Because a system use case describes the way that an interaction plays out, it is very close to being a test script. And the way the text is typically organized, as separate “flows,” makes it easy to identify test scenarios.
Slide #24
Once you’ve decided what system use cases are required to support a business use case, you document your findings in a system use-case diagram. Create one (or more if necessary) system use-case diagram for each system use-case package. The system use-case diagram shows which actors participate in each system use case. The diagram does not show sequencing; you can’t tell from the diagram the order in which the system use cases should be used or the sequence of activities within each use case. (To show sequencing, use an activity diagram instead.)
Figure shows a system use-case diagram. It illustrates the following modeling elements: PRIMARY ACTOR: An actor who initiates a use-case interaction (indicated as an actor at the tail end of an arrow pointing to a use case). SECONDARY ACTOR: An actor that the system initiates an interaction with after the use case has started (indicated as an actor at the tip of an arrow pointing from a use case). SYSTEM USE CASE: A user task (indicated as an oval).
Figure shows: Primary actor Secondary actor System use case. Here’s what the diagram says: A CSR (customer service representative) or a manager enters credit card–application information A manager may adjudicate a credit-card application. The system use case, once underway, may involve an interaction with an external computer system, Adjudication System—for example, by requesting a maximum allowable credit limit for the customer based on application information and credit history. The system use case may also involve an interaction with a bank customer—for example, by emailing the customer a letter of acceptance or rejection. How Many Primary Actors Can a Use Case Have? In the situation modeled in Figure, either a CSR or a manager can initiate the system use case, Enter Credit Card Application Information. In this situation, the practice followed by me is to indicate both as primary actors—the implication being that either the CSR or manager may initiate the interaction. Others argue against this practice, however, because they would interpret this to mean that both actors are required to initiate the use case; those following this approach would indicate only one actor, a CSR, for this use case, since that is the role being played regardless of the user’s job title.
Be aware, in any case, that the issue of whether multiple primary actors indicates an or (either actor may initiate) or an and (both are required to initiate) is controversial. What if the manager is acting in a truly separate role, however, as the authorizer of information previously entered during the use case by the CSR? In that case, all practitioners would model the manager as an additional actor for the use case. Whether the actor is primary or secondary depends on who initiates the interaction between the manager and the system. If the system does—for example, by sending a request for approval to the manager—then the manager is a secondary actor. If the manager does—for example, by signing in and selecting the case for review—then the manager is a primary actor.
To draw a system use-case diagram, follow these steps: 1. Copy all the actors connected to the package in the main use-case package diagram onto the new diagram. This will ensure that you don’t forget any actors.
2. Draw a system use-case symbol (an oval) to represent each user goal within the package.
3. Connect the actors to the use cases using the UML association symbol: a solid line that may, if desired, be adorned (as UML puts it) with an open arrowhead. The following steps explain the rules for drawing the association.
4. Connect an actor to a system use case if the actor participates in any way while the use case plays out. If all you can say at this time is that the actor participates somehow, use a solid line.
5. If the actor initiates the system use case, draw an arrow that points from the actor to the use case. This designates the actor as a primary actor for the use case. Note that the direction of the arrow indicates who initiated the interaction (it always points away from the initiator). The arrow does not indicate the direction of the data. For example, a user initiates a query transaction. The arrow points away from the actor even though the data moves from the system to the actor.
6. If the actor gets involved only after the system use case has already begun, draw the arrow from the use case to the actor. In this case, it is the system (of which the use case is a part) that has initiated the interaction with the actor. This type of actor is termed a secondary actor.
7. If several possible actors may initiate the system use case, connect all of them to the use case as primary actors. This does not break the “one initiating actor” rule. In any particular execution of the system use case, only one of these primary actors is involved. (Keep in mind, however, that as previously discussed, there is controversy around this issue: Some interpret two primary actors to mean that both must be involved, as opposed to the interpretation of this book, that either may be involved.) You may also designate more than one secondary actor for the use case, if appropriate.
8. If all of the specialized actors of a generalized actor participate with the use case, draw an association between the generalized actor and the use case. It implies association with the specializations. Is There a Rule of Thumb for How Many System Use Cases a Project Would Have? No. Ivar Jacobson (one of the lead names in UML) recommends about 20 use cases for a 10 person-year project. Martin Fowler (chief scientist, thoughtworks) reports about 100 use cases for a project of the same size. Keep in mind that one reason for splitting requirements into system use cases is to assist the planning of releases. Try to size the system use cases so that you can roll out one or more complete system use cases (or use-case scenarios) in each release.
Slide #28
Once the Initiation phase of the project is over, you need to “baseline” your analysis. This simply means saving the state of the analysis at this point and putting it under change control. By baselining your documentation, you ensure that if changes are requested later, you’ll be able to check whether they represent a change from the original scope of the project. Keep in mind, however, the exception for agile projects, where the requirements are not baselined unless they are under development.) The analysis up to this point also becomes the starting point for the next phase of the project, the Discovery phase