1 Requirements and Initial Analysis Module 3 http://blog.csdn.net/hhmoll/ hhmall@hotmail.com 2004-01-08 Created 2004-01-08 Version 2004 2009-05-25 Last Updated Copyright by Huang Hui @2004-2009

2 Objectives Develop a system design and requirements specification Explain the process of gathering information Explain the role of domain experts Write a definitive Problem Statement Define the importance of building and maintaining a Data Dictionary Define the process of identifying candidate business objects Copyright by Huang Hui @2004-2009

3 Objectives – cont. Explain the role and functionality of the Use Case diagrams Explain the process of writing multiple scenarios for every Use Case Graphically portray a Use Case with an Activity Diagram Explain the importance of risk assessment Explain the packaging of Use Cases and high-level package notation Define Component and Deployment Diagrams Copyright by Huang Hui @2004-2009

4 Starting the Development Process This module focuses on the following Initiating a system development effort Analyzing the initial workflows Gathering information Creating a Problem Statement Creating Use Cases Introducing Component and Deployment diagrams Copyright by Huang Hui @2004-2009

5 Gathering Information You can gather information from several sources, including: Customer’s initial requirements specification Domain Experts Customers and users Managers Input from marketing Previous projects Copyright by Huang Hui @2004-2009

6 Avoiding Traditional Assumptions You must avoid traditional assumptions, such as the following: Users are naive, developers know best Requirements are static You can build a correct solution the first time Remember that projects evolve, and customer requirements can change Copyright by Huang Hui @2004-2009

7 Avoiding Traditional Assumption Do the following: Clearly identify the user’s requirements Ensure that your model can adapt to evolving requirements Ensure that you can change your model Copyright by Huang Hui @2004-2009

8 Domain Experts Refers to specialist in a particular area of business Can be broadly subdivided into: General domain experts Application-specific domain experts and current business experts Similar business domain experts Copyright by Huang Hui @2004-2009

9 Problem Statement Is a document that clearly describes the customer and system requirements for a project Customer input is critical for this document Uses business domain language Has a clear sentences, no jargon Contains details on project scope Specifies the context of the problem Specifies any known constrains Copyright by Huang Hui @2004-2009

10 Problem Domain Refers to a statement that clearly identifies new system-specific areas and problems Can be graphical or textual Copyright by Huang Hui @2004-2009

11 Candidate Objects and Classes Identified from the Problem Statement Underline noun phrases from the Problem Statement to build the list of candidate objects and classes Copyright by Huang Hui @2004-2009

12 Candidate Object and Classes From chap3-problem.doc Copyright by Huang Hui @2004-2009

13 Data Dictionary A document describing all the vocabulary used in a project Entries are gathered with user interviews Stays for the entire length of the project and the system Adds new terminology during the project Satisfies the need for a common vocabulary Assists in a avoiding ambiguity Must be easily available to all project team members Needs frequent, carefully controlled updates Copyright by Huang Hui @2004-2009

14 Data Dictionary chap3_datadictionary.doc Copyright by Huang Hui @2004-2009

15 Creating Use Cases A Use Case is a graphical and schematic representation of a user’s interactions with a system Assists in understanding system requirements and context Graphically shown as an ellipse with solid lines Copyright by Huang Hui @2004-2009

16 Creating a Use Case Model Comprised of several Use Cases Components are: Actors Use Cases System Generalization and association relationships Copyright by Huang Hui @2004-2009

17 Hotel Use Case Diagram Copyright by Huang Hui @2004-2009

18 With New Actor Copyright by Huang Hui @2004-2009

19 Additional Dependencies Copyright by Huang Hui @2004-2009

20 New Extension Points Copyright by Huang Hui @2004-2009

21 Use Case Scenarios Use Cases show a function from the user’s perspective A scenario refers to one instance of a Use Case Scenario do not contain conditional statements Begin the same way, but can end differently Major scenarios should be written Successful and unsuccessful paths through a Use Case should be shown Copyright by Huang Hui @2004-2009

22 Activity Diagrams Show activities, processes, or workflows Are graphical Used anywhere you need to model activities Modeling a Use Case is just one example Copyright by Huang Hui @2004-2009

23 Activity Diagrams Includes the following elements Activities Decision Split of control Merge of control Iteration Object flow Swimlanes Copyright by Huang Hui @2004-2009

24 Activity Diagram Notation Copyright by Huang Hui @2004-2009

25 Example Copyright by Huang Hui @2004-2009