modeling system requirements

7

1

Chapter 4. Modeling System Requirements (~20/30 marks)

7 4.1 Traditional Approach to Requirement: Data Flow Diagrams, Documentation of DFD Components, Information Engineering Models

4.2 Object-Oriented Approach to Requirement: Object-Oriented Requirements, The System Activities, identifying Input and Outputs, Identifying Object Behavior, Integrating Object-Oriented Models.

4.3 Evaluating Alternatives for requirements, Environment and Implementation

2

7

3

Models and Modeling

A model: a representation of some aspect of the system being built

A variety of models

Many are graphical (e.g. Data flow diagram, ER diagram)

Can show different levels of detail

Some focus on data

Some focus on processing

Purpose: creating a model can help clarify and refine the design

Developing the model raises questions that need to be considered

Models help to simplify complex aspects of systems

7

4

Reasons for Modeling

Learning from the modeling process

New pieces are found to be needed

New questions arise that need to be answered to complete the model

Reducing complexity by abstraction

Systems can be complex and intangible

Models of parts of the system help to clarify and focus on important aspects

Remembering all of the details

Models are a way of storing information for later use in a form that can be digested (e.g. A picture can say a lot)

7

5

Reasons for Modeling (cont.)

Communicating with other development team members

Can show others aspects of the system in a succinct(briefly and clearly expressed) way

Support communication – e.g. someone working on inputs and outputs can use the model to communicate with someone working on processing details

Communicating with a variety of users and stakeholders

Users need to see clear and complete models to understand what the analyst is proposing

Users often work with analyst to create models (this process can help users better understand what the system can do)

7

6

Reasons for modeling (cont.)

Documenting what was done for future maintenance/enhancement Critical development team leaves behind a record of

what was created Need to package everything in a form future

developers can understand and use when they modify and update the system

Much of the documentation consists of models (e.g. diagrammatic) as text mentions – also much of documentation also consists of textual reports

7

7

Types of Models Mathematical model: a series of formulas that describe technical

aspects of a system

Ex: R=r1, r2, ..., rn ;

S= s1, s2, ..., sn ;

there is a relation {(ri,sj) | ri є R sj є S }

Comfortable for scientific or engineering applications

Sometimes used in business systems – e.g. simple formula for payroll where you model gross pay as regular pay plus overtime pay

Descriptive model: narrative memos, reports, or lists that describe some aspect of the system

E.g. might jot down notes from interviewing a user

Users may describe what they do in reports or memos

Analyst can then convert these descriptions to a modeling notation

7

8

Types of Models (cont.) Sometimes narratives are the best way for recording information

Simple lists of features, inputs, outputs, events or users are examples

A very important form of narrative model: writing a procedure in a very precise way – structured English or pseudocode

Pseudocode used a lot by programmers, can also be used to describe procedures during earlier phases

Example of Pseudocode description of a payroll function:

1. Input the employees payroll data

2. If hours worked is greater than 40 then calculate overtime pay

3. Calculate gross pay for the employee - Gross Pay = hourly pay times 40 plus overtime

4. Calculate tax for the employee ETC.

7

10

Types of Models (cont.)

Graphical Model: diagrams and schematic representations of some aspect of a system Easy to understand complex relationships (old saying: a

picture is worth a thousand words) Graphical models may look similar to a real-world part of

the system (e.g. a screen design or report layout) But often represent more abstract things, e.g. processes,

data, objects, messages, connections Key graphical models tend to represent abstract aspects

of a system during Analysis Phase The more concrete models (e.g. screen design) tend to

appear later in the Design Phase

7

11

Notes on graphical models

Many different types and formats Variations in notation However, still based on basic symbols

Circle Square Rectangle line

7

12

Models used in the Analysis Phase

The analysis phase named “Define System Requirements” involves creating models logical models (define what is required without

committing to one specific technology)

Many different types of formalisms for defining logical models

7

14

Models used in the Design Phase

These are physical models – since will be implemented with a specific technology

Some are extensions of requirements models created during systems analysis

Some may be used during both analysis and design (e.g. object-oriented class diagram)

7

16

Events and System Requirements Two key concepts to model:

Events Things

Event – an occurrence at a specific time and place, that can be described and is worth remembering E.g. customer placing an order, shipping identifies a

backorder, nuclear reactor goes to meltdown

When defining system requirements it is useful to begin by asking what events occur that will affect the system being studied What events will occur that the system will have to respond

to? Allows you to focus on external environment to keep you at

high level view of system (not the workings of it)

7

17

Events (cont.)

Also allows you to focus on the interfaces of the system to outside people and systems

End users can easily describe system needs in terms of events that affect their work, very useful when working with users

Gives a way to divide (or decompose) the system requirements so you can study each separately (complex systems need to be decomposed based on events)

7

19

“Things”

In addition to modeling events, we have to model the “things” that the system needs to store information about E.g. products, orders, invoices, customers etc.

In traditional approach, these things make up the data which the system stores information about

In the object-oriented approach these things are objects

7

20

A way to identify “things” of interest

The analyst can identify types of things by thinking about each event in the event list and asking what types of things are affected that the system needs to know about E.g. when a customer places an order we need to

know about the following The customer

The items ordered

Details about the order

e.g. date and payment terms

7

21

Relationships among Things Relationship: a naturally occurring association among

specific things An order is placed by a customer and an employee works in a

department “Is placed by” and “works in” are two relationships Relationships apply in two directions

A customer places an order An order is placed by a customer

Important to know the number of associations of things – I.e. the cardinality (or multiplicity) of the relationship

E.g. one to one, one to many

It is also important to know the range of possible values of the cardinality

Zero to many (optional relationship), one to one, and one to many (mandatory relationships)

7

23

Types of relationships Binary relationship

Relationship between two different types of things E.g. between a customer and an order

Unary (recursive) relationship Relationship between two things of the same type

E.g. one person being married to another person

Ternary relationship A relationship between three different types of things

E.g. one order associated with a specific customer plus a specific sales representative

n’ary relationship A relationship between n (any number) different types of things

7

24

Attributes of Things

Attribute: one piece of specific information about a thing E.g. a customer has a name, phone number,

credit limit etc. (these are attributes of a customer) Compound attribute: an attribute that contains a

collection of related attributes – E.g. a full name is made up of first and last name

Identifier (key) – an attribute that uniquely identifies a thing E.g. a person’s social insurance number (?), or an invoice or transaction number)

7

26

Data Entities and Objects

Data entities For the traditional approach, are things the system needs

to store information about. Modeled as boxes in the ER diagram)

Computer processes interact with these data entities Entities are things like customers and order

Objects – the other way to look at things Similar to data entities in traditional approach BUT the objects do the work in the system, they do not

just store information (i.e. They have behavior) This difference has important effects on system modeling

7

27

Objects

Class: the type or classification to which all similar objects belong (e.g. guitar and violin objects both belong to class “stringed instruments”) Classes, associations among classes and attributes of classes are

modeled using a class diagram

Attribute:Store information (data) about the class, e.g. Custumer: name:string, ID:integer,Married:boolean

Method: the behaviours all objects of the class are capable of A behaviour is an action that the object processes itself, when asked to do

so E.g. ask a boiler object to check its water level by sending it a message

Encapsulation: covering or protecting each object so that it contains values for attributes and methods for operating on those attributes (making the object a self-contained and protected unit)

7

29

The Entity-Relationship Diagram

Used in traditional approach Emphasizes data storage

Data entities

Their attributes

Relationships among data entities

Model used to define data storage Entity-relationship diagram (ERD)

7

30

ERD Notation

Rectangles: data entities Lines connecting rectangles: relationships

7

31

Customer OrderPlace1 0..n

7

------------------------------------------- --------------------------------------------- -------------------------------------------

32

7

33

1. (Traditional Approach to Requirements) Data Flow Diagrams (DFD)

Data Flow Diagram (DFD) A graphical system model that shows all of the main

requirements for an information system: inputs, outputs, processes and data storage

Everyone working on the project (and end users) can see all the aspects of the project in the diagram with minimal training (simple – only 5 symbols)

7

A DFD is a graph showing the flow of data values from their sources through processes that transform them to their destinations.

A DFD contains

1. Processes – that transforms data

2. Data flows – that move data

3. Actor objects / External agents – that produce or consume data

4. Data store – that store data passively

DFD shows the functional relationships of the values computed by the system– Functional Model

34

7

36

Elements of a Data Flow Diagram

The square is an external agent A person or organization, outside the boundary of a

system that provides data inputs or accepts data outputs

The rectangle with rounded edges is a process A symbol that represents an algorithm or procedure

by which data inputs are tranformed into data outputs

The lines are data flows Represents movement of data

The flat three-sided rectangle/ parallel lines are data stores (a file or part of a database) A place where data is held

7

38

Data Flow Diagrams and Levels of Abstraction

Levels of abstraction Particular to any modeling technique that breaks

the system into a hierarchical set of increasingly more detailed models

Example above – a DFD fragment – showing one process in response to one event

Other diagrams show the processing at a higher level (more general) or lower level (a more detailed view of one process)

Higher level processes in a DFD can be decomposed into separate lower level DFD (or some other diagram)

7

39

Context Diagrams(Level0)

Context Diagram: A DFD that summarizes all processing activity within the system in single process symbol Describes highest level view of a system All external agents and all data flows into and out

of a system are shown in the diagram The whole system is represented as one process

Example – fig. 6-5 shows a context diagram for a university course registration system that interacts with 3 agents: academic dept., student, and faculty member

7

41

Notes on Context Diagram

Useful for showing system boundaries External agents are outside the software scope

(which is represented by the single process). But not from System Analysis

Data stores are not shown in the context diagram since they are considered to be in the software scope (i.e. the single process)

It is the highest level DFD Context diagram does not show any details of what

takes place within the system (i.e. that single process)

7

43

DFD Fragments(Level 1) DFD fragment: A DFD that represents the

system response to one event within a single process symbol A fragment is created for each event in the event list –

it is a self-contained model showing how the system responds to a single event

Created one at a time Fig. 6-7 shows 3 DFD fragments for a course

registration system Each fragment represents all processing for an event

within a single process symbols The data stores in the DFD fragment represent

entities in the ERD (Entity Relationship Diagram – see last lecture) – Not Necessarily !

7

47

The Event-Partitioned System Model

Event-partitioned system model: a DFD that models requirements using a single process for each event The entire set of DFD fragments can be combined into this single

DFD called the event-partitioned system model or diagram 0 Diagram 0 shows the entire system on a single DFD

Figure 6-10 (next slide) shows a set of four related DFDs The top diagram shows the Context diagram for course

registration (same as fig. 6-5 above) The diagram below that (Diagram 0) is the decomposition of the

one process in the context diagram AND consists of the a combined version of the 3 DFD fragments in fig. 6-7 above (in fig. 6-10, DFD fragment 1 is shown below diagram 0)

Finally, Diagram 1 is a decomposition of the process in DFD fragment 1

7

49

Next Step: After the subsystems are defined: A DFD is created to represent the division of the

system into subsystems – the subsystem DFD This subsystem DFD shows how the four RMO

subsystems are connected (i.e. how they are related to all the outside sources and destinations of data)

Note that there is a process in the diagram for each of the four subsystems that were defined for RMO

See figure 6-13 for an example based on the 4 subsystems in the RMO example

Note - even with only 4 subsystems (rather than one process for each of the 20 events) the diagram gets cluttered

7

51

Next Step: can decompose a subsystem DFD into event-partitioned models - one for each subsystem: In the RMO example can expand the subsystem in

fig. 6-13 called “Order entry subsystem” into an event-partitioned model

this model has 5 processes within it – see next slide

The analyst would also create an event-partitioned model for the other 3 subsystems in the RMO example

7

53

Summary - Relationship of all these diagrams

Figure 6-12 shows the relationship among DFD abstraction levels when subsystems are defined

The figure starts off with the context diagram, which breaks down to the subsystem diagram (one for each subsystem)

The subsystem diagram is turn broken down into the event-partitioned subsystem diagrams

ETC.

7

54

Layers of DFD Abstraction

7

55

Decomposing Processes to see Details of One Activity

Using this same principle of breaking down the model to more detailed level, we can take a DFD fragment (e.g. create new order fragment from the RMO example) and decompose it into sub-processes

In figure 6-15 this is shown Since fragment “create new order” was the second

DFD fragment defined for the RMO example (see fig. 6-8) we will label processes inside of it as processes 2.1, 2.2, 2.3 etc.

The diagram decomposes “create new order” into 4 sub-processes (see fig. 6-15) – labeled sub-processes 2.1-2.4

7

57

Evaluating DFD Quality

A quality set of DFDs is

Readable

Internally consistent

Accurately represents system requirements

Minimizing complexity

Want to avoid information overload

Occurs when too much information is presented to a user at one time

Two ways to avoid information overload use 7 + or – 2 rule (which limits the number of components) and interface minimization (which minimizes the number of interfaces and connections between components)

A single DFD should have no more than 7 + or – 2 processes

No more than 7 + or – 2 data flows into or out of a process

7

58

Data Flow Consistency Want consistency in DFDs Common errors:

Differences in data flow for a process and its decomposition (want to have balancing: equivalence of data content between data flows entering and leaving a process or its decomposition)

Black hole A process with data input that is never used to produce a

data output Miracle

A process with a data output that is created out of nothing (I.e. “miraculously appears”)

Black hole and miracle problems apply to both processes and data stores

Most CASE tools perform data flow consistency checking

7

61

Documenting Data Flow Diagram (DFD) Components

Process Descriptions Each process on a DFD needs to be defined Can keep breaking down DFD to more detailed

DFD but at some point have to describe the process in structured English

Uses instructions, repetition and if-then-else logic Note that this is not necessarily a computer

program (its an algorithm that describes the process)

7

63

Limitations of structured English

Good for representing processes such as those in previous slide

Not so good for showing complex decision logic – as shown in next slide

Not so good if there are few or no sequential steps

Decision Table

A tabular representation of processing logic containing decision variables, decision variable values and actions (or formulas)

Decision Tree

A graphical description of process logic that uses lines organized like branches of a tree

7

65

Making a Decision Table (from the logic on previous slide)

Step 1 Identify the decision variables

Year to date purchases (YTD) Number of items ordered Delivery date

Step 2 Put variable with fewest possible value ranges in the

first row of the table In this example could put either YTD or number of items

7

66

Table so far is just one row:

YTD Purchases > $250 YES NO

Step 3 – put variable with next fewest possible value ranges as next row in the table, to now get:


Number of Items (N) N <=3 N>=4 N<=3 N>=4

Step 4 – keep inserting rows as in step 3 until all decision variables are included in the table

7

67

Table now looks like:


Number of Items (N) N <=3 N>=4 N<=3 N>=4

Delivery Day Next 2nd 7th Next 2nd 7th Next 2nd 7th Next 2nd 7th

Step 5 – Finally put as bottom row of the table the actions for each of the possible conditions – see next slide (fig. 6-22) from the text for the complete table

7

69

Decision Tree

A graphical description of process logic that uses lines organized like branches of a tree

Decision table is more compact but decision tree is easier to read

Decision tree can be developed in essentially same way as a decision table (only difference is that it runs horizontally – i.e. Rows in a decision table are columns in the tree – just flip the table sideways and you get the tree)

7

71

there may be several actions associated with a set of conditions in a Decision Table Figure 6-24 shows a table where if the customer is

new and if an item is on backorder for >= 25 days then two things are done:

(a) include detailed return instructions

(b) expedite delivery

See next slide for this example

7

73

Data Flow Definitions Data flow – a collection of data elements Data flow definition – a textual description of a data flow’s

content and internal structure Lists all the elements- eg. a “New Order” data flow consists of

Customer –Name

Customer-Address

Credit-Card-Information

Item-Number

Quantity

Most of these are stored and correspond to the attributes of data entities

In addition to just listing elements can use algebraic notation Data flow “equals” one element followed by another (repeating groups can be

shown in curly brackets)

7

78

Data Element Definitions

Describe a data type E.g. String, integer, floating point, or Boolean Lengths are usually defined for strings Numeric values usually have a minimum and maximum

value (a valid range) Might define special codes (e.g. code A means ship

immediately etc.)

7

79

+int

9(4)

+9(6).99

String[50]

7

80

Data Store Definitions

Usually, a data store on the DFD represents a data entity on the ERD

Should look at the ERD for details on this If no ERD can define the data store as a

collection of elements (like did for data flows)

7

81

Workflow Modeling

Workflow The flow of control through a processing activity as it

moves among people, organizations, computer programs, and specific processing steps

Encompasses Trigger

The processing steps that respond to a trigger

Participants (or “actors”) – can be people and machines

Flow of data

7

82

Workflow models directly model the sequence of processing activities Can develop and check with users to gain better

understanding of a system or organization

Can also be developed during the transition between analysis and structured design

Can be used to describe complex interactions Can be used to describe alternative approaches Uses some symbols from flow charts

DFD are good at capturing flow of data within a workflow (but not control)

Flow charts and activity charts can represent control flow but don’t represent data flow

74.2 Object-Oriented Approach to

Requirements1. OO Requirements

2. The System Activities

3. Identifying Input and Outputs

4. Identifying Object Behavior

5. Integrating Object Oriented Models

7

Learning Objectives Understand the models and processes of defining

object-oriented requirements

Develop use case diagrams and activity diagrams

Develop system sequence diagrams

Develop state machine diagrams to model object behavior

Explain how UML diagrams work together to define functional requirements for the object-oriented approach

Systems Analysis and Design in a Changing World, 5th Edition 86

7

Overview The objective of requirements definition is

understanding – understanding the users’ needs, the business processes, and the systems to support business processes

Understand and define requirements for a new system using object-oriented analysis models and techniques

Line between object-oriented analysis and object-oriented design is somewhat fuzzy Iterative approach to development Models built in analysis are refined during design


7

88

1.Object-Oriented Requirements Object-oriented system requirements are specified and

documented through process of building models

Systems development process starts with identification of events and things

Events are business processes that new system must address

Things are problem domain objects involved in business process

7

89

Requirements Diagrams: Traditional and OO Models

7

90

Object-Oriented Approach Models Class diagram – definition of system components Use case diagrams and use case descriptions –

What are user roles and how they use the system Systems sequence diagrams (SSDs) – define inputs

and outputs and sequence of interactions between user and system for a use case

Statechart diagrams – describe states of each object Activity diagrams – describe user activities

72.The System Activities—A Use Case/Scenario View(refer

notes) Use case analysis used to identify and define all

business processes that system must support

Use case – an activity a system carried out, usually in response to a user request

Actor

Role played by user

Outside automation boundary


7

Techniques for Identifying Use Cases Identify user goals

Each goal at the elementary business process (EBP) level is a use case

EBP – task performed by one user in one place and in response to business event that adds measurable business value, and leaves system and data in consistent state

Event decomposition technique (event table)

CRUD analysis technique (create, read/report, update, delete) to ensure coverage


7

Use Case Diagram

Graphical UML diagram that summarizes information about actors and use cases

Simple diagram shows overview of functional requirements

Can have multiple use case diagrams

By subsystem

By actor


7

Simple Use Case with an Actor


Figure 7-2

7Use Case Diagram with Automation Boundary and Alternate Actor Notation


Figure 7-3

7All Use Cases Involving Customer as Actor


Figure 7-4

7Use Cases of RMO Order Entry Subsystem


Figure 7-5 (partial figure)

7

<<Includes>> Relationship

Documents situation in which one use case requires the services of a common subroutine

Another use case is developed for this common subroutine

A common use case can be reused by multiple use cases


7Example of Order-Entry Subsystem with <<Includes>> Use Cases


Figure 7-6

7

Developing a Use Case Diagram Underlying conditions for describing use cases

Based on automated system, e.g. users “touch” the system

Assume perfect technology condition

Iterate through these two steps Identify actors as roles List goals, e.g. use cases, for each actor. A goal is a unit

of work.

Finalize with a CRUD analysis to ensure completeness


7

101

3.The Class Diagram(refer notes)

There are two kinds of descriptions of systems Structural information (components of the system)

Behavioral information (logic performed by components)

Class diagram provides definition of structural components of the system

The other OO diagrams (e.g. use case, sequence, collaboration) focus on activities the system performs

NOTE – with OO Analysis, the class diagrams describes system requirements that can map very closely to the structure (i.e. classes) in the OO computer program that will be eventually created

7

102

Generalization/Specialization Hierarchies• Hierarchies that structure or rank classes from the

more general superclass to the more specialized subclasses (sometimes called inheritance hierarchies)

• Generalizations• group similar types of things like all cars share certain

features (e.g. all cars have wheels, engine etc.)• Specializations

• are judgments that categorize different types of things (e.g. sports car is a special type of car)

• A generalization/specialization hierarchy structures things from the general down to the more special – Each class has a more general class above it – a superclass– A class may have a more specialized class below – a

subclass

7

103

7

104

7

•Inheritance: a concept that allows subclasses to share characteristics of their superclasses

•E.g. a sports car has everything a car has (e.g. 4 wheels and an engine, which it “inherits” from the class car which is above it)

•The sports car then specializes E.g. has a sports option, racing wheels etc.

105

Inheritance

7

106

Aggregation (Whole-Part Hierarchies)

•Can also structure things by defining them in terms of parts•Aggregation: A relationship between and object and its parts•E.g. aggregation in the context of a computer system, a computer system is made up of:- processor, main memory, keyboard, disk storage, monitor

7

107

7

108

Example of Class Diagram Notation

7

109

Another Example of Class Diagram Notation

7

Activity Diagrams

Used to document workflow of business process activities for each use case or scenario

Standard UML 2.0 diagram as seen in Chapter 4

Can support any level of use case description; a supplement to use case descriptions

Helpful in developing system sequence diagrams


7

Activity Diagram— Telephone

Order Scenario


Figure 7-8

7

Activity Diagram— Web Order Scenario


Figure 7-9

7Identifying Inputs and Outputs—The System Sequence Diagram(refer

notes) Interaction diagram – a communication diagram or a

sequence diagram

System sequence diagram (SSD) is type of UML 2.0 interaction diagram

Used to model input and output messaging requirements for a use case or scenario

Shows sequence of interactions as messages during flow of activities

System is shown as one object: a “black box”


7

SSD Notation Lifeline or object lifeline is a vertical line under object

or actor to show passage of time for object Message is labeled on arrows to show messages

sent to or received by actor or system Actor is role interacting with the system with

messages Object is the component that interacts with actors

and other objects


7System Sequence Diagram (SSD)

Notation


Figure 7-10

7

SSD Lifelines Vertical line under object or actor

Shows passage of time

If vertical line dashed Creation and destruction of thing is not important for

scenario

Long narrow rectangles Activation lifelines emphasize that object is active only

during part of scenario


7

SSD Messages

Internal events identified by the flow of objects in a scenario

Requests from one actor or object to another to do some action

Invoke a particular method


7

Repeating Message


Figure 7-11

7Developing a System Sequence

Diagram Begin with detailed description of use case from fully

developed form or activity diagram

Identify input messages

Describe message from external actor to system using message notation

Identify and add any special conditions on input message, including iteration and true/false conditions

Identify and add output return messages


7Activity Diagram of the Telephone Order Scenario


Figure 7-12

7Resulting SSD for the Telephone Order Scenario


Figure 7-13

7

SSD of the Web Order Scenario

for the Create

New Order Use case


Figure 7-14

7Identifying Object Behavior— The State Machine Diagram(refer

notes) State machine diagram is UML 2.0 diagram that models object states and transitions Complex problem domain classes can be modeled

State of an object A condition that occurs during its life when it satisfies some

criterion, performs some action, or waits for an event Each state has unique name and is a semipermanent

condition or status

Transition The movement of an object from one state to another state


7Simple State Machine Diagram for a

Printer


Figure 7-15

7State Machine Terminology

Pseudostate – the starting point of a state machine, indicated by a black dot

Origin state – the original state of an object from which the transition occurs

Destination state – the state to which an object moves after the completion of a transition

Message event – the trigger for a transition, which causes the object to leave the origin state

Guard condition – a true/false test to see whether a transition can fire

Action expression – a description of the activities performed as part of a transition


7Composite States and Concurrency—

States within a State


Figure 7-16

7Concurrent Paths for Printer in the On State


Figure 7-17

7Rules for Developing State Machine

Diagram Review domain class diagram, select important ones,

and list all state and exit conditions

Begin building state machine diagram fragments for each class

Sequence fragments in correct order and review for independent and concurrent paths

Expand each transition with message event, guard-condition, and action-expression

Review and test each state machine diagram


7States and Exit Transitions for

OrderItem


Figure 7-18

7Partial State Machine for OrderItem


Figure 7-19

7

Final State Machine for OrderItem


Figure 7-20

7Order Domain Class for RMO—

States and Exit Transitions


Figure 7-21

7First-Cut State Machine Diagram for

Order


Figure 7-22

7Second-Cut State Machine Diagram for Order


Figure 7-23

7

Integrating Object-Oriented Models

Complete use case diagram is needed to understand total scope of new system

Domain model class diagrams should also be as complete as possible for entire system

With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration

Development of a new diagram often helps refine and correct previous diagrams


7Relationships Between OO

Requirements Models


Figure 7-24

7

4.3 Evaluating Alternatives for requirements, Environment and

Implementation

7Major Activities in the Analysis Phase

Gather information Define system requirements Prototype for feasibility and discover Prioritize requirements Generate and evaluate alternatives Review recommendations with management

7The end of the Analysis Phase

During analysis many more requirements may be determined than can be dealt with

Must prioritize and evaluate them Several alternative packages of requirements may be

developed A committee of executives and users will decide

which are most important Must select a system scope and level of automation Methods of development are reviewed

7Assessing the Target Processing

Environment Target processing environment

Configuration of computer equipment, operating systems and networks that will exist when the new system is deployed

Must be a stable environment to support the new system

Design and implementation of the processing environment is one of the early activities in moving from analysis to design

71.Centralized Systems

Prior to the early 1980’s there was only one environment – the mainframe computer system at a central location

Options focused around what kind of input or output to these large systems

Common to large-scale batch processing applications (e.g. banking, insurance, government etc.) where:

Some input transactions don’t need to be processed in real time

On-line data entry personnel can be centrally located

Large numbers of periodic outputs are produced

Often used for a subsystem of a larger, sometimes distributed information system

72.Single Computer Architecture

Places all information system resources on a single computer system and its attached peripherals

Requires all users be located near the computer Advantage is simplicity and ease of maintenance However, many systems require more computing

power than one single machine can provide

73.Cluster Architecture

A group of computers of the same type that have the same operating environment and share resources

Computers from the same manufacturer are networked

Clusters act like a single large computer system One may act as entry point and the others

function as slave computers

74.Multicomputer architecture

A group of dissimilar computers that are linked together but the hardware and operating systems are not required to be a similar as in the clustered architecture

System still functions like one single large computer

Can have central computer and slave computers Main computer may execute programs and hold

database The front-end computer may handle all communication

75.Distributed Computing

Distributed computing The approach to distributing a system across several

computers and locations

E.g. corporate financial data might be stored on a centralized mainframe, linked to minicomputers in regional office and personal computers at more locations

Relies on computer networks to connect up the systems

76.Client-Server Architecture

Currently the dominant architectural model for distributing information resources

Server computer (server): A computer that provides services to other computers on the network

Client computer: A computer that requests services from other computers on the network

E.g. print server on a network, that clients (other PCs on the network) can send print jobs to

Middleware

Computer software that implements communication protocols on the network and helps different systems communicate

Data layer

A layer on a client-server configuration that contains the database

77.Three Layer Client-Server Architecture

An information system application program can be divided into the following set of client and server processes or layers

Three-layer architecture

The data layer

Manages stored data, implemented as one or more databases

The business logic layer

Implements the rules and procedures of business processing

The view layer

Accepts user input, and formats and displays processing results

View layer acts as client of the business logic layer, which acts a a client of the data layer

7Notes on Three Layer Architecture

Easy to distribute and replicate over a network Layers are relatively independent of each other Can be expanded into a larger number of layers N-layer architectures, or n-tiered architectures

A client-server architecture that contains n layers

7The Internet and Intranets

Internet: a global collection of networks that are interconnected using a common low-level networking standard – TCP/IP (Transmission Control Protocol/Internet Protocol)

Services provided by the Internet E-mail protocols (Simple Mail Transfer Protocol – SMTP) File transfer protocols (e.g. File Transfer Protocol – FTP) Remote login and process execution protocols (e.g.

Telnet)

7Intranets and Extranets

Intranet

A private network that is accessible to a limited number of users, but which used the same TCP/IP protocol as the Internet

Restricted access – firewalls, passwords, unadvertised

Extranet

An intranet that has been extended outside of the organization to facilitate the flow of information (e.g. access to suppliers, customers, and strategic partners)

Allows organizations to exchange information and form a virtual organization

The Web is organized as a client-server architecture Web processes are managed by server processes

that execute on dedicated servers and clients send requests to servers using a standard web resource request protocol

7The Internet as an Application Platform

The Internet provides an alternative for implementing systems E.g. RMO buyer can access the system while on the

road – the client portion of the application is installed on their laptop computers (uses modem/wi-fi/… to connect)

Using the WWW for accessing the remote site, all the buyer needs is a web browser and is now accessible from any computer with Internet access

Use of the Internet greatly expands accessibility and eliminates need to install custom client software – also cheaper to put up on the Web

7Advantages of WWW over traditional client-server approaches

Accessibility

Web browser and Internet connections are nearly ubiquitous and are accessible to large numbers of users

Low-cost communication

High-capacity WAN form the Internet backbone are funded primarily by governments (a company can use the Internet as a low-cost WAN)

Widely implemented standards

Web standards are well known and many computer professionals are trained in their use

Use of intranet or extranet enjoys all the advantages of web delivery

Really represents evolution of client-server computing to the WWW

7

Negative Aspects of Application

Security Web servers are well-defined target for security

breaches Reliability

Internet protocols do not guarantee a minimum level of network through put or that a message

Throughput Data transfer capacity of many users limited by analog

modems to under 56 kilobits per second Volatile standards

Web standards change rapidly

7Development and System Software

Environments Development environment

Consists of standards and tools used in an organization

E.g. CASE tools, programming standards

System software environment Includes operating system, network protocols,

database management systems etc.

Important activity during analysis To determine the components of the environment that

will control the development of the new application

7Important components of the environment

that will affect the project

Language environment and expertise

Companies often have preferred languages

Numerous languages out there – COBOL, C++, Visual Basic, to web-based languages like Java and Perl Script

Choosing a new language requires additional work

Existing CASE tools and methodologies

If a company has invested heavily in a CASE tool then all new development may have to conform to it

Required interfaces to other systems

A new system typically must provide information to and receive it from existing systems

7

Operating System environment Strategic goals may exist to change the operating

system Multiple platforms may be needed Legacy systems are often still there and may be

linked to newer client-server applications and databases

Database management system (DBMS) Many corporations have committed to a particular

database vendor May require a distributed database environment with

portions distributed over the country

7Deciding on Scope and Level of Automation

Scope of a system E.g. current RMO point-of-sales system’s scope includes

handling mail and telephone sales but not Internet

Level of Automation In the new system a very low level of automation is

needed for telephone sales aspects

“Scope creep” A problem with development projects where requests for

additional features just keeps continuing To avoid we need to formalize the process of selecting

which functions are critical or not We need to Prioritize Requirements

7Scoping Table

Scoping table: a tabular list of all the functions to be included within a system

It is an expanded version of the event table It may include events from the event table plus

some identified later on Each business function can be prioritized

Mandatory Important Desirable

7Defining Level of Automation

Level of automation The kind of support the system will provide for each function

Low, middle, high

E.g. low level is using computer for order-entry function, high level is using computer to support high-level decision making by human

Low end is basically an automated version of a current manual procedure

A high level occurs when system takes over as much as possible the processing of the function

High end often involves creating new processes and procedures

7

Rocky Mountain Outfitters – example of functions of a high-end system Customers can access catalog on-line with 3D

pictures over the WWW The catalog is also interactive and allows customer

to combine items The user interface is voice-activated Payment is verified on-line The customer can see a history of all prior orders

and can check the status of any order over the WWW or telephone

7Selecting Alternatives

More and more new systems are being used to provide high-level automation solutions

Criteria used to decide which functions to support and level of automation are based on Strategic IT plan Feasibility study

Economic feasibility

Operational, organizational and cultural feasibility

Technological feasibility

Schedule and resource feasibility

7Evaluation of Alternatives for RMO

example

Project team decided to include all functions that were classified as mandatory or important

For each, a detailed analysis was done to determine level of automation

A table or list can be made of preliminary selection of which functions to include and at what level of automation

For most functions, a medium level of automation was selected (see shaded boxes)

See next slide for part of that table

7Generating Alternatives for Implementation

Now ask “where do we go from here?” Options include buying a computer program if the

application is fairly standard OR company may decide to build the system from ground up

Next figure shows this in a graph Vertical column is the build-versus-buy axis (at the top

of the axis the entire system is bought as a package) In between is a combination of buy and build There a various alternatives ranging from in-house

development to purchasing a complete ERP system

7

Cloud

7In-House Development

Large and medium-sized companies have in-house development staff

A problem with this is that special technical expertise may be beyond employees’ experience

So may use company employees to manage and staff projects, but also call in consultants when needed

Advantage Control of project and knowledge retained in the company Company can build internal expertise

Disadvantage In-house staff may not know when they need assistance

7Custom Software Development

A solution that is developed by an outside service provider

New system is developed from scratch (using SDLC)

But project team consist mainly of outside consultants

Advantages of custom development: consulting firm may have developed similar systems and has good

knowledge of the domain and pool of qualified staff

Outsourcing and contract development are the fastest growing segments of the IS industry

Disadvantage: the cost (paying at high consulting hourly wages – e.g. $100 per

hour is typical)

Opted for when no in-house expertise or tight schedules

Often for large systems (e.g. health care) where cost is outweighed by savings due to high volume of use of system

7Packaged and Turnkey Software Systems

Packaged software: software that is already built and can be purchased as a package Strict definition is that software is used as is, with no change E.g. a standard reporting system package may work for some of

the companies requirements

Turnkey system: a complete system solution, including software and hardware, that can be just turned on Companies creating these systems usually specialize in a

particular industry But problem is that often they don’t exactly meet the needs of an

organization May allow for vendor to customize part of it to better suit needs Company may buy base system + a number of customization

changes and a service agreement (e.g. hospital systems)

7 In some cases only executable code is provided,

other cases include both source and executable Vendor may make the changes or company itself

might (if it has programmers) Enterprise Resource Planning (ERP)

A turnkey system that includes all organizational functions of an organization (e.g. companies such as SAP, Oracle provide these)

May take longer than a year to install Can cost millions Advantage of ERP: a new system can often be obtained

at a much lower cost than in-house development, also risks may be lower

Disadvantage of ERP: system may not do exactly what the organization needs (even after customization). Customization can also take quite a long time and money

7Facilities Management / Cloud

Facilities management: the outsourcing of all data processing and information technology to an outside vendor E.g. a bank my hire a facilities management firm to

provide all of the data processing including software, networks and even technical staff

Typically part of a long-term strategic plan for an entire organization

Contracts cost a lot (millions) – example EDS (Electronic Data Systems)

7Choosing an Alternative for Implementation

Identifying Criteria for Selection Criteria will be used to compare alternative choices (e.g. in-

house or outsourcing) Three general areas to consider

General requirements Technical requirements Functional requirements

General requirements include Feasibility assessment (scope and level of automation) Each alternative must meet the requirements of

Cost

Technology

Operations

schedule

7

For outsourced alternatives The providers stability and performance record is

also important

For in-house alternatives Must consider risks, length of schedule and

availability of in-house expertise

Must evaluate for total cost and impact on the organization of alternatives

7

Criteria for assessment of alternatives

The performance record of the provider

Level of technical support from the provider

Availability of experienced staff

Development costs

Expected value of benefits

Length of time (schedule) until deployment

Impact on internal resources

Requirements for internal expertise

Organizational impacts (retraining, skill levels)

Expected cost of data conversion

Warranties and support services (from outside vendors)

7 Relative importance of each criteria can be weighted on a 5-

point scale (a weighting scale)

1 indicates low importance

5 indicates high importance

Also for each alternative we can rate the alternative for that criteria, on a five point scale

1 indicates the alternative is weak for that criteria

5 indicates the alternative is strong on that criteria

Then we can multiply the importance of a criteria by its rating for each alternative to get extended scores

Finally, we can add up the extended scores for all alternatives and see which comes up best

7 In addition to general requirements, we should include

criteria to evaluate the quality of the software Robustness (software does not crash) Programming errors (software calculates correctly) Quality of code (maintainability) Documentation Easy installation Flexibility (adjusts to new functionality and

environments Structure (maintainable, easy to understand) User-friendliness

Can do tables for the above technical requirements and also for functional requirements (tables 8-8 and 8-9) on next slides