CHP 32

7/21/12
Object-Oriented Analysis and Design Using UML: Student Guide
Chapter 3
Understanding Requirements Modeling
Before defining any system you should analyze and understand the problem, identify the stakeholders need, and document all the requirements. This will help in better understanding of the current system and the goals that need to be achieved by the new software system. UML provides modeling techniques for analyzing and documenting the requirements of a software system. This chapter includes the process of analyzing a problem by using business and system modeling. In addition, it explains the creation of use case diagrams for system modeling.
Objectives
In this chapter, you will learn to: Analyze a problem by using business and system modeling Create use case diagrams for system modeling
www.niitstudent.com/india/Content/063OUML1S1/OEBPS/09_ch03.htm
1/34
7/21/12
Defining the System

You should not commission a software project until you have all the requirements of the project available for preliminary planning. Lack of clarity in understanding the requirements of the existing process leads to rework in the designing of the new software system. Defining a new software system consists of the following phases: Analyzing a problem Identifying stakeholders Identifying, gathering, organizing, and documenting the requirements
Analyzing a Problem
The problem analysis phase of a software project involves preparing a concise problem statement that specifies the problem in the existing software system or the workflow of the organization and the constraints that exist for the proposed solution. A problem statement should include the description of the existing processes and the goals that need to be achieved by the new software system. In addition, you should define a problem statement in the terminology understood by the customer instead of the software jargon. This ensures that the proposed software system will conform to the customer requirements. You can analyze the existing process or software system to create a problem statement by using the following modeling techniques: Business modeling System modeling
Business Modeling
Business modeling is a visual modeling technique that describes the working of the existing process of an organization and the role that each person plays in the process. In other words, business modeling provides a comprehensive overview of the working of the business. The technique enables the development team to focus on the areas that can be automated to improve the efficiency of the business. It also helps identify the changes and enhancements required to implement a new system. After the business requirements for a software project are understood a business case is developed. A business case is a document that contains the cost benefit justification for the project. This information enables a manager to decide whether to support the project before significant resources are committed to its development. The overall intent and purpose of the proposed system is documented in a vision document. The vision document is created for the software development team so that they are clear on the purpose and scope of the project. The document provides an overview of the software being developed. It provides a macrolevel view of software requirements.
www.niitstudent.com/india/Content/063OUML1S1/OEBPS/09_ch03.htm 2/34
7/21/12
The vision document captures the structure of the proposed system to communicate its intent. Broadly speaking, it lists a statement of the problem, key stakeholders, user needs, a list of the features of a system, and use cases. The vision document also specifies the key stakeholders, key features, and the constraints of the software. Using UML for Business Modeling UML provides various notations for the constructs that enable you to create a business model of the existing software system or process. The following table shows the business modeling constructs and their corresponding UML notations.
3/34
7/21/12
The examples of non-human actors are: Other systems: When a system or a process interacts with the system, it should be represented as an actor. Date or time: When a use case is initiated by the events, such as date or time,
7/21/12
then the events should be modeled as an actor. For example, a software system attached with an appliance needs to start at 6:00 P.M. and should stop at 6:15 P.M. In this case, time initiates the working of the software system and, therefore, becomes an actor for the system. Triggers: When a trigger, such as temperature, initiates a use case then it should also be represented as an actor. For example, a software system to maintain a particular range of the temperature is initiated when the temperature goes below its lower limit.
Business modeling provides the following two models to analyze the existing system: Business use case model: Represents the functions of the existing process by using business actors and use cases. The business use-case model uses business use case diagrams and abstract activity diagrams to outline the activities for the existing system. Business object model: Represents extensive interaction between business workers and business entities. For example, a business object model can show the procedure of acceptance of quotations by a department. The quotations are represented as entities, the department that accepts the quotation is an actor because it initiates the quotation process, and the departments that send the quotations are business workers. A business object model uses the following diagrams for an extensive representation of the workflow of the existing processes or the existing software system of an organization: Class diagram: Shows the static or internal structure of the business in the form of relationships among various classes for the existing system. The classes in the class diagram represent either a business worker or a business entity. These diagrams also show the collaborations between the business workers and business processes in the existing system. Activity diagram: Represents the flow of activities of the existing system. The diagram represents the dynamic nature of the system and enables you to identify the parallel activities as well as the alternate paths for these activities. It also represents the roles and responsibilities of each business object in the existing system. Interaction diagram: Represents the interaction between business workers and business objects to perform a business function. Interaction diagrams are of four types, communication, sequence, interaction overview, and timing. Analyzing a Hospital Administration System Consider a problem statement of a hospital administration system. A patient needs to take an appointment for a doctor from the receptionist in the hospital. The receptionist checks the schedule of the doctor and gives the appointment accordingly. The hospital has categorized patients into two age groups: up to 14 and above 14. The receptionist ensures that patients up to 14 years are given an appointment only with a child specialist. The cashier accepts the fees from the patient after each visit. This fee varies according to the doctor attending the patients. During the first visit of the patient, the doctor enters the relevant personal information about the patient in a computer, for future reference. The doctor also enters the health history of the patients, the reports of the tests, if any, and the medicines prescribed to the patients. The doctor can also print the prescription slip and
7/21/12
give it to the patient. When the patient goes to the store, the storekeeper accepts the payment, and gives the prescribed medicine to the patient. To ensure that there is uninterrupted supply of medicines, the storekeeper orders new stock when the quantity of a medicine reaches the reorder level. The storekeeper can also order new medicines. The hospital administration system needs to be automated. The proposed software system of the hospital administration system should be able to offer the following functions: Provide an automated voice response system over the phone that receives the phone calls of the patient and schedules an appointment. The automated voice response system should also enable a patient to cancel the existing appointment. Provide an automated system that sends a requisition request for medicines whenever the quantity of medicines reaches the reorder level. Automate the payment procedure from the patient for the services of the doctor and the purchase of medicines. Automate the schedule modification process. The doctor should be notified about the cancellation of any appointments due to the change in schedule. If the doctor still wants to change the schedule, then all the affected appointments should be cancelled and the patients should be informed accordingly. Let us identify business use cases, business workers, and business actors to analyze the existing process of the hospital administration system. The business use cases identified for the existing hospital administration system are: Take Appointment: Describes how the receptionist gives an appointment to the patients based on the schedule of the doctor and the category of the patient. This business use case is initiated on the patient's request or when the doctor wants to schedule a new appointment. Deliver Medicine : Describes how the storekeeper delivers medicines to the patient. This business use case is initiated when a patient buys the medicine. Accept Fee : Describes how the cashier accepts the fee from the patient. This business use case is initiated when the patient pays for the services of the doctor. Print Slip: Describes the procedure of printing the slip on the doctor's computer. This business use case is initiated when a doctor creates the prescription and gives a print command for the same. Accept Payment: Describes how the cashier accepts payment from the patient for the medicines purchased from the store. This business use case is initiated when the patient buys medicines from the store. Reorder Medicine : Describes how the storekeeper orders the medicines. This business process is initiated when the quantity of the medicine falls below the reordering level or the storekeeper wants to buy new medicines. Modify Schedule : Describes how the doctor modifies the schedule. This process is initiated when the doctor wants to enter new information or modify the existing information in the schedule. The business actors for the hospital administration system are:
7/21/12
Patient: Initiates the T a k eA p p o i n t m e n t ,A c c e p tF e e , and A c c e p tP a y m e n t use cases and is external to the system. Doctor: Initiates the P r i n tS l i pand M o d i f yS c h e d u l euse cases and is external to the existing process. Reorder Level: Acts as a trigger to initiate the R e o r d e r i n gM e d i c i n euse case and is external to the system. Business workers are involved in carrying out a business use case or a business process. A person or an entity can act as a business actor for one process and a business worker for another process. For example, if Treatment is considered as a use case, then the doctor who is an actor for other processes becomes the business worker for the Treatment process. The business workers of the existing hospital administration system are: Receptionist: Attends the patient's phone calls and, therefore, is involved in the T a k e A p p o i n t m e n tuse case. Storekeeper: Delivers medicine to the patients and orders new medicine. The storekeeper is involved in the R e o r d e r i n gM e d i c i n eand D e l i v e rM e d i c i n ebusiness use cases. Cashier: Accepts fees and payment from the patient and, therefore, is involved in the A c c e p tF e eand A c c e p tP a y m e n tbusiness use cases. A business use case diagram for the hospital administration system shows the interaction between the business use cases and the business actors. The following figure shows the business use case diagram for the existing hospital administration system.
System Modeling
Business modeling enables you to understand the existing process and gather the requirements for the new
7/21/12
software system. On the other hand, system modeling gives a proposed solution to fulfill the gathered requirements. System modeling provides a System Context Diagram (SCD) to depict the flow of information between the proposed software system and its environment at the different levels of the hierarchy. The subsystems for the proposed software system are modeled as use cases. After the use cases are identified, you can derive other UML diagrams, such as the class, object, and activity diagrams, from these use cases. You can derive the use cases for the proposed software system from a business model. The following are the business modeling constructs that you can derive and use for system modeling: Business use cases : Enable you to identify the sub processes that constitute the proposed solution. Business actors : Map to the actors in the system model. Behaviors of business workers : Enable you to find system use cases and define the features for the new system model. Business entities : Help find the entity classes when you create the class diagrams. System Modeling for the Hospital Administration System You can use the identified business use cases to derive the system use cases for the hospital administration system. The use cases for the automated hospital administration system are: Modify Schedule : Enables the doctor to enter new information or modify the existing information in the schedule. Give Appointment: Gives an appointment to a patient by using the automated voice response system. Accept Fee : Accepts the payment from the patient for the services of the doctor. Reordering Medicines : Orders medicines whenever the stock of the particular medicines reaches the reorder level. Print Slip: Prints the slip on the doctor's computer. Accept Payment: Accepts payment from the patient for the purchased medicines. The new software system needs to interact with the existing software system. For example, the process of entering the information about the patient does not change, and the new software system should be able to use this information from the existing software system itself. As a result, a new use case, C o m m u n i c a t i o nw i t hE x i s t i n gS y s t e m , is required to create a link between the existing software system and the new software system. You need to include the C o m m u n i c a t i o nw i t hE x i s t i n gS y s t e muse case in the SCD. The following figure shows the SCD at the first level of the automated hospital administration system.
8/34
7/21/12
You will learn more about how to create a use case diagram for system modeling in the next section, Creating Use Case Diagrams for System Modeling.
Just a minute:
Which of the following diagrams of business object model shows the static or internal structure of the business in the form of relationships among various classes for the existing system? 1. Class diagram 2. Use-case diagram 3. Activity diagram 4. Interaction diagram Answer: 1. Class diagram
Identifying Stakeholders
The success of a project depends upon the satisfaction of the stakeholders. Therefore, it is necessary to identify the stakeholders before you develop the product. Identifying the needs of stakeholders enables a software team to make better decisions in the definition and implementation phases of the development process. You can define the need of a stakeholder as any
7/21/12
business, personal, or operational problem that should be solved to justify the existence of the new software system. You should interview the stakeholders to obtain the requirements of the new software system. The responses of the stakeholders are useful for system scope management and the requirement negotiation process. A few guidelines that you should follow when you interview the stakeholders are: Ask direct questions that enable you to identify how the new software system will fulfill the requirements of the stakeholder. Probe stakeholders to define the conflicting requirements in detail. Document the input gathered from interviews in a universally accepted language, such as English. The input provided by stakeholders during the interview is documented as the required features of the software system. A feature can also be defined as a service that the software system provides to fulfill one or more stakeholder needs. You need to provide additional information in the form of feature attributes when you document features. This ensures that the features are communicated adequately to the rest of the team. The attributes of the features that you should document are: Status : Indicates whether the feature is proposed for the next version, approved for the next version, or already incorporated in the previous versions. Rank: Indicates the level of priority of the feature. The ranking could be high, medium, or low depending on the stakeholder's need. This ranking helps manage the scope and determine the priority of the features. Effort: Indicates the effort in terms of the work hours required to incorporate a feature in the proposed software system. It is useful in estimating the number of work months and lines of code. You can assign the following three values to this attribute: low, medium, and high. Uncertainty: Indicates the probability of the feature causing undesirable events, such as cost overruns, schedule delays, or cancellation of the project. You can assign a high, medium, or low value to this attribute. Stability: Indicates the probability of a change in the feature. You can assign a high, medium, or low value to this attribute. Target release : Records the intended product release or iteration in which the feature will first be incorporated. Assigned to: Indicates who will be responsible to incorporate the feature in the product. It could be one person or the complete development team. Source : Tracks the source of the requested feature. It could be a reference to a page of the product specification document. You can use attributes to track, prioritize, and manage the features proposed for implementation. For example, the attribute, target release, records the software version in which you intend to incorporate the feature.
Identifying and Managing Requirements

Requirements define the features that the software system should deliver. Requirements form the basis on
7/21/12
which the system is built. Nonconformance to requirements can lead to the failure of the software system. Therefore, requirements identification and management is a very critical process in the life cycle of a project. Any software development project should follow a formal requirements management process that helps identify, document, organize and track the requirements. Requirement management is a continuous process that continues throughout the life cycle of the project. However, most of the activities pertaining to requirement identification, gathering, analysis and negotiation are performed in the requirements analysis phase. In terms of RUP phases, most of these activities will be performed in the inception and elaboration phases. As the project moves to design phase, these requirements are specified in terms of technical requirements and design concepts developed to fulfill these requirements. At this stage requirements may further be refined and some of them dropped. For example, requirements that are less important may be dropped to reduce the development time. In terms of RUP phases, most of these activities happen in the elaboration and construction phases. During designing and construction, these requirements may be validated to ensure that the design would be able to meet the stated requirements. At this stage, you may also need to fine-tune the design, refine the requirements, or change the priority of requirements. In terms of RUP phases, these activities are done during elaboration and construction phases and peak when any iteration is starting. The various phases in requirement management are: Requirements gathering Requirements analysis and negotiation Requirements specification Requirements validation
Requirement Gathering
Without gathering requirements, you cannot build a complete functional system. The factors that make requirements gathering difficult are: Scope : The scope is usually not well-defined because the stakeholders usually do not specify the requirements completely. Requirements understanding: Requirements are usually not understood completely. This is because stakeholders are not sure of the functions that should be included in the software system. As a result, requirements keep on changing throughout the development process. Volatility: The requirements are volatile. This means that requirements keep on changing and new requirement keep on adding during the development process. You need to follow a systematic approach to gather requirements. The various activities involved in gathering requirements are: Assess the economic, technical, and operational feasibility for the proposed software system: Economic feasibility: Signifies the economic value that the proposed software system will add to the existing process. Technical feasibility: Indicates whether or not it is possible to develop the
7/21/12
proposed software system. Operational feasibility: Indicates whether it is feasible to install the new software system in the operational environment of the existing process. Identify the stakeholders and end users who specify the requirements and jargon that appear in the existing process. Identify the domain constraints that limit the working of the proposed software system. Identify the methods for requirement elicitation, such as the activities to interview stakeholders and hold team meetings between the development team and the stakeholders. Identify the ambiguous requirements that can be made clear using prototypes. Identify the expected requirements, which are the trivial requirements that stakeholders do not specify. Such requirements are also called implicit requirements. For example, the user-friendly interface of a Graphical User Interface (GUI) application is an implicit expectation of most stakeholders. The output of the requirements gathering phase is in the form of various documents, such as: Statement of need and feasibility Bounded statement of scope for the product List of all the participants and stakeholders involved in the requirements gathering activity Statement that describes the environment in which the software system will operate List of all the requirements of the proposed software system and the constraints imposed on the proposed software system Statement that contains the prototypes identified to remove ambiguity from the requirements
Requirement Analysis and Negotiation

Requirement analysis is the process to categorize and organize requirements based on the documents produced in the requirements gathering activity. You can classify requirements into functional and nonfunctional requirements. Requirement analysis enables you to define and represent the behavior of the software. The process enables you to segregate information and behavior in a way that uncovers detail in a hierarchical structure. Functional Requirements Functional requirements are derived from the need of the stakeholders and include the functions and features of the software system. You can use the business use cases of the existing software system to identify the functional requirements of the proposed software system. For example, in the automated hospital administration system, the functional requirements could be to: Accept telephone calls from patients to give new appointments and cancel the existing appointments. Generate reports of patients based on their name, age, or prescription slip. Generate a report of all the patients who visit a particular doctor on a particular day. Use the reorder level to order new medicines.
12/34
7/21/12
Non-Functional Requirements Non-functional requirements are qualities that a software system should possess other than those concerning its functionality. Examples of non-functional requirements are security, performance, reliability, maintainability, and scalability.
Requirements Specification
Requirement specification is an activity that involves converting the requirements analyzed in the analysis phase into technical requirements that can be implemented. The documented requirements need to unambiguous. The Software Requirements Specification (SRS) is a document produced at the culmination of the analysis task. This document provides the detailed description of the information domain and each function that needs to be performed by the software. It also provides information about the behavioral description of the software system. The SRS document should be: Consistent Concise Complete Flexible You can use various formats to create an SRS. An SRS must provide the following information: Definition of the software system Purpose of the SRS document Scope of the software system Functional requirements Non-functional requirements Conditions under which the proposed software system operates
Requirement specification is not specific to software engineering. It is also used in hardware and database engineering.
Requirement Validation
Requirement validation is an activity that involves validating all the requirements after they are specified. Normally, the quality department performs requirement validation to ensure that each requirement is clearly understood and is measurable. A checklist is used to ensure that a particular customer requirement is practical and properly understood by the developers. The objectives of the checklist are: Identifying all the ambiguous requirements Identifying the source of each requirement Stating the requirements quantitatively Identifying the dependence among the requirements
7/21/12
Verifying if the requirements are concise, testable, and traceable Verifying that no requirement conflicts with the constraints imposed on the software system
Requirement Gathering Techniques

It is important to capture the correct requirements for a software system. To gather requirements effectively, you need to follow a predefined approach. Using multiple techniques for gathering requirements helps in effective requirements gathering. The commonly used requirement gathering techniques are: Interview stakeholders. Conduct brainstorming sessions among stakeholders. Prepare questionnaires. Observe the existing processes of the organization. Appoint a domain expert.
Interview Stakeholders
You need to interview customers to understand the software system requirements in detail and develop a clear understanding about the expectations of the customer from the proposed software system. Interviewing involves a context-free discussion, which enables you to ask questions to the customer to obtain unbiased input. The questions asked during the interviewing session should be short and should emphasize on understanding the software system requirements clearly. The context-free questions that you can ask during the interview are: Who would use the system? What should be the output of a particular function? A member of the technical team can use a structured interview template to conduct the customer interview. You need to perform the following activities to conduct a far-reaching customer interview: Identify the people who will be interviewed. Review the questions to be asked in the interview. Re-examine the background of the company and the stakeholder to be interviewed. Ask relevant questions by using the template. Record the answers during the interview.
Conduct Brainstorming Sessions

In brainstorming sessions, the stakeholders suggest the possible system requirements and discard insignificant and redundant ideas. Brainstorming helps the stakeholders to identify new features and resolve ambiguities in the requirements, if any. Brainstorming involves the following activities: Idea generation: Focuses on the task to generate new ideas. The goal is to outline as many ideas as possible. Idea reduction: Focuses on the task to reduce the ideas already generated. This activity also involves the task to prune, organize, eliminate, group, and refine ideas to obtain concrete ideas
7/21/12
to develop the system. Before a brainstorming session, the rules and objectives for the session are clearly defined. The facilitator asks the participants to share their ideas aloud. The various features of a brainstorming session are to: Encourage participation by all the stakeholders. Allow the participants to criticize as well as appreciate additional ideas. Generate multiple ideas in a short span of time. Arrive at solutions in case of overlapping system requirements.
Prepare Questionnaires
Gathering requirements through questionnaires is a technique that involves the task to ask questions to gather information. The questions can be about the expected software system behavior, the time required to complete the project, or the required output of a particular process. Normally, the questionnaire round is conducted before interviewing the customer. This round prepares the customer for the interview as a questionnaire is sent to all the stakeholders. The customer needs to answer the questionnaire keeping the perspective of the software system requirements in mind.
Observe the Existing Process

The observation technique requires you to visit the customer site to understand how the existing process works and to identify the people involved in a process. For example, to automate the account keeping process of a bank, the system analyst visits the bank. The system analyst needs to identify the flow of information from one department to another. The analyst observes the documents and the bank employees involved in the information flow. The analyst also identifies how each transaction is recorded in separate books of accounts. This enhances the understanding of the requirements of the software system to be developed. In addition, the analyst identifies how to integrate the processes of the existing software system with the proposed software system.
Appoint a Domain Expert

It is important to obtain input about the technicalities of a particular system before you gather and document requirements. For example, you may need to develop an account keeping system that involves various technicalities, such as when to debit a transaction. In such a situation, you need to consult a domain expert who has expertise about the technicalities of the account keeping process. Consulting a domain expert will enable you to understand all the bank transactions, which, in turn, will help you to develop a robust software solution.
Identify Story Boarding Techniques

The requirements communicated by the customer may not be stated clearly. You may need to interpret the requirements and create an outline for the software system that needs to be developed. This outline should
7/21/12
be presented to the customer for approval. Storyboarding is a technique that involves the task to design a series of user interfaces on paper before you develop the software system. The user interface storyboards match the definitions of the use case paths described in the basic course of events and provide the graphic presentations of various processes. Storyboarding enables you to obtain customer feedback on how the system should work at a very early stage. Storyboards include large cardboard wall charts with pictures that depict the sequence of each process. The objective of storyboarding is to: Understand data visualization. Define and understand business rules. Model algorithms and other mathematical constructs. Demonstrate reports. An analogy for storyboarding is creating sketches for an advertisement project. To create an advertisement, the creative team normally draws or sketches the idea of the advertisement on paper. This enables the creative team to communicate their thoughts to the customer and obtain an approval from the customer before the team creates actual advertisement. Similarly, storyboarding enables you to obtain an early response from the stakeholders for the unclear requirements. Storyboarding not only enables you to obtain feedback from the customer on user interfaces. It also enables you to demonstrate how the various sequence of actions will be performed using the software application. You can apply different types of storyboards in one project. The various types of storyboards are: Passive storyboard: Consists of sketches, pictures, screen shots, presentations, or sample application outputs. In a passive storyboard, the analyst gives the description of each result generated by performing a particular operation. Active storyboards : Consists of animations or an animation tool, and a recorded computer script or simulation. Active storyboards provide an automated description of the software system behavior in an operational scenario. Interactive storyboard: Consists of the simulations or prototypes. This storyboard requires an interaction with the end user and is useful to capture the requirements about which the stakeholders are not clear.
16/34
7/21/12
Creating Use Case Diagrams for System Modeling

A use case diagram for system modeling describes the interaction between the use cases and actors of the proposed software system. In addition, a use case diagram outlines the various relationships, such as association and generalization, which exist between use cases and actors.
Identifying Use Cases

The use cases identified for system modeling are text descriptions of the interaction between outside entities and the software system. Use cases can model both functional and non-functional requirements. In addition, you use use cases in the design, implementation, and testing phases of software development. The use cases for the proposed software system should contain the following characteristics: Provide value to actors : Each interaction shown using a use case diagram should either provide an output to the external entity or affect the output provided to an external entity that does not participate in the interaction. For example, a use case such as Management Information System (MIS) may not provide value to the data entry operator who enters data. Therefore, the data entry operator is simply a business worker. The manager who will use the data is the actor for the use case. The data contributes indirectly to the manager because the manager uses the data to make business decisions. Although the manager does not directly interact with the data entry part of the system, the system provides value to the manager. Provide a brief description of the desired functionality: The use case diagram should contain a brief description of the proposed process at the first level. Detailed information should be provided in the subsequent steps. A use case should explain all the business and technical requirements that the sub-process needs to implement. The information that a use case should contain includes: Name : Indicates a unique identification of the use case. For example, you can name a use case as Give Appointment. Summary: Indicates the functions provided by the use case. Basic course of events : Indicates the steps of interaction that occur between the actor and the software system to achieve the functions described in the use case. For example, the actor initiates the process and then the system responds. Alternative paths : Describe the situations in which an uncommon condition occurs. Exception paths : Describe the interactions that occur between a use case and an actor when an error occurs. Triggers : List the conditions that must occur to make an actor initiate a use case. Triggers describe a business need, time-related event, or the output of another use case. Assumptions : Specify the conditions that should be true to make the system work. You make these assumptions to make the design of the system relatively simpler. Preconditions : List the conditions that must occur before the interaction between the use case and an external entity begins. Preconditions are outside the scope of the use case and the software system.
7/21/12
Post conditions : List the conditions that are satisfied when the use case is completed. Post conditions are a part of the contract between this use case and the outside world. Business rules : List the business rules that relate to the requirements presented in the use case. Non-functional requirements : List the non-functional requirements that the use case must meet. Author: Specify the name of the author. Date : Contains the date on which the use case was originally written with references to when it was changed. Consider the example of the G i v eA p p o i n t m e n tuse case of the automated hospital administration system. The G i v eA p p o i n t m e n tuse case should specify the following information: Name : Give Appointment Summary: Give appointments to the patients based on the schedule of the doctor and the category of the patient. A doctor can also give appointments to the patients during treatment Actors : Patient and Doctor Assumptions : The doctor has updated the schedule Basic course of events : The patient makes a call for an appointment. The software system asks for the age of the patient. The patient enters the age. The software system checks the schedule of the doctor and gives the appointment accordingly. Preconditions : The doctor's schedule should be valid Post conditions : The software system records the new appointment time and updates the schedule of the doctor Non-functional requirements : The patient should not be required to wait for more than a minute to obtain an appointment Author: Bill Jones Date : 02/07/07
In case of an automated hospital administration system, the business use case, T a k e A p p o i n t m e n t , will change to G i v eA p p o i n t m e n t . Notice that the functions of the use case remain the same. This is because in system modeling, you need to view the software system from the perspective of the automated system that gives the appointment to the patients. The other use cases of the automated hospital administration system will remain the same. However, this might not be the case in all the business scenarios.
Identifying Actors
7/21/12
Like business actors, system actors are external entities that interact with the software system and affect the system functions. An actor could represent a person, another system, or some triggers depending upon the scenario. The system actors can be classified as: Primary actors : Directly affect the system and initiate the use case. For example, a data entry operator for the MIS directly interacts with the system and, therefore, should be represented as a primary actor in the use case diagram. Secondary actors : Do not directly interact with the system but can initiate the interaction of a primary actor with the system. For example, when a supplier provides an invoice to a data entry operator, the supplier should be shown as a secondary actor in the use case diagram. You should depict secondary actors in the use case diagrams only when the actions of these actors affect the responses or output of the system. The actors of the hospital administration system are external entities that initiate any use case of the automated hospital administration system. The actors for the automated hospital administration system are: Doctor Patient Reordering level
In case of the hospital administration system, the actors will be identical to the business actors. However, this might not be the case in all the business scenarios.
Relationships
Relationships depict the interaction of actors with each other and with use cases. The various types of relationships that exist are: Generalization Association Generalization The generalization relationship exists among the actors that have similar behavior and properties. Two actors are said to have a generalization relationship when the characteristics of one actor can be derived from the other abstract actor. The actor from which another actor is derived is known as the super actor and the derived actor is known as the sub actor. For example, the actor, Patient, represents a general behavior and, therefore, is called a super actor. The Upto 14 actor is derived from the Patient actor to show special characteristics and, therefore, the Upto 14 actor is a sub actor. The following figure shows a super actor and two sub actors of
7/21/12
the automated hospital administration system.
Association The association relationship shows the communication path between a use case and an actor. An association is represented using an arrow or a simple line. The arrow shows the direction of communication, and the line indicates that the communication is occurring in both the directions. The following figure shows the association relationship between the P a t i e n tactor and the T a k eA p p o i n t m e n tuse case.
20/34
7/21/12
Activity: Identifying Requirements and Creating a Use Case Diagram for the InfoSuper Bank
Problem Statement
The InfoSuper bank is a leading financial institution having its clientele across the globe. The bank offers the following services to customers: Corporate banking Personal banking Mutual funds Financer Home loans The InfoSuper bank earns 45 percent of its total revenue from the personal banking service. As a result, the bank wants to improve the customer satisfaction level and make efforts to retain and gain customer loyalty. The bank conducts a survey to find the customer requirements in terms of process time, satisfaction level, and resource requirement for personal banking. The result of the survey highlights that on an average a customer visits the bank 10 to 15 times each month for transactions, such as cash withdrawal, check deposit, and acquiring the transaction summary. The bank needs to have a software system that can reduce customer visits and improve customer service through improved facilities. The representatives of the InfoSuper bank presented the requirements for the software system to Janes Technologies. After analyzing the requirement document, the project manager, Jennifer, of Janes Technologies suggested that the bank should incorporate an Automatic Teller Machine (ATM) system with the following features: Cash withdrawal Cash deposit Transaction summary PIN change Fund transfer within the same bank Information about various other services provided by the bank The place where the ATM system will be deployed should also provide boxes where customers can drop the checks and request for checkbooks. Jennifer needs to design the ATM system highlighting the system advantages and constituents.
Solution
To design the ATM system, you need to perform the following tasks: 1. Identify requirements.
7/21/12
2. 3. 4. 5. 6.
Create SRS. Identify use cases. Identify actors. Depict the relationship between use cases and actors. Save the model.
Task 1: Identifying Requirements You can derive the functional requirements from the features specified in the problem statement of InfoSuper bank. The functional requirements for the ATM system are: Cash withdrawal Cash deposit Check deposit Transaction summary PIN change Fund transfer within the same bank Checkbook request The non-functional requirements are the implied requirements that the new software system should implement. The non-functional requirements for the ATM system could be: When a customer requests for cash withdrawal and specifies the amount, the cash should be dispensed within 30 seconds. When a customer requests for transaction summary, the summary should be provided to the customer within 10 seconds. When a customer request for fund transfer within the same bank and provides the necessary details, the transaction should be completed within 30 seconds. When a customer requests to change the PIN and provides the old and the new PIN number, the system should confirm the same within 5 seconds. All transactions performed using the Bank ATM system should be secure. Task 2: Creating SRS SRS provides the specification of frozen requirements in different categories. The SRS for the Cash Withdrawal module, based on the IEEE format is: Introduction: The ATM software will provide a 24-hour cash withdrawal feature to the customers of the InfoSuper bank. Purpose: The SRS document will serve as an input to the design and coding phase of SDLC. Scope: The ATM will enable the bank to increase their customer base because it can be installed at remote locations.
7/21/12
Functional Requirements: The software should validate the customer PIN. The software should uniquely identify combination of the card number and PIN. The software should deny the cash withdrawal request if cash request is greater than the available balance. The software should provide cash only in dollars. The maximum cash withdrawal limit should be $5000 in a day. The minimum cash withdrawal limit should be $100. The software should generate the transaction report for the current transaction. The software should allow the customer to make more than one transaction. Non-functional Requirements: The software should not take more than one minute for a transaction. The software should not withdraw cash less or more than the requested amount. Interface Requirements: The software should have keypad mechanism to input the PIN and cash withdrawal amount. The customer should be able to terminate the cash withdrawal request at any moment. Operating Environments: For the efficient working of ATM system, the temperature should be maintained using a temperature controller device, such as an Air Conditioner.
Institute of Electrical and Electronics Engineers (IEEE) is an organization that develops standards for the computer and electronics industry. IEEE has laid down the standard for the SRS document. You can create specific SRS formats for all the requirements of the InfoSuper bank.
Task 3: Identifying Use Cases You can directly derive the use cases for the ATM system from the SRS document. The use cases are: C a s hW i t h d r a w a l C a s hD e p o s i t C h e c kD e p o s i t T r a n s a c t i o nS u m m a r y P I Nc h a n g e F u n dT r a n s f e r C h e c k b o o kR e q u e s t Task 4: Identifying Actors
7/21/12
The actors for the ATM system are: Centralized bank system: Enables the ATM system to validate the PIN number and balance in the customer's account. It also enables the ATM system to make transactions, such as cash withdrawal and cash deposit. The centralized bank system is external to the ATM system and interacts with the ATM system. Therefore, it is an actor. Bank customer: Requests for the various services, such as cash withdrawal and deposit, offered by the system and enters the PIN number to access the services.
Centralized bank system is external to the ATM system and also interacts with the ATM system and, therefore, acts as an actor.
Task 5: Depicting the Relationship among Use Cases and Actors To establish and depict the relationships among the use cases and actors of the ATM system, you need to draw a use case diagram. You can draw UML diagrams using Microsoft Visio. To create a use case diagram, you need to perform the following steps: 1. Select StartAll ProgramsMicrosoft OfficeMicrosoft Office Visio for Enterprise Architects . The Microsoft Visio window appears. 2. Click Software from Category section in the Choose Drawing Type window. All the templates will appear in the Template section. 3. Select the UML Model Diagram (Metric) template from the list of templates. The Drawing1-Microsoft Visio window with a blank drawing page appears. 4. Select the UML Use Case (Metric) stencil in the Shapes window. 5. Drag the Use Case symbol ( ) from the UML Use Case (Metric) stencil on the drawing page, as shown in the following figure.
24/34
7/21/12
6. Double-click UseCase1 to rename it. The UML Use Case Properties dialog box appears. 7. Type Cash Withdrawal in the Name text box, as shown in the following figure.
25/34
7/21/12
8. Click the OK button. The renamed use case is displayed. 9. Drag the Actor symbol ( ) from the UML Use Case (Metric) stencil on the drawing page. 10. Double-click Actor1 to rename it. The UML Actor Properties dialog box appears. 11. Type Bank Customer in the Name text box. 12. Click the OK button. The renamed Actor is displayed, as shown in the following figure.
To rename a symbol, double-click the symbol to open its Properties dialog box, and type the name in the Name text box.
13. Drag the Communication symbol ( ) from the UML Use Case (Metric) stencil on the drawing page. Connect one end of the communication symbol with the actor and the other end with the use case to represent the interaction between the use case and the actor. The following figure shows the association relationship between the actor and use case as Bank Customer and Cash Withdrawal, respectively.
26/34
7/21/12
The end names are displayed at the two ends of the Communication symbol. In addition, an asterisk(*) indicating multiplicity is also displayed. To change the display options of the Communication symbol, you need to perform the following steps: a. Right-click the Communication symbol and select the Shape Display Options option. The UML Shape Display Options dialog box appears, as shown in the following figure.
27/34
7/21/12
b. Clear the First end name , Second end name , and End multiplicities check boxes from the End options section. c. Click the OK button. The use case diagram appears, as shown in the following figure.
28/34
7/21/12
14. Repeat the preceding steps to draw the following use cases, actors, and the association relationships between the use cases and the actors of the InfoSuper Bank ATM system. Use cases for InfoSuper Bank ATM sytem: Other Information Check Book Request Check Deposit Fund Transfer Change PIN Check Deposit Transaction Summary Actors for InfoSuper Bank ATM system: Centralized Bank System The final use case diagram should appear, as shown in the following figure.
29/34
7/21/12
Task 6: Saving the Model 1. 2. 3. 4. Select FileSave . The Save As dialog box appears. Select the folder in which you want to save the file. Type Bank_ATM in the File name text box. Select Drawing from Save as type drop-down list, as shown in the following figure.
30/34
7/21/12
5. Click the Save button. 6. Close the Microsoft Visio application.
31/34
7/21/12
Summary
In this chapter, you learned that: Business modeling and system modeling enable you to construct the behavioral as well as functional models of a system. As a result, they enable you to identify the problems of the existing system and the requirements of the proposed system. It is essential to identify the stakeholders and their needs to develop a system. Requirement management is an activity that enables you to systematically manage requirements that evolve during the development of a system. Requirement management consists of various activities, such as requirement gathering, requirement analysis and negotiation, requirement specification, and requirement validation. An SRS is a formal document that contains all the final requirements gathered through various processes, such as stakeholder interviews. The requirements validation phase enables you to identify and remove ambiguous requirements. Requirements can be classified as functional and non-functional. The customer explicitly states the functional requirements as opposed to the non-functional requirements, which are the extensions of functional requirements. Use cases are used to model both, functional as well as non-functional requirements. The use case diagram shows the interaction between actors and use cases. Actors represent any external entity that has an effect on the output of the system. There are two types of relationships in which an actor participates, generalization and association.
Exercises
Exercise 1
Blue Valley Consulting Inc. is an organization of real estate specialists who provide expert advice on purchasing, leasing, selling, and building properties. The organization wants to automate recording and reporting of investments, monitor the flow of planned and invested capital funds, track the sources of capital funds, and calculate the return on investments. The automated real estate system of Blue Valley Consulting Inc. should also track the property, leaseholder, and contract details of investments. Mike Womack, CEO of Blue Valley Consulting Inc., has designated the Operations Manager for administering and managing the data entry and maintenance work for the Real Estate Management System. The Operations Manager's responsibilities include creating reports for providing information about inquiries on proposed investments and sale and purchase details for properties. The organization has a Property Manager who is responsible for tracking the utilization of funds made available to him for sale, purchase, leasing, and any other activities related to properties. The Property Manager will also identify different types of projects for investments. Blue Valley Consulting Inc. has partners who help the organization to ensure sufficient return on investments. These partners also provide information to the Property Manager on cash flows and help in
7/21/12
closing deals by providing appropriate consultancy services. These partners are external to the organization and usually have a stake in the properties of the organization and manage few properties owned by Blue Valley Consulting Inc. The responsibilities of the partners include maintaining and leasing properties and providing data and revenues whenever required as per their agreement with Blue Valley Consulting Inc. Using the Real Estate Management System of Blue Valley Consulting Inc., the external partners and Operations Manager can enter data into the system or import data into the system from another system. This data can then be stored and made available for reporting. The Real Estate Management System will also enable the Operations Manager to record details of lease including the lease contract, leaseholders, and property details. The system allows the Operations Manager to enter details of each tenant for billing and tracking. The Operations Manager can also establish cash flow on a regular basis by recording the rent and lease payments made by the tenant. The Operations Manager is also responsible for recording information on sale of a property, or if the company has leased or subleased the property, then information on lease termination. In addition, the Operations Manager's responsibilities include recording the reasons due to which the property will not be managed by the organization at some point. Each investment is made up of the capital committed to the project by the Property Manager and the cash flow generated by leasing parts of the investment to individuals or organizations. Each investment could span several properties. The system allows the Property Manager and Operations Manager to enter such details on property. Identify the use cases and actors that will be involved in the Real Estate Management System of Blue Valley Consulting Inc.
33/34
7/21/12
Reference Links
Defining the System

Reference Reading: Books Managing Software Requirements: A Use case Approach by Dean Leffingwell Don Widrig Publisher: Addison Wesley Reference Reading: URLs http://www.smartdraw.com/resources/centers/ uml/uml4.htm#whatuse
Creating Use Case Diagrams for System Modeling

Reference Reading: Books Managing Software Requirements: A Use case Approach by Dean Leffingwell Don Widrig Publisher: Addison Wesley Reference Reading: URLs http://www.smartdraw.com/resources/centers/ uml/uml4.htm#whatuse
34/34

CHP 32

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CHP 32

Caricato da

Copyright:

Formati disponibili

7/21/12

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Defining the System

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Identifying and Managing Requirements

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Requirement Analysis and Negotiation

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Requirement Gathering Techniques

Conduct Brainstorming Sessions

Object-Oriented Analysis and Design Using UML: Student Guide

Observe the Existing Process

Appoint a Domain Expert

Identify Story Boarding Techniques

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Creating Use Case Diagrams for System Modeling

Identifying Use Cases

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

the automated hospital administration system.

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

5. Click the Save button. 6. Close the Microsoft Visio application.

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Defining the System

Creating Use Case Diagrams for System Modeling

Potrebbero piacerti anche